Hello! 各位 AI 開發者大家好 👋
我是 ihower，不知不覺這是第 30 期啦，感謝你一路以來的訂閱與支持 🙏
如果喜歡輕鬆交流和分享最新消息，歡迎加入 Telegram 討論群！
🧭 A Field Guide to Rapidly Improving AI Products
Hamel Husain 分享了真正成功的 AI 團隊的六個評估迭代策略:
- 錯誤分析才是王道，別沈迷漂亮的 dashboard 通用指標
- 最重要的投資：客製化的數據檢視介面
- 讓領域專家直接寫 Prompt
- 用合成數據起步
- 保持評估系統的可信度，用二元判斷取代模糊分數
- 路線圖要數實驗，不是數功能
先建評估基礎設施，再考慮具體功能。聽起來很慢，實際上是最快的路。
❓ AI Evals 課程的 FAQ
Hamel Husain 和 Shreya Shankar 整理了他們 AI Evals 課程 的 FAQ，收集了教 700+ 工程師和 PM 後最常被問的問題。包括:
- 錯誤分析 (Error Analysis) 是王道
- 自建評估介面比現成工具好
- 二元評估 > 李克特量表(1-5分)
- RAG 沒死，只是要用對方法
- 別用現成的通用指標，這些指標對大部分 AI 應用都沒用
🕵️♀️ 什麼是錯誤分析 Error analysis ?
上兩篇都重點提到錯誤分析，我整理了一篇文章來講什麼是 AI 應用評估的錯誤分析。文長請直接看我 blog 文章。
針對沒有標準答案的問答評估(對比有標準答案的是指單選、多選等有固定答案)，這裏不同於常見的 G-Eval 評估方式採用正面表列，根據你的 Criteria 做評估量測打分(例如1~5分有多符合)。
這裏教的方法是先做錯誤分析，拿到具體的負面表列後，後續再針對 “每一種” 失敗模式都來做評估量測和改進。
🧠 How Long Contexts Fail and How to Fix
雖然模型支援越來越長的 Long Context，但更長的上下文不等於更好的回應，作者總結了四種失敗模式:
- 上下文中毒: 幻覺錯誤進入上下文後被反覆引用。例如 Gemini 玩寶可夢時產生錯誤遊戲狀態，導致 AI 執著於不可能的目標
- 上下文分心: 上下文太長時，模型過度依賴歷史記錄而忽略訓練知識。研究發現超過 100k tokens 後，Agent 開始重複過去行為而非產生新策略
- 上下文混亂: 無關資訊影響模型產生低品質回應。Berkeley 功能呼叫評測顯示，所有模型在提供多個工具時表現都會下降
- 上下文衝突: 新資訊與既有資訊產生矛盾。微軟研究顯示，將提示分段輸入比一次性輸入平均下降 39% 效能
作者也分享了How to Fix 解決方案，包括 RAG 選擇性加載、工具動態選擇、上下文隔離、修剪無關資訊等技巧。
⚙️ Manus 的 AI Agent 上下文工程經驗
最近搬去新加坡的 Manus 團隊分享了他們的 Agent 開發實戰經驗，有不少獨到的觀點，非常值得一讀，包括:
- KV-Cache (Prompt快取) 命中率是 Production 環境的 AI Agent 最重要的指標，要盡可能確保 context 的 prefix 部分不變，這會直接影響成本差了10倍
- 工具選擇太多會讓 Agent 變笨，可以設計狀態機來動態決定當下可用哪些工具。但是要避免動態改變工具列表 schema，因為這會破壞 Prompt 快取，而是用遮罩 logits 讓模型不要選特定的工具
- 使用檔案系統當成無限的外部記憶體，減少 context 佔用，避免截斷或壓縮。例如使用網頁抓取工具時，不要將結果全文塞回 context，而是寫入檔案，然後讓 Agent 自己用工具再去讀檔案，context 中只需預設保留 URL 即可。
編按: 這段寫不是很清楚它是怎麼做的，以下是我腦補可能的讀取方式: 例如配置 grep 工具，讓 Agent 查找讀取部分段落，或是更進階用 sub-agent 工具去讀檔案，然後 sub-agent 只擷取回傳相關的段落給 lead agent 放到 context 之中，如此可以大幅降低主 context 的佔用
- 用 todo.md 來操控注意力，不斷重寫待辦清單放到 context 最後
- context 中保留錯誤的路徑，避免重複犯錯
- few-shot 要有多樣性，避免過度一致的範例
如此重視快取命中率，是我之前沒想過的，但想想也非常有道理，Agent 的 tokens 成本控制太重要了，因為整個對話串會很長啊!
更多討論在我 Facebook 貼文。
🏅 Galileo Agent Leaderboard v2
Galileo Labs 發佈了 Agent Leaderboard v2 評測，不只測試 Agent 能不能呼叫對的工具，而是模擬真實企業場景，評估 AI 在多輪對話中處理複雜決策和完成實際任務的能力。
評測涵蓋五大關鍵產業：銀行、醫療、投資、電信和保險。每個測試場景都精心設計，包含 5-8 個相互關聯的用戶目標，真實反映企業環境中的任務複雜度。
他們測量兩個核心指標:
- Action Completion (AC): 行動完成度，Agent 是否真正完成了用戶的每個目標？
- Tool Selection Quality (TSQ): 工具選擇品質，Agent 是否選擇了正確的工具並正確使用？
最新結果顯示，GPT-4.1 以平均 62% 的 Action Completion 分數位居榜首，每次對話成本為 0.068 美元。
令人意外的是，推理模型在此評測中表現不佳。推測原因在於企業場景更重視執行效率而非深度分析，推理模型可能因過度思考反而降低了任務完成效率。
這提醒我們選擇 AI 模型應優先考量實際應用需求，雖然推理模型在學術測試中表現卓越，但面對日常商業任務時，簡單直接的執行力可能更具實效。
📊 LLM Benchmark 快速解釋
Xeophon 介紹了各種 AI 評測基準，很多人看到模型排行榜上的分數，但其實不太清楚這些數字代表什麼意義。
拿 GPQA 來說，這是目前最熱門的評測之一，設計得很精良，但重點是它只測「生物、物理、化學」三個領域。如果你以為 GPQA 高分就代表模型什麼都懂，那就誤會大了。
類似的還有 LiveCodeBench，會定期更新題目保持新鮮度，但現在的 LLM 對簡單的程式題目已經太輕鬆了，基本上 easy/medium 的 LeetCode 題目已經難不倒它們。
看 AI benchmark 要小心，不是分數高就代表全能。每個評測都有它的設計目的和侷限性，了解背後的細節才能正確解讀模型的真實能力。
🔥 Temperature 一定要設 0 嗎？
使用 LLM 時的一個關鍵迷思是 Temperature 到底該不該設為 0 ?
很多人會說「穩定最重要，直接把 temperature 設成 0 吧！」，理由不外乎是: 降低幻覺、保證可重現、效果最好。但作者認為這可能是 LLM 使用上最大的誤解之一。
作者 Oscar 從 LLM decoding 機制講起，破解了三大迷思:
- 迷思1: Temperature=0 能有效降低幻覺。實際上 temperature>1 時確實會增加幻覺，但在 temperature<1 的範圍內，並不保證越小越好。關鍵在於: Greedy decoding 容易陷入重複循環，會偏向輸出訓練資料中最常見的答案，但網路上最正確的資訊往往不是最常出現的，在 RAG 場景中，可能會讓模型過度依賴內部知識而忽略 context
- 迷思2: Temperature=0 才能每次得到相同結果。這個邏輯有根本性錯誤。現代電腦的「隨機」其實是偽隨機數，只要控制 random seed 就能重現。所以 OpenAI 提供的是 seed 參數，而不是要求你設 temperature=0。
- 迷思3: Temperature=0 效果最好。大量研究顯示 greedy decoding 容易出現 嚴重的自我重複問題、局部最優但非全域最優、與人類語言組織方式差異過大。人類在組織語言時，經常會使用從 LLM 角度看來是「低機率」的詞彙，因為我們會深思熟慮選擇更精確的表達。
最後建議把 temperature 當作 hyperparameter 來調整，基於具體任務做實驗，大多數模型官方推薦的設定是 temperature=0.6, top_p=0.9。可以嘗試新興的 Min-p sampling 方法。
建議有評估的流程，透過實驗找出最佳設定，而不是無腦設定 temperature=0。
🛠️ 如何正確設計 tools 來提升 Agent performance
和上篇同樣來自 Oscar 的文章，這篇講述了設計 edit tool 的來龍去脈故事，非常精彩。
- 第一代 Whole editing: 讓 LLM 直接重新生成整份 code
- 第二代 diff & patch: 使用 Linux 原生的 diff 和 patch 指令
- 第三代 improved tools: 各大廠針對 diff 的問題做了各種改進
光有更強的 LLM 是不夠的，要搭配好的 tool 設計才能發揮最大效果。這些改進在 SWE-Bench Verified 上能帶來 6-8% 的提升。
🎓 2025 年如何自學 LLM
連續推薦 Oscar 的文章，他分享了他建議的 LLM 自學清單。Oscar 認為如果真的把這些內容學透，絕對比市面上過半年薪100~200萬的 junior LLM engineer 還要懂 LLM，面試絕對沒問題。
現在科技業出現一個奇特現象，2021-2022年入職的老員工現在連面試都過不了，而2023年入職的同事普遍也比不上現在比較強的新人，所以必須持續學習才不會被技術浪潮淘汰。
希望你喜歡這集內容！如果你想更有系統地掌握 Context Engineering 技術，歡迎報名我的大語言模型 LLM 應用開發工作坊 課程。也歡迎把這門課推薦給對 LLM 應用開發有興趣的朋友！
– ihower