第 10 章 — 主流评测框架
LLM Primer III: Enhancing Enterprise AI with RAG 章节走读的第十篇。三件套配上了工具箱 — 两脉里八个框架 — 加上对它们其中没人合上的那一块的一次诚实坦白。
这一章为什么存在
第 9 章的三件套讲的是「该度量什么」。它没讲怎么在生产里把这些度量跑起来。度量是概念。它们的实现是给法官的 prompt、给论断的拆分逻辑、给相似度的嵌入选择、给成本的采样策略、仪表盘、告警、人工复核环。这些没有团队从零造。
这一片框架沿一条好认的轴分了家。一侧,指标先行的库 — RAGAS、TruLens、DeepEval — 按一份有记录、可复现的方法把三件套算出来。另一侧,观测平台 — Braintrust、LangSmith、Phoenix、Galileo、Opik — 从生产 trace 开始,把评测当作更大工作流里的一项功能整合进去。在两者之间选,与其说是功能比对,不如说是问「上线后第二天,团队要这套系统帮我做什么」。
10.1 指标先行那一脉 — RAGAS、TruLens、DeepEval
RAGAS 是这块地里最接近三件套参考实现的一个。指标集保守、prompt 有记录、每一次 LLM 调用都显式可见。Faithfulness 的算式是一条两段流水线 — 把回答拆成论断、逐条对照上下文 — 结果里返回中间的论断列表,工程师能指着说「这条断言是它判为不被支撑的」。研究、强监管行业、或者任何要为方法学辩护的团队,RAGAS 是默认。代价是它读起来很学术。它算指标;不出厂仪表盘。
TruLens 坐在指标库和观测平台之间。重心在埋点:框架把应用按函数粒度包起来,把每次检索和每次模型响应都捕获成结构化的 Trace,再在 trace 上跑三件套。三件套指标作为 feedback function 暴露 — 小、可组合,自己写也容易。当团队的评测需求超出标准集、或者工作流更偏向一条一条看失败而不是看聚合仪表盘时,TruLens 合适。
DeepEval 走第三种姿态:把评测当 pytest。用例像测试一样写,跟 pytest 风格的 CLI 跑;失败会拦 PR;指标集三家里最广,bias、毒性、幻觉的检查跟三件套并列。代价是广度伴着不齐的严谨。不读实现照单挑一项指标,容易报出一个名不副实的数字。对的纪律是挑一小撮、读它们的 prompt、对着人工标注标定,其余当灵感。
10.2 观测平台 — Braintrust、LangSmith、Phoenix、Galileo、Opik
指标先行那一脉答的是「我怎么算三件套」。观测平台答的是「我怎么在生产里跑一套 RAG」。它们的出发点是:在可预见的未来,团队都会在写 prompt、对比模型版本、吃 trace、盯仪表盘。评测是一项功能;prompt 版本管理、trace 探索、A/B、告警,跟评测分量相当。
Braintrust 以开发体验领跑 — experiment,一份模型在数据集上行为的版本化记录,UI 里并排打分对比,用起来真是顺手。LangSmith 是已经深扎 LangChain 的团队的自然选择;它默认自己应该坐在应用埋点的正中央,而且这份承诺确实回报以深度。Phoenix,来自 Arize,是开源选项,以嵌入漂移和聚类分析见长 — 那是别家不太张扬的地方 — 对不能把 trace 发往 SaaS 端的团队是可行解。Galileo 是面向企业的那一档,带专有 Correctness 分,有面向强监管行业的本地部署。Opik 是最新入场的,来自 Comet,像 Phoenix 一样开源优先,像 Braintrust 一样精打磨,还多一个把 LLM 与经典 ML 观测统一到一个平台上的好处。
五家之间的选择,功能上不那么重要,组织契合上更重要。LangChain 店伸手够 LangSmith。绿地产品工程团队伸手够 Braintrust。开源优先伸手够 Phoenix。强监管企业伸手够 Galileo。Comet 店伸手够 Opik。五家的指标质量大致相当 — 它们都实现三件套、都用 LLM-as-Judge、都背着第 9 章点过的那些根本限制。差别在工作流,不在度量。
10.3 评测鸿沟,以及三环样式
这里有一件框架之旅刚才一带而过的尴尬事实。上面几乎所有工具评的都是推理层:在检索已经发生之后,模型尊重了块吗、答案贴问题吗、块在话题上吗。没有一家真的告诉你:检索一开始就找对块了吗。检索器的输出是推理层的输入,推理层的指标度量的是输出,不是输入。如果检索一致地漏掉某份重要文档,Faithfulness 仍然高(模型尊重了给它的内容)、Answer Relevance 仍然高(回答合问题的形),用户照样拿到错答案。
这就是评测鸿沟。结构性原因是:推理层评测是 reference-free 的,而严肃的上下文层评测得知道「对的块」是哪些 — 这要么需要标注集,要么需要合成集。绕道办法 — 合成问题生成、needle-in-a-haystack 探针、下游影响代理、查询条件下的检索审计、retrieval-against-self — 都有用,都不完整。诚实的小结:上下文层评测是开放前沿,团队应预期把自己的一些工程直接投到检索质量上。框架帮你跑推理环;检索环大多还得团队自己来。
成熟团队收敛到的样式是三环,不是一环。内环:一个指标先行的库(通常是 RAGAS 或 DeepEval)在固定回归集上每次有意义的改动都跑一次三件套,快、确定性、为了抓回归而生。外环:观测平台负责生产 trace 存储、对采样流量做在线指标、仪表盘、告警 — 为了抓回归集漏掉的漂移。慢环:一小撮人工复核负责把 LLM 法官标定回来、审计被标记的 trace、随着产品演化维护回归集。只有内环的团队上线时漂移就有了。只有外环的团队看见漂移却无法 debug。两环都有却没人复核的团队,会信任一群正在悄悄走偏的法官。三环都必要,框架的价值在于把每一环都做得更便宜。
第 10 章接下去会怎么走
有了第 9 章的三件套和第 10 章的框架,团队就有了度量一套 RAG 系统的家伙:一份词汇、一份关于这份词汇错过什么的诚实账单、还有一小拨把度量变仪表盘的工具。系统会变得可读。可度量只是生产故事的一半。一套被度量但不被维护的系统照样会漂 — 因为文档变、用户变、底下的模型也变。知道质量掉了,跟能把它修回来,不是同一件事。
明天 — 第 11 章:持续更新与流水线优化。CDC 与增量索引、语义缓存与模型分层,以及那条把生产遥测真正变成「越跑越好用的系统」的四段反馈环。
