ollama+anythingllm 本地知识库

你想在内网或断网环境弄一个能问自己文档的助手，看到 Ollama 加 AnythingLLM 这套组合，装完之后却卡在几个地方：模型在哪配、文档传进去半天不出结果、答案老是答非所问。这篇按搭建顺序把动作拆开，每一步给你要点的确认项和出错时的排查顺序，不承诺装完就好用。

你想在内网或者干脆断网的环境里，弄一个能问自己文档的助手，搜到了 Ollama 加 AnythingLLM 这套组合。装完之后大概率会卡在几个具体的地方：模型到底在哪配、文档传进去半天不出东西、答案老是答非所问。这篇不承诺你装完就好用，而是按搭建顺序把动作拆开，每一步告诉你该确认什么、出错时先看哪里。

整体是三大段：先把模型和服务备好并试通，再把 AnythingLLM 接到本地模型上，然后喂文档、按顺序排查答案不准的问题。三段里任何一段没确认就往下走，后面出问题会叠在一起，很难判断是环境的锅还是参数的锅。

动手前先把三件事定下来

装之前先别急着敲命令，有三件事定不下来，后面装到一半就得推倒重来。这三件事分别是离线的档位、用哪个嵌入模型、Ollama 服务是不是真的通了。把它们写在一张纸上再动手，比装完再回去找问题省事得多。

• 确认「离线」到底离到哪一档：是全程断网、只在首次拉模型时联网、还是允许做更新检查。档位不同，安装顺序和镜像源配置完全不一样，先定档再装
• 按任务挑一个对话模型和一个嵌入模型。嵌入模型负责把文档切片变成向量，它选错，后面提示词怎么调都救不回来
• 先把 Ollama 服务跑通并确认它监听在哪个地址，用命令行问一句试通，再装 AnythingLLM。服务没通就装前端，两边的报错会混在一起

把 AnythingLLM 接到本地模型上

这一步的坑集中在地址和模型指定上。AnythingLLM 里选本地 Ollama 那一类入口，然后填服务地址和模型标识。地址填 localhost 还是容器内网名，取决于是不是跑在 Docker 里，这是最常见的连不上原因之一。对话模型和嵌入模型必须分别指定，别图省事两个都填同一个对话模型。

1. 选本地模型入口在模型设置里找到本地 Ollama 那类选项，不要用云端那一栏，填错栏位后面全是白折腾。
2. 填地址并测通地址写法要和你的部署方式对上。填完点一次测试或保存，看有没有返回，没返回先回头查服务监听地址。
3. 分开指定两类模型对话模型管生成，嵌入模型管检索，两个都指到同一个对话模型上，检索环节会跑出无意义的结果。
4. 保存后刷新改完配置先点保存再刷新页面。很多「配置不生效」其实只是前端没重新读取，刷新一下就好了。

如果验证还是连不上，先按服务地址的写法自查一遍：端口对不对、是不是被防火墙挡了、容器里的 localhost 指的是容器自己而不是宿主机。地址写法可以到 /ollama-api-endpoint-guide 对照当期说明核对。

喂文档：切分粒度比模型更影响效果

很多人以为答不准是模型不够强，实际上在这套组合里，切片大小和重叠长度这两个参数对结果的影响，往往比换模型更明显。切片太大，检索命中后塞给模型的上下文过杂；切片太小，一句话被从中间切开，语义就断了。上线前值得花时间在这两个数上试几轮。

文件本身也要先做一次预处理。扫描件要先过 OCR，否则进去的只是一张图；重复文档先清掉，不然同一段资料被召回多次，反而挤占上下文。表格和代码块单独归类，别和普通段落混在一起切。

• 工作区按主题分开，一个工作区对应一类问题，命中率明显好过把所有文档堆进一个库
• 先清脏数据再入库，脏数据进去只会让答案更飘，后面很难倒查
• 表格、代码块、扫描件这三类单独处理，别指望默认切分能照顾好它们
• 入库后先问几个你已知答案的问题，用它们当基线，再去看真实提问的效果

答不准时的排查顺序

答不准的时候，最容易犯的错是先换模型。正确做法是按顺序来，先看检索出了什么片段，而不是先动模型参数。多数「答错」其实是没有检索到正确的段落，跟模型能力没什么关系。顺序错了，你会一直在错的层面上调整。

1. 看检索片段打开这次问答命中的片段，看正确那段话到底有没有被捞出来。没捞到就往切片和召回方向查。
2. 调切片与召回条数把命中片段调准，再考虑召回条数。这一步没调好之前，换模型基本是白换。
3. 才动提示词和温度指令里写清楚「只根据给定资料回答，资料里没有就说没有」，这一句能挡掉相当一部分编造。
4. 最后才考虑换模型前面几步都做到位还不够，再考虑换更大的对话模型，或者换一个嵌入模型重做索引。

还有一个常被忽略的因素是延迟。如果本地跑起来慢到没法用，先按 /tools/speed-test 量一遍基线，搞清楚瓶颈在模型推理还是检索，再决定是换更小的模型还是调参数，别凭感觉换。

什么情况下这套方案不合适

这套组合适合的是文档量中等、提问频率不高、以单人或小团队为主的场景。比如一家 5 人小团队把内部规范和历史文档丢进去，偶尔查一下，这种用法很合适。但有几类场景，硬上会明显吃力，提前想清楚能省不少返工。

• 文档量特别大，或者需要多人同时高频提问时，单机这套会明显吃紧，得按显存和并发重新算，参考 /models/deploy 的测算口径
• 需要跨文档复杂推理、多跳检索的场景，单靠一轮向量召回往往不够，要考虑加检索重排或换更重的方案
• 合规要求高的场景要先确认模型许可证和数据留存方式，离线不等于自动合规，这条最容易被忽略

换句话说，离线是手段不是目的。如果你的真实需求是「多人协作、随时可用、还要有审计」，单机这套组合大概率不是终点，而是过渡方案。先想清楚边界，再决定投多少时间在上面。

离线解决的是数据不出门的问题，不解决答案一定对的问题；这两件事要分开评估。