MCP + RAG：为什么我不再构建复杂的 RAG 系统
我花了四年时间构建复杂的 RAG 系统。
我使用了分块策略、嵌入模型、向量数据库和重排序器。我为自己长达 1,800 小时的知识库构建了一套系统。每一次，我都以为自己正在使其趋于完美。
但它从未运行良好。
后来，我加入了 Model Context Protocol (MCP) 支持。这改变了一切。对于大多数人来说，MCP 让传统的复杂 RAG 变得过时了。
我过去常被这些问题困扰：
- 在语义分块（semantic chunking）还是递归分块（recursive chunking）之间做选择。
- 在 OpenAI、Cohere 或 Nomic 嵌入模型之间做选择。
- 在 Pinecone、Weaviate 或 Chroma 之间做决定。
- 管理 top-k 检索和重排序。
我的 RAG 系统达到了 2,000 行代码。它看起来很厉害，但失败了。我试图让我的数据变得“聪明”，而事实上 AI 本身就已经很聪明了。
我转向了 MCP 方法。我只用了 150 行代码就构建了一个服务器。
我只给了 AI 两个工具：
search_notes：使用简单的文本匹配来查找笔记。get_note_content：返回笔记的全文。
没有分块。没有复杂的嵌入。没有向量数据库。
这种简单的方法在 10 次中有 9 次胜过我那套花哨的 RAG 系统。原因如下：
- AI 处理逻辑。AI 比预设的分块器更擅长判断什么是相关的。
- 全文上下文。传统的 RAG 将笔记切成碎片，这往往会导致丢失答案。通过 MCP，AI 可以阅读整篇笔记，从而理解完整的思想。
- 可预测性。文本搜索非常简单。只要关键词存在，它就能奏效。你避免了嵌入漂移（embedding drift）和维度错误。
如果遇到以下情况，你仍然应该使用传统的 RAG：
- 你拥有超过 100,000 份大型文档。
- 你需要低延迟的大规模生产环境。
但对于个人知识库、侧边项目或内部工具，你并不需要它。
MCP 的优势：
- 易于维护：150 行代码，而不是 2,000 行。
- 无嵌入成本：当模型变化时，你不需要重新对数据进行嵌入。
- 更高的准确度：AI 可以获取完整的上下文。
- 易于调试：你可以清楚地看到搜索失败的具体原因。
停止过度工程。让 AI 来承担繁重的工作。给它访问数据的权限，让它去阅读。
Optional learning community: https://t.me/GyaanSetuAi