InferNews

DomainShuttle 開源：把主角穿梭到任何風格的影片

Share to X
teaser

DomainShuttle 是一個以 Wan2.2-T2V-A14B 為基底的 subject-driven text-to-video（主體驅動文字轉影片）框架，目標是讓用戶提供一張參考圖後，能在不同視覺風格與場景中維持同一角色的身份一致性。過去的 subject-driven 方法多在 in-domain（與訓練資料同域）下能保留主體細節，但一旦跨域到風格差異大的場景，主體往往走樣或失去身份特徵；DomainShuttle 把參考特徵與影片特徵解耦，並引入 domain attribute 建模與 intrinsic subject representation，試圖兼顧 in-domain fidelity 與 cross-domain editability。

開發團隊來自香港科技大學 C4G 實驗室，作者群包括 Nan Chen、Yiyang Cai、Rongchang Xie、Junwen Pan、Cheng Chen、Weinan Jia、Zhuowei Chen、Wen Zhou（項目負責人）、Zhenbang Sun 以及通訊作者 Wenhan Luo。等貢獻作者共同發表技術報告，並同時釋出 14B 規模的非官方權重與推理代碼。

先以 conda 建立 Python 3.10 環境並安裝 PyTorch 2.5.1（CUDA 12.4），接著執行 build_env_conda.sh。模型準備分兩步：先用 huggingface-cli 下載 Wan-AI 的 Wan2.2-T2V-A14B 作為基底模型，再下載 CNcreator0331/DomainShuttle_weight，最後將 VAE、configuration.json 等檔案移入指定的 ./models/Diffusion_Transformers/Wan2.2-DomainShuttle-A14B/ 目錄。原始資料未提供完整推論指令片段，相關細節需參考技術報告與項目頁面的後續說明。

從示範結果看，DomainShuttle 能在寫實人物、動漫風、Ghibli 風、3D 動畫風等不同域之間切換，同時保留臉部與服飾特徵，跨域 personalisation 效果明顯。適合短片創作、角色 IP 化、廣告分鏡與動畫預覽等需要「同一角色穿梭多場景」的團隊。需注意目前釋出的是非官方實作，且依賴 14B 規模的基座模型，部署對顯存要求較高。

重點摘要：

  • 類型：subject-driven text-to-video 框架，建基於 Wan2.2-T2V-A14B
  • 開發團隊：香港科技大學 C4G 實驗室，Wen Luo 為通訊作者
  • 核心設計：解耦參考與影片特徵、加入 domain attribute 與 intrinsic subject representation
  • 與同類差異：強調 cross-domain editability，補足過往方法跨域走樣的缺陷
  • 資源：已釋出 14B 權重、技術報告與推理代碼，需 CUDA 12.4 環境

GitHub： https://github.com/HKUST-C4G/DomainShuttle

項目主頁： https://cn-makers.github.io/DomainShuttle/

模型： https://huggingface.co/CNcreator0331/DomainShuttle_weight

Categories: 開源, 香港, 香港科技大學, NVIDIA, Stable Diffusion, Video, Content Creator, 3D, IDE, Python, Python NLP, 動畫, 模型, 視覺模型, 視頻模型, 框架

dots.tts：支持廣東話的連續式語音合成

Share to X
dots.tts

dots.tts 是一個文字轉語音（Text-to-Speech, TTS）模型，主要用來將輸入文字轉成自然語音，並兼顧聲線模仿同情緒表達。它採用全連續、端到端的自回歸（Autoregressive, AR）設計，整條流程都唔用離散 token，這點同不少傳統 TTS 做法有明顯分別。

項目提供本地模型目錄或 Hugging Face repo id 載入方式，亦有 CLI、Python API 同 Gradio 網頁示範可試。用 --prompt-audio 配合 --prompt-text 可以做延續式 cloning；只給 --prompt-audio 時則走 x-vector-only cloning；而 --language 可幫多語言或 code-switching 文字鎖定語言標籤。

这开源TTS 太狠了：3 秒复刻音色+情绪迁移，还能实时朗读！

它的取向偏向高保真同穩定生成，而唔係只追求速度。官方數據顯示，dots.tts 在 Seed-TTS-Eval 取得較佳平均表現，zh / en / zh-hard 的 WER 分別係 0.94% / 1.30% / 6.60%，MiniMax multilingual benchmark 亦有 83.9 的平均 speaker similarity，反映它在聲音相似度同多語言能力上都有競爭力。

較適合做語音產品原型、配音流程、虛擬人聲、以及需要少量參考音去複製語氣嘅團隊。要留意參考音大約 10 秒較合適，而且 --prompt-text 必須同參考錄音內容一致，否則穩定性會下降。

  • 2B 參數、全連續 AR TTS，核心目標係文字轉自然語音
  • 支援 voice cloning、多語言同情感表達
  • 提供 CLI、Python API、Web Demo，方便測試同部署
  • 評測上在 Seed-TTS-Eval 同 MiniMax multilingual 都有強勢成績
  • 相關模型包括 dots.tts-base、dots.tts-soar、dots.tts-mf

GitHub： https://github.com/rednote-hilab/dots.tts

模型： https://huggingface.co/collections/rednote-hilab/dotstts

Categories: 開源, 文字轉語音, API, Audio, Clone, Python, Python NLP, 模型, 語音

Unlimited-OCR：長文件 OCR 新取向

Share to X
Baidu Inc.

Unlimited-OCR 是一個 OCR 視覺文字辨識模型項目，也可視為一個針對長文件解析而改造的研究原型。它主要用來把圖片或 PDF 內的大量文字與版面內容一次過轉成可輸出的解析結果，重點是處理多頁文件時盡量減少記憶體負擔。

現有 end-to-end OCR 做法以 DeepSeek-OCR 為代表，會用 large language model（LLM）作 decoder，優點是能借助語言先驗提升辨識效果，但輸出一長，KV cache 會一路累積，令顯存需求上升、生成愈來愈慢。Unlimited-OCR 的做法是保留高壓縮 encoder，再把 decoder 的 attention 層改成 Reference Sliding Window Attention（R-SWA），讓每個 token 持續關注 reference tokens 與有限長度的前文，目標是把 KV cache 維持在常數規模。

這個取向最值得留意的地方，不是單純追求單頁最高精度，而是把「one-shot long-horizon parsing」放在核心位置。跟一般 full attention 比，它犧牲的是傳統全域注意力形式，換來多頁文件在 32K 長度下仍可做單次 forward pass；跟 vanilla SWA 比，它又保留 visual tokens 作為穩定參照，避免狀態傳遞後愈來愈模糊。

部署路線相當明確：項目提供 Hugging Face Transformers 推理方式，測試環境寫明需 NVIDIA GPU，並以 Python 3.12.3、CUDA 12.9 為基礎；單張圖片可在 gundam 與 base 兩種設定中選擇，多頁與 PDF 則使用 base 配置。想先了解效果，也可直接看 Hugging Face Spaces demo 或 ModelScope 版本，再決定是否自行落地。

  • 類型定位：OCR 模型／研究原型，解決長文件、多頁解析時記憶體與速度惡化問題
  • 核心差異：以 Reference Sliding Window Attention（R-SWA）取代 decoder 全部 attention layers
  • 適合情境：長 PDF、批量文件數碼化、需要版面解析與長輸出的團隊
  • 相關模型：DeepSeek-OCR、Unlimited-OCR；文中亦提到 R-SWA 可延伸到 ASR、translation
  • 限制判斷：目前公開資訊主力放在推理與方法設計，具體評測數字仍要回看 arXiv 論文原文才適合作更細比較

對需要處理保單、報表、掃描檔、書籍或多頁行政文件的團隊，這個項目的吸引力會比一般單頁 OCR 更高。若你的工作重點是短文字截圖、手機快拍辨識，Unlimited-OCR 的優勢未必完全發揮，但對長輸出穩定性與部署在 GPU 環境的可行性，它展示了一條很清楚的改良路線。

GitHub： https://github.com/baidu/Unlimited-OCR

Paper： https://arxiv.org/pdf/2606.23050

Categories: 開源, NVIDIA, DeepSeek, Image, Python, Python NLP, 模型, 視覺模型, Meta, 百度

SproutRAG：長文 RAG 檢索的新取向

Share to X
SproutRAG

現時不少 RAG（Retrieval-Augmented Generation）做法，通常在「細粒度 chunk 準確但零碎」與「大段內容連貫但嘈雜」之間取捨；有些方法靠 LLM-guided chunking、single-level context expansion，或 hierarchical summarization 去補救，但代價是要額外 LLM 呼叫、只支援單一層級擴展，或者在摘要過程流失資訊。SproutRAG 提出的方向，是用 attention-guided hierarchical RAG framework，把句子逐步組成語意連貫的多層結構，再做 multi-granularity retrieval。

這是一個 RAG 工具／框架，重點不是單獨一個模型，而是把索引、檢索、reranking、答案生成與評測串成完整流程，處理長文件問答中「證據要夠準又要保留上下文」的問題。它用 YAML 或 JSON config 驅動 CLI，每一步各有設定，輸出統一是 JSON，對接下游工具和保留可重現紀錄都幾方便。

部署和測試思路算清楚：先準備 JSONL 文件，之後分開建立 index、執行 retrieve、再 answer；若要研究效果，還可 train 和 evaluate。附加套件分別對應 PyYAML、ROUGE-L、METEOR、BERTScore 及 spaCy，反映這個項目除了生成，也很著重檢索與答案品質的量化比較。

和常見 flat retrieval 相比，SproutRAG 較值得留意的是 hierarchical attention-based indexing 加上 hierarchical beam search：它不是只撈單一粒度片段，而是沿樹狀結構找不同大小的候選證據。論文資料指出，它在四個 benchmark 的 information efficiency（IE）平均比最強 baseline 高 6.1%，但目前公開說明未見太多資源消耗與大型部署細節，訓練部分亦提到 MS MARCO 只先載入 v2.1 train split 的首 30k 筆樣本，代表現階段較適合研究、評測與流程驗證。

  • 適合需要處理長文件的 RAG 項目，例如法律、科研、知識庫問答
  • 配置檔主導流程，方便版本控制、重現實驗與比較不同設定
  • 支援 optional reranking 與生成評測，不只是單做檢索
  • 相關模型包括 sentence-transformers/all-MiniLM-L6-v2，底層依賴 PyTorch 2.x 與 Transformers 4.51+
  • 若你想比較多粒度證據檢索與傳統 chunk-based RAG 的差異，這個項目很有研究價值

GitHub： https://github.com/AmirAbaskohi/SproutRAG

Paper： https://arxiv.org/pdf/2606.18381

Categories: 開源, 工具, Python, Python NLP, RAG, 庫, Meta, 框架

MCompassRAG 把 RAG 檢索變得更準更省

Share to X
alt Method

現時不少 RAG 會用 dense retrieval，直接把查詢同文本 chunk 的 embedding 拿去比對；當 chunk 切得較粗、語料又雜，語意接近未必等於真正答到問題。MCompassRAG 屬於檢索框架，做法是替段落加入 topic metadata，再用 LLM teacher 離線產生判斷訊號，蒸餾成一個輕量 retriever，修正「只靠 chunk embedding 排名」這種固定範式的偏差。

它的取向幾清楚：把較重的判斷放在訓練前期，推理階段只保留 metadata bank、embedding lookup 同小型 scorer，所以標明可做到 zero LLM calls at inference。這個取捨很適合想保留檢索速度，但又嫌傳統向量檢索太粗糙的團隊；代價是前處理較長，要先訓練 topic model，再生成 distillation data。

項目流程分成幾步：先準備語料、訓練 topic model、生成蒸餾資料、建立 metadata index，再訓練 retriever。環境上要 Python 3.10+、PyTorch 2.x、Transformers 4.51+，而且建議有 CUDA GPU；OpenRouter API key 只在 Step 2 — Generate distillation data 需要，之後檢索本身不依賴 LLM 連線。

可留意的重點有幾個：
– 不只重排結果，而是把 topic signal 放進 retriever embedding space 一齊學習
– 支援可插拔 topic model backend，現成有 CEMTM、ETM、CWTM、SoftLTM
– 推理成本貼近 embedding model latency，較適合高頻查詢場景
– 比起純 dense retrieval，更著重 paragraph-level evidence quality

作者強調它會在 complex retrieval benchmarks 提升 evidence quality 同效率，但目前倉庫內容較像 research implementation，未見非常完整的產品化基準表。較受惠的會是做知識庫問答、文件搜尋、企業內部檢索的團隊，尤其當資料主題分散、段落切分又未必夠細時，MCompassRAG 的 topic compass 概念比單純換一個 embedding model 更有分析價值。

GitHub： https://github.com/AmirAbaskohi/MCompassRAG

項目主頁： https://huggingface.co/papers/2606.18508

Paper： https://arxiv.org/pdf/2606.18508

Categories: 開源, API, Embedding, Python NLP, RAG, 庫, 模型訓練, 框架

MemSlides 把簡報生成變成可記憶代理

Share to X
MemSlides hierarchical memory and localized revision overview

不少簡報生成工具仍然走 one-shot source-to-slides conversion：丟一份材料進去，整份投影片一次生成，之後每次修改又大範圍重做。MemSlides 把問題改寫成 stateful authoring process，核心不是單次輸出，而是記住你是誰、這一輪想改甚麼，以及過往哪些工具操作較可靠。

這是一個 Agent Framework，目標是解決 personalized slide generation 與 multi-turn local revision 兩個常見痛點。它把記憶拆成 user profile memory、working memory、tool memory：前者保存跨工作重覆出現的偏好，中段記住當前簡報的限制與暫時要求，後者則保留工具鏈執行經驗，方便之後做相似修改時少走彎路。

跟同類做法相比，最需要留意的是它不主張每次收到新意見就重生整副 deck，而是做 scoped slide-local revision，只更新受影響的最小區域。這種取向的好處是修改更穩定，較易保留原本好的內容；代價是整體品質會依賴記憶管理與局部編輯判斷是否準確。

從倉庫資訊看，這個項目較適合研究 presentation agents、企業內部簡報自動化，或要反覆為不同角色產出版本的團隊。倉庫亦提供 Docker Hub、網站、示範影片與論文連結，理解方式可先看 demo，再決定用容器部署還是按 Python 3.11 與 Node 20 的環境自行搭建；不過公開資訊未見完整量化基準，現階段較像研究型框架，而非已標準化的產品方案。

  • 把簡報生成由一次性輸出改成有狀態的寫作流程
  • 分層記憶是重點：user profile memory、working memory、tool memory
  • 修改時傾向局部修補，不是整份重生成
  • 適合需要 persona-aware 內容、反覆修訂、多人協作的情境
  • 相關元素包括 presentation agents、multi-turn revision、localized editing、tool-chain execution

GitHub： https://github.com/huohua325/Memslides

項目主頁： https://memslides.github.io/

Categories: 開源, Agentic, 工具, IDE, Python, Python NLP, 庫, 清華大學, 框架

SR-REAL 把空間推理拆成兩條路

Share to X
Repository image for jiyt17/SR-REAL

現有 spatial VLM 往往用單一路線回答空間問題，不是純文字 chain-of-thought，就是直接靠感知結果輸出答案；作者認為這種固定範式難以同時處理語意推理與精確幾何判斷。SR-REAL 提出的做法，是把空間推理分成 Language-Only Reasoning（LOR）與 Detect-Then-Reason（DTR）兩條互補路徑，前者逐步文字推理，後者先找 3D 幾何線索，再做明確幾何推斷。

這個項目屬於框架加訓練流程實作，核心是強化 spatial vision-language models 在複雜空間問答中的判斷能力。它不是單純新增資料集，而是從 cold-start supervised fine-tuning 到 reinforcement learning（RL）都重新安排，並加入 region-to-3D 介面，令模型可把 region tokens 連到 3D 座標、中心點或 bounding boxes。

SR-REAL 重點集中在資料準備與訓練前處理。流程上會先用 SPAR、EmbodiedScan 等來源整理物件對應與 3D 座標，再由 expert.py 生成推理鏈，配合 qwen3.py 抽取物件名稱，最後組成 DTR 指令微調資料；若不想自行重建，也可直接下載作者已整理好的 Hugging Face 數據。這表示它較適合有 Python、資料處理及多模態訓練基礎的研究團隊，而不是即裝即用的終端工具。

和同類做法相比，SR-REAL 不假設所有空間問題都應該用同一種 reasoning path。作者的取向很清楚：語意關係適合 LOR，涉及明確位置、距離、中心點、框選區域的題目則交給 DTR；代價是整個資料構建與訓練流程更複雜，對 grounding 資料品質亦更敏感。

  • 重點不在單一模型結構，而在 LOR + DTR 雙路徑推理設計
  • DTR 會先處理 region tokens 與 3D 幾何線索，再做空間判斷
  • 訓練分為 cold-start supervised fine-tuning 與 reinforcement learning（RL）兩段
  • 已提及 accuracy、format、detection rewards，顯示評測不只看答對與否，也看輸出格式及幾何對齊
  • 相關模型與資料來源包括 spatial VLM、SR-3D、Qwen3、SPAR、EmbodiedScan、SpatialRGPT、Omni3D、CA1M、OmniNOCS

SR-REAL 在多個 spatial benchmarks 有明顯提升，並強調單一 RL-trained model 可同時支援兩條路徑，且不用 per-task tuning 也能跨資料集泛化。不過儲存庫片段未完整列出詳細分數與對照表，因此較穩妥的判斷是：這是一個研究味很重、方法論清晰的項目，適合關注 spatial reasoning、3D grounding、multimodal instruction tuning 的團隊拿來重現與延伸。

GitHub： https://github.com/jiyt17/SR-REAL

項目主頁： https://sr-real.github.io/

Categories: Qwen, 香港, 香港大學, Google, NVIDIA, DeepSeek, OpenAI, Agentic, 工具, 3D, Python, Python NLP, 多模態模型, 庫, 模型, 模型訓練, 編程, 框架

RATs 用多代理玩出機械人技能庫

Share to X
RATs pipeline overview — click to play the video

現有機械人代理很多時仍然沿用 task-driven 路線：先收到明確指令，再透過 Code-as-Policy 產生可執行程式來完成任務。RATs 則批評這種做法太依賴外部任務，令可重用技能只會在被要求時才出現，所以它提出一個多代理 Code-as-Policy 系統，先用 free-form play 自行發明練習目標，再把成功行為整理成技能庫。

這個項目屬於機械人學習框架，要解決的是機械人代理遇到新任務時，欠缺可直接調用的長期技能累積。RATs 分成 Play 與 Evaluation 兩段：前者由 proposer、planner、policy-writer、verifier、failure-diagnoser 幾個 LLM 代理協作，後者把已凍結的技能當成 planner context 重用，而且強調 no gradients、no RL，主要靠 structured natural-language feedback 與 code reuse 學習。

如果你想試這個項目，較適合把它當成研究型系統來跑 benchmark，而不是即裝即用小工具。環境要求包括 Python 3.10、CUDA-capable GPU，並牽涉 LIBERO-PRO、MolmoSpaces、Robosuite 及真實 Franka Panda 流程；比較合理的測試次序，是先看 Play 階段怎樣生成技能，再檢查 Evaluation 階段對 held-out tasks 有沒有改善。

它的創新點，在於把「玩」正式納入 lifelong robot skill learning：不是隨機探索，而是讓代理自己提出可學習任務、逐步驗證中間進度、失敗後再診斷重試，最後把成功執行蒸餾成 reusable skill library。這令技能可在跨環境情境重用，不一定綁死原本訓練場景。

論文給出的結果相當具體：在 LIBERO-PRO 與 MolmoSpaces，play-learned skills 相比 no play 與 random-play baselines 有提升，對 CaP-Agent0 分別高出 20.6 和 17.0 個百分點；把技能直接檢索進其他 inference-time Code-as-Policy agents 的 context，對 Robosuite 與真實世界 transfer 亦分別提升 8.9 和 8.8 點。相關模型與基線主要包括 CaP-X、CaP-Agent0，以及文中使用的 LLM agents 協作流程；若你關心 agentic robotics、技能重用與真機轉移，這個項目很值得細讀。

  • 類型定位：多代理機械人學習框架，核心是 Code-as-Policy 與技能庫重用
  • 方法重點：先 Play 自提任務學技能，再 Evaluation 把技能注入 planner context
  • 技術取向：不靠 gradients 或 RL，主要依賴自然語言回饋、程式修正與 code reuse
  • 適合場景：研究 embodied agents、robot skill library、cross-environment transfer 的團隊
  • 已提到的相關系統：CaP-X、CaP-Agent0、LIBERO-PRO、MolmoSpaces、Robosuite、Franka Panda

GitHub： https://github.com/Playful-RATs/rats

項目： https://playful-rats.github.io/

Categories: 開源, NVIDIA, Agentic, 工具, AI productions, Python, Python NLP, 庫, 模型, 模型訓練, Robotic, 框架, Skill 技能

MultiLCB：即時追蹤程式模型表現

Share to X
codeLogo

MultiLCB（Multi Live Code Bench）是一個公開的編程模型評測項目，重點是用動態榜單和比較工具，觀察不同模型在多種程式語言上的表現。網站提供 Main Leaderboard、Model Comparison，以及按月份查看 pass@1 變化，適合想快速了解模型編碼能力的人。

這個項目處理的問題很明確：不少編程模型成績只停留在單次發布，難以看出時間變化、語言差異和推理設定的影響。MultiLCB 把資料整理成可篩選的介面，支援語言、難度、平台，以及是否使用 CoT（Chain-of-Thought）等條件，方便直接比較。

使用時，讀者可先在 Leaderboard 選擇日期範圍，再按 Python、JavaScript、TypeScript、Java、C++、C#、Go、Rust、Ruby、PHP、Kotlin、Scala 等語言篩選。若想深入看兩個或多個模型差距，可打開 Compare 頁面，用 pass@1 與平均分數交叉檢視，也可留意每月走勢圖。

  • 支援 LCB、LCB-PRO、LCB-PRO-AGENTIC 多種基準
  • 可按語言、難度、平台、CoT 條件篩選
  • 以 pass@1 為核心指標，方便直觀比較
  • 提供月份變化圖，較易看出模型進步或波動

這類項目特別適合模型研究者、AI 工程師、技術媒體，以及需要挑選 coding model 的團隊。從頁面可見，它偏向基準測試與橫向比較工具；至於數據來源、題目構成和完整評測方法，仍要配合站內 Code、Hf、Submit 或相關說明頁面再作確認。

項目： https://multi-lcb.github.io/

Categories: 開源, Agentic, 工具, Python, Python NLP, Vibe Coding, 模型, 編程
Page 1 of 2
1 2