模型替換實作坊：GPT-5.5、Kimi、DeepSeek 與 Mistral 大對決

Pamela Fox 是 Microsoft Foundry 的開發者推廣（developer advocate），她主張 AI 工程師必須用自家場景實測頂尖模型，不能只信 benchmark（基準測試），因為模型在 groundedness（有據性）、工具呼叫效率與多模態閱讀上的行為差異極大。這場議程是實作工作坊：她讓 GPT-5.5、Kimi K2.6、DeepSeek V4 Flash 與 Mistral Large 3 依序跑過計數、RAG、影像輸入、函式呼叫、代理迴圈與評估，再示範兩種縮小落差的方法——LLM-as-judge／ASSERT 評估，以及 DSPy 提示最佳化。標題的「模型對模型」框架說得通但不完整：大約後三分之一談的是評估與提示生成工具，而非這四個模型本身。

Fox 的立場很務實。她說自己最常做 RAG，觀察到模型的主要差異在於「是否願意承認自己不知道」。工作坊標明的動機是模型獨立性：新模型層出不窮，取用許可權也可能隨時被切斷，因此應用程式必須能跨供應商移植。讀者應該帶走三件事：每個模型具體在哪裡出錯的清楚地圖、哪些修法是提示層次而哪些是能力層次，以及為什麼在生產環境換模型時，瓶頸是評估——而不是調提示。

計數測試暴露真實落差，提示工程能補上其中一部分

開場測試只發一次 OpenAI Responses API 呼叫，問「the elderly gentleman eagerly enter the elevator」這句話裡字母「e」出現幾次。GPT-5.5 與 Kimi K2.6 都答 13，正確。DeepSeek V4 Flash 答 6，Mistral Large 3 答 8。Fox 提到 GPT-5.5 的心算能力很強，並引用同事用它跑財務 benchmark 的經驗。

把提示改成「拆成單詞、逐詞計數、加總、顯示推理過程」之後，Mistral 在同一題就答對了。Fox 的重點是：有些模型缺陷可以靠提示解決，有些不行，而整場工作坊就是圍繞著如何分辨兩者來安排。

有據性比原始能力更能區分模型

在一項使用木蜂（carpenter bee）資料集的 RAG 測試中，問題要求比較蜜蜂與木蜂的築巢方式差異，但來源資料只涵蓋木蜂。正確答案應該給出木蜂的細節，並說明蜜蜂的資訊不可得。

| 模型 | 木蜂 RAG 測試的表現 |
|---|---|
| GPT-5.5 | 指出資料集未涵蓋蜜蜂築巢——符合期望行為 |
| Kimi K2.6 | 表現同樣良好；Fox 因時間關係跳過 |
| DeepSeek V4 Flash | 表示提供的來源不含該資訊——通過 |
| Mistral Large 3 | 從自身權重回答蜜蜂細節，超出來源範圍 |

Fox 接著試著強制 Mistral 為每項陳述標註來源，沒有來源時就寫「未提供來源」。結果只成功一半：Mistral 正確標出蜜蜂細節沒有來源，卻還是照樣給了。她的結論是：較小的模型更容易把權重知識當成上下文內容呈現；而為 RAG 挑模型時，有據性是第一個該評估的專案。

影像理解是能力落差，不是提示問題

影像測試用三個本機檔案：一張原牛（aurochs）照片（Fox 特別說明牠不是獨角獸）、一張她在哥斯大黎加拍到的鱷魚照片，以及一張小字型植物價目表的截圖。DeepSeek V4 Flash 因只接受文字而被排除。

| 模型 | 原牛／獨角獸 | 鱷魚 vs 短吻鱷 | 最便宜的植物 |
|---|---|---|---|
| GPT-5.5 | 正確判斷不是獨角獸 | 依吻部正確判斷為鱷魚 | 正確從小字價目表中找到最便宜的植物 |
| Kimi K2.6 | 正確辨識出原牛 | 正確判斷為鱷魚 | 正確找到最便宜的植物 |
| Mistral Large 3 | 判斷不是獨角獸，但沒認出是原牛 | 答成短吻鱷 | 選了 2.30 美元的植物，而非最便宜的 1.58 美元 |

Fox 的論點是：影像任務很難靠提示工程補救——模型要嘛讀得懂圖，要嘛讀不懂。她還補了一個語言上的提醒：同一道鱷魚題改用西班牙文問（「caimanes or cocodrilos」）會得到錯誤答案，因為模型把英文和西班牙文的詞混在一起。她指出，這對在加州打造、服務西語使用者的應用程式來說很關鍵。

工具呼叫揭示引數紀律與迴圈效率

Fox 用 JSON schema 定義了一個 create_calendar_event 函式，包含 title 字串與 description，連同使用者請求一起送出（平臺團隊同步會議，出席者有 Eng 的 Sarah、Marcus、新 PM Priya，明天下午 1:30，以 Microsoft Teams 線上進行），再檢視回傳的引數。GPT-5.5 把 Fox 本人也加進出席者，其餘大致正確。DeepSeek 把使用者加進出席者，並把 location 設成「virtual (Microsoft Teams)」，而非使用者指定的值。教訓是：引數錯誤代表 schema 描述有歧義，工程師接著要把描述收緊（例如「不要包含我或你，只列具名出席者」）。

迴圈測試用一個 calculate 工具，以及一道買三件襯衫含稅的應用題，系統提示為「不要在腦中算數學」。GPT-5.5 把整個計算併成一個運算式、一次工具呼叫。DeepSeek 用了四次工具呼叫才得到正確答案。Fox 把這當成效率指標：每次呼叫都是一次網路請求，所以即使兩個模型都答對，得到答案的時間也不同。她提到 Kimi 有一次答對之後，又花了四次呼叫驗算。

代理框架大同小異，平行工具呼叫則不然

Fox 用三個框架提供同一個旅遊規劃代理——LangChain v1、Pydantic AI 與 Agent Framework——並實際跑 LangChain 版本。工具包括搜尋航班、搜尋飯店、檢查預算與搜尋活動。使用者要求下個月從舊金山到紐約、三晚、總預算 600 美元、直飛，並安排一項活動。

GPT-5.5 第一輪就平行化，同時搜尋飯店與航班，接著拿兩邊結果對照預算，再用剩餘預算搜尋活動——效率最高的路徑。Kimi 沒有平行化，把航班與飯店搜尋拆成兩輪，還做了兩次預算檢查，多花兩次呼叫。DeepSeek 做了四次呼叫，完全沒有平行化。Mistral 搜完航班與飯店就停了，跳過預算檢查與活動搜尋。

Fox 的診斷是：代理會隨著上下文填滿而退化，忘記先前的指示，因此可能需要在執行途中介入引導。她引用 Ralph Loop（歸功於 Jeff Huntley，他本人也在會場），說明這是強迫代理比預設迴圈更積極的手段。她也提醒，比較模型等於同時比較 harness（測試框架），因為每個框架的工具呼叫迴圈都略有不同。

評估才是真正的瓶頸，ASSERT 幫你起步

Fox 從人工觀察轉向自動化評估。第一層是針對工具呼叫引數做字串比對，測試案例很多，包括日期運算、模糊的時長、一個西語案例，以及俚語（「Yo, can you book the big comp room?」）。她警告評估不該放在一般的 PyTest 套件裡，因為又慢又貴；而且生產環境的使用者輸入必須回饋到評估集，以防漂移。

第二層是 LLM-as-judge，直接手寫在 repo 裡：由評審模型（GPT-5.5）根據查詢、回應與上下文回傳通過／不通過以及理由。Fox 強調，好的評審需要完整 trace——工具定義與每一次呼叫——不能只看輸入與輸出。在有據性評審上，多數模型拿到三分之二，Mistral 只拿到三分之一。她請讀者去看 Hamel Husain 關於評估的文章與課程，並提醒：評估失敗可能代表評審錯了，而不是應用程式錯了。

第三層是 ASSERT，這是 Microsoft Research 的工具，她說截至演講時大約才推出一週。它接收一份 YAML spec，描述代理及其各個維度（例如預算壓力，分為充裕、緊縮與可見三種），據此生成行為類別與合成測試集，再為每次執行評分。在 DeepSeek、Kimi 與 GPT-5.5 的旅遊規劃代理測試中，違規次數越低越好，GPT-5.5 得分最佳——Fox 說這個結果讓她意外，因為 Kimi 在其他專案表現亮眼。她對預設評估器的評語很直白：「千萬別用那些。LLM 最擅長的就是講得頭頭是道。」

DSPy 用寫規格取代寫提示，順便換來模型獨立性

最後一項技術針對的是「每個模型都要重新調提示」的成本。DSPy 讓工程師宣告程式的限制與檢查條件，再用 GEPA（一種遺傳式 Pareto 演算法）搜尋能滿足這些條件的提示。Fox 的範例要求產生一份編號清單，每行字數必須精確，且首字母要拼出指定單字。最佳化器在 Mistral（工作坊中最弱的模型）上跑了約六分鐘，產出的系統提示存進 repo。

她指出的策略效益是：能用更便宜或地端自架的模型跑出同等結果；她也引用 Dropbox 與 Shopify 的演講，說明他們如何用 DSPy 加 GEPA 擺脫較大的模型。代價是架構上的：提示變成流程的產出物，而不再是工程師親手寫的程式碼。

工作坊留下的未解問題

有兩條線索尚未收束。第一，模型排名因場景而異，有時甚至互相矛盾：Kimi 在計數與影像上與 GPT-5.5 並駕齊驅，卻在代理平行化與 ASSERT 違規次數上落後，因此整場下來沒有任何單一排序站得住腳。第二，操作建議本身刻意不完整——Fox 說她會後必須輪替共用 .env 檔裡的 API key，這限制了與會者能重現這些執行的時間。她還提到有些 Anthropic 部署必須改用 Messages API 而非 OpenAI SDK，並特別點出 Anthropic 內建的引用功能是她做 RAG 時很喜歡的程式化有據性機制。Ollama 支援是在演講前一天才加上，所以同一批範例只要改端點與模型名稱，就能跑在地端模型上。值得持續追蹤的主線是：評估工具——ASSERT、LLM-as-judge 框架、DSPy——成熟的速度比任何單一模型的領先優勢都快，而這正是模型可移植性從「加分項」變成「設計必要條件」的處境。