type
status
date
slug
summary
tags
category
icon
password
复杂且知识密集的大语言模型（LLM）应用通常需要在运行时检索数据，以实现检索增强生成（RAG）。RAG典型架构的核心组件是向量存储，它用于支持文档检索。
使用向量存储需要设置一个索引管道，从来源（例如网站、文件等）加载数据，将数据转化为文档，嵌入这些文档，并将嵌入和文档插入向量存储中。
如果数据源或处理步骤发生变化，就需要重新索引数据。如果这种情况经常发生，而且更改是增量的，那么避免将重复内容写入向量存储是很有价值的。这可以节省时间和成本。同时，还需要设置向量存储清理流程，以移除过时数据。
LangChain 索引 API
新的 LangChain 索引 API 使从任何来源加载和同步文档到向量存储变得简单。它特别能帮助：
- 避免将重复内容写入向量存储
- 避免重写未更改的内容
- 避免对未更改内容重新计算嵌入
关键是，即使文档经过多次转换步骤（例如通过文本分块），索引 API 仍能正常工作。
工作原理
LangChain 索引使用记录管理器（RecordManager）来跟踪文档写入向量存储的情况。
在索引内容时，会为每个文档计算哈希值，并将以下信息存储在记录管理器中：
- 文档哈希（页面内容和元数据的哈希）
- 写入时间
- 来源ID——每个文档应该在其元数据中包含信息，以确定文档的最终来源
清理模式
在将文档重新索引到向量存储中时，可能需要删除一些现有文档。如果您对文档处理方式进行了更改，或者源文档发生了变化，您需要删除来自相同来源的所有现有文档，并用重新索引的文档替换它们。
索引 API 清理模式让您可以选择所需的行为：
有关 API 和其限制的详细文档，请参阅文档：https://python.langchain.com/docs/modules/data_connection/indexing
实际操作
首先，我们初始化向量存储。我们将使用
ElasticsearchStore 进行演示，因为它满足支持插入和删除的先决条件。有关向量存储要求的更多信息，请参阅Requirements文档部分。现在我们初始化并为记录管理器创建一个模式，我们将使用 SQLite 表：
假设我们想索引 reuters.com 的首页。我们可以加载并拆分 URL 内容：
现在我们可以开始索引了！假设我们首次索引首页的前 10 个文档：
如果我们一个小时后再次索引，可能有两个文档发生了变化：
从输出中可以看出，虽然索引了 10 个文档，但实际的工作量是 2 次新增和 2 次删除——我们添加了新文档，删除了旧文档，并跳过了所有重复文档。
ChatLangChain + 索引 API
我们最近重新设计了 ChatLangChain 聊天机器人，用于回答有关 LangChain 的问题。作为重新设计的一部分，我们恢复了托管版本 https://chat.langchain.com 并设置了使用新 API 的每日索引作业，以确保聊天机器人能及时了解最新的 LangChain 发展。
这非常简单——我们只需：
- 设置一个 Supabase Postgres 数据库作为记录管理器，
- 更新摄取脚本以使用索引 API，而不是直接将文档插入向量存储，
- 设置一个计划的 GitHub Action，每天运行摄取脚本。您可以在这里查看 GHA 工作流。
结论
当您将应用程序从原型转移到生产环境时，能够高效地重新索引并保持向量存储中的文档与其来源同步变得非常重要。LangChain 的新索引 API 提供了一种清晰且可扩展的方式来实现这一点。