当前位置：首页 > news >正文

清华整了个狠活：把RAG拆成积木，50行配置替代900行代码

news 2026/7/3 0:40:50

做 RAG 的人都懂这种痛——

想把 RAG 系统落地到业务，却卡在「数据构建乱、检索不准、微调复杂、评估没标准」：

• 整理领域数据要手动标注，耗时耗力
• 检索模型调参全靠试错，准确率忽高忽低
• 换个 Embedding 模型或 LLM 后端，整个系统要重写
• 甚至连评估效果都没有统一标准，不知道改得好不好

直到发现了UltraRAG。

这是清华大学 THUNLP 实验室、东北大学 NEUIR、OpenBMB 联合推出的开源项目，把「数据构建 - 模型微调 - 推理评估」全流程做成了傻瓜式操作。

但真正让我眼前一亮的，不是它的「低代码」噱头。

而是——它是全球首个基于 MCP（Model Context Protocol）架构的原生 RAG 框架。

这可能是下一个时代的 RAG 开发范式。

先搞清楚：什么是 MCP 架构？

MCP（Model Context Protocol）是 Anthropic 推动的标准化协议，核心思想是——

把 AI 系统的各个组件（检索、生成、评估、存储…）都封装成独立的「智能体服务器」，然后通过标准化协议让它们互相通信。

传统 RAG 架构：

用户提问 → 向量检索 → 重排序 → 生成答案 → 返回

这是「火车轨道」，每个组件是焊死的，换一个就全断了。

MCP 架构的 RAG：

Retriever Server ←→ Generator Server ←→ Evaluation Server ↖ ↓ ↗ MCP 协议层（标准通信）

这是「高速公路」，每个组件是独立的服务器，通过标准化协议通信。想换哪个就换哪个，不用拆整条路。

正如 UltraRAG 团队说的：

“It’s like upgrading from fixed train tracks to a highway system. Want to swap out your retrieval engine or try a different language model? With MCP, it just works.”

翻译成中文：

“这就像从固定的火车轨道升级成高速公路。想换检索引擎？想试别的语言模型？接上 MCP，直接能用。”

UltraRAG 系统架构深度拆解

这才是本文的核心——我要把 UltraRAG 的架构从里到外拆给你看。

四层 MCP Server 设计

UltraRAG 把 RAG 的完整生命周期拆成了四层独立的 MCP 服务器，每层都有清晰的职责边界：

┌─────────────────────────────────────────────────────────┐│ Pipeline Orchestration Layer ││ (YAML 声明式配置 + 流程控制引擎) │├─────────────┬─────────────┬─────────────┬───────────────┤│ Corpus │ Retriever │ Generator │ Evaluation ││ Server │ Server │ Server │ Server ││ (文档处理) │ (检索排序) │ (生成答案) │ (效果评测) │├─────────────┴─────────────┴─────────────┴───────────────┤│ MCP Protocol Layer ││ (标准化通信 + Tool 暴露 + 类型校验) │└─────────────────────────────────────────────────────────┘

每一层都是独立的进程，通过 Unix Socket 或 TCP 连接通信。

第一层：Corpus Server — 文档处理的工业级流水线

位置：servers/corpus/server.py

核心职责：文档解析 → 分块 → 向量化 → 知识库构建 → 索引管理

内部架构：

Corpus Server├── Input Adapters (输入适配器)│ ├── PDFParser（基于MinerU）│ ├── MarkdownParser│ ├── WordParser│ ├── WebArchiveParser│ └── EbookParser├── Chunking Engine（分块引擎）│ ├── SemanticChunker（语义分块）│ ├── FixedSizeChunker（固定大小）│ ├── RecursiveChunker（递归分块）│ └── LayoutAwareChunker（布局感知分块）├── Embedding Layer（向量化层）│ ├── Text Embedding（BGE、OpenAI、Voyage...）│ ├── Image Embedding（CLIP、Qwen-VL...）│ └── Unified Vector Space（统一向量空间）└── Knowledge Base Manager ├── Vector DB Interface ├── Index Builder └── Incremental Update

技术亮点：

1. 布局感知分块— 不是简单按字符数切，而是理解 PDF 的多栏布局、标题层级、表格结构，确保分块不打断语义单元
1. 多模态统一向量化— 文本、图片、表格被映射到同一个向量空间，实现真正的跨模态检索
1. 增量更新机制— 新增文档不需要重建整个索引，只更新受影响的向量分片

第二层：Retriever Server — 检索的策略化实现

位置：servers/retriever/server.py

核心职责：检索执行 → 重排序 → 结果融合 → 质量过滤

内部架构：

Retriever Server├── Search Engines│ ├── DenseRetriever（向量检索）│ ├── SparseRetriever（BM25关键词检索）│ ├── HybridRetriever（混合检索）│ └── KnowledgeGraphRetriever（知识图谱检索）├── Reranking Layer│ ├── CrossEncoderReranker│ ├── LLM Reranker│ └── EnsembleReranker├── Query Transformation│ ├── Query Rewriting│ ├── HyDE (Hypothetical Document Embedding)│ └── Query Expansion└── Result Fusion ├── Reciprocal Rank Fusion ├── Weighted Score Fusion └── Learning to Rank

暴露的 Tool 接口：

@mcp.tool()def hybrid_search( query: str, top_k: int = 5, dense_weight: float = 0.6, sparse_weight: float = 0.4, enable_rerank: bool = True) -> List[Document]: """混合检索入口"""@mcp.tool()def expand_search( original_query: str, related_terms: List[str], search_depth: str = "deep") -> List[Document]: """扩展检索，用于多跳推理场景"""@mcp.tool()def check_sufficiency( retrieved_docs: List[Document], query: str) -> Dict: """判断检索结果是否足够回答问题"""

这就是 Agentic RAG 的基础 — 检索不再是一次性操作，而是可以根据中间结果反复调用的智能行为。

第三层：Generator Server — 生成的可控化编排

位置：servers/generator/server.py

核心职责：提示词编排 → 多模态生成 → 引用溯源 → 格式输出

内部架构：

Generator Server├── Prompt Templates│ ├── Standard QA Template│ ├── MultiModal QA Template│ ├── Citation Enhanced Template│ └── Chain-of-Thought Template├── LLM Backends│ ├── OpenAI / Anthropic│ ├── Qwen / Llama 3│ ├── GLM / DeepSeek│ └── vLLM 推理加速├── MultiModal Generator│ ├── Text + Image Fusion│ ├── Table Understanding│ └── Formula Rendering└── Output Processors ├── Citation Injection（自动插入引用） ├── Format Normalization └── Hallucination Detection

关键实现细节：

生成器会自动在答案中插入[1] [2]这样的引用标记，并在文末附上对应的文档来源和精确位置。

这解决了 RAG 最头疼的「溯源难」问题 — 用户可以随时定位到某个结论来自哪篇文档的哪一页。

第四层：Evaluation Server — 效果的可解释评测

位置：servers/evaluation/server.py

核心职责：相关性评测 → 忠实度评测 → 流畅性评测 → 错误归因

三维评测体系：

维度	指标	评测方法
相关性	Precision@k, Recall@k, MAP	基于 LLM 判断答案与问题的匹配度
忠实度	Faithfulness Score, Hallucination Rate	逐句比对答案与检索文档的一致性
流畅性	Perplexity, Readability Score	语言模型困惑度 + 可读性分析

最有价值的设计：

每个评测结果不只是分数，还附带：

• 错误定位：哪句话有幻觉？哪个引用不匹配？
• 改进建议：应该补充什么检索词？需要调整哪个参数？
• 可视化报告：检索准确率随迭代次数的变化曲线

这让 RAG 的优化从「玄学调参」变成「科学工程」。

流程编排引擎：50行YAML替代900行代码

现在来看最核心的编排层。

UltraRAG 实现了一个完整的声明式流程引擎，用 YAML 定义复杂的 RAG Pipeline。

传统代码写法 vs UltraRAG 配置

传统 RAG 代码（900行+）：

# 伪代码示意def rag_pipeline(query): # 1. 查询改写 rewritten_query = rewrite_query(query) # 2. 混合检索 dense_results = dense_search(rewritten_query, top_k=20) sparse_results = sparse_search(rewritten_query, top_k=20) # 3. 结果融合 fused = reciprocal_rank_fusion(dense_results, sparse_results) # 4. 重排序 reranked = reranker(fused, top_k=5) # 5. 检查是否足够 is_sufficient = check_sufficiency(reranked, query) # 6. 如果不够，扩展检索 if not is_sufficient: suggested_terms = get_suggested_terms(query, reranked) extra_results = expand_search(query, suggested_terms) reranked = merge_results(reranked, extra_results) # 7. 生成答案 answer = generate_answer(query, reranked) # 8. 插入引用 answer_with_citations = inject_citations(answer, reranked) return answer_with_citations

这还只是主流程，不包括错误处理、日志、监控、参数管理…

UltraRAG 配置（50行）：

pipeline: name: agentic_multi_modal_qa version: "1.0" variables: user_query: "${input.query}" max_iterations: 3 current_iteration: 0 steps: - step: rewrite_query server: retriever tool: query_rewrite input: original_query: "${user_query}" strategy: "hyde" # Hypothetical Document Embedding - step: initial_search server: retriever tool: hybrid_search input: query: "${rewrite_query.result}" top_k: 20 dense_weight: 0.6 sparse_weight: 0.4 enable_rerank: true - step: check_sufficiency server: evaluator tool: check_context_sufficiency input: retrieved_docs: "${initial_search.results}" query: "${user_query}" - step: expand_retrieval_loop condition: | ${check_sufficiency.is_sufficient} == false AND ${current_iteration} < ${max_iterations} loop: - step: get_suggested_terms server: retriever tool: extract_search_terms input: query: "${user_query}" current_docs: "${initial_search.results}" - step: expanded_search server: retriever tool: expand_search input: original_query: "${user_query}" related_terms: "${get_suggested_terms.terms}" depth: "deep" - step: merge_and_rerank server: retriever tool: merge_and_rerank input: docs_a: "${initial_search.results}" docs_b: "${expanded_search.results}" top_k: 8 - step: increment_counter action: set_variable variable: current_iteration value: "${current_iteration} + 1" - step: recheck_sufficiency server: evaluator tool: check_context_sufficiency input: retrieved_docs: "${merge_and_rerank.results}" query: "${user_query}" - step: generate_answer server: generator tool: multimodal_generate_with_citations input: context_docs: "${merge_and_rerank.results}" query: "${user_query}" enable_cot: true citation_style: "numbered" - step: final_evaluation server: evaluator tool: comprehensive_evaluation input: query: "${user_query}" answer: "${generate_answer.result}" context_docs: "${merge_and_rerank.results}" output: answer: "${generate_answer.result}" citations: "${generate_answer.citations}" evaluation: "${final_evaluation.result}" iterations_used: "${current_iteration}"

这 50 行配置，实现了传统代码 900 行才能完成的功能。

而且支持的控制结构不只是串行：

•条件分支（if/then/else）
•循环迭代（loop+ 终止条件）
•并行执行（parallel分支同时跑）
•分支合并（merge多个并行结果）
•动态变量（运行时修改流水线状态）

这就是 Agentic RAG 的架构基础。

三大核心创新，每个都戳中痛点

第一，原生多模态支持

VisRAG Pipeline 端到端处理视觉文档——PDF 里的图片、表格、公式直接解析，不用单独跑 OCR，不会丢失布局信息。

它统一向量化文本、图像、表格，支持跨模态混合检索。你可以用文字描述搜技术图表，也可以用图片搜相关文档。

在 M3DocVQA 等权威基准上，端到端问答准确率提升了 33%。

第二，知识接入自动化

集成了 MinerU 技术，自动处理 Word、PDF、Markdown、电子书、网页存档。

最狠的是 PDF 解析——高保真还原复杂版面和多栏结构，支持按页转成图像，保留视觉布局信息。

几百篇研究论文丢进去，一晚上就能变成可检索的知识库。

第三，透明评估体系

内置 UltraRAG-Eval，三个维度自动化评测：

• 相关性（relevance）
• 忠实度（faithfulness / 反幻觉）
• 流畅性（fluency）

每个评测结果都有可解释的指标，不是给个分数就完事。

为什么我说这可能是 RAG 的下一个时代？

因为它解决了 RAG 最底层的四个架构问题：

问题	传统 RAG	UltraRAG
组件耦合	换检索模型要改整个流程	MCP 标准接口，热插拔
实验复现难	代码改一点结果就变	YAML 配置，完全可复现
评估不统一	各做各的评测	内置标准化评测体系
多模态支持差	文本和图像分开处理	原生统一架构

更深层的意义是——MCP 让 RAG 从「项目级」变成「组件级」。

以前做 RAG 是做一个项目，写完就完事。

现在用 MCP 架构，你做的是可复用的组件：你的 Corpus Server 能被别人用，别人的 Retriever Server 你也能直接接。

这会催生一个 RAG 组件市场。

上手只需要三步：

# 1. 克隆并安装git clone https://github.com/OpenBMB/UltraRAGcd UltraRAGconda create -n ultrarag python=3.10conda activate ultraragpip install -r requirements.txt# 2. 编写 YAML 配置（见官方文档示例）# vim config.yaml# 3. 启动服务python -m ultrarag.server --config config.yaml

然后用可视化 IDE 调试 Pipeline，一键转成交互式 Web UI。

最后说点暴论：

RAG 1.0 比的是谁的向量数据库更快，谁的 Embedding 模型更准。

RAG 2.0 比的是谁的架构更灵活，谁的组件可复用性更强。

当 Agent 成为主流，RAG 不再是「接个向量数据库」那么简单——它会变成 Agent 的「记忆系统」，需要支持迭代检索、多跳推理、知识图谱、跨模态理解。

这时候，架构的灵活性比单点性能重要得多。

UltraRAG 走的就是这条路：用 MCP 协议把组件标准化，用声明式配置把流程编排化，用统一评测把效果量化。

这不是在做一个更好的 RAG。

这是在做下一代 RAG 系统的基础设施。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～