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