InferNews

Google 開源表格基礎模型 TabFM：零樣本處理混合欄位資料

Share to X
Repository image for google-research/tabfm

對熟悉表格資料分析的人來說，每次換資料集就得重新訓練模型，是一個長期存在的痛點。TabFM 想解決的就是這個卡位：透過 in-context learning，把訓練資料當作「上下文」直接餵進模型，省掉逐個資料集做參數訓練的步驟，支援數值與類別混合欄位的零樣本分類與迴歸。

這個項目屬於模型與框架混合性質的開源工具，以 scikit-learn 風格的 API 呈現，因此熟悉 fit、predict、predict_proba 的人可以幾乎無痛地接入。它提供 v1.0.0 預訓練權重，使用者可選擇 JAX（含 Flax 0.12.7 的 flax.nnx API）或 PyTorch（torch 2.12.1）作為後端，權重會自動從 Hugging Face Hub 下載。

與傳統監督式表格模型相比，TabFM 的差異在於「即時預測、不需要再訓練」這個取向，特別適合快速原型設計或資料集頻繁變動的場景；不過它的實際效果仍取決於預訓練權重對目標領域的覆蓋程度。中小型資料團隊、需要處理多種表格欄位類型的研究者，以及想用統一介面同時跑分類與迴歸任務的人，較容易從中受惠。

效能方面，由於原文提供的評測細節有限，難以斷言它在所有基準上的強弱；採用 GPU 版本時推理速度會明顯提升，但 CPU 環境亦可運行。需注意此項目並非 Google 官方支援產品，定位偏向研究原型，正式部署前應自行評估穩定性與資料合規性。

重點摘要：

  • 零樣本推論：無需在自己資料上訓練參數，靠 in-context learning 即時產生預測
  • scikit-learn 相容 API：可用熟悉的 fit、predict、predict_proba 流程接入
  • 混合欄位支援：同時處理數值與類別特徵，免去額外前處理設計
  • 雙後端選擇：可依環境需求在 JAX（Flax）與 PyTorch 之間切換
  • 開源但非官方產品：定位為研究性質，部署前宜自行驗證效果與合規

項目主頁 · GitHub · 模型

Categories: 開源, Google, API, Python, 模型, Dataset 數據集

FunASR 工業級語音辨識：支援廣東話

Share to X
Repository image for modelscope/FunASR

如果你做過語音相關項目，大概率遇過呢種情況：開源模型散落喺唔同倉庫、部署方式各異、要接入 Agent 仲要自己寫 WebSocket 中間層。FunASR 就係針對呢類工程痛點嘅工業級語音識別工具包，屬於開源框架，由阿里達摩院維護，提供統一 Python 接口，將 ASR、VAD、標點恢復、說話人分離、情感偵測同音訊事件辨識串成一條流水線。

旗艦模型 Fun-ASR-Nano 係基於 LLM 嘅解碼架構，覆蓋中、英、日三語以及中文方言群組；針對 31 種語言嘅場景可以用 Fun-ASR-MLT-Nano-2512；鍾意多語言又有 LLM 解碼能力嘅，亦有 Qwen3-ASR（52 種語言、0.6B/1.7B 參數）。如果想要更輕量、非自迴歸嘅選擇，Paraformer 同 SenseVoice 仍係穩陣起點，前者適合生產線串流，後者額外送情感同音訊事件標籤。

funasr-server 一行指令就可以拉起 OpenAI 相容嘅轉寫 API，本地聽返 localhost:8000，配合 vLLM 仲可以做到 2-3 倍 LLM 解碼加速同 tensor parallel 批次推理。Agent 整合係另一個重點：MCP Server 可以直接接入 Claude 或 Cursor，OpenAI API 接口又同 LangChain、Dify、AutoGen 無縫對齊。最近幾個版本（v1.3.18 至 v1.3.22）就專門執緊 SRT/字幕分段、長時 WebSocket 連線、verbose_json 回傳呢啲工程細節。

要留意嘅取捨係：Fun-ASR-Nano 需要 GPU；新環境第一次 import funasr 已唔再強行依賴 PyTorch，但用 AutoModel 仍然要先裝 torch。FunASR 比較適合需要私有語音 API、字幕生成、長會議轉寫、或想將語音能力塞入 Agent 工作流嘅團隊開發者。

重點摘要：

  • 統一 Python 接口整合 ASR、VAD、標點、說話人分離、情感偵測
  • Fun-ASR-Nano 旗艦模型支援 31 種語言及中文方言，Fun-ASR-MLT-Nano 覆蓋更廣
  • funasr-server 提供 OpenAI 相容 API，搭配 vLLM 可達 2-3 倍加速
  • 內建 MCP Server 支援 Claude/Cursor，亦可接入 LangChain、Dify、AutoGen
  • 近期版本持續優化字幕分段、WebSocket 長連線、verbose_json 回傳等工程細節

以下是其對粵語支持的詳細信息：

  • UniASR模型：這是一個專為粵語設計的語音識別模型，能夠處理簡體中文的粵語語音識別任務。
  • ITN模型：用於對粵語語音識別結果進行擬文本正則化後處理，以提高識別結果的準確性。
  • VAD模型：語音端點檢查模型，用於檢測長語音片段中有效語音的起止時間點，這對於粵語方言的語音識別同樣重要。
  • 訓練語料：為了提高模型的準確性和適用性，通常會使用大量的粵語語料進行訓練，以便模型能夠更好地理解和識別粵語中的特有詞彙和表達方式。
  • 離線功能：Funasr提供了離線語音識別模型，這意味著即使在沒有網絡連接的情況下，也能夠進行粵語語音識別。

項目主頁 · GitHub

Categories: 開源, Qwen, NVIDIA, Agentic, API, MCP, IDE, LangChain, Python, 語音, Dataset 數據集

Hermes Missing Control 用 Telegram 管理五人 AI 團隊

Share to X
Og image

這個教程價格為 US$15, 它是一套多 Agent（multi-agent）工作流，核心是用一個 Orchestrator 牽頭，配合 Scout、Scribe、Reach 和 Dev 四個常駐助手，分工處理探索、記錄、外聯和開發。它解決的不是單一對話，而是多角色協作、訊息路由同埋狀態追蹤，令每個助手各守其位。

同一般把所有工作塞入同一個聊天頻道的方法相比，這套做法把每個助手分到獨立的 Telegram 頻道，再配合 Telegram bot 和 routing plugin 做轉發。好處是角色邊界更清晰，對話唔易混亂，亦方便之後把任務、日誌同檔案接入同一個 mission-control dashboard。

文章亦展示咗點樣將資料層做成只讀，並把 Overview、Agents、Tasks Board、Chat、Content Library 同 Schedule 等版面逐一接上 live data。對需要長時間跟進 AI 工作流的人會幾有用，尤其係想喺 VPS 上集中監控，又唔想直接改動底層資料的人。

  • 以 Orchestrator 統籌四個專職助手
  • 每個助手都有自己嘅 Telegram 頻道同工作邊界
  • 儀表板只讀，方便監察而唔會誤改資料
  • 支援任務板、聊天記錄、文件庫同排程追蹤
  • 內容亦包含部署、故障排查同可選擴充做法

整體嚟講，呢個項目示範咗點樣把多 Agent 協作變成可觀察、可路由、可回溯嘅系統。對想用 Telegram 做日常 AI 協作中樞嘅讀者，會比一般聊天式代理更貼近日常工作需要。

項目主頁

Categories: Agentic, 庫, 教學

Krea 2 Outpaint：外擴 LoRA 補畫面

Share to X
Og image

畫面外擴最怕兩件事：原圖內容被改壞，或者延伸後透視、光線同結構接唔上。呢個項目明確建立在 Krea/Krea-2-Turbo 之上，並以 Krea 2 Raw 作訓練目標，形式係一個 rank-32 的 LoRA，用嚟做 image-to-image outpainting，重點唔係單純參考原圖，而係連原圖要放喺新畫布邊個區域都一併編碼。

它的做法是把來源 latent tokens 加上來自目標 bounding box 的 rotary coordinates，令 denoiser 能理解「已知畫面屬於整張新圖的哪個位置」。所以它比一般 image-reference adapter 更適合做左貼右擴、上貼下擴，甚至置中後向兩邊延伸，對透視、光照、紋理連續性的控制更直接。

檔案資訊相當清楚，但重點不在量化版本。頁面列出 krea2_outpaint_rank32.safetensors、pipeline.py、outpaint.py、example.py，另有授權與雜湊檔；同時明確說明 Hugging Face 自動產生的 Diffusers snippet 及一般 LoRA importer 不相容，要用隨附腳本與自訂 pipeline。這代表它不是即插即用型 LoRA，而係帶有功能性介面的適配器。

  • 基礎模型已指明為 Krea/Krea-2-Turbo，並針對 distilled 8-step inference 設計。
  • 核心差異在 registered reference_placements，可指定原圖在目標畫布的位置。
  • 已測試寫實、水彩、stylized 3D 等場景，涵蓋橫向、縱向與置中延伸。
  • 頁面沒有提供 GGUF、mmproj、llama.cpp、Ollama、LM Studio 或量化等資訊。

使用取向上，它更像為 Krea 2 編輯流程補上一個 UI 版的外擴能力，而唔係通用本地推理模型。由於依賴 diffusers 與自訂程式碼，適合已經在 Python 圖像流程中工作、需要穩定控制構圖位置的人。

項目主頁 · 模型

Categories: 開源, Image, Ollama, 影像模型, 影像處理, 視覺模型

MobileWan 把 5B 影片生成壓進手機

Share to X
MobileWan logo

手機影片生成常見的痛點，不是能不能出片，而是畫質、動作連貫性與記憶體限制往往只能三選二。MobileWan屬於模型推理工具加輕量化模型方案，核心是在保留Wan2.2-5B基礎能力的前提下，讓單一提示詞影片生成更接近流動裝置可承受的範圍。

目前只支援 Snapdragon®
8 Gen. 5 NPU：不走細模型路線，而是把 Wan2.2-5B 改寫成更節省記憶體的推理形式。項目公開的是 inference-only sampler，會先做 hybrid-attention surgery，再套用已封裝的 self-attention head-pruning 計劃，之後才載入 MobileWan transformer 權重；換句話說，重點不是訓練流程，而是怎樣把既有大模型壓到可部署狀態。

資料顯示，MobileWan 以 recurrent distillation、causal linear attention 同記憶體優化解碼去支撐流動裝置生成，官方亦給出 5 秒、480×832、16 FPS、端到端約 20 秒延遲，以及 VBench 83.79 的成績。這些數字反映它追求的是「手機可跑，同時畫質不要跌得太明顯」，而不是只用極低參數換取能執行便算。

  • 支援單一提示詞影片生成，重點放在推理與部署而非訓練
  • 基於 Wan2.2-5B，透過 hybrid-attention surgery 與 head pruning 減低負擔
  • 可選 scheduler，包括 flow euler、unipcm 或 pipeline 預設方案
  • 生成流程提供 seed、略過既有輸出、較高品質 MP4 輸出等控制項目

這個項目的參考價值高；但它目前聚焦單一提示詞輸出，亦未見完整訓練鏈公開，適合拿來驗證推理路線，未必等同即插即用的產品方案。

項目主頁 · GitHub · 模型

Categories: 開源, Video, 視頻模型

Netflix 正式納入 AI 製作流程：300 部作品已使用生成式AI

Share to X
Og image

Netflix 在這段影片裡拋出的訊號很直接：生成式 AI 已經進入它的製作流程，而且不是少量試水溫。今年大約有 300 部作品用到這類工具，範圍由概念發想、前期視覺化到後期製作都涵蓋在內。這代表影視團隊處理畫面與內容時，開始把 AI 當成日常工具，而不只是額外加上的噱頭。

它最值得留意的地方，在於改變了內容製作的分工方式。傳統流程裡，很多視覺探索和素材整理都要靠人手反覆試，時間和成本都不輕；AI 介入後，團隊可以更快做出草稿、比較方向，再把資源集中在真正要打磨的部分。

  • 生成式 AI 已進入 Netflix 的實際製作流程
  • 應用範圍不只一個環節，而是橫跨前期與後期
  • 主要價值是加快探索速度，減少重複勞動
  • 反映串流內容工業化製作正進一步自動化
  • 對內容團隊、後期製作和視覺開發最有參考價值

這種做法和單純把 AI 當展示工具不同，重點在於它已經被放進正式工作流，變成可持續使用的製作手段。對做影像、廣告、預告片或大量內容開發的人來說，這類變化會直接影響交付速度、試錯成本和團隊分工。

項目主頁

Categories: Video, AI productions

Film space：用 iPhone 走出 AI 鏡頭路徑

Share to X
Film space

拍 AI 風格化影片時，最難控制的往往唔係畫風，而係鏡頭點樣郁、人物點樣企。Film space 把呢個問題拆得幾務實：它屬於 3D 預演工具，用 iPhone ARKit 把你真實行走時的裝置移動，轉成可錄製的虛擬鏡頭路徑，之後再交畀 Seedance 2.0 呢類工具做 AI style transfer 參考。

它的定位唔係直接生成影片，也唔係完整剪接系統，而係補上 AI video workflow 入面最易失真的一段：先用虛擬 studio 做 blocking，再用手機走一次鏡頭。相比純文字提示詞或者只靠模型自己猜運鏡，Film space 換來的是更清楚的鏡頭方向感；代價是你需要親身拿住 iPhone 進行錄製，而且目前明顯偏向單機、裝置端流程。

部署方式：整個流程在裝置上完成，建議橫向畫面使用，錄好的片段會存入相簿，再帶去後續生成工具。場景編排包括棋盤地板、格線、座標軸，亦可加入 human stand-ins 來模擬人物站位；去到 Camera mode，手機的移動、轉向與傾斜會直接變成鏡頭運動，配合 35mm、50mm、75mm、200mm 焦段預覽，對做分鏡、音樂錄像、短片測鏡頭的人尤其有幫助。

  • 把 blocking、走位同運鏡參考集中在同一個 iPhone 流程處理
  • 重點唔在生成畫面，而在為 Seedance 2.0 等模型提供更穩定的鏡頭參考
  • 以 ARKit 驅動 Camera mode，保留真人手持鏡頭的節奏感
  • 有基本 lens simulation 同 stand-ins，足夠做前期預演，但未見到進階場景製作能力

效能數據同正式 benchmark 目前未有公開，因此較難量化追蹤精度或錄製穩定性；現有資訊較能確認的是工作流設計，而唔係模型級指標。Film space 最適合用來做前期測試、概念驗證同低成本鏡頭預演，尤其當你想保留真人運鏡感，但又準備把最終畫面交畀 AI 重新風格化，這個項目的價值就會幾明顯。

GitHub

Categories: 開源, Video, 工具, 3D, AI productions, Dataset 數據集

PixelRAG 想用截圖重寫 RAG 檢索

Share to X
PixelRAG — Visual Retrieval-Augmented Generation

遇到表格、版面層次、插圖同文字混排內容，單靠文字檢索好容易漏掉關鍵線索；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: 開源, API, Embedding, RAG, 框架

[入門教學文章]一文搞懂 CNN、RNN 與 Transformer

Share to X
Og image

學深度學習最容易卡住的位置，往往不是模型太難，而是聽過 neural network、Deep Learning、CNN、RNN、Transformer，腦入面仍然分唔清邊個處理影像、邊個擅長序列、邊個適合長距離內容關係。這篇文章屬於入門教學，重點是用 mental model 幫讀者建立直覺，而不是一開始就掉出一堆數學式。

內容先把 AI（Artificial Intelligence）、ML（Machine Learning）同 Deep Learning 的層次關係講清楚，再解釋 neural networks 點樣透過多層表示學習資料特徵。文中亦提醒一個常見誤解：Deep Learning 入面的「deep」主要是指層數夠多，並不是指模型真的像人腦那樣理解世界。

之後的重點放在三類常見架構之間的差異：CNN 適合由局部特徵逐步組合出整體理解，常見於影像；RNN 會按次序處理資訊，較貼近文字或時間序列；Transformer 則更重視整段內容之間的關聯，成為近年自然語言處理與多模態模型的重要基礎。對初學者來說，這種比較方式比單獨背定義更容易入手。

  • 用直觀方式整理 Deep Learning 與 neural networks 的基本概念
  • 把 CNN、RNN、Transformer 放在同一條線上比較用途與取向
  • 強調模型強項來自資料處理方式，而不只是名稱不同
  • 文章亦提到 Keras，方便之後進一步動手建立模型

引用模型：CNN、RNN、Transformer。整體來說，這項內容適合剛接觸深度學習、想先建立整體地圖的人閱讀；有少量 Python 基礎會更易銜接到 Keras，但就算未寫過模型，也能先用它釐清觀念。

項目主頁

Categories: Python, 教學, 模型訓練, 深度學習, Dataset 數據集

NotebookLM 改名 Gemini Notebook

Share to X
Og image

做研究、整理文件同準備報告時，最麻煩往往唔係搵資料，而係點樣喺一堆來源之中保持脈絡清楚。Gemini Notebook 由 NotebookLM 更名而來，定位仍然係獨立使用的筆記與研究助手，但重點放在同 Google 服務有更深整合，並加入 secure cloud computer，令資料處理方式更貼近雲端工作流。

對一般用家而言，呢次更新最直接的改變唔係功能名稱，而係使用體驗更靠近 Gemini 系列產品。你可以把它理解成原本 NotebookLM 的延伸版本：保留原有獨立產品形態，同時更容易接上 Google 生態中的內容、帳戶與服務，適合需要長時間整理知識、追蹤文件脈絡的人。

  • 由 NotebookLM 更名為 Gemini Notebook
  • 產品仍然獨立存在，唔係單純併入另一個介面
  • 與 Google 生態整合更深，協作路徑更順
  • 加入 secure cloud computer，強調雲端處理與安全性

對常用 Google 工具做學習、研究、內容整理的人來講，呢個方向比單純改名更有意思，因為它指向的是更完整的一站式知識工作流程。

項目主頁

Categories: Google, Gemini, 安全
Page 1 of 118
1 2 3 … 118