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

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: Qwen, Gemini, Embedding, LLaMa, Ollama, Kimi, Dataset 數據集

StreamArena 多模態長片代理的記憶與互動分析

來自香港科大、港大與中大及小紅書的團隊,把長達近 90 分鐘的影片理解拆成可持續觀察、回想、找工具與主動回應四種能力。

StreamArena overview

由 HKUST(香港科技大學)、The University of Hong Kong(香港大學) 與 The Chinese University of Hong Kong(香港中文大學) 及小紅書組成的開發團隊,將焦點放到一個很多多模態代理都未真正處理好的難題:影片唔再係幾秒剪輯,而係接近一個半鐘頭、仲要持續互動。StreamArena 屬於資料集與評測工具包,處理的是 continuous streaming video understanding,目標係用統一方法檢驗代理在長時間影音流之中,能否即時理解、隔一段時間後仍然記得內容,並在合適時機用工具或主動回應。

呢個項目最值得注意的地方,在於它唔用短片加選擇題去掩蓋模型弱點,而係用 243 段 full-length videos、平均 88.8 分鐘、合共 3,646 個 open-ended tasks,分成 Real-Time Perception (RTP)、Historical Retrospection (HR)、External Tool Use (Tool) 同 Proactive Interaction (Pro)。HR 與 Pro 仲按時間跨度分層,HR 最遠拉到 30 分鐘,直接把長期記憶與延遲控制的取捨攤開來測。

StreamArena Evaluation Toolkit:streamarena/ 放資料載入、媒體處理、tool-call protocol、OpenAIBackend、GeminiBackend 同 LLM-as-Judge scorer;method/ 則整理多種被測方法,包括 offline 的 Qwen、MiMo、Kimi、Qwen-Omni、Gemini,以及 MiniCPM-o-4.5、VST、StreamForest、ThinkStream。所有方法都寫入同一套 records JSONL schema,所以 judge/ 可以用同一把尺評分。安裝與執行細節在目前資訊裡未完全展開,但可確認它不是單一模型倉庫,而是用來重跑、對齊與比較不同方法的評測框架。

  • 覆蓋四類能力:RTP、HR、Tool、Pro,唔只問答,仲測持續監看與主動互動
  • 243 段長影片、平均 88.8 分鐘,資料規模明顯偏向長時序理解
  • 同一份 JSONL 輸出格式配合通用 judge,方便橫向比較不同方法
  • StreamMind 在同一 Qwen3.5-397B-A17B backbone 上,把 pooled query-to-answer latency 降低 66.2%

一個重要限制:StreamMind 在這次釋出裡只有 evaluation protocol docs,未附完整可直接重現的實作;AURA 亦只提供 client,server 仍要依賴官方 vLLM。換句話說,StreamArena 現階段更像研究團隊、代理系統開發者同多模態評測工作流會用到的基礎設施。想比較不同 streaming method、檢查長影片代理究竟卡在記憶、反應,還是工具調用,呢個項目比一般短片 benchmark 更接近部署前要面對的現實。

項目主頁 · GitHub

Categories: 開源, Qwen, 香港, 香港大學, 香港中文大學, 香港科技大學, Gemini, Agentic, Video, 多模態模型, Kimi

PerceptionBench:Moonshot AI 教你測試 MLLM 視覺盲點

不少多模態模型答得似模似樣,但未必真係睇得準。PerceptionBench 把問題拆到最細,專門量度 MLLM 最基本的視覺感知能力。

kimi small

不少 Multimodal Large Language Models(MLLMs)表面上回答完整,但錯誤未必來自推理,往往早在「看圖」那一步已經出現。PerceptionBench 就是一個評測資料集兼 benchmark,專門把視覺感知拆成最細單元,檢查模型究竟係讀錯字、看漏關係,還是出現 perception-related hallucination(Hallu)。

它的價值,在於不再用一個總分掩蓋問題。團隊先分析 42 個現有 benchmarks 的失敗案例,再整理出一套錯誤分類,當中視覺感知分支包含十種 atomic perceptual capabilities,之後用這個框架建立 3,000 條經驗證題目,每題只測一種能力,答案亦刻意保持簡短而明確,盡量避免把推理或背景知識混入結果。

對做模型評估、資料標註或多模態產品調校的人來說,這個項目最有用的地方,是你可以更早定位問題源頭。它不是教你部署模型的工具,而是用來比較模型能力輪廓的尺;資料已放上 Hugging Face,程式碼亦公開,較適合拿來跑 benchmark、重現論文結果,或者把自家模型放入同一套題目做橫向比較。

  • 以 3,000 條 verified questions 測十種 atomic visual perception 能力
  • 題目刻意隔離單一能力,減少推理與知識干擾
  • 共評測 16 個 frontier MLLMs,使用統一 prompts
  • 沒有模型準確率超過 60%,Hallu 表現平均最弱
  • 相近總分之下,不同模型的能力分佈可以差很遠

所有題目都採用開放式短答案,再由 GPT-oss-120B 依參考答案判分,官方指它與人工審核在 300 個樣本上的一致率達 99.7%。這類設計未必等同真實產品場景,但很適合做能力層面的診斷;當你想知道模型到底「唔識答」還是「睇錯圖」,PerceptionBench 提供的資訊比一般綜合排行榜更有分析價值。

GitHub

Categories: 開源, 多模態模型, Kimi, Dataset 數據集

OpenWorker – Andrew Ng 開發桌面 AI 龍蝦

OpenWorker 係一個開源嘅桌面 AI 同事,由 Andrew Ng 團隊開發,強調本地執行、帶自己嘅模型 API key,並且會產出真正嘅成品而唔止係聊天回覆。

How OpenWorker works

對好多打工仔嚟講,最大嘅困擾唔係 AI 唔夠聰明,而係佢只識得「答問題」而唔識得「做完件事」。OpenWorker 嘅切入點正正喺呢度:佢定位係一個會跑喺你電腦上面嘅 AI 同事,可以幫你整理 calendar、寫 follow-up email、甚至自動出一份 customer brief,最後畀你一份可以直接開嚟用嘅文件,唔係一串對話。

OpenWorker 由 Andrew Ng(吳恩達)相關團隊推出,引擎建基於佢哋自己開發嘅 Python 開源庫 aisuite,呢個庫提供統一嘅 chat-completions API 以及支援工具調用(tool calling)、MCP 等功能。簡單講,OpenWorker 唔係從零寫起嘅 wrapper,而係將 aisuite 包成一個真正面向桌面用戶嘅應用,並且喺原本 aisuite 倉庫入面開發咗一段時間之後,先搬出嚟獨立成 repo。

目前支援 macOS(Apple Silicon)以及 Windows 10/11,用家可以貼上自己嘅 API key 去用 OpenAI、Anthropic、Google Gemini、DeepSeek、Kimi、Qwen、Mistral 等模型,亦可以經 Ollama 完全本地跑開源模型。所有嘢都喺本機行,只有用家授權嘅 model call 或者連接工具先會接觸到網絡。對於注重私隱或者公司政策唔畀數據出 cloud 嘅人,呢個係一個幾實際嘅選擇。

OPENWORKER: The Free AI Desktop Agent That Isn't Locked to One Model

佢亦內建 25+ 個整合,包括 GitHub、Slack、Jira、Notion、Linear、HubSpot、Outlook、Gmail、Google Calendar 等,亦支援任何可以經 MCP(Model Context Protocol)接駁到嘅工具。最令筆者欣賞嘅係佢嘅審批機制:寫訊息、發送郵件、執行 shell 指令呢類「對外有影響」嘅動作,全部都要先經你確認先至會執行,唔會自己靜靜雞撳掣。

以下係幾個用家會比較關心嘅重點:

  • 定位係桌面 AI 同事,目標係交到「成品」而唔止係聊天回覆,例如 HTML brief、Markdown 報告、排好嘅 calendar 更新等。
  • 完全開源、MIT 授權,由 Andrew Ng 團隊開發,引擎建基於佢哋嘅 aisuite 開源庫。
  • 模型自選,支援多間主流 cloud provider,亦可以經 Ollama 完全本地執行開源模型。
  • 重視私隱,對話、token、API key 都儲喺本機 secret store,唔需要登入亦可以用。
  • MCP + 審批機制,所有對外動作(發訊息、執行指令)都會先問過你先做,減低「AI 自行撳掣」嘅風險。

如果你係一個人或者小型團隊,想搵一個可以幫你「跑手」而唔係淨係「傾偈」嘅 AI 工具,又唔想將公司敏感資料送去閉源服務,OpenWorker 算係一個值得試嘅選擇。佢而家仲喺 open beta,官方表示會自動更新、不斷執吓啲 bugs,畀用家提交 issue。適合想認真將 AI 融入日常工作流、對私隱同可控性有要求嘅人。

項目主頁 · GitHub

Categories: 開源, Qwen, Google, Gemini, DeepSeek, OpenAI, API, MCP, 工具, Mac, Ollama, Python, Anthropic, 蘋果, Kimi

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