8,009 文字
こんにちはコミュニティの皆さん。今日はクロード3.7ソネットの新しいツール「シンク」についてお話しします。これは新しい同期ツールのように聞こえるかもしれませんが、実際は1ヶ月前にクロードが発表した拡張思考とは少し異なります。ただし、関連性はあります。説明しましょう。
この動画で以前お見せしたように、ソネット3.7は32kや64kコンテキストでの拡張思考機能を持っています。これは「拡張思考」と呼ばれるものです。この仕組みですが、まず訓練時間があり、事前訓練、教師あり微調整、強化学習のRLHFがあります。そして推論時間では、ユーザークエリが入力され、ここで「テスト時計算スケーリング」（TTS）が行われます。これは推論モデルとも呼ばれ、DeepSeekのR1、OpenAIのO1、スタンフォード大学のS1、あるいは長いチェーンオブソートモデルとも呼ばれます。Anthropicではこれを「拡張思考モデル」と呼んでいます。つまり、特定のクエリに対して、AIが本当に考えるために2分か20分か待つ必要があるということです。
では、この新しい「シンク」ツールはどう位置づけられるのでしょうか？テスト時計算スケーリングの領域内にありますが、途中で呼び出すことができます。これは単体のツールであり、他の外部ツールとも関連しています。
ではこの動画を開いて詳しく見てみましょう。ここにソネット3.7の説明があります。彼らは「このツールはソネットの複雑な問題解決能力を向上させる」と述べています。パフォーマンスを向上させるものには常に興味があります。「構造化された思考のための専用スペースを作成するツール」とあります。これは興味深いですね。ツールが数学的空間を作るというのは、ベクトル空間なのか、テンソル空間なのか、どんな構造化された空間なのでしょうか？
さらに「クロードのエージェント的ツール使用能力に著しい改善」をもたらすとされています。ここで別のヒントが得られます。これはツール使用と拡張思考に焦点を当てています。特定のポリシー遵守、一貫した決定、多段階推論問題の処理を含むとのことです。
Anthropicの説明によると、「シンクツールによってクロードに追加の思考ステップを含める能力を与えている」とのことです。これは興味深いですね。テスト時計算では数百や数千のGPUで継続的に思考していますが、ここに追加の思考ステップを加えるわけです。また、「シンクツールはクロードが応答生成を開始した後、先に進むために必要な情報がすべてあるかどうかについて立ち止まって考えるためのステップを追加するためのものです」とあります。これは「長いチェーンのツール呼び出しを実行する際に特に役立つ」と述べています。
つまり、7つの異なるツールから並列入力を受け取り、ツール呼び出しが結果を返した後、LLM全体に停止コマンドを出して、「構造化された知識のためのスペースを作成するので、これを分析してパフォーマンスを向上させることができます」というわけです。興味深いですね。
Anthropicによれば、拡張思考はコーディング、数学、物理学などのユースケースに適しているとされています。しかし、物理学では異なるライブラリを呼び出したり、仮想実験のためにC++環境を使ったりするので、実際には多くのツール呼び出しが必要です。
この新しいツールは、クロードが複雑なツールを呼び出し、ツール出力を分析し、長いチェーンのツール呼び出しで結果をナビゲートし、詳細なガイドラインを持つポリシー重視の環境をナビゲートする必要がある場合に適しているとされています。この時点で、単に何かを返すだけでなく、特定のポリシーガイドラインに従う必要があることがわかります。
そこでSierra Researchの論文を読むと理解が深まりました。2024年6月17日に発表された「TooBench」という論文です。これはツール・エージェント・ユーザー・ツール相互作用のためのベンチマークで、「最先端の関数呼び出しエージェントでもタスクの50%未満でしか成功しない」と述べています。
関数呼び出しエージェントはそれほど成功率が高くないということです。SQLデータベースに対するハードコードされた問い合わせと違って、AIエージェントが使用する関数呼び出しは必ずしも確実ではありません。関数呼び出しは人工知能とデータベースの間の橋渡しに過ぎず、橋の上で何のコマンドが渡されるかは人工知能次第であり、私たちがハードコードするわけではないのです。
Sierra ResearchのGitHubページ「TooBench」を見ると詳細な説明があります。彼らはTooBenchのエージェントが失敗する主な3つの理由を挙げています：
A. 構造化データに対する複雑な推論：エージェントは時々ツール呼び出しに誤った引数を入力したり、必要な詳細を省略したりします。これはSQLへのテキスト変換やシステムの機能に必要なフィールドが欠けていることで失敗につながります。
B. エージェントは頻繁に誤った決定を下し、提供されたルールをすべて遵守しないことがあります。システムを扱うためのルールや条件がエージェントによって確実に強制されなければ問題が発生します。エージェントが意思決定プロセスにドメインポリシーを統合していなかったのです。
C. 複合リクエストの処理：タスクが複数のステップを必要とする場合、エージェントは時々タスクを部分的にしか完了しないことがあります。エージェントが「50%完了したからもういいや」と判断するようなものです。訓練データの確率分布において、次のトークンがアクションではなく終了トークンだった場合、エージェントは停止を決定するかもしれません。途中で停止すれば全体的な失敗となります。
この研究論文は重要でした。また、TooBenchの著者たちは1年前に「関数呼び出しエージェントに思考機能を追加する実験をしたが、パフォーマンスを向上させなかった」と述べていました。これはまさにAnthropicが今ソネット3.7に行ったことです。なぜ当時は効果がなく、1年後の今は50%以上のパフォーマンス向上があるのでしょうか？
TooBenchの核心的アイデアを理解するためには、次のセットアップを見る必要があります。ユーザー（知的な大規模言語モデルでシミュレートされる）がいて、例えば航空会社の予約エージェントがいます。このエージェントには特定のポリシーが実装されており、システムプロンプトには航空会社のルールや規制がすべて含まれています。例えば「基本エコノミー運賃は予約後24時間経過後はキャンセルできない」などの25の異なるルールがあります。
これが「ドメインポリシー制約」と呼ばれるものです。ユーザーが航空会社の予約エージェントと対話する場合、このドメインポリシーを正確に実装する必要があります。エージェントはAPIコール、関数呼び出し、ツール使用能力を持っており、フライト情報データベース、予約データベース、支払いデータベースなどへのアクセスが可能です。
ここで例として、ユーザーが「フライトを変更したい。サンフランシスコではなく同じ日にLAに飛びたい」と言ったとします。ボットは内部フライトデータベース、予約データベースにアクセスし、その人のID用の予約詳細を取得します。データベースを読み取り、予約の詳細をすべて取得します。そして「お客様は基本エコノミーを予約されましたが、これは変更できません。ただし24時間以内なのでキャンセルして新しく予約することはできます。これでよろしいですか？」と返答します。
成功した予約の各ステップの詳細な例を見てみましょう。これにより、エージェントとデータベース間、およびエージェントとユーザー間のすべての相互作用と、すべてがどのように通信されるかが分かります。
ユーザーの指示：「ニューヨークからシアトルへの特定の日付のフライトが必要です。午前11時前のフライトは避けたいです。エコノミーで飛びたいです。」
アシスタント：「こんにちは、お手伝いします。ユーザーIDを教えていただけますか？」
ユーザー：「私のユーザーIDは○○です」
アシスタント：「ありがとうございます。さらに詳細が必要です。片道または往復ですか？出発日はいつですか？何クラスで旅行されますか？乗客の数は？旅行保険を購入されますか？」
ユーザーが回答し、アシスタントはその人のIDを取得して「get_user_details」関数を実行します。ツールは名前、住所、Eメール、支払い方法、クレジットカード情報などのすべての結果を返します。
次にアシスタントは、特定の出発地と目的地間の直行便を検索する関数を定義します。ツールは利用可能なフライト番号とすべてのデータを返します。
アシスタントはユーザーに利用可能なフライトの詳細（出発、到着、空席、価格）を提供し、どのフライトを予約したいか確認を求めます。
ユーザー：「少し早すぎますね。午前11時以降のフライトは可能ですか？」
アシスタントは新しい関数を定義し、特定の日にJFKからシアトルへの乗り継ぎ便を検索し、フライト情報データベースから利用可能なすべての情報を取得します。
アシスタント：「複数のオプションを見つけました。フライトオプション1は最初の区間がこれで、2番目の区間がこれです。フライトオプション2は…どのフライトを予約されますか？」
ユーザー：「最初のオプションで行きます」
アシスタントは予約の詳細と支払い方法を確認します。
ユーザー：「予約情報は正確ですが、支払いには2つの旅行証明書を最初に使用したいです」
アシスタント：「安全上の理由から、1つの予約につき1つの旅行証明書しか使用できません。支払い詳細は次の通りです。続行しますか？」
この時点でアシスタントは特定のポリシーを実装する必要があることを認識しています。ユーザーの希望に従うことはできませんが、ルールを説明します。
ユーザー：「はい、確認します。支払い手続きを進めてください」
アシスタントは利用可能なすべての情報、日付、フライト、支払い方法を含む予約関数を実行します。
ツールは予約が完了したことを確認し、アシスタントはユーザーに予約の詳細を提供します。
これが完璧なプロセスの例ですが、AIシステムが正しい情報を入力しなかったり、入力フィールドを混同したり、必要なすべての情報を提供しなかったりする可能性があります。特定の時点でシステムが幻覚を始めたり、アクションではなく削除トークンで続けることを決定したりして、ループに陥る可能性があります。多くのことが間違う可能性がありますが、これが完璧なプロセスです。
Anthropicの発表に戻りましょう。「シンクツール：複雑なツール使用状況でクロードが停止して考えることを可能に」というものが2025年3月（4日前）に公開されました。現在はソネット3.7でのみ確認していますが、おそらく他のクロードモデルでも機能する可能性があります。
実装は標準的なツール仕様形式JSONを使用しています：
名前：シンク
説明：何かについて考えるためにツールを使用します。新しい情報を取得したりデータベースを変更したりすることはなく、ログに思考を追加するだけです。キャッシュメモリに対する複雑な推論が必要な場合に使用します。
これで理解できました。これは基本的に追加メモリで、ログに情報を追加するだけです。入力スキーマは「sort」プロパティを持つオブジェクトで、それは単なる文字列です。つまりスクラッチパッドですが、どうしてこのスクラッチパッドがソネット3.7のパフォーマンスを50%向上させることができるのでしょうか？
公式のクロードソネット3.7パフォーマンス論文から重要な詳細を見てみましょう。航空会社のタスク「フライトの再予約」について、青色のグラフがベースラインパフォーマンス、黄色がピュアシンキングツールのパフォーマンスで、これはベースラインよりわずかに良い程度です。オレンジ色の線は1ヶ月前に発表された拡張思考（テスト時計算スケーリング、2分間の思考）です。そして最も良いパフォーマンスラインは「シンクツール＋プロンプト最適化」です。
ここで理解しました。シンクツールだけを与えてもベースラインと比較してほとんどパフォーマンス向上はありませんが、シンクツールとプロンプト最適化を組み合わせ、プロンプト最適化で検証や反証を行うためのメモリ割り当てを行うと、シンクツールは意味を持つようになります。ベクトル空間ではなく、単に文字列を保存するスペースを開くだけです。
航空会社ドメイン例の最高のパフォーマンスは、シンクツール（スクラッチパッド）と最適化されたプロンプトを組み合わせることで達成されました。この最適化されたプロンプトは、使用する推論アプローチの例を提供します。最適化されたプロンプトは、顧客リクエストを分析する際にシステムに適用して欲しい推論タイプの例を与えますが、これはポリシーテンプレートであり、手順の構造化された順序付きフローです。これはプロンプト内の文脈内学習に直接的に短い例をいくつか提供するものです。
シンクツールと最適化されたプロンプトの例を見てみましょう。シンクツールはスクラッチパッド、新しいスペース、新しいメモリとして使用されますが、単なる情報ではなく、非常に専用のシーケンスを供給します。
たとえば：
現在のリクエストに適用される特定のルール、フライト再予約のポリシーガイドラインをリストアップする
必要な情報がすべて収集されているか確認する
計画されたアクションがシステムプロンプトで定義されているすべてのポリシーに準拠していることを確認する
ツール結果の正確性を反復的に確認する
これは単なるスクラッチパッドではなく、最適化されたプロンプトが本当に付加価値とパフォーマンス向上をもたらしています。
最適化されたプロンプトの例を見てみましょう：
例1：ユーザーがフライトABCをキャンセルしたいと言っています。ユーザーID、予約ID、およびキャンセルに有効な理由があるかどうかを確認する必要があります。システムはメモリで「キャンセルルールを確認し、航空会社のポリシーを確認し、予約から24時間以内かどうかを確認し、そうでない場合はチケットクラスと保険を確認し、まだ搭乗していないセグメントや過去のセグメントがないことを確認する」という手順を踏みます。
例2：ユーザーが各2つのチェックイン荷物を持つニューヨーク行きの3枚のチケットを予約したいと言っています。ここでも最適化されたプロンプトがソネット3.7のパフォーマンス向上をもたらしています。ユーザーIDや荷物計算（エコノミークラスの3人の乗客、1人の通常会員、1人のシルバー会員、1人のゴールド会員など）、支払いルールの確認などの完全なポリシー実装と、明確な手順での進め方の計画があります。
これは2年前の古典的なICL（In-Context Learning）プロンプトに非常に似ています。Anthropicが実装したのは古い友人のようなもので、数学的空間から追加されたメモリですが、このメモリには航空会社の例のポリシーガイドラインに従い、それが有効かどうかを確認するための明確な指示があります。
シンクツールと最適化されたプロンプト（航空会社の例のポリシーガイドラインを実装している）の組み合わせにより、より高い複雑性のタスクを解決できるようになりました。
これを逆に考えると、ソネット3.7は思考ツールとドメイン固有の最適化されたプロンプト（会社のポリシーガイドラインを含む）がなければ、予約タスクや飛行機のキャンセルに推論や実行を失敗していたのでしょうか？これは市場の他のモデルと比較して、ソネットがエージェントパフォーマンスでどこに位置するのか疑問に思わせます。
要約すると、ソネット3.7は単に追加の別個の思考スペースと追加ガイダンスを持つことで改善されました。少しのメモリと特定のユーザータスク、特定の会社、特定の再予約またはキャンセルフライトなどの特定のテンプレートがあるだけです。
Anthropicはこのシンクツール（単なるスクラッチパッド）をいつ使用するべきかの指示を提供しています：
クロードが行動する前に以前のツール呼び出しの出力を慎重に処理する必要があり、アプローチをバックトラックする必要がある場合（ログファイルを持っている）
ポリシー重視の環境でクロードが詳細なガイドラインに従い、ログファイルとテンプレート指示によるコンプライアンスを検証する必要がある場合
各アクションが前のアクションに基づいている場合（クレジットカードが検証され、次に特定のフライトを予約する場合など）
公式研究によれば、Anthropicはシンクツールがポリシー遵守と長いチェーンのツール呼び出しでの推論を必要とする複雑なタスクでクロード3.7ソネットのパフォーマンスを大幅に向上させることができることを実証しました。
私は正直、これがすでにソネット3.7に実装されていると思っていました。ソネットは新しいモデルで、すでにこれらのツール呼び出しやツール呼び出しの連鎖に最適化されていると思っていましたが、シンクツールと新しい最適化されたプロンプトの組み合わせの新発表により、明らかになりました。
最適化されたプロンプトはエージェントに必要なすべてのルールを提供し、シンクツールはエージェントが提供されたルールに対して作業をチェックするのを助けます。
私の理解では、純粋なシンクツールは単に10個のボックスをチェックするスクラッチパッドであり、これらの10個のボックスはオンラインでフライトを予約するための航空会社のポリシー実装です。
もう少し深く考えると、これはルール遵守に関するものですが、人工知能の時代におけるルール遵守は本当に望むものではありません。私たちは正しい道を進む、特定のフライト予約やキャンセルプロセスのための正しい実装の内在的理解を持つ人工知能を望んでいます。
エージェントが真に恩恵を受けるためには、さらなるトレーニングや、そのような中間的な反省プロセスの使用を奨励するためのアーキテクチャの修正が必要かもしれません。これにより、外部ツールとルール遵守規則を実装する必要がなくなります。
これで私の質問につながります。クロード3ソネットは他のモデルと比較してどの程度進歩していますか？推論において内在的に自己反省的ですか？ソネット3.7は訓練データセットで内部自己検証のトレーニングを受けていますか？ソネット3.7は内部自己修正能力を持っていますか？もしこれらのことがあれば、シンクツールとルール遵守およびポリシー実装を適用した場合のパフォーマンス向上は、それほど重要ではないでしょう。
また、クロードが4日前にウェブ検索ができるようになったという発表があったことに気づきました。私はクロードやAnthropicの専門家ではありませんが、これはAIシステムに広く実装されている機能だと思っていました。クロードがこの特定の機能を4日前に達成したことを知って驚きました。
もしこの関数呼び出しの特殊性、自己反省、自己検証に関する経験がある方、特にクロードソネット3.7について経験がある方がいれば、ぜひコメントしてください。ご興味があれば、ぜひチャンネル登録してコメントを残してください。次回の動画でお会いしましょう。
コメント