检索 - LangChain 博客

TL;DR: 我们正在调整我们的抽象概念，以便除了 LangChain 的 VectorDB 对象之外的其他检索方法也能在 LangChain 中轻松使用。这样做是为了实现以下目标：(1) 允许在其他地方构建的检索器在 LangChain 中更易于使用，(2) 鼓励更多地试验替代检索方法（如混合搜索）。这与之前的版本向后兼容，因此所有现有的链应继续像以前一样工作。但是，我们建议尽快从 VectorDB 链更新到新的 Retrieval 链，因为这些链将在未来获得最全面的支持。

Python 文档

JS 文档

介绍

自从 ChatGPT 问世以来，人们一直在为他们的数据构建个性化的 ChatGPT。我们甚至写了一篇关于此的教程，然后在几个月前举办了一场关于此的竞赛。对此的渴望和需求突显了 ChatGPT 的一个重要局限性——它不了解您的数据，如果了解，大多数人会觉得它更有用。那么，如何构建一个了解您数据的聊天机器人呢？

实现此目的的主要方法是通过一个通常被称为“检索增强生成”的过程。在此过程中，系统不是直接将用户问题传递给语言模型，而是“检索”任何可能与回答问题相关的文档，然后将这些文档（连同原始问题）传递给语言模型以进行“生成”步骤。

大多数人（包括 LangChain 的我们）进行检索的主要方式是使用语义搜索。在此过程中，为所有文档计算一个数值向量（嵌入），然后将这些向量存储在向量数据库中（一个针对存储和查询向量优化的数据库）。然后也将传入的查询向量化，检索到的文档是那些在嵌入空间中最接近查询的文档。我们不会在此处深入探讨太多细节——但此处有一篇关于该主题的更深入的教程，下面是一个很好地总结了这一点的图表。

问题

这个过程效果很好，我们构建的许多组件和抽象概念（嵌入、向量存储）都是为了促进这个过程。

但我们注意到了两个问题。

第一： 在执行此检索步骤的方式上有很多不同的变化。人们希望做超出语义搜索的事情。具体来说

我们支持两种不同的查询方法：一种仅优化相似度，另一种优化最大边际相关性。
用户通常希望在执行语义搜索之前指定元数据过滤器来过滤结果
其他类型的索引，如图，引起了用户的兴趣

第二： 我们还意识到，人们可能会在 LangChain 之外构建检索器——例如 OpenAI 发布了他们的 ChatGPT Retrieval Plugin。我们希望尽可能方便人们在 LangChain 中使用他们创建的任何检索器。

我们意识到我们犯了一个错误——通过将我们的抽象概念集中在 VectorDBQA 上，我们限制了链的使用，使得 (1) 想要尝试其他检索方法的用户，(2) 在 LangChain 生态系统之外创建检索器的用户难以使用它们。

解决方案

那么我们是如何解决这个问题的呢？

在我们最新的 Python 和 TypeScript 版本中，我们

引入了 Retriever 的概念。检索器应公开一个 get_relevant_documents 方法，其签名如下：def get_relevant_documents(self, query: str) -> List[Document]。这是我们对检索器做出的唯一假设。请参阅下文了解有关此接口的更多信息。
更改了我们所有使用 VectorDB 的链，现在都使用检索器。 VectorDBQA 现在是 RetrievalQA，ChatVectorDBChain 现在是 ConversationalRetrievalChain 等。 请注意，展望未来，我们有意使用 Conversational 前缀来表示链正在使用内存，并使用 Chat 前缀来表示链正在使用聊天模型。
添加了第一个非 LangChain 检索器实例——ChatGPT Retrieval Plugin。这是 OpenAI 昨天开源的一个模块，旨在帮助公司公开检索端点以连接到 ChatGPT。注意：在所有意图和目的上，ChatGPT Retrieval Plugin 的内部工作原理与我们的 VectorStore 非常相似，但我们仍然非常高兴将其集成，以此来突出显示存在的新灵活性。

扩展 Retriever 接口

我们特意只要求一个方法 (get_relevant_documents)，以便尽可能地具有包容性。我们（尚未）对这些检索器的构建方式提出任何统一的要求。
我们特意强制 query: str 作为唯一参数。对于所有其他参数（包括元数据过滤），这应存储为检索器本身的参数。这是因为我们预计检索器经常嵌套在链内部使用，并且我们不希望围绕其他参数进行管道。

完成这一切的最终目标是使（LangChain VectorStore 之外的）替代检索器更容易在链和代理中使用，并鼓励替代检索方法的创新。