数据问答可靠性，先从语义建模补课

数据问答答错了，先改提示词，还是先查表？作者的判断是：Genie 能否可靠工作，首先取决于底层数据有没有明确的业务含义。粒度混乱、关联关系缺失、指标口径冲突，都会被聊天界面包装成流畅却错误的答案。

文章用一个事实表与维度表的演示说明，怎样把数据整理成可供 AI 查询的范围。它值得程序员读的地方，是提醒我们：接上模型和聊天 UI，只完成了入口；答案是否可信，还要看入口后面的数据契约。

为什么先修数据模型，比继续改提示词更有效

这里的「建模」指数据建模，不是训练大语言模型。作者要求的准备程度也很朴素：把聊天界面拿掉，一位谨慎的分析师仍然愿意信任这些表。

作者描述了一种常见补救过程：团队先把 Genie 接到整理了一半的数据上，演示很漂亮；发现答案有问题后，花一周改提示词，错误的关联却一直存在。这是作者对项目模式的观察，原文没有提供统计样本或对照实验。

它背后的机制并不难理解。回答「某类客户贡献了多少收入」，至少需要确定收入字段、客户分类、关联路径和汇总规则。如果这些信息只存在于人的脑子里，模型就得猜。猜出来的 SQL 可能合法，也能返回数字，却没有回答业务真正想问的问题。

作者把准备工作归为四根支柱：整理过的数据结构、业务名称与术语、明确的关联关系，以及有负责人的指标定义。提示词覆盖在这些基础之上。

因此，他建议先认证一小块 gold 数据范围。这里的 gold 可以理解为经过整理、面向分析消费的数据层；bronze 和 raw 则是更接近原始落地的数据。把所有生产表开放给聊天工具，看似增加了能力，实际也增加了歧义。

聊天入口能降低提问门槛，却不会自动补齐业务定义。

一张表能不能交给 AI，先看它有没有讲清这些事

第一件事是粒度，也就是「一行到底代表什么」。

订单头和订单明细混在一起，或者事件记录与定期快照放在同一张事实表里，都可能让计数和求和出错。人需要额外说明才能理解的地方，也应该明确告诉查询工具。

作者的演示把约定直接写进表描述：每个 id 对应一行，每行恰好属于一个 segment，并说明数值如何汇总。每列都有含义说明，关键列标记为主键和外键。信息放在表上，才能被不同消费者复用。

第二件事是名称和术语。用户问的是 amount，字段却叫 COL_A，两者的对应关系就应该进入工具可读取的目录元数据或语义层。把 key_a 描述成「key a」没有增加任何业务信息。

长系统提示词也能塞进术语表，但作者认为这会形成维护负担：字段和业务口径变化后，多处说明容易失去同步。更稳妥的做法，是让查询规划器和模型都能从数据附近读到同一份含义。

演示中，Genie 的数据源面板确实显示了来自目录的粒度描述、主外键标记和列注释。这支持了一个具体结论：这些元数据在作者的环境里能够进入 Genie。它并不能单独证明模型每次都会正确使用。

第三件事是指标归属。每个指标需要一个定义、一位明确的负责人，以及工具有权读取的存放位置。三个团队各算一套「收入」，聊天工具选中其中一套，也解决不了组织内部的口径冲突。

最后是敏感字段分类。对话式访问仍然是数据访问，脱敏、列级权限和排除范围应该在开放前处理。用户能自然语言提问，不代表他就应该获得更大的查询权限。

别只看回答对不对，要看 SQL 怎么关联

原文最具体的验证发生在两张演示表之间：事实表 fact_a 的主键是 id，维度表 dim_a 的主键是 segment_id，事实表通过外键 segment_id 指向维度表。

作者还通过 Genie spaces API，在空间定义中提交了 join_specs，声明两表按 segment_id 建立多对一关系。

这里有一个重要的证据边界：作者所在工作区的 Genie 界面没有显示这条关联配置。他给出的佐证，是目录中声明的键，以及 Genie 最终生成的 SQL。

当问题要求统计某个属性对应的总值时，生成 SQL 使用 INNER JOIN，按 segment_id 关联，再根据维度属性过滤，结果为 97.00。

这个例子说明，作者检查了实际关联路径，而不只是截取一个看起来正确的答案。但它没有证明所有问题都能正确关联，也没有通过对照实验分离主外键、注释和 join_specs 各自的作用。

关联错误尤其麻烦，因为结果常常很像真的。两列日期都像业务日期，模型就可能选错；桥接表没有说明，模型可能自行拼出一条不成立的路径。仅仅确认 SQL 能执行，远远不够。

作者因此建议维护固定问题集，记录预期结果，检查生成 SQL 的关联，并定期复查。它比一次精彩的现场演示更适合作为验收依据。

认证范围也需要持续管理。新增「就一张表」，仍然要经过粒度、键、描述、敏感性、指标和评估检查。原文只允许在限时探索、且没有终端用户流量的情况下，把 Genie 指向 raw 或 bronze。

我的判断

我认同作者把排查顺序前移。面对数字不可信的问题，先检查粒度、关联和口径，通常比不断添加「请准确回答」更有针对性。这些整理工作也能服务 BI 报表和其他数据消费者，收益不会只停留在聊天工具里。

但「建模优先」不等于建模完成后就能放心使用。原文没有给出提示词优化与建模优化的量化对照，也没有提供准确率、失败率或持续运行的数据。演示验证了一条查询路径，不能替代完整的质量评估。

标题同时提到 Genie 和 Fabric Agents，实际展示的是 Genie 的元数据与查询行为。对 Fabric Agents，文章主要借助语义模型的一般原则展开，没有提供同等程度的实测。因此，具体平台能读取哪些描述、怎样使用关系配置，还需要分别确认。

和把业务规则写进提示词相比，把公共定义放进目录或语义层更便于复用；代价是需要维护者，也需要约束新增数据的流程。原文明确承认，建模比改提示词慢，评估也要花时间。对一般团队而言，难点可能不是写出第一批说明，而是谁持续维护、谁处理口径争议。

这篇更适合作为数据问答的准备清单，而不是产品准确性的证明。

能拿来做什么

• 做内部数据问答时，先挑一个边界清楚的业务范围，明确允许查询的表、每行含义、关联路径和指标负责人。第一版的目标应该是让有限的问题稳定可验，而不是一次开放整个仓库。
• 在前端展示结果、由 Node 服务承接查询的场景里，把答案对应的 SQL 纳入调试和验收流程。发现异常时，检查关联键、日期字段和聚合方式，给排查留下具体依据。
• 把固定业务问题做成回归集，保存预期结果，并检查 SQL 是否采用预期关联。新增表、调整指标或更换模型后，重新执行这些问题，避免只靠人工试聊判断质量。
• 开放聊天入口前，按现有数据权限检查敏感列、脱敏和排除范围。术语与指标定义则放进工具实际能读取的位置，避免只维护在团队 wiki 中。