快速改进 AI 产品背后不那么光鲜的工作
大多数 AI 团队在产品发布六周后都会遇到同样的瓶颈。最初的演示令人印象深刻，原型按时交付，早期用户也褒奖有加。然而，"足以展示" 和 "足以留住用户" 之间的鸿沟变得无法避免。团队手忙脚乱——调整提示词、更换模型、添加防护措施——但产品却几乎纹丝不动。
那些真正能快速改进的团队有一个反直觉的习惯：他们花在架构上的时间较少，而花在审视数据上的时间更多。不是仪表盘。不是汇总指标。而是对话日志中那些原始的、糟糕的、单独的失败案例。
这是一份实践指南，旨在区分快速发展的 AI 团队和停滞不前的团队。
错误分析是投资回报率最高的活动，而你可能正在忽略它
当 AI 产品表现不佳时，本能反应是寻求解决方案——更好的模型、新的检索策略、提示词中增加更多示例。这种本能几乎总是操之过急的。在你解决正确的问题之前，你需要知道问题到底是什么。
正确的错误分析并不光鲜亮丽。它看起来像是查看 100-200 条对话痕迹，随意记录下出了什么问题，然后将这些笔记归类整理。
存在两种方法，大多数团队默认使用错误的那一种：
自上而下的分析从预设的类别开始——“幻觉”、“不相关回复”、“格式错误”——并要求审阅者为每个失败打标签。它设置快速，能生成整洁的电子表格。但它在发现真正重要的问题方面表现糟糕，因为领域特定的失败很少能映射到你在查看数据之前发明的通用类别上。
自下而上的分析从开放观察开始。你阅读失败案例，用简单的语言写下你注意到的问题，而不强行将其归入预设的类别。只有在积累了大量示例的笔记之后，你才将它们归类。分类体系是从数据中浮现出来的，而不是强加于数据之上的。
这种回报是不对称的。在大多数 AI 产品中，3-4 种失败类别就占所有问题的 60% 或更多。自下而上的分析能可靠地发现这些问题；而自上而下的分析则常常错过它们，因为真正的失败模式一开始就不在你的列表中。目标是达到理论饱和：持续审查直到没有真正新的失败类型出现。对于大多数产品来说，这会在 150-200 个示例左右发生。
数据查看器是基础设施，而非可有可无的附加功能
迭代速度直接受到审查 AI 输出痛苦程度的限制。大多数团队在这里忍受着巨大的摩擦——在日志查看器之间跳转、查询数据库、打开多个标签页来重构一次对话。每多一次点击都是对速度的微小消耗，而这些消耗会累积起来。
对于早期 AI 团队来说，最具杠杆作用的投资通常是一个自定义数据查看器：一个轻量级的内部工具，能在一个地方显示评估单个交互所需的所有信息。
要求最少但具体：
- 无需导航即可查看完整上下文（提示词、检索到的文档、对话历史、模型输出）
- 一键捕获反馈——正确、不正确或标记
- 用于定性笔记的开放文本字段
- 供高级用户使用的键盘快捷键
通用可观察性平台有利于基础设施的可见性。但它们无法替代根据你的数据形态和审阅者所需判断而设计的领域专用工具。一个简单、一天内就能建成的自定义查看器，通常会胜过昂贵的平台，因为它消除了减缓人工审查的摩擦。
检验标准是：如果一位领域专家（而非工程师）能加载该工具，在一小时内审查 50 次对话，并捕获结构化反馈而无需向任何人求助，那么它就是有效的。
领域专家应撰写提示词
AI 产品开发中最顽固的瓶颈之一是假设提示词是工程产物。它们不是。提示词是一种规范——它描述了良好行为的样貌、哪些边缘情况很重要以及要避免哪些失败模式。最了解这些的人是领域专家，而不是工程师。
障碍在于语言。工程师们无意中通过使用非工程师不熟悉的行话来把持这个过程：
- "RAG" 而不是 "确保模型在回答前有正确的上下文"
- "prompt injection" 而不是 "用户试图诱导 AI 忽略其规则"
- "hallucination" 而不是 "模型有时会自信地编造信息"
一旦语言变得易于理解，领域专家就可以直接贡献——而且他们往往能捕捉到工程师永远不会注意到的失败模式，因为他们理解正确行为在特定情境下到底是什么样子。
结构性解决方案是构建一个可以称之为集成提示词环境的东西：它是你实际产品 UI 的一个管理版本，领域专家可以在其中编辑提示词，并立即看到这些更改如何在他们关心的上下文中影响实际输出。不是一个独立的沙盒，也不是 Jupyter notebook。而是实际的界面，在其上有一个编辑层。
这不仅仅是加速迭代。它在了解“良好”表现的人和定义良好行为的机制之间创建了一个反馈循环。
合成数据解决冷启动问题
启动前进行评估的常见反驳是循环论证的：“我们还没有数据，所以我们无法评估。” 这在很大程度上是错误的。
在单个真实用户互动发生之前，就可以生成真实的合成数据。关键在于将其基于实际系统约束——真实的数据库模式、实际的业务规则、特定的监管要求——而不是要求大型语言模型从零开始编造听起来 plausiblen 的对话。
一个生成合成测试数据的有用框架涉及三个维度：
- 能力: 系统应该执行哪些核心任务？(搜索、总结，安排，推荐)
- 场景: 每种能力会出现什么情况？(找到精确匹配，找到多个匹配，未找到任何内容，输入模糊)
- 用户画像: 哪些类型的用户将与系统互动？(高级用户，初次使用者，具有特殊目标的用户)
生成用户输入，而不是预期输出。关键是创建对系统进行压力测试的情境，而不是预先定义可能限制你日后评估真实响应的正确答案。
现代大型语言模型在获得充分基础上下文时，在生成多样化、真实的用户提示方面表现出惊人的有效性。在启动前构建评估基础架构的团队，在启动时就已经具备了测量能力——而这正是迭代速度最关键的时候。
二进制评估优于数值评分
衡量人工智能输出质量的直观方法是评分量表：1-5分或1-10分，分数越高代表越好。评分量表感觉精确。但它们通常并非如此。
数值评分要求评估者对界限的划分做出隐性的、通常不一致的决定。一个人评3分的响应，另一个人可能评4分。随着标准不断演变——在你观察到更多输出时，标准总是会演变——校准历史评分就成了原始测量挑战之上叠加的次要问题。
二进制评估（通过/不通过）消除了这种模糊性。它强制回答一个问题：这个输出是否达到标准？对于临界情况，这更难回答，而这却是一个特点而非缺陷。临界情况揭示了标 准未充分明确的地方，解决这种模糊性使评估系统更加有用。
二进制评估的关键补充是批判——对某项结果通过或未通过的书面解释。这些批判同时服务于两个目的：
- 它们使评估可审计，并有助于人工审查
- 它们充当少量样本，可显著提高基于大型语言模型的评判者在类似输入上的表现
将二元决策与书面批判相结合，并跟踪人机（人类与大型语言模型）一致率（目标是90%以上）的团队，最终会拥有可扩展的评估基础架构。人工精力从标注每个输出转移到校准系统——这是对专家时间更有效的利用。
围绕实验而非功能构建路线图
围绕功能交付构建的人工智能产品路线图存在结构性问题：可行性不确定，这与传统软件通常不同。在你进行实验之前，你不知道某个功能是否可实现。在进行这些实验之前就承诺时间表，意味着你承诺了错误的事情。
替代方案是围绕带有明确决策点的实验来组织路线图。
一项能力不会一步到位地从“想法”变为“发布”。进展是循序渐进的：
- 系统能否做出响应？
- 它能否无错误执行？
- 它能否返回相关结果？
- 它是否符合用户实际想要的内容？
- 它是否最优地解决了问题？
将路线图条目映射到这个漏斗的各个阶段，而不是简单的完成/未完成二元状态，能更准确地反映工作的实际进展。时间限定的探索阶段——两周用于数据 可行性，一个月用于技术可行性，六周用于原型开发——并在每个阶段做出明确的通过/不通过决策，可以防止导致人工智能项目失败的无限期漂移。
文化上的推论是：常态化地讨论哪些行不通。经常分享失败实验的团队比只记录成功的团队学习得更快，因为失败数据包含了成功数据所没有的问题空间信息。
预测改进速度优于几乎任何其他指标的是单位时间内完成的实验数量。更多的实验——被设计、执行、评估并从中学习——意味着更快的改进，这几乎与正在发生的其他事情无关。
共同点
这些实践在技术上都不是什么奇特的。它们不需要最新的模型、最复杂的架构或最大的评估基础架构预算。它们需要的是严格遵守以下原则：观察实际行为，让测量变得容易，让了解“好”的含义的人参与进来，并将实验视为主要的工作单元。
随着时间推移，能够交付显著改进的人工智能产品的团队，不一定更聪明或资源更丰富。他们只是用先查看数据的习惯取代了增加复杂性的本能。
这不那么光鲜亮丽。但它也几乎总是有效的。
