ollama+graphrag

本地跑 Ollama 不难，但一到 GraphRAG 就容易卡在几处：索引阶段要多次调模型、并发一高就超时，向量与抽取用哪几个模型分不清，建完索引进界面又不知道填哪个地址。这篇按落地顺序给出可执行的步骤和排查清单，不重复讲协议兼容和 RAG 原理，只解决装完之后跑不跑得动、界面怎么连上的问题。

本地把 Ollama 跑起来只是第一步，真正卡人的地方在 GraphRAG：索引阶段要反复调模型，对话模型和嵌入模型经常被混成一个，并发稍微一高就整条链路超时。好不容易索引建完，进界面又发现地址不知道填哪、模型名对不上、读的根本不是同一份索引。

这篇不讲协议兼容和 RAG 原理，只按落地顺序解决「装完跑不跑得动」和「界面怎么连上」。下面的步骤都能直接照做，判断标准也写清楚了，什么情况下这套本地方案不适用，最后一节会说。

先把模型和环境准备到位

准备阶段最容易犯的错是把三类角色压成一个模型用。抽取和摘要需要一个指令跟随稳的对话模型，向量化必须另配一个专门的嵌入模型，两者职责不同，混用会让检索质量崩掉。抽取类任务的上下文开大一些，但具体开多大要看你本机显存，去 /models/deploy 做一次测算再定，别看别人的配置照抄。

对话模型

负责实体抽取、关系抽取和社区摘要，要求指令跟随稳定、能稳定输出结构化结果

嵌入模型

专门做向量化，负责把文本转成可检索的向量，别用对话模型兼职

中间产物目录

索引每一步的落盘结果，重跑时能只补失败那一步，不用从头再来

• 确认 Ollama 服务允许外部进程访问，界面和索引脚本一般跑在别的容器或进程里；
• 把监听地址和端口定下来，用 curl 打一次接口确认通，通了再往下走；
• 先把数据目录、配置文件、输出目录三者分开，方便删了重来不误删原始数据；
• 先在几份小文档上跑通全流程，再换全量数据，别一上来就压全库。

建索引：分阶段跑，别一把梭

GraphRAG 的索引是个多阶段链路：先抽实体、再抽关系、然后做社区摘要。整个过程里模型要被调用很多次，一把梭跑完的结果是哪个环节出错你完全不知道。正确做法是拆开跑，中间产物全部落盘，哪步报错就单独重跑那步。

1. 拆阶段执行把实体抽取、关系抽取、社区摘要分开跑，每步结束确认输出文件已经生成，再进下一步。
2. 压低并发本地模型的并发能力有限，索引期把并发数调到个位数，同时配上请求超时和失败重试。
3. 量单请求延迟用 /tools/speed-test 测一次单请求耗时，再根据它能接受的等待时间倒推并发上限。
4. 留日志记录每次请求的耗时、用的哪个模型、失败原因，调参全靠它；日志里别写进隐私原文。

判断标准很简单：如果某一步长时间不动，先看是不是并发太高或超时太短，而不是怀疑模型能力。日志里如果反复出现同一条超时，就把并发再降一档重试那一步。

选界面并把本地服务接进去

搜 graphrag-ollama-ui 能找到的界面大致分两类，选之前先想清楚你要的是「看结构」还是「问问题」。聊天式客户端问答体验好，但不展示实体关系图谱；图谱可视化工具能看关系结构，但问答交互一般。目标不同，选型就不同。

配置界面时重点看三处：模型服务地址怎么写、模型名怎么填、嵌入模型是否单独配置。地址填错是最常见的连不上原因，逐项对照客户端的配置说明核对，别默认它和索引脚本用同一份配置。接好后先用一个答案明确写在文档里的小问题验证链路，通过了再问开放性问题。

跑不动时的排查顺序

报错的时候不要东查一下西查一下，按固定顺序走一遍，能省很多时间。下面这个顺序从底层往上层，任何一步断了就往回修，不要跳步。

• 服务能不能连通：回到 curl 那一步，确认接口有响应；
• 模型名存不存在：核对界面和脚本里填的名字，和本地拉下来的标签是否一致；
• 单次请求能不能通：用最简单的一次调用确认模型真的能出结果；
• 索引中间产物有没有生成：去输出目录看实体、关系、社区摘要这些文件在不在；
• 界面读的是不是同一份索引目录：路径填错会表现为能连上但回答空泛。

几个典型现象对照：卡在建索引进度不动，多半是并发太高或超时太短；界面能连上但回答空泛，多半是嵌入模型没配对，或者索引压根没建完；报模型不存在，是模型名和本地拉下来的标签不一致。

另外提醒一句，选模型、看延迟这些涉及具体数字的部分，别照抄别人的配置。本机显存、磁盘、你要处理的文档量都不一样，去 /tools/speed-test 和 /models/deploy 看当时的实测结果再决定，比任何教程里的固定数字都靠谱。