企业官网建设流程全解析

别再靠感觉调 RAG 了：一套能跑的评估流水线

你改完 Prompt、调过 chunk 大小、换了 Embedding 模型——然后问同事「这次好点了吗」，得到的是「感觉还行」。

这就是最危险的状态：你没法证明它变好了，也没法证明它变差了。每次改动都是一场没有裁判的赌博。

RAG 评估不是选一个工具装上去就完事。它是一个工程流程：先人工打底，再自动化，最后接进回归。下面这 4 步，我走过一遍。

「感觉 RAG 变好了」是最危险的状态

我见过三个翻车现场，都是同一个模式：

场景 1：有人改了一版 Embedding 模型，说「新模型效果更好」，理由是「试了几个问题感觉更准」。上线后，用户反馈问题变少了，但客服工单翻倍——因为新模型把长文档的 chunk 召回率降了 12%，但没人在意。

场景 2：调 chunk 大小从 512 改到 256，「这样召回更精准」。结果答案引用溯源变差了，用户问「你根据哪段说的」，系统答不上来。因为小 chunk 把上下文切断了。

场景 3：换了一个更强的 LLM 当生成器，「幻觉少了」。实际上幻觉确实少了 30%，但答案变长了 2 倍，用户看完更晕了——因为原来短答案的信息密度更高。

这三个场景的共同点：都不是技术能力问题，是没有评估基线。

没有评估体系，RAG 开发就是炼丹。改完不知道好没好，上线全凭感觉，出了问题全靠用户反馈。

第 1 步：人工抽检 20 个 case 打底

别一上来就搞自动化。先手动做 20 个 case。

怎么挑这 20 个 case：

按场景分布，6 类 × 3-4 个：

场景

case 数

示例

典型问答（知识库里有明确答案）

4

「公司年假几天」「报销流程」

多文档跨引用（答案需要拼接）

3

「华东和南区库存差多少」

边界/模糊问题（答案不在知识库里）

3

「竞品 X 的功能对比」

时间敏感问题（答案会过期）

3

「最新政策」「当前价格」

长文档定位（答案在文档中间）

4

「第 3 章提到的约束条件」

多轮上下文（依赖前几轮对话）

3

「上面那个数字再确认下」

打分维度（4 个，1-5 分）：

• 答案准确性

  ：事实对不对，数字对不对

• 引用溯源

  ：能不能给出依据（哪个文档、哪段）

• 延迟

  ：从提问到出答案的响应时间（秒）

• 幻觉

  ：有没有编造知识库里没有的内容

工具：Excel 就够。

一张表，20 行，每行一个 case：问题、参考答案、系统答案、4 个维度的分数、总分、备注。不要上系统，不要接数据库。Excel 够用 3 个月。

踩坑：case 太少没统计意义，太多维护不起。

10 个 case 以下，改一次 Prompt 就能全部对上，没参考价值。30 个以上，每轮评测要 1-2 小时，团队不愿意跑，系统就废了。20 个是平衡点——足够覆盖典型场景，又能在 30 分钟内跑完。

第 2 步：LLM-as-judge 自动化打分

人工打分的问题是：主观、慢、一致性差。

LLM-as-judge 是用一个 LLM 当裁判，自动打分。这是当前行业标配——Ragas、TruLens、LangSmith 都支持。

三家工具怎么选：

工具

优势

劣势

适合

Ragas

开源、指标多（Faithfulness/Context Recall 等）、可自部署

配置复杂、中文支持一般

已有评测框架的团队

TruLens

集成 LangChain、有 UI

闭源、依赖 LangChain

LangChain 用户

LangSmith

全托管、开箱即用、有版本对比

贵、数据出境

想快速上手的团队

如果你没有现成框架，先手动用 API 调，不要急着上工具。跑通流程再选型。

Judge Prompt 模板（直接复制）：

你是一个 RAG 系统评估专家。请根据以下信息打分： 【用户问题】：{question} 【参考答案】：{reference_answer} 【系统答案】：{system_answer} 【引用的文档片段】：{retrieved_chunks} 请从以下 4 个维度打分（1-5 分）： 1. 答案准确性：系统答案与参考答案的事实一致性 2. 证据支撑度：引用的文档片段是否包含答案依据 3. 完整性：是否遗漏了参考答案中的关键信息 4. 幻觉程度：是否有参考答案中没有的编造内容 输出 JSON： {"accuracy": X, "evidence": X, "completeness": X, "hallucination": X, "reason": "一句话说明"}

防自欺机制（重要）：

如果你用 GPT-4 当 judge，它可能会系统性地给自家答案高分。解决方法：

• 用不同模型当 judge

  ：系统用 GPT-4，judge 用 Claude 或 Gemini

• 校准阈值

  ：先拿 20 个人工打分 case，跑一次自动打分，算 Pearson 相关系数。低于 0.8 说明 judge 不可信，调 prompt

• 人工复核 10%

  ：每周随机抽 2 个 case 人工复核，发现偏差及时调整

踩坑：用同一个模型当 judge 会系统性偏高。

我试过一次，用 GPT-4 当 judge 评 GPT-4 生成的答案，平均 4.2 分。换成 Claude 评，同一批答案平均 3.4 分。差 20%。这不是谁对谁错，是系统性偏差必须识别。

第 3 步：基线与回归，每次改动跑一遍

有了自动打分，下一步是建基线。

基线 = 人工抽检 20 case 的平均分。

第一次跑完人工打分，算出 4 个维度的平均分，这就是你的基线。比如：准确性 3.8、证据支撑 3.5、完整性 3.6、幻觉 4.1。

CI 流程：

改动（Prompt / chunk / embedding） → 跑 20 个 case 自动打分 → 对比基线 → 超阈值？告警，不合并 → 未超阈值？合并，更新基线

阈值参考：

指标

告警阈值

说明

Recall@5

下降 > 5%

召回率下降意味着答案质量下降

Faithfulness

下降 > 0.3 分

Ragas 指标，1-5 分制

延迟 P95

上升 > 500ms

用户体验底线

幻觉率

上升 > 10%

安全底线

踩坑：基线太松等于没有，太紧天天误报。

基线是「当前最优」，不是「完美标准」。你的目标是防止回归，不是追求满分。设太严（比如准确性必须 4.5），每次改动都报警，团队就会忽略告警。设太松（4.0 以下才报警），等于没有。

第 4 步：评测集持续演进

20 个 case 不是终点。评测集要活着。

新 case 从哪来：

• 线上 bad case

  ：每周捞 5 个用户反馈「答错了」的真实问题，加入评测集

• 新功能前置

  ：开发新功能时，先写 3-5 个 case 验证，测完入库

• 边界场景

  ：遇到一次线上边界情况（比如超长文档、特殊字符），补进评测集

旧 case 怎么淘汰：

3 个月没命中的 case 归档。怎么判断「没命中」？看线上真实提问的记录，如果 90 天内没出现过类似问题，这个 case 就过时了。

踩坑：评测集越用越大，最后跑一次要 2 小时。

不加淘汰规则，评测集会无限膨胀。跑一次要 2 小时，团队就不会跑了。所以必须有「3 个月没命中就归档」的规则。归档不是删除，是移到「历史 case」表，需要时还能查。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】