ollama open webui rag

本地跑模型的人常卡在同一处：模型装好了，Open WebUI 也开了，但把公司文档丢进去问，要么答非所问，要么干脆检索不到。这篇不给协议原理，只给一条能跑通的落地路径——文档怎么清洗切块、向量模型怎么选、检索参数怎么调、显存不够怎么降级、怎么验证它真的在用你的资料而不是瞎编。

本地跑模型的人常卡在同一处：模型装好了，Open WebUI 也开了，但把公司文档丢进去问，要么答非所问，要么干脆检索不到。这篇不给协议原理，只给一条能跑通的落地路径——文档怎么清洗切块、向量模型怎么选、检索参数怎么调、显存不够怎么降级、怎么验证它真的在用你的资料而不是瞎编。

先说明适用范围：下面这套做法适合个人或小团队在单机上跑，文档量在几十到几百份这个量级。如果你要服务很多人同时提问、文档量上万，跟着做能跑通，但后面得换更重的组件，别硬扛。

进料先洗：文档不干净，后面全白搭

检索质量的上限在进料这一步就定了。文档里混着页眉页脚、目录、水印文字，切出来的块本身就是噪音，后面参数再怎么调都救不回来。所以先把文档分门别类，再决定怎么处理。

• 切块按语义段落切，别按固定字数硬切；操作手册的切块粒度通常比聊天记录小，因为问题往往落在单条步骤上
• 给每块补来源字段（文件名、章节、页码），回答时能指回原文，出问题好核对是哪一块召回的
• 同一份文档更新时用同一个文件名覆盖，别留两个版本，否则检索会把旧内容也召回
• 清洗完先随机抽十块人工看一眼，比调半天参数见效快

向量模型：本地能跑起来比榜单排名重要

嵌入模型负责把文档和问题都变成向量，它和生成模型是两回事。很多人只盯着生成模型，结果嵌入模型选了个本地跑不动或者中文效果差的，检索环节直接崩。选型先看你能不能稳定跑起来，再谈效果。

1. 先跑通最小闭环拿三五份文档入库，问一个答案在文档里的问题，能答对再往上加量
2. 记录基线把当前切块方式、嵌入模型、召回块数记下来，后面每次只改一个变量
3. 换模型留后路换嵌入模型前先把原始切块数据单独存一份，重建失败还能退回去

检索参数：召回几条、怎么排序、什么时候说不确定

检索环节就三件事：召回多少块、要不要重排、提示词怎么约束。这三件事的调整顺序很重要，先动召回块数，再考虑重排，最后才改提示词。跳过前两步直接改提示词，多半是在掩盖检索没召回的问题。

• 召回块数先从小往大试，块数太少覆盖不到答案，太多会把不相关内容塞进上下文稀释注意力
• 开启重排能提升命中率，代价是多一次模型推理；文档量不大且问题简单的场景可以先不开
• 提示里明确写「只依据提供的资料回答，资料里没有就说没有」，本地小模型很容易顺着问题编
• 给回答附上来源块，方便你判断它是真读了资料还是蒙的

资源与降级：显存、内存、响应速度的取舍

资源不够是最常见的卡点。向量库个人单机规模用轻量方案就够，别为了几十份文档上分布式组件，运维成本比收益高。真正吃资源的是生成模型，跑不动时按固定顺序降级，别乱调。

整套流程不联网时，模型文件要提前拉好。嵌入模型和生成模型是两份独立的文件，少一个就跑不通。拉取命令和模型体积到站内模型资料库核对当时的数字，别凭印象估。

# 先确认本地已拉取的模型列表
ollama list
# 拉取生成模型（示例，具体名字到站内模型库查）
ollama pull <生成模型名>
# 嵌入模型同样需要单独拉取
ollama pull <嵌入模型名>

验证与维护：怎么知道它不是在瞎编

搭完不代表能用。必须有一套固定用例反复跑，否则你永远不知道某次回答变好是参数调对了还是碰巧。验证的核心指标只有一个：回答能不能指回原文。指不回的基本可以判定为幻觉。

1. 准备固定用例挑一组覆盖不同文档位置的问题，答案要能在原文里找到明确出处
2. 每次改动后重跑调整切块或参数后跑一遍全部用例，看命中率变化，不要凭单次体验下判断
3. 抽查来源随机抽几条回答，点开它引用的原文块，看是否真的回答了问题
4. 文档更新后重新入库个人规模直接全量重建更省心，增量更新的复杂度不值当

• 提示词调整只在检索确认没问题后再动，否则是在治标
• 回答指不回原文时优先查检索，不是先改提示词
• 固定用例要定期更新，文档结构变了旧用例会失效

本地知识库的可靠性不取决于模型多大，取决于你能不能证明它在读你的资料。