企业官网建设流程全解析

最近一个朋友跟我吐槽：公司想把内部项目文档、产品说明、甚至聊天记录做成一个能自动问答的智能库，但数据敏感，绝对不能传到云端API去。我直接甩给他一套方案——GraphRAG + Ollama 本地化部署。整套东西跑在公司一台普通工作站上，8G显存的显卡就能转起来，数据不出内网，问答效果比普通向量检索强一大截。这篇文章我就把从零搭建的完整过程、踩过的坑、还有背后的原理掰开揉碎讲清楚，适合有一定Python基础、想在企业内网或本地环境落地知识库问答的同学参考。

先说清楚这个组合到底干了什么。Ollama负责把大模型跑在本地，并提供一套OpenAI兼容的API；GraphRAG负责把文档里的实体和关系抽出来建知识图谱，再用图谱结构增强问答推理。两者一组合，等于你本地就有一台既能做全局理解、又能做多跳推理的问答引擎，而且整个链路不依赖公网。

1. 先想清楚：为什么是GraphRAG，而不是普通向量检索

1.1 普通RAG答不了"跨文档推理"类问题

传统RAG（Retrieval-Augmented Generation，检索增强生成）流程大家应该都熟：文档切块、向量化、存向量库；用户提问时，把问题也向量化，然后做相似度检索，把最相关的几块文本拼进提示词，交给大模型回答。

这套方案在"答案就藏在某一段文字里"的场景下很好用，比如"产品A的保修期是多久"。但遇到需要跨多个段落、甚至跨多份文档推理的问题就抓瞎了。举个例子：你问"研发中心负责人王总，和供应商腾飞科技的法人是同一个人吗？"答案可能分散在员工档案、供应商登记表、董事会决议三份材料里。普通RAG检索时，每一块文本和问题的向量相似度都不高，排在前面的可能是完全不相关的段落，大模型自然答不出来。

这个问题的根源在于：向量相似度只能衡量"字面相关"，没法表达"逻辑关系"。而现实中的知识库问答，偏偏大量问题都是关系型的。

1.2 GraphRAG用图谱把碎片信息串起来

GraphRAG最早是微软在2024年开源的研究项目，核心思路分两步走。

第一步，索引阶段：把原始文档交给大模型，让它抽取出实体（人、组织、产品、地点等）和关系（"甲是乙的CEO""丙被丁收购"），然后把这些实体和关系组织成一张图。接下来对这张图做社区检测（常见算法是Leiden），把联系紧密的实体聚成一个个社区，再让大模型为每个社区生成一份摘要报告。

第二步，查询阶段：当用户提问时，系统不再去匹配"原文片段"，而是去匹配"社区报告"和"实体关系"。比如问"公司去年最大的供应商是谁"，模型会先定位到相关社区，读取社区里聚合好的信息，再综合推理。这就解决了普通RAG答不了全局性问题、跨文档问题的痛点。

我实际体验下来，GraphRAG对两类问题提升特别明显：

• 全局性问题：如"整个项目里涉及哪些合规风险""文档中提到的主要合作伙伴有哪些"。这类问题在传统RAG里基本没法答，因为答案没有聚焦在某一段文字。
• 多跳推理问题：如"A产品的负责人所在部门，和B项目有合作吗"。需要先找到A负责人，再跳转到部门，再关联到B项目，图谱上的路径检索天然适合这种需求。

1.3 为什么偏偏选Ollama做推理引擎

GraphRAG官方默认接入的是OpenAI等云端模型。但对于企业内部知识库来说，把业务文档发给第三方API，本身就是很多公司接受不了的事。Ollama的价值在于：

• 把模型权重、推理服务、API封装成一个本地命令就能搞定的工具，相当于你机器上装了个"本地版OpenAI"。
• 支持Llama、Qwen、DeepSeek、Mistral等主流开源模型，尤其是Qwen2.5和DeepSeek系列的中文能力相当能打。
• 对硬件要求不算离谱：7B~8B的量化模型，6G~8G显存就能流畅运行；如果纯CPU推理，内存32G以上也能凑合跑，只是速度慢一些。
• 提供OpenAI兼容接口，GraphRAG、Dify、FastGPT这些上层工具可以直接对接，不用改多少代码。

所以我最后的选型就是：Ollama跑Qwen2.5系列做抽取和推理，加一个嵌入模型做向量化，GraphRAG负责图谱构建和查询编排。整套链路完全本地化，断网也能用。

2. 环境准备：先把Ollama这块地基打牢

2.1 安装Ollama时就要规划好路径和模型

Ollama的安装本身不复杂，但有几个细节我建议提前处理，否则后面有得折腾。

Windows上直接去官网下载exe安装包。但注意，默认安装会进C盘，模型文件也会放在C盘用户目录下的.ollama/models，几十个G的模型塞进C盘，系统盘分分钟爆掉。我一般装完第一件事就是改环境变量：

# Windows用户：右键"此电脑" -> 属性 -> 高级系统设置 -> 环境变量 # 新建两个用户环境变量： OLLAMA_MODELS=D:\ollama\models OLLAMA_HOST=0.0.0.0:11434

OLLAMA_MODELS指定模型存放路径；OLLAMA_HOST=0.0.0.0:11434则是把服务暴露到局域网，这样同一网段的同事也能访问你机器上的模型。如果是纯个人本机用，OLLAMA_HOST保持默认的127.0.0.1:11434就行。

Linux/macOS用户直接用官方脚本：

curl -fsSL https://ollama.com/install.sh | sh

装完之后验证一下：

ollama --version ollama serve

看到服务监听在11434端口就算成功。注意在Windows上，安装程序会自动注册成后台服务，一般不需要手动执行ollama serve。

2.2 模型拉取与离线导入：下载太慢的真实解法

Ollama的使用逻辑很简单，先拉模型，再对话：

# 拉取模型 ollama pull qwen2.5:7b ollama pull deepseek-r1:8b # 列出本地模型 ollama list # 测试对话 ollama run qwen2.5:7b "你好，简要介绍一下你自己"

但很多同学卡在了第一步——拉模型极慢，甚至直接报错max retries exceeded。这个报错我遇到过太多次了，根因是Ollama拉模型时要访问海外存储节点，网络链路不稳定时就会反复重试然后失败。

我的经验是别死磕ollama pull，改用"曲线救国"的方案：去国内能正常访问的模型社区（比如魔搭ModelScope）下载GGUF格式模型文件，然后通过Modelfile导入Ollama。整个过程全内网可完成，速度能跑满带宽。

具体步骤：

# 1. 在ModelScope上搜索对应模型的GGUF文件并下载，比如 qwen2.5-7b-instruct-gguf # 2. 编写Modelfile FROM /data/models/qwen2.5-7b-instruct-q4_k_m.gguf # 3. 用ollama create导入 ollama create qwen2.5:7b -f Modelfile # 4. 验证 ollama list

提示：GGUF文件有不同的量化等级，常见q4_k_m、q5_k_m、q8_0。q4_k_m体积最小，质量损失不大，7B模型大约4.7G，对8G显存很友好。追求效果就上q8_0，但显存占用会明显增加。

嵌入模型也很关键。GraphRAG做向量化时需要嵌入模型，我推荐用nomic-embed-text，直接在Ollama里拉：

ollama pull nomic-embed-text

如果你对中文嵌入效果要求更高，也可以试试bge-m3，这个在Ollama里也能找到。

2.3 验证Ollama API可用

GraphRAG对接Ollama，本质是走一个OpenAI兼容的HTTP接口。装完先验证一下接口通不通：

curl http://localhost:11434/v1/models

能看到模型列表，就说明环境基本OK了。如果想测对话接口：

curl http://localhost:11434/api/chat -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "你好"}] }'

这里我强烈建议把Ollama服务版本固定下来，别随便升级。我遇到过两次Ollama升级后，GraphRAG调用时偶发连接被重置的问题，回滚到稳定版本就好了。生产环境求稳不追新，这是第一条经验。

3. GraphRAG工作原理解读：明白流程才能调好参

3.1 索引阶段：把文档"读"成一张知识图谱

GraphRAG的完整流程可以拆成两个阶段。索引阶段是重头戏，也是最耗时间、最耗Token（或者说最耗本地模型推理次数）的环节。

第一步是文本切块。原始文档会被切成固定大小的chunk，默认大概1200个词左右，相邻chunk之间有重叠，避免关系被切断裂开。

第二步是实体和关系抽取。这一步会把每个chunk交给大模型，让它识别里面的实体（Entity）和它们之间的关系（Relationship）。比如这段文档写的是"张三于2023年加入腾飞科技，担任研发总监"，模型会抽出：

• 实体：张三（人）、腾飞科技（组织）、研发总监（职位）
• 关系：张三 -> 任职于 -> 腾飞科技；张三 -> 担任 -> 研发总监

第三步是构建图结构。所有chunk抽出来的实体和关系会被合并成一张大图，同一个实体会被合并成一个节点。然后做社区检测，把联系紧密的实体划到同一个社区里。这一步用的通常是Leiden算法，它的好处是不用提前指定社区数量，能自动发现层次化的社区结构。

第四步是生成社区报告。GraphRAG会让大模型针对每个社区，生成一份概括性描述：这个社区涉及哪些实体、它们之间的关系是什么、有哪些关键信息。这就是后续全局检索时的"索引卡片"。

最后还会为实体、社区报告等对象生成向量嵌入，用于局部检索时的语义匹配。

3.2 查询阶段：全局搜索和局部搜索两条路径

GraphRAG提供两种查询模式，我实际用下来互补性很强。

全局搜索（Global Search）：适合回答"整个知识库里……"这类跨文档、全局性的问题。流程是：找出与问题语义最相关的若干社区报告，把所有报告拼接起来，分批次让大模型提炼要点（这一步称为map），再把要点合并起来生成最终答案（称为reduce）。因为看到了全图的社区摘要，所以能回答"公司面临哪些主要风险""文档里涉及了哪些关键人物"这类问题。

局部搜索（Local Search）：适合回答"某一实体相关的具体问题"。流程是：根据问题找到相关实体，然后沿图谱扩展，把相邻实体、相关关系、原始文本、社区报告全部取出来，一起交给大模型做推理。因为信息是围绕实体聚合的，所以回答"张三负责哪些项目"这种问题时，信息完整度远高于普通的向量检索。

理解了这两条路径，后面的参数调优才有方向。比如全局搜索慢，可以把社区报告层级调低一点，减少输入量；局部搜索答不准，可以增加实体扩展的跳数。

3.3 为什么图谱结构比向量更擅长多跳推理

我再用一个更直观的比喻。向量库像一本字典，你要查一个词，按偏旁部首翻到那一页，只能看到这个词的释义。图谱则像一张人际关系网，每个实体是一个节点，节点之间用关系线相连。当问题需要"跳"好几次才能找到答案时，字典式检索无能为力，但图谱可以沿着关系线一步步走，每次跳转都有明确依据。

GraphRAG的聪明之处在于，它不是让大模型在推理时实时去遍历整张图——那太慢了——而是在索引阶段就把全局结构消化成了社区报告，查询时只需要在"浓缩过"的信息上做推理。这就是它比普通RAG更适合做知识库问答的根本原因。

4. 实战记录：从初始化到跑通全流程

4.1 安装GraphRAG并初始化项目

环境准备好后，开始装GraphRAG。用独立的Python虚拟环境是基本操作：

python -m venv .venv source .venv/bin/activate # Windows下是 .venv\Scripts\activate pip install graphrag

然后初始化项目：

python -m graphrag init --root ./demo

执行完会在demo目录下生成两类文件：

• settings.yaml：核心配置文件，包括LLM服务地址、模型名、嵌入模型、各类参数。
• .env：存放环境变量，如API Key。

GraphRAG比较麻烦的一点是，不同版本的配置方式有差异。老版本靠环境变量，新版本统一收敛到settings.yaml。我建议以你安装的版本官方文档为准，这里列一份我用过的、能跑通的配置供参考：

llm: api_key: ollama type: openai_chat model: qwen2.5:7b api_base: http://localhost:11434/v1 max_tokens: 4000 request_timeout: 300.0 model_supports_json: true embedding: api_key: ollama type: openai_embedding model: nomic-embed-text api_base: http://localhost:11434/v1 chunks: size: 1200 overlap: 200 parallelization: enabled: true num_threads: 8

提示：api_key这里随便填一个占位符就行，Ollama不校验Key。但GraphRAG代码里如果没读到Key会直接报错，所以不能留空。

重要：model_supports_json要看情况开。GraphRAG抽取实体时要求模型输出严格JSON格式，Qwen2.5系列本身支持JSON模式可以开，但有些模型对JSON输出支持不好，开了反而更容易出错，可以先关掉跑通再说。

4.2 准备语料，执行索引构建

在demo目录下创建input文件夹，把文档放进去。纯文本txt就行，PDF需要额外装解析库，我建议起步阶段统一转成txt或md，省去一堆麻烦。

语料准备好后，执行索引构建：

python -m graphrag index --root ./demo

这一步非常考验耐心。以一份50页左右的文档为例，我用7B模型在单张8G显存的卡上跑，大概需要30到50分钟。索引过程会大量调用本地模型做实体抽取、社区报告生成，每一步都要等推理完成，所以慢是正常的。

跑完以后，output目录下会生成一批parquet文件，包括：

• entities：实体表
• relationships：关系表
• communities：社区划分结果
• community_reports：社区摘要报告

看到这些文件，说明知识图谱已经建好了。我习惯先看一眼entities.parquet的规模，确认抽取出的实体数量在合理范围——如果一份50页的文档只抽出几十个实体，说明抽取prompt或模型有问题，要排查。

4.3 用命令行跑通问答

索引构建完成，先直接用命令行验证效果：

# 全局搜索 python -m graphrag query --root ./demo --method global --query "这套文档中提到了哪些核心技术方向？" # 局部搜索 python -m graphrag query --root ./demo --method local --query "研发总监张三参与了哪些项目？"

全局搜索通常需要20到40秒，局部搜索会快一些。如果两条命令都能得到结构合理的回答，恭喜，整套链路通了。

命令行跑通之后，我习惯再封装一个Python脚本，方便集成到内网系统里：

from graphrag.query import parse_query_mode def ask_question(question: str, method: str = "local") -> str: # 这里可以调用graphrag提供的查询接口 # 也可以直接解析CLI输出，或者封装Indexer和Search器 ...

说实话，GraphRAG官方查询接口在不同版本里变化比较大，直接写Python调用容易踩版本坑。我更推荐的做法是：先用命令行走通流程，然后如果你要接Web应用，把命令行封装成后端服务接口，或者去对接Dify/FastGPT这类现成的编排平台——它们已经做了图形化界面，Ollama的模型可以直接接入，Graphrag的能力也能通过插件方式挂进去。这样开发成本最低，交付速度最快。

4.4 用脚本把问答能力API化

如果一定要自己写服务，我给一个最小可用的封装思路：用subprocess调CLI，或者用FastAPI包一层HTTP接口，内部调用GraphRAG的查询入口。这里要注意GraphRAG查询时会做大量并行调用，如果你同时跑多个查询请求，Ollama那边很容易出现并发排队，显存不够时甚至会OOM。

所以我的建议是：Ollama侧可以设置环境变量OLLAMA_NUM_PARALLEL控制并发数，一般设1或2；服务层加上简单的请求队列，避免把本地模型压垮。本地部署不比云端API，并发是把双刃剑，宁可排队慢一点，也不要直接崩掉。

5. 常见问题排查与避坑指南

5.1 Ollama端：我从"报错狂魔"到"稳定运行"的几板斧

报错一：max retries exceeded: get "https://huggingface.co"

这是Ollama拉模型时的经典报错，本质是网络链路问题。解决办法前面写过：别死磕ollama pull，去国内模型社区下载GGUF文件再导入。这条路最稳，速度也快。

报错二：model not found 或 run file does not exist

一般有两个原因：一是模型名没写对，用ollama list查一下准确的名称和标签；二是模型没拉成功但残留了记录，可以删掉重新导入。执行ollama rm 模型名清理后重试。

报错三：Ollama服务只能在本地访问

检查环境变量OLLAMA_HOST是否设置为0.0.0.0:11434。修改环境变量后，Windows需要重启Ollama服务，Linux需要重启ollama进程：

sudo systemctl restart ollama

报错四：显存不足，OOM

这是本地跑大模型的常态。我的处理顺序是：先换更小的量化版本（比如q4_k_m换成q4_k_s）；再检查是否同时加载了太多模型，用ollama ps查看当前加载的模型，不用的用ollama stop 模型名卸载；最后降低GraphRAG的并发线程数，比如从8降到4。

5.2 GraphRAG端：索引慢、内存爆、格式错

索引速度太慢

慢的根源是本地7B模型逐块推理。提升手段有几种：

• 换更小的模型（如qwen2.5:3b）做抽取，速度会快几倍，但抽取质量可能下降。
• 如果显存够，可以试试把并发数调高，让Ollama同时处理多个请求，单次推理吞吐量会提升。
• 先拿小数据量跑通，再逐步扩大语料，避免一上来就让模型啃几百页文档，调参都调不动。

LLM返回格式不正确导致索引中断

GraphRAG对实体抽取的JSON格式要求很严格，模型一旦输出不规范的JSON，整个流程就会报错。除了前面提到的model_supports_json参数，我还会在配置里打开重试，并适当增加request_timeout。如果频繁出错，我建议换一个对JSON输出更友好的模型——Qwen2.5和Llama 3.1在这方面的表现都比较稳。

内存和磁盘占用过高

索引过程中会生成大量中间数据，parquet、缓存、向量库都占空间。起步阶段建议控制语料量，不要在第一次就把全部历史文档倒进去。我踩过的教训是：一次导入800MB文档，结果索引跑到一半磁盘满了，最后还得清数据重来。小步快跑，先把流程打通，再逐步扩量。

5.3 回答质量调优的几个有效方向

如果回答质量不理想，我的排查顺序是：

• 先看实体抽取质量。打开entities.parquet，看看实体是不是明显缺漏。如果实体抽取就漏了，后面所有环节都会跟着错。处理方法：优化输入语料的格式，去掉多余噪音（页眉页脚、无关表格）；或者换更大的模型做抽取。
• 再看问题类型和查询模式是否匹配。全局性问题用global，局部实体问题用local，混用容易答非所问。
• 调chunk大小。实体抽取是基于chunk的，chunk太小，跨段关系容易被截断；chunk太大，单个chunk里的噪音信息过多。我常用的范围是800到2000，配合10%~20%的overlap。
• 升级模型。7B模型做抽取和社区报告生成，质量上限就摆在那里。如果预算和硬件允许，换14B甚至更大尺寸的模型，效果提升是立竿见影的。

6. 最后分享几个我踩出来的小经验

这套 GraphRAG + Ollama 的本地化方案，我在搭完之后最大的感受是：真正的难点不是安装部署，而是语料治理和参数调优。一份干净、结构化、噪声少的语料，能让你在后面的每个环节都省心；反过来，语料乱七八糟，后面模型再好也救不回来。

第二个体会是：不要一开始就追求把所有数据都灌进去。先拿几十页高质量文档跑通全流程，再逐步增加数据量。每增加一批数据，都重新审视实体抽取质量和回答效果。知识图谱不像向量库，它的构建成本高、结构性更强，前期多花时间做小样验证，远比后期返工划算。

最后再分享一个小技巧：GraphRAG索引构建过程中，如果你发现某个chunk频繁触发重试，不妨把那块原始文本拿出来看一眼，往往是有特殊格式、特殊符号，或者表格结构被切碎了。把这些文本清洗一下再放回去，整个流程会顺畅很多。

如果你公司内部也想做一套"数据不出内网"的知识库问答系统，这套组合目前是我认为性价比很高的方案。硬件门槛不高，软件全免费，唯一需要投入的就是时间和调优的耐心。