2026-06-27

知識庫問答系統怎麼建：架構選型與落地路徑

搭建一套真正「能用」的知識庫問答系統，光跑通 demo 遠遠不夠。本文從五條驗收標準出發，覆蓋檢索品質、多模態路由、知識優先策略與可觀測性，並對比自建 RAG、開源產品、低程式碼編排三條落地路徑的適用場景與取捨，幫助團隊在架構選型時少走彎路。

為什麼知識庫問答系統「跑得通」不等於「能用」

大多數知識庫問答系統的演示環節都很順利：上傳幾份文件，提一個問題，模型給出像模像樣的答案，會議室裡點頭通過。問題在於，這個場景和生產環境之間隔著一道工程上的鴻溝。Demo 驗證的是「這條鏈路能產生回答」，而生產要回答的是「這條鏈路能不能持續產生可信、可控、可追責的回答」。這兩件事的難度不在一個量級。

真正決定專案成敗的分水嶺，不是 RAG 原理有沒有講清楚。檢索增強生成的基本邏輯——把問題轉成向量、在文件庫裡找相似片段、把片段塞進提示詞讓模型作答——並不複雜，網上的教程能讓一個工程師在一天內搭出可執行的原型。但原理跑通和系統可用之間，橫著大量在演示裡看不見、上線後才集中爆發的工程問題。檢索結果偶爾為空時模型會怎麼辦？召回的片段品質參差不齊時答案可信度如何保證？使用者問的是表格裡的資料但系統只檢索了正文段落，會發生什麼？這些都不是原理問題，是工程問題。

對決策者來說，需要回答的從來不是「RAG 怎麼實現」。這個問題該由技術團隊消化。決策者真正要判斷的是另一件事：這套系統上線後會不會翻車，會在哪些場景翻車，翻車的代價由誰承擔。一個會編造答案的問答系統，比沒有問答系統更危險——它會讓業務人員基於錯誤資訊做決策，而且因為答案看起來很專業，錯誤往往要到造成後果時才被發現。可用性不是一個模糊的體感，它是一組可以逐條檢查的工程條件。

所以這篇文章不打算從原理講起。原理類的內容已經足夠多，再寫一遍既無新意也幫不上決策。我們換一個角度：把「這套系統能不能用」拆成五個可驗收的標準。每一條標準都對應著具體的配置項、可以現場檢查的設定，以及一旦不滿足就會出現的明確失敗訊號。驗收的邏輯是反過來的——不去論證系統應該怎麼設計，而是直接列出如果設計有問題，會暴露出哪些症狀。決策者拿著這份清單，可以繞開技術細節，直接對照檢查供應商的方案或自建團隊的成果。

這五個標準分別覆蓋幾個最容易出事的環節。第一，模型的回答是否嚴格鎖定在檢索到的內容範圍內，還是會在檢索為空時自由發揮。第二，檢索的召回數量和品質門檻是不是可調的參數，而非寫死的黑盒。第三，當知識庫裡包含圖片、表格、掃描件這類非純文本內容時，多模態的處理鏈路是否被正確觸發，還是悄悄被跳過。第四，系統是否真的優先去查知識庫，還是經常繞過知識庫直接用模型的通用知識作答，導致你精心維護的資料根本沒被用上。第五，整套系統能不能被觀測、被維護、被接進現有的工作流，而不是一個誰也不敢動的孤島。

這五條不是理論框架，是從一次次上線翻車裡反推出來的檢查點。每一條背後都有一類真實發生過的故障模式。把它們當成驗收單來用：能逐條通過的系統，大機率經得起生產環境的考驗；有任何一條卡住的，上線前就該把它解決掉，而不是等使用者替你發現。接下來逐條展開，每一條都會說清楚要檢查什麼、怎麼檢查、不達標時會看到什麼現象。

驗收標準一：檢索結果非空，且模型只基於檢索內容回答

這是最基礎也最容易被跳過的一條。很多團隊上線前只測了「問答能不能出結果」，卻沒分清楚兩件事：模型回答得流暢，和模型回答得有依據，完全是兩碼事。一個能編故事的系統看起來比一個老實承認「不知道」的系統更討喜，但前者在生產環境裡是定時炸彈。

先說檢索為空的問題。如果你發現某些提問明明命中了知識庫裡的內容，系統卻返回空白或者答非所問，第一反應不該是去調相似度閾值，而是回到知識庫管理介面，確認那批文件的索引狀態。文件上傳成功不等於可被檢索——它還要經過切分和向量化才能進入檢索池。這個過程是非同步的，大檔案或批次匯入時可能要等上幾分鐘。我見過太多「檢索沒結果」的工單，最後查出來是文件卡在處理中狀態就被當成已上線了。所以上線前的硬動作是：逐一核對待檢索文件的處理狀態是否全部完成，而不是看一眼上傳列表就放行。

第二件事更隱蔽，關係到模型到底在回答什麼。檢索環節把相關片段撈出來了，但這些片段未必真的進了模型的視野。在大多數編排框架裡，檢索節點會產出一個結果變數，承載召回的文本內容。如果你在 LLM 節點沒有把這個變數掛進上下文，模型拿到的就只是使用者的原始問題，於是它會呼叫自己的預訓練知識自由作答。表面上一切正常，回答還挺像樣，但它壓根沒看你的知識庫。正確做法是把檢索產出的結果顯式注入上下文，並在系統提示詞裡用上下文佔位符去引用它，明確告訴模型「只能基於這段材料回答」。這一步配錯，整套 RAG 鏈路就退化成了一個普通對話機器人，知識庫形同虛設。

這兩個問題有個共同的麻煩：它們不會報錯。系統照常執行，回答照常生成，監控面板一片綠。問題只在你拿真實業務問題去對照標準答案時才暴露出來，而那往往已經是使用者投訴之後了。

所以驗收這一條，光看正常提問通不通是不夠的，得反著測。最有效的動作是故意問一個知識庫裡根本不存在答案的問題——比如編一個不存在的產品型號、問一個超出資料覆蓋範圍的政策細節。然後看模型怎麼回應：

• 合格的回答是明確告知「在現有資料中沒有找到相關內容」，或者引導使用者換個問法、補充資訊。
• 不合格的回答是煞有介事地給出一段聽起來專業、實則完全虛構的內容。這就是典型的幻覺，也是脫離知識庫自由發揮的鐵證。

把這個測試做成一組固定的「陷阱問題」，每次改動提示詞、換模型、調檢索參數後都跑一遍，比任何主觀體驗都靠譜。一個系統寧可多說幾次「我不知道」，也不能在使用者面前一本正經地胡說——在企業知識場景裡，錯誤答案的代價遠高於沒有答案。

這一條過了，說明你的檢索鏈路是通的，模型也確實被約束在了知識邊界內。但「能基於知識庫回答」只是及格線，回答得準不準、全不全，取決於檢索本身的品質。下一條標準就來處理這件事。

驗收標準二：檢索品質與召回數量可控可調

第一個標準解決的是「答案有沒有依據」，這一條解決的是「依據找得準不準、給得夠不夠」。一個問答系統真正進入可用狀態的分水嶺，往往不在模型有多強，而在檢索層是否暴露了足夠的調節旋鈕。如果檢索行為是黑盒——條數固定、模式不可選、切片不可見，那麼上線後遇到答非所問，你連下手調優的地方都沒有。

先看檢索模式。純向量檢索擅長捕捉語義相近，但在專有名詞、產品型號、錯誤碼這類需要精確命中的場景上經常失手；純關鍵詞檢索反過來，認字不認意。實踐中更穩妥的做法是讓檢索節點同時跑語義和關鍵詞兩條路，再做結果融合，也就是常說的混合檢索，並在此基礎上疊加重排序以提高頭部結果的相關度。檢索節點的輸出不應該是一段拼好的純文本，而應該是結構化的對象陣列，每個元素攜帶文件片段及其來源、得分等元資訊。這一點很關鍵：結構化輸出意味著後續的 LLM 環節能拿到清晰的上下文邊界，你也能在鏈路裡對每一條召回結果做過濾、截斷或重排，而不是面對一坨無法拆解的字串。

再看召回數量。每輪檢索返回幾條文件，本質是在召回率和上下文長度之間做權衡。條數太少，相關資訊可能根本沒進上下文，模型自然答不全；條數太多，無關片段稀釋了有效訊號，還會擠佔 token 預算、推高延遲和成本。一個合理的工程預設值是每輪取 3 條，同時把上限開放給使用者按場景調整。FAQ 類短問答需要的條數較少，需要綜合多個段落的分析型問題則可能要相應放寬。重點不在於某個魔法數字，而在於這個值必須是可配置的——能根據實際問答效果回呼，而不是寫死在程式碼裡。

真正容易被低估的是切片策略，它在資料入庫階段就決定了召回品質的天花板。常見的預設配置是按 1000 字元切片、重疊 200 字元，對結構鬆散的長文本通常夠用。但預設值是給通用情況兜底的，不是給你的文件量身定做的。問題在於固定長度的切分很可能從一個語義單元中間一刀切下去：一張表格被拆成兩半、一段程式碼示例首尾分離、一個完整的操作步驟被截斷在第三步。這種被切碎的片段進入向量庫後，單獨看語義殘缺，檢索時既不容易被命中，命中了也無法支撐模型給出完整回答。

所以入庫後一定要抽查切片結果。開啟實際生成的片段看一眼——一箇中等長度的 Markdown 文件大致會被切成十幾個片段，逐條確認它們是否落在合理的語義邊界上。如果發現表格、列表、程式碼塊這類強結構內容被頻繁切斷，就需要回過頭調整切片粒度，或者引入按標題層級、按段落結構切分的策略，讓切片尊重文件本身的組織方式。這部分投入看著瑣碎，卻是檢索品質裡回報最高的一塊——它在最上游，一旦切壞了，下游再怎麼調模式、調條數都補不回來。

把這條標準落到驗收上：檢索模式能切換並預設啟用混合檢索，召回條數可配置且有合理預設，切片結果經過人工抽查確認沒有切碎語義單元。三者都滿足，檢索層才算交到了可以持續調優的狀態，而不是一個調不動的黑盒。

驗收標準三：多模態鏈路被正確路由與觸發

前兩條標準管的是單一文字鏈路的可靠性，但真實場景裡使用者不會只發文字。維運同事會截一張報錯日誌的圖，售後會拍一段裝置銘牌，財務會甩過來一張發票掃描件。系統能不能識別出「這次輸入帶了圖」，並把請求送進正確的處理通道，是第三條要驗收的核心。判斷標準很直接：同一個對話方塊，使用者什麼都不改，發純文字時走文字檢索，附了圖片時走視覺理解，兩邊都給出像樣的回答。做不到這一點，使用者就得被迫記住「問文字用這個入口、傳圖用那個入口」，體驗直接退回到割裂狀態。

實現上的關鍵是路由邏輯。請求進來後要先做一次判斷——這一輪有沒有附帶檔案。帶檔案的，分流到能讀圖的視覺模型；沒帶的，走純文本的檢索增強通道，由語言模型結合知識庫上下文作答。這個判斷本身不復雜，難的是它必須放在鏈路最前端，且對兩種輸入都有明確的去向，不能出現「帶圖請求誤入文字通道」或者反過來的情況。一旦路由判斷寫得含糊，比如只判斷了有檔案的分支、漏了無檔案的兜底，純文字提問就可能卡在一個等不到圖片的節點上，表現為莫名其妙的超時或空響應。

視覺節點的 Vision 開關：最容易漏掉的一格

這裡要單獨點出一個出現頻率極高的配置疏漏。視覺模型節點通常帶一個控制是否處理影像輸入的開關，預設狀態往往是關的。如果路由本身搭對了、圖片也確實傳到了視覺節點，但這個開關忘了開啟，結果不是報錯退出，而是模型把圖當作不可讀內容處理，回一句類似「無法識別檔案」的話。問題就出在這個回饋太像「正常的失敗」——配置的人會以為是模型能力不行或者圖片格式有問題，轉頭去換模型、壓縮圖片，折騰半天，根源其實只是一個沒勾上的選項。

之所以反覆強調它，是因為這個故障的排查成本和它的實際複雜度嚴重不成比例。從現象往回推：上傳圖片後穩定收到「無法識別」，文字提問卻一切正常，那麼大機率不是路由錯了，而是視覺節點壓根沒在讀圖。先去確認開關狀態，比先去懷疑模型和圖片要快得多。把這條寫進團隊的排障清單，能省下大量無意義的試錯。

怎麼驗收：兩條鏈路各跑一次

驗收動作設計得越簡單越好，因為它要被反覆執行——每次改了路由、換了模型、調了節點配置，都該重跑一遍。具體做兩件事：

• 純文字提問一次。挑一個知識庫裡確實有答案的問題，確認回答內容來自知識庫、且沒有觸發任何影像相關的處理。這驗證的是無檔案分支被正確命中。
• 帶圖提問一次。傳一張和業務相關、內容清晰的圖片，配上文字訴求，確認視覺節點真的讀到了圖、並基於影像內容作答，而不是回「無法識別」。這驗證的是有檔案分支命中、且 Vision 開關確實生效。

兩次都通過，才算這條鏈路真正打通。這裡有個容易被忽略的點：很多人只測了帶圖的那條——因為視覺是新功能、最讓人不放心——卻預設純文字一直沒問題。但路由是個二選一的判斷，改動有圖分支時完全可能誤傷無圖分支，所以兩邊都必須實際跑過，不能靠推斷。

還有一個進階的驗收角度：試一次「帶圖但圖片無關」的提問，看看系統是退回純文字檢索，還是硬要從圖裡找答案、最後答非所問。這一步不是強制項，但它能暴露路由邏輯是不是過於粗糙——只看「有沒有檔案」而不管檔案是否真的需要被理解。對圖文混雜頻繁的場景，提前想清楚這種邊界情況的處理方式，比上線後被使用者的真實輸入打個措手不及要划算。

把這三條做紮實，多模態這部分基本就穩了。它不像檢索品質那樣需要持續調參，更多是一次性把路由和開關配對、再用固定動作守住迴歸，屬於「搭對了就長期省心」的那類工作。

驗收標準四：知識檢索前置，保證知識庫利用率

有一類失敗很隱蔽：系統跑得通、答得也像樣，但你回頭一查日誌，發現真正命中知識庫的請求佔比低得離譜。知識庫建了，錢花了，結果大部分回答來自模型自己的參數記憶，跟你那批文件沒什麼關係。這種「繞過」不會報錯，所以驗收時如果不專門去查，很容易漏掉。

問題出在路由順序上。常見的錯誤設計是先判斷使用者輸入型別——有沒有上傳檔案、是不是圖片、要不要聯網——再決定走哪條鏈路。這套分支邏輯一旦把「純文本提問」和「帶附件提問」分開處理，知識檢索往往只掛在其中一條路徑上，另一條就裸奔了。使用者隨手丟一張截圖過來，系統就直接餵給視覺模型，知識庫連碰都沒碰。

更穩的做法是把知識檢索抬到所有分支之前，作為無條件的第一步。不管來的是文字、檔案還是圖片，先拿使用者意圖去庫裡撈一遍相關片段，把結果作為參考上下文掛上去，再往下走型別判斷。這樣無論後續鏈路怎麼分叉，模型手裡始終握著一份來自你知識庫的材料。檢索為空是另一回事（那歸驗收標準一管），這裡要保證的是「檢索這個動作必然發生」，而不是看心情觸發。

視覺鏈路是這條原則最容易被忽略的地方。很多團隊預設圖片就該交給多模態模型孤立地看，看完直接回答。可現實裡使用者傳圖常常帶著上下文——一張裝置報錯截圖，配的問題是「這個故障在我們的維修手冊裡怎麼處理」。如果只讓視覺模型描述圖裡有什麼，再憑空作答，它給出的就是通用常識，不是你手冊裡的標準流程。正確的做法是圖文一起餵：視覺模型負責解析影像內容，知識檢索結果同步注入，讓模型在「看懂這張圖」和「對照我們的資料」之間做融合分析。驗收時可以專門構造一批「圖片+知識庫相關問題」的樣例，看回答裡有沒有引用到庫內資訊，而不是停留在對圖片的客觀描述。

第三個層面是擴展位。今天你的庫可能只有文本和圖片，明天就要接 PDF 解析、音訊轉寫、表格抽取。架構如果一開始沒給這些分支留位置，每加一種輸入型別都得動核心路由，改一次壞一次。比較務實的設計是把輸入處理做成可插拔的分支，新格式進來時只是多註冊一條預處理管線，知識檢索前置這個公共動作和下游的模型呼叫都不用改。

驗收新分支時，重點不在於新功能本身能不能跑，而在於它接進去之後老鏈路有沒有被帶壞。建議保留一組覆蓋原有輸入型別的迴歸用例，每次擴展後整組重跑一遍：原來的純文本問答、圖文問答是否還按預期命中知識庫，路由有沒有把請求錯誤地分流到新分支上。一個常見的翻車場景是新加的 PDF 分支搶了本該走普通文本的流量，或者音訊轉寫的結果繞過了檢索前置。這些都不是功能 bug，是整合 bug，單測覆蓋不到，只有跑端到端迴歸才暴露得出來。

把這條標準濃縮成一句可執行的檢查：隨機抽一批線上真實請求，統計其中真正觸發知識檢索的比例，再看圖片類、檔案類請求裡有多少把庫內內容用進了答案。比例如果明顯偏低，說明你的知識庫正在被路由悄悄架空，這比答錯更值得警惕——答錯你看得見，被繞過你看不見。

驗收標準五：可觀測、可維護、可整合到現有工作流

前四條標準管的是「答得對不對」，第五條管的是「用不用得起來、扛不扛得住時間」。很多問答系統在演示環節表現得無可挑剔，但它始終活在一個獨立的測試頁面裡——要回答問題，得先開啟那個頁面、登入、輸入。這種形態決定了它的命運：上線一個月後沒人記得入口在哪，知識庫也就停在了交付那天的版本。判斷一套系統能不能進生產，先看它願不願意「消失」在使用者已經在用的地方。

第一個落點是終端形態。員工每天的工作面是聊天視窗和瀏覽器，不是某個新開的網址。一套能落地的問答系統應當能以網頁掛件的方式嵌進現有門戶或文件站，也能掛載成釘釘、飛書、企業微信裡的機器人，讓使用者在原有對話流裡直接發問、直接拿到回答。開源專案裡像 PandaWiki 就把這幾種整合形態都打通了，這不是錦上添花，而是把「使用成本」壓到接近零——使用者不需要為了問一個問題改變任何習慣。反過來說，如果一套系統只能給你一個孤立頁面，那它的真實使用率幾乎一定會歸零，再好的檢索品質也兌現不出價值。

第二個落點是內容怎麼進來，以及進來之後還能不能持續更新。知識庫不是一次性灌裝的水箱，是需要常流常新的管道。驗收時要確認匯入通道是否覆蓋真實的內容來源：能不能直接吃一個網頁 URL，能不能順著站點的 Sitemap 把整站文件批次拉進來，能不能訂閱 RSS 讓新發布的內容自動入庫，能不能處理本地的離線檔案。這幾條通道對應的是不同的內容生命週期——官網文件靠 URL 和 Sitemap，動態資訊靠 RSS，內部資料靠檔案上傳。少一條通道，就意味著某一類知識永遠停留在系統之外，回答的盲區會一直存在。能否持續更新，本質上由這些匯入方式的完整度決定。

第三個落點藏在架構裡，平時看不見，維護時全是它。一套需要長期演進的系統，工程組織方式直接決定了改一行程式碼要付出多大代價。這裡有兩個值得在選型或自建時確認的做法。其一是大模型的載入方式：模型客戶端應當以單例形式只初始化一次，後續所有請求複用同一個實例。模型載入本身開銷不小，如果每來一個請求就重建一次連接，資源佔用和響應延遲都會被無謂地拉高，單例化是把這部分浪費直接消除掉。其二是模組邊界：把向量資料庫的讀寫、文本的切分與清洗、模型互動、以及上層應用邏輯拆成各管一攤的獨立模組。這種拆分的回報會在第二年顯現——當你要換一個向量庫、調整切分策略、或者接入另一家模型時，改動能被鎖在單個模組內，不會牽一髮而動全身。

把這三點合起來看，可觀測和可維護其實是同一件事的兩面：系統要讓你看得見它在做什麼（哪條鏈路被觸發、哪次檢索為空、哪個模組出錯），也要讓你改得動它的某一部分而不必重寫整體。驗收時不妨問一個樸素的問題——半年後接手的工程師，能不能在不通讀全部程式碼的前提下，安全地替換掉其中一個元件。答得上來，這套系統才算真正可以交給時間。

三條落地路徑對照：自建 RAG、開源產品、低程式碼編排怎麼選

前面五條驗收標準定義了「能用」的邊界，但落地時還有一個繞不開的決策：到底是自己從向量庫搭起，還是直接拿現成的方案改？這三條路不是水平面上的並列選項，而是工程投入、可控程度和上線速度三個維度上的取捨。把這三個變數擺清楚，選型基本就有答案了。

先說自建。這條路的典型形態是一套全本地棧：向量資料庫用 Milvus，嵌入模型用面向中文最佳化的 m3e，生成模型掛一個輕量級的 qwen2.5。它的核心價值只有一個——資料不出門。整條鏈路可以在斷網環境跑，沒有任何 API 呼叫費用，每個環節的參數都攥在自己手裡，相似度閾值、召回策略、模型權重都能改。代價也很直接：分塊策略、嵌入服務、檢索調優、模型部署、維運監控，每一塊都得自己寫自己扛。如果團隊沒有穩定的研發投入，自建很容易卡在「跑得通的 demo」和「能用的系統」之間那道坎上。所以這條路只對一類團隊成立：有明確的資料隱私硬約束，同時養得起一支能持續迭代的工程隊伍。把它當成首選方案而非兜底方案的團隊，往往低估了後續維護的長尾成本。

第二條路是直接用開源產品。這類系統已經把知識庫搭建、多源匯入、AI 問答、AI 搜尋打包成開箱可用的形態，自己用 Docker 託管即可。以 PandaWiki 為例，它在 GitHub 上積累了約 9.8k Star，發布過三百多個版本、保持著相當高頻的迭代節奏，社群活躍度和維護連續性都經得起看。對沒時間從零造輪子、又想把資料放在自己機器上的團隊，這是價效比最高的起點。但有兩個前提要盯住：一是部署門檻，它需要 Linux 上 20.x 以上的 Docker 環境，機器和維運得提前備好；二是協議風險，它走的是 AGPL-3.0，意味著一旦涉及商業化分發或對外提供服務，你的修改和整合程式碼可能被要求同等開源。這一條對法務和商業模式的影響，必須在動手前就攤到桌面上，不能等上線後才發現繞不開。

第三條路是低程式碼編排。它把整條問答鏈路拆成視覺化的節點，在畫布上拖拽拼接。一個能跑的多模態問答流，通常就是使用者輸入、知識檢索、條件分支、文本生成模型、視覺模型這幾類節點組合出來的——前面驗收標準裡反覆強調的「檢索前置」「條件路由」「多模態觸發」，在這種編排範式裡恰好對應著幾個看得見、可單獨除錯的節點。它最大的好處是把抽象的鏈路變成了可觀察的拓撲：哪一步出了問題，點開哪個節點看輸入輸出就行；想加一條新分支，連兩根線就成。對於還在驗證業務假設、需要快速試錯的場景，它能把「從想法到能演示」的週期壓到最短。侷限在於深度客製時會撞到平台抽象的天花板，某些精細控制不如自己寫程式碼來得直接。

把三者放進一張表對比，差異更清楚：

最後一點比選型本身更重要：這三條路不是互斥的單選題。務實的做法是先用開源產品或低程式碼編排把前面五條驗收標準逐項跑通，確認問答系統在自己的業務資料上確實「能用」，再回頭判斷是否值得投入自建去做深度客製。先驗證再重投，比一上來就賭自建要穩得多——很多團隊踩的坑，恰恰是把最重的路當成了第一步。

常見問題 FAQ

AI 回答時經常編造知識庫裡沒有的內容，怎麼排查？

這是上線後最常見的投訴，但它不是一個問題，而是一類症狀。排查時不要急著調 prompt，先按鏈路從後往前定位故障點。

第一步，看模型拿到的輸入。把某條編造回答對應的檢索結果原樣打出來——很多時候你會發現檢索壓根返回了空，或者返回的全是不相關片段。模型在沒有可用上下文時，會本能地用預訓練知識補全，這就是幻覺的直接來源。如果是這種情況，問題在檢索側，不在生成側，改 prompt 沒用。

第二步，確認檢索非空之後，再看 prompt 有沒有把「只能基於以下內容回答，無依據就明說找不到」這條約束寫死。約束缺失或寫得太軟（比如只說「請參考」），模型會把檢索內容當成建議而非邊界。這裡的措辭要強制：寧可讓它回答「知識庫中未找到相關資訊」，也不要給一個看似流暢實則虛構的答案。

第三步，檢查切分粒度。一段話被切成兩半、關鍵資訊分散在兩個 chunk 裡，檢索只命中其中一個，模型拿到半截事實就會自己腦補另一半。遇到這種情況，調整切分策略或增大重疊區，比反覆改 prompt 見效快。

一個實用判斷：把同一個問題問三次，如果每次編造的內容都不一樣，基本是檢索沒給夠上下文；如果每次編造內容穩定一致，那更可能是某條錯誤資料真的進了知識庫，需要回去清洗資料來源。

上傳了圖片但模型說無法識別檔案，是哪裡配置錯了？

先分清兩件事：圖片有沒有被存下來，和圖片有沒有被送進能看懂它的模型。這兩步任何一步斷了，表現都是「無法識別」，但修復位置完全不同。

最高頻的原因是路由沒走對。系統裡往往同時掛著純文本模型和多模態模型，使用者傳圖後，請求如果預設仍然分發給了文本模型，那它確實看不到影像，只會收到一個檔案路徑或亂碼，於是回覆無法識別。排查方法是看請求日誌裡實際呼叫的是哪個模型端點——這一步能篩掉大半的配置問題。

第二類是格式與體積。部分模型對圖片格式、解析度、單檔案大小有硬性上限，超限會被靜默丟棄或在預處理階段報錯。建議先用一張小尺寸、標準 PNG 或 JPG 的圖片做最小驗證，能通就說明鏈路本身是好的，再回頭排查具體那張圖的屬性問題。

第三類是把「能存圖」誤當成「能讀圖」。有些系統支援上傳圖片作為附件儲存和下載，但並沒有接入視覺理解能力，圖片對模型而言只是一個不可讀的二進位制。這種情況不是配置錯，是能力沒具備，需要確認所選模型本身支援視覺輸入。

完全離線、不聯網的內網環境能搭知識庫問答嗎？

能，而且對很多有資料合規要求的團隊來說，內網部署是唯一可接受的方案。但要把代價提前算清楚。

核心約束有兩個。一是模型必須本地化：你需要選一個可以私有部署的開源模型，並準備相應的推理算力，通常意味著至少一塊夠用的 GPU，模型越大顯示記憶體要求越高。二是嵌入模型同樣要本地跑，因為構建向量索引和每次檢索都依賴它，這一步不能偷偷調外部介面。

除模型外，向量庫、文件解析、應用服務這幾層都有成熟的可離線執行的開源選擇，搭起來不難。真正的隱性成本在品質：同等參數規模下，本地小模型的回答品質通常不如聯網呼叫的大模型，多模態、複雜推理這類能力差距更明顯。務實的做法是先明確業務能接受的回答品質下限，再倒推選多大的模型，而不是預設越大越好——很多內部知識問答場景，中等規模模型加上紮實的檢索就夠用了。

還要注意更新維護：離線環境拿不到自動更新，模型升級、安全補丁都得手動走流程，要把這塊維運工作量納入長期成本，而不只看一次性搭建。

沒有研發團隊，預算有限，最低成本怎麼起步？

不要從自建 RAG 起步。從零搭一套檢索加生成的鏈路，光是把切分、嵌入、檢索、重排、生成各環節調到能用，就需要持續投入工程時間，這恰恰是沒有研發團隊的團隊最缺的資源。

更合理的起步路徑是用低程式碼編排或現成的開源問答產品，把精力放在資料和驗收上，而不是基礎設施上。具體可以這樣做：先挑一個邊界清晰、文件相對規整的場景做試點，比如產品手冊問答或內部制度查詢，範圍越窄越容易做出可感知的效果；把這批文件整理乾淨——去掉過期內容、統一格式、補上缺失的標題層級，這一步的投入回報遠高於折騰模型參數。

驗證階段優先用按量付費的線上模型介面，先跑通流程、確認效果，再決定要不要為了合規或成本切換到自建。這樣能把前期投入壓到很低，避免在還沒驗證價值時就買下一堆固定資產。

一個反直覺但實用的提醒：起步階段最該花時間的不是選型，而是準備一份覆蓋典型問法的測試問題清單。有了這份清單，無論用哪種方案，你都能客觀判斷它到底能不能用，也能在後續替換工具時快速回歸驗證——這比任何選型糾結都更能幫你少走彎路。