Open WebUI 本地知识库完整指南3 分钟把文档变成会回答问题的检索源【免费下载链接】open-webuiUser-friendly AI Interface (Supports Ollama, OpenAI API, ...)项目地址: https://gitcode.com/GitHub_Trending/op/open-webui假设这样一个场景团队的技术文档散落在几十个 PDF 和 Markdown 文件里有人问部署时向量数据库配在哪一步你翻了二十分钟也没找到确切位置。Open WebUI 的知识库功能就是为这种时刻准备的——把本地文档喂给它它自己切块、向量化之后你在聊天框里直接提问答案连同出处一起返回全程数据不出本机。它能帮你干什么离线问答文档解析、向量存储、检索全部跑在本地敏感内容不经过任何云端服务多格式吃进文本、Markdown、PDF 等常见格式由统一的加载器层处理不用自己写解析脚本按人按组放权限同一个知识库可以给开发组只读、管理员可写不用复制文件批量吞吐一次丢进几十个文件自动排队处理失败的单独立项报出来可挂到任意模型上知识库与模型解耦换 LLM 不换语料从零到第一个答案四步走完第 1 步把服务跑起来需要 clone 仓库的话地址是 https://gitcode.com/GitHub_Trending/op/open-webui 。本地开发可以直接用backend/start.sh拉起后端生产部署看仓库根目录的Dockerfile与docker-compose.yaml。第 2 步建一个空知识库进入知识库管理页点创建或直接调POST /knowledge/create。系统会生成唯一 ID并在向量库里建一个以该 ID 命名的集合——后面所有文档都进这个集合。模型定义在 backend/open_webui/models/knowledge.pyID、名称、描述、时间戳都是标准字段。第 3 步把文档灌进去两种方式单文件POST /knowledge/{id}/file/add批量POST /knowledge/{id}/files/batch/add一次提交多个file_id逐个做权限校验处理失败的会带错误明细返回不会阻塞整批入口逻辑集中在 backend/open_webui/routers/knowledge.py文件本身先经backend/open_webui/routers/files.py接收并存元数据再交给处理管线。第 4 步在聊天里提问聊天界面关联该知识库后发送问题。检索走POST /retrieval/query/collection后端从对应集合取回相关片段拼进上下文再由 LLM 生成回答。正常情况下从提问到片段返回在 300ms 内。为什么快、为什么准一份文档进来管线是固定的四段文件上传 → 加载器提取文本 → 滑动窗口分块 → 嵌入向量入库提取backend/open_webui/retrieval/loaders/ 按格式分发到不同加载器PDF、网页、YouTube 等各有对应实现分块按滑动窗口切成语义完整的片段块太大稀释相关性太小丢上下文技术类文档 200–300 字是稳妥区间向量化调用配置的嵌入模型生成向量写入向量集合底层客户端在 backend/open_webui/retrieval/vector/Chroma、Milvus、Elasticsearch、Qdrant 等可切换检索这是准的关键。backend/open_webui/routers/retrieval.py 里的/query/collection默认走混合检索——BM25 关键词匹配和语义相似度加权合并权重由HYBRID_BM25_WEIGHT控制再按相关度阈值RELEVANCE_THRESHOLD过滤可选接 reranker 做二次排序。纯语义检索容易漏掉恰好没被说出口的词混合策略就是补这个短板返回条数由k参数控制默认读TOP_K配置想要更全的答案就调大它。进阶玩法权限私有、按人、按组访问控制由AccessGrants体系管理定义在 backend/open_webui/models/access_grants.py知识库级别改在POST /knowledge/{id}/access/update。三种典型姿势私有不给任何授权仅创建者可见按人共享user_ids点名可访问的用户按组共享group_ids交给整个组人员变动不用逐个改读、写权限分开控制常见组合是全组可读、仅管理员可写。批量导入的正确姿势用POST /knowledge/{id}/files/batch/add而不是循环调单文件接口。后端会先批量查文件、统一鉴权、自动跳过已关联的文件避免重复嵌入产生脏数据最后把成功/失败分开汇报。几百个文件的目录搬家一次请求就够。与模型联动在模型配置里挂上知识库model.meta.knowledge里记录 ID 和名称该模型的所有会话都能引用这份语料也可以只在单次对话里临时关联按需取用。避坑与调优Q文档导入失败怎么办先确认格式在加载器支持范围内常见文本类和 PDF 基本都覆盖再核对单文件是否超过 50MB 默认上限仍失败就看服务端日志批量接口的报错响应里已经带具体是哪个文件、什么原因。Q检索结果不够准把问题改具体混合检索里关键词部分很吃查询措辞用POST /knowledge/{id}/reset重建知识库后重新导入清掉旧向量调大返回条数k或检查分块策略是否切得过碎Q语料过期了走POST /knowledge/{id}/reset或POST /knowledge/reindex重建索引不必删库重建。Q资源怎么配向量处理建议至少 2GB 内存文档量大时优先把压力给到检索侧混合检索 reranker而不是无脑加大分块。Q组织上怎么不乱按业务域拆库产品手册一个库、内部规范一个库命名带主题和日期每月清一次过时内容。本地文档检索这件事核心就是入库管干净、检索配对策略两步。安装与部署细节见仓库内的README.md和Makefile动手前的最后一步就是把那堆一直想整理的文档拖进去试试。【免费下载链接】open-webuiUser-friendly AI Interface (Supports Ollama, OpenAI API, ...)项目地址: https://gitcode.com/GitHub_Trending/op/open-webui创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Open WebUI 本地知识库完整指南3 分钟把文档变成会回答问题的检索源【免费下载链接】open-webuiUser-friendly AI Interface (Supports Ollama, OpenAI API, ...)项目地址: https://gitcode.com/GitHub_Trending/op/open-webui假设这样一个场景团队的技术文档散落在几十个 PDF 和 Markdown 文件里有人问部署时向量数据库配在哪一步你翻了二十分钟也没找到确切位置。Open WebUI 的知识库功能就是为这种时刻准备的——把本地文档喂给它它自己切块、向量化之后你在聊天框里直接提问答案连同出处一起返回全程数据不出本机。它能帮你干什么离线问答文档解析、向量存储、检索全部跑在本地敏感内容不经过任何云端服务多格式吃进文本、Markdown、PDF 等常见格式由统一的加载器层处理不用自己写解析脚本按人按组放权限同一个知识库可以给开发组只读、管理员可写不用复制文件批量吞吐一次丢进几十个文件自动排队处理失败的单独立项报出来可挂到任意模型上知识库与模型解耦换 LLM 不换语料从零到第一个答案四步走完第 1 步把服务跑起来需要 clone 仓库的话地址是 https://gitcode.com/GitHub_Trending/op/open-webui 。本地开发可以直接用backend/start.sh拉起后端生产部署看仓库根目录的Dockerfile与docker-compose.yaml。第 2 步建一个空知识库进入知识库管理页点创建或直接调POST /knowledge/create。系统会生成唯一 ID并在向量库里建一个以该 ID 命名的集合——后面所有文档都进这个集合。模型定义在 backend/open_webui/models/knowledge.pyID、名称、描述、时间戳都是标准字段。第 3 步把文档灌进去两种方式单文件POST /knowledge/{id}/file/add批量POST /knowledge/{id}/files/batch/add一次提交多个file_id逐个做权限校验处理失败的会带错误明细返回不会阻塞整批入口逻辑集中在 backend/open_webui/routers/knowledge.py文件本身先经backend/open_webui/routers/files.py接收并存元数据再交给处理管线。第 4 步在聊天里提问聊天界面关联该知识库后发送问题。检索走POST /retrieval/query/collection后端从对应集合取回相关片段拼进上下文再由 LLM 生成回答。正常情况下从提问到片段返回在 300ms 内。为什么快、为什么准一份文档进来管线是固定的四段文件上传 → 加载器提取文本 → 滑动窗口分块 → 嵌入向量入库提取backend/open_webui/retrieval/loaders/ 按格式分发到不同加载器PDF、网页、YouTube 等各有对应实现分块按滑动窗口切成语义完整的片段块太大稀释相关性太小丢上下文技术类文档 200–300 字是稳妥区间向量化调用配置的嵌入模型生成向量写入向量集合底层客户端在 backend/open_webui/retrieval/vector/Chroma、Milvus、Elasticsearch、Qdrant 等可切换检索这是准的关键。backend/open_webui/routers/retrieval.py 里的/query/collection默认走混合检索——BM25 关键词匹配和语义相似度加权合并权重由HYBRID_BM25_WEIGHT控制再按相关度阈值RELEVANCE_THRESHOLD过滤可选接 reranker 做二次排序。纯语义检索容易漏掉恰好没被说出口的词混合策略就是补这个短板返回条数由k参数控制默认读TOP_K配置想要更全的答案就调大它。进阶玩法权限私有、按人、按组访问控制由AccessGrants体系管理定义在 backend/open_webui/models/access_grants.py知识库级别改在POST /knowledge/{id}/access/update。三种典型姿势私有不给任何授权仅创建者可见按人共享user_ids点名可访问的用户按组共享group_ids交给整个组人员变动不用逐个改读、写权限分开控制常见组合是全组可读、仅管理员可写。批量导入的正确姿势用POST /knowledge/{id}/files/batch/add而不是循环调单文件接口。后端会先批量查文件、统一鉴权、自动跳过已关联的文件避免重复嵌入产生脏数据最后把成功/失败分开汇报。几百个文件的目录搬家一次请求就够。与模型联动在模型配置里挂上知识库model.meta.knowledge里记录 ID 和名称该模型的所有会话都能引用这份语料也可以只在单次对话里临时关联按需取用。避坑与调优Q文档导入失败怎么办先确认格式在加载器支持范围内常见文本类和 PDF 基本都覆盖再核对单文件是否超过 50MB 默认上限仍失败就看服务端日志批量接口的报错响应里已经带具体是哪个文件、什么原因。Q检索结果不够准把问题改具体混合检索里关键词部分很吃查询措辞用POST /knowledge/{id}/reset重建知识库后重新导入清掉旧向量调大返回条数k或检查分块策略是否切得过碎Q语料过期了走POST /knowledge/{id}/reset或POST /knowledge/reindex重建索引不必删库重建。Q资源怎么配向量处理建议至少 2GB 内存文档量大时优先把压力给到检索侧混合检索 reranker而不是无脑加大分块。Q组织上怎么不乱按业务域拆库产品手册一个库、内部规范一个库命名带主题和日期每月清一次过时内容。本地文档检索这件事核心就是入库管干净、检索配对策略两步。安装与部署细节见仓库内的README.md和Makefile动手前的最后一步就是把那堆一直想整理的文档拖进去试试。【免费下载链接】open-webuiUser-friendly AI Interface (Supports Ollama, OpenAI API, ...)项目地址: https://gitcode.com/GitHub_Trending/op/open-webui创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
