AI总查错数，元数据才是真Prompt

很多团队还在比拼谁的Agent更聪明，殊不知决定成败的，是那份没人愿意好好写的dbt文档。

最近海外数据圈流传着一篇很扎心的复盘：一位工程师给自己的公司数据搭了一套MCP服务器，让AI Agent能自动查找和查询内部数据。按理说，工程主体应该是那台MCP服务器——协议对接、权限、查询路由，活儿不少。

但他自己承认：大部分时间没花在服务器上，全花在了一个问题上——为什么Agent总是选错表？

答案几乎每次都一样：不是模型不够聪明，不是检索算法不够强，而是dbt文档本身烂。

这个判断值得所有正在做"ChatBI""智能问数""数据Agent"的团队停下来想一想。当大模型的能力已经过剩，真正的瓶颈悄悄转移到了最古老的环节：元数据质量。

🤖 Agent选错表，别急着怪模型

先还原一下这个典型场景。

业务方在对话框里问："上季度注册但没付费的用户有多少？"

Agent开始干活：先在元数据索引里检索，找到一堆候选表——dim_users、fct_signups、user_payment_summary、还有三个历史遗留的user_info_v1/v2/v3。然后它挑了一张看起来最像的表，生成SQL，返回一个数字。

数字是错的。因为那张表的user_id其实是账号ID，不是玩家ID；或者那张表是月度快照，粒度根本对不上。

数据平台的负责人看到这一幕，第一反应往往是"换个更强的模型"或者"调一下RAG参数"。但MCP服务器的搭建者发现，问题出在一个所有人都忽视的地方：模型描述（description）的写法。

这里有个残酷的事实：Agent看到的元数据，和人类分析师看到的，根本不是同一份。

人类分析师会点开dbt docs，滚动阅读全文，还会去问写这个模型的人。Agent不会——它只检索，不翻页。

这就引出了第一条实战结论。

📝 描述的第一句话，决定Agent的一生

这位工程师在给dbt模型做索引时遇到了硬约束：长文本没法全部向量化。超长的描述会被截断。

结果是什么？只有模型描述的第一行、每一列描述的前两句话，会真正进入检索系统。后面写得再详尽、再专业，Agent永远看不到。

这对写文档的人来说是一个范式转变。传统dbt文档的逻辑是"给未来的自己或同事看"，可以娓娓道来、层层递进。而现在，你的读者是一台不做推理铺垫、只做语义匹配的机器。

正确的写法因此变得极其"功利"：

• 第一句话就说清楚三件事：这张表是什么、粒度（grain）是什么、它不是什么；
• NULL值的特殊含义必须放进第一句——如果某列因为特定业务原因为空，这就是Agent最需要的判断依据；
• 背景故事、演进历史、设计权衡，统统往后放。

我们可以用一张表对比两种写法的差距：

左边这种写法，人类能看懂，但Agent已经在里面自我循环了。右边多出来的每一个信息点——粒度、排除项、NULL语义、禁止混用的关联——都是Agent无法从SQL代码里自行推断的知识。

一句话总结这节：元数据不再是为人类写的注释，而是Agent的Prompt本身。

⚠️ 让AI写YAML，是数据团队最流行的自杀方式

接下来是作者称之为"最大的陷阱"的问题。

场景太熟悉了：300个dbt模型，文档欠账两年，数据团队没人手。于是很自然地想到——让AI来写描述呗，把SQL喂进去，让它自动生成YAML，一晚上补完全部文档。

技术上完全可行，产出物看起来也像模像样。但你打开一看：

“user_id：用户的标识符（Identifier of user）。

这就是一句废话。Agent自己就能看到这列叫user_id，它需要的是怎么用这张表：该和哪张表关联、可不可以为NULL、这个ID指的是玩家还是账号、还有哪些同名的user_id列绝对不能混用。

作者的判断很犀利：一个只会读模型的AI，只能复述模型。Agent再来读这段文字，学到的东西是零。整个系统陷入一个死循环——代码在向它自己解释它自己。

这个循环的隐蔽之处在于：补文档的KPI完成了，YAML覆盖率100%，工具链看起来很完善，领导汇报很好看。但Agent选表的准确率纹丝不动。

据多位接触过类似改造的从业者私下反馈，这个"AI生成文档覆盖率"的数字游戏，在不少公司已经成了心照不宣的表面文章——覆盖率高企，问数准确率原地踏步，没人愿意第一个承认文档是无效的。

真正的解法只有一个：描述必须来自知道业务的人。哪些信息是SQL里看不出来的？粒度的业务含义、NULL的潜规则、ID体系的边界——这些恰恰是写模型的人脑子里有、但从来不屑于写下来的东西。AI没法替你回答"这个user_id到底是玩家还是账号"，因为答案不在代码里，在业务里。

🕸️ Netflix的答案：别补文档了，建知识图谱吧

如果说个人开发者层面的教训是"把描述写好"，那么Netflix给出了一个更工程化的解法——当元数据复杂到文档根本写不动时，换一种载体。

在一场技术分享中，Netflix的Prasanna Vijayanathan和Renzo Sanchez-Silva介绍了他们在可观测性（Observability）上的做法。先感受一下体量：每秒3800万条事件。靠人盯告警、靠传统的被动式监控（reactive monitoring），已经完全不可能了。

他们的思路是把四类遥测数据——指标（Metrics）、事件（Events）、日志（Logs）、链路追踪（Traces），业界合称MELT——统一成可查询的知识图谱，在此基础上跑一个由Claude驱动的Agent工作流，配合图数据库做运营本体（operational ontology）建模。

这套东西的专业名字叫本体驱动可观测性（Ontology-Driven Observability）。听起来很玄，但拆开看逻辑非常朴素：

1. 以前告警是一个个孤立的点，现在通过知识图谱把它们连成了网络；

2. 服务、依赖、变更、指标之间的关系不再是散落在各个系统里的 Tribal Knowledge，而是可查询的图结构；

3. Agent接手后，可以沿着图谱自动做故障分诊（triaging）和根因分析（root cause analysis），甚至触发自愈（self-healing）。

注意这里和前文案例的深层共性：Netflix也没有把宝押在"更聪明的模型"上。Claude很重要，但真正让Agent能干活的前提，是那个把3800万事件/秒的混乱遥测收敛成结构化知识的本体层。

模型是发动机，元数据是地图。没有地图的发动机，马力越大，跑偏越远。

💡 数据团队的新KPI：文档即接口

把两个案例放在一起，能看到一条清晰的产业信号。

过去十年，数据行业围绕"人"建设了一套元数据体系：数据字典给人看、数据目录给人搜、数据血缘给人排查。dbt的YAML、各家的数据目录产品，默认读者都是分析师和工程师。

现在，第一批"非人类常驻读者"来了。它们7×24小时在线、只读检索结果、不做口头追问、且会一本正经地把错误答案送给业务方。整个元数据体系必须为此重构。

这个过程大概会经历三个阶段：

对数据团队来说，这意味着几个具体的动作变化：

• 模型描述的首句成为第一等公民，code review时应该像审查列命名一样审查它；
• "AI生成描述"从效率工具降级为反模式，AI可以协助起草，但业务语义必须由懂业务的人注入；
• 粒度、NULL语义、ID边界、禁止混用清单，这些以前写在Wiki深处的东西，要前置到检索入口；
• 当复杂度超出文档承载能力时，参考Netflix，考虑用知识图谱和本体建模替代平面文档。

数据仓库时代有句老话：Garbage in, garbage out。Agent时代它有了新变体——Description in, decision out。你喂给Agent什么质量的元数据，它就用什么质量的判断回报你。

小结

Agent时代的竞争，正在从"谁的模型更强"转移到"谁的元数据更能被机器消费"。一位独立工程师的MCP实践揭示了最朴素的真相：Agent只读描述首句，AI生成的文档是自我循环的废话，真正的语义必须由懂业务的人写进去；而Netflix在每秒3800万事件的体量上，用知识图谱和本体建模给出了规模化答案。对数据团队而言，2025年最值钱的投资可能不是再买一个更贵的模型，而是回头把那300个模型的YAML，一句一句重写一遍——这次，读者是机器。