前言语核科技技术团队在售前场景的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 / summaryif intent single_fact:单指标型如某型号维修项目保修期是多久 —— 一次工具调用即可定位答案return fast_path对比推理型 / 总结概述型需要拆解为多个子任务逐步检索、逐步收敛return deep_pathdef fast_path_retrieval(query: str, kb) - dict: 快速检索通道单次工具调用完成定位和回答适合高频、单一事实型查询。 chunk kb.search(query, top_k1) 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_k8) 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: fields[slot] { value: matched[0][content], confidence: matched[0][score], } else: fields[slot] {value: None, confidence: 0.0} return fields四、效果验证与实测数据Agentic RAG架构的检索效率提升幅度在真实生产环境随机样本上对比Agentic RAG架构相比传统单轨检索在响应效率、提报准确率和信息覆盖完整度三个维度都有明显提升且优势在长链路、多轮推理场景下更为显著。需要说明的是售前报价场景目前尚未积累到同等规模的对照实验数据以下验证数据来自同一套Agentic RAG技术基座在制造业另一真实场景——上海仪电集团产线异常处理——中的落地效果非精选测试集仅代表该场景下的实测结果不代表售前报价场景已复现同等数值指标传统处理方式Agentic RAG架构支撑后异常提报语言解析准确率依赖人工记录格式不统一95.2%知识库自然语言检索准确率依赖人工翻查手册与经验库90%以上异常响应效率工单流转周期长响应滞后提升300%多规则冲突场景下的信息覆盖完整度依赖单次翻查易遗漏冲突信息支持动态补充检索来源覆盖更完整在售前报价场景中这套双轨检索机制解决的是同一类工程问题——单指标型查询走快速通道长链路的报价字段提取与组装走深度检索模式。具体到某一家企业的量化效果会因该企业知识库质量、字段规范程度而有差异本文暂不引用某一具体报价案例的对照数据仅说明架构层面的能力边界。五、总结与后续方向本文围绕知识库检索的长链路推理需求以售前技术支持场景中的报价生成任务为典型代表拆解了Agentic RAG架构的双轨检索设计——通过语义意图分析动态分流、ReAct推理机制支撑深度检索、结果校验层保证信息补全工程化解决了传统RAG在复杂业务检索任务中的系统性失灵问题。后续方向包括进一步优化多规则冲突场景下的自动决策能力以及将该架构扩展至方案大纲生成、历史案例匹配等更多售前技术支持环节。
前言语核科技技术团队在售前场景的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 / summaryif intent single_fact:单指标型如某型号维修项目保修期是多久 —— 一次工具调用即可定位答案return fast_path对比推理型 / 总结概述型需要拆解为多个子任务逐步检索、逐步收敛return deep_pathdef fast_path_retrieval(query: str, kb) - dict: 快速检索通道单次工具调用完成定位和回答适合高频、单一事实型查询。 chunk kb.search(query, top_k1) 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_k8) 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: fields[slot] { value: matched[0][content], confidence: matched[0][score], } else: fields[slot] {value: None, confidence: 0.0} return fields四、效果验证与实测数据Agentic RAG架构的检索效率提升幅度在真实生产环境随机样本上对比Agentic RAG架构相比传统单轨检索在响应效率、提报准确率和信息覆盖完整度三个维度都有明显提升且优势在长链路、多轮推理场景下更为显著。需要说明的是售前报价场景目前尚未积累到同等规模的对照实验数据以下验证数据来自同一套Agentic RAG技术基座在制造业另一真实场景——上海仪电集团产线异常处理——中的落地效果非精选测试集仅代表该场景下的实测结果不代表售前报价场景已复现同等数值指标传统处理方式Agentic RAG架构支撑后异常提报语言解析准确率依赖人工记录格式不统一95.2%知识库自然语言检索准确率依赖人工翻查手册与经验库90%以上异常响应效率工单流转周期长响应滞后提升300%多规则冲突场景下的信息覆盖完整度依赖单次翻查易遗漏冲突信息支持动态补充检索来源覆盖更完整在售前报价场景中这套双轨检索机制解决的是同一类工程问题——单指标型查询走快速通道长链路的报价字段提取与组装走深度检索模式。具体到某一家企业的量化效果会因该企业知识库质量、字段规范程度而有差异本文暂不引用某一具体报价案例的对照数据仅说明架构层面的能力边界。五、总结与后续方向本文围绕知识库检索的长链路推理需求以售前技术支持场景中的报价生成任务为典型代表拆解了Agentic RAG架构的双轨检索设计——通过语义意图分析动态分流、ReAct推理机制支撑深度检索、结果校验层保证信息补全工程化解决了传统RAG在复杂业务检索任务中的系统性失灵问题。后续方向包括进一步优化多规则冲突场景下的自动决策能力以及将该架构扩展至方案大纲生成、历史案例匹配等更多售前技术支持环节。
