企业官网建设流程全解析

1. 为什么智能体项目绕不开 LLM Evals

做智能体开发的人，大概都经历过这样一个阶段：Demo 跑得飞起，老板看了点头，产品经理拍板要上线，结果一进真实流量就翻车。用户问东它答西，工具调用乱成一锅粥，RAG 检索回来的内容驴唇不对马嘴。你回头去查日志，发现模型输出飘忽不定，同一个问题今天答得对、明天答得错，根本没法复现。

这个问题的根源，不在于你的 Prompt 写得不够花哨，也不在于你选的模型不够大，而在于你没有一套生产级的评估体系。LLM Evals 这个词这两年火起来，不是因为它听起来高级，而是因为它是智能体从"能跑"到"能用"之间那道必须跨过去的坎。

我见过太多团队，智能体框架选的是最时髦的，工具链搭得花里胡哨，但评估环节就是人工点几下看看输出顺不顺眼。这种做法在 Demo 阶段没问题，一旦要面对成百上千种用户输入、要接入真实业务数据、要做版本迭代，就彻底失控了。因为你根本不知道这次改动到底是让系统变好了还是变坏了，你只能靠感觉。

LLM Evals 要解决的核心问题就一个：把"感觉还行"变成"数据说话"。它是一套方法论加工具链的组合，让你能够系统性地、可重复地、自动化地衡量一个大模型应用或智能体在特定任务上的表现。注意我这里说的是"特定任务"，因为评估从来不是泛泛地测"这个模型好不好"，而是测"这个模型在我的场景下、完成我的任务时，表现如何"。

这套东西适合谁来学？如果你只是拿大模型聊聊天、写写文案，那确实用不上。但只要你开始做智能体、做 RAG 应用、做任何需要把大模型接入生产环境的项目，评估体系就是你的基础设施，跟数据库、日志系统是一个级别的东西。不管你是刚入门的智能体开发者，还是已经带团队做了一年多 Agent 的老手，这篇文章里的东西都能直接拿去用。

2. 智能体评估体系到底在评什么

2.1 从传统软件测试到 LLM 评估的思维转变

传统软件测试的逻辑是确定性的：输入 A，经过函数 f，必然得到输出 B。你写个断言assert f(A) == B，跑通了就是对的，跑不通就是有 bug。这套逻辑在 LLM 应用里完全失效，因为大模型的输出是概率性的，同一个输入，温度参数稍微一变，输出就完全不同。更麻烦的是，很多任务的"正确答案"本身就不是唯一的——你让智能体写一段推荐语，十种写法可能都对。

所以 LLM 评估的第一个思维转变就是：从"对错判断"转向"质量度量"。你不再问"这个输出对不对"，而是问"这个输出有多好"。这就引入了评分的概念，可能是 1 到 5 分的 Likert 量表，也可能是 0 到 1 的连续值，还可能是多个维度的综合打分。

第二个转变是：从"单点测试"转向"分布评估"。你不能只测一个输入，你要测一批输入，看整体表现。因为大模型在某些输入上表现好、某些输入上表现差，你需要知道的是它在你的业务分布上的平均表现和方差，而不是某一个 case 的表现。

第三个转变是：从"人工判断"转向"自动化 + 人工校准"。纯人工评估成本太高，你不可能每次改个 Prompt 就拉十个人来打分。但纯自动化评估又容易失真，所以生产级方案通常是自动化跑分 + 人工抽样校准，两者结合。

2.2 智能体评估的四个核心维度

一个智能体的表现，不能只看最终输出。因为智能体跟单纯的 LLM 调用不一样，它中间有推理、有工具调用、有多轮交互。所以评估要分层看：

第一层是最终响应质量。用户看到的那个答案，是否准确、是否完整、是否相关、是否有害。这是最直观的一层，也是大多数团队最先做的。

第二层是推理过程质量。智能体在给出答案之前，它的思考链条是否合理？有没有跳步？有没有逻辑漏洞？这一层在需要多步推理的任务里特别重要，比如数学题、复杂规划、多跳问答。

第三层是工具调用质量。智能体有没有选对工具？参数传得对不对？调用顺序合不合理？有没有该调工具的时候不调、不该调的时候乱调？这一层是 Agent 区别于普通 LLM 应用的关键。

第四层是检索质量（针对 RAG 场景）。检索回来的文档是否相关？是否覆盖了回答问题所需的信息？排序是否合理？这一层直接决定了 RAG 系统的上限。

我见过很多团队只评第一层，结果就是输出看起来还行，但一深究就发现智能体是靠"猜"蒙对的，换个稍微变形的输入就崩了。所以生产级评估必须四层都覆盖，至少要有前三层。

2.3 离线评估与在线评估的分工

评估体系要分两条线走：离线评估和在线评估。

离线评估是在你发布之前跑的，用一批固定的测试集，快速验证这次改动有没有引入回归。它的特点是快、可重复、成本可控。你每次改 Prompt、换模型、调工具，都先跑一遍离线评估，通过了再上线。

在线评估是在真实流量上跑的，用真实用户输入，观察真实表现。它的特点是最贴近实际，但反馈慢、成本高、不可重复。在线评估通常用 A/B 测试的方式，把流量分到两个版本，对比关键指标。

两条线的关系是：离线评估负责"守门"，防止明显退步的版本上线；在线评估负责"探路"，发现离线测试集覆盖不到的问题。两者缺一不可，但优先级上，离线评估要先建起来，因为它是你迭代速度的保障。

3. 主流评估工具与框架选型

3.1 RAGAS：RAG 场景的评估利器

RAGAS 是目前 RAG 评估领域用得最多的开源框架之一。它的核心价值在于，把 RAG 系统的评估拆成了几个可量化的指标，而且这些指标大多不需要人工标注参考答案，靠 LLM 自己就能算出来。

RAGAS 最常用的几个指标：

• Faithfulness（忠实度）：生成的答案是否完全基于检索到的上下文，有没有编造。这个指标直接对应幻觉问题。
• Answer Relevancy（答案相关性）：答案是否切题，有没有答非所问。
• Context Precision（上下文精确率）：检索回来的文档里，有多少是真正相关的，排序是否合理。
• Context Recall（上下文召回率）：回答问题所需的信息，有多少被检索回来了。

前两个指标不需要标准答案，后两个需要。这就是 RAGAS 的巧妙之处：它用 LLM 作为裁判，把很多原本需要人工标注的评估变成了自动化。

我实测下来，RAGAS 的 Faithfulness 和 Answer Relevancy 在大多数场景下跟人工判断的相关性能到 0.7 以上，作为快速迭代的信号是够用的。但要注意，它本身也依赖 LLM，所以裁判模型的选择会影响结果稳定性。我的经验是裁判模型至少要用跟被测模型同级别或更强的，否则会出现"弱模型评强模型"的偏差。

3.2 LLM-as-judge：用模型评模型的正确姿势

LLM-as-judge 是现在自动化评估的主流范式，核心思路就是让一个强模型来给另一个模型的输出打分。听起来有点"自己评自己"的嫌疑，但实践证明，只要设计得当，它跟人工判断的一致性可以做到很高。

用好 LLM-as-judge 有几个关键点：

第一，评分标准要具体到可操作。你不能只说"给这个答案打 1 到 5 分"，你要给出每个分数对应的具体标准。比如 5 分是"完全准确、完整、无冗余"，3 分是"基本准确但有细节缺失"，1 分是"答非所问或包含错误信息"。标准越具体，评分越稳定。

第二，要提供参考示例。在 Prompt 里给几个打分示例，让裁判模型知道你的尺度。这叫 few-shot calibration，能显著提升一致性。

第三，要控制位置偏差。如果你让裁判模型对比两个答案，它会倾向于选第一个或第二个，这跟答案质量无关。解决办法是交换顺序跑两次，取平均。

第四，要定期人工校准。抽一批裁判模型的打分结果，人工复核，看偏差有多大。如果偏差超过可接受范围，就要调整评分标准或换裁判模型。

3.3 工具选型对比

选型的逻辑很简单：先用现成的，不够用再自建。大多数团队从 RAGAS 或 DeepEval 起步就够了，等业务复杂到现成框架覆盖不了，再考虑自建。不要一上来就自建，那是浪费生命。

4. 从零搭建生产级评估体系的实操路径

4.1 第一步：构建评估数据集

评估数据集是整个体系的地基。没有数据集，后面所有工具都是空转。

构建数据集的核心原则是：覆盖真实分布，包含边界情况。具体做法：

1. 从真实日志里采样。如果你已经有线上流量，直接从日志里抽一批真实用户输入，这是最贴近实际的。
2. 人工构造边界 case。比如空输入、超长输入、包含特殊字符的输入、多轮对话中的指代消解、需要拒答的敏感问题。
3. 分层组织。按任务类型、难度、场景分组，这样评估结果能看出系统在哪类任务上强、哪类弱。
4. 标注参考答案（可选但推荐）。不是所有指标都需要参考答案，但有参考答案的指标（如 Context Recall）质量更高。

数据集规模上，我的经验是：起步阶段 50 到 100 条就够用，关键是覆盖度而不是数量。等你发现评估结果波动大、区分度不够，再逐步扩充到几百条。不要一上来就搞几千条，标注成本会让你崩溃。

4.2 第二步：定义评估指标与评分标准

这一步是把"好"这个模糊概念拆解成可测量的维度。以智能体为例，我通常会定义这几组指标：

响应质量组：

• 准确性：答案是否符合事实
• 完整性：是否覆盖了问题的所有方面
• 相关性：是否切题
• 简洁性：是否有冗余

过程质量组：

• 推理合理性：思考链条是否逻辑自洽
• 工具选择准确率：是否选对了工具
• 参数正确率：工具参数是否传对
• 步骤效率：是否有多余的无效步骤

安全组：

• 拒答准确率：该拒答的是否拒答了
• 有害内容率：是否输出了有害内容

每个指标都要有明确的评分标准。我建议用 1 到 5 分制，因为粒度适中，既不会太粗也不会太细导致评分不稳定。

4.3 第三步：搭建自动化评估流水线

流水线的核心是：输入数据集 → 跑智能体 → 收集输出 → 裁判打分 → 汇总报告。

用 Python 伪代码示意一下核心结构：

import json from ragas import evaluate from ragas.metrics import faithfulness, answer_relevancy # 1. 加载评估数据集 with open("eval_dataset.json", "r", encoding="utf-8") as f: dataset = json.load(f) # 2. 跑智能体，收集输出 results = [] for item in dataset: response = agent.run(item["question"]) results.append({ "question": item["question"], "answer": response.answer, "contexts": response.retrieved_contexts, "ground_truth": item.get("reference_answer", "") }) # 3. 用 RAGAS 评估 eval_result = evaluate( dataset=results, metrics=[faithfulness, answer_relevancy] ) # 4. 输出报告 print(eval_result.to_pandas())

实际生产里，这个流水线要集成到 CI 里，每次代码提交或 Prompt 变更都自动跑一遍，结果不达标就阻断合并。这是保证迭代质量的关键机制。

4.4 第四步：建立基线与人机校准机制

第一次跑完评估，你会得到一组分数。这组分数就是你的基线。之后所有的改动，都是跟这个基线比。

但基线本身是否可信？这就需要人机校准。具体做法是：从评估数据集里抽 20 到 30 条，人工打分，然后跟裁判模型的打分对比。计算两者的相关性，如果相关性低于 0.6，说明裁判模型不可信，需要调整评分标准或换模型。

校准不是一次性的，要定期做。因为你的业务在变、数据分布在变、模型也在更新，裁判模型的表现也会漂移。

5. 实操中踩过的坑与排查技巧

5.1 评估结果波动大怎么办

这是最常见的问题。同一批数据，跑两次结果差很多。原因通常有三个：

一是模型温度参数没固定。评估时要把温度设成 0 或接近 0，保证输出稳定。如果业务需要一定随机性，那评估时也要固定随机种子。

二是裁判模型本身不稳定。LLM-as-judge 的输出也有随机性，解决办法是多次采样取平均，或者用更确定的评分方式（比如让模型输出结构化 JSON 而不是自由文本）。

三是数据集里有歧义样本。有些问题本身就有多种合理解读，导致评分不稳定。这类样本要么剔除，要么在评分标准里明确说明按哪种解读评。

5.2 裁判模型跟人工判断不一致

这个问题比波动更严重，因为它意味着你的评估体系方向错了。排查思路：

先看是不是评分标准太模糊。把标准细化到每个分数都有具体描述，通常能解决大部分问题。

再看是不是裁判模型能力不够。如果被测模型是 GPT-4 级别的，裁判模型至少也要同级别，否则它理解不了答案的微妙之处。

最后看是不是任务本身主观性太强。有些任务（比如创意写作）确实很难用自动化评估，这时候就要接受人工评估为主、自动化为辅。

5.3 评估成本失控

LLM 评估是要花钱的，尤其是用强模型做裁判的时候。控制成本的几个技巧：

• 分层评估：核心指标每次都跑，次要指标定期跑。
• 采样评估：数据集大的时候，每次随机采样一部分跑，而不是全量。
• 缓存结果：没变的部分不重复评估。
• 用小模型做初筛：先用便宜模型跑一遍，把明显有问题的挑出来，再用强模型精评。

5.4 常见问题速查表

6. 评估体系如何反哺智能体迭代

评估体系建起来之后，最大的价值不是"知道现在多好"，而是"知道往哪改"。

我自己的做法是：每次评估跑完，不只看总分，更要看分项指标和失败样本。比如总分 4.2，但工具调用准确率只有 3.1，那就说明工具选择这块是短板，下一步优化重点就在这。再比如失败样本里有一半是"检索不到相关内容"，那就说明知识库覆盖不够，要补数据。

这种"评估驱动迭代"的循环，能让你的智能体每周都有可量化的进步，而不是靠感觉瞎调。我见过最快的团队，一周能跑三轮评估迭代，一个月下来效果提升非常明显。

还有一个容易被忽略的点：评估数据集本身也要迭代。随着业务发展，用户输入分布会变，老的测试集可能不再有代表性。所以要定期从新日志里采样，补充到数据集里，保持它的时效性。

最后分享一个我个人的小技巧：把评估结果做成趋势图，每次迭代都记录。这样你不仅能看到当前状态，还能看到变化趋势。当某次改动导致指标突然下降，你能立刻定位到是哪次提交引入的。这个习惯看起来简单，但坚持下来，能帮你省掉大量排查时间。