让 AI 做数据分析前,先补上“本体工程”这一课

一张销售明细表，四十七列。

三列带着“金额”两个字：金额、金额（含税）、确认金额。“状态”那列是 0、1、2、3，中间还混着几个中文词。

你把这个文件丢给 AI，问它：上个月卖了多少钱。

它给你一个数。小数点后两位，下面还有一行“环比增长 12.3%”。

这个数可能是错的。不是它算错了，是它选的列不是你想的那列。

换四个人来算，能给四个答案。差三成，很正常。

它也不会跟你解释这个选择。在它眼里，“金额”和“备注”“编号”一样，都是几个汉字。

这跟模型聪明不聪明没关系，今天最好的模型也一样。原因只有一个：它不知道“销售额”在你们这儿指什么。

────────────────────────

它算得快，但不知道自己在算什么

模型做数据分析，路子一般是：读表，写一段代码，跑出来，画图，解释。

前几步它做得不错。写 SQL 比很多人快，Excel 里的嵌套公式也难不倒它。

它只有一处过不去：那些列名的意思，还有那些值背后的规矩。

具体会怎么翻车。我编几个例子，坑都不新鲜。

一张表里，缺失值写了三种：有的是 -1，有的是空，还有一格写着“暂无”。它碰到 -1，会老老实实当负一算进平均里。

两列都叫金额，一列单位是元，一列单位是万元。它不会停下来问，它会挑看起来更干净的那列。

“客户编号”在订单表和客户表里都有。订单表那份是内部编号，客户表那份是渠道给的外部编号。它按这两列对上，行数从八千变成一万二。它看不出来。

“状态”里 0 到 3 各是什么，只有你们内部知道。3 是已取消还是已退款？算不算进销售额？这个答案决定最后一句话，而答案不在表里。

它不会说“我不知道”。它会挑一个最像的假设，一路算到底，最后给你一张挺好看的图。

这一点得记住：它的错误，不会以错误的样子出现。

────────────────────────

一个听着吓人的词

计算机里管这件事的叫本体，本体工程（Ontology Engineering）。

这一行引用最多的定义，是“对某个概念化的明确、形式化的规约”。翻成人话：把你们这儿的词，写到机器能照着办的细度。

哲学里的本体问“世界由什么构成”。搬到工程里，问题变得很小——这个圈子里有哪些东西，每个东西有哪些字段，字段里什么值算数，它们之间怎么连，哪条规矩不许破。

四件事。写起来不难。难的是你会写着写着发现，很多条你们自己也没定过。

这里要分清两个东西，很多人混着说。

数据字典只写字段：这一列叫什么、什么类型。本体比它多两样。一样是关系：哪一列跟哪一列是同一件事，连起来是一对一还是一对多。另一样是规矩：什么值算数，什么情况不许用，哪些数字是算出来的、怎么算。

少了这两样，词典还是词典。AI 读得懂列名，照样不知道能不能加。

顺便说一句知识图谱。图谱是照着本体填进去的一堆实例——张三、李四、订单 8001。本体是那张纸，图谱是纸上的字。先有纸。

────────────────────────

为什么模型的“聪明”救不了这件事

有人会想：模型见过那么多表，难道猜不出来。

它确实会猜，而且猜得挺准。大部分公司的表长得像，列名也像。问题在“大部分”这三个字。

它猜得准不准，取决于你们的表有多标准。业务越特殊，表越不标准。偏偏是那些最值得分析的业务，最难猜。

还有一层。模型是在文本上做预测的。“销售额”这三个字它见过无数遍，每次上下文都不一样。它知道这个词常见，不知道你们公司算的是哪一列、排的是哪些行。

打个不太准的比方：它像个数学很好的实习生，第一天上班就拿到全部数据权限，但没人跟他讲过业务。他会算，也会算错，而且他不好意思说自己没听懂。

────────────────────────

先给它一张纸

不用建全公司的知识图谱，那是另一个工程。一张纸，四段话，够用了。

第一段，这张表一行是什么。是订单、订单行，还是一天的汇总。这一句决定后面所有的求和能不能加。

第二段，每个字段。中文名、含义、单位、缺失怎么表示、合法取值是哪几个。字段多就先挑你要用的十来个。

第三段，跟别的表怎么连。哪一列对哪一列，会不会一对多，连完行数大概怎么变。

第四段，口径。算这个数用哪几列、排掉哪些行、时间按哪个字段。这一段里每一句都该是能吵起来的，吵得起来的才需要写下来。

把这四段贴在提问前面。下面这段可以直接改。

我接下来要你分析一张表。先把下面这份说明读完，不要急着写代码。  【这张表一行是什么】 【字段说明】字段名 | 含义 | 单位 | 缺失值怎么表示 | 合法取值 【与其他表的关系】 【口径】本月销售额 = ……（用哪列、排掉哪些行、时间按哪一列）  读完先做一件事：用你自己的话，把上面四条复述一遍，特别是“口径”那条。复述完停下来等我确认，不要往下算。

最后那句话是整段里最值钱的。

因为它复述的时候，你会看见它把哪一条理解歪了。三十秒的事，省掉后面半小时的重算。

────────────────────────

一张纸上的口径，长什么样

举个典型的难题：客单价。

客单价怎么算，多数人会答：销售额除以客户数。这句话没法执行，因为两个词都没定。

销售额，是含税还是不含税？退款的那部分扣不扣？

客户数，是下单的客户，还是活跃的客户，还是全部客户？一个人这个月下了三单，算一个还是三个？

“一个人”又是个坑。同一个手机号注册了两个账号，同一个公司用了三个抬头，算一个人还是三个人。

这些问题的答案不同，客单价能差出好几倍。而它们没有一个能从表结构里看出来。

写清楚的样子大概是这样，一行一行写，写完就能拿去对：

客单价 = 本月销售额 ÷ 本月下单客户数 本月销售额：用“确认金额”列，含税，剔除状态为“已退款”和“已取消”的行，时间按“到账日”。 本月下单客户数：按“客户主档编号”去重，不按手机号；本月至少一笔有效订单即计入。 内部测试账号：客户主档里标了“测试”的，两个数都要排掉。

写到这个细度，它才是能交给机器执行的规矩。写成“销售额除以客户数”，那只是一个说法。

你可能会觉得这太琐碎。麻烦的地方在于，不写的代价不是没有，是每次都要重新吵一遍，而且每次吵出来的结论可能不一样。

────────────────────────

让它自己交代

确认完口径，再让它算。算的时候补一句：每个数字后头都得标出来，用了哪几个字段、排掉了哪些行。

现在按上面的口径算。每给出一个数字，后面跟一行小字：用了哪几个字段，排掉了哪些行。给不出标注的数字不要给。

加这句话，是因为它会偷懒。不要求标注，它就把中间步骤全藏起来，只给你结果。你只能选择信或不信。

要求标注之后，它写得慢一点，但你能查。查起来也不费劲，一行一行对，跟你自己算的对。

还有一件事值得知道：它不记事。

你上周跟它讲过的口径，这周新开一个对话，它不记得。人会记住“我们公司一直是这么算的”，模型不会。它每一次都是从零开始，靠你给的东西推理。

所以那份纸不只是给某一轮对话用的。它也是唯一能让下一个接手的人少问一遍的东西。

────────────────────────

写到一半就写不下去

方法说到这儿就完了。剩下的不是技术问题。

做数据分析，真正花时间的不是算，是确认两个人在说同一件事。

两份报表差了两个点，多数时候不是谁算错了，是“销售额”在两边指的不是一个东西：一边含税一边不含，一边算退款一边不算，一边按签单日一边按到账日。

这些差别平时没人写下来，因为它们“大家都懂”。等到要交给机器算，才发现“大家都懂”是懂在不同地方。

写本体，说到底就是把这些懂在不同地方的规矩，钉到一张纸上。

反过来也有个省事的用法：让 AI 帮你起草这份纸。把表头和十来行样本给它，让它猜每个字段的意思，猜完你再改。它猜得比你写初稿快，改起来也比你从零写轻松。但改这一步跑不掉，因为只有你知道哪条规矩是真的。

────────────────────────

从哪张表开始

别从最复杂的开始，挑一个你们每个月都要争一次的指标。

写到什么程度算够？写到一个刚入职的人拿着这张纸能照着算，且算出来的数，你们几个都认。

大概率写不完。写到一半就写不下去。写不下去的地方，通常是这么一句：

这个我们一直没定过。

────────────────────────

雄哥批示：凡交办数据之事，先递说明一纸，写明一行何指、各列何义、各值何取、各数何由；口径未落纸者，不得径行动笔；算毕须令其自陈所用之列与所排之行，陈不出者，其数不录。此事不费一钱，不添一人。各部门接文即办，先将本家那张纸写出来；写不出来之处，正是当议之处，据实报来。

────────────────────────

参考文献

1. Gruber, T. R.（1993）：本体的经典定义“a formal, explicit specification of a shared conceptualization”。本文只用了这句定义，原文（《Knowledge Acquisition》5(2)）未取得全文，读的是转述版本，转述出处见 TAS³ 项目交付文档（https://cordis.europa.eu/docs/projects/cnect/7/216287/080/deliverables/001-001TAS3D02p2CommonUpperOntologiesV3p22.pdf）。

2. OWL 2 Web Ontology Language Document Overview (Second Edition)（https://www.w3.org/TR/owl2-overview/）：W3C 推荐标准，本体在工程里可写可查的载体。本文只作名词解释，未涉及语法细节。

3. Protégé（https://protege.stanford.edu/）：斯坦福的开源本体编辑器。本文未使用，只用来对照“正式的本体工程长什么样”。

口径：本文没有做任何实测。 文中的销售表、订单号、行数变化、客单价算式，全是为说明问题编的示例，不对应任何真实公司的数据，也不构成对某一款模型表现的判断。文中关于模型行为的描述（会猜、不主动说不知道、不记事）是这类工具的通行性质，读者可以在自己的表上验证，本文未做验证。本期不给可直接套用的结果数字，只给一份可以照着写的表格结构。