一、为什么需要Graphiti？

传统的RAG（检索增强生成）系统在处理动态变化的数据时遇到了瓶颈。想象一下，当用户说"我喜欢Adidas鞋子"，几天后又说"我的鞋子坏了，准备买Nike"，传统系统很难准确追踪这种偏好变化。它们依赖批处理和静态摘要，无法实时更新知识，也难以回答"上个月我最喜欢哪个品牌？"这类历史查询。

Graphiti应运而生，它是一个专为AI智能体设计的时序知识图谱框架，解决了动态环境中的知识管理问题。核心突破在于：

• 实时增量更新：新对话立即融入图谱，无需重新计算整个图
• 双时态追踪：同时记录"事件何时发生"和"系统何时知道"，支持时光旅行查询
• 混合检索：结合向量语义、BM25关键词和图遍历，查询延迟降至亚秒级
• 灵活Schema：从零Schema开始，随需扩展自定义实体类型

二、核心架构设计

Graphiti的架构由三层组成：数据层、处理层和检索层。

2.1 图数据库选择

Graphiti支持多种图数据库后端，通过统一的GraphDriver接口实现：

数据库	版本要求	适用场景
Neo4j	5.26+	生产环境（默认）
FalkorDB	1.1.2+	基于Redis的高性能场景
Kuzu	0.11.2+	本地开发和嵌入式应用
Amazon Neptune	-	AWS云端大规模部署

from graphiti_core import Graphitifrom graphiti_core.driver.neo4j_driver import Neo4jDriver# Neo4j配置示例driver = Neo4jDriver(    uri="bolt://localhost:7687",    user="neo4j",     password="password",    database="agent_memory")graphiti = Graphiti(graph_driver=driver)

三、双时态数据模型：时光旅行的秘密

传统系统只记录"当前状态"，而Graphiti引入双时态模型，分别追踪两个时间维度：

3.1 两个时间维度

1. Valid Time（有效时间） - 事实在现实世界中为真的时间

• valid_at：关系建立的时间点
• invalid_at：关系失效的时间点

2. Transaction Time（事务时间） - 事实被系统记录的时间

• created_at：节点/边的创建时间戳

3.2 时间信息提取

LLM会从对话内容中智能提取时间信息，支持：

• 绝对时间：2024年10月28日
• 相对时间：10年前、2分钟前（基于参考时间戳计算）
• 模糊时间：只有年份时默认为1月1日00:00:00

所有时间统一使用ISO 8601格式：YYYY-MM-DDTHH:MM:SS.SSSSSSZ

3.3 矛盾处理机制

当系统检测到矛盾信息时，不是简单删除旧数据，而是通过invalid_at字段标记失效：

时间T1: Edge(fact="Robbie只穿Adidas鞋", valid_at=T1, invalid_at=null)时间T2: 新事实"Robbie准备穿Nike"结果:  - 旧边: Edge(fact="Robbie只穿Adidas鞋", valid_at=T1, invalid_at=T2)  - 新边: Edge(fact="Robbie准备穿Nike", valid_at=T2, invalid_at=null)

这种设计让知识图谱拥有"记忆"——既知道当前状态，也保留完整历史。

四、Schema设计：从零到定制

Graphiti采用渐进式Schema策略，无需预先定义复杂的本体结构。

4.1 默认Schema：开箱即用

系统使用通用的Entity节点和EntityEdge关系，适合快速启动：

await graphiti.add_episode(    name="user_chat",    episode_body="John在TechCorp工作，负责软件开发",    reference_time=datetime.now())

4.2 自定义实体类型

当需要结构化属性时，通过Pydantic模型定义：

from pydantic import BaseModel, Fieldclass Person(BaseModel):    """人物实体"""    age: int | None = Field(None, description="年龄")    occupation: str | None = Field(None, description="职业")class Organization(BaseModel):    """组织实体"""    industry: str | None = Field(None, description="所属行业")entity_types = {    "Person": Person,    "Organization": Organization}await graphiti.add_episode(    name="meeting",    episode_body="John，30岁，在TechCorp工作，该公司属于软件行业",    entity_types=entity_types)

4.3 自定义关系类型

通过edge_type_map定义实体对之间允许的关系：

edge_types = {    "WORKS_AT": WorksAtRelation,    "MANAGES": ManagesRelation}edge_type_map = {    ("Person", "Organization"): ["WORKS_AT"],    ("Person", "Person"): ["MANAGES"]}

这些类型信息会传递给LLM，指导其提取符合业务逻辑的关系。

五、图谱构建：两阶段提取策略

Graphiti采用先实体后关系的两阶段提取，避免指代歧义。

5.1 阶段1：实体提取

关键步骤：

1. LLM提取 - 调用extract_nodes()从Episode内容中识别实体
2. Reflexion机制 - 通过MAX_REFLEXION_ITERATIONS次迭代（最多2次）检查是否遗漏
3. 去重解析 - 使用嵌入相似度（阈值0.8）+ LLM判断识别重复实体
4. 属性提取 - 为自定义实体类型填充结构化属性

5.2 阶段2：关系提取

```plaintext

关系提取Prompt的核心约"只提取满足以下条件的关系：1. 主体和客体都必须来自已识别的ENTITIES列表2. 必须涉及两个不同的实体3. 关系类型使用SCREAMING_SNAKE_CASE格式（如WORKS_AT）4. 不得编造或推断时间信息5. fact_text应直接引用或紧密释义原文"

为什么是两阶段？

• 降低认知负担：实体作为"锚点"先被识别，关系提取时可引用明确的实体ID
• 避免指代不清：确保"他"、"那家公司"等代词已被解析为具体实体
• 提高准确性：分而治之，每个阶段专注单一任务

5.3 并发控制

系统通过环境变量SEMAPHORE_LIMIT（默认10）控制并发数，防止触发LLM的速率限制。在MCP服务器中，使用队列机制确保同一group_id的Episode按顺序处理，避免竞态条件。

六、混合检索：三管齐下的RAG增强

Graphiti的检索系统结合三种互补方法，实现亚秒级查询。

6.1 三种检索方法

方法	实现	索引	擅长场景
BM25全文检索	edge_fulltext_search()	edge_name_and_fact 全文索引	关键词精确匹配
向量相似度	edge_similarity_search()	fact_embedding 向量索引	语义相似查询
图遍历BFS	edge_bfs_search()	图结构遍历	关系链路查询

6.2 预配置搜索策略

策略1：基础混合搜索（RRF融合）

from graphiti_core.search.search_config_recipes import EDGE_HYBRID_SEARCH_RRFresults = await graphiti.search(    query="John的工作信息",    config=EDGE_HYBRID_SEARCH_RRF,    group_ids=["user_123"])

RRF（倒数排名融合）算法合并BM25和向量搜索结果，平衡关键词和语义匹配。

策略2：图遍历增强搜索

from graphiti_core.search.search_config_recipes import EDGE_HYBRID_SEARCH_NODE_DISTANCEresults = await graphiti.search(    query="与John相关的所有信息",    config=EDGE_HYBRID_SEARCH_NODE_DISTANCE,    center_node_uuid="john_uuid"  # 以John为中心)

从中心节点出发进行BFS遍历，根据图距离调整结果排序，发现隐藏的关联关系。

策略3：Cross-Encoder深度重排序

from graphiti_core.search.search_config_recipes import COMBINED_HYBRID_SEARCH_CROSS_ENCODERresults = await graphiti.search(    query="John的职业发展路径",    config=COMBINED_HYBRID_SEARCH_CROSS_ENCODER)

使用LLM对初步结果进行深度语义重排序，适合复杂查询。

6.3 Prompt拼装示例

# 1. 检索相关事实edges = await graphiti.search(    query="用户的饮食偏好",    num_results=10)# 2. 格式化为上下文context = "\n".join([    f"- {edge.fact} (时间: {edge.valid_at})"    for edge in edges])# 3. 拼装RAG Promptprompt = f"""基于以下知识图谱中的事实回答问题：<FACTS>{context}</FACTS><QUESTION>{user_question}</QUESTION>请基于FACTS中的信息回答，不要编造内容。如果信息不足，请明确说明。"""

6.4 检索性能对比

与传统GraphRAG的数秒到数十秒相比，Graphiti的查询延迟通常在亚秒级。

七、质量评估：LLM-as-Judge

Graphiti使用LLM作为评判者的方法评估图谱构建质量。

7.1 评估流程

7.2 评估Prompt示例

"""给定PREVIOUS MESSAGES和MESSAGE，判断CANDIDATE图谱提取是否优于BASELINE。评判标准：1. 实体提取的完整性（召回率）2. 关系提取的准确性（精确率）3. 是否存在幻觉或遗漏4. 整体质量对比如果CANDIDATE更好或质量相近，返回True；否则返回False。"""

7.3 隐含评估指标

虽然没有明确的量化指标，但评估隐含考虑：

• 召回率：是否提取了所有重要实体和关系
• 准确率：提取的信息是否正确
• 一致性：跨Episode的实体去重是否准确
• 时态正确性：时间信息提取是否准确

局限性：LLM-as-Judge方法可能存在评判偏差，建议结合人工抽样验证。

八、Graphiti vs GraphRAG：核心差异

维度	GraphRAG	Graphiti
主要用途	静态文档摘要	动态数据管理
数据处理	批处理	连续增量更新
知识结构	实体集群+社区摘要	情节数据+语义实体+社区
检索方法	顺序LLM摘要	混合语义+关键词+图搜索
适应性	低	高
时态处理	基础时间戳	双时态显式追踪
矛盾处理	LLM驱动的摘要判断	时态边失效
查询延迟	数秒到数十秒	通常亚秒级
自定义实体	否	是，灵活定制
可扩展性	中等	高，优化大规模数据集

适用场景：

• GraphRAG：适合对静态文档集合进行一次性分析和摘要
• Graphiti：适合需要实时交互、精确历史查询的AI智能体应用

九、实战建议

9.1 渐进式开发路径

9.2 检索策略选择指南

查询类型	推荐策略	原因
简单事实查询	EDGE_HYBRID_SEARCH_RRF	平衡速度和准确性
关系链查询	EDGE_HYBRID_SEARCH_NODE_DISTANCE	利用图结构发现关联
复杂语义查询	COMBINED_HYBRID_SEARCH_CROSS_ENCODER	深度语义理解
时间范围查询	使用SearchFilters时间过滤	精确时态查询

9.3 性能优化要点

1. 并发控制：根据LLM提供商的速率限制调整SEMAPHORE_LIMIT
2. 批量处理：对历史数据使用批量摄入，降低延迟
3. 索引优化：确保Neo4j的向量索引和全文索引正确构建
4. 嵌入模型选择：根据业务场景选择合适的嵌入模型（平衡精度和速度）

十、总结

Graphiti将静态的批处理知识图谱转变为能够实时演化的动态记忆系统，特别适合AI智能体在动态环境中的应用场景。

核心创新点：

1. 实时增量更新 - 告别批处理，新对话即刻融入
2. 双时态模型 - 记住历史，回答"过去时"问题
3. 两阶段提取 - 先实体后关系，降低歧义
4. 混合检索 - 三管齐下，查询延迟降至亚秒级
5. 灵活Schema - 从零到定制，渐进式演进

Graphiti不仅仅是一个技术框架，更是AI智能体记忆管理的新范式。它让智能体拥有了"时光旅行"的能力——既记得当前状态，也能回溯历史，在动态世界中保持连贯的上下文感知。

如何高效转型Al大模型领域？

作为一名在一线互联网行业奋斗多年的老兵，我深知持续学习和进步的重要性，尤其是在复杂且深入的Al大模型开发领域。为什么精准学习如此关键？

• 系统的技术路线图：帮助你从入门到精通，明确所需掌握的知识点。
• 高效有序的学习路径：避免无效学习，节省时间，提升效率。
• 完整的知识体系：建立系统的知识框架，为职业发展打下坚实基础。

AI大模型从业者的核心竞争力

• 持续学习能力：Al技术日新月异，保持学习是关键。
• 跨领域思维：Al大模型需要结合业务场景，具备跨领域思考能力的从业者更受欢迎。
• 解决问题的能力：AI大模型的应用需要解决实际问题，你的编程经验将大放异彩。

以前总有人问我说：老师能不能帮我预测预测将来的风口在哪里？

现在没什么可说了，一定是Al；我们国家已经提出来：算力即国力！

未来已来，大模型在未来必然走向人类的生活中，无论你是前端，后端还是数据分析，都可以在这个领域上来，我还是那句话，在大语言AI模型时代，只要你有想法，你就有结果！只要你愿意去学习，你就能卷动的过别人！

现在，你需要的只是一份清晰的转型计划和一群志同道合的伙伴。作为一名热心肠的互联网老兵，我决定把宝贵的AI知识分享给大家。 至于能学习到多少就看你的学习毅力和能力了 。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】