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

“当前店里库存压了多少?”“新品销售情况怎么样?”“这个月销售目标完成没?”这些一线店长每天要面对的问题，看似只是“问个数”，但要让 AI 真正服务业务，还需要解决指标口径、查询规则和数据权限等问题。

小米中国区零售团队从 Text-to-SQL 转向 Text-to-Metrics，并围绕指标治理、语义路由、查询执行和评测体系进行工程化建设。本文记录这套方案的实践过程。

01 为什么需要调整技术路线

“当前店里库存压了多少?”

“新品销售情况怎么样?”

“这个月销售目标完成没?”

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

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

1. 字段级歧义：数据库中与”钱”相关的字段有十几个，模型不知道哪一个或哪几个组合才是业务认可的”销售额”。
2. 状态过滤缺失：已取消、已退款、已退货的订单需要排除，但模型不知道什么时候该加这些条件。
3. 跨表关联逻辑：实际业务中，退款和退货可能在不同表中，需要多表关联并正确匹配，模型纯靠猜测。

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

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

Text-to-SQL：模型现场自己写 SQL 查数。
RAG：给模型塞文档当参考，帮它补上下文。

Text-to-Metrics：指标口径提前定义好，模型只负责识别意图、填参数。

为补足模型缺失的业务上下文，团队引入 RAG 方案。但实际问题并不只是“找到信息”，还在于面对多个相似指标时，如何选择正确答案。

复盘这个案例，RAG 主要遇到了三个问题：

1. 碎片化上下文：每段文档独立检索，彼此之间的业务层级关系在检索结果中被切断。模型看到的是孤立的字段说明，看不到它们在全量指标体系中的位置。
2. 缺失的业务约定：数据库文档通常记录“字段是什么”，不一定记录“什么时候该用什么字段”。比如店长日常问销量时应该用哪个口径，这类知识更多存在于业务团队中，没有进入检索库。
3. 缺少确定性选择机制：多个候选指标语义高度相似，仅靠 Top-K 检索排序难以完成最终业务判断。

需要说明的是，RAG 并不是一条独立路线，而是对 Text-to-SQL 的增强——通过检索注入业务上下文来补足模型缺失的知识。因此，RAG 遇到的三个问题，根源仍在于 Text-to-SQL”现场推理 schema”这一确定性的缺失：无论检索到多少文档，最终口径判断仍要靠模型当场完成。这让我们跳出”继续增强 Text-to-SQL”的思路，转而考虑另一条路线 Text-to-Metrics。下面这张图对比了两者的核心差异：

两条路线没有绝对优劣。对于小米中国区零售业务，选择 Text-to-Metrics 主要基于三个判断：

• 核心用户是一线店长，查询以获取可信结果为主；
• 高频查询集中在经营分析、库存管理等固定场景；
• 查询结果涉及备货、排班等经营决策，对结果准确性要求较高。

两条路线由路由层统一调度：Query 命中已治理指标时进入 Text-to-Metrics，未命中时降级到 Text-to-SQL。

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

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

▍指标治理：统一业务口径

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

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

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

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

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

1. 明确指标边界：将三个“达成率”的公式差异、适用对象、考核体系全部文档化。
2. 建立决策表：为用户常见表达方式建立精确的指标映射规则——“综合达成率”→综合考核口径，“渠道X达成率”→渠道X口径，“渠道Y达成率”→渠道Y口径，“达成率”（无修饰）→根据用户归属自动判断。
3. 补充数据过滤约：发现部分指标底层存在未过滤的脏数据，查询时必须加过滤条件。

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

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

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

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

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

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

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

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

• 指标权限预检

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

• 零结果保护

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

▍查询安全：实体消歧与权限控制

查询安全需要贯穿查询执行链路。进入查询执行阶段后，问题从“理解得对不对”变成“执行得安不安全”。在零售场景中，AI 不仅需要回答问题，还需要遵循业务系统已有的权限、经营规则和数据安全要求。查询过程被拆解为三个关键步骤，不同环节承担独立的校验职责。

• 实体消歧：用户口语化的“旗舰店”“华东区”“某某型号产品”等表达，需要转换为数据库中的标准维度值。系统先召回相关实体，再按业务逻辑归并到正确的分析粒度。当匹配到多个候选结果且无法精排时，系统不会让模型自行判断，而是主动请求用户确认。
• 权限注入：权限逻辑不交给模型决定。在查询构造阶段，系统根据用户角色自动注入数据访问范围：店长只能查自身门店，分公司只能查辖区数据。即使上层模型产生偏差，这一层仍能兜底。
• 安全路由：对于“同网格排名”“标杆店对比”等跨门店查询意图，系统结合用户角色、关键词和查询目的进行三重判断，只有全部满足才进入越权查询分支。普通聚合查询不会被误判。

▍场景编排：将自然语言映射到查询模板

店长提出的问题往往很简单：“这个月卖得怎么样？”“哪些店最近压力比较大？”这些表达背后缺少完整的时间范围、指标定义和查询条件。

场景编排层负责将自然语言转换为标准查询参数。系统结合意图识别、角色信息、多轮上下文和预定义查询模板，将用户表达映射到对应业务场景。例如用户说“那上周呢”，系统能够基于上下文识别其对应的指标和时间维度，而无需重新理解完整意图。每个业务场景对应一个预定义模板，模型只需在模板框架内填充参数，而不是从零构造查询。

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

为持续评估系统效果并定位失败案例，团队建立了“上线前 + 上线后”的双闭环评测机制。上线前，基于业务团队提供的真实查询案例和期望结果构建测试集。评测采用双维度设计：不仅评估 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 返回结果与真值。当准确率出现波动时自动告警，及时发现准确性变化。

05工程复盘：三点实践经验

1. 用确定性换可靠性

Text-to-Metrics 将部分在线推理转化为“离线验证 + 在线执行”：指标口径提前治理，查询模板提前验证，模型只需在预设范围内完成选择。相比让模型每次从零推理，这种方式更容易控制结果稳定性。

1. 不确定性不向下游传递

路由不确定就缩小范围或追问，实体消歧不确定就请求确认，查询构造不确定就中止执行。将问题尽量解决在当前环节，而不是把不确定性继续传递给下游。

1. 模型负责理解，系统负责执行

模型负责理解自然语言和查询意图，工程系统负责指标选择、权限控制和查询构造等确定性环节。通过明确分工，将模型的灵活性与系统的确定性结合起来。

06下一阶段：从查询响应走向主动分析

目前，该 AI 问数系统已服务超过 1000 名一线店长，渗透率达 88.8%，累计真人对话超过 1.6 万条，综合满意度评分 4.32/5，多数店长反馈查询时间明显缩短。

目前系统主要解决“用户问，系统答”。下一步将从被动响应向主动分析延伸：当某门店库存周转天数异常升高时，系统可以主动提醒；用户询问“这个月销量为什么下降”后，也可以继续分析哪些品类贡献了降幅、与去年同期相比如何。系统将进一步基于已有数据主动识别异常指标，并提示值得关注的方向。

本文作者@小米技术。原文链接：https://mp.weixin.qq.com/s/mvzwjZlJJ-rCK59pXHg19A