上周六，一条来自 Tesla AI 一线工程师的帖子在 X 平台上炸开了锅。550 条回复、1500 次转发、1 万点赞、1700 万曝光。马斯克回了两个字：「So true。」
发帖人 Yun-Ta Tsai，职位是 Sr. Staff Engineer @ Tesla AI。帖子的核心是一个反直觉的数字：在真实的 ML 项目中，模型训练只占全部工作量的 2%。
剩下 98% 的构成是：50% 评估、40% 数据清洗、8% 集成。
外面铺天盖地的头条都围绕着哪个模型更强、哪种架构更优、训练算力如何飙升。现在，一个来自特斯拉 AI 一线的人告诉你：整个产业花了 99% 的注意力在那 2% 上。
那剩下的 98% 究竟是什么？拉出来拆开看，你就会理解为什么 Yun-Ta Tsai 紧接着说了一句话：「因此，我没有一天不在思考本体论（ontology）。」
50% 评估：不是尝咸淡，是质检流水线
普通人理解的"模型评估"，就是在测试集上跑一个准确率，最多再画一张混淆矩阵。收工。
在真实的 ML 生产系统中，评估不是一道菜出锅前尝一口咸淡。它是持续运转的质检流水线，占整个工程团队一半的工作量。
因为现代 ML 系统的评估早就不回答"这个模型好不好"这种单一问题了。它是一组嵌套的拷问：
离线评估：模型在历史数据上的表现。这是第一道门。在线评估：模型在真实流量中的表现。用户点击了吗？留存提升了吗？核心指标有没有被某个边缘场景拉低？切片评估：模型在每一类用户群、每一个地理区域、每一种边缘场景中表现如何？平均准确率 90% 可能隐藏着某个关键切片只有 30% 的事实。公平性评估：模型是否对不同群体产生了歧视性输出？在监管日趋严格的环境下，这不是 PR 问题，是合规问题。鲁棒性评估：模型在对抗样本、数据偏移、极端输入下会如何表现？成本评估：模型推理延迟、算力消耗、存储开销是否在产品可接受范围内？每一个评估维度都需要独立的评价数据集、评价指标、评价流水线和持续运行的监测告警。在 Google、Tesla 这类公司，评估工程师是一个明确的细分岗位，其职级和训练工程师平级。
Yun-Ta Tsai 把评估放在 50% 的位置，不是随口一说。在 Tesla AI，任何模型的发布都必须通过层层评估关卡。一个 FSD（全自动驾驶）模型要经过数百项不同的评估指标——从车道保持的横向偏差到行人识别的反应时间。每个指标背后都是代码、数据、可视化仪表盘和持续监控。
评估不是在"完成训练"之后做的一个小步骤。它是驱动整个迭代循环的引擎——没有评估，你连"模型变好了还是变差了"都无从判断，后面的所有工作都是在黑暗中摸索。
40% 数据清洗：原油不进炼油厂
数据清洗占 40%。注意——不是"数据收集"，是"数据清洗"。
这两个概念在 ML 行业外的讨论中几乎从不被区分。对外界来说，数据就是数据，多一点总是好的。真实的情况是：从真实世界采集的原始数据，和可以直接喂进模型的数据，中间隔着一条巨大的工程鸿沟。
你在路上采集的 100 万张行车记录仪照片，可能是这样一批数据：
30% 的照片包含了各种无关杂物：镜头前的虫渍、雨滴、眩光10% 的照片在极端天气下拍摄，标签几乎不可用15% 的照片中目标物体被部分遮挡，标注员自己都不确定在标什么5% 的照片因为传感器故障完全白屏或黑屏剩余的照片中还有相当数量的标注框偏移，因为标注员注意力涣散这些数据如果直接喂给模型训练，会发生一种极其隐蔽但致命的灾难：模型学会的不是识别物体，而是学会容忍噪声。
训练 loss 可能照常下降，准确率可能照常上升——但模型实际上在用统计规律"蒙"出正确的输出。它的内部表征是模糊的，因为没有准确的信息来锚定。
这就是 Yun-Ta Tsai 后半段那句话的物理含义："前两项（评估和数据清洗）设定了学习的噪声下限。模型无法降低噪声下限。"
这句话背后，站着整个信息论大厦。
香农的幽灵：为什么模型不能低于噪声下限
1948 年，克劳德·香农发表了一篇名为《通信的数学理论》的论文。76 年后，它仍然是理解 ML 极限的最锋利工具。
香农-哈特利定理给出了一个简洁到令人窒息的公式：
C = B log₂(1 + S/N)
C 是信道容量——理论上能可靠传输的最大信息速率。B 是带宽。S 是信号功率。N 是噪声功率。
如果你是通信工程师，你把噪声降低 1 分贝，信道容量就实打实地增加。但在 ML 中，模型（接收器）不能改变数据中已经存在的噪声。所有标签错误、标注不一致、边界模糊——这些都是 N。所有正确标注、信号特征——这些都是 S。模型通过训练学习 S/N 比中蕴含的模式，但模型的表达能力无法超过这个 S/N 比的限制。
用更直观的类比：
想象你在听一场讲座。讲师的声音（S）时不时被背景噪音（N）淹没。你用的助听器（模型架构）再好，也听不到讲师没有说出来的内容。降噪耳机有限——它无法恢复已经被噪音掩盖的信息。
这就是为什么 Yun-Ta Tsai 说"no ML magic matters"。你可以换更大的模型——大模型不会让错误标签变正确。你可以加更多训练数据——如果新数据的噪声同样高，S/N 比不会改善。你可以试试世界上最先进的注意力机制——它也不会把原本就标注错误的数据变成正确的。
香农信息论给所有 ML 模型画了一条绝对的天花板。
这条天花板不在训练阶段，不在推理阶段——它在数据阶段。而数据阶段（评估 + 清洗）恰好就是那 90%。
8% 集成：让模型在真实世界中活下来集成占 8%。一块经常被低估但极其耗时的工作。
训练好一个模型和把它部署到生产环境中，中间差的不是一个 API 封装。现代 ML 系统的集成包括：
数据管线的对接：模型的输入来自实时流还是离线批处理？不同数据源的 schema 不一致怎么办？模型的版本管理与灰度发布：新版模型上线后如何渐进式替代旧版本？出问题如何自动回滚？多模型协作：一个推荐系统背后可能有十几个模型协同工作——召回模型、排序模型、重排序模型、多样性控制模型。任何一个模型的行为变化都会改变整体输出。这就是 Google 那篇经典论文《隐藏的机器学习系统技术债》中说的"纠缠"问题。监控与告警的接入：模型表现下降时如何及时发现？数据分布偏移了怎么办？on-call 机制：模型在凌晨 3 点出问题，谁来处理？在 Tesla 的 FSD 系统中，集成本身就是一个大型工程。模型需要和车辆上几十个传感器、实时操作系统、CAN 总线、地图数据、导航系统一一对接。任何一个接口的变化都要求全链路回归测试。
Google 的研究（Sculley et al., 2015）发现，在真实的 ML 生产系统中，真正的 ML 代码只占整个代码库的 5% 到 10%。剩下的全是管线、配置、监控、测试、数据处理和管理界面。
8% 的集成时间，已经是项目中对它最低的估计了。
2% 训练：最耀眼的冰山尖最后，2% 的训练。
这个数字让人震惊，不是因为训练不重要——而是因为训练是 ML 行业最受关注、最被炒作、资源最集中的环节。
想想看：所有科技媒体的 AI 报道，95% 以上在讨论模型对比。所有的 ML 框架（PyTorch、TensorFlow、JAX）都在优化训练效率。整个算力市场围绕着训练需求定价。投资人的追捧对象永远是"训练出下一个 GPT 的公司"。
但训练只占 2%。
不是因为训练在事实上不重要——没有训练就没有模型。而是因为训练在工程上已经被高度自动化了。写配置文件，调好超参数，选好框架，剩下的就是等待 GPU 跑完。现代 ML 框架让"训练"这个动作变得如此简单，它不再是工程的瓶颈。
真正决定模型质量的，是按下"训练"按钮之前的工作——你把什么数据放进去，你用什么样的标准来评估出来的结果。
这就引出了 Yun-Ta Tsai 帖子中最意味深长的那段话：
"因此，我没有一天不在思考本体论（ontology）。即使已经打好的标签，也必须不断重新审查。"
本体论：那个每天都要思考的东西
Ontology（本体论）——这个词可能是整条帖子中最容易被忽略但最重要的概念。
在 ML 数据标注的语境下，本体论是指你用来组织数据的分类体系。
听起来抽象，用具体的例子：
假设你要训练一个自动驾驶模型来识别"障碍物"。你需要定义什么是"障碍物"——包括静止的车辆吗？包括路面上的纸箱吗？包括从空中飘过的塑料袋吗？包括正在施工的路障吗？包括一只正在过马路的猫吗？
每个标注团队都需要一本"本体手册"来回答这些问题。但问题在于，这本手册永远不完备——因为现实世界有无限多种情况，而你的分类体系只有有限个类别。
更糟的是，这本手册会随时间变化。今天定义为"非障碍物"的东西，明天可能因为一起安全事故被重新分类。你今天把一个塑料袋标注为"忽略"，明天工程师发现模型通过识别"飘动的物体"来辅助判断路况，你就得立刻回去把所有"飘动的物体"重新审查一遍。
这就是 Yun-Ta Tsai 说的"即使旧标签也得不断重新审查"。
在 Google、Tesla 和 OpenAI，有专门的标注本体论团队，负责：
定义分类体系的边界：什么属于某个类别，什么不属于解决类别间的冲突：当一个目标同时符合两个类别的定义时怎么办管理标注一致性的度量：不同标注员对同一张图的标注结论是否一致追踪本体变更对已有标注的影响：当分类体系变化后，哪些旧数据需要重新标注这项工作本质上就是降低数据的噪声下限——通过系统化的本体管理，把标注的不一致性降到最低，提高信号与噪声的比例。
特斯拉的秘密武器：数据引擎
理解了上面这些，你就会明白为什么 Tesla 能够在自动驾驶领域建立领先优势。
不是特斯拉的模型架构比别人强多少——Transformer 大家都在用。不是特斯拉的训练算力有多夸张——各大厂都不缺。
特斯拉的真正壁垒是一个叫做'数据引擎'（Data Engine）的闭环系统。
这个系统的运作逻辑：
采集：数百万辆特斯拉在路上行驶，持续收集各种场景的视频筛选：系统自动识别出"有趣"的场景——模型表现不好的、不常见的、有异常的标注：通过自动标注结合人工审查，为选中的场景生成高质量标签训练：用清洗过的数据训练模型部署：新模型推送回车队评估：每一辆车的实际表现数据回流，发现新的失败模式回到第 1 步这个循环每一步都在执行 Yun-Ta Tsai 说的那四个环节。但最关键的是第 2 和第 3 步——筛选和标注（评估 + 清洗）恰恰是特斯拉投入最大的地方。
马斯克之所以回复"So true"，不是因为他不了解自己的公司——恰恰是因为他太了解了。他知道特斯拉 AI 团队每天在做什么。他知道用于训练 FSD 的代码提交量中，模型结构改动的比例可能连 5% 都不到。他也知道数据清洗和评估管线才是让 FSD 从"能用"进化到"好用"的真正引擎。
启示：对每一个 ML 从业者
Yun-Ta Tsai 的帖子之所以能获得 1700 万曝光，戳中的是每个 ML 从业者日常工作中的一个深层矛盾：
外部世界以为你在做模型架构研究，实际上你的日常是修数据。
如果你是一个 ML 团队的成员，可以立刻审视一下——
过去一个月，团队花在数据清洗和评估上的时间是多少？过去一个月，团队花在模型架构调整上的时间是多少？如果前者远大于后者，这恰恰印证了 2% 的结论——而不是你有什么问题。更大的启示在于，理解"噪声下限"之后，你会意识到不是所有问题都能通过"更好的模型"来解决。数据集中的噪声和错误是一种物理层面的限制，任何能工巧匠都无法用精湛技艺来弥补劣质材料的缺陷。
几个可以落地的方向：
建立多层评估体系：不要只看一个数字，要分层、切分地评估模型表现自动化数据质量监控：对数据漂移、标注漂移设置自动告警投资数据标注工具和流程：给标注员清晰的本体指南和即时反馈用评估结果驱动数据改进：让评估结果直接触发数据清洗流程Yun-Ta Tsai 说他没有一天不思考本体论。对于任何一个想把 ML 做扎实的团队来说，这大概也是他们应该开始认真对待的问题。
当整个行业都在攀比更大的模型、更多的算力时，真正的赢家正在安静地打磨他们的数据飞轮——因为他们知道，在那 2% 的闪光之外的那 98%，才是不可复制的基础设施。
那 2% 是技术。那 98% 是工程。而工程，才是真正的护城河。