GraphRAG 技能
基于知识图谱的检索增强生成，而非平面分块。 从文档中提取实体和关系，存储在图形数据库中， LLM 在查询时基于图结构进行推理。
为什么用图而不是向量
向量搜索找到的是相似的块。它无法追踪联系：
- “哪些供应商受到了工厂 X 故障的影响？”需要
故障 → 影响 → 工厂 → 由...供应 → 供应商——这是两跳，没有单个块包含。 - “总结我们目前关于项目 Y 的所有信息”需要围绕 Y 的社区 实体，而不是最相似的十个段落。
如果你的问题是单一事实查询，坚持使用向量 RAG——它更简单。 当问题涉及关系时，再用 GraphRAG。
技术栈
- Kuzu — 嵌入式图数据库（
pip install kuzu），无需运行服务器， 使用 Cypher 查询语言。从这里开始。 - Neo4j — 当你超出嵌入式限制时：多用户、更大图、Bloom 可视化。相同的 Cypher 技能可以迁移。
- LLM 提取 — 任何具有结构化输出能力的强模型，用于实体/关系提取。
管道
1. 先定义模式
不要让提取器自由创造类型——你会得到同一个关系的 40 种拼写。 提前声明节点和边的类型：
CREATE NODE TABLE Person(name STRING, PRIMARY KEY(name));
CREATE NODE TABLE Project(name STRING, status STRING, PRIMARY KEY(name));
CREATE NODE TABLE Document(title STRING, date DATE, PRIMARY KEY(title));
CREATE REL TABLE WORKS_ON(FROM Person TO Project, role STRING);
CREATE REL TABLE MENTIONS(FROM Document TO Person);
CREATE REL TABLE MENTIONS_PROJECT(FROM Document TO Project);
保持模式小巧（5-10 种节点类型）。你可以扩展它；但无法廉价地清理一个混乱的已经提取好的图。
2. 提取实体和关系
将文档分块（500-1000 tokens，重叠），然后提示提取器：
请从下面的文本中提取实体和关系。
允许的节点类型：Person, Project, Document
允许的边类型：WORKS_ON (Person→Project), MENTIONS (Document→Person),
MENTIONS_PROJECT (Document→Project)
规则：
- 规范化名称（“J. Smith”和“John Smith”是同一个 Person）
- 只提取文本中明确陈述或清晰暗示的关系
- 返回 JSON：{