从模型能力到业务可用：零售AI问数落地实践

“当前店里库存压了多少？”“新品销售情况怎么样？”“这个月销售目标完成没？”这些一线店长每天面对的日常问题，看似只是“问个数”，却暴露出AI落地业务的核心挑战。项目早期采用Text-to-SQL结合RAG方案处理业务查数需求时，遇到了字段歧义、规则缺失、权限混乱等问题。用户口中的“销售额”“库存压力”需要精确映射到指标定义、过滤条件和数据范围。这不仅考验模型的语义理解能力，更考验整个工程系统对业务语义的治理能力。本文记录一套从技术选型到工程落地的完整实践过程。

技术路线的困局与突破

在项目早期阶段，系统直接让大模型理解数据库schema并生成SQL查询。看似简单直接的技术路线，却在实际运行中暴露出深层问题：用户询问“昨天店里卖了多少钱”，模型凭直觉选择了支付金额字段直接求和，SQL语法完全正确，却漏掉了取消、退款、退货等关键过滤条件，结果比业务标准口径高出近10%。问题集中在三个层面：字段级歧义——数据库中与“钱”相关的字段有十几个，模型难以判断哪个或哪些组合才是业务认可的“销售额”；状态过滤缺失——已取消、已退款、已退货的订单需要排除，但模型不知道何时该添加这些条件；跨表关联逻辑——退款和退货可能在不同表中，需要多表关联，模型纯靠猜测难以保证正确性。

Text-to-Metrics的转型逻辑

为补充业务上下文，团队引入RAG方案，但实际效果并不理想。RAG主要遇到三个问题：碎片化上下文——每段文档独立检索，业务层级关系在检索结果中被切断；缺失的业务约定——数据库文档记录“字段是什么”，但不一定记录“什么时候该用什么字段”；缺少确定性选择机制——多个候选指标语义高度相似，仅靠Top-K检索排序难以完成最终业务判断。RAG遇到的这些问题，根源在于Text-to-SQL“现场推理schema”这一本质缺陷：无论检索到多少文档，最终口径判断仍要靠模型当场完成。由此团队转向Text-to-Metrics路线：将指标口径提前定义好，模型只负责识别意图、填充参数。两条路线由路由层统一调度，Query命中已治理指标时进入Text-to-Metrics，未命中时降级到Text-to-SQL。

工程实现的关键环节

确定技术路线后，系统围绕指标治理、指标路由、查询安全和场景编排展开工程化建设。指标治理是基础工作：业务团队深入一线收集真实查询需求和用户表达方式，数据团队基于指标管理平台统一指标计算口径、维度归属、数据来源和统计规则，同时沉淀字段释义、业务别名、枚举值、时间口径等元数据。以“达成率”为例，治理前系统中至少存在三种不同公式的“达成率”，治理后通过明确指标边界、建立决策表、补充数据过滤约束，将指标选择准确率从约65%提升至接近98%。语义路由按销售、库存、人员、大盘等8个业务领域建立分区，通过关键词路由按需加载语义文件。查询安全贯穿执行链路：实体消歧将口语化表达转换为标准维度值；权限注入由系统根据用户角色自动注入数据访问范围；安全路由对跨门店查询意图进行三重判断，确保权限合规。场景编排层负责将自然语言映射到预定义查询模板，每个业务场景对应一个模板，模型只需在框架内填充参数。

质量保障与持续迭代

为持续评估系统效果并定位失败案例，团队建立了“上线前+上线后”双闭环评测机制。上线前基于业务团队提供的真实查询案例构建测试集，采用双维度设计：评估DSL准确率（生成的查询语句是否正确）和答案准确率（最终返回的数据是否正确）。两者可能并不完全一致，因此分开评测可以分别定位问题。针对失败案例，分析根因后进入“发现问题→分析原因→修复优化→回归验证”的循环。某版本评测中，企微领域18个指标122条用例中17条badcase，有8条指向同一个根因——时间口径处理不一致。不同指标类型使用不同的时间字段和偏移关系，模型对“上周”“近一个月”等时间表达统一处理。团队从时间口径约束入手，明确分组、添加Hard Rule、建立字段联动机制，下一版专项评测答案准确率达到100%。上线后建立离线自动化评测体系，从BI看板自动采集真值构造评测集，进行周期性自动化验证。

目前该AI问数系统已服务超过1000名一线店长，渗透率达88.8%，累计真人对话超过1.6万条，综合满意度评分4.32/5，多数店长反馈查询时间明显缩短。系统下一步将从被动响应向主动分析延伸：当某门店库存周转天数异常升高时主动提醒，分析销量下降的品类贡献和同期对比。AI问数的核心价值不在于模型能力有多强，而在于工程系统能否将业务语义转化为可信赖的执行结果。从Text-to-SQL到Text-to-Metrics的转型，本质上是用确定性换可靠性——将模型推理的不确定性约束在理解环节，而将业务规则和数据权限的执行交给确定性更高的工程系统负责。