个人打造私有知识库 RAG（检索增强生成）教程：基于 Ollama + AnythingLLM 完全断网运行

想把自己的资料做成能问答的知识库，又不想把文件传到别人服务器上，这条路是通的，但卡点不在「装不装得上」，而在选型、进料和验证：模型挑哪个、文档怎么清、答不准时先改哪一步。这篇按部署顺序给一套断网可跑的流程，每步都有验收动作。

想把自己的资料做成能问答的知识库，最省事的方式通常是丢给在线服务，但很多人过不去「文件传到别人服务器」这道坎。本地这条路是通的：Ollama 负责跑模型，AnythingLLM 负责做界面和文档管理，两样都装在自己机器上，全程不联网也能用。真正卡人的不是「装不装得上」，而是模型挑哪个、文档怎么清、答不准时先改哪一步。

这篇按部署顺序给一套断网可跑的流程，每一步都配一个验收动作，没通过就不要往下走。你先得想清楚一件事：这套东西走的是检索，不是训练，下面第一节就把这个分岔口讲明白。

先分清：RAG 和微调不是一回事，别一上来就想训模型

检索路线的本质是：把资料切片存进向量库，提问时先搜出相关段落，再把这些段落连同问题一起喂给模型。模型本身一个参数都没改，你改的是它每次能看到的上下文。所以资料更新，你只要重新索引，不用动模型。这一点决定了两条路的适用场景完全不同。

RAG

资料切片入库，提问时先检索再生成，模型不变，改的是上下文；资料天天变就走这条

微调

拿数据再训练模型本身，改的是模型的表达习惯和输出格式；代价是要数据、要算力、改完要重训

判断口诀

要能指出出处、资料会变、不想重训，选检索；要改模型说话方式或固定输出格式，才考虑微调

• 你的资料每周都在增删，检索是唯一现实的选择，微调跟不上这个节奏
• 你需要答案能点回原文那一段，检索天然带出处，微调给不出来
• 你只是想让它按某种固定格式输出，且资料基本不变，那才轮到微调登场
• 本地机器跑不动大模型时，RAG 照样成立，只是生成那一步换成小模型，检索质量决定整体上限

动手前先量机器：显存、内存、磁盘三笔账

装之前先花十分钟摸清自己的硬件，不然装完才发现跑起来等半天，白折腾。三笔账要分开算：显存决定你能跑多大的模型和什么量化档位，内存决定切分和索引时会不会把系统卡死，磁盘决定你能装多少资料。只有 CPU 也能跑，但等待时间要按分钟算，能不能接受得你自己判断。

把「能跑」和「好用」分开看：能出字不算跑通，能稳定在你可接受的等待时间里出答案才算。不确定自己的机器能带多大模型，到 /models/deploy 按显存和量化档位对一遍；那里的数字是动态维护的，以你查看当时的为准。

断网安装：模型文件、程序、依赖三样都要提前落地

断网部署的关键是「先在联网机器上把东西备齐，再整体搬过去」。顺序错了会很痛苦，比如先装程序再发现模型拉不下来，或者模型下好了但依赖缺一个包，最后排查半天。下面这套顺序照着走，每步都有验收点。

1. 联网机器上拉模型权重在能上网的机器上把 Ollama 的模型文件完整拉下来，确认文件目录里有实际权重而不是空占位；拉完先在这台机器上跑一次对话，能出字才算拉全。
2. 准备程序和依赖包把 AnythingLLM 的安装包和它依赖的运行环境一起准备好，别等到目标机器上才发现少东西。如果是容器方式部署，镜像也要提前拉好并导出。
3. 搬到目标机器并安装把模型目录和安装包整体拷过去，路径建议显式指定，比如模型放哪个盘、数据目录放哪里，默认路径在搬家时最容易丢东西。
4. 断网验证拔网线或关掉网卡，彻底断开外网，再跑一次对话，确认没有任何请求偷偷外发，也没有因为联网失败而卡住的步骤。

模型权重落地后先单独起一次对话验证，能出字再进下一步。这样做的好处是：出问题时你能确定是模型的事还是程序的事，不用把两个变量的故障混在一起排查。

进料这一步最容易白干：文档清洗和切分

很多人装完程序，兴冲冲把一堆 PDF 拖进去，结果问什么都不知道。问题通常不在模型，而在进料：文档本身是扫描件、切分位置切碎了语义、同一份文件有多个版本。这一步花的时间应该比装程序多。

• 扫描件和图片型 PDF 先做文字识别，识别不出来等于空文档，喂进去只会占索引位置
• 按语义单元切，不要按固定字数硬切：合同按条款、手册按小节、论文按段落
• 切完自己抽十段读一遍，看看有没有把一句话切成两半、有没有丢掉标题和上下文
• 去重和去旧版先做，同一份文件留三个版本，检索出来互相打架，答案会来回变
• 给每份文档标上来源和日期，后面排查答案来源时靠它定位

清洗和分块的细化清单见 /ai-nav/category/ai-note，挑工具和对照维度时可以按它列的条目逐条过一遍。切分策略不是一次定死的，先按一版跑起来，用真实问题测出问题再回来调。

建索引：切分粒度、嵌入模型和重排怎么配

这一步决定了「搜得准不准」。嵌入模型负责把文字转成向量，它决定检索的召回质量；切分粒度决定搜出来的块信息是否完整；重排决定搜到的内容里哪几条能排到最前面喂给模型。三者配合不好，模型再强也答不对。

切得太碎会丢上下文，检索出来的片段没头没尾；切得太大检索命中后噪声多，模型会被无关内容带偏。没有一个放之四海皆准的数值，起步建议用中等块加少量重叠，然后拿十个真实问题去测，看命中段落读起来是否完整。具体档位和模型清单到 /embeddings 对照，以你查看当时的数字为准。

索引重建比想象中便宜，改完切分策略就重建一次，不要试图靠打补丁修错的分块。

验收：用二十个真问题测，而不是问「你好」

「你好」能回不代表知识库能用。真正有效的验收是准备一组覆盖你日常用途的问题，然后记录每条答得对不对。更关键的是：答错了要能分清是哪个环节的问题，否则你只会不停地换模型，换到最后还是不对。

1. 准备问题集覆盖三类问题：能直接答的、资料里没有的、需要跨两份文件才能答的，每类若干条，总数控制在二十条上下。
2. 逐条测试并记录对每条问题记下：有没有搜到相关段落、答案是否正确、依据出自哪份文档。搜到什么比答了什么更重要。
3. 按三类分因没搜到归到检索问题；搜到了但答偏归到提示词或模型问题；资料里压根没有归到语料问题。三类处理方式完全不同。
4. 回原文找依据对每条错误都回到原文确认一遍，找不到依据说明进料阶段就有缺口，换生成模型解决不了这个问题。

多数情况下，答不准的根因在检索或语料，而不是生成模型。先修上游再换模型，顺序反了会浪费大量时间。

长期跑起来：更新、备份和没人问时的检查

搭起来只是开始，能不能长期用下去取决于维护动作是否固定。断网环境有个好处：模型和程序都不会自己更新，版本锁死反而让结果可复现。坏处是资料旧了不会有人提醒你，得自己定规矩。

• 资料更新要有固定动作：新增放哪个目录、旧版怎么标记作废、多久重建一次索引，写成流程贴出来
• 定期备份索引目录和配置，重装一次远比重新建索引省事，备份要真的还原验证过一次
• 判断变差是资料旧了还是检索退了：固定问题集重跑一遍，结果对比比凭感觉靠谱
• 记下当前用的模型和程序版本，方便以后复现，也方便排查「以前能用现在不行」这类问题
• 没人问的时候定期抽查几个问题，别等到真要用的时候才发现索引坏了

更新频率高的场景，维护成本主要在索引重建上，可以考虑固定周期全量重建而不是增量追加；更新频率低、资料稳定的场景，建一次管很久，重点放在备份上。