在为实际应用设计提示时，一个关键的权衡问题出现了：如何在简洁性和有效性之间取得平衡。在所有因素都相同的情况下，简洁的提示比冗长的提示更快、更便宜且更易于维护。这在延迟和令牌限制非常重要的 Web 环境中尤为相关。不过，如果提示过于简单，模型可能缺乏生成高质量结果所需的背景信息、指令或示例。
借助评估驱动型开发 (EDD)，您可以系统地监控和优化这种权衡。它提供了一个可重复、可测试的流程，让您能够以小而稳妥的步骤改进输出、捕获回归，并随着时间的推移使模型行为与用户和产品预期保持一致。
您可以将其视为测试驱动开发 (TDD)，但针对 AI 的不确定性进行了调整。与确定性单元测试不同，AI 评估无法进行硬编码，因为输出（无论是格式正确的输出还是失败的输出）可能会以意想不到的形式呈现。
EDD 还可以为您的发现工作提供支持。正如编写测试有助于明确功能行为一样，定义评估标准和查看模型输出会迫使您直面模糊不清之处，并逐步为开放式或不熟悉的任务添加更多细节和结构。
了解用户需求、注意语气和清晰度，并愿意将模型视为创意合作伙伴，这些对于制作出能引起用户共鸣的更出色的提示和功能至关重要。定义问题
您可以像 API 合同一样描述问题，包括输入类型、输出格式和任何其他限制。例如：
- 输入类型：博文草稿
- 输出格式：包含 3 个帖子标题的 JSON 数组
- 限制：少于 128 个字符，使用亲切的语气
然后，收集输入示例。为了确保数据多样性，您需要同时包含理想示例和真实的杂乱输入。考虑各种变体和极端情况，例如包含表情符号、嵌套结构和大量代码段的帖子。
初始化基准
撰写您的第一个提示。您可以从零样本开始，并包含：
- 清晰的说明
- 输出格式
- 输入变量的占位符
在评估和优化时，您可以增加复杂性，并与其他组件和高级提示技术搭配使用。首先，我们需要设置一个评估系统，以便将优化工作引导到正确的方向。
创建评估系统
在 TDD 中，您可以在了解需求后立即开始编写测试。使用生成式 AI 时，没有可供测试的确定性输出，因此您需要投入更多精力来精心设计评估循环。
您可能需要多种衡量工具才能有效评估。
定义评估指标
评估指标可以是确定性的。例如，您可以检查模型是否返回有效的 JSON 或输出正确数量的项目。
不过，您的大部分时间都应该用于确定和改进主观或定性指标，例如清晰度、实用性、语气或创意。您可能一开始会设定宽泛的目标，但很快就会遇到更细致的问题。
例如，假设您的标题生成器过度使用某些短语或模式，导致生成的结果重复且机械。在这种情况下，您需要定义新的指标，以鼓励多样化并避免过度使用某些结构或关键字。随着时间的推移，核心指标会趋于稳定，您可以跟踪改进情况。
此流程可受益于了解应用领域中良好状态的专家，他们可以发现细微的故障模式。例如，如果您正在开发写作助理，请与内容制作人或编辑配对，以确保您的评估与他们的世界观保持一致。
选择评委
不同的评估标准需要不同的评估者：
- 基于代码的检查非常适合确定性或基于规则的输出。例如，您可以扫描标题中是否有要避免的字词、检查字符数或验证 JSON 结构。这些动画快速、可重复，非常适合固定输出界面元素，例如按钮或表单字段。
- 人类反馈对于评估更具主观性的质量（包括语气、清晰度或实用性）至关重要。尤其是在早期阶段，自行（或与领域专家一起）检查模型输出有助于快速迭代。不过，这种方法无法很好地扩展。应用发布后，您还可以收集应用内信号（例如星级评分），但这些信号往往会带来干扰，并且缺乏进行精确定位所需的细微差别。
- LLM-as-judge 提供了一种可扩缩的方式来评估主观标准，即使用另一个 AI 模型对输出进行评分或评价。它比人工审核更快，但并非没有缺点：在简单的实现中，它可能会使模型的偏差和知识差距长期存在，甚至加剧这些问题。
优先考虑质量而非数量。在经典机器学习和预测性 AI 中，众包数据注释是一种常见做法。对于生成式 AI，众包注释者通常缺乏领域背景信息。高质量、情境丰富的评估比规模更重要。
评估和优化
您测试和优化提示的速度越快，就越快能获得符合用户期望的结果。您需要养成持续优化的习惯。尝试改进、评估，然后尝试其他方法。
在生产环境中，继续观察和评估用户和 AI 系统的行为。然后，分析这些数据并将其转换为优化步骤。
自动执行评估流水线
为了减少优化工作中的阻力，您需要能够自动执行评估、跟踪更改并将开发与生产联系起来的运营基础设施。这通常称为 LLMOps。虽然有些平台可以帮助实现自动化，但在采用第三方解决方案之前，您应该先设计理想的工作流程。
以下是一些需要考虑的关键组件：
- 版本控制：将提示、评估指标和测试输入存储在版本控制中。将它们视为代码，以确保可重现性和清晰的更改历史记录。
- 自动批量评估：使用工作流（例如 GitHub Actions）针对每次提示更新运行评估，并生成比较报告。
- 提示的 CI/CD：通过自动化检查（例如确定性测试、LLM 作为评判者的得分或安全护栏）来控制部署，并在质量下降时阻止合并。
- 生产日志记录和可观测性：捕获输入、输出、错误、延迟时间和 token 使用情况。监控是否存在漂移、意外模式或故障峰值。
- 反馈收集：收集用户信号（赞、重写、放弃），并将重复出现的问题转化为新的测试用例。
- 实验跟踪：跟踪提示版本、模型配置和评估结果。
通过小规模的针对性更改进行迭代
提示优化通常从改进提示的语言开始。这可能意味着使指令更具体、阐明意图或消除歧义。
注意不要过拟合。一种常见的错误做法是添加过于狭窄的规则来修补模型问题。例如，如果您的标题生成器一直生成以 The Definitive Guide 开头的标题，您可能会很想明确禁止使用此短语。请改为抽象出问题，并调整更高级别的指令。 这可能意味着您强调原创性、多样性或特定的编辑风格，以便模型学习潜在的偏好，而不是单一的例外情况。
另一种途径是尝试更多提示技巧，并将这些技巧结合起来。选择技术时，请问自己：此任务最好通过类比（少样本）、逐步推理（思维链）还是迭代优化（自我反思）来解决？
当您的系统投入生产时，EDD 飞轮不应减速。如果说有什么变化，那就是应该加快。如果您的系统会处理并记录用户输入，那么这些数据将成为您最有价值的洞见来源。在评估套件中添加周期性模式，并不断确定和实施下一个最佳优化步骤。
要点总结
评估驱动型提示开发可为您提供一种结构化方式来应对 AI 的不确定性。通过明确定义问题、构建量身定制的评估系统，以及通过小规模的针对性改进进行迭代，您可以创建一个可稳步改进模型输出的反馈环。
资源
如果您想实现 LLM-as-judge，建议您阅读以下内容：
- 比较 LLM 的总结功能。
- 阅读 Hamel Husain 关于将 LLM 用作评判器的指南。
- 阅读论文：A Survey on LLM-as-a-Judge。
如果您有兴趣进一步改进提示，请详细了解情境感知开发。 最好由机器学习工程师来完成。
检验您的掌握情况
评估驱动型开发的主要目标是什么？
为何使用更大的模型来评估客户端系统？
使用 LLM-as-a-judge 进行评估可能会遇到哪些潜在陷阱？
哪个组件是推荐的自动化评估流水线的一部分？
为评估系统选择评判员时，使用人工反馈的主要限制是什么？