Graphify 是一个开源的知识图谱构建工具，将知识库转换为知识图谱，来帮助AI 更好地理解项目结构。我会想，这个东西的作用究竟有多大？至少它并没有在我的工作域流行起来。
按照仓库 README 我们先安装 graphify，建议我们先安装 uv 工具，它是下一代 Python 工具链，旨在替代传统的 pip。uv 是使用 rust 开发的，是用新的语言实现了一遍旧的功能吗？
uv tool install graphifyy
这里安装的是 graphifyy，最后是双y，主要是 graphify 单词已经被占用了。如果名称被抢占的话，开源项目有一套常见的命名策略，这可能也算是其中的一种。
现在我们将 graphify 注册到 claude 中，在 claude 通过技能来使用它。这里可以有两种安装选项，一个是用户维度的，另一个是项目维度的。安装后的效果如图（在控制台我习惯展示3个窗口，安装位于最右边）
graphify installgraphify install --project
在 claude 命令行输入 /graphify 就可以正常触发，它既可以借助大模型来构建关系图，也可以直接基于语法树来构建。当务之急是找一个代码库来验证一下效果。当然 graphify 在自我介绍中这么说：Turn any folder of code, SQL schemas, R scripts, shell scripts, docs, papers, images, or videos into a queryable knowledge graph.
人家的定位可不仅仅是代码，只用来解决代码就太局限了。现在用代码来验证下效果当然可以。找一个 Go 语言的开源库算是比较靠谱的，阅读到这里的读者大多都和编程有点关系。
将 Go 的源码下载到本地，我们将分析目标局限在一个具体的包上。选择一个比较常用的 sync.map 的代码包分析，让大模型帮我们解释下，sync map 是如何来解决读写冲突问题的
git clone git@github.com:golang/go.git
对于这类底层工具包，目录下的每个文件都代表了一种独立功能，文件和文件之间的关系非常简单，所以，我们通过 graphify 是想更加聚焦单个文件内部，我们要对这个目录构建知识图谱，但我们只想分析其中的 map.go 文件
在目录下启动 claude，然后在命令行触发 graphify，系统开始执行，模型在不断地推理、执行、反思、再执行、经过了多次的问题修复，最终输出了：Graph: 658 nodes, 1369 edges, 38 communities 的效果图
No existing graph found. I will build the knowledge graph from the current directory
图谱底层生成采用的是社区检测算法，很明显，sync.map 的社区比较独立，和它相关的节点就是几个对应的函数，这个包确实不太适合来做分析。这个图中其实还有一个关键信息：置信度。
图的每条边上都有一个自信度的标记，Graphify 在提取实体和关系时使用三种置信度标记，分别是EXTRACTED (高置信度)、INFERRED (中等置信度) 、AMBIGUOUS (低置信度) ，这样的等级划分其实是可以参考的。
运行之后当前目录下生成了 graphify-out 文件夹，这几个文件。你可以打开 graph.html 查看可视化图谱（如上图），或根据 GRAPH_REPORT.md 中的建议问题探索代码库结构。
使用基础的 query 命令查询 map，对比命令行直接执行和在大模型中执行的效果。根据左侧命令的输出，程序使用广度优先搜索 (Breadth-First Search) 进行遍历。右侧是大模型的结果，直接输出了大模型处理后的结果。
然后我对比一个贴近工作语义的问题，直接在大模型中输入：sync.map是如何解决并发读写问题的 vs /graphify sync.map 是如何解决并发读写问题的。后者的数据结果主要基于 /graphify 召回的节点进行分析。
我们发现，graphify 在这个场景解决的是召回率的问题，结合生成的图谱，可以快速召回相关的数据。相比于 RAG 在构建知识库是文本固定切块，块与块之间保留一部分内部重合的模式，graphify 数据的召回内容相关性更好。
粤ICP备14082021号
免费POC，
零成本试错
