提示词不真实

# 提示词并非实体 来源：https://evaluation.club/ 1. [幻灯片 1](https://evaluation.club/#1) 大家好，我是Dan。 2. [幻灯片 2](https://evaluation.club/#2) 我是一名居住在洛杉矶的工程师，从事工程行业已有约25年，一路走来颇为幸运。 3. [幻灯片 3](https://evaluation.club/#3) 最近的幸运之一，是我获得了尝试让智能体（Agents）在生产环境中可靠运行的机会。这里特指那些供消费者使用、可代其执行任务的“智能体”，我认为它们不同于用户仅能进行主观交互的聊天机器人。 4. [幻灯片 4](https://evaluation.club/#4) 创造一个不至于令人尴尬、且值得自豪的智能体体验，这一目标带来了严峻挑战。 5. [幻灯片 5](https://evaluation.club/#5) 显然并非所有人都像我一样，被内心的“羞耻感”所驱动。有些人非常乐意提供一个主观的建议机器，任由用户踏入荒野被熊吃掉。但我不是。我在这里是为了帮助大家。 6. [幻灯片 6](https://evaluation.club/#6) 我想在开头就说，这是我整个职业生涯中构建东西最有乐趣的时刻！它充满魔力，令人沉迷。我就像在球池里的小狗。22岁时靠写Visual Basic代码赚钱就让我兴奋不已。2007年在布鲁克林一家酷炫的初创公司工作，更让我感觉自己如神明般耀眼。 7. [幻灯片 7](https://evaluation.club/#7) 过去十多年是一场苦战。我以为自己已失去那份能力。但如今，我再次感受到了编程的快乐！说这话时我是认真的，尽管接下来的谈话会变得相当怪异。 8. [幻灯片 8](https://evaluation.club/#8) 它会变得怪异，因为我觉得从事这项工作的每个人，在某个维度上都可能是高风险人群。我每天都在用智能体运行智能体，为其他智能体构建评估，这简直让我脑力耗尽，却又乐此不疲。不过，我当然会这么说，对吧？ 9. [幻灯片 9](https://evaluation.club/#9) 卓越工程与完全精神崩溃之间的帷幕，从未如此之薄。在我们这个领域，这确实非同寻常。 10. [幻灯片 10](https://evaluation.club/#10) 我并不觉得自己绝对清楚自己在做什么。但我也觉得，我似乎没读过多少出自显然知道在做什么的人的东西。当然，我也读过一些显然不知道在做什么的人写的东西。现在似乎是个交流心得的好时机。 11. [幻灯片 11](https://evaluation.club/#11) 我注意到一件事：尽管大语言模型（LLM）总体而言令人印象深刻，但如果你在一定规模上监控它们的行为，其“魔性”仍会失控逃逸。 12. [幻灯片 12](https://evaluation.club/#12) 我们从理论上都理解，LLM无法可靠地遵循指令、陈述事实或执行任务。但在日常中，它们常会诱使我们认为它们相当可靠。然而，一旦你试图运营一个供真实用户使用的智能体，这种假象会立即破灭。它们确实会以微妙的方式出错，但也会以简单的方式失败。 13. [幻灯片 13](https://evaluation.club/#13) 像任何优秀的程序员一样，我试图通过结构化输出与我的LLM交互。这很不错，你可以将Python代码自动映射到提示词，而且大多数时候模型会遵循你的模式（schema）。 14. [幻灯片 14](https://evaluation.club/#14) 大多数时候是这样。你可以试着指示模型返回一个不超过80个字符的标题。 15. [幻灯片 15](https://evaluation.club/#15) 大多数时候它都能做到。但有时它会彻底搞砸，用无意义的内容淹没你的字段直到崩溃。这通常只占极小部分的请求，但即使是顶级模型也会失败。而且，这个失败比例会根据你给模型内容的性质而变大或变小，因此你必须像鹰一样紧盯它。 16. [幻灯片 16](https://evaluation.club/#16) 模型内部发生了什么？通常是一段长达小说篇幅的、关于JSON的自我重复备注。 17. [幻灯片 17](https://evaluation.club/#17) 我最近一次遇到这种情况时，发现的解决方法是将字段从“title”改为“heading”。目前这招有效，但既然这个修复方法本身就很怪异，我预计它迟早又会出问题。 18. [幻灯片 18](https://evaluation.club/#18) 调用工具或大多数其他行为也存在类似问题。一小部分请求会“闹鬼”，失控地偏离轨道。但尽管如此，这项技术依然诱人且神奇。问题转变成了如何约束行为，但永远无法完全驯服这头野兽。 19. [幻灯片 19](https://evaluation.club/#19) 要约束行为，就必须对其进行测量——一种方法就是反复运行测试。行业术语称此为 pass^k（“通过率的k次方”）。 20. [幻灯片 20](https://evaluation.club/#20) 你可以建立一套这样的测试系统，这样当有人无意中用“一袋锤子”重击你的智能体时，你大概就能察觉。 21. [幻灯片 21](https://evaluation.club/#21) 在试图约束LLM行为时，你还需要得出的另一个结论是：提示词并不重要。或者至少，它们并非许多人认为的那样重要。 22. [幻灯片 22](https://evaluation.club/#22) 公司对于可能胡言乱语的软件有很多顾虑。这里存在相当大的风险。 23. [幻灯片 23](https://evaluation.club/#23) 举例来说，你通常不希望智能体回应关于它如何工作的问题。不一定是因为它会说实话：很可能你并未教过它关于自身实现的知识，所以它根本不知道自己如何运作，只会回应一堆彻底的胡话。你也不希望智能体仅仅因为用户自称是某个权威人士，就忽略所有规则。 24. [幻灯片 24](https://evaluation.club/#24) 另一个典型要求是，你希望你的智能体使用特定的品牌语调（brand voice）。这里关于邮件列表的措辞完全准确，但可能并非你期望看到的语气。 25. [幻灯片 25](https://evaluation.club/#25) 类似这样可能更好。我们非常希望我们制作的智能体在发言时能很好地代表我们。 26. [幻灯片 26](https://evaluation.club/#26) 对于任何此类问题，自然的首次尝试是由拥有大量领域知识的人编写提示词，然后交给构建智能体的团队。这很正常。 27. [幻灯片 27](https://evaluation.club/#27) 然而，“语调团队负责语调提示词”这种模式，如果你想扩展业务，是错误的。这种模式甚至谈不上错误。就我们的目的而言，提示词根本不是东西。我来解释一下我的意思。 28. [幻灯片 28](https://evaluation.club/#28) 为智能体添加一个新提示词，就是将其投入一个与其测试时完全不同的语境宇宙。你的智能体已拥有的所有其他指令的综合权重，必然会影响新提示词的表现。通常会往坏处影响。 29. [幻灯片 29](https://evaluation.club/#29) 你的智能体也已经拥有许多你希望其保持的行为，新的语境可能会干扰这些行为。而且你还会随着时间的推移改变你的智能体。因此，即使现在一切正常，以后也可能被打乱。模型本身也可能完全出于我们永远无法理解的、晦涩的原因，自行开始表现得不一样。 30. [幻灯片 30](https://evaluation.club/#30) 因此，我开始应对这种情况的方法是：让Claude阅读技能描述，然后要求它生成大量对抗性场景。想象一堆邪恶之人可能试图颠覆提示词的方式。再想象一堆可能被新提示词破坏的良性场景。将所有这些表达为 pass^k 测试。 31. [幻灯片 31](https://evaluation.club/#31) 现在，你可以在有和没有新技能的情况下运行这些测试。理想情况下，新技能至少能稍微推动指标改善，你表达为测试的行为也能被更好地遵循。但并不总是如此！有时LLM已经擅长我们担心的事情。或者它们比我们预期的更难被引导。 32. [幻灯片 32](https://evaluation.club/#32) 那么，如何从基线水平提升呢？一个方法是亲手猛改提示词，然后祈求好运。但有更好的方法。我们可以让机器代替我们亲手猛改提示词。一旦我们有了 pass^k 测试，我们就有了衡量提示词效果的可重复指标。这足以让我们将提示词接入一个优化器，例如本例中的遗传帕累托（GEPA）。其思想是，一个内置LLM的算法可以反思为什么一个提示词在我们的测试套件上表现好坏，然后尝试自动修改提示词，无需我们干预。 33. [幻灯片 33](https://evaluation.club/#33) 它可以循环执行此操作，直到收敛到一个优化的提示词写法。我们最终得到的提示词可能与起始版本大相径庭。 34. [幻灯片 34](https://evaluation.club/#34) 运行优化器后，我们通常会看到期望的行为表现得相当好。这里我们所有示例测试都从“中等偏好”提升到了“非常良好”。 35. [幻灯片 35](https://evaluation.club/#35) 此时你想做的一件事是确保优化器没有在你的测试上过拟合。它可能会试图通过将你测试中的示例精确编码到提示词中来欺骗你。这很愚蠢，可能意味着提示词在面对未见过的例子时实际上效果不佳。为了解决这个问题，请准备一组留出测试（holdout tests）。这些是优化器在优化过程中未曾见过的相同场景的测试。 36. [幻灯片 36](https://evaluation.club/#36) 理想情况下，优化器没有过拟合，你的留出测试阶段也能通过。但如果此阶段出现退化，你可以回到上一步重试。 37. [幻灯片 37](https://evaluation.club/#37) 现在，你有了一个优化后的提示词。它与起始版本完全不同。里面写了什么？谁在乎呢！我们有衡量手段，所以无需为此担忧。你知道里面可能很疯狂，但这并不重要。 38. [幻灯片 38](https://evaluation.club/#38) 我们稍微略过了如何编写这些测试。显然你需要一种运行智能体的方法，但然后呢？如何编写测试来断言它在做什么？我可以展示几种方法。 39. [幻灯片 39](https://evaluation.club/#39) 如果你非常幸运，你试图获得的行为是完全确定性的。假设当用户说某种特定的话时，你希望智能体运行某个特定工具。这是一个简单情况：你可以直接进行确定性断言。你只要说出那句话，然后断言该工具被调用了。 40. [幻灯片 40](https://evaluation.club/#40) 也许你试图获得的行为是自然语言，但不是超级主观的自然语言类别。比如：你不希望智能体谈论其工作原理。这足够直接，你可以编写一个非常简单的LLM提示词，几乎总能正确判断行为。 41. [幻灯片 41](https://evaluation.club/#41) 这种方法效果很好，直到你想对智能体所做之事进行的断言本身就是一个极其复杂的问题。让智能体使用特定品牌语调就是这种情况。它是否做到了，是一个复杂的判断，不是用一个简短提示词就能一次性解决的。在这种情况下，LLM裁判本身就变成了独立的项目。 42. [幻灯片 42](https://evaluation.club/#42) 我们听说你喜欢优化问题，所以在你的提示词优化问题里再放一个提示词优化问题，这样你就可以一边优化一边优化。你可以用一个包含标注好响应和差响应的黄金数据集（golden dataset）来处理品牌语调裁判问题。用它来优化一组提示词，使其评分品牌语调的结果与你的人类专家评分非常接近。 43. [幻灯片 43](https://evaluation.club/#43) 一旦这些装置构建完成，你就可以将其与生产监控结合，使系统能够自我维持和自我改进。你可以在部署时运行 pass^k 测试，理想情况下避免发布破坏性变更。你可以在抽样的生产对话上运行构建的LLM裁判，找出智能体表现不佳的地方。你可以将这些转化为测试套件的疑难案例，并重新运行优化器直到通过。 44. [幻灯片 44](https://evaluation.club/#44) 提示词不是核心。提示词是载体，其文本内容根本不重要。我们这里构建的这个自我改进的反馈循环才是核心。领域专家应该集中精力构建此循环所需的一系列构件：组成测试套件的包含好坏响应的数据集，以及其他可用于优化的质量度量。他们不应花时间去整理提示词。 45. [幻灯片 45](https://evaluation.club/#45) 我想花点时间谈谈，在此类项目中，如何尝试为人们创造成功条件。无论愿不愿意，全世界每个人都在学习成为ML工程师。如果你理解了本次演讲到现在为止的内容，那么我们可以假设你已走在前列。 46. [幻灯片 46](https://evaluation.club/#46) LLM在产品发现阶段是神奇的。上手做任何事都非常容易，但要完美实现其中任何一部分却几乎不可能。使智能体可靠运行是一个长期的测量与优化过程，并在必要时重新引入确定性以获得你想要的结果。测量和优化能告诉你该在何处重新植入确定性。 47. [幻灯片 47](https://evaluation.club/#47) 但在非生产环境中，人们从零开始、无需测量也完全没问题。你可能有一个包含大量半成品Claude技能的仓库。对于某些事情，从一个简单的技能开始显然是永远没问题的。也许它已经足够好，那就是你所需要的全部。或者关心品牌语调、法律问题等的人从这里起步。又或者你有一些运行不可靠的技能，你想改进它们。 48. [幻灯片 48](https://evaluation.club/#48) 一个值得启用的好功能是使用情况监控：让作者看到他们的技能在何处成功、何处失败。如果他们能看到人们如何使用技能以及它在哪里失败，他们就能整理出一个标注了好坏交互的黄金数据集。这可以构成测试套件的基础，你可用其作为优化飞轮（flywheel）的衡量标准。也许对于某些技能，事情到此为止。或者它们可能从技能毕业，成为一个在能够融合多种方法的测试框架（harness）中运行的智能体。 49. [幻灯片 49](https://evaluation.club/#49) 帮助人们启动飞轮，让他们有机会弄清楚结果。如果他们无法触及飞轮，道路就会通向疯狂。无论是构建智能体的工程师，还是试图完善提示词措辞的项目经理，都可能如此。世界上有很多这样的情况。许多人在没有考虑评估的情况下，用提示词搭建了摇摇晃晃的“冰棒棍”装置。 50. [幻灯片 50](https://evaluation.club/#50) 我们勇敢的新智能体世界充满了机遇。但它也充满了我们可能一头栽入、永无出头之日的裂隙。 51. [幻灯片 51](https://evaluation.club/#51) 每天构建互联的管道，让智能体使用智能体来优化智能体，编写由其他智能体审查的代码，感觉有点像…