你的 Agent 都在腦補什麼？用開源工具設計偏見測試

開發 Agent 時，我們會檢查工具有沒有呼叫成功、流程有沒有跑完，以及答案是否正確。但還有一種問題不容易被這些檢查抓到：Agent 的回答看起來很合理，卻偷偷加入了使用者沒說、開發者也沒設定的假設。 例如，使用者只問「正餐可以吃什麼？」，Agent 卻一直往晚餐的情境回答。這表示它可能偏向某種理解，但這樣就算有偏見嗎？還得看這個應用希望如何處理不明確的問題：應該先追問、列出幾種可能，還是可以採用某個預設？ 本演講會先從常見的偏見案例出發，再把問題帶回 Agent 開發：除了性別、年齡等刻板印象，我們也關心 Agent 是否反覆做出某些假設，讓回答或行動偏離應用原本想提供的協助。 內容包含四個部分： （一）先說清楚：什麼樣的回答才符合預期？ 把「我們希望 Agent 怎麼做事」整理成可以檢查的要求。例如，資訊不足時是否應該追問？推薦時應該考量哪些條件？哪些事情不應該自行假設？這些要求會成為後續判讀測試結果的依據。 （二）從自己的文件產生測試題 說明如何從應用文件、FAQ 或知識文本整理出問題，再透過拿掉關鍵資訊、換成較概括的說法，或增加不同條件，建立一組組可以互相比較的測試題，觀察 Agent 的回答如何變化。 （三）比較回答，找出 Agent 補了哪些假設 介紹 Python 測試流程的設計，包括測試案例整理、批次呼叫、回應紀錄與結果比較。重點是先觀察回答傾向，再判斷它是否違反預期；回答不同不一定代表有偏見，資訊完整的問法也不保證一定得到正確答案。 （四）題目越生越多，怎麼測才划算？ 討論如何記錄每道題對應到原文的哪些內容，了解哪些地方測過、哪些還沒碰到；並探討當條件組合大量增加時，如何選取測試題、減少重複測試，以及這些取捨可能漏掉什麼。 本次分享以方法設計、案例與 測試流程為主，分享開發中的做法與尚待解決的問題。適合具備 Python 基礎，對 LLM、RAG 或 Agent 開發有興趣的工程師，不需要先具備技術背景。可以帶大家走一套工具使用與設計思路，開始替自己的 Agent 規劃測試，檢查它在資訊不完整時，究竟做了哪些我們沒注意到的假設，進而可能的修正或改善。