22款本地模型知识图谱能力可复现评测

给知识图谱挑本地模型，聊天榜单可能帮不上忙。模型得先从文档中提取实体、关系和证据，再依据检索结果回答问题。这两份工作需要的能力不同，聊天流畅的模型，也可能把图谱建得一团乱。

作者用 Ollama 中的 22 个本地模型做了一套可复现评测，结论是：提取能力比参数量更值得看，排名旁边的误差区间和异常标记也不能跳过。对准备搭文档问答、知识库的程序员，这套选型方法比记住榜首更有用。

建图和回答问题，为什么要分开测

作者把评测拆成 Extraction 和 Chat，分别检查「图谱能不能建干净」和「回答会不会超出证据」。

Extraction 使用真实的提取提示词和解析器，通过纯函数检查判定成败，不让另一个模型充当裁判。测试覆盖输出格式、证据句引用、禁止使用外部知识、实体命名，以及关系提取。例如，实体应当是具体名字，不能拿角色称谓顶替。

测试分两组：65 个独立探针，以及 39 个嵌入《战争与和平》真实文本块的探针。后者更贴近实际文档，因为模型在短小、整洁的测试里遵守规则，不代表放进长段落后还能守住。

Chat 则让每个模型回答《战争与和平》第一卷的同一批问题，使用相同的参考图谱和检索上下文。答案既要包含问题要求的信息，也不能加入上下文没有的内容；书中无法回答时，还得拒答。

这样固定输入，才能尽量把差异归到回答模型上。但它测的是「从同一份图谱回答」，并没有让每个模型使用自己建出的图谱。

Overall 的权重为提取 0.6、聊天 0.4；提取内部，真实文本块成绩计两份，独立探针计一份。提取时关闭 thinking，聊天时开启，两者都使用 temperature 0 和固定 seed。

这个总分表达了作者的业务偏好：建好图谱，比回答流畅更重要。

榜首值得参考，但异常标记更该先看

作者观察到，Chat 成绩比较集中，Extraction 差距更大。选建图模型时，应优先按提取成绩筛选。

参数量也不能替代实测。Gemma 4 12B 排在一些需要更多 GPU 显存的模型附近，部分 30B 级模型却因为真实文本块提取表现不佳而靠后。作者据此判断，严格格式和句子引用能力更依赖训练，不能只看模型大小。

Gemma 4 31B 的 Overall 领先，两组提取测试均无异常标记。不过，所有 Chat 测试使用的参考图谱，也由它构建。这不直接否定结果，但说明整个问答评测仍依赖一份特定模型生成的图谱。

每个分数都有一个标成 ± 的 90% 区间，来自对该行任务进行 2,000 次重采样。榜单用 ≈ 标出无法与上一行区分的模型。相邻名次经常打平，没必要把前几名当成确定的冠亚季军。

异常标记更能解释低分：

• GPT-OSS 20B 和 DeepSeek-R1 14B 在关闭 thinking 后仍然推理，消耗了输出预算，GPT-OSS 20B 的许多回答因此被截断。
• Llama 3.1 8B 和 GLM 4.7 Flash 在许多探针上触及输出上限；失控重复被检测器终止，也会被标记。
• 「No tools」表示 Ollama manifest 没有声明工具调用能力。它可以参加评测，但无法担任该应用的聊天模型，因为应用的聊天循环始终传入 tools。

这些分数记录的是模型实际产出的结果。可用性问题是真实的，但不能仅凭低分判断模型完全不具备提取能力。

页面还放了少量 Claude 参考行：通过 Claude Code 运行，仅测提取，采用客户端自身设置，且只覆盖部分真实文本块测试。因此不能与固定参数的本地模型逐行等价比较。

怎么把这套评测搬到自己的文档上

下面这组命令完成安装、配置和两类本地评测：

pipx install chaoscypher-cli
chaoscypher setup        # once: pick Ollama as the provider
chaoscypher benchmark run probes --local-only
chaoscypher benchmark run chat-probes --local-only

要看清第二行：benchmark 需要先配置 provider，新安装后应运行 chaoscypher setup，选择 Ollama。

模型要提前下载，例如 ollama pull gemma4:12b。probes 生成提取成绩，chat-probes 生成聊天成绩，--local-only 只运行配置中的本地模型，跳过托管模型。

正式开跑前，可用 --estimate 查看调用次数；--model-timeout 限制卡住的模型，超时后继续运行。chaoscypher benchmark list 列出全部配置和数据集。

结果会以 JSON 和 Markdown 表格保存到数据目录，之后可用 chaoscypher benchmark show <results.json> 重新渲染。测试自己的文档，需要在内置数据集旁新增数据集目录，具体布局原文没有展开。

页面另有一组检索对比，让各模型分别使用普通向量 RAG、关键词加向量的混合检索、图谱加向量检索回答相同问题。其中普通向量 RAG 使用 LlamaIndex 标准教程管线。作者说，只有结论跨所测模型成立才会写成主要结论，但这篇原文没给出具体成绩，不能据此宣称图谱检索已经胜出。

我的判断

我认同它把格式、证据和拒答拆成可检查规则。知识库最麻烦的错误，往往是答案看起来合理，证据却对不上。把这些要求写成检查，比只看几段演示回答更有选型价值。

但它测的是模型与 ChaosCypher 提示词、解析器、输出预算共同组成的系统，不能直接当作模型的通用能力排名。更换提示词或输出上限，异常模型的成绩可能变化。

聊天部分还只覆盖一部小说。中文技术文档、代码符号和团队内部缩写是否适用，原文没有验证。它也没有提供运行耗时、显存或成本的对照数据，因此无法回答「哪个最划算」。

这份榜单适合缩小候选范围，最终选择仍要由自己的文档决定。

作者认为版本和量化会改变小数点后的成绩，但模型分组应当稳定。这是需要复现检验的判断，不能直接视为保证。

能拿来做什么

• 给项目文档或内部知识库选模型时，先准备一小组真实文本，分别检查实体、关系和证据句，再测试问答，避免只凭聊天体验决定。
• 把当前提示词、解析器、模型量化、Ollama 版本和输出限制一起记录下来。遇到低分先查截断、重复和 thinking 行为，让复现结果有解释依据。
• 接入工具调用式聊天流程前，检查目标模型的 Ollama manifest；如果应用始终传入 tools，就应把这项兼容性纳入筛选。
• 决定是否增加图谱检索前，用相同问题比较向量、混合和图谱加向量三条路径，依据自己的结果判断是否值得承担建图与维护工作。