Nadella 談企業 AI 評估：模型可以租，判斷好壞的標準為何要自己留？
企業 AI 評估為何會成為智慧資產？從 Nadella 的 20VC 訪談與 Unilever 訂單案例，理解私有評估、工作回饋及更換模型時應保留的知識。
企業 AI 評估正在成為一項經營問題：公司花錢買到模型能力之後，有沒有把自己判斷好壞的方法累積下來？如果沒有，每換一個工具，團隊就可能重新摸索一次。
Satya Nadella 在 2026 年 10 月 26 日上架的 20VC 訪談中說，每家公司未來都可能擁有私有的評估基準，而且它會成為核心智慧資產。
他的重點涵蓋原始資料以外的知識。員工如何修正答案、哪些結果被接受，以及例外如何處理，都可能反映公司多年累積的工作方法。
這些經驗可以存在於背景資料與測試案例裡，未必需要先訓練一個專屬模型。因此，一般企業也能從自己的工作標準開始整理。
同時，擁有評估資料並不自動保證產品品質。資料放在哪裡、誰能使用，以及測試是否貼近實際工作，仍要分別確認。
對準備導入 AI 的團隊，可先把一項熟悉工作變成可重複檢查的案例，讓模型選擇依據逐步回到公司自己的需求。
企業 AI 評估為何會成為公司的智慧資產？
公司對什麼結果算好，往往包含一般模型測驗無法呈現的工作知識。因此，公開排行榜可以協助認識模型，卻不足以替公司決定哪個結果可以交付。
Nadella 在訪談九分鐘後的回答中，把企業知識延伸到使用模型留下的回饋。例如，按讚與負評這類訊號，也可能說明哪一種回答符合公司的工作期待。
他主張，公司應能累積這些使用智慧所產生的價值。保存方式可以是背景資料，也可以是評估基準，並不一定要把所有知識都寫進模型本身。
所謂評估，是用一組工作案例，依相同標準檢查模型或代理的結果。私有評估則把公司的特定需求放進去，例如某種訂單格式、服務規則，或只有內部人員理解的例外。
知道正確答案，本身就有價值
假設兩個模型都能寫出流暢的客戶回信，但其中一封承諾了公司無法提供的交貨日期。對這家公司而言，文字漂亮與能寄給客戶之間，還差了一個重要判斷。
熟悉業務的人知道這個差別，模型的通用測驗卻未必會測。若團隊把日期限制、判斷依據與合格回覆保存成案例，下一次換模型，就能再次檢查同一個問題。
這也是 Nadella 將私有評估視為智慧資產的理由。它把工作經驗變成可重複使用的判斷依據，讓公司比較工具時，不必完全依賴供應商選好的展示題目。
不過，「未來每家公司都有」是他的預期。他沒有在訪談中證明所有企業已建立這套能力，也沒有給出一份通用題庫，讓任何公司直接套用就能完成轉型。
這些標準要能留下來，先得把員工心中的判斷轉成可檢查的案例。
一份私有評估，需要留下哪些工作經驗？
評估案例要同時保留問題、背景與可接受結果，才能讓不同人重複判斷。只有一個「不喜歡」，通常還不足以解釋模型應該改什麼。
延續交貨日期的假設，團隊可以保存客戶詢問、當時可供貨的資訊，以及回覆應遵守的限制。如果結果錯在日期，就把原因記成資料引用或承諾範圍的問題，才容易追蹤之後是否改善。
這比把所有錯誤都歸類成「模型不好」更有用。因為錯誤也可能來自背景資料過期、工具沒有查到庫存，或團隊對可承諾的條件沒有共識，更換模型未必會解決。
Microsoft Foundry 的評估文件把既有測試資料、生成的回答，以及代理在正式服務中執行過的步驟紀錄，都列為可評估的對象。團隊可以先選與工作最相關的單位，再決定如何評分。
這代表私有評估不必從大型排行榜開始。一段已處理過的工作，只要有可信的原始背景與清楚的接受條件，就能成為日後比較工具的起點。
為什麼要保留失敗與邊界案例？
順利完成的例子能確認基本功能，容易出錯的例子則能指出限制。若題庫只留下規則最整齊的訂單，團隊就可能高估工具處理模糊日期或缺漏資訊的能力。
Visual Studio Code 的官方評估指南建議納入一般請求、邊界情況與已知失敗，版本比較時使用相同基準，另外保留案例檢查改善能否適用到未見過的資料。
固定比較基準，是為了知道變更帶來什麼影響。若每次換模型，也同時把難題拿掉，成績提高就無法單獨說明工具進步了多少。
用合成資料補充少見情境時，也需要檢查案例是否真的符合業務。
延伸閱讀：Microsoft 企業合成資料怎麼測 Copilot？三種產業情境與評估邊界
案例具體之後，還要確認測試的結果能否反映整段工作。
從訂單到收款，為何不能只評一句回答？
企業代理會連續處理多步工作，單句答案正確仍可能沒有完成任務。因此，評估需要接上工作最後產生的結果。
Nadella 在談到 Unilever 的段落說明，導入工作先從業務問題、評估方式與代理架構開始，之後才由企業自己的 IT 團隊接手管理。
Microsoft 同日公布的 Unilever 案例讓流程更具體：NOVA 使用五個代理，四個讀取郵件、理解背景與擷取訂單，另一個檢查工作。缺少資訊或碰到例外時，交由人員檢視。
這個安排說明，讀懂文件只是其中一步。訂單資料還要能被檢查，缺漏也要被辨認，才不會把一封看似完整的郵件，直接當成可以輸入系統的訂單。
企業公布的試行成果可以提供研究方向，但不能據此推定任何公司採用相同工具，都能得到相同改善。流程、資料品質與人工處理方式不同，測出的結果也可能不同。
一句「完成」應該對上什麼結果？
以假設的訂單代理為例，它可能回答「已完成」，但後台只建立草稿，沒有送出正式訂單。若評估只看最後文字是否符合要求，就會漏掉這種部分完成的情況。
因此，測試可以把接受條件接到實際狀態：哪些欄位已填妥、哪些工作仍需人工核可，以及例外是否正確交給人。這些條件要由熟悉流程的人定義，才不會由模型自行宣布過關。
評估工具能協助計分，人仍需檢查計分是否測到原來的目的。若一項分數只描述回答流暢度，就不能把它當成訂單處理成功率。
完整流程能否持續改善，又與資料和判斷標準由誰掌握有關。
模型可以更換，什麼資料應由企業持續累積？
公司能保留可用案例與修正依據，才比較容易評估更換模型的影響。這份累積的價值，在於它能讓不同工具接受同一批工作要求。
Nadella 在訪談裡談到的未來，是不同模型競爭，企業可以依任務選擇。他對單一垂直整合供應商掌握一切持保留態度，但也承認產業最後如何發展仍有不確定性。
對企業來說，可操作的部分，是把模型名稱與工作標準分開。今天使用某個模型，不代表合格訂單的條件、服務準則與例外處理知識，都必須跟著它一起更換。
假如原本測試資料只存在供應商後台，沒有可供團隊持續使用的案例與紀錄，換工具時就可能失去比較基礎。因此，導入時就要理解資料能否匯出，以及保留內容是否足以重建測試。
這不等於要求企業把所有資料集中到一份文件。原始資料可以有不同存放位置，但使用案例時，應能辨認當時的版本、引用依據與判定原因，避免新舊規則混在一起。
同樣地，私有題庫需要限制使用範圍。若案例包含客戶資訊或商業條件，保存資料與拿去呼叫外部模型，是不同的操作，團隊仍要依實際產品安排管理。
保留知識的目的，是讓下一次選擇有比較基礎，並非把一份測試永遠固定。
一般團隊如何開始建立自己的評估？
從一項範圍清楚的工作開始，通常比先追求完整評估平台容易形成結果。團隊已經知道怎麼做、也知道常見失誤的任務，尤其適合當起點。
例如先挑一種需要回覆的客戶問題，整理具有代表性的案例，再請業務人員說明什麼答案能交付、哪些情況應轉人工。這是流程示例，實際案例數量與門檻仍要依工作差異安排。
接著讓現有工具跑過這批案例，保留失敗原因。若多數錯誤都出在找不到最新資料，改善方向就會與「模型不夠會寫」不同，也能避免把所有問題都變成升級訂閱方案。
等背景與判定標準穩定後，再比較另一個模型或新的提示方式。比較時把工具版本、資料與評分方法記清楚，才能知道改善來自哪一項變更。
評估也可以放進持續運作的流程，定期檢查新情境。企業工具如何把測試與實際工作連在一起，已有不同產品嘗試。
延伸閱讀：Salesforce Agent Fabric 新增代理評估：AI 回答出錯、費用失控時怎麼處理？
能說明哪些情況通過、哪些仍需人工處理，才算累積了可帶走的判斷能力。
企業 AI 評估常見問題
私有評估等於自己訓練模型嗎？
不等於。評估先定義工作與接受條件，可以拿來檢查不同模型。是否訓練或調整模型，是後續依需求選擇的做法。
評估分數提高，就代表工作品質一定改善嗎？
還要確認分數測量的是哪種結果，以及測試案例是否接近實際工作。單一分數不能涵蓋所有品質，也需要檢查個別失敗情況。
Nadella 是否說所有公司已經有私有評估？
他描述的是對未來的期待。訪談沒有宣稱所有公司都已具備這項能力。
把工作標準留下來，才能讓下一次選擇更有依據
Nadella 的看法把 AI 導入拉回一項企業能力：知道什麼結果可以接受，並把這種判斷持續累積。這能讓工具的進步與公司的工作需求，有更清楚的比較方式。
對正在導入 AI 的團隊，可以先整理一項工作的實際案例與失敗原因。免費訂閱 AI 郵報，持續閱讀企業 AI 如何從展示走向可檢查的工作成果。
