RAG 生态与选型 on 扎塔-Zata

Graph RAG 开源项目全景：从微软 GraphRAG 到 LightRAG

Fri, 27 Mar 2026 16:00:00 +0800

传统 RAG 的核心思路是"向量检索 + 生成"，但在处理需要多跳推理、全局理解的问题时，效果往往不理想。

Graph RAG（知识图谱 + RAG）通过构建文档间的实体关系网络，让检索不再局限于局部相似度匹配，而是能够进行图遍历、社区发现、路径推理。这让 RAG 系统能回答更复杂的问题。

这篇文章系统梳理 Graph RAG 的主流开源项目，帮你快速了解和选型。

一、为什么需要 Graph RAG

传统 RAG 的局限

问题 1：多跳推理

用户问："A 公司的合作方的竞争对手有哪些？"

传统 RAG：
1. 检索"A 公司的合作方" → 找到 B 公司
2. 检索"B 公司的竞争对手" → 找到 C、D 公司

问题：
- 需要两轮检索，中间结果可能丢失
- 无法自动发现推理路径

Graph RAG：
A 公司 --合作--> B 公司 --竞争--> C、D 公司
一次图遍历即可完成

问题 2：全局理解

用户问："这篇文章的核心观点是什么？"

传统 RAG：
- 检索 Top-K 相关段落
- 但核心观点可能分散在各处
- 无法形成全局视角

Graph RAG：
- 通过社区发现，将文档划分为多个主题
- 每个社区生成摘要
- 整合社区摘要，形成全局理解

Graph RAG 的核心思路

传统 RAG：
文档 → Chunk → 向量化 → 向量检索

Graph RAG：
文档 → 实体抽取 → 关系抽取 → 知识图谱
 ↓
 图检索 + 向量检索
 ↓
 LLM 生成

二、主流框架概览

框架	Stars	作者	核心特点	适用场景
LightRAG	36K+	港大 HKUDS	轻量快速，双层检索	中小规模，实时更新
GraphRAG	33K+	Microsoft	社区摘要，全局理解	大规模文档
HippoRAG	3.5K+	俄亥俄州立	模拟海马体记忆	长期记忆系统
Fast-GraphRAG	3.8K+	Circlemind	自适应，快速	快速部署
Neo4j Graph Builder	4.7K+	Neo4j	企业级图数据库	可视化，企业应用
R2R	7.8K+	SciPhi AI	生产级，完整方案	企业部署

下面逐一详细介绍。

三、Microsoft GraphRAG

基本信息

GitHub: https://github.com/microsoft/graphrag
Stars: 33,800+
论文: GraphRAG: Unlocking LLM Discovery on Narrative Private Data
语言: Python

核心原理

GraphRAG 的核心创新是社区发现 + 社区摘要：

Step 1: 知识图谱构建
文档 → 实体抽取 → 关系抽取 → 图存储

Step 2: 社区发现
用 Leiden 算法将图划分为多个社区
每个社区是一个紧密相关的实体群组

Step 3: 社区摘要
对每个社区，用 LLM 生成摘要
摘要包含社区的核心实体和关系

Step 4: 检索
局部查询：从相关实体出发，图遍历
全局查询：检索社区摘要，整合回答

架构图

┌──────────────────────────────────────────────────────┐
│ Microsoft GraphRAG Pipeline │
└──────────────────────────────────────────────────────┘
 │
 ▼
 ┌──────────────────┐
 │ 文档输入 │
 └────────┬─────────┘
 │
 ┌──────────────┼───────────────┐
 ▼ ▼ ▼
 ┌─────────┐ ┌──────────┐ ┌──────────┐
 │ 文本分块 │ │ 实体抽取 │ │ 关系抽取 │
 └────┬────┘ └────┬─────┘ └────┬─────┘
 │ │ │
 └──────────────┼───────────────┘
 ▼
 ┌──────────────────┐
 │ 知识图谱 │
 │ (NetworkX) │
 └────────┬─────────┘
 │
 ▼
 ┌──────────────────┐
 │ 社区发现 │
 │ (Leiden) │
 └────────┬─────────┘
 │
 ▼
 ┌──────────────────┐
 │ 社区摘要 │
 │ (LLM 生成) │
 └────────┬─────────┘
 │
 ┌──────────────┼───────────────┐
 ▼ ▼ ▼
 ┌─────────┐ ┌──────────┐ ┌──────────┐
 │ 局部查询 │ │ 全局查询 │ │ 混合查询 │
 └────┬────┘ └────┬─────┘ └────┬─────┘
 │ │ │
 └──────────────┼───────────────┘
 ▼
 ┌──────────────────┐
 │ LLM 生成答案 │
 └──────────────────┘

快速开始

# 安装
pip install graphrag

# 初始化项目
python -m graphrag.index --init --root ./ragtest

# 配置（settings.yaml）
graphrag:
 llm:
 type: openai_chat
 model: gpt-4o
 embeddings:
 type: openai_embedding
 model: text-embedding-3-small

# 构建索引
python -m graphrag.index --root ./ragtest

# 查询
python -m graphrag.query --root ./ragtest --method local "What is the main topic?"
python -m graphrag.query --root ./ragtest --method global "What are the key themes?"

查询模式

Local Search（局部查询）：
- 从问题中识别实体
- 扩展实体的邻居节点
- 用局部子图生成答案
- 适合：具体事实查询

Global Search（全局查询）：
- 检索相关社区摘要
- 整合多个社区的信息
- 形成全局视角
- 适合："核心观点"、"主要主题"类问题

DRIFT Search（混合查询）：
- 结合局部和全局
- 动态调整检索范围
- 适合：复杂推理问题

优缺点

优点：
✅ 全局理解能力强（社区摘要）
✅ 微软官方维护，质量有保障
✅ 论文驱动，原理清晰
✅ 支持多种查询模式

缺点：
❌ 索引构建慢（需要多次 LLM 调用）
❌ 成本高（实体抽取、关系抽取、社区摘要）
❌ 不适合实时更新（重建索引代价大）
❌ 需要一定学习成本

适用场景

✅ 推荐：
- 大规模文档库（10K+ 文档）
- 需要全局理解（"核心观点"、"主要趋势"）
- 需要多跳推理
- 离线构建，在线查询

❌ 不推荐：
- 小规模知识库
- 需要实时更新
- 成本敏感

四、LightRAG

基本信息

GitHub: https://github.com/HKUDS/LightRAG
Stars: 36,600+
论文: LightRAG: Simple and Fast Retrieval-Augmented Generation (EMNLP 2025)
作者: 香港大学数据科学实验室
语言: Python

核心创新

LightRAG 针对 GraphRAG 的痛点做了优化：

GraphRAG 的问题：
1. 索引构建慢：需要多次 LLM 调用
2. 成本高：实体抽取、关系抽取、社区摘要
3. 不支持实时更新

LightRAG 的解决方案：
1. 双层检索：低层（实体）+ 高层（关键概念）
2. 无需社区发现：用双层图代替
3. 流式插入：支持实时更新
4. 轻量存储：无需图数据库，文件即可

双层检索原理

传统 GraphRAG：
文档 → 实体 → 图 → 社区发现 → 社区摘要 → 检索

LightRAG：
文档 → 实体 + 关键概念 → 双层图 → 直接检索

双层图结构：
┌─────────────────────────────────────┐
│ 高层（关键概念层） │
│ [AI] ── [机器学习] ── [深度学习] │
│ │ │ │ │
├─────────┼───────────┼───────────┼───┤
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 低层（实体层） │
│ [GPT-4] [神经网络] [CNN/RNN] │
└─────────────────────────────────────┘

查询时：
1. 先在高层找到相关概念
2. 再在低层找到具体实体
3. 双层结果融合

快速开始

# 安装
pip install lightrag-hku

# 基础使用
from lightrag import LightRAG
from lightrag.llm import openai_complete_if_cache, openai_embedding

# 初始化
rag = LightRAG(
 working_dir="./rag_storage",
 llm_model_func=openai_complete_if_cache,
 embedding_func=openai_embedding
)

# 插入文档
with open("document.txt", "r") as f:
 rag.insert(f.read())

# 查询
result = rag.query("What is machine learning?", mode="hybrid")

# 查询模式
result = rag.query("...", mode="naive") # 纯向量检索
result = rag.query("...", mode="local") # 局部图检索
result = rag.query("...", mode="global") # 全局图检索
result = rag.query("...", mode="hybrid") # 混合检索

性能对比（官方数据）

索引构建时间：
- GraphRAG: 100 分钟
- LightRAG: 10 分钟
- 提升: 10x

查询时间：
- GraphRAG: 2 秒
- LightRAG: 0.3 秒
- 提升: 6x

成本（Token 消耗）：
- GraphRAG: $10
- LightRAG: $1
- 降低: 90%

准确率：
- GraphRAG: 45%
- LightRAG: 52%
- 提升: 7%

优缺点

优点：
✅ 快：索引和查询都很快
✅ 省：成本降低 50-90%
✅ 灵活：支持实时插入更新
✅ 简单：无需图数据库
✅ 准确：双层检索更精准

缺点：
❌ 全局理解不如 GraphRAG（无社区摘要）
❌ 大规模场景下，图文件可能很大
❌ 功能相对简单

适用场景

✅ 推荐：
- 中小规模知识库（< 10K 文档）
- 需要实时更新
- 成本敏感
- 快速原型

❌ 不推荐：
- 超大规模文档
- 需要深度全局理解

五、HippoRAG

基本信息

GitHub: https://github.com/OSU-NLP-Group/HippoRAG
Stars: 3,500+
论文: HippoRAG: A Neurobiological Framework for Long-Term Memory (NeurIPS 2024)
作者: 俄亥俄州立大学
语言: Python

核心原理：模拟海马体

人类记忆机制：
海马体（Hippocampus）：
- 索引新记忆
- 将记忆整合到大脑皮层

大脑皮层：
- 存储长期记忆
- 知识以网络形式组织

检索时：
- 从海马体获取线索
- 在大脑皮层中激活相关记忆
- 通过联想找到答案

HippoRAG 的实现：
海马体 → 向量索引（快速找到入口）
大脑皮层 → 知识图谱（关联检索）
检索 → Personalized PageRank（模拟联想）

架构图

┌──────────────────────────────────────────────────────┐
│ HippoRAG 架构 │
└──────────────────────────────────────────────────────┘

索引阶段：
文档 → Passage 节点 → 向量化（海马体索引）
 → 实体抽取 → 实体节点
 → 关系抽取 → 边
 → 知识图谱（大脑皮层）

检索阶段：
Query → 向量化 → 找到相关 Passage 节点
 ↓
 Personalized PageRank
 （从入口节点扩散）
 ↓
 激活相关实体和 Passage
 ↓
 LLM 生成答案

Personalized PageRank

传统 PageRank：
- 所有节点平等
- 计算全局重要性

Personalized PageRank：
- 从特定节点出发（Query 相关的 Passage）
- 计算相对这些节点的重要性
- 模拟"联想"过程

示例：
Query: "GPT-4 的训练数据"

Step 1: 向量检索找到入口 Passage
入口节点: [Passage_A, Passage_B]

Step 2: Personalized PageRank
从 Passage_A、Passage_B 出发
计算其他节点的激活程度

Step 3: 激活扩散
Passage_A → 实体"GPT-4" → 实体"训练数据" → Passage_C
Passage_B → 实体"OpenAI" → 实体"GPT-4" → ...

Step 4: 收集高激活度的 Passage
Top-K: [Passage_A, Passage_B, Passage_C, ...]

Step 5: LLM 生成答案

快速开始

# 安装
pip install hipporag

# 使用
from hipporag import HippoRAG

rag = HippoRAG(
 graph_db="neo4j", # 支持 Neo4j 或 NetworkX
 llm_model="gpt-4",
 embedding_model="text-embedding-3-small"
)

# 索引
rag.index("./documents")

# 查询
result = rag.query("What are the key features of GPT-4?")

适用场景

✅ 推荐：
- 长期记忆系统
- 持续学习的知识库
- 需要精准检索
- 个性化 RAG

❌ 不推荐：
- 简单问答场景
- 成本敏感

六、Neo4j + RAG 方案

Neo4j LLM Graph Builder

GitHub: https://github.com/neo4j-labs/llm-graph-builder
Stars: 4,700+
作者: Neo4j 官方
语言: Python

核心特点

Neo4j 的优势：
1. 成熟的图数据库
2. 强大的 Cypher 查询语言
3. 可视化工具（Neo4j Browser）
4. 企业级支持

LLM Graph Builder 的功能：
1. 从非结构化文本构建知识图谱
2. 支持多种 LLM（OpenAI、Azure、Gemini、Ollama）
3. 实体和关系抽取
4. 图谱可视化

工作流程

┌──────────────────────────────────────────────────────┐
│ Neo4j Graph Builder Pipeline │
└──────────────────────────────────────────────────────┘
 │
 ▼
 ┌──────────────────┐
 │ 文档输入 │
 │ (PDF/TXT/URL) │
 └────────┬─────────┘
 │
 ▼
 ┌──────────────────┐
 │ 文本分块 │
 └────────┬─────────┘
 │
 ▼
 ┌──────────────────┐
 │ LLM 实体抽取 │
 │ "苹果公司" → Organization │
 │ "库克" → Person │
 └────────┬─────────┘
 │
 ▼
 ┌──────────────────┐
 │ LLM 关系抽取 │
 │ (苹果公司, CEO, 库克) │
 └────────┬─────────┘
 │
 ▼
 ┌──────────────────┐
 │ 存入 Neo4j │
 │ CREATE (a:Org {name:"苹果"})│
 │ CREATE (b:Person {name:"库克"})│
 │ CREATE (a)-[:CEO]->(b) │
 └────────┬─────────┘
 │
 ▼
 ┌──────────────────┐
 │ 图检索 + LLM │
 └──────────────────┘

快速开始

# 安装
pip install neo4j-graphrag

from neo4j import GraphDatabase
from neo4j_graphrag.llm import OpenAILLM
from neo4j_graphrag.embeddings import OpenAIEmbeddings
from neo4j_graphrag.generation import GraphRAG

# 连接 Neo4j
driver = GraphDatabase.driver(
 "bolt://localhost:7687",
 auth=("neo4j", "password")
)

# 初始化
llm = OpenAILLM(model_name="gpt-4")
embedder = OpenAIEmbeddings()
rag = GraphRAG(driver, llm, embedder)

# 构建图谱
rag.build_graph("./documents")

# 查询
result = rag.search("Who is the CEO of Apple?")

适用场景

✅ 推荐：
- 企业级应用
- 需要可视化
- 已有 Neo4j 基础设施
- 复杂图查询

❌ 不推荐：
- 小规模、轻量场景
- 不想维护图数据库

七、其他值得关注的项目

1. Fast-GraphRAG

GitHub: https://github.com/circlemind-ai/fast-graphrag
Stars: 3,800+

特点：
- 自适应：根据数据和查询自动调整
- 快速：优化的检索算法
- 简单：开箱即用

适用：快速部署，数据多样

2. R2R (Reason to Retrieve)

GitHub: https://github.com/SciPhi-AI/R2R
Stars: 7,800+

特点：
- 生产级 RAG 系统
- Agentic RAG（Agent + RAG）
- 支持知识图谱
- 完整 RESTful API
- 评估工具

适用：企业级部署

3. graph-rag-agent（拼好RAG）

GitHub: https://github.com/1517005260/graph-rag-agent
Stars: 2,200+

特点：
- 融合 GraphRAG + LightRAG + Neo4j
- DeepSearch 推理能力
- 自制 GraphRAG 评估框架
- 国产项目，中文友好

适用：学习对比，评估测试

4. Medical-Graph-RAG

GitHub: https://github.com/ImprintLab/Medical-Graph-RAG
Stars: 800+
论文: ACL 2025

特点：
- 医疗领域专用
- 循证医学信息检索
- 医学实体识别优化

适用：医疗知识库

5. GraphRAG-Local-UI

GitHub: https://github.com/severian42/GraphRAG-Local-UI
Stars: 2,300+

特点：
- 支持本地 LLM（Ollama）
- 完整 UI 界面
- 索引/调参/查询/可视化
- 无需云端 API

适用：本地部署，隐私敏感

八、框架对比

性能对比

指标	GraphRAG	LightRAG	HippoRAG
索引速度	慢	快 10x	中等
查询速度	中等	快 5x	快
成本	高	低 50-90%	中等
全局理解	强	中等	中等
局部检索	强	强	很强
实时更新	❌	✅	✅

功能对比

功能	GraphRAG	LightRAG	HippoRAG	Neo4j
社区发现	✅	❌	❌	✅
双层检索	❌	✅	❌	❌
PageRank	❌	❌	✅	✅
可视化	❌	❌	❌	✅
本地部署	✅	✅	✅	✅
流式插入	❌	✅	✅	✅

适用场景对比

大规模文档（10K+）：
1. GraphRAG（全局理解）
2. Neo4j + RAG（企业级）

中小规模（< 10K）：
1. LightRAG（快速、低成本）
2. Fast-GraphRAG（简单部署）

长期记忆：
1. HippoRAG（模拟海马体）

医疗/专业领域：
1. Medical-Graph-RAG
2. KG_RAG

本地部署：
1. GraphRAG-Local-UI
2. LightRAG + Ollama

九、选型决策树

开始选型
 │
 ├─ 需要全局理解（"核心观点"、"主要趋势"）？
 │ ├─ 是 → Microsoft GraphRAG
 │ └─ 否 → 继续
 │
 ├─ 需要实时更新？
 │ ├─ 是 → LightRAG
 │ └─ 否 → 继续
 │
 ├─ 需要可视化？
 │ ├─ 是 → Neo4j + RAG
 │ └─ 否 → 继续
 │
 ├─ 长期记忆系统？
 │ ├─ 是 → HippoRAG
 │ └─ 否 → 继续
 │
 ├─ 成本敏感？
 │ ├─ 是 → LightRAG
 │ └─ 否 → 继续
 │
 ├─ 快速原型？
 │ ├─ 是 → LightRAG / Fast-GraphRAG
 │ └─ 否 → 继续
 │
 └─ 企业级部署？
 ├─ 是 → R2R / Neo4j + RAG
 └─ 否 → LightRAG

十、学习资源

必读论文

1. GraphRAG: Unlocking LLM Discovery on Narrative Private Data
 - Microsoft GraphRAG 原始论文
 - 社区发现 + 社区摘要的核心思想

2. LightRAG: Simple and Fast Retrieval-Augmented Generation
 - EMNLP 2025
 - 双层检索的设计

3. HippoRAG: A Neurobiological Framework for Long-Term Memory
 - NeurIPS 2024
 - 模拟海马体的记忆机制

4. From Local to Global: A Graph RAG Approach to Query-Focused Summarization
 - 图检索到全局理解的演进

开源资源

Awesome-GraphRAG:
https://github.com/DEEP-PolyU/Awesome-GraphRAG
- 论文、项目、基准测试汇总

GraphRAG 深度学习:
https://github.com/JayLZhou/GraphRAG
- GraphRAG 源码解读

LightRAG 实验对比:
https://github.com/NanGePlus/LightRAGTest
- LightRAG vs GraphRAG 性能对比

官方文档

Microsoft GraphRAG:
https://microsoft.github.io/graphrag/

LightRAG:
https://github.com/HKUDS/LightRAG/blob/main/README.md

Neo4j GraphRAG:
https://neo4j.com/docs/graphrag-manual/

十一、总结

Graph RAG 是 RAG 技术的重要演进方向，让检索从"局部相似度匹配"升级为"全局图推理"。

核心框架对比：

Microsoft GraphRAG：
- 定位：大规模文档，全局理解
- 优势：社区摘要，全局视角
- 代价：构建慢，成本高

LightRAG：
- 定位：中小规模，快速部署
- 优势：快速、低成本、实时更新
- 代价：全局理解较弱

HippoRAG：
- 定位：长期记忆，精准检索
- 优势：模拟海马体，联想检索
- 代价：相对复杂

Neo4j + RAG：
- 定位：企业级，可视化
- 优势：成熟图数据库，生态完善
- 代价：需要维护数据库

选型建议：

快速上手：LightRAG
全局理解：Microsoft GraphRAG
企业部署：Neo4j + RAG 或 R2R
长期记忆：HippoRAG
本地部署：GraphRAG-Local-UI

没有银弹，关键是根据场景选择合适的工具。

相关文章：

RAG 技术全景：从入门到进阶

Thu, 26 Mar 2026 16:00:00 +0800

前面我们分析了 RAGFlow，它解决了"从文档到答案"的核心问题。但 RAG 领域发展极快，除了文档解析、Chunking、混合检索这些基础能力，还有很多值得关注的技术方向。

这篇文章会系统梳理 RAG 的技术演进路线，帮你建立完整的知识图谱。

一、RAG 的技术演进

RAG 1.0：检索 + 生成
Query → 向量检索 → LLM 生成

RAG 2.0：多路检索 + Rerank + 引用溯源
Query → 多路检索 → 融合 → Rerank → 生成 + 引用

RAG 3.0：Agentic RAG + Graph RAG + 多模态
Query → Agent 规划 → 多轮检索/推理 → 反思修正 → 生成

下面按技术方向逐一展开。

二、Graph RAG：知识图谱 + RAG

本文对 Graph RAG 做概要介绍，详细的开源项目分析和选型指南请参阅 Graph RAG 开源项目全景：从微软 GraphRAG 到 LightRAG。

为什么需要 Graph RAG

传统 RAG 的局限：

问题："A 公司的合作方的竞争对手有哪些？"

传统 RAG：
1. 检索"A 公司的合作方" → 找到 B 公司
2. 检索"B 公司的竞争对手" → 找到 C、D 公司
问题：需要多轮检索，且中间结果可能丢失

Graph RAG：
1. 从知识图谱中找到 A → 合作 → B
2. 从知识图谱中找到 B → 竞争 → C、D
优势：一次图遍历即可完成多跳推理

Graph RAG 的架构

┌──────────────────────────────────────────────────────┐
│ Graph RAG Pipeline │
└──────────────────────────────────────────────────────┘
 │
 ┌───────────────┼───────────────┐
 ▼ ▼ ▼
 ┌─────────┐ ┌──────────┐ ┌──────────┐
 │ 文档输入 │ │ 实体抽取 │ │ 关系抽取 │
 └────┬────┘ └────┬─────┘ └────┬─────┘
 │ │ │
 └──────────────┼───────────────┘
 ▼
 ┌──────────────────┐
 │ 知识图谱构建 │
 │ (Neo4j / NetworkX) │
 └────────┬─────────┘
 │
 ┌──────────────┼───────────────┐
 ▼ ▼ ▼
 ┌─────────┐ ┌──────────┐ ┌──────────┐
 │ 向量检索 │ │ 图检索 │ │ 混合检索 │
 └────┬────┘ └────┬─────┘ └────┬─────┘
 │ │ │
 └──────────────┼───────────────┘
 ▼
 ┌──────────────────┐
 │ LLM 生成答案 │
 └──────────────────┘

核心技术点

1. 实体抽取

输入文档："苹果公司由史蒂夫·乔布斯于 1976 年创立，总部位于加利福尼亚州库比蒂诺。"

实体抽取结果：
- 苹果公司（Organization）
- 史蒂夫·乔布斯（Person）
- 1976 年（Date）
- 加利福尼亚州库比蒂诺（Location）

技术方案：
- NER 模型（spaCy、Stanford NER）
- LLM 抽取（GPT-4、Qwen）
- 开源工具（DeepKE、OpenIE）

2. 关系抽取

关系抽取结果：
- 苹果公司 -- 创立者 --> 史蒂夫·乔布斯
- 苹果公司 -- 创立时间 --> 1976 年
- 苹果公司 -- 总部位置 --> 加利福尼亚州库比蒂诺

3. 图检索策略

策略 1：子图检索
- 找到问题中的实体节点
- 扩展 N 跳邻居
- 将子图转为文本，喂给 LLM

策略 2：路径检索
- 找到起点和终点实体
- 检索两点间的路径
- 路径上的节点/边作为上下文

策略 3：社区检索
- 预先对图谱做社区发现
- 检索相关社区
- 社区摘要作为上下文

代表项目

项目	特点	适用场景
Microsoft GraphRAG	微软官方，社区摘要	大规模文档全局理解
LightRAG	轻量级，无图数据库依赖	快速部署
Neo4j + LangChain	成熟图数据库，生态完善	企业级应用
LlamaIndex GraphRAG	与 LlamaIndex 深度集成	已有 LlamaIndex 项目

适用场景

✅ 推荐使用 Graph RAG：
- 需要多跳推理（"A 的 B 的 C 是什么"）
- 需要全局理解（"这篇文章的核心观点"）
- 实体关系密集（知识库、企业图谱）
- 需要可解释的推理路径

❌ 不推荐：
- 文档间无关联
- 问题简单，单次检索可解
- 实体稀疏，图构建成本高

三、Agentic RAG：Agent + RAG

从被动检索到主动规划

传统 RAG（被动）：
Query → 检索 → 生成
问题：检索策略固定，无法应对复杂问题

Agentic RAG（主动）：
Query → Agent 规划 → 执行 → 反思 → 再规划 → ...

Agentic RAG 的核心能力

1. 查询理解与改写

原始问题："那个产品怎么样"
↓ LLM 分析
问题太模糊，需要澄清

改写策略：
1. 分解问题："那个产品" → 识别具体产品
2. 扩展问题：生成多个相关 Query
3. HyDE：生成假设性答案，用答案检索

示例：
Query: "报销流程"
↓
改写为：
1. "公司报销流程步骤"
2. "报销需要哪些材料"
3. "报销审批流程"

2. 迭代检索

第一轮检索：
Query: "A 公司的融资情况"
结果: A 公司 B 轮融资 5000 万

判断：信息不完整，缺少投资方
↓
第二轮检索：
Query: "A 公司 B 轮投资方"
结果: 红杉资本领投

判断：信息完整
↓
生成答案

3. 工具调用

Agent 可用的工具：
- 向量检索：检索内部知识库
- 关键词检索：BM25 搜索
- 联网搜索：Google/Bing API
- SQL 查询：查询结构化数据
- API 调用：获取实时信息

示例：
Query: "今天北京天气怎么样，适合户外活动吗？"
↓ Agent 规划
1. 调用天气 API 获取北京天气
2. 检索知识库中"户外活动适宜条件"
3. 综合判断并回答

4. 自我反思

生成答案后，Agent 自我评估：

评估维度：
- 答案是否完整？
- 是否需要补充检索？
- 是否有矛盾信息？

示例：
答案："A 公司成立于 2010 年"
反思：检索结果中有两个年份（2010 和 2012），需要验证
↓
再次检索："A 公司成立时间 官方"
↓
修正答案

Agentic RAG 架构

┌──────────────────────────────────────────────────────┐
│ Agentic RAG │
└──────────────────────────────────────────────────────┘
 │
 ▼
 ┌──────────────────┐
 │ Query 分析 │
 │ - 意图识别 │
 │ - 实体抽取 │
 │ - 查询改写 │
 └────────┬─────────┘
 │
 ▼
 ┌──────────────────┐
 │ 规划器 │
 │ - 分解任务 │
 │ - 选择工具 │
 │ - 生成执行计划 │
 └────────┬─────────┘
 │
 ┌──────────────┼───────────────┐
 ▼ ▼ ▼
 ┌─────────┐ ┌──────────┐ ┌──────────┐
 │ 向量检索 │ │ 联网搜索 │ │ SQL 查询 │
 └────┬────┘ └────┬─────┘ └────┬─────┘
 │ │ │
 └──────────────┼───────────────┘
 ▼
 ┌──────────────────┐
 │ 反思器 │
 │ - 结果评估 │
 │ - 是否继续检索 │
 │ - 是否需要修正 │
 └────────┬─────────┘
 │
 ▼
 ┌──────────────────┐
 │ LLM 生成答案 │
 └──────────────────┘

代表框架

框架	特点	适用场景
LangGraph	LangChain 出品，状态机模型	复杂工作流
AutoGPT + RAG	自主 Agent	开放域任务
CrewAI	多 Agent 协作	团队式任务
LlamaIndex Agent	内置 RAG Agent	快速构建

适用场景

✅ 推荐使用 Agentic RAG：
- 问题复杂，需要多步推理
- 需要调用多种工具
- 需要实时信息（联网、API）
- 需要自我纠错

❌ 不推荐：
- 问题简单，单次检索可解
- 对延迟敏感（Agent 会增加延迟）
- 成本敏感（多轮 LLM 调用）

四、多模态 RAG

为什么需要多模态

企业知识库不只是文本：
- 产品手册：文字 + 图片 + 示意图
- 技术文档：文字 + 代码 + 架构图
- 财务报告：文字 + 表格 + 图表
- 培训视频：音频 + 视频 + 字幕

多模态 RAG 架构

┌──────────────────────────────────────────────────────┐
│ 多模态 RAG Pipeline │
└──────────────────────────────────────────────────────┘
 │
 ┌───────────────┼───────────────┐
 ▼ ▼ ▼
 ┌─────────┐ ┌──────────┐ ┌──────────┐
 │ 文本 │ │ 图片 │ │ 表格 │
 │ 处理 │ │ 处理 │ │ 处理 │
 └────┬────┘ └────┬─────┘ └────┬─────┘
 │ │ │
 ▼ ▼ ▼
 ┌─────────┐ ┌──────────┐ ┌──────────┐
 │ 文本 │ │ VLM 描述 │ │ 结构化 │
 │ Embedding│ │ Embedding│ │ 存储 │
 └────┬────┘ └────┬─────┘ └────┬─────┘
 │ │ │
 └──────────────┼───────────────┘
 ▼
 ┌──────────────────┐
 │ 统一向量存储 │
 └────────┬─────────┘
 │
 ▼
 ┌──────────────────┐
 │ 多模态检索 │
 │ - 文本 Query │
 │ - 图片 Query │
 └────────┬─────────┘
 │
 ▼
 ┌──────────────────┐
 │ 多模态生成 │
 │ (GPT-4V, Qwen-VL)│
 └──────────────────┘

各模态的处理方式

1. 图片

方案 1：VLM 描述
图片 → VLM → 文字描述 → Embedding

方案 2：直接 Embedding
图片 → CLIP/SigLIP → 图片向量

方案 3：混合
图片 → VLM 描述 + CLIP 向量 → 双路检索

2. 表格

方案 1：Markdown 化
表格 → Markdown 格式 → Embedding

方案 2：结构化存储
表格 → DataFrame → SQL 数据库
查询时：自然语言 → SQL → 执行查询

方案 3：行列切分
表格 → 每行一个 Chunk → 保留表头上下文

3. 音频/视频

音频：
音频 → ASR → 文字 → Embedding

视频：
视频 → 关键帧提取 → VLM 描述 → Embedding
 → ASR（音轨） → 文字 → Embedding

代表技术

技术	用途	特点
CLIP / SigLIP	图文联合 Embedding	支持以图搜文、以文搜图
GPT-4V / Qwen-VL	视觉语言模型	理解图片内容，生成描述
ColPali	端到端文档检索	直接用文档图片检索，无需 OCR
Whisper	语音识别	音频转文字

适用场景

✅ 推荐使用多模态 RAG：
- 知识库包含大量图片/图表
- 需要检索产品图片
- 需要理解架构图/流程图
- 视频内容检索

❌ 不推荐：
- 纯文本知识库
- 对成本敏感（VLM 调用昂贵）

五、长上下文 vs RAG

长上下文模型的崛起

2023 年：Claude 2（100K）、GPT-4 Turbo（128K）
2024 年：Claude 3（200K）、Gemini 1.5 Pro（1M）、Kimi（200K）
2025 年：上下文窗口继续扩大...

长上下文能替代 RAG 吗？

长上下文方案：
Query + 全部文档 → LLM → 答案

优势：
- 不需要检索，不会遗漏信息
- 全局理解能力强
- 实现简单

劣势：
- 成本高（每 token 都要计费）
- 延迟高（处理长上下文需要时间）
- 不适合大规模知识库（100 万 token 放不下）

RAG 的优势

RAG 方案：
Query → 检索 Top-K → LLM → 答案

优势：
- 成本可控（只处理相关文档）
- 延迟低
- 可扩展（知识库无限大）
- 可追溯（知道答案来自哪里）

劣势：
- 可能检索不准，遗漏信息
- 缺乏全局理解

结论：互补而非替代

场景分析：

| 场景 | 推荐方案 | 理由 |
|------|----------|------|
| 小规模文档（<100K） | 长上下文 | 简单，不会遗漏 |
| 大规模知识库 | RAG | 成本、延迟可控 |
| 需要全局理解 | 长上下文 | RAG 擅长局部检索 |
| 需要精确引用 | RAG | 可追溯来源 |
| 实时更新知识库 | RAG | 长上下文需要重新处理 |

最佳实践：RAG + 长上下文
- RAG 检索相关文档
- 长上下文模型处理检索结果
- 兼顾成本和效果

六、检索技术进阶

1. Dense Retrieval 的演进

第一代：Single Vector（单向量）
文档 → 一个向量
问题：语义压缩过度，细节丢失

第二代：Multi-Vector（多向量，ColBERT）
文档 → 每个 token 一个向量
问题：存储成本高，但精度提升

第三代：Late Interaction（延迟交互，ColPali）
检索时不压缩，最后才做交互
优势：精度最高，适合文档检索

ColBERT 的核心思想

传统向量检索：
Query: "机器学习" → 向量 Q
Doc: "机器学习是人工智能的分支..." → 向量 D
相似度 = Q · D

ColBERT：
Query: "机器学习" → [q1, q2]（每个 token 一个向量）
Doc: "机器学习是人工智能的分支..." → [d1, d2, d3, d4, ...]
相似度 = Σ max(qi · dj) ← 每个 Query token 找最相似的 Doc token

优势：
- "机器学习"中的"机器"和"学习"分别匹配
- 精度更高

2. Query 理解技术

HyDE（Hypothetical Document Embeddings）

问题：Query 很短，语义信息不足

HyDE 的思路：
1. 让 LLM 生成一个假设性答案
2. 用假设答案的向量检索
3. 假设答案与真实文档更相似

示例：
Query: "Python 如何读取 JSON 文件？"
↓ LLM 生成假设答案
假设答案: "可以使用 json.load() 函数读取 JSON 文件。首先导入 json 模块，然后用 open() 打开文件..."
↓ 用假设答案检索
检索结果: 找到真实的 JSON 读取教程

Multi-Query（多查询）

问题：用户的 Query 可能表述不清

Multi-Query 的思路：
1. 用 LLM 生成多个相关 Query
2. 多路检索
3. 结果融合

示例：
Query: "报销流程"
↓ LLM 生成
Query 1: "公司报销流程步骤"
Query 2: "报销需要哪些材料"
Query 3: "报销审批流程"
↓ 多路检索，融合结果

3. 自适应检索（Self-RAG）

问题：不是所有问题都需要检索

Self-RAG 的思路：
1. LLM 自己判断是否需要检索
2. 如果需要，检索并生成
3. 生成后，LLM 自我评估答案质量
4. 如果不满意，重新检索

示例：
Query: "写一个 Python Hello World"
↓ LLM 判断
不需要检索（LLM 自己会写）
↓ 直接生成

Query: "公司最新的报销政策"
↓ LLM 判断
需要检索（LLM 不知道）
↓ 检索 → 生成

七、生成技术进阶

1. Citation（引用溯源）

RAG 的可信度关键：答案来自哪里？

输出格式：
答案：参数 timeout 的类型是 int，默认值是 30 秒。
引用：
 [1] API 文档.pdf, 第 3 页, 表格 2
 [2] 配置说明.md, 第 15 行

实现方式：
1. 检索时记录每个 Chunk 的来源
2. 生成时让 LLM 标注使用了哪些 Chunk
3. 前端支持点击引用跳转原文

2. Fact Checking（事实核查）

问题：RAG 也可能产生幻觉

方案：生成后验证

流程：
1. LLM 生成答案
2. 提取答案中的事实陈述
3. 再次检索验证每个事实
4. 标注置信度或修正错误

示例：
答案："A 公司成立于 2010 年，创始人张三"
↓ 提取事实
事实 1: A 公司成立于 2010 年
事实 2: 创始人是张三
↓ 验证
事实 1: ✅ 文档确认
事实 2: ❌ 文档说是李四，不是张三
↓ 修正
答案："A 公司成立于 2010 年，创始人李四"

八、工程优化

1. 增量索引

问题：知识库每天都在更新

方案：
- 只索引新增/修改的文档
- 向量数据库支持增量写入
- 版本管理（可回滚）

实现：
1. 记录每个文档的 hash
2. 检测变更
3. 只索引变更部分
4. 定期全量重建（避免碎片化）

2. 多级缓存

缓存层级：

Level 1: Exact Match Cache
完全相同的问题 → 直接返回缓存答案
命中率：10-20%

Level 2: Semantic Cache
语义相似的问题 → 返回缓存答案
示例："报销流程" ≈ "如何报销"
命中率：20-30%

Level 3: Query Cache
缓存检索结果，只重新生成
命中率：30-40%

效果：
- 延迟降低 60-80%
- 成本降低 50-70%

3. RAG 评估

评估维度：

检索质量：
- Recall@K：前 K 个结果中相关文档的比例
- MRR：正确答案的平均排名
- NDCG：考虑排序的检索质量

生成质量：
- Faithfulness：答案是否忠实于检索内容
- Relevance：答案是否回答了问题
- Coherence：答案是否连贯

端到端：
- Correctness：答案是否正确
- Completeness：答案是否完整
- Latency：响应延迟

评估工具：
- RAGAS：自动化 RAG 评估
- TruLens：LLM 应用评估
- DeepEval：开源评估框架

九、技术选型指南

按场景选择

场景 1：企业知识库（文档密集）
推荐：RAGFlow / Dify / FastGPT
理由：开箱即用，文档解析强

场景 2：需要多跳推理
推荐：GraphRAG / LightRAG
理由：知识图谱支持复杂推理

场景 3：需要 Agent 编排
推荐：LangGraph / CrewAI
理由：灵活的工作流控制

场景 4：多模态知识库
推荐：RAGFlow / LlamaIndex + VLM
理由：支持图片、表格、视频

场景 5：快速原型
推荐：Dify / AnythingLLM
理由：低代码，快速落地

场景 6：深度定制
推荐：LangChain / LlamaIndex
理由：底层控制能力强

按技术栈选择

已有 LangChain 项目：
→ 继续用 LangChain + LangGraph

已有 LlamaIndex 项目：
→ 继续用 LlamaIndex + GraphRAG

从零开始：
→ 考虑 RAGFlow（一站式）或 Dify（低代码）

需要图数据库：
→ Neo4j + LangChain/LlamaIndex

需要极致性能：
→ 自建向量库 + 自定义检索逻辑

十、开源项目速览

项目	Stars	特点	适用场景
RAGFlow	82K+	DeepDoc 文档解析	企业知识库
MinerU	67K+	通用文档解析	文档转 Markdown
Dify	50K+	RAG + Agent 平台	低代码构建
FastGPT	20K+	国产 RAG 平台	快速落地
LangGraph	10K+	Agent 编排	复杂工作流
LightRAG	10K+	轻量级 Graph RAG	多跳推理
GraphRAG	10K+	Microsoft 出品	企业级图谱
QAnything	10K+	多模态 RAG	端到端方案
AnythingLLM	20K+	全功能平台	企业部署

十一、学习资源

必读论文：

Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（RAG 原始论文）
Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
GraphRAG: Unlocking LLM Discovery on Narrative Private Data
Dense Passage Retrieval for Open-Domain Question Answering

官方文档：

LlamaIndex Documentation
LangChain RAG Tutorial
RAGFlow Documentation

评估框架：

RAGAS: https://github.com/explodinggradients/ragas
TruLens: https://www.trulens.org/
DeepEval: https://github.com/confident-ai/deepeval

十二、总结

RAG 技术正在快速演进，从简单的"检索 + 生成"发展为复杂的多技术融合系统。

技术演进路线：

RAG 1.0 → RAG 2.0 → RAG 3.0
基础检索 → 多路融合 → Agent + Graph + 多模态

核心趋势：
1. 从被动检索到主动规划
2. 从单一模态到多模态融合
3. 从局部检索到全局理解
4. 从固定流程到自适应调整

选择技术方案时，关键是明确需求：

简单场景：用 RAGFlow、Dify 这类一站式方案
复杂推理：引入 Graph RAG
Agent 编排：用 LangGraph
多模态：选择支持 VLM 的方案
深度定制：用 LangChain/LlamaIndex 自建

没有银弹，只有最适合的方案。

相关文章：

RAGFlow 深度解析：为什么它是最值得关注的 RAG 开源项目

Wed, 25 Mar 2026 16:00:00 +0800

过去两年，RAG 领域涌现了无数框架：LangChain、LlamaIndex、Haystack……它们各有侧重，但解决的核心问题相似——如何让 LLM 接地气。

但如果你实际做过企业级 RAG 项目，会发现一个被忽视的问题：文档解析。

大部分框架默认你已经有干净、结构化的文本。现实却是：PDF 扫描件、嵌套表格、数学公式、多栏排版……这些"脏活累活"往往占据项目 60% 以上的时间。

RAGFlow 的定位很明确：从文档到答案的全流程解决方案，而不是又一个"需要你自己处理文档"的检索框架。

这篇文章会深入分析 RAGFlow 的设计思路、核心技术和适用场景。

一、RAGFlow 的差异化定位

现有框架的盲区

LangChain 和 LlamaIndex 的设计假设是：

输入：干净的文本 / 简单的 PDF
处理：Chunk → Embed → Retrieve → Generate
输出：答案

但企业真实场景是：

输入：扫描件 PDF、带表格的年报、技术手册、合同......
预处理：OCR、布局分析、表格识别、公式识别......
处理：Chunk → Embed → Retrieve → Generate
输出：答案 + 引用

预处理阶段的复杂度，往往被框架忽略。

RAGFlow 的思路

RAGFlow 的核心定位：

不只是 RAG 框架，而是"文档理解 + RAG"的一体化方案

它的技术栈覆盖：

阶段	能力	技术方案
文档解析	OCR、布局分析、表格识别	DeepDoc（自研）
文档切分	8 种切分策略	按文档类型选择
检索	向量 + 关键词 + Rerank	混合检索 + RRF 融合
生成	多模型支持	OpenAI、Qwen、Ollama 等
运维	可视化 UI、API、监控	企业级特性

一句话总结：RAGFlow 解决的是"从 PDF 到答案"的完整链路，而不是"从文本到答案"。

二、DeepDoc：RAGFlow 的核心护城河

DeepDoc 是 RAGFlow 自研的文档理解引擎，也是它区别于其他框架的核心竞争力。

为什么需要 DeepDoc

传统 PDF 解析的问题：

问题 1：OCR 质量差

原文：错误码 E0028
OCR 结果：错误码 E002B（8 被识别成 B）

用户问：错误码 E0028 是什么意思
检索：找不到（因为文档里是 E002B）

问题 2：布局信息丢失

原文（两栏排版）：
┌──────────────┬──────────────┐
│ 左栏内容 │ 右栏内容 │
│ 跨多行... │ 跨多行... │
└──────────────┴──────────────┘

普通解析结果：
左栏内容
右栏内容 ← 两栏混在一起，语义被打断

问题 3：表格结构破坏

原文表格：
┌────────┬────────┬────────┐
│ 参数 │ 类型 │ 说明 │
├────────┼────────┼────────┤
│ timeout│ int │ 超时时间│
│ retry │ bool │ 是否重试│
└────────┴────────┴────────┘

普通解析结果：
参数 类型 说明 timeout int 超时时间 retry bool 是否重试
← 变成一行，结构全丢了

DeepDoc 的技术方案

DeepDoc Pipeline：

┌──────────┐ ┌──────────┐ ┌──────────────┐
│ Input │───▶│ Layout │───▶│ OCR Engine │
│ File │ │ Analysis│ │ (PaddleOCR) │
└──────────┘ └──────────┘ └──────┬───────┘
 │
 ┌──────────────────────┘
 ▼
┌──────────────────────────────────────────────┐
│ Structure Recognition │
│ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│ │ Table │ │ Figure │ │ Formula │ │
│ │ Parser │ │ Parser │ │ Parser │ │
│ └──────────┘ └──────────┘ └──────────────┘ │
└──────────────────────────────────────────────┘
 │
 ▼
┌──────────────────────────────────────────────┐
│ Semantic Understanding │
│ • 标题识别 │
│ • 章节分割 │
│ • 关系提取 │
└──────────────────────────────────────────────┘
 │
 ▼
┌──────────────────────────────────────────────┐
│ Markdown / Structured Output │
└──────────────────────────────────────────────┘

核心技术点：

模块	技术方案	解决的问题
OCR	PaddleOCR	高精度文字识别
布局分析	YOLO/LayoutLM	检测文本、表格、图片区域
表格识别	Table-Transformer	还原表格结构
公式识别	LaTeX-OCR	数学公式转 LaTeX
图片描述	VLM	生成图片文字描述

表格识别的原理

表格是最难处理的文档元素之一。DeepDoc 的表格识别流程：

Step 1: 表格检测
用目标检测模型定位表格区域

Step 2: 结构识别
Table-Transformer 识别：
- 行边界
- 列边界
- 单元格合并关系

Step 3: 内容识别
对每个单元格做 OCR

Step 4: 结构化输出
┌────────┬────────┐
│ A1 │ A2 │ → [{"row":1,"col":1,"text":"A1"}, ...]
├────────┼────────┤
│ B1 │ B2 │
└────────┴────────┘

为什么这件事重要？

如果表格结构丢了，用户问"参数 timeout 的类型是什么"，系统找不到答案——因为表格已经变成一团乱码。

与其他解析方案的对比

|| 方案 | OCR | 布局分析 | 表格识别 | 公式识别 | 输出格式 | |——|—–|———-|———-|———-|———-| | PyPDF2 | ❌ | ❌ | ❌ | ❌ | 纯文本 | | pdfplumber | ❌ | ⚠️ 基础 | ⚠️ 基础 | ❌ | 纯文本 | | Unstructured | ⚠️ 外部 | ✅ | ⚠️ 基础 | ❌ | 结构化 | | MinerU | ✅ | ✅ | ✅ | ✅ | Markdown/JSON | | DeepDoc | ✅ | ✅ | ✅ | ✅ | 结构化 + 语义信息 |

DeepDoc vs MinerU：不同的设计哲学

MinerU 是 2024 年上海人工智能实验室开源的文档解析工具，同样具备强大的 OCR、表格识别、公式识别能力。但 DeepDoc 和 MinerU 的设计目标有本质区别：

MinerU：通用文档解析工具

定位：将文档转换为 LLM 可用的 Markdown/JSON
输出：标准化的文本格式
目标：服务于各种下游应用（RAG、Agent、知识库等）
集成：支持 LangChain、Dify、FastGPT、RAGFlow 等

DeepDoc：RAG 原生文档理解引擎

定位：RAGFlow 的核心组件，深度集成
输出：保留语义结构的中间表示（标题层级、章节边界、表格结构等）
目标：直接服务于 Chunking 和检索策略
特点：与后续流程紧密耦合，非独立工具

核心差异：输出是否保留结构语义

MinerU 输出（Markdown）：
# 第一章 概述
## 1.1 背景
文本内容...
## 1.2 目标
文本内容...

↓ 丢失了什么？
- 标题的层级深度信息
- 章节边界的精确位置
- 表格的行列结构（变成 Markdown 表格，但丢失原始坐标）

DeepDoc 输出（结构化表示）：
{
 "chunks": [
 {
 "text": "文本内容...",
 "metadata": {
 "hierarchy": ["第一章", "概述", "1.1", "背景"],
 "level": 3,
 "bbox": [x1, y1, x2, y2],
 "type": "paragraph"
 }
 }
 ],
 "tables": [
 {
 "cells": [[...]],
 "headers": ["参数", "类型", "说明"],
 "bbox": [...]
 }
 ]
}

为什么 RAGFlow 不用 MinerU？

时间线：RAGFlow（2023.12）比 MinerU（2024.02）更早，DeepDoc 已经开发成熟
深度集成：DeepDoc 的输出直接适配 8 种 Chunking 策略，需要语义和结构信息
核心护城河：文档理解是 RAGFlow 的差异化竞争力，不依赖外部工具
输出差异：MinerU 输出 Markdown，DeepDoc 输出保留更多结构信息

选择建议

场景	推荐	理由
只需要文档转 Markdown	MinerU	开箱即用，输出标准
构建企业 RAG 系统	RAGFlow + DeepDoc	文档解析与检索一体化
已有 RAG 框架，需补充解析能力	MinerU	作为独立组件集成
需要自定义 Chunking 逻辑	MinerU + 自己实现	更灵活

DeepDoc 是目前开源方案中唯一为 RAG 场景深度优化的文档解析引擎。

三、Chunking 策略：一种文档一种切法

RAGFlow 提供了 8 种 Chunking 策略，针对不同文档类型：

为什么需要多种策略

不同类型文档的结构差异很大：

FAQ 文档：
Q: 问题
A: 答案
─────────
每个 QA 对是独立的语义单元

技术手册：
## 安装
步骤 1...
步骤 2...
## 配置
参数 1...
参数 2...
─────────
按章节切分，保留标题上下文

法律文档：
第一条 ...
第二条 ...
第三条 ...
─────────
按条款切分，每条有独立法律意义

用同一种"固定长度切分"处理所有文档，效果必然不好。

RAGFlow 的 8 种策略

策略	适用文档	切分依据
Naive	简单文本	固定字符数
Q&A	FAQ 文档	问题-答案对
Book	书籍、长文档	章节层级
Manual	技术手册	小节
Law	法律、合同	条款
Paper	学术论文	摘要、章节
Table	表格数据	行/单元格
Picture	图片	VLM 描述

核心思路：保留语义完整性

无论哪种策略，核心原则相同：一个 chunk 应该能独立回答一个问题。

以 Book Chunking 为例：

原始文档：
# 第一章 概述
## 1.1 背景
文本内容...
## 1.2 目标
文本内容...
# 第二章 设计
## 2.1 架构
文本内容...

切分结果：
Chunk 1: 【第一章 概述 > 1.1 背景】文本内容...
Chunk 2: 【第一章 概述 > 1.2 目标】文本内容...
Chunk 3: 【第二章 设计 > 2.1 架构】文本内容...

关键设计：把父级标题拼到 chunk 前面。

这样做的原因我在 RAG 进阶篇详细讲过：Embedding 只能看到 chunk 内部的文字。如果 chunk 里没有"第一章"、“概述”、“背景"这些关键词，用户问"第一章的背景是什么"时就召不回。

Table Chunking 的特殊性

表格数据的切分需要特殊处理：

方案 1：行级切分
每行一个 chunk，保留表头

方案 2：单元格级切分
每个单元格一个 chunk，附带行列信息

RAGFlow 的做法：
- 检测表格结构
- 保留表头作为上下文
- 行级切分
- 每个 chunk 包含：表头 + 该行内容

示例：
原始表格：
| 参数 | 类型 | 说明 |
|------|------|------|
| timeout | int | 超时时间 |

切分后的 chunk：
【表：API 参数配置】
参数: timeout | 类型: int | 说明: 超时时间

这样用户问"timeout 参数的类型是什么”，就能精确召回这一行。

四、检索架构：混合检索 + RRF 融合

RAGFlow 的检索架构是标准的混合检索方案：

整体架构

Query
 │
 ├─── 向量检索（Dense）───┐
 │ │
 ├─── 关键词检索（BM25）──┤──→ RRF 融合 ──→ Rerank ──→ Top-K
 │ │
 └─── Metadata 过滤 ─────┘

RRF 融合算法

RRF（Reciprocal Rank Fusion）的核心思想：不依赖分数，只依赖排名。

RRF 公式：
score(d) = Σ 1 / (k + rank_i(d))

其中：
- d：文档
- rank_i(d)：文档 d 在第 i 路检索中的排名
- k：平滑参数（通常 60）

为什么有效？

问题：向量分数（0.82）和 BM25 分数（5.2）不在同一尺度

传统方案：
- 分数归一化：复杂，不稳定
- 加权融合：权重难调

RRF 的做法：
- 不管分数多少
- 只看排名
- 排名第 1 → 得分 1/61
- 排名第 2 → 得分 1/62
- 两路都召回的文档，得分更高

示例：

Query："错误码 401"

向量检索：
#1 Doc_A
#2 Doc_B
#3 Doc_C

BM25 检索：
#1 Doc_D
#2 Doc_C ← 两路都有
#3 Doc_A ← 两路都有

RRF 融合：
Doc_C: 1/(60+3) + 1/(60+2) = 0.032 ← 最高
Doc_A: 1/(60+1) + 1/(60+3) = 0.032
Doc_B: 1/(60+2) + 0 = 0.016
Doc_D: 0 + 1/(60+1) = 0.016

两路都召回的文档，得分更高，自然排在前面。

Rerank 实现

RAGFlow 内置 Cross-Encoder Rerank：

原理：
Query + Document → Transformer → Relevance Score

为什么比向量检索更准：
- 向量检索：Query 和 Document 各自编码，交互少
- Cross-Encoder：Query 和 Document 拼在一起编码，充分交互

支持的 Rerank 模型：

模型	特点	延迟（100 候选）
bge-reranker-v2-m3	多语言，效果好	~180ms
bge-reranker-large	效果好	~150ms
ms-marco-MiniLM	轻量，快速	~45ms

Rerank 的成本很高，只能对小规模候选做精排。RAGFlow 的默认配置：

召回：top-50（向量 + BM25）
Rerank：top-50 全部重排
输出：top-5

五、与其他框架的对比

功能对比

维度	RAGFlow	LangChain	LlamaIndex
文档解析	⭐⭐⭐⭐⭐ DeepDoc	⭐⭐⭐ 基础	⭐⭐⭐ 基础
Chunking	⭐⭐⭐⭐⭐ 8 种策略	⭐⭐⭐ 需自己实现	⭐⭐⭐⭐ 较丰富
检索	⭐⭐⭐⭐⭐ 混合 + RRF	⭐⭐⭐ 需组合	⭐⭐⭐⭐ 较完整
可视化 UI	⭐⭐⭐⭐⭐ 完整	⭐⭐ LangSmith	⭐⭐⭐ LlamaCloud
开箱即用	⭐⭐⭐⭐⭐ 高	⭐⭐⭐ 需组装	⭐⭐⭐⭐ 较高
自定义扩展	⭐⭐⭐ 中等	⭐⭐⭐⭐⭐ 高	⭐⭐⭐⭐⭐ 高

架构理念对比

RAGFlow：应用导向
"我要做一个企业知识库" → RAGFlow 提供完整方案
特点：一站式，开箱即用

LangChain：组件导向
"我要组装一个 Agent" → LangChain 提供各种组件
特点：灵活，但需要自己组装

LlamaIndex：数据导向
"我要索引和查询数据" → LlamaIndex 提供数据框架
特点：数据处理能力强，适合研究

代码风格对比

# RAGFlow：高层抽象，配置驱动
from ragflow import RAGFlow

app = RAGFlow()
dataset = app.create_dataset(name="knowledge")
dataset.add_documents("./docs")
chat = app.create_chat(dataset=dataset)
response = chat.query("What is RAG?")

# LangChain：Chain 组合式
from langchain.chains import RetrievalQA
from langchain.vectorstores import Chroma
from langchain.embeddings import OpenAIEmbeddings

vectorstore = Chroma.from_documents(docs, OpenAIEmbeddings())
qa = RetrievalQA.from_chain_type(
 llm=ChatOpenAI(),
 retriever=vectorstore.as_retriever()
)
response = qa.run("What is RAG?")

# LlamaIndex：索引为中心
from llama_index import VectorStoreIndex, SimpleDirectoryReader

documents = SimpleDirectoryReader("./docs").load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine()
response = query_engine.query("What is RAG?")

选型建议

场景	推荐	理由
企业知识库	RAGFlow	开箱即用，DeepDoc 解析复杂文档
复杂 Agent 应用	LangChain	灵活的 Chain/Tool 组合
数据分析研究	LlamaIndex	强大的索引策略
快速原型	RAGFlow	最快落地
高度定制化	LangChain/LlamaIndex	更底层的控制

六、生产级特性

API 设计

RAGFlow 提供完整的 REST API：

# 创建数据集
POST /api/dataset
{"name": "my_knowledge"}

# 上传文档
POST /api/document/upload
-F "file=@document.pdf"
-F "dataset_id={id}"

# 对话
POST /api/chat/completion
{
 "question": "什么是 RAG?",
 "dataset_ids": ["{id}"],
 "stream": true
}

部署方案

最小部署（Docker Compose）：
├── ragflow（API 服务）
├── milvus（向量库）
├── mysql（元数据）
└── elasticsearch（可选，全文检索）

生产部署（Kubernetes）：
├── Ingress
├── ragflow deployment（多副本）
├── milvus cluster
├── mysql primary/replica
└── 监控（Prometheus + Grafana）

多租户与权限

租户隔离：
- 每个租户独立的数据集
- 数据集级别的访问控制
- API Key 认证

权限模型：
- 管理员：全部权限
- 编辑者：上传、解析、编辑
- 查看者：仅查询

可观测性

指标监控：
- 文档处理吞吐量
- 检索延迟（P50/P95/P99）
- LLM 调用耗时
- 向量库查询性能

日志追踪：
- 请求级 Trace ID
- 结构化日志
- 全链路追踪

七、RAGFlow 的优势与局限

优势

维度	说明
DeepDoc	业界最强的开源文档解析能力
开箱即用	完整 UI + API，快速落地
企业级	多租户、权限、监控完备
多策略 Chunking	针对不同文档类型优化
混合检索	向量 + BM25 + Rerank 完整支持

局限

维度	说明
灵活性	不如 LangChain/LlamaIndex 灵活
Agent 能力	不适合复杂多 Agent 场景
定制成本	深度定制需要理解源码
学习曲线	概念较多，需要时间熟悉

适用场景

强烈推荐：

企业内部知识库
需要处理复杂文档（PDF、表格）
追求快速落地
需要可视化管理和审计

谨慎选择：

复杂 Agent 编排
需要深度定制检索逻辑
已有 LangChain/LlamaIndex 生态

八、快速入门

# 克隆项目
git clone https://github.com/infiniflow/ragflow.git
cd ragflow

# Docker Compose 启动
docker compose up -d

# 访问 Web UI
open http://localhost:9380

# 创建数据集、上传文档、开始对话

核心概念：

Dataset（数据集）
├── Document（文档）
│ ├── Chunk（切片）
│ └── Embedding（向量）
└── Chat（对话）

流程：
上传文档 → DeepDoc 解析 → 切分 → 向量化 → 存储
 ↓
Query → 检索 → Rerank → LLM 生成 → 答案 + 引用

九、总结

RAGFlow 不是"又一个 RAG 框架"，而是从文档到答案的全流程解决方案。

它的核心价值：

1. DeepDoc：解决被忽视的文档解析问题
2. 多策略 Chunking：不同文档不同切法
3. 混合检索：向量 + BM25 + Rerank
4. 开箱即用：UI + API + 部署方案

如果你在做企业级 RAG 项目，尤其是需要处理复杂文档的场景，RAGFlow 是目前最值得尝试的开源方案。

它不一定是灵活性最高的，但可能是落地最快的。

相关链接：

GitHub: https://github.com/infiniflow/ragflow
文档: https://ragflow.io/docs
Demo: https://ragflow.io

相关文章：

vector-database

Thu, 20 Nov 2025 16:41:12 +0800

向量数据库的教程

松果

AI 的“海马体”选型指南：2026 年主流向量数据库全景对比

摘要：在构建 RAG（检索增强生成）和 AI Agent 系统时，向量数据库（Vector Database）充当着“长期记忆”的关键角色。面对市场上琳琅满目的选项——Milvus、Qdrant、Weaviate、pgvector……架构师该如何抉择？本文将从架构轻重、运维成本和适用场景三个维度，为您深度解析主流向量数据库的优劣势。

在构建 RAG（检索增强生成）和 AI Agent 系统时，向量数据库（Vector Database）充当着“长期记忆”的关键角色。通过将文本、图片等非结构化数据转化为高维向量（Embeddings），向量数据库允许我们进行语义搜索。当用户问“还是老规矩”时，系统能从数据库中检索出该用户过去的行为偏好，而不是仅仅匹配关键词。但在 2026 年的今天，选型变得异常困难：是追求极致性能？还是追求开发效率？

我们来聊聊主流的向量数据库，它们各有特色，也有不同的适用场景。以下是第一梯队的原生向量数据库：

Milvus 是全球最流行的开源向量数据库之一，由 Zilliz 主导。

核心定位：企业级、云原生、追求极致扩展性。
✅ 核心优势：
十亿级吞吐：分布式架构极其成熟，轻松支撑 Billion-scale（十亿级）向量存储。
生态完善：国内社区最活跃，文档支持最好，索引类型（HNSW, IVF 等）丰富。
❌ 潜在短板：
架构极重：标准版部署依赖 Etcd（元数据）、MinIO（存储）和 Pulsar/Kafka（消息流）。在 docker-compose 中启动它需要拉起 4-5 个容器，运维成本高。
资源门槛：起步资源要求较高，不适合 MVP（最小可行性产品）阶段的小微项目。
适用场景：大型互联网应用、核心推荐系统、海量知识库。

Qdrant 是用 Rust 编写的新一代向量数据库，也是许多 Agent 框架的首选。

核心定位：兼顾高性能与易用性，开发者友好。
✅ 核心优势：
架构轻量：Rust 编写，内存安全且高效。部署只需一个 Docker 容器，无外部依赖。
元数据过滤：它的 Payload Filtering 机制非常强大，支持像 MongoDB 一样灵活地过滤 JSON 字段（例如：“查找昨天情绪为‘开心’的对话记忆”）。
本地模式：支持 Python 本地内存模式，开发阶段甚至无需启动服务。
❌ 潜在短板：
超大规模验证：虽然支持分布式，但在百亿级规模的公开案例略少于 Milvus。
适用场景：AI Agent 记忆系统、中大型 RAG 应用、快速迭代的初创项目。

Weaviate 是一款 AI 原生的向量数据库，具有模块化特性。

核心定位：模块化、对象存储风格。
✅ 核心优势：
内置模块：可直接集成 OpenAI/HuggingFace 模型，自动处理 Embedding，无需应用层操心。
混合搜索：原生支持 BM25（关键词）+ 向量的混合检索，搜索效果通常优于纯向量。
❌ 潜在短板：
学习曲线：使用 GraphQL 接口查询，Schema 定义方式独特，需要一定的上手时间。
适用场景：Notebook 演示、Hackathon、个人知识库。

Chroma 是一款面向 Python 全栈开发者的向量数据库，设计极简。

核心定位：面向 Python 全栈开发者，极简。
✅ 核心优势：
上手最快：pip install chromadb 即可，API 设计极其简单。
❌ 潜在短板：
性能瓶颈：在大规模并发和分布式能力上弱于上述三位“老大哥”。
适用场景：Notebook 演示、Hackathon、个人知识库。

如果你的技术栈已经很成熟，不想引入新的组件，传统数据库的扩展方案可能是更好的选择。

PostgreSQL (pgvector) 是全球最强开源关系型数据库的插件。

定位：全球最强开源关系型数据库的插件。
优点：单一数据源。无需在 SQL 数据库和向量库之间同步数据，完美支持 ACID 事务。如果你的数据量在百万级以内，直接开插件是最省事的选择。
缺点：在高并发 QPS 或超高维向量场景下，索引构建速度和查询延迟不如原生向量库。

Elasticsearch (ES) / OpenSearch 是全文检索的王者。

定位：全文检索的王者。
优点：如果你需要极强的关键词搜索（BM25）能力，向量检索只是辅助，ES 是不二之选。
缺点：Java 编写，资源消耗大（内存吞噬者），纯向量检索性能并非顶尖。

Redis (RediSearch) 是一款基于内存的数据库。

定位：基于内存的极致速度。
优点：亚毫秒级延迟，适合高频读写的短期记忆缓存。
缺点：内存昂贵，存储海量历史数据成本太高。

为了方便大家决策，我整理了这份决策矩阵：

你的需求场景	推荐选型	核心理由
MVP 原型 / 个人开发	Chroma / Qdrant (Local)	代码量最少，环境搭建最快。
中型生产环境 / 追求性价比	Qdrant	Rust 高效、Docker 单容器部署、Filter 语法极佳。 (这也是我们 V1.2 架构的首选)
超大规模 / 十亿级数据	Milvus	经过大规模验证的分布式能力，Zilliz 企业级支持。
已有 Postgres 且数据量不大	pgvector	架构最简单，不用维护新数据库。
强依赖关键词搜索	Elasticsearch	混合检索生态最强。

没有“最好”的数据库，只有“最适合”的架构。

在我们的**“变色龙”进化型对话系统项目中，我们最终选择了 Qdrant。原因很简单：在快速迭代阶段，我们需要一个部署足够轻量**（不拖累 Docker Compose）、查询足够灵活（处理复杂的记忆元数据）且性能足够强的组件。Qdrant 完美击中了这三个甜点。

tutorial

Milvus

Milvus 专为大规模向量数据的存储、索引和搜索而设计，常用于构建 RAG（检索增强生成）、图像检索、推荐系统等应用。

以下教程将涵盖：环境部署、核心概念、以及完整的 Python 代码实战。

1. 什么是 Milvus？

Milvus 是一款云原生的向量数据库。它的核心作用是存储“向量”（Embeddings，即由 AI 模型生成的浮点数数组），并利用算法快速找出与查询向量“最相似”的数据。

非结构化数据处理： 它可以让图片、视频、文本等非结构化数据通过向量化后进行语义搜索。
高性能： 支持十亿级向量规模的毫秒级搜索。

2. 环境部署 (基于 Docker)

使用 Docker 是运行 Milvus 最简单、最标准的方式。

第一步：下载 Docker Compose 文件

在你的终端中执行以下命令，下载官方的单机版配置文件：

curl -L https://github.com/milvus-io/milvus/releases/download/v2.4.0/milvus-standalone-docker-compose.yml -o docker-compose.yml

第二步：启动 Milvus

docker-compose up -d

启动后，Milvus 会暴露以下端口：

19530: gRPC 端口（主要用于代码连接）。
9091: 管理端口。

推荐工具： 建议安装 Attu (Milvus 的官方可视化管理界面)，可以通过 Docker 一并安装，方便查看数据。

docker run -p 8000:3000 -e MILVUS_URL=localhost:19530 zilliz/attu:v2.6

桌面端安装

如果你是使用docker 容器安装在mac或者windows的docker desktop里面，你可以使用host.docker.internal:19530连接

3. Python 代码实战

我们将使用 Python SDK (pymilvus) 来完成从连接、建表、插入数据到相似度搜索的全过程。

0. 安装 SDK

uv add pymilvus

1. 完整代码示例

这个脚本模拟了一个场景：我们有 10,000 条文本数据（已转化为向量），我们要找出与某条查询最相似的 3 条数据。

import random
import time
import numpy as np
from pymilvus import (
 connections,
 utility,
 FieldSchema,
 CollectionSchema,
 DataType,
 Collection,
)

# ==========================================
# 1. 连接 Milvus
# ==========================================
print(">>> 正在连接 Milvus...")
connections.connect("default", host="host.docker.internal", port="19530")
print(">>> 连接成功！")

# ==========================================
# 2. 定义集合 (Schema)
# ==========================================
# 类似于关系型数据库中的“表”
collection_name = "tutorial_demo"
dim = 128 # 向量维度 (根据你的 Embedding 模型决定，如 OpenAI text-embedding-3 是 1536)

# 如果集合已存在，先删除（为了演示方便）
if utility.has_collection(collection_name):
 utility.drop_collection(collection_name)

# 定义字段
fields = [
 # 主键 ID (自动增长)
 FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
 # 向量字段 (FLOAT_VECTOR)，必须指定维度
 FieldSchema(name="embeddings", dtype=DataType.FLOAT_VECTOR, dim=dim),
 # 元数据字段 (例如文章标题、日期等)
 FieldSchema(name="title", dtype=DataType.VARCHAR, max_length=200),
 FieldSchema(name="count", dtype=DataType.INT64),
]

schema = CollectionSchema(fields, description="Milvus 基础教程演示")
collection = Collection(name=collection_name, schema=schema)

print(f">>> 集合 '{collection_name}' 创建成功")

# ==========================================
# 3. 插入数据 (Insert)
# ==========================================
num_entities = 3000 # 插入 3000 条数据

# 生成随机向量数据模拟 Embeddings
rng = np.random.default_rng(seed=19530)
vectors = rng.random((num_entities, dim), dtype=np.float32) # 生成随机浮点数

# 生成一些元数据
titles = [f"Article_{i}" for i in range(num_entities)]
counts = [i for i in range(num_entities)]

# 组织数据 (列表的顺序必须与 Schema 定义的顺序一致，排除 auto_id 的主键)
# 注意：Milvus 插入数据是列式存储格式 [Column1_List, Column2_List, ...]
data = [
 vectors, # 对应 embeddings
 titles, # 对应 title
 counts, # 对应 count
]

insert_result = collection.insert(data)
# 即使插入了，数据还在内存缓冲区，需要 flush 到磁盘才能确保立即可见（生产环境通常不需要手动频繁 flush）
collection.flush()

print(f">>> 已插入 {insert_result.insert_count} 条数据")

# ==========================================
# 4. 创建索引 (Indexing)
# ==========================================
# 向量搜索如果是暴力搜索 (Flat) 会很慢，必须建立索引。
# IVF_FLAT 是一种基于倒排文件的常见索引。
index_params = {
 "metric_type": "L2", # 距离度量：L2 (欧氏距离) 或 IP (内积/余弦相似度)
 "index_type": "IVF_FLAT", # 索引类型
 "params": {"nlist": 128}, # nlist 是聚类中心的数量
}

print(">>> 正在构建索引...")
collection.create_index(field_name="embeddings", index_params=index_params)
print(">>> 索引构建完成")

# ==========================================
# 5. 加载集合 (Load)
# ==========================================
# *关键步骤*：Milvus 必须将集合加载到内存中才能进行搜索
collection.load()

# ==========================================
# 6. 向量搜索 (Search)
# ==========================================
# 模拟一个查询向量
search_vectors = rng.random((1, dim), dtype=np.float32)

# 搜索参数
search_params = {
 "metric_type": "L2",
 "params": {"nprobe": 10}, # nprobe: 在多少个聚类中心里搜索，值越大越准但越慢
}

print(">>> 开始搜索...")
start_time = time.time()

results = collection.search(
 data=search_vectors, # 查询向量
 anns_field="embeddings", # 在哪个字段搜索
 param=search_params, # 搜索参数
 limit=3, # Top K：返回最相似的 3 个
 output_fields=["title", "count"] # 同时返回这些元数据字段
)

end_time = time.time()

# ==========================================
# 7. 解析结果
# ==========================================
print(f">>> 搜索耗时: {end_time - start_time:.4f} 秒")
print("-" * 20)
for hits in results:
 for hit in hits:
 # hit.id 是主键, hit.distance 是距离, hit.entity.get() 获取元数据
 print(f"ID: {hit.id}, Distance: {hit.distance:.4f}, Title: {hit.entity.get('title')}")

# ==========================================
# 8. 清理 (可选)
# ==========================================
# collection.drop()
# connections.disconnect("default")

4. 关键概念详解

为了用好 Milvus，你需要理解以下几个核心参数：

A. Metric Type (距离度量)

这是衡量两个向量“相似度”的标准，必须在建立索引和搜索时保持一致。

L2 (欧氏距离): 也就是几何距离。值越小表示越相似。适用于大多数场景。
IP (内积): 如果向量已归一化，它等同于余弦相似度。值越大表示越相似。适用于文本语义搜索。

B. Index Type (索引类型)

FLAT: 暴力搜索，准确率 100%，但速度最慢。仅适用于少量数据 (<1万)。
IVF_FLAT / IVF_SQ8: 基于倒排聚类。速度快，但在召回率上有一点点损失。最常用。
HNSW: 基于图的索引。性能极高，是目前最流行的索引算法，但内存占用比 IVF 大。

C. Consistency Level (一致性级别)

Milvus 是分布式的，搜索时可以指定一致性：

Strong: 保证刚插入的数据立马能搜到（性能最慢）。
Bounded: 允许几秒钟的延迟（性能最好，默认推荐）。

5. 进阶：结合 RAG 的应用流程

如果你在做 AI 应用，Milvus 的工作流通常是这样的：

Embedding: 用户输入问题 -> 调用 OpenAI/HuggingFace API -> 获得向量 [0.1, 0.5, ...].
Search: 将这个向量传给 Milvus (collection.search)。
Context: Milvus 返回 Top 3 相似的文本片段 (通过 output_fields 返回文本内容)。
Generation: 将 “用户问题 + Milvus 返回的文本片段” 拼成 Prompt，发给 ChatGPT。
Answer: ChatGPT 根据参考资料回答问题。

6. 常见问题 (FAQ)

为什么搜索报错 Collection not loaded？
- Milvus 为了性能，搜索前必须显式调用 collection.load() 将数据加载到内存。
向量维度不匹配？
- 创建集合时的 dim 必须与你的 Embedding 模型输出维度完全一致（例如 BERT 是 768，OpenAI text-embedding-3-small 是 1536）。
如何删除数据？
- 使用 collection.delete("id in [1, 2]")。注意，删除操作是软删除，物理空间不会立即释放。

以下是一个非常实用的企业级开发场景。阿里云百炼 (DashScope) 提供了强大的通义千问 (Qwen) 大模型和文本向量化服务，结合 Milvus 的存储检索能力，可以快速搭建一个私有知识库问答系统。

以下是完整的 Python 代码示例，涵盖了从“文本向量化”到“存入 Milvus”，再到“检索并生成回答”的全流程。

前置准备

获取 API Key：你需要去阿里云百炼控制台开通服务并获取 API Key。
安装依赖库：你需要安装阿里云的官方 SDK dashscope 和 Milvus SDK pymilvus。

pip install dashscope pymilvus

完整代码示例

新建一个 Python 文件（例如 rag_bailian_milvus.py），填入你的 API Key 即可运行。

import dashscope
from dashscope import Generation
from pymilvus import (
 connections,
 utility,
 FieldSchema,
 CollectionSchema,
 DataType,
 Collection,
)
from http import HTTPStatus

# ==========================================
# 0. 配置部分
# ==========================================

# 【重要】请替换为你的阿里云百炼 API Key
dashscope.api_key = "sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxx"

# Milvus 配置
MILVUS_HOST = "localhost" # 如果在 Docker 内运行且用 host 模式，或者是本地运行
MILVUS_PORT = "19530"

# 模型配置
EMBEDDING_MODEL = "text-embedding-v2" # 阿里云通用文本向量模型
LLM_MODEL = "qwen-turbo" # 通义千问-Turbo (性价比高)
VECTOR_DIM = 1536 # text-embedding-v2 的维度是 1536

# ==========================================
# 1. 辅助函数：调用百炼 API
# ==========================================

def get_embedding(text: str):
 """调用阿里云百炼 Embedding API 将文本转换为向量"""
 resp = dashscope.TextEmbedding.call(
 model=EMBEDDING_MODEL,
 input=text
 )

 if resp.status_code == HTTPStatus.OK:
 # 获取向量数据
 return resp.output['embeddings'][0]['embedding']
 else:
 print(f"Embedding API 报错: {resp}")
 raise Exception("Failed to generate embedding")

def call_llm(prompt: str):
 """调用通义千问生成回答"""
 messages = [{'role': 'user', 'content': prompt}]
 resp = Generation.call(
 model=LLM_MODEL,
 messages=messages,
 result_format='message', # 设置返回格式为 message
 )

 if resp.status_code == HTTPStatus.OK:
 return resp.output.choices[0]['message']['content']
 else:
 print(f"LLM API 报错: {resp}")
 return "抱歉，生成回答时出错了。"

# ==========================================
# 2. 初始化 Milvus 集合
# ==========================================
print(">>> 连接 Milvus...")
connections.connect("default", host=MILVUS_HOST, port=MILVUS_PORT)

collection_name = "bailian_rag_demo"

# 如果存在旧集合则删除，保证每次运行都是干净的环境
if utility.has_collection(collection_name):
 utility.drop_collection(collection_name)

# 定义 Schema
fields = [
 FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True),
 FieldSchema(name="vector", dtype=DataType.FLOAT_VECTOR, dim=VECTOR_DIM),
 FieldSchema(name="text", dtype=DataType.VARCHAR, max_length=2048) # 存储原始文本用于构建 Prompt
]
schema = CollectionSchema(fields, description="阿里云百炼 RAG 演示")
collection = Collection(name=collection_name, schema=schema)

# 创建索引 (IVF_FLAT 适合大多数场景)
index_params = {
 "metric_type": "L2", # 欧氏距离 (阿里云 Embedding 推荐用 Cosine，但在归一化后 L2 效果也能接受，这里演示用 L2)
 "index_type": "IVF_FLAT",
 "params": {"nlist": 1024}
}
collection.create_index(field_name="vector", index_params=index_params)
collection.load() # 加载到内存
print(f">>> 集合 {collection_name} 准备就绪")

# ==========================================
# 3. 模拟私有数据并入库 (Ingestion)
# ==========================================
# 假设这是一些只有你知道，ChatGPT 此时此刻可能不知道的“私有知识”
knowledge_base = [
 "TransMaster 项目是一个由 Python 开发的高效翻译管理系统。",
 "Zata 计划在 2025年9月 去温州旅行。",
 "Milvus 是一款高性能的开源向量数据库，支持十亿级数据检索。",
 "在 Python 中使用 Celery 可以轻松处理异步任务队列。",
 "阿里云百炼是阿里巴巴推出的一站式大模型服务平台。"
]

print(">>> 正在向量化并存入数据...")
data_vectors = []
data_texts = []

for text in knowledge_base:
 vec = get_embedding(text)
 data_vectors.append(vec)
 data_texts.append(text)

# 插入 Milvus
collection.insert([data_vectors, data_texts])
collection.flush()
print(f">>> 成功插入 {len(knowledge_base)} 条知识数据")

# ==========================================
# 4. RAG 核心流程：检索 + 生成
# ==========================================

def rag_chat(user_query):
 print(f"\n[用户提问]: {user_query}")

 # A. 检索 (Retrieval)
 # 1. 把用户的问题变成向量
 query_vector = get_embedding(user_query)

 # 2. 在 Milvus 中搜最相似的 2 条
 search_params = {"metric_type": "L2", "params": {"nprobe": 10}}
 results = collection.search(
 data=[query_vector],
 anns_field="vector",
 param=search_params,
 limit=2, # Top 2
 output_fields=["text"] # 记得把原始文本拿回来
 )

 # 3. 提取上下文
 retrieved_texts = []
 for hits in results:
 for hit in hits:
 # print(f" (命中参考资料: {hit.entity.get('text')} - 距离: {hit.distance})")
 retrieved_texts.append(hit.entity.get("text"))

 context_str = "\n".join(retrieved_texts)

 # B. 生成 (Generation)
 # 4. 组装 Prompt
 prompt = f"""
 请根据以下参考资料回答用户的问题。如果参考资料中没有答案，请回答“我不知道”。

 【参考资料】：
 {context_str}

 【用户问题】：
 {user_query}
 """

 # 5. 调用大模型
 print(">>> 正在思考...")
 answer = call_llm(prompt)
 print(f"[AI 回答]: {answer}")

# ==========================================
# 5. 测试运行
# ==========================================

# 测试 1: 问一个库里有的私有知识
rag_chat("Zata 打算什么时候去温州？")

# 测试 2: 问一个库里有的技术知识
rag_chat("TransMaster 是什么项目？")

# 测试 3: 问一个库里没有的无关问题
rag_chat("西红柿炒鸡蛋怎么做？")

代码核心逻辑解析

统一模型：
- 入库时：使用 text-embedding-v2 将知识转为向量。
- 搜索时：使用同一个 text-embedding-v2 将用户问题转为向量。这是向量搜索准确的前提。
Schema 设计：
- 我们在 Milvus 中定义了 text 字段。这是 RAG 的关键技巧：向量数据库不仅存向量，最好也存一份原始文本。这样搜索到向量后，直接就能取出对应的文字喂给大模型，不需要再去查 MySQL。
Prompt 组装：
- 代码中的 prompt 变量展示了经典的 RAG 提示词模板。强制要求 AI 基于【参考资料】回答，可以有效减少大模型的“幻觉”（胡说八道）。

可能遇到的问题

Dimension 错误： 如果你换了模型（比如换成了 text-embedding-v1），请务必确认它的维度。v2 是 1536 维，如果报错 dimension mismatch，请检查 Milvus 建表时的 dim 参数。
DashScope API 报错： 如果提示 InvalidApiKey，请检查环境变量或代码中 Key 是否复制完整。

下一步

现在你已经跑通了最核心的流程。如果你想把这个应用到实际的 TransMaster 项目中，下一步通常是**“文档切分”**：

任务： 把长的 PDF 或 Markdown 文档切成 500 字左右的小块。
工具： 可以使用 LangChain 的 RecursiveCharacterTextSplitter 来做切分，然后再传给这个脚本入库。

演示如何用 Python 切分长文本

在实际的 RAG 应用（比如你的 TransMaster 项目）中，直接把整篇几千字的文章扔给 Embedding 模型是不行的，因为：

模型限制：Embedding 模型通常有 Token 长度限制（比如 8192 token）。
搜索精度：如果一段文本太长，里面包含的信息太杂，搜索匹配的精准度会下降。

因此，我们需要切分 (Chunking)。

业界最常用的是 LangChain 提供的 RecursiveCharacterTextSplitter（递归字符文本分割器）。它很聪明，会优先在段落（\n\n）处切分，如果不行再在换行（\n）切，尽量保证句子的完整性。

1. 安装必要的库

为了轻量化，我们只安装 LangChain 的文本切分组件，不需要安装整个庞大的 LangChain。

uv add langchain-text-splitters

2. 独立演示代码：长文本切分

这个脚本演示了如何把一篇关于“TransMaster 项目开发规范”的长文档，切分成适合入库的小块。

from langchain_text_splitters import RecursiveCharacterTextSplitter

# 1. 模拟一个长文档 (假设这是你项目里的 README 或需求文档)
long_text = """
# TransMaster 项目开发规范 V1.0

## 1. 项目简介
TransMaster 是一个基于 Python 的高效翻译管理系统，旨在解决多语言项目中的协同翻译痛点。
它集成了 Redis 缓存、Celery 异步任务队列以及 Docker 容器化部署方案。
后端主要使用 Flask/FastAPI 框架，数据库采用 PostgreSQL。

## 2. 核心功能
 2.1 自动翻译
系统接入了百度翻译、DeepL 以及 Google Translate API。
当用户上传文档时，后台会通过 Celery Worker 自动将文档解析并进行预翻译。
为了防止 API 超时，所有网络请求都必须设置 timeout 参数，建议值为 10 秒。

 2.2 术语库管理
用户可以上传 TMX 格式的术语库。
在翻译过程中，系统会优先匹配术语库中的词汇，确保专业名词的统一性。
术语库的匹配算法采用了最长字符串匹配策略。

## 3. 部署指南
 3.1 Docker 环境
请确保本地安装了 Docker 和 Docker Compose。
运行 `docker-compose up -d` 即可启动所有服务，包括 Web、Redis 和 Postgres。
数据库的默认端口映射为 5432，Redis 为 6379。

 3.2 数据库迁移
我们使用 Alembic 进行数据库版本管理。
如果修改了 models.py，请务必执行 `alembic revision --autogenerate` 生成迁移脚本，
然后执行 `alembic upgrade head` 应用变更。

## 4. 常见问题
Q: 为什么上传大文件会失败？
A: 请检查 Nginx 配置中的 client_max_body_size 设置，默认限制为 1MB，建议调整为 50MB。
"""

# 2. 初始化切分器
text_splitter = RecursiveCharacterTextSplitter(
 # chunk_size: 每个块的目标大小（字符数）。
 # 设置为 100-500 之间通常比较适合做 Embedding。
 chunk_size=200,

 # chunk_overlap: 重叠部分。
 # 这是一个关键技巧！让两个块之间有重叠，防止切分时把一句话切断，导致上下文丢失。
 chunk_overlap=50,

 # separators: 切分优先级。先试着按双换行切，不行就按单换行，再不行按空格。
 separators=["\n\n", "\n", " ", ""]
)

# 3. 执行切分
chunks = text_splitter.create_documents([long_text])

# 4. 打印结果
print(f">>> 原始文本长度: {len(long_text)}")
print(f">>> 切分后的块数: {len(chunks)}\n")

print("--- 切分详情 ---")
for i, chunk in enumerate(chunks):
 content = chunk.page_content
 print(f"[块 {i+1}] (长度 {len(content)}):")
 print(f"\"{content}\"") # 打印内容
 print("-" * 30)

运行结果分析

你会发现，它不会在“TransMaster”这个词中间切开，而是尽量在段落结束的地方切开。同时，由于设置了 chunk_overlap=50，你可以观察到块1的结尾和块2的开头会有部分重复的内容。

3. 如何集成到刚才的 RAG 代码中？

把你刚才那个 rag_bailian_milvus.py 的 “3. 模拟私有数据并入库” 部分替换为下面的逻辑：

# ... (前面的代码保持不变) ...
from langchain_text_splitters import RecursiveCharacterTextSplitter

# 假设这是从文件读取出来的超长内容
raw_content = "......这里是很长的 TransMaster 项目文档......"

# 1. 切分
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=100)
split_docs = splitter.create_documents([raw_content])

print(f">>> 文档已切分为 {len(split_docs)} 个片段，开始向量化...")

data_vectors = []
data_texts = []

# 2. 遍历切分后的片段进行 Embedding
for doc in split_docs:
 chunk_text = doc.page_content

 # 调用百炼 API 获得向量
 try:
 vec = get_embedding(chunk_text)

 data_vectors.append(vec)
 data_texts.append(chunk_text)
 print(f" - 已处理片段: {chunk_text[:30]}...") # 打印前30个字示意
 except Exception as e:
 print(f" x 跳过出错片段: {e}")

# 3. 批量插入 Milvus
if data_vectors:
 collection.insert([data_vectors, data_texts])
 collection.flush()
 print(f">>> 成功入库 {len(data_vectors)} 个知识片段！")

# ... (后面的搜索代码保持不变) ...

总结：最佳实践参数

对于中文技术文档（如你的 Python 后端开发文档），我推荐以下参数：

Model: 阿里云 text-embedding-v2
Chunk Size: 300 - 500 字符 (中文含金量高，不需要太长)
Overlap: 50 - 100 字符 (保证上下文连续)
Separators: ["\n\n", "\n", "。", "！", "？"] (优先按段落切，其次按句号切)

这样切分后存入 Milvus，当你问“TransMaster 用什么数据库？”时，RAG 就能精准定位到包含“PostgreSQL”的那一小段文字，而不是把整篇文档都拉出来。