自然语言让提问更容易，但不会自动解决指标口径、数据范围和权限问题。衡石 Data Agent 可以协助即时分析、创建指标和生成仪表盘；回答是否可信，仍取决于数据准备、相关信息的召回、模型配置以及业务复核。本文按一次问数任务的实际顺序，说明这些环节如何配合。

1 先让数据和指标可被正确理解

例如“上个月华东区销售额是多少”，至少要明确销售额是否含税、是否扣除退款、按下单日还是支付日统计，以及“华东区”对应哪个字段。仅把数据库表接进平台，不能替代这些业务定义。团队应先整理数据包，补全数据集、字段和原子指标的名称与说明，隐藏无关对象，并把常用计算沉淀为可复用的指标。

落地时可以先为核心数据包建立一张“可问数清单”：哪些数据集可用于销售分析，订单、退款和地区字段分别代表什么，常用指标引用哪套计算规则，哪些字段只供内部核对。清单不必成为另一套孤立文档；更有效的做法，是把名称、描述与示例直接维护在数据集和指标定义中，让分析人员与 Data Agent 使用同一份信息。

以“上个月华东区销售额”为例，人工先用已确认的指标和过滤条件算出基准结果，再用自然语言提问。若问数结果偏离基准，逐层看时间范围、地区映射、退款处理和关联粒度。这样既能发现模型误解，也能发现原有报表间口径不一致的问题。

这一步也决定排错方向。如果回答引用了错误字段，应先核对数据集知识和字段描述；如果字段选对但数字不对，应检查指标口径、过滤条件和权限范围。不要把所有偏差都归因于模型能力。

2 向量化帮助召回，但不替代业务定义

在数据包较多、字段较多或业务术语与物理字段名差异较大时，可以对数据包执行向量化。产品手册说明，字段和原子指标的名称、描述及字段值等文本会转成语义向量，供 Data Agent 检索相关信息。它有助于识别同义词和近义表达，减少只依赖关键词时的漏召回。

向量搜索是可配置能力。启用后，系统会结合向量搜索与大模型的选择结果；是否进一步用大模型筛选数据集，也由配置决定。因此，不宜把每次问数都描述成同一条固定的“向量检索—生成 SQL”流水线。字段说明、知识内容和向量化任务需要随业务变化维护，检索结果也应以实际问题集验证。

产品手册提供数据包的“向量化”操作入口，任务进度可在任务管理的执行计划中查看。首次处理后，还应在字段说明、原子指标或业务术语发生变化时检查向量化任务是否按计划更新。大量 distinct 值并不适合无差别写入索引，具体数量和资源限制要按部署版本与配置核对。

当系统没有选中预期数据集时，可按“候选数据是否可访问—名称与描述是否足够明确—业务词是否有同义表达—向量化是否完成—精选规则是否合适”的顺序排查。若召回的是正确数据集但计算错了，继续回到指标定义和关联模型，而不是反复提高检索数量。

表 1 问数偏差的排查顺序（实施建议）

问数现象	先核对	验收证据
找不到预期数据集	账号权限、名称与说明、向量化任务	该角色能够定位已授权的数据集
字段正确但数值有偏差	指标口径、时间过滤、关联粒度	与人工基准及已确认报表一致
不同角色看到不同结果	连接、应用及行列权限	差异与授权规则一致
同题结果不稳定	数据更新、模型与提示词配置	固定样本在同一配置下复测

3 模型接入和权限一起验证

衡石支持配置云端或私有部署的大模型服务，接入时要核对请求地址、密钥及接口格式；私有部署模型可采用与 OpenAI API 兼容的接口。可选模型不等于效果相同，更不意味着任意模型都能无改造接入。模型连接、响应质量和成本应在目标环境中分别测试。

选择入口时也要区分任务。Data Agent 侧边栏适合结合当前页面继续分析、创作和解读；独立的 ChatBI 更适合围绕一段会话持续问数、生成图表和看板。Agent、Workflow 与 API 模式的能力范围并不完全相同。对外集成前，先确认需要的是页面内辅助、独立问数入口，还是由业务系统调用接口，再决定模型和数据准备方案。

Data Agent 应在用户已获授权的数据范围内工作。验收时用不同角色提出同一个问题，核对可见数据包、连接权限、应用数据权限及行列权限；再核对结果使用的指标定义、筛选条件和图表。这样才能判断一次回答是“说得通”，还是“算得对、看得合规”。

4 把准确性变成可复核的工作

建议从真实业务问题中选取一组样例，覆盖同义词、跨表分析、时间口径、无权限数据和数据更新后的重问。为每个问题记录预期数据范围、指标口径与人工核对结果，再调整数据描述、向量化和模型配置。准确性应由这组问题持续衡量，不宜用未经说明的单次准确率或固定响应时间代表产品表现。

样例集最好同时包含正向与反向问题。正向问题验证同义词、跨表和复杂指标能否找到正确数据；反向问题验证无权限字段、空结果、歧义口径和不存在的指标如何处理。每次调整配置后，比较同一组问题的变化，并保留人工复核的查询结果与反馈，不要只挑选回答漂亮的案例展示。

下面是一条问数验收记录的写法。字段仅用于说明如何固定预期，不是衡石产品配置文件。

question: 上个月华东区销售额是多少？
data_scope: 已授权的销售数据包
metric: 销售额（采用已确认口径）
time_field: 支付日期
expected: 与人工基准结果一致

上线后的排查同样需要证据。对于报错，可记录完整执行日志、失败请求的响应和目标版本；对于“回答看似合理但数值有误”，应保存问题原文、用户身份、选中的数据范围、指标口径及基准计算。只有把失败归到数据、检索、模型、权限或交互中的具体环节，后续优化才有方向。

场景案例：连锁零售的滞销库存问数

一家连锁零售企业想用自然语言追问“本周哪些门店的商品积压最明显”。业务方先定义“积压”：采用哪天的库存快照、近多少天的销量、怎样计算可售库存，以及按门店和商品的什么粒度比较。实施人员再把这些定义写进销售与库存数据包的字段说明和指标中，并补充“积压”“滞销”等常用说法。

提问时，Data Agent 应在提问者已获授权的数据范围内选择相关数据集和指标。如果没有找到库存字段，就先检查描述、同义词与向量化任务；如果字段选对但排名异常，则检查库存快照、销量窗口和关联粒度，而不是只调整模型提示词。

验收时固定同一批门店、商品和日期，以人工查询形成基准，再由不同门店角色重复提问。通过条件是排名和数值符合已确认口径、无权限门店不出现在结果中；这是一种可复核的实施场景，并非真实客户效果数据。

衡石的实践重点，是把数据准备、语义召回、模型能力和权限复核放进同一条交付链。AI 降低了提问门槛，可靠的分析仍需可检查的业务口径与结果。