做本地知識庫這件事我從最初只想把幾份產(chǎn)品手冊塞進模型里問答到后來給幾個小團隊做內(nèi)部文檔檢索前后折騰了兩年多。中間換過三輪方案踩過的坑能寫滿兩頁紙。最后穩(wěn)定下來的組合就是Ollama 跑模型、Open WebUI 當(dāng)日常對話入口、AnythingLLM 管知識庫和檢索。這套組合最大的好處是全部跑在自己機器或內(nèi)網(wǎng)服務(wù)器上文件不出局域網(wǎng)模型不調(diào)用外部接口費用是一次性硬件投入后續(xù)零調(diào)用成本。它適合兩類人一類是對資料保密有要求的個人比如手上有些合同模板、技術(shù)筆記、研究草稿不想往云端傳另一類是十幾到幾十人規(guī)模的小團隊需要一套能查內(nèi)部文檔、又不愿意每年付訂閱費的問答系統(tǒng)。這篇文章我會把整套東西從選型到落地拆開講包括每個參數(shù)為什么這么設(shè)、哪里最容易翻車、以及我實測下來比較穩(wěn)的配置組合。1. 整體架構(gòu)怎么搭以及為什么這么搭1.1 三層分離模型、界面、知識層各管一段很多人一開始會想找一個“全能軟件”把模型、界面、知識庫全包了省事。我試過結(jié)論是不劃算。全能型工具往往在某一塊特別弱要么模型選擇受限要么文檔解析拉胯要么界面難用。分層之后每層都能單獨替換出問題也容易定位。我現(xiàn)在的結(jié)構(gòu)是這樣層級承擔(dān)角色具體組件替換成本模型層提供推理能力與向量化能力Ollama 服務(wù)常駐在 11434 端口低換個模型名就行界面層日常對話、多輪上下文、賬號管理Open WebUI中可換成任意兼容接口的前端知識層文檔解析、分塊、向量存儲、檢索召回AnythingLLM中數(shù)據(jù)在 storage 目錄里可遷移關(guān)鍵點在于Ollama 提供的是標準 HTTP 接口AnythingLLM 和 Open WebUI 都能直接對接它。這就意味著模型層是公共底座上面兩個應(yīng)用是平行的消費者互不干擾。我平時用 Open WebUI 做通用問答和代碼輔助用 AnythingLLM 專門查內(nèi)部文檔兩個入口分開避免把閑聊上下文和檢索上下文混在一起污染回答。還有個細節(jié)AnythingLLM 自己也能當(dāng)聊天界面用那為什么還要 Open WebUI我的理由是 Open WebUI 的多輪對話體驗、模型切換、提示詞預(yù)設(shè)更順手適合“問模型本身”的場景AnythingLLM 的強項是文檔工作區(qū)和引用溯源適合“問我的資料”的場景。硬塞進一個界面里兩邊都不舒服。1.2 不上云的真實理由數(shù)據(jù)邊界和成本賬先說數(shù)據(jù)邊界。企業(yè)文檔里最敏感的不是技術(shù)文檔是合同、報價、客戶名單、內(nèi)部復(fù)盤。這些東西一旦上傳到外部服務(wù)你就失去了對它的控制權(quán)哪怕對方承諾不訓(xùn)練審計上也過不去。本地部署的價值不在于“更安全”這種空話而在于物理隔離拔掉網(wǎng)線系統(tǒng)照樣能問答。再說成本。我?guī)鸵粋€小團隊算過賬20 人規(guī)模如果按人頭訂閱云端問答服務(wù)一年下來是四位數(shù)到五位數(shù)不等的支出而且隨著文檔量增長向量存儲還要另外計費。本地方案的成本結(jié)構(gòu)完全不同一次性硬件一臺帶 24GB 顯存的機器或者二手的同規(guī)格卡價格固定電費滿載 300W 左右按每天跑 4 小時算一年電費可以忽略軟件全部開源零授權(quán)費隱性成本你自己的時間部署加調(diào)優(yōu)大概兩三天對于長期使用的場景本地方案在 8 到 14 個月左右回本之后全是凈收益。但如果只是臨時查幾份 PDF那真沒必要折騰直接用現(xiàn)成服務(wù)更省事。選型的第一原則是匹配使用強度和保密要求而不是技術(shù)潔癖。1.3 硬件與模型的匹配測算別拍腦袋買卡這是最容易花冤枉錢的地方。模型能不能跑核心看顯存。粗略的估算方式是顯存占用 ≈ 參數(shù)量 × 每參數(shù)字節(jié)數(shù) 上下文緩存量化等級決定每參數(shù)字節(jié)數(shù)。Q4_K_M 大約 0.55 到 0.6 字節(jié)/參數(shù)Q8 大約 1 字節(jié)/參數(shù)FP16 是 2 字節(jié)/參數(shù)。實際還要加上 KV 緩存跟上下文長度和層數(shù)相關(guān)長上下文時這部分能占到幾個 GB。我整理了一張常用檔位的實測參考表單卡、Q4_K_M 量化、上下文 8K模型規(guī)模權(quán)重大小實際顯存占用機器配置建議適用場景7B / 8B約 4.5GB6 到 7GB8GB 顯存或 16GB 內(nèi)存純 CPU簡單問答、摘要速度可接受14B約 9GB11 到 12GB12GB 顯存日常主力性價比最高32B約 20GB23 到 25GB24GB 顯存復(fù)雜推理、長文檔理解70B約 40GB45GB 以上雙卡或大內(nèi)存 CPU 推理效果最好但速度慢一般不推薦純 CPU 也能跑只是速度按 token/秒 算會掉到個位數(shù)7B 在普通桌面 CPU 上大概 3 到 6 token/s讀一段回答要等半分鐘。如果只是偶爾查資料能忍如果天天用還是建議上顯卡。還有一個常被忽略的點嵌入模型也要吃資源。文檔入庫時要把每個分塊轉(zhuǎn)成向量這個過程是批量的如果嵌入模型太大首次入庫會非常慢。我的建議是嵌入模型和對話模型分開選嵌入用輕量的專用模型對話用大一點的通用模型。2. Ollama 部署與模型選型的實操細節(jié)2.1 部署前的環(huán)境檢查清單裝之前先確認幾件事能省掉后面一半的麻煩系統(tǒng)是 64 位 Linux、macOS 或 WindowsLinux 建議較新的內(nèi)核版本否則容器網(wǎng)絡(luò)會有奇怪問題磁盤至少留 50GB模型文件比想象中大一個 14B 模型加嵌入模型輕松吃掉 15GB如果用容器部署上層應(yīng)用先確認 Docker 或同類容器運行時能正常工作內(nèi)網(wǎng)服務(wù)器要確認防火墻策略后面要放行幾個端口關(guān)閉系統(tǒng)的休眠和自動更新重啟半夜重啟服務(wù)是運維事故的常見原因還有一個隱形坑模型目錄的磁盤掛載。默認模型存在用戶主目錄下如果主目錄分區(qū)很小拉到一半報磁盤滿。建議提前把模型目錄指到大容量分區(qū)用環(huán)境變量控制。2.2 安裝與模型拉取安裝走官方腳本最省事注意腳本地址從官方文檔取不要用來源不明的鏡像# 從官方渠道獲取安裝腳本并執(zhí)行 curl -fsSL 官方安裝腳本地址 | sh # 確認服務(wù)已啟動 systemctl status ollama # 檢查版本 ollama --version服務(wù)起來后默認監(jiān)聽本地 11434 端口。這里有個必須改的配置如果上層應(yīng)用跑在容器里默認只聽 127.0.0.1 會導(dǎo)致容器連不上。需要讓它監(jiān)聽所有網(wǎng)卡# 修改服務(wù)配置讓 Ollama 監(jiān)聽所有網(wǎng)卡 sudo systemctl edit ollama # 在編輯器中加入 [Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_KEEP_ALIVE30m # 重載并重啟 sudo systemctl daemon-reload sudo systemctl restart ollama三個環(huán)境變量分別解決三個問題OLLAMA_HOST讓容器能訪問OLLAMA_MODELS把模型存到大盤OLLAMA_KEEP_ALIVE讓模型在內(nèi)存里多待一會兒避免每次提問都重新加載。最后這個特別重要默認只有 5 分鐘超過就卸載下一次提問要等十幾秒加載。設(shè)成 30 分鐘之后連續(xù)使用體驗差別巨大。拉模型# 對話模型14B 級別日常夠用 ollama pull qwen2.5:14b # 小一點的備選硬件緊張時用 ollama pull llama3.1:8b # 嵌入模型專門做向量化體積小速度快 ollama pull bge-m3 # 查看已安裝模型 ollama list # 簡單驗證推理是否正常 ollama run qwen2.5:14b 用一句話說明向量檢索的原理2.3 模型檔位怎么選不是越大越好我在這上面走過最大的彎路就是迷信大模型。一開始上 32B覺得效果肯定好結(jié)果發(fā)現(xiàn)三個問題加載慢、并發(fā)差、長文檔一塞就爆上下文。后來退回 14B實際使用滿意度反而更高。我的判斷標準是這樣的使用強度推薦檔位理由個人每天幾十次問答7B 到 8B響應(yīng)快顯存占用低能同時跑嵌入模型個人主力每天上百次14B理解力和速度的平衡點中文表達也更自然團隊共用3 到 10 人14B 加并發(fā)限制單卡能撐住配合隊列避免排隊過久復(fù)雜文檔分析、代碼審查32B只在需要深度推理時切換不做常駐還有一個經(jīng)驗同一檔位下選中文語料訓(xùn)練更充分的模型。這個差別在中文問答上非常明顯英文強中文弱的模型經(jīng)常在專業(yè)術(shù)語上翻車把“向量維度”理解成幾何概念。測試方法是拿三五個你業(yè)務(wù)里的真實問題去問看回答是否貼合領(lǐng)域比看榜單有用得多。2.4 嵌入模型的單獨考量嵌入模型不參與對話只負責(zé)把文本轉(zhuǎn)成向量。它的選擇直接影響檢索質(zhì)量重要性被嚴重低估。選型時看三點第一是維度。維度高表達能力更強但存儲和計算成本也高。常見的有 768 維、1024 維。幾百份文檔的規(guī)模1024 維完全夠用。第二是多語言支持。中文文檔必須選對中文友好的嵌入模型純英文模型在中文上召回率會明顯下降因為它對中文的語義空間建模不充分。第三是最大輸入長度。如果分塊設(shè)成 1024 token嵌入模型的最大長度至少要覆蓋這個值否則會被截斷塊尾的信息直接丟失。配置上Ollama 拉下來的嵌入模型可以直接在 AnythingLLM 里選。切換嵌入模型要注意換了嵌入模型之前入庫的向量全部失效必須清空重新向量化。這個坑我踩過一次換了模型沒重新入庫檢索結(jié)果全是亂的排查了半天才想起來。3. Open WebUI 的部署與訪問控制3.1 容器化部署與端口規(guī)劃Open WebUI 我推薦用容器跑依賴干凈升級方便。端口規(guī)劃上要提前想好避免和已有服務(wù)沖突。我習(xí)慣的規(guī)劃是11434Ollama 模型服務(wù)3000Open WebUI 對話界面3001AnythingLLM 知識庫界面部署命令大致長這樣鏡像地址以官方文檔為準docker run -d \ --name open-webui \ --restart always \ -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -e WEBUI_SECRET_KEY自定義長隨機串 \ -e DEFAULT_MODELSqwen2.5:14b \ -v /data/open-webui:/app/backend/data \ 官方鏡像名:main幾個參數(shù)值得單獨解釋OLLAMA_BASE_URL是關(guān)鍵。容器里的localhost指的是容器自己不是宿主機。Linux 上host.docker.internal不一定默認可用穩(wěn)妥的做法是用宿主機的內(nèi)網(wǎng) IP或者在啟動容器時加--add-hosthost.docker.internal:host-gateway。這個配置錯一次界面能打開但模型列表是空的很多人卡在這一步。WEBUI_SECRET_KEY必須設(shè)不設(shè)的話每次重啟會話密鑰都變用戶全部被登出。生成一個長隨機串固定下來。--restart always別忘了服務(wù)器重啟后服務(wù)自動起來不然第二天上班發(fā)現(xiàn)系統(tǒng)掛了。數(shù)據(jù)卷掛載到宿主機目錄升級容器時數(shù)據(jù)不丟。這條是血淚教訓(xùn)我有次直接docker rm重建所有對話記錄和配置一起沒了。3.2 賬號體系與內(nèi)網(wǎng)訪問邊界Open WebUI 默認第一個注冊的賬號是管理員后面注冊的是普通用戶。這個設(shè)計很方便但也意味著部署完第一件事就是立刻注冊管理員賬號否則誰先訪問誰就是管理員。訪問控制我建議做三層第一層是網(wǎng)絡(luò)層。這套系統(tǒng)只在內(nèi)網(wǎng)使用不要在公網(wǎng)暴露端口。如果確實需要遠程訪問走內(nèi)網(wǎng)穿透或者專線別直接把端口映射到公網(wǎng)。第二層是應(yīng)用層。關(guān)閉開放注冊改成管理員手動創(chuàng)建賬號。設(shè)置路徑在管理面板的賬號設(shè)置里把“允許新用戶注冊”關(guān)掉。團隊規(guī)模小的時候手動建號最省心。第三層是數(shù)據(jù)層。定期備份數(shù)據(jù)目錄尤其是對話記錄和用戶配置。備份策略我一般用每天增量、每周全量保留四周。還有一個容易忽略的點用戶之間的會話是隔離的但知識庫不一定。如果讓 Open WebUI 和 AnythingLLM 共用同一個模型服務(wù)模型本身沒有權(quán)限概念誰都能調(diào)用。所以涉及分部門資料隔離的場景要靠 AnythingLLM 的工作區(qū)權(quán)限來控制而不是指望模型層。3.3 對接 Ollama 的常見故障界面能打開但模型列表空白這是最高頻的問題八成是網(wǎng)絡(luò)不通。排查順序在宿主機上curl http://localhost:11434/api/tags看有沒有返回模型列表在容器內(nèi)docker exec -it open-webui curl http://host.docker.internal:11434/api/tags看容器能不能通檢查 Ollama 是否設(shè)了OLLAMA_HOST0.0.0.0檢查宿主機防火墻有沒有攔 11434 端口如果第 2 步不通但第 1 步通那就是容器網(wǎng)絡(luò)問題換用宿主機內(nèi)網(wǎng) IP 通常能解決。另一個問題是回答到一半中斷。原因通常是上下文超限或者模型被卸載。前者調(diào)小上下文長度參數(shù)后者加大OLLAMA_KEEP_ALIVE。還有一種情況是顯存不夠模型加載到一半被系統(tǒng)殺掉日志里能看到 OOM 字樣這時候只能換小模型。4. AnythingLLM 知識庫的搭建與調(diào)優(yōu)4.1 工作區(qū)劃分與文檔投喂策略AnythingLLM 的核心概念是“工作區(qū)”Workspace一個工作區(qū)就是一個獨立的知識庫加一套對話上下文。劃分工作區(qū)的原則不是按文檔類型而是按提問場景。比如“產(chǎn)品資料”一個區(qū)、“技術(shù)文檔”一個區(qū)、“行政制度”一個區(qū)。這樣檢索時范圍更聚焦召回準確率會明顯提升。我見過有人把所有文檔塞進一個工作區(qū)結(jié)果問產(chǎn)品參數(shù)的時候檢索出一堆行政通知回答自然跑偏。分區(qū)的本質(zhì)是給檢索加一個前置過濾條件。文檔投喂這塊格式支持挺全PDF、Word、Markdown、純文本、網(wǎng)頁都能進。但有幾點必須注意掃描版 PDF 沒有文字層直接扔進去解析出來是空的。這類文件必須先做文字識別轉(zhuǎn)成可搜索的 PDF 或者純文本否則入庫了也檢索不到。判斷方法很簡單用閱讀器試著選中文字選不中就說明是圖片。表格類文檔容易被切碎。一份參數(shù)表如果按字符數(shù)硬切行和列會錯位檢索出來的片段沒法看。這類文檔建議先轉(zhuǎn)成 Markdown 表格再入庫結(jié)構(gòu)保留完整。超長文檔要做章節(jié)拆分。幾百頁的手冊直接入庫分塊后每塊都是碎片語義不完整。我的做法是按章節(jié)拆成多個文件再傳天然形成語義邊界。入庫方式有兩種一是上傳文件二是給一個網(wǎng)頁地址讓它抓取。網(wǎng)頁抓取適合內(nèi)部 Wiki但注意抓取范圍別把導(dǎo)航欄和頁腳重復(fù)抓進每一頁會嚴重污染檢索結(jié)果。4.2 分塊與檢索參數(shù)這幾個數(shù)值決定成敗這是整篇文章最值錢的部分。默認參數(shù)能用但效果離“好用”差得遠。核心參數(shù)就四個參數(shù)默認值附近我常用的值作用與調(diào)整邏輯分塊大小1000 字符左右512 到 800 token太大語義混雜太小語義殘缺分塊重疊20 到 5080 到 120 token防止句子被切斷重疊太少會丟上下文召回數(shù)量 TopN44 到 6太多會引入噪音太少會漏關(guān)鍵信息相似度閾值0.25 左右0.2 到 0.3太高召回不足太低全是無關(guān)內(nèi)容分塊大小的判斷標準是一個塊能不能獨立講清一件事。中文大概 500 到 800 字是一個自然段落的量級對應(yīng) 512 到 800 token。如果你的文檔是條文式的短句比如制度條款可以切小一點400 左右如果是敘述性長文可以切大到 1000。重疊的作用是保險。舉個例子一句話被切在兩塊中間前半句在第一塊末尾后半句在第二塊開頭檢索時只召回其中一塊模型就只能看到半句話。加上 100 token 的重疊兩塊都包含完整句子就不會丟。閾值這個參數(shù)最需要實測。設(shè) 0.25 意味著相似度低于這個分數(shù)的片段直接丟掉。如果你的文檔用詞和提問用詞差異大比如文檔寫“采購審批流程”用戶問“買東西怎么申請”閾值設(shè)高了就什么都召不回來。這種情況要么降低閾值要么在文檔里補充同義表述。4.3 提示詞模板與引用溯源AnythingLLM 允許自定義系統(tǒng)提示詞這是提升回答質(zhì)量最便宜的手段。默認提示詞比較泛我一般改成這樣幾個要求你是內(nèi)部資料檢索助手。請嚴格依據(jù)提供的上下文片段回答問題。 規(guī)則 1. 只使用上下文中的信息不要引入外部知識補充。 2. 如果上下文中沒有相關(guān)信息直接回答“資料中未找到相關(guān)內(nèi)容”不要猜測。 3. 回答時標注信息來源的文檔名和章節(jié)。 4. 涉及數(shù)字、日期、金額時必須原文引用不要改寫。 5. 用簡體中文回答語言簡潔不使用客套話。這幾條規(guī)則解決四個真實問題模型愛編造、愛客套、愛改寫數(shù)字、不給出處。尤其是第 4 條涉及金額和日期的時候模型“順手”把 3 個工作日改成 5 個工作日這種錯誤最致命。引用溯源功能要打開。它會在回答后面附上引用的文檔片段和來源方便核對。剛開始用的時候我建議每次都點開引用看一眼確認模型是真的讀了文檔還是在編。用兩周之后你就能判斷哪些回答可信、哪些需要復(fù)核。溫度參數(shù)也要調(diào)。知識庫問答不需要創(chuàng)造性溫度設(shè) 0.1 到 0.3 之間讓回答穩(wěn)定、可復(fù)現(xiàn)。默認值偏高的話同一個問題問兩次答案不一樣用起來很難受。4.4 多用戶與權(quán)限邊界AnythingLLM 支持多用戶模式開啟后可以給不同用戶分配不同工作區(qū)的訪問權(quán)限。這對小團隊很實用行政資料只給行政看技術(shù)文檔全員可見財務(wù)相關(guān)的單獨建區(qū)。開啟多用戶需要注意幾點一是必須設(shè)置管理員賬號二是每個用戶的工作區(qū)權(quán)限要單獨配置三是默認情況下新用戶看不到任何工作區(qū)需要手動授權(quán)。權(quán)限配置界面不算直觀第一次配容易漏。還有一個現(xiàn)實問題模型服務(wù)本身沒有權(quán)限隔離。用戶在 AnythingLLM 里看不到某個工作區(qū)但如果他知道模型服務(wù)地址理論上可以直接調(diào)用。所以真正的隔離要靠網(wǎng)絡(luò)層比如把模型服務(wù)只監(jiān)聽內(nèi)網(wǎng)、用防火墻限制來源 IP。應(yīng)用層的權(quán)限更多是防誤操作不是防惡意訪問。5. 檢索效果調(diào)優(yōu)與實測記錄5.1 文檔清洗比換模型更有用這句話我想強調(diào)三遍。很多人檢索效果差第一反應(yīng)是換更大的模型實際上八成的質(zhì)量問題出在文檔本身。我做過一次對比。同一批 200 份技術(shù)文檔第一輪直接入庫問 20 個標準問題答對 11 個。第二輪做了清洗去掉頁眉頁腳、統(tǒng)一術(shù)語表述、把表格轉(zhuǎn)成 Markdown、按章節(jié)拆分文件、補上文檔標題和版本號同樣的模型和參數(shù)答對 17 個。模型一個字沒改效果提升 55%。清洗清單我總結(jié)成這幾條刪除重復(fù)的頁眉頁腳、頁碼、水印文字統(tǒng)一同義詞比如“客戶端”和“用戶端”選一個另一個在檢索時靠同義詞擴展補表格保留結(jié)構(gòu)用 Markdown 或明確的分隔符每份文檔開頭加三行元信息文檔名、版本、適用范圍按章節(jié)拆分成獨立文件文件名帶上章節(jié)號去掉目錄頁和修訂記錄頁這些內(nèi)容沒有檢索價值還容易誤召回最后那條特別有用。目錄頁里堆滿了章節(jié)標題語義密度高但信息量為零特別容易被誤召回然后模型拿著一堆標題硬編答案。5.2 分塊參數(shù)的實測對比我在同一批文檔上做了幾組分塊實驗用 30 個問題的命中率作為指標命中指召回的片段中至少有一塊包含正確答案分塊大小重疊TopN閾值命中率觀察10005040.2568%塊太大語義混雜回答常跑題5125040.2574%有改善但句子切斷情況多51210040.2581%重疊加大后明顯改善80012060.2287%綜合最好的一組800120100.2284%召回太多噪音拉低準確率40010060.2279%切太碎上下文不完整結(jié)論很清楚分塊 800 加重疊 120 加 TopN 6 是這批文檔的最優(yōu)組合。但這個數(shù)值不能直接抄因為它跟文檔的寫作風(fēng)格強相關(guān)。條文式文檔適合切小敘述式文檔適合切大。我的建議是拿 20 到 30 個真實問題做一次小規(guī)模網(wǎng)格測試花兩個小時后面幾個月都受益。測試方法很簡單列一張表左邊是問題右邊是期望答案的關(guān)鍵詞。每換一組參數(shù)就跑一遍統(tǒng)計命中。別憑感覺判斷“好像變好了”人的感覺在檢索質(zhì)量上極不可靠。5.3 檢索不準的三條排查路徑回答不準的時候先分清是召回問題還是生成問題。判斷方法打開引用溯源看召回的片段里到底有沒有答案。如果引用的片段里根本沒有正確答案那是召回問題。排查方向提問的用詞和文檔用詞差異太大試試換成文檔里的表述方式再問分塊把關(guān)鍵信息切斷了調(diào)大重疊閾值太高把相關(guān)片段過濾掉了降到 0.2 試試該文檔壓根沒入庫或者入庫時解析失敗掃描件常見嵌入模型對中文支持不好換一個中文友好的如果引用的片段里有正確答案但模型答錯了那是生成問題。排查方向上下文塞太多關(guān)鍵信息被淹沒了降低 TopN提示詞沒強調(diào)“只用上下文”模型自由發(fā)揮溫度太高回答不穩(wěn)定降到 0.2模型本身理解力不足換大一號的模型這個二分法能省掉大量盲目調(diào)試。我見過有人一直換模型實際上問題是文檔沒入庫成功。6. 常見問題速查與運維加固6.1 部署與運行問題速查表現(xiàn)象可能原因處理辦法界面能開模型列表空容器連不上 Ollama改用宿主機內(nèi)網(wǎng) IP加 host-gateway 參數(shù)提問后長時間無響應(yīng)模型正在加載調(diào)大 keep-alive預(yù)熱一次模型回答到一半中斷上下文超限或顯存不足減小上下文長度換小模型服務(wù)重啟后數(shù)據(jù)丟失數(shù)據(jù)目錄沒掛載到宿主機加 volume 掛載重建前先備份用戶頻繁被登出會話密鑰未固定設(shè)置固定的 secret key入庫進度卡住文檔過大或解析超時拆分文件分批入庫檢索返回空閾值過高或向量未生成降閾值檢查文檔是否顯示已向量化中文回答夾雜英文模型訓(xùn)練語料偏英文換中文更強的模型提示詞要求中文6.2 運維層面的加固建議系統(tǒng)跑起來只是開始長期穩(wěn)定靠的是運維習(xí)慣。我固定在做的幾件事備份三件套模型目錄、Open WebUI 數(shù)據(jù)目錄、AnythingLLM 存儲目錄。前兩個丟了重裝就行第三個丟了所有向量和文檔元信息都要重建幾百份文檔重新入庫要幾個小時。備份用定時任務(wù)每周全量、每天增量異地存一份。日志保留。容器日志默認會無限增長加日志輪轉(zhuǎn)配置限制單文件大小和保留份數(shù)。我遇到過磁盤被日志寫滿導(dǎo)致服務(wù)崩潰的情況排查了半天才發(fā)現(xiàn)是這個原因。版本鎖定。鏡像不要用 latest 標簽用具體版本號。開源項目迭代快某次更新改了配置項格式升級后服務(wù)起不來回滾又找不到舊鏡像。鎖定版本升級前先在測試環(huán)境驗證。資源限制。給容器加內(nèi)存和 CPU 限制防止某個進程吃滿整機。尤其是嵌入模型批量處理的時候內(nèi)存占用會突然飆升。訪問日志。內(nèi)網(wǎng)服務(wù)也要記錄訪問日志至少記錄誰在什么時候問了什么。這既是審計需要也是排查問題的依據(jù)。6.3 安全邊界的三條底線雖然這套系統(tǒng)跑在內(nèi)網(wǎng)但基本的安全習(xí)慣還是要守住。第一條不要在公網(wǎng)暴露任何端口。這套系統(tǒng)設(shè)計上就沒考慮公網(wǎng)安全沒有防暴力破解、沒有驗證碼、沒有速率限制。真要遠程訪問套一層帶認證的反向代理并且限制來源 IP。第二條模型服務(wù)不做鑒權(quán)。Ollama 的接口默認沒有認證機制任何能訪問 11434 端口的人都能調(diào)用模型。所以這個端口只能在內(nèi)網(wǎng)開放不要做端口轉(zhuǎn)發(fā)。如果多人共用一臺機器考慮給上層應(yīng)用做賬號隔離而不是指望模型層。第三條敏感文檔單獨分區(qū)。合同、報價、人事資料這類文檔單獨建工作區(qū)只授權(quán)給特定賬號。同時注意刪文檔不等于刪向量刪除文檔后要確認向量也被清理否則殘留數(shù)據(jù)還能被檢索到。這個細節(jié)很多人會忽略。7. 我個人跑下來的一點體會這套組合我從最早的單機試玩到后來給幾個小團隊部署前后搭過七八次。最大的感受是部署只占兩成工作量剩下八成都在文檔治理和參數(shù)調(diào)優(yōu)上。工具本身沒有魔法。同一套 Ollama 加 AnythingLLM文檔整理得好的團隊問答準確率能到八成以上文檔亂七八糟直接往里扔的準確率不到五成然后就開始懷疑模型不行、工具不行。實際上問題出在源頭。還有個心態(tài)上的建議別追求一步到位。先把系統(tǒng)跑通能用起來然后拿真實問題去試發(fā)現(xiàn)哪里不準就針對性地調(diào)。我見過有人花兩周時間研究各種參數(shù)組合結(jié)果一份文檔都沒入庫。先跑起來再優(yōu)化這個順序不能反。最后分享一個我自己常用的小技巧建一個“測試問題集”文檔把 20 個真實問題和標準答案寫進去每次改參數(shù)或者換模型跑一遍看命中率變化。這張表比任何主觀感受都可靠也是我判斷“這次改動到底有沒有用”的唯一依據(jù)。攢了半年之后它已經(jīng)成了我評估這套系統(tǒng)健康度的基準線。