ActiveVision 點出視覺推理真空帶

望一眼答題的多模態模型,在 ActiveVision 幾乎集體失靈。這個 benchmark 把「要一路觀察先答到」的能力,拆成更貼近人類解題節奏的測試。

ActiveVision — An Exam for Active Observers. Vision is a loop, not a glance.

不少視覺題目唔係靠一眼辨認,而係要沿住線追、逐區域數、一步步核對先答得到;ActiveVision 正正針對呢種落差而來。作為一個 benchmark,它集中測試 iterative visual reasoning,處理的是模型看得到畫面,但未必能持續整理觀察過程的問題。

現有多模態模型常見做法是對單張圖作一次性判讀,再配合 chain-of-thought 直接作答;作者認為這種 single-glance 範式,對需要反覆掃描、追蹤順序與維持中間狀態的題型特別吃力。ActiveVision 因此設計了 17 個任務,並用 deterministic program 生成場景,再以 photorealistic 方式重繪,令畫面自然之餘仍保留可驗證結構。

數字相當直接:人類表現為 96.1%,前沿模型在官方無工具評測下最高約 10.6%,差距接近 9 倍。網站亦列出 agent 版本的 tool-use ablation,像 Claude Code 與 Codex 接入工具後,分數明顯高過純 chain-of-thought,表示問題未必只是「看不懂圖」,而是缺少可逐步外化與操作的解題流程。

  • 收錄 17 個任務,重點放在 distributed scanning 與 sequential traversal 一類逐步觀察題
  • 官方評測涵蓋 Claude、GPT、Gemini,亦提供 agent ablation 腳本
  • 數據集可經 Hugging Face 下載,評測程式以 Python 為主
  • 同一靜態圖片也能迫使模型做多步推理,唔靠影片輸入撐起難度

整個 GitHub 項目比較像研究與評測基建,而唔係即用型產品:你需要先下載數據集、配置對應供應商 API,然後用 repo 內的 eval 腳本跑結果。對做多模態模型評測、Agentic 工作流、或者想驗證 Computer-use agents、CUAs 式外部工具協作價值的團隊,它提供了一個很尖銳的檢查點:模型是否真的會「觀察」,還是只會對影像作高階猜測。

項目主頁 · GitHub · Paper

Categories: 開源, Agentic, 多模態模型, OpenAI, Gemini, API, Python, Anthropic, Dataset 數據集

Cura 1T 瞄準醫療代理工作流

Cura 1T唔只想答醫療問題,而係朝住診療對話、臨床推理同 EHR 操作一條龍處理。對想評估醫療 Agentic 能力嘅團隊,呢個項目值得細看。

main comparison

醫療場景最難處理嘅,往往唔係單次問答,而係要連續對話、讀文字同影像、再連到 EHR 做操作。Cura 1T 就係朝住呢種 Agentic healthcare 用途打造嘅大型模型,重點不在通用聊天,而在病人諮詢、臨床推理同 FHIR-based record operations 呢三類高風險任務。

同類模型多數以通用能力再加醫療微調去應付需求,Cura 1T 則明顯押注 recursive self-improvement:由 training agent 規劃目標能力、訓練、沿 benchmark trajectories 找失誤,再調整 data mixture,而且每輪都有人類決定 keep-or-revert。呢個取向反映佢想解決嘅不只是知識覆蓋,而係醫療流程中跨回合、跨工具、跨模態嘅穩定度。

現階段最實際係經 OpenAI-compatible API 接入,model id 為 actava/cura-soar;公開資訊未見完整開放權重,較似面向企業試用與系統整合,而唔係本地自行訓練或離線推理。對醫療機構、健康科技團隊,或者要做 EHR、care management、行政自動化項目嘅開發者,呢種交付方式會較直接。

  • 以醫療模型定位,但核心賣點其實係 agentic workflows
  • 支援 text + vision,同時提供 256K context,適合長病歷與多模態判讀
  • 基於 Kimi-K2.6 後訓練而成,並非由零開始訓練
  • 基準測試在 6 個 healthcare benchmark panels 之中領先 5 項,但 MedXpertQA-Multimodal 仍落後 GPT-5.5

表現:HealthBench Hard 36.8、HealthBench Professional 66.2,亦在 AgentClinic 與 MedAgentBench 略勝 Claude Opus 4.8;相對 base model Kimi-K2.6 亦有明顯進步。要留意嘅限制係,分數來自 technical report 指定 protocol,而且 API 仍需排隊申請,現階段更適合做能力評估、流程驗證同企業整合規劃,未算係隨手可用嘅開源醫療模型。

項目主頁 · GitHub · Paper

Categories: 清華大學, Agentic, 多模態模型, API, Medical醫學, Dataset 數據集, Kimi

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

你可以把它理解成一個專門為表格資料設計的基礎模型,由 Google Research 開源,無需訓練即可做分類與迴歸,對於常用 scikit-learn 的團隊特別友善。

Repository image for google-research/tabfm

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

這個項目屬於模型與框架混合性質的開源工具,以 scikit-learn 風格的 API 呈現,因此熟悉 fitpredictpredict_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:可用熟悉的 fitpredictpredict_proba 流程接入
  • 混合欄位支援:同時處理數值與類別特徵,免去額外前處理設計
  • 雙後端選擇:可依環境需求在 JAX(Flax)與 PyTorch 之間切換
  • 開源但非官方產品:定位為研究性質,部署前宜自行驗證效果與合規

項目主頁 · GitHub · 模型

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

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

想在本地架一個 OpenAI 相容嘅語音轉文字 API?ModelScope 嘅 FunASR 將 SenseVoice、Paraformer、Fun-ASR-Nano 等模型收喺同一個 Python 接口,仲支援 vLLM 加速同 MCP 接入 AI Agent。

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: 開源, Agentic, MCP, Qwen, NVIDIA, API, IDE, LangChain, Python, 語音, Dataset 數據集

PixelRAG 想用截圖重寫 RAG 檢索

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

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: 開源, RAG, Embedding, API, 框架

Grok Build 開源後,編碼代理點樣運作一目了然

想知道 AI 編碼代理點樣讀上下文、調工具同改碼,Grok Build 而家可以直接睇原始碼。它更吸引的地方,是連本地推理流程都可自行接駁。

Og image

想追到 AI 編碼代理點樣一步步理解程式碼、決定用咩工具,再把結果送回終端,Grok Build 而家提供了一個相當直接的入口。這個由 SpaceXAI 公開的 coding agent 與 TUI,不只方便試用,還把整個運作骨架開源,重點是讓人真正查清楚代理在處理什麼、又可以改到什麼。

對開發者而言,價值不止在「可用」,而是在「可驗證」。你可以直接查看它怎樣組裝 context、解析模型回應、分派 tool calls,也可以理解它怎樣讀寫程式碼、搜尋內容與執行指令。做緊技能擴充、插件整合,或者研究 MCP servers、subagents 工作流的人,這份原始碼會比單靠文件更有參考價值。

  • 開源範圍涵蓋 agent loop、tools、terminal UI 與 extension system
  • 可研究 skills、plugins、hooks、MCP servers、subagents 的載入與呼叫方式
  • 支援 local-first 用法,可自行編譯並接上本地 inference
  • 主要透過 config.toml 控制整體執行流程

和常見只提供託管服務或有限介面的工具相比,Grok Build 把關鍵細節直接攤開。使用時不一定要綁定雲端環境,亦可以自己編譯、指向本地推理後端,令測試、除錯、客製化與安全審視都有更大空間;代價是你要自己處理部署與整合,門檻自然較高。

對需要打造自訂 coding agent、終端工作流,或研究代理工具調度方式的人來說,這次開源相當有參考價值。

項目主頁

Categories: 開源, Agentic, MCP, API, Vibe Coding, 編程, 安全, Skill 技能

statistical_self_consistency:檢查 LLM 判斷靠唔靠得住

同一個問題換幾種切法,模型答案未必能夠互相對得上。呢個研究項目正正用統計方法量度呢種落差。

Statistical self-consistency in language models

當你想用 Large Language Models(LLMs)去估計某個群體的收入、意見分布或問卷答案,最麻煩唔係模型有冇答,而係同一批人用不同條件拆開再合併之後,結果會唔會前後一致。statistical_self_consistency 針對的正是呢個問題:它屬於研究實驗型程式庫,用二元 conditioning tree 把人群逐層分割,向模型索取各節點估計,再用 law of total probability 重建整體分布,檢查模型輸出有幾接近真正「條件機率」應有的表現。

項目的技術重點唔係再訓練一個新模型,而係替現有 LLM 加上一套 reference-free 的自我檢查方法。它一邊比較重建後的 aggregate 與直接 marginal estimate 是否一致,一邊再用 American Community Survey(ACS)、Global Opinion QA 同 World Values Survey(WVS)的人類統計資料做 alignment 對照。呢個取向同一般只睇單題準確率或 benchmark 分數的做法唔同,因為它更關心模型輸出在統計層面有冇內在矛盾。

資料與執行方式也反映出它偏向研究用途。README 已交代實驗分佈在 src/experiments_acs/src/experiments_global_opinion_qa/src/experiments_wvs/,ACS 與 WVS 亦有對應 data loader;WVS 需要自行從官方網站下載 SPSS 檔案並放到指定資料夾,另有 secrets/secret_config.yaml 儲存 API keys。原始資料沒有提供一鍵部署、公開模型下載或產品化介面,較合理的理解是:你會用它重跑論文實驗、檢查提示設計下的估計穩定性,或者把同類方法接到自己的 LLM 評測流程。

  • 用 binary conditioning trees 檢查 LLM 估計能否在分割與聚合後保持一致
  • 涵蓋 ACS、Global Opinion QA、WVS 三類任務,包含收入估計、跨國意見題與問卷分布
  • 同時做 self-consistency checks 與 human data alignment,唔只看單次回答
  • 依賴外部資料與 API keys,較接近研究驗證流程,未見即裝即用的產品包裝

受益最大的會是做 LLM evaluation、computational social science、survey estimation 或 prompt-based inference 的研究者與團隊。它未有在目前資料中列出完整性能數字,但方法定位相當清楚:不是追求更花巧的生成能力,而是量度模型在條件推斷場景下有幾可信。相關模型名稱在現有資訊中未被具體列出,只能確認此項目面向一般 LLM 實驗,而非綁定單一模型家族。

GitHub

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

SearchOS:把搜尋變成像作業系統排程一樣的多代理協作

面對開放領域的複雜提問,多數 AI 搜尋都困在對話歷史裡打轉。SearchOS 把問題拆成一張覆蓋表,由多個子代理平行補齊每個空格,最後交出一份附引用的答案。

SearchOS — from single-fact lookups to full-domain research, unified as citation-grounded relational schema completion

開放領域搜尋最常見的瓶頸,不是模型不夠聰明,而是任務一複雜,搜尋狀態就會淹沒在對話紀錄裡,代理開始遺忘、繞圈、重複。SearchOS 嘗試解決的正是這個卡位:它把搜尋狀態從對話裡抽離,放進一個像檔案系統一樣的常駐層,由 Search-Oriented Context Management(SOCM)統一管理任務序列、證據圖和覆蓋表。

這個開源框架以 LangGraph 為骨幹,把提問先正規化成 entity × attribute 的覆蓋表,再把空格派給多個 pipeline-parallel 子代理去填。每格證據都帶著來源寫入共享的證據圖,最後由合成階段產出附引用的答案。整體端到端耗時接近最慢的那條單鏈,而不是各鏈相加。內建 sensor 機制會偵測五種迴圈或停滯,必要時重新派工。

Introduce SearchOS: Agentic Search Operating System

Skills 系統與 SF PROVIDER 讓它能處理反爬、登入牆,也能對接多家搜尋供應商。對做深度研究、競品盤點、盡職調查的團隊來說,這種「每個結論都追得到來源」的設計,比單純的長上下文檢索更貼近真正的工作場景。需要留意的是,覆蓋表驅動的設計在簡單事實查詢上略嫌重,平行代理也會增加 API 成本;但對於需要高召回、可審核的研究任務,差異是明顯的。

GitHub

Categories: 開源, Agentic, API, LangGraph, Skill 技能

KeyFrame-Compass:關鍵幀尺度評測

想知道影片生成有沒有跟住關鍵畫面,KeyFrame-Compass 就把這個矛盾拆開量度。它同時看畫面有沒有到位、順序有沒有跟足,還會檢查整體影片質感。

KeyFrame-Compass benchmark domains and examples

KeyFrame-Compass 是一個用來評測 keyframe-conditioned video generation 的基準項目,重點在於檢查模型能否同時跟住文字提示同一組按順序排列的 keyframes 生成影片。對做影片生成的人來說,這類測試最有價值的地方,是它不只看成片好不好看,還會追問畫面有沒有真係按要求出現、順序有沒有走樣。

這個項目把評測拆成兩層:一層看 keyframe execution,包括關鍵畫面存在、視覺還原、時間順序、定位、持續性同回應唯一性;另一層看 overall video quality,會用 evidence-grounded MLLM(Multimodal Large Language Model, MLLM)判斷,加上專門的感知模型去量度視覺質素、時間連貫性、指令遵從同音訊表現。這種分法比單純比對整體分數更清楚,因為它能分辨出模型係「畫得靚」定「跟得準」。

官方提供 386 個案例,涵蓋三個應用領域,亦分有 multi-shot 同 one-take 片段,配合四種 keyframe 密度。安裝上需要 Linux、Conda 或 Mamba、NVIDIA GPU,同埋可用的 VLM API;倉庫亦提供 envsassetsall 三種設定模式,方便只建環境、只拉資產,或者一次過做完整驗證。

  • 把影片生成的「跟畫面」同「成片質感」分開量度,結果較容易解讀
  • 支援不同 keyframe 密度,較適合比較模型對控制力的穩定度
  • 適合做影片生成模型、研究原型或產品 demo 的質量驗證
  • 需要 GPU 同外部 VLM API,部署門檻唔算低
  • 相關模型類別可歸到 Video、視覺模型、多模態模型、模型、工具

GitHub

Categories: 開源, 模型, 視覺模型, 多模態模型, 視頻模型, NVIDIA, Gemini, API, Video, 工具, Linux

Kimi K3 把開源大模型推到 3T 級別

想要一個同時處理寫碼、長文件同推理工作的模型,Kimi K3值得留意。它未追平最強閉源模型,但已把開源模型的上限再推高一截。

Kimi K3 hero visual

長上下文、程式開發同知識工作往往要分開交畀不同模型處理,Kimi K3嘗試把這幾件事收在同一個開放模型內。它屬於大型多模態模型,重點是處理長流程 coding、長篇資料閱讀與推理之間的切換成本,並提供原生 vision 能力與 1M context。

Kimi K3 的定位,不是單靠參數規模取勝,而是想在開源路線上逼近 frontier intelligence。資料提到它有 2.8T parameters,屬於首個 open 3T-class model,整體表現仍落後於 Claude Fable 5 和 GPT 5.6 Sol,但在自家 evaluation suite 內已持續超過其他被測模型,顯示它在開源陣營有明顯競爭力。

技術上,這個模型建基於 Kimi Delta Attention(KDA)同 Attention Residuals(AttnRes),目的是改善資訊在長序列與深層網絡中的流動方式;同時也擴大了 Mixture of Experts(MoE)sparsity。這種做法反映它要處理的核心矛盾:一邊維持超長 context 與多類任務能力,一邊控制推理與訓練效率。

  • 首個 open 3T-class model,規模達 2.8T parameters
  • 原生支援 vision,並提供 1M context window
  • 目標場景包括 long-horizon coding、knowledge work 同 reasoning
  • 採用 Kimi Delta Attention(KDA)、Attention Residuals(AttnRes)與 Mixture of Experts(MoE)
  • 已在 Kimi.com、Kimi Work、Kimi Code 同 Kimi API 提供使用

對開發者、研究者同需要長文檔工作流的人來說,Kimi K3最有吸引力的地方,在於它把「夠長、夠廣、夠開放」放在同一個項目裡。現階段可確認的限制也很清楚:它未到最強閉源模型的水平,而完整權重、架構與訓練細節仍要等後續 technical report 與正式釋出。

項目主頁

Categories: 開源, Agentic, 多模態模型, API, Vibe Coding, 教學, 線上服務, IDE, Mac, 編程, OpenClaw

Page 5 of 9
1 3 4 5 6 7 9