LLM应用程序呈现出一个看似简单的界面：一个文本输入框。但这种极简主义背后运行的是一系列概率性阶段，包括意图分类、文档检索、排序、提示构建、模型推理和安全过滤。对链中任何环节的调整都可能在整个流水线中产生不可预测的连锁反应，将昨天的完美答案变成今天的幻觉。

构建标准化评估流程

在构建Dropbox Dash的过程中，我们认识到在基础模型时代，AI评估——确保准确性和可靠性的结构化测试集——与模型训练同等重要。

最初我们的评估有些非结构化——更像是临时测试而非系统方法。随着不断实验，我们注意到真正的进展来自流程的改进：优化模型检索信息的方式、调整提示、在答案的一致性和多样性之间找到适当平衡。因此我们决定让方法更加严谨。

我们设计并构建了标准化评估流程，将每个实验视为生产代码。我们的规则很简单：以与发布新代码相同的谨慎态度处理每个变更。每个更新在合并前都必须通过测试。换句话说，评估不是我们在最后简单添加的东西，而是融入流程的每一步。

第一步：策划合适的数据集

我们以公开可用数据集开始评估，为检索和问答性能建立基线。对于问答任务，我们使用了Google的Natural Questions、Microsoft Machine Reading Comprehension (MS MARCO)和MuSiQue。每个数据集都带来了不同的价值：Natural Questions测试从超大文档中检索，MS MARCO强调处理单个查询的多个文档命中，MuSiQue用多跳问答挑战模型。

但仅靠公共数据集是不够的。为捕捉现实世界表达的长尾分布，我们通过收集Dropbox员工使用Dash的生产日志构建了内部数据集。我们从中构建了两种评估集：代表性查询数据集通过匿名化和排名顶部内部查询来反映实际用户行为；代表性内容数据集专注于用户最依赖的材料类型：广泛共享的文件、文档和连接的数据源。

第二步：定义可操作的指标和评分标准

在评估对话式AI系统输出时，很容易想到BLEU、ROUGE、METEOR、BERTScore和嵌入余弦相似度等传统指标。这些离线指标计算快速，多年来一直是自然语言处理基准测试的支柱。但当应用于现实任务时，它们很快就显得力不从心。

LLM作为评判者

使用一个LLM来评估另一个可能听起来很递归，但这提供了真正的灵活性。评判模型可以根据基本事实或上下文检查事实正确性，评估每个声明是否被适当引用，强制执行格式和语气要求，并在传统指标忽略的维度上进行扩展。

我们将基于LLM的评估视为软件模块：设计、校准、测试和版本控制。核心是一个可重用模板，每个评估运行接收查询、模型答案、源上下文（可用时），偶尔还有隐藏参考答案。评判提示通过结构化问题集指导过程，如：

• 答案是否直接回应查询？
• 所有事实声明是否得到提供上下文的支持？
• 答案是否清晰、格式良好且语气一致？

评判者回应时包含理由和分数（标量或分类）。例如，评分标准输出可能如下：

1
2
3
4
5
6
7

{
  "factual_accuracy": 4,
  "citation_correctness": 1, 
  "clarity": 5,
  "formatting": 4,
  "explanation": "答案基本准确但引用了上下文中不存在的来源。"
}

我们定义了三类指标，每类在开发流水线中都有明确作用：

第三步：建立评估平台

当我们有了数据集和指标，并经过几轮构建、测试和发布后，很明显需要更多结构。管理分散的工件和实验不可持续。这时我们采用了Braintrust评估平台，它为工作流带来了结构，帮助我们管理数据集、评分器、实验、自动化、追踪和监控。

该平台提供了四个关键能力：中央存储库、实验API、并排比较仪表板和追踪级调试。

第四步：在开发到生产流水线中自动化评估

我们将提示、上下文选择设置和模型选择视为应用程序代码，意味着它们必须通过相同的自动化检查。每个拉取请求触发约150个规范查询，在10分钟内自动评判并返回结果。

按需合成扫描

大型重构或引擎更新可能隐藏细微回归，因此我们运行端到端评估扫描来及早发现它们。这些扫描从黄金数据集开始，可以作为Kubeflow DAG分发，并行运行数百个请求。

实时流量评分

离线评估很关键，但真实用户查询是最终测试。为尽快捕获静默退化，我们持续采样实时生产流量，并使用与离线套件相同的指标和逻辑进行评分。

分层门控

为控制变更在流水线中移动时的风险，我们使用分层门控逐步收紧要求，使评估环境更接近现实使用情况。合并门控对每个变更运行策划的回归测试，阶段门控扩展到更大、更多样化的数据集并应用更严格的阈值，生产门控持续采样真实流量并评分。

第五步：通过持续改进闭环

评估不是一个阶段，而是一个反馈循环。从自身错误中学习的系统比任何路线图允许的进化更快。

每个评分低的查询都包含教训。通过挖掘实时流量中的低分追踪，我们发现了合成数据集经常遗漏的失败模式：稀有文件格式的检索差距、被上下文窗口截断的提示、多语言输入中不一致的语气，或由未明确查询触发的幻觉。

并非每个变更都准备好用于生产门控，特别是风险较高的实验，如新的分块策略、重新排序模型或工具调用方法。为安全探索这些，我们构建了结构化A/B测试场。

LLM流水线是多阶段系统，当答案失败时，猜测成本很高。为加速调试，我们投资于指导工程师直接找到可能原因的演练手册。

最后是文化部分：评估不由单个团队拥有，而是嵌入日常工程实践。每个功能拉取请求都链接到评估运行，每个值班轮次都有仪表板和警报阈值，每个负面反馈都被分类和审查。

经验总结

当我们开始时，原型是用任何可用的评估数据拼接而成的。这对于快速演示很好，但一旦真实用户开始提出真实问题，裂缝就显现出来了。

微小的提示调整导致意外回归。产品经理和工程师争论答案是否足够好，每个人都使用自己的心理记分牌。最糟糕的是？问题溜过预发布环境进入生产环境，因为没有东西捕获它们。

解决方案不是更多的英雄主义，而是结构。我们为数据集创建了中央存储库，并通过相同的Braintrust驱动的评估流程运行每个变更。自动化检查成为我们的第一道防线，在代码合并前捕获缺失引用或损坏的格式。共享仪表板用真实数字取代了走廊辩论。

最大的惊喜之一是，许多回归不是来自交换模型，而是来自编辑提示。指令中的单个单词更改可能严重影响引用准确性或格式质量。正式门控，而不是人眼，成为唯一可靠的安全网。

关键收获是：评估不是开发的附属品。以与生产代码相同的严谨性对待评估堆栈，您将更快、更安全地发布，并大大减少"这是怎么通过的？“时刻。

我们当前的堆栈捕获回归并保持质量稳定，但下一个前沿是使评估变得主动而不仅仅是保护性的。这意味着超越准确性，衡量用户满意度、任务成功率和答案置信度等指标。这意味着构建能够在指标下降时建议修复的自愈流水线，缩短调试循环。还意味着将覆盖范围扩展到文本之外的图像、音频和低资源语言，使评估反映人们的实际工作方式。

目标很简单：不断提高标准，使评估不仅保护产品，而且推动产品前进。通过将评估视为一流学科——锚定在严格的数据集、可操作的指标和自动化门控中——我们可以将概率性LLM转变为可靠的产品。