1. 先想清楚为什么要自己搭一套知识库把 Ollama、WebUI、AnythingLLM 这三个东西拼在一起做知识库这两年问的人越来越多但很多人一上来就照着教程敲命令装完了发现模型跑起来了、界面也能打开可一问问题就开始胡说八道或者干脆答文档里没有找到相关内容。问题不在工具而在于没想清楚这套东西各自管什么、边界在哪。我自己的场景很典型手上有一堆内部文档、产品手册、历史项目复盘格式乱七八糟PDF、Word、Excel、Markdown 全有。想用大模型来检索问答但资料本身不适合往外传也不能保证外部服务不会拿这些内容做别的事。于是思路就落到本地部署这条路上——模型跑在自己的机器上向量库落在自己的硬盘里整个链路不出内网。这套组合的分工是Ollama 负责把模型跑起来并提供统一接口WebUI 负责给人一个顺手的对话入口AnythingLLM 负责文档解析、切片、向量化和检索增强。三者都是可以独立运行的拼在一起才形成能读自己资料、能留痕、能分权限的完整闭环。适合谁来参考两类人。一类是个人手上有一台带独显的机器或者一台常年开着的迷你主机想把自己收藏的资料变成可问答的知识库另一类是小团队需要给几个同事共享一套内部问答但又不想为此专门立项开发。前者关注能不能跑起来后者关注能不能稳住、能不能隔离这篇都会讲到。关于安全可靠这四个字我理解成三层意思数据不出本机或内网、服务重启后配置和数据还在、回答有据可查能点回原文。后面每一个技术选择我都会围绕这三层来解释为什么这么定。2. 方案设计与选型拆解2.1 三件套的分工边界别让功能互相打架很多人第一次接触会疑惑Open WebUI 自己就带文档上传和 RAG 功能AnythingLLM 也是干这个的为什么两个都装这不是重复建设吗我踩过这个坑。一开始我只装了 Ollama Open WebUI上传了几份 PDF 测了一下确实能用。但用了一段时间发现几个问题一是文档管理比较粗改一份文档得重新上传整个文件没法做增量更新二是工作区概念弱不同项目的资料混在一个池子里检索时互相干扰三是引用溯源做得不够细回答里给个角标但很难一眼看到原文上下文。AnythingLLM 的强项正好在这块它有明确的工作区Workspace概念每个工作区独立的文档池、独立的向量集合、独立的提示词模板甚至可以给不同工作区配不同的模型。做企业场景时这个隔离能力几乎是刚需——财务的资料和研发的资料放在同一个检索池里早晚出事。所以我的定位是这样组件核心职责我会用它做什么不建议用它做什么Ollama模型运行时统一 HTTP 接口跑对话模型、跑 embedding 模型不要指望它做文档解析和检索编排Open WebUI通用对话前端多用户、多模型日常聊天、模型对比、快速验证模型能力不适合当严肃的知识库管理后台AnythingLLM文档管线 向量检索 引用建工作区、灌文档、做带出处的问答不适合当通用聊天工具界面偏功能型一句话概括WebUI 是跟模型聊天的地方AnythingLLM 是跟资料对话的地方。两者都指向同一个 Ollama模型只加载一份显存不会翻倍——这点很重要很多人担心装两套前端会占两份显存其实不会因为推理是 Ollama 在做。2.2 数据是怎么流动的画不出图也要在脑子里过一遍整个链路我拆成四段理解了这四段后面所有参数调整都有依据。第一段是文档摄入。AnythingLLM 拿到你的 PDF、Word、TXT先做文本抽取。PDF 是最麻烦的扫描版需要 OCR双栏排版容易串行表格抽出来往往变成一堆乱码字符。抽取完的纯文本会按规则切成一个个片段chunk每个片段几百字。第二段是向量化。每个片段送进 embedding 模型变成一个高维向量。这里用的是 Ollama 拉下来的 embedding 模型比如常见的多语言向量模型输出 768 维或 1024 维的浮点数组。这些向量连同原文一起存进向量库AnythingLLM 默认用内置的 LanceDB也可以换成外部的向量数据库。第三段是检索。你提一个问题问题本身也被同一个 embedding 模型转成向量然后在向量库里做相似度搜索取回最相近的 Top-K 个片段。第四段是生成。取回的片段拼进提示词模板和你的问题一起送给对话模型模型基于这些片段组织答案同时 AnythingLLM 会把用到的片段来源标出来。这条链路上任何一段出问题最终表现都是答得不对。所以排查的时候必须能定位到是哪一段——是文档没抽干净还是切片切断了语义还是检索没召回还是模型不听话。后面第 5 章我会给一套逐段排查的方法。提示向量化用的 embedding 模型和对话用的生成模型是两个独立的模型必须分开拉取。很多人只拉了对话模型AnythingLLM 里配 embedding 时选不到东西就是因为少了这一步。2.3 硬件和模型规模的账先算再装这一步最容易被跳过然后装完发现跑不动。我见过有人拿一台 16G 内存的办公本硬上 32B 模型一个回答等三分钟最后得出结论说本地模型不可用。先看权重占用。量化后的模型大小大致可以按参数量 × 每参数字节数估算Q4_K_M 量化大约是每参数 0.55 到 0.6 字节模型规模Q4_K_M 权重占用4K 上下文 KV 缓存建议显存建议内存单人问答体验7B / 8B约 4.1 – 4.9 GB约 0.5 – 1 GB8 GB16 GB流畅14B约 9 GB约 1 – 2 GB12 – 16 GB32 GB流畅32B约 20 GB约 3 – 4 GB24 GB64 GB尚可首字延迟明显70B约 43 GB约 6 – 8 GB48 GB 以上128 GB需要专业卡或多卡KV 缓存这块给个能自己算的公式方便你换模型时快速估KV_bytes 2 × 层数 × KV头数 × 头维度 × 序列长度 × 数据类型字节数拿一个 7B、32 层、GQA 8 个 KV 头、头维度 128 的模型算序列长度 4096半精度 2 字节2 × 32 × 8 × 128 × 4096 × 2 ≈ 537 MB也就是说 4K 上下文下 KV 缓存大概半 G。如果你把num_ctx调到 16384这项就变成 2G 左右。这就是为什么 RAG 场景调大上下文之后显存突然吃紧——不是模型变大了是缓存变大了。没有独显怎么办CPU 推理完全可行7B Q4 在普通桌面 CPU 上大概 5 到 10 token/s一个人看文档问答够用只是首字要等两三秒。我的建议是个人用优先 7B 或 8B 的指令微调版本团队共享且有显卡就上 14B32B 以上没有 24G 显存别轻易尝试。3. 环境准备与三件套部署实操3.1 Ollama 安装与关键环境变量Ollama 的安装本身没什么好说的各平台都有对应方式。Linux 上用官方脚本一行搞定Windows 和 macOS 直接下安装包。装完之后ollama --version能看到版本号就说明服务起来了。真正要动手的是环境变量配置因为默认配置是给本机单人用设计的一旦要跨机访问或者多人共享就必须改。Linux 下用 systemd 的 override 机制改最规范sudo systemctl edit ollama.service在打开的编辑器里填[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_KEEP_ALIVE30m EnvironmentOLLAMA_NUM_PARALLEL2 EnvironmentOLLAMA_MAX_LOADED_MODELS2逐个解释为什么要这么设。OLLAMA_HOST改成0.0.0.0是为了让容器里的 WebUI 和 AnythingLLM 能访问到。默认只监听 127.0.0.1容器里访问宿主机会直接被拒。这一项是新手最容易卡住的地方。OLLAMA_MODELS指向一个大盘目录。模型动辄几个 G默认放在系统盘的用户目录下装三四个模型系统盘就红了。我一般单独挂一块盘专门放模型重装系统也不用重新下载。OLLAMA_KEEP_ALIVE决定模型在内存里待多久。默认 5 分钟意味着你隔一会儿不问模型就被卸载了下次提问要重新加载7B 大概等 3 到 5 秒32B 能等十几秒。设成 30 分钟体验会好很多代价是内存一直被占着。个人机器我设 30m共享服务器设 2h。OLLAMA_NUM_PARALLEL是并发数默认 1。设成 2 意味着同时能处理两个请求但显存占用会接近翻倍因为要开两份 KV 缓存。团队共享设 2 到 4个人机器保持 1。OLLAMA_MAX_LOADED_MODELS控制同时加载几个模型。如果你既要对话模型又要 embedding 模型这个至少得是 2否则每检索一次就要卸载重载一次对话模型慢得离谱。改完重启服务sudo systemctl daemon-reload sudo systemctl restart ollama然后拉模型。对话模型和向量模型都要拉这一步不能省ollama pull qwen2.5:7b-instruct-q4_K_M ollama pull nomic-embed-text拉完ollama list确认两个都在。再验证一下接口通不通curl http://127.0.0.1:11434/api/tags返回 JSON 里有模型列表就说明服务正常。注意显卡驱动和 CUDA 运行时这块Ollama 会自动检测。如果日志里出现回退到 CPU 的提示先查驱动版本别急着怀疑模型。用ollama ps能看到当前加载的模型以及跑在 GPU 还是 CPU 上这个命令我几乎每次部署完都要看一遍。3.2 Open WebUI 部署注意存储卷和跨容器访问Open WebUI 我习惯用容器方式跑好处是升级方便删掉容器数据还在。启动命令docker run -d \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main三个参数值得说。-v open-webui:/app/backend/data是命名的存储卷用户账号、聊天记录、配置全在这里面。我第一次装的时候忘了加容器一删所有对话记录全没了。--add-hosthost.docker.internal:host-gateway在 Linux 上是必须的否则容器里解析不了host.docker.internal这个主机名。macOS 和 Windows 的 Docker Desktop 自带这个解析Linux 上不加就会连不上宿主机上的 Ollama。这是我在 Linux 服务器上第一次部署时卡了半小时的地方。-p 3000:8080把容器内 8080 映射到宿主 3000。映射到哪个端口看你习惯只要不冲突就行。起来之后浏览器打开http://服务器IP:3000第一次会让你注册管理员账号。第一个注册的账号就是管理员所以部署在能被别人访问的网络上时装完立刻注册别拖着。进后台设置里把 Ollama 的连接地址填成http://host.docker.internal:11434。如果 Ollama 和 WebUI 在同一台机器上这个地址就对。如果 Ollama 在另一台机器上直接填那台机器的内网 IP。填完点保存正常情况下模型下拉框会自动刷出你拉过的模型。刷不出来按顺序查三件事Ollama 的OLLAMA_HOST是否改了、防火墙是否放行 11434、从容器内部能不能curl通。这里有个细节很多人不知道Open WebUI 自己也有个文档功能可以把文件传到它的知识库里做检索。功能是有的但在大文档量场景下管理能力偏弱我一般只在小规模快速验证时用正式的知识库还是交给 AnythingLLM。3.3 AnythingLLM 部署与工作区配置AnythingLLM 同样用容器跑命令比 Open WebUI 稍复杂一点docker run -d \ -p 3001:3001 \ --cap-add SYS_ADMIN \ -v /opt/anythingllm:/app/server/storage \ -e STORAGE_DIR/app/server/storage \ --name anythingllm \ --restart always \ mintplexlabs/anythingllm--cap-add SYS_ADMIN这个参数是为了容器内能跑无头浏览器做网页内容抓取用的。如果你确定只用本地文件、不抓网页理论上可以不加但加了更省事避免以后想用发现报错再回来改。存储卷挂在/app/server/storage所有上传的原始文档、切好的向量库、配置都在里面。这个目录一定要做备份尤其是向量库重建一次要重新向量化所有文档几十份文档就是十几分钟。起来之后访问http://服务器IP:3001走一遍初始化向导。向导里会让你选模型提供方选 Ollama地址填http://宿主机IP:11434。注意这里如果 AnythingLLM 跑在容器里同样要用host.docker.internal或者宿主机的内网 IP不要填127.0.0.1容器里的127.0.0.1是容器自己。向导第二步会让你选 embedding 模型这里选 Ollama 里拉的那个向量模型。如果下拉框是空的说明向量模型没拉回去ollama pull一下。初始化完成后进主界面新建工作区Workspace起个能看懂的名字比如产品文档、技术规范。每个工作区是一个独立的检索池这点是 AnythingLLM 最有价值的设计。上传文档的路径是工作区里的上传按钮支持 PDF、DOCX、TXT、MD、CSV 等常见格式。上传完点击移动到工作区然后点保存并嵌入这时候才会真正做切片和向量化。这一步我见过很多人漏掉文件传上去了但没点嵌入然后问问题永远查不到。文档分区的实际建议不要把所有资料塞进一个工作区。我一般的划分是按业务线或者按文档类型分比如售前资料、实施手册、历史复盘、合同模板四块。检索时只在你选中的工作区里搜召回精度会明显提升因为干扰项少了。3.4 内网访问与基础加固别把服务裸奔在公网这一节是安全可靠里安全的落地点我单独拎出来说因为见过太多人直接把端口映射到公网几天后日志里全是扫描记录。第一条这三个服务默认都没有强认证机制不要暴露到公网。Ollama 的 11434 端口是完全无认证的 HTTP 接口谁能访问谁就能调你的模型、看你的日志。Open WebUI 和 AnythingLLM 虽然有账号体系但配置不当也会有风险。正确做法是把服务绑在内网地址上外部访问走统一网关。第二条限制监听地址。如果你确定只有本机用Ollama 的OLLAMA_HOST就保持127.0.0.1:11434容器访问走 host 网络模式或者用--network host。只有确实需要跨机访问时才改成0.0.0.0。第三条用防火墙做白名单。Linux 上用 iptables 或 nftables 限制来源 IP只放行团队所在的网段。这条比什么密码都管用sudo iptables -A INPUT -p tcp --dport 11434 -s 192.168.10.0/24 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 11434 -j DROP第四条模型文件本身也要注意。Ollama 的模型目录里存的是 GGUF 格式的权重本身不含你的业务数据但 embedding 模型跑出来的向量库是实打实从你的资料里算出来的那个目录的权限要收紧只给运行服务的账号读写。第五条留好备份。我给自己的规矩是每周备份一次 AnythingLLM 的 storage 目录用 rsync 增量同步到另一块盘rsync -av --delete /opt/anythingllm/ /backup/anythingllm/别用cp -r大目录复制一半中断会留下半残的文件恢复的时候更麻烦。4. 知识库构建的核心细节切分、向量化与检索4.1 文档预处理决定了上限在哪我一直认为知识库效果的天花板在文档预处理这一步就定死了后面的模型和参数只能在天花板下面微调。一份扫描歪了的 PDF你用再强的模型也问不出准确答案。PDF 处理是重灾区。分三种情况电子版原生 PDF文本层是完整的直接抽取质量很高扫描件 PDF本质是图片必须走 OCR混合型 PDF前面几页是封面扫描后面是电子版正文抽取出来往往是前半段空白后半段正常。判断方法很简单用pdftotext抽一下看结果pdftotext -layout input.pdf output.txt wc -c output.txt如果输出的字符数少得可怜比如一百多页的文档只有几千字符基本就是扫描件老老实实上 OCR。-layout参数保留原始排版对双栏文档和表格的抽取效果明显好于默认模式。Word 文档的坑在表格和批注。常规正文抽取没问题但文档里的表格经常被抽成一行行用空格隔开的文字语义全丢。我的处理办法是把关键表格单独转成 Markdown 或者 CSV 再上传让检索时能按行匹配。Excel 不能整表上传。一个几千行的表切成片段之后每个片段都是一堆没有表头的数字向量化出来毫无意义。正确做法是先在表里加一列行描述把这一行的语义用一句话写出来只上传描述 关键字段这两三列。听起来麻烦但这是让表格类数据可检索的唯一靠谱办法。预处理还有一个容易被忽略的动作去页眉页脚。一份两百页的手册每页都有公司名和页码切片之后每个片段都带着这些重复内容会稀释向量的语义。用脚本批量删掉重复出现的首尾行效果提升立竿见影。4.2 切片参数的取舍没有标准答案只有合适答案切片chunk这一步的核心矛盾是切太小语义不完整检索出来答非所问切太大一个片段里混了好几个主题向量被平均掉检索精度下降。AnythingLLM 默认的切片大小是一千字符左右重叠两百字符。这个默认值对中文文档其实偏大因为中文一个字符的信息量比英文高一千个中文字符已经是一大段了。我实测下来的经验值文档类型建议切片大小重叠理由产品手册、说明书600 – 800 字符100段落短条目化切小更精准技术规范、制度文件800 – 1000 字符150条款之间有上下文依赖项目复盘、会议纪要1000 – 1200 字符200叙事性强切碎会丢逻辑问答对、FAQ一问一答为一个片段0保持完整语义单元重叠的作用是防止一句话正好被切在边界上前后两个片段各拿半句谁都读不懂。重叠量一般设成切片大小的 15% 到 20%。调整位置在 AnythingLLM 的工作区设置里有个文本分割偏好Text Split Preference可以改。改完要重新嵌入已有文档才生效所以建议在灌文档之前就把参数定下来别等灌了几百份再改重来一遍很费时间。提示切片参数没有全局最优解。我的做法是先拿 5 到 10 份代表性文档做小批量测试用一组固定的问题去问对比不同切片参数下的召回情况选定之后再批量导入。这个前期投入能省掉后面大量的返工。4.3 Embedding 模型和向量库的选择逻辑Embedding 模型决定了语义相近这件事算得准不准。选型上有三个维度要考虑。第一是语言。中文为主的资料一定要选多语言或者中文优化过的向量模型。纯英文模型在中文上表现会明显退化因为它压根没在中文语料上训练过。判断方法很直接拿两个语义相近但用词完全不同的中文句子算一下余弦相似度好的模型应该在 0.7 以上。第二是维度。768 维和 1024 维的模型后者表达能力强一些但存储和计算开销也大。对于几万份文档以内的场景768 维完全够用没必要追高。第三是和对话模型解耦。Embedding 模型可以比对话模型小得多一个几百兆的向量模型跑起来几乎不占显存。所以不要为了省事用对话模型来做 embedding那样又慢又差。向量库这块AnythingLLM 内置了 LanceDB开箱即用不需要额外部署。文档量在十万片段以内LanceDB 完全撑得住检索延迟在几十毫秒级别。什么时候需要考虑换外部向量库两个信号一是片段数超过几十万检索开始变慢二是需要多实例共享同一个向量库。这时候可以考虑外接支持向量检索的数据库AnythingLLM 支持配置外部向量库地址。但对绝大多数个人和小团队场景我的建议是先用内置的别一上来就折腾分布式向量库。我见过有人为了架构先进性先搭了一套外部向量库结果数据量根本没那么大反而多了一个故障点。4.4 检索策略与提示词模板把碎片拼成答案检索这块有两个关键参数召回数量和相似度阈值。召回数量就是 Top-K。K 太小召不全K 太大塞进提示词的内容变多一是容易超出上下文长度二是噪音变多反而干扰模型。我的经验值是K 取 4 到 6四平八稳。如果文档切片比较小600 字符左右可以取 6 到 8切片大就取 4。相似度阈值是个过滤线低于这个分数的片段直接丢掉不送给模型。这个参数的价值在于防止硬凑——当你的问题在知识库里压根没有对应内容时不加阈值的话系统还是会强行拿几个不相关的片段喂给模型模型就会编。设了阈值之后召回为空AnythingLLM 会明确告诉你没有找到相关内容这比编一个答案强得多。提示词模板System Prompt是另一个容易被忽略的点。默认模板比较通用我一般会改成更严格的三条约束你是内部资料助手。请严格依据下面提供的参考资料回答问题。 1. 参考资料中没有的信息直接回答资料中未提及不要推测。 2. 回答时用 [来源编号] 标注每句话的依据。 3. 如果不同资料存在冲突把冲突点列出来不要自行选择一方。这三条约束实测下来效果明显。第一条治编造第二条治无据可查第三条治多版本文档打架——后者在企业场景里极其常见同一个流程去年和今年的文档说法不一样模型如果不被要求指出冲突就会随机选一个然后你就被同事问为什么系统说是这样。温度temperature在知识库问答场景建议设低0.1 到 0.3 之间。温度高会带来表达多样性但在事实性问答里就是风险。我做合同条款问答的时候温度直接设 0。5. 调优与效果验证从能跑到好用5.1 上下文长度这个参数不设会出大问题这一节单独讲num_ctx因为它是 RAG 场景最容易出问题、又最不直观的参数。Ollama 的默认上下文长度在旧版本是 2048新版本提到 4096。听起来够用但你要算一笔账检索回来 5 个片段每个 800 字符加起来就是 4000 字符中文大概折算成 3000 到 4000 token再加上系统提示词、历史对话、你这次的问题很容易就超过 4096。超了会怎么样Ollama 不会报错它会静默截断。截断的是哪部分通常是最前面的内容也就是你的参考资料。表现就是明明检索到了正确片段模型却答资料里没说。这个现象我遇到过两次查了半天以为是检索问题最后发现是上下文被截了。所以正确做法是显式把num_ctx调大。两种设法一种是在 Ollama 侧用 Modelfile 固化ollama show qwen2.5:7b-instruct-q4_K_M --modelfile Modelfile编辑 Modelfile加上或修改这一行PARAMETER num_ctx 8192然后重新创建ollama create my-qwen-8k -f Modelfile另一种是在调用时通过 API 参数传AnythingLLM 的模型设置里也有对应的输入框。两种都行前者的好处是一次设定全局生效后者灵活。代价是什么回到第 2 章的公式上下文翻倍KV 缓存也翻倍。7B 模型从 4K 到 8KKV 缓存从 0.5G 涨到 1G还能接受32B 从 4K 到 16KKV 缓存能从 3G 涨到 12G这时候显存就紧张了。所以调大上下文之前先算一下显存余量别调完发现模型被挤到 CPU 上跑速度掉十倍。我的取值习惯7B/8B 用 819214B 用 819232B 用 8192 到 16384并且随时用ollama ps确认模型还在 GPU 上。5.2 建一套自己的评测集别靠感觉判断好坏效果调优最怕的就是感觉好像好了一点。人的判断很不稳定同一段回答上午看觉得不错下午看又觉得不行。所以我建议花半小时建一套小评测集。做法很简单从你的文档里挑 20 个问题覆盖几种典型情况。问题类型数量举例方向判断标准事实查找8某个参数值、某个日期、某个责任人答案与原文完全一致归纳总结4某流程分几步、某方案的三个要点要点齐全无遗漏无添加跨文档对比3两个版本的区别能指出差异点标注来源无答案问题3文档里确实没有的内容明确回答未提及不编造边界问题2模糊表述、多义词能澄清或给出条件性回答无答案问题这一类特别重要很多人建评测集只测能答对的不测该拒答的。但实际使用中编造答案的危害远大于答不出来。每次调整参数切片大小、K 值、阈值、提示词、模型都跑一遍这 20 题记录通过数。这样你能清楚看到每次改动是正收益还是负收益。我的记录表大概长这样版本改动内容通过数/20备注v1默认切片 1000K413事实题基本对无答案题全编v2加相似度阈值 0.416无答案题改善明显v3切片降到 700K618归纳题还有一题漏要点v4换 14B 模型19速度和效果平衡点这张表是我做过最值的一件事它把玄学调参变成了可观测的工程过程。5.3 多人共享时的并发与资源规划单机自用和团队共享是两种完全不同的负载。自用的时候你可以慢慢等共享的时候同事等十秒就开始抱怨了。先明确瓶颈在哪。Ollama 的推理是串行的OLLAMA_NUM_PARALLEL1时第二个人提问必须等第一个人答完。一个人问一个长问题生成 500 个 token7B 模型大概要 15 到 25 秒第二个人就得等这么久。解决方案有两个方向。一是加并发把OLLAMA_NUM_PARALLEL调到 2 到 4代价是显存按倍数增长每路一份 KV 缓存。二是控制输出长度在提示词里明确要求回答控制在 200 字以内这个手段几乎零成本效果立竿见影。我一般两个一起用。还有一个隐藏的坑embedding 请求和对话请求会抢资源。用户提问时系统先调 embedding 模型算问题向量再调对话模型生成答案。如果OLLAMA_MAX_LOADED_MODELS1这两个模型会互相挤每次提问都触发一次模型切换慢得离谱。所以这个参数至少设成 2这是多人场景的硬性要求。资源规划上给个粗略参考4 个人日常使用7B 模型 2 并发16G 内存 8G 显存的机器够用10 人以上建议 14B 模型 4 并发32G 内存 16G 显存起步。这是经验值具体还要看问题长度和文档规模。6. 常见问题与排查实录6.1 部署阶段的问题速查部署阶段的问题占了新手提问的一大半而且高度集中在几个点上。我整理成表按现象反查现象最可能的原因排查动作WebUI 里模型列表是空的Ollama 地址填成了 127.0.0.1容器内改用 host.docker.internal 或内网 IP容器连不上宿主机 OllamaLinux 缺 host-gateway 映射加--add-hosthost.docker.internal:host-gatewayOllama 启动即退出模型目录权限或磁盘满journalctl -u ollama -n 100看日志模型加载极慢显存不足回退到 CPUollama ps看处理器列nvidia-smi看占用AnythingLLM 上传文档报错存储目录无写权限chown修正目录属主文档传了但检索不到没点保存并嵌入工作区里手动触发嵌入首次登录后无法访问账号密码或会话问题清浏览器缓存检查存储卷是否可写几个我印象比较深的排查过程。案例一模型跑在 CPU 上却查不出原因。有一次在一台带显卡的机器上部署nvidia-smi显示显存完全没被占用问答速度慢得像蜗牛。查了半天发现是 Ollama 版本和驱动不匹配日志里其实有提示只是被淹没了。解决办法是看服务日志找到类似 no compatible GPUs found 的行。这个案例的教训是部署完第一件事就是ollama ps确认处理器类型别等到用户抱怨慢才发现。案例二容器里时间不对导致向量库报错。有一台机器的系统时区没设容器继承的 UTC 时间跟本地差 8 小时LanceDB 写记录时的时间戳出现倒序偶尔报错。加上-e TZAsia/Shanghai就解决了。这个坑很偏但排查起来极费时间因为报错信息指向的是数据库不是时间。案例三端口冲突。AnythingLLM 默认 3001如果机器上已经有别的服务占了容器起不来。docker logs anythingllm里能看到EADDRINUSE。换端口映射即可比如-p 3002:3001。6.2 检索质量问题的逐段定位法回答不准是最高频的问题也是最难排查的因为整条链路上任何一环出问题表象都一样。我用一套四步定位法从后往前推。第一步先看检索结果不看最终回答。AnythingLLM 的回答下方会列出引用的片段来源点开看原文。如果引用的片段跟问题压根无关问题在检索如果引用的片段是对的但回答错了问题在生成。这一步能把问题范围砍掉一半。第二步如果检索错了看切片。到工作区的文档管理里找到那份文档看它被切成了什么样。常见问题有三种切片把一句话切断了、切片里混进了页眉页脚、表格被抽成了乱码。看到具体问题就知道怎么改了。第三步如果切片正常但检索不到看 embedding。用同一个问题手动调一下 embedding 接口看返回的向量维度对不对。有个真实案例是用户误把对话模型配成了 embedding 模型向量维度完全不对检索结果纯随机。检查方法是在 AnythingLLM 的设置里确认嵌入模型选的是向量模型不是对话模型。第四步如果检索对了回答错看提示词和上下文长度。先确认num_ctx够不够回到 5.1 节再检查提示词是不是约束太弱。把温度降到 0.1 试试如果还是编就是提示词没镇住。这套方法的精髓是用引用片段这个中间产物把黑盒打开让问题定位从猜测变成观察。我在实际排查中基本都是靠它把范围缩小到具体环节的。6.3 性能与稳定性上的几个实战经验内存泄漏的迹象要盯。长时间运行之后如果发现响应越来越慢free -h看内存持续上涨不回落多半是模型卸载不干净。缓解办法是设一个定时重启策略比如每天凌晨重启一次 Ollama 服务。生产环境上我一般会用 cron 定时执行0 4 * * * systemctl restart ollama这个做法有点糙但确实有效比追查泄漏点省事。当然如果你的场景对连续性要求高还是应该定位具体原因。磁盘空间要定期清。Ollama 拉模型不自动清理旧版本ollama list里堆一堆用不上的模型很常见。ollama rm 模型名删掉不用的。AnythingLLM 的 storage 目录里删掉的文档对应的向量文件有时候不会立刻释放需要重建工作区才彻底清。文档更新是个真问题。你改了一份 PDF 重新上传向量库里会同时存在新旧两份内容检索时可能召回到旧版本然后答出过时信息。正确做法是先在工作区里删除旧文档、确认嵌入记录消失再上传新的。这个流程一定要跟同事说清楚否则知识库里的幽灵文档会成为长期隐患。给文档加元数据能省很多事。上传时在文档名前加上版本号或日期比如产品手册_v3_202503.pdf检索出来的引用片段会带着这个文件名你一眼就能判断是不是最新版本。这个小习惯比什么版本管理机制都简单有效。6.4 我踩过的几个坑写下来给后来人省点时间第一个坑别用超长文档直接灌。曾经把一份八百多页的规范手册整份上传向量化跑了二十多分钟然后发现检索效果很差因为文档里大量重复的模板化表述。后来的做法是先拆分按章节拆成十几个文件分别上传每个文件的主题更聚焦检索精度明显提升。大文档先拆后传这是我对所有超过一百页文档的标准动作。第二个坑别忽视中文标点和全半角。同一个词配置和配置一个全角一个半角在向量空间里可能有细微差异虽然影响不大但在精确匹配场景下会出问题。批量处理时统一转成半角能减少一些莫名其妙的匹配失败。第三个坑别指望模型理解你的内部黑话。公司内部有大量缩写和代号通用模型没训练过这些词embedding 也算不准。解决办法是在工作区里放一份术语表文档把所有内部缩写和它的完整解释列出来一起嵌入。检索时如果问题里带了缩写术语表会被召回模型就知道是什么意思了。这个技巧成本极低收益很高。第四个坑备份策略要包含向量库。我一开始只备份了原始文档觉得大不了重新向量化。后来一次硬件故障恢复重新向量化几百份文档花了近一个小时中间还因为某份 PDF 解析出错卡住了。从此我把整个 storage 目录纳入日常备份恢复时间从一小时缩短到五分钟。第五个坑别在同一个工作区里混放不同密级的资料。技术上做不到隔离因为检索是全局的谁有工作区访问权就能看到所有内容。企业场景下的正确做法是按权限划分工作区把用户分配到对应工作区。AnythingLLM 支持多用户和工作区权限配置部署时把这块配好能省掉后面很多麻烦。我个人在实际操作中的体会是这套组合真正的价值不在于用了大模型而在于它把资料检索这件事从人找文档变成了文档找人而且整个过程数据不出内网。但前提是你得愿意在文档预处理和参数调优上花时间——工具只是把路修好了路上跑得顺不顺取决于你喂进去的东西干不干净。
1. 先想清楚为什么要自己搭一套知识库把 Ollama、WebUI、AnythingLLM 这三个东西拼在一起做知识库这两年问的人越来越多但很多人一上来就照着教程敲命令装完了发现模型跑起来了、界面也能打开可一问问题就开始胡说八道或者干脆答文档里没有找到相关内容。问题不在工具而在于没想清楚这套东西各自管什么、边界在哪。我自己的场景很典型手上有一堆内部文档、产品手册、历史项目复盘格式乱七八糟PDF、Word、Excel、Markdown 全有。想用大模型来检索问答但资料本身不适合往外传也不能保证外部服务不会拿这些内容做别的事。于是思路就落到本地部署这条路上——模型跑在自己的机器上向量库落在自己的硬盘里整个链路不出内网。这套组合的分工是Ollama 负责把模型跑起来并提供统一接口WebUI 负责给人一个顺手的对话入口AnythingLLM 负责文档解析、切片、向量化和检索增强。三者都是可以独立运行的拼在一起才形成能读自己资料、能留痕、能分权限的完整闭环。适合谁来参考两类人。一类是个人手上有一台带独显的机器或者一台常年开着的迷你主机想把自己收藏的资料变成可问答的知识库另一类是小团队需要给几个同事共享一套内部问答但又不想为此专门立项开发。前者关注能不能跑起来后者关注能不能稳住、能不能隔离这篇都会讲到。关于安全可靠这四个字我理解成三层意思数据不出本机或内网、服务重启后配置和数据还在、回答有据可查能点回原文。后面每一个技术选择我都会围绕这三层来解释为什么这么定。2. 方案设计与选型拆解2.1 三件套的分工边界别让功能互相打架很多人第一次接触会疑惑Open WebUI 自己就带文档上传和 RAG 功能AnythingLLM 也是干这个的为什么两个都装这不是重复建设吗我踩过这个坑。一开始我只装了 Ollama Open WebUI上传了几份 PDF 测了一下确实能用。但用了一段时间发现几个问题一是文档管理比较粗改一份文档得重新上传整个文件没法做增量更新二是工作区概念弱不同项目的资料混在一个池子里检索时互相干扰三是引用溯源做得不够细回答里给个角标但很难一眼看到原文上下文。AnythingLLM 的强项正好在这块它有明确的工作区Workspace概念每个工作区独立的文档池、独立的向量集合、独立的提示词模板甚至可以给不同工作区配不同的模型。做企业场景时这个隔离能力几乎是刚需——财务的资料和研发的资料放在同一个检索池里早晚出事。所以我的定位是这样组件核心职责我会用它做什么不建议用它做什么Ollama模型运行时统一 HTTP 接口跑对话模型、跑 embedding 模型不要指望它做文档解析和检索编排Open WebUI通用对话前端多用户、多模型日常聊天、模型对比、快速验证模型能力不适合当严肃的知识库管理后台AnythingLLM文档管线 向量检索 引用建工作区、灌文档、做带出处的问答不适合当通用聊天工具界面偏功能型一句话概括WebUI 是跟模型聊天的地方AnythingLLM 是跟资料对话的地方。两者都指向同一个 Ollama模型只加载一份显存不会翻倍——这点很重要很多人担心装两套前端会占两份显存其实不会因为推理是 Ollama 在做。2.2 数据是怎么流动的画不出图也要在脑子里过一遍整个链路我拆成四段理解了这四段后面所有参数调整都有依据。第一段是文档摄入。AnythingLLM 拿到你的 PDF、Word、TXT先做文本抽取。PDF 是最麻烦的扫描版需要 OCR双栏排版容易串行表格抽出来往往变成一堆乱码字符。抽取完的纯文本会按规则切成一个个片段chunk每个片段几百字。第二段是向量化。每个片段送进 embedding 模型变成一个高维向量。这里用的是 Ollama 拉下来的 embedding 模型比如常见的多语言向量模型输出 768 维或 1024 维的浮点数组。这些向量连同原文一起存进向量库AnythingLLM 默认用内置的 LanceDB也可以换成外部的向量数据库。第三段是检索。你提一个问题问题本身也被同一个 embedding 模型转成向量然后在向量库里做相似度搜索取回最相近的 Top-K 个片段。第四段是生成。取回的片段拼进提示词模板和你的问题一起送给对话模型模型基于这些片段组织答案同时 AnythingLLM 会把用到的片段来源标出来。这条链路上任何一段出问题最终表现都是答得不对。所以排查的时候必须能定位到是哪一段——是文档没抽干净还是切片切断了语义还是检索没召回还是模型不听话。后面第 5 章我会给一套逐段排查的方法。提示向量化用的 embedding 模型和对话用的生成模型是两个独立的模型必须分开拉取。很多人只拉了对话模型AnythingLLM 里配 embedding 时选不到东西就是因为少了这一步。2.3 硬件和模型规模的账先算再装这一步最容易被跳过然后装完发现跑不动。我见过有人拿一台 16G 内存的办公本硬上 32B 模型一个回答等三分钟最后得出结论说本地模型不可用。先看权重占用。量化后的模型大小大致可以按参数量 × 每参数字节数估算Q4_K_M 量化大约是每参数 0.55 到 0.6 字节模型规模Q4_K_M 权重占用4K 上下文 KV 缓存建议显存建议内存单人问答体验7B / 8B约 4.1 – 4.9 GB约 0.5 – 1 GB8 GB16 GB流畅14B约 9 GB约 1 – 2 GB12 – 16 GB32 GB流畅32B约 20 GB约 3 – 4 GB24 GB64 GB尚可首字延迟明显70B约 43 GB约 6 – 8 GB48 GB 以上128 GB需要专业卡或多卡KV 缓存这块给个能自己算的公式方便你换模型时快速估KV_bytes 2 × 层数 × KV头数 × 头维度 × 序列长度 × 数据类型字节数拿一个 7B、32 层、GQA 8 个 KV 头、头维度 128 的模型算序列长度 4096半精度 2 字节2 × 32 × 8 × 128 × 4096 × 2 ≈ 537 MB也就是说 4K 上下文下 KV 缓存大概半 G。如果你把num_ctx调到 16384这项就变成 2G 左右。这就是为什么 RAG 场景调大上下文之后显存突然吃紧——不是模型变大了是缓存变大了。没有独显怎么办CPU 推理完全可行7B Q4 在普通桌面 CPU 上大概 5 到 10 token/s一个人看文档问答够用只是首字要等两三秒。我的建议是个人用优先 7B 或 8B 的指令微调版本团队共享且有显卡就上 14B32B 以上没有 24G 显存别轻易尝试。3. 环境准备与三件套部署实操3.1 Ollama 安装与关键环境变量Ollama 的安装本身没什么好说的各平台都有对应方式。Linux 上用官方脚本一行搞定Windows 和 macOS 直接下安装包。装完之后ollama --version能看到版本号就说明服务起来了。真正要动手的是环境变量配置因为默认配置是给本机单人用设计的一旦要跨机访问或者多人共享就必须改。Linux 下用 systemd 的 override 机制改最规范sudo systemctl edit ollama.service在打开的编辑器里填[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_KEEP_ALIVE30m EnvironmentOLLAMA_NUM_PARALLEL2 EnvironmentOLLAMA_MAX_LOADED_MODELS2逐个解释为什么要这么设。OLLAMA_HOST改成0.0.0.0是为了让容器里的 WebUI 和 AnythingLLM 能访问到。默认只监听 127.0.0.1容器里访问宿主机会直接被拒。这一项是新手最容易卡住的地方。OLLAMA_MODELS指向一个大盘目录。模型动辄几个 G默认放在系统盘的用户目录下装三四个模型系统盘就红了。我一般单独挂一块盘专门放模型重装系统也不用重新下载。OLLAMA_KEEP_ALIVE决定模型在内存里待多久。默认 5 分钟意味着你隔一会儿不问模型就被卸载了下次提问要重新加载7B 大概等 3 到 5 秒32B 能等十几秒。设成 30 分钟体验会好很多代价是内存一直被占着。个人机器我设 30m共享服务器设 2h。OLLAMA_NUM_PARALLEL是并发数默认 1。设成 2 意味着同时能处理两个请求但显存占用会接近翻倍因为要开两份 KV 缓存。团队共享设 2 到 4个人机器保持 1。OLLAMA_MAX_LOADED_MODELS控制同时加载几个模型。如果你既要对话模型又要 embedding 模型这个至少得是 2否则每检索一次就要卸载重载一次对话模型慢得离谱。改完重启服务sudo systemctl daemon-reload sudo systemctl restart ollama然后拉模型。对话模型和向量模型都要拉这一步不能省ollama pull qwen2.5:7b-instruct-q4_K_M ollama pull nomic-embed-text拉完ollama list确认两个都在。再验证一下接口通不通curl http://127.0.0.1:11434/api/tags返回 JSON 里有模型列表就说明服务正常。注意显卡驱动和 CUDA 运行时这块Ollama 会自动检测。如果日志里出现回退到 CPU 的提示先查驱动版本别急着怀疑模型。用ollama ps能看到当前加载的模型以及跑在 GPU 还是 CPU 上这个命令我几乎每次部署完都要看一遍。3.2 Open WebUI 部署注意存储卷和跨容器访问Open WebUI 我习惯用容器方式跑好处是升级方便删掉容器数据还在。启动命令docker run -d \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui \ --restart always \ ghcr.io/open-webui/open-webui:main三个参数值得说。-v open-webui:/app/backend/data是命名的存储卷用户账号、聊天记录、配置全在这里面。我第一次装的时候忘了加容器一删所有对话记录全没了。--add-hosthost.docker.internal:host-gateway在 Linux 上是必须的否则容器里解析不了host.docker.internal这个主机名。macOS 和 Windows 的 Docker Desktop 自带这个解析Linux 上不加就会连不上宿主机上的 Ollama。这是我在 Linux 服务器上第一次部署时卡了半小时的地方。-p 3000:8080把容器内 8080 映射到宿主 3000。映射到哪个端口看你习惯只要不冲突就行。起来之后浏览器打开http://服务器IP:3000第一次会让你注册管理员账号。第一个注册的账号就是管理员所以部署在能被别人访问的网络上时装完立刻注册别拖着。进后台设置里把 Ollama 的连接地址填成http://host.docker.internal:11434。如果 Ollama 和 WebUI 在同一台机器上这个地址就对。如果 Ollama 在另一台机器上直接填那台机器的内网 IP。填完点保存正常情况下模型下拉框会自动刷出你拉过的模型。刷不出来按顺序查三件事Ollama 的OLLAMA_HOST是否改了、防火墙是否放行 11434、从容器内部能不能curl通。这里有个细节很多人不知道Open WebUI 自己也有个文档功能可以把文件传到它的知识库里做检索。功能是有的但在大文档量场景下管理能力偏弱我一般只在小规模快速验证时用正式的知识库还是交给 AnythingLLM。3.3 AnythingLLM 部署与工作区配置AnythingLLM 同样用容器跑命令比 Open WebUI 稍复杂一点docker run -d \ -p 3001:3001 \ --cap-add SYS_ADMIN \ -v /opt/anythingllm:/app/server/storage \ -e STORAGE_DIR/app/server/storage \ --name anythingllm \ --restart always \ mintplexlabs/anythingllm--cap-add SYS_ADMIN这个参数是为了容器内能跑无头浏览器做网页内容抓取用的。如果你确定只用本地文件、不抓网页理论上可以不加但加了更省事避免以后想用发现报错再回来改。存储卷挂在/app/server/storage所有上传的原始文档、切好的向量库、配置都在里面。这个目录一定要做备份尤其是向量库重建一次要重新向量化所有文档几十份文档就是十几分钟。起来之后访问http://服务器IP:3001走一遍初始化向导。向导里会让你选模型提供方选 Ollama地址填http://宿主机IP:11434。注意这里如果 AnythingLLM 跑在容器里同样要用host.docker.internal或者宿主机的内网 IP不要填127.0.0.1容器里的127.0.0.1是容器自己。向导第二步会让你选 embedding 模型这里选 Ollama 里拉的那个向量模型。如果下拉框是空的说明向量模型没拉回去ollama pull一下。初始化完成后进主界面新建工作区Workspace起个能看懂的名字比如产品文档、技术规范。每个工作区是一个独立的检索池这点是 AnythingLLM 最有价值的设计。上传文档的路径是工作区里的上传按钮支持 PDF、DOCX、TXT、MD、CSV 等常见格式。上传完点击移动到工作区然后点保存并嵌入这时候才会真正做切片和向量化。这一步我见过很多人漏掉文件传上去了但没点嵌入然后问问题永远查不到。文档分区的实际建议不要把所有资料塞进一个工作区。我一般的划分是按业务线或者按文档类型分比如售前资料、实施手册、历史复盘、合同模板四块。检索时只在你选中的工作区里搜召回精度会明显提升因为干扰项少了。3.4 内网访问与基础加固别把服务裸奔在公网这一节是安全可靠里安全的落地点我单独拎出来说因为见过太多人直接把端口映射到公网几天后日志里全是扫描记录。第一条这三个服务默认都没有强认证机制不要暴露到公网。Ollama 的 11434 端口是完全无认证的 HTTP 接口谁能访问谁就能调你的模型、看你的日志。Open WebUI 和 AnythingLLM 虽然有账号体系但配置不当也会有风险。正确做法是把服务绑在内网地址上外部访问走统一网关。第二条限制监听地址。如果你确定只有本机用Ollama 的OLLAMA_HOST就保持127.0.0.1:11434容器访问走 host 网络模式或者用--network host。只有确实需要跨机访问时才改成0.0.0.0。第三条用防火墙做白名单。Linux 上用 iptables 或 nftables 限制来源 IP只放行团队所在的网段。这条比什么密码都管用sudo iptables -A INPUT -p tcp --dport 11434 -s 192.168.10.0/24 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 11434 -j DROP第四条模型文件本身也要注意。Ollama 的模型目录里存的是 GGUF 格式的权重本身不含你的业务数据但 embedding 模型跑出来的向量库是实打实从你的资料里算出来的那个目录的权限要收紧只给运行服务的账号读写。第五条留好备份。我给自己的规矩是每周备份一次 AnythingLLM 的 storage 目录用 rsync 增量同步到另一块盘rsync -av --delete /opt/anythingllm/ /backup/anythingllm/别用cp -r大目录复制一半中断会留下半残的文件恢复的时候更麻烦。4. 知识库构建的核心细节切分、向量化与检索4.1 文档预处理决定了上限在哪我一直认为知识库效果的天花板在文档预处理这一步就定死了后面的模型和参数只能在天花板下面微调。一份扫描歪了的 PDF你用再强的模型也问不出准确答案。PDF 处理是重灾区。分三种情况电子版原生 PDF文本层是完整的直接抽取质量很高扫描件 PDF本质是图片必须走 OCR混合型 PDF前面几页是封面扫描后面是电子版正文抽取出来往往是前半段空白后半段正常。判断方法很简单用pdftotext抽一下看结果pdftotext -layout input.pdf output.txt wc -c output.txt如果输出的字符数少得可怜比如一百多页的文档只有几千字符基本就是扫描件老老实实上 OCR。-layout参数保留原始排版对双栏文档和表格的抽取效果明显好于默认模式。Word 文档的坑在表格和批注。常规正文抽取没问题但文档里的表格经常被抽成一行行用空格隔开的文字语义全丢。我的处理办法是把关键表格单独转成 Markdown 或者 CSV 再上传让检索时能按行匹配。Excel 不能整表上传。一个几千行的表切成片段之后每个片段都是一堆没有表头的数字向量化出来毫无意义。正确做法是先在表里加一列行描述把这一行的语义用一句话写出来只上传描述 关键字段这两三列。听起来麻烦但这是让表格类数据可检索的唯一靠谱办法。预处理还有一个容易被忽略的动作去页眉页脚。一份两百页的手册每页都有公司名和页码切片之后每个片段都带着这些重复内容会稀释向量的语义。用脚本批量删掉重复出现的首尾行效果提升立竿见影。4.2 切片参数的取舍没有标准答案只有合适答案切片chunk这一步的核心矛盾是切太小语义不完整检索出来答非所问切太大一个片段里混了好几个主题向量被平均掉检索精度下降。AnythingLLM 默认的切片大小是一千字符左右重叠两百字符。这个默认值对中文文档其实偏大因为中文一个字符的信息量比英文高一千个中文字符已经是一大段了。我实测下来的经验值文档类型建议切片大小重叠理由产品手册、说明书600 – 800 字符100段落短条目化切小更精准技术规范、制度文件800 – 1000 字符150条款之间有上下文依赖项目复盘、会议纪要1000 – 1200 字符200叙事性强切碎会丢逻辑问答对、FAQ一问一答为一个片段0保持完整语义单元重叠的作用是防止一句话正好被切在边界上前后两个片段各拿半句谁都读不懂。重叠量一般设成切片大小的 15% 到 20%。调整位置在 AnythingLLM 的工作区设置里有个文本分割偏好Text Split Preference可以改。改完要重新嵌入已有文档才生效所以建议在灌文档之前就把参数定下来别等灌了几百份再改重来一遍很费时间。提示切片参数没有全局最优解。我的做法是先拿 5 到 10 份代表性文档做小批量测试用一组固定的问题去问对比不同切片参数下的召回情况选定之后再批量导入。这个前期投入能省掉后面大量的返工。4.3 Embedding 模型和向量库的选择逻辑Embedding 模型决定了语义相近这件事算得准不准。选型上有三个维度要考虑。第一是语言。中文为主的资料一定要选多语言或者中文优化过的向量模型。纯英文模型在中文上表现会明显退化因为它压根没在中文语料上训练过。判断方法很直接拿两个语义相近但用词完全不同的中文句子算一下余弦相似度好的模型应该在 0.7 以上。第二是维度。768 维和 1024 维的模型后者表达能力强一些但存储和计算开销也大。对于几万份文档以内的场景768 维完全够用没必要追高。第三是和对话模型解耦。Embedding 模型可以比对话模型小得多一个几百兆的向量模型跑起来几乎不占显存。所以不要为了省事用对话模型来做 embedding那样又慢又差。向量库这块AnythingLLM 内置了 LanceDB开箱即用不需要额外部署。文档量在十万片段以内LanceDB 完全撑得住检索延迟在几十毫秒级别。什么时候需要考虑换外部向量库两个信号一是片段数超过几十万检索开始变慢二是需要多实例共享同一个向量库。这时候可以考虑外接支持向量检索的数据库AnythingLLM 支持配置外部向量库地址。但对绝大多数个人和小团队场景我的建议是先用内置的别一上来就折腾分布式向量库。我见过有人为了架构先进性先搭了一套外部向量库结果数据量根本没那么大反而多了一个故障点。4.4 检索策略与提示词模板把碎片拼成答案检索这块有两个关键参数召回数量和相似度阈值。召回数量就是 Top-K。K 太小召不全K 太大塞进提示词的内容变多一是容易超出上下文长度二是噪音变多反而干扰模型。我的经验值是K 取 4 到 6四平八稳。如果文档切片比较小600 字符左右可以取 6 到 8切片大就取 4。相似度阈值是个过滤线低于这个分数的片段直接丢掉不送给模型。这个参数的价值在于防止硬凑——当你的问题在知识库里压根没有对应内容时不加阈值的话系统还是会强行拿几个不相关的片段喂给模型模型就会编。设了阈值之后召回为空AnythingLLM 会明确告诉你没有找到相关内容这比编一个答案强得多。提示词模板System Prompt是另一个容易被忽略的点。默认模板比较通用我一般会改成更严格的三条约束你是内部资料助手。请严格依据下面提供的参考资料回答问题。 1. 参考资料中没有的信息直接回答资料中未提及不要推测。 2. 回答时用 [来源编号] 标注每句话的依据。 3. 如果不同资料存在冲突把冲突点列出来不要自行选择一方。这三条约束实测下来效果明显。第一条治编造第二条治无据可查第三条治多版本文档打架——后者在企业场景里极其常见同一个流程去年和今年的文档说法不一样模型如果不被要求指出冲突就会随机选一个然后你就被同事问为什么系统说是这样。温度temperature在知识库问答场景建议设低0.1 到 0.3 之间。温度高会带来表达多样性但在事实性问答里就是风险。我做合同条款问答的时候温度直接设 0。5. 调优与效果验证从能跑到好用5.1 上下文长度这个参数不设会出大问题这一节单独讲num_ctx因为它是 RAG 场景最容易出问题、又最不直观的参数。Ollama 的默认上下文长度在旧版本是 2048新版本提到 4096。听起来够用但你要算一笔账检索回来 5 个片段每个 800 字符加起来就是 4000 字符中文大概折算成 3000 到 4000 token再加上系统提示词、历史对话、你这次的问题很容易就超过 4096。超了会怎么样Ollama 不会报错它会静默截断。截断的是哪部分通常是最前面的内容也就是你的参考资料。表现就是明明检索到了正确片段模型却答资料里没说。这个现象我遇到过两次查了半天以为是检索问题最后发现是上下文被截了。所以正确做法是显式把num_ctx调大。两种设法一种是在 Ollama 侧用 Modelfile 固化ollama show qwen2.5:7b-instruct-q4_K_M --modelfile Modelfile编辑 Modelfile加上或修改这一行PARAMETER num_ctx 8192然后重新创建ollama create my-qwen-8k -f Modelfile另一种是在调用时通过 API 参数传AnythingLLM 的模型设置里也有对应的输入框。两种都行前者的好处是一次设定全局生效后者灵活。代价是什么回到第 2 章的公式上下文翻倍KV 缓存也翻倍。7B 模型从 4K 到 8KKV 缓存从 0.5G 涨到 1G还能接受32B 从 4K 到 16KKV 缓存能从 3G 涨到 12G这时候显存就紧张了。所以调大上下文之前先算一下显存余量别调完发现模型被挤到 CPU 上跑速度掉十倍。我的取值习惯7B/8B 用 819214B 用 819232B 用 8192 到 16384并且随时用ollama ps确认模型还在 GPU 上。5.2 建一套自己的评测集别靠感觉判断好坏效果调优最怕的就是感觉好像好了一点。人的判断很不稳定同一段回答上午看觉得不错下午看又觉得不行。所以我建议花半小时建一套小评测集。做法很简单从你的文档里挑 20 个问题覆盖几种典型情况。问题类型数量举例方向判断标准事实查找8某个参数值、某个日期、某个责任人答案与原文完全一致归纳总结4某流程分几步、某方案的三个要点要点齐全无遗漏无添加跨文档对比3两个版本的区别能指出差异点标注来源无答案问题3文档里确实没有的内容明确回答未提及不编造边界问题2模糊表述、多义词能澄清或给出条件性回答无答案问题这一类特别重要很多人建评测集只测能答对的不测该拒答的。但实际使用中编造答案的危害远大于答不出来。每次调整参数切片大小、K 值、阈值、提示词、模型都跑一遍这 20 题记录通过数。这样你能清楚看到每次改动是正收益还是负收益。我的记录表大概长这样版本改动内容通过数/20备注v1默认切片 1000K413事实题基本对无答案题全编v2加相似度阈值 0.416无答案题改善明显v3切片降到 700K618归纳题还有一题漏要点v4换 14B 模型19速度和效果平衡点这张表是我做过最值的一件事它把玄学调参变成了可观测的工程过程。5.3 多人共享时的并发与资源规划单机自用和团队共享是两种完全不同的负载。自用的时候你可以慢慢等共享的时候同事等十秒就开始抱怨了。先明确瓶颈在哪。Ollama 的推理是串行的OLLAMA_NUM_PARALLEL1时第二个人提问必须等第一个人答完。一个人问一个长问题生成 500 个 token7B 模型大概要 15 到 25 秒第二个人就得等这么久。解决方案有两个方向。一是加并发把OLLAMA_NUM_PARALLEL调到 2 到 4代价是显存按倍数增长每路一份 KV 缓存。二是控制输出长度在提示词里明确要求回答控制在 200 字以内这个手段几乎零成本效果立竿见影。我一般两个一起用。还有一个隐藏的坑embedding 请求和对话请求会抢资源。用户提问时系统先调 embedding 模型算问题向量再调对话模型生成答案。如果OLLAMA_MAX_LOADED_MODELS1这两个模型会互相挤每次提问都触发一次模型切换慢得离谱。所以这个参数至少设成 2这是多人场景的硬性要求。资源规划上给个粗略参考4 个人日常使用7B 模型 2 并发16G 内存 8G 显存的机器够用10 人以上建议 14B 模型 4 并发32G 内存 16G 显存起步。这是经验值具体还要看问题长度和文档规模。6. 常见问题与排查实录6.1 部署阶段的问题速查部署阶段的问题占了新手提问的一大半而且高度集中在几个点上。我整理成表按现象反查现象最可能的原因排查动作WebUI 里模型列表是空的Ollama 地址填成了 127.0.0.1容器内改用 host.docker.internal 或内网 IP容器连不上宿主机 OllamaLinux 缺 host-gateway 映射加--add-hosthost.docker.internal:host-gatewayOllama 启动即退出模型目录权限或磁盘满journalctl -u ollama -n 100看日志模型加载极慢显存不足回退到 CPUollama ps看处理器列nvidia-smi看占用AnythingLLM 上传文档报错存储目录无写权限chown修正目录属主文档传了但检索不到没点保存并嵌入工作区里手动触发嵌入首次登录后无法访问账号密码或会话问题清浏览器缓存检查存储卷是否可写几个我印象比较深的排查过程。案例一模型跑在 CPU 上却查不出原因。有一次在一台带显卡的机器上部署nvidia-smi显示显存完全没被占用问答速度慢得像蜗牛。查了半天发现是 Ollama 版本和驱动不匹配日志里其实有提示只是被淹没了。解决办法是看服务日志找到类似 no compatible GPUs found 的行。这个案例的教训是部署完第一件事就是ollama ps确认处理器类型别等到用户抱怨慢才发现。案例二容器里时间不对导致向量库报错。有一台机器的系统时区没设容器继承的 UTC 时间跟本地差 8 小时LanceDB 写记录时的时间戳出现倒序偶尔报错。加上-e TZAsia/Shanghai就解决了。这个坑很偏但排查起来极费时间因为报错信息指向的是数据库不是时间。案例三端口冲突。AnythingLLM 默认 3001如果机器上已经有别的服务占了容器起不来。docker logs anythingllm里能看到EADDRINUSE。换端口映射即可比如-p 3002:3001。6.2 检索质量问题的逐段定位法回答不准是最高频的问题也是最难排查的因为整条链路上任何一环出问题表象都一样。我用一套四步定位法从后往前推。第一步先看检索结果不看最终回答。AnythingLLM 的回答下方会列出引用的片段来源点开看原文。如果引用的片段跟问题压根无关问题在检索如果引用的片段是对的但回答错了问题在生成。这一步能把问题范围砍掉一半。第二步如果检索错了看切片。到工作区的文档管理里找到那份文档看它被切成了什么样。常见问题有三种切片把一句话切断了、切片里混进了页眉页脚、表格被抽成了乱码。看到具体问题就知道怎么改了。第三步如果切片正常但检索不到看 embedding。用同一个问题手动调一下 embedding 接口看返回的向量维度对不对。有个真实案例是用户误把对话模型配成了 embedding 模型向量维度完全不对检索结果纯随机。检查方法是在 AnythingLLM 的设置里确认嵌入模型选的是向量模型不是对话模型。第四步如果检索对了回答错看提示词和上下文长度。先确认num_ctx够不够回到 5.1 节再检查提示词是不是约束太弱。把温度降到 0.1 试试如果还是编就是提示词没镇住。这套方法的精髓是用引用片段这个中间产物把黑盒打开让问题定位从猜测变成观察。我在实际排查中基本都是靠它把范围缩小到具体环节的。6.3 性能与稳定性上的几个实战经验内存泄漏的迹象要盯。长时间运行之后如果发现响应越来越慢free -h看内存持续上涨不回落多半是模型卸载不干净。缓解办法是设一个定时重启策略比如每天凌晨重启一次 Ollama 服务。生产环境上我一般会用 cron 定时执行0 4 * * * systemctl restart ollama这个做法有点糙但确实有效比追查泄漏点省事。当然如果你的场景对连续性要求高还是应该定位具体原因。磁盘空间要定期清。Ollama 拉模型不自动清理旧版本ollama list里堆一堆用不上的模型很常见。ollama rm 模型名删掉不用的。AnythingLLM 的 storage 目录里删掉的文档对应的向量文件有时候不会立刻释放需要重建工作区才彻底清。文档更新是个真问题。你改了一份 PDF 重新上传向量库里会同时存在新旧两份内容检索时可能召回到旧版本然后答出过时信息。正确做法是先在工作区里删除旧文档、确认嵌入记录消失再上传新的。这个流程一定要跟同事说清楚否则知识库里的幽灵文档会成为长期隐患。给文档加元数据能省很多事。上传时在文档名前加上版本号或日期比如产品手册_v3_202503.pdf检索出来的引用片段会带着这个文件名你一眼就能判断是不是最新版本。这个小习惯比什么版本管理机制都简单有效。6.4 我踩过的几个坑写下来给后来人省点时间第一个坑别用超长文档直接灌。曾经把一份八百多页的规范手册整份上传向量化跑了二十多分钟然后发现检索效果很差因为文档里大量重复的模板化表述。后来的做法是先拆分按章节拆成十几个文件分别上传每个文件的主题更聚焦检索精度明显提升。大文档先拆后传这是我对所有超过一百页文档的标准动作。第二个坑别忽视中文标点和全半角。同一个词配置和配置一个全角一个半角在向量空间里可能有细微差异虽然影响不大但在精确匹配场景下会出问题。批量处理时统一转成半角能减少一些莫名其妙的匹配失败。第三个坑别指望模型理解你的内部黑话。公司内部有大量缩写和代号通用模型没训练过这些词embedding 也算不准。解决办法是在工作区里放一份术语表文档把所有内部缩写和它的完整解释列出来一起嵌入。检索时如果问题里带了缩写术语表会被召回模型就知道是什么意思了。这个技巧成本极低收益很高。第四个坑备份策略要包含向量库。我一开始只备份了原始文档觉得大不了重新向量化。后来一次硬件故障恢复重新向量化几百份文档花了近一个小时中间还因为某份 PDF 解析出错卡住了。从此我把整个 storage 目录纳入日常备份恢复时间从一小时缩短到五分钟。第五个坑别在同一个工作区里混放不同密级的资料。技术上做不到隔离因为检索是全局的谁有工作区访问权就能看到所有内容。企业场景下的正确做法是按权限划分工作区把用户分配到对应工作区。AnythingLLM 支持多用户和工作区权限配置部署时把这块配好能省掉后面很多麻烦。我个人在实际操作中的体会是这套组合真正的价值不在于用了大模型而在于它把资料检索这件事从人找文档变成了文档找人而且整个过程数据不出内网。但前提是你得愿意在文档预处理和参数调优上花时间——工具只是把路修好了路上跑得顺不顺取决于你喂进去的东西干不干净。
