強化学習が本番運用を industrialize する — Alessandro Cappelli (Adaptive ML)

Alessandro Cappelli は Adaptive ML 大企業向け RL Ops (Reinforcement Learning Operations) プラットフォーム。 AT&T / Manulife / CCS 等の大企業が、 自社専用の特化型 LLM を構築・評価・本番運用するための 「Adaptive Engine」 を提供。 公式: adaptive-ml.com の共同創業者・Chief Customer Officer。 経歴は約 3 年前、 当時最も広く採用された OSS モデルの 1 つ Falcon 2023 年に UAE の Technology Innovation Institute (TII) が発表したオープンソース大規模言語モデル。 当時最も広く採用された OSS の 1 つで、 Llama-2 と並ぶ位置にあった。 Cappelli はその訓練チームに所属、 そこで 「OSS を production に持ち込むには RL が不可欠」 という洞察を得た (TII) の訓練チームに所属。 そこで得た核心的洞察 — 「OSS モデルを本番に持ち込む際の決定的ギャップ = 強化学習 (RL)」 — が Adaptive ML 創業の起点になった。

本講演の主張は明快: RL は post-training の数あるアルゴリズムの 1 つではなく、 model を production に到達させる唯一のアルゴリズム である。 「ラストマイルの神話」 という業界の幻想 (= MVP までが難しい、 production までは簡単) を打ち砕き、 大企業 (AT&T / Manulife / CCS / 医療サプライ会社) での実装事例で実証する。

1、 「ラストマイルの神話」 への反証 — MVP 構築は first mile に過ぎず、 真のマラソンは MVP → production → beyond の道のり。 prompt 微調整も SFT (instruction fine-tuning) もこの距離を systematic に縮められない、 RL だけが任意のフィードバックを数学的に統合できる構造を持つ

2、 RL の outsized performance による経済的 unlock — 同等性能を SFT より遥かに小さなモデルで実現可能 = 推論コスト・レイテンシ・所有権の 3 つでビジネス影響大。 AT&T の通話文字起こし要約だけで年間数百万ドル、 Sonnet サイズではなく 10B クラスで対応できれば桁違いに節約

3、 環境さえあれば合成データもパイプラインの副産物 — agent training に必要なデータは Web に存在しない、 でも RL 環境が組まれていれば 「reward signal が良いと言ったトラジェクトリ」 = 合成データセットとして自動生成される。 rejection sampling で bootstrap、 そのままモデル training に流せる

着眼点

「95% の GenAI パイロットは本番に到達できない」 — ラストマイルの神話 (01:38 - 03:30)

Cappelli の起点。 「95% の GenAI pilot は production に行けない、 なぜか? 『ラストマイルの神話』 によるもの」 (01:38)。

神話の中身: 「MVP 構築こそが大変、 production は最後のひと押し」 という業界通念。 これは誤り、 という主張。 「MVP は proprietary models や OSS の SFT で組める、 でもどちらも solution を systematically 改善できない」 (02:18)。

具体的に: 「proprietary model 使用時、 defect 発見後にできるのは system prompt 変更だけ、 1 方向に変えると別な defect が出る、 systematic な改善手段がない」 (02:38)。 「SFT 使用時、 dataset を iterate するしかない、 高コスト、 production 後は毎週新しい dataset を作るのか?」 (02:55)。

Cappelli が提示するリアル: 「MVP は first mile に過ぎない、 真のマラソンは MVP → production → beyond。 そこを accelerate できる秘密は RL — 任意のクライアントフィードバック / business metric / environmental reward を model lifecycle に systematic に統合できる唯一の手段」 (03:13)。

「RL は SFT の対等な代替ではない、 outsized performance を unlock する」 (04:22 - 05:33)

Cappelli の RL 推し論。 「prompt engineering と SFT と RL は同じゴール (モデル挙動の steering) に向かう、 でも同等な効果ではない」 (04:22)。

RL の独自価値: 「同等の性能を SFT に対して遥かに小さなモデルで実現可能」 (04:48)。 これが大企業にとって決定的:

• スケール時の経済性: AT&T は通話文字起こし要約だけで年間数百万ドル消費、 Sonnet / GPT サイズでなく 10B クラスで対応できれば桁違いに節約
• レイテンシ制約の解消: 顧客サポートの speech-to-speech は 0.5 秒以下の応答が必須 (半秒でも違和感)、 大規模モデルでは到達不可
• 所有権: 自社のビジネスデータで訓練、 model update で性能が突然変わるリスクがない

「Agent 時代に RL のリードはさらに広がる」 (06:48 - 09:04)

Cappelli の構造論。 「Agent はトークン消費が増え、 複雑性が増し、 エラー許容範囲が狭まる (DB を agent が触る)、 production 基準が上がる、 tokenomics の問題が大きくなる」 (07:21)。

ここで RL の歴史的優位が活きる: 「RL は元々 robot / agent を環境内で訓練するために生まれた、 環境こそが agent の振る舞いを成立させる場所。 つまり RL は agent の訓練に natural fit」 (07:54)。

2 つのシナリオ: 「既に agent workflow がある (Manulife のような) なら、 そこに training したモデルを直接 plug する。 環境がなければ、 tool を mock + LLM-as-mock-user で作れる。 reward は business outcome / KPI / LLM-as-judge を組み合わせる」 (08:42)。

「環境さえあれば、 合成データは副産物として湧いてくる」 (09:38 - 10:34)

データ問題への回答。 「クライアントとの会話で最大の懸念点 = agent 訓練用データがない」 (09:38)。 Agent の training data は野生に存在しない (Web スクレイプで取れるものではない)。

RL の構造的解答: 「環境 + reward が組まれていれば、 自動的に synthetic dataset pipeline が成立する。 環境を回せば trajectory が生成される、 reward が良いと判定したものを rejection sampling で抽出すれば、 model bootstrap 用の dataset になる」 (10:08)。

既存データの活用も可能: 「顧客とエージェントの実会話の transcript を mock user の訓練に使える。 医療サプライ会社の事例では、 パニック状態の顧客 (『救急車呼んで』 と言うべき場面) も mock で再現できる」 (10:34 - 11:01)。

「Human-in-the-loop は annotation campaign じゃなく rubric 設計」 (11:25 - 13:10)

Cappelli の現実主義。 「RLHF (= Reinforcement Learning from Human Feedback) が ChatGPT で広まったが、 『human in the loop』 という美名の裏は 高コストな annotation campaign。 経験上、 誰も annotation をやりたがらない、 高いか役立たないかのどちらか」 (11:25)。

Adaptive Engine のアプローチ: 「人間の役割は rubric 定義 / LLM-as-judge の system prompt 設計 / scenario の調整 のみ。 数分から数時間で済む、 数週間繰り返す必要なし」 (12:55)。

Reward の組み立て方:

• systematic reward: コードが実行できるか、 syntax が正しいか — 機械的に判定可能
• direct KPIs: CCS の containment rate (= 通話の何 % が end-to-end で agent 内完結) を直接最大化
• open-ended な質的評価: tone は正しいか、 business guideline に沿っているか — LLM-as-judge で代替

「PPO は 4 つの LLM を同時 orchestrate する」 — RL の複雑性 (13:35 - 14:38)

Cappelli の正直な但し書き。 「RL の catch = RL は実際に難しい。 prompt 変更でも SFT dataset 作りでもない、 桁違いの複雑性」 (13:35)。

具体例: 「PPO (RL アルゴリズムの代表) は 1 つではなく 4 つの LLM を同時 orchestrate する必要がある」 (13:55)。 これが Adaptive Engine の存在意義 — 「rubric 等の意思決定はクライアントに残す、 RL の複雑性は pre-built recipe で隠蔽する」 (14:18)。

Karpathy が AI Ascent で示した 「vibe coding from agents」 路線とは対照的に、 Adaptive ML は enterprise の生産環境で RL を industrialize する ことに焦点。 個人開発者の生産性と、 Fortune 500 の本番運用は、 求められる infrastructure が桁違い。

動画の構成

• (00:00) 自己紹介、 Adaptive ML の概要、 AT&T / Manulife / CCS 等の事例
• (00:45) RL は単なる post-training algorithm ではなく、 model を production に到達させるための algorithm という主張
• (01:08) Falcon 訓練チームでの経験、 「OSS → production のギャップ = RL」 の発見
• (01:38) 「95% の GenAI pilot は production に行けない」、 「ラストマイルの神話」
• (02:18) MVP の組み方 (proprietary / SFT) の限界、 改善経路の不在
• (03:13) 真のマラソン = MVP → production → beyond、 RL こそが accelerate できる
• (04:22) RL vs SFT vs prompt、 同じゴールでも効果が違う
• (04:48) outsized performance、 小さいモデルで同等性能
• (05:30) スケール経済 (AT&T 数百万ドル例)、 レイテンシ制約 (0.5 秒)、 所有権
• (06:48) Agent 時代 = トークン増、 複雑性増、 エラー許容狭、 RL の歴史的優位
• (07:54) RL は元々 agent / robot 訓練のため、 環境こそが場所
• (08:42) 既存 agent あり vs 新規環境構築、 Manulife 事例
• (09:38) データ問題 (Web に存在しない)、 環境 = synthetic dataset 副産物
• (10:34) 顧客実会話 transcript を mock user 訓練に流用、 医療サプライの 「救急車呼んで」 例
• (11:25) RLHF の正体 = annotation campaign、 高コスト
• (12:00) reward signal の組み立て (systematic / KPI / LLM-as-judge)
• (12:55) 人間の役割は rubric 定義のみ、 数分〜数時間
• (13:35) RL は難しい、 PPO は 4 つの LLM を同時 orchestrate
• (14:18) Adaptive Engine が複雑性を pre-built recipe で隠蔽
• (15:00 -) Q&A: cursor の tab completion 用 implicit feedback について、 reward model のスケール化

出典

AI Engineer Europe 2026 公式 YouTube プレイリストより。 動画 ID は AI Engineer 公式チャネルで確認可能。

• AI Engineer Europe 2026 公式スケジュール
• Adaptive ML 公式
• Falcon (TII)

用語集

Adaptive ML / Adaptive Engine

大企業向け RL Ops (Reinforcement Learning Operations) プラットフォーム。 AT&T / Manulife / CCS 等の大企業が、 自社専用の特化型 LLM を構築・評価・本番運用するための holistic な platform。 公式: adaptive-ml.com

ラストマイルの神話 (The Myth of the Last Mile)

Cappelli の批判用語。 業界の通念 「MVP までが難しく、 production までは最後のひと押し」 を誤りとする主張。 実際は MVP は first mile、 真のマラソンは MVP → production → beyond。 prompt 変更も SFT も systematic な改善経路を持たないため、 ここで詰まる。

Falcon

2023 年に UAE の Technology Innovation Institute (TII) が発表したオープンソース大規模言語モデル。 当時最も広く採用された OSS の 1 つで、 Llama-2 と並ぶ位置にあった。 Cappelli はその訓練チームに所属、 そこで 「OSS を production に持ち込むには RL が不可欠」 という洞察を得て Adaptive ML 創業へ繋がる。

Outsized performance

RL の SFT に対する独自価値を Cappelli が指す表現。 同等の性能を SFT より遥かに小さなモデルで実現可能。 結果として推論コスト・レイテンシ・所有権の 3 つでビジネス影響を unlock する。

PPO (Proximal Policy Optimization)

RL アルゴリズムの代表。 1 つではなく 4 つの LLM を同時に orchestrate する必要がある (policy / reference / value / reward model)。 RL の実装複雑性の象徴。 Adaptive Engine はこれを pre-built recipe で隠蔽する。

LLM-as-judge

Open-ended な質的評価 (tone / business guideline 準拠等) を LLM に判定させる手法。 reward signal の構成要素の 1 つ。 rubric を人間が定義 → LLM が個別判定 → reward に変換、 という分業で human-in-the-loop を最小化できる。

Containment Rate

CCS (医療サプライ会社) の顧客サポート KPI。 「通話の何 % が agent 内で end-to-end 完結したか (人間にエスカレーションせず)」 を測る指標。 RL の reward として直接最大化される好例。