用 Braintrust 把客服 agent 推上線

概要

• 卡關的是營運不是模型Braintrust 的講者認為，POC 上不了線通常不是模型不夠聰明，而是營運上的嚴謹度沒跟上。講者把重點放在清楚知道系統改了什麼、怎麼系統性地變好。
• 先拆階段再談追蹤範例從單次呼叫開始，加入三個本地工具，再拆成五個階段。講者說拆開之後，才看得出哪一段出了問題。
• 追蹤與評估是基本功用巢狀 trace 看完整執行路徑，用 golden set 加上確定性評分與 LLM as a judge 守住底線。講者直言有上線的應用卻沒追蹤，就該回頭補。
• 託管讓非工程師也能改prompt、工具與評分函式推到 Braintrust 後，SME 與產品經理可以在介面改 prompt 或模型，不用動程式碼，變更也留有紀錄。
• 線上評分補上真實資料LLM judge 一開始取樣率高，穩定後降到 5% 到 10%，確定性評分則建議一直跑；抓到的失敗案例再丟回資料集重跑。
• Trainline 的實際用法他們用 Braintrust 追蹤助理的評分、在換模型前離線模擬再線上確認，並讓非技術同事自己查資料。

原話

• “there's no substitute for real world data”

  測試資料集做得出來，但真實資料沒有東西能取代

  ▶ 09:36

• “Before BrainTrust, we had no specific way of doing it”

  換模型前要確認表現不輸現有模型，但在用 Braintrust 之前，我們沒有專門的做法

  ▶ 21:22

• “I have a concrete way of saying, okay, this is how it's performed over time.”

  我有具體的方式能說明它長期的表現

  ▶ 58:34

• “if you cannot write it in a deterministic way, you want to be using LLM as a judge where possible.”

  寫不成確定性規則的，就盡量用 LLM as a judge

  ▶ 59:30

• “observability's table stakes at this point”

  Braintrust 的講者說，到這個階段 observability 是基本門檻

  ▶ 1:35:14

延伸

• 講者提到 Braintrust 為了處理大量 trace，自己做了一種新類別的資料庫，但只點到為止，沒有說明內部設計。
• Trainline 的旅客助理能處理退款與轉人工客服，這場只講到使用情境，沒有展開架構。
• 講者也提到 Braintrust 已宣布一個 CLI，可以做自動 instrumentation，細節沒有說明。