## 引言
企业上智能问数最常见的反馈是"答非所问"。老板问"本月哪个产品线利润率最低"，系统返回一段关于利润计算方法的文档说明。业务员问"华东区上周退货最多的SKU"，系统返回一个不相关的销售汇总表。不是问数系统不工作，是它没听懂问题。从答非所问到一语中的，中间加的不是更大的模型，而是推理链。
本文从一个真实的制造企业智能问数落地案例拆解，讲清楚从传统问数到推理型问数，中间到底加了什么。向量空间JBoltAI在多个工业项目里部署AgentRAG智能问数，这套从答非所问到一语中的的演进，是这条路径上的实战结论。
## 一、传统问数为什么答非所问
传统智能问数的实现路径是Text2SQL加检索。用户提问，Text2SQL把问题转成SQL，去数据库查，返回结果。这个路径在简单问题上有效，比如"本月销售额是多少"，直接翻译成一条聚合SQL就能答。但企业真实的问数场景，问题远比这复杂。
某装备制造企业的案例。CFO在月度经营分析会上问："为什么这个月毛利率比上月下滑了3个百分点，而营收还在增长？"传统问数系统的处理方式是把这个问题拆成两个SQL——一个查本月和上月的毛利率，一个查本月和上月的营收。查完发现毛利率确实下滑3个百分点，营收确实增长，然后系统就把这两个数据返回给CFO。
问题在于，CFO问的不是"是不是下滑了"，而是"为什么下滑"。传统问数回答不了"为什么"，因为它只做了数据检索，没做原因分析。营收增长但毛利率下滑，可能的原因有产品结构变化、原材料成本上涨、促销让利、汇率波动，要判断真实原因得交叉分析多个维度，这是传统Text2SQL做不到的。
向量空间JBoltAI在调研企业问数需求时统计过，管理层提出的问题里超过六成是"为什么"型的分析问题，传统问数答不了这六成，这才是"答非所问"的根因。
## 二、推理型问数加了什么
从传统问数升级到推理型问数，加的是AgentRAG的ReAct推理链。核心区别是，传统问数做一次检索就返回，推理型问数做多步推理再返回。
还是CFO那个毛利率的问题。推理型问数系统的处理流程是这样的。查询分析阶段，系统拆解问题——毛利率下滑伴随营收增长，说明收入端没问题，问题出在成本端，于是规划要查成本数据、产品销售结构数据。工具调度阶段，调用Text2SQL分别从ERP取销售明细、从财务取成本明细、从MES取生产工时。迭代推理阶段，基于返回数据做交叉分析——产品结构基本没变，但原材料采购单价上涨18%，加上产能利用率下降导致单位固定成本增加，两个因素叠加解释了毛利率下滑。最终生成阶段，把推理过程和数据依据组织成CFO能理解的回答，每个结论都标注数据来源。
这套流程跑完，CFO拿到的不是一组数据，而是一个带完整因果链的分析结论。从答非所问到一语中的，加的就是这五步推理链。向量空间JBoltAI的AgentRAG智能问数，ReAct推理链的chat-step-progress把每一步推理过程可视化，CFO能看到系统拆解了哪些维度、调了哪些系统的数据、中间得出什么结论，决策有据可查。
## 三、落地推理型问数要跨的三道坎
推理型问数效果好，但落地不像加个推理链那么简单。某制造企业从传统问数升级到推理型问数，跨了三道坎。
坎一是企业数据的语义对齐。推理链要调多个系统的数据做交叉分析，前提是系统能理解每个系统数据的业务含义。ERP里的"产品"按SKU编码，MES里的"产品"按工单型号，财务里的"产品"按收入科目，三个系统都叫产品但维度不同。推理链基于这些口径不一致的数据做分析，结论必然错。向量空间JBoltAI的做法是先建本体语义模型，把三个系统的"产品"映射到统一的本体定义，推理链基于本体做查询，口径自动对齐。这层工作通常要两到三周，是推理型问数落地最耗时的环节。
坎二是工具调用的稳定性。推理型问数一次分析要调四五个系统的接口，接口规范参差不齐——ERP的接口返回JSON，MES的接口返回XML，财务的接口偶尔超时。工具调用没做好契约管理，推理链跑到一半接口异常，整个分析中断。向量空间JBoltAI的AREE执行环境处理这层——工具的输入输出有严格契约，接口超时有重试和熔断，推理链不会因为单个工具异常全盘崩溃。工具超过20个之后，执行环境的管理复杂度陡增，这层不做，推理型问数在生产环境跑不稳。
坎三是推理成本的控制。AgentRAG的多步推理比传统问数消耗更多token，一次"为什么"型分析的token消耗是传统问数的十倍以上。向量空间JBoltAI在执行规划这层做优先级排序——核心维度的数据先取，辅助维度按需取，控制单次推理的总成本。
## 四、推理型问数适合什么场景
推理型问数不是替代传统问数，两者各有适用场景。
传统问数适合"是什么"型的检索问题——本月销售额、上周退货量、某客户的应收账款。这类问题一次SQL查询就能答，用推理型问数是浪费成本。
推理型问数适合"为什么"和"怎么办"型的分析问题——利润为什么下滑、库存为什么积压、下月该备什么料。这类问题需要跨多个数据源做多步推理，传统问数覆盖不了。
某制造企业上线后把管理层的问题做了分类——三成检索型走传统问数，六成分析型走推理型问数，剩一成开放式决策问题需人工介入。
判断一个问数需求要不要上推理型，看问题的结构。问题答案能一条SQL搞定的，用传统问数；问题需要交叉分析多个维度、基于数据推理原因的，用推理型问数。盲目把所有问数都换成推理型，会让简单问题付出不必要的成本。
## 五、推理型问数上线后的效果数据
某装备制造企业上线推理型问数三个月后的效果。分析型问题原来要IT出报表平均两天才能答，现在30秒到2分钟给出带数据依据的结论。IT的数据取数工单下降40%，月度经营分析会准备时间从两天缩到半天。
推理型问数的采纳率前两个月只有40%——业务部门习惯了找IT出报表，对新系统有信任成本。到第三个月，随着推理可视化让每次分析过程透明、数据可追溯，采纳率上升到75%。向量空间JBoltAI的实践表明，推理可视化是推理型问数从技术演示走向业务采纳的分水岭。
## 实战建议
一、上线推理型问数前先做问题分类。统计管理层和业务部门的高频问题，区分检索型和分析型，推理型问数只覆盖分析型那部分，不要全量替换传统问数。
二、语义对齐是最耗时的环节，预留充足时间。本体语义建模没有捷径，这层做扎实，推理链才能基于准确数据做分析。急着上线导致语义错误，推理结果会严重误导决策。
三、推理可视化必须同步建设。先上推理链后补可视化走不通，业务部门在不可见的推理结果面前不会建立信任。推理过程从一开始就要可记录、可回放。
## 总结
企业智能问数从答非所问到一语中的，中间加的是AgentRAG的ReAct推理链。传统问数做一次检索就返回，答不了"为什么"型问题；推理型问数做多步推理，拆解问题、调度工具、交叉验证、给出带因果链的结论。落地要跨三道坎——数据语义对齐、工具调用稳定、推理成本控制。推理型问数适合分析型问题，检索型问题用传统问数更划算。判断要不要上，看的是问题结构是否需要跨源推理。
