我用内核验证了 AI Agent 沙箱的真实隔离边界

RAG Pipeline 优化技术

以下是常用的 RAG Pipeline 优化技术：

Query Transformation and Expansion（查询转换与扩展）

Multi-Vector Retrieval（多向量检索）

这些技术用于提升 LLM 生成答案的质量。

今天我们聚焦于 Parent Retrieval（父级检索）。

什么是 Chunk

A chunk 是文档或段落的一小部分，通常由 500–1000 个词组成。当这些 chunks 被转换为嵌入向量并存储到向量数据库中时，语义相关的 chunks 会在向量空间中彼此靠近。

当用户提交查询时，系统会检索与查询最接近的 chunks。然而，并非所有检索到的 chunks 都是最相关的。有时我们可能会遗漏其他能为用户查询提供更好上下文的 chunks。

假设我们有如下段落：

每一行存储为一个独立的 chunk：

每一行也存储为独立的 chunks：

假设用户查询的期望答案是 P1C2。

向量数据库检索结果为：

尽管 P1C2 被正确检索到了，但相关的 chunks P1C1、P1C3 和 P1C4 可能比 P2C3 提供更好的上下文。由于这些 chunks 没有被检索到，我们可能会丢失能够提升最终 LLM 回答质量的重要上下文。

如果我们将文档按段落存储而不是使用更小的 chunks，可能会检索到不必要的上下文，从而增加 token 消耗。

解决方案 —— Parent Retrieval

假设段落 1 被分成四个 chunks：

每当从向量数据库检索到特定 chunk 时，该 chunk 的元数据中还包含对其父段落的引用。

例如，如果检索到 P1C2，元数据中也包含对段落 1 的引用。

利用这个引用，检索器还可以获取同一父段落下的其余 chunks：

这样可以确保不会遗漏与用户查询密切相关的重要上下文。

假设用户查询是：

"Create a dictionary"

检索到的 chunks 为：

Parent Retrieval 不会只将这些 chunks 发送给 LLM，而是将同一父段落的其余 chunks 也包含进来：

提供这些额外的上下文使 LLM 能够生成更准确的回答。

何时使用 Parent Retrieval？

当我们感觉检索到的 chunks 缺少重要上下文，并且希望加入与查询密切相关的额外上下文时，Parent Retrieval 非常有用。

父段落与其他 chunks 的存储方式相同。然而，它不直接用于向量搜索。相反，它的引用存储在每个 chunk 的元数据中，允许检索器在需要时获取父级上下文。