AI 工程实践
AI 应用上线前的评估清单
从样本集、失败类型、人工复核和版本记录四个角度，整理 AI 应用上线前应该完成的评估动作。
背景
很多 AI Demo 在演示时效果很好，但一进入真实使用场景就会出现不稳定：有时答非所问，有时格式不对，有时引用了不存在的信息。问题不一定来自模型本身，也可能来自输入清洗、检索、Prompt、工具调用或后处理。
因此上线前的评估不能只问“模型聪不聪明”，而要问“系统在哪些输入下会失败，失败能否被发现，能否被回滚”。
目标
我的评估清单会优先覆盖四件事：
- 固定一组代表真实使用的样本。
- 为每个样本定义期望结果和不可接受结果。
- 记录失败类型，而不是只记录分数。
- 每次修改模型、Prompt 或检索策略后都能复跑。
方法
样本集不需要一开始就很大，但要覆盖核心路径。比如 RAG 问答系统至少要有事实查询、跨段总结、无答案问题、歧义问题和恶意输入。内容生成系统则要覆盖正常输入、信息不足、格式约束、敏感词和超长输入。
评估结果可以先用人工表格记录：输入、输出、是否通过、失败原因、修复动作、版本号。等流程稳定后，再把其中一部分自动化，例如 JSON 格式校验、引用链接存在性检查、关键字段完整性检查。
常见问题
最常见的误区是只看平均分。平均分高不代表系统安全，因为一次严重幻觉、一次错误执行工具、一次泄露内部信息，都可能比十次普通回答更重要。
另一个误区是每次只调 Prompt，不记录变更。Prompt 一旦成为系统行为的一部分，就应该像代码一样有版本、有样本、有回归测试。
结果
引入评估清单后，迭代会慢一点，但判断会稳定很多。团队不再靠“感觉变好了”推进，而是能说明：哪些样本通过了，哪些失败还存在，下一步应该改检索、改 Prompt，还是改产品约束。
复盘
AI 应用的工程化，本质上是把不可控的模型输出放进可观察、可比较、可回滚的流程里。评估不是上线前最后一步，而应该从第一个可用版本就开始积累。
Reusable projects
关联可复用项目
本文已经进入以下工程项目；项目页提供固定版本、运行命令和结果工件。
- 设计依据真实运行已验证
AI 工程技术博客与内容交付平台
本文提出固定样本、失败归因与上线门槛，本项目据此设计文章实验工件和 preflight 检查，但它本身不是项目运行证据。
讨论