說實話半年前接到這個項目時我差點被一張架構圖勸退。業(yè)務方丟給我一批產品手冊和培訓PPT要做一個能回答問題的內部知識庫。我一開始想得很簡單不就是RAG嘛解析文檔、切塊、向量化、召回老套路了。結果把資料庫翻開一看整個人有點麻——手冊里大量關鍵信息都以截圖、流程圖、參數表格的形式存在很多頁面甚至沒有幾個字。用傳統(tǒng)純文本RAG跑了一輪效果慘不忍睹。搜“設備電源接口在哪個位置”召回的是一堆含“電源”字樣的不相干段落真正在圖片里標注答案的內容根本進不了候選。沒辦法只能認真搞多模態(tài)RAG把圖文混合檢索這條鏈路完整搭起來。做了一圈調研選了日調用量達10億次級別的WeMM-Embedding作為主力向量模型。這篇文章就是把這套方案的完整落地過程、踩坑記錄和可直接復用的代碼都整理出來給正在被圖文資料庫虐的同行們一個參考。1. 圖文檢索為什么難純文本RAG在真實資料庫里的翻車現場1.1 真實資料庫的構成核心信息大量以圖像形式存在我這次要處理的是一個產品知識庫里面大概有3000多頁資料構成很典型產品說明書、售后FAQ、銷售培訓PPT、活動海報截圖。粗略統(tǒng)計下來超過40%的關鍵信息是以圖片形式承載的。比如設備接口說明經常是一張產品背板圖每個接口旁邊標著序號底部一個表格逐行解釋比如故障排查流程基本就是一張決策樹截圖很少有純文字版本。這意味著什么如果你用純文本RAG第一步就會丟掉一半信息。傳統(tǒng)的做法是OCR抽文字可OCR只能抽出來“圖片里有哪些字”抽不出“這些字的位置關系”“這個標注指的是哪塊區(qū)域”。對于流程圖、結構圖、對比表格這類強依賴版式的內容OCR后的純文本完全變形檢索質量自然崩。1.2 把圖和文字切進同一個chunk問題變得更復雜純文本RAG還有一個經典操作文檔切塊然后把每個塊向量化。但圖文混排資料一旦切塊新的麻煩就來了。最直接的方案是PDF解析時把圖片也當成“一個元素”按閱讀順序跟文本一起切?？蛇@樣會導致圖文被硬生生拆開一張產品結構圖在chunk 5圖里的關鍵部件文字解釋在chunk 8檢索時很難同時命中。如果硬把圖和它周圍所有文本塞進同一個chunk一個chunk可能幾千token向量化時語義被噪聲稀釋召回精度反而下降。我實操中遇到一個特別典型的翻車案例用戶問“這款型號支持POE供電嗎”資料里答案其實是一張電源規(guī)格截圖圖里清清楚楚標注了“POE 802.3af”。但純文本鏈路把這張圖OCR成了幾段亂序文本向量化后這條內容淹沒在幾十個無關塊里最終LLM答的是“未在產品資料中找到明確信息”。這種體驗基本沒法用。1.3 為什么不能指望多模態(tài)大模型“硬看”全部資料有人會問既然圖片是重點干嘛不直接把所有資料喂給多模態(tài)大模型讓它看完整庫再回答問題這個思路聽起來直接但落地時會撞墻。3000頁PDF、上萬張圖就算塞進VLM的上下文窗口成本、延遲、幻覺率都不可控。而且業(yè)務知識庫是持續(xù)更新的每更新一版資料就要全量重讀不現實。所以多模態(tài)RAG的核心價值仍然在“召回的準確性”先把大海撈針的問題變成小范圍精讀把最相關的圖文片段找出來再交給LLM或VLM生成答案。這也是我最終選擇“多模態(tài)Embedding 向量檢索”而不是“無檢索硬答”的根本原因。2. WeMM-Embedding 到底能干什么模型能力邊界與選型分析2.1 多模態(tài)統(tǒng)一向量空間圖像和文字能相互檢索了傳統(tǒng)RAG里文本和圖像用的是兩套完全獨立的表示方式文本檢索和圖像檢索各跑各的最后強行合并結果跨模態(tài)匹配的效果很差。WeMM-Embedding這類多模態(tài)Embedding模型解決的核心問題是把文本和圖像映射到同一個向量空間。也就是說在同一個空間里“POE供電支持圖”的圖像向量和“如何判斷是否支持POE供電”的文本向量距離是近的。這樣你就能做兩件事用文字直接檢索圖片以及用圖片檢索相關的文字描述。WeMM-Embedding覆蓋了80多種語言對中文場景尤其友好不需要單獨做英文翻譯再走一遍。它還有配套的Rerank模型可以在第一輪向量召回后做精細重排這套組合基本覆蓋了RAG從召回到底排的完整鏈路。2.2 “日調用10億次”在工程上意味著什么選型時我被“日調用10億次”這個數字吸引說實話這個量級的在線服務一定經過了極大規(guī)模的流量打磨和長尾數據檢驗。在工程上它至少意味著接口的穩(wěn)定性、各種極端輸入模糊截圖、低分辨率圖、中英混排文本的魯棒性、以及多語言場景下的覆蓋面都經過了一線驗證。但我也提醒自己冷靜大廠內部跑得好不代表自己項目里直接套就行。我們自己的數據分布、查詢意圖、圖文比例可能跟它的線上場景差別很大。所以不能因為“背景硬”就不做適配測試該有的小樣本評測、閾值校準、badcase分析一個都不能少。2.3 選型判斷什么場景真的需要多模態(tài)Embedding不是所有RAG項目都需要上多模態(tài)。如果知識庫以純文本為主圖像只是點綴那多模態(tài)Embedding引入的解析復雜度反而會拖慢開發(fā)進度純文本Embedding模型足夠。但如果出現以下特征基本可以確定需要走多模態(tài)路線相當比例的資料是截圖、海報、掃描件、流程圖。用戶查詢中有大量“圖上的信息”比如“第一張圖里標紅的接口是什么”。圖文強關聯單獨看文字無法理解完整語義例如培訓PPT里一頁圖一句標題。這里給個簡單的決策表場景特征純文本Embedding多模態(tài)Embedding資料幾乎全是Markdown/Word純文本推薦簡單高效沒必要成本更高PDF里圖像占比高圖表是核心信息檢索效果差基本不可用推薦能圖文互檢需要跨語言檢索依賴翻譯鏈路效果一般原生多語言支持更適合實時性要求極高數據量巨大單模態(tài)向量化速度快圖像向量化稍慢需要異步處理我這次項目顯然屬于第二類所以直接鎖定多模態(tài)路線。3. 接入前必須想清楚的架構問題走API還是本地部署向量庫怎么選3.1 API與本地部署的取舍WeMM-Embedding同時提供了云端API和開源權重這個選擇會直接決定后續(xù)的系統(tǒng)復雜度和運維成本。我做了個簡單對比維度云端API本地部署開源權重上線速度有Key就能跑幾分鐘接入需要準備GPU、拉模型、起服務成本結構按量付費量越大成本越高一次性硬件投入長期邊際成本低數據隱私文檔內容會經過云端數據完全不出內網推理延遲網絡往返一般100ms級別看顯卡通常更快運維負擔幾乎為零模型更新、并發(fā)擴容都要自己管我當時的建議是第一版先用API跑通全流程把產品邏輯驗證清楚再根據數據量和隱私要求決定是否遷移到本地部署。原因很簡單項目早期最大的風險是“鏈路是否可靠”不是“GPU利用率”。用API可以把向量化和接入的復雜度壓縮到最小讓你集中精力調檢索效果。3.2 向量庫選型pgvector先行Milvus兜底向量庫這個環(huán)節(jié)我見過太多項目一上來就上重型組件最后發(fā)現數據量萬把條運維成本比檢索成本還高。這次我選了pgvector理由很樸素項目初始數據量就是幾萬chunkpgvector完全扛得住。團隊對PostgreSQL已經很熟不需要額外引入Milvus/Weaviate/ES這類分布式系統(tǒng)。結構化過濾按文檔類型、頁碼、業(yè)務線過濾可以直接用SQL跟向量檢索寫在一起非常方便。但如果你預判數據量會快速沖到百萬級、查詢QPS很高那還是要上Milvus或專門的向量數據庫。它支持HNSW這類ANN索引的分布式部署、多副本、動態(tài)擴容運維上有更成熟的方案。小步快跑永遠比一步到位更穩(wěn)后面真的遇到瓶頸再加中間件也不遲。3.3 整體數據流設計我把整個鏈路畫成了下面這條線用文字描述更直觀文檔解析抽文本塊和圖像塊→ 切塊文本按語義切圖像按信息密度切→ 多模態(tài)Embedding向量化 → 統(tǒng)一寫入pgvector → 查詢時文本Query向量化 → 雙路召回文本向量表圖像向量表→ Rerank精排 → 拼裝上下文 → 交給LLM生成回答。這里的關鍵點是文本Query只做一次向量化但它可以同時去檢索文本向量表和圖像向量表因為WeMM-Embedding把圖文放在同一空間完全支持文字直接查圖片。這就是“跨模態(tài)檢索”的落地點。4. 從零搭起圖文混合檢索鏈路文檔解析、切塊策略與入庫邏輯4.1 環(huán)境準備與模型調用如果你用云端API先把依賴裝上。我習慣用OpenAI SDK來調兼容接口因為這樣切換供應商時改動最小。import os from openai import OpenAI client OpenAI( api_keyos.getenv(WEMM_API_KEY), base_urlos.getenv(WEMM_BASE_URL, https://dashscope.aliyuncs.com/compatible-mode/v1), ) def embed_texts(texts): resp client.embeddings.create( modelwemm-embedding, input[{text: t} for t in texts], ) return [item[embedding] for item in resp.data] def embed_images(image_urls): resp client.embeddings.create( modelwemm-embedding, input[{image: url} for url in image_urls], ) return [item[embedding] for item in resp.data]如果你傾向本地部署可以用transformers直接加載開源權重from transformers import AutoModel, AutoTokenizer model AutoModel.from_pretrained(你的本地模型目錄/WeMM-Embedding, trust_remote_codeTrue) tokenizer AutoTokenizer.from_pretrained(你的本地模型目錄/WeMM-Embedding) def embed_local(textsNone, imagesNone, devicecuda): inputs tokenizer(texttexts, imagesimages, return_tensorspt, paddingTrue).to(device) with torch.no_grad(): embeddings model.encode(**inputs) return embeddings.cpu().tolist()建議正式開發(fā)前先跑一次冒煙測試拿一張清晰的產品圖和一句對應的中文描述算一下相似度確認調用鏈路沒問題再往下走。4.2 PDF圖文解析怎么把圖從文檔里“摳”出來做多模態(tài)RAG文檔解析是最容易被低估的一步。我這邊主要處理PDF用的是PyMuPDF一個非常好用的庫。核心邏輯是按頁遍歷提取文本塊同時把所有圖片區(qū)域單獨摳出來。import fitz # PyMuPDF def parse_pdf_with_images(pdf_path): doc fitz.open(pdf_path) elements [] # 每個元素要么是text要么是image for page_idx, page in enumerate(doc): # 提取文本 page_text page.get_text(text) if page_text.strip(): elements.append({ type: text, content: page_text.strip(), page: page_idx 1, }) # 提取圖像 image_list page.get_images(fullTrue) for img_index, img in enumerate(image_list): xref img[0] base_image doc.extract_image(xref) image_bytes base_image[image] ext base_image[ext] image_path fextract/page{page_idx1}_img{img_index}.{ext} with open(image_path, wb) as f: f.write(image_bytes) elements.append({ type: image, content: image_path, page: page_idx 1, }) return elements這里有個工程細節(jié)PDF里的圖片不只會以獨立“對象”形式存在有的其實是頁面背景或裝飾圖。我建議對摳出來的圖像做一個基礎過濾小于某個面積比例例如頁面面積的8%的圖直接跳過。否則你可能會給一張邊框裝飾線都做向量化浪費存儲和額度還拉低檢索精度。4.3 切塊策略文字按語義拆圖像按“信息密度”拆文本切塊相對常規(guī)我按512字符一個chunk重疊80字符按標題層級做邊界修正。但圖像切塊一定要講策略。以我的實踐來看圖像有兩種典型情況需要區(qū)別處理弱信息密度圖比如一張整體的產品外觀渲染圖信息都在“整體觀感”上這種圖應該整張向量化切成小塊反而丟失全局語義。強信息密度圖比如一張軟件界面截圖里面密密麻麻全是文字如果整張圖向量化模型容易眼花,細碎信息被壓縮丟失。這種情況建議先OCR抽一層文字把文字作為文本chunk單獨入庫圖像本身也保留一份向量兩條檢索通道互相補充。再比如流程圖建議整張切分而不是按節(jié)點拆分因為流程的核心價值在于結構關系。多模態(tài)Embedding在做這類圖時會把整體拓撲關系編碼進向量拆碎了反而毀了語義。表格截圖則相反如果一張表格特別大建議按行區(qū)間切成多個小圖否則一行重點信息會被其他行淹沒。每塊入庫時metadata里記錄page、來源文件名、chunk類型、原始圖片路徑后面調試badcase時能直接定位到原始資料。4.4 入庫邏輯統(tǒng)一表還是分表我最終選了“一張統(tǒng)一向量表 chunk_type字段區(qū)分”的方案。理由很現實查詢時用一條SQL就能同時召回文本和圖像按類型重新排序分表雖然結構上更干凈但跨類型合并結果時多一層邏輯對項目早期來說是多余的復雜度。建表SQL示意CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE doc_chunks ( id BIGSERIAL PRIMARY KEY, chunk_type TEXT NOT NULL, -- text 或 image content TEXT, -- 文本內容或圖片的本地路徑/URL embedding VECTOR(1024), -- 維度跟模型輸出對齊 page_number INT, source_file TEXT, metadata JSONB, created_at TIMESTAMP DEFAULT NOW() ); CREATE INDEX ON doc_chunks USING hnsw (embedding vector_cosine_ops);插入代碼import psycopg2 from psycopg2.extras import Json def insert_chunk(cursor, chunk_type, content, embedding, page, source, metadataNone): cursor.execute( INSERT INTO doc_chunks (chunk_type, content, embedding, page_number, source_file, metadata) VALUES (%s, %s, %s, %s, %s, %s) , (chunk_type, content, embedding, page, source, Json(metadata or {})))入庫前建議做一次批量向量化不要一張圖一次請求而是攢一批比如64個一起調吞吐會好很多。5. 檢索階段的核心實現雙路召回、跨模態(tài)匹配與閾值調優(yōu)5.1 查詢鏈路完整代碼檢索邏輯的核心是把用戶query做一次文本向量化然后同時去查文本chunk和圖像chunk各自取topN再做合并和過濾。說的更直白點用戶輸入一句話它能查到相關的文本段落也能查到“最可能包含答案的那張圖”。def search(query, top_k10): query_vec embed_texts([query])[0] cursor.execute( SELECT id, chunk_type, content, page_number, source_file, 1 - (embedding %s::vector) AS score FROM doc_chunks WHERE content IS NOT NULL ORDER BY embedding %s::vector LIMIT %s , (query_vec, query_vec, top_k)) rows cursor.fetchall() # 可以按 chunk_type 統(tǒng)計召回分布方便觀察 return rows def search_by_type(query, chunk_type, top_k10): query_vec embed_texts([query])[0] cursor.execute( SELECT id, content, page_number, source_file, 1 - (embedding %s::vector) AS score FROM doc_chunks WHERE chunk_type %s ORDER BY embedding %s::vector LIMIT %s , (query_vec, chunk_type, query_vec, top_k)) return cursor.fetchall()實際項目中我建議先走統(tǒng)一檢索看返回結果里圖像chunk和文本chunk的比例。如果圖像chunk一個都沒出現說明要么圖像解析入庫環(huán)節(jié)有bug要么query的語義離圖太遠這時候再分別用search_by_type單獨查一次快速定位問題。5.2 相似度閾值怎么定別拍腦袋要數據向量檢索的相似度閾值最容易犯的錯誤是拍腦袋定一個0.8、0.9然后發(fā)現召回超少或噪音超多。我這里用的距離是余弦距離1 - cosine_similarity是最終得分。實際操作中我先抽取了20條真實業(yè)務問題對每條問題查詢后把所有候選的得分撈出來畫出分布。你會發(fā)現一個規(guī)律真正相關的chunk得分普遍在0.65以上弱相關或無關chunk大多在0.4以下。中間0.4到0.65這段屬于模糊地帶建議不要直接丟棄而是保留下來交給Rerank去判斷。我把初篩閾值定在0.35這樣能盡量不丟答案把“是否相關”的精細生殺大權交給Rerank。這里還有一個經驗不同文檔類型、不同圖片清晰度得分分布差異很大。掃描件或低分辨率截圖出來的向量得分整體會偏低如果統(tǒng)一用一個閾值很容易誤殺。所以閾值最好按“來源文件”或“資料類型”配置而不是全局寫死。5.3 文中圖、圖中文的輸入限制問題多模態(tài)Embedding模型對圖像輸入是有尺寸和token限制的。我踩過一個坑把一張超大架構圖分辨率6000x4000直接丟進去向量化模型把大量細節(jié)壓縮檢索時死活召不回圖里的某個模塊名。后來我加了一個圖像預處理步驟讀取圖片尺寸如果長邊超過模型建議值比如2048px先把圖切分成2x2或3x3的網格每個子圖單獨向量化入庫同時保留整圖的向量。查詢時如果命中了某個子圖可以回溯到整圖把整圖作為上下文喂給LLM。這樣既不會丟細節(jié)又能保留全局結構。類似地用戶上傳的查詢圖片也要做同樣處理不然檢索端“圖搜圖”時精度會明顯下降。6. 從跑通到好用Rerank、緩存與搜索架構的長尾問題6.1 第一輪召回不準交叉編碼器Rerank來兜底向量召回本質上是一道“粗篩題”它足夠快但精度有限。多模態(tài)RAG落地時第一輪top10里可能只有兩三個真正相關。這時候如果直接把top10拼給LLM不僅浪費上下文窗口還容易因為噪聲信息干擾導致幻覺。我的做法是加一個Rerank層用交叉編碼器CrossEncoder對召回結果逐條精排。交叉編碼器能把query和candidate拼在一起做深度交互比雙塔式向量檢索精度高不少。WeMM-Embedding官方也配套了對應的Rerank模型。簡化版代碼from sentence_transformers import CrossEncoder reranker CrossEncoder(wemm-rerank-model, max_length512) def rerank(query, candidates): pairs [(query, c[content]) for c in candidates] scores reranker.predict(pairs) for c, s in zip(candidates, scores): c[rerank_score] s candidates.sort(keylambda x: x[rerank_score], reverseTrue) return candidates[:5]加了這個層以后我們內部評測里“答案命中率”正確答案出現在最終上下文中的比例大概提升了18個百分點。代價是每條查詢增加了幾十到上百毫秒延遲但換來的精度提升非常值。6.2 圖片內容的OCR與多模態(tài)Embedding的配合很多人以為有了多模態(tài)EmbeddingOCR就可以扔了。實際用下來兩者是互補關系不是替代關系。對于界面截圖、掃描表格這類文字密集的圖像OCR抽出的結構化文本往往是“最硬的線索”向量相似度反而會因為圖像壓縮損失精度而排得不夠靠前。我在項目里的策略是雙軌并行圖片既做圖像向量化也做OCR文字提取OCR文本作為一個獨立chunk入庫。檢索時如果query偏文字匹配比如“登錄按鈕在哪”O(jiān)CR文本chunk大概率命中如果query偏視覺語義比如“這張圖整體在講什么流程”圖像向量chunk效果更好。兩條結果進Rerank層統(tǒng)一排序最后取最優(yōu)。6.3 緩存與限流別把日調用10億次的接口當成無限量雖然WeMM-Embedding本身日調用量是10億級別但那是整個平臺的總量你一個項目拿到的賬號有QPS限制。如果索引階段一次性喂幾千張圖很容易觸發(fā)限流報錯。我踩過的坑是批量向量化沒做并發(fā)控制跑了一半接口開始報錯還得寫重跑腳本。后面我加了兩層保護本地緩存相同圖片或相同文本塊的向量結果直接讀緩存不重復請求。指數退避重試請求失敗時等1秒、2秒、4秒重試最多5次。import time def embed_with_retry(textsNone, imagesNone, max_retries5): for attempt in range(max_retries): try: return embed_texts(texts) if texts else embed_images(images) except Exception as e: wait 2 ** attempt print(fembedding failed: {e}, retry in {wait}s) time.sleep(wait) raise RuntimeError(embedding retry exhausted)如果是一次性全量入庫建議把任務拆成多個批次用消息隊列或簡單的生產者消費者模型慢慢消費別讓短期內流量太集中。6.4 從單次查詢到Agentic RAG多跳檢索怎么接項目跑順之后業(yè)務方自然會提更多需求比如“連續(xù)問好幾輪”“需要根據一個問題去查多個來源再總結”。這時候單次檢索就不夠用了需要在外面套一層Agent邏輯。我目前的做法是用FastAPI把檢索服務包成一個獨立微服務上層再用LangGraph編排多輪檢索流程pgvector繼續(xù)當向量存儲。多輪場景里有個小心得在每輪檢索前先用LLM把對話歷史壓縮成一個獨立的、自包含的搜索query再進檢索鏈路。否則問題里的代詞“它”“這個設備”會讓向量檢索完全失焦。這些屬于進階方向第一版先把“單輪圖文檢索”做扎實多跳Agent可以在基礎穩(wěn)定的情況下逐步疊加。搜索架構這東西最怕的就是基礎沒打牢就堆花活?；氐轿易约旱捻椖扛惺?。多模態(tài)RAG對比傳統(tǒng)純文本RAG最大的進步不是“多了一個模態(tài)”而是讓檢索真正理解了圖文之間的關系。文字和圖像落進同一個高維空間后很多以前根本搜不到的答案現在能被撈出來了。但這套鏈路也絕不是裝個模型就萬事大吉文檔解析的精細度、切塊策略、圖像預處理、閾值校準、Rerank組合每一步都在影響最終體驗。最后分享一個比較實用的習慣無論換什么模型、調什么參數先在真實數據集上攢一批badcase批量跑一輪按“召回缺失、重排錯誤、上下文截斷、生成幻覺”分類記錄。發(fā)現問題先改鏈路再考慮換模型。這個習慣幫我少走了很多彎路。