WeMM-Embedding：對齊文字、圖片、影片的多模態檢索

2026 年 8 月 28 日 Share to X Copy link

騰訊微信視覺團隊把文字、圖片、影片、視覺文件等多種輸入收進同一個嵌入空間，推出涵蓋 2B／4B／9B 三個尺寸的 WeMM-Embedding 系列，主打檢索與多模態理解一條龍。

把文字、圖片、短影片、文件截圖一次過丟進同一個嵌入空間做檢索，一直是多模態團隊頭痛的工程難題。WeMM-Embedding 系列由騰訊微信視覺團隊開源，正是針對這個場景而來：三個規模（2B／4B／9B）都用同一套介面，輸出可直接比對的向量，免卻多模型串接的麻煩。

向量從模型最後一層的 <embedding> token 位置取出，再做 L2 正規化，方便直接接入既有向量資料庫。對想做跨模態檢索或 RAG 的團隊而言，這類統一模型比起同時維護 CLIP 系、BGE 系、影片模型幾套 pipeline，部署成本明顯較低。

官方推薦 transformers==5.2.0 以保證預處理一致性，亦支援 SentenceTransformer 直接載入 Hugging Face 模型 ID。比較有彈性的是 Matryoshka Representation Learning（MRL）：例如 9B 版本支援 64 到 4096 多段維度，開發階段可以用低維度快速迭代，再逐步切到高維度；2B 與 4B 版同樣提供 64 至 2048 左右的選項。已驗證 vLLM 0.27.0 與 SGLang 0.5.9 兩套推理引擎，兩者都以 pooling runner 啟動，搭配專屬的 chat template 即可提供 embedding 服務。

與同類開源嵌入模型相比，WeMM-Embedding 強調「影片與視覺文件也在同一個向量空間」，而不是只覆蓋到圖文。短影片摘要、PDF 截圖理解、社交媒體（X Demo）多模態內容推薦等場景，會比純圖文模型更貼地。音訊輸入目前不在支援範圍內，是規劃時要留意的限制。受惠對象包括做多模態 RAG、跨模態檢索、商品搜尋及內容審核的中小團隊，因為他們通常缺乏同時訓練多個專門模型的資源。

重點：

• 統一嵌入空間：文字、圖片、影片、視覺文件、交錯輸入共用同一向量表示，免除多模型串接。
• 三種規模：2B、4B、9B 同步開源，可在準確度與成本之間靈活取捨。
• Matryoshka 維度彈性：支援 64 至 4096 多段可選維度，平衡儲存與效果。
• 生態友善：兼容 transformers、SentenceTransformer，並已驗證 vLLM 與 SGLang 部署。
• 目前限制：音訊輸入未支援，預處理對 Transformers 版本敏感，需固定在 5.2.0。

GitHub · 模型

Categories: 開源, 騰訊, AI productions, RAG, Embedding, 模型, Video, Image, Dataset 數據集

---

MobileMem 把手機長期記憶放入真實場景測試

2026 年 8 月 18 日 Share to X Copy link

手機助手要記住一年的生活，難點不只是搜尋資料，更要理解跨應用、跨模態的長期脈絡。

手機助手若要回答「女兒七歲生日有哪些照片」或核對過敏藥物，單靠短對話記憶很快會失準。MobileMem 屬於端側長期記憶（on-device long-term memory）的評測框架與資料集，將一年手機經歷整理成可重現的測試環境，檢驗記憶系統能否跨應用保留、連結及找回重要資訊。

它涵蓋 365 天、12 個應用程式，以及每位使用者平均 1.72M tokens 的資料規模，來源包括對話、日曆、筆記、瀏覽紀錄和相片等異質內容。與只測單輪問答或獨立文件檢索的做法相比，MobileMem 更接近長期使用情境，但同時令資料整理、隱私處理和推理成本變得更複雜。

資料分為兩條 benchmark track：text 供文字記憶系統處理長期對話與結構化 mobile-app events；omni 則加入 screenshots 和 photos，測試多模態記憶。它本身不是模型，而是用來比較不同 memory systems、分析失敗原因及建立 leaderboard 的測試基礎。

• 支援文字與多模態兩類測試
• 涵蓋跨應用、長期且知識密集的 mobile agent trajectories
• 可從 HuggingFace 下載資料集
• Dataset Explorer branch 提供互動式資料瀏覽
• 現有資訊未列出具體模型分數，需查看 leaderboard 或自行重跑測試

研究人員可先下載 HuggingFace 資料集，按 text 或 omni 軌道接入自己的記憶模型，再利用網站和 Dataset Explorer 檢查案例。適合開發 mobile agents、personalized assistant、長期 RAG 或 multimodal memory 的團隊；涉及健康紀錄、家庭相片等私人內容時，仍要自行確認資料授權、匿名化和端側部署要求。

項目主頁 · GitHub

Categories: 開源, Agentic, RAG, 多模態模型, Medical醫學, 中國, Dataset 數據集

---

MiniMax-H3-Text-Embeddings ?

2026 年 8 月 15 日 Share to X Copy link

這不是傳統 NLP 或 RAG 領域中所指的「文本向量嵌入（Text Embedding）」模型。

這不是傳統 NLP 或 RAG 領域中所指的「文本向量嵌入（Text Embedding）」模型。MiniMax-H3-Text-Embeddings 實際上是 DiffSynth-Studio 團隊為 MiniMax-H3 影片生成大模型所設計的「視覺特效/風格控制向量（Diffusion Templates / Textual Inversion）」。

MiniMax-H3 是一個高達 33B 參數的大型多模態生成模型，若要透過訓練 LoRA 來控制風格或特效，顯存與算力成本非常高。DiffSynth-Studio 團隊採用了類似 Textual Inversion（文字翻轉/概念嵌入） 的做法：

1. 極輕量替代方案：將特定特效（如火爆、風暴、環繞鏡頭等）預先訓練或編碼成特徵 Tensor。
2. 直接注入文字特徵層：這些檔案體積非常小，能在推理階段直接替換或疊加到 MiniMax-H3 的 Text Encoder 輸出上。
3. 模組化與組合：使用者可以像掛載外掛一樣，組合多個特效 Embedding 來控制生成的影片視覺效果。

3. 總結建議

• 如果你是在找 RAG / 知識庫 / 搜尋用的文本嵌入模型：請忽略此模型，這不是向量檢索工具。
• 如果你是在使用 DiffSynth-Studio 進行 MiniMax-H3 影片生成：這是用來快速套用影片特效、節省顯存並替代重型 LoRA 的控制模組。

項目主頁

Categories: 開源, RAG, Embedding, 視頻模型, MiniMax

---

NanoVDR：70M 文字編碼器取代 2B VLM：視覺文檔檢索的輕量化新嘗試

2026 年 8 月 12 日 Share to X Copy link

NanoVDR 把 2B 參數嘅視覺語言模型蒸餾成 69–151M 嘅純文字編碼器，查詢時完全唔需要視覺模型，CPU 51 毫秒即可完成。

處理幾十萬張文件圖片嘅時候，每次查詢都要過一次 2B 嘅視覺語言模型（VLM），開銷大到令人卻步。NanoVDR 想解決嘅就係呢個落差：文件索引由教師模型離線建好，查詢階段只用一個 DistilBERT 規模嘅純文字編碼器，CPU 上 51 毫秒出結果，2048 維嘅單一向量直接做點積，扔得入 FAISS。

佢嘅做法係將 Qwen3-VL-Embedding-2B 凍結做教師，提早把目標向量快取落嚟，學生只係學一個餘弦距離嘅 loss——即係 loss = 1 - cos(student, teacher)。訓練時冇相關性標註、冇負例採樣，兩邊完全解耦，所以查詢端同索引端可以分開換組合。DistilVDR 進一步把文件端都換走，做到成個流程都唔再需要教師。

對於做企業 RAG、法律文件搜尋、學術庫檢索嘅團隊，最大吸引力係每頁索引得 4 KB，比 ColPali 嗰類多向量檢索慳 64 倍儲存，而且唔使 GPU 即可頂住查詢負載。ViDoRe v1 上面，NanoVDR-S-Multi 拎到 82.2 NDCG@5，保留咗教師大約 95% 嘅能力，呢個取捨對批量部署嚟講好實際。

重點摘要：

• 極輕量查詢端：文字編碼器僅 69–151M 參數，無需視覺模型參與查詢
• 高效索引：每頁僅 4 KB（float16），比多向量方案節省約 64 倍儲存
• 簡易整合：輸出為單一向量，FAISS 即可處理，無需 MaxSim 池化
• 教師-學生解耦：目標向量預先快取，兩端可獨立訓練與組合
• 完整資源：模型、訓練數據集、線上 Demo 同論文均已開源

多向量查詢塔嘅程式碼已就位，但 checkpoint 要等 NanoVDR-v2 先出齊，想要更高召回嘅人需要留意後續更新。

項目主頁 · GitHub

Categories: 開源, RAG, Embedding, 模型, 視覺模型, 多模態模型, Qwen

---

UEmbed：單一模型同時做稠密與稀疏檢索

2026 年 8 月 4 日 Share to X Copy link

UEmbed 把文字、圖片、影片都放進同一套 embedding 流程，令稠密向量與稀疏詞彙向量可以一併輸出。對要做多模態搜尋或檢索增強生成的團隊，這種設計可減少來回切換模型。

UEmbed 把文字、圖片、影片都放進同一套 embedding 流程，它走的是多模態 embedding 模型路線，重點是把 dense 向量和 SPLADE-style sparse lexical 向量放在同一個 causal forward pass 內處理，方便直接做檢索、多模態搜尋和 visual-document retrieval。它不是只做文字匹配，而是把文字、圖片、影片與混合輸入統一到同一套表示空間。

直接取用 Hugging Face 上的 2B、4B、9B 權重，再按輸入格式送入不同媒體內容，檢查 dense 與 sparse 輸出是否符合預期。若要部署到搜尋系統，dense 部分可接向量檢索，sparse 部分可接倒排索引，兩條路可以同時保留。

它和傳統 learned sparse retriever 最大分別，在於保留 decoder-only multimodal backbone，並用 16 個 learnable special tokens 分攤稀疏詞彙空間，避開單一 token 的表達瓶頸。訓練時同時優化 dense InfoNCE、sparse InfoNCE 和 FLOPS regularization，取捨是結構較巧，但推理時可以用同一個模型兼顧語義召回與詞彙可解釋性。

效能方面，UEmbed-9B 在 MMEB-v2 取得 71.8（dense）與 71.0（sparse），並在公開數據訓練條件下做出很強的稀疏檢索表現；在 BEIR 上亦保持競爭力。對做搜尋、RAG、跨媒體內容索引，或者要把文字與圖像一齊納入檢索的團隊，這套做法會較有吸引力。

• 同一個模型同時輸出 dense 與 sparse 表示
• 支援文字、圖片、影片與混合輸入
• 稀疏輸出可直接對接倒排索引，較易解釋
• 以 Qwen3.5 multimodal backbone 為基礎，並用公開資料訓練
• 2B、4B、9B 三個規模可選

項目主頁 · GitHub

Categories: 開源, 阿里巴巴, RAG, Embedding, 模型, 多模態模型, Qwen, Image

---

ARI 用 RAG 修復韓國朝鮮古籍殘字

2026 年 7 月 28 日 Share to X Copy link

遇到人名、地名殘缺的古籍，單靠上下文往往會估錯。ARI把檢索到的史料一併交畀模型判斷，明顯更適合做歷史文獻修復。

最值得留意的，不是模型把缺字補回來本身，而是它專門處理古籍修復最棘手的一類內容：人名、地名等 Named Entities。ARI 屬於一個結合 Retrieval-Augmented Generation（RAG）的文獻修復框架，針對朝鮮王朝實錄與承政院日記這類韓文漢字史料，補足只靠局部語境時經常失準的缺口。

現有做法多數依賴 masked language modeling，擅長根據前後文猜測一般字詞，但一遇到需要外部史實支持的專名就容易失手。ARI 的取向很清楚：先用 BM25 從歷史語料找出前 20 份相關文本，再以字串相似度 0.8 過濾重複內容，將這些外部證據交給模型一併生成，修正通用 LLM 容易出現的幻覺。

模型部分不是從零開始，而是建基於 Qwen3 32B 與 Qwen3 8B 微調成 ARI-32B 和 ARI-8B，並加入 25% named entity-prioritized masking 訓練策略，把學習重點放在知識密集片段。論文亦指出，對漢字材料而言，詞彙層面的 BM25 檢索比 embedding-based retrieval 更有效，這一點頗有說服力，因為表意文字的字形與字詞對應關係本身就影響檢索效果。

• 適合歷史文獻整理、數位人文研究與古籍校勘團隊參考
• 主要強項在於修復需要外部知識支撐的 Named Entities
• ARI-32B 與 ARI-8B 同步提供，前者追求表現，後者較重視運算成本
• 論文結果顯示，它在 named entity 與隨機遮罩字元修復都勝過多個基線與通用模型

把它視為一個已有公開模型與方法說明的研究項目。對需要先驗證效果的人來說，現階段較合理的路線會是先查看論文設定與模型頁面，再判斷是否足以接入自己的古籍修復工作流。

項目主頁 · GitHub · Paper

Categories: 開源, RAG, Embedding, 模型, Qwen, 語音, Dataset 數據集

---

FinanceComplexQA 點評：金融長文件問答基準

2026 年 7 月 26 日 Share to X Copy link

想測試模型是否真係讀得懂財務文件，FinanceComplexQA比一般抽句式問答更貼近難題。它把中英雙語、推理、多步計算與文件依據綁在同一個基準內。

金融問答最容易失真的位置，不是模型識唔識術語，而是它會否真正在整份參考文件入面推理、比對同計數。FinanceComplexQA屬於數據集／Benchmark，焦點不是背答案，而是檢驗 LLMs 和 agents 能否根據完整 reference documents 回答複雜金融問題。

它修正了只靠 parametric knowledge 或抽取單一段落的評測範式。作者把重點放在 document-grounded complex financial QA，要求答案同問題及原始文件一致，並涵蓋 multi-hop reasoning、numerical calculation、comparison、implicit inference、planning、summarization 同 evidence-grounded verification，對 RAG、Agentic workflow 同長文本閱讀能力都有參考價值。

資料結構本身亦有取捨。FinComplexQA-Pro 收錄 2,026 組獨立 QA，按語言、金融場景與任務分類組織；同一題會以 scene_categories 與 task_categories 兩種視角出現，所以總記錄視圖有 4,052 筆。另有 overall 提供 agent_answer、agent_thinking 及 LLM-as-a-judge 分數，但這些分數只適合做診斷訊號，不能當 ground truth。

• 支援中文與英文，但兩個子集覆蓋的文件領域不同，schema 亦不完全一致
• 較適合逐個子目錄讀取 JSONL，而不是一開始合併全部資料
• 可用 exact match、數值容差、F1、semantic similarity 等方法比對輸出
• 附有 Reference_documents，方便追查 PDF 與 LaTeX 原文證據

部署和測試的理解方式相當直接：資料主要在 Hugging Face 發佈，研究團隊可先挑單一語言、單一 task category 載入，再把模型輸出對照 gold answer 或文件證據做評估。它較受惠於做金融 RAG、長文件 QA、Agent 評測或雙語研究的團隊；要留意的是金融事實具時效性，而且項目已明確標示僅供研究與評估，不應延伸成投資、會計、法律或財務建議。

項目主頁 · GitHub · Paper

Categories: 開源, Agentic, RAG, 多模態模型, 微軟, DeepSeek, 中國, Dataset 數據集

---

PixelRAG 想用截圖重寫 RAG 檢索

2026 年 7 月 18 日 Share to X Copy link

當文字檢索捉唔到版面、圖表同視覺線索，PixelRAG 會改為讀網頁截圖。你可以把它理解成幫 RAG 補上「睇畫面」能力的一套檢索工具。

遇到表格、版面層次、插圖同文字混排內容，單靠文字檢索好容易漏掉關鍵線索；PixelRAG 就係衝住呢個缺口而來。它屬於一個面向 Retrieval-Augmented Generation 的開源工具項目，核心做法係先把頁面或文件渲染成 screenshots，再按畫面內容建立可搜尋索引，讓 Claude 之類模型唔只讀字，亦可以靠視覺內容搵資料。

呢個取向同傳統 RAG 最大分別，在於它假設「文件點樣呈現」本身就係訊息，而唔係只抽文字再做 embedding。代價亦好直接：前處理多咗一層 render，索引與搜尋流程會更倚賴視覺管線；但換來的好處，是面對網頁、圖文混排文件，甚至靠版面先分得清的內容時，命中機會更高。

目前公開資訊已經交代得幾清楚：安裝後可以先用 pixelshot 把任意頁面輸出成 screenshot tiles，再接上搜尋流程；亦可以直接調用官方託管 API，對既有的 8.28M Wikipedia pages 索引做查詢，連本地建庫都未必需要。它仲支援用文字查詢，並提供 visual search，意味住輸入端都唔再局限於純文字。

• 把文件先轉成 screenshots，再做檢索，而唔係只抽文字
• 適合網頁、表格、圖文混排等重視版面結構的內容
• 可直接試用 hosted API，亦可自行跑 render 與 search 流程
• 與 Claude 配合時，重點在於補足模型對畫面資訊的讀取能力

受益最大的一般會係做 RAG 應用、文件搜尋、知識助理同企業內部資料檢索的團隊，尤其手上資料唔係乾淨純文字，而係大量網頁截圖感強、排版複雜的內容。名稱已經講明「Web Screenshots Beat Text for Retrieval-Augmented Generation」，定位相當鮮明；不過 README 暫時未交代完整基準數字同部署成本，現階段更適合視為一條值得驗證的新路線，而唔係即刻取代所有文字檢索方案。

GitHub

Categories: 開源, RAG, Embedding, API, 框架

---

MedPMC 把醫學圖文資料做成可訓練基座

2026 年 7 月 14 日 Share to X Copy link

想做醫學影像與文字理解，卡位通常唔係模型，而係乾淨又夠大的圖文配對。MedPMC 把這件事連同訓練流程一併開放，方向相當務實。

做醫學多模態模型，最難往往不是再堆一個新架構，而是先整理到可用的圖文資料。MedPMC 屬於Dataset 數據集加模型訓練程式碼項目，核心價值是把 PubMed Central (PMC) 文獻中的醫學圖片與文字抽取、清理，再接上訓練與評估流程，處理的是醫學 vision-language 資源長期分散、難重現的問題。

目前最值得留意的是 MedPMC Dataset 首個版本，提供約 1,100 萬組 medical image-text pairs；同時亦有基於 MedPMC-11M 訓練的 MedPMC-CLIP。這種做法與不少只放模型權重、或只交出資料連結的項目不同，它把 dataset curation、preprocessing、model training、evaluation 放在同一個代碼庫，較適合研究團隊沿住同一條流程再做微調或重跑實驗。

部署與測試的理解方式很直接：資料集與模型都已放到 Hugging Face，現階段較像給研究者先下載資料、檢查抽樣品質、再接入自家訓練管線。README 未提供很完整的操作文件，dataset viewer 亦未必可直接預覽，所以短期內它比較偏向有 Python 與資料處理能力的團隊，而不是即開即用的線上服務。

• 約 1,100 萬組來自 PMC 的醫學圖文配對，是項目現時最重要資產
• 連同 MedPMC-CLIP 一併釋出，方便由資料走到模型驗證
• 重點不在花巧介面，而在可重現的資料整理與訓練流程
• 文件仍在補完中，benchmarks 與更多 training recipes 尚待發布

以現有資訊看，MedPMC 的強項是規模與研究流程整合，限制則是文件與基準結果仍未齊備，暫時較難單靠公開頁面判斷模型表現上限。對醫學 AI、視覺模型、RAG 前處理，或需要建立醫學圖文檢索基座的團隊來說，這個開源項目已有不錯參考價值；相關模型現時可確認的是 MedPMC-CLIP。

項目主頁 · GitHub · 模型

Categories: 開源, RAG, 視覺模型, 多模態模型, 模型訓練, NVIDIA, Image, Medical醫學, Python, Dataset 數據集

---

NL2SQL 如何走向企業級數據智能體

2026 年 7 月 4 日 Share to X Copy link

這項文章整理 NL2SQL 由語義解析到智能體化的演進重點，說明它點樣由「寫 SQL」變成「理解業務查數」。

這是一篇介紹 NL2SQL（Natural Language to SQL）與 Text2SQL 技術演進的技術文章。它主要說明系統如何把自然語言查詢轉成可執行、可驗證，而且符合業務語義的 SQL，而不只是做文字層面的翻譯。

文章指出，NL2SQL 真正處理的是「業務語言」與「資料庫結構」之間的落差。使用者問的是模糊的商業問題，系統卻要完成查詢意圖理解、表與欄位定位、JOIN 路徑規劃、SQL 校驗、執行與結果驗證，所以它同時牽涉 NLP、資料庫、程式生成、資訊檢索與系統工程。

和早期把 NL2SQL 視為 Seq2Seq 翻譯任務的做法相比，文中更強調執行語義等價。一段 SQL 就算語法正確，也可能選錯表、誤解指標口徑，或者在聚合粒度、過濾條件與權限範圍上出錯，因此企業場景的重點不是「生成像 SQL 的文本」，而是產出能在真實數據環境中正確運作的查詢邏輯。

• 技術演進由規則模板、傳統語義解析、Seq2Seq，一路走到 Schema Linking、Schema-aware、Graph-based、RAG + LLM
• 核心難點不只在生成 SQL，更在表、欄位、值與業務指標的語義映射
• 新一代方向是 Agentic + Semantic Layer，加入檢索、規劃、校驗、修復與解釋能力
• 固定報表場景可用模板法提升穩定性，但覆蓋率有限，難應付開放式提問

這類內容最適合數據平台、BI、自助查數與企業 AI 問答工作流的讀者閱讀。文中提供的是技術脈絡與方法拆解，暫時未見具體安裝流程、下載連結或可直接啟用 OpenClaw、OpenCode、Codex、Hermes Agent、Copilot、Pi 的後台操作資訊，因此不能延伸成相關部署教學。

項目主頁

Categories: Agentic, RAG, OpenClaw

---