向量检索与图检索融合架构
原创
灵阙教研团队
S 精选 进阶 研究报告 |
约 7 分钟阅读
更新于 2026-02-27 AI 导读
向量检索与图检索融合架构 GraphRAG vs VectorRAG 与混合检索实战 | 2026-02 一、两种检索范式的本质差异 大模型时代的知识检索有两条路径：基于向量相似度的语义检索（VectorRAG）和基于图结构的关系检索（GraphRAG）。二者解决的是不同维度的问题： VectorRAG 擅长回答： "跟 X 语义最相似的内容是什么？" -> 基于 embedding...
向量检索与图检索融合架构
GraphRAG vs VectorRAG 与混合检索实战 | 2026-02
一、两种检索范式的本质差异
大模型时代的知识检索有两条路径：基于向量相似度的语义检索（VectorRAG）和基于图结构的关系检索（GraphRAG）。二者解决的是不同维度的问题：
VectorRAG 擅长回答：
"跟 X 语义最相似的内容是什么？"
-> 基于 embedding 余弦相似度，模糊匹配
GraphRAG 擅长回答：
"X 和 Y 之间有什么关系？经过了哪些中间节点？"
-> 基于图遍历，精确的结构化推理
对比分析：
| 维度 | VectorRAG | GraphRAG | 混合架构 |
|---|---|---|---|
| 检索方式 | 语义相似度 (ANN) | 图遍历 + 子图匹配 | 两者结合 |
| 擅长问题 | 模糊语义查询 | 多跳关系推理 | 全类型问题 |
| 数据结构 | 文档块 -> 向量 | 实体-关系三元组 | 文档+图谱 |
| 构建成本 | 低（切片+嵌入） | 高（NER+关系抽取+图构建） | 最高 |
| 维护成本 | 低 | 中-高 | 中-高 |
| 幻觉控制 | 中（可能检索到不相关块） | 强（结构化事实约束） | 最强 |
| 全局视角 | 弱（局部文档块） | 强（全图社区+摘要） | 最强 |
二、VectorRAG 架构解析
2.1 标准流程
文档 -> 分块(Chunking) -> 向量化(Embedding) -> 存入向量数据库
|
用户查询 -> 向量化 -> ANN 检索 -> Top-K 文档块 -> LLM 生成回答
2.2 关键组件选型
| 组件 | 选项 | 推荐 |
|---|---|---|
| 向量数据库 | Milvus / Qdrant / Weaviate / Pinecone / pgvector | Qdrant（轻量）/ Milvus（规模） |
| Embedding | text-embedding-3-large / bge-m3 / jina-v3 | bge-m3（多语言性价比最高） |
| 分块策略 | 固定长度 / 递归分割 / 语义分块 | 语义分块（LlamaIndex SemanticChunker） |
| 重排序 | bge-reranker-v2 / Cohere Rerank | bge-reranker-v2（本地部署） |
2.3 LangChain 实现
from langchain_community.vectorstores import Qdrant
from langchain_openai import OpenAIEmbeddings
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import ChatOpenAI
from langchain.chains import RetrievalQA
# 1. 文档分块
splitter = RecursiveCharacterTextSplitter(chunk_size=512, chunk_overlap=64)
chunks = splitter.split_documents(documents)
# 2. 向量化并存入 Qdrant
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = Qdrant.from_documents(
chunks,
embeddings,
location=":memory:",
collection_name="knowledge_base",
)
# 3. 检索增强生成
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
llm = ChatOpenAI(model="gpt-4o", temperature=0)
qa_chain = RetrievalQA.from_chain_type(llm=llm, retriever=retriever)
answer = qa_chain.invoke("灵阙科技的主要产品是什么？")
2.4 VectorRAG 的局限
- 多跳问题失效："张三的老板的客户是谁？"需要跨文档块关联，单纯向量召回困难
- 全局摘要缺失："这个领域的整体趋势是什么？"向量检索只返回局部片段
- 结构化关系丢失：文档被切片后，实体间的精确关系信息被稀释
三、GraphRAG 架构解析
3.1 微软 GraphRAG 流程
文档 -> LLM 实体抽取 -> LLM 关系抽取 -> 构建知识图谱
|
社区检测 (Leiden)
|
社区摘要 (LLM)
|
┌───────────────────┴───────────────────┐
| |
Local Search Global Search
(实体 + 关系 + (社区摘要 +
局部上下文) Map-Reduce)
3.2 Local Search vs Global Search
| 模式 | 适用问题 | 检索策略 | 示例 |
|---|---|---|---|
| Local | 具体实体查询 | 实体匹配 -> 子图展开 -> 上下文组装 | "Neo4j 的创始人是谁" |
| Global | 全局概述/趋势 | 社区摘要 -> Map(各社区回答) -> Reduce(汇总) | "图数据库行业趋势" |
3.3 LlamaIndex PropertyGraph 实现
from llama_index.core import PropertyGraphIndex, SimpleDirectoryReader
from llama_index.llms.openai import OpenAI
from llama_index.graph_stores.neo4j import Neo4jPropertyGraphStore
# 1. 加载文档
documents = SimpleDirectoryReader("./data").load_data()
# 2. 配置图存储
graph_store = Neo4jPropertyGraphStore(
username="neo4j",
password="password",
url="bolt://localhost:7687",
)
# 3. 构建 PropertyGraph 索引（自动抽取实体和关系）
llm = OpenAI(model="gpt-4o", temperature=0)
index = PropertyGraphIndex.from_documents(
documents,
llm=llm,
graph_store=graph_store,
show_progress=True,
)
# 4. 图检索问答
query_engine = index.as_query_engine(
include_text=True, # 包含原始文本上下文
response_mode="tree_summarize",
)
response = query_engine.query("张三和灵阙科技之间的关系是什么？")
3.4 GraphRAG 的局限
- 构建成本高：LLM 抽取实体和关系的 API 调用费用显著
- 抽取质量不稳定：LLM 可能遗漏实体或抽取错误关系
- 语义模糊查询弱：图检索依赖精确的实体匹配，模糊语义查询不如向量检索
四、混合架构设计
4.1 架构总览
┌─────────────────┐
│ 用户查询 │
└────────┬────────┘
|
┌────────┴────────┐
│ 查询路由器 │
│ (意图分类) │
└───┬────┬────┬───┘
| | |
┌─────────┘ | └──────────┐
v v v
┌────────────┐ ┌──────────┐ ┌─────────────┐
│ 向量检索 │ │ 图检索 │ │ 混合检索 │
│ (语义匹配) │ │ (结构化) │ │ (两者结合) │
└─────┬──────┘ └────┬─────┘ └──────┬──────┘
| | |
└───────────────┼───────────────┘
|
┌──────┴──────┐
│ 结果融合 │
│ + 重排序 │
└──────┬──────┘
|
┌──────┴──────┐
│ LLM 生成 │
│ (带引用) │
└─────────────┘
4.2 查询路由策略
from enum import Enum
class QueryType(Enum):
SEMANTIC = "semantic" # "什么是知识图谱？"
STRUCTURAL = "structural" # "张三的同事有哪些？"
HYBRID = "hybrid" # "知识图谱在风控中有哪些应用案例？"
GLOBAL = "global" # "图数据库行业整体趋势"
def classify_query(query: str, llm) -> QueryType:
"""用 LLM 对查询意图分类"""
prompt = f"""
将以下查询分类为四种类型之一：
- semantic: 概念解释、定义、描述类问题
- structural: 涉及具体实体间关系、路径、多跳推理
- hybrid: 既需要语义理解又需要结构化关系
- global: 全局概述、趋势、总结类问题
查询: {query}
类型:
"""
result = llm.invoke(prompt).content.strip().lower()
return QueryType(result)
def route_query(query: str, query_type: QueryType):
"""根据类型路由到不同检索器"""
if query_type == QueryType.SEMANTIC:
return vector_retrieve(query, k=5)
elif query_type == QueryType.STRUCTURAL:
return graph_retrieve(query)
elif query_type == QueryType.GLOBAL:
return global_search(query)
else: # HYBRID
vec_results = vector_retrieve(query, k=3)
graph_results = graph_retrieve(query)
return merge_and_rerank(vec_results, graph_results)
4.3 结果融合策略
| 策略 | 方法 | 适用场景 |
|---|---|---|
| 分数归一化 | 将向量和图分数归一到 [0,1] 后加权求和 | 两路结果质量稳定 |
| RRF (Reciprocal Rank Fusion) | 1/(k+rank) 加权合并 | 通用场景 |
| LLM 重排序 | 用 LLM 对合并结果做相关性打分 | 质量优先 |
| 交叉验证 | 两路都命中的结果优先 | 高精度场景 |
def reciprocal_rank_fusion(results_lists: list[list], k: int = 60) -> list:
"""RRF 融合多路检索结果"""
scores = {}
for results in results_lists:
for rank, item in enumerate(results):
item_id = item["id"]
if item_id not in scores:
scores[item_id] = {"item": item, "score": 0}
scores[item_id]["score"] += 1.0 / (k + rank + 1)
fused = sorted(scores.values(), key=lambda x: x["score"], reverse=True)
return [entry["item"] for entry in fused]
五、何时用哪种方案
决策树：
你的数据是非结构化文档为主？
|
是 -> 实体关系对业务重要吗？
| |
| 是 -> 混合架构（Vector + Graph）
| 否 -> VectorRAG 足够
|
否 -> 数据已经是结构化的？
|
是 -> 已有知识图谱？
| |
| 是 -> GraphRAG
| 否 -> 先建图谱，再 GraphRAG
|
否 -> 半结构化 -> 混合架构
六、性能基准参考
以 10 万文档（约 50 万文档块、200 万三元组）规模测试：
| 指标 | VectorRAG | GraphRAG (Local) | GraphRAG (Global) | 混合架构 |
|---|---|---|---|---|
| 构建时间 | 2 小时 | 18 小时 | 同左 + 社区摘要 6h | 24 小时 |
| 构建成本 | $5 (embedding) | $150 (LLM 抽取) | $200 (含社区摘要) | $205 |
| 检索延迟 | 50-100ms | 100-300ms | 2-5s (Map-Reduce) | 200-500ms |
| 事实型问题准确率 | 72% | 85% | 68% | 88% |
| 多跳推理准确率 | 35% | 78% | 55% | 82% |
| 全局概述质量 | 4.2/10 | 6.5/10 | 8.8/10 | 8.5/10 |
| 存储空间 | 2 GB | 8 GB | 10 GB | 12 GB |
关键发现：
- 事实型单跳问题：VectorRAG 够用，GraphRAG 成本回报比不高
- 多跳推理问题：GraphRAG 大幅领先，VectorRAG 几乎不可用
- 全局概述问题：GraphRAG Global Search 独有优势
- 混合架构在多数场景取得最佳综合表现，但构建成本最高
七、生产级实现建议
7.1 增量更新策略
class HybridIndexUpdater:
"""混合索引增量更新"""
def update(self, new_documents: list):
# 1. 向量索引更新（低成本）
chunks = self.splitter.split_documents(new_documents)
self.vectorstore.add_documents(chunks)
# 2. 图谱增量更新（高成本，可异步）
for doc in new_documents:
entities, relations = self.extract_knowledge(doc)
self.graph_store.upsert_entities(entities)
self.graph_store.upsert_relations(relations)
# 3. 社区重计算（周期性，非每次更新）
if self.should_recompute_communities():
self.recompute_communities()
7.2 成本优化
- 图谱构建用小模型（GPT-4o-mini / Gemini Flash）抽取，质量损失约 5-10%
- 社区摘要按周更新而非实时更新
- 向量检索用开源 embedding（bge-m3），节省 API 费用
- 查询路由将 60-70% 的简单查询路由到纯向量检索，节省图查询开销
7.3 监控指标
| 指标 | 目标 | 告警阈值 |
|---|---|---|
| 检索延迟 P95 | <500ms | >1000ms |
| 回答准确率（人工抽检） | >85% | <75% |
| 图谱更新延迟 | <24h | >48h |
| 向量索引碎片率 | <20% | >40% |
| LLM Token 消耗 | 按预算 | 超预算 120% |
Maurice | [email protected]
深度加工（NotebookLM 生成）
基于本文内容生成的 PPT 大纲、博客摘要、短视频脚本与 Deep Dive 播客，用于多场景复用
PPT 大纲（5-8 张幻灯片） 点击展开
向量检索与图检索融合架构 — ppt
向量检索与图检索的核心差异
- VectorRAG 擅长基于向量相似度的语义模糊匹配，适合回答“跟 X 语义最相似的内容是什么”[1]。
- GraphRAG 擅长基于图遍历的精确结构化推理，适合回答“实体之间有什么关系”以及寻找多跳路径[1]。
- 从构建和维护成本来看，VectorRAG 较低（切片与向量化），而 GraphRAG 依赖实体抽取和关系构建，成本较高[1]。
- 幻觉控制方面，GraphRAG 凭借结构化的事实约束和社区摘要，具有最强的幻觉控制能力和全局视角[1]。
VectorRAG 架构解析与局限性
- 标准流程主要包括：文档分块（推荐语义分块）、向量化（如使用性价比高的 bge-m3）并存入 Qdrant 或 Milvus 等向量数据库[1]。
- 系统优势：在事实型单跳问题上表现良好，检索延迟极低（通常为 50-100ms），且构建成本极低[2]。
- 局限性一：多跳推理问题极易失效，因为文档切片阻断了跨片段的关联，单纯的向量召回难以找到完整的推理路径[3]。
- 局限性二：缺失全局摘要能力，对于询问行业整体趋势的宏观问题，向量检索只能返回局部片段，且文档切片会稀释实体间的精确关系[3]。
GraphRAG 架构解析与双搜索模式
- 核心构建流程高度依赖大语言模型：包含 LLM 实体抽取、LLM 关系抽取构建知识图谱，并执行 Leiden 社区检测与摘要生成[3]。
- 两种检索模式：Local Search 针对具体实体的子图展开与上下文组装，Global Search 采用 Map-Reduce 应对全局趋势总结[3, 4]。
- 系统优势：在多跳推理问题（准确率 78%）和全局概述质量（8.8/10）上大幅领先纯向量检索[2]。
- 核心局限：构建成本极高（LLM API 调用费用显著），可能面临抽取质量不稳定问题，并且对于语义模糊查询的处理较弱[4, 5]。
向量与图检索混合架构设计
- 查询意图路由：系统前端引入查询路由器，使用 LLM 将查询精准分类为语义、结构化、混合或全局概述四种类型[5]。
- 动态检索调用：根据不同的查询类型，系统灵活选择调用纯向量检索、纯图检索，或同时触发两路联合检索[6]。
- 结果融合策略：在混合查询场景中，采用 RRF（倒数排名融合）、分数归一化加权或交叉验证等方法对多路结果进行合并与重排序[6]。
- 综合表现：混合架构在各类场景下取得了最佳综合表现（多跳准确率达 82%，事实型准确率 88%），但代价是整体构建时间最长且存储空间最高[2]。
架构选型决策与性能基准对比
- 决策依据：如果业务数据以非结构化文档为主，且实体间关系极其重要，优先选择混合架构或 GraphRAG[2]。
- 性能表现对比（以10万文档为例）：VectorRAG 构建仅需 2小时（成本约 $5），混合架构需 24小时并花费 $205，但准确率有质的飞跃[2]。
- 多跳与宏观问题：在解决复杂多跳问题时，VectorRAG 的准确率仅为 35%，几乎不可用，必须依赖图检索的结构化能力[2]。
- 如果企业已有构建成熟的结构化知识图谱，则可直接接入 GraphRAG 进行高效推理[2]。
生产级落地与成本优化建议
- 增量更新策略：向量索引实施低成本即时更新，图谱的增量抽取采用异步处理，而社区重计算只在需要时周期性触发[2, 7]。
- 模型成本优化：在图谱构建阶段使用如 GPT-4o-mini 等小模型提取实体，同时采用开源嵌入模型（如 bge-m3），可大幅节省 API 费用[1, 7]。
- 算力与检索优化：将 60-70% 的简单事实类查询直接路由至纯向量检索，以此有效降低昂贵的图查询与生成开销[7]。
- 系统指标监控：需建立严格的生产告警机制，重点关注检索延迟（P95 <500ms 告警）、人工抽检准确率（低于75%告警）以及 Token 的预算消耗情况[7]。
博客摘要 + 核心看点 点击展开
向量检索与图检索融合架构 — summary
这里为您生成基于文章内容的 SEO 友好博客摘要及核心看点：
SEO 友好博客摘要（约 150 字）
在大模型检索增强生成（RAG）领域，基于语义相似度的向量检索（VectorRAG）与基于关系推理的图检索（GraphRAG）各有优劣[1]。本文深入对比两者的底层逻辑、适用场景与局限性[1-3]。针对复杂业务需求，文章详细讲解了如何通过意图分类的查询路由与 RRF 融合策略构建混合架构[3, 4]。结合详实的性能基准测试与成本分析，为开发者提供从组件选型到生产级落地的一站式实战指南[5, 6]。
核心看点
- **场景互补：**VectorRAG 适合低成本语义匹配，GraphRAG 在多跳推理与全局摘要上优势显著[1, 2, 7]。
- **混合检索：**通过查询路由器与 RRF 结果融合策略，完美结合语义理解与结构化关系推理[3, 4]。
- **降本增效：**混合架构性能最佳但成本高，建议采用小模型抽取与图谱增量更新来优化开销[5, 6]。
60 秒短视频脚本 点击展开
向量检索与图检索融合架构 — video
为您定制的 60 秒短视频脚本如下：
【钩子开场】（12字）
大模型检索，用向量还是图谱？[1]
【核心解说一】（26字）
向量检索成本低，擅长模糊语义匹配，但多跳推理容易失效 [1, 2]。
【核心解说二】（26字）
图检索精于多跳关系与全局总结，但大模型抽取构建成本高 [1, 3, 4]。
【核心解说三】（27字）
混合架构通过意图路由结合两者优势，综合表现最好但最贵 [4, 5]。
【一句收束】
结合具体的业务数据类型与场景需求去灵活选型，才是最优解 [4]。
课后巩固
与本文内容匹配的闪卡与测验，帮助巩固所学知识
延伸阅读
根据本文主题，为你推荐相关的学习资料