前言

在“企业大模型落地之道”这个专栏里，我一直在试图回答一个问题：AI和大模型到底该怎么在企业内部真正用起来？过去一年，我们团队在多个业务线尝试部署RAG（Retrieval-Augmented Generation）架构的知识库系统，尤其聚焦于服务研发工程师日常协作与问题排查。初期的热情很快被现实泼了冷水——我们能跑通流程，也能做出界面，但始终无法清晰回答：“这个知识库到底有没有用？”访问量高不代表内容有用，用户点赞也可能只是出于礼貌。更麻烦的是，当多个版本的知识库迭代上线后，我们甚至无法判断哪一版效果更好。这种“黑盒式”的建设方式显然不符合工程团队对确定性和可验证性的基本要求。于是，我们开始思考：能否像测试代码一样，为知识库建立一套可自动运行、可横向对比、可长期追踪的评估体系？这篇文章就是我们在这一方向上的初步探索与实践总结。我会从问题出发，讲清楚为什么需要评估、怎么设计指标、如何搭建系统，以及从中获得的真实洞察。这不是一篇纯理论文章，而是来自一线踩坑后的经验沉淀。

1. 为什么知识库需要可度量的评估？

1.1 “感觉良好”不是工程语言

很多团队在建设知识库时，初期目标往往是“先跑起来”。导入文档、配置向量库、接入大模型，几天之内就能做出一个能问答的Demo。这种快速验证固然重要，但随之而来的问题是：如何判断这个系统是否真正解决了用户的问题？常见的反馈方式包括：

• 查看访问日志：有人问了，说明有需求。但无法区分是有效提问还是误操作。
• 人工抽检回答：抽10个问题看是否答对。样本小、主观强、不可复现。
• 问卷调研：问用户“你觉得好用吗？”——结果往往偏乐观，且难以定位具体问题。

这些方法本质上依赖“人的主观判断”，无法形成闭环优化。在一个以数据驱动和自动化为核心理念的技术团队中，这显得格格不入。我们需要一种客观、稳定、可重复执行的评估机制。

1.2 RAG系统的脆弱性需要暴露

RAG系统由两个关键环节组成：检索（Retrieval） 和 生成（Generation）。任何一个环节出问题，都会导致最终回答失效。但问题在于，这两个环节的失败模式不同：

• 检索失败：模型根本没看到正确知识，却可能靠自身参数“猜对”答案。
• 生成失败：检索到了正确文档，但模型误解或错误表达。

如果只看最终答案是否正确，会掩盖系统内部的真实瓶颈。例如，一个看似“答对”的问题，可能完全没用到知识库内容（即存在幻觉），这种“正确”是危险的。因此，评估必须拆解到子环节，才能精准定位问题。

1.3 迭代优化需要基准线

没有度量，就没有改进。当我们调整分块策略、更换向量模型、优化提示词（prompt）或引入重排序（rerank）模块时，如何判断改动是否带来正向收益？唯一可靠的方式是：在相同的测试集上运行评估，比较分数变化。这要求评估体系具备可复现性和稳定性。

笔者在实践中深刻体会到：评估不是终点，而是迭代的起点。只有建立了可靠的评估基准，后续的所有优化才有意义。

2. 核心评估指标的设计逻辑

2.1 Recall Score：检索是否命中关键知识

Recall Score 衡量的是检索模块是否成功召回了与问题相关的正确知识片段。其计算方式是将检索到的文档内容（retrieved）与人工撰写的基准答案（ground_truth）进行语义相似度比对，通常使用余弦相似度。

这里的关键在于：ground_truth 不是标准答案，而是“应该被检索到的知识”。例如，针对问题“如何申请内部CI资源？”，ground_truth 可能是一段来自《研发平台操作手册》的原文，而不是对该问题的概括性回答。

我们选用与知识库一致的 bge-m3 向量模型 对文本进行编码，确保评估环境与生产环境一致。若使用不同的嵌入模型，可能导致评估偏差。

Recall Score 的典型阈值设定：

• ≥0.7：检索效果优秀
• 0.5–0.7：基本可用，有提升空间
• <0.5：检索链路存在严重问题

2.2 Correctness：模型回答是否准确

Correctness 关注的是最终输出的答案是否正确。它将大模型生成的回答（answer）与人工撰写的理想答案（ground_truth）进行向量相似度计算。

注意：这里的 ground_truth 是对问题的完整、准确、简洁的回答，而非原始文档。例如，问题“GitLab Merge Request 的审批流程是什么？”，理想答案应是一个结构化的步骤描述，而不是直接复制平台帮助文档中的长段落。

Correctness 高并不一定代表系统健康。如前文所述，若 Recall Score 很低而 Correctness 很高，说明模型在“裸考”——完全依赖自身知识作答，未利用知识库。这种情况在通用问题上可能发生，但在企业专属问题（如内部工具使用）上，模型本不应具备先验知识。

2.3 Groundedness：回答是否基于检索内容

Groundedness 是防止“幻觉”的关键指标。它衡量的是模型回答与实际检索到的文档之间的语义一致性。计算方式同样是余弦相似度，但比较对象是 answer 与 retrieved。

高 Groundedness 意味着模型忠实引用了知识库内容；低 Groundedness 则表明模型可能在编造信息。例如，当检索到的文档只提到“支持Python 3.8+”，但模型回答“支持Python 3.6及以上”，这就是典型的幻觉，即使表述看似合理。

该指标特别适用于企业场景，因为内部知识往往具有强约束性，不允许自由发挥。

2.4 三指标的组合解读

下表总结了三种指标的不同组合所反映的系统状态：

Recall Score	Correctness	Groundedness	系统状态解读
低	高	低	模型靠自身知识“蒙对”，知识库未生效，存在幻觉风险
高	低	高	检索正确，但模型未能正确理解或表达，需优化生成环节
高	高	高	理想状态：知识库有效，模型准确且忠实
低	低	低	全链路失败，需全面回炉

这种多维评估避免了单一指标的误导性。笔者曾遇到一个案例：某次优化后 Correctness 从 0.72 提升到 0.78，看似进步，但 Groundedness 从 0.65 降到 0.48。深入分析发现，模型开始大量编造内部流程细节。若只看正确率，反而会误判为优化成功。

3. 轻量级评估系统的实现

3.1 系统架构设计原则

我们坚持“最小可行评估系统”（Minimal Viable Evaluation System）的理念，避免过度工程化。整个系统仅包含四个核心模块，全部基于现有基础设施构建：

• 复用现有检索接口：不另起炉灶，直接调用线上知识库的 retriever。
• 模拟真实用户路径：通过 Dify API 调用生成回答，确保评估路径与用户一致。
• 无外部依赖：所有计算在内网完成，不依赖第三方API（如 GPT-4 评分）。
• 代码简洁可读：便于团队成员理解和修改。

这种设计使得评估系统可以随知识库同步迭代，维护成本极低。

3.2 核心模块详解

3.2.1 retriever.py：保持评估与生产一致

该模块封装了向量检索逻辑，使用与线上知识库相同的 bge-m3 模型对查询进行编码，并从 Milvus 或 Weaviate 中检索 top-k 文档。关键点在于：

• 使用相同的分块策略（chunk size, overlap）
• 使用相同的元数据过滤条件（如仅检索“研发规范”类文档）
• 返回原始文本，而非摘要或嵌入向量

确保评估环境与真实场景高度一致。

3.2.2 generator.py：走通完整RAG链路

该模块调用 Dify 提供的问答接口，传入用户问题，获取模型生成的回答。之所以选择 Dify，是因为我们的知识库前端正是基于其构建。这样做的好处是：

• 自动包含 prompt engineering、上下文拼接等细节
• 无需手动复现复杂的 RAG pipeline
• 可评估端到端用户体验

每次调用都记录输入、输出及耗时，便于后续分析。

3.2.3 evaluator.py：三指标自动化计算

该模块是评估核心，负责：

1. 加载人工编写的测试集（含 question、ground_truth_for_retrieval、ground_truth_for_answer）
2. 对每个问题执行 retriever 和 generator
3. 使用 bge-m3 编码以下三组文本：
   • retrieved_text vs. ground_truth_for_retrieval → Recall Score
   • answer vs. ground_truth_for_answer → Correctness
   • answer vs. retrieved_text → Groundedness
4. 输出 JSON 格式的评分报告

所有相似度计算均采用 sklearn 的 cosine_similarity 实现，数值稳定。

3.2.4 main.py：批量执行与结果聚合

该脚本加载测试集（如 test_questions.json），遍历所有问题，调用上述模块，最终输出平均分及各问题明细。支持增量测试：只需添加新问题到 JSON 文件，下次运行自动包含。

整个系统代码不足300行，可在5分钟内跑完20个问题的评估。

4. 初步评估结果与洞察

4.1 第一版 Benchmark 表现

我们基于内部研发平台高频问题，人工编写了20个测试用例，覆盖以下类别：

• 工具使用（如 Jenkins、GitLab）
• 流程规范（如 Code Review 要求）
• 架构约束（如微服务注册规范）

运行结果如下：

指标	平均分
Recall Score	0.54
Correctness	0.75
Groundedness	0.59

这一结果与团队主观感受基本吻合：系统“能用但不够稳”。具体来看：

• Recall Score 偏低：部分问题因关键词稀疏或分块不当，未能召回关键段落。例如，“如何配置私有 npm 源？”的正确文档被切分到多个 chunk，导致相关性分散。
• Correctness 较高：得益于 Qwen3 的较强语言能力，即使检索不全，也能推理出大致正确的流程。
• Groundedness 中等：模型偶尔会补充知识库未提及的“常识”，如“建议使用 HTTPS”，虽无害但属于幻觉。

4.2 典型问题案例分析

案例1：检索失败但回答正确

• 问题：“内部监控告警如何升级？”
• 检索结果：返回了“日志采集规范”文档（无关）
• 模型回答：正确描述了三级升级流程
• 分析：模型凭通用运维知识作答，Recall=0.32，Correctness=0.81，Groundedness=0.28

此案例暴露了知识库覆盖不全的问题——关键流程文档缺失。

案例2：检索正确但回答错误

• 问题：“数据库变更申请需要哪些审批人？”
• 检索结果：正确返回了《DBA 变更管理规范》
• 模型回答：遗漏了“安全团队”审批环节
• 分析：模型未完整提取文档信息，Recall=0.78，Correctness=0.52，Groundedness=0.71

说明生成环节需加强指令约束，如强制模型“逐条列出”。

5. 未来优化方向

5.1 扩充与自动化构建测试集

当前20个问题是人工编写，覆盖面有限。我们计划：

• 从用户真实问答日志中抽取高频、高困惑度问题
• 利用大模型自动生成测试问题：给定一段知识文档，让模型反向提问
• 构建分类体系：按问题类型（操作类、概念类、流程类）平衡分布

目标是建立一个包含100+问题的动态 benchmark，每季度更新。

5.2 引入更精细的评估方法

当前仅依赖向量相似度，存在局限：

• 无法判断逻辑矛盾（如“支持A” vs “不支持A”）
• 对数值、日期等细节不敏感

我们正在探索：

• LLM-as-a-Judge：使用 GPT-4 或本地大模型判断 answer 与 ground_truth 是否“语义一致”
• NLI（自然语言推理）模型：判断回答是否被检索文档“蕴含”（entailment）
• Ranking 模型：评估检索结果的相关性排序质量，而非仅 top-1

这些方法虽增加复杂度，但能提供更细粒度的反馈。

5.3 与 CI/CD 集成

长远来看，评估应成为知识库发布的必要环节。我们计划：

• 在 GitLab CI 中加入评估 job
• 设定阈值：若 Recall < 0.6 或 Groundedness < 0.5，则阻断发布
• 自动生成评估报告并通知负责人

让质量保障自动化，而非依赖人工检查。

6. 结语：从“能用”到“可信”

知识库不是文档的堆砌，而是企业知识的工程化表达。当我们把评估从“我觉得还行”转变为“Recall 0.54，Correctness 0.75”，我们就迈出了科学落地的第一步。这套框架或许不够完美，但它让我们第一次看清了 RAG 系统的“健康状况”。

笔者深切感受到，在大模型时代，构建能力只是起点，验证能力才是护城河。没有度量，优化就是盲人摸象；没有评估，落地就是空中楼阁。

未来，随着知识库形态的演进——从静态文档到动态知识图谱，从单轮问答到多轮智能体协作——评估体系也必须持续进化。但核心原则不变：可量化、可复现、可对比。

这条路才刚刚开始。希望我们的探索，能为你在企业大模型落地的征途中，点亮一盏微弱但坚定的灯。