一个数字还不够完成回答
用户问：“上周新增客户为什么变少了？”界面返回一个百分比，再配上流畅解释，看起来已经完成任务。但如果数据只更新到周四，或者两周使用了不同的客户定义，这段解释就缺少可靠基础。
业务数据问答需要把答案依赖什么、哪些部分能够验证，直接展示给使用者。模型已有知识、临时查到的资料和应用算出的指标，应当能在结果中追溯，否则很难判断一个错误发生在哪一步。
先为问题确定可计算的含义
新增客户可能指完成注册、首次下单或人工审核通过的人。遇到尚未约定的口径，可以先给出选项，或者展示当前采用的定义，请用户确认。时间范围也应说明时区、起止日期和数据更新时间，避免把尚未结束的一周与完整周比较。
以演示产品为例，可以使用一份明确标注为合成数据的客户转化样例。先让程序完成固定口径的计数和比较，再让模型解释结果。解释若涉及“为什么”，应将已观察到的渠道变化与尚待验证的原因分开，不能仅凭同时发生就写成因果关系。
答案旁边应该能找到什么
一份简短的答案说明可以包含四类信息：
- 口径：统计对象、去重规则、过滤条件和比较区间。
- 来源：获准使用的数据集、相关文档和查询版本。
- 时效：数据更新到何时，哪些分区缺失或延迟。
- 限制：哪些结论由数据直接支持，哪些仍需业务确认。
Microsoft 的 RAG 文档将检索相关性、内容权限和数据准备列为实现挑战。把资料接入模型只是开始，还要确保当前用户有权读取、检索结果适用，以及引用真的支持对应结论。
因此，“没有找到足够证据”应该是一种正常输出。数据缺失时，可以先返回已经核实的范围，再说明还缺什么；不要用貌似完整的解释填平空白。若用户指出口径错误，界面应允许修改条件后重新计算，并让他看见前后变化。
用问题集检查交付质量
验收可以准备一组典型问题，覆盖明确口径、含糊口径、过期数据、空结果和越权请求。每个问题记录期望查到的资料、允许执行的动作及应保留的不确定性。除了看数字是否正确，还要检查引用、时间说明和拒答是否符合预期。
同一个问题可以多次运行，观察结果是否稳定；更换模型、检索规则或数据结构后，再运行同一组问题。这样才能知道修改改善了什么，又损伤了什么。
对展示给招聘方或潜在客户的作品，选择两三个能点击核查的例子即可：一条成功回答、一条缺证据的回答、一条口径修改后的回答。把可检查的过程做清楚，读者才有办法判断这套工具是否适合进入实际工作。