InferNews

BVB 用 影片內容令 AI 自動轉為 Blender 3D 場景

Share to X

BVB 拋開選擇題，要求 AI 代理直接用 Blender 重建 288 段真實室內影片，從程式碼品質判斷它到底有冇真正理解畫面內容。

BVB logo

現時大多數影片理解 benchmark 都係問 AI 「張圖入面有幾多張椅」，但 BVB（Blender-VideoBench）行另一條路：畀 AI 睇一段室內影片，然後叫佢自己寫 Blender 腳本，把場景、鏡頭動線逐個 primitive 砌返出嚟。如果代理人交到一個可以重新開啟、可以渲染嘅 .blend 檔，代表佢真係睇明條片。

每個代理會都被困喺同一個 Blender 4.2 Docker 沙盒入面，淨係可以用 bash 同 frames，仲有共享成本上限。禁止使用任何外部素材庫，幾何體全部由代理自己用基本操作砌出嚟。呢種「同條件競技」設計解決咗以往影片 benchmark 靠選擇題容易被 prompt hack 或者背答案嘅問題。

數據方面，BVB 用咗 ARKitScenes、ScanNet、ScanNet++ 嘅 288 段室內影片，配合 5,130 條時空題目，並涵蓋 10 個模型家族、共 51 個配置。評分用兩條軸：Dual VQA 睇重建場景保留幾多影片入面嘅時空事實；Latent Similarity 就用凍結影片 embedding 對比重建結果同原片嘅感知距離，再以平方根均值合成綜合分數。

對做空間智能、機器人感知或者影片理解研究嘅團隊嚟講，呢個 benchmark 提供咗一個更貼近「代理人真係要喺軟件入面操作世界」嘅測試場景。視頻生成、動畫製作或者世界模型團隊亦可以直接借用 Mini-BVB harness 喺自己 pipeline 度做壓力測試。

團隊結果顯示，最強配置喺 Latent Similarity 做到 88.6，但 Dual VQA 仲有明顯差距，代表現時頂級模型仲未做到「理解」同「重建」兩條線同步推進。呢個落差本身就係 BVB 想凸顯嘅訊號：識答題未必等於識建模。

重點摘要

  • 288 段真實室內影片，全部來自 ARKitScenes、ScanNet、ScanNet++ 嘅 held-out split。
  • 51 個代理配置橫跨 10 個模型家族，統一跑喺 Mini-BVB 沙盒同成本上限下。
  • 禁止使用外部素材庫，逼代理人由 Blender primitives 自己砌幾何。
  • 評分用 Dual VQA 加 Latent Similarity 兩條軸，避免單一指標偏廢。
  • 目標係可執行、可重新渲染嘅 .blend 檔案，而唔係文字描述或者單張圖。

項目主頁 · GitHub

Categories: 開源, Agentic, AI productions, Embedding, 視覺模型, 多模態模型, 世界模型, Qwen, OpenAI, Gemini, Video, 軟件, 庫, Anthropic, 動畫, Dataset 數據集

MovieGrid 把長片拆成方格生成，解決多鏡頭一致性

Share to X

來自 UC Santa Cruz 等院校的 MovieGrid 框架，把長片拆成空間方格同步生成，目標是同時兼顧鏡頭內連續動作與跨鏡頭視覺一致性。

Repository image for jwmao1/moviegrid

MovieGrid 針對的痛點很直接：現有影片生成模型傾向犧牲多鏡頭敘事完整性來換取單鏡頭內的動作連貫，而傳統把整段故事沿時間軸壓縮的做法，更會加深這個偏差。

核心做法是把一段長影片切成分佈於空間方格上的短片段，每格只負責少量鏡頭與較短的時間跨度，從而降低單格需要建模的轉場數量；同時所有格子會被聯合生成，並透過 Grid Embedding、角色感知的 Story Prompt 以及 Grid Boundary Loss 來維持格與格之間的銜接。訓練時採用的 Noise-Free Random-Grid Training，會隨機保留部分格子作為乾淨視覺上下文，引導其餘格子的去噪過程。

項目以 Wan2.2-TI2V-5B 作為基座模型，並配搭自家構建的 MGLV 資料集——從 1,000 段長片萃取出 54K 條方格影片，每條都附有角色級故事標註。在等量 token 預算下，MovieGrid 在 1,616 幀長片裡可生成比 Temporal Packing 基線多 6.05 倍的鏡頭，並在自建基準上取得 0.9131 的鏡頭內一致性與 0.5914 的跨鏡頭一致性，分別優於 HoloCine 與 StoryMem。

目前已開源 16 格與 64 格的訓練與推理配置，以及對應的 MovieGrid-16、MovieGrid-64 LoRA 權重；環境需以 Python 3.10 搭配官方 Wan2.2 倉庫安裝。對需要批量產出多鏡頭短片、廣告分鏡或敘事預覽的團隊，這套框架提供了比單時間軸方案更可擴展的路徑，但生成品質仍受基座模型與資料規模所限，未來計劃加入 first frame 與 storyboard 條件控制。

重點摘要：
– 核心方法：將長片切成空間方格短片段並聯合生成，減輕每格時間跨度負擔。
– 關鍵機制：Grid Embedding、角色感知 Story Prompt、Grid Boundary Loss 與 Noise-Free Random-Grid Training。
– 基座與資料：基於 Wan2.2-TI2V-5B，配搭自建 MGLV 資料集共 54K 條方格影片。
– 開源狀態：已釋出 16 格與 64 格的推理配置、訓練代碼，以及對應 LoRA 權重。

項目主頁 · GitHub · 模型

Categories: 開源, AI productions, Embedding, 模型, 模型訓練, Video, 框架, Python, 庫, Dataset 數據集

Hojo TTS Light 輕量語音合成，4000 萬參數就做到 15 種聲線

Share to X

Hojo-TTS-Light 僅約 0.08B 參數，以 ONNX 格式在 CPU 即時合成 24 kHz 語音，並預載 15 種聲線，免依賴 PyTorch。

Og image

想把文字轉語音（TTS）嵌入邊緣裝置或本地腳本，最大阻力往往來自 PyTorch 依賴肥大、GPU 門檻高。Hojo-TTS-Light 直接以 ONNX Runtime 執行，連 PyTorch 都不用安裝，對只有 CPU 或資源受限的環境相當友善。模型檔約 4000 萬參數（0.08B），輸出 24 kHz 音訊，並內建 15 種預設說話人聲線，開發者只需切換 embedding 即可換聲，省下自行收集語料或微調的工序。

隨倉提供的 infer.py 與 onnx_model.py 展示完整推理流程，搭配 requirements.txt 即可用幾行程式碼完成合成。對需要快速在本地或伺服器側加入語音回饋的項目而言，這種「開箱即播」的設計，比傳統 TTS pipeline 更貼近部署需求。

不過，15 種聲線屬於 preset 性質，若要新增自訂說話人，就需要額外準備參考音訊與對應 embedding，無法像大型 TTS 模型那樣靠一句話克隆。整體取向偏向「輕量、即用」，而非追求擬真度或表現力。

重點摘要：

  • 參數量約 0.08B，屬輕量級 TTS 模型
  • 採用 ONNX 格式，免安裝 PyTorch 即可在 CPU 環境執行
  • 預載 15 種 speaker-conditioned 聲線，可即時切換
  • 隨附 infer.py、onnx_model.py、requirements.txt，方便快速整合
  • 發佈平台為 Hugging Face，授權與權重可至該頁查閱

適合需要把語音合成嵌進邊緣裝置、CLI 工具或本地自動化流程的開發者；對追求高擬真或自訂聲線克隆的場景，則需要再評估擴充成本。

項目主頁

Categories: 開源, 文字轉語音, Agentic, Embedding, 模型, Audio, 語音, Skill 技能

KBMR 視覺問答檢索帶向實體語義

Share to X

KBMR 針對 KB-VQA 容易搵錯相似圖片的問題，以 MLLM 將檢索焦點由外觀匹配轉向實體語義。

KBMR method overview

面對人物、地點或物件，KB-VQA 若只按圖片外觀搜尋，容易因視角、年代和風格變化搵錯資料。KBMR 屬於面向 Knowledge-Based Visual Question Answering（KB-VQA）的多模態模型檢索器，實際處理的是「畫面相似但實體不同」的證據搜尋問題。

KBMR 先由 EVA-CLIP-8B 篩選候選，再以 MLLM-based Semantic Discriminator 為查詢與候選產生連續的 entity-consistency weights。Qwen2-VL-7B 以這些語義訊號訓練 embedding retriever，並透過 symmetric KL distillation，令 cosine similarity 得出的 retriever posterior 與 discriminator weights 形成的 semantic prior 對齊。

重點整理為：
– 由 surface-level visual matching 改為 entity-aligned semantic retrieval。
– 連續權重可支援較可靠的 hard-negative mining 和 soft supervision。
– 替換原有 first-stage retriever，毋須改動下游 reasoning 或 reranking。
– 不同 KB-VQA pipeline 的端到端答案準確率最高提升 9.4 個百分點。

這種取捨適合已有 KB-VQA、外部知識庫和後續推理流程的研究團隊，因為 KBMR 主打 plug-and-play 替換檢索器，而不是重新設計整條系統。KBMR 列出 Python 3.10+、EVA-CLIP-8B 及 Qwen2-VL-7B 等準備項目，亦包括訓練和評估章節；目前已提供完整安裝指令、模型取得方式及獨立推理流程。

GitHub

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

SimLoss 用單次生成多階段圖像描述

Share to X

由 UMass Amherst 與 Adobe Research 團隊開發，SimLoss 想解決圖像描述太籠統的老問題。它把細節監督搬到 embedding space，換來更快推理與更高描述精細度。

Repository image for srynsh/SimLoss-Image-Captioning

UMass Amherst 與 Adobe Research 團隊，瞄準的是圖像描述常常只講到大意、漏掉材質、數量、紋理同位置關係的問題。SimLoss 屬於影像 captioning 模型訓練方法，核心不是再加一條冗長後處理流程，而是令 Vision-Language Model 在單次生成前，先把隱藏狀態對齊影像 embedding，直接補回細節監督。

它的技術關鍵，在於用 reference-free 的 embedding-space objective 取代人手撰寫細粒度 captions，亦唔需要先跑多階段系統去製造 pseudo-captions。SimLoss 列出兩條路線：SimLoss FFT 會透過本地可用的 Qwen3-VL-Embedding-2B 反向傳播；SimLoss GRPO 則把 Gemini Embedding 2 當成 black-box reward。兩者都建基於 Qwen2.5-VL-7B-Instruct captioning policy，但前者偏向直接做表徵對齊，後者更接近以獎勵訊號微調。

同類方法常見做法，是生成、拆解、驗證、重寫逐步修補描述內容；SimLoss 揀的是保留 single-pass inference，換取更低延遲，再用對比式學習補回細節。代價是它仍然依賴外部 embedding 模型品質，而且項目展示的是研究基準與訓練框架，不是即裝即用的成品服務。

IIW-400 測試中，SimLoss FFT 配合 Qwen2.5-VL-7B backbone，把 precision 由未調整 backbone 的 0.788 提升到 0.849，F1 與多階段 CapMAS 接近到難以區分，同時推理速度約快 20 倍；SimLoss GRPO 則拿到最強 recall。呢個取捨幾實際：想要更準確地講出畫面細節，又唔想接受多步驗證延遲的團隊，會比一般 captioning fine-tune 更感受到差別。

  • 同一儲存庫放入 SimLoss、CapMAS、PAPO、DCScore RL 等基線，方便直接比較
  • 單次生成保留低延遲，同時補足 attributes、counts、textures、materials、spatial relations
  • 提供方法分目錄、資料與 checkpoint 說明，但大型資料與模型檔案未隨儲存庫附上

研究、內容理解、影像搜尋標註，甚至要為電商圖片或視覺資產建立更細緻描述的團隊，都會較容易受益。安裝與執行入口在儲存庫內有 setup 與各方法，但目前公開資訊主要指向研究復現流程；想完整重跑訓練或延遲基準，仍要另外處理資料集、checkpoint 同對應運行環境。

項目主頁 · GitHub

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

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

Share to X

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

WeMM-Embedding Performance Overview

把文字、圖片、短影片、文件截圖一次過丟進同一個嵌入空間做檢索，一直是多模態團隊頭痛的工程難題。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 數據集

VoiceMem 讓語音 AI 記住你的情緒與偏好

Share to X

VoiceMem 以流式雙腦架構處理事實記憶、情緒與人格，讓語音智能體在對話中更懂使用者，同時控制延遲與成本。

VoiceMem Logo

語音智能體要記住「我是素食者、對堅果過敏」，並不只是保存轉錄文字，還要分辨人物、情緒、偏好與性格。VoiceMem 屬於語音 AI 記憶引擎及可整合的庫，處理音訊輸入、記憶抽取、檢索和回應前的上下文注入，讓長期個人化對話不必每次重新建立背景。

它採用 VoiceMem Dual-Brain Streaming Architecture（流式雙腦架構）：左腦以 schema 與 entity 組織事實記憶，右腦獨立管理情緒、偏好和人格，亦維護跨 entity 的關聯。音訊仍在輸入期間，系統已經分段、轉錄、抽取資料並寫入記憶圖；查詢時先路由及排序，只把 Top-K 記憶放入上下文，減少語音回應需要處理的內容。

  • 左腦在 Top-3 限制下維持 Mem0 的滿載性能
  • 右腦加入長短期情緒歸因及交叉節點
  • 透過壓縮資訊、分層儲存和流式查詢降低等待時間
  • 單輪查詢約需 300 token，架構及底層記憶引擎可替換

VoiceMem 內置 ASR（Automatic Speech Recognition）、聲紋、場景、情緒感知及本地 embedding 元件，亦提供離線記憶引擎和 streaming interface。倉庫資訊包含 Python 庫、互動式網頁 demo、VoiceMem_Default_Models_Env 模型環境，以及可選的 Qwen 回應模型；但完整硬件要求、服務依賴和模型授權仍需按連結內容逐項確認，不能單靠 README 推斷。

ChatMem-400K 以記憶世界構建、SLM 驗證的 online on-policy distillation 和人工修訂三階段製作，配合 VoiceMem Model Families 的 Qwen3 6 35B A3B Qlora 模型系列。這令項目較適合需要長期語音陪伴、個人助理、客服或具情緒連續性的 voice agent 團隊；對只需短對話轉錄的工作流，雙腦記憶層會增加整合和維護成本。

項目主頁 · GitHub · 模型

Categories: 開源, 香港中文大學, 清華大學, Agentic, Embedding, 多模態模型, Qwen, Python, 庫, 語音

WeMM-Embedding 統一多模態向量

Share to X

WeMM-Embedding 把文字、圖片、影片和視覺文件放進同一套向量空間，適合要做檢索、比對和跨模態搜尋的場景。它同時提供不同尺寸選擇，方便在準確度與成本之間取捨。

WeMM-Embedding Performance Overview

WeMM-Embedding 是一組多模態 embedding 模型，目標是把文字、圖片、影片、視覺文件和交錯式多模態輸入，轉成可直接比對的統一向量。對要做搜尋、相似度比對、內容檢索或跨媒體匹配的團隊來說，這種做法比逐一分開處理不同素材更省事。

它提供 2B、4B、9B 三個版本，還支援 Matryoshka dimensions，代表可以按需要輸出不同長度的 embedding，減少計算和儲存成本。README 也提到，向量來自 <embedding> token 的最後一層 hidden state，再做 L2 normalization；目前不支援 audio。

實作和試跑方式都算直接，既可以用 transformers，也可以用 SentenceTransformer 直接載入 Hugging Face 模型 ID。作者同時標明推理較建議用 transformers==5.2.0，原因是較新的版本在前處理行為上可能有差異；serving 方面則測過 vLLM 和 SGLang。

  • 統一處理 text、image、video、visual document 和 interleaved multimodal inputs
  • 支援 Matryoshka dimensions，可按成本需要縮短 embedding 長度
  • 適合做跨模態搜尋、內容去重、相似度比對和檢索索引
  • 推理可用 transformers 或 SentenceTransformer，部署可接 vLLM、SGLang
  • 現階段不支援 audio，做語音相關流程要另配其他模型

對要處理多媒體內容的應用團隊、檢索系統、內容平台和資料整理流程，這類模型最直接的價值是減少多套表示法之間的銜接成本。它在多個基準上取得領先結果，但實際選型仍要看你要的是完整維度、較低成本版本，還是偏向部署效率的配置。

GitHub · 模型

Categories: 開源, 騰訊, AI productions, Embedding, 模型, 多模態模型, Video, Image, Audio

InfinityEdit：支援多輪連續編輯嘅開源影片框架

Share to X

InfinityEdit 將影片編輯變成連續接力，每個指令都在上一段結果上再延伸。它適合要處理長片段、持續畫面同多輪改動嘅場景。

Pianist source video thumbnail

InfinityEdit 係一個影片編輯框架，核心問題唔係單次改一段短片，而係面對持續流入嘅影片，連續套用多個指令，令後一段自然接住前一段，仲要保住畫面連貫。對做長片生成、直播式視覺改寫，或者需要一路加指令一路修正畫面嘅工作流程，佢處理嘅正正就係「編輯唔可以只限喺固定片段內」呢個限制。

佢嘅做法係喺凍結嘅 video diffusion backbone 上面加一個輕量嘅 Edit-Ignition Adapter，令原本負責串流生成嘅模型多咗三層訊息路徑：歷史畫面引導、時間因果注意力，同埋編輯指令注入。生成時只會喺有新編輯指令到達嘅那一段啟動 adapter，之後嘅片段就交回原模型接力，記憶體負擔唔會一路膨脹。

項目提供訓練程式同多輪推理流程，安裝方法都幾直接，先建 Python 3.11 環境，再裝 requirements.txt，之後下載基座模型 Helios-Distilled。訓練分兩階段，第一階段學基本編輯能力，第二階段再針對低噪聲細節同時間權重做修正；推理則會輸出一串 source.mp4、edit_1、edit_2 之類嘅連續結果，方便睇到每次指令點樣疊落去。

同一般固定源片逐格改寫嘅方法相比，InfinityEdit 睇重嘅係「延續」而唔係「覆寫」。呢個取捨令佢更貼近長影片、持續鏡頭、反覆編修呢類工作，但亦意味住訓練資料要先做 VAE latent 同文字 embedding 預處理，流程比即插即用工具重少少。官方展示同評估都集中喺長片生成同多輪 sequential editing，顯示佢嘗試解決嘅唔係單次風格轉換，而係編輯累積後仍然保持穩定。

  • 支援多輪順序編輯，每次指令都建立喺上一段已編輯內容之上
  • 以凍結 backbone 配合輕量 adapter，改動集中，唔需要重寫整個生成模型
  • 適合長片生成、持續鏡頭改寫、分段式影片修正呢類場景
  • 訓練同推理都已經拆好流程，但前期資料預處理同模型下載仍然係必要步驟
  • 評估重點放喺長序列穩定性同編輯連貫性，而唔係單一片段嘅局部改動

對做影片生成、研究串流式編輯，或者想將文字指令一路疊加到同一條影片流嘅團隊，呢個項目提供咗一個較完整嘅技術路線。佢唔係追求一次過改到最盡，而係用較細嘅介入，令編輯可以一路接力落去，仲保持住原本生成器嘅長片能力。

項目主頁 · GitHub

Categories: 開源, 阿里巴巴, Embedding, Video, 框架, Python

[技術文章]LLM 媲美 Embedding，成本卻高逾 1431 倍

Share to X

LLM已能追上頂尖Embedding模型，但搜尋系統未必值得因此承受高昂成本。

Hugging Face

做語意搜尋、分類或文件聚類時，LLM已能在多項測試追上專門的文字嵌入模型；但每次評測成本最高相差1,431倍，令「是否應取代Embedding pipeline」成為成本與能力之間的取捨。本頁屬研究論文內容，並非可直接下載的單一模型頁面；未有提供可確認的 base model 或 fine-tuned from 資訊，因此無法判定某個模型的原始基礎模型。

研究比較10個、來自6個家族的 large language models (LLMs)，以及26個參數量由118M至14B的 embedding models，測試涵蓋37項 MTEB(LLM) 任務，包括分類、semantic textual similarity (STS)、聚類、pair classification 和 retrieval。最佳 LLM Gemini 3.1 Pro 得分77.6，最佳 embedding model 得分77.2，差距只有0.4分。

  • Embedding models 在分類、相似度和聚類表現較合適
  • LLM 在需要推理的 retrieval 任務較有優勢
  • LLM 每次 benchmark pass 成本約154美元，embedding model 約0.11美元
  • 開源 LLM 在同一 GPU 上慢約2.5至736倍
  • reasoning tokens 佔 LLM inference 成本28%至81%

研究亦指出，降低 reasoning budget 對多數模型的 retrieval 品質沒有明顯傷害，反映混合式流程更合理：以 embedding model 負責大部分相似度搜尋，再把需要理解語境或多步推理的查詢交給 LLM。

Paper

Categories: Embedding, Qwen, Gemini, LLaMa, Ollama, Dataset 數據集, Kimi
Page 1 of 5
1 2 3 … 5