What retrieval augmentation solutions are included?

这个 repo 内置了哪些检索增强方案

UltraRAG 基于 Model Context Protocol (MCP) 架构，通过 YAML 配置文件的形式内置了多种先进的检索增强生成（RAG）方案。根据仓库中的 examples 和代码实现，内置的主要方案包括：

###1. 基础与进阶 RAG 方案

• Vanilla RAG: 最基础的“检索-生成”模式。
• IRCoT (Interleaved Retrieval Chain-of-Thought): 交替进行检索和思维链推理，利用推理的中间步骤引导后续检索，适用于复杂的多跳查询（参考 examples/ircot.yaml）。
• IterRetGen (Iterative Retrieval-Generation): 迭代地进行检索和生成，通过生成的草稿来改进检索质量，循环往复以提升准确性（参考 examples/iterretgen.yaml）。
• RankCoT (Ranking Chain-of-Thought): 引入了知识精炼（Knowledge Refinement）阶段，在生成回答前先对检索到的知识进行处理和排序（参考 examples/rankcot.yaml）。

###2. 多模态/视觉 RAG (VisRAG)

• VisRAG / EVisRAG: 针对多模态数据的 RAG 方案。它支持直接对文档图像进行检索和理解，避免了传统 OCR 带来的信息损失。UltraRAG 3.0 特别强化了对 VisRAG 2.0 的支持（参考 examples/visrag.yaml, examples/evisrag.yaml）。

###3. 智能体与深度研究方案 (Deep Research)

• LightResearch: 一个轻量级的深度研究管线，支持自动生成研究计划、拆分子问题并进行多轮迭代检索。
• AgentCPM-Report: 专门用于生成研究报告的智能体方案，基于 8B 规模的端侧模型实现本地化的深度研究。
• WebNote: 模仿人类研究笔记的过程，包含计划生成、子问题检索、页面填充等步骤（参考 examples/webnote.yaml）。

###4. 推理模型增强方案 (Reasoning-based Search)

• Search O1 / Search R1: 结合了具有强化推理能力的模型（如 OpenAI o1 或 DeepSeek R1），将模型的思维链（CoT）能力引入搜索和精炼过程，适用于对逻辑要求极高的场景（参考 examples/search_o1.yaml, examples/search_r1.yaml）。

###5. 检索技术变体

• Hybrid Search: 支持混合检索，结合了向量搜索（Vector Search）和关键词搜索（BM25）。
• Web Search: 支持实时网页搜索接入（参考 examples/web_search.yaml）。

###核心特点

这些方案在 UltraRAG 中不是硬编码的，而是通过 MCP Client 编排 MCP Server（如 Retriever Server, Generation Server）来实现的。这意味着你可以通过修改 examples 文件夹下的 YAML 脚本，轻松地：

• 修改循环次数（如 loop: times: 5）。
• 添加条件分支（如根据检索质量决定是否继续检索）。
• 更换模型/提示词（只需更改 YAML 中的参数）。

你可以通过运行 python script/api_usage_example.py 或启动 UltraRAG UI 来体验这些内置 Pipeline。

解释一下 “这些方案在 UltraRAG 中不是硬编码的，而是通过 MCP Client 编排 MCP Server（如 Retriever Server, Generation Server）来实现的。”

这句话揭示了 UltraRAG 的核心架构逻辑。为了让你更清晰地理解，我们可以从 “传统做法” 和 “UltraRAG 的 MCP 做法” 两个维度进行对比：

###1. 什么是“硬编码” (Hard-coded)？

在传统的 RAG 框架中，如果你想实现 IRCoT（交替检索推理），开发者通常需要写一段 Python 代码：

# 传统伪代码
def ircot_pipeline(query):
    for i in range(3):
        context = vector_db.search(query)
        thought = llm.generate(query + context)
        if "answer is" in thought:
            break
        query = thought # 更新查询
    return thought

问题在于： 逻辑被“锁死”在代码里。如果你想把 vector_db 换成网页搜索，或者想把循环次数从 3 改成 5，你必须去修改 Python 源码。

###2. UltraRAG 的 MCP 编排模式

UltraRAG 将 RAG 的各个环节拆解为独立的 MCP Server，并使用 MCP Client 进行动态调度。

####A. MCP Server：原子化的能力单元

你可以把 MCP Server 想象成一个个独立的插件盒。

• Retriever Server: 只负责搜索，不关心谁在调用它。
• Generation Server: 只负责调用大模型生成文本。
• Router Server: 只负责做逻辑判断（比如：回答是否完整？）。

这些 Server 之间是解耦的，通过标准协议（MCP）通信。

####B. MCP Client：中央调度器

UltraRAG 的核心是一个通用的 MCP Client。它不预设任何 RAG 逻辑，它唯一的任务就是：读取 YAML 配置文件，按顺序调用 Server 提供的工具。

####C. YAML 编排：逻辑的可视化

以 ircot.yaml 为例，复杂的逻辑变成了配置：

pipeline:
- retriever.retriever_init  # 调用检索服务器初始化
- loop:                     # 这是一个循环结构，由 Client 实现
    times: 3
    steps:
    - retriever.retriever_search  # 调用检索工具
    - generation.generate         # 调用生成工具
    - branch:                     # 分支判断
        router:
        - router.ircot_check_end  # 调用路由服务器判断是否结束

在这个模式下，UltraRAG 本身并不“拥有” IRCoT 算法，它只是通过这个配置文件，把“检索”、“生成”、“判断”这三个动作编排在了一起。

###3. 这样做的好处是什么？

1. 极低的学习和修改门槛：

   • 如果你想把 IRCoT 变成单轮 RAG，你不需要写 Python，只需要删掉 YAML 里的 loop 节点。
   • 如果你想在检索前加一个“Query 改写”，只需在 YAML 中插入一行 prompt.rewrite_query。

2. 组件可复用性（Plug & Play）：

   • 你的 Retriever Server 既可以用在普通的问答 Pipeline 里，也可以直接挪到 DeepResearch Pipeline 里。因为接口是 MCP 标准化的，就像乐高积木一样。

3. 跨语言与跨环境：

   • MCP Server 可以用 Python 写，也可以用 Go 或 TypeScript 写。只要它们遵循 MCP 协议，UltraRAG 的 Client 就能编排它们。

###总结

“非硬编码” 意味着 UltraRAG 像是一个 “工作流引擎”。它内置的 IRCoT、RankCoT 等方案，本质上是官方提供的 “最佳实践配置文件 (YAML)”。你可以像修改文档一样，随时定制、组合或创造全新的 RAG 方案，而无需深入框架底层修改代码。