1. 從零搭建私有文檔問答系統(tǒng)為什么向量檢索是繞不開的一環(huán)大模型火起來之后我身邊不少做后端和算法的朋友都動(dòng)過一個(gè)念頭能不能把公司內(nèi)部那堆散落在各個(gè)角落的文檔、手冊(cè)、會(huì)議紀(jì)要整合起來做一個(gè)能直接問答的私有知識(shí)庫。想法很美好但真動(dòng)手就會(huì)發(fā)現(xiàn)一個(gè)尷尬的現(xiàn)實(shí)——大模型本身并不知道你那些私有文檔里寫了什么。你直接問它它要么一本正經(jīng)地胡說八道要么干脆告訴你“我無法訪問該信息”。解決這個(gè)問題的核心思路就是檢索增強(qiáng)生成也就是常說的RAG。它的邏輯其實(shí)不復(fù)雜用戶提問時(shí)系統(tǒng)先從私有文檔庫里找出和問題最相關(guān)的幾段內(nèi)容把這些內(nèi)容作為上下文塞給大模型讓大模型基于這些真實(shí)材料來回答。這樣一來答案既有依據(jù)又能引用原文幻覺問題能壓下去一大截。而在這個(gè)流程里向量數(shù)據(jù)庫扮演的是“找相關(guān)段落”這個(gè)關(guān)鍵角色。傳統(tǒng)的關(guān)鍵詞搜索靠字面匹配你搜“報(bào)銷流程”文檔里寫的是“費(fèi)用申請(qǐng)審批步驟”字面對(duì)不上就搜不到。向量檢索不一樣它把文本轉(zhuǎn)成一串?dāng)?shù)字也就是向量語義相近的文本在向量空間里距離就近哪怕用詞完全不同也能匹配上。這就是為什么做私有文檔問答向量數(shù)據(jù)庫幾乎是標(biāo)配。這套東西適合誰我覺得三類人最需要一是想給團(tuán)隊(duì)搭內(nèi)部知識(shí)助手的技術(shù)負(fù)責(zé)人二是做企業(yè)級(jí)AI應(yīng)用的后端工程師三是自己手里有一堆資料想做成個(gè)人知識(shí)庫的獨(dú)立開發(fā)者。不管你用Python還是Java不管你數(shù)據(jù)量是幾千條還是幾百萬條這套方法論都能落地。接下來我會(huì)把選型、向量化、檢索調(diào)優(yōu)、和大模型對(duì)接這整條鏈路拆開講盡量把每個(gè)決策背后的“為什么”說清楚讓你看完能直接抄作業(yè)。2. 向量數(shù)據(jù)庫選型別一上來就盯著最火的那個(gè)選型這件事我見過太多人踩坑。最常見的錯(cuò)誤就是看到某個(gè)數(shù)據(jù)庫在技術(shù)圈刷屏二話不說就上結(jié)果發(fā)現(xiàn)自己的場(chǎng)景根本用不上那些花哨功能反而被運(yùn)維復(fù)雜度拖垮。向量數(shù)據(jù)庫選型沒有“最好”只有“最合適”關(guān)鍵是把你的實(shí)際需求先理清楚。2.1 先搞清楚你到底需要什么在對(duì)比具體產(chǎn)品之前我建議你先回答幾個(gè)問題這幾個(gè)問題的答案基本能幫你砍掉一半選項(xiàng)。數(shù)據(jù)規(guī)模有多大是幾千條文檔片段還是上億條向量這個(gè)直接決定了你對(duì)索引類型和硬件的要求。幾千條的話很多輕量方案甚至用本地文件加暴力檢索都能扛住上億條就必須要考慮分布式和專門的近似最近鄰索引了。要不要持久化有些場(chǎng)景數(shù)據(jù)可以重建重啟后重新灌一遍就行但生產(chǎn)環(huán)境通常要求數(shù)據(jù)落盤、重啟不丟這就排除了純內(nèi)存方案。查詢延遲要求多高內(nèi)部知識(shí)庫問答幾百毫秒到一兩秒用戶都能接受但如果是實(shí)時(shí)推薦或者在線廣告那要求就是毫秒級(jí)選型邏輯完全不同。團(tuán)隊(duì)運(yùn)維能力如何這一點(diǎn)最容易被忽略。一個(gè)需要獨(dú)立部署集群、配置分片副本的方案如果沒有專人維護(hù)出問題時(shí)排查成本極高。小團(tuán)隊(duì)我更傾向于選運(yùn)維負(fù)擔(dān)輕的。要不要混合檢索也就是向量檢索加關(guān)鍵詞檢索一起用。很多場(chǎng)景下純向量檢索對(duì)專有名詞、編號(hào)、代碼這類內(nèi)容的召回并不理想混合檢索能明顯提升效果。如果你的文檔里有大量這類內(nèi)容選型時(shí)就要看這個(gè)數(shù)據(jù)庫支不支持原生混合檢索。把這幾個(gè)問題想清楚你手里就有一把尺子了。2.2 主流方案橫向?qū)Ρ认旅孢@張表是我根據(jù)實(shí)際使用和社區(qū)反饋整理的覆蓋了幾類典型方案。注意這里說的是類型而不是具體品牌因?yàn)榫唧w產(chǎn)品迭代很快但類型特征相對(duì)穩(wěn)定。方案類型典型特征適合場(chǎng)景主要短板專用向量數(shù)據(jù)庫原生為向量設(shè)計(jì)索引算法豐富中大規(guī)模、追求檢索性能生態(tài)相對(duì)獨(dú)立需單獨(dú)運(yùn)維傳統(tǒng)數(shù)據(jù)庫擴(kuò)展在現(xiàn)有數(shù)據(jù)庫上加向量能力已有數(shù)據(jù)庫、想少引入組件向量性能不如專用方案嵌入式/本地庫無需獨(dú)立服務(wù)進(jìn)程內(nèi)運(yùn)行小規(guī)模、原型驗(yàn)證、邊緣部署擴(kuò)展性差不適合高并發(fā)搜索平臺(tái)擴(kuò)展搜索引擎加向量字段需要混合檢索、已有搜索棧配置復(fù)雜學(xué)習(xí)曲線陡我個(gè)人的經(jīng)驗(yàn)是原型階段用嵌入式方案快速驗(yàn)證生產(chǎn)階段根據(jù)規(guī)模決定是上專用數(shù)據(jù)庫還是復(fù)用現(xiàn)有數(shù)據(jù)庫的向量擴(kuò)展。很多團(tuán)隊(duì)一上來就部署重型方案結(jié)果數(shù)據(jù)量根本沒到那個(gè)級(jí)別純屬浪費(fèi)。2.3 選型時(shí)最容易忽略的三個(gè)細(xì)節(jié)第一個(gè)細(xì)節(jié)是索引構(gòu)建時(shí)間和查詢精度的權(quán)衡。幾乎所有向量索引都是近似檢索用精度換速度。有的索引構(gòu)建快但召回率一般有的召回率高但構(gòu)建慢、內(nèi)存占用大。你要根據(jù)業(yè)務(wù)能容忍的召回?fù)p失來選。比如法律文檔檢索漏掉一條關(guān)鍵條款可能后果嚴(yán)重那就得選高召回配置哪怕慢一點(diǎn)。第二個(gè)細(xì)節(jié)是過濾條件的支持程度。實(shí)際業(yè)務(wù)里很少是純向量檢索往往還要加元數(shù)據(jù)過濾比如“只搜2023年之后的文檔”“只搜某個(gè)部門的資料”。有些數(shù)據(jù)庫是先做向量檢索再過濾過濾后結(jié)果可能所剩無幾有些支持帶過濾的向量檢索效率高很多。這個(gè)差異在數(shù)據(jù)量大時(shí)非常明顯。第三個(gè)細(xì)節(jié)是更新和刪除的成本。文檔庫不是靜態(tài)的隨時(shí)可能新增、修改、刪除。有些索引結(jié)構(gòu)對(duì)刪除支持很差刪一條要重建整個(gè)索引這在頻繁更新的場(chǎng)景下是災(zāi)難。選型時(shí)一定要確認(rèn)增量更新和刪除的實(shí)際表現(xiàn)。提示選型階段強(qiáng)烈建議用你自己的真實(shí)數(shù)據(jù)做一次小規(guī)模壓測(cè)別只看官方benchmark。官方數(shù)據(jù)往往是理想條件你的數(shù)據(jù)分布、查詢模式可能完全不同。3. 文檔向量化決定檢索質(zhì)量的地基工程選好數(shù)據(jù)庫只是開始真正決定檢索效果上限的是向量化這一步。文檔切得不好、向量模型選得不對(duì)后面檢索調(diào)優(yōu)再怎么折騰都是事倍功半。我見過太多人把精力全花在調(diào)數(shù)據(jù)庫參數(shù)上卻忽略了向量化這個(gè)地基。3.1 文本切分顆粒度就是生命線文本切分看起來簡(jiǎn)單實(shí)際上是最考驗(yàn)經(jīng)驗(yàn)的一步。切得太粗一個(gè)片段里混了好幾個(gè)主題檢索時(shí)匹配到了但里面只有一小部分相關(guān)噪聲大切得太細(xì)一個(gè)完整的意思被拆散檢索到了也拼不出完整答案。我的經(jīng)驗(yàn)法則是按語義邊界切同時(shí)控制長度。具體來說優(yōu)先按文檔的自然結(jié)構(gòu)切比如標(biāo)題、段落、列表項(xiàng)。Markdown和HTML文檔尤其要利用好這些結(jié)構(gòu)信息。單個(gè)片段長度控制在200到500個(gè)token之間比較穩(wěn)妥。太短信息不完整太長會(huì)稀釋語義、增加噪聲。相鄰片段之間保留一定的重疊通常10%到20%。這是為了防止一個(gè)完整的句子或邏輯被硬生生切斷檢索時(shí)兩邊都差一點(diǎn)。對(duì)于表格、代碼塊這類特殊內(nèi)容要么單獨(dú)成段要么用專門的處理方式別和普通文本混在一起切。這里有個(gè)容易被忽略的點(diǎn)切分策略要和你的查詢模式匹配。如果你的用戶習(xí)慣問很具體的問題片段可以切小一點(diǎn)如果習(xí)慣問概括性問題片段需要包含更多上下文。沒有萬能參數(shù)得根據(jù)實(shí)際問答效果反復(fù)調(diào)。3.2 向量模型選擇不是越大越好向量模型負(fù)責(zé)把文本轉(zhuǎn)成向量它的質(zhì)量直接決定語義匹配的準(zhǔn)確度?，F(xiàn)在市面上的模型大致分幾類通用文本嵌入模型、多語言模型、針對(duì)特定領(lǐng)域微調(diào)的模型。選模型時(shí)我主要看幾個(gè)維度語言支持。如果你的文檔中英文混雜必須選多語言模型否則中文文檔的向量質(zhì)量會(huì)很差。純中文場(chǎng)景用中文優(yōu)化過的模型效果通常更好。維度。向量維度越高表達(dá)能力越強(qiáng)但存儲(chǔ)和計(jì)算成本也越高。常見的有384維、768維、1024維、1536維等。我的建議是別盲目追高維768維對(duì)大多數(shù)場(chǎng)景已經(jīng)夠用除非你的數(shù)據(jù)特別復(fù)雜。最大輸入長度。這個(gè)參數(shù)決定了單個(gè)片段能有多長。如果你的切分片段比較長模型的最大長度必須覆蓋得住否則超出部分會(huì)被截?cái)嘈畔⒕蛠G了。推理成本。如果文檔量很大向量化是一次性的大批量操作模型推理速度直接影響你多久能建好庫。有些大模型效果好但推理慢批量處理時(shí)可能要跑很久。注意向量模型一旦選定整個(gè)庫的向量必須用同一個(gè)模型生成。中途換模型意味著所有歷史向量都要重新算這個(gè)成本很高。所以選型時(shí)要考慮長遠(yuǎn)別選一個(gè)以后可能下架或者不再維護(hù)的模型。3.3 批量向量化的工程細(xì)節(jié)實(shí)際做批量向量化時(shí)有幾個(gè)工程上的坑值得提前知道。分批處理。別一次性把所有文檔塞給模型內(nèi)存扛不住而且失敗一次全白干。按批次處理每批幾十到幾百條處理完一批存一批這樣即使中途出錯(cuò)也能斷點(diǎn)續(xù)傳。并發(fā)控制。如果模型是遠(yuǎn)程調(diào)用的并發(fā)太高會(huì)被限流太低又慢。我一般會(huì)先小批量測(cè)一下穩(wěn)定并發(fā)數(shù)然后按這個(gè)數(shù)來。本地模型則要看GPU顯存別把顯存撐爆。失敗重試。網(wǎng)絡(luò)抖動(dòng)、服務(wù)臨時(shí)不可用都是常事一定要有重試機(jī)制并且記錄哪些片段失敗了方便后續(xù)補(bǔ)處理。冪等性。重新跑向量化時(shí)要能識(shí)別哪些文檔已經(jīng)處理過避免重復(fù)插入。通常用文檔ID加內(nèi)容哈希來做去重判斷。下面是一個(gè)批量向量化的偽代碼結(jié)構(gòu)展示一下這個(gè)流程該怎么組織def batch_embed(documents, batch_size64, max_retries3): results [] for i in range(0, len(documents), batch_size): batch documents[i:ibatch_size] for attempt in range(max_retries): try: vectors embed_model.encode([d.text for d in batch]) for doc, vec in zip(batch, vectors): results.append({ id: doc.id, vector: vec, text: doc.text, metadata: doc.metadata }) break except Exception as e: if attempt max_retries - 1: log_failure(batch, e) else: sleep(2 ** attempt) return results這段代碼里分批、重試、失敗記錄都體現(xiàn)了。實(shí)際寫的時(shí)候還要加上進(jìn)度記錄和斷點(diǎn)續(xù)傳的邏輯。4. 檢索調(diào)優(yōu)讓召回結(jié)果真正有用庫建好了向量也灌進(jìn)去了接下來就是檢索調(diào)優(yōu)。這一步的目標(biāo)很明確讓真正相關(guān)的內(nèi)容排到前面讓不相關(guān)的內(nèi)容沉下去。聽起來簡(jiǎn)單做起來需要不少技巧。4.1 相似度度量與Top-K的選擇向量檢索的核心是計(jì)算查詢向量和庫中向量的相似度。常用的度量有余弦相似度、點(diǎn)積、歐氏距離。余弦相似度只看方向不看長度對(duì)文本向量最常用點(diǎn)積在向量歸一化后等價(jià)于余弦相似度歐氏距離對(duì)長度敏感適合某些特定場(chǎng)景。選哪個(gè)通常跟著向量模型的訓(xùn)練方式走模型文檔會(huì)說明它推薦用哪種。Top-K就是返回最相似的K個(gè)結(jié)果。K選多少很講究太小可能漏掉相關(guān)內(nèi)容太大則引入噪聲還會(huì)增加后續(xù)大模型的上下文長度和成本。我的經(jīng)驗(yàn)是先取一個(gè)較大的K比如20然后用重排序或者閾值過濾把真正相關(guān)的篩出來最終給大模型3到5條就夠了。這里有個(gè)實(shí)用技巧不要只看相似度絕對(duì)值要看相對(duì)分布。如果Top-20的相似度都集中在0.7到0.75之間說明這些結(jié)果質(zhì)量差不多可能都相關(guān)也可能都不太相關(guān)如果第一名0.9后面斷崖式掉到0.6那第一名大概率就是你要的。根據(jù)分布動(dòng)態(tài)調(diào)整閾值比固定閾值靠譜得多。4.2 混合檢索向量加關(guān)鍵詞的組合拳純向量檢索有個(gè)天然短板對(duì)專有名詞、產(chǎn)品編號(hào)、代碼標(biāo)識(shí)符、人名這類內(nèi)容的匹配不夠精確。因?yàn)檫@些詞的語義信息弱向量表達(dá)不出它們的獨(dú)特性。這時(shí)候關(guān)鍵詞檢索比如BM25就能補(bǔ)上?；旌蠙z索的思路是兩路并行召回然后融合排序。常見融合方法有兩種加權(quán)求和把向量相似度和關(guān)鍵詞得分歸一化后按權(quán)重相加。權(quán)重需要根據(jù)你的數(shù)據(jù)特點(diǎn)調(diào)一般向量占大頭關(guān)鍵詞占小頭。倒數(shù)排名融合不看具體分?jǐn)?shù)只看兩路各自的排名把排名倒數(shù)相加作為最終得分。這個(gè)方法的好處是不用處理兩路分?jǐn)?shù)尺度不一致的問題比較省心。我實(shí)測(cè)下來在文檔包含大量專有名詞的場(chǎng)景混合檢索比純向量檢索的召回率能提升不少。代價(jià)是要維護(hù)兩套索引查詢時(shí)也要跑兩路延遲會(huì)略高。是否值得取決于你的文檔特點(diǎn)。4.3 重排序把最相關(guān)的頂上來檢索出來的Top-K結(jié)果順序未必最優(yōu)。重排序就是用一個(gè)更精細(xì)的模型對(duì)候選結(jié)果重新打分排序。它和向量檢索的區(qū)別在于向量檢索是雙塔結(jié)構(gòu)查詢和文檔分別編碼速度快但精度有限重排序模型是交叉編碼查詢和文檔一起輸入能捕捉更細(xì)粒度的交互精度高但速度慢。所以典型流程是向量檢索粗召回快取幾十條→ 重排序精排慢但只處理幾十條→ 取Top-3給大模型。這樣兼顧了速度和精度。重排序模型的選擇上同樣要考慮語言支持和推理成本。如果候選集不大用大一點(diǎn)的重排序模型沒問題如果候選集很大就得權(quán)衡延遲。4.4 元數(shù)據(jù)過濾與查詢改寫實(shí)際業(yè)務(wù)里檢索往往不是孤立的。用戶可能帶著條件來問比如“上季度的銷售數(shù)據(jù)”“技術(shù)部的文檔”。這時(shí)候元數(shù)據(jù)過濾就派上用場(chǎng)了。給每個(gè)文檔片段打上時(shí)間、部門、類型等標(biāo)簽檢索時(shí)先按條件過濾再算相似度能大幅提升相關(guān)性。另一個(gè)提升召回的手段是查詢改寫。用戶的問題往往口語化、信息不全直接拿去檢索效果一般?？梢韵扔么竽Ｐ桶褑栴}改寫成更適合檢索的形式比如補(bǔ)全上下文、提取關(guān)鍵詞、生成多個(gè)查詢變體。多個(gè)變體分別檢索再合并結(jié)果召回率通常會(huì)有提升。提示查詢改寫會(huì)增加一次大模型調(diào)用延遲和成本都會(huì)上升。建議只在檢索效果不理想時(shí)啟用或者對(duì)復(fù)雜問題才走這條路。5. 與大模型對(duì)接把檢索結(jié)果變成靠譜答案檢索做好了最后一步是把結(jié)果喂給大模型讓它生成答案。這一步看似簡(jiǎn)單其實(shí)提示詞的設(shè)計(jì)直接決定答案質(zhì)量。5.1 上下文組裝的藝術(shù)給大模型的上下文不是簡(jiǎn)單把檢索結(jié)果拼起來就行。我通常遵循幾個(gè)原則標(biāo)注來源。每個(gè)片段前面標(biāo)上來源和編號(hào)方便大模型引用也方便用戶核對(duì)。比如“【文檔1】……”?？刂崎L度。大模型的上下文窗口有限塞太多反而會(huì)稀釋關(guān)鍵信息還增加成本。一般3到5個(gè)最相關(guān)的片段就夠了總長度控制在模型窗口的一半以內(nèi)比較穩(wěn)妥。保留結(jié)構(gòu)。如果片段里有列表、表格盡量保留原始格式別壓成一行否則大模型理解起來會(huì)打折扣。明確指令。在提示詞里明確告訴大模型只根據(jù)提供的材料回答材料里沒有就說不知道不要編造。這一條能顯著降低幻覺。5.2 提示詞模板設(shè)計(jì)一個(gè)好的提示詞模板通常包含幾個(gè)部分角色設(shè)定、任務(wù)說明、上下文材料、用戶問題、輸出要求。下面是一個(gè)我常用的結(jié)構(gòu)你是一個(gè)嚴(yán)謹(jǐn)?shù)闹R(shí)助手。請(qǐng)僅根據(jù)下面提供的材料回答用戶問題。 材料 【文檔1】{chunk_1} 【文檔2】{chunk_2} 【文檔3】{chunk_3} 用戶問題{question} 要求 1. 只使用材料中的信息回答不要編造。 2. 如果材料中沒有相關(guān)信息直接說明“根據(jù)現(xiàn)有資料無法回答”。 3. 回答時(shí)標(biāo)注引用的文檔編號(hào)。 4. 回答簡(jiǎn)潔準(zhǔn)確不要重復(fù)材料原文。這個(gè)模板的關(guān)鍵在于約束。大模型天生愛發(fā)揮不給約束就容易跑偏。明確說“只用材料”“沒有就說不知道”能把它框住。5.3 引用與溯源生產(chǎn)環(huán)境里答案的可信度至關(guān)重要。用戶看到答案往往想知道“這是從哪來的”。所以引用溯源是必備功能。實(shí)現(xiàn)方式是在提示詞里要求大模型標(biāo)注引用編號(hào)前端再把編號(hào)映射回原始文檔和位置用戶點(diǎn)擊就能跳轉(zhuǎn)查看原文。這個(gè)功能不僅提升可信度還方便用戶驗(yàn)證。如果發(fā)現(xiàn)答案有問題能快速定位是檢索錯(cuò)了還是大模型理解錯(cuò)了對(duì)后續(xù)調(diào)優(yōu)很有幫助。6. 常見問題與排查技巧實(shí)錄做這套系統(tǒng)的過程中我踩過的坑不少這里整理成速查表希望能幫你少走彎路。問題現(xiàn)象可能原因排查方向解決思路檢索結(jié)果完全不相關(guān)向量模型與語言不匹配檢查模型是否支持文檔語言換多語言或?qū)?yīng)語言模型相關(guān)文檔排不到前面切分顆粒度不當(dāng)查看片段是否包含完整語義調(diào)整切分長度和重疊專有名詞搜不到純向量檢索語義弱測(cè)試關(guān)鍵詞檢索能否命中引入混合檢索答案有編造內(nèi)容提示詞約束不足檢查提示詞是否明確限制強(qiáng)化“只用材料”指令檢索延遲高索引類型或數(shù)據(jù)量問題看索引配置和查詢量換近似索引或加緩存新增文檔后搜不到索引未更新檢查增量更新流程補(bǔ)上索引刷新機(jī)制相似度分?jǐn)?shù)普遍偏低模型或度量方式問題對(duì)比不同度量方式換度量或重新評(píng)估模型除了這些還有幾個(gè)獨(dú)家避坑技巧值得分享。第一先做小規(guī)模端到端驗(yàn)證再規(guī)?；?。很多人一上來就灌幾十萬文檔結(jié)果發(fā)現(xiàn)問題時(shí)排查成本極高。正確做法是先用幾百條數(shù)據(jù)跑通全流程確認(rèn)檢索和生成都正常再逐步加量。第二把檢索和生成分開評(píng)估。答案不好可能是檢索沒召回對(duì)的也可能是大模型沒用好材料。分開評(píng)估才能定位問題。檢索看召回率和準(zhǔn)確率生成看忠實(shí)度和相關(guān)性。第三保留原始文本和向量對(duì)應(yīng)關(guān)系。調(diào)優(yōu)時(shí)經(jīng)常需要回看某個(gè)向量對(duì)應(yīng)的是哪段文本如果這個(gè)映射丟了排查會(huì)很痛苦。第四注意向量歸一化的一致性。如果模型訓(xùn)練時(shí)用了歸一化檢索時(shí)也要?dú)w一化否則相似度計(jì)算會(huì)出錯(cuò)。這個(gè)細(xì)節(jié)很容易被忽略。第五定期用真實(shí)用戶問題做回歸測(cè)試。系統(tǒng)上線后收集用戶實(shí)際問的問題定期跑一遍看檢索和回答質(zhì)量有沒有退化。數(shù)據(jù)在變模型在更新不測(cè)就不知道效果。這套私有文檔問答系統(tǒng)從選型到上線我前后折騰了不少時(shí)間。最大的體會(huì)是沒有一步是可以隨便糊弄的每個(gè)環(huán)節(jié)的決策都會(huì)在后面體現(xiàn)出來。向量數(shù)據(jù)庫選錯(cuò)了后面調(diào)優(yōu)事倍功半切分沒做好檢索再優(yōu)化也救不回來提示詞沒約束好大模型就放飛自我。所以我的建議是每一步都花點(diǎn)時(shí)間想清楚為什么這么做別急著往前趕。慢就是快這話在這件事上特別成立。