图解 LangChain 30｜Retrievers：检索的抽象与进阶策略

上一篇讲了 Vector Stores。这一篇讲第五段——Retrievers：检索。

检索是 RAG 五段的最后一段，也是决定「找到的资料质量」的关键。资料找得准不准，直接决定模型答得好不好。这一篇讲 Retriever 这个抽象，以及几种提升检索质量的进阶策略。

Retriever：检索的抽象

Retriever 是一个协议：给一个查询，返回一组文档。就这么简单。

retriever.invoke(查询) → [Document, Document, ...]

为什么要有这个抽象？因为「检索」这件事，来源可能不止向量库：

• 向量库的相似搜索（最常见）
• 关键词搜索（BM25 等）
• 混合检索（向量 + 关键词）
• 别的数据源

不管来源是什么，对 RAG 链来说，它只想要「给我查询，还我文档」这个接口。Retriever 就是统一这个接口的抽象。

VectorStore 可以变成 Retriever

上一篇提过，VectorStore 有个 as_retriever() 方法，能把自己转成 Retriever。转完之后，它就完全融入 Runnable 体系，能进 LCEL 链：

retriever = vectorstore.as_retriever()
rag_chain = {"context": retriever, "question": ...} | prompt | model

这是个优雅的设计：VectorStore 是「存储+搜索」的实体，Retriever 是「给查询返回文档」的协议。VectorStore 实现了 Retriever 协议，于是存储层和应用层解耦。RAG 链只认 Retriever，不在乎背后是什么。

基础检索的局限

最基础的检索就是「向量相似搜索」：问题转向量，找最近的几块。简单，但有局限：

• 只看语义相似，不看关键词：有时用户用专业术语搜，纯向量可能错过精确匹配
• 返回的块可能冗余：最相似的几块可能内容重复，浪费 prompt 空间
• 不会判断「需不需要检索」：不管什么问题都检索，有时没必要

下面几种进阶策略，就是针对这些局限的。

进阶策略一：混合检索

纯向量检索抓住语义，但可能错过精确的关键词匹配。混合检索把向量检索和关键词检索（如 BM25）结合：两路各找一些，合并去重排序。

适合：专业领域（术语精确匹配重要）、用户经常用特定名词搜索的场景。

进阶策略二：重排序（Reranking）

先用向量检索快速召回一批候选（比如 20 块），再用一个更精细的模型对这批候选重新排序，取最好的几块（比如 5 块）。

为什么要两步？因为向量检索快但粗，精细模型准但慢。两步结合：先粗筛（量大），再精排（量小）。这是工业界常用的「召回-排序」范式。

进阶策略三：上下文压缩

检索回来的文档块，可能只有一部分和问题相关。上下文压缩 retriever 会先检索，再对结果做压缩——只保留和问题相关的片段，去掉无关部分。

好处：塞进 prompt 的更精炼，省 token，模型更聚焦。

进阶策略四：自查询（Self-Query）

用户问题里常含结构化条件，比如「2024 年关于 RAG 的文章」。自查询 retriever 能从问题里同时抽出「语义查询」（关于 RAG）和「过滤条件」（年份=2024），检索时既比语义又按条件过滤。

适合：文档有丰富 metadata（时间、类别、作者等），用户会按这些维度提问的场景。

选择策略的判断

这些策略不是越多越好，要按问题选：

务实做法：从基础向量检索起步，遇到具体问题再加对应策略。不要一开始就上全套，过度设计。

收束：检索质量决定 RAG 上限

这一篇讲了 Retrievers：

• Retriever 是「给查询返回文档」的 Runnable 抽象，统一各种检索来源
• VectorStore 能转成 Retriever，融入 LCEL 链
• 基础向量检索有局限，有几种进阶策略
• 混合检索、重排序、上下文压缩、自查询各有适用
• 从基础起步，按问题加策略，别过度设计

下一篇是 Phase 4 收束——Agentic RAG：把固定 RAG 升级成「Agent 自己决定何时检索、检索什么」。

关于十三Tech

我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。我相信 AI 是程序员的最佳搭档。

如果你想跟完这套「图解 LangChain」，欢迎关注公众号 「十三Tech」。全系列 42 篇，会按认识基础、LangGraph 状态机、Agent 与 middleware、RAG 检索、Tools/MCP/记忆、生产化收束这条线更新。