> 本場以日文演講。 原文來自使用者提供之日文 SRT,譯文與日文原文逐段 1:1 對齊;穿插於正文中的轉錄幻覺段(prompt 回放)已剔除,部分剔除點的原音內容在來源 SRT 中即已遺失。

評估的不是模型,而是「哪個模型最適配業務」

大家好。感謝各位蒞臨 Code with Claude Tokyo。這雖然是開發者的活動,但謝謝大家特地走進「我們是怎麼挑模型的」這個場次。我不確定大家是抱著什麼期待來的;比起標題那種偏技術性的內容,今天我更想談的是:野村総合研究所 作為一家企業級公司,在把 AI 套用到客戶業務時,是用什麼觀點選擇模型、用什麼方式評估業務的。

我們是一個從各種角度,支援把生成式 AI 應用到生產業務、應用到業務系統的組織。雖然簡介上寫著日文研究等各種面向,我自己其實早在 Anthropic、Claude 設立日本法人之前——從 Claude 模型剛能用的時候——就非常關注這個模型與服務,也在 Anthropic 官網上發表過多個案例研究。今天能有這個機會,深感榮幸。

進入正題。今天從早上開始的場次,應該已經聽了很多模型評估、基準測試的話題。當然,公開基準等衡量模型能力的指標很多,但模型的優劣當然不是由單一指標決定的。實際上,客戶想做的業務、我們自身的開發業務、或客戶自己想做的事,要用 AI 的時候,並不必然是「哪個模型比較強」這種單一評估就能決定的——過去幾年我一直有這樣的感受。

因此,個別業務的評估在交付時當然會做;但「實際用在工作上、用在企業裡時有什麼特性」「到什麼程度可以放心交給模型」,我們建立並持續營運了一套機制:每當新模型發布,幾乎即時就能在公司內部完成評估。重複一下訊息:與其說是評估模型,不如說是評估「對這項業務,哪個模型最適配」——今天想談的就是這樣的框架。野村総合研究所 的文化是:面對客戶要解什麼問題,為其挑選並提供最合適的手段、給予支援——今天就以這樣的視角來分享。

我們在量什麼:業務觀點的基準

在進入業務觀點基準的內容之前,先講幾個觀點。簡單說,就是我們用什麼量法、什麼視角。若講到細部的個別指標,今天再多時間也不夠,所以先談「在量什麼」,以及我們為什麼一路選擇 Claude。在這個場合講這個有點不好意思——我們當然不是在所有任務上都永遠選 Claude。最近的模型在多模態任務上的能力確實提升了,但舉個極端的例子:「想要即時翻譯」這種任務,當然有其他模型更勝一籌的情況,自然會有取捨。但在企業一般用途上,為什麼 Claude 總是名列選型前段——就是這樣的視角。另外,標題裡沒有特別放出來,但現在已經是「不談 agent 就什麼都談不了」、每天都會出現「agent」這個關鍵字的日常了,所以在這個階段我們是怎麼設定、設計評估的,也會依序介紹。

首先,這些終究是以業務觀點歸納的;實際用模型或 agent 跑起來時,還有各式各樣的指標。

例如安全性——Anthropic 的 Claude 非常重視的觀點;還有最近——今天看了各位講者的場次,更覺得「果然現在就是這個局面」——長任務(long task)能做到什麼程度等等。要量的觀點很多,但就「在企業的各種業務上使用」這一點,首先是日文的業務文書:例如條款(約款)、公司內部大量複雜的業務文件、法規監理文件……各種文件,簡直是 context 的結晶塊。能否恰當地解讀這些,是一種能力。

第二點是「帳票」——用英文說大概是 report、form、application 等各種詞——在日文環境做大量業務時,雖然最近可能不太用紙了,但例如處理紙本帳票、處理各種表單的非定型資訊時:與 OCR 服務組合後能否正確解讀內容?或者根本不用那些,模型單體就有多少能力?這是另一個觀點。再來,常有與幻覺(hallucination)混淆的情況:當知識不足、發生邏輯不一致、邏輯錯誤、推理過程有問題時,能不能說「這不對」、能不能說「我不知道」——這樣的能力等等。各種觀點——就業務觀點而言,各領域其實都存在專門的基準,在座各位可能知道;但「實際用真任務跑跑看」這件事,非常重要。

還有一點——複雜指令稍後會講——把這些觀點,用各行各業實際可能出現的各種測試資料來跑。投影片上寫「模型發布的隔天」,但最近幾乎已是當天就能跑的狀態。

今天大家從早上開始,應該聽了好幾次 Fable 的話題——做這種場次就是會遇到這種「經典劇情」:講模型評估的那天早上,新模型偏偏發布了,真不知道該塞進哪裡。資料當然來不及改,我還猶豫要不要講——總之,基準測試已經執行、結果已經確認,現在實際正由公司內部社群試用、各種敲打、進行評估中。

補充一點:就企業用途而言,過去例如 Bedrock、或第一方等等,多數客戶與環境是在啟用 ZDR(零資料保留)的狀態下使用的;但這次的 Fable、以及今後的 Mythos ,會有資料留存等等、依使用環境需要注意的狀況,所以我們當然也把這些納入考量,在適合評估的環境中執行。評估結果在公司內部作為 know-how 共享;野村総合研究所 不只金融,也支援各行各業客戶的生成式 AI 應用,所以有一套把這些回饋到公司內部的機制。

再補充一點:確實有「安全護欄上得相當重」這類使用心得的評論出現;當然,一般性的基準我們也在看。寶可夢終於被攻略,應該也上了新聞——老實說因為花的時間還不短,「如果比 RTA(即時通關競速)的話,人類還是比較強」之類的——我們內部真的在進行各式各樣的討論。

為什麼 Claude 名列選型前段

基於這些 know-how,我們認為 Claude 是最出色的。在日本,從 Claude 3.5、4 一路累積歷史之前,稍早就有這樣的傾向:能仔細讀入、解讀並執行這類文件——這一點,我們評價為 Claude 非常強的地方。

至於這為什麼對企業重要:用 agent 處理各種業務時——今天其他場次也都在講——想自律地交給 AI 的業務有很多,而我們終究想把「人介入的環節」減到最少。一方面是成本觀點:做出費用對效果、把資源留給人真正該做的事;反過來,只要能做出「agent 一條龍搞定」的狀態,商業上的影響力會大幅提升:不必經過人手,不必在意加班或時間限制,能把商業管線大幅壓縮——成本效益之外的好處也會不斷湧現。所以「能遵循這類指令」的能力,價值非常高。

什麼才是重要的?

如果只是一直測「單純任務能解到什麼程度」,大多會飽和(saturate)。模型能做的事不斷擴大,當趨於飽和時,「過去做不到的事變得做得到」——Anthropic 的人常用「jump up」這個說法——context 長度變長、或這張投影片寫的「自我驗證」:對方法錯誤、對 error 的修正、coding 支援、測試階段、以文件為本對原始碼做檢查與稽核——self-correction capabilities。

評估該用什麼單位來設計

也想談談方法論:從這裡進入「評估該用什麼單位切分」的方法論。多 agent——一言以蔽之,所謂 orchestration 之類的關鍵字,這一年冒出了很多。但與其一上來就大規模多 agent 地跑——抱歉,這跟 agent 個別實作的話題是兩回事——而是「用什麼視角判斷 agent 把任務做好了、得到了期待的成果」,該用什麼單位來設計,是這樣的話題。固然有精度——所謂幾題中解了幾題、F 值、LLM-as-a-judge 這類數值化、定量的評估;但「對所給的任務,是否達到業務上期待的基準」——能做出多少這樣的評估,我認為才是關鍵。

如果只用數值評估來組裝,中途會出現「所以這樣到底算不算成功?」的窘境——做過的人應該都有經驗。「大量 agent 跑起來、湧出大量點子、短時間內就能取得精選結果」這類有點炫的 demo agent,跟「真的能把業務整個託付」的系統,是兩回事——這點我至今仍這麼認為。必須以這樣的視角實作 agent 評估。

這時,「把人在做的業務逐步交給 AI」這個趨勢確實存在,所以先從小單位開始。這不是說要個別評估 agent、或用小編排、小規模來評估。而是以業務為單位:「這樣的東西、用這樣的輸入、這樣的 context 去做時,期待什麼結果」——做出能以這個單位評估的「塊」,那個業務單位就能反覆再評估。能再評估之後,當模型進化、agent 精度變好、基底更新時,業務側就能自動受惠——首先,這樣的方法非常有效。

Skill・MCP・工具:「靠 prompt 硬撐」時代的結束

另外,「該把 skill 當成什麼樣的資產來持有」,我們常和各種客戶討論。正好昨天,Boris 和 <mark>Cat</mark> 的對談影片在 YouTube 上線,我邊聽邊覺得「太好了」——他們倆正好聊到:一年前,還真有不少得靠 prompt 硬撐的情況。正是因為一年前模型側自律運作的能力還不夠,只要拚命努力,某些業務還是能跑起來:在 prompt 上下苦功、用各種機制在模型周邊自建一堆實作硬撐——各種案例都有。但現在不是了。與其把一切塞進 prompt,不如用 skill、用 MCP、用工具——把 context 正確傳達給模型的手段已經大量出現——把業務知識、資料、驗證、判準(criteria)、業務知識裝載上去,我認為這是必要的。

原則與收尾

說「原則」有點僭越,連同收尾,我想把「注意這些就好」的要點過一遍。第一點:無法評估的構成——如果無法以業務為單位評估,中途就會難以控制,這是第一點。右邊依序:重複說過的,設計成能以業務為單位評估;對那項業務一定要放基準線(baseline)——人來做的話要花多少時間。

另外,字有點小很抱歉,我放了 rubric 這個關鍵字。現在,在這份文件裡,官方手冊已用「Define Outcomes」這個關鍵字寫明:當 agent 完成某項任務時,「只要這些都過了就算 OK」可以被明確地寫下來。這跟塞進 prompt、跟 skill 又是另一個框架——慢慢變成系統設計的話題了——對模型給出判準。做 Scrum 開發的人,可以想成跟「在 backlog 裡好好寫完成條件(Definition of Done)」很接近的味道:對模型不斷加上可評估的斷言(assertion),並盡量管線化,讓新模型一出來就能評估——我認為這是重點。

再來,雖然跟「複雜指令遵循」排在一起——並非所有業務都如此,但我們接觸的客戶,真的是法律監理、公司內規、個別法規一應俱全,大量情境是由相當資深的專家在把關的。不切入這些部分,轉型就難以推進——我們正逐步逼近這樣的局面。所以,請務必把具備這類能力的模型、服務、解決方案用起來。

skill 的話題與前一張投影片略有重疊,稍微跳過。真正的第一個重點是「有沒有被語言化」:語言化既包括資料的處理方式,也包括能讓模型把資料恰當拉進 context 的資料基盤——請帶著這樣的意識去使用。

還有,關於基準的設計,上面講了很多,但絕對不是說一定要二元分類、一定要用 OK/NG 來定。剛才也稍微提過:適度併用綜合性的分數評估——「70 分還不能用在業務上,但如果能拿到 80 分左右,業務側這樣調整,AI 的應用就能繼續推進」——能做出這種取捨關係的業務其實很多。連同定性評估一起設計,業務套用會更容易。到現在也仍有使用者說「不到 100% 就不用」的情況,所以請在這之間取得平衡推進。

持續這樣做會怎樣呢?正好一年前——這放在 Anthropic 的案例研究網站上——某項業務效率提升了 50%。說白了,就是「原本由人做雙重檢查的業務,幾乎都被 AI 取代了」——指的是這件事,而且始終是以業務為軸。以業務軸來量,當精度相當高之後,「是不是能做更廣的業務了?」——讓它寫文件、校對、做複雜的檢查……「模型能做的範圍正在擴大」這件事本身會變得可觀測。參考一般性基準、參考同業等各種案例,「人家都做到這裡了,我們應該也行」——像這樣一點一點往外探,我覺得很好。

要量測「能把多少交給模型」,只能反覆做「把業務語言化、做成可評估的形式」這件事。看今天其他登台者的分享,如果所有資料與 context 都集中在一處——例如 Claude for Enterprise——或許會出現更不一樣的世界;但需要以小步驟、階段性地推進套用。另外,需要意識到實務的顆粒度,以「會變成什麼狀況」來設計,我會很開心。話雖如此,今天其實只講了模型的事;但「治理有效、事後可稽核,而且連成本效益一起,到底該在哪裡、怎麼跑」的問題會大量出現。這些部分,包括我們這樣的業者在內,支援、實作陪跑等等,都已經是能做到的狀態了。老實說,這對整個日本社群都適用:共享知見、把「到這裡已經可以了」不斷堆上去,是捷徑、也是最短路線。期待今後能與大家有各種協作。我今天的分享就到這裡。謝謝大家。