Naive RAG 就是 Chunk → Embedding → Top-K → LLM。单点事实够用，多跳、全局主题、硬条件过滤就容易翻车。

GraphRAG 的做法是先把语料做成图（实体、关系、属性，也可以加社区/层级），查询时语义找入口，图上再扩一层，最后才生成：

1
2
3
4
索引：文档 → 抽取 →（对齐）→ 图库
           └→ Embedding / 倒排 → 向量库或 ES

查询：Query → 入口召回拿到 ID → 图扩散 / 社区 / 重排 → 上下文 → LLM

下面按落地要拍板的几件事记：图库、向量、抽取、Schema、检索、Benchmark。中间夹一点自己项目里用过的判断。

1. 图库

图库干的事很具体：存点边、按 ID 扩邻居、属性过滤，有时还要跑 PageRank、社区发现。

图库 查询语言 我怎么看
Neo4j Cypher 生态最熟，GDS、示例多；新版本还能挂节点向量，小规模可以考虑「图里顺便做入口」
HugeGraph Gremlin 国内见得多，分布式、多存储后端，偏大规模 OLTP
NebulaGraph nGQL 超大图、路径查询强，也在补向量/全文
JanusGraph Gremlin 挂 Cassandra/HBase 那种，灵活，运维重
FalkorDB / Memgraph openCypher 一类 偏低延迟；体量和生态不如 Neo4j
RDF（如 GraphDB） SPARQL 本体、推理向，和 LLM 随便抽三元组那套路不太同构

选型上我不太信「榜单第一」。更在意：

  • 团队会不会写多跳、会不会看执行计划（Cypher 通常比 Gremlin 好上手）
  • 边到千万～亿级有没有，有的话 HugeGraph / Nebula / Janus 才进短名单
  • PageRank、社区发现是内置还是要外挂
  • 向量要不要拆出去（拆出去性能好，多一跳一致性和延迟）

HugeGraph 和 Neo4j 能不能平替？
数据模型都是属性图，知识层 Schema、仓储接口可以按「可替换」来设计。查询语言、客户端、运维不是换依赖就能热插拔。项目里两套都碰过，所以业务里尽量别写死某一种方言。

2. 向量 / 检索入口

向量这边的任务其实就一句：听懂口语 Query，吐出能和图 join 的 ID（Chunk / Entity）+ score。

系统 适合什么 别忽略什么
Milvus 大规模纯向量、ANN 种类全 关键词弱，常要另接 ES
ES / OpenSearch BM25 + 向量一条链，过滤熟 超大规模纯向量未必比专库稳
Qdrant / Weaviate 过滤、payload、云原生 看团队基础设施熟不熟
pgvector 和业务库一体、省事 量起来要单独评估
Faiss 嵌进程、算法灵活 服务化、持久化自己扛
图内向量（如 Neo4j） 少一次跨库 入口规模大了可能不够

我自己选型时 ES 和 Milvus 都能接受，契约先定死：

1
[{ id, score, payload? }, ...]

后面图扩散只认 ID。引擎换了，Schema 和遍历逻辑不用跟着翻。

HNSW 的 M、ef 该调还是要调，那是召回和延迟的常规杠杆；和「用哪家向量库」是两层问题。

3. 抽取

抽取脏了，后面检索再漂亮也是断图。

方案 优点 坑
Prompt + 通用 LLM 启动快，关系类型灵活 JSON 易崩，贵、慢，长文/表格不稳
UIE / 结构化抽取 格式稳，可部署，成本可控 要适配 schema，开放关系不如大模型
传统 NER → 关系 可控、端侧友好 迁移贵，隐式关系弱
小模型微调（Qwen 等） 垂直域准确率和格式能拉高 要语料和训练链路
版面解析再抽（MinerU 等） 先治「输入源脏」 多一截流水线
框架内置 indexer（如微软 GraphRAG） 和社区摘要流水线对齐 贵，改 schema 麻烦

经验上冷启动先 Prompt，但一定要校验和重试；字段固定、要吞吐就上 UIE 或小模型。PDF 出问题，先分清是版面错还是 IE 错，别混在一块调。

自己做过 UIE 和 Prompt：表格/固定槽位偏 UIE，开放关系、快速试 schema 偏 Prompt。常见组合是解析打底 → UIE 保核心字段 → Prompt 补开放关系。

4. Schema：先认知识形态，再谈分层

Schema 不是先画一张万能 ER。抽出来是什么形状，图上就要有对应的点边约定。

4.1 六种常见知识形态

前面两种工程里最常见：

形态 抽什么 图上长什么样
概念拓扑（三元组） 谁和谁、什么关系 (h)-[r]->(t)
实例属性填空 表单/表格字段 实体 + 稠密属性（或 EAV）

后面几类也很常见，别硬塞进同一种扁平三元组：

事件脉络 / 事理图谱
抽 Event、Time、Trigger、Actor、Object，连成时间链或因果链。事件要当一等节点，边写顺承/因果，不要只当实体属性。适合审计、交接、风控链条。

多模态连接图
架构图、CAD、仪表盘：VLM 把箭头变成 调用/连接 边，证据链回图片区域或页码，不只是文本 Chunk。问「引脚怎么接」时，靠的是这张连接图。

文档树 Doc-Tree
抽的是章/节/段归属，不是业务实体。章-包含→节-包含→Chunk。命中一段后沿树上溯或捞邻段，专门对付长文断章取义。可以和实体图并存：同一个 Chunk 既挂树，又 mention 实体。

数据血缘 Lineage
从代码、SQL、API、配置抽依赖：API → Service → Table/Column。字段改名、服务升级看影响面，靠这种图。

对照一下：

1
2
3
4
5
6
纯文本关系   → 实体关系 Schema
表单/表格    → 实体 + 属性
叙事演进     → 事理 / 时间轴
图/音视频    → 连接 / 空间关系
长文档版面   → Doc-Tree
代码 SQL 配置 → Lineage

都能进图谱，不等于共用一套边类型。多形态就分子图或边前缀，查询按题型路由。

4.2 怎么铺层

做法 什么时候有用 代价
扁平三元组 快速验证抽取和多跳 宏观弱，易超级节点
Chunk + 实体双层 LightRAG 那种局部+全局 mention、对齐要维护
Doc-Tree + 实体双轨 长文档 两套边，查询要会分流
社区层次（微软 GraphRAG） 全局主题 索引贵，更新重
强本体 主数据、合规 和 LLM 开放抽取要调和
类 HNSW：上层少、下层密 先粗后细的导航直觉 上层到底是社区、类型还是章节，必须说清楚
事理/血缘子图 溯源、变更影响 别和纯实体 Schema 搅在一起

关系类型也是：全用 RELATED 好抽，扩散噪声大；mention / 事实 / 包含 / 依赖分开，才能按边控深。组织边、事理边、血缘边语义不一样，扩散策略不要混用。

自己这边： Schema 还没定稿。倾向双层（Chunk + 实体）+ 属性过滤，导航上借用 HNSW「上层少、下层密」。设计讨论里提过核心控制、双层、三类关系、属性过滤——三类关系的最终边名等定稿再写，不在这里先列一张假表。六类形态哪些进业务，进了就单独开子 Schema。

5. 检索：图建好之后怎么捞

检索可以按机制拆几派。微软社区流、LightRAG 是用得比较多的两条；路径剪枝、Agent 迭代、混合重排、文档树恢复也值得建档。

5.1 对照

流派 代表 擅长 代价
社区 / 摘要 微软 GraphRAG Global 等 跨文档主题、全局趋势 索引贵、更新重
双层双路 LightRAG 局部细节 + 一点全局，相对轻 高低层索引要养
路径敏感 / 多跳 PathRAG、PPR、最短路 多约束推理、证据链完整 路径要剪枝，边太粗路径就没语义
Agent 迭代 ToG、GraphFlow 等 根因、审计，深度自适应 慢、贵，要步数熔断
混合召回 + 精排 BM25 + 向量 + 图 + Reranker 高并发、抗噪 链路长，要调融合
Doc-Tree 分支 章→节→段上溯 长手册、防断章 依赖文档树质量
纯向量 Top-K 基线 简单事实 多跳和全局弱

社区流：Leiden 社区 + 社区摘要，宏观题捞摘要再聚合；还有 Local、DRIFT。
LightRAG：Local 走实体邻域，Global 走高层标签/簇，两路融合。
路径派：多个种子实体命中后，在图上找连接路径（或 PathRAG 那种对节点对做 flow-based 路径剪枝），把整条路径说成人话再进 Prompt，比扔孤立节点好推。
Agent 派：查一步、看一眼、再决定扩哪条边；GraphFlow 一类还把「下一步动作」做成策略学习。注意论文里的 flow matching 和工业精排用的 Cross-Encoder 不是一层东西。
混合派：ES 抓字面、向量抓语义、图扩关联，候选合并（可用 RRF），再 Cross-Encoder / PageRank 收口，只留 Top-K。单路抽错不至于整链死。
树状恢复：命中 Chunk 后沿 Doc-Tree 上溯章/节，打包分支；和实体路径可以双轨。

5.2 一条常用闭环：混合入口 + 有界路径 + 重排

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class AdvancedGraphRetriever:
    def __init__(self, vector_db, keyword_db, graph_db, reranker):
        self.vector_db = vector_db
        self.keyword_db = keyword_db
        self.graph_db = graph_db
        self.reranker = reranker  # 如 BGE-Reranker

    def retrieve(self, query, top_k=5):
        seeds = merge_ids(
            self.vector_db.search(query, top_k=10),
            self.keyword_db.search(query, top_k=10),
        )
        raw_paths = self.graph_db.expand_paths(
            seeds, max_hops=2, edge_types=["fact_relation"], limit=50
        )
        contexts = [
            serialize_path(p) + " | 出处: " + related_chunks(p)
            for p in raw_paths
        ]
        ranked = self.reranker.compute_scores(query, contexts)
        return [
            x["text"]
            for x in sorted(ranked, key=lambda i: i["score"], reverse=True)[:top_k]
        ]

max_hops 和 LIMIT 不是细节，是防超级节点把图库打爆的基本纪律。

题型可以大致对一下：

题型 优先试
全局趋势 社区摘要
要快、要细节 双层双路
多实体约束 路径 + 文本化
根因 / 审计 Agent（加熔断）
高并发要稳 混合 + Cross-Encoder
长手册 Doc-Tree 分支

默认主路径用 Benchmark 选。社区、双层、路径+重排（可加 PageRank）、有树再加树状恢复，同一题集对比；Agent 单独用复杂题子集测，别和低延迟主路径抢位。

6. Benchmark

没有题集，上面那些表都只是意见。

指标上至少分开看：检索有没有捞到金标实体/三元组（Recall、Hit）、路径够不够、生成质量（EM/F1/Judge，要控生成模型变量）、全局题主题覆盖、延迟和 Token、改写 Query 的鲁棒性。

题从哪来：公开集（HotpotQA、2Wiki、GraphRAG-Bench）可复现但对不齐领域；业务金标最贴近但贵；LLM 合成题便宜但容易虚高；线上日志有分布但要脱敏、冷启动没有。

粒度也要拆：抽取 F1、对齐、向量召回、图扩散、重排 NDCG 做组件门禁；换检索策略做 A/B；最后才端到端验收。换了抽取或 Schema，索引版本要重跑，避免检索背锅。

我觉得够格的 Benchmark 至少有：固定题 + 金标证据 ID/三元组；组件报表和端到端报表；多策略同题对比；主表带成本和延迟；公开集验证方法、领域集做上线门禁。

自己更想先把这套库搭起来，再堆队列、SSE 那些工程件。

7. 取舍和工程

轴 追上限时 追成本和速度时
图库 GDS/超大规模分布式 团队最熟的那套 + 仓储抽象
向量 专库 ANN ES 混合或够用的同栈向量
抽取 大模型开放抽 + 社区摘要 UIE/小模型
Schema 按形态分域 Chunk–实体双层 + 强属性，Doc-Tree 按需
检索 路径 / 社区 / Agent 混合召回 + Rerank + LIMIT；双层双路也常够用
Benchmark 公开多跳 + Judge 领域金标 + 组件门禁 + 成本

抽取 → Schema → 检索 → Benchmark 还没跑顺之前，不必先上消息队列全家桶。真要上线再补：async + SSE、写入异步、图查询超时和 LIMIT、图挂了降级纯向量、Trace 拆耗时。工程放大的是已经对的检索，救不了建错的图。

目前项目侧比较明确的是：图库 HugeGraph / Neo4j 按接口抽象；向量统一吐 node_id；抽取走过 UIE 和 Prompt；Schema 还在构想；检索多路线建档，用 Benchmark 定默认路径。