检索器
概览
存在多种不同类型的检索系统,包括向量存储库、图数据库和关系型数据库。 随着大型语言模型的普及,检索系统已成为 AI 应用(例如 RAG)的重要组成部分。 鉴于其重要性和多样性,LangChain 为与不同类型的检索系统进行交互提供了一个统一的接口。 LangChain 的 retriever 接口非常直观:
- 输入:查询(字符串)
- 输出:文档列表(标准化的 LangChain Document 对象)
关键概念

所有检索器都实现了一个简单的接口,用于使用自然语言查询检索文档。
接口
检索器的唯一要求是能够接受一个查询并返回文档。
特别是,LangChain 的检索器类仅要求实现 _get_relevant_documents 方法,该方法接收一个 query: str 并返回与查询最相关的 Document 对象列表。
用于获取相关文档的底层逻辑由检索器指定,可以是任何对应用程序最有用的内容。
LangChain 检索器是一个可运行对象,它是 LangChain 组件的标准接口。
这意味着它具有一些通用方法,包括invoke,用于与其交互。检索器可以通过查询进行调用:
docs = retriever.invoke(query)
Retrievers 返回一个 文档 对象列表,这些对象具有两个属性:
page_content: 本文档的内容。当前为字符串。metadata: 与此文档关联的任意元数据(例如,文档 ID、文件名、来源等)。
- 查看我们关于构建您自己的自定义检索器的操操作指南。
常见类型
尽管检索器接口具有灵活性,但几种常见的检索系统类型经常被使用。
搜索 apis
重要的是要注意,检索器实际上并不需要存储文档。 例如,我们可以基于搜索 API 构建检索器,它们只需返回搜索结果即可! 请参阅我们与Amazon Kendra或Wikipedia 搜索的检索器集成。
关系型或图数据库
检索器可以构建在关系型或图数据库之上。 在这些情况下,查询分析技术对于从自然语言构建结构化查询至关重要。 例如,您可以使用文本到SQL转换为SQL数据库构建检索器。这允许将自然语言查询(字符串)检索器在后台转换为SQL查询。
词法搜索
正如我们在对检索的概念性回顾中所讨论的那样,许多搜索引擎都是基于将查询中的单词与每个文档中的单词进行匹配。 BM25和TF-IDF是两种流行的词汇搜索算法。 LangChain为许多流行的词汇搜索算法/引擎提供了检索器。
- 查看 BM25 检索器集成。
- 查看 TF-IDF 检索器集成。
- 查看 Elasticsearch 检索器集成。
向量存储
向量存储 是一种强大且高效的方法,用于索引和检索非结构化数据。
调用 as_retriever() 方法可以将向量存储用作检索器。
vectorstore = MyVectorStore()
retriever = vectorstore.as_retriever()
高级检索模式
集成
由于检索器接口非常简单,给定搜索查询后返回一个包含Document个对象的列表,因此可以使用集成(ensembling)方法组合多个检索器。
当您拥有多个擅长查找不同类型相关文档的检索器时,这种方法特别有用。
创建集成检索器以结合多个检索器并使用线性加权分数非常简单:
# Initialize the ensemble retriever
ensemble_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, vector_store_retriever], weights=[0.5, 0.5]
)
在集成检索时,我们如何整合来自多个检索器的搜索结果? 这引出了重排序(re-ranking)的概念,它利用更复杂的算法(如倒数等级融合 (RRF))将多个检索器的输出进行整合。
源文档保留
许多检索器利用某种索引使文档易于搜索。 索引过程可能包括一个转换步骤(例如,向量存储通常使用文档分割)。 无论使用何种转换,保留已转换文档与原始文档之间的链接都非常有用,这使得检索器能够返回原始文档。

这在 AI 应用中特别有用,因为它确保了模型不会丢失文档上下文。 例如,您可能使用较小的分块大小对向量存储中的文档进行索引。 如果您仅返回只作为检索结果的分块,那么模型将丢失这些分块的原始文档上下文。
LangChain 拥有两种不同的检索器可用于解决这一挑战。 多向量检索器允许用户在使用任何文档转换(例如,使用 LLM 生成文档摘要)进行索引的同时,保留与源文档的链接。 父文档检索器在将来自文本分割器转换的文档块用于索引的同时,保留与源文档的链接。
| 名称 | 索引类型 | 使用大型语言模型 | 何时使用 | 描述 |
|---|---|---|---|---|
| ParentDocument | Vector store + Document Store | No | If your pages have lots of smaller pieces of distinct information that are best indexed by themselves, but best retrieved all together. | This involves indexing multiple chunks for each document. Then you find the chunks that are most similar in embedding space, but you retrieve the whole parent document and return that (rather than individual chunks). |
| Multi Vector | Vector store + Document Store | Sometimes during indexing | If you are able to extract information from documents that you think is more relevant to index than the text itself. | This involves creating multiple vectors for each document. Each vector could be created in a myriad of ways - examples include summaries of the text and hypothetical questions. |