上个月帮一个做工业设备的团队收拾他们那套本地知识库起因特别朴素售前把三百多页的产品手册、两百多条历史工单和一堆内部报价规则直接丢进公有云对话框里问被合规那边看到截图当场叫停。他们的诉求其实很典型——既要大模型那种问一句话就能翻出答案的体验又不能把资料传到任何外部服务上去。折腾了两周最后落地的就是 Ollama Open WebUI AnythingLLM 这套组合Ollama 在本地跑模型AnythingLLM 负责把文档切成片、向量化、检索Open WebUI 给不熟悉命令行的同事当一个统一入口。这套组合在技术圈被讲了很多遍但大部分教程停留在跑起来了这一层真正让人头疼的问题全在后面模型答非所问、文档明明上传了却检索不到、同事第一次登录就报连接超时、跑了一周发现向量库和模型版本对不上要全部重建。这篇就把我踩过的这些坑顺着链路捋一遍从职责划分、硬件选型、容器部署、文档入库一直讲到效果调优和内网加固。如果你正准备给自己或团队搭一套不外传的知识库或者已经搭了一半卡在效果上下面这些内容应该能省你不少时间。1. 三个组件各管一段先把职责边界划清楚大多数教程上来就贴 docker run结果新手跑完一脸懵我到底该在哪个界面里传文档为什么 Open WebUI 里也能传文件AnythingLLM 里也能传文件两个都传一遍吗这个困惑的根源是没搞清楚三个组件在数据流里分别站在哪个位置。先把这张地图画清楚后面的所有配置决策都会变得有据可依。1.1 Ollama 在链路里到底承担什么Ollama 的角色非常单纯它是一个本地模型运行时对外暴露一套兼容的 HTTP 接口负责加载权重、管理显存、执行推理。它不懂文档、不懂切分、不懂向量你给它一段提示词它还你一段补全仅此而已。把它理解成本地版的模型 API 网关最准确——它同时也管模型的下载、版本标签、卸载和并发调度。这个定位带来一个很重要的实践结论Ollama 是整个链路里唯一吃显存的组件也是唯一需要认真做资源隔离的组件。AnythingLLM 的检索、切分、向量化如果不走 Ollama 的 embedding 接口几乎不占显存Open WebUI 更是个纯前端加一层转发。所以硬件预算应该几乎全部倾斜给 Ollama 所在的机器其他两个组件塞在同一台机器的普通内存里就行。我见过有人在三台机器上分别部署三个组件结果 Ollama 那台的显卡闲着另外两台反而因为跨机调用产生了额外的网络延迟和排错成本。除非你有明确的隔离要求单机 Docker Compose 编排是最省心的方案容器之间走一个自定义 bridge 网络用服务名互访比记 IP 靠谱得多。另外要提前想清楚的是 Ollama 的模型存储路径。默认它在用户目录下的.ollama里容器化部署时如果不做卷映射容器一删模型全没几十个 G 重新拉一遍能耗掉半天。我一般的做法是单独挂一块盘到./ollama然后通过OLLAMA_MODELS指过去这样迁移机器的时候整个目录打包带走即可。1.2 AnythingLLM 不是聊天壳子它管的是文档到答案的那段管道很多人第一次打开 AnythingLLM 会觉得它就是个套壳聊天界面这个印象会让你低估它的价值也会让你在调优时找错方向。它真正干的事情是 RAG 的全流程文档解析、文本切分、调用 embedding 模型生成向量、写入向量库、收到问题后做相似度检索、把检索到的片段拼进提示词再交给模型。这条管道上任何一个环节出问题表现出来都是同一句话——它答得不对。AnythingLLM 里有个概念叫工作区Workspace这是它设计上最值得称道的地方。每个工作区有自己的文档集合、自己的系统提示词、自己的对话历史。你可以给产品手册建一个工作区给售后工单建一个给内部制度再建一个互不干扰。企业场景下这一点非常关键因为把报价规则和公开产品手册混在一个向量空间里检索很容易让模型把不该说的内部价格说出来。还有一个容易被忽略的开关文档上传后有两种状态一种是已嵌入Move to Workspace一种是仅存储Save and Embed 之外的归档状态。只有嵌入过的文档才会参与检索。我见过不止一个人把文件拖进去就直接开问然后抱怨检索不到实际上是文件还躺在存储区没进向量库。这个交互设计确实有点反直觉第一次用务必确认文档列表里那个向量图标是点亮的。1.3 Open WebUI 的定位管理台还是第二套前端Open WebUI 的定位需要根据你的团队情况来定这也是我认为最容易被教程带偏的一点。它自带一套相当完整的对话界面、模型切换、多用户管理、对话历史功能上其实和 AnythingLLM 的聊天界面有重叠。如果两个都开着让同事用必然出现我在 A 界面问的和 B 界面答的不一样这种混乱。我的建议是二选一让另一个退回到它最擅长的位置。有两种典型组合组合方式前端入口适用场景代价Open WebUI 做主入口同事只用 3000 端口需要多用户、模型自由切换、对话归档AnythingLLM 只当后台知识库通过 API 调用AnythingLLM 做主入口同事只用 3001 端口以文档问答为绝对核心不需要切模型放弃 Open WebUI 的多用户和模型管理能力两个都开但分人群技术用 Open WebUI业务用 AnythingLLM团队里既有折腾模型的也有只用文档的运维两套权限要分别配我个人更倾向第一种。Open WebUI 的多用户体系、登录鉴权、对话分享做得更成熟适合直接推给非技术同事AnythingLLM 退居后台通过它提供的接口被调用或者干脆只让知识库维护人员进去管文档。这样前端只有一个入口培训成本最低出了问题排查路径也唯一。顺带说一句Open WebUI 自己也有文档上传和 RAG 功能但它对切分参数、向量库的控制粒度比 AnythingLLM 粗不少。如果你的文档结构简单、量不大用 Open WebUI 内置的就够了一旦涉及几百份异构文档、需要精细控制切分和检索阈值还是把 RAG 这层交给 AnythingLLM 更稳。2. 硬件与模型选型显存、量化、上下文三者互相拉扯选型这件事没有标准答案但有一个必须遵守的原则先算显存再定模型最后调上下文。顺序反了就会陷入模型跑起来了但一提问就 OOM的死循环。下面这些数字是我在不同机器上反复试出来的经验值可以当估算起点。2.1 显存估算的实际算法权重占用很好算参数量乘以每个参数的字节数。常见的 4-bit 量化Q4_K_M实际约 4.5 bit 每参数折算下来是 0.56 字节左右再加一点点额外开销。所以 7B 模型大约 4~5 GB14B 大约 9~10 GB32B 大约 19~21 GB。这只是权重。真正让显存爆掉的是 KV Cache它随上下文长度线性增长。粗略的经验公式是每 1K 上下文7B 模型约占 0.12~0.15 GB14B 约占 0.25 GB32B 约占 0.5 GB。也就是说一个 14B 模型开 8K 上下文权重 10 GB 加上 KV Cache 约 2 GB实际要准备 13 GB 左右才安全。把这个账算到具体配置上显卡显存可流畅运行的模型建议上下文备注8 GB7B Q44K只够轻量问答文档一多就吃力12 GB7B Q5 / 14B Q4紧4K~8K14B 需要限制并发16 GB14B Q48K个人知识库的甜点配置24 GB14B Q5 / 32B Q4紧8K~16K32B 效果明显更好但余量小48 GB 及以上32B Q5 / 70B Q416K~32K企业多用户场景没有独立显卡也别急着放弃。7B Q4 在普通桌面 CPU 上跑大概 3~6 token/s问一句话等十几秒作为个人查阅工具是可以接受的。但要注意 AnythingLLM 做检索时会先调 embedding 模型如果 embedding 也在同一台 CPU 上跑首次入库几百份文档可能要等很久建议放在夜间批量处理。2.2 中文知识库场景下的模型梯队知识库问答对模型的要求和聊天不一样它更看重三件事指令遵循能不能老老实实只根据给定材料回答、中文长文本理解、以及拒答能力材料里没有就说没有而不是编。参数量在这三件事上的边际收益非常明显我的实测感受是 7B 到 14B 的提升远大于 14B 到 32B但从 7B 直接跳到 32B 又是质变。企业场景里我一般推荐 14B 级别的中文优化模型作为主力32B 作为效果上限的备选。7B 更适合做文档摘要字段抽取这类结构化任务放到开放式问答上容易自信地胡说。还有一个常被忽略的点是模型的上下文窗口和 Ollama 实际分配的不一定一致——有些模型标称 128K但 Ollama 默认只给 2K 或 4K 的num_ctx你必须显式在 Modelfile 或请求参数里调大否则 AnythingLLM 塞进去的几个检索片段会被静默截断模型只看到最后一段答案自然驴唇不对马嘴。这一点我踩过实实在在的坑某次排查一个回答总是漏掉关键条款的问题查了两天检索日志都正常最后发现是num_ctx设的 2048而 AnythingLLM 每次塞进去的上下文有 3000 多 token前面检索到的内容全被截掉了。改完参数立刻正常。2.3 embedding 模型选错后面全白搭embedding 模型是整条管道里最不起眼但影响最大的一个环节。它负责把文本变成向量向量质量直接决定检索能不能找对片段。生成模型再强检索环节捞回来的是无关内容答案也不可能对。中文场景下我优先选多语言能力强的 embedding 模型维度一般在 768 到 1024 之间。维度高不代表好它只影响存储和计算开销效果还是看训练语料。选型时有个铁律同一个知识库里入库和查询必须用同一个 embedding 模型。我见过有人入库时用一个模型后来换了模型只改了查询配置结果向量空间对不上检索出来的东西完全是随机的。换 embedding 模型的代价是必须重建整个向量库没有捷径。所以在正式往里灌文档之前先用二三十份代表性文档做个小规模验证确认检索效果满意了再全量导入。这个前置动作能省掉后面几个小时的重复劳动。另外 embedding 模型对硬件要求很低几百 MB 的模型在 CPU 上跑就够快没必要和生成模型抢显存。可以在 AnythingLLM 里把 embedding 指向一个独立的 Ollama 实例或者直接用内置的本地 embedding把显存全留给生成模型。3. 部署落地Docker 网络与端口是最先翻车的地方三个组件单独跑都不难难在让它们互相看见。90% 的连接失败报错都跟容器网络、监听地址、端口映射这三件事有关。下面这份 Compose 编排是我用了很多次的基础版本可以直接拿去改。3.1 Ollama 的监听地址与跨容器访问Ollama 默认只监听127.0.0.1:11434这个默认值在裸机上是安全考虑但在容器里就是灾难——容器内的 127.0.0.1 只指向容器自己别的容器根本连不进来。必须显式改成0.0.0.0。services: ollama: image: ollama/ollama:latest container_name: ollama ports: - 11434:11434 volumes: - ./ollama:/root/.ollama environment: - OLLAMA_HOST0.0.0.0 - OLLAMA_KEEP_ALIVE30m - OLLAMA_NUM_PARALLEL2 - OLLAMA_MAX_LOADED_MODELS1 restart: unless-stopped networks: - kb-net几个参数值得单独解释。OLLAMA_KEEP_ALIVE控制模型在空闲多久后从显存卸载默认只有 5 分钟意味着同事每隔几分钟问一次模型就要重新加载一遍第一次响应会慢到十几秒。设成 30 分钟或更长体验会好很多代价是显存一直被占着。OLLAMA_NUM_PARALLEL是并发请求数设太大会让每个请求分到的上下文变小反而降低单次回答质量两个人以内用就设 1 或 2团队用再往上加。OLLAMA_MAX_LOADED_MODELS在多模型切换场景下可以设 2但要注意显存够不够同时装下两个。还有个隐蔽的坑如果你的宿主机本身已经装了 Ollama 并占用了 11434 端口容器映射会直接失败。部署前先用ss -lntp | grep 11434确认一下端口空闲。3.2 AnythingLLM 的环境变量与工作区创建AnythingLLM 的容器化部署有两个关键点一是存储目录必须挂出来二是模型配置可以在环境变量里预置也可以在首次启动的引导界面里填。我的经验是环境变量只配最基础的连接信息模型和工作区相关的配置全部在界面里做。原因是环境变量的变量名在不同版本之间改过好几次照着旧教程抄很容易配了个不生效的参数还查不出来。anythingllm: image: mintplexlabs/anythingllm:latest container_name: anythingllm ports: - 3001:3001 volumes: - ./anythingllm:/app/server/storage environment: - STORAGE_DIR/app/server/storage - LLM_PROVIDERollama - OLLAMA_BASE_PATHhttp://ollama:11434 - EMBEDDING_ENGINEollama cap_add: - SYS_ADMIN restart: unless-stopped networks: - kb-net注意OLLAMA_BASE_PATH这里填的是http://ollama:11434用的是 Compose 里的服务名而不是 localhost。这就是自定义网络的价值——容器之间可以直接用服务名解析。如果你没用 Compose 而是单独docker run那就得用--network指定同一个网络或者退而求其次用宿主机的内网 IP。cap_add: SYS_ADMIN这一行是为了让容器内的文档解析组件能正常工作部分镜像版本在做 PDF 转文本时需要它。不加的话可能出现上传成功但解析出空内容的诡异现象。启动后进 3001 端口第一件事是在设置里确认 LLM 和 Embedding 两个 provider 都选到了 Ollama并且点一下测试连接。测试通过再去创建你的第一个工作区。工作区名字建议带业务含义比如产品手册-2024后续文档一多你会感谢自己。3.3 Open WebUI 接入 Ollama 的两种方式Open WebUI 接 Ollama 有两个路径区别在于它是不是和 Ollama 在同一个容器网络里。open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui ports: - 3000:8080 volumes: - ./open-webui:/app/backend/data environment: - OLLAMA_BASE_URLhttp://ollama:11434 - WEBUI_AUTHtrue - DEFAULT_MODELSqwen2.5:14b-instruct-q4_K_M restart: unless-stopped networks: - kb-net这里有一个版本差异必须提醒较早的版本用单数的OLLAMA_BASE_URL新版本改成了复数的OLLAMA_BASE_URLS多个地址之间用分号分隔。变量名用错了不会报错只会表现为模型列表空空如也。判断方法很简单进界面后看设置里的连接页面如果一个模型都列不出来先去核对容器日志里读到的环境变量名。WEBUI_AUTHtrue是默认值但我要强调一下别关它。这是在公网或者公司内网暴露服务时最基本的一道门槛关掉意味着任何能访问到 3000 端口的人都能直接使用你的模型和对话历史。还有一点Open WebUI 的数据卷./open-webui里存着用户账号、对话记录、配置这个目录的备份优先级和向量库一样高。我一般把这两个目录一起放进定时快照任务里。4. 文档入库切分策略决定检索质量的上限前面三步都是把管道搭起来从这一步开始才真正决定这套东西好不好用。RAG 领域有句话我认为非常准确检索质量的上限由切分决定生成质量的上限由模型决定。检索没找对模型再强也是巧妇难为无米之炊。4.1 解析层PDF、扫描件、表格各自的处理方式文档解析是所有环节里最容易被低估的一步。很多人的第一反应是PDF 拖进去不就行了但 PDF 本质上是排版格式而不是文本格式解析出来的东西质量差别巨大。电子版 PDF可直接选中文字解析通常没问题但要注意多栏排版的文档解析器可能把左右两栏的文字交错拼接读起来是断句的。这类文档入库前最好转成纯文本或 Markdown 检查一遍。扫描版 PDF图片型解析出来是空的或者全是乱码必须走 OCR。这是最常见的翻车点判断方法是拿解析结果搜一个你确定文档里有的词搜不到就是没解析出来。Word 和 Markdown解析质量最好结构化信息保留得完整如果原始资料有这两种格式优先用它们。Excel 表格这一类的处理最麻烦因为表格的行列关系在纯文本里会丢失。我的做法是把每一行拼成一句自然语言再入库比如把型号、功率、价格三列拼成型号 X 的功率是 Y价格是 Z检索命中率会高很多。图片和图片型表格除非用多模态模型否则建议人工转写或干脆不入库。解析质量不达标后面调多少参数都救不回来。我通常会在入库前抽 5 份文档看一眼 AnythingLLM 里显示的解析文本确认没有大面积乱码和错位再批量导入。4.2 切分粒度与重叠的取舍切分参数里最重要的是块大小chunk size和重叠overlap。默认值通常偏小对中文文档不一定合适。块太小的后果是语义被切断比如一个条款的条件和结论被分到两个块里检索到条件那半句模型看到的是半截话答案就会缺一半。块太大的后果是检索精度下降一个块里塞了三四个不同主题向量被平均掉了跟任何一个具体问题的相似度都不高。我的经验值是这样中文技术文档、手册、制度类块大小在 800 到 1200 字符之间比较合适重叠设 100 到 200 字符保证跨块边界的句子不至于完全丢失上下文。FAQ、工单这种每条本身就短的材料块可以更小甚至按问答对切。合同、法规这种强结构文档最好按条款编号切让每个块天然对齐一个语义单元。切完之后有个快速验证方法随便提三个你心里有答案的问题看检索出来的片段里是不是包含答案所在的那一段。如果片段总是差一点就是切分粒度不对调参数重来。这个验证花不了五分钟比后面反复怀疑模型有用得多。4.3 向量库选型与重建成本AnythingLLM 内置支持好几种向量库默认用轻量的嵌入式方案个人和小团队场景完全够用零额外运维。企业场景如果要处理几十万级片段可以考虑换成独立的向量数据库服务但在那之前先想清楚你真的需要吗我见过文档总量不到两千份就上重型向量库的纯属给自己增加运维负担。比选型更重要的是建立向量库可重建的意识。向量库是从原始文档派生的产物不是主数据。任何时候都应该保证原始文档有一份完整归档配置参数切分大小、embedding 模型、向量库类型有记录那么向量库随时可以删掉重建。我在实际项目里会把这些参数写在一个 README 里放在文档目录旁边换人的时候能直接接上。5. 效果调优检索不到与答非所问的排查链路这套东西跑起来之后最难的不是部署是同事跑来说它答得不对时你怎么办。这句话背后至少对应四种完全不同的故障不分开排查就只能瞎调参数。我一般按下面这条链路往下走。5.1 先分清是没检索到还是检索到了不会答第一步永远是看检索片段而不是看答案。AnythingLLM 的回复里可以展开查看引用了哪些文档片段这一步能直接把问题二分现象判断方向引用的片段里没有答案检索问题切分、embedding、TopK、相似度阈值引用的片段里有答案但回答错了生成问题提示词、模型能力、上下文长度引用为空或极少入库问题文档没嵌入、解析失败、向量库为空引用正确但答不知道提示词问题系统提示词过于保守或过于严格这个二分动作能省掉大量时间。我曾经花了半天调提示词最后发现是那份关键文档压根没嵌入成功因为它的文件格式解析器不支持。5.2 相似度阈值与 TopK 的实测调整TopK 指的是每次检索返回多少个片段。设太小答案分散在多个片段里就会漏设太大无关片段混进来会干扰模型也更容易触发上下文截断。默认值一般在 4 左右我通常调到 5 到 8 之间做对比测试。相似度阈值是另一道闸门低于阈值的结果会被直接丢弃。阈值设太高容易一个都不返回模型只能说资料里没有设太低什么垃圾片段都往里塞。这个参数没有通用值因为不同 embedding 模型的分数分布完全不同必须在自己数据上实测。方法是拿十个你确定知识库里有答案的问题观察命中片段的分数分布把阈值定在明显相关和明显无关之间那个位置。这里有个实操技巧用具体名词提问来校准用抽象概念提问来验证。因为具体名词的检索最容易命中抽象概念最难命中两种都能过才说明参数合理。5.3 提示词模板与引用溯源生成环节最常见的病是幻觉——材料里没有模型自己编。解决办法主要靠系统提示词约束核心是三句话只根据提供的参考资料回答参考资料中没有的内容明确说不知道回答时标注引用的文档名称。AnythingLLM 的系统提示词是可以在工作区级别自定义的我一般会加上一条如果参考资料之间相互矛盾把矛盾点列出来而不是自己选一个。这条在处理多版本手册共存的知识库时特别有用能避免模型拿旧版参数回答新版问题。引用溯源这个功能强烈建议开着。它不只是给用户看个出处更重要的是给你排查问题提供了抓手——用户说答错了你点开引用就知道是检索错了还是模型读错了责任划分清清楚楚。没有引用的话所有问题都会变成我觉得它答得不对这种无法复现的反馈。6. 企业场景的权限、审计与内网加固个人用和团队用是两码事。个人场景下能跑就行团队场景下要考虑谁能看哪些文档、出了问题怎么追溯、服务怎么保证不中断。这一节讲的是那套标题里安全可靠四个字真正的落点。6.1 多用户与工作区隔离AnythingLLM 支持多用户但它的权限模型相对简单主要是按角色分管理员和普通用户。真正做隔离要靠工作区把不同部门、不同密级的资料分到不同工作区然后只给对应的人开权限。这里有个现实限制要提前说明这套组合的工作区隔离是应用层的不是存储层的。也就是说所有向量数据都在同一个数据库文件里管理员账号能看到全部。如果你的场景要求连管理员也不能看某个部门的资料那这套组合做不到需要上更重的方案比如按部门拆成多套独立部署各自独立的存储卷和端口。对大多数中小企业来说应用层隔离已经够用了。关键是把管理员账号只给一两个人这条规矩立住别图省事所有人共用一个账号那样审计日志等于没有。6.2 反向代理下的鉴权与会话把服务直接暴露在内网 IP 加端口上时间长了必然出现谁都能访问的局面因为链接一旦在群里传开就收不回来了。正式一点的做法是在前面加一层反向代理统一做 TLS、访问控制和日志。代理层配置有几个坑长连接超时模型推理可能耗时几十秒默认 60 秒的代理超时会让请求提前断开表现为问了没反应刷新后历史里也没有。把读超时调到 300 秒以上。流式输出被缓冲如果代理开了响应缓冲打字机效果会消失用户盯着空白页面等半天然后一次性弹出全部内容。需要关闭代理对响应的缓冲。上传大小限制批量导入文档时单次请求体积可能很大默认的 1MB 限制会直接 413。按需调大。登录态与会话如果代理做了统一认证要确认转发时保留了必要的头部信息否则会出现登录后反复跳回登录页的情况。我个人偏向的做法是只在公司内网开放通过内网 DNS 给一个易记的域名前面挂代理做 TLS然后用代理的访问日志作为最基础的使用审计。不追求复杂的单点登录集成够用就好。6.3 备份与模型/向量库版本管理这套系统里有三份东西需要备份重要程度排序是原始文档、应用数据目录、模型权重。原始文档是主数据必须完整归档我一般用同步盘或者版本库管理。应用数据目录里装着账号、配置、对话历史和向量库直接打包备份即可但要注意备份时容器最好处于停止状态或者用支持一致性的快照避免拷到写了一半的数据库文件。模型权重其实不用备份重新拉一遍就行记下用了哪个模型和哪个量化标签更重要。版本管理这块我要多说一句把用了哪个模型、哪个 embedding、什么切分参数当成配置项记录下来。升级模型是很常见的需求但升级之后如果效果变差你需要能快速回退。如果没记录清楚回退都无从下手。我的做法是在文档目录里放一个config.md每次改参数就记一行带上日期简单但极其有效。另外提醒一下升级 AnythingLLM 镜像版本前先备份存储目录也留意一下 changelog 里有没有涉及向量库结构变更的说明。这类升级偶尔会触发向量库迁移虽然大多数时候是自动的但万一失败你得有备份可以回。7. 几个反直觉的实测结论写完上面这些还有几条经验是没法归到具体章节里、但我觉得比配置参数更值钱的单独拎出来说一下。**第一模型不是越大越好先解决检索再谈模型。**我见过太多人花几天时间折腾怎么在有限显存里塞进更大的模型结果检索出来的片段就是错的换什么模型都答不对。资源有限的时候优先级应该是先把切分和 embedding 调好再上更大的生成模型。前者的投入产出比远高于后者。**第二知识库不是一次性工程是需要持续养护的。**手册会改版、制度会更新、工单会累积。我建议给知识库定个节奏比如每月检查一次失效文档、把过期版本移出工作区。放任不管的结果是向量库里新旧版本共存模型经常拿旧参数回答新问题而用户完全不知道。**第三给非技术同事准备一份怎么问的说明比调十个参数有用。**这套系统的表现高度依赖提问方式。带具体名词、具体型号、具体条款编号的问题检索命中率远高于这个产品怎么样这种模糊表述。我一般会在界面首页放一段简短的提问示例效果立竿见影。**第四留一个人能看懂整条链路。**这不是技术问题而是组织问题。这套东西的每个环节都能独立出故障如果团队里没人能说清文档从上传到变成答案经过了哪几步那每次出问题都只能重启试试。哪怕只是画一张图贴在文档里标清楚每一步用的是什么组件什么参数维护成本都会降一大截。最后分享一个小技巧部署完成之后先别急着灌全量文档。挑二十份最有代表性的、你最熟悉内容的文档先入库然后自己出二十道题涵盖能直接找到答案需要跨文档综合文档里根本没有答案三种类型把准确率记下来作为基线。这份基线在你后面调任何参数、换任何模型的时候都是唯一的判断依据。没有基线的话所有调优都是凭感觉改好改坏自己也不知道。 
长河君 · 2026/10/26 11:37:47 · 阅读 1.2k Ollama+AnythingLLM+Open WebUI本地知识库部署与调优
上个月帮一个做工业设备的团队收拾他们那套本地知识库起因特别朴素售前把三百多页的产品手册、两百多条历史工单和一堆内部报价规则直接丢进公有云对话框里问被合规那边看到截图当场叫停。他们的诉求其实很典型——既要大模型那种问一句话就能翻出答案的体验又不能把资料传到任何外部服务上去。折腾了两周最后落地的就是 Ollama Open WebUI AnythingLLM 这套组合Ollama 在本地跑模型AnythingLLM 负责把文档切成片、向量化、检索Open WebUI 给不熟悉命令行的同事当一个统一入口。这套组合在技术圈被讲了很多遍但大部分教程停留在跑起来了这一层真正让人头疼的问题全在后面模型答非所问、文档明明上传了却检索不到、同事第一次登录就报连接超时、跑了一周发现向量库和模型版本对不上要全部重建。这篇就把我踩过的这些坑顺着链路捋一遍从职责划分、硬件选型、容器部署、文档入库一直讲到效果调优和内网加固。如果你正准备给自己或团队搭一套不外传的知识库或者已经搭了一半卡在效果上下面这些内容应该能省你不少时间。1. 三个组件各管一段先把职责边界划清楚大多数教程上来就贴 docker run结果新手跑完一脸懵我到底该在哪个界面里传文档为什么 Open WebUI 里也能传文件AnythingLLM 里也能传文件两个都传一遍吗这个困惑的根源是没搞清楚三个组件在数据流里分别站在哪个位置。先把这张地图画清楚后面的所有配置决策都会变得有据可依。1.1 Ollama 在链路里到底承担什么Ollama 的角色非常单纯它是一个本地模型运行时对外暴露一套兼容的 HTTP 接口负责加载权重、管理显存、执行推理。它不懂文档、不懂切分、不懂向量你给它一段提示词它还你一段补全仅此而已。把它理解成本地版的模型 API 网关最准确——它同时也管模型的下载、版本标签、卸载和并发调度。这个定位带来一个很重要的实践结论Ollama 是整个链路里唯一吃显存的组件也是唯一需要认真做资源隔离的组件。AnythingLLM 的检索、切分、向量化如果不走 Ollama 的 embedding 接口几乎不占显存Open WebUI 更是个纯前端加一层转发。所以硬件预算应该几乎全部倾斜给 Ollama 所在的机器其他两个组件塞在同一台机器的普通内存里就行。我见过有人在三台机器上分别部署三个组件结果 Ollama 那台的显卡闲着另外两台反而因为跨机调用产生了额外的网络延迟和排错成本。除非你有明确的隔离要求单机 Docker Compose 编排是最省心的方案容器之间走一个自定义 bridge 网络用服务名互访比记 IP 靠谱得多。另外要提前想清楚的是 Ollama 的模型存储路径。默认它在用户目录下的.ollama里容器化部署时如果不做卷映射容器一删模型全没几十个 G 重新拉一遍能耗掉半天。我一般的做法是单独挂一块盘到./ollama然后通过OLLAMA_MODELS指过去这样迁移机器的时候整个目录打包带走即可。1.2 AnythingLLM 不是聊天壳子它管的是文档到答案的那段管道很多人第一次打开 AnythingLLM 会觉得它就是个套壳聊天界面这个印象会让你低估它的价值也会让你在调优时找错方向。它真正干的事情是 RAG 的全流程文档解析、文本切分、调用 embedding 模型生成向量、写入向量库、收到问题后做相似度检索、把检索到的片段拼进提示词再交给模型。这条管道上任何一个环节出问题表现出来都是同一句话——它答得不对。AnythingLLM 里有个概念叫工作区Workspace这是它设计上最值得称道的地方。每个工作区有自己的文档集合、自己的系统提示词、自己的对话历史。你可以给产品手册建一个工作区给售后工单建一个给内部制度再建一个互不干扰。企业场景下这一点非常关键因为把报价规则和公开产品手册混在一个向量空间里检索很容易让模型把不该说的内部价格说出来。还有一个容易被忽略的开关文档上传后有两种状态一种是已嵌入Move to Workspace一种是仅存储Save and Embed 之外的归档状态。只有嵌入过的文档才会参与检索。我见过不止一个人把文件拖进去就直接开问然后抱怨检索不到实际上是文件还躺在存储区没进向量库。这个交互设计确实有点反直觉第一次用务必确认文档列表里那个向量图标是点亮的。1.3 Open WebUI 的定位管理台还是第二套前端Open WebUI 的定位需要根据你的团队情况来定这也是我认为最容易被教程带偏的一点。它自带一套相当完整的对话界面、模型切换、多用户管理、对话历史功能上其实和 AnythingLLM 的聊天界面有重叠。如果两个都开着让同事用必然出现我在 A 界面问的和 B 界面答的不一样这种混乱。我的建议是二选一让另一个退回到它最擅长的位置。有两种典型组合组合方式前端入口适用场景代价Open WebUI 做主入口同事只用 3000 端口需要多用户、模型自由切换、对话归档AnythingLLM 只当后台知识库通过 API 调用AnythingLLM 做主入口同事只用 3001 端口以文档问答为绝对核心不需要切模型放弃 Open WebUI 的多用户和模型管理能力两个都开但分人群技术用 Open WebUI业务用 AnythingLLM团队里既有折腾模型的也有只用文档的运维两套权限要分别配我个人更倾向第一种。Open WebUI 的多用户体系、登录鉴权、对话分享做得更成熟适合直接推给非技术同事AnythingLLM 退居后台通过它提供的接口被调用或者干脆只让知识库维护人员进去管文档。这样前端只有一个入口培训成本最低出了问题排查路径也唯一。顺带说一句Open WebUI 自己也有文档上传和 RAG 功能但它对切分参数、向量库的控制粒度比 AnythingLLM 粗不少。如果你的文档结构简单、量不大用 Open WebUI 内置的就够了一旦涉及几百份异构文档、需要精细控制切分和检索阈值还是把 RAG 这层交给 AnythingLLM 更稳。2. 硬件与模型选型显存、量化、上下文三者互相拉扯选型这件事没有标准答案但有一个必须遵守的原则先算显存再定模型最后调上下文。顺序反了就会陷入模型跑起来了但一提问就 OOM的死循环。下面这些数字是我在不同机器上反复试出来的经验值可以当估算起点。2.1 显存估算的实际算法权重占用很好算参数量乘以每个参数的字节数。常见的 4-bit 量化Q4_K_M实际约 4.5 bit 每参数折算下来是 0.56 字节左右再加一点点额外开销。所以 7B 模型大约 4~5 GB14B 大约 9~10 GB32B 大约 19~21 GB。这只是权重。真正让显存爆掉的是 KV Cache它随上下文长度线性增长。粗略的经验公式是每 1K 上下文7B 模型约占 0.12~0.15 GB14B 约占 0.25 GB32B 约占 0.5 GB。也就是说一个 14B 模型开 8K 上下文权重 10 GB 加上 KV Cache 约 2 GB实际要准备 13 GB 左右才安全。把这个账算到具体配置上显卡显存可流畅运行的模型建议上下文备注8 GB7B Q44K只够轻量问答文档一多就吃力12 GB7B Q5 / 14B Q4紧4K~8K14B 需要限制并发16 GB14B Q48K个人知识库的甜点配置24 GB14B Q5 / 32B Q4紧8K~16K32B 效果明显更好但余量小48 GB 及以上32B Q5 / 70B Q416K~32K企业多用户场景没有独立显卡也别急着放弃。7B Q4 在普通桌面 CPU 上跑大概 3~6 token/s问一句话等十几秒作为个人查阅工具是可以接受的。但要注意 AnythingLLM 做检索时会先调 embedding 模型如果 embedding 也在同一台 CPU 上跑首次入库几百份文档可能要等很久建议放在夜间批量处理。2.2 中文知识库场景下的模型梯队知识库问答对模型的要求和聊天不一样它更看重三件事指令遵循能不能老老实实只根据给定材料回答、中文长文本理解、以及拒答能力材料里没有就说没有而不是编。参数量在这三件事上的边际收益非常明显我的实测感受是 7B 到 14B 的提升远大于 14B 到 32B但从 7B 直接跳到 32B 又是质变。企业场景里我一般推荐 14B 级别的中文优化模型作为主力32B 作为效果上限的备选。7B 更适合做文档摘要字段抽取这类结构化任务放到开放式问答上容易自信地胡说。还有一个常被忽略的点是模型的上下文窗口和 Ollama 实际分配的不一定一致——有些模型标称 128K但 Ollama 默认只给 2K 或 4K 的num_ctx你必须显式在 Modelfile 或请求参数里调大否则 AnythingLLM 塞进去的几个检索片段会被静默截断模型只看到最后一段答案自然驴唇不对马嘴。这一点我踩过实实在在的坑某次排查一个回答总是漏掉关键条款的问题查了两天检索日志都正常最后发现是num_ctx设的 2048而 AnythingLLM 每次塞进去的上下文有 3000 多 token前面检索到的内容全被截掉了。改完参数立刻正常。2.3 embedding 模型选错后面全白搭embedding 模型是整条管道里最不起眼但影响最大的一个环节。它负责把文本变成向量向量质量直接决定检索能不能找对片段。生成模型再强检索环节捞回来的是无关内容答案也不可能对。中文场景下我优先选多语言能力强的 embedding 模型维度一般在 768 到 1024 之间。维度高不代表好它只影响存储和计算开销效果还是看训练语料。选型时有个铁律同一个知识库里入库和查询必须用同一个 embedding 模型。我见过有人入库时用一个模型后来换了模型只改了查询配置结果向量空间对不上检索出来的东西完全是随机的。换 embedding 模型的代价是必须重建整个向量库没有捷径。所以在正式往里灌文档之前先用二三十份代表性文档做个小规模验证确认检索效果满意了再全量导入。这个前置动作能省掉后面几个小时的重复劳动。另外 embedding 模型对硬件要求很低几百 MB 的模型在 CPU 上跑就够快没必要和生成模型抢显存。可以在 AnythingLLM 里把 embedding 指向一个独立的 Ollama 实例或者直接用内置的本地 embedding把显存全留给生成模型。3. 部署落地Docker 网络与端口是最先翻车的地方三个组件单独跑都不难难在让它们互相看见。90% 的连接失败报错都跟容器网络、监听地址、端口映射这三件事有关。下面这份 Compose 编排是我用了很多次的基础版本可以直接拿去改。3.1 Ollama 的监听地址与跨容器访问Ollama 默认只监听127.0.0.1:11434这个默认值在裸机上是安全考虑但在容器里就是灾难——容器内的 127.0.0.1 只指向容器自己别的容器根本连不进来。必须显式改成0.0.0.0。services: ollama: image: ollama/ollama:latest container_name: ollama ports: - 11434:11434 volumes: - ./ollama:/root/.ollama environment: - OLLAMA_HOST0.0.0.0 - OLLAMA_KEEP_ALIVE30m - OLLAMA_NUM_PARALLEL2 - OLLAMA_MAX_LOADED_MODELS1 restart: unless-stopped networks: - kb-net几个参数值得单独解释。OLLAMA_KEEP_ALIVE控制模型在空闲多久后从显存卸载默认只有 5 分钟意味着同事每隔几分钟问一次模型就要重新加载一遍第一次响应会慢到十几秒。设成 30 分钟或更长体验会好很多代价是显存一直被占着。OLLAMA_NUM_PARALLEL是并发请求数设太大会让每个请求分到的上下文变小反而降低单次回答质量两个人以内用就设 1 或 2团队用再往上加。OLLAMA_MAX_LOADED_MODELS在多模型切换场景下可以设 2但要注意显存够不够同时装下两个。还有个隐蔽的坑如果你的宿主机本身已经装了 Ollama 并占用了 11434 端口容器映射会直接失败。部署前先用ss -lntp | grep 11434确认一下端口空闲。3.2 AnythingLLM 的环境变量与工作区创建AnythingLLM 的容器化部署有两个关键点一是存储目录必须挂出来二是模型配置可以在环境变量里预置也可以在首次启动的引导界面里填。我的经验是环境变量只配最基础的连接信息模型和工作区相关的配置全部在界面里做。原因是环境变量的变量名在不同版本之间改过好几次照着旧教程抄很容易配了个不生效的参数还查不出来。anythingllm: image: mintplexlabs/anythingllm:latest container_name: anythingllm ports: - 3001:3001 volumes: - ./anythingllm:/app/server/storage environment: - STORAGE_DIR/app/server/storage - LLM_PROVIDERollama - OLLAMA_BASE_PATHhttp://ollama:11434 - EMBEDDING_ENGINEollama cap_add: - SYS_ADMIN restart: unless-stopped networks: - kb-net注意OLLAMA_BASE_PATH这里填的是http://ollama:11434用的是 Compose 里的服务名而不是 localhost。这就是自定义网络的价值——容器之间可以直接用服务名解析。如果你没用 Compose 而是单独docker run那就得用--network指定同一个网络或者退而求其次用宿主机的内网 IP。cap_add: SYS_ADMIN这一行是为了让容器内的文档解析组件能正常工作部分镜像版本在做 PDF 转文本时需要它。不加的话可能出现上传成功但解析出空内容的诡异现象。启动后进 3001 端口第一件事是在设置里确认 LLM 和 Embedding 两个 provider 都选到了 Ollama并且点一下测试连接。测试通过再去创建你的第一个工作区。工作区名字建议带业务含义比如产品手册-2024后续文档一多你会感谢自己。3.3 Open WebUI 接入 Ollama 的两种方式Open WebUI 接 Ollama 有两个路径区别在于它是不是和 Ollama 在同一个容器网络里。open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui ports: - 3000:8080 volumes: - ./open-webui:/app/backend/data environment: - OLLAMA_BASE_URLhttp://ollama:11434 - WEBUI_AUTHtrue - DEFAULT_MODELSqwen2.5:14b-instruct-q4_K_M restart: unless-stopped networks: - kb-net这里有一个版本差异必须提醒较早的版本用单数的OLLAMA_BASE_URL新版本改成了复数的OLLAMA_BASE_URLS多个地址之间用分号分隔。变量名用错了不会报错只会表现为模型列表空空如也。判断方法很简单进界面后看设置里的连接页面如果一个模型都列不出来先去核对容器日志里读到的环境变量名。WEBUI_AUTHtrue是默认值但我要强调一下别关它。这是在公网或者公司内网暴露服务时最基本的一道门槛关掉意味着任何能访问到 3000 端口的人都能直接使用你的模型和对话历史。还有一点Open WebUI 的数据卷./open-webui里存着用户账号、对话记录、配置这个目录的备份优先级和向量库一样高。我一般把这两个目录一起放进定时快照任务里。4. 文档入库切分策略决定检索质量的上限前面三步都是把管道搭起来从这一步开始才真正决定这套东西好不好用。RAG 领域有句话我认为非常准确检索质量的上限由切分决定生成质量的上限由模型决定。检索没找对模型再强也是巧妇难为无米之炊。4.1 解析层PDF、扫描件、表格各自的处理方式文档解析是所有环节里最容易被低估的一步。很多人的第一反应是PDF 拖进去不就行了但 PDF 本质上是排版格式而不是文本格式解析出来的东西质量差别巨大。电子版 PDF可直接选中文字解析通常没问题但要注意多栏排版的文档解析器可能把左右两栏的文字交错拼接读起来是断句的。这类文档入库前最好转成纯文本或 Markdown 检查一遍。扫描版 PDF图片型解析出来是空的或者全是乱码必须走 OCR。这是最常见的翻车点判断方法是拿解析结果搜一个你确定文档里有的词搜不到就是没解析出来。Word 和 Markdown解析质量最好结构化信息保留得完整如果原始资料有这两种格式优先用它们。Excel 表格这一类的处理最麻烦因为表格的行列关系在纯文本里会丢失。我的做法是把每一行拼成一句自然语言再入库比如把型号、功率、价格三列拼成型号 X 的功率是 Y价格是 Z检索命中率会高很多。图片和图片型表格除非用多模态模型否则建议人工转写或干脆不入库。解析质量不达标后面调多少参数都救不回来。我通常会在入库前抽 5 份文档看一眼 AnythingLLM 里显示的解析文本确认没有大面积乱码和错位再批量导入。4.2 切分粒度与重叠的取舍切分参数里最重要的是块大小chunk size和重叠overlap。默认值通常偏小对中文文档不一定合适。块太小的后果是语义被切断比如一个条款的条件和结论被分到两个块里检索到条件那半句模型看到的是半截话答案就会缺一半。块太大的后果是检索精度下降一个块里塞了三四个不同主题向量被平均掉了跟任何一个具体问题的相似度都不高。我的经验值是这样中文技术文档、手册、制度类块大小在 800 到 1200 字符之间比较合适重叠设 100 到 200 字符保证跨块边界的句子不至于完全丢失上下文。FAQ、工单这种每条本身就短的材料块可以更小甚至按问答对切。合同、法规这种强结构文档最好按条款编号切让每个块天然对齐一个语义单元。切完之后有个快速验证方法随便提三个你心里有答案的问题看检索出来的片段里是不是包含答案所在的那一段。如果片段总是差一点就是切分粒度不对调参数重来。这个验证花不了五分钟比后面反复怀疑模型有用得多。4.3 向量库选型与重建成本AnythingLLM 内置支持好几种向量库默认用轻量的嵌入式方案个人和小团队场景完全够用零额外运维。企业场景如果要处理几十万级片段可以考虑换成独立的向量数据库服务但在那之前先想清楚你真的需要吗我见过文档总量不到两千份就上重型向量库的纯属给自己增加运维负担。比选型更重要的是建立向量库可重建的意识。向量库是从原始文档派生的产物不是主数据。任何时候都应该保证原始文档有一份完整归档配置参数切分大小、embedding 模型、向量库类型有记录那么向量库随时可以删掉重建。我在实际项目里会把这些参数写在一个 README 里放在文档目录旁边换人的时候能直接接上。5. 效果调优检索不到与答非所问的排查链路这套东西跑起来之后最难的不是部署是同事跑来说它答得不对时你怎么办。这句话背后至少对应四种完全不同的故障不分开排查就只能瞎调参数。我一般按下面这条链路往下走。5.1 先分清是没检索到还是检索到了不会答第一步永远是看检索片段而不是看答案。AnythingLLM 的回复里可以展开查看引用了哪些文档片段这一步能直接把问题二分现象判断方向引用的片段里没有答案检索问题切分、embedding、TopK、相似度阈值引用的片段里有答案但回答错了生成问题提示词、模型能力、上下文长度引用为空或极少入库问题文档没嵌入、解析失败、向量库为空引用正确但答不知道提示词问题系统提示词过于保守或过于严格这个二分动作能省掉大量时间。我曾经花了半天调提示词最后发现是那份关键文档压根没嵌入成功因为它的文件格式解析器不支持。5.2 相似度阈值与 TopK 的实测调整TopK 指的是每次检索返回多少个片段。设太小答案分散在多个片段里就会漏设太大无关片段混进来会干扰模型也更容易触发上下文截断。默认值一般在 4 左右我通常调到 5 到 8 之间做对比测试。相似度阈值是另一道闸门低于阈值的结果会被直接丢弃。阈值设太高容易一个都不返回模型只能说资料里没有设太低什么垃圾片段都往里塞。这个参数没有通用值因为不同 embedding 模型的分数分布完全不同必须在自己数据上实测。方法是拿十个你确定知识库里有答案的问题观察命中片段的分数分布把阈值定在明显相关和明显无关之间那个位置。这里有个实操技巧用具体名词提问来校准用抽象概念提问来验证。因为具体名词的检索最容易命中抽象概念最难命中两种都能过才说明参数合理。5.3 提示词模板与引用溯源生成环节最常见的病是幻觉——材料里没有模型自己编。解决办法主要靠系统提示词约束核心是三句话只根据提供的参考资料回答参考资料中没有的内容明确说不知道回答时标注引用的文档名称。AnythingLLM 的系统提示词是可以在工作区级别自定义的我一般会加上一条如果参考资料之间相互矛盾把矛盾点列出来而不是自己选一个。这条在处理多版本手册共存的知识库时特别有用能避免模型拿旧版参数回答新版问题。引用溯源这个功能强烈建议开着。它不只是给用户看个出处更重要的是给你排查问题提供了抓手——用户说答错了你点开引用就知道是检索错了还是模型读错了责任划分清清楚楚。没有引用的话所有问题都会变成我觉得它答得不对这种无法复现的反馈。6. 企业场景的权限、审计与内网加固个人用和团队用是两码事。个人场景下能跑就行团队场景下要考虑谁能看哪些文档、出了问题怎么追溯、服务怎么保证不中断。这一节讲的是那套标题里安全可靠四个字真正的落点。6.1 多用户与工作区隔离AnythingLLM 支持多用户但它的权限模型相对简单主要是按角色分管理员和普通用户。真正做隔离要靠工作区把不同部门、不同密级的资料分到不同工作区然后只给对应的人开权限。这里有个现实限制要提前说明这套组合的工作区隔离是应用层的不是存储层的。也就是说所有向量数据都在同一个数据库文件里管理员账号能看到全部。如果你的场景要求连管理员也不能看某个部门的资料那这套组合做不到需要上更重的方案比如按部门拆成多套独立部署各自独立的存储卷和端口。对大多数中小企业来说应用层隔离已经够用了。关键是把管理员账号只给一两个人这条规矩立住别图省事所有人共用一个账号那样审计日志等于没有。6.2 反向代理下的鉴权与会话把服务直接暴露在内网 IP 加端口上时间长了必然出现谁都能访问的局面因为链接一旦在群里传开就收不回来了。正式一点的做法是在前面加一层反向代理统一做 TLS、访问控制和日志。代理层配置有几个坑长连接超时模型推理可能耗时几十秒默认 60 秒的代理超时会让请求提前断开表现为问了没反应刷新后历史里也没有。把读超时调到 300 秒以上。流式输出被缓冲如果代理开了响应缓冲打字机效果会消失用户盯着空白页面等半天然后一次性弹出全部内容。需要关闭代理对响应的缓冲。上传大小限制批量导入文档时单次请求体积可能很大默认的 1MB 限制会直接 413。按需调大。登录态与会话如果代理做了统一认证要确认转发时保留了必要的头部信息否则会出现登录后反复跳回登录页的情况。我个人偏向的做法是只在公司内网开放通过内网 DNS 给一个易记的域名前面挂代理做 TLS然后用代理的访问日志作为最基础的使用审计。不追求复杂的单点登录集成够用就好。6.3 备份与模型/向量库版本管理这套系统里有三份东西需要备份重要程度排序是原始文档、应用数据目录、模型权重。原始文档是主数据必须完整归档我一般用同步盘或者版本库管理。应用数据目录里装着账号、配置、对话历史和向量库直接打包备份即可但要注意备份时容器最好处于停止状态或者用支持一致性的快照避免拷到写了一半的数据库文件。模型权重其实不用备份重新拉一遍就行记下用了哪个模型和哪个量化标签更重要。版本管理这块我要多说一句把用了哪个模型、哪个 embedding、什么切分参数当成配置项记录下来。升级模型是很常见的需求但升级之后如果效果变差你需要能快速回退。如果没记录清楚回退都无从下手。我的做法是在文档目录里放一个config.md每次改参数就记一行带上日期简单但极其有效。另外提醒一下升级 AnythingLLM 镜像版本前先备份存储目录也留意一下 changelog 里有没有涉及向量库结构变更的说明。这类升级偶尔会触发向量库迁移虽然大多数时候是自动的但万一失败你得有备份可以回。7. 几个反直觉的实测结论写完上面这些还有几条经验是没法归到具体章节里、但我觉得比配置参数更值钱的单独拎出来说一下。**第一模型不是越大越好先解决检索再谈模型。**我见过太多人花几天时间折腾怎么在有限显存里塞进更大的模型结果检索出来的片段就是错的换什么模型都答不对。资源有限的时候优先级应该是先把切分和 embedding 调好再上更大的生成模型。前者的投入产出比远高于后者。**第二知识库不是一次性工程是需要持续养护的。**手册会改版、制度会更新、工单会累积。我建议给知识库定个节奏比如每月检查一次失效文档、把过期版本移出工作区。放任不管的结果是向量库里新旧版本共存模型经常拿旧参数回答新问题而用户完全不知道。**第三给非技术同事准备一份怎么问的说明比调十个参数有用。**这套系统的表现高度依赖提问方式。带具体名词、具体型号、具体条款编号的问题检索命中率远高于这个产品怎么样这种模糊表述。我一般会在界面首页放一段简短的提问示例效果立竿见影。**第四留一个人能看懂整条链路。**这不是技术问题而是组织问题。这套东西的每个环节都能独立出故障如果团队里没人能说清文档从上传到变成答案经过了哪几步那每次出问题都只能重启试试。哪怕只是画一张图贴在文档里标清楚每一步用的是什么组件什么参数维护成本都会降一大截。最后分享一个小技巧部署完成之后先别急着灌全量文档。挑二十份最有代表性的、你最熟悉内容的文档先入库然后自己出二十道题涵盖能直接找到答案需要跨文档综合文档里根本没有答案三种类型把准确率记下来作为基线。这份基线在你后面调任何参数、换任何模型的时候都是唯一的判断依据。没有基线的话所有调优都是凭感觉改好改坏自己也不知道。