RAG 的工作链路#

RAG 的工程链路通常分两个阶段：离线索引和在线检索生成。索引阶段把原始文档处理成可检索的数据结构；在线阶段在用户提问时完成查询理解、检索召回、上下文构建和答案生成。详细的实现会在之后进行说明。

索引阶段

输入文档：文本文件、PDF、网页、数据库记录等。

清理文档：去掉 HTML 标签、特殊字符等噪声。

增强文档：补充元数据，比如时间戳、分类标签，为后续检索提供过滤维度。

文档拆分（Chunking）：用文本分割器把文档切成较小片段。这一步要兼顾语义完整性、Embedding 模型输入长度、生成模型上下文窗口和召回粒度。Chunk 太大容易引入噪声，太小又可能丢上下文。拆分策略会直接影响召回质量，详细可以看 RAG 文档处理篇。

向量化表示（Embedding Generation）：通过嵌入模型将文本片段映射为语义向量，也就是高维稠密向量。常见嵌入模型包括 OpenAI 的 text-embedding-3-small / text-embedding-3-large，以及 Hugging Face 上的开源模型。

存储到向量存储或索引系统：把嵌入向量、原始内容和对应元数据存入向量存储或向量索引系统，比如 Milvus、pgvector、Elasticsearch / OpenSearch 向量检索，或基于 Faiss 构建本地向量索引。向量数据库选型、索引算法和 pgvector 实践可以看 RAG 向量库篇。

索引过程通常离线完成。团队每周跑一次定时任务，把新增和变更的文档重新索引一遍。如果是用户上传文档这类动态场景，索引也可以在线完成，直接集成到主应用里。

检索阶段

检索是在线进行的。用户提问之后，系统通常会走下面这些步骤：

接收请求：拿到用户的自然语言查询。有些系统会先做查询改写或扩充，让后续检索更容易命中。

查询向量化：用嵌入模型把查询也转成向量，这样才能和文档向量在同一个空间里比较。

信息检索（R）：在向量库里做相似性搜索，把和查询向量最相关的文档片段捞出来。

上下文增强（A）：把检索片段、原始问题、系统指令和引用要求组织成 Prompt，交给 LLM。

输出生成（G）：LLM 输出自然语言回复，同时附上参考资料链接。

结果反馈：用户不满意时可以反馈，系统再调整 Prompt 或检索策略。有些实现也支持多轮对话来逐步完善回答。

检索效果不稳定时，问题往往出在查询改写、召回策略、排序或上下文质量上。

RAG 文档处理与切分策略#

RAG 的瓶颈在文档处理。

买了最贵的向量库、调了最好的 embedding 模型，上线后答案还是一塌糊涂。排查半天才发现文档在进入索引之前那段管线 的多栏布局被错误地按行读串了，表格的列被切散、失去了对应关系，一段政策里的 "条件" 和 "结论" 被切成了两半，页眉页脚和水印被当成正文进了索引。

RAG 向量索引算法和向量数据库#

文档切分并嵌入成向量之后，面对动辄百万、千万级的向量，需要在毫秒级内找出和查询最相似的那几个，这就是向量索引和向量数据库要解决的主要问题。

嵌入：把语义变成向量

嵌入 (Embedding) 是把一段文本映射成一个高维稠密向量的过程，语义相近的文本，其向量在空间中的距离也相近。检索的本质就是计算查询向量和文档向量之间的相似度。

嵌入模型分两大类。稀疏检索以 BM25 为代表，本质是关键词匹配的加权统计，擅长精确的词面命中，对专有名词、代码、ID 类查询很有效，但理解不了同义改写。稠密检索基于 BERT 等预训练语言模型，把文本编码成稠密向量，擅长捕捉语义，能理解 "如何提升性能" 和 "怎样优化速度" 是相近的意思。

近年涌现了 BGE、GTE、E5、Voyage 等一批优秀的嵌入模型，可以参考 MTEB、C-MTEB 这类公开榜单来选型。需要强调的是，没有放之四海皆准的最佳嵌入模型, 不同模型在不同语言、不同领域上的表现差异很大；在医疗、法律等术语密集的专业领域，往往还需要在自有数据上微调嵌入模型, 才能取得理想效果。

实践中越来越多系统采用混合检索 (Hybrid Retrieval) 同时跑稀疏和稠密两路，再把结果融合。稀疏保证关键词精确命中，稠密保证语义召回，两者互补，鲁棒性明显优于单路。

RAG 知识库文档更新策略#

知识库不是一次性建好就完事的。企业文档天天在变 —— 新增、修订、下线，如果索引不能同步更新，RAG 就会拿着过时的资料一本正经地给出错误答案。更新策略，是 RAG 绕不开的一环。

检索 (Retrieval)、生成 (Generation) 与增强 (Augmentation)#

RAG 在线运行时的检索、生成、增强是 RAG 框架的三块基石。

评估与落地#

RAG 系统好不好要靠科学的评估。评估通常分两个维度:检索质量(用命中率 Hit Rate、MRR、NDCG 等衡量召回的准不准) 和生成质量(用忠实度、答案相关性、上下文相关性等衡量答得好不好)。业界也已经有 RAGAS、ARES、TruLens 等自动化评估工具，以及 RGB、CRUD 等基准，可以用来系统化地度量噪声鲁棒性、负样本拒绝、信息整合、反事实鲁棒性等能力。

工程落地的环节要注意几点: 先把上游做干净。文档解析和切分是地基，地基歪了上层怎么调都白搭，优先投入在这里回报最高。从简单开始，按需加复杂度。先用递归切分 + HNSW + 混合检索 + 重排跑通一条基线，再针对评测暴露的问题逐点优化，不要一上来就堆迭代检索、自适应检索这些重武器。

建立评测集。比如精心标注的问答对，每次改动都用它回归，才能知道是效果真变好还是错觉。

重视更新与运维。知识库会持续变化，更新策略和监控要在设计之初就纳入考虑，减少上线后打补丁。

此外RAG 与微调可以结合。RAG 负责动态、可溯源的知识注入，微调负责固化领域语感和输出风格，两者互补，很多成熟系统是二者的组合拳。 RAG 的价值，在于用一种低成本、可更新、可追溯的方式，把大模型的通用能力和企业的私域知识、实时信息接了起来。它不是一个一劳永逸的银弹，而是一整套需要在文档处理、索引、检索、生成、增强、更新、评估各个环节持续打磨的工程体系。把每一环都做扎实，才能真正把它从惊艳的 Demo, 变成可靠的生产力。

MCP 的调用流程#

以一个用户查询为例，整个链路是这样流转的:

1. 前端发起请求。前端识别出"这是一个需要调用大模型的查询"，于是把用户的查询发送出去，准备交给 LLM 处理。
2. 后端把查询连同工具清单一起交给 LLM。这一步是关键:发给模型的不只是查询本身，还附带了 MCP 服务器当前可用的工具列表。这样 LLM 才能"知道"自己手上有哪些牌可打——比如它看到有一个"获取天气数据"的工具。
3. LLM 判断并向 MCP 请求工具。如果模型判断回答这个问题需要天气数据，它就会向 MCP 层发出请求:"请给我调用天气数据工具的权限。"
4. MCP 层执行工具并回传数据。MCP 层根据登记的功能真正去执行这个工具，取到数据后再把结果交回给 LLM。
5. LLM 处理数据并生成回答。模型基于拿到的真实数据组织出最终回答。

另外，LLM 与 MCP 之间是一种双向通信：模型可以反复地"要工具、拿结果、再要工具"，直到它认为信息足够为止。所有操作完成后，响应会沿原路返回——从 LLM 回到后端，再传到前端展示给用户。整个闭环可以概括为:

1
前端(发起查询)
2
   │  查询
3
   ▼
4
后端 ──── 查询 + 工具清单 ────►  LLM
5
   ▲                              │  ①请求某个工具
6
   │                              ▼
7
   │                          MCP 层(工具:库存订单/天气数据…)
8
   │                              │  ②执行工具，回传数据
9
   │                              ▼
10
   │  ◄──── 最终响应 ────  LLM(基于真实数据生成)
11
   ▼
12
前端(展示结果)

MCP 服务器是如何运作的#

后端集成 MCP 背后有不少细节要处理。在一个最小可用 (MVP) 的实现里，主要围绕四个步骤展开：

注册工具

这一步是让模型就知道自己能做什么，所以初始阶段必须先把工具登记清楚。我们可以向 MCP 服务器注册大量工具，它们的来源五花八门 —— 可能是数据库里的数据，可能是某种数组或数据的加工处理，也可能是来自第三方 API 的实时数据。具体做法就是定义一个个网关函数，比如 "获取价格" 或 "查询数据库"， 然后由 MCP 服务器把这些能力暴露给 AI 模型。

设置传输通道

这一步是在 LLM 与服务器之间建立起可靠的通信链路。先创建端点（通常基于 HTTP ），让大模型能通过一套标准化的协议与服务器通信。传输通道可以支持会话 (有状态)， 也可以是无会话 (无状态) 的，这里可以看具体需求而定。

处理请求

服务器需要接收模型传来的工具调用请求， 执行对应的业务逻辑，最后把一个结构化的响应返回给模型。以 "获取天气" 的函数为例，无论它底层调用的是什么功能还是实时数据 API， 都要完成 "执行 — 取数 — 整理" 这套动作。这里有个关键点：LLM 对返回格式是有要求的，所以取到的数据不能原样丢回去，必须按模型能接受的特定格式组织好再传递。这套请求处理机制使得 LLM 与服务器之间才能进行双向交互，模型要什么工具，服务器就处理什么，来回协商，而不是一次性把所有事情做完。

把结果呈现给用户

当模型基于工具返回的数据生成了最终响应，还要把它和前端整合起来。无论前端是 Angular 还是 React， 或是别的技术栈，目的都是把结果流畅、无缝地展示给用户。至此，一条完整的 MCP 工作流就走完了:注册工具 → 设置传输 → 处理请求 → 展示结果。

以天气 MCP 服务器为例，假设我们有一个天气 MCP 服务器，它对外提供一个网关工具。当用户问出 "帮我看看天气" 这类问题时，大模型会判断需要外部数据，于是向 MCP 请求调用这个网关工具；网关在服务器侧完成处理，取到数据后整理成结构化响应，再回传给大模型；大模型拿到结果后，用自然语言把它组织出来 —— 比如 "伦敦现在气温多少度"—— 最终呈现在用户面前。整个过程里，大模型负责理解和表达，而实时数据的获取则完全依赖 MCP 工具， 两者各司其职，配合完成了一次看似简单、实则跨越了多层的问答。

RAG 与 MCP 的结合#

"静态、稳定、不常变" 的知识都是 RAG 的主场 —— 公司文档、产品目录、常见问题 (FAQ) 与售后文章、互联网知识库、历史记录等等。但一套架构再好也有边界，一旦需求需要从 API、数据库或文件里动态检索，RAG 就触及了它的局限：处理的是已被索引的静态内容，拿不到实时数据。这时候 MCP 就该登场与 RAG 配合使用，由它去调用外部 API、访问动态数据源，调度多个工具、编排 GPT、Gemini 等多个 LLM，承担所有工具与集成的中枢。

假设用户提出"把我的销售报告和今天的实时汇率对比一下。" 这个问题同时踩中了两条数据线：一条是存放在文档里的历史报告，另一条是随时变动的实时数据。设计的系统会这样拆解并处理:

首先，RAG 负责取回文档数据。应用通过检索流程，从文档存储 (比如 Firebase 里的文档) 中找到并召回相关的销售报告，这一步 RAG 的检索与重排 (re-ranking) 能力就发挥了作用，确保拿到的是最相关的内容。接着 MCP 工具负责取回实时数据。系统调用一个 MCP 工具，通过外部 API 获取当前的实时汇率。到这里两路数据都已就位。

然后进入上下文整合 (Context Integration)环节。系统把来自两个数据源的信息合并成一份完整的上下文，再交给大模型 (Deepseek，GPT) 去处理。模型同时看到了 "历史销售报告" 和 "实时汇率" ，才能给出一个有依据、贴合当下的响应， 准确性也随之大幅提升。

这套架构对任何想构建 AI 系统、既要用好自有数据、又要接入实时数据的公司来说都极具价值。落地到产品，用户只需和 AI 助手对话，就能拿到分散在文档、数据库、实时接口里的全部数据，提高结果的可靠性。

一、为什么要把 RAG 做成 MCP 服务#

在最初的 RAG 系统里,检索能力往往是以一个私有 HTTP 接口的形式存在的,谁要用就去对接它的 URL、参数、鉴权。这种做法在单一应用里没问题,但一旦接入方变多——不同的 Agent、不同的大模型客户端、IDE 插件、内部工作流——问题就暴露出来了:每个接入方都要重复实现一遍对接逻辑,参数格式各不相同,升级一次接口所有下游都要跟着改,模型也无法"自己发现"有哪些检索能力可用。

MCP 把这层耦合标准化，让 RAG 从接口变成一个能被模型自主发现和调用的标准工具。它是一套让大模型与外部工具、数据源通信的开放协议:工具方(Server)把自己的能力按统一格式注册出来,模型方(Client / Host)通过协议自动发现这些工具、按标准调用、拿回结构化结果。把 RAG 封装成 MCP 服务之后,任何支持 MCP 的宿主——无论是 Claude、还是自研 Agent 框架、还是 IDE——都能"即插即用"地获得知识检索能力,不需要为每个接入方单独适配。

二、整体架构#

整个系统自上而下分为四层 接入层、编排与工具层、检索内核层、存储与数据层。Go 与 Node 的分工贯穿其中——Node 负责靠近模型、协议密集、IO 密集的接入与编排,Go 负责靠近数据、计算密集、并发密集的检索内核。

1
┌─────────────────────────────────────────────────────────┐
2
│  MCP Host / Client (Claude、自研 Agent、IDE 插件 … )   │
3
└───────────────────────────┬─────────────────────────────┘
4
                            │  MCP 协议 (stdio / SSE / Streamable HTTP)
5
┌───────────────────────────▼─────────────────────────────┐
6
│  ① MCP 接入层  (Node + TypeScript)                     │
7
│     · 实现 MCP Server,注册 tools / resources / prompts  │
8
│     · 协议解析、鉴权、参数校验、结果格式化            │
9
│     · 会话管理、流式返回                               │
10
└───────────────────────────┬─────────────────────────────┘
11
                            │  gRPC (内部高性能 RPC)
12
┌───────────────────────────▼─────────────────────────────┐
13
│  ② 编排与工具层  (Node,也可下沉到 Go)                 │
14
│     · 查询改写 / 扩展 / 路由                           │
15
│     · 多工具编排:检索 → 重排 → 上下文压缩             │
16
│     · 调用大模型做 query rewrite / rerank(可选)        │
17
└───────────────────────────┬─────────────────────────────┘
18
                            │  gRPC
19
┌───────────────────────────▼─────────────────────────────┐
20
│  ③ 检索内核层  (Go)                                    │
21
│     · 向量检索(ANN)、BM25 稀疏检索、混合检索融合      │
22
│     · Embedding 调用与缓存、Rerank 调度                │
23
│     · 高并发、连接池、批处理、限流熔断                │
24
└───────────────────────────┬─────────────────────────────┘
25
                            │
26
┌───────────────────────────▼─────────────────────────────┐
27
│  ④ 存储与数据层                                       │
28
│     · 向量数据库(Milvus / Qdrant …)                    │
29
│     · 元数据库(PostgreSQL)、缓存(Redis)                │
30
│     · 对象存储(原始文档)、消息队列(离线更新)          │
31
└─────────────────────────────────────────────────────────┘

MCP 协议本身是 IO 密集型的,涉及大量 JSON-RPC 消息收发、流式传输、与模型的交互,Node 的异步事件模型和 TypeScript 生态(官方 MCP SDK 就是 TS 优先)非常契合;而向量检索、BM25 打分、结果融合这些是计算密集、并发密集的活儿,Go 的 goroutine、静态编译、低 GC 开销让它在高 QPS 下依然稳定低延迟。两层之间用 gRPC 通信,既有强类型契约,又有高性能。

三、MCP 接入层设计(Node + TypeScript)#

接入层是整个系统对外的门面,它把内部的检索能力翻译成 MCP 协议规定的三类原语(可被模型调用的动作)、resources(可被读取的数据)、prompts(预置的提示词模板)。RAG 场景下,核心是 tools。

传输通道#

MCP 支持多种传输方式,接入层应同时支持:

• stdio:适合本地场景(IDE 插件、桌面 Agent),宿主直接以子进程方式拉起 MCP Server,通过标准输入输出通信,零网络开销。
• Streamable HTTP / SSE:适合远程、多租户、云端部署场景。服务常驻,多个客户端通过 HTTP 连接,支持服务端流式推送(检索结果可以边算边返回)。 生产环境以 Streamable HTTP 为主,本地开发和轻量集成保留 stdio。

鉴权、校验与会话#

接入层还要承担几件"守门"的工作。

鉴权 请求进来先校验身份(API Key / OAuth Token),并把用户身份透传到下游,用于数据权限过滤——这一点在企业场景尤其关键,不同用户能看到的知识库范围不同,权限必须在检索层生效,绝不能让模型跨权限拿到数据。参数校验:用 zod 之类的库对入参做严格校验,非法参数直接拒绝,不打到内核。会话管理:维护 MCP 会话状态,支持多轮上下文。结果格式化:把内核返回的结构化结果整理成 MCP 规定的 content 格式(文本 + 结构化元数据),并做好脱敏。 Node 侧直接用官方的 @modelcontextprotocol/sdk,它把协议细节都封装好了,我们只需专注于工具的注册和实现。

四、编排与工具层设计#

这一层是"检索前 + 检索后"优化的落点,决定了给到模型的证据质量。它可以放在 Node(靠近协议、方便调模型),也可以下沉到 Go(追求性能),推荐初期放 Node,链路成熟后把重计算部分下沉。 一个 rag_search 请求进来后,编排层典型地会走这样一条链路。首先是查询理解与改写:用户的原始问题往往口语化、有歧义,这里可以做查询重写、多查询扩展(把一个问题从多角度改写成几条并行检索)、或子查询分解(把复杂问题拆成几个简单问题)。如果场景需要,还可以做 HyDE——先让模型生成一个假想答案,再拿它去检索,通常召回更准。 接着是路由:如果有多个知识库,先判断这个问题该查哪个集合,避免全库乱撞。然后调用检索内核拿到初步候选。拿到候选后进入检索后处理:用 rerank 模型对候选重排,把最相关的顶到前面;再做上下文压缩,剔除冗余、控制长度,避免模型"迷失在中间"。最后把整理好的证据(或证据 + 生成的答案)返回给接入层。 这条链路里,查询改写和 rerank 可能需要调用大模型或专门的小模型,属于 IO 密集操作,这也是为什么编排层适合放在 Node。

五、检索内核层设计(Go)#

检索内核是系统的性能担当,它不关心 MCP 协议,只专注一件事:给定一个(或一组)查询,又快又准地返回候选片段。用 Go 实现的理由是它在高并发下的稳定性和低延迟表现。

内核对外(对编排层)暴露 gRPC 接口,内部负责:向量检索(调用向量库做 ANN 搜索)、稀疏检索(BM25 关键词打分)、混合检索融合(把稠密和稀疏两路结果用 RRF 等算法融合排序)、Embedding 调用(把 query 编码成向量,带缓存避免重复计算)、以及可选的 rerank 调度。

高并发场景下,每个检索请求可能要并行发起"向量检索 + BM25 检索 + embedding 计算"多个子任务,Go 的 goroutine 让这种并行编排写起来简单、开销极低。同时,静态编译产物部署方便、内存占用可控、GC 停顿短,在 QPS 冲高时延迟曲线比解释型语言平滑得多。此外,向量库(如 Milvus、Qdrant)大多提供 Go SDK,连接池、批量查询、超时控制都好实现。

内核层要把稳定性做扎实:对下游(向量库、embedding 服务、rerank 服务)都要有连接池、超时、限流、熔断;对 embedding 结果做缓存(相同 query 或相同文本不重复算);支持批处理(把并发到达的多个 embedding 请求攒成一批调用,提升吞吐);并暴露完善的指标(检索延迟、召回数、缓存命中率)供监控。

六、离线更新链路#

在线检索之外,还有一条离线的知识库更新链路,它决定了知识的新鲜度。这条链路可以独立部署,用 Node 或 Go 都行(文档解析生态 Python/Node 更丰富,重计算部分可用 Go)。 流程是:文档源发生变化(新增 / 修改 / 删除)时,通过 webhook 或定时扫描感知变更,把变更事件投递到消息队列;消费者做文档解析、清洗、切分(chunking)、调用 embedding 编码成向量,再写入向量库和元数据库。更新采用增量方式而非全量重建:给每个文档维护唯一 ID 和内容指纹,修改时"先删旧 chunk、再写新 chunk",删除时按文档 ID 清除对应向量,并配合软删除和版本管理保证一致性。这条链路和在线检索通过共享的存储层解耦,互不阻塞。

七、技术选型汇总#

Roadmap#

MVP 实现一个只有 rag_search 一个工具的 MCP Server,内核直连向量库做纯向量检索,用 stdio 在本地跑通,验证协议链路和检索效果。

补齐质量:加入混合检索、rerank、查询改写、元数据过滤和权限,把检索质量做上去,切到 Streamable HTTP 支持远程多客户端。

做生产化:补齐离线增量更新链路、缓存、限流熔断、全链路可观测,压测调优,并把编排层的重计算部分按需下沉到 Go 服务

相关技术细节可以看后面的博客