来源：NVIDIA

是否曾想过，能否在不涉及嵌入模型或向量数据库的复杂性的情况下，利用检索增强生成（RAG）的强大功能？有一种创新的方法可以使用结构化的 CSV 数据来实现 RAG，它由 NVIDIA API 目录中的模型提供支持，并由 PandasAI 进行编排。

在探索GitHub上的NVIDIA仓库时，我偶然发现了一个有趣的东西，名为结构化数据RAG。

[来源：此处]

首先，让我们简要总结一下检索增强生成（RAG）。传统上，大语言模型（LLMs）仅根据其训练数据生成回复。这可能会导致以下问题：

幻觉：生成事实错误或无意义的信息。

过时信息：缺乏训练截止后最新事件或发展的相关知识。

缺乏特定领域知识：无法回答有关专有或小众数据的问题。

检索增强生成（RAG）通过用外部、最新且特定领域的信息扩充大语言模型（LLM）的知识来解决这些局限性。一般的RAG工作流程通常包括：

1. 检索：当用户提出问题时，检索机制（通常使用嵌入和向量数据库）会在庞大的知识库（文档、文章、网页等）中搜索相关信息。

2. 增强：然后将检索到的信息作为额外的上下文与用户的原始查询一起提供给大语言模型。

3. 生成：大语言模型使用这个增强提示来生成更有见地、准确且与上下文相关的响应。

究竟什么是结构化RAG？这是逻辑与氛围之争

让我给你详细地描绘一幅完整的画面。

AI行业喜欢用行话，所以让我们拨开迷雾。普通RAG和结构化RAG之间的区别是哲学上的根本性转变。

普通的检索增强生成（RAG）基于“氛围”（语义相似性）运行。这就像询问一位非常博学、热情的朋友，他快速浏览过关于某个主题的每一本书。它使用向量嵌入来查找在高维空间中具有相似几何位置的文本块。它理解“主旨”，非常适合探索性问题。但它对邻近性的依赖意味着它很容易将细微差别误认为是噪音。

结构化检索增强生成（RAG）基于“逻辑”（符号表示）运行。这就好比让一位法律专家站在图书馆的证人席上，馆内每一本书都经过了精心的交叉引用。这位专家不关心“语义感觉”。他们依据由事实、实体、行为以及它们之间明确关系构建的知识图谱进行操作。它回答问题不是通过查找相近的内容，而是通过基于逻辑查询查找真实的内容。

深度剖析结构化RAG管道

结构化检索增强生成（Structured RAG）的强大能力和精准度并非在查询时才产生，而是在其数据摄取流程的火热锤炼中铸就。这不仅仅是索引的问题，更是精心为你的数据构建第二个结构化“大脑”的过程。以我的经验来看，在这些步骤中任何一个环节偷工减料，都会导致成果沦为仅适合演示的玩具，而非可投入生产的工具。

步骤1：智能解析和布局感知分块

一切都始于原始文档。标准的检索增强生成（RAG）可能只是提取文本，并每512个标记就进行一次分割。这是第一个也是最常见的失败点。一个关键的表格、一项法律条款或一项技术规范可能会被一分为二，从而破坏其含义。

相比之下，结构化检索增强生成（RAG）使用感知布局的解析。它不把PDF看作是文本流，而是看作标题、段落、表格、列表和页脚的集合。因此，分块是语义性的。它沿着这些自然边界分割文本，确保每个分块都是逻辑上完整的单元。这保留了文档的固有层次结构，这对后续步骤至关重要。

步骤2：高保真知识提取

这是整个过程的核心，我们在此将人类语言转化为机器逻辑。对于每个语块，一个复杂的提取过程会识别关键的结构元素。这通常借助强大的大语言模型（如GPT-4），在非常具体的提示引导下完成，或者使用微调模型以提高准确性。目标是提取一组“三元组”（主语-谓语-宾语）。

• 实体（“谁/什么”）：“项目经理”、“规划阶段”、“阿克梅公司”

• 行动/事件（“做了什么”）：“批准”、“审核”、“发起”。

• 属性/特性（“详情”）：“开始日期”、“预算”、“所有者”。

像“项目经理约翰·多伊于10月26日批准了预算”这样的句子会变成一组结构化的事实： {主体: “约翰 ”, 关系: “是一个”, 对象: “项目经理” } {主体: “约翰 ”, 关系: “批准了”, 对象: “预算” } {主体: “预算”, 关系: “有批准日期”, 对象: “2023 10–23” }

步骤3：知识图谱与多索引构建

这些提取的三元组并非仅仅存储在列表中；它们被编织进一个知识图谱（使用像 Neo4j 这样的数据库），或者被组织成关系表（像带有 JSONB 的 PostgreSQL）。这个图谱是系统关于概念如何相互关联的“长期记忆”。

同时，系统会构建一系列高效的倒排索引。如果你曾经使用过教科书后面的索引，就会理解这个概念。你不用在整本书中查找某个术语，而是在索引中查找该术语，它会告诉你确切的页码。这就是倒排索引的作用。

• 实体索引：将John Doe映射到[DocID_12, Chunk_3]

• 操作索引：已批准的地图 → [DocID_12, Chunk_3]

• 主题索引：地图财务>预算编制→ [DocID_12, 块_3]

这种多索引方法能够对结构化数据进行闪电般快速的查找，构成了查询引擎的核心。

查询过程：

当用户最终提出问题时，结构化RAG系统会执行一个多阶段的过程，该过程将精确性置于首位。

1. 查询翻译与结构化自然语言查询首先会被传递给查询翻译器。这个模块通常是经过微调的大语言模型（LLM）或基于规则的解析器，它会将用户的意图解构为正式的结构化查询。

像“给我展示所有由爱丽丝批准的、与Q4计划相关的、Acme公司的合同”这样的问题就变成了一个符号表达式：

{
  "type": "AND",
  "clauses": [
    { "field": "entity", "value": "Alice" },
    { "field": "entity", "value": "Acme Corp" },
    { "field": "action", "value": "approved" },
    { "field": "topic", "value": "Q4 initiative" }
  ]
}

---

2. 多索引符号搜索 然后，使用集合操作在倒排索引上执行此结构化查询。

• 它获取实体等于“Alice”的文档ID集合。

• 它获取实体等于 “Acme Corp” 的 ID 集合。

• 它获取动作等于“已批准”的ID集合。

• 然后，它计算这些集合的交集，仅找出在所有集合中都出现的文档 ID。

这是一种确定性的逻辑操作。其结果是一个规模小但高度相关的候选文档集合，保证包含用户所要求的确切事实组合。

3. 备用机制的作用 但如果查询模糊不清，比如 “我们面临的主要风险是什么？” 该怎么办？结构化搜索可能返回很少或没有结果。这正是成熟的结构化RAG系统展现其智能之处。如果符号搜索的置信度较低，它会回退到传统的密集矢量搜索。它使用嵌入来查找语义相关的片段，作为一种辅助的“尽力而为”方法。这就形成了一个强大的混合体：在可能的情况下，你可以获得符号搜索的精确性，在必要时，又能获得矢量搜索的语义灵活性。

1.1接收传入的对话消息文本、时间戳、发送者 ID、消息 ID1.2将消息存储在持久内存存储中按对话/会话 ID索引以提供历史上下文来自用户（和系统）的每一条消息都不仅仅是临时存储在 RAM 中。它被持久地存储在数据库或内存存储中，以便：系统可以检索并使用过去的上下文，即使是在几天/几周之后。多个会话（对话）可以分开并单独跟踪。2.1提取结构化知识使用：
     └── extractKnowledgeFromText(message.text)

2.2识别：
     ├── 命名实体（人物、地点、组织）
     ├── 动作（动词、事件、意图）
     └── 层次主题（主题、领域）

2.3合并到现有对话知识库中
     └── 使用规范实体匹配或哈希去重

3.1创建语义引用链接：──抽取知识讯息ID+位置

3.2更新主ConversationIndex：
将术语/实体映射到内存中的语义锚


4.1实体索引
──由规范化实体名称索引（例如，"John Doe"→Person）

4.2主题索引
分层映射（例如，“财务>税收>退款”）

4.3行动指数
──捕捉动词、活动和关系（例如，"报税申报"）

4.4附加索引
     ──属性索引（如属性、品质）
──消息文本索引（全文 和语义嵌入）
──相关术语索引（同义词、别名）


5.1接受用户的自然语言查询

5.2翻译查询→结构化搜索查询
──使用：SearchQueryTranslator（例如search. ts：42-55）
──可涉及按实体、主题、动作等进行过滤。

6.1同时查询：
录──实体索引
──话题索引
──行动指数
     └── 其他（属性、文本等）6.2 使用集合 运算合并结果：
     ├── 交集（与）
     ├── 并集（或）
     └── 差集（非）
     └── 参考：conversation.ts:609-643、841-8557.1 如果结构化搜索的置信度较低或结果较少：
     └── 回退到：
         ├── 密集向量RAG搜索
         ├── 全文本相似度（语义）
         └── 基于规则或关键词回退
     └── 参考：searchLang.ts:69-848.1将顶级结果组织到最终上下文窗口中8.2如果总上下文 > 模型令牌限制：通过段落/消息边界126-1378.3并行化块推理（可选）184-2048.4使用“快速停止”启发式方法如果早期块产生足够的答案，停止剩余调用9.1使用选定的块生成自然语言答案9.2附加：    ├── 引用的消息 ID 或 文本片段
 ├── 源元数据（时间戳、发送者）
 └── 置信度 或可追溯性得分

---

4. 可追溯的最终答案生成排名靠前、经过筛选和验证的文本片段会被传递给最终的大语言模型（LLM）。但现在它的任务有了根本性的不同。它不再被要求 “根据自身知识回答”。它被指示：“仅使用提供的文本，综合生成答案，并为每个事实引用来源。”

第一部分：检索流程

第二部分：检索流程

最终输出不仅仅是一个答案；它是一份可验证的报告，通常带有脚注，可追溯到源文档的 ID、页码，甚至文本片段本身。对于任何重视信任和可审计性的企业来说，这种可追溯性是至关重要的特性。

为什么不是每个人都在使用结构化RAG？

如果它如此强大，为什么它不是默认选项呢？坦率地说，是因为它很难。实际情况是，结构化检索增强生成（Structured RAG）伴随着重大的权衡，你必须了解这些。

前期成本高：预处理和摄取管道在计算上成本高昂且复杂。设计提取模式和构建知识图谱需要大量的领域专业知识和工程努力。

模式刚性：你受限于你决定提取的内容。如果你没有为因果关系创建“关系”，你就无法提出因果问题。系统的智能程度仅取决于你为其设计的本体论。适应新领域或新类型的查询可能需要重新设计模式。

细微差别丢失：将文本抽象为结构化三元组时，有时会丢失字里行间的微妙叙事语境、讽刺意味或隐含意义。这是在模糊性和精确性之间的权衡。

最终裁决

普通检索增强生成（RAG）和结构化检索增强生成（RAG）之间的选择，并非是在真空中比较哪一个更好；而是要使工具与任务的风险相匹配。

随着我们这个行业的成熟，我们必须超越构建令人印象深刻的演示，开始设计可靠的系统。普通的检索增强生成（RAG）是点燃这场革命的耀眼火花。但结构化检索增强生成（Structured RAG）提供了构建未来值得信赖、具备工业强度的AI所需的严谨工程框架。