GraphRAG：用图结构补充向量检索

发表于2025-09-06|人工智能

|浏览量:

向量 Top-K 擅长相似片段，GraphRAG 补关系推理与全局摘要类问题。

动机

Chunk 孤岛化；向量相似度不保证逻辑邻接；「整个库的趋势」类问题需社区检测与图遍历。GraphRAG 构建实体关系图，检索时走子图 + 摘要。

机制

索引期：抽取实体边、社区划分、生成社区摘要。查询期：局部向量检索 + 图扩展 + 汇总 Prompt。成本高于纯向量 RAG。

选型

适合关系密集、多跳问答、研报类全局问题。简单 FAQ 纯向量即可。可混合：向量初召 + 图 refine。

误区

一切上图；忽视构建与更新成本；图质量差于向量 baseline 未对比评测。

延伸思考

GraphRAG 索引成本包含实体抽取 LLM 调用、社区摘要生成与图存储。查询时若走全局搜索，延迟高于普通 RAG，适合离线分析型问答而非毫秒级客服。与向量混合：先用向量找种子实体，再 k-hop 扩展。更新时图边也需增量维护，否则节点过期。评测应用多跳数据集验证是否真的优于 baseline，避免为图而图。

实践小结

练习：选 5 个多跳问题，对比向量 RAG 与（若有）图扩展结果。估算构图 LLM 成本是否可接受。明确团队是否有「必须 GraphRAG」的数据特征。

工程检查清单

检查清单：是否真有多跳需求；构图成本；更新策略；与向量 baseline 对比指标。GraphRAG 是补充而非默认方案。

读者 takeaway

读者 takeaway：GraphRAG 解决关系和全局性问题，不是向量 RAG 的简单升级。用数据和成本证明需要它，否则维护图结构的投入可能高于收益。

学习建议

文章作者: Dai Wei

文章链接: https://www.daiwei.biz/knowledge/ai/rag/graphrag/

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Dai Wei！

RAG GraphRAG 知识图谱

扫码打赏

微信
支付宝

相关推荐

RAG 面试题总结

RAG 面试重点在召回链路而非「向量库名词」。基础RAG 阶段：离线索引与在线检索生成；Embedding 与相似度；混合检索；幻觉与引用。进阶Chunk 策略、Parent-Child、重排、Query 改写；权限过滤在召回前；增量更新与 embedding 版本一致。 GraphRAG何时补图结构；多跳 vs 向量 Top-K；成本权衡。排查题「答非所问」从解析、Chunk、召回、重排、Prompt 五层查。误区：只会说 Milvus 不会说评测闭环。延伸思考Chunk 题比较固定长、递归、语义、Parent-Child 适用场景。优化题说闭环：Badcase 标注→定位层→改策略→回归。更新题强调 embedding 版本一致与 delete-then-insert。GraphRAG 题说何时值得：多跳、全局摘要、关系密集域。排查「胡编」先查检索是否空、引用是否匹配、模型是否忽略 context。准备混合检索公式：BM25 召回 + 向量召回 + RRF 合并 + cross-encoder 重排。实践小结练习：对一条「答非所问」样本做五层排查笔记。口述混合检...

RAG 专题：文档处理、向量数据库、GraphRAG、检索优化与知识库更新

RAG 专题解决「让模型基于可更新、可溯源的企业知识回答」的问题。链路总览解析 → 清洗 → Chunk → Embedding → 索引 → 查询改写 → 召回 → 重排 → 生成 → 引用。任一环节弱则整体「答非所问」。子专题文档处理定上限；向量库定规模与延迟；优化定召回率；GraphRAG 补关系；更新保时效。与 LLM 评测、权限设计联动。实践顺序rag-basis → document-processing → vector-store → optimization → knowledge-update → graphrag。误区只买向量库不做 Chunk 评测；无权限过滤；忽视 embedding 模型版本锁定。延伸思考企业 RAG 项目常见里程碑：M1 单库 FAQ、M2 混合检索+重排、M3 权限与更新、M4 评测闭环、M5 Graph/Agent 扩展。每阶段定义可量化指标，如 Recall@5、人工评分>=4 的比例。文档处理与向量库选型往往被低估工期——扫描件 PDF、表格、多语言混合是常态。专题学习后应能独立设计索引...

RAG 基础概念：检索、生成与工程取舍

RAG 在检索与生成之间架桥，解决时效、私有数据与幻觉三难题（非零幻觉）。工作原理离线索引六步：摄入、清洗、元数据、Chunk、Embedding、入库。在线：Query 向量化 → 相似检索 → 上下文增强 → 生成 + 引用。为何需要预训练知识过期；企业数据不可外泄；生成需证据降低胡编。但仍可能检索错、引用错、模型不跟指令。与搜索对比找文档用搜索；读文档答问题用 RAG。很多企业双入口并存。RAG 延迟与成本更高，需评测与 ACL。误区RAG 消灭幻觉；Chunk 越大越好；不做混合检索与重排。延伸思考Embedding 模型选择看语种、领域、维度与推理成本；查询与文档应同一模型。相似度 metric 要与索引实现一致（cosine/L2/IP）。与微调对比：RAG 适合知识频繁变、需 citation；微调适合风格/格式固定、知识相对稳定。长上下文可补 RAG 但无法替代权限与溯源。生产 RAG 必做：低分拒答、引用片段展示、用户反馈回流索引。实践小结练习：手工走一遍索引+查询，打印 top5 chunk 与最终答案，检查 gr...

RAG 文档处理与切分策略：从解析、清洗、Chunking 到多模态内容处理

上传前半段决定 RAG 上限——Garbage In, Garbage Out。处理链路格式解析（PDF/HTML/Office）→ 去噪 → 结构识别（标题/table）→ Chunk → 元数据（来源、页码、ACL）→ Embedding。 Chunk 策略固定长度简单但断语义；递归字符保段落；语义切分贵；按标题/结构切边界清晰；Parent-Child 小 chunk 召回、大 parent 生成。重叠缓解边界截断。多模态图/表需 OCR 或专用模型；表格转 Markdown 保结构。代码库按函数/类切分。误区不清洗 HTML 噪声；统一 chunk size；无元数据无法过滤与溯源。延伸思考PDF 解析优先保结构：标题层级、列表、表格单元格边界。代码文档按函数切分并保留 import 上下文。FAQ 可整段为 chunk。重叠 size 通常 10%-20% chunk length。Metadata 至少含 source_id、page、section、acl、lang、updated_at，供过滤...

AI 应用开发知识体系：大模型、Agent、RAG、MCP、Prompt 工程与系统设计

AI 应用开发不是单点调 API，而是模型、检索、工具、评测与运维的串联工程。知识主线后端工程师进入 AI 领域，建议按四条线并行：大模型基础（Token、采样、结构化输出）、Agent（Loop、Memory、工具）、RAG（索引、召回、更新）、系统设计（网关、安全、可观测、评测）。四条线互相依赖——只懂 Prompt 不懂召回，知识库问答会翻车；只懂 RAG 不懂权限，生产环境会泄露。工作机制一次典型企业问答请求：入口鉴权 → 查询改写 → 混合检索 → 重排 → 上下文组装 → 模型生成 → 引用校验 → 日志落盘。任何环节缺失都会在 Demo 与生产之间形成鸿沟。工程实践优先建立 Golden Set 与回归评测，再迭代 Prompt 和检索；网关层统一限流、路由与成本核算；Agent 工具调用必须最小权限 + 审计。学习顺序建议：核心概念 → LLM 机制 → Agent/RAG 专题 → 面试题查漏补缺 → 系统设计收尾。常见误区把「全量文档塞进上下文」当 RAG；把 MCP 当安全方案；忽略 Token 预算导致长任务失忆；Demo 未做失败重...

AI Agent 记忆系统：短期记忆、长期记忆与记忆演化机制

记忆让 Agent 跨轮次保持任务连贯，也是长对话失控的主要变量。记忆分类短期记忆通常是对话历史与当前任务状态，受上下文窗口限制。长期记忆存用户偏好、历史结论、实体关系，常用向量库或 KV/图数据库。 episodic 记「发生了什么」，semantic 记「知道什么」。生命周期写入：工具结果、用户确认、摘要压缩后入库。读取：按 query 检索相关记忆注入上下文。更新：冲突合并、过期淘汰、重要性打分。遗忘：主动删除敏感或过时条目。与 RAG 的边界RAG 面向企业知识库、强调溯源与权限；Memory 面向会话/用户态、强调个性化与任务连续。二者可共存：RAG 供事实，Memory 供交互历史。勿把整库当 Memory 无差别注入。实践与误区长任务定期做 rolling summary；记忆写入前脱敏。误区：无限追加历史导致偏题；不做去重重复注入矛盾信息；长期记忆无 TTL 引发隐私风险。延伸思考工程上可为 Memory 设计写入门槛：仅持久化用户显式确认、工具返回的结构化结论、或经摘要压缩后的高价值事实。读取侧做相关性阈值，低于阈值不注入，避免...

评论

数据加载中