点击蓝字
关注我们
为什么需要评估？
AI 大模型的输出具有不确定性和主观性。同样的 prompt，在不同模型上可能得到完全不同的响应。
此外，响应的质量和结果还会受到用户意图、上下文等因素的影响。传统的软件测试方法很难有效应对这种情况。
因此，我们需要制定一些指标来评估大模型的返回结果，比如：答案在事实上是否正确？是否与问题相关？是否遵循了指令？是否安全且合适？
什么是评估框架？
简单来说，大模型应用的评估框架就是为这种“非确定性”的 AI 应用，建立的一套“确定性”的评价体系。一个完整的、可落地的评估框架，通常由以下三部分构成：
1. 测试数据集（Test Dataset）
这是评估的基础——你需要一组具有代表性的测试用例，能够覆盖应用的典型场景和边界情况。就像考试的考题库，其质量甚至直接决定了整个评估结果的有效性。
2. 评估指标体系（Metrics）
这是我们用来衡量结果的标准，主要包含两种类型的指标：一类是“业务场景指标”，例如是否遵循饮食禁忌；另一类是“系统架构指标”，例如检索是否精准、有无产生幻觉。
3. 评分方式（Scorers / Evaluators）
有了考题和评分维度，接下来的问题就是“由谁来评分”以及“如何评分”。根据指标的客观性程度，主要有两种评分策略：
代码裁判（Code-based）
适用场景：格式检查、关键词匹配等完全客观的指标。可直接用 Python 脚本写断言（Assert）来实现，这是最快、成本最低的方式。
示例：
assert "禁忌" in response # 检查响应中是否提及禁忌assert len(response) < 500 # 检查回答长度
AI 裁判（LLM-as-a-Judge）
适用场景：语气是否礼貌、逻辑是否连贯等主观性较强的维度，对于无法量化的质量维度，可以引入大模型来担任评分角色。主流策略有两种：
●直接评估：给评判模型一份结构化的评分标准，让它对输出按维度逐项打分，将抽象的质量转化为可量化、可复用的评分项。
●成对比较：让评判模型同时面对两个输出，选出较优的那个，从而得到相对排名。这种方式能捕捉更细微的质量差异，尤其适合模型版本的 A/B 测试。
构建 LLM 评估框架的四个关键步骤
大模型应用的评估框架本质上是连接业务目标与技术指标的桥梁。它需要将评估的各个步骤或元素（如测试数据集、指标、评估器）串联成一个闭环。以下是构建这样一个框架的基本步骤。
第一步：明确评估目标
一切都要以终为始。在开始制定目标前，不妨先试着回答以下几个问题：
核心业务场景是什么？
普通 FAQ、政策制度问答、客服售后、金融法律合规——这些场景的容错率天差地别。金融法律医疗场景重点看拒答、风险提示和合规性，而普通 FAQ 可能只要 Answer Relevancy 过线就够了。明确你的目标，才知道哪些指标“必须过”、哪些“可以宽松”。
最大的风险敞口在哪里？
如果模型输出错误，会导致什么后果？是引发严重的法律合规危机、导致用户流失，还是仅仅带来些许体验上的降级？风险等级决定了你在哪些指标上的阈值应该设得更严，比如幻觉容忍度要不要从 10% 降到 5%。
指标的阈值是多少？
系统要达到什么水平、完成多少任务，才能上线？目标必须具体、可量化、可验收。不要笼统地说“提升准确率”，而要明确到具体指标，比如：RAG 系统的答案忠实度（Faithfulness）需达到 0.85 以上，上下文相关性（Contextual Relevancy）不低于 0.70。
评估目标确定后，后续的指标选取、数据集构建和阈值设置，都要能对应回这几个问题的答案！
第二步：准备评估数据集
评估离不开数据集，对大模型应用来说，测试数据集尤为关键。测试数据本质上就是测试用例，包含真实的用户提问、期望的上下文信息，以及理想的标准答案。
构建数据集通常有以下三种途径：
1. 人工撰写
纯手工编写测试用例。虽然耗时，但可以完全把控测试内容，非常适合覆盖关键边界情况（Edge Cases），或者在项目冷启动、从零开始时使用。建议前期先人工打磨 20–50 个覆盖核心业务场景的高质量测试用例。
2. 真实数据提取
直接抽取用户日志、客服对话或线上交互数据，能真实反映用户行为分布。注意：抽取时务必做好隐私脱敏，并按问题类型、难易程度分层抽样，避免数据倾斜。如果已有一定用户积累，这是性价比最高的方式。
3. 合成数据生成
借助大模型自动生成测试数据，速度快、易于扩展。不过，大模型生成的数据质量可能不太稳定（不然我们为什么还要评估大模型呢），因此必须配合人工抽检，筛掉无意义或高度重复的模式。
在实际项目中，建议采用混合构建策略——以人工用例为起点，合成数据作为补充。例如按 7:3 的比例将工具生成数据与人工标注数据结合，在保证效率的同时降低纯自动生成的质量风险。
第三步：选择评估指标
建议一开始严格控制在 3-5 个核心指标。指标过多不仅会成倍增加评估成本，还会制造数据噪音——分数一多，反而搞不清楚下一步该优化哪里。
具体如何选择指标：
1. 对齐业务目标
不要盲目追求学术榜单，最适合的才是最好的。选择的指标应与业务目标对齐。例如，如果你的应用是智能客服机器人，评估指标就应当能回答“用户是否觉得回答有帮助”这类问题，并与转人工率、工单处理时长等业务数据挂钩。
2. 贴合底层架构
不同架构的“病因”不同。如果你做的是 RAG 系统，必须加上针对检索环节的指标（上下文相关性、精确度和召回率），而不是只盯着大模型。如果只是做简单的单步问答或文本摘要，则剥离检索指标，专注评估生成质量。
3. 接受权衡取舍
评估维度之间天然存在博弈。极度追求“完整性”，输出往往变得冗长，牺牲“简明度”；追求绝对安全和准确，模型可能频繁回答“我不知道”。接受取舍，把对当前业务最重要的指标放在首位。
举例：知识库问答机器人
假设有 AI 应用：用户输入问题，系统从本地食谱知识库中检索相关内容，再由大模型生成回答。
“我想做一道适合健身后吃的高蛋白晚餐，不要西兰花，30 分钟内能搞定的那种。”
第四步：选择评估工具与框架
大语言模型（LLM）与检索增强生成（RAG）的兴起，带来了对评估框架的迫切需求。选用合适的评估框架可以节省时间，并提升大模型应用的可靠性。
目前主流的开源评估框架包括：
DeepEval
最接近传统测试框架。可直接集成 pytest 并接入 CI/CD，在失败时直接阻断合并，体验与普通测试用例几乎一致。内置 50+ 指标，覆盖 RAG、Agent、多轮对话、安全性等场景，同时支持本地模型（如 Ollama）和云端模型作为 Judge。
RAGAS
RAGAS是专门为 RAG 定制。目的是让团队从“凭感觉检查”转向结构化的评估循环，并围绕 RAG 中实际出现的故障模式设计了一套指标。
Promptfoo
偏向提示词工程阶段。核心用途是在同一批测试用例上对比多个 Prompt 版本或多个模型，输出对比报告，判断哪个 Prompt 更优。更适合在开发阶段的实验性调优迭代
LangSmith
LangChain 生态的可观测性平台，评估功能只是其中一环。其优势在于自动采集每次 LLM 调用的 trace、日志和中间状态，调试体验极佳。如果应用已基于 LangChain / LangGraph 构建，使用 LangSmith 几乎是默认选择。
横向对比：
以上是构建 LLM 评估框架的通用路径。接下来，我们以一个 RAG 问答机器人为例，基于 DeepEval 走一遍完整的评估实战流程。
实战-基于DeepEval的评估实战指南
准备工作
在进入实战前，请提前准备好以下：
●本地模型：安装 Ollama，并拉取所需的对话模型与嵌入模型。本文使用 qwen2.5:7b 和 qwen3-embedding:4b，你可按需更换。
●云端大模型：准备好一个大模型平台的 API Key。本文使用阿里百炼的通义千问作为评测模型及数据集生成模型。
●RAG问答机器人：我们基于 LangChain 构建了一个简单的 RAG 问答机器人作为评估对象，具体实现分为两步：先构建本地向量知识库，再搭建问答链路。完整代码见 https://github.com/bridgeshi85/deepeval-poc。
未完待续
后续我们将继续深入解析基于DeepEval的评估四大实战步骤
声明：本文为51Testing软件测试网 TestCraft 用户投稿内容，该用户投稿时已经承诺独立承担涉及知识产权的相关法律责任，并且已经向51Testing承诺此文并无抄袭内容。发布本文的用途仅仅为学习交流，不做任何商用，未经授权请勿转载，否则作者和51Testing有权追究责任。如果您发现本公众号中有涉嫌抄袭的内容，欢迎发送邮件至:editor@51testing.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
