想在自己机器上跑 GraphRAG，又不想把文档丢给云端 API，通常会选 Ollama 做本地推理。但真动手时容易卡在这几处：索引构建跑到一半显存爆了、图谱抽取结果一堆重复实体、换一批文档不知道要不要全量重建。这篇按工程落地的顺序把搭建流程拆开，给判断标准和排查顺序，不给死数字。
想在自己机器上跑 GraphRAG，又不想把文档丢给云端 API，通常会选 Ollama 做本地推理。这样做的好处是数据不出本机，代价是整条链路都要自己盯：模型选多大、并发开多少、抽取结果怎么去重、索引什么时候需要重建，每一步都能把人卡住。这篇按工程落地的顺序把流程拆开，给判断标准和排查顺序，不给死数字。
先说清楚适用边界。文档量在几十到几百篇、团队有台带独显的机器、能接受索引构建跑上几十分钟甚至更久，这套本地方案才划算。如果文档上万篇、或者要求分钟级更新，本地单机通常扛不住，得考虑多机或者换回托管方案。具体某个模型在本机的实际速度，到 /tools/speed-test 测一遍比看任何参数表都准。
先定机器与模型，再谈搭建
很多人一上来就装库写代码，跑起来才发现机器顶不住。图谱抽取的负载和日常对话完全不是一个量级：它要把每块文档都送进模型跑好几轮，理解成实体、抽关系、生成描述，调用次数是文档块数的若干倍，显存和内存的峰值远高于单轮问答。先估资源、再选模型，顺序不能反。
- 先量文档规模和单块处理成本统计文档总块数，用 /tools/speed-test 测出本机单次调用的耗时，两者相乘就是粗略的总时长。心里有这个量级，后面调并发和模型规格才有参照。
- 把抽取和摘要分成两个模型实体抽取吃的是稳定性和格式遵循，不需要多强的文采；社区摘要环节才更依赖生成能力。用同一个大模型跑完全程不是错，但会白白拖慢抽取阶段。
- 调好并发和上下文窗口再跑批默认并发往往偏高或偏低，先用少量文档压一遍，观察请求是否排队、是否超时。参考 /ollama-concurrency-capacity 里的思路先拉一条基线出来。
- 留一个降级方案如果目标模型跑不动，先降并发再考虑换小规格模型，两者对结果稳定性的影响不一样。
- 图谱抽取负载
- 对每块文档做多轮模型调用，峰值资源消耗远高于普通问答，别按聊天的经验估机器。
- 抽取模型
- 负责把文本变成实体和关系，重点是输出稳定、格式可控，不追求生成质量。
- 摘要模型
- 负责给社区生成自然语言概述，这一环才值得上更强的模型。
图谱抽取：把实体和关系从文档里榨出来
图谱质量基本在这一步决定，后面对检索参数怎么调都补不回来。最常见的两个毛病：一是分块策略没定好导致实体被切碎，二是抽取出来的实体没做归一去重，同一个东西因为写法不同在图里变成好几个节点，最后图看着挺大，其实全是孤岛。
- 分块先试两三档再定：块太大实体信息被稀释，块太小一段关系被切在两边，先用少量样本文档横向比一遍输出效果
- 抽取结果必须做归一去重：同一实体在不同段落的写法、简称、别名要先合并再入图，否则图会碎成互不相连的片
- 关系要带方向与描述：只存「A 关联 B」回答不了方向性问题，要存成「A 是 B 的什么」这类可判断的表述
- 跑批失败要能断点续跑：每块的处理结果先落盘，中断后只重跑失败的块，别每次都从头再来
| 现象 | 大概率原因 | 先查什么 |
|---|---|---|
| 实体数量明显偏少 | 分块太大，一段里塞了太多主题 | 把块调小，看同样几段文档抽出的实体数是否变多 |
| 同一实体重复出现 | 没有做别名归一或大小写统一 | 抽取后加一道合并规则，看重复节点是否消失 |
| 关系全是无方向的关联 | 提示词只要求抽关系，没要求方向和描述 | 改提示词模板，要求输出谓语或关系类型 |
| 跑到一半中断后进度全丢 | 中间结果没落盘，失败即整批重来 | 改成逐块写盘，中断后按已完成块跳过 |
索引构建与后续维护
抽取完只是拿到了原材料，真正耗时间的是社区检测和摘要生成。这一步会先把图切成若干社区，再让模型给每个社区写一段总览，社区数量多的时候调用量很大，也是整条链路最容易跑崩的环节。稳妥的做法是先在小样本上走通全链路，确认输出形态符合预期，再放开跑全量。
维护阶段要分清两种更新。追加全新文档，通常只跑新增部分就够了；但如果改动的是核心概念相关的旧文档，图的社区结构会跟着变，这时候只跑增量会让新内容和旧摘要对不上，需要把摘要层重跑一遍。判断标准很简单：这次改动会不会影响节点之间的连接关系。
- 每次构建把参数记下来：分块大小、用的模型、提示词版本，效果变差时才能分清是数据变了还是配置变了
- 构建产物留版本目录：想回滚到上一版索引时直接切目录，不用重建
- 先小样本跑通全链路：确认摘要输出形态符合预期再上全量，省得白跑几个小时
- 区分增量与全量的触发条件：追加文档走增量，动到核心概念关系时重跑摘要层
查询验证与常见卡点排查
回答质量差的时候，很多人第一反应是调检索参数，其实大部分问题出在前面的图谱本身。排查要有顺序，从最外层往里收，这样能最快定位到底哪一环没跑对。
- 先确认 Ollama 服务本身正常单独发一次调用看有没有正常返回，服务挂了或者端口不通，后面所有环节都会连锁失败。
- 再看抽取结果是否非空打开落盘的块级结果，确认实体和关系真的被抽出来了，而不是模型输出格式不对被解析成空。
- 然后检查社区摘要有没有生成社区检测跑完但摘要为空，通常说明上游图太稀疏，先回头补抽取质量。
- 最后才怀疑检索侧前面三步都正常，再去调检索参数和提示词，否则是在错误的地方花时间。
本地小模型在多跳推理上本来就容易断链，遇到需要串起好几个实体才能回答的问题，表现比不上更大的模型，这属于预期内的取舍，不是配置错了。批量任务跑不动时，优先降并发而不是换更小的模型，退避和重试的思路可以参考 /429-concurrency-backoff。哪些问题适合留在本地、哪些转给更强的模型，这个边界心里要有数。
下一步搭之前先去测一遍本机速度，再对照模型资料库选规格，能省掉大半返工。→常见问题
用 Ollama 跑 GraphRAG，普通笔记本能行吗？
小规模文档、小参数量模型可以跑通流程，但图谱抽取是反复调用，速度和显存压力都比单轮对话大。先拿几十篇文档试一遍全链路，看构建耗时和显存峰值能不能接受，再决定要不要上更大机器或租卡。
GraphRAG 和普通向量 RAG 到底差在哪，值得多花这些构建时间吗？
普通 RAG 是按相似度捞片段，回答多跳问题或需要整体概括时容易漏。GraphRAG 额外建了实体关系和社区摘要，适合「这几份文档整体在讲什么」「A 和 B 有什么关系」这类问题。如果你的场景只是查单个条款，构建成本可能不划算。
图谱抽取出来的实体重复、关系混乱怎么办？
这是最常见的问题，通常是分块过碎加上没有归一去重。先把分块调大一档重试，再在入图前加一层实体名归一和同义合并。提示词里明确要求实体用规范全称，也能明显减少碎片。
