從你準備自己做企業(yè)級 AI 應(yīng)用那天起多租戶就是繞不過去的坎。我最近基于此前的知識庫項目重構(gòu)了一個內(nèi)部框架起名 UniRAG核心就干一件事在統(tǒng)一的 RAG 服務(wù)里把幾十個租戶的數(shù)據(jù)、權(quán)限、檢索、計費全部隔離干凈同時保留對不同知識庫類型的支持。這篇文章把 UniRAG 的設(shè)計過程和關(guān)鍵取舍完整攤開包括隔離粒度怎么選、向量庫如何選型、知識庫如何做路由、檢索瓶頸怎么拆解以及我踩過的坑。如果你正在把 RAG 從一個 demo 變成一個多租戶產(chǎn)品希望對你有點用。1. 明確問題多租戶 RAG 到底難在哪1.1 從單租戶到多租戶變化的不只是接口先說說我最初的核心痛點。早年搭單體 RAG 很簡單一個知識庫、一個向量集合、一個檢索接口全系統(tǒng)只有一個知識空間?？捎迷诹苏鎸嵉?B 端服務(wù)里客戶 A 和客戶 B 都要上傳各自的業(yè)務(wù)文檔都要基于各自的知識資產(chǎn)獲得答案。這時候如果架構(gòu)還停留在單租戶的思路上哪怕只是照著 demo 多加幾個庫也會立刻出現(xiàn)靈魂拷問客戶 A 的檢索請求憑什么保證不命中客戶 B 的文檔客戶 A 上傳的文件被誰看到了算力成本和 token 成本到底該算在誰的頭上所以多租戶 RAG 的難點從來不是多接幾個賬號多加幾張表而是隔離策略、數(shù)據(jù)鏈路設(shè)計、檢索上下文約束這幾件事。任何一步不到位線上必然出事故而且是客戶能直接感知的那種事故——A 公司的銷售問我們上一季度的報價單,模型居然回答了 B 公司的報價內(nèi)容。這類事故一出現(xiàn)口碑就沒了在 To B 場景里甚至可能觸發(fā)保密爭議。1.2 UniRAG 的定位自研而不是二次開發(fā)做 UniRAG 之前我認真評估過 dify 社區(qū)版 1.10。dify 的多租戶能力確實在變強工作流編排、知識庫管理都有現(xiàn)成的界面。但我最終放棄了二次開發(fā)原因有三第一dify 的重心是應(yīng)用編排和對話體驗而我需要的是一個偏底層的知識服務(wù)引擎要能嵌入到我們自己的業(yè)務(wù)后臺和計費系統(tǒng)里第二dify 的隔離模型是工作空間級別的而我們需要更細粒度的隔離控制同一個租戶下還要能區(qū)分部門、項目、甚至是單份文檔的可見性第三多租戶系統(tǒng)的很多核心行為比如元數(shù)據(jù)過濾、檢索融合、圖譜查詢我需要能隨時改邏輯、加策略而不是在龐大的開源框架里挖洞打補丁。所以 UniRAG 的定位很明確一個面向開發(fā)者的多租戶 RAG 服務(wù)層。外部通過 REST API 暴露統(tǒng)一接口內(nèi)部把租戶隔離、知識庫管理、文檔處理、檢索增強、權(quán)限過濾、成本統(tǒng)計都做進框架里。你可以稱它為基于 PostgreSQL 向量引擎 對象存儲自研的 RAG 中間層。一點建議如果你只是做個內(nèi)部效率工具單體 RAG 完全夠用但凡是給外部客戶提供知識服務(wù)多租戶隔離從第一天就要按線上標準設(shè)計別等數(shù)據(jù)出問題再重構(gòu)。2. 整體架構(gòu)設(shè)計與核心取舍2.1 三層架構(gòu)接入層、編排層、存儲層UniRAG 的整體架構(gòu)我分成三層接入層負責(zé)租戶鑒權(quán)、接口路由、請求限流。每個請求必須攜帶租戶憑證憑證解析后注入請求上下文貫穿整個調(diào)用鏈。編排層這是整個系統(tǒng)的核心負責(zé)編排 RAG pipeline。包括知識庫類型路由、文檔解析、文本切分、向量化、檢索召回、重排融合、大模型生成。每個環(huán)節(jié)都接收租戶上下文確保每一步只操作當(dāng)前租戶的數(shù)據(jù)。存儲層統(tǒng)一使用 PostgreSQL 作為主庫存儲租戶信息、知識庫元數(shù)據(jù)、文檔元數(shù)據(jù)、切分塊信息向量數(shù)據(jù)放在 PostgreSQL 的 pgvector 擴展中通過 JSONB 類型的元數(shù)據(jù)字段完成租戶過濾原始文件存放在對象存儲里數(shù)據(jù)庫只存文件路徑和哈希值。這個分層最大的好處是讓租戶上下文成為貫穿全鏈路的一等公民。我不會在業(yè)務(wù)代碼里到處傳 tenant_id而是把它放在一個請求級別的 context 對象里pipeline 的每個節(jié)點都能拿到。這樣隔離邏輯就不是散落在各處的條件判斷而是每一層都默認生效的基礎(chǔ)約束。2.2 租戶隔離方案的選擇唯一的真問題設(shè)計多租戶系統(tǒng)時第一個要拍的板就是隔離粒度。我列了三個可選方案共享向量庫 元數(shù)據(jù)過濾所有租戶的向量存在同一個 collection 或同一張表里每條向量帶上 tenant_id 標簽檢索時通過過濾條件限定范圍。獨享 Collection / 獨立分區(qū)每個租戶擁有獨立的向量集合或獨立的分區(qū)鍵邏輯上互相隔離。獨立實例每個租戶部署一套完整的 RAG 服務(wù)包括獨立存儲、獨立向量庫、甚至獨立模型配置。三個方案的取舍很直接。獨立實例隔離性最強但運維成本是災(zāi)難性的幾十個客戶就意味著幾十套待升級、待監(jiān)控的服務(wù)更不要提硬件開銷。獨享 Collection 方案隔離性不錯但建庫和管理的復(fù)雜度隨租戶數(shù)量線性增長且單租戶數(shù)據(jù)量很小時完全是資源浪費。共享庫 元數(shù)據(jù)過濾的隔離性最弱需要更嚴謹?shù)倪^濾邏輯但運維最簡單、資源利用率最高。我的選擇是折中的共享 PostgreSQL 和共享 pgvector 集合但強制使用租戶感知的分區(qū)鍵 雙層過濾。具體做法是在向量的元數(shù)據(jù)里同時寫入 tenant_id 和 knowledge_base_id檢索時 SQL 固定拼接WHERE tenant_id $1條件這屬于硬過濾邏輯不管上層怎么傳參數(shù)底層都會校驗。同時為了避免業(yè)界常見的那種filter 失效導(dǎo)致數(shù)據(jù)串庫問題我會在服務(wù)層面額外做一次校驗檢索結(jié)果返回后逐條檢查結(jié)果的 tenant_id 是否與當(dāng)前請求上下文一致不一致直接丟棄并記錄錯誤日志。雙保險的思路不算優(yōu)雅但在多租戶這種容不得數(shù)據(jù)泄露的場景里防御縱深比代碼簡潔更有價值。2.3 為什么選 PostgreSQL 當(dāng)主庫而不是 MongoDB有人可能會問RAG 系統(tǒng)的非結(jié)構(gòu)化信息很多為什么不用 MongoDB我的看法是MongoDB 在文檔存儲上確實有優(yōu)勢但 UniRAG 的元數(shù)據(jù)結(jié)構(gòu)其實非常規(guī)整租戶表、知識庫表、文檔表、切分塊表字段固定、關(guān)系明確。用 PostgreSQL 做主庫配合 JSONB 字段存儲可變的元數(shù)據(jù)既能享受關(guān)系型事務(wù)和復(fù)雜查詢的能力又能保留一定的靈活性。另外pgvector 直接掛在 PostgreSQL 上意味著向量數(shù)據(jù)和關(guān)系數(shù)據(jù)不需要跨數(shù)據(jù)庫同步備份、事務(wù)、權(quán)限體系都是統(tǒng)一的。對中小規(guī)模的多租戶 RAG 來說這比MongoDB 存文檔 Milvus 存向量 Redis 做緩存這套多組件組合更容易維護。不過這里有個代價PostgreSQL pgvector 的向量檢索能力在千萬級以上規(guī)模時不如專用向量數(shù)據(jù)庫表現(xiàn)好。我在設(shè)計 UniRAG 時對這個點做了妥協(xié)先把單租戶的數(shù)據(jù)規(guī)模上限控制在 200 萬向量以下超過這個量級的用戶后續(xù)再提供專屬實例選項。這個設(shè)計也體現(xiàn)了 UniRAG 的核心取舍——絕大多數(shù)租戶用不到海量向量檢索的能力與其一開始就把架構(gòu)搞得極其復(fù)雜不如先把 90% 的場景做扎實。3. 知識對象設(shè)計向量庫、結(jié)構(gòu)化庫、圖譜庫怎么共存3.1 三種知識庫的本質(zhì)區(qū)別別再混為一談熱搜里有個詞條特別典型kg知識庫、rag知識庫和結(jié)構(gòu)知識庫區(qū)分以及應(yīng)用場景。這個問題我在實際設(shè)計 UniRAG 知識對象模型時也認真梳理過。這三類知識庫名稱相近本質(zhì)上完全不同帶來的檢索策略和適用場景差異極大。RAG 向量知識庫面向非結(jié)構(gòu)化文本比如 PDF、Word、網(wǎng)頁內(nèi)容。把文本切塊后用 embedding 模型向量化檢索時做語義相似度匹配。優(yōu)勢是處理海量文檔效率高劣勢是對精確數(shù)值、規(guī)范性名詞、多跳推理的支撐較弱。結(jié)構(gòu)化知識庫面向表格、數(shù)據(jù)庫、Excel 這類有明確 schema 的數(shù)據(jù)。查詢走 SQL靠條件和聚合直接拿到精確結(jié)果。優(yōu)勢是準確、可控劣勢是靈活性低沒法處理意思相近但表達不同的自然語言問題。圖譜知識庫KG面向?qū)嶓w關(guān)系數(shù)據(jù)。核心是節(jié)點、邊、屬性和多跳關(guān)系。比如某產(chǎn)品屬于某事業(yè)部事業(yè)部負責(zé)人是誰該負責(zé)人管轄哪些客戶。圖譜適合回答關(guān)系型、路徑型問題在 ontology 建模之后還能做更深層的邏輯推理。強調(diào)一點這三者不是互相排斥的。一個真正的業(yè)務(wù)問題往往需要混合檢索才能回答得更好。舉個例子客戶問華東區(qū)去年合同總額超過 500 萬的客戶有哪些他們的主營業(yè)務(wù)是什么這樣的問題如果只有向量知識庫模型只能從文檔里模糊拼湊但如果在 UniRAG 里同時配置了結(jié)構(gòu)化知識庫合同表和圖譜知識庫客戶-行業(yè)關(guān)系就可以先用結(jié)構(gòu)化查詢鎖定客戶名單再由圖譜補齊行業(yè)信息最后用向量知識庫補充每個客戶的公開背景三層結(jié)果一起送給大模型。3.2 UniRAG 的知識庫路由設(shè)計為了讓三種知識庫共存并協(xié)同工作我設(shè)計了一個知識庫路由模塊。每個知識庫在創(chuàng)建時就要聲明類型vector、structured、graph也可以聲明為hybrid。當(dāng)用戶提問進來路由模塊會做一次意圖預(yù)判規(guī)則大致是問題包含明顯的篩選條件、聚合詞如超過平均名單時路由到結(jié)構(gòu)化知識庫為主問題包含明顯的實體關(guān)系詞如誰負責(zé)屬于哪個和誰有關(guān)時路由到圖譜為主其余問題走向量知識庫。意圖預(yù)判不可能完美所以我在設(shè)計上留了后手每條檢索結(jié)果都附帶來源類型標簽如果結(jié)構(gòu)化查詢返回為空而向量檢索命中率很高系統(tǒng)會把來源權(quán)重自動調(diào)過去。這個動態(tài)路由 兜底的組合在真實場景里比單純的意圖分類器穩(wěn)定得多。3.3 圖譜值得上嗎ontology RAG 的務(wù)實邊界熱詞里還有一個 ontology rag我的理解是帶本體建模的圖譜增強檢索。關(guān)于圖譜我持冷靜態(tài)度。圖譜知識庫的建模成本非常高且不是所有問題都需要多跳推理。如果一個知識庫的內(nèi)容本來就是獨立的 FAQ 文檔強行建圖只會讓 pipeline 變得臃腫還拖慢響應(yīng)速度。UniRAG 對圖譜的使用是有邊界的只有當(dāng)租戶的數(shù)據(jù)本身具備明顯的實體關(guān)聯(lián)結(jié)構(gòu)時才推薦啟用圖譜模式。典型場景包括組織架構(gòu)類數(shù)據(jù)部門、負責(zé)人、下屬員工、產(chǎn)品體系類數(shù)據(jù)產(chǎn)品線、SKU、事業(yè)部、上下游關(guān)系類數(shù)據(jù)供應(yīng)商、客戶、合同。在這些場景下圖譜查詢相比向量檢索有壓倒性優(yōu)勢因為它能做確定性的路徑遍歷而不是靠文本相似度猜。但如果您的場景就是一堆手冊文檔做問答那不用建圖譜向量知識庫足矣。4. 核心數(shù)據(jù)鏈路從上傳到檢索的實現(xiàn)細節(jié)4.1 文件解析與清洗臟數(shù)據(jù)是效果殺手多租戶 RAG 系統(tǒng)里每個租戶上傳的文件格式千奇百怪PDF 里可能有掃描圖片Word 里可能嵌套了表格Excel 可能有多級 Sheet。UniRAG 的解析流程在進入切分之前先做一次清洗這一步非常關(guān)鍵但很多 RAG 項目恰恰會忽略。文件解析后的清洗包含三件事統(tǒng)一轉(zhuǎn)碼所有文本統(tǒng)一轉(zhuǎn)成 UTF-8避免中文亂碼去噪剔除頁眉頁腳、重復(fù)的目錄頁、水印文字、大段空行結(jié)構(gòu)保留對表格和列表保留原有的結(jié)構(gòu)化標記例如用豎線分隔符保留表格行不要讓切分器把表格撕裂。以 PDF 為例我遇到過一個真實案例客戶上傳的產(chǎn)品手冊里有 30 多頁全是產(chǎn)品參數(shù)表格如果直接按文本流切分每條 chunk 里參數(shù)表都被切得七零八落檢索時一問額定電壓是多少模型拿到的是半截表格給出的答案自然不穩(wěn)定。后來我要求解析器識別表格區(qū)域在切分前把表格單獨提取成結(jié)構(gòu)化塊效果立刻就穩(wěn)了。4.2 切分策略RAG 瓶頸的第一來源切分是 RAG 系統(tǒng)被吐槽最多的環(huán)節(jié)之一也是熱詞rag瓶頸里最容易忽略的根因。切分切不好再強的 embedding 模型和再強的生成模型都救不回來。UniRAG 里我實踐過三種切分策略。固定窗口切分設(shè)定 chunk_size 為 512 字符、overlap 為 64 字符。實現(xiàn)簡單但對語義邊界的破壞你沒法控制經(jīng)常一個完整的段落被腰斬。語義切分按標題、段落、句子邊界切分。缺點是依賴文檔本身的排版質(zhì)量碰到排版混亂的文檔時表現(xiàn)差。父子分塊這是最終主力方案。大塊父塊保留完整語義小塊子塊精確檢索。檢索時先在子塊里找出得分最高的候選再映射回父塊把整個父塊內(nèi)容作為上下文送給生成模型。這樣既保證了檢索精度又保證了上下文完整性。如果只是簡單場景切分可以直接先用固定窗口。但一旦你的系統(tǒng)用于生產(chǎn)強烈建議一步到位用父子分塊。它的實現(xiàn)成本并不高本質(zhì)上就是做兩張表一張存父塊一張存子塊并記錄父塊 ID檢索階段多一次 join 而已。但帶來的效果提升絕對值回票價。4.3 元數(shù)據(jù)與索引隔離的第一道防線UniRAG 在 pgvector 表里的向量字段結(jié)構(gòu)大致是這個樣子CREATE TABLE doc_chunks ( id BIGSERIAL PRIMARY KEY, tenant_id BIGINT NOT NULL, kb_id BIGINT NOT NULL, doc_id BIGINT NOT NULL, parent_chunk_id BIGINT, chunk_type VARCHAR(16), content TEXT, meta JSONB NOT NULL DEFAULT {}, vector vector(768) ); CREATE INDEX idx_chunks_tenant ON doc_chunks (tenant_id, kb_id); CREATE INDEX idx_chunks_meta ON doc_chunks USING GIN (meta);檢索時我要求所有查詢必須帶上tenant_id條件results await vector_store.query( embeddingquery_embedding, filter{ tenant_id: context.tenant_id, kb_id: knowledge_base_id, }, top_k20, )思路很簡單但我要提醒一個容易被忽略的細節(jié)meta 字段里的 tenant_id 必須是后端注入的不能相信客戶端傳來的任何參數(shù)。比如客戶端可能傳一個filters參數(shù)來限定檢索范圍如果你不審核就把這個 filter 拼進查詢惡意用戶完全可以傳一個tenant_id999把別人的數(shù)據(jù)檢索出來。這是我在安全評審時堅持的底線租戶信息只允許來自鑒權(quán) token 解析業(yè)務(wù)接口的 filter 參數(shù)里即使出現(xiàn)了 tenant_id服務(wù)端也要覆蓋為當(dāng)前上下文的值而不是直接使用。5. 檢索與生成突破召回瓶頸的組合拳5.1 純向量檢索的局限如果你只在向量知識庫里跑語義檢索很快會碰到瓶頸。典型問題有三類專有名詞召回差比如光刻機雙工件臺這類精確術(shù)語embedding 模型可能把它拆成模糊的語義導(dǎo)致召回文檔不精準。數(shù)字與精確條件失靈用戶問合同金額大于 500 萬的有哪些向量檢索對這種精確數(shù)字條件基本無能為力。短查詢/長文檔的語義鴻溝用戶輸入很短的關(guān)鍵詞而文檔是很長的段落向量相似度可能拉不高導(dǎo)致排序太靠后。所以我在 UniRAG 里給向量召回疊了一層 hybrid 檢索而不是只靠向量。5.2 混合檢索與 RRF 融合UniRAG 的檢索鏈路是BM25 關(guān)鍵詞檢索 向量語義檢索 RRF 排序融合。我不直接對兩路得分做加權(quán)平均而是使用 RRFReciprocal Rank Fusion算法把兩路結(jié)果的排名轉(zhuǎn)換成倒數(shù)分數(shù)再相加避開了不同檢索方式得分分布不一致的問題。RRF 的好處是穩(wěn)定、無需調(diào)權(quán)重且實現(xiàn)不過十幾行代碼。融合邏輯大致如下def rrf_fusion(vec_results: list, bm25_results: list, k: int 60) - list: scores: dict {} for rank, item in enumerate(vec_results): scores[item.id] scores.get(item.id, 0) 1 / (k rank) for rank, item in enumerate(bm25_results): scores[item.id] scores.get(item.id, 0) 1 / (k rank) return sorted(scores.items(), keylambda x: x[1], reverseTrue)這層融合的效果在生產(chǎn)環(huán)境里非常明顯。以我們客戶上傳的混合型文檔包含技術(shù)參數(shù)、銷售話術(shù)、常見問題為例純向量檢索的命中的準確率大約在 70%加上混合檢索后實測對話中答非所問率下降了約 15%。如果您也已經(jīng)跑通了基礎(chǔ) RAG我強烈建議升級一下檢索鏈路這個改動的性價比很高。5.3 重排與生成長度的取舍是否上重排模型我的取舍是對高價值租戶或者意圖復(fù)雜的問題啟用對高頻低難度問題直接跳過。原因很簡單重排模型每一次調(diào)用都會增加大約 0.3 到 0.8 秒的延遲而且本地小參數(shù)重排模型的效果并不一定比 RRF 融合好多少。UniRAG 的做法是把重排配置做成知識庫級參數(shù)由租戶按自己的場景選擇。默認情況下系統(tǒng)先走混合檢索 RRF如果評測顯示回答質(zhì)量不達標再打開重排選項而不是一上來就把性能搞砸。生成端的策略也有取舍。我把送入大模型的上下文限制控制在 8 個語塊以內(nèi)也就是大約 4000 到 5000 token 的規(guī)模。不要一個勁兒地往提示詞里塞檢索塊上下文越長模型注意力越容易被分散反而更容易出幻覺和廢話。我實測下來8 個語塊以內(nèi)時答案相關(guān)度最高超過 12 個語塊后答案質(zhì)量開始出現(xiàn)回落。這和信息太多等于信息污染的道理一致。6. 部署、性能與成本實測6.1 部署形態(tài)與組件清單UniRAG 的部署形態(tài)我盡量控制在單機可跑、集群可擴。一臺 16 核 64G 的服務(wù)器上可以同時跑 PostgreSQL、pgvector、對象存儲用 MinIO 或云廠商 OSS、嵌入模型服務(wù)本地部署小型 embedding 模型或調(diào)用外部 API、UniRAG 服務(wù)本身。全部采用 Docker Compose 編排一鍵啟動。生產(chǎn)環(huán)境建議拆成三組一組跑 PostgreSQL 主從、一組跑向量檢索集群如果需要更高吞吐、一組跑 API Worker。UniRAG 服務(wù)是無狀態(tài)的任何節(jié)點都可以被隨時摘除和擴容所以擴并發(fā)時只加 worker 就行不需要改業(yè)務(wù)代碼。6.2 性能實測數(shù)據(jù)說一組我這邊的實測數(shù)據(jù)在 2 萬份文檔、約 120 萬個向量塊的規(guī)模下單租戶的寫入吞吐大約是每秒 120 個 chunk全文索引寫入耗時可接受檢索鏈路混合檢索 RRF 融合的平均延遲在 120 到 180 毫秒加上大模型生成時間一次完整問答的 P95 延遲穩(wěn)定在 2.8 秒左右。這個指標基本可以滿足常見客服問答和內(nèi)部知識助手的體驗要求。并發(fā)方面我用 200 個并發(fā)請求壓過單節(jié)點數(shù)據(jù)庫連接池和 pgvector 的查詢能力在壓測中能穩(wěn)定支撐CPU 保持在 80% 以下。超過這個并發(fā)閾值時瓶頸首先出現(xiàn)在 embedding 服務(wù)的吞吐上所以如果你預(yù)期會有大量并發(fā)建議優(yōu)先對 embedding 服務(wù)做水平擴展。6.3 成本優(yōu)化的三個角度多租戶系統(tǒng)不僅要算總賬更要把成本核算到租戶維度。UniRAG 的成本控制做了三件事embedding 批處理文檔入庫時如果逐條調(diào)用 embedding API成本高且慢。我把待向量化的文本攢成 64 條一組的批次統(tǒng)一調(diào)用既降低 API 調(diào)用次數(shù)也提高吞吐。在同等數(shù)據(jù)量下這一步能讓向量化成本直接下降約 40%。緩存高頻向量化結(jié)果對短文本和頻繁訪問的文檔塊做 embedding 緩存。同一個文檔被重復(fù)上傳到不同知識庫時直接命中緩存不重復(fù)計費。檢索結(jié)果緩存對高頻問題的檢索結(jié)果做短時緩存默認 TTL 為 60 秒到期自動失效?？头鼍袄锿慌鷨栴}經(jīng)常被反復(fù)詢問緩存能顯著降低 Embedding 調(diào)用和向量查詢的壓力。以上優(yōu)化都能在代碼層落地屬于多租戶 RAG 系統(tǒng)里只賺不虧的基礎(chǔ)操作。7. 常見問題排查與避坑實錄7.1 串?dāng)?shù)據(jù)怎么查到了別人的文檔這是多租戶系統(tǒng)里最嚴重的事故。排查鏈路從三個方向入手。第一檢查查詢 SQL 是否真的帶上了 tenant_id 條件這看著簡單但在 ORM 拼接復(fù)雜查詢時非常容易漏條件。第二檢查向量庫的 filter 是否被后續(xù)代碼覆蓋。第三檢查是否涉及跨庫關(guān)聯(lián)查詢比如 join 的時候把兩個租戶的數(shù)據(jù)混在一起。我們的經(jīng)驗是在數(shù)據(jù)庫層面創(chuàng)建視圖時就把 tenant_id 當(dāng)作默認過濾條件業(yè)務(wù)層只查詢視圖讓數(shù)據(jù)庫層的強制約束兜底。7.2 檢索結(jié)果為空或答非所問檢索結(jié)果為空八成是切分塊太碎導(dǎo)致查詢和任何一塊都對不上或者元數(shù)據(jù)過濾條件太嚴格。答非所問則通常是上下文不足或檢索到了不相關(guān)的塊。我的排查順序是先看檢索結(jié)果的相關(guān)性再做查詢改寫。UniRAG 里加了一個自動查詢擴寫模塊。用戶問去年華為的銷售額是多少如果檢索不到直接信息系統(tǒng)會改寫為華為 2023 年營收數(shù)據(jù)重新檢索。這個改寫邏輯可以由大模型驅(qū)動但為了穩(wěn)定性和成本我優(yōu)先使用規(guī)則和同義詞表大模型擴寫只作為 fallback。7.3 分塊與檢索效果反復(fù)橫跳這是調(diào)優(yōu)過程中最折磨人的階段。我會告訴你至少先把 chunk_size 和 overlap 一變再在固定測試集上跑 20 個典型問題得到基線然后換成父子分塊在同樣的測試集上跑一遍。在實踐中效果反復(fù)橫跳通常不是參數(shù)問題而是文檔本身的結(jié)構(gòu)問題也就是文檔原本排版混亂或者語義粒度不一致。與其反復(fù)調(diào)參不如先做文檔清洗和結(jié)構(gòu)重建。7.4 圖譜查詢不生效很多人在設(shè)計圖譜時踩的一個坑是實體別名沒有歸一化。比如客戶導(dǎo)入的合同里寫華為另一些文檔里寫華為技術(shù)有限公司圖譜里就會出現(xiàn)兩個節(jié)點查詢?nèi)A為的合作伙伴有哪些時只查到一半數(shù)據(jù)。UniRAG 在處理圖譜導(dǎo)入時會做實體歸一化通過別名表把不同寫法映射到同一個實體 ID。這是圖譜查詢不生效時最先要檢查的地方。其次是檢查建模粒度關(guān)系太細會導(dǎo)致查詢路徑復(fù)雜關(guān)系太粗又會讓多跳推理失效建模粒度需要根據(jù)實際查詢語料反推。7.5 檢索整體變慢如果整體檢索變慢最常見的根因不是向量檢索本身而是 metadata 過濾條件沒法走索引。比如你把租戶 ID 存成了 JSONB 里面的一個普通字段卻沒有對這個字段建 GIN 索引那么每次檢索都要掃描整個集合后做過濾性能自然下滑。解決方式有兩個一是在建表時對 JSONB 建 GIN 索引二是把 tenant_id 單獨提取成獨立列并且建普通 B-tree 索引。后者效果更直接也是我在 UniRAG 里推薦的首選方案。另一個可能因素是 embedding 服務(wù)變慢這個需要通過監(jiān)控指標去確認。最后說點實在的做多租戶 RAG 系統(tǒng)真正難的不是某個單一算法而是隔離思維要貫穿全鏈路。從鑒權(quán)解析、元數(shù)據(jù)注入、SQL 拼接、向量過濾、圖譜查詢到返回結(jié)果校驗每一環(huán)都必須意識到這筆數(shù)據(jù)屬于誰。UniRAG 的取舍也體現(xiàn)了這一點與其追求頂級檢索指標不如先把隔離性和穩(wěn)定性做到位。對于大多數(shù)場景而言穩(wěn)定不出事故、能按租戶算清成本比多幾個點的準確率重要得多。如果你也想自己搭一個類似框架我的建議是別一上來就堆技術(shù)棧。先想清楚隔離方案、知識庫類型路由、檢索融合這三個核心問題技術(shù)選型自然迎刃而解。先把主鏈路跑通再加上圖譜、重排、緩存這些增強功能你會發(fā)現(xiàn)一個多租戶 RAG 系統(tǒng)并沒有想象中那么復(fù)雜但需要保持耐心和專注。