使用 PageIndex 改进 RAG 系统
Source: Dev.to
请提供您希望翻译的具体文本内容，我将为您翻译成简体中文并保留原始的格式、Markdown 语法以及技术术语。谢谢！
传统 RAG 的隐藏问题
大多数 RAG 流程遵循类似的工作步骤：
- 将文档拆分为块。
- 将每个块转换为嵌入向量（embeddings）。
- 将嵌入向量存入向量数据库（vector database）。
- 查询时，系统检索最相似的块。
- 将这些块作为上下文传递给 LLM。
这种方法在初期效果良好，但存在结构性弱点：块会失去与原始文档的关联。当系统检索上下文时，可能会从文档的完全不同位置抽取片段，导致信息碎片化。
示例：
一篇研究论文的组织结构可能是：
- 第 1 页 — 引言
- 第 2 页 — 系统架构
- 第 3 页 — 实现细节
- 第 4 页 — 结果
一次典型的 RAG 查询可能会检索到第 1 页的一个块、第 4 页的另一个块，以及第 2 页的第三个块，导致模型只能得到零散的片段，且可能遗漏与检索块位于同一页的上下文信息。
什么是 PageIndex RAG？
PageIndex RAG 是一种简单的改进，在检索过程中保留文档结构。它不再把每个块视为孤立的信息，而是附加元数据记录每个块所属的页面（或章节）。当检索到相关块时，系统会通过加入同一页面的其他块来扩展上下文，使 LLM 能看到原本一起编写的周围信息。
核心思路
- 检索最相关的块。
- 确定其所在页面。
- 将该页面的其他块添加到上下文中。
为什么页面结构很重要
文档是有意结构化的；作者会将相关信息放在同一页面或章节，通常跨越多个段落。忽视这种结构会打断信息的逻辑流。PageIndex 通过提供连贯的上下文块来恢复这种流，保留原始组织方式，这可以显著提升答案质量。
PageIndex 如何提升检索
PageIndex 在检索与生成之间增加了一个额外步骤：
- 向量检索 – 获取最相关的片段。
- 页面识别 – 确定这些片段所属的页面。
- 上下文扩展 – 收集同一页面的相邻片段。
- 有序组装 – 将合并后的片段按原文档顺序排列。
发送给 LLM 的最终上下文包括：
- 触发的相关片段。
- 同一页面的相邻片段。
- 内容按源文档的顺序排列。
真正的好处：更好的上下文重建
大型语言模型在能够看到连贯结构的信息时表现最佳。仅提供一半的解释可能导致幻觉，而包含周围段落则让模型能够对完整解释进行推理，显著减少不完整答案和幻觉。
当 PageIndex 最佳使用时
PageIndex 对于结构组织严密的文档尤其有用，例如：
- 研究论文
- PDF 文件
- 技术文档
- 法律文件
- 报告
- 教科书
在这些情况下，相关信息通常聚集在同一页或章节内，保持这种分组对于准确理解非常有价值。
PageIndex vs. Larger Context Windows
Increasing the context window size does not solve retrieval quality. If the system retrieves the wrong chunks, a larger window simply adds more irrelevant information. PageIndex improves the quality of the retrieved context, not just the quantity, which is crucial for real‑world applications.
PageIndex 与 更大的上下文窗口
增大上下文窗口的大小并 不 能解决检索质量问题。如果系统检索到了错误的片段，更大的窗口只会增加更多无关信息。PageIndex 提升了检索上下文的 质量，而不仅仅是数量，这对真实世界的应用至关重要。
为什么这种技术被低估了
许多 RAG 讨论集中在：
- 更好的嵌入
- 混合搜索
- 重新排序模型
- 向量数据库调优
虽然这些改进很重要，但它们常常忽视了一个更简单的因素：文档结构。PageIndex 将检索与人类组织信息的方式对齐，以最小的额外复杂度利用结构信号。
最终思考
RAG 管道常被视为纯粹的语义检索系统，但文档中蕴含的结构信号可以显著提升性能。PageIndex 是一种轻量级技术，能够恢复部分丢失的结构。通过将块重新连接到它们原始的页面，你可以让 LLM 在完整的信息片段上进行推理，而不是在碎片化的摘录上进行推理。有时，最大的改进来自最简单的想法，而 PageIndex 正是一个典型的例子。