実世界の経験からの学習

Perplexity Computerモデルの事後トレーニングを行い、成功した行動の模倣、ユーザー修正の必要性の削減、およびツールエラーの回避を実現します。

著者Perplexity Research

ユーザーが現実世界で私たちの製品とどのようにやり取りするかは、モデルのトレーニングにとって貴重な情報源です。データは豊富であり、ユーザータスクの実際の分布を反映しており、合成環境では見落とされる可能性のあるユーザーの修正やツールの障害を捉えています。

現実世界のデータから学習するための一般的な方法は、拒否サンプリングファインチューニングです。各セッションの結果を評価し、成功したものを保持し、それを模倣するようにモデルをトレーニングします。しかし、成功した結果はすべてのステップが正しかったことを意味するわけではないため、軌跡全体を模倣すると、良い中間動作に加えて悪い中間動作も強化されるリスクがあります。失敗したセッションを破棄すると、モデルがどこで不足しているかという重要な証拠も失われます。

拒否サンプリングファインチューニングとヒントガイド付き自己蒸留を組み合わせて、成功したセッションと失敗したセッションの両方から学習します。ヒントとは、モデルが間違いを犯したときにすでに持っていた情報に基づく、短い修正命令です。成功したセッションからの有用なステップは模倣のターゲットとして残り、根拠のあるヒントは回避可能な間違いを修正のターゲットに変えます。

ユーザーの修正やツールのエラーは、タスクが最終的に成功したかどうかだけでなく、その過程で何がうまくいかなかったかについての監視情報も追加します。当社では、この段階を合成環境での強化学習の後に適用し、そうした環境と実際の使用環境とのギャップを埋めるサポートをしています。

実際の運用において、後からポストトレーニングを実施したGLM-5.2のチェックポイントでは、初期のトレーニング済みチェックポイントと比較して、ツール呼び出しの失敗が21.2%減少しました。GLM-5.3では、ポストトレーニングにより、ツール呼び出しの失敗が33.0%、中程度または高いユーザー不満度の平均推定確率がベースモデルと比較して17.2%減少しました。

合成データから現実世界のデータへ

合成タスクにより、検証が容易な結果を持つ制御された問題を作成できますが、通常は単一のプロンプトに限定されており、明示的に設計したシナリオしかカバーできません。

対照的に、現実世界のセッションのユーザーは、複数のターンのインタラクションを通じて展開するセッションに、多様な指示、コンテキスト、およびツールの組み合わせを持ち込みます。このような現実世界の使用により、間違いの2つの貴重なシグナルが自然に得られます。ユーザーの修正は、エージェントが求めていたものを提供できなかった場所を明らかにし、ツールエラーは、実際の環境でそのアクションがどのように崩壊したかを示します。私たちのサンプリングパイプラインは、個人特定情報（PII）を含むセッションやオプトアウトしたユーザーからのセッションを除外することにより、ユーザーのプライバシーとトレーニングの選択を尊重します。

したがって、現実世界のデータは、合成環境では露出しない可能性のある失敗ケースを提供し、多くの場合、失敗が発生した場所がすでに組み込まれた状態で提供されます。

良いステップを模倣し、悪いステップを修正する

現実世界のデータでトレーニングする場合、標準の拒否サンプリングファインチューニング（RFT）は、ユーザーやツールのフィードバックを明示的に使用して良好な中間アクションと不良な中間アクションを区別することなく、最終的な結果に基づいて成功したセッションを選択します。エージェントは、不良なツールコールから回復したり、ユーザーフィードバックの後に間違いを修正したりして、最終的に適切な出力を提供することができます。

失敗したセッションを破棄すると、サンプルの効率も制限されます。良好な結果に到達しなかったセッションであっても、明確で回避可能な間違いを有用なトレーニングシグナルとして明らかにすることができます。

これらの制限に対処するため、どのセッション模倣する価値のある動作を含んでいるか、どのターンが修正する価値のある間違いを含んでいるかという2つの決定を分離します。データパイプラインはこれらの決定を個別に下し、モデルのターンに次の3つの処理のいずれかを割り当てます。

  • 模倣: 成功したセッションのエラーではないターンは通常の交差エントロピー（CE）損失を受け取り、記録されたトークンの確率を上げます。
  • 修正: 成功したセッションと不成功のセッションの両方において、有効なヒントを持つエラーターンはKullback-Leibler（KL）発散損失を受け取り、ヒントを見たときに行う次のトークンの予測に向けてモデルを移動させます。
  • コンテキストとして保持: 検証済みのヒントがない不成功セッションのターン、およびどちらのセッションタイプでも検証済みのヒントがないマークされた不適切なターンは、コンテキストとして機能しますが、どちらの損失も受け取りません。

その結果、成功したセッションは模倣ターゲットと修正ターゲットの両方を提供できるのに対し、不成功のセッションは修正ターゲットのみを提供します。システム、ユーザー、ツール出力を含む残りのすべてのターンは、コンテキストとしてそのまま残ります。

現在のセッションルーティングとアシスタントコンテンツのマスク。成功したセッションは模倣ターゲットに貢献し、保持されたフィードバックレコードは、セッションが不成功であってもヒント付きの修正に貢献できます。その他のコンテンツはコンテキストとしてそのまま残ります。不完全なセッションは除外されます。最終的ではないyield/stop-token CE例外は描画されておらず、この図は以前のチェックポイントで使用された混合を示すものではありません。

模倣部分には標準のRFTを使用します。補正部分にはOn-Policy Self-Distillation（OPSD）を使用します。同じモデルが教師と生徒として機能し、教師には特権情報が与えられます。ここでは、その特権情報とは、回避可能な間違いを説明する短いヒントです。生徒モデルにヒントを渡すことなく、教師の次のトークンの予測に一致するようにトレーニングします。

両方の部分が重要です。補正のみのトレーニングでは近道が露出する可能性があります。つまり、教師モデルと生徒モデルは、修正を学習するのではなく、コンテキストを無視することで一致してしまう可能性があります。CE項はトレーニングを有用な動作に固定し、コンテキストを無視することから生じる一致を抑制するのに役立ちます。

ポストトレーニングを受けた生徒モデルは、Computerのモデルオプションになります。ライブ使用からの新しいセッションは、トレーニングパイプラインの別のラウンドに入る前に、同じ適格性フィルターとプライバシーフィルターを通過します。

例: 1つのセッションで両方の教訓を学ぶことができる

次に、模倣と修正の両方を含む具体的な例を見ていきます。

ユーザーが公式ドキュメントを使用してPython 3.13でのasyncioの変更の比較を求める、最終的に成功するセッションを考えてみます。私たちのツールドキュメントには、search.webがヒットのリストを返し、それぞれにurlフィールドが含まれていることが記載されています。

モデルは、比較の証拠を収集するプロセスの一環として、まず1つのバージョンの有効な検索を実行します。これは模倣するのに適した動作です。

しかし、次のコード実行呼び出しでは、そのリストが辞書として誤って扱われます。コードツールは TypeError: list indices must be integers or slices, not str を返します。戻り値の型は呼び出し前に文書化されていたため、モデルが回避できたはずの間違いです。そのアクションを修正するために、正しい呼び出しを含むヒントを生成できます。

説明的なコーディングセッションは、3つのトレーニングロールを示しています。コンテキスト専用の入力とツール出力（グレー）、有用な記録されたコールのCE模倣（ダーク）、およびマークされた間違いのKL修正（ティール）。ここでは、モデルが検索ヒットのリストを辞書として誤って扱っています。以前のツールドキュメントにグラウンディングされた教師専用のヒントが修正をガイドします。完了したセッションが成功と判断された場合にのみCEターゲットが適用され、不成功のセッションでも適格なKL修正ターゲットを提供できます。

トレーニングの仕組み

トレーニングパイプラインには4つのステージがあります。セッションを選択して結果を評価する、ユーザーフィードバックやツールエラーから間違いを特定してヒントを作成する、教師モデルと生徒モデルの両方から次のトークンの確率を生成する、そして組み合わせたCEおよびKL損失でモデルをトレーニングする。

セッションを選択し、結果を評価する

サンプリングパイプラインは、GLM 5.2 によって提供される実世界の Computer セッションのうち、学習対象となるサブセットからデータを取得します。学習オプトアウトと、パイプラインの PII に関連する除外は、このワークフローで例を選択する前に適用されます。

初期スクリーニングプロセスでは、LLMジャッジによる5段階のタスク難易度スケールで4または5と評価された候補を選択し、2つのグループに分割します。

  • ユーザーフィードバックグループには、実際のユーザーのフォローアップまたは中～高の不満フラグを持つセッションが含まれています。ユーザーはタスクを完了しようと積極的に試みており、その修正によってモデルが見落としたものが正確に指摘されるため、これらの高意図のフォローアップは学習に特に役立つことがわかりました。
  • ツールエラーグループには、認識されたインフラストラクチャの障害や拒否された承認を除き、ルールベースのチェックによってフラグが付けられた失敗した呼び出しが含まれるセッションが含まれます。

続いて、2つのLLMジャッジがユーザーのリクエストに対して最終的な出力を評価します。セッションを「成功」と見なすには、両方のジャッジが肯定的な判定を下す必要があります。アーティファクトを出力するケースでは、成果物ステージで出力の再構築と検証を行い、そのステージが失敗した場合はテキストベースの判定にフォールバックします。ユーザーからの応答待ちなどの不完全と分類されたセッションは除外されます。

このステップでは、学習シグナルの潜在的な発生源を特定しますが、あいまいな指示やインフラストラクチャの障害に起因するものもあるため、すべてのエラーがモデルに起因するわけではありません。その後の注釈によって、どの候補の間違いが実際に回避可能であり、トレーニングに適しているかが決まります。

ユーザーフィードバックから間違いを見つける

ユーザーフィードバックグループのサンプルセッションを考えてみましょう。ユーザーが「How do I find my w3 on paychex（Paychexでw3を見つけるにはどうすればよいですか）」と尋ねます。モデルは「w3」をW-2のタイポ（入力間違い）として扱い、W-2の指示を検索し、そのフォームの探し方を説明します。ユーザーのフォローアップである「I meant the W-3 transmittal form（W-3送付フォームのことです）」によって、セッションが最終的に成功した場合でも、間違いが特定されます。

苦情は間違いを特定するのに役立ちますが、根本原因は「w3」をW-2と再解釈するという以前の決定です。元のリクエストにより、間違いが回避可能になります。モデルはW-3を保持するか、説明を求めることができました。苦情の直前のアシスタントのターンが根本原因になるのは、約半分のケースにすぎないことが判明しています。

私たちの注釈パイプラインは、各ユーザーフィードバックセッション内で原因と結果を体系的にマッピングします。アノテーターはまず、見落とされた要件や、以前のコンテキストによってサポートされている意図がないかスクリーニングします。次に、3つのLLMジャッジが担当するターンを特定し、特定のターンについて少なくとも2つが同意することを求めます。以前のステートメントが要件を明示的に確立している場合もあります。他のケースでは、単一の先行ステートメントがそうするわけではありませんが、先行する会話の複数の部分が結合されて、意図された動作が推論可能になります。この設計により、最後の回答のみに起因するのではなく、苦情を以前の根本的な間違いに結びつけることができます。

ヒントを受け入れる前に、パイプラインはその修正の主張が、マークされたターンの前に利用可能な情報から導き出されていることも確認します。これらのチェックは、苦情で明らかにされた新しい好みが、モデルがすでに知っていたはずのものとして扱われる、後知恵バイアスを減らすことを目的としています。

この例では、ヒントは、W-2ではなくPaychexでW-3送付フォームを検索するようにモデルに指示するか、リクエストがあいまいな場合はユーザーがどのフォームを意図しているかを尋ねるように指示します。修正は、最終的な回答だけでなく、以前の解釈と検索の決定をターゲットにします。元のターンは変更されません。注釈によって is_bad_turn: true と空ではない hint が追加されます。

苦情が以前の間違いまでどのようにたどられるかを示す実際のセッション。注釈手順がオーバーレイされている。ユーザーはPaychexで「w3」を求めたが、モデルはそれをW-2のタイポとして扱い、間違ったフォームを検索した。提案者の合意により根本原因が特定され、2つのグラウンディングチェックによって、証拠が間違いの前に存在していたか、およびヒントの主張がその時点で利用可能な情報から導き出されているかどうかが評価される。受け入れられた注釈は、書き換えられたターゲットではなく、元のテキストを保持し、マークとヒントを追加します。

ツールエラーから間違いを見つける

エージェントが recency_filter: "year" で検索を実行する検索呼び出しを含む、ツールエラーグループ内の別のセッションを考えてみますが、許可された値が「day」、「week」、「month」であるため、ツールによって拒否されます。これは明らかなスキーマ違反です。

ツールエラーパスでは、既知の間違いには決定論的ルールを使用し、あいまいなケースにはモデルの判断を使用します。エラーメッセージだけでは、モデルを非難するには不十分です。ジャッジされた修正は、ツールスキーマ、システムインストラクション、または以前の会話からモデルが知っていたはずの何かを指している必要があります。

レポートの無効な検索引数は、現在のツールエラーの手順を示しています。スキーマがあるためこの間違いは回避可能ですが、単なる障害であれば回避できませんでした。元の呼び出しはレコードに残り、グラウンディングされたヒントを受け取ります。フィールドがオプショナルである場合、ヒントによってリストされた値の使用または省略が許可されます。すべてのリクエストに「month」が必要なわけではありません。

ユーザーの修正とツールエラーにより、タスクが最終的に成功したかどうかに加えて、途中で何がうまくいかなかったかについてのスーパービジョンが追加されます。合成環境での強化学習の後にこのステージを適用し、それらの環境と現実世界の使用の間のギャップを埋めるのに役立てます。

2つのフォワードパス

ターンがマークされると、トレーナーは同じチェックポイントを2回実行します。1回目は教師として、2回目は生徒としてです。教師にはヒントが表示されますが、生徒には表示されません。

両方のパスでティーチャーフォーシングを使用します。新しいトークンを選択させる代わりに、モデルに記録されたセッションを入力します。フォワードパスは各ステップで完全な次のトークンの分布を生成しますが、ロールアウトトークンではなく、常に記録からの固定プレフィックスに条件付けられます。

検索の例では、ヒントが与えられた場合、同じモデルは「month（月）」に対してはるかに高い確率を割り当て、「year（年）」に対する確率は低くします。トレーニングでは、この分布のシフトをソフトターゲットとして使用します。

2つのパス、1つの重みセット。両方のパスでログに記録された継続がスコアリングされますが、ヒントを受け取るのは教師モデルのみです。そのデタッチされた次のトークンの確率は、フォワードKLを通じて生徒モデルをガイドします。個別のCEターゲットが模倣を固定します。両方の損失が1つの重み更新にフィードされます。以前のヒントは教師モデルの現在のセグメントに残る可能性がありますが、どちらのパスも代替のトレーニング回答を生成しません。

教師モデルの予測はデタッチ（切り離し）、またはストップグラエディント（勾配停止）されます。これらはターゲットを提供しますが、教師モデルのパスを通じて更新を受け取ることはありません。生徒モデルのパスの後に、1つのオプティマイザーステップが共有モデルを更新します。

損失関数

CE損失

CE損失は、模倣のために選択された記録されたトークンをグランドトルース（正解）のターゲットとして扱い、それらに低い確率を割り当てたモデルにペナルティを課します。これにより、ハードな模倣ターゲットが作成されます。

トークン位置 において、完全な語彙 内のトークン に対する生徒モデルの確率を とします。応答またはツール呼び出しにおける記録された次のトークンは であり、ワンホットターゲット分布は です。iipi(v)p_i(v)vvVVyiy_irir_i

ri(v)=1[v=yi]r_i(v)=\mathbf{1}[v=y_i]

交差エントロピーは、生徒モデルがその記録されたトークンをどれだけうまく予測するかを測定します。ワンホットターゲットを使用すると、yiy_i に割り当てられた負の対数確率に簡略化されます。

H(ri,pi)=−∑v∈Vri(v)log⁡pi(v)=−log⁡pi(yi)H(r_i,p_i)=-\sum_{v\in V}r_i(v)\log p_i(v)=-\log p_i(y_i)

CEマスク miCEm_i^{\mathrm{CE}} は、トークンを模倣すべき場所では 11 であり、そうでない場所では 00 です。選択された位置にわたって合計すると、模倣損失が得られます。

LCE=∑imiCEH(ri,pi)\mathcal{L}_{\mathrm{CE}}=\sum_i m_i^{\mathrm{CE}}H(r_i,p_i)

KL損失

KL損失では、ソフトな補正ターゲットとして、教師モデルの完全な次のトークンの確率分布 qiq_i が代わりに使用されます。教師モデルのコンテキストには、現在のヒントと、そのトレーニングセグメント内で保持されている以前のヒントが含まれます。生徒モデルのコンテキストは常にヒントなしです。

KLマスク miKLm_i^{\mathrm{KL}} は、トークンを修正すべき場所では 11 であり、そうでない場所では 00 です。CEマスクとKLマスクはオーバーラップしません。これらの位置では、フォワードKLにより、語彙全体にわたる教師モデルと生徒モデルの間の不一致にペナルティが課されます。

LKL=∑imiKLDKL(qi∥pi)=∑imiKL∑v∈Vqi(v)log⁡qi(v)pi(v)\mathcal{L}_{\mathrm{KL}}=\sum_i m_i^{\mathrm{KL}}D_{\mathrm{KL}}(q_i\Vert p_i)=\sum_i m_i^{\mathrm{KL}}\sum_{v\in V}q_i(v)\log\frac{q_i(v)}{p_i(v)}

組み合わせ損失

両方の項は、別々に正規化されるのではなく、1つの分母を共有します。この分母は、グローバルなトレーニングバッチ全体で模倣のために選択されたトータルのトークン数をカウントします。重み λ\lambda は、模倣に対する補正トレーニングの寄与を制御します。

この共有正規化は、トレーニングインフラストラクチャの単一分母インターフェイスに適合し、λ=0\lambda=0 のときに標準のSFT損失を回復するため、ベースラインの比較が簡素化されます。CEトークンはKLトークンよりもはるかに豊富であるため、共有分母を使用することで、マークされたトークンが少ないバッチで個々のKLトークンに不均衡に大きな重みが与えられることも回避されます。

L=LCE+λLKL∑imiCE\mathcal{L}=\frac{\mathcal{L}_{\mathrm{CE}}+\lambda\mathcal{L}_{\mathrm{KL}}}{\sum_i m_i^{\mathrm{CE}}}

以前の例に適用すると、W-3/W-2の混同と無効な検索呼び出しを含むターンがKLを受け取ります。成功したセッション内の他のお墨付きのないアシスタントコンテンツは、引き続きCEを受け取ります。不成功のセッション内のその他のお墨付きのないアシスタントコンテンツは、コンテキストとして保持されますが、CEもKLも受け取りません。

評価が示していること

私たちの評価は、2つの別々の質問に答えるものです。第1に、ヒントが存在する場合、ヒントは実際にモデルがエラーを修正するのに役立つか？第2に、トレーニングは、ヒントなしで、モデルがそのエラーを後で回避するのに役立つか？1つ目は、ヒントが有用なトレーニングシグナルを提供するかどうかをテストします。2つ目は、モデルがそれらから学習するかどうかをテストします。

ヒントにより、モデルの間違いを回避するように誘導できる

ヒントが本当にモデルの間違いを回避するよう誘導できることを確認するため、トレーニングの実行前に最初の質問をテストします。

ユーザーフィードバック

温度ゼロの同じGLM-5.2ベースモデルを使用して、ヒントありおよびヒントなしで、マークされたユーザーフィードバックのターンを再生成しました。ブラインドジャッジには、その後の苦情は表示されますが、ヒントやどの条件で回答が生成されたかは表示されません。

W-3の例では、プレフィックス「W-」の後に、ヒントによって次のトークンの確率が「2」から離れ、「3」に向かってシフトします。

ヒントにより、要求されたW-3の形式が保持されます。バーは8つのフォワードパスにわたる平均の次のトークンの確率を示し、ヒゲは信頼区間ではなく観測された範囲を示しています。両方の条件で変更されていないベースモデルが使用されます。

明示的に述べられた以前の証拠によって裏付けられた、より大規模な40ターンのホールドアウトサンプルでは、修正されたまたはオントラックと判断された割合が、ヒントなしの40.0%からヒントありの75.0%に上昇します。推論された意図に裏付けられた別の40ターンでは、32.5%から80.0%に上昇します。

ポストトレーニングの評価ではなく、ヒントの検証。各証拠グループ内の同じ40個のマークされたターンが、温度ゼロの変更されていないGLM-5.2を使用して、ヒントありおよびヒントなしで再生成されます。ジャッジには苦情は表示されますが、ヒントや条件は表示されません。カウントはレポートのレートとサンプルサイズから導出されたものであり、信頼区間は報告されていません。

ツールエラー

検索ツールのエラーの例では、ヒントによって、確率の質量がyearトークンからmonthトークンに実際にシフトします。

ヒントにより、確率が許可された値に向かってシフトします。バーは8つのフォワードパスにわたる平均の次のトークンの確率を示し、ヒゲは信頼区間ではなく観測された範囲を示しています。両方の条件で同じベースモデルが使用されており、トレーニング済みチェックポイントとの比較ではありません。

より大規模な985ターンのホールドアウトサンプルで、同じベースモデルを使用し、ヒントありおよびヒントなしで各ターンを4回再生成しました。ブラインドジャッジは、各再生成が元の失敗を回避しているかどうかを評価します。ヒントにより、失敗の回避率が75.1%から93.7%に上昇し、18.6パーセントポイントのペアのゲインが得られ、修正されたアクションを取る割合が60.6%から82.3%に増加します。サンプリングの繰り返しだけでは修正が難しいエラーに対して、改善効果が最も大きくなります。

条件ごとに4回再生成を行った、985個のホールドアウトされたマークされたターンに対するツールエラーのヒントの検証。バーは、ヒントの有無にかかわらず、変更されていないベースモデルの失敗回避率と修正アクション率を示しています。ターゲットとなる間違いを回避しても、ツール呼び出しやタスクの成功が保証されるわけではありません。

トレーニング後のツールの信頼性とユーザーフィードバック

次に、学習済みモデルがヒントを受け取らなくても誤りを減らせるかどうかをテストします。オフラインのベンチマークタスクと実際のユーザーセッションで、標準モデルおよびさまざまなポストトレーニングのチェックポイントを評価し、ツールの失敗の減少とユーザーの不満の軽減を確認します。

オフライン評価

オフライン評価では、BrowseComp、Finch、WideSearch、DRACO、DSQA、SpreadsheetBench、HLE、および代表的なComputerのタスクセットを使用し、スキルのロード、ドキュメントレビュー、およびインライン引用を確認します。評価の軌跡全体で、結果が明示的にエラーとしてフラグ付けされたツール呼び出しの割合を測定します。

これらの評価において、記録されたツールエラー率は、ストックのGLM 5.2で2.79%、RFTのみのチェックポイントで1.35%、RFT＋OPSDチェックポイントで0.87%でした。これらのチェックポイントは異なるデータでトレーニングされているため、これはOPSDのデータ一致アブレーションではありません。タスクレベルのベンチマーク結果はさまざまであったため、ツールエラーが減ったからといって、必ずしもタスクの成功における幅広い改善につながるとは限らない。

ストックのGLM-5.2、RFTのみ、およびRFT＋OPSDチェックポイントのオフラインツールエラー率。トレーニングデータはチェックポイント間で異なり、これは制御されたアブレーションではありません。

オンライン評価: GLM-5.2

GLM-5.2では、各条件に約10万人のユーザーを配置した2つの独立したA/Bテストを実施しました。1回目のテストでは、初期のRFT-plus-OPSDチェックポイントのツール障害率が標準GLM 5.2の2.94%に対して2.82%とわずかに低かったものの、その差は統計的に有意ではありませんでした。

後のテストでは、2つのRFT＋OPSDチェックポイント（初期のもの（チェックポイント1）と後のもの（チェックポイント2））を比較しました。ステータスが記録された呼び出しのうち、ツール呼び出しの失敗は2.24%から1.77%に減少しました。これは、統計的に有意な21.2%の相対的な削減でした。チェックポイント2とストックのGLM 5.2をオンラインで直接比較することはしませんでした。

ユーザーフィードバックの結果はそれほど決定的ではありませんでした。2回目のGLM-5.2の実験では、強い不満（中または高）の平均確率は、チェックポイント1が2.58%、チェックポイント2が2.54%であり、統計的に有意な差はありませんでした。

GLM-5.2の2つの独立したライブA/Bテスト。チェックポイント1は標準のGLM-5.2と比較され、チェックポイント2はチェックポイント1と比較されています。これら2つのテストのうち、後のツール障害軽減のみが統計的に有意です。MID+率は、クレート数ではなく、中程度または高度な不満の平均推定確率を表しています。

オンライン評価：GLM-5.3

GLM-5.3について、ポストトレーニング済みのチェックポイントと標準のGLM-5.3を直接比較しました。ステータスが記録された呼び出しのうち、ツール呼び出しの失敗は3.56%から2.38%に低下し、33.04%の相対的な減少となりました。中程度または高い不満度の平均推定確率であるMID+率は、4.12%から3.41%に低下し、17.2%の相対的な減少となりました。どちらの減少も統計的に有意でした。

別個のオンラインA/Bテストにおける、ポストトレーニング済みGLM-5.3と標準GLM-5.3の比較。ツール失敗率、MID+率、相対的変化、および95%逐次信頼区間にはCUPED調整が適用されています。どちらの減少も統計的に有意です。MID+率は、苦情の件数ではなく、対象となるスコア付きのフォローアップスレッド全体における中程度または高い不満度の平均推定確率です。ツール失敗率は、成功または失敗のステータスが記録されていない呼び出しを除外しています。

結論

中心となるアイデアは、セッション単位だけでなく、決定のレベルで学習することです。

成功した結果は間違いを隠すことができ、不成功のセッションでも改善方法が明らかになることがあります。成功したセッションからの有用な動作をアンカーとして保持し、苦情やツールエラーを使用して回避可能な失敗を特定し、それらの間違いや修正が明示されたときに行う予測に向けてモデルをトレーニングします。成功は保存するべき動作を提供し、失敗は改善のための方向性を提供します。

現実世界の使用により、このアプローチは特に有用なものとなります。実際のユーザーは、合成環境で予測することが困難な目標、制約、およびワークフローを持ち込みます。ユーザーの修正はモデルが見落とした要件を明らかにし、ツールエラーはモデルが試みたことと環境が許可していることの間のギャップを露出させます。これらのシグナルは、アウトカムベースのトレーニングを補完します。タスクが成功したかどうかだけを尋ねるのではなく、モデルの何が間違いだったのか、そしてどのような情報があればより良い決定を下すのに役立ったのかを尋ねることができます。

制限事項も同様に重要です。評価者が間違えることもあり、1ターンの修正がタスク全体の成功を保証するわけではありません。目標は、単に修正後に回復するエージェントを作ることではありません。修正の必要性がより少ないエージェントを作ることです。

引用

BibTeX
@online{perplexity2026LearningFromRealWorldExperience,
  author = {{Perplexity} and Senzeyu Zhang and Chuan Wang and Hang Wu and Hao Zhang and Yuan Liang and Yunfan Zhong and Phi Hoang and Claire Beamer and Jeremy Yang and Andrew Wilson and Denis Yarats},
  title = {{Learning from real-world experience}},
  date = {2026-09-21},
  url = {https://www.perplexity.ai/hub/blog/learning-from-real-world-experience}
}