从本地 RAG 到 Modular RAG 设计（一）

一、背景：为什么课程咨询系统需要 RAG？

在 AI 应用中，课程咨询是一个非常典型的知识库问答场景。

用户可能会问：

• 这个课程适合零基础吗？

• Python 课程有没有项目实战？

• AI 课程需要数学基础吗？

• Java 后端课程学完可以做什么项目？

• 课程价格是多少？

• 有无就业辅导？

• 上课时间怎么安排？

这些问题看似简单，但如果完全让大模型凭自己的知识回答，就很容易出现一个严重问题：幻觉。

所谓幻觉，就是模型编造知识库里不存在的信息。

比如课程资料里只写了：

本课程适合零基础学生。

但大模型可能回答成：

本课程适合零基础学生，并且三个月内保证拿大厂 offer。

这就是非常危险的回答。对于课程咨询系统来说，AI 不能随便编课程价格、就业承诺、讲师背景、优惠政策或学习效果。

因此，一个相对可靠的方案是使用 RAG。

RAG 的全称是 Retrieval-Augmented Generation，中文通常叫“检索增强生成”。

简单来说，就是让 AI 在回答用户之前，先去知识库里查资料，然后基于查到的资料回答。

流程大概是：

用户提问 → 系统去课程知识库中检索相关资料 → 找到最相关的课程片段 → 把资料交给大模型 → 大模型基于资料生成回答

这样做的好处是：AI 的回答不再完全依赖模型记忆，而是尽量基于我们自己的课程资料。

二、当前系统：本地轻量 RAG 是什么？

假设当前课程咨询系统已经有一个本地轻量 RAG。

它可能由这几个部分组成：

SQLite + Embedding + FAISS + 大模型回答

这几个词对初学者来说可能比较陌生，可以逐个拆开看。

三、SQLite：本地轻量数据库

SQLite 是一个轻量级数据库。

它最大的特点是：不需要单独启动数据库服务器，通常就是一个本地.db文件。

相比 MySQL、PostgreSQL 这种数据库，SQLite 更轻、更简单，非常适合本地项目、原型项目、小型系统。

在课程咨询系统里，SQLite 可以用来存储：

课程名称 课程介绍 课程价格 课程适合人群 课程 FAQ 课程标签 知识库文档片段 文档 metadata

例如可以有一张课程表：

course_id | course_name | description | price | target_users

也可以有一张文档片段表：

chunk_id | course_id | content | source | updated_at

简单理解：

SQLite 就是一个本地小数据库，用来存放课程资料和知识库内容。

四、Embedding：把文字变成向量

Embedding 是 RAG 系统里非常关键的一步。

它的作用是：把文字转换成一串数字向量。

比如一句话：

Python 入门课程适合零基础学生吗？

经过 embedding 模型后，可能会变成类似这样的数字：

[0.12, -0.45, 0.89, 0.03, ...]

为什么要这样做？

因为计算机很难直接理解“语义相似”，但它可以比较数字之间的距离。

比如下面两句话：

用户问题：零基础可以学 Python 吗？ 知识库内容：本课程面向没有编程基础的学生。

这两句话字面上不完全一样，但意思很接近。

Embedding 可以把它们转换成向量，然后通过向量距离判断它们是否相关。

简单理解：

Embedding 就是把文字变成机器可以比较相似度的数字表示。

五、FAISS：快速找到相似内容

FAISS 是一个向量检索工具。

它的作用是：从大量向量中快速找到最相似的几个结果。

在 RAG 系统中，通常流程是：

1. 课程资料提前切分成很多 chunk 2. 每个 chunk 都生成 embedding 向量 3. 用户问题也生成 embedding 向量 4. 用 FAISS 在知识库向量中搜索相似内容 5. 返回最相关的几个 chunk

例如用户问：

Python 课程适合转专业学生吗？

FAISS 可能会找到这样的知识库片段：

本课程适合零基础、转专业、转码求职学生，课程从 Python 基础语法开始讲解。

然后大模型再根据这个片段生成回答。

简单理解：

FAISS 就是一个向量搜索引擎，用来快速找到和用户问题最相关的课程资料。

六、为什么不直接替换成新的 Modular RAG？

如果当前系统已经能用，后面又计划接入一个新的 MODULAR-RAG-MCP-SERVER，那么一个常见问题是：

为什么不直接把旧系统替换掉？

原因很简单：风险太高。

RAG 系统不是只要“能跑”就可以上线。它还需要回答这些问题：

新系统检索是否比旧系统更准？ 新系统回答是否更少胡编？ 新系统是否能覆盖真实用户问题？ 新系统有没有引入新的错误？ 新系统的延迟是否可接受？ 新系统是否稳定？

如果直接替换生产链路，可能出现：

课程信息回答错误 检索不到关键资料 回答中混入无关内容 模型编造不存在的优惠或承诺 用户体验下降 问题难以及时回滚

所以更稳妥的方式不是直接替换，而是分阶段验证：

Eval-only → Shadow 模式 → 小流量灰度 → 主链路替换

这其实就是 AI 应用上线前的质量控制流程。

七、Eval-only：只评估，不影响用户

Eval-only 的意思是：只做评估，不接入真实生产回答链路。

也就是说，新 RAG 系统虽然已经接进来了，但它暂时不负责回答真实用户。

它只负责跑测试集，输出结果，然后被打分。

例如我们准备 100 个课程咨询问题：

1. Python 课程适合零基础吗？ 2. Java 后端课程有没有项目实战？ 3. AI 课程需要数学基础吗？ 4. 数据分析课程适合文科生吗？ 5. 课程有没有就业辅导？

然后让旧系统和新系统都去回答这些问题，比较谁的检索更准、谁的回答更可靠。

Eval-only 的重点是：

不影响用户 不替换线上链路 只做质量评估 用指标说话

简单理解：

Eval-only 就是让新系统先参加考试，不让它直接接待真实用户。

八、Golden Test Set：标准测试集

要评估 RAG 系统，首先需要一套标准测试集。

这就是 golden test set。

Golden test set 可以理解为：标准考题 + 标准答案 + 标准检索依据。

一个标准测试样本可以长这样：

{ "question": "Python 课程适合零基础学生吗？", "expected_answer": "适合，课程从基础语法开始，面向零基础学生。", "expected_context": ["python_course_intro_chunk_03"] }

它至少应该包含：

用户问题 标准答案 应该检索到的知识片段 问题类型 难度等级 是否需要多跳推理 是否涉及价格、时间、适合人群等高风险信息

没有 golden test set，RAG 系统评估就只能靠感觉。

比如：

这个回答好像还行。 那个回答好像不太准。 这个系统感觉比之前好。

这种判断非常主观。

有了 golden test set，就可以量化：

100 个问题里，检索命中了多少个？ 正确文档平均排在第几？ 回答中有多少是忠实于知识库的？ 有多少回答混入了无关信息？

简单理解：

Golden test set 就是 RAG 系统的标准考试题。

九、Hit@K：前 K 个结果是否命中正确资料

Hit@K 是检索评估里常用的指标。

它回答的问题是：

系统检索出来的前 K 个结果里，有没有包含正确文档？

例如用户问题是：

Python 课程适合零基础学生吗？

标准正确文档是：

python_course_intro_chunk_03

系统检索出来的前 5 个结果是：

1. python_course_price_chunk_01 2. python_course_intro_chunk_03 3. java_course_intro_chunk_02 4. ai_course_math_chunk_01 5. python_project_chunk_04

正确文档出现在第 2 个，所以 Hit@5 是命中。

常见的 Hit@K 包括：

Hit@1：第 1 个结果是否就是正确资料 Hit@3：前 3 个结果里是否包含正确资料 Hit@5：前 5 个结果里是否包含正确资料 Hit@10：前 10 个结果里是否包含正确资料

Hit@K 关注的是“有没有找到”。

但它不太关心正确资料具体排第几。

比如正确资料排第 1 和排第 5，对于 Hit@5 来说都算命中。

所以 Hit@K 适合判断检索系统有没有能力把正确资料召回。

简单理解：

Hit@K 就是看前 K 个检索结果里有没有正确答案。

十、MRR：正确资料排得越靠前越好

MRR 的全称是 Mean Reciprocal Rank，中文可以理解为“平均倒数排名”。

它衡量的是：正确资料在检索结果中排得有多靠前。

计算方式很直观：

正确文档排第 1，得分 = 1 / 1 = 1 正确文档排第 2，得分 = 1 / 2 = 0.5 正确文档排第 5，得分 = 1 / 5 = 0.2 没找到，得分 = 0

如果一个 RAG 系统总是把正确资料排在第 1，它的 MRR 就会很高。

如果它虽然能找到正确资料，但经常排在第 8、第 9，它的 MRR 就会比较低。

为什么 MRR 重要？

因为大模型通常更容易关注前面的上下文。

如果正确资料排得太靠后，前面又混入大量无关内容，那么最终回答就可能跑偏。

Hit@K 和 MRR 的区别是：

Hit@K：看有没有找到 MRR：看找到后排得靠不靠前

简单理解：

MRR 就是正确资料越靠前，分数越高。

十一、Faithfulness：回答是否忠实于资料

Faithfulness 是 RAG 回答质量评估中非常重要的指标。

它衡量的是：

模型的回答是否忠实于检索到的上下文。

如果知识库里写的是：

Python 课程适合零基础学生。

模型回答：

Python 课程适合零基础学生。

这就是 faithful。

但如果模型回答：

Python 课程适合零基础学生，并且保证三个月内拿到大厂 offer。

而知识库里根本没有“保证三个月拿大厂 offer”，这就是不 faithful。

在课程咨询场景里，faithfulness 特别关键。

因为 AI 不能随便编造：

不存在的优惠 不存在的保过承诺 不存在的就业承诺 不存在的老师背景 不存在的课程时间 不存在的课程价格 不存在的合作企业

一个回答即使语言很流畅，如果它不忠实于知识库，仍然是不合格的。

简单理解：

Faithfulness 就是回答有没有根据资料说话，有没有胡编。

十二、Context Precision：检索上下文是否精准

Context precision 可以理解为“上下文精确率”。

它衡量的是：

检索出来的内容里，有多少是真正有用的？

例如用户问：

Python 课程适合零基础学生吗？

系统检索出 5 段资料：

1. Python 课程适合零基础学生 —— 有用 2. Python 课程学习路径 —— 有用 3. Java 课程价格 —— 无关 4. AI 课程数学要求 —— 无关 5. Python 项目实战介绍 —— 部分相关

如果检索结果里有很多无关内容，context precision 就比较低。

为什么它重要？

因为 RAG 系统会把检索到的上下文交给大模型。

如果上下文里混入大量无关内容，大模型可能会：

回答跑偏 混入错误课程信息 把其他课程的信息说成当前课程的 生成不必要的废话 降低回答准确性

所以一个好的 RAG 系统不仅要能找到正确资料，还要尽量少拿无关资料。

简单理解：

Context precision 就是检索结果里的“废料”多不多。

十三、Shadow 模式：新系统后台陪跑

当 Eval-only 阶段指标比较稳定后，就可以进入 Shadow 模式。

Shadow 模式也叫影子模式、旁路模式。

它的意思是：

真实用户的问题仍然由旧系统回答。 新系统在后台也收到同样的问题。 新系统也生成检索结果和回答。 但新系统的回答不展示给用户。 系统只记录新旧系统的结果，用于后续对比。

流程大概是：

用户提问 → 旧 RAG 系统正常回答用户 → 同时复制一份问题给新 RAG 系统 → 新 RAG 系统后台生成结果 → 记录两边的检索结果、回答、耗时和错误 → 后续人工或自动评估对比

Shadow 模式的价值在于：它可以让新系统在真实流量下接受检验，但不影响用户体验。

因为新系统不直接对用户输出，所以即使它回答错了，也不会造成线上事故。

Shadow 模式可以重点观察：

新系统真实问题覆盖率 新旧系统检索差异 新系统回答质量 新系统延迟 新系统错误率 新系统是否出现不稳定输出

简单理解：

Shadow 模式就是让新系统在后台陪跑，先观察，不接管。

十四、Modular RAG MCP Server：模块化 RAG 服务

MODULAR-RAG-MCP-SERVER 这个名字可以拆开理解。

首先是 Modular，意思是模块化。

一个模块化 RAG 系统通常会把整个流程拆成多个组件：

文档加载 文本清洗 文本切分 Embedding 生成 向量索引 向量检索 关键词检索 混合检索 Rerank 重排序 Prompt 构造 答案生成 结果评估 日志记录 监控告警

这样做的好处是：每个模块都可以独立替换和优化。

比如：

Embedding 模型不好，可以换 embedding 模型。 向量库不够快，可以换向量数据库。 检索结果不够准，可以加 rerank。 回答不够稳定，可以改 prompt。 评估不够细，可以增加指标。

RAG 指的是检索增强生成，也就是前面讲的“先查知识库，再让模型回答”。

MCP 通常指 Model Context Protocol，可以理解为一种让 AI 应用和外部工具、外部服务进行连接的协议。

所以 MODULAR-RAG-MCP-SERVER 可以简单理解为：

一个独立的、模块化的 RAG 服务，通过标准协议向外部系统提供检索和问答能力。

它和本地轻量 RAG 的区别可能在于：

本地轻量 RAG：更简单，适合快速实现和本地使用。 Modular RAG：更工程化，模块更清晰，更适合扩展、评估、监控和长期维护。

十五、这到底是不是 AI 测试？

是的，而且更准确地说，它属于 AI 应用测试中的 RAG Evaluation。

它不是传统软件测试里那种：

接口能不能调用 页面按钮能不能点击 数据库能不能写入 函数返回值是否正确

它测试的是 AI 系统的质量，包括：

检索是否准确 回答是否忠实 答案是否完整 上下文是否相关 是否有幻觉 是否能覆盖真实用户问题 新旧系统谁更好 是否可以安全上线

所以它更像是：

AI 系统评估 RAG 质量评估 LLM 应用测试 知识库问答质量控制 AI 上线前验证

传统软件测试更关注确定性结果。

例如：

输入 1 + 1，输出必须是 2。

而 AI 测试更复杂，因为模型输出往往不是完全固定的。

同一个问题，模型可能有多种表达方式：

适合零基础学生。 这个课程面向零基础人群。 没有编程基础也可以学习。

这些回答表达不同，但含义可能都正确。

因此 AI 测试不能只看字符串是否完全一致，而要看语义是否正确、是否忠实于资料、是否满足业务要求。

十六、为什么 RAG 系统评估很重要？

RAG 系统看起来像是一个简单的问答系统，但实际有很多容易出错的地方。

1. 检索错了，回答就容易错

如果用户问 Python 课程，系统却检索到了 Java 课程资料，那么大模型很可能把 Java 的信息混到 Python 课程回答里。

2. 检索到了正确资料，但排序靠后

如果正确资料在第 8 个，前面 7 个都是弱相关资料，大模型可能没有充分利用正确资料。

3. 上下文太杂

如果检索结果里混入多个课程的信息，大模型可能把不同课程内容混在一起回答。

4. 模型自己补充信息

即使检索结果正确，大模型也可能为了让回答更完整而补充一些知识库里没有的信息。

这种补充在普通聊天里可能没问题，但在课程咨询里可能造成误导。

5. 新系统不一定比旧系统好

新的 Modular RAG 看起来更高级，但并不代表上线效果一定更好。

它必须通过数据证明自己更稳定、更准确、更适合业务场景。

十七、一个稳妥的 RAG 升级路线

比较稳妥的 RAG 升级方式可以分为四步。

第一步：构建 Golden Test Set

先整理标准测试集。

测试集应该覆盖常见问题和高风险问题。

例如：

课程适合人群 课程价格 课程时间 课程内容 就业支持 前置基础 项目实战 课程对比 退款政策 优惠政策

同时要标注标准答案和正确知识片段。

第二步：Eval-only 离线评估

让新旧系统都跑同一批 golden test set。

对比指标包括：

Hit@K MRR Faithfulness Context Precision 回答完整性 回答安全性 平均延迟 错误率

这一阶段不影响真实用户。

第三步：Shadow 模式旁路对比

当离线评估结果比较稳定后，让新系统接收真实用户问题，但只在后台生成结果，不展示给用户。

然后对比：

新旧系统回答差异 真实问题覆盖率 真实场景下的检索质量 真实流量下的稳定性 真实请求下的延迟

第四步：逐步替换主链路

如果 Shadow 模式表现稳定，可以考虑小流量灰度。

例如：

先让 5% 流量走新系统 再扩大到 20% 再扩大到 50% 最后替换主链路

同时保留回滚机制。

一旦新系统出现明显问题，可以快速切回旧系统。

十八、用一句话总结

SQLite、Embedding、FAISS 是当前本地轻量 RAG 的基础组件。

Eval-only、Golden Test Set、Hit@K、MRR、Faithfulness、Context Precision、Shadow 模式，则是围绕 RAG 系统质量评估和上线安全设计的一套方法。

所以，这套内容的重点不是单纯“怎么做一个 AI 问答系统”，而是：

如何验证一个 RAG 系统是否真的检索准确、回答可靠，并且能安全替换原有生产链路。

它本质上属于 AI 应用测试，尤其是 RAG 系统评估。

如果用更工程化的话总结，就是：

先构建标准测试集， 再做离线评估， 然后进入旁路对比， 最后逐步灰度上线。

这是一条比“直接替换系统”更稳妥、更专业的 AI 应用升级路线。