Opera WebAI 將本地模型帶入瀏覽器，背後有一項擬議標準

Opera 於 10 月 27 日推出 Opera WebAI，讓網站及擴充功能可使用本地 AI，而非每次請求都必須傳送至雲端伺服器。公司將其描述為一項擬議網頁標準的實作。這個分別很重要：推出瀏覽器功能，並不代表已在整個網絡建立共識標準。

這項公布將焦點由瀏覽器內置的 AI 助手，轉向其他開發者可使用的 AI 功能。Google Chrome 與 Microsoft Edge 已在進行相關工作。Opera 的貢獻著重於存取不同的相容模型，將模型選擇納入其主打賣點。

核心張力在於通用瀏覽器介面與其底層能力參差不齊之間。本地處理為特定工作提供另一種架構。開發者仍須考慮硬件、權限、模型行為，以及從不啟用此功能的用戶。

Opera WebAI 向網站及擴充功能開放本地模型

根據 Opera 的發布公告，Opera 的本地 AI 預覽版率先於 Opera One 推出。Opera GX 與 Opera Neon 則列為稍後跟進。此次發布列出 Google 的 Gemma 及 Apple 的裝置端基礎模型為支援選項。

這些是透過瀏覽器功能存取的獨立模型。WebAI 本身不是模型，而選擇相容模型亦不代表所有可用模型均可運作。

這項公布為開發者提供另一個執行 AI 工作的場所，而不只是新增一個聊天視窗。

應用程式介面（API）是網站用來請求瀏覽器功能的軟件介面。在此情況下，瀏覽器成為網頁應用程式與可用模型之間的中介。

這種安排改變了責任所在。開發者可圍繞瀏覽器提供的 AI 建立互動，而毋須營運每次互動背後的模型基礎設施。瀏覽器及裝置隨之成為應用程式執行環境的一部分。

試想像一個閱讀擴充功能，用來評估某段文字是否與進行中的專案相關。它的價值來自該段文字與讀者目標之間的匹配。若較窄範圍的操作已能作出這種判斷，便無須與助手進行一般對話。

Opera 透過實驗性擴充功能展示這類體驗。例子包括按專案相關性標示文章段落的 Project Lens，以及產生閱讀測驗的 Got It?。這些是示範，而非已獲廣泛採用的證據。

這個分別有助界定此次發布。Opera 提供了執行途徑，以及開發者可能建立的功能示例。它並未證明由此產生的工具優於現有服務，或能滿足每名用戶的期望。

實際供應情況亦存在差異。Opera 的公開網誌稱 One、GX 與 Neon 均可使用預覽版，新聞稿則指出會分階段推出。讀者應查看已安裝的瀏覽器版本，而不應假設存取權完全相同。

兩種說法均不改變事件本質：Opera 正向網頁應用程式開放本地 AI。但當開發者要判斷某項功能是否已可供客戶使用時，準確的供應資訊十分重要。

對用戶而言，眼前問題同樣具體：一款有用的應用程式，是否確實在其電腦上支援此功能？瀏覽器公告創造了機會；應用程式決定該機會是否能改善日常工作。

開發者可選擇不將每項工作都傳送到雲端

最直接受影響的開發者，是正在衡量一項小型 AI 功能是否值得營運雲端服務的人。

雲端服務在遠端基礎設施上運行模型。本地推論，即在用戶裝置上產生模型輸出的過程，則將這種運算移至不同環境。

對小型擴充功能而言，這可改變產品的盤算。考慮文章分類功能的開發者，否則必須決定如何處理遠端請求、憑證、服務可用性及持續使用。瀏覽器提供的執行能力帶來另一條途徑。

這不代表整個應用程式可以免費營運。開發、測試、支援、分發及安全工作仍然存在。即使開發者毋須另付模型服務費，運算仍會消耗用戶裝置資源。

因此，有意義的比較在於架構：誰提供運算資源、誰管理模型，以及工作流程中哪些部分需要遠端服務？

對處理讀者眼前已開啟頁面的功能而言，本地執行在概念上十分契合。相關內容與介面本已在一起。是否將內容傳送至其他地方，成為設計選擇而非自動要求。

雲端執行保留另一種優勢：開發者可指定其服務使用的遠端模型。使用瀏覽器提供的模型時，應用程式必須在用戶可用的相容能力範圍內運作。

這種差異會對產品假設帶來壓力。介面不能只因功能在開發者自己的電腦上運作，便承諾即時 AI 回應。在本地執行不可用時，仍須提供容易理解的體驗。

合理的產品仍可讓用戶手動標記文章、按字詞搜尋，或閱讀原始材料。這些替代方式保留核心工作，亦避免把可選的瀏覽器功能變成障礙。

對企業買家而言，考量不止於單一功能。本地處理改變了工作的執行位置，但機構仍需了解應用程式會存取及保留哪些資訊。

即使模型在本地執行，會讀取內部文件的瀏覽器擴充功能仍會引發疑問。本地推論回答了處理位置的問題，卻不能獨自回答存取控制、保留或分發的問題。

知識工作者亦有相關顧慮：有效檢索不只取決於產生答案。來源集合、權限及檢視佐證材料的能力仍然重要。個人知識庫可處理這個更廣泛的資訊問題。

因此，Opera WebAI 為工作流程的某些組件提供選項。它不會自動提供周邊知識系統、協作模式或管治控制。

短期機會較取代所有雲端 AI 的說法更狹窄，也更可信。開發者可評估某項特定工作是否適合在裝置上進行，並在應用程式需要時保留其他執行途徑。

共用介面並不保證共通的模型行為

Opera 正加入既有的瀏覽器 AI 工作。Google 的文件描述了 Chrome 中使用 Gemini Nano 的瀏覽器語言模型介面。Microsoft 則在 Edge 開發者頻道記錄了一項實驗性的內置 Prompt API。

這些實作提供有用的參考點。Opera 的公布是更廣泛嘗試的一部分，即透過瀏覽器介面讓模型可供使用，而非發明本地瀏覽器 AI 本身。

通用的答案請求方式，並不保證獲得通用答案、同等品質或相同的支援裝置。

相關的 Prompt API 草案說明如何存取瀏覽器提供的語言模型。其狀態聲明明確指出，該項目並非 W3C 標準，亦不在 W3C 標準化軌道上。

這正是此次公告中「標準」一詞應有的語境。擬議介面可在正式標準化前引導實作並吸引支援。報道其可用性時，應保留其提案狀態。

對開發者而言，這個分別不只是術語問題。瀏覽器功能即使尚未廣泛可攜，仍可能具有價值。但面向更廣泛網絡的應用程式，仍須確定哪些環境支援所需行為。

這裏有不同問題：介面是否存在？裝置能否提供模型？該模型能否恰當處理應用程式的工作？回答第一個問題，並不能解決其他問題。

分類功能說明了這個落差。即使應用程式發出等效指令，不同模型對某段文字是否相關仍可能有不同判斷。介面可以正確運作，而用戶體驗仍會有所差異。

當應用程式將模型輸出轉化為行動時，這種變異尤其重要。標示可能相關的段落，仍為用戶判斷保留空間；自動捨棄文件則需要更強的信任基礎。

因此，模型選擇同時帶來彈性與測試工作。支援另一個相容模型會擴大可用的執行選項，也引入開發者需要評估的另一種行為。

正確的比較單位是已完成的工作。功能能否找出有用段落而不隱藏關鍵脈絡？生成的測驗能否維持以文章內容為依據？分類結果能否被更正？

這些問題比模型能否產生流暢文字更具參考價值。流暢度可令不完美的答案看來已成定論。有用的應用程式需要證據證明其輸出符合實際決策需要。

瀏覽器供應商亦面對相關挑戰。簡化模型存取令實驗更容易，但開發者需要足夠資訊，以了解可用性及故障情況。隱藏基礎設施細節，不應同時隱藏該功能的實際限制。

Opera 的多模型做法正處於這種張力之中。它在執行層提供彈性，同時讓應用程式建立者負責評估結果。其承諾是提供替代選項，而非可互換的行為。

瀏覽器層面的 AI 改變小型功能的形態

Opera 將文字生成、分類及內容之間的關係描述為開發者的組成模塊。其 WebAI 範例展示這些操作如何支援圍繞讀者正在閱讀頁面的互動。

最適合的初步應用，是輸出可供用戶檢視及更正的有限範圍工作。

語義嵌入是用於按含義比較內容的數值表示，說明模型能力與完整產品之間的分別。它們可支援尋找相關段落，但應用程式必須決定要收集及顯示甚麼。

一個假設的研究擴充功能，可將已儲存的問題與文章中的段落作比較，然後顯示看似相關的段落。讀者仍需閱讀原文，以判斷匹配是否有用。

這可清楚維持建議與證據之間的關係。模型有助引導注意力，而原始頁面仍可供查閱。這與產生缺乏支持依據的答案，是不同的責任。

同一邏輯亦適用於分類。當錯誤可逆時，顯示給用戶的標籤可加快整理工作。若系統根據該標籤靜默刪除內容，後果便會不同。

對開發者而言，這令介面設計成為模型評估的一部分。功能應清楚說明輸出代表甚麼、來源何在，以及是否屬於建議。單靠模型執行並不足以建立這些界線。

這亦解釋了為何值得關注範圍較窄的瀏覽器功能。其價值毋須取決於能否在所有主題上媲美通用助理。只要改善與目前螢幕內容的特定互動，便可以成功。

例如，文章重點標示工具的目標，與被要求研究整個市場的助理並不相同。前者可根據可見文件及已說明的興趣來評估；後者則需要更廣泛的資訊蒐集及核實。

這是對可能產品契合度的分析，並非對 Opera 實作的基準測試主張。公告提供了可能互動方式的例子，但未能證實其對不同讀者、主題或裝置的準確性。

同時亦有分發問題。瀏覽器可以提供這項能力，但開發者仍須交付人們希望持續使用的工具。示範只顯示互動是可行的；重複使用才可證明其值得採用。

這項差異應影響人們對發布的預期。相關的採用證據，將來自能解決明確問題的應用程式，尤其是用戶能說明為何本機執行可改善體驗的情境。

就知識工作而言，這或代表在整理閱讀內容或尋找相關資料時，出現較少中斷；不應只是因為可以生成，便額外產生文字。

Opera 為建立這類體驗開闢了另一條途徑。它會否變得重要，取決於應用程式質素、用戶信任，以及支援無法使用本機模型人士的能力。

私隱與硬件界定預覽版的限制

Opera 表示，預覽版採用選擇加入機制，啟用後才開始下載模型，並以網站專屬權限控制存取。其列出的平台包括 64 位元 Intel 或 AMD Windows 電腦，以及採用 Apple silicon 的 Mac。

該公司的網誌將 Intel Mac、Linux 及 Windows on Arm 排除在預覽版之外。Opera 亦表示，回應速度取決於裝置。

本機處理減少的是某一項資料傳輸；它並不代表整個應用程式已獲私隱認證。

網站即使使用本機 AI，仍可能因其他原因與遙距服務通訊。擴充功能亦可能擁有與模型執行無關的權限。用戶需要評估應用程式的完整行為。

這並不減損將模型輸入留在裝置上的價值，而是精確界定該項主張。避免向遙距模型發出請求，處理的是該請求本身，而非所有可能的收集或披露途徑。

對機構而言，相關審查應追蹤資訊在整個工作流程中的流向。應用程式會讀取甚麼？結果儲存在哪裏？接收輸出後可採取哪些行動？

即使模型從不連接網絡，這些問題依然重要。本機生成的摘要，一旦由另一個元件儲存或分享，仍可能成為敏感資訊。

硬件帶來另一條界線。支援的平台代表合資格環境，並不保證在所有工作負載下均有相同體驗。正在執行其他高要求應用程式的電腦，可能與安靜的示範機有截然不同的狀況。

恰當的做法是量度，而非假設本機執行必然更快。移除遙距請求會改變時間計算方式，但模型初始化及運算仍然需要進行。

Google 及 Microsoft 自身的文件亦明確說明裝置資格及模型可用性。這加強了一項更廣泛的教訓：瀏覽器 AI 是應用程式必須檢查的能力，而非可假設人人具備的通用條件。

評估應區分首次體驗與其後使用。尚未可用的模型，與已準備就緒的模型會產生不同互動。將兩種體驗混為單一印象，可能掩蓋重要的摩擦點。

質素同樣需要這種嚴謹態度。本文所審閱的材料，並未建立 Opera 在受支援模型及硬件上的獨立、可比較效能量度。因此，關於回應速度或準確度的主張應保持有限。

具說服力的比較會固定任務及評估準則，並檢視完成時間、輸出的實用性，以及使用者需要修正結果的頻率，同時說明所用的電腦。

對買家而言，這些證據比功能是否帶有本機 AI 標籤更重要。有用的問題是：在機構的實際條件下，應用程式是否能滿足已界定的需要？

因此，Opera WebAI 應被視為具有明確界線的早期實作。其架構提供一個有意義的選項，而私隱及效能仍是必須在應用程式層面評估的特性。

Opera 發布後值得關注的事項

下一批證據應來自更廣泛的可用性、可重現的任務結果，以及人們持續使用的應用程式。

首先，留意更清晰的推出文件及更廣泛的實作相容性。Opera 對 GX 與 Neon 可用性的不同描述，應收斂為清晰無誤的支援情況。

這將提升部署規劃的信心。持續含糊不清，會令開發者更難向用戶說明功能缺失究竟反映瀏覽器版本、裝置還是應用程式的問題。

在 Opera 推出的同時，整體瀏覽器格局亦很重要。相似的介面名稱可作為有用起點，但真正的相容性需要在不同實作中測試相同的預期行為。

正面訊號會是開發者記錄哪些功能能穩定運作、哪些需要調整。這可將瀏覽器 AI 的一般支援，轉化為應用程式開發者可用的實際資訊。

其次，留意在受支援電腦上進行的可重現評估。有用的結果應識別任務、所選模型、硬件，以及可接受答案的準則。

對閱讀工具而言，相關證據可包括重點標示的段落是否回應讀者已說明的專案需要。對測驗工具而言，則可檢視問題及答案是否仍以來源材料為依據。

這類結果可加強特定本機工作負載的理據。即使底層介面運作正常，如輸出不一致或等待時間過長，該理據仍會收窄。

這些評估亦應包括失敗時的行為。能清楚說明 AI 不可用並保留用戶工作內容的產品，仍可保持實用；無故停滯的產品，則會帶來不同的採用問題。

第三，留意超越示範、並能贏得重複使用的應用程式。這是把瀏覽器基建與持久用戶效益連繫起來的訊號。

若擴充功能因改善閱讀或整理而獲人們保留使用，便可支持 Opera 的論點。若示範數量不斷增加，但缺乏持續使用，則只會提供較弱的實際需求證據。

這些應用程式的質素亦會揭示本機處理在哪些方面對用戶重要。私隱、回應速度及避免依賴遙距服務，是不同的好處。開發者應確認其產品實際提供的是哪一項。

Opera WebAI 令瀏覽器更明確參與決定 AI 工作在何處進行。其重要性將取決於這項決定如何清晰服務某項任務，而非有多少功能獲加上 AI 標籤。

如要評估預覽版，請先選擇一項能以原始材料判斷結果的任務。比較該功能是否有助你作出更佳決定，而不只是會否產生答案。檢查應用程式讀取甚麼、要求哪些權限，以及模型不可用時會怎樣。尤其當生成文字聽起來比證據所支持的更肯定時，應保持來源可見。對開發者而言，請發布結果背後的條件，讓其他人可以重現。對買家而言，請要求供應商在具代表性的裝置上示範完整工作流程。有用的問題很具體：本機瀏覽器 AI 是否足以改善這項工作，以證明其要求合理？