企业级 RAG 的七个短板与工程解法

腾讯云 ADP 团队｜2026年9月30日

传统 RAG 的五个短板——单跳检索、切片碎片化、结构化数据无力、时效性缺失、被动检索——上一篇已经逐一盘点。这篇看工业界怎么把它们补齐，以腾讯云智能体开发平台（ADP）在复杂业务场景中的工程落地实践为样本。

先说结论：企业级 RAG 的演进方向，是从「先检索后生成」的直线流水线，变成「边检索、边判断、边决策」的 Agentic 数据服务。检索不再是流程里一次性执行的前置步骤，而是过程中可以按需调用的动作。

从直线流水线到 Agentic 数据服务

在实际工程落地中，RAG 主流程呈现出三个关键特征：

意图先行，检索反哺意图。 先做多意图识别，并行检索知识库、工作流、数据库等多种来源；更关键的一步是，把第一轮粗查拿到的内容再作为意图判断的输入——先粗查一轮拿到线索，再据此校正意图，让「这个问题到底要查什么」判断得更准。

多路并行的混合检索。 向量、关键词、结构化（Text2SQL）、图（GraphRAG）多路并行，复杂场景下效果和速度都更优。

策略灵活，可插拔可降级。 不同场景按需选择参数、模型和检索路数；资源紧张或某一路失效时可平滑降级，而不是整体失败。

下面按能力模块逐个展开。

1. 文档解析：三层架构加动态路由

第一篇讲过，大部分效果问题出在解析层。ADP 在复杂图文表混排场景下，结合自研多模态文档解析能力与语义切分机制，有效缓解了传统规则切分的碎片化、上下文割裂等痛点。

在系统架构上，文档解析抽象为清晰的层次化服务：

任务路由层：统一管理文档解析与拆分请求，提供标准化接入与全链路状态追踪；
任务调度与能力层：基于动态路由机制，先自动研判输入页面的复杂度。简单页面走工程规则与传统 OCR 快车道（保障毫秒级响应与超低成本），复杂图文混排、含表格公式页面走多模态大模型链路（保高精度与版面结构还原）。

一句话：工程链路保速度，模型链路保精度，动态路由决定谁上。

导入后可以通过解析切分干预查看原文与切片，调整影响回答的切分结果。

2. Text2SQL：补「结构化数据无力」的短板

面对 Excel 和数据库，纯向量检索做不了精确的条件筛选与聚合。这在真实业务里非常致命：数据库动辄海量数据且动态更新，不可能全量文本化入库；「哪些产品销售额最高」「某区域有多少家网点」这类带比较、聚合、多表关联的查询，传统向量检索只能给出残缺答案。

早期工程落地的典型挑战包括：英文表头与自然语言提问难以对齐、多表场景下语义互相干扰导致选错表、复杂子句转换困难、表格合并单元格导致结构识别失真。

针对这些问题，工程上采取了一套组合拳：

Schema Linking + Value Linking：结构召回补上表结构语义，值召回把用户问的关键词直接还原为库内真实值；配合语义检索解决多语言与同义词映射，再用 RRF 综合排序，实现语义与精准匹配互补。
人工干预 + 宽表剪切：支持自定义库表和字段注释，覆盖业务先验信息；通过剪掉无关列减少语义噪声干扰。
执行层双引擎：SQL 语句精准但容错率低，检索引擎兜底但分词易泛化——通过 SQL 工程矫正执行加检索引擎兜底，兼顾精准与泛化。
枚举释义 + 结构化表头改写：把业务枚举代码转换为清晰释义，增强模型理解；把双表头、首行说明等非规整表头重构为标准结构化表格，大幅拓宽 Text2SQL 的适用边界。

在包含多表关联与复杂条件的内部测试集上，这套组合拳使结构化数据检索的可用率取得显著突破，大幅提升了复杂问答下的召回率与准确度。

3. 接入外部数据库：不搬数据，只学结构

文档和问答对本质是相对静态的数据，无法满足交易流水、订单库存等持续变化的动态场景。而千万级业务数据如果全量复制入库，成本与同步时延也完全无法承受。

务实的解法是「不搬数据、只学结构 + 实时查询」：

采样学习：对数据进行采样学习并建立轻量索引（数值列做条件匹配、非数值列提取高频特征向量化），有效压缩索引体积；
实时读取 + 刷新学习：不搬迁真实业务数据，检索生成的 SQL 直接下推到客户数据库执行，并持续刷新对表结构特征的学习，兼顾实时性与数据新鲜度；
协议丰富 + 抽象接口：支持 MySQL、SQL Server、PostgreSQL、Oracle 等主流数据库协议，通过标准化抽象接口让不同环境以极小改动快速扩展。

这套设计的关键取舍是：知识库里沉淀的是「数据的结构描述」而非业务数据本身，真正的数据访问发生在外部数据库内，做到业务数据不落地。接入类型、数据表描述与学习配置可查看数据库接入指南。

这类动态数据需求也出现在钢贸行业方案中：商品匹配与报价需要结合企业商品库、业务规则和行业资源价格，采购则需要将多格式报价整理为可比较的数据。

4. GraphRAG：补「单跳、跨文档」的短板

基于知识图谱的检索增强生成，把文档抽取为「实体—关系」图结构，显式建模跨文档的语义关联，弥补纯文本检索在多跳推理上的短板。

面对复杂关系链路（例如跨系统的故障联动排查），答案往往分散在多个不相邻的文档中。引入 GraphRAG 的核心工程考量包括：

带 Schema 约束的图构建：引入预设 Schema 约束大模型三元组（实体、属性、关系）的抽取过程，有效抑制无监督自动抽取的噪声。
向量定位 + 图扩展：先用向量检索快速命中关键起点实体，再沿关系图向外做多跳扩展，相比全局图遍历效率大幅提升。
剪枝与复杂度控制：多跳遍历后候选规模呈指数级膨胀，工程做法是通过限制图扩展深度和候选规模，并结合语义检索与重排机制控制计算复杂度；同时根据具体业务场景在探索深度与延迟之间做平衡。
融入混合检索大盘：GraphRAG 并非孤立系统，而是作为混合检索的补充分支，图检索结果去重后与其他路召回统一走综合重排，平滑降级。

此外，在建图流程上从早期的「边抽边写」演进为「抽取后全局整治」——合并同义实体与同义关系、统一对齐属性，使图谱更加纯净规范。

在跨文档多跳关联评测中，相较于单一向量检索，引入 GraphRAG 后多跳推理问答的准确率获得实质性改善，有效连接了原本割裂的信息孤岛。

5. Agentic RAG：检索成为 Agent 的工具

把检索从固定流水线的一次性前置步骤，转变为智能体自主调用的工具，形成动态闭环：

规划 → 调用检索工具 → 评估证据 → 信息不足则改写 Query / 换数据源再检索 → 证据充足再综合回答

工具箱覆盖标准检索、文档切片与父切片溯源、结构化 SQL 执行、图谱关系遍历等多类独立工具。智能体可根据当前问题复杂度自主决策调用链路。在涉及多步对比、合同审查、复杂故障诊断等跨文档推理场景中，端到端问答准确率与证据溯源完整度获得大幅改善。

具体的工具添加、反思模型与检索范围配置，可查看Agentic RAG 功能指南。

6. 元数据检索：提高目标知识的召回权重

把编码、型号、批号这类强约束信息从正文中抽取为结构化元数据并建立独立索引，实现两阶段分层检索：先用元数据精准锁定文档，再回到全文获取细节切片。

典型场景是大规模、强约束的企业级知识库。例如在某大型企业服务知识库中，文档规模达数十万级，用户查询常包含明确的产品型号代码、故障警报代号、物料编码或生产批号。

传统向量检索在处理离散标识符时语义区分度极低，容易出现召回漂移；纯全文检索中编码又易被高频词掩盖。两阶段增强管线先通过 Query 提取强约束字段命中目标文档，再在限定范围内做混合检索，有助于减少相近编号干扰，并保留局部语义的完整性。

对编码、型号等查询，可以通过元数据设置提高相关知识的召回权重；需要严格限定候选范围时，应同时配置标签过滤。

7. 时效性检索：让检索看懂时间

在传统检索中，一条去年的旧政策和今年刚发布的修订版在库内共存时，向量相似度常常无法正确感知新旧，甚至导致旧版本优先召回。

时效性检索通过工程化链路让系统读懂时间意图：

查询预处理：自动识别用户提问中的时间限制；
时间窗口路由：结合文档的生效与失效时间字段做条件过滤；
时间衰减重排：在后处理阶段对时效性高的文档引入时间衰减加权，使最新权威内容在排序中占据优势。

在包含明确时间维度的法规、政策与动态信息问答中，该机制可减少新旧文档冲突造成的回答倒挂。操作可查看时效性检索设置：明确时间范围用于过滤，“最新”等意图主要用于加权排序。

8. 细分场景的持续突破

在高水准基线之上，真实业务的持续优化更多来自对工程细节的精细打磨：

子问题拆分：多实体、复合型问题自动拆解为主子问题并发检索，避免局部信息遗漏。
自定义切分与人工干预：在某物流服务知识库中，针对活体动植物寄递细则等分散且长尾的内容，默认切片常导致上下文碎片化，通过规则干预将关联条款收拢到一个语义完整的切片，使复杂业务细则能够被准确回答。
问答对双向匹配：在「问题—问题」匹配基础上增加答案向量化索引，针对答案反向提问的匹配准确率大幅提升，几乎消除了过去命中在答案侧却无法召回的盲区。
模型生态灵活升级：持续升级内置 Embedding 与 Reranker 模型，增强中英混搜、小语种和垂直领域效果，同时全面支持接入外部专属模型。