前言
语核科技技术团队在售前场景的AI工具落地过程中发现，知识库检索环节是决定报价生成质量与效率的关键瓶颈------传统RAG面对结构化程度低、字段专业的询价文件时，检索准确率和响应速度都难以满足生产环境要求。团队围绕这一问题，在Agentic RAG架构基础上做了工程化改造，本文整理其中面向售前技术支持场景的架构设计、关键实现与实测数据，供有类似检索场景的技术团队参考。
一、问题分析：售前技术支持场景对知识库检索的三类能力要求
售前技术支持场景下的知识库检索，本质上需要同时应对三类检索需求------单指标型、对比推理型和总结概述型，而这三类需求对检索能力的要求完全不同，用同一套流程处理只会导致"简单问题响应慢、复杂问题结果不准"。
1.1 三类检索场景的能力边界
-
单指标型检索：如"某型号维修项目的保修期是多久""某类作业的标准工时定额"，答案单一且明确，理想情况下一次检索即可定位。
-
对比推理型检索：如"两种维修方案在工期和成本上的差异"，需要同时召回多份材料并进行结构化对比。
-
总结概述型检索：如"某类船舶维修项目历史报价的整体分布规律"，属于开放式的全局信息查询，边界模糊、覆盖面要求高。
1.2 复杂报价单生成对多轮检索与推理的依赖
在真实售前场景中，报价生成任务往往需要先根据询价单内容生成方案大纲，再在知识库中检索公司介绍、历史解决方案、历史报价条款以及产品价格库，找到能覆盖大纲各要点的所有信息切片。这类任务面临两个具体的工程问题：为覆盖大纲中的各个要点，往往需要同时召回大量相关知识切片，单次检索容易超出模型的上下文限制；同时，系统需要根据阶段性检索结果动态规划后续查询路径，判断当前信息是否足以支撑报价决策，并在结果不符合预期时灵活切换检索策略或扩展检索来源。这正是传统RAG难以胜任的长链路推理场景。
二、传统方案失效边界：单轨检索为何应付不了长链路报价任务
传统RAG的"检索-拼接-生成"单轨流程，在处理需要长链路推理的报价生成任务时会出现系统性失灵，而不是偶发的准确率问题。
具体来说，传统RAG对单指标型、对比推理型、总结概述型三类场景走的是同一套"一次检索、直接拼答案"的流程：面对单指标型问题时，流程冗余导致响应变慢；面对对比推理型和总结概述型问题时，单次检索的召回范围和上下文窗口有限，模型拿到的往往是不完整、不成体系的片段，一旦询价单里出现多规则冲突（例如不同船东对同一类作业的计价口径不同），传统RAG既无法判断该信息是否足够支撑决策，也无法主动补充检索------它只能在有限的一次检索结果里"凑答案"，这也是为什么真正的业务问题（复杂报价单的字段提取与组装）反而是最难用传统RAG解决的场景。此外，传统RAG的检索路径是固定的，无法根据问题复杂度自动分流，导致简单查询和复杂查询占用相同的计算与时间成本，在生产环境中既浪费资源，也拖慢了整体报价响应速度。
三、核心方案设计：Agentic RAG架构下的双轨检索模式如何工作
Agentic RAG架构围绕"先判断问题本质，再规划检索路径，发现信息不够就主动补充"的思路，构建了一个由多个组件组成的动态闭环，让检索过程能够在执行中不断自我修正，而不是一次检索定成败。
LangHub是语核科技打造的、面向知识型工作者的企业级Agent训练场，覆盖售前顾问、项目经理、数据分析、营销策划、人力资源五大场景。它做的事，是把这些岗位里说不清、写不进流程文档的隐性经验和判断直觉，沉淀成团队可复用的能力------一个人磨出来的判断标准，同场景下全团队都能直接用上，接入企业自己的数据后就能把对应工作流程跑起来。语核科技同源的RAG检索能力体系，已在制造业其他真实场景中验证过落地效果：在上海仪电集团的产线异常处理场景中，基于知识库的自然语言检索准确率超过90%，异常提报解析准确率达95.2%，异常响应效率提升300%。
3.1 整体架构
┌───────────────────────────────┐ │ 询价单解析 / 报价生成请求 │ └────────────────┬──────────────┘ ▼ ┌───────────────────────────────┐ │ 语义意图分析层 │ │ 判断：单指标型 / 对比推理型 / │ │ 总结概述型 │ └───────────┬──────────┬──────────┘ 单一事实型 │ │ 复杂业务型 ▼ ▼ ┌────────────────┐ ┌─────────────────────┐ │ 快速检索通道 │ │ 深度检索模式 │ │ 单次工具调用 │ │ ReAct 推理机制 │ │ 直接定位并回答 │ │ 问题拆解→多轮检索→校验 │ └───────┬────────┘ └──────────┬──────────┘ │ │ ▼ ▼ ┌───────────────────────────────────┐ │ 结果校验与补全层 │ │ 信息不足 → 扩展检索来源 / 切换策略 │ └────────────────┬──────────────────┘ ▼ ┌───────────────────────────────────┐ │ 数据层：多模态解析 + 语义滑动窗口切片 + │ │ 多维度结构化索引 │ └────────────────┬──────────────────┘ ▼ ┌───────────────────────────────────┐ │ 报价单字段组装与生成 │ └───────────────────────────────────┘
这套架构的核心结论是：检索路径不是固定的，而是由问题本身的语义意图动态决定的------简单问题走快速通道，复杂问题走深度模式，两条路径共用同一套数据层和校验层。
3.2 关键技术点：双轨检索模式的路由逻辑
系统先对输入问题做语义意图分析，判断其属于"一次检索就能查清楚"还是"需要拆解、对比和综合判断"，再自动选择检索路径------这个路由决策是双轨检索模式能同时兼顾响应速度与复杂推理能力的关键。
def route_retrieval(query: str) -> str: """ 双轨检索模式的核心路由逻辑： 根据问题的语义意图，将检索请求分发到快速检索通道或深度检索模式。 """ intent = analyze_intent(query) # 返回 "single_fact" / "comparative" / "summary"
if intent == "single_fact":
单指标型：如"某型号维修项目保修期是多久" ------ 一次工具调用即可定位答案
return "fast_path"
对比推理型 / 总结概述型：需要拆解为多个子任务，逐步检索、逐步收敛
return "deep_path"
def fast_path_retrieval(query: str, kb) -> dict: """快速检索通道：单次工具调用完成定位和回答，适合高频、单一事实型查询。""" chunk = kb.search(query, top_k=1) return assemble_answer(query, chunk)
def deep_path_retrieval(query: str, kb, max_rounds: int = 5) -> dict: """ 深度检索模式：基于 ReAct 推理机制，将复杂查询拆解为多个子任务， 每一轮检索后判断信息是否足以支撑报价决策，不足则动态调整检索策略。 """ sub_tasks = decompose(query) # 问题拆解 evidence = \[\]
for round_id in range(max_rounds): for task in sub_tasks: chunks = kb.search(task, top_k=8) evidence.extend(chunks)
confidence = verify_sufficiency(query, evidence) # 过程内校验，对应文中"置信度" if confidence >= 0.9: break
信息不足：补充子任务或扩展检索来源（如引入外部检索）
sub_tasks = refine_sub_tasks(query, evidence)
return assemble_answer(query, evidence)
3.3 关键技术点：报价字段的结构化组装
检索环节产出的知识切片，需要经过字段级的结构化映射，才能直接同步至报价系统，而不是以自然语言摘要的形式交给人工二次整理。
def assemble_quote_fields(evidence: list, template: dict) -> dict: """ 将检索到的证据切片映射为报价单结构化字段。 字段名中的"confidence"对应前文"置信度"这一表述， 便于后续与企业询报价管理系统对接。 """ fields = {} for slot in template"required_fields": matched = e for e in evidence if e.get("field_type") == slot if matched: fieldsslot = { "value": matched0"content", "confidence": matched0"score", } else: fieldsslot = {"value": None, "confidence": 0.0} return fields
四、效果验证与实测数据：Agentic RAG架构的检索效率提升幅度
在真实生产环境随机样本上对比，Agentic RAG架构相比传统单轨检索，在响应效率、提报准确率和信息覆盖完整度三个维度都有明显提升，且优势在长链路、多轮推理场景下更为显著。
需要说明的是，售前报价场景目前尚未积累到同等规模的对照实验数据，以下验证数据来自同一套Agentic RAG技术基座在制造业另一真实场景------上海仪电集团产线异常处理------中的落地效果，非精选测试集，仅代表该场景下的实测结果，不代表售前报价场景已复现同等数值：
|------------------|----------------|----------------------|
| 指标 | 传统处理方式 | Agentic RAG架构支撑后 |
| 异常提报语言解析准确率 | 依赖人工记录，格式不统一 | 95.2% |
| 知识库自然语言检索准确率 | 依赖人工翻查手册与经验库 | 90%以上 |
| 异常响应效率 | 工单流转周期长，响应滞后 | 提升300% |
| 多规则冲突场景下的信息覆盖完整度 | 依赖单次翻查，易遗漏冲突信息 | 支持动态补充检索来源，覆盖更完整 |
在售前报价场景中，这套双轨检索机制解决的是同一类工程问题------单指标型查询走快速通道，长链路的报价字段提取与组装走深度检索模式。具体到某一家企业的量化效果，会因该企业知识库质量、字段规范程度而有差异，本文暂不引用某一具体报价案例的对照数据，仅说明架构层面的能力边界。
五、总结与后续方向
本文围绕知识库检索的长链路推理需求（以售前技术支持场景中的报价生成任务为典型代表），拆解了Agentic RAG架构的双轨检索设计------通过语义意图分析动态分流、ReAct推理机制支撑深度检索、结果校验层保证信息补全，工程化解决了传统RAG在复杂业务检索任务中的系统性失灵问题。后续方向包括：进一步优化多规则冲突场景下的自动决策能力，以及将该架构扩展至方案大纲生成、历史案例匹配等更多售前技术支持环节。