一句话定义：Self-Query Retrieval（自查询检索）是AI 词典：检索增强生成">检索增强生成（RAG）里的一种检索策略：先让大语言模型（LLM）把用户那句口语化的问题拆成两半——一半是用于向量匹配的“语义查询”，一半是结构化的“元数据过滤条件”，然后带着这两样东西去向量数据库（vector database）里查。
原理：先填单子，再找书
打个图书馆的比方。普通向量检索，就像你把想找的内容描述给管理员：“帮我找找报销怎么弄。”管理员很懂语义，按“内容像不像”抱一堆书过来，但他不看出版年份，也不管那本书在哪个馆区——于是三年前的旧制度和隔壁部门的内部文档一起堆到你面前。
Self-Query 相当于让你先填一张借书单：主题写“报销流程”，限制条件写“2023 年以后、财务部、正式发布”。管理员先按单子把范围缩小到那一小格书架，再在里面做相似度排序。
实现上，模型通常输出一个结构化对象，例如 query="差旅报销流程"，filter={"year": {"$gte": 2023}, "department": "财务"}。这依赖模型的结构化输出（structured output）或工具调用（function calling）能力，具体写法以各框架官方文档为准。
和相邻概念的区别
| 做法 | 对问题的处理 | 用不用元数据 |
|---|---|---|
| 普通向量检索 | 整句直接做嵌入（embedding） | 基本不用，或全局硬过滤 |
| 查询改写（query rewriting） | 重写、扩写语义文本 | 不用 |
| 元数据过滤（metadata filtering） | 由人预先写死条件 | 用，但靠人 |
| Self-Query Retrieval | 模型自动拆成语义 + 过滤条件 | 用，且靠模型推断 |
差别就在最后一行：过滤条件既不是人写死的，也不是单纯改写文本，而是模型从问题里“读”出来的。
对实际工作的意义
对做 RAG 的人，这是把“时间、部门、类型、状态”这类硬性限制接入检索的最低成本方式，能减少“语义很像但事实上已过期或不该看”的召回。坑也很实在：元数据（metadata）的字段名和取值必须规范（部门用中文还是英文、年份是数字还是字符串），否则模型生成的过滤器对不上；过滤器写错时，召回可能直接归零，所以要打印出模型生成的条件便于排查，并准备“去掉过滤重试”这种兜底。
对普通使用者，提问时把时间、范围、对象说清楚，系统才用得上这套本事。“最近半年的”“我们部门的”这类限定词，正是它最想要的线索。