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