NCP-Bench 把電影故事變成可逐輪檢查的互動環境

這個基準把電影故事變成可逐輪檢查的互動環境,重點不是講得順,而是能否守住既定事實與劇情承諾。你可以把它理解成用來測試 LLM agent 會否在長對話中改寫故事的工具。

NCP-Bench overview: data construction, interaction history, and evaluation framework

NCP-Bench 是一個 benchmark,加上一套固定 evaluator,用來測試 Interactive Narratives 裡的 Narrative Commitment Preservation (NCP)。它處理的問題很直接:當玩家自由輸入動作時,Narrator agent 會不會偷改已建立的世界事實,或跳過本來應該出現的劇情節點。

使用方式偏向研究與評測流程:每個電影 synopsis 會被轉成 stateful environment,內有 initial fact ledger、narrative commitments 同 ordered reference trajectory;agent 每回合回應後,固定 evaluator 會檢查 fact、commitment 同 player-input conflicts,再更新狀態。儲存庫同時提供 100 個 benchmark environments、方法無關的 episode runner,以及 Baseline 和 HiAgent 參考方法,方便直接比較。

這套做法的價值在於,它不只看文字是否自然,還逼系統在長 horizon 內維持一致性。和只看單輪生成的測試比,NCP-Bench 更接近互動式敘事真正會遇到的拉扯:玩家可以亂入,但系統仍要守住已承諾的劇情骨架。

較適合關心長對話敘事、互動式故事生成、角色扮演型 agent 的研究者與團隊。若要部署,重點不是訓練一個新模型,而是接上既有 narrator,再用 repo 提供的環境規格同 evaluator 跑整個 episode,觀察違反事實、承諾和劇情順序的情況。

  • 100 個 movie-level environments,涵蓋 18 個 genres
  • 每個環境都有 YAML 規格,包含 metadata、facts、commitments 同 trajectory nodes
  • 評測核心是逐回合檢查一致性,而非只看最終輸出
  • 提供 Baseline 與 HiAgent,方便和論文結果對照
  • 適合做長篇互動敘事、Narrative agent 與一致性評測

GitHub

Categories: 開源, Agentic, 框架, Dataset 數據集

dembrandt:把網站風格秒轉成可追蹤的設計 tokens

Dembrandt 直接把網站的 logo、色彩、字體和間距抽成 design tokens,方便你在 AI 工具或 CI 裡持續比對變化。它不只做擷取,還把每次改版的風格漂移記錄下來。

Dembrandt: Any website to design tokens

Dembrandt 係一個用來抽取網站設計系統嘅工具,重點係將 logo、色彩、字體、邊框、陰影等視覺元素整理成 design tokens,方便團隊快速理解一個網站嘅視覺規則。對做前端、設計系統或者品牌一致性檢查嘅人嚟講,佢可以省去逐頁抄資料嘅時間。

使用時要先準備 Chromium,因為它透過 Playwright 核心去驅動瀏覽器,唔裝 browser binaries 就冇得啟動。安裝後可以用 CLI 直接抽取,亦可以透過 MCP 接入 Claude Code、Cursor 或 Windsurf,令 AI 助手幫你讀出 tokens。

同類工具多數只做一次性擷取,Dembrandt 加入咗漂移追蹤同快照時間線,令你可以比較兩次發佈、兩個網站,或者同一個 domain 喺唔同時間嘅變化。佢仲提供視覺差異、分類分數同 baseline 比對,對 CI 監察改版影響特別有用。

  • 可把網站外觀整理成可重用嘅 design tokens
  • 需要先安裝對應 Chromium,否則無法運行
  • 支援 MCP,方便接入 AI 編程工作流
  • 可以記錄快照,持續追蹤設計漂移
  • 適合前端、設計系統同品牌檢查工作

如果團隊要維持多個頁面或多次發布之間嘅視覺一致性,呢個工具比單次擷取更有用。它將抽取、比較同追蹤放埋一齊,令設計變化唔容易悄悄走樣。

GitHub

Categories: 開源, MCP, IDE,

spark-to-paper-skills:14 個 Claude Code 技能把點子直出論文 PDF

由一句想法走到可編譯論文,連引用、圖表同數字來源都一併追蹤。呢個 Claude Code 插件瞄準的,不是寫草稿,而是把研究寫作流程拆成可驗證工序。

spark-to-paper-skills

研究寫作最麻煩的地方,往往不是起草,而是引用會唔會失真、圖表能否修改、數字有冇來源可追。spark-to-paper-skills 把呢件事做成 Claude Code 插件型工具鏈,用 14 個可組合技能,將一句想法推進到可編譯 PDF,處理的是論文生成流程入面最容易出錯的核對與整理工作。

它吸引人的地方,在於唔靠獨立 app 或伺服器,而是直接掛入 Claude Code 會話。安裝前提相對簡單,重點是有 Claude Code,另外部分圖像流程需要 Python 3.10+ 同指定依賴;換句話說,這不是雲端代寫服務,而是偏向本機、插件式、可拆件調用的研究寫作工作流。

  • 14 個技能可分步串接,涵蓋資料整理、成稿到 PDF 編譯
  • 引用強調 verified,數字強調 traced to source,主打可追溯性
  • v1.2.0 加入 PaperBanana+ figure engine,圖可重畫成原生 editable vector figures
  • 新版支援 Claude Code plugin 自動載入,部署方式比早期版本完整

同類做法多數把重點放在生成速度,這個項目則把可信度同後續可編輯性放得更前。PaperBanana+ 的做法幾值得留意:先由官方 PaperBanana 產生候選圖,再用 ts-figure-svg 學習該渲染風格,根據論文事實原生重繪,並以 stdlib-only geometry audit 反覆修正至少 4 輪,換來的是圖像更容易進一步編修,但流程也明顯比單次出圖更講究。

目前公開資訊較多集中在工作流完整度。它已展示 7 篇跨 6 個領域的端到端樣本,並支援 ICML 2025、NeurIPS 2025 風格輸出,足以說明這套技能並非只停留在片段 demo。較適合研究助理、學術團隊、技術內容作者,或者需要快速整理初稿但又唔想放棄引用與圖表可追蹤性的人;最終學術品質,仍然要視乎輸入構想、來源材料同人工審稿力度。

GitHub

Categories: 開源, Python, Anthropic, Skill 技能

360CityArena 把城市導航基準拉近真街景

想測試 Embodied Agents 喺城市場景到底識唔識搵路,360CityArena 提供咗一個更貼近真實街區的基準,但結果亦直接揭示現時模型離人類判斷仲有一大段距離。

360CityArena teaser showing a panoramic Akihabara scene and an embodied navigation agent

喺模擬城市入面叫 Embodied Agents 認路、數物件、跟地圖行,難度一向唔低;換成秋葉原的 360 度真實街景之後,問題就由「會唔會做任務」變成「可唔可以喺複雜環境保持判斷」。360CityArena 屬於 benchmark,核心用途係評估 multimodal large language models 喺 embodied navigation 同 visual reasoning 上,到底有幾接近真實城市探索需求。

呢個項目最有意思的地方,在於它唔係靠乾淨的 3D 合成地圖,而係用 602 段 360° 影片重建東京秋葉原 85 條街道,再放入 Unity 環境,用 pose graph 方式讓 agent 沿既定節點移動。換句話說,代理唔可以自由行去任何 3D 座標,也唔涉及實體互動;它測的是在受限移動下,模型能否理解街景、地圖、語言提示同空間關係。

公開版本有 175 個人工設計任務,涵蓋 localization、landmark search、counting、map navigation、language guided navigation 同 relational spatial reasoning。部署方式亦算清楚:Unity 6.5 負責環境,Python runner 接模型 API、送出相機與地圖觀察,再把每次執行結果寫入 outputs/<run_id>/,因此它比較適合研究團隊或評測項目直接重跑同對照。

  • 用 360° 真實街景而唔係純合成場景,城市細節更接近真實導航
  • 任務覆蓋找地標、看圖尋路、數物件、按文字指示前進等七類能力
  • Unity 環境配合 Python runner,方便接駁不同 MLLM API 做可重現測試
  • agent 只可沿 pose graph 移動,限制更明確,同時保留城市探索的推理壓力

最值得留意的是結果並唔樂觀。官方比較指出,Gemini 2.5 Flash 目前在整體任務只有 17.1%,人類則有 77.3%,差距大到足以說明:現時多模態模型即使已經能看圖和讀指令,一旦放入連續街景、地圖對位與空間推理混合的場景,穩定性仍然不足。對做 Agentic、Robotic、世界模型相關研究的團隊來講,360CityArena 的價值正在於它唔再只測單步理解,而係把城市級導航的瓶頸攤開畀人直接比較。

項目主頁 · GitHub

Categories: 開源, Agentic, 多模態模型, Gemini, API, Robotic, 3D, Python, Dataset 數據集

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

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

NanoVDR

處理幾十萬張文件圖片嘅時候,每次查詢都要過一次 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

MiLMMT-v1.0:小米升級開源翻譯模型:支援至 46 種語言

小米把旗下開源多語翻譯項目 GemmaX 升級至 MiLMMT-v1.0,支援語言一舉擴至 46 種,並透過強化學習與模型合併提升翻譯品質。

gemmax

過去想用開源 LLM 做多語翻譯,往往要遷就 20 多種語言的覆蓋,遇上東歐、非洲或東南亞較少見的語種就容易撞牆。MiLMMT-v1.0 把覆蓋範圍一口氣推至 46 種,這個改變對做跨國內容本地化、跨境電商文案,或是需要處理多語客戶查詢的團隊尤其受用。

這個項目屬於多語翻譯模型(multilingual machine translation model),並非框架或工具,核心目標是讓 Gemma3 等開放權重模型在多語翻譯場景下,貼近商用翻譯引擎的水準。它以 Gemma3-1B 與 Gemma3-4B 為基底,先做持續預訓練,再用翻譯指令微調,最後透過強化學習(GRPO)配合 xCOMET、OpenLID、CometKiwi 等無參考指標作為獎勵訊號。

與傳統依賴大型封閉模型、或需要平行語料的監督式微調不同,MiLMMT 強調 reference-free 後訓練:不需要人工對照譯文也能用 LLM-as-judge 改善翻譯結果。同時配合模型合併(model merging),在 1B 規模的小模型上嘗試兼顧多語泛化與低資源語種的穩定性,這點對硬體資源有限、想自建翻譯服務的工作場景相當關鍵。

重點摘要:

  • 支援語言從 28 種擴展至 46 種,覆蓋更多低資源語種
  • 基於 Gemma3-1B / Gemma3-4B 開放權重,可離線部署
  • 採用 GRPO 強化學習搭配 xCOMET、OpenLID 等無參考獎勵
  • 提供 Hugging Face Spaces 線上 Demo,亦有 RL launcher 與獎勵服務腳本可重現訓練流程
  • 相關論文已上 arXiv,紀錄後訓練與模型合併的實證結果

對本地化團隊、開發者或研究人員而言,這個項目提供了一條毋須依賴商業 API 的多語翻譯路線,1B 等級的模型體積亦令自部署門檻大幅降低。

項目主頁 · GitHub · 模型

Categories: 開源, 模型, 中國, 小米-Xiaomi

Ex-Omni-2D 直接對話生成同步發聲與表情的數字人影片

Ex-Omni-2D 讓對話模型同時輸出文字、個人化語音與表情同步的頭像影片,以多碼本語音單元串接語音與畫面,並提供 Teacher 與 Prefix-Streaming Student 兩種部署模式。

Ex-Omni-2D framework

想讓 AI 數字人不只是「會打字」,而是真的「邊說邊演」?香港中文大學(深圳)與 LIGHTSPEED 合作開源的 Ex-Omni-2D,正是針對這個目標設計。它是一個開源對話框架,接受多模態查詢、參考圖像與參考音訊後,先由語言模型輸出一份結構化的 Visual Thought Plan(VTP),再依此生成文字回應、個人化語音,並產出嘴形與動作同步的頭像影片。

傳統做法通常把語音合成與人物影片視為兩條獨立管線,需要額外對齊文字、聲音與嘴形,容易出現時間錯位。Ex-Omni-2D 的差異在於採用 16 個 codebook 構成的原生多碼本語音單元,作為語音與影片共享的聲學與時序介面:同一組語音單元既驅動 TTS,也作為影片生成器的緊緻條件,從而降低跨模態錯位的風險。

影片生成路徑提供兩種互補模式:Full-sequence Teacher 採雙向注意力,追求最高畫質;Prefix-Streaming Student 則是蒸餾而來的少步數 block-causal 版本,支援 2、4、8 步串流推論,方便在工作站、GPU 伺服器甚至 Hugging Face Spaces 上做漸進式部署。

這個項目的重點:

  • 對話原生影片:視覺行為直接從多模態對話上下文規劃,不必再手動撰寫影片提示詞。
  • 結構化 VTP:明確定義首幀、場景、情緒、動作風格與動作細節,方便後續控制與除錯。
  • 共享語音介面:16 個 codebook 同步驅動語音合成與人物動作。
  • 品質與效率取捨:Teacher 負責最高畫質,Student 支援 2/4/8 步串流。
  • 彈性部署:同一套代碼可在個人工作站、GPU 伺服器或 HF Spaces 執行,並提供線上 Demo 試玩。

在串流場景中,作者指出 Prefix Streaming 從第 9 至 16 chunk 的一致性明顯較強,將 last-to-first consistency error 降低 21.4%,這對需要長時間維持角色身份一致的應用相當關鍵。論文亦提到 Prefix Streaming 能減少長序列累積形變,同時保留參考圖像的人物外觀。

較適合的對象包括需要快速打造可對話 AI 助手、虛擬主播、客服分身或教學數字人的團隊;對研究多模態對話、語音驅動動畫的人來說,這份開源代碼、模型權重與 arXiv 論文也是一個方便的起點。

項目主頁 · GitHub · 模型

Categories: 開源, 香港中文大學, 騰訊, 文字轉語音, AI productions, 數字人, 多模態模型, 視頻模型, Qwen, 香港, 語音

LTX-2.5 原生多鏡頭、4K HDR,一次看懂升級重點

LTX 最新開源基礎模型 LTX-2.5,主打原生多鏡頭銜接、4K HDR,並降低重試與算力成本,繼續走開放權重路線。

LTX-2.3 Examples Video

如果你是用開源模型做影片生成的開發者,LTX-2.5 這次更新解決的卡位頗明確:人物、環境、光線與聲音在多鏡頭之間斷裂的問題。它把多鏡頭生成變成原生能力,並加入自動時長預測,模型會按指令動作自行決定片段長度,省下人手剪接的麻煩。

對比起多數只能透過後製拼接的同類方案,LTX-2.5 在 prompt 跟隨度上也有明顯進步,能夠處理更複雜的創作指示,而且只需要更短的提示詞就能產生穩定結果。配合新的擴散影片解碼器,動態假影更少,畫面在高解析度與 HDR 下仍能逐格保持質感。

本地部署與微調是這次版本延續的核心承諾:開源權重可直接下載,預訓練基礎模型可在自家做 LoRA 微調,產出與後製則支援原生 RAW workflow,貼近專業調色與剪接流程。

從官方比較表來看,目前維持開放權重且不受地區限制的開源視頻生成選擇仍然有限,這也是 LTX-2.5 在定位上最值得留意的差異化。不過實際表現仍需視本地硬件配置與工作流整合程度而定。

重點摘要

  • 原生多鏡頭生成:人物、環境、光線與聲音在不同鏡頭間保持一致。
  • 自動時長預測:依據動作需要自動決定片段長度。
  • 4K HDR 與原生 RAW:支援專業調色與後製 pipeline。
  • Gemma 4 12B 文字編碼器:搭配自研提示詞增強器,提升 prompt 跟隨度。
  • 開源權重可下載:可在本地硬件運行,並支援 LoRA 微調。

項目主頁

Categories: 開源, AI productions, 數字人, 多模態模型, 視頻模型, 模型訓練, Video, Image, LTX

NeMo Speech:NVIDIA 把 ASR、TTS、語音 LLM 收進同一條 PyTorch 生產線

NVIDIA 把語音研究最常碰到的 ASR、TTS 與 Speech LLM 整合成單一框架,研究員和工程師不用再東拼西湊,也能用預訓練權重快速微調與部署。

Repository image for NVIDIA-NeMo/Speech

語音 AI 的痛點往往不是模型不夠強,而是開發者要同時面對 ASR、TTS、串流識別等好幾套獨立工具鏈。NVIDIA NeMo Speech 把這些任務收進同一個 PyTorch 框架,並提供預訓練權重,讓研究員可以把精力花在實驗設計,而不是從頭搭建訓練流程。

從近期更新可以看到三個值得留意的方向:MagpieTTS v2607 把支援語言擴展到 12 種,新增阿拉伯文、韓文、葡萄牙文;Nemotron-3.5-ASR-Streaming-0.6B 在單一 H100 上能同時處理最多 2400 條串流,並允許把延遲控制在 80ms 到 1s 之間;Parakeet-unified-en-0.6b 則把離線與串流推理合併成一個英文模型,最短延遲 160ms。

Nemotron 3 VoiceChat 把 LLM、骨幹與 TTS 解碼器串成全雙工對話,能自然處理打斷與插話,這對於想建立語音助理的團隊是比較完整的一條路。Fastconformer 等快取感知架構是背後的工程功臣,讓長音訊串流不需要犧牲太多吞吐量。

訓練階段必須配備 NVIDIA GPU 與 CUDA 環境,推薦使用 PyTorch 2.7 或以上版本;現時倉庫正進行拆分,下一個主要版本預定 2026 年 6 月發佈,短期內穩定使用可以考慮 26.02 NGC container。對做客服、會議記錄、媒體字幕或有聲書生成的團隊,這套框架能把語音模型從原型走到部署的距離明顯縮短。

重點摘要:

  • 單一框架覆蓋三大任務:ASR、TTS 與 Speech LLM 都在 NeMo Speech 內,減少切換工具鏈的成本。
  • 串流效能突出:Nemotron-3.5-ASR-Streaming-0.6B 支援 40 種語言,單張 H100 可並行 2400 條流,延遲可調。
  • 多語 TTS 擴張:MagpieTTS v2607 覆蓋 12 種語言,並提供 Hugging Face 線上 demo。
  • 全雙工語音助理:Nemotron 3 VoiceChat 把 LLM 與 TTS 解碼器結合,支援自然打斷與低延遲對話。
  • 硬體要求明確:至少配備 80 GB 記憶體。訓練需 NVIDIA GPU 與 CUDA,PyTorch 2.7 或以上版本,推理可在 CPU 或 GPU 執行。

GitHub · 模型

Categories: 開源, 文字轉語音, Agentic, NVIDIA, 框架, Python, 語音, Dataset 數據集

NVIDIA Nemotron 3.5 Lightning:專為長期運行 Agent 而生的輕量 MoE 模型

AI Agent 大部分時間都在做工具呼叫、結果驗證等高頻次執行,而非高階推理。Nemotron 3.5 Lightning 以 30B MoE 架構瞄準這個執行層,速度比同級模型快 4 倍。

Og image

長期運行的 AI Agent 真正花時間的地方,往往不是規劃,而是工具呼叫、結果驗證、子代理分派這些高頻次的執行步驟。每一個小動作都用頂級推理模型去跑,會帶來明顯的成本與延遲壓力。NVIDIA 推出的 Nemotron 3.5 Lightning 就是針對這個「執行層」設計的開放模型,採用 30B 參數的 Mixture-of-Experts(MoE)架構,但每次只啟動 3B 參數,在維持效率的同時兼顧準確度。

與坊間常見做法不同,Nemotron 3.5 Lightning 並非要取代大型推理模型,而是與之分工——前者處理高頻執行,後者專注規劃與複雜推理。模型本身針對 agent harness(如 OpenClaw、Hermes Agent)做了訓練優化,並提供 speculative decoding、NVFP4 與 BF16 量化版本,宣稱輸出速度比同級模型快 4 倍。這對需要長時間在線、隨時待命的 Agent 來說,省下的不只是金錢,還有回應時間。

Nemotron Lightning - NVIDIA's Super Fast Agent MoE

NVIDIA 同時推出 NeMo Switchyard,一個負責任務分派的路由函式庫,能根據任務類型自動挑選最合適的模型。整個 Nemotron 系列定位有點像「模型版的軟件庫」,每次發佈都在累積可組合的元件。對於需要自己掌控成本與效能的開發團隊,這套組合提供了相當完整的權重、數據與訓練配方,加上寬鬆的開源授權,方便做深度客製化。

  • 專注 Agent 執行層:30B MoE 架構、3B 活躍參數,設計目標是高頻低延遲的工具呼叫與驗證。
  • 速度與成本取捨:相比同級模型,輸出速度提升達 4 倍,搭配 NVFP4 量化可在本地硬件運行。
  • 分層協作模式:與 Nemotron 3 Ultra 等大型推理模型分工,由 NeMo Switchyard 負責智能路由。
  • 完整開源:權重、訓練數據與配方一併釋出,授權寬鬆,方便客製與整合。
  • 生態整合:對應 NemoClaw 安全管理開源方案,支援 OpenClaw、Hermes Agent 等長期運行框架。

項目主頁

Categories: 開源, Agentic, 模型, NVIDIA, 軟件, , 安全, OpenClaw

Page 21 of 92
1 19 20 21 22 23 92