news 2026/5/23 1:34:42

从“能查到”到“查得准”:Agentic RAG 在 B2B 复杂业务场景的工程实践

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
从“能查到”到“查得准”:Agentic RAG 在 B2B 复杂业务场景的工程实践

前言

我们是语核科技的技术团队,专注于 B2B 售前场景的 AI 工程化落地。在构建售前数字员工产品的过程中,我们遇到了一个在企业 RAG 落地中极为普遍的问题:基础 RAG 流程的检索准确率在实验室环境下看似不错,但一旦进入真实业务场景——面对几百页的投标文件、跨文档的技术参数对比、长链路的方案生成任务——准确率就开始显著下降。

本文分享我们在解决这一问题过程中的工程思路:为什么传统 RAG 在复杂业务场景下表现不佳,以及我们如何通过引入 Agentic RAG 架构、双轨检索模式和数据层优化,将售前数字员工的业务检索能力提升到可量化、可落地的水平。


一、传统 RAG 的工程局限

问题的本质:企业知识不是标准 QA 库

很多 RAG 实现方案在设计时隐含了一个假设:知识库是结构良好的,问题和答案有较清晰的对应关系。但企业私有知识库的实际情况与此相差甚远:

  • 体量大:一个中型制造企业的技术知识库可能包含数千份 PDF、Word 文档、Excel 表格
  • 结构复杂:同一个技术参数可能散落在 3 份文档的不同版本中,且表述不一致
  • 检索类型多样:业务人员的提问既有单值型(“这个设备的额定功率是多少”),也有对比型(“A 型号和 B 型号的功耗差异”),还有总结型(“生成这个客户的完整解决方案”)

传统 RAG 对这三类检索走同一套流程,结果是:

简单问题:向量召回 top-k → 拼接上下文 → 生成答案 复杂问题:向量召回 top-k → 拼接上下文 → 生成答案(同上)

对于单值型检索,这套流程基本够用。但对于对比推理型和总结概述型检索,单次向量召回的 top-k 往往无法覆盖所有需要参考的文档片段,导致生成结果不完整、甚至存在事实错误。

售前场景的典型挑战

以我们的核心业务场景——售前方案生成为例,任务链路如下:

客户需求输入 ↓ 理解需求意图,生成方案大纲(含 5-10 个核心要点) ↓ 对每个要点,在知识库中检索:公司介绍 / 历史解决方案 / 相关客户案例 / 产品规格数据 ↓ 综合检索结果,生成结构化方案文档

这个任务对 RAG 系统提出了两个传统架构无法满足的需求:

  1. 上下文容量问题:为覆盖方案大纲的全部要点,需要同时引入大量相关片段,极易超出模型的 context window
  2. 动态路径规划:数字员工需要根据阶段性检索结果,判断当前信息是否足以支撑某个要点的内容生成,并在信息不足时自主决定补充检索,而不是等所有检索完成后再生成

二、Agentic RAG:让检索具备"推理过程"

核心思路

我们引入了 Agentic RAG 架构,核心改变是:将检索从"一次性执行"变为"迭代式推理"。

传统 RAG: query → 向量检索 → 召回 top-k → LLM 生成 Agentic RAG: query → 意图分析 → 任务规划 → [检索 → 评估 → 是否需要补充检索] × N → 汇总生成

具体实现上,我们构建了一个由五个智能组件组成的动态检索闭环,依次承担意图分析、子任务规划、多策略检索执行、信息完整性评估和最终生成五个职责:

┌─────────────────────────────────────────────────┐ │ Agentic RAG 核心 │ │ │ │ ① 意图与复杂度判断 │ │ ↓ │ │ ② 子任务拆解与检索路径规划 │ │ ↓ │ │ ③ 多策略检索执行 │ │ ↓ │ │ ④ 信息完整性评估 │ │ ↓ 若信息不足,回到 ③ │ │ ⑤ 基于完整上下文生成 │ └─────────────────────────────────────────────────┘

信息完整性评估是这套架构的关键环节。它负责在每轮检索后评估当前已召回的内容是否足以支撑任务目标,主要判断:

  • 关键实体(如特定型号、技术参数、客户名称)是否已被覆盖
  • 存在冲突的信息片段是否已通过多源验证得到解决
  • 尚未找到答案的子任务是否需要切换检索策略(如扩大范围、使用不同关键词)

这种"边查边想、按需补充"的机制,使得系统在处理复杂推理型检索时,不再是被动地拼接信息,而是能逐步收敛到可用于业务决策的结论。

ReAct 推理机制的应用

在深度检索模式下,我们采用了 ReAct(Reasoning + Acting)推理机制来驱动多轮检索。每一步遵循"先推理、再行动"的节奏:

[当前已有信息] + [任务目标] ↓ Reasoning:判断下一步应该做什么 ├── 信息不足 → Acting:发起新一轮检索(可选 semantic / keyword / hybrid 策略) ├── 信息存在冲突 → Acting:对冲突片段进行多源验证 └── 信息已充分 → 结束循环,进入生成阶段 ↓ 将检索结果追加到上下文,进入下一轮 Reasoning

这个循环最多执行 N 轮(根据任务复杂度配置上限),每轮结束后由信息完整性评估模块判断是否继续。对于简单事实查询,通常 1-2 轮即可收敛;对于复杂的方案生成任务,可能需要多轮才能覆盖所有要点。

核心价值在于:检索不再是一次性的静态操作,而是随着信息积累不断自我修正的动态过程。这使得系统在面对信息分散、结构复杂的企业知识库时,能逐步收敛到完整、可靠的结论。


三、双轨检索模式:效率与深度的平衡

为什么不把所有问题都走 Agentic 路径

Agentic RAG 的推理和多轮检索会带来额外的延迟(典型值:深度检索比单次检索多 1.5-3 秒)和 token 消耗。对于高频的简单查询,这个开销是不必要的。

我们设计了双轨检索模式:

用户问题输入 ↓ 意图复杂度分类器 ├── 简单型(single-hop)→ 快速检索通道(目标:< 1s 响应) │ ↓ │ 一次向量检索 → 召回 top-3 → 直接生成 │ └── 复杂型(multi-hop / reasoning)→ 深度检索通道 ↓ Agentic RAG(ReAct + Evidence Evaluator)

复杂度分类方面,我们使用了一个轻量分类模型(基于规则 + 小模型打分),核心特征包括:

  • 问题中是否包含对比词(“区别”“优劣”“相比”)
  • 问题是否涉及多个实体的关联(“A 客户 + B 产品”)
  • 问题是否要求生成性输出(“帮我写”“生成”“拟定”)
  • 问题中是否有时间序列约束(“最新的”“历史上”)

快速检索通道响应速度显著优于深度检索通道,适合高频、低复杂度的日常查询场景,在保持秒级响应的同时降低整体计算成本。

深度检索通道的完成时间随任务复杂度变化,方案生成类任务耗时相对较长,但输出结果可靠性更高,适合对准确性要求严格的关键业务场景。

实际场景中,绝大多数业务问题属于单跳型查询,只有少量复杂推理任务需要走深度通道。这种分流机制使系统在整体响应效率和准确性之间取得平衡。


四、数据层:准确率的真正地基

工程层的优化能解决"查的方式"的问题,但如果输入的数据质量本身有问题,检索精度的上限也会受到限制。我们在数据层做了三方面的专项优化。

4.1 多模态文档解析

企业文档往往不是纯文本,而是包含大量表格、图片、混合排版内容。传统 OCR 在处理复杂表格(如合并单元格、嵌套表头、图文混排)时准确率有明显下降。

我们基于多模态模型构建了专用解析管线,核心能力:

  • 复杂表格还原:识别合并单元格,正确重建行列关系(而非将表格展平为线性文本)
  • 图文关联:识别图片与其相邻文字标注的语义关联,将图表内容与正文上下文绑定
  • 版式感知:识别标题层级(H1/H2/H3),在切片时保留文档的逻辑结构

当前我们的多模态文档解析在标准企业文档集合上的整体字段准确率达到 99%+(包含纯文本、简单表格、复杂表格三类文档)。

4.2 语义感知的切片策略

文档解析完成后,如何切片直接影响召回质量。固定长度切片(如每 512 token 一段)会导致语义完整的段落被截断,检索时召回的片段缺乏完整上下文。

我们采用了基于语义的滑动窗口切片,核心思路是:以语义完整的边界(段落边界、列表项边界、标题边界)作为切分点,而非按固定 token 数硬截断。同时在相邻切片之间保留一定重叠,避免跨切片的上下文信息在检索时割裂。

具体流程:

文档全文 ↓ 按语义边界拆分为基本单元(句子 / 段落 / 列表项) ↓ 滑动累积:将单元逐步并入当前切片 ├── 当前切片未超过 max_size → 继续并入 └── 即将超过 max_size → 在当前语义边界处切断,保留末尾若干单元作为 overlap ↓ 输出切片列表(每个切片语义完整,相邻切片有适度重叠)

关键点在于切分位置的选择:优先在段落结束处、列表完整结束处切分,保证每个切片在语义上是自完备的,检索时召回的片段不会因为被截断而缺失关键信息。

4.3 结构化元数据索引

仅靠向量相似度检索,对于一些精确匹配场景(如"型号 XR-2200 的额定电压是多少")效果不如关键词检索。我们为每个切片自动生成多维度元数据标签,支持向量检索与关键词检索的混合策略。标签体系示例(以制造业技术文档为例):

切片元数据结构: ├── document_type 文档类型(技术规格书 / 历史方案 / 客户案例 / 产品目录) ├── extracted_entities 提取的关键实体(型号名称、技术参数类型、客户行业) ├── date 文档时间(用于时效性排序) ├── section_path 文档章节路径(如"3.2 > 电气参数") └── confidence 解析置信度(低置信度切片在召回排序中降权)

在实际检索时,系统根据查询意图动态选择策略:

  • 含精确型号 / 参数名的查询 → 优先走元数据过滤 + 关键词召回
  • 语义理解类查询 → 优先走向量召回
  • 复杂查询 → 混合召回后通过 reranker 精排

五、实测效果

在真实业务环境中,优化后的系统在复杂业务检索场景的准确率和响应完整度均有显著提升,具体体现在:

  • 单值型查询:准确率基础已经较高,优化后进一步收敛,误召回和漏召回明显减少
  • 对比推理型查询:传统 RAG 最薄弱的场景,Agentic 架构通过多轮检索和信息整合,显著改善了答案的完整性和逻辑一致性
  • 方案生成任务:要点覆盖率和内容结构完整性提升明显,减少了"检索到部分信息但漏掉关键要点"的情况

以售前报价场景为例,某装备制造企业客户使用优化后的售前数字员工,完整报价文档的生成时间从人工的平均4 天缩短至20 分钟,报价内容的准确率(经人工复核)达到92%,剩余 8% 为需要销售经理判断的非标场景。


六、总结与展望

回顾整个优化路径,可以提炼出几个对企业 RAG 落地有参考价值的工程原则:

  1. 先诊断瓶颈,再选方案:准确率问题可能来自解析层、切片层、检索层或生成层,不同环节的问题需要不同的优化手段,盲目升级大模型不能解决检索问题
  2. Agentic 化是方向,但要控制成本:双轨模式比全量 Agentic 更适合生产场景,对高频简单查询保持低延迟,对复杂任务投入深度推理
  3. 数据质量是上限:再精妙的检索架构,也无法从低质量的切片中召回高质量信息;文档解析和切片策略值得投入专项优化
  4. 以业务指标驱动技术选型:技术选型的标准应该是"业务问题是否被解决",而非"技术方案是否足够复杂"

后续我们计划探索的方向:针对垂直岗位场景的检索路径预训练(基于岗位 SOP 生成定制化检索策略),以及多 Agent 协作场景下的知识路由机制。


关于语核科技
语核科技成立于 2023 年 5 月,作为国内领先的 B2B AI Native 公司,始终致力于为个人与组织提供AI劳动力,创造增量生产力、释放人类潜能,帮助企业快速训练能够真正上岗工作的AI数字员工,为企业直接交付业务结果。
截至2025年公司已完成数千万融资,营收突破千万,助力上海仪电集团、中远海运集团、唯捷创芯等龙头企业实现业务突破,并先后获央视等多家官媒与专业科技媒体深度报道,荣获几十项各类荣誉,实现行业硬实力与市场影响力持续领跑。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/5/23 1:34:38

二叉树的遍历算法

二叉树的遍历算法 一、算法原理 二叉树遍历是指按照特定的顺序访问树中所有节点的过程&#xff0c;主要分为深度优先遍历&#xff08;DFS&#xff09;和广度优先遍历&#xff08;BFS&#xff09;。深度优先遍历包括前序遍历、中序遍历和后序遍历&#xff0c;广度优先遍历即层次…

作者头像 李华
网站建设 2026/5/23 1:34:39

2026最新版默纳克电梯年检试验方法及原理(精准版)

本标准依据TSG T7007-2016《电梯型式试验规则》、TSG T7001—2023《电梯监督检验和定期检验规则》,结合默纳克NICE3000new/NICE5/7000系统最新硬件配置(MCTC-SCB-D全面替代SCB-C)、参数规范及2026年最新检验实操要求制定,涵盖UCMP功能、抱闸制动力监测、门锁短接检测、门旁…

作者头像 李华
网站建设 2026/5/23 1:34:42

如何选择轻量级轮播插件实现响应式设计?前端开发必备解决方案

如何选择轻量级轮播插件实现响应式设计&#xff1f;前端开发必备解决方案 【免费下载链接】slick the last carousel youll ever need 项目地址: https://gitcode.com/GitHub_Trending/sl/slick 在现代前端开发中&#xff0c;轮播组件作为展示图片、产品或内容的核心交互…

作者头像 李华
网站建设 2026/5/23 1:34:46

Spring AI 实战进阶:Ollama+Spring AI 构建离线大模型应用全指南

前言 随着大模型技术的普及&#xff0c;企业对数据安全、隐私合规的要求越来越高&#xff0c;离线部署大模型成为 Java 后端开发者的核心需求。Spring AI 作为 Spring 生态的 AI 集成框架&#xff0c;搭配 Ollama 本地大模型运行工具&#xff0c;可快速构建完全离线、数据不出…

作者头像 李华
网站建设 2026/5/23 1:35:10

为什么 ABAP 开发团队现在要认真看待 AI 这项能力

对于很多做 ABAP 开发的人来说,AI 工具早就不再是一个遥远的概念。真正有价值的,不是把一个通用聊天机器人塞进开发流程,而是让 AI 深度嵌入已经熟悉的开发环境、对象模型和企业语境里。SAP Joule for developers, ABAP AI capabilities 的价值正落在这里:它不是一个游离于…

作者头像 李华
网站建设 2026/5/23 1:34:51

【办公类-142-04】20260330插班生word转长表EXCLE(4)新表重制

背景需求&#xff1a; 4月份转了两位插班生进来 之前做了一份word内容提取到excel的代码 【办公类-142-03】20260304插班生word转长表EXCLE&#xff08;3&#xff09;从word表格按行导出列表&#xff0c;提取索引内容。写入EXCLE长表&#xff0c;另存有名字的文件名https://m…

作者头像 李华