第 1600 篇——写到这里，我对 AI 工程化的认知更新了哪些
第 1600 篇——写到这里，我对 AI 工程化的认知更新了哪些
今天是第 1600 篇。
我没有准备什么特别的仪式感，就是坐在平时写东西的地方，泡了杯茶，打开文档，开始写。
写到 1000 篇的时候，我写了一篇类似的回顾，那时候的感受是"终于到了一个数字"，是一种完成感。
现在写到 1600，感受不一样了，主要是：有些我之前很确定的判断，在这 100 篇的写作过程中，被我自己否定了。
我想把这些被推翻的判断写出来，因为我觉得这比再写一篇"AI 工程最佳实践"更有价值。
认知更新一：我高估了 Agent 在生产环境里的成熟度
一年多以前，我写过好几篇文章，语气相当笃定地说：Agent 是 AI 工程的下一个范式，RAG + Tool Calling + Memory 的组合可以处理绝大多数企业级复杂场景。
我当时有这个判断，不是瞎写的，是基于我在几个项目里做过的实验。实验环境下，Agent 确实表现出了令人印象深刻的能力。
但过去这一年，有好几次让我重新审视这个判断的经历。
一次是一个朋友的公司，他们在 2024 年初很积极地把 Agent 引入了他们的客服系统，设计了一个多 Agent 的协作架构——意图识别 Agent、工单处理 Agent、知识库查询 Agent、解决方案生成 Agent，各司其职，通过消息传递协作。
三个月后，他跟我说：这套系统在 demo 里非常好看，但上线后有几个问题让他们头疼：
- 不确定性的积累：每个 Agent 都有一定的出错概率，多个 Agent 串联后，错误概率叠加，整体系统的可靠性比单步 LLM 调用低很多
- 调试困难：出了问题很难定位是哪个 Agent 的决策导致的，中间步骤的 trace 很长，看起来费力
- 延迟问题：多个 Agent 的串联调用，延迟叠加，用户体验不好
最终他们回退到了一个更简单的方案：单次 LLM 调用 + 结构化的工具调用，同样能完成大部分任务，但稳定性好很多，也容易维护。
另一次是我自己在一个项目里过度使用了 ReAct Agent，最后发现对于 80% 的请求，其实一个固定的 chain（固定步骤的 LLM 链）就能处理，只有 20% 的复杂请求真正需要 Agent 的动态推理能力。而把这 20% 的情况单独处理，比把所有请求都走 Agent，要稳定得多。
我现在的判断： Agent 不是"下一个范式替代所有东西"，而是一种在特定场景下（任务步骤不确定、需要动态工具选择）才应该使用的架构模式。对于步骤可以预定义的场景，固定 Chain 永远比 Agent 更可靠、更便宜、更容易维护。
这个判断，和一年半前我写的文章，有明显的矛盾。我不会去改那些文章，但我想让现在读这篇的人知道：技术判断是可以更新的，被自己的经验推翻是好事，不是坏事。
认知更新二：数据质量的重要性远超我之前的估计
这个认知更新，发生在大概 8 个月前。
那时候我在帮一家做智能制造的公司做 RAG 系统，他们有几千篇内部的设备维护文档和操作手册。我们花了大量时间在架构设计、模型选型、检索策略上，结果上线后效果很差——相关问题的召回率只有 55% 左右。
排查了好几天，最后发现根本原因是：文档质量极差。
这些文档是不同的维修工程师在不同年份写的，没有统一格式，大量的专业术语使用不一致（同一个零部件有三种叫法），很多文档是从 Word 里导出来的，有大量的乱码和格式错误，还有一些是扫描版的 PDF，OCR 之后充满了识别错误。
我们在系统架构上花了 4 周，在数据清洗上花了 6 周。清洗之后重新评估，召回率提到了 83%。
这件事让我重新估计了 AI 应用里数据质量的权重。
我以前会说："数据质量很重要，要注意"。这是正确的话，但太轻描淡写了。
我现在的判断是： 在 RAG 类 AI 应用里，数据工程（清洗、结构化、去重、标准化）的工作量，应该占整个项目的 40%-60%。如果你的数据工程投入比这少很多，效果大概率会让你失望。
更具体地说：在项目启动前，先花 1-2 周做一个"数据质量评估"，对样本数据做抽样分析，量化数据的问题分布，再估算清洗成本。如果数据质量太差，有时候更明智的决策是先不做 AI，而是先把数据治理的基础工作做好。
这听起来不像是 AI 工程师该关心的事，但它是决定项目成败最关键的因素之一。
认知更新三：评估体系的缺失是行业系统性问题，不只是"技术欠缺"
写 1500-1600 这批文章的过程中，我和很多在实际项目里做 AI 应用的工程师聊过。有一个问题我频繁听到：
"我们做的 RAG 系统，不知道效果算好还是不好，也不知道优化了之后到底提升了多少。"
这不是因为这些工程师技术不好。这是 AI 应用工程里一个系统性的问题：缺乏成熟的、被业界广泛接受的评估体系。
软件工程有单元测试、集成测试、性能测试——有清晰的通过/失败标准。AI 应用呢？
评估 RAG 系统的质量，你需要：
- 一套有标准答案的测试问题集（通常要人工构建）
- 能客观量化"召回是否相关"的指标（这本身就很难定义）
- 能评估"生成答案是否准确"的方法（人工评估太贵，自动评估不可靠）
我在 2023 年初开始认真研究这个问题，用过 RAGAS、TruLens 等评估框架，也尝试过用 LLM 做自动评估（LLM-as-Judge）。
结论是：现有的工具都有用，但没有一个是足够好的解决方案。RAGAS 的指标在中文场景下表现不稳定，LLM-as-Judge 的一致性问题（同样的问题重复评估，结果有时候不一样）在生产评估里是大问题。
这个认知更新，让我改变了一个行为：在做 AI 项目之前，我现在会花时间和业务方一起定义"什么叫成功"——不是让 AI 自动评估，而是让业务方参与定义评估标准，基于业务场景设计测试集，用人工评估作为最终标准。
这更笨，也更慢，但比依赖自动评估工具更可靠。
写到 1600 篇，我对这件事本身的理解
我开始写这个公众号，最初的动机很简单：把自己在工作里学到的东西记录下来，顺便练习一下表达。没有想过会写到 1600 篇，也没有想过会有人真的在读。
到了第 1600 篇，我对"写作这件事本身"有了一些更深的理解：
理解一：写作不只是输出，更是思考的工具
很多认知，我在动手写之前以为自己懂了，坐下来写才发现有很多细节没想清楚。写作逼着你把模糊的直觉变成清晰的逻辑，这个过程本身，就是深化理解的过程。
上面说的三个认知更新，有两个是在写文章的过程中才逐渐清晰的——不是先想清楚了再写出来，而是在写的过程中想清楚的。
理解二：持续输出比完美输出更重要
我前几百篇里有一些很烂的文章，逻辑不清楚，或者判断后来被证明是错的。我没有删掉它们，因为它们是真实的记录——记录了我在那个时间点的认知，以及后来认知更新的轨迹。
如果我在写第 500 篇的时候，因为"不够完美"而停下来，我就不会有后来写第 1000 篇时的认知跃升，也不会有现在的认知更新。
完美主义是持续输出的敌人。
理解三：读者是真实的，不是"流量"
这是我最近一年才真正感受到的。随着读者数量增加，我开始收到越来越多的私信——有人问技术问题，有人分享自己的困境，有人说某篇文章帮他做了一个决定。
有一次，一个读者发私信说：他在最低谷的时候，读到了我写的 35 岁职业焦虑那篇文章，觉得"终于有人说了一些真实的判断而不是空洞的安慰"，让他想清楚了自己该做什么。
那条私信我看了好几遍。
这让我重新校准了一件事：写作的目的，不是积累流量，而是在真实的人之间传递有价值的判断。哪怕只有一个人，因为读了我写的东西，做了一个更好的决定，这篇文章就值了。
给正在看这篇文章的你
我不知道你在什么阶段。可能你刚开始转型 AI，正在选技术栈；可能你已经在做 AI 工程，正在遇到具体的问题；可能你在考虑要不要跳槽，要不要转方向，要不要做副业。
我写不了适合所有情况的话，但有一句话是真实的：
你遇到的大多数困惑，不是因为你笨，也不是因为你学得不够，而是因为 AI 工程这个领域本身就在快速变化，所有人都在同时摸索。
这听起来像是安慰，但它是事实。我见过很多顶尖的工程师，在 AI 工程的某些问题上，判断也是错的，也在一边做一边修正。差别不是聪明或笨，是有没有在真实环境里动手，有没有愿意把错误的判断修正过来。
继续动手，继续记录，继续分享你的真实判断——无论多粗糙。
这件事，做了比不做好。
如果可以重来，我会有什么不同
写到这里，顺便回答一个我自己问过自己的问题：如果重新开始，有什么会做得不同？
会更早关注数据工程。 我在 AI 工程上花的早期时间，大部分在研究模型和框架，而很少思考数据质量和数据治理。这个次序其实该反过来：先把数据搞清楚，再做模型和框架的选型。
会对"新框架"保持更高的怀疑度。 AI 领域每个月都有新框架出来，我早期浪费了一些时间在最终没有被广泛采用的框架上。现在的原则是：一个框架发布超过 6 个月、在生产环境里有真实大规模使用案例、社区活跃且 issue 响应及时，才值得深入投入。
会更早建立评估体系。 我在早期的项目里，花了大量时间做开发，但没有花时间定义"什么叫成功"。有了功能，不知道效果好不好，迭代方向也不清晰。现在每个 AI 项目开始时，我会先做两件事：一是和业务方对齐成功指标，二是建立测试集，有了这两样东西再写代码。
会更早开始写作。 写作的复利效应是真实的，但它需要时间积累。如果早三年开始认真写，现在的积累会很不一样。没有遗憾，但有提醒。
这些都不是大道理，是具体的、可以在今天开始做的调整。如果你现在比我晚入场，看到这些，你有机会比我少走一些弯路。
对下一个 100 篇（到 1700 篇）的想法
我没有非常详细的计划，但有几个方向是确定的：
继续跟踪 AI 工程的一线实践，尤其是评估体系、生产化最佳实践、成本控制这几个我认为还不成熟的领域。
继续写转型主题——因为这个群体里仍然有大量真实的需求和困惑，而高质量的实战经验分享并不多。
可能会尝试更多的视频或者互动形式，文字以外的表达方式，对一些话题可能更有效。
还有一件事我最近在想：读这个公众号的人里，有一部分已经在 AI 工程里做得很好了，有一部分还在起步。我想把内容做得对两类人都有价值，这是个挑战，也是值得尝试的事。
不管最终走向哪里，有一点不会变：写真实的东西，不写凑字数的东西。
到 1700 的时候再见。
第 1600 篇，写完了。
茶凉了。去倒杯热的。