互動與多模態

interaction-multimodal 領域的內容地圖 — 11 個概念。這是精選入口；所有領域請見 Home。

• Content-Driven Intervention — 因內容值得發言而開口——糾正錯誤主張、警告危險、提供正在尋找的詞語——而不是因為對話結構輪到自己發言；Peng et al. (2026) 透過情境配對的獨白區分兩者，發現五種全雙工語音家族的七種配置中，被點名和沉默會影響開始發言的時機，而錯誤事實與危險造成的影響最多只有.06；額外停頓及明確指示「如果我錯了就打斷我」都無法縮小差距；即使把發言權交給模型，非空白的錯誤事實回覆中也只有.14-.15會質疑該主張，危險回覆中只有.04-.07會提出警告
• Encoder-Free Early Fusion — 以最少前處理進行多模態設計，而非使用大型獨立編碼器：TML 在單一 transformer 中共同訓練 dMel 音訊、40×40-patch hMLP 與 flow head，延遲為 200ms；Gemma 4 的 12B 模型獨立捨棄了 305M 音訊 conformer，以節省裝置端記憶體；Inkling 將此設計擴展至 975B 開放權重規模；Kimi K3 在 2.8T 規模保留 401M MoonViT-V2 編碼器，在影像密集文字語料上排名第一——Tuna-2 最後補上尺寸配對組：僅使用 patch embedding 的 7B 模型在 12 項理解基準中的 10 項勝過搭載 SigLIP 的同規模模型（也在 OCRBench 勝出，打消了密集文字疑慮），但生成能力較差；這項優勢只在 1.5B 骨幹模型以上，且只在 3T 預訓練 token 中約 2T 之後出現
• Full-Duplex Interaction — 跨模態同時感知並回應——這是排程特性，而非以語音輸出的特性；主動插話、對視覺線索作出反應、同步發言、即時翻譯與具時間感知的語音都是模型行為的特殊情況；自 2026 年 7 月起以 GPT-Live 在正式環境提供純音訊服務，並於 2026-09-10 在 API 推出，OpenAI 將雙工功能作為按價計費的層級銷售，並把輪次偵測做成非輪次模型上的選用功能；NVIDIA（2026 年 9 月）展示系統可同時採用全雙工與級聯架構，其開放權重 VoiceChat-11B 則提供啟發式 BOS/EOS 終止點偵測器作為備援——偵測器從側門回來；Peng et al. 又提出第三種區分——是否決定開口，也不是雙工功能所賦予；Google 宣稱視覺接地與對話中切換 97 種語言都是即時模式；OmniVChat：原生輸入音訊與影片，不具雙工功能
• Interaction / Background Model Split — 雙模型架構：具時間感知的互動模型持續在線，非同步背景模型負責深度推理與工具；以豐富的情境套件進行委派；「以推理模型規劃，同時維持非思考延遲」；Inkling 是具名的背景模型，OpenAI 的 GPT-Live 則是正式環境中的互動模型，而 NVIDIA（2026 年 9 月）公開了另外兩者未提供的委派訊號——<tc bos>/<tc eos> token 配對、僅以逐字稿交接、prefill-and-repeat 回傳，以及會進入靜音而非保持在線的前端；2026-09-10，這種分工成為按價計費的產品界線：前端每分鐘 $0.05，後端由開發者選擇；2026-09-15，Google 推出兩個即時服務層級，未指出後端模型，兩端也都未定價，再次提出保持在線的主張，並銷售與之矛盾的拖延語句及步驟敘述
• Interaction Models — Thinking Machines Lab（2026 年 5 月）：原生即時處理音訊／影片／文字互動的模型，而非透過 harness 實現；只有互動能力內建於模型時，互動性才會隨智慧提升——OpenAI 的 GPT-Live（2026 年 7 月）也獨立在正式環境推出相同結論中的音訊部分
• Interactivity Benchmarks — FD-bench、Audio MultiChallenge + TimeSpeak/CueSpeak（主動音訊）與 RepCount-A/ProactiveVideoQA/Charades（視覺主動性）；TML-Interaction-Small 的輪替延遲為 0.40s；工具呼叫部分（BFCL-audio、FDB3、EVA-Bench、τ-Voice）中，語音代理完成有依據的客服任務比例為 31–51%，文字代理則為 85%；Peng et al. 的情境配對獨白測試顯示，內容線索最多讓開始發言時間移動.06；以及相隔一週的兩份廠商評分表——OpenAI 的七張 GPT-Live-1 自我對照卡，以及 Google 繪製於第三方評分榜的五張圖表，其中 Sierra 銀行項目與 OpenAI 的數字逐位相同，而同一配置在兩個基準名稱下分別得到 67.9% 與 86.2%；還有 OmniVChat-Bench：2,800 段完全合成的視聽對話，採用分級門檻式評分規準，單一檢查點的差異只是雜訊
• Live-Path Minimalism — GPT-Live 的服務原則——「語音必須流暢」：即時媒體迴圈是即時路徑上的唯一工作；委派、壓縮、持久化與執行個體管理都在路徑之外非同步進行。有狀態的執行個體交接（預熱替代執行個體、prefill、兩者並行、切換）可將壓縮與重新平衡轉為零中斷轉換；委派是以預熱且完成 prefill 的前沿模型工作階段為基礎、受預算限制的迴圈；WARP + Instant Connect 將 WebRTC 啟動從六次往返縮短為一個 UDP 封包；容量指每個影格都能準時處理的並行工作階段數，而非 GPU 吞吐量。這條界線面向第三方，且採用按價計費（GPT-Live-1 API，2026-09-10：僅即時路徑每分鐘 $0.05）；NVIDIA 的啟用／停用委派消融實驗（2026 年 9 月）為此定價：即時路徑輪替延遲增加 15 ms，代價則由路徑外的 ASR WER 10.80→11.47 及 CommonEval 2.87→2.36 承擔
• Native Multimodal Modeling: Fusion Depth and I/O Duality — An, Lu, Dong et al.（Tencent Youtu + 5 所大學，2026 年 5 月）以兩種運算子定義形式化界定「原生」：中期融合將編碼器特徵注入共同骨幹，早期融合則透過單一統一 tokenizer 將每種模態映射到共享空間；晚期融合（凍結的 LLM + 移植的 head）則直接排除；接著將此軸與正交的輸入／輸出雙重性（Multi-to-Text、Multi-to-Target、Multi-to-Multi）交叉分析，涵蓋 43 個模型；其重點主張是每種融合機制都要求特定訓練特性：中期融合必須使用差異化學習率（CogVLM 的編碼器學習率為 1/10），早期融合的前提是 z-loss + QK-Norm（Chameleon 若缺少這兩者，訓練約 20% 後便會發散），以模態混合排程取代差異化學習率，而一旦 softmax 統一，RL 路徑局部性便會完全消失
• Time-Aligned Micro-Turns — 互動模型的核心做法：輸入／輸出採用約 200ms 的交錯連續串流區塊，不設輪次界線；串流工作階段推論（已 upstream 至 SGLang）、針對延遲調校的 MoE kernels、位元層級的 trainer-sampler 對齊；Moshi 與 NVIDIA VoiceChat 都採用 80ms（12.5Hz）影格，而 VoiceChat 將輪次界線設為影格層級的 BOS/EOS 目標，對其加權 12.5/7.5，padding 則為 1.0
• Turn-Based Interface Bottleneck — 為何目前的 AI 介面限制了協作：單一對話串的輪替是頻寬瓶頸；介面而非工作本身把人排除在外；能力較弱的 harness（VAD／輪次偵測）應該消失——而且確實已經消失：GPT-Live 在正式環境的音訊路徑中移除了輪次偵測器（2026 年 7 月），輪次只保留為衍生的應用層檢視——到了 2026 年 9 月的 API，又把輪次偵測作為選用功能賣回給開發者，提供給本身沒有輪次的模型
• Why AI Lags at Design — Andrew Ambrosino 提出前沿模型在視覺／產品設計上不如程式碼的四個原因：設計難以評分（沒有「是否能編譯」這種明確獎勵）、不在實驗室所最佳化的 AI 研究飛輪之內、設計獎勵新意而程式碼獎勵已知模式，以及設計↔程式碼之間藏有抽象層（一項品牌改造表面上涉及 263 個元件，底層則是語意關係）

衍生內容#

（無）