# 策展 · X (Twitter) 🔥🔥 > 作者：Ramp Labs (@RampLabs) · 平台：X (Twitter) · 日期：2026-05-08 > 原始來源：https://x.com/RampLabs/status/2052447438795833506 ## 中文摘要 # 使用 Prime-RL 後訓練打造快速且精準的 Agent 試算表 Agent 的表現取決於它所檢索到的資訊品質。如果讀取的資料太少，它會錯失答案；如果讀取的資料太多，它會變得緩慢、昂貴，且更容易被無關的頁籤（tabs）干擾。 在 Ramp Sheets 中，我們開發了 **Fast Ask** 來處理這種檢索迴圈。當使用者提出「三月到五月的營收是多少？」這類問題時，Fast Ask 會導覽活頁簿、讀取相關範圍，並回傳一個精簡的答案供主要 Agent 使用。我們與 Prime Intellect 合作，利用他們的 RL 訓練堆疊（training stack）對開源的 Qwen 模型進行後訓練，以支援此工作流程。我們在此將 Fast Ask 作為 RL 後訓練的案例研究：探討何時值得訓練專用 Agent、如何設計環境，以及如何評估後訓練是否成功。 --- ## 動機 在我們的追蹤紀錄中，我們觀察到大量的探索開銷（exploration overhead），實際上也浪費了許多時間。主要 Agent 在取得回答所需的資料前，有 17.8% 的工具呼叫（tool calls）花在開啟頁籤、讀取範圍和過濾無關工作表上。其中約 75% 的呼叫後緊接著又是另一次讀取呼叫，這顯示 Agent 往往無法在第一次嘗試時就檢索到正確資訊。 單純使用 Prompt 並無法改變這個核心迴圈：一個龐大且緩慢的通用模型，仍需負責導覽試算表並過濾無關資訊。因此，我們透過後訓練將一個開源 Qwen 模型轉化為專門的檢索子 Agent（subagent）。這讓我們能將檢索任務移交給一個更小、更快的模型，同時保持準確性，並達到生產環境所需的延遲表現。 最終的 Fast Ask 模型是一個經過微調的 Qwen3.5-35B-A3B 變體，擁有約 30 億個活躍參數，執行速度約為 Claude Haiku 的 4.5 倍延遲。在我們保留的評估集上，Fast Ask 的精確匹配準確度比 Claude Opus 4.6 高出 4 個百分點。這使得最終的 Agent 系統既快速又精準。 ## 為什麼檢索任務值得擁有專屬的子 Agent 檢索任務之所以適合專用模型，有三個原因： - 首先，它能保護主要 Agent 的 context。如果主要模型讀取每一個頁籤，它會消耗 token 在無關的列上，並可能被誘餌資訊誤導。檢索子 Agent 可以只回傳答案相關的儲存格或計算出的數值。 - 其次，檢索對延遲非常敏感。如果主要 Agent 能快速取得所需的試算表事實，而不必花費多個步驟探索活頁簿，使用者體驗會好得多。 - 第三（也是最重要的一點），檢索是可以驗證的。與開放式的財務推理不同，許多試算表問題都有確定的答案：日期、發票 ID、金額、是非題或儲存格參照。這使得該任務非常適合 RL，因為我們可以確定性地為軌跡（trajectories）評分。 這些特性使檢索成為 RL 後訓練的絕佳目標。該任務範圍狹窄、重複性高、對延遲敏感且具備客觀評分標準。 --- ## 實驗設置 我們透過將試算表互動視為一個包含許多相關任務、小型工具介面以及確定性獎勵函數的環境，使該工作流程能夠透過 RL 進行訓練。模型不是透過學習正確行為的示範來訓練，而是透過強化學習，自行探索導覽活頁簿、檢索資料和計算答案的策略。 我們使用 Qwen/Qwen3.5-35B-A3B 作為基礎模型，並在 Prime Intellect 的 Lab 平台上，利用他們的 Hosted Training 基礎設施與驗證器框架進行訓練。訓練環境直接對應我們生產環境的部署 harness。 該次訓練使用了 100 個訓練步驟、256 的 batch size，以及每個範例 8 個 rollouts。每 20 個步驟會在 128 個保留範例上進行評估，並將基礎模型與訓練後的檢查點（checkpoint）進行比較。我們停用了思考模式（thinking mode），以確保比較條件符合我們在意的低延遲生產環境。 ## 合成資料集 每個任務由一個合成的商業活頁簿、一個自然語言問題和一個基準答案（ground truth）組成。這些活頁簿旨在反映真實的財務工作流程：營收彙總、發票調節、支出分析、時間篩選查詢以及多重連接聚合。 合成資料讓我們能在保持可靠性的同時擴展任務分佈。它允許我們產生相同檢索問題的多種變體、精確控制答案，並在不改變底層訓練技能的情況下變更表面措辭。 我們定義了橫跨三個類別的 14 種任務類型： ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778203319515-iaHHutUHeWwAIKdoXjpg.jpg) 對於每個任務，我們產生了三種不同措辭的變體，例如投資人備忘錄請求、收款追蹤和募資模型問題。這能防止模型對單一 Prompt 模板產生過度擬合（overfitting）。調節任務透過發票描述符、付款線索以及客戶/日期/金額簽章增加了更多變化，將有效的 Prompt 空間擴展到每種類型 3 個以上。 範例： > 我正在精簡我們的投資人備忘錄。South 在 2025-03 到 2025-05 期間的累計淨認列營收是多少（以美元分計）？ > 工作表：['Orders', 'OrderLines', 'Shipments', 'Returns', 'OrderMonthNet', 'FxExposure', 'Contracts', 'FXRates', 'Targets', 'HiringPlan', 'CapTable'] 訓練批次以平衡的輪詢（round robin）方式組裝：每次遍歷資料集時，都會在重複前先打亂並輸出所有 14 種任務類型，確保覆蓋率均勻 ¹。 對抗性活頁簿設計 我們使用難度等級來控制模型面臨的導覽壓力。簡單任務通常會直接暴露通往答案的路徑。中等和困難任務則使用三種策略來增加難度：干擾項、不可靠的捷徑以及模糊的識別碼。 難度控制使策略更具魯棒性。透過變更干擾項、輔助摘要和模糊識別碼，我們訓練模型應對它在合成環境之外會遇到的各種導覽失敗。 - 誘餌工作表（Decoy sheets）：在中等和困難難度下，營收活頁簿會包含與財務相關但對答案無關的頁籤，例如 `HiringPlan` 和 `CapTable`，裡面有招募人員姓名、職缺、選擇權池等規劃資料。這些工作表不包含目標問題所需的資訊。不加區分地讀取這些頁籤的模型會浪費其回合預算。 - 部分輔助摘要：有些活頁簿包含像 `RegionalPnL` 或 `SpendSummary` 這樣的摘要工作表，但省略了直接回答問題所需的計算欄位。模型會看到一個看起來像捷徑的頁籤，但仍必須從原始資料中驗證或聚合。在困難難度下，輔助摘要會被完全移除。 - 識別碼混淆：在約 15-20% 的調節任務中，問題參照發票時不是使用 `INV-####` ID，而是使用付款線索（如來源系統、方式、日期和金額）或簽章（如客戶、月份、金額和到期日）。模型必須先解析該參照才能回答。 工具介面 模型擁有三個工具和 15 個回合的預算： - `get_workbook_metadata`：回傳工作表名稱、頁籤顏色和近似的 `used_ranges`。 - `read_ranges`：回傳儲存格資料，每次呼叫上限為 1,000 個儲存格。過大的請求會被拒絕。 - `run_python`：執行沙盒 Python（僅限標準函式庫）。狀態會在同一個 rollout 的呼叫之間持續存在。 刻意保持工具空間如此狹小是有目的的。只有三個工具，在獎勵訊號中更容易區分高效與浪費的軌跡。 --- ## Fast Ask 背後的 RL 數學 對於每個試算表問題，模型會採樣八個軌跡： 每個軌跡都是完整的互動追蹤：工具呼叫、試算表讀取、Python 執行和最終答案。驗證器使用我們的確定性獎勵函數為每個軌跡評分： 我們圍繞 Fast Ask 的生產需求設計了獎勵機制。它應該回傳正確答案、快速完成，並避免在主要 Agent 的 context 中加入不必要的文字。 正確性在獎勵中佔主導地位。`1.0` 的項僅在最終的 `"ANSWER:"` 行解析為預期類型且與基準答案精確匹配時才會觸發。效率和簡潔性項是較小的塑造獎勵（shaping rewards）。它們無法挽救錯誤的答案，但能區分正確的軌跡。在五個回合內給出正確答案，其得分應略高於在瀏覽無關工作表後才給出相同答案的軌跡。 我們使用 GRPO 進行訓練，這是一種策略梯度方法，從為相同 Prompt 採樣的一組 rollouts 中估算優勢（advantages）。GRPO 不會擬合單獨的價值模型，而是將每個 rollout 的獎勵相對於其組內的其他 rollouts 進行標準化。對於給定的試算表問題，一個軌跡可能在五個回合內正確回答，而另一個則將預算花在誘餌頁籤上並失敗。這種相對獎勵差異就成為了學習訊號。編寫 rollout `i` 優勢的一個簡單方法是： 暫時忽略離線策略（off-policy）修正，策略梯度更新的形式為： 這正是讓 RL 成為工具使用 Agent 自然選擇的部分。我們從不標記正確的下一個工具呼叫，只對最終軌跡評分。數學運算將機率質量推向使最終答案正確的行為：先讀取元資料、避開誘餌頁籤、在有效時使用輔助摘要、在需要時回退到原始列，並輸出可解析的 `"ANSWER:"` 行。 為什麼非同步離線策略 RL 讓這一切變得可行 對於 Fast Ask 來說，一個 rollout 是一個多回合軌跡，Agent 會檢查活頁簿元資料、讀取範圍、執行 Python，最後輸出可解析的答案。這使得 rollout 產生的速度比一般的監督式微調資料載入慢得多。 Prime Intellect 的 `prime-rl` 堆疊透過非同步離線策略訓練使其變得可行。離線策略訓練能夠從由稍微舊版本的模型（更新次數較少）產生的軌跡中學習，而不要求每個 rollout 都來自最新的權重。Rollout 工作節點（workers）在訓練器更新模型的同時持續產生軌跡。雖然有些軌跡來自稍微舊的策略，但目標函數透過重要性加權（importance weighting）修正了這種有界的滯後性。 重要性比率為： 直觀地說，`rho_t` 問的是：當前模型產生此 token 的可能性，與最初產生它的模型相比，是更高還是更低？ Prime Intellect 使用 AIPO 風格的截斷重要性加權目標函數來保持更新穩定： 這對於工具使用任務至關重要，因為 rollout 很慢。如果訓練必須在每次更新後停下來等待完全新鮮的軌跡，GPU 利用率就會受損。離線策略 RL 讓 rollout 工作節點在訓練器持續從近期產生的追蹤中學習的同時，能繼續探索試算表。 --- ## 結果 我們在保留的任務集上評估了基礎模型和訓練後模型，並與 Claude 系列進行了比較。指標為精確匹配準確度和每個 rollout 的實際執行時間（wall clock time）： 訓練進行了 100 個步驟，耗時約 26 小時。獎勵在前 40 個步驟中從約 0.2 上升到 0.8，隨後趨於平穩。大部分的提升來自兩方面：模型學會產生正確解析和格式化的答案，以及規劃出浪費更少回合的更緊湊軌跡。有趣的是，每個 rollout 讀取的總儲存格數在訓練期間大致保持平穩。這表明模型並未學會減少總讀取量，而是學會了更有效地分配讀取資源。 ![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1778203319521-iaHHuwNjsWIAIoG79jpg.jpg) RL 訓練比基礎模型提升了 10 個百分點的準確度，同時實際降低了平均完成時間。訓練後的模型在準確度上勝過 Opus 4 個百分點以上，且執行速度達到 Haiku 的延遲水準。 --- ## 重點總結 RL 後訓練之所以在此奏效，是因為該環境使試算表檢索變得可衡量且可重複。利用 RL 環境，我們將檢索簡化為具有明確結果的重複決策。這為模型提供了一個清晰的優化目標，而無需人工標記的軌跡或 LLM 裁判。 Fast Ask 是我們預期未來會更多使用的模式範例：為狹窄的瓶頸訓練小型、可驗證的子 Agent，並讓前沿模型將 token 花在判斷上，而非檢索上。 在嚴格限定的環境中透過 RL 訓練的小型模型，可以在特定檢索任務上超越前沿模型，且成本和延遲僅為其一小部分。重要的工作不在於模型架構或規模，而在於環境設計：正確的任務、最小化的工具介面，以及植根於產品實際運作方式的獎勵函數。這使模型學會了讀取正確的內容。 --- ¹ 合成世界在內部是一致的。客戶、供應商、SKU、合約層級、付款方式、調整原因和輸入來源均從固定詞彙表中採樣，使模型在數千個產生的活頁簿中具有真實的實體結構。 --- 共同作者：Ben Geist @b_geist & Will Brown @willccbb --- 想跟上我們下一個 AI 實驗嗎？請在此訂閱並在 @RampLabs 追蹤我們。我們也在 Ramp 招募各類職位。 ## 標籤 Agent, 開源專案, AIGC, Ramp, Prime Intellect, Qwen