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 或检索策略。有些实现也支持多轮对话来逐步完善回答。

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

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 助手对话，就能拿到分散在文档、数据库、实时接口里的全部数据，提高结果的可靠性。