评估集

为智能体建立一套小规模但覆盖典型场景的评估集，记录每次修改后的通过率变化，评估集应包含正常路径、边界条件和刻意制造的异常。

建议将模型选择隐藏在配置值后面，随功能交付评估集，并设置回退路径：小模型连续两次验证失败时升级到更强模型。

在模型选择时，关键问题是找到在评估集上以可接受准确率通过且运行成本最低的模型，而非最聪明的模型。

评估框架第一版可以是一个表格（输入+预期检查）加一个跑完打印分数并与上次对比的脚本，而不需要平台。

对每个评估样本，应由懂业务的人写下“好答案”的书面定义，这有助于团队对功能目标达成一致。

评估集应刻意包含模糊请求、越界请求、坏输入、对抗性输入和高风险案例等不舒服的案例，以暴露真问题。

评估样本应来自实际工作负载（如真实客服消息、文档、通话录音），而非虚构或干净样本。

评估集（eval set）由三部分组成：真实输入的集合、每个输入“好答案”的书面定义、每次改动后记录的分数。

生产环境是评估集的真正来源，应记录输入、输出、系统决策（在隐私规则内），盯住失败信号，并把每个真实失败变成新评估案例。

AI功能的变化（提示词修改、模型更新、数据变化、成本变化）多数不会出现在diff评审里，每次这类变化都应跑一遍评估集。

对于LLM应用，用于提示工程调试的示例不应与最终评估集重叠。

评估集的建设质量取决于对功能目标的理解程度，且由于 LLM 输出的概率性，评估噪声不可避免，阈值设计应接受一定比例的波动（如允许90%的用例通过）。

建议从最小可用开始：十个能代表“正确”的用例，包括曾经导致故障的输入，并随着现实反馈不断添加新用例。

评估集本身也会漂移，需要定期回顾和更新，否则测试会逐渐失效。

评估集应随Agent能力扩展而同步增长，并将线上失败案例转化为新的评估用例。

生产环境可靠系统需要评估集（20到50个保存的测试用例用于捕捉回归）和带重试护栏的提示词链，而不是依赖vibe checking或巨型Mega-Prompt。

建立评估集的方法是从产品中挑30到50个真实输入，为每个预先写好'什么才算好输出'的判定标准，形成可重复运行的基准。

五十个问题的评估集规模足够覆盖主要查询类型，又能在每次改动后快速重跑（通常几分钟内完成），成本低到可以纳入日常开发循环。

评估集是一组带有标准答案或期望命中文档标记的问题集合，召回率衡量在全部应被检索出的相关文档中系统实际返回的比例，基线是最简方案在同一评估集上的成绩。

本地评估使用了一个包含七组问题与预期答案配对的小型评估集，首轮测试四组通过，三组失败，失败原因包括遗漏已知事实、跳过后续追问、触发速率限制。