LangSmith 自改进评估器：让 LLM 裁判对齐人类偏好
评估是持续改进 LLM 应用的过程，需要一个能衡量应用表现的方法。LLM 应用的输出是自然语言，很难用硬编码规则来评判——简洁性、与参考输出的正确性这类属性，很难写成常规单元测试。
用"LLM-as-a-Judge"（LLM 当裁判）是给 LLM 应用输出打分的流行做法：把生成结果（以及其它信息）交给另一个 LLM，让它评判。这在多个场景中已被证明有用，但它引出一个有趣的问题：你不得不为裁判提示词再搞一轮提示工程。LangSmith 的评估器给出了一个新解法——"自改进"。
LLM-as-a-Judge 是什么
LLM 应用输出很难程序化评估，一大原因是缺乏好指标。做分类、命名实体抽取这类传统 ML 任务有标准指标，但生成式任务（多数应用都属于此类）没有太多好选择。
LLM-as-a-Judge 评估器就是用一个 LLM 给输出打分的评估器，当程序化评估很困难、唯一替代方案是人工标注时尤其有用。LangSmith 团队在实践中观察到的关键用例包括：在线检测 RAG 幻觉、离线检测 RAG 正确性、离线在线检测 LLM 是否生成了有毒或不恰当的答案。
为什么让生成答案的模型再去打分反而有效？两个因素在起作用。第一，评估时 LLM 可能拿到生成时没有的信息——比如判断 RAG 正确性时，把标准答案交给裁判 LLM 让它对比，这是生成时刻没有的信息。第二，判断一个答案是否正确，对 LLM 来说比生成正确答案更容易——任务的"简化"让 LLM-as-a-Judge 变得可行。
但这个过程有麻烦：你仍然要为裁判提示词再做一轮提示工程，这很耗时，还会阻碍团队搭建规范的评估体系。
两篇动机研究
LangSmith 的解法建立在两篇研究之上。第一篇是老概念：语言模型擅长少样本学习（few-shot learning）。给 LLM 展示做对的例子，它就会模仿正确行为。这在客户端 LLM 应用里被广泛采用，尤其适用于难以用指令解释清楚行为、又期望特定输出格式的场景——评估恰好同时满足这两个条件。
第二篇是伯克利 Shreya Shankar 的论文《Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences》，处理的是同一问题。论文提出了不同的解法，但启发了 LangSmith 用反馈收集来程序化对齐 LLM 评估与人类偏好的思路。
LangSmith 的实现：自改进评估
LangSmith 的评估器支持"自改进"：人类对 LLM-as-a-Judge 输出的纠正被存为少样本示例，未来迭代时回填进提示词。净效果是无需提示工程，就能创建准确反映你偏好的 LLM-as-a-Judge 评估器，并随你在 LangSmith 中的原生交互持续适应。
工作流程四步：
搭建 LLM 裁判：在 LangSmith 里配置在线或离线 LLM-as-a-Judge 评估器。初始配置只需极少量设置，因为系统会随时间改进。配置时可指定少样本示例如何格式化进提示词。
让它给出反馈：LLM 评估器对生成输出给出反馈，按上一步裁判中指定的标准评估正确性、相关性等。
原生纠正反馈：用户审查 LLM 的评估结果时，可直接在 LangSmith 界面里修改或纠正反馈。这一步是捕获人类偏好和判断的关键，还可以为纠正附带解释。
纠正存为少样本示例并回填：LangSmith 自动把人类纠正存为少样本示例，形成不断增长的人类对齐评估数据集。下一次评估器运行时，系统把这些示例（和可选的解释）并入裁判 LLM 的提示词，利用语言模型的少样本学习能力，让评估器随时间越来越对齐人类偏好。
这个自改进循环让 LLM-as-a-Judge 基于真实世界反馈适应和优化，消除手动调整提示词和耗时的提示工程。团队可以把精力放在必要时审查和纠正评估结果上，而不是反复打磨裁判提示词。
来源：Aligning LLM-as-a-Judge with Human Preferences - LangChain