前段時(shí)間在調(diào)一套基于Dify的知識(shí)庫(kù)問(wèn)答遇到一個(gè)很典型的問(wèn)題向量檢索召回的前幾條結(jié)果里正確答案經(jīng)常排在第3、第4位。查了一圈之后把目光放到了重排序Rerank上最后是用Xinference容器跑了一個(gè)Reranker模型再把服務(wù)地址配置到Dify的模型供應(yīng)商里檢索精度明顯改善。這條鏈路不算復(fù)雜但中間有幾步挺容易卡住容器端口、模型UID、Dify側(cè)Rerank模型綁定任何一環(huán)對(duì)不上都會(huì)讓人懷疑人生。這篇就把這套做法完整寫(xiě)一遍給正在用Dify搭RAG、或者想給現(xiàn)有知識(shí)庫(kù)加精排能力的同學(xué)一個(gè)可以直接照做的參考。1. 整體思路為什么用Docker部署Reranker1.1 Rerank在RAG流程里到底解決什么問(wèn)題大多數(shù)RAG應(yīng)用的第一階段是向量檢索也就是把用戶問(wèn)題和知識(shí)庫(kù)里的文本片段都轉(zhuǎn)成向量然后按相似度倒排召回。這個(gè)過(guò)程叫召回Recall特點(diǎn)是快、覆蓋面廣但精度不高。它只能保證“相關(guān)的內(nèi)容大概率在結(jié)果里”不能保證“最相關(guān)的內(nèi)容一定排最前面”。原因也很簡(jiǎn)單向量檢索通常用雙塔模型Bi-Encoder問(wèn)題和文檔被獨(dú)立編碼成兩個(gè)向量再做點(diǎn)積或余弦相似度。在這種結(jié)構(gòu)里問(wèn)題和文檔的交互信息是缺失的它只能感知語(yǔ)義相似感知不到細(xì)粒度的匹配關(guān)系。第二階段是精排Rank也就是Rerank。這里用的是交叉編碼器Cross-Encoder做法是把用戶問(wèn)題和候選文檔拼成一個(gè)完整的輸入喂給模型做深度交互編碼最后輸出一個(gè)相關(guān)性分?jǐn)?shù)。交叉編碼器能看到“問(wèn)題里的某個(gè)關(guān)鍵詞到底有沒(méi)有在文檔對(duì)應(yīng)位置被回應(yīng)”這種級(jí)別的關(guān)系所以打分精度通常比向量相似度高一截。我用一個(gè)生活化的類(lèi)比來(lái)理解向量檢索是海選從十萬(wàn)份簡(jiǎn)歷里篩出20個(gè)候選人Rerank是評(píng)委面試對(duì)每個(gè)候選人單獨(dú)打分最后按分?jǐn)?shù)決定排名。沒(méi)有評(píng)委的時(shí)候就只能按海選材料上的幾個(gè)標(biāo)簽排序誤差必然存在。Dify默認(rèn)的檢索流程里召回之后怎么排序直接決定最終答案質(zhì)量不把Rerank接上前面向量模型再好也容易在最后一公里翻車(chē)。1.2 為什么把Reranker拆成獨(dú)立服務(wù)再接DifyDify本身支持很多模型供應(yīng)商里面也有Rerank模型入口。那為什么不直接在Dify里配一個(gè)在線Rerank API非要自己用Docker跑一個(gè)Xinference我當(dāng)時(shí)的考慮有幾點(diǎn)數(shù)據(jù)隱私和可控性。知識(shí)庫(kù)內(nèi)容可能涉及內(nèi)部資料不想把文本片段發(fā)到外部API做重排。本地部署意味著所有請(qǐng)求都留在自己的服務(wù)邊界內(nèi)。模型統(tǒng)一管理。團(tuán)隊(duì)里同時(shí)有Embedding、Rerank、對(duì)話模型的需求用Xinference統(tǒng)一暴露OpenAI兼容接口Dify、其他應(yīng)用都可以復(fù)用不用每個(gè)系統(tǒng)各搞一套模型服務(wù)。進(jìn)程解耦。模型推理本身吃資源如果直接塞進(jìn)Dify所在的進(jìn)程或同臺(tái)機(jī)器裸跑內(nèi)存和顯存容易被擠爆。Docker容器可以把模型服務(wù)的資源邊界限制住壞了重拉一個(gè)容器就行不影響主應(yīng)用。環(huán)境一致性。Xinference依賴的Python包、CUDA版本、模型文件路徑在容器里都是固定的一套換機(jī)器部署不用重新踩一遍環(huán)境坑。這件事的本質(zhì)是把“模型如何運(yùn)行”和“應(yīng)用如何使用模型”拆開(kāi)了。Dify只關(guān)心一個(gè)符合OpenAI規(guī)范的服務(wù)地址而Xinference容器負(fù)責(zé)模型加載、請(qǐng)求排隊(duì)、顯存管理。后續(xù)換模型、升級(jí)版本都不需要?jiǎng)覦ify的配置改Xinference側(cè)即可。1.3 方案選型對(duì)比我也對(duì)比過(guò)其他做法比如直接在Dify里配云廠商的Rerank API或者自己寫(xiě)一個(gè)Python服務(wù)封裝模型。把幾個(gè)方案的差異列在下面方案部署成本數(shù)據(jù)隱私擴(kuò)展性穩(wěn)定性云廠商Rerank API低只需填Key文本需外發(fā)受限于廠商配額依賴外部網(wǎng)絡(luò)自己寫(xiě)Python服務(wù)中要處理依賴和進(jìn)程數(shù)據(jù)不出內(nèi)網(wǎng)需自行實(shí)現(xiàn)并發(fā)和調(diào)度看代碼質(zhì)量容易進(jìn)程崩潰Xinference裸機(jī)部署中要配Python環(huán)境數(shù)據(jù)不出內(nèi)網(wǎng)一般環(huán)境變動(dòng)容易出問(wèn)題Xinference Docker部署中低一條命令起步數(shù)據(jù)不出內(nèi)網(wǎng)好可做端口映射和資源限制高容器隔離自恢復(fù)最后選Docker方式純粹是經(jīng)驗(yàn)和成本權(quán)衡的結(jié)果同樣要搞模型推理環(huán)境容器化是最不容易出幺蛾子的方式。2. 關(guān)鍵選型模型與部署參數(shù)2.1 Reranker模型的核心原理與選擇邏輯先明確一點(diǎn)Rerank模型的輸入輸出和Embedding模型完全不同。Embedding模型輸入是一段文本輸出是一個(gè)向量Rerank模型輸入是“問(wèn)題候選文檔”的對(duì)輸出是一個(gè)相關(guān)性分?jǐn)?shù)。這個(gè)分?jǐn)?shù)不是概率而是一個(gè)可比較的標(biāo)量范圍取決于模型本身有些模型輸出0到1有些輸出負(fù)無(wú)窮到正無(wú)窮但用法都一樣對(duì)同一批候選文檔按分?jǐn)?shù)從高到低排序取TopK。我這次選模型時(shí)主要考慮了三類(lèi)bge系列的小模型。參數(shù)量小、速度極快CPU都能跑Rerank效果在通用場(chǎng)景夠用是性價(jià)比最高的選擇。中杯模型。支持中文和英文混合場(chǎng)景對(duì)長(zhǎng)文檔的處理能力更強(qiáng)適合知識(shí)庫(kù)片段較長(zhǎng)的場(chǎng)景。大杯模型或更重的開(kāi)源重排模型。效果上限高但顯存占用和單次推理延遲都上來(lái)了適合對(duì)精度要求極高、候選集較大的場(chǎng)景。具體選哪個(gè)要看你的知識(shí)庫(kù)規(guī)模和機(jī)器資源。我的實(shí)踐樣本是內(nèi)部知識(shí)庫(kù)文檔偏技術(shù)手冊(cè)和項(xiàng)目文檔片段的平均長(zhǎng)度在200到500字之間混合中英文比較多所以選了中杯模型。如果你的文檔全英文、片段又短小杯模型也能打如果文檔偏專(zhuān)業(yè)法規(guī)、合同類(lèi)建議直接上大杯模型或更大規(guī)模的重排模型。2.2 顯存與資源估算方法模型部署最容易被低估的是顯存占用。粗算公式很簡(jiǎn)單模型權(quán)重顯存約等于參數(shù)量乘以精度字節(jié)數(shù)。FP16下每個(gè)參數(shù)占2字節(jié)所以參數(shù)量約0.28B的模型權(quán)重約0.56GB加推理緩存和框架開(kāi)銷(xiāo)實(shí)際預(yù)留1到2GB顯存比較穩(wěn)。參數(shù)量約0.57B的模型權(quán)重約1.1GB實(shí)際預(yù)留2到3GB顯存。如果再算上并發(fā)請(qǐng)求Transformer的KV Cache建議按兩倍權(quán)重顯存再往上加。如果你是純CPU部署內(nèi)存同理建議至少給模型留4GB內(nèi)存空間否則加載大模型時(shí)容易OOM。我這個(gè)方案選的中杯模型在CPU上單條查詢幾十條候選文檔延遲大概幾百毫秒到一兩秒可接受如果上了GPU那就是毫秒級(jí)。2.3 端口、模型目錄與版本規(guī)劃部署前先規(guī)劃三個(gè)東西端口Xinference默認(rèn)監(jiān)聽(tīng)9997端口容器映射就選9997Dify側(cè)配置也用這個(gè)端口。你當(dāng)然可以換但換掉之后所有文檔、示例、API地址都要跟著改沒(méi)必要。模型緩存目錄Xinference首次加載模型時(shí)會(huì)下載權(quán)重文件默認(rèn)放在容器內(nèi)的/root/.xinference目錄。這個(gè)目錄必須掛載到宿主機(jī)否則容器刪掉重建模型要重新下載一遍尤其在大模型文件有幾個(gè)GB時(shí)非常耽誤事。鏡像版本別上來(lái)就latest。latest雖然寫(xiě)著最新但保不齊哪天升級(jí)就改了默認(rèn)行為。我習(xí)慣先跑一次latest驗(yàn)證功能再把容器commit成一個(gè)固定的帶版本號(hào)的鏡像來(lái)用或者直接指定Xinference發(fā)布的具體版本號(hào)。這些看起來(lái)是小事但在后面的實(shí)際操作中會(huì)反復(fù)影響體驗(yàn)。3. 完整實(shí)操?gòu)腄ocker啟動(dòng)到接入Dify3.1 環(huán)境準(zhǔn)備與目錄規(guī)劃我本次的部署環(huán)境是一臺(tái)Linux服務(wù)器已經(jīng)裝好Docker有20GB可用磁盤(pán)空間CPU 8核內(nèi)存16GB沒(méi)有獨(dú)立GPU。這個(gè)配置跑中杯Rerank模型足夠。如果你有NVIDIA GPU命令會(huì)稍微多一點(diǎn)但思路一致。在宿主機(jī)上先建好模型目錄mkdir -p /data/xinference這個(gè)目錄將掛載到容器內(nèi)的 /root/.xinference里面存放模型權(quán)重、日志和臨時(shí)文件。之后不管容器怎么換模型文件都在宿主機(jī)上保留著不會(huì)重復(fù)下載。3.2 啟動(dòng)Xinference容器CPU版本的啟動(dòng)命令我實(shí)際用的是docker run -d \ --name xinference \ -p 9997:9997 \ -e XINFERENCE_MODEL_SRCmodelscope \ -v /data/xinference:/root/.xinference \ --restart unless-stopped \ xprobe/xinference:latest逐個(gè)解釋這些參數(shù)-d后臺(tái)運(yùn)行容器。--name xinference給容器起個(gè)固定名字方便后續(xù)docker logs、docker stop操作。-p 9997:9997把容器的9997端口映射到宿主機(jī)9997端口。Xinference的API和UI都走這個(gè)端口。-e XINFERENCE_MODEL_SRCmodelscope讓模型權(quán)重優(yōu)先從ModelScope鏡像源下載。如果你在海外部署或者網(wǎng)絡(luò)直連HuggingFace沒(méi)問(wèn)題可以刪掉這個(gè)環(huán)境變量。-v /data/xinference:/root/.xinference模型緩存目錄掛載這是重中之重的參數(shù)。沒(méi)有這個(gè)掛載容器一刪模型就全沒(méi)了。--restart unless-stopped容器意外退出時(shí)自動(dòng)拉起避免機(jī)器重啟后模型服務(wù)起不來(lái)。如果你有GPU則在命令里加一行--gpus all變成docker run -d \ --name xinference \ --gpus all \ -p 9997:9997 \ -e XINFERENCE_MODEL_SRCmodelscope \ -v /data/xinference:/root/.xinference \ --restart unless-stopped \ xprobe/xinference:latest容器起來(lái)之后可以看一下日志確認(rèn)端口正常監(jiān)聽(tīng)docker logs -f xinference看到類(lèi)似“Uvicorn running on http://0.0.0.0:9997”的輸出就說(shuō)明服務(wù)已經(jīng)就緒了。3.3 拉取并啟動(dòng)Reranker模型Xinference支持通過(guò)UI上傳模型也支持命令行管理模型。兩種方式效果一樣選順手的一種即可。UI方式瀏覽器訪問(wèn)http://宿主機(jī)IP:9997/ui在模型管理頁(yè)面中找到Rerank模型分類(lèi)選擇對(duì)應(yīng)模型點(diǎn)擊安裝。安裝過(guò)程會(huì)下載權(quán)重文件并自動(dòng)安裝依賴可能需要幾分鐘到十幾分鐘不等取決于模型大小和網(wǎng)絡(luò)。命令行方式先進(jìn)入容器環(huán)境然后用Xinference自帶的CLI操作docker exec -it xinference bash在容器內(nèi)執(zhí)行啟動(dòng)模型命令xinference launch \ --model-name 模型名稱 \ --model-type rerank \ --model-format pytorch這里的--model-name要填模型家族名。以中杯模型為例如果模型名稱里有版本號(hào)需要按Xinference支持的命名格式來(lái)填比如在模型列表里看到的是帶版本后綴的名字就填那個(gè)全名。啟動(dòng)成功后CLI會(huì)返回一個(gè)模型UID這個(gè)UID在配置Dify時(shí)要用到務(wù)必復(fù)制保存。依賴的自動(dòng)安裝是這一步最花時(shí)間的地方。首次啟動(dòng)模型時(shí)Xinference會(huì)檢查并補(bǔ)裝模型所需的Python包這些包可能包括torch、transformers等重量級(jí)依賴視覺(jué)效果就像卡住不動(dòng)了。升級(jí)建議別急著按CtrlC先用docker stats看看容器CPU有沒(méi)有波動(dòng)再翻日志確認(rèn)是在下載還是真卡死。加載完成后可以再用CLI確認(rèn)模型列表xinference list能看到該模型處于RUNNING狀態(tài)就說(shuō)明模型已經(jīng)在容器里跑起來(lái)了。3.4 本地接口驗(yàn)證模型還沒(méi)接到Dify之前先用curl直接驗(yàn)證Xinference的Rerank接口通不通。接口路徑是/v1/rerank請(qǐng)求體里帶上模型名、查詢文本和候選文檔列表curl -X POST http://127.0.0.1:9997/v1/rerank \ -H Content-Type: application/json \ -d { model: 模型名稱, query: 寵物狗走丟了怎么找回來(lái), documents: [ 如何訓(xùn)練寵物狗定點(diǎn)大小便, 寵物狗走失后的查找方法與注意事項(xiàng), 寵物狗日常飲食推薦清單 ] }正常返回的JSON里會(huì)有一個(gè)results數(shù)組每個(gè)元素包含index和relevance_score字段。index對(duì)應(yīng)候選文檔的下標(biāo)relevance_score是相關(guān)性分?jǐn)?shù)。如果返回結(jié)果里“寵物狗走失后的查找方法與注意事項(xiàng)”分?jǐn)?shù)最高說(shuō)明Rerank已經(jīng)在正常工作可以進(jìn)入下一步配置Dify。提示這里我故意放入一個(gè)強(qiáng)干擾項(xiàng)“如何訓(xùn)練寵物狗”來(lái)驗(yàn)證分?jǐn)?shù)差異如果模型把所有分?jǐn)?shù)都打得很接近說(shuō)明候選文檔本身區(qū)分度不夠不是Rerank模型的問(wèn)題。3.5 把服務(wù)配置到Dify這一環(huán)節(jié)是標(biāo)題里說(shuō)的“配置已成功應(yīng)用至dify”的核心。進(jìn)入Dify管理后臺(tái)按照模型供應(yīng)商導(dǎo)航找到Xinference。新版本Dify里Xinference是在模型供應(yīng)商列表中單獨(dú)存在的不是放在OpenAI兼容供應(yīng)商下的。打開(kāi)Xinference供應(yīng)商配置界面后需要填幾個(gè)字段Server URL填http://宿主IP:9997。注意這里不要加/v1Dify會(huì)自己拼接對(duì)應(yīng)的API路徑。API KeyXinference默認(rèn)可以不鑒權(quán)這里填任意非空字符串就行比如xinference。不過(guò)如果你的Xinference側(cè)開(kāi)啟了鑒權(quán)要填它要求的Key。模型類(lèi)型選擇Rerank。模型名稱填你在Xinference里啟動(dòng)的模型名稱。Model UID填前面xinference list返回的UID。保存后Dify會(huì)發(fā)起一次模型校驗(yàn)請(qǐng)求。只要Xinference容器端口通、模型名稱對(duì)狀態(tài)就會(huì)顯示可用。有些版本還要求去“模型名稱”下拉列表里再選一次剛才配置的模型這個(gè)是Dify不同版本交互的差異遇到的話不要慌配置頁(yè)里多出來(lái)的模型選項(xiàng)都試一遍即可。模型配置完之后真正讓Rerank生效的地方在知識(shí)庫(kù)設(shè)置。打開(kāi)某個(gè)知識(shí)庫(kù)的設(shè)置頁(yè)面找到檢索設(shè)置或多路召回設(shè)置把Rerank模型從“無(wú)”切換成剛配置的Xinference Rerank模型。Dify會(huì)自動(dòng)對(duì)召回結(jié)果重新排序。之后在知識(shí)庫(kù)的“召回測(cè)試”里輸入一個(gè)測(cè)試問(wèn)題觀察結(jié)果排序和打分的差異——如果排序明顯和之前不一樣尤其正確結(jié)果跑到了第一位說(shuō)明整條鏈路已經(jīng)通了。4. 常見(jiàn)問(wèn)題與排查實(shí)錄4.1 模型加載失敗或一直卡住這是最常遇到的情況。容器日志里反復(fù)出現(xiàn)下載重試或者模型列表始終沒(méi)有出現(xiàn)RUNNING狀態(tài)基本都是網(wǎng)絡(luò)拉取權(quán)重不順利。Xinference支持切換模型下載源國(guó)內(nèi)服務(wù)器建議優(yōu)先設(shè)置ModelScope如果已經(jīng)設(shè)了仍然卡住可以檢查一下宿主機(jī)是否能正常解析下載域名必要時(shí)手動(dòng)把權(quán)重文件放到掛載目錄的對(duì)應(yīng)路徑下再重新觸發(fā)加載。另一個(gè)隱蔽問(wèn)題是掛載目錄權(quán)限。如果宿主機(jī)/data/xinference目錄屬于root且權(quán)限是700容器內(nèi)進(jìn)程可能無(wú)法寫(xiě)入。出現(xiàn)加載一半報(bào)Permission denied直接對(duì)該目錄執(zhí)行chmod -R 777 /data/xinference或者換成當(dāng)前用戶的目錄。4.2 Dify測(cè)試返回401、404或模型不存在配置到Dify后點(diǎn)擊測(cè)試可能出現(xiàn)的報(bào)錯(cuò)有幾種401 Authentication failure。這是因?yàn)锳PI Key沒(méi)填或者填了Dify不認(rèn)的值。Xinference默認(rèn)不鑒權(quán)時(shí)填任意字符串通常會(huì)被接受如果服務(wù)端開(kāi)了鑒權(quán)則需要正確配置Key。404 Not Found。通常是Server URL的路徑不對(duì)看看是不是加了/v1或者多了空格。Dify配置的Xinference接口需要指向根地址不帶路徑。Model not found。這是Model UID填錯(cuò)或模型沒(méi)啟動(dòng)?；氐饺萜骼飯?zhí)行xinference list確認(rèn)UID完全一致注意大小寫(xiě)和連字符。我踩過(guò)最深的坑是復(fù)制UID時(shí)多復(fù)制了一個(gè)換行符Dify校驗(yàn)時(shí)一直報(bào)模型不存在肉眼半天看不出來(lái)。4.3 Rerank配置了但結(jié)果排序沒(méi)變化有時(shí)候Dify配置成功、測(cè)試也不報(bào)錯(cuò)但知識(shí)庫(kù)召回結(jié)果看起來(lái)和之前一樣。別急著懷疑模型掛了先確認(rèn)兩件事知識(shí)庫(kù)的具體設(shè)置里是不是真的選了Rerank模型。Dify的模型供應(yīng)商配置是“可用能力”知識(shí)庫(kù)檢索設(shè)置是“是否啟用”兩個(gè)是獨(dú)立開(kāi)關(guān)。只配好前者后者沒(méi)切換等于白配。候選集是否本身只有一條或被截?cái)唷Ｈ绻蛄繖z索只召回少量文檔Rerank無(wú)論怎么打分排序變化都不明顯。需要保證第一次召回的候選條數(shù)足夠比如10條以上再讓Rerank在這10條里重新定序。還可以反過(guò)來(lái)做一個(gè)壞Case測(cè)試故意用語(yǔ)義相近但答案不同的候選文檔比如一條講“感冒吃什么藥”另一條講“感冒多久能自愈”問(wèn)題問(wèn)“感冒恢復(fù)要幾天”看Rerank能不能把后者頂上來(lái)。如果分?jǐn)?shù)幾乎沒(méi)區(qū)分度才考慮模型本身選型問(wèn)題。4.4 性能與穩(wěn)定性排查Docker部署模型之后機(jī)器并不是萬(wàn)事大吉。我遇到過(guò)Dify調(diào)用Rerank時(shí)偶爾超時(shí)的情況排查后發(fā)現(xiàn)是容器內(nèi)存限制沒(méi)設(shè)模型和進(jìn)程把宿主機(jī)內(nèi)存吃滿后觸發(fā)了內(nèi)核回收。后來(lái)給容器加上資源限制并調(diào)整了推理參數(shù)問(wèn)題消停了?？梢詤⒖嫉腄ocker運(yùn)行參數(shù)docker update --memory 8g --cpus 4 xinferenceRerank請(qǐng)求本身是CPU密集或GPU密集任務(wù)批量并發(fā)高的時(shí)候務(wù)必觀察容器的CPU和內(nèi)存水位。日志里出現(xiàn)[Errno 28] No space left on device時(shí)先檢查掛載目錄的磁盤(pán)余量模型權(quán)重疊加中間臨時(shí)文件很容易把分區(qū)填滿。下面把這些高頻問(wèn)題整理成速查表現(xiàn)象可能原因處理方式模型下載卡住網(wǎng)絡(luò)無(wú)法訪問(wèn)權(quán)重源切換ModelScope源或手動(dòng)下載權(quán)重到掛載目錄容器啟動(dòng)后端口不通端口映射錯(cuò)誤或服務(wù)沒(méi)起來(lái)docker logs看監(jiān)聽(tīng)日志檢查-p參數(shù)Dify報(bào)401API Key不匹配填任意非空字符串或關(guān)閉服務(wù)端鑒權(quán)Dify報(bào)404Server URL多加了/v1改為http://host:9997Dify報(bào)模型不存在Model UID復(fù)制錯(cuò)誤xinference list核對(duì)UID排序無(wú)變化知識(shí)庫(kù)檢索設(shè)置未切換Rerank在知識(shí)庫(kù)設(shè)置里重新選擇模型推理超時(shí)容器資源不足或模型冷啟動(dòng)docker update限制資源或預(yù)熱模型5. 一點(diǎn)收尾這套配置的后續(xù)擴(kuò)展如果你只是把Rerank模型跑通其實(shí)只用了Xinference能力的一小部分。后續(xù)可以在這個(gè)容器里接著掛載Embedding模型、對(duì)話模型Dify側(cè)統(tǒng)一從一個(gè)供應(yīng)商接入所有模型。Docker方式的好處這時(shí)候就體現(xiàn)出來(lái)了模型服務(wù)的升級(jí)、回滾、遷移全都圍繞容器操作不會(huì)污染宿主機(jī)的Python環(huán)境。我個(gè)人實(shí)際操作中的體會(huì)是單獨(dú)把Xinference的Rerank接口調(diào)通不算完真正的驗(yàn)收標(biāo)準(zhǔn)是回到Dify里用真實(shí)業(yè)務(wù)問(wèn)題做對(duì)照測(cè)試至少拿十個(gè)之前的壞Case來(lái)驗(yàn)證排名變化。配置成功只是第一步能夠穩(wěn)定地提升知識(shí)庫(kù)答案質(zhì)量這條鏈路才算是真正落地。建議你在切換Rerank之后保留幾天的觀察期對(duì)比用戶的真實(shí)提問(wèn)反饋再?zèng)Q定要不要調(diào)整候選數(shù)量、模型大小和部署資源。