Travelers 攜手 OpenAI，在全美部署 AI 驅動的理賠服務
🏦 台灣Pay 銀行轉帳 💙 PayPal
Travelers CIO 分享如何用 AI claim assistant 處理首次出險通知，兩個月內從 8 州推到全國
- 00:02 受訪者 Eric Rowan 是 Travelers Insurance 資深副總裁暨資訊長，在 Travelers 任職 28 年，近 15 年在理賠部門，近 7 年同時在技術部門
- 09:20 主持人指出這是反覆測試的過程：給 agent context 和回饋，它就會學習
- 18:33 Travelers 將延續並擴大與 OpenAI 的合作
💡 你可以怎麼用：你自己用 AI 做重複性工作時，可以學他們的做法：先寫下 10～20 個常見情境當成小考題，每次改指令就全部重跑一次，再請另一個 AI 檢查語氣和正確性。也可以先定好自己的優先順序，例如「正確 > 對方感受 > 省時間」，AI 的輸出衝突時就照這個順序取捨。
看全部 63 條重點
🧑🏫 美國產險公司 Travelers 的資訊長 Eric Rowan 分享，他們怎麼用 OpenAI 做出一個會講電話的 AI 理賠助理，只花兩個月就從 8 個州推到全美。值得看的是他講的「做法」：怎麼讓業務人員一起參與、怎麼測試、怎麼監控、怎麼帶員工面對改變。這些經驗就算你不是工程師，也能拿來用。
- 00:02 受訪者 Eric Rowan 是 Travelers Insurance 資深副總裁暨資訊長，在 Travelers 任職 28 年，近 15 年在理賠部門，近 7 年同時在技術部門↳ 受訪者 Eric Rowan 是 Travelers 保險的資深副總兼資訊長（CIO，公司管技術的最高主管）。他在公司待了 28 年，理賠和技術兩邊都懂。
- 00:34 他負責理賠部門的技術、分析與業務交付，也涵蓋所有 AI 相關事務↳ 理賠部門的技術、數據分析和實際交付都歸他管，AI 相關的事也是，所以這個專案從頭到尾都是他負責。
- 00:34 first notice of loss 會替整個理賠流程定調，是關鍵的工作流程↳ first notice of loss（首次出險通知）就是出事後第一次聯絡保險公司報案。這一步做得好不好，會影響後面整個理賠順不順。
- 01:04 從客戶角度看：客戶可能剛出車禍，或車子被暴風雨損壞，壓力大、疑問多。他們來電是想知道下一步該怎麼做、要不要報案、怎麼報案↳ 打電話來的人可能剛出車禍，或車子被暴風雨打壞，心裡很慌又有一堆問題。他們要的是有人告訴他接下來該怎麼辦，而不是一張表格。
- 01:36 從營運角度看：前端資訊若準確又及時，理賠會順利很多，也能啟動分流、指派理賠專員、設定自助預約修車廠等服務↳ 對公司來說，一開始資料收得準又快，後面才能分流（triaging，依案件狀況決定怎麼處理）、指派專員，或讓客戶自己約修車廠。
- 02:07 目前先從 auto physical damage 開始↳ auto physical damage 是汽車車損險，也就是理賠車子本身的損壞。他們先從這一種開始，沒有一次全部上線。
- 02:07 這個流程在「開案需要哪些資料」上是結構化的，但客戶的問題與需要的說明差異很大，所以 non-deterministic agents 能發揮很大價值↳ 開案要收哪些資料是固定的，但每個人的問題千奇百怪。non-deterministic agents（不照固定腳本、會隨機應變的 AI 代理）正好擅長處理這種情況。
- 02:39 agents 能因應不同問題與回答做調整，提供清楚說明，並用多種方式引導客戶完成報案↳ agent（AI 代理）是能自己判斷下一步、幫你完成任務的 AI。它會依客戶怎麼問來調整說法，換不同方式帶客戶把報案完成。
- 02:39 信心來源：很早就和 OpenAI 合作，甚至早於部分模型 GA。real-time APIs 很強大↳ 他們很早就和 OpenAI 合作，有些模型還沒 GA（正式對外開放）就開始用了。他們認為 real-time APIs（讓程式能和 AI 即時互動的串接介面）非常強。
- 03:09 早期的評估、benchmarking 與測試就顯示，它的體驗會和大家過去幾年習慣的 chatbot 非常不同↳ 早期做評估和 benchmarking（用同一套標準比較表現）時就發現，它跟大家印象中常答非所問的 chatbot（聊天機器人）完全不同。
- 03:40 導入前，客戶可透過網站或 app 等數位管道報案，也有很多人打電話到客服中心↳ 以前客戶可以用網站或 app 報案，但還是有很多人習慣直接打電話到客服中心。
- 03:40 遇到颶風等事件時，短時間湧入大量來電。公司很難為這種不常見的尖峰配置人力，導致客戶等候時間變長↳ 颶風一來，大量電話同時湧進來。為了一年少數幾次的尖峰養一大批人並不實際，結果就是客戶在電話上等很久。
- 04:11 現在客戶來電報案時，可以選擇和 AI claim assistant 互動，由它引導理賠流程，並協助客戶判斷是否要報案↳ 現在打電話報案，客戶可以選擇讓 AI claim assistant（AI 理賠助理）接手。它會帶你走完流程，也會幫你想清楚到底要不要報案。
- 04:41 客戶選擇使用後，由多個 agents 無縫協作，客戶完全察覺不到。系統會聆聽、理解意圖、提供說明、回答問題↳ 背後其實有好幾個 agents 在分工，但客戶感覺只是在跟一個對象講話。它會聽你說、搞懂你要什麼，再解釋、回答你的問題。
- 04:41 最後系統會在 legacy system 建立理賠案件，並啟動其他作業，例如預約修車廠或租車↳ 最後它會在 legacy system（公司用了很多年的既有核心系統）把案件開好，接著安排修車廠預約或租車。
- 05:13 主要差異化功能是 loss consultation agent：處理客戶不確定該不該報案、適用哪種保障、自付額多少、報案是否影響保費等情況↳ 最大的亮點是 loss consultation agent（出險諮詢 AI），能幫你判斷該不該報、適用哪種保障、deductible（自付額）多少、報了會不會漲保費。
- 05:44 loss consultation agent 也能處理「有過失時該向 Travelers 還是對方保險公司報案」等許多情況↳ 像「自己也有責任時，該找 Travelers 還是對方的保險公司」這種一般人搞不清楚的情況，它也能處理。
- 05:44 客戶在任何時候都可以選擇改和客服中心專員通話↳ 客戶隨時可以改找真人客服，不會被困在 AI 裡出不來。
- 06:15 主持人 Denise 指出，最成功的公司把 AI 視為 operating layer，而不只是技術或應用層；Travelers 在 AI 的營運化與治理上也採取這種思維↳ 主持人 Denise 說，做得好的公司會把 AI 當成 operating layer（營運層，也就是融入公司日常運作的方式），而不只是一套工具。Travelers 也是這樣看的。
- 06:45 營運模式：一開始就讓資料工程師、軟體工程師、資料科學家、法務、架構師、領域專家一起參與，與 OpenAI 團隊合作↳ 他們一開始就把工程師、資料科學家、法務、架構師和懂業務的人拉進同一個團隊，和 OpenAI 一起做，沒有各做各的。
- 06:45 原因是這次的建置、測試與部署方式會和過去非常不同↳ 因為 AI 產品的做法、測法、上線方式都和傳統軟體差很多，只靠技術部門做不起來。
- 07:17 傳統軟體開發約 80% 工作在技術端、20% 在業務端，業務端大致只在開頭提需求、最後做 UAT 與上線↳ 以前做系統，約八成工作在技術端。業務單位只在開頭提需求，最後做 UAT（使用者驗收測試，上線前由實際使用者確認能不能用）。
- 07:17 這次業務人員的投入比例接近 50/50，他們參與 Evals、建立 LLM judges，並和團隊一起迭代↳ 這次業務人員的投入接近一半。他們參與 Evals（用一批情境測試 AI 的表現），也一起建立 LLM judges（讓大型語言模型當評審，替 AI 的回答打分數）。
- 07:48 第二件事是大量的變革管理：多數人過去的 chatbot 體驗大概不理想，所以從高階主管到客服中心人員都被帶進來了解底層運作↳ 第二件事是 change management（變革管理，幫大家接受新做法）。多數人對 chatbot 印象不好，所以從高階主管到客服人員都被帶來了解它怎麼運作。
- 07:48 內容包括 agents 怎麼運作、如何做 observability，並讓他們親身體驗。這大幅提升了大家對這個方向的接受度↳ 他們讓大家看懂 agents 怎麼運作、怎麼做 observability（可觀測性，隨時看得到 AI 在做什麼），還讓大家親自試用，接受度因此大幅提升。
- 08:18 治理面：理賠部門做 AI 與 machine learning 已經 15 年，本來就有 responsible AI framework 與 tech governance 流程↳ 理賠部門做 AI 和 machine learning（機器學習）已經 15 年，本來就有 responsible AI framework（負責任使用 AI 的規範）和技術治理流程。
- 08:49 Claim three laws 第一律：每一件理賠都支付應付的金額↳ 他們自訂了「理賠三律」，第一條最優先：每一件理賠都要賠到該賠的金額。
- 08:49 第二律：在不違反第一律的前提下，給客戶或 agent 很好的體驗↳ 第二條：在賠對錢的前提下，讓客戶或 agent 都有很好的體驗。
- 08:49 第三律：在不違反前兩律的前提下，讓內部作業有效率、有成效↳ 第三條：前兩條都顧到了，才追求內部效率。也就是說，省成本排在最後，不能犧牲賠款正確或客戶體驗。
- 08:49 三律、responsible AI framework、tech governance 是「凳子的三隻腳」，讓他們能快速又負責任地創新↳ 三律、負責任 AI 規範、技術治理，就像凳子的三隻腳，缺一隻就站不穩。三者都在，他們才能又快又負責任地創新。
- 09:20 主持人指出這是反覆測試的過程：給 agent context 和回饋，它就會學習↳ 主持人說，這是一直測、一直修的過程：你給 agent 足夠的背景資訊（context）和回饋，它就會越做越好。
- 09:20 最成功的部署會讓跨部門利害關係人全程參與，既能得到好回饋，大家也知道該期待什麼↳ 最成功的導入，會讓各部門從頭參與到尾。這樣既拿得到實用的回饋，大家對結果也有合理預期，不會上線才嚇一跳。
- 09:51 傳統軟體流程是 kickoff、設計、conference room pilot、UAT、上線，現在已經不是這樣了↳ 傳統流程是開案、設計、conference room pilot（在會議室模擬實際作業試跑）、驗收、上線，一關一關走。現在已經不是這樣了。
- 09:51 透明讓大家都熟悉 agents、prompts 與 evals，得以在 test and learn 中迭代↳ 因為過程透明，大家都熟悉 agents、prompts（給 AI 的指令）和 evals，就能用 test and learn（邊試邊學、小步修正）的方式一直改。
- 09:51 現在每天都在上變更；過去可能一週才找業務人員來確認一次↳ 現在幾乎每天都在改；以前可能一週才找業務人員確認一次，速度差很多。
- 10:23 從 8 個州試行擴展到全國，只花了 2 個月↳ 先在 8 個州試行，只花 2 個月就推到全美。
- 10:23 建立 mission control，用於測試、試行與正式環境，近即時串流所有資料↳ 他們建了 mission control（監控中心），把測試、試行、正式上線三種環境的資料幾乎即時傳進來，隨時掌握狀況。
- 10:54 mission control 以 15 分鐘為單位，可看到業務成果、系統效能、模型效能、客戶體驗與 intervention monitoring↳ 每 15 分鐘就能看到業務成果、系統和模型的表現、客戶體驗，還有 intervention monitoring（介入監控，影片沒有細說內容）。
- 10:54 整個過程中持續進行一系列 evals↳ 從頭到尾都在持續跑各種 evals，不是上線前測一次就結束。
- 11:25 其中一項 eval 是用 AI 建立 synthetic caller，打進 IVR 跑上千種理賠來電情境↳ 其中一種測法，是用 AI 扮演 synthetic caller（模擬來電者），打進 IVR（電話語音系統，就是「請按 1」那種）跑上千種報案情境。
- 11:25 後端由 LLM judges 評估語氣、準確度、資訊是否正確，以加快測試迭代↳ 通話結束後，由 LLM judges 檢查語氣、準確度和資訊對不對。不用人一通一通聽，測試就快很多。
- 11:55 mission control 中的 LLM judges 也作為 fail safes，檢查 agents 是否產生幻覺、提供不正確資訊，或做出不該有的承諾性陳述↳ LLM judges 也是 fail safes（安全機制），會抓 AI 有沒有 hallucinating（一本正經地講錯）、給錯資訊，或亂做承諾，例如說「這一定會賠」。
- 11:55 一旦觸發，團隊會收到警示，必要時可在 10 分鐘內關閉 agent↳ 一旦發現問題，團隊會收到警示，必要時 10 分鐘內就能把 agent 關掉。
- 12:25 observability、mission control 與隨手可得的資料，讓他們能帶著信心、負責任地持續推進↳ 能隨時看見 AI 在做什麼、資料也隨手拿得到，他們才敢一邊往前推，一邊負責任地控管風險。
- 12:25 主持人認為這是把 AI 從技術層轉為營運層的具體實例↳ 主持人認為，這就是把 AI 從「技術專案」變成「日常營運的一部分」的真實例子。
- 12:55 目前約 80 到 90% 的客戶透過 assistant 完成報案；從試行起採用率就很高，不太需要爬坡↳ 目前約 80～90% 的客戶透過 AI 助理完成報案，而且從試行開始就這麼高，不需要慢慢爬升。
- 12:55 採用率高歸功於事前大量的 evals 與測試，包括用 synthetic caller 找出需要調整的 backlog，所以一開始體驗就很好↳ 因為上線前做了大量測試，用模擬來電先挖出一堆要修的地方（backlog，待辦清單），所以客戶第一次用就覺得好用。
- 13:27 客戶回饋很好，有人來電表示「從沒體驗過這樣的東西」↳ 客戶反應很好，還有人特地說「從來沒遇過這樣的體驗」。
- 13:59 仍有 35% 的人在被提供選擇時想和真人通話。Eric 認為這只是還沒體驗過新事物的行為因素↳ 還是有 35% 的人一聽可以選，就想找真人。Eric 認為這是大家還沒用過、不習慣新東西的行為因素。
- 13:59 他認為隨著更多公司推出、大家在生活中體驗到更好的語音 agentic 體驗，人們會更願意嘗試↳ 他認為等更多公司推出好用的語音 AI，大家在生活中用習慣了，就會更願意嘗試。
- 15:02 選擇 OpenAI 前做過相當廣泛的 benchmarking 與測試↳ 選 OpenAI 之前，他們把不同方案都做過廣泛的比較和測試，並不是直接指定。
- 15:02 他們要找的是能一起在第一線捲起袖子、在做 evals 和建 judges 時渴望回饋的夥伴↳ 他們要的不只是賣模型的廠商，而是願意一起下場做 evals、建評審，而且真心想聽意見的夥伴。
- 15:32 OpenAI 研究人員喜歡這些回饋，能把 Travelers 看到的問題直接納入下一版模型，讓雙方都走得更快↳ OpenAI 的研究人員很歡迎這些回饋，會把 Travelers 遇到的問題直接放進下一版模型改進，雙方都因此跑得更快。
- 15:32 給其他企業的建議：投入時間、安排專責人員挑一個問題，和 OpenAI 夥伴一起解決，並接受 test and learn 的做法↳ 給其他公司的建議：投入時間、派專人挑一個具體問題，和 OpenAI 一起解決，並接受邊試邊改的做法。
- 16:03 倚靠 evals、LLM judges 與 observability 帶來信心以加快速度。永遠不會有完美資訊，也不該讓專案拖太久才進 production↳ 靠 evals、LLM judges 和可觀測性建立信心，速度才快得起來。資訊永遠不會完美，別因為等資訊齊全而一直拖著不上線。
- 16:33 對「AI 取代工作」的擔憂：他們在變革管理上投入大量時間，一路延伸到客服中心員工↳ 面對「AI 會搶工作」的擔心，他們花了很多時間溝通，一路做到第一線客服人員。
- 17:03 Eric 肯定客服中心領導層帶領組織度過這次改變，並確保各地主管理解改變的意義↳ Eric 特別肯定客服中心的主管帶著大家度過這次轉變，也確保各地主管理解這次改變代表什麼。
- 17:03 公司審慎規劃如何 upskill、reskill，並把人才重新調派到理賠組織的其他部分↳ 公司有計畫地讓員工 upskill（提升現有技能）、reskill（學新技能），再把人調到理賠部門的其他職位。
- 17:03 他們認為 AI 會成為 Travelers 所有職能的一部分，全體都在投入 upskilling 與 reskilling↳ 他們認為 AI 會進到公司每一個職能，所以不只客服，全公司都在學新技能。
- 17:33 下一步：把 AI claim assistant 推廣到其他業務線，以這種方式處理 personal loss 內的各種理賠↳ 下一步是把 AI 理賠助理推到其他險種，用同樣方式處理個人保險裡的各種理賠。
- 18:03 也在整個 claim life cycle 投入 AI。光是理賠部門就有約 20 個其他專案進行中，Travelers 全公司還有更多↳ 他們也要把 AI 用在整個 claim life cycle（從報案到結案的完整理賠過程）。光理賠部門就還有約 20 個專案在進行，全公司更多。
- 18:03 這些專案的目標同樣是：支付應付金額、提供好的體驗、有效率且有成效地執行↳ 這些專案的目標都一樣，就是理賠三律：賠該賠的錢、給好的體驗、內部有效率。
- 18:33 Travelers 將延續並擴大與 OpenAI 的合作↳ Travelers 會延續並擴大和 OpenAI 的合作。
📘 術語
first notice of loss（首次出險通知）：為整個理賠流程定調的關鍵流程；客戶來電詢問下一步、是否及如何報案
auto physical damage（汽車車體損失）：字幕未解釋；是 Travelers 目前率先導入 AI 的業務線
non-deterministic agents（非確定性 agent）：能因應不同問題與回答調整、提供清楚說明、引導客戶完成報案
GA（正式釋出）：字幕未解釋；提到 Travelers 在部分模型 GA 之前就開始與 OpenAI 合作
real-time APIs（即時 API）：字幕只說這些模型搭配 real-time APIs 非常強大，未進一步解釋
AI claim assistant（AI 理賠助理）：客戶來電可選用，由多個 agents 協作引導報案並建立案件
loss consultation agent（損失諮詢 agent）：處理客戶不確定是否該報案、保障、自付額、保費影響、過失歸屬等問題
deductible（自付額）：字幕未解釋；列為客戶可能不清楚的事項之一
legacy system（既有舊系統）：字幕未解釋；AI 最後會在 legacy system 中建立理賠案件
triaging（分流）：字幕未解釋；列為前端資訊正確後可啟動的服務之一
operating layer（營運層）：主持人指出成功企業把 AI 視為營運層，而不只是技術或應用層
UAT（使用者驗收測試）：字幕未解釋；是傳統軟體開發在後段、上線前進行的測試
conference room pilot（會議室試行）：字幕未解釋；列為傳統軟體流程的步驟之一
Evals（評估）：業務人員參與的工作之一；讓團隊有信心更快推進
LLM judges（LLM 評審）：評估語氣、準確度、資訊是否正確，也作為 fail safes 偵測幻覺等問題並發出警示
change management（變革管理）：讓高階主管到客服中心人員了解 agents 運作並親身體驗，也涵蓋員工轉型
observability（可觀測性）：讓大家了解如何監看 agents；搭配 mission control 帶來推進的信心
responsible AI framework（負責任 AI 框架）：理賠部門做 AI 與 machine learning 15 年來一直遵循的框架
Claim three laws（理賠三律）：支付應付金額、在不違反第一律下提供好體驗、在不違反前兩律下有效率執行
test and learn（測試與學習）：反覆迭代的做法，當時每天都在上變更
mission control（任務控制中心）：在測試、試行、正式環境近即時串流資料，每 15 分鐘看各項成果與效能
intervention monitoring（介入監控）：字幕未解釋；是 mission control 可監看的項目之一
synthetic caller（合成來電者）：用 AI 建立，打進 IVR 跑上千種理賠來電情境
IVR（語音應答系統）：字幕未解釋；synthetic caller 會打進 IVR 進行測試
fail safes（安全防線）：LLM judges 檢查幻覺、錯誤資訊、不當承諾，觸發時警示團隊
hallucinating（幻覺）：字幕未解釋；是 LLM judges 要偵測的問題之一
promissory statements（承諾性陳述）：字幕中指 agent 不該做出的陳述，是 LLM judges 要偵測的問題之一
upskill / reskill / redeploy（技能提升／再培訓／重新調派）：把人才培訓並調派到理賠組織的其他部分
claim life cycle（理賠生命週期）：字幕未解釋；Travelers 將在整個 claim life cycle 投入 AI
auto physical damage（汽車車體損失）：字幕未解釋；是 Travelers 目前率先導入 AI 的業務線
non-deterministic agents（非確定性 agent）：能因應不同問題與回答調整、提供清楚說明、引導客戶完成報案
GA（正式釋出）：字幕未解釋；提到 Travelers 在部分模型 GA 之前就開始與 OpenAI 合作
real-time APIs（即時 API）：字幕只說這些模型搭配 real-time APIs 非常強大，未進一步解釋
AI claim assistant（AI 理賠助理）：客戶來電可選用，由多個 agents 協作引導報案並建立案件
loss consultation agent（損失諮詢 agent）：處理客戶不確定是否該報案、保障、自付額、保費影響、過失歸屬等問題
deductible（自付額）：字幕未解釋；列為客戶可能不清楚的事項之一
legacy system（既有舊系統）：字幕未解釋；AI 最後會在 legacy system 中建立理賠案件
triaging（分流）：字幕未解釋；列為前端資訊正確後可啟動的服務之一
operating layer（營運層）：主持人指出成功企業把 AI 視為營運層，而不只是技術或應用層
UAT（使用者驗收測試）：字幕未解釋；是傳統軟體開發在後段、上線前進行的測試
conference room pilot（會議室試行）：字幕未解釋；列為傳統軟體流程的步驟之一
Evals（評估）：業務人員參與的工作之一；讓團隊有信心更快推進
LLM judges（LLM 評審）：評估語氣、準確度、資訊是否正確，也作為 fail safes 偵測幻覺等問題並發出警示
change management（變革管理）：讓高階主管到客服中心人員了解 agents 運作並親身體驗，也涵蓋員工轉型
observability（可觀測性）：讓大家了解如何監看 agents；搭配 mission control 帶來推進的信心
responsible AI framework（負責任 AI 框架）：理賠部門做 AI 與 machine learning 15 年來一直遵循的框架
Claim three laws（理賠三律）：支付應付金額、在不違反第一律下提供好體驗、在不違反前兩律下有效率執行
test and learn（測試與學習）：反覆迭代的做法，當時每天都在上變更
mission control（任務控制中心）：在測試、試行、正式環境近即時串流資料，每 15 分鐘看各項成果與效能
intervention monitoring（介入監控）：字幕未解釋；是 mission control 可監看的項目之一
synthetic caller（合成來電者）：用 AI 建立，打進 IVR 跑上千種理賠來電情境
IVR（語音應答系統）：字幕未解釋；synthetic caller 會打進 IVR 進行測試
fail safes（安全防線）：LLM judges 檢查幻覺、錯誤資訊、不當承諾，觸發時警示團隊
hallucinating（幻覺）：字幕未解釋；是 LLM judges 要偵測的問題之一
promissory statements（承諾性陳述）：字幕中指 agent 不該做出的陳述，是 LLM judges 要偵測的問題之一
upskill / reskill / redeploy（技能提升／再培訓／重新調派）：把人才培訓並調派到理賠組織的其他部分
claim life cycle（理賠生命週期）：字幕未解釋；Travelers 將在整個 claim life cycle 投入 AI
✏️ 小考一題
Travelers 的 AI 理賠服務從 8 個州試行擴展到全國，花了多久時間？
A. 1 年B. 2 個月C. 6 個月D. 2 週看答案
答案：B。[10:23] Eric 說他們在 2 個月內從 8 個州的試行擴展到全國（went from piloting in the eight states to countrywide within 2 months）
💛 覺得有幫助？支持一下
課本免費、沒有廣告，支持與否都能照常讀 🐰