来自 30 多个AI生产实施的评估方法、数据驱动改进和实验技术：
大多数AI团队的关注点都错了。以下是我在咨询工作中经常遇到的情况：
AI 团队：
这是我们的代理架构——这里有 RAG，那里有路由器，我们正在使用这个新框架来……
我
（举起我的手，打断这位热情的技术主管）
你能告诉我你是如何衡量这一切是否真的有效的吗？
……房间里一片寂静
在过去两年里，这样的场景已经上演了几十次。团队投入数周时间构建复杂的人工智能系统，却无法告诉我他们的改变是有益还是有害。
这不足为奇。每周都有新的工具和框架涌现，我们很自然地会关注那些我们能够掌控的、切实可行的事情——使用哪个向量数据库，选择哪个LLM提供商，采用哪个代理框架。但在帮助30多家公司构建AI产品之后，我发现成功的团队几乎根本不谈论工具。相反，他们执着于测量和迭代。
在这篇文章中，我将向你展示这些成功团队的具体运作方式。虽然每个团队的情况各不相同，但你会发现一些模式，无论你的领域或团队规模如何，都适用。首先，让我们来分析一下我看到团队最常犯的一个错误——一个在AI项目开始之前就让其脱轨的错误。
最常见的错误：跳过错误分析
“工具至上”的思维模式是人工智能开发中最常见的错误。团队往往沉迷于架构图、框架和仪表盘，而忽略了真正理解哪些有效、哪些无效的过程。
这就是“工具陷阱”——相信采用正确的工具或框架（在这里指的是通用指标）就能解决你的AI问题。通用指标比无用更糟糕——它们会从两个方面阻碍AI进步：
首先，它们会造成一种虚假的衡量和进展感。团队自以为是数据驱动的，因为他们有仪表盘，但他们追踪的只是一些与实际用户问题无关的虚荣指标。我见过一些团队庆祝他们的“有用性得分”提高了 10%，而实际用户在完成基本任务时却仍然举步维艰。这就像在优化网站的加载时间，而你的结账流程却出了问题——你正在错误地改进。
其次，过多的指标会分散你的注意力。你没有专注于特定用例中最重要的几个指标，而是试图同时优化多个维度。当所有指标都重要时，就没有什么真正重要了。
替代方案？错误分析：这是人工智能开发中最有价值的活动，并且始终是投资回报率最高的活动。让我向你展示在实践中有效的错误分析是什么样的。
错误分析过程
当Nurture Boss创始人 Jacob需要改进公司公寓行业 AI 助手时，他的团队构建了一个简单的查看器来查看 AI 与用户之间的对话。每段对话旁边都有一个空间，用于记录关于故障模式的开放式注释。
在对数十条对话进行注释后，清晰的模式浮现出来。他们的AI在日期处理方面遇到了困难——当用户说“我们安排两周后的旅行吧”之类的话时，66% 的情况都无法处理。
他们没有寻求新的工具，而是：
- 查看实际对话记录
- 对日期处理失败的类型进行分类
- 建立特定的测试来发现这些问题
- 这些指标的衡量改进
自下而上与自上而下的分析
识别错误类型时，您可以采用“自上而下”或“自下而上”的方法。
自上而下的方法首先从“幻觉”或“毒性”等常见指标开始，然后结合特定任务的指标。虽然这种方法很方便，但往往会忽略特定领域的问题。
更有效的自下而上方法迫使你关注实际数据，让指标自然浮现。在Nurture Boss，我们首先使用电子表格，其中每一行代表一次对话。我们对任何不良行为都写下开放式的注释。然后，我们使用法学硕士学位（LLM）构建了常见故障模式的分类法。最后，我们将每一行映射到特定的故障模式标签，并计算每个问题的发生频率。
结果令人震惊——仅三个问题就占了所有问题的 60％ 以上：
- 对话流程问题（缺少背景上下文Context、回答尴尬）
- 交接失败（无法识别何时转移给人工）
- 重新安排问题（日期处理困难）
效果立竿见影。Jacob 的团队发现了太多切实可行的见解，以至于他们花了数周时间才修复了我们已经发现的问题。
这就引出了一个关键问题：如何让团队轻松查看数据？答案引出了我认为任何 AI 团队都能做的最重要的投资……
最重要的人工智能投资：一个简单的数据查看器
我见过最管用的人工智能团队投资，不是那些花里胡哨的仪表盘，而是专门做了一个让所有人都能看清楚AI到底在干嘛的界面。
重点是这个界面必须量身定制——因为每个行业要看的都不一样，现成的工具根本不够用。比如看租房对话时，你得能同时看到完整聊天记录和看房时间；查房子信息时，必须马上调出房源详情和原始合同。就连小细节也特别重要——像把附加信息放哪、设置什么筛选条件——这些直接决定了大家爱不爱用这个工具。
有些团队用通用标签页搞得焦头烂额，为了搞懂一个操作得来回切换五六个系统。这些麻烦事会越积越多：不停切换系统查背景、把报错信息复制到另一个表格里、来回比对不同工具的数据...不仅拖慢工作进度，更会耽误发现关键问题的系统性分析。
用好数据查看工具的团队，改进速度能比其他团队快十倍！
最棒的是：现在用AI辅助开发工具（比如Cursor或Loveable），几个小时就能做出来。花的功夫少，回报却大得惊人！
优秀的数据注释工具应具备以下特点：
- 将所有上下文信息集中显示。用户无需费力搜索不同的系统才能了解发生了什么。
- 让反馈信息易于获取。一键式正确/错误按钮胜过冗长的表格。
- 捕捉开放式反馈。这能让你捕捉到那些不符合预设分类法的细微问题。
- 启用快速筛选和排序功能。团队需要轻松深入了解特定的错误类型。在上面的示例中，Nurture Boss 可以按渠道（语音、文本、聊天）或他们想要快速查看的特定属性进行快速筛选。
- 具有热键，允许用户在数据示例之间导航并进行注释，而无需单击。
使用什么 Web 框架并不重要——只要你熟悉就行。因为我是一名 Python 开发者，所以我目前最喜欢的 Web 框架是FastHTML和MonsterUI，因为它允许我在一个小的 Python 文件中定义后端和前端代码。
关键在于从某个地方开始，即使它很简单。我发现定制的 Web 应用提供了最佳体验，但如果您才刚刚起步，电子表格总比没有好。随着需求的增长，您可以相应地改进您的工具。
这给我们带来了另一个违反直觉的教训：最有能力改进人工智能系统的人往往是对人工智能了解最少的人。
授权领域专家编写提示
我最近与一家教育初创公司合作，与法学硕士（LLM）合作开发一个互动学习平台。他们的产品经理是一位学习设计专家，她会制作详细的PowerPoint演示文稿，解释教学原则和示例对话。她会将这些内容呈现给工程团队，然后工程团队会将她的专业知识转化为提示。
但问题是：提示语就是英文。让学习专家通过 PowerPoint 传达教学原则，然后工程师再将其翻译回英文提示语，这造成了不必要的摩擦。最成功的团队会颠覆这种模式，为领域专家提供工具，让他们直接编写和迭代提示语。
搭建桥梁，而不是守门人
提示练习是一个很好的起点。像 Arize、LangSmith 和 Braintrust 这样的工具可以让团队快速测试不同的提示，输入示例数据集并比较结果。
但许多团队忽略了至关重要的下一步：将提示开发集成到他们的应用程序环境中。大多数 AI 应用程序不仅仅是提示；它们通常涉及从知识库中提取数据的 RAG 系统、协调多个步骤的代理编排以及特定于应用程序的业务逻辑。我合作过的最高效的团队超越了独立的游乐场。他们构建了我所说的集成提示环境——本质上是其实际用户界面的管理员版本，可以公开提示编辑。
与领域专家沟通的技巧
另一个阻碍领域专家有效贡献的障碍是：不必要的术语。我曾与一家教育初创公司合作，那里的工程师、产品经理和学习专家在会议上各说各话。工程师们不停地说：“我们要开发一个能完成 XYZ 任务的代理”，而实际上要做的工作只是写一个提示。这造成了一道人为的障碍——学习专家，也就是真正的领域专家，感觉自己无法做出贡献，因为他们不懂“代理”。
这种现象随处可见。我见过法律科技公司的律师、心理健康初创公司的心理学家，以及医疗保健公司的医生。法学硕士的魅力在于它能让人工智能通过自然语言变得触手可及，但我们常常用技术术语包装一切，从而破坏了这一优势。
以下是如何翻译常见人工智能术语的简单示例：
不说：“我们正在实施 RAG 方法。” 说： “我们要确保模型具有正确的背景来回答问题。” |
这并不意味着要简化流程，而是要精确地描述你实际在做什么。当你说“我们正在构建一个代理”时，你具体在添加什么功能？是函数调用？工具使用？还是仅仅是一个更好的提示？具体化有助于每个人理解实际发生的事情。
这里面有细微的差别。技术术语的存在是有原因的：它能确保与其他技术利益相关者沟通时的准确性。关键在于根据你的受众调整你的语言。
许多团队此时提出的挑战是：“这一切听起来很棒，但如果我们还没有任何数据怎么办？我们刚开始的时候，该如何查看示例或迭代提示？”这就是我们接下来要讨论的内容。
使用合成数据引导你的人工智能是有效的（即使没有用户）
我从团队那里听到的最常见的障碍之一是“我们无法进行适当的评估，因为我们还没有足够的真实用户数据。”这就产生了一个先有鸡还是先有蛋的问题——你需要数据来改进你的人工智能，但你需要一个像样的人工智能来获取生成这些数据的用户。
幸运的是，有一个出奇有效的解决方案：合成数据。LLM 可以生成逼真的测试用例，涵盖 AI 可能遇到的各种场景。
生成真实测试数据的框架
有效合成数据的关键在于选择正确的测试维度。虽然这些维度会根据你的具体需求而有所不同，但我认为考虑以下三大类别会有所帮助：
- 功能：你的AI需要支持哪些能力？
- 场景：它会遇到什么情况？
- 用户角色：谁将会使用它以及如何使用它？
但定义好这些维度只是成功的一半。真正的挑战是确保你的合成数据能够真正触发你想要测试的场景。这需要两件事：
- 具有足够多样性以支持您的场景的测试数据库
- 验证生成的查询是否真正触发预期场景的方法
实用合成数据的关键在于将其建立在实际系统约束之上。对于房地产AI助手而言，这意味着：
- 使用数据库中的真实房源 ID 和地址
- 结合实际的座席时间表和可用时间窗口
- 尊重商业规则，例如展示限制和通知期
- 包括特定市场的详细信息，例如 HOA 要求或当地法规
有时您无法访问生产数据库，尤其是新产品。在这种情况下，可以使用 LLM 生成测试查询和底层测试数据。对于房地产 AI 助手来说，这可能意味着创建具有现实属性的合成房产列表——与市场范围相匹配的价格、包含真实街道名称的有效地址以及适合每种房产类型的便利设施。关键在于将合成数据置于现实世界的约束中，使其可用于测试。如何生成强大的合成数据库的具体细节超出了本文的讨论范围。
使用合成数据的指南
生成合成数据时，请遵循以下关键原则以确保其有效性：
- 数据集多样化：创建涵盖各种特征、场景和人物角色的示例。这种多样性可以帮助你识别一些你可能无法预料到的极端情况和失败模式。
- 生成用户输入，而非输出：使用 LLM 生成真实的用户查询或输入，而非预期的 AI 响应。这可以防止合成数据继承生成模型的偏差或局限性。
- 融入真实的系统约束：将合成数据建立在实际的系统限制和数据基础之上。例如，在测试排班功能时，请使用真实的可用时间段和预订规则。
- 验证场景覆盖率：确保生成的数据能够真正触发您想要测试的场景。原本用于测试“未找到匹配项”的查询，在系统上运行后，实际上应该返回零结果。
- 先简单后复杂：先从简单的测试用例开始，然后再添加细微的差别。这有助于在处理边缘情况之前隔离问题并建立基准。
让我们看看如何在扩展过程中保持对评估系统的信任。
保持对评估的信任至关重要
这是我反复看到的一个模式：团队建立了评估系统，然后逐渐对其失去信心。有时是因为指标与他们在生产中观察到的情况不一致。有时是因为评估变得过于复杂，难以解读。无论哪种情况，结果都是一样的：团队又回到了基于直觉和轶事反馈的决策模式，从而破坏了评估的整个目的。
维护对评估系统的信任与建立它同样重要。以下是最成功的团队应对这一挑战的方法。
理解标准漂移
人工智能评估中最隐蔽的问题之一是“标准漂移”——一种随着观察更多模型输出而演变的现象。Shankar等人在其论文《谁来验证验证者？将 LLM 辅助的 LLM 输出评估与人类偏好相结合》中描述了这种现象：
为了对输出进行评级，人们需要外化并定义他们的评估标准；然而，对输出进行评级的过程有助于他们定义这些标准。
创建值得信赖的评估系统
那么，如何才能构建一个即使标准发生变化也能保持可信的评估体系呢？以下是我发现最有效的方法：
1. 倾向于二元决策，而非任意尺度
二元决策能够提供更复杂的尺度常常掩盖的清晰度。面对1-5的尺度，评估人员常常难以区分3和4，从而引入了不一致和主观性。“有点帮助”和“有帮助”究竟是什么区别？这些边界情况会消耗过多的脑力，并在评估数据中产生干扰。即使企业使用1-5的尺度，他们也不可避免地会问“足够好”的界限应该在哪里，或者应该触发干预，最终迫使他们做出二元决策。
相比之下，二元的“通过/未通过”标准迫使评估者做出清晰的判断：这个输出是否达到了预期目的？这种清晰性也延伸到了进度的衡量上——通过率提升10%立即就有意义，而5分制中0.5分的提升则需要解读。
我发现，那些抵制二元评估的团队这样做往往是因为他们想要捕捉细微差别。但细微差别并没有消失——它只是转移到了伴随评判的定性批评中。批评提供了丰富的背景信息，解释了某件事为什么通过或失败，以及哪些具体方面可以改进，而二元决策则提供了切实可行的清晰信息，明确了是否需要改进。
2. 通过详细的批评来增强二元判断
虽然二元决策能够提供清晰的思路，但最好结合详细的评审意见，以捕捉事情成功或失败的细微差别。这种组合能让你兼得两全其美：清晰、可操作的指标和丰富的情境理解。
例如，在评估正确回答用户问题但包含不必要信息的回复时，好的批评可能是这样的：
AI 成功提供了所要求的市场分析（通过），但其中包含了过多与投资问题无关的社区人口统计信息。这使得回复冗长，并且可能分散注意力。
这些批评除了解释之外，还有多种功能。它们迫使领域专家将隐性知识外化——我见过一些法律专家从“听起来不对劲”的模糊感觉，转变为用引用格式或推理模式清晰地阐明具体问题，以便系统地解决。
当这些评论作为少样本示例纳入评判题时，它们能够提升法学硕士 (LLM) 推理复杂边缘案例的能力。我发现，与没有示例评论的题型相比，这种方法通常能使人工评估和 LLM 评估之间的一致性率提高 15% 到 20%。这些评论还为生成高质量的合成数据提供了绝佳的原始素材，为改进提供了飞轮。
3. 衡量自动评估与人工判断之间的一致性
如果您使用 LLM 来评估输出（这通常是大规模所必需的），那么定期检查这些自动评估与人类判断的一致性至关重要。
鉴于我们过度信任人工智能系统的天性，这一点尤为重要。正如 Shankar 等人在“谁来验证验证者？ ”一文中指出的那样，缺乏验证评估者质量的工具令人担忧。
研究表明，人们倾向于过度依赖和过度信任人工智能系统。例如，在一个备受瞩目的事件中，麻省理工学院的研究人员在arXiv上发布了一篇预印本，声称GPT-4可以在麻省理工学院电子工程与计算机科学（EECS）考试中取得高分。几个小时后，这篇论文就被驳斥……理由是过度依赖GPT-4进行自我评分存在问题。
这种过度信任的问题不仅仅局限于自我评价。研究表明，LLM 可能会受到一些简单因素的影响，例如选项集的顺序，甚至是提示中看似无害的格式更改。如果没有严格的人工验证，这些偏见可能会悄无声息地破坏你的评估体系。
这就造成了一个悖论：你无法完全定义你的评估标准，除非你看过各种各样的输出，但你首先需要有评估这些输出的标准。换句话说，在人工评判LLM输出之前，不可能完全确定评估标准。
我在与 Honeycomb 的 Phillip Carter 合作开发公司查询助手功能时亲身观察到了这一点。在评估 AI 生成数据库查询的能力时，Phillip 注意到了一些有趣的事情：
看到法学硕士如何分解其推理让我意识到我对某些边缘情况的判断并不一致。
审查人工智能输出的过程帮助他更清晰地阐明了自己的评估标准。这并不是计划不周的表现，而是与人工智能系统合作的固有特性，因为人工智能系统会产生各种各样、有时甚至出乎意料的输出。
对评估体系保持信任的团队会拥抱现实，而不是与之对抗。他们将评估标准视为动态文档，随着对问题空间的理解而不断发展。他们也认识到，不同的利益相关者可能持有不同的（有时甚至相互矛盾的）标准，并努力协调这些观点，而不是强加单一标准。
在不失去信任的情况下扩大规模
随着人工智能系统的发展，你不可避免地会面临减少评估人力投入的压力。这正是许多团队容易犯的错误——他们过度、过快地实施自动化，从而失去了支撑评估的人力联系。
最成功的团队采取了更加慎重的方法：
- 从高度的人为参与开始：在早期阶段，让领域专家评估相当大比例的输出。
- 研究一致性模式：与其自动化评估，不如专注于理解自动化评估与人工判断的契合点和差异点。这有助于您识别哪些类型的案例需要更细致的人工关注。
- 使用策略抽样：不是评估每个输出，而是使用统计技术对提供最多信息的输出进行抽样，特别关注一致性最弱的区域。
- 保持定期校准：即使扩大规模，也要定期将自动评估与人工判断进行比较，并利用这些比较来完善您对何时信任自动评估的理解。
现在我们已经介绍了如何保持对评估的信任，让我们来谈谈如何处理人工智能发展路线图的根本转变。
你的人工智能路线图应该考虑实验，而不是功能
如果你从事过软件开发，你对传统的路线图一定不陌生：一份功能列表，其中包含目标交付日期。团队承诺在特定截止日期前交付特定功能，而衡量成功的标准是他们实现这些目标的程度。
这种方法在人工智能方面彻底失败了。
我见过一些团队承诺实现路线图目标，例如“第二季度前推出情绪分析”或“年底前部署基于代理的客户支持”，结果却发现技术根本无法满足他们的质量标准。他们要么交付了质量不达标的产品以赶上最后期限，要么干脆错过最后期限。无论哪种情况，信任都会逐渐消失。
根本问题在于，传统的路线图假设我们知道什么是可能的。对于传统软件来说，这通常是正确的——只要有足够的时间和资源，你就能可靠地构建大多数功能。而对于人工智能，尤其是在前沿领域，你需要不断地测试可行性的边界。
结论
在这篇文章中，我分享了在数十个 AI 实现中观察到的模式。最成功的团队并非拥有最复杂工具或最先进模型的团队，而是掌握测量、迭代和学习基本原理的团队。
核心原则出奇的简单：
- 查看您的数据。没有什么能取代从实际案例中获得的洞察力。误差分析始终能揭示投资回报率最高的改进方法。
- 构建简单的工具，消除摩擦。自定义数据查看器可以轻松检查 AI 输出，比使用通用指标的复杂仪表板提供更多洞察。
- 赋能领域专家。最了解你的领域的人往往能够最有效地改进你的人工智能，无论他们的技术背景如何。
- 策略性地使用合成数据。你无需真实用户即可开始测试和改进你的人工智能。精心生成的合成数据可以引导你的评估过程。
- 保持对评估的信任。二元评判加上详细的评论，既清晰明了，又保留了细微之处。定期进行一致性检查，确保自动化评估的可靠性。
- 围绕实验而非功能构建路线图。致力于实验和学习的节奏，而不是在特定日期前实现特定结果。