Structured RAG：解决传统 RAG 的准确性盲区 - 文章 - 开发者社区

picture.image

想深入研究技术细节? 论文链接：https://arxiv.org/abs/2511.08505v1

核心要点

传统 RAG 的坑 ：处理复杂的企业问题时经常掉链子,给出的答案要么不完整,要么根本不靠谱
结构化 RAG(S-RAG)：把乱七八糟的文档变成结构化、能查询的数据,让推理过程更精准、更透明
混合玩法 ：把结构化检索和嵌入检索结合起来用,准确率直接飙升 60%,召回率几乎满分
企业场景专用 ：可以自动识别数据结构,也能让用户自己定义,轻松搞定几百万文档,全程透明可控
最终效果 ：在合规、报告和关键业务流程中,给出靠谱又能说清楚的答案

RAG 的美好愿景 vs 残酷现实

这些年,很多团队都想用 RAG 技术来榨干数据的价值。但现实总是很打脸——系统生成的答案听起来头头是道,但靠不靠谱就是另一回事了。

比如说,你问个关于业绩趋势或供应商对比的问题,基于 LLM 的系统可能只给你讲一半故事。它可能找到几段看起来相关的内容,但把关键数据给漏了,或者干脆把一堆半吊子相关的信息拼凑在一起,压根没答到点子上。在金融和合规这种领域,这可不是小毛病,而是实打实的风险。

RAG 技术本身没啥大问题,只是需要升级一下才能达到企业级的标准。这就是结构化 RAG(S-RAG)的由来——一种增强版方案,给检索过程加入结构和推理能力,从而提供精准、可追溯的答案。

传统 RAG 的套路是先检索文本片段,然后让 LLM 在有限的上下文里硬想答案。S-RAG 完全换了个思路:它在离线阶段就从非结构化文档里把信息提取出来,塞进关系数据库。运行的时候,直接用 SQL 查询来检索和推理这些结构化数据。这意味着那些需要聚合、对比或筛选的分析问题——也就是企业天天遇到的问题——终于能被准确、透明地解决了。

真实案例 :当被问到一个简单的财务问题时(这种问题大多数 RAG 系统都答不好),用了 S-RAG 的系统能直接从结构化数据里拿到精确值,而不是靠文本相似度在那儿"蒙"答案。

picture.image

结构化 RAG 示例

底层原理:

  
SELECT   
    "current\_liabilities" / 1000000 AS current\_liabilities\_millions  
FROM   
    "SEC\_Report"  
WHERE   
    LOWER("company\_name") = 'netflix'   
    AND "fiscal\_year" = 2017

为啥嵌入式 RAG 不够用

嵌入式 RAG 是第一代知识代理的基石,在检索增强生成的进化史上确实很重要。它的做法是把问题和文档都转成高维向量,试图找到语义上"靠近"的文本片段,然后丢给 LLM 去推理。

但对企业来说,这种方法在三种关键场景下就不太行了。

1. 聚合类问题

金融和合规领域的客户经常碰到看似简单的分析查询:

"去年所有子公司里,最高资本支出是多少?"
"按准时交付率排名,前五的供应商是谁?"
"安全事故在各季度的趋势咋样?"

这些可不是"大海捞针"式的问题(答案藏在几段文字里就完事)。要正确回答这类分析问题,系统得在可能几十上百条记录里筛选、对比、汇总。

嵌入式 RAG 没有靠谱的办法来干这些活儿。它只是检索固定数量的文本片段,扔给 LLM,然后让 LLM 在有限的上下文窗口里硬算——而 LLM 的数学能力本来就很弱。

2. 需要全覆盖的问题

企业团队经常会问需要完整清单的问题:

"列出所有 2025 年前到期、违约金超过100万元的合同。"
"哪些员工的资质证书今年要过期?"
"哪些市场的监管变化会影响报告要求?"

漏掉任何一项都不只是不方便,而是合规风险。但嵌入式检索本质上是概率性的,它优化的目标是找最匹配的那几个片段,而不是所有相关证据。因为它只根据相似度分数拿文档子集,所以永远没法保证完全覆盖。在金融报告或监管合规这种场景,这是没法接受的——全面覆盖和准确性一样关键。

3. 信息密集或特征不明显的语料库

再看技术文档或监管文件这类语料库。它们信息密集、重复性高、以属性为主。文档之间可能就差几个数字或条款,而查询可能聚焦在条款编号或型号 ID 这种精确属性上。这种情况下,嵌入相似度就抓瞎了。检索结果会很乱,因为嵌入模型没学到这些术语背后的真正含义,所以那些看起来"接近"但实际不相关的段落经常会把真正的答案给挤掉。

比如在财务分析查询里,大多数报告看起来差不多,都包含类似的术语——"总负债"、"股东权益"、"净利润"。对嵌入模型来说,它们都显得很相关。结果就是,语义检索经常返回一堆看起来上下文接近、但实际答非所问的不相关文档。

这时候结构化 RAG 就该上场了。

用结构化方法给 RAG 加 buff

结构化 RAG 通过拓展 RAG 系统在企业环境中能准确处理的问题范围,解决了这些痛点。

它不再把文档当成纯粹的非结构化文本,而是在导入阶段就利用结构化信息来弥补嵌入式检索的短板。系统会分析文档,找出反复出现的模式。比如:

在财务报表里 ,每份报告都包含收入、运营费用、资本支出这些属性
在人力资源简历里 ,每条记录都有教育背景、工作年限、证书
在合同里 ,条款遵循标准章节,比如终止、违约金、适用法律

但因为文档是各自编写的,同一个值可能以多种格式出现——比如"1,000,000"、"1M"或者干脆就是"1"。没有标准化,跨文档推理基本不可能。

系统会自动推断出一个能抓住这些属性的模式。通过结构化 RAG,每个文档都被转成符合这个模式的结构化记录,格式、术语、验证全都保持一致。用户可以在导入前查看、编辑、调整自动生成的模式,来满足特定需求。整个语料库变成了一个结构化数据库,同时保留指向原始文本的链接,保证透明性和可控性。

在推理阶段,当用户提出跟某个可用模式相关的问题时,系统会把自然语言问题转成针对这个结构化数据库的正式 SQL 查询。

picture.image

结构化 RAG 工作流程

这样就能执行传统 RAG 搞不定的精确分析操作——算最大/最小值、分析趋势、复杂筛选——同时还能追根溯源。

"各子公司里最高的 ARR 是多少?"
"显示历年平均员工数增长情况。"
"2020 年后签的哪些合同包含仲裁条款?"

执行完 SQL 查询后,系统把结果返回给 LLM,生成流畅、业务友好的答案。

性能表现与混合检索

这种方法在聚合查询上的准确率比嵌入式系统高出 60%,在全覆盖问题上召回率接近满分(前提是有合适的模式)。

picture.image

聚合评估集上的答案对比

对比了嵌入式 RAG(用 gpt-o3 做生成模型)、OpenAI Responses API 和结构化 RAG 在聚合问题基准测试上的表现。

picture.image

聚合评估集上的答案召回率

但不是所有信息都能完美地塞进模式。有些属性很少见,或者问题可能需要对叙事性文本进行推理。这种情况下,系统会先用结构化 RAG 把数据集范围缩小,然后在这个缩小的集合上用嵌入式检索。

这种混合检索方式在全面覆盖和灵活性之间找到了平衡点,确保不会漏掉相关信息,同时还能支持细致的、文本密集型问题。它还通过先查询精确属性来规避密集语料库的失败模式。

如下图所示,混合方法在真实世界基准测试中明显吊打纯嵌入 RAG 和竞品的 RAG 系统。

picture.image

Maestro 混合 RAG 对比

在 FinanceBench(一个大型金融分析师风格的基准测试)上,对比了 Maestro 混合 RAG、经典嵌入式 RAG 和 OpenAI Responses API。

从答案到决策

对企业老板们来说,这意味着啥一目了然:

答案靠得住 :结构化推理提供的结果在高风险场景下准确、可追溯、站得住脚。动态混合架构把结构化检索和嵌入式检索结合起来,取长补短,在改进结果的同时保留经典流程作为保底方案
放心扩展 :系统能搞定几百万文档、信息密集的技术语料库和不断变化的监管要求。S-RAG 能适应具体查询——根据查询上下文自动推断模式,或者让用户自己定义模式来获得完全控制

因为结构化 RAG 在动态混合流程里运作,得到的每个答案都比已经信任的基准 RAG 结果更准。

通过解决嵌入式方法的盲区,这套系统把非结构化的企业数据变成了结构化的决策引擎。对企业来说,这意味着能拿来就用的答案、能自动化的工作流程,还有能降下来的风险。

picture.image

添加微信，备注” LLM “进入大模型技术交流群

picture.image

如果你觉得这篇文章对你有帮助，别忘了点个赞、送个喜欢

/ 作者：致Great

/ 作者：欢迎转载，标注来源即可