· 12 min read · LLM · Eval · AI 产品 · 金融 AI
从 0 到 1 构建企业级 LLM Eval 集：一份产品经理的实战笔记
Eval 不是事后验证工具，是 AI 产品 0→1 的发动机。本文沉淀我在企业 AI 场景与个人项目里跑通的一套 Rule-based + LLM-as-Judge + Bad Case 分类的三层 Eval 方法论。
Eval 不是事后验证工具，是 AI 产品 0→1 的发动机。
TL;DR
- 通用 Eval（MMLU / GSM8K / HumanEval）不能验证企业场景的”答得对、答得稳、答得合规”——它们离你的真实业务太远。
- 真正能跑通产品 → 反馈 → 迭代闭环的 Eval 集，至少要分三层：① Rule-based Scoring（机器可判定）② LLM-as-Judge（语义可比对）③ Human-in-loop（关键 case 兜底）。
- Bad Case 分类是闭环的核心：没有清晰的失败模式分类，所有的 Prompt / Routing / RAG 优化都在拍脑袋。
- 这套方法论我先在个人项目 AI Info Tracker（6,087 篇素材自动分档）上验证可行，再带到企业 AI 场景，逻辑可复用。
一、为什么”通用 Eval”在企业里不够用
进入大模型时代第一年，几乎所有 PM 的本能反应是”看看 MMLU 排名”或”跑一遍 GSM8K”。但在企业场景做 AI 产品，你很快会发现一个问题：
这些通用 benchmark 离你的业务有十万八千里。
- 你做一个内部知识 Chatbot，用户问的是”上季度 X 项目的合规审批进度”——MMLU 永远验证不了这个。
- 你做一个智能审核工具，错误答案的代价是合规事故——通用 benchmark 不会教你模型在你的语料上稳不稳。
- 你做一个 Agent 调用内部 API——通用 benchmark 不会告诉你它在你这个 schema 下调对了没。
结论很朴素：你必须自己造一份 Eval 集。问题是怎么造。
二、Eval 集的三层结构
我把可用的 Eval 集设计为三层，从机器可判定到人工兜底，逐层下沉：
第一层 · Rule-based Scoring（机器可判定）
适合有明确正误标准的场景：分类、抽取、调用决策、字段校验。
优点：成本几乎为零、跑得快、CI/CD 能直接接。 缺点：只能验证”格式对/不对”层面，不能验证”质量好不好”。
我在 AI Info Tracker 里用的就是这层——一个 6 信号 rule-based 评级模型给每篇素材自动打分：
score = author_tier × source_tier × citation × depth × novelty × pr_penalty- 作者 tier：是否在维护好的 author allowlist
- 信源 tier：博客 / 微信 / Newsletter / Podcast 各类信源的可信度权重
- 引用度：被其他高分内容引用的次数
- 内容深度：长文 / 含代码 / 含数据 vs. 短贴
- 新颖度：是否复述已有信息
- PR 扣分：明显的 PR 稿 / 推广稿降权
跑下来 6,087 篇原始素材自动分档为 ★★★ 21 / ★★ 117 / ★ 532 / skip 5,417——90% 的”靠机器分捡”已经被这一层完成。
第二层 · LLM-as-Judge（语义可比对）
适合需要语义判断的场景：摘要质量、回答相关性、风格一致性。
核心原则三条：
- 判官模型必须更强或同强——用 Claude Opus 评 Sonnet 输出可以，反过来不行。
- 判官 Prompt 必须用 rubric——不要让判官自由心证，必须给它明确的打分维度（相关性 / 准确性 / 流畅度 / 是否答非所问）。
- 判官输出必须结构化——
{score: 1-5, reasoning: "...", failure_mode: "..."}，方便聚合统计。
典型坑：判官自己幻觉。我在 LiveBoard 项目里跑过 5 轮 Autoresearch 优化，第一轮判官给了 80 分，但人工抽查发现它对”summary 字数超限”这种确定性事实判错了——后来加了一道 rule-based 前置过滤把字数硬约束兜住，再交给 judge 评语义，分数才稳到 90。
第三层 · Human-in-loop（关键 case 兜底）
适合高风险、高价值、有合规边界的场景。
我把这层留给两类 case：
- 关键路径 case：用户最常问的 Top 100 个 query，必须人工标注 ground truth。
- Bad case：所有 LLM-as-Judge 给低分的 case，全部进人工 review 池。
人工 review 不是”看看就行”，要做两件事：① 写 ground-truth ② 归类失败模式（见下文）。
三、Bad Case 分类：闭环的核心
如果 Eval 集是发动机，Bad Case 分类就是诊断仪。
我在企业 AI 场景里见过太多团队”模型不行就换一个、Prompt 不行就重写一遍”——但没人系统地把失败 case 归类。结果是优化方向永远在拍脑袋。
我用的失败模式分类（可按你的业务调整）：
| 失败模式 | 典型表现 | 优化方向 |
|---|---|---|
| Hallucination · 幻觉 | 引用了不存在的来源 / 编造数字 | 加 RAG · 加 citation 强约束 · 换更稳的模型 |
| Off-topic · 跑题 | 答非所问 · 跑去回答相邻问题 | Prompt 强化 task focus · 加 query rewriting |
| Format · 格式错 | JSON 不合法 · 字段缺失 · 字数超限 | Prompt 加 schema 约束 · 后处理兜底 |
| Incomplete · 不完整 | 只答一半 · 漏关键步骤 | 拆 chain · 加 self-check |
| Overconfident · 过度自信 | 不会的也敢答 | 加 abstain · 加 confidence threshold |
| Routing · 路由错 | 用错了模型 / 工具 | Multi-model routing 重新设计 |
| Compliance · 合规越界 | 给出禁止建议 / 涉及合规红线 | Guardrails · constitutional prompting |
每个 Bad Case 必须打上一个或多个标签。然后每周看一次 dashboard：哪类失败模式占比最高，下周优化就打哪。
四、Regression Testing · 别让旧 bug 复活
Eval 集做到这里还差最后一块：回归测试。
每次改 Prompt / 换模型 / 调 Retrieval 配置，必须把所有历史 bad case 跑一遍——确认旧问题没复活。
我在 LiveBoard 上跑了 5 轮 Autoresearch 优化（score 80 → 90 → 90），每一轮都跑完整 regression suite。最折腾的一次是 Polymarket 官方搜索接口挂了，我改成本地关键词匹配 Top 50，结果发现 summary 长度的 regression 全亮——因为新数据流走 prompt 路径变了。没有回归测试这一层，这种”改 A 坏 B”的 bug 会上线后被用户当面打脸。
五、对产品经理的三条 Takeaway
- Eval 集是 AI 产品的核心资产，不是工程师的私事。 PM 必须主导 rubric 设计、bad case 分类、failure mode 监控——这些都是产品决策。
- 从能机器评的部分先开始。 不要追求”一上来就 LLM-as-Judge 全场景覆盖”——先把 rule-based 这层吃干榨净，覆盖 70-80% 的 case，剩下的再上 judge 和人工。
- Eval 不是一次性工作。 它跟着你的产品迭代——新场景 = 新 case · 新模型 = 新 bad case · 新合规要求 = 新 rubric。把 Eval 集当代码一样版本化，每个 release tag 都能 reproduce。
后记
我的所有个人 AI 项目（AI Info Tracker / WeekendGo / LiveBoard / LLM Wiki）都开源在 github.com/sherconan。如果你想看一份 6 信号 rule-based scoring 的具体实现，AI Info Tracker 仓库的 classify/ 目录就是。
下一篇我会写《企业 AI Multi-Model Routing 决策框架》——为什么单模型方案不够、跨 Claude / GPT / Gemini / DeepSeek / Kimi / Qwen / GLM 七家模型怎么做 Routing 的工程化实践。
如果你也在做 AI 产品，对 Eval / Routing / Agent 架构这些话题有共鸣，欢迎邮件 shinyashokudo@163.com。
—— 刘鹏洋 · AI Builder · AI Product Manager · 北京