24次全對之後：怎樣設計更有區分度的上下文實驗？

上一輪 Agnes 3.0 對照完成了24次真實請求：18個含答案條件回傳正確編號，6個無答案條件正確回傳 UNKNOWN。這證明那批材料上的表現符合預期，卻無法區分“位置確實沒影響”和“材料太容易，差異沒有顯現”。

下一步不應只是把請求數擴大。這篇把“更難”變成可檢查的材料設計：讓干擾更像目標，保持其他條件可比，先確認實驗程式沒有替模型洩漏答案。

本篇交付實驗設計與可執行的離線工程；新協議計畫128次，真實模型請求為0。 沒有新的正確率、帳單或延遲結果，也不與舊24次樣本合併。

固定版本工程 · 完整凍結請求 · Java 8本機驗證

1. 全對結果留下了什麼疑問？

舊材料中，目標句式與編號前綴和背景存在差異。模型可能通過明顯線索找到目標，而不需要解決多個近似項目之間的精確檢索。這只是一個待排除的混雜因素，不是已經證明模型用了某種捷徑。

如果直接把背景從60行拉到2400行，就同時改變了長度、費用、失敗機率和資訊密度。即使開始答錯，也很難判斷原因。新版先保留精確項目名查編號這一任務，單獨增加低相似與高相似的成對條件。

2. 高相似干擾具體長什麼樣？

下面摘出凍結材料S1中的項目與編號；全部是合成實驗資料，不是真實業務記錄；項目名稱保留原始簡體輸入，以便核對凍結請求：

記錄	項目名	編號
目標	松塔北站试验项目	OM-3642
一字差	松塔南站试验项目	NA-0653
詞序差	北站松塔试验项目	EL-4135

問題仍是“松塔北站试验项目的交接編號是什麼”，要求輸出編號；資料缺失時輸出 UNKNOWN。這些表格行只是完整請求的摘錄，不能作為完整實驗重現輸入。

新版所有記錄使用統一句式、八字元項目名、相同格式的隨機編號池。高相似背景固定包含六條近似記錄：一字差、詞序差、不同限定詞各兩條。低相似版本在相同位置放無關項目名，編號不變。

這使同一對 low/high 只改變六個項目名，長度、編號、目標答案和其他背景保持一致。六條近似記錄分散在背景索引 floor((2*k+1)*N/12)，其中 k=0..5。它們不會全部堆在開頭；60條與240條背景中都只有六條，因此“近似干擾數量”不隨長度一起增加。

3. 128項計畫怎樣組成？

維度	水平
題目實例	8個項目/編號實例
背景長度	60、240條
相似度	low、high
目標條件	beginning、middle、end、absent
計畫請求	8 × 2 × 2 × 4 = 128
模型	agnes-3.0-flash
參數	temperature=0，max_tokens=1024

含答案的三種條件只移動目標記錄，背景不變。無答案條件在中間放一條等長無關記錄，避免刪除目標後文本突然變短。問題總在記錄之後，系統訊息也不能攜帶答案。

八題來自同一個模板家族，是詞名和編號實例，不是八種獨立任務。128次請求更不是128個獨立統計樣本。這一設計也沒有隔離模型內部注意力機制：隨著目標位置移動，它與近似干擾的距離仍然會變。

4. 執行順序也屬於實驗設計

沿用上一輪的四條件小塊：同題、同長度、同相似度的四個請求構成一個block；low/high兩個完整block構成一個pair。整套材料有32塊、16對。

為避免四個條件永遠按同一順序執行，使用四行順序：

B-M-A-E
M-E-B-A
E-A-M-B
A-B-E-M

B/M/E/A 對應開頭、中間、結尾和缺失。每個長度與相似度層內，四種順序各出現兩次。題序由固定的Java隨機種子洗牌，low/high先後順序按洗牌後的題索引交替。

獨立Node稽核會重建Java洗牌和請求順序，而不是只相信執行器寫出的“已經隨機化”。這個安排能平衡順序位置，但不保證消除所有服務負載或時間相關因素。

5. 答錯、無效回應與缺失分別怎么處理？

收到正常、完整的助手文本後，使用Java trim()再精確比較。它只去掉U+0000到U+0020的首尾字元，與JavaScript trim()並不完全相同；獨立評分不能偷偷使用另一種空白規則。

• 回傳正確編號或應有的 UNKNOWN：符合預期。
• 回傳其他編號、錯誤拒答、額外解釋或格式錯誤：有效回應中的錯誤，保留在分母。
• HTTP失敗、非 stop 完結、角色/型號異常、無法解析或空正文：請求/協議失敗，單列。
• 尚未請求的項：未執行，不補成錯誤答案。

“答成了干擾編號”的歸因只匹配這份請求實際出現過的編號。出現一個格式正確的隨機編號，不能自動稱為受到某條干擾影響。

四份回應在協議上都有效才有完整block；兩個相似度block都完整才有完整pair。主要分析進一步要求同一題在所有長度上配對完整，先在題內平均長度，再對題等權平均。部分結果保留為探索性描述，列出排除原因，不能把缺失填成零。

6. 在看結果前，先固定要算什麼

對每個題目、長度與相似度，令B、M、E為開頭、中間、結尾的精確正確指示值（0或1）：

中間位置損失 = (B + E) / 2 - M
相似干擾差值 = 中間位置損失_high - 中間位置損失_low
主指標 = 先平均同題的長度，再平均各題

它問的是：高相似干擾是否額外放大了中間位置相對兩端的損失？ 它不是總體錯誤率。缺失條件用於檢查無證據拒答，不塞進位置差值。

例如B=1、M=0、E=1時，位置損失為1；這只是公式演示，不是實測結果。若low/high都全對，差值為0，仍可能存在天花板效應，不能據此證明位置無關。

協議使用按題聚類的bootstrap與95%區間，預設10個百分點的復驗門檻；只有差值達到門檻且區間下界大於0，才描述為本批材料提供支持。八題區間會粗，模板共享也限制外推；預設門檻不等於已經做過統計功效保證。

7. 現在能重現什麼？

在 experiments/04-context-position-similar 目錄，先跑以下離線命令：

mvn -q compile
mvn -q exec:java "-Dexec.args=--self-test"
mvn -q exec:java "-Dexec.args=--dry-run"
node --test audit.test.mjs
mvn -q exec:java "-Dexec.args=--verify-prepared evidence/20260930-offline-prepared"
node audit.mjs evidence/20260930-offline-prepared --prepared

本機使用Oracle JDK 1.8.0_171、Maven 3.6.3、Node 26.8.2，編譯通過，2515項Java自檢、60項獨立Node測試通過；128項材料和原始碼指紋與原快照一致。相比交付時僅驗證Java 8目標字節碼，這次補上了真實Java 8執行環境。

測試覆蓋答案洩漏、等長配對、順序重建、預算矩陣、回應異常、缺失處理與評分篡改。它們證明程式按所定義的規則工作，不能證明模型會如何回答。--simulate 使用假Transport並明確標記模擬，不能拿模擬全對結果發布模型結論。

8. 開始線上實驗前還缺什麼？

已有24次真實請求授權已用於L1v2。新計畫的128是程式碼上限，不是費用授權；上線執行前仍需確認當前賬戶費率與本輪總金額上限。本次沒有讀取金鑰、沒有呼叫Agnes。

工程要求明確請求預算、已凍結準備目錄和伺服器程序環境中的金鑰；不在部落格提供公共呼叫入口。每次請求完成後至少等20秒，429/401/403立即停止，其他請求或協議失敗連續兩次停止，不重試。讀取逾時不等於伺服器端沒有執行；缺失usage保持未知，不能報零費用。

下一步是審定預算後執行凍結計畫，保留全部失敗與未執行項，再補逐題結果和不確定性。如果需要32次探索檔，應另建協議版本並重新凍結材料；不能執行到一半挑選看起來“更有意思”的題目。

這一輪推進的價值是：把“再做難一點”變成可核對的變量、輸入、順序和評分；模型結論要等真實資料，而不是等文章排版完成。