Graphiti：让 AI 分清“以前如此”和“现在如此”

一份客户记录说“偏好邮件联系”，后来的沟通却改成了电话；项目周报里的人名没变，负责人已经换过一轮。如果 AI 把这些材料一起找出来，却分不清事实在什么时间成立，资料越全，回答反而越容易混乱。Graphiti 值得关注的地方，就是把“关系什么时候有效”写进知识结构，让应用有机会同时回答现在与过去的问题。

它是 Zep 团队维护的 Python 框架，面向需要持续更新资料的 AI 应用。输入可以是对话、文字记录或结构化数据，处理后形成实体、关系以及关系的时间信息。它提供构图和查询能力，面向有开发支持的团队；直接上传文档就能使用的成品问答助手，还需要另外建设。官方项目说明

一双鞋的偏好，为什么需要时间线

官方动画用 Kendra 的鞋子偏好解释这个问题。先输入她喜欢 Adidas 鞋的陈述，图中出现人物、鞋子与喜欢的关系；后来输入旧鞋坏了、转而喜欢 Puma 的新消息，图中加入新的关系，同时给旧的喜欢关系标记失效时间。

官方动画的末帧，转为静态 PNG。上方 Puma 关系带有生效时间，右下 Adidas 的旧偏好带有失效时间，另保留鞋子损坏这一关系。来源与原动画；可点击图片打开原图。画面为英文示意，不是中文效果测试。

这个例子的关键不在于画出几个圆圈，而在于旧事实没有被直接删掉。问“现在喜欢什么”，应考虑关系当前是否有效；问“之前为什么推荐过另一个品牌”，仍然可以沿历史关系回到当时的材料。这比把新旧陈述压成一段最新摘要，多保留了一层解释变化的依据。

Graphiti 把原始输入称为 episode，可以理解为一条带来源的记录。实体和关系能追溯到产生它们的记录，事实又带有有效期。这使时间与出处可以一起参与检查：某条关系从哪里来，属于哪个阶段，后来是否被新的材料替代。自动抽取仍可能出错，留下来源能帮助人追查错误，并不等于模型获得了事实裁判能力。

查询返回的，也可以是一条带日期的关系

官方快速示例代码把文字与 JSON 数据作为不同类型的记录加入图中，再提出一个关于历史任职的问题。代码的后续处理会打印关系的事实描述，并在存在相应字段时打印有效起止时间。这说明应用拿到的可以是带时间条件的检索材料，而不只是最终的一段聊天回答。

按这一机制，可以设计一个中文教学情境：先导入“五月由小林负责设备采购”，再导入“六月起改由小周负责”。构图阶段识别人、事务和关系变化；查询阶段结合问题语义、关键词与图上的联系，取回相应关系；应用再据此组织回答。“五月找谁”和“现在找谁”应该有不同的检索条件。这是用来说明处理链路的自拟例子，没有实际运行，也不据此承诺中文姓名消歧的效果。

我更看重它对持续变化资料的组织方式：如果知识库经常出现“原来是这样，后来改了”，保留事实的有效期与出处，会比只保存一份最终摘要更有调查价值。若材料长期不变，主要问题只是查某一页说明书，额外建设时间图谱的收益就需要重新衡量。

适合建设应用的团队，门槛也在这里

Graphiti 与 Zep 托管产品要分开看。框架需要团队准备图数据库、语言模型与向量模型，并自行建设数据导入、用户隔离、访问控制和日常运维。官方主文档还提醒，抽取模型最好具备可靠的结构化输出能力；模型输出格式不合要求，可能导致入库失败。自托管框架也不意味着资料一定不离开本机，数据去向取决于接入的模型服务。

代码采用 Apache 2.0 许可证。这里开放的是框架代码，接入的模型权重、数据库产品和用户资料，各自仍有自己的条款。准备进一步了解时，可以从官方示例中的“加入记录—检索关系—检查时间字段”这条路径开始，先判断自己的资料是否真的需要保留变化史。