AI 工程化最难的 3 个点：90% 的团队都死在了监控上
AI 工程化最难的 3 个点：90% 的团队都死在了监控上
做 AI Agent 的人，几乎都经历过这样一个死亡循环：
Demo 做得非常惊艳，所有人看了都说牛逼。 信心满满地上线，切 1% 的流量。 然后就开始出事：有时候答非所问，有时候胡说八道，有时候卡住不回复，有时候甚至会说一些有安全风险的话。 你想排查问题，但是你根本不知道它为什么会犯这个错。 你想优化，但是你根本不知道优化什么，怎么衡量优化有没有效果。 最后，Demo 永远是 Demo，永远上不了线。
这就是今天 AI 工程化的现状。 所有人都在做 Demo，但是 90% 的 Demo 都死在了上线的路上。
为什么？ 因为 AI 工程化和传统软件工程，根本就是两个完全不同的东西。 传统软件工程里那些成熟的方法论、工具链、最佳实践，放到 AI Agent 身上，几乎全部失效了。
今天我就来聊聊 AI 工程化里，最难的三个核心问题。 尤其是第二个——监控——90% 的团队，都是死在了这一步。
第一个难题：评估——什么是"好"，什么是"不好"？
传统软件工程里，评估是一件非常简单的事情。 对就是对，错就是错。 代码跑通了就是跑通了，报错了就是报错了。 接口返回 200 就是成功，返回 500 就是失败。 没有任何模糊的空间。
但是 AI Agent 不是这样的。 AI Agent 的输出，是概率性的，是模糊的，是主观的。
什么叫"回答得好"？ 什么叫"回答得不好"？ 80 分的回答和 85 分的回答，区别在哪里？ 同样一个回答，有的人觉得很好，有的人觉得很烂，你听谁的？
这就是 AI 工程化的第一个，也是最大的一个难题： 你甚至连"好不好"都定义不清楚。
行业里常用的几种评估方案
现在整个行业，也没有什么完美的解决方案，大家都是摸着石头过河，用的都是组合拳：
方案 1：黄金标准集
找几百个、几千个最有代表性的测试用例，人工标注好标准答案。 每次改完模型、改完提示词、改完系统，就在这个标准集上跑一遍，看正确率升了还是降了。
优点：客观、可量化、可回归。 缺点：用例的质量和覆盖率决定了一切。而且非常昂贵，标注成本很高，维护成本也很高。 而且最烦人的是：你会发现，标准集上的分数涨了，用户实际体验反而下降了。这种"过拟合测试集"的事情，简直是家常便饭。
方案 2：模型打分
用一个更强的大模型（比如 GPT-4o）当评委，给 Agent 的输出打分。 你给它一个 rubric（评分标准），它自动给每一条回答打 1-10 分。
优点：成本低，速度快，可以大规模做。 缺点：大模型当评委，本身就不稳定。同一个回答，它这次打 8 分，下次可能打 6 分。而且它的偏好，和真实用户的偏好，很可能是两回事。
方案 3：A/B 测试
线上做 A/B 测试，一半用户用旧版本，一半用新版本。 看关键指标（任务完成率、用户满意度、对话轮数、人工接管率等等）有没有提升。
这是最终的、最可信的评估方法。 但是缺点也很明显：慢，贵，需要有足够的流量。 而且如果你的改动比较小，信号很可能会淹没在噪音里。
现实是什么？
现实就是：大多数团队，到今天为止，都还没有建立起一套可信的、可量化的评估体系。 他们优化的依据，就是几个人拍脑袋觉得"这个版本好像比上个版本好一点"。 这也是为什么，大多数 Agent 项目，永远都在"好像更好了"但是永远不敢全量上线的状态里。
第二个难题：监控——它犯错的时候，甚至不会告诉你它错了
如果说评估是上线前最大的难题，那么监控就是上线后最大的噩梦。 而且我敢说，90% 的团队，都死在了这一步。
传统系统的监控是什么样的？ 错了就会报错，就会打日志，就会抛异常，就会返回 500。 你只要盯着错误率、响应时间、吞吐量这些指标就行了。 出了问题，报警就会响。
AI Agent 的监控是什么样的？ 它不会报错，不会抛异常，不会返回 500。 它只会：
- 一本正经地胡说八道
- 悄悄地给用户一个错误的答案
- 漏掉了关键的信息，但是说得好像很有道理
- 或者，它只是回答得比平时差了一点，你甚至可能都发现不了
最恐怖的是什么？ 它出问题了，但是你不知道它出问题了。 可能过了一个星期，你才从用户的投诉里发现：哦，原来这一周，它一直在胡说八道。
我们到底应该监控什么？
那么，对于 AI Agent，我们到底应该监控什么？ 我总结了四个层级的监控指标，你可以按照这个顺序一步步来搭：
第一层：基础指标
这是最基础的，必须先有的：
- 成功率/失败率：工具调用有没有报错？API 有没有挂？有没有超时？
- 延迟：首 token 时间、单轮响应时间、完整任务耗时
- Token 用量：输入 token、输出 token、每轮平均 token、成本估算
- 重试次数：工具调用失败重试了几次？有没有进入死循环？
这些指标和传统系统的监控差不多，是最容易做的，也是最基础的。 但是这些指标全绿，不代表你的 Agent 表现是好的。 它完全可能所有工具调用都成功了，但是给用户的答案是完全错误的。
第二层：行为指标
这一层开始接触 Agent 的实际行为：
- 工具调用分布：每个工具被调用了多少次？哪个工具的调用率突然上升或者下降了？
- 平均工具调用次数：完成一个任务，平均调用几次工具？这个数字突然变大了，很可能说明它开始绕圈了。
- 回退率：有多少比例的对话，最后转人工了？这个数字突然上升，一定是出问题了。
- 用户主动打断率：有多少用户在它回答到一半的时候，打断了它？这通常意味着它回答得不对路。
这些指标，已经可以帮你发现很多明显的问题了。
第三层：质量指标
这一层开始真正监控回答的质量：
- 自动打分：用另一个大模型，实时地给每一条回答打分。低于某个分数就报警。
- 关键词监控：有没有出现不该出现的词？有没有出现道歉、"我不知道"、"我再想想"这类兜底话术？出现频率突然上升，一定是哪里出问题了。
- 模式异常检测：它是不是开始反复说同一句话？是不是开始进入某个奇怪的循环模式？
- 安全性扫描：有没有出现敏感内容？有没有出现违规建议？
这一层的核心是：你不需要 100% 准确地检测出所有不好的回答。 你只需要在它明显出问题的时候，能够发现，能够报警，就足够了。
第四层：用户反馈闭环
最后，也是最重要的一层：把用户的反馈接入你的监控系统。
- 👍👎 点赞点踩数据：有多少用户给你的回答点了踩？踩率突然上升，立刻报警。
- 用户的追问和纠正：用户说"不对"、"你理解错了"、"不是这样的"，这些都是强烈的负面信号。
- 客服工单：因为 AI 回答错误导致的客诉，有多少？比例是多少？趋势是什么？
用户是最好的监控器。 你做再多的自动监控，都不如真实用户的一个踩，一句"不对"来得准确。
监控的终极目标
很多人以为监控的目标是发现所有的错误。 这是不可能的。 你永远不可能 100% 地检测出 Agent 所有的错误回答。
监控的真正目标是：
当你的 Agent 表现突然变差的时候，你能够在几分钟之内发现，而不是等一个星期之后从用户投诉里知道。
能做到这一点，你就已经超过了 90% 的团队。
第三个难题：调试——黑盒里到底发生了什么？
传统软件出了问题，你可以：
- 打日志
- 打断点
- 单步调试
- 看堆栈
- 打印中间变量
- 复现问题，一步步查
但是 Agent 出了问题，你能做什么？ 你看着它给出来的错误答案，你根本不知道它为什么会给出这个答案。 它的"思考过程"是个黑盒。 你甚至都没办法稳定地复现问题——同样的问题，你再问一遍，它可能这次就答对了。
这就是 AI 工程化的第三个大难题：调试。 传统软件工程积累了几十年的调试方法论，在这里几乎全部失效。
现在行业里是怎么做调试的？
现在大家也都是摸着石头过河，慢慢摸索出来了一些方法：
1. 完整的轨迹回放
这个是最基础，也是最重要的。 把 Agent 每一步的完整状态都记录下来：
- 原始的用户输入
- 当时的系统提示词是什么
- 当时注入的上下文是什么
- 调用了什么工具，入参是什么，返回是什么
- 每一步 LLM 的完整输入和输出
- 中间的思考过程（Chain of Thought）
出了问题之后，你可以完整地回放整个过程，一步一步看，它到底是在哪一步走偏的。 没有这个，你根本谈不上调试。
2. 中间状态可视化
不要只看最终输出。 要把中间的所有状态都可视化出来。 它检索到了哪几段上下文？相似度分数是多少？它选择了调用哪个工具？为什么选择这个工具？它提取的参数对不对？ 把这些东西都清清楚楚地展示出来。
很多时候，你一看就知道问题出在哪了。 哦，原来检索出来的第三段上下文是错的，把它带偏了。 哦，原来它提取参数的时候，把日期搞错了。
3. Prompt 版本管理
很多时候，问题根本不是出在模型上，也不是出在代码上。 就是因为某个人改了一下提示词，加了一句话，改了一个词。 然后整个系统的表现就崩了。
所以，提示词必须像代码一样管理。 版本号、变更记录、diff、回滚、发布流程，一个都不能少。 出了问题，第一个要查的就是：最近有没有改提示词？
4. 确定性测试
虽然 Agent 整体是概率性的，但是我们可以尽可能地引入确定性。 比如，把检索出来的上下文固定下来，把工具的返回固定下来，然后看在同样的输入下，Agent 的表现是不是稳定的。 很多时候，问题根本就不是 LLM 的问题，是上游的检索出了问题，是工具返回的格式变了。
给所有做 AI 工程化的人的 5 个建议
最后，结合我自己踩过的坑，给大家 5 个非常实在的建议。
建议 1：先做监控和评估，再做功能
这是我最最重要的一个建议。
90% 的团队的做法是： 先拼命做功能，加工具，优化体验。 Demo 做得差不多了，想上线了，才想起来：哦，我们好像还没有监控，还没有评估体系。 然后就死在了上线前的最后一步。
正确的顺序应该反过来： 第一天就要开始搭评估框架和监控系统。 哪怕你的 Agent 只有最简单的功能，你也要先把这两个东西搭起来。 不然，等你功能做了一大堆之后，你会发现，你根本不敢上线。
建议 2：不要追求完美
不要追求 100% 地检测出所有错误。 不要追求评估分数 100% 准确。 不要追求能够复现所有的问题。
这是一个全新的领域。 没有完美的解决方案，大家都是摸着石头过河。 能做到 60 分，能发现最明显的问题，能不犯致命的错误，就已经足够好了。
建议 3：多做"坏案例"分析
不要天天盯着那些成功的案例看。 要多花时间看那些失败的案例。 把那些最离谱的错误，那些用户投诉最多的案例，一个个拿出来复盘。 分析它为什么会错？错在了哪一步？是哪一层的问题？我们下次怎么避免类似的错误？
每解决一个"坏案例"模式，你的系统的可靠性就上一个台阶。
建议 4：人工抽检是必须的
不管你的自动监控系统做得有多好，每周抽几十条出来，人工看一遍。 这是必须的。
很多微妙的问题，自动监控是根本发现不了的。 比如，回答整体都对，但是语气不对； 比如，所有事实都对，但是逻辑顺序反了； 比如，它开始变得啰嗦，开始说废话，但是每一句单独拿出来看都没什么问题。
这些问题，只有人能发现。 每周花一个小时抽几十条看看，比你做再多的自动监控都有用。
建议 5：接受不完美
最后，也是最重要的一个心态建议。
你永远不可能做出一个 100% 正确的 Agent。 它永远都会犯错，永远都会有胡说八道的时候，永远都会有让你意想不到的状况。 这是大模型的本质属性决定的，你不可能改变它。
你能做的，不是去追求零错误。 你能做的是：
- 把严重错误的概率降到足够低
- 出了问题能够及时发现，及时止损
- 有快速回滚和修复的能力
- 设计好兜底和降级机制，让它就算犯错，也不会犯致命的错
接受不完美，学会和不确定性共处。 这是每一个 AI 工程师的必修课。
写在最后
AI 工程化，现在还处在非常非常早期的阶段。
我们今天在这个领域遇到的所有问题，所有的痛点，所有的摸索， 其实和五六十年前，软件工程刚诞生的时候，前辈们遇到的问题是一模一样的。
那时候的人也不知道怎么写大型软件，不知道怎么做版本控制，不知道怎么做测试，不知道怎么做监控，不知道怎么调试。 所有的方法论，所有的工具链，所有的最佳实践，都是一代一代的工程师，踩了无数的坑，一点点摸索出来的。
今天，我们站在一个全新的时代的门口。 我们就是这个新时代的先行者。 我们就是那些踩坑的人，那些摸索的人，那些一点点建立新的方法论的人。
这个过程很痛苦，很迷茫，很多时候甚至很让人沮丧。 但是，这也正是这个时代最迷人的地方。
我们正在亲手创造历史。 与所有在这个领域里摸爬滚打的同行们共勉。
作者: itech001 来源: 公众号：AI人工智能时代 网站: https://www.theaiera.cn/ 每日分享最前沿的AI新闻资讯和技术研究。
本文首发于 AI人工智能时代，转载请注明出处。
