核心要点
能给定义：Self-Query 让 LLM 把一句自然语言拆成语义查询和结构化元数据过滤条件两部分
能讲它解决的痛点：纯向量检索处理不了「2023 年之后、作者=X、价格<100」这类精确属性约束
能描述流程：先定义文档 metadata schema → LLM 据 schema 抽取 filter → 执行「向量检索 + metadata filter」
能与相邻技术区分：Query Rewrite/Expansion 改的是查询文本，Self-Query 额外产出可执行的结构化过滤器
标准回答
它是什么
Self-Query（自查询）检索是让 LLM 充当「翻译器」：把用户的一句自然语言问题，解析成两部分——一部分是用于语义相似度检索的「查询字符串」，另一部分是针对文档元数据的「结构化过滤条件」。然后对向量库执行「向量检索 + metadata filter」，先用过滤器把候选文档限定在满足硬约束的子集内，再在其中做语义匹配。
为什么 RAG 需要它
纯向量检索只看语义相似度，对「精确属性约束」无能为力。比如「找 2023 年之后、作者是张三、价格低于 100 的文档」，其中「2023 年之后」「作者=张三」「价格<100」是结构化条件，靠 embedding 相似度根本无法保证精确命中——向量空间里「价格 99」和「价格 101」可能离得很近。Self-Query 把这些条件抽出来交给数据库的精确过滤，剩下的「讲了什么内容」才交给向量检索，从而兼顾语义召回与精确约束。
典型流程
第一步，为文档定义 metadata schema：声明每个可过滤字段的名称、类型和含义（如 year:整数、author:字符串、price:浮点）。第二步，把 schema 连同用户问题一起给 LLM，让它按 schema 抽取出过滤器（通常是结构化的比较/逻辑表达式）和精炼后的语义查询。第三步，把过滤器翻译成向量库支持的 metadata filter，连同语义查询一起执行带 filter 的检索，返回 Top-K。
与普通 RAG 及相邻技术的区别
普通 RAG 只做「embedding 用户问题 → 向量检索」，无法利用结构化字段。Query Rewrite（查询改写）和 Query Expansion（查询扩展）改造的仍是「查询文本本身」，目的是改善语义召回；Self-Query 的独特之处在于额外产出一份「可被数据库执行的结构化过滤器」，处理的是文本相似度之外的硬性约束，三者常常组合使用。
常见误区
⚠️ 常见踩坑
Self-Query 的过滤精度取决于文档入库时是否抽取并存好了规范的 metadata——如果索引阶段没沉淀干净、类型一致的元数据，查询时 LLM 生成的 filter 再准也匹配不到字段，等于白做。
追问
追问 1：LLM 抽取出的过滤器字段或取值不合法怎么办？
要做校验与兜底：把过滤器限定在 schema 允许的字段、类型和取值枚举内，对非法字段或解析失败的情况丢弃该过滤项或回退到纯语义检索，避免直接报错。可用受约束生成（如 JSON Schema 约束输出）提高合法率，并记录失败样本持续优化提示。
追问 2：Self-Query 和 Query Rewrite 能一起用吗？
可以且常配合。一个自然请求里往往既有需要改写以改善召回的语义部分，又有需要精确过滤的属性约束。流程上可以先 Self-Query 拆出 filter 和语义查询，再对语义查询做改写或扩展，最后执行「带 filter 的语义检索」，兼顾召回率与精确度。
追问 3：过滤条件过严导致召回为空，如何处理？
常见策略是分级放松：先用全部硬约束检索，命中为空时按重要性逐步放宽（如把「等于」放宽为范围、去掉次要过滤项），或退化为纯语义检索并在结果里提示用户约束已放宽。也可在前端把抽出的过滤条件展示给用户确认，避免误抽取直接造成零结果。
🔗 相似问题
同一考点的不同问法，面试官可能换着问，一起刷更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习