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