RAG-Architectures：六种 RAG 范式一站式对比实验场

一位开发者的"强迫症"：为什么需要 6 种 RAG？

想象你是一个 RAG 新手，面对"向量检索增强生成"这个概念，搜遍了全网教程，却发现每篇文章讲得都不一样——有人用 Embedding 直接匹配，有人加了个重排序，有人又扯上知识图谱，还有人说要用 Agent 动态规划。你开始怀疑：到底哪种方法才是正确的？

西班牙开发者 Jaime IrazaBal 或许也有过同样的困惑。他的答案是：与其在理论中绕圈圈，不如把目前主流的 6 种 RAG 架构全部实现一遍，做成可以一键启动的微服务。哪个好用、哪个坑多，跑一跑就知道。

这就是 rag-architectures 的诞生动机：一个收录了 Naïve RAG、Advanced RAG、Modular RAG、GraphRAG、Agentic RAG 和 Hybrid RAG 六种完整实现的对比实验平台，每个都是可以独立运行的 REST API 服务。

---

从"朴素检索"到"混合增强"：六种范式逐个拆解

1. Naïve RAG：最原始的 RAG 起点

这是 RAG 的"Hello World"。工作流极为直接：文档分块（Chunking）→ 向量化（Embedding）→ 存储向量数据库 → 用户提问时，检索最相似的 Top-K 块 → 将块作为上下文注入 LLM Prompt → 生成回答。

这套流程的局限也很明显：检索质量直接决定回答质量。如果 Embedding 模型不够精准，或者分块策略不当，有效信息可能被埋在噪声后面，导致 LLM"看到"的是错误上下文，回答自然跑偏。

2. Advanced RAG：在检索侧下功夫

Advanced RAG 针对"检索"这个薄弱环节做了多轮优化。典型策略包括：查询改写（Query Rewriting）——用 LLM 将用户模糊的提问重写为更精确的查询语句；重排序（Re-ranking）——先用 Embedding 快速召回一批候选，再用一个更精准的交叉编码器模型（如 Cohere Rerank）重新排序，提升 Top 结果的相关性。

这种"先海选再精选"的两阶段检索，是工业级 RAG 系统中最常见的标配。

3. Modular RAG：像搭积木一样自由组合

Modular RAG 的核心思想是解耦。它将 RAG 流程中的各个环节（检索器、重排序器、生成器、记忆模块等）拆成独立可插拔的模块，通过配置文件或代码层面的模块注册机制，让开发者可以自由组合不同的策略。

这解决了 Advanced RAG"写死逻辑"的问题：你想试试换一个 Embedding 模型？换一个重排序方法？Modular 架构下只需改配置，不用重写代码。

4. GraphRAG：用知识图谱弥补全局理解

传统向量检索只能找到"语义相似"的片段，但无法回答"整体主题是什么"这类需要全局理解的问题。GraphRAG 引入知识图谱来解决：

1. 用 LLM 从每个文本块中提取实体（人名、地点、概念等）
2. 实体之间若有共现关系则建立图边（Edge），权重表示共现频率
3. 检索时不仅找相似块，还通过图遍历找到相关实体及其关联上下文

这套方法在微软 GraphRAG 论文中大放异彩，特别适合处理需要理解文档整体语义的任务——比如"这篇论文的核心贡献是什么"，而非"某个具体概念在哪里"。

代码中用 NetworkX 构建和管理知识图谱，实体通过 extract_entities() 函数由 LLM 自动提取。

5. Agentic RAG：让 Agent 自主规划检索策略

Agentic RAG 引入了工具调用和动态决策机制。服务中内置多个工具（向量检索、网页搜索、计算器等），LLM 作为 Agent，根据用户问题自主决定调用哪个工具、用几次、结果如何整合。

关键在于 MAX_ITERATIONS = 6——Agent 最多循环 6 次，可以不断修正策略、补充信息，直到给出满意答案或达到迭代上限。这比传统 RAG"一次检索+一次生成"的固定流程灵活得多。

值得注意的是，Agentic RAG 集成了 DuckDuckGo 网页搜索作为工具之一，使得系统具备实时联网能力，不再局限于本地知识库。

6. Hybrid RAG：向量 + 关键词的双塔检索

Hybrid RAG 结合了向量检索和传统关键词检索的优点。向量检索擅长捕捉语义相似性，但面对专有名词、型号、代码片段时往往力不从心；TF-IDF 这类关键词检索则对这些精确匹配有天然优势。

项目使用 scikit-learn 的 TfidfVectorizer 实现 BM25 风格的关键词检索，最终通过加权融合两种检索结果，给出更全面的上下文。avg_doc_length 参数用于归一化不同检索方式的分数，确保两者在同一尺度上可比较。

---

技术架构：FastAPI 微服务 + 共享模块

六个服务（01-06）各自独立，通过 docker-compose.yml 统一编排。每个服务：

• 基础镜像：python:3.11-slim
• 入口：uvicorn main:app --host 0.0.0.0 --port 800X
• 端口：8001（Naïve）→ 8006（Hybrid），互不冲突
• 共享模块：shared/ 目录通过 sys.path.insert(0, "/app/shared") 注入，提供统一的 Embedding（sentence-transformers/all-MiniLM-L6-v2）、分块、LLM 调用能力

LLM 层面完全解耦：通过 LLM_BASE_URL 环境变量指向任何 OpenAI API 兼容的端点——本地 Ollama（默认）、OpenAI API、vLLM 均可。shared/llm.py 中的 LLMClient 负责统一封装，调用方无需关心底层细节。

---

部署体验：一键启动的对比实验

通过 docker-compose up 即可同时启动全部 6 个服务，默认连接本地 Ollama（http://host.docker.internal:11434/v1）。无需额外部署向量数据库——项目直接在内存中管理向量（numpy.ndarray）。

每个服务暴露 /ingest（文档摄入）和 /query（问答）两个核心端点，接口设计完全统一，便于用同一套测试脚本批量对比 6 种架构的表现。

---

上手门槛与局限

优势：

• 6 种架构开箱即用，无需逐个从零搭建
• 文档极为详细（MANUAL.md 覆盖完整原理和对比分析）
• 完全本地化运行，数据不外泄

需要注意的地方：

• 无 Web UI，纯 REST API，调试需要用 curl 或 Postman
• 无测试覆盖率数据，代码未经过 CI 验证
• GraphRAG 和 Agentic RAG 依赖 LLM 做实体提取/工具规划，对 LLM 质量敏感
• 内存占用随文档量线性增长，大规模场景需额外优化

---

行业意义：RAG 进化的活标本

从 2023 年到 2025 年，RAG 技术经历了从"朴素检索"到"知识图谱增强"再到"Agent 动态规划"的快速迭代。这个项目用微服务架构将这些里程碑串联起来，让开发者可以直观感受到每种范式的适用场景与取舍。

如果你正在为业务选择合适的 RAG 方案，或者想深入理解 RAG 各变体的内在逻辑，这个项目是最好的起点——跑通全部 6 种，对比答案质量，答案自然浮现。