mcp and rag difference

做知识问答时被问「为什么不用 MCP」，或者接了 MCP 却发现模型还是答不出公司内部资料——这类混乱基本都来自把「模型能碰什么」和「模型知道什么」混成一件事。这篇不重复原理，只给判断标准：什么场景该上 RAG、什么场景该上 MCP、两者同时上时接口怎么切、日志和评测怎么留痕，最后给一张能直接照着走的选型清单。

做知识问答时被问「为什么不用 MCP」，或者接了 MCP 却发现模型还是答不出公司内部资料——这类混乱基本都来自把「模型能碰什么」和「模型知道什么」混成一件事。前者是能力接入，后者是上下文供给，方向完全不同，混着谈就会得出「上了 MCP 就不用做检索」这种错误结论。

这篇不重复原理，只给判断标准：什么场景该上 RAG、什么场景该上 MCP、两者同时上时接口怎么切、日志和评测怎么留痕。看完你至少能回答三个问题：这需求该用哪条链路、两条链路同时存在时谁调谁、上线后怎么知道它坏了。

先分清两件事：模型「知道什么」和模型「能碰什么」

RAG 解决的是上下文注入问题：把外部资料检索出来塞进提示词，模型本身不执行任何动作，只是读到了更多东西。MCP 解决的是能力接入问题：把外部系统暴露成标准工具，模型决定何时调用、传什么参数、拿到什么返回。一个是喂资料，一个是给手脚。

RAG 的产出

一段被检索出来的文本，最终变成提示词里的一部分

MCP 的产出

一次真实的系统调用与返回结果，可能改变了外部状态

共同点

都是为了让模型在单次对话里显得更靠谱

关键差异

RAG 只读且无副作用，MCP 可以写、可以改、可以发消息

判断口径很简单：答案已经在静态资料里，且资料不常变，就倾向 RAG；答案要靠实时查询、写操作或跨系统动作，就倾向 MCP。两者不互斥，但也不是可以随便替换的关系。

一张判断清单：按「数据形态 + 时效 + 是否要动作」三步走

大部分选型纠结，都是因为把三个维度搅在一起想。拆开来看，每一步都有明确的判断依据，走完三步基本就定了。下面这张表可以对着自己的需求逐行过一遍。

1. 第一步看数据形态非结构化文档、PDF、Wiki 页面是 RAG 的主场；结构化接口、数据库、SaaS 系统是 MCP 的主场。数据形态决定了你更适合检索还是更适合封装成工具。
2. 第二步看时效要求分钟级以内必须准的，别指望离线索引，走 MCP 实时查；能接受小时级甚至天级更新的，RAG 完全够用，维护成本还更低。
3. 第三步看是否要产生副作用只要有写操作就必须走工具调用，且要配权限与确认；不确认就执行，等于把线上系统交给了概率性输出。

三步都不明确时，先用 RAG 做只读问答验证价值，再考虑把高频查询改成 MCP 工具。原因很实际：只读链路的出错后果可控，试错成本低，先跑通再考虑加大投入。

延迟与成本：两条链路的钱花在哪，怎么量

RAG 的开销主要在检索与上下文长度：召回条数、切片大小直接决定单次请求的 token 量。很多人只盯着模型单价，却忽略了自己把上下文塞到多长，到 模型成本计算器（/tools/model-cost-calculator） 按你实际的上下文长度算一遍，往往比看单价更有用。

MCP 的开销主要在往返次数：一次对话可能触发多轮工具调用，每轮都算一次请求，延迟是叠加的，成本也是叠加的。工具描述本身也占上下文，工具越多，模型选错的概率越高。

测量顺序建议这样走：先用 接口测速（/tools/speed-test） 量出单次调用的延迟基线，再把检索耗时和工具往返耗时分开记，才知道瓶颈到底在本地检索、在网络、还是在模型侧排队。

• 上下文长度按最坏情况估，不要按平均值估，否则高峰期账单会失控
• 给工具调用设上限，避免模型反复试错触发多轮往返
• 检索召回条数先设小再逐步加，加条数要验证是否真的提升了答案质量
• 把重试算进延迟预算，一次失败重试就是双倍耗时

各自的典型翻车方式与排查顺序

两条链路的故障表现完全不同，混在一起看就会误判。RAG 出问题时，模型往往「看起来在正常回答」，只是答错了；MCP 出问题时，通常是链路层面就断了，或者模型调了不该调的工具。

统一做法：把每次请求的检索命中、工具名、参数、返回状态都写进日志，出问题时能按链路回放。否则你只能靠猜，而猜的成本远高于打日志。

不适用提醒：别为了「可观测」把整段上下文原文落盘，敏感数据要脱敏，站内安全与合规相关资料里有更细的口径，按自己的数据分级来定。

两者一起用：把检索做成工具，还是工具里带检索

实际项目里很少是纯粹二选一，更多是同时存在。这时候真正要决定的是接口怎么切：检索结果直接拼进提示词，还是封装成工具让模型按需调用，还是让工具内部自带检索。

选择依据是：看你对「这一轮要不要查」有没有确定的判断。判断得了，就自己决定，链路短、延迟低、可控；判断不了，就交给模型，但一定要给调用上限，防止它在不确定时反复尝试。

什么情况下两个都别上

不是所有问题都需要检索或工具。硬上方案的代价不只是开发时间，还有长期维护成本，以及更长的链路带来的更多故障点。

• 答案本来就在模型常识范围内，比如通用概念解释、常规代码片段，加检索只会引入噪声
• 数据量极小，比如十几条 FAQ，直接写进提示词比搭一套检索链路更省事
• 读操作之外的合规风险没解决：涉及个人数据、财务数据的写操作，先解决权限与审计再谈接入方式
• 团队没有维护能力：检索质量依赖持续清洗语料，工具依赖接口变更跟进，没人管的话半年后一定烂掉
• 问题本身就没定义清楚：连「什么算答对」都说不清的场景，上什么链路都是在放大混乱

落地步骤：从最小可验证版本开始

最容易踩的坑是一上来就全量替换。正确做法是先定义清楚什么叫「答对」，再针对答错的部分小步引入，每一步都能对比前后差异。

1. 第一步：建验收集定义 5 到 10 个真实问题作为验收集，先跑纯模型回答，记下哪些答错、错在哪。这批问题后面每次改动都要重跑。
2. 第二步：只补短板只针对答错的那几类问题引入检索或工具，不要一上来就全量替换。改动范围越小，越容易判断是谁带来的提升。
3. 第三步：固定指标对比答案正确率、工具调用成功率、单次平均耗时各选一个，每次改动前后对一遍。指标不要贪多，一个阶段盯一个。
4. 第四步：配好降级路径上线前把超时、重试和降级路径配好，工具挂掉要能退回纯模型回答而不是报错给用户。降级不是丢人，是基本可用性。

上线之后盯什么：日志字段、评测节奏与常见回归

上线不是终点。检索和工具都会随外部环境变化，语料会更新、接口字段会改、权限会被收紧，这些变化都会表现为「模型突然变笨」，但根因不在模型。

• 日志至少记：请求 ID、命中的资料标识、调用的工具名与参数、每段耗时、最终是否降级
• 评测节奏：语料或工具接口有变更就重跑一次验收集，别等用户反馈
• 常见回归一：接口字段改了但工具描述没更新，模型按旧描述传参
• 常见回归二：工具权限被收紧，调用返回无权限但模型仍以为自己调通了
• 常见回归三：检索索引没重建，新资料查不到，模型只能凭常识编

排查顺序建议固定成一条线：先确认工具连通性，再确认检索是否返回结果，最后才怀疑模型本身。参考 质量监控（/tools/quality-monitor） 的口径，把这三个环节的状态分开看，定位时间能省一大半。想对比不同链路在真实场景下的表现，也可以到站内的中转站可信度与价格追踪页面核对当时的数字，别凭印象做判断。

RAG 决定模型读到什么，MCP 决定模型能做什么。混着讲，就会既读不到也做不对。