改了一行 prompt、換一個模型、多接一個工具,怎麼知道沒有改壞別的地方?手動測過、看起來很成功,然後在別人手上出事 —— 這 30 天要解的就是這件事。
我會自己建一隻需求釐清 agent:讀進需求方給的雜亂 ticket,輸出結構化 ticket,並標出 AC 裡彼此衝突、不可驗證、與描述不符的那幾條。接著一層層把驗收機制建起來:可重跑的 case、寫得出對錯的 goal state、自己寫的 scorer,再讓模型當裁判,並回頭校準這個裁判。
最後手上會有一份 dataset、一支判定程式和一組上線門檻 —— 改完跑一次就知道這次有沒有改壞什麼。
Day 11|它每次上網查到的東西都不一樣,這樣要怎麼重跑? 輸入固定住還不夠,外面那個世界也要跟著固定。做法是錄放(record/replay):第一次真的連...
用來驗收這隻需求釐清 agent 的資料集(dataset),是一筆一筆「輸入加上通過條件」的 case,公開建議的起點是 20 到 50 筆。但決定這份資料集...
一筆 case 分成輸入和答案兩部分,輸入可以讓 AI 模型產生,把一張已經標好的卡改寫成問題相同的另外幾張;答案要人自己寫,包括這筆通過的條件、goal st...
agent 出過錯的卡是最好的測試資料,但它們要能跟程式碼放在一起重跑、審查、送進模型 API,內容就得整套重建,能留下的只有它讓 agent 出錯的那個結構。...
判定今天交給程式了,那個少掉的標註是程式抓出來的,不是人對照 goal state 找出來的,而且程式回的不只一個紅字,還有少了哪一項、多了哪一項。 被驗收的是...
同一筆 case 跑完可以算出兩個數字,能當上線門檻的只有第二個,第一個留著看差多遠,改完 prompt 看的那份報表上兩個並列。 先接昨天的東西,被驗收的是一...
這隻需求釐清 agent 該找的問題大多找到了,麻煩的是它額外標出來的比找到的多了將近兩倍,多到看卡的人不會再逐條去翻,所以先讓的是多標那一邊。 需求方翻了三次...
判定程式也要被驗收,拿已知正確與錯誤的產出分別測試,確認該通過的會過、該擋下的會被擋下,才有依據相信它給的分數。 前一篇用 precision 跟 recall...
一次通過還不足以判斷 agent 是否穩定,同一筆 case 重跑 k 次後,要一起看單次通過率、至少一次通過,以及全部通過,k 是執行次數。 優惠碼功能的 t...
最終產出正確,仍可能漏掉「覆寫前先取得同意」這種要求;要確認它有沒有被遵守,還需要授權內容與執行順序的紀錄。 優惠碼功能的 ticket 裡,需求方列了 7 條...