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

对一线店长来说，这些都是日常问题。但要让 AI 正确回答，难点并不只是生成 SQL，还包括指标口径、查询规则和数据权限等业务约束。用户口中的“销售额”“库存压力”，需要进一步映射到明确的指标、规则和数据范围。

在项目早期，系统直接用大模型理解数据库 schema 并生成 SQL。用户问了一句“昨天店里卖了多少钱”，模型凭直觉选择了订单表中的支付金额字段直接求和，SQL 语法完全正确，却漏掉了取消、退款、退货等关键过滤条件，结果比业务标准口径高出近 10%。进一步拆解，问题主要集中在三个层面：

1. 字段级歧义：数据库中与"钱"相关的字段有十几个，模型不知道哪一个或哪几个组合才是业务认可的"销售额"。

2. 状态过滤缺失：已取消、已退款、已退货的订单需要排除，但模型不知道什么时候该加这些条件。

3. 跨表关联逻辑：实际业务中，退款和退货可能在不同表中，需要多表关联并正确匹配，模型纯靠猜测。

为补充业务上下文，团队进一步引入 RAG，将指标定义、字段释义和历史查询案例加入向量库。但检索能力提升后，指标选择仍存在不确定性。

路线选择：从 Text-to-SQL 到 Text-to-Metrics

工程实现：从指标治理到查询执行

确定技术路线后，系统进一步围绕指标治理、指标路由、查询安全和场景编排展开工程化建设。

指标治理首先需要明确指标定义和适用边界。如果底层指标没有统一定义，模型能力提升也无法解决业务口径不一致的问题。

业务团队深入一线收集真实查询需求和用户表达方式，数据团队基于指标管理平台，统一指标计算口径、维度归属、数据来源和统计规则。同时，沉淀字段释义、业务别名、枚举值、时间口径等元数据，将分散在业务系统和人员经验中的知识整理成机器可以使用的语义资产。

以“达成率”为例。在小米零售体系中，“达成率”是店长和分公司经常查看的指标之一。但在治理前，系统中至少存在三种不同公式的“达成率”。三个指标都叫“达成率”，但三个答案都可能是对的：

实际问题是，三个指标公式不同、适用对象不同、考核体系不同，但字面描述高度相似。用户说“看下达成率”，系统需要判断他想看哪个体系的达成率，如果是新体系还要区分不同渠道。

因此，治理工作主要包括三个方面：

1. 明确指标边界：将三个“达成率”的公式差异、适用对象、考核体系全部文档化。

2. 建立决策表：为用户常见表达方式建立精确的指标映射规则——“综合达成率”→综合考核口径，“渠道X达成率”→渠道X口径，“渠道Y达成率”→渠道Y口径，“达成率”（无修饰）→根据用户归属自动判断。

3. 补充数据过滤约束：发现部分指标底层存在未过滤的脏数据，查询时必须加过滤条件。

   
   

治理后，“达成率”相关查询的指标选择准确率从约 65% 提升至接近 98%。

▍指标路由：按业务领域加载语义

在传统方案中，模型通常从大量资料中自行寻找答案。但实际问题并不是信息不足，而是在多个相似指标中选择正确指标。

用户说的“销量”可能对应多个指标别名。为缩小指标选择范围，系统按照销售、库存、人员、保险、大盘、运营、分公司、培训 8 个业务领域建立语义分区，通过关键词路由按需加载对应语义文件。

加载上限设为 3 个分区。根据真实查询分布统计，80% 以上的查询只涉及 1 到 2 个分区，较少有业务问题同时横跨 4 个以上领域。当触发词命中超过 3 个分区时，系统优先追问澄清，而不是继续扩大上下文。

路由也不是简单的关键词匹配。不同领域设置了优先级规则，例如大盘查询强制独占，避免大盘数据与其他经营指标混淆；多分区命中时按优先级加载。这些规则来自真实业务运行中的边界案例积累。

同时，系统增加了多层校验：

• Alias 白名单确保最终执行的指标和维度来自已注册列表，避免未治理字段进入查询流程。

• 指标权限预检在查询前完成，提前区分“指标不存在”和“用户无权限”两类问题。

• 零结果保护将空结果视为有效业务结论，禁止系统换日期或去条件反复尝试。

  
  

质量保障：建立上线前后的评测闭环

为持续评估系统效果并定位失败案例，团队建立了“上线前 + 上线后”的双闭环评测机制。上线前，基于业务团队提供的真实查询案例和期望结果构建测试集。评测采用双维度设计：不仅评估 DSL 准确率，即生成的查询语句是否正确，还评估答案准确率，即最终返回给用户的数据是否正确。

两者可能并不完全一致。例如 DSL 中维度少了一级，但答案通过其他方式补全，最终结果仍然可能正确。因此分开评测，可以分别定位查询构造和最终结果上的问题。针对失败案例，进一步分析原因：如果问题来自业务定义缺失，则补充语义资产；如果问题来自模型判断偏差，则优化 Prompt 和约束规则。每一次失败都会进入“发现问题 → 分析原因 → 修复优化 → 回归验证”的过程。

案例：从 badcase 定位时间口径问题

某版本评测中，企微领域 18 个指标、122 条用例，DSL 准确率 93.2%。17 条 badcase 中，8 条集中在同一个根因，占比接近一半。逐条分析这 8 条失败 case，所有问题都指向同一个模式——时间字段的偏移错误：不同指标类型使用不同的业务时间字段，有的需要两个时间字段联动，且偏移关系各不相同。模型在处理“上周”“最近一个月”等时间表达时，对所有指标都统一使用了相同的处理逻辑。明确根因后，团队从时间口径约束入手，做了三项修复：

1. 明确时间口径分组：在分区文件中将指标按时间口径分组，每组标注其专属的时间字段和偏移规则。

2. 添加 Hard Rule：不同口径的指标不可混查，必须分别构造查询。

3. 时间字段联动：明确各时间字段之间的偏移关系，禁止对所有指标统一处理。

   
   

为验证修复效果，下一版评测没有直接沿用原测试集，而是针对这一问题新增了 44 条专项用例。

结果是：DSL 准确率仍为 93.2%，但答案准确率首次达到 100%（44/44）。这说明，单看 DSL 是否一致，并不足以判断系统最终答案是否正确。

▍离线自动化评测：基于真值持续验证

上线后的人工评测无法覆盖日常迭代引入的回归问题。为此，团队建立了离线自动化评测体系，核心思路是从 BI 看板自动收录真值（Ground Truth，即从业务系统获取的真实数据值），构造真值评测集，进行周期性自动化评测。

• 真值收录：从 BI 看板自动采集各指标的真实数据值，作为评测基准。相比人工标注，真值来自业务系统本身，可以持续更新。

• 评测集构造：基于收录的真值，参考线上真实 Query 模式自动构造评测集。每条评测用例包含 Query 文本、期望 DSL、期望返回数据。

• 周期性自动化评测：定期自动执行评测集，对比 Skill 返回结果与真值。当准确率出现波动时自动告警，及时发现准确性变化。