AIエージェントは指示をどこまで記憶できる？ — Laurie Voss（Arize AI）

日本語العربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia한국어PortuguêsРусский中文
AAI Engineer
Computing/SoftwareInternet Technology

Transcript

00:00:00-
00:00:12皆さん、こんにちは。
00:00:15この非常にマニアックなセッションにお越しいただきありがとうございます。
00:00:20この講演はタイトルがかなり長いので、
00:00:22最初に要約をお伝えしますね。
00:00:23スキルファイルに数多くの指示を詰め込んでいくと、
00:00:27ある時点でモデルはそのすべてを把握しきれなくなります。
00:00:31問題は、それが一体どこなのかという点です。
00:00:33スキルファイルに指示を詰め込みすぎるのは、
00:00:35いったいどの段階でしょうか？
00:00:36そしてその答えは、この1年で大きく様変わりしました。
00:00:40私はローリーです。Arise AIでDeveloper Relationsの責任者をしています。
00:00:44以前はNPM Inc.の共同創業者でした。
00:00:46そのため、JavaScript全盛期の頃からご存知の方もいるかもしれません。
00:00:48最近では、AIやそのテスト方法について
00:00:50多くの時間を割いて考えています。
00:00:53数ヶ月前、マイアミで開催されたAIエンジニアのカンファレンスに参加しました。
00:00:55とても良いカンファレンスでした。
00:00:57そこでデクスター・ホージーの講演を聞いていたのですが、
00:00:59それがまた良い内容でした。
00:01:00もちろん今回のトピックとは全く関係ありません。
00:01:02ですが、彼が講演の中で、
00:01:04余談としてこう言いました。
00:01:06エージェントが指示を忘れ始めるまでに追従できるのは、
00:01:10およそ200個程度が限界なのだと。
00:01:13その後、彼は何事もなかったかのように話を続け、
00:01:15あくまで完全に余談という扱いでした。
00:01:17その数値は2025年時点のものだそうですが、
00:01:20今はもっと改善されているかもしれないとのことでした。
00:01:22それを聞いた瞬間、私は思わず聞き入ってしまいました。
00:01:25なぜなら、「200個の指示なんて、
00:01:27ほんのわずかではないか」と思ったからです。
00:01:31まともなスキルファイルであれば、200個の指示など
00:01:33あっという間に超えてしまいます。
00:01:35ユーザーがXと言えばYを実行し、
00:01:37Zに関するセクションを必ず含め、
00:01:39Wという表現は絶対に使わない――
00:01:40これら一つひとつがすべて独立した指示なのです。
00:01:42もしモデルが200個を超えた時点でこっそり追跡をやめてしまうなら、
00:01:45それは私たちが構築できるシステムの複雑さにおいて、
00:01:47非常に厳しい上限になってしまいます。
00:01:49だからこそ、その数字の出所がどこなのか、
00:01:52そして本当にそれが事実なのかを知りたくなりました。
00:01:55皆さんも、きっとこの感覚に覚えがあるはずです。
00:01:57大規模で素晴らしいスキルファイルを書き上げ、
00:01:58何ページにもわたるルール、エッジケース、口調、フォーマットを定義する。
00:02:00そしてそれをエージェントに渡す。
00:02:01エージェントはタスクをこなします。
00:02:03しかし、出力結果を見てこう思うわけです。
00:02:05「本当にちゃんと注意を払っていただろうか？」
00:02:07「本当にこれらすべてのルールに従ったのだろうか？」
00:02:09それとも、ただ自分の気の向くままに適当に動いて、
00:02:11私が期待していたものにそれっぽく似せた代物を
00:02:14出力しただけではないのか、と。
00:02:16本当のところは分からない……いや、分かるでしょうか？
00:02:18その話はまた後ほど。
00:02:20私たちは、実行ボタンを押すたびに
00:02:23こうした小さな不安を抱えながら生き急いでいます。
00:02:24今回の研究は、まさにその感覚をテーマにしたものであり、
00:02:27それを回避できるかどうかを検証しようとするものです。
00:02:30それではこれからの18分間でお約束します。
00:02:33あの「200」という数字がどこから来たのか、
00:02:36今でもそれが通用するのか、
00:02:37そして現在の本当の数値はいくつなのかをお見せします。
00:02:39なぜなら、数値は一桁以上も変わっているからです。
00:02:41そして、それが私たちにとって何を意味するのか、
00:02:44どんな教訓を持ち帰るべきかについてお話しします。
00:02:46スキルやプロンプトは実際どのくらいの長さにしてよいのか、
00:02:49その結果として自身のワークフローをどう変更すべきなのかを
00:02:51解説していきます。
00:02:54この「200」という数字は、決してただの迷信ではありません。
00:02:57「IfScale」と呼ばれる実際のベンチマークに由来するもので、
00:02:59昨年、名前を発音するのが難しいヤロスワヴィチュ氏と
00:03:03その共同執筆者たちによる論文で発表されたものです。
00:03:06このテストの内容は非常にシンプルです。
00:03:10IfScaleの仕組みはこうです。
00:03:12モデルにビジネスレポートの作成を依頼し、
00:03:14レポートの中に必ず含めなければならない
00:03:16特定の単語のリストを渡します。
00:03:19「customer」という単語を正確に含め、
00:03:20「revenue」という単語を正確に含め、
00:03:22といった具合に、必要な数だけ単語を指定します。
00:03:24それら一つひとつが、モデルが従わなければならない指示となります。
00:03:27そして、指定した正確な単語が実際にいくつ出現したかを数えるのです。
00:03:32テストがこのように非常にシンプルであるため、
00:03:34私たちが頭に入れておくべき数字は2つだけです。
00:03:361つ目は「密度（nと呼びます）」で、
00:03:38これは一度にいくつのルールを扱っているかを示します。
00:03:41そして2つ目は「精度」で、
00:03:42それらのルールのうち、実際にどれだけの割合を
00:03:43守ることができたかを示すパーセンテージです。
00:03:46レポートの中にランダムな単語を含めることなど本当の指示に従うこととは違う、
00:03:50という意見もあるかもしれませんし、それはもっともな話です。
00:03:52これについては後ほど詳しくお話ししますが、
00:03:55キーワードはあくまで代理指標です。
00:03:57「revenueという単語を含める」というタスクの形式は、
00:04:01「価格に関するセクションを含める」というタスクと同じ構造をしています。
00:04:02「この表現は絶対に使わない」なども同様です。
00:04:04それは、エージェントに従うよう指示した
00:04:06個別的かつ名前の付いた制約なのです。
00:04:09もしモデルが1つのプロンプトで200個の単語を追跡できないのであれば、
00:04:11より複雑な200個の指示を扱う際には
00:04:13間違いなく苦戦することになるでしょう。
00:04:16したがって、下手をすればさらにパフォーマンスは悪化するはずです。
00:04:20つまり、この数字が上限になります。
00:04:22この数字が限界値なのです。
00:04:23さらに複雑な指示を与えれば、
00:04:25その数値はおそらくさらに低下するでしょう。
00:04:27そして、200というのはあまりにも低い上限です。
00:04:30ですから、新しいモデルを追い求める前に、
00:04:32まずは正しい科学的検証を行う必要があります。
00:04:33それはすなわち、過去の結果を再現し、
00:04:36その200という上限が本物であるかを確認することです。
00:04:39そこで、私は元のベンチマークを再実行してみました。
00:04:42元の論文では多くのモデルがテストされましたが、
00:04:45AIモデルの世代交代のスピードは非常に急速です。
00:04:47そのため、私がこの検証に取り掛かった時点では、
00:04:50元々使用されていた10種類のモデルのうち、
00:04:52何らかのAPIを通じて利用できるものは
00:04:54わずか3つしか残っていませんでした。
00:04:57それがGPT 4.1、Claude Sonnet 4、
00:04:59そしてGemini 2.5 Proです。
00:05:01これらは12ヶ月前に利用可能であり、
00:05:03現在でもかろうじて利用できるモデルでした。
00:05:05だからこそ、それら残された3つをテストしたのです。
00:05:07他に選択肢がなかったからです。
00:05:08私がこの調査を最初に発表してから
00:05:11数週間のうちに
00:05:12つまり、これがこのテストを実行できる最後の機会でした。
00:05:14だからこの時が最後のタイミングだったのです
00:05:16このテストを実行できたのは
00:05:17結果として、検証対象のラインナップはすでに2つに減ってしまいました。
00:05:20ですから、特定のモデルに執着しすぎてはいけません。
00:05:22それでは、元のIfScaleの検証結果を再現して得られた
00:05:25データを見てみましょう。
00:05:27縦軸が精度を示しています。
00:05:29100%からスタートし、徐々に低下していきます。
00:05:32そして横軸には、対数スケールでルールの数が増えていきます。
00:05:36グラフのメモリを半分進むごとに、
00:05:37処理しているルールの数が倍増していることになります。
00:05:42そのため、500個のルールに達する頃には、30%、40%、50%ものルールが失われてしまいます。
00:05:46私たちの曲線は、元の論文の実験結果と
00:05:49誤差の範囲内で一致しており、この発見は本物でした。
00:05:521年前は、200から300個ほどのルールで
00:05:55フロンティアモデルの性能が崩壊し始めていました。
00:05:57それは本当に低い天井です。
00:06:00それが私たちのベースラインですが、ここからが面白いところです
00:06:03まったく同じテストを使って
00:06:05現在のフロンティアモデルを検証しました。
00:06:07正確に言うと、私がこのテストを実行した時点での
00:06:09フロンティアモデルです。
00:06:10テストしたのは、GPT 5.5、Claude Opus 4.7
00:06:13（4.8はこのテストの1週間後にリリースされたため）、
00:06:17Gemini 3.1 Pro、そしてDeepSeek V4 Proです。
00:06:20同じプロンプト、同じ言葉を与え、
00:06:22何もかも同じ条件でした。そしてすぐに問題に直面しました。
00:06:25それは、彼らが満点を取ったということです。
00:06:27すべてのモデルがこのテストで即座に100%を記録し、
00:06:30バグは一切ありませんでした。
00:06:34私たちは限界を見つけるためにテストを作りましたが、
00:06:36モデルたちはその天井など意に介さず、
00:06:37まっすぐ突き抜けてしまいました。
00:06:40それが問題でした。なぜならベンチマークは
00:06:42500語で頭打ちになるよう作られていたため、
00:06:43新たな限界を見つけるために
00:06:45ベンチマークを変更しなければならなかったのです。
00:06:47ゴールポストを動かし、含めるべき単語を増やしました。
00:06:50500語から1,000語へと倍増させ、
00:06:52さらに1,000語から2,000語へと倍増させました。
00:06:55そうして語彙数を10,000語に達するまで増やし続け、
00:06:56ようやく近年のモデルができることの限界を
00:07:00見出し始めることができたのです。
00:07:03それではスライドをお見せしましょう。これが肝心のデータ、結果です。
00:07:06結果のスライドです。
00:07:07X軸は対数スケールになっていることを思い出してください。
00:07:12500、1,000、5,000、10,000へと推移しています。
00:07:16そのため、グラフが崖から落ちているように見えますが、
00:07:18実際には1,000近くの数値幅の中で起きています。
00:07:20しかし、この新しい曲線が折れ曲がるまでに
00:07:25どれほど右側まで伸びているかをご覧ください。
00:07:261年前は200から300の指示で崩壊していましたが、
00:07:29現在ではモデルによって境界線は2,000近くになり、
00:07:32優れたものでは、崖から落ち始めるまでに
00:07:36最大5,000もの指示を処理できるようになっています。
00:07:38つまり、約12ヶ月でフロンティアモデルは
00:07:41同時に指示に従う能力が約10倍向上したのです。
00:07:44これが最大の発見ですが、ここには掘り下げるべき
00:07:47多くの詳細なニュアンスがあります。
00:07:491つのプロンプトで2,000個の制約事項を追跡する能力が
00:07:53備わっているのです。
00:07:55これは本当に興味深いことで、私自身もそう感じていますし、
00:07:57他のみなさんがどう感じているかは分かりませんが、
00:07:59例えばGPT 5.1からGPT 5.5への進化は
00:08:04どちらかといえば段階的な進歩に感じられたのではないでしょうか？
00:08:0710倍も良くなったようには感じられませんでしたが、
00:08:09これは「自分のスキルファイルはどれくらい長くできるか」という
00:08:14非常に実用的な課題において本当に重要なテストです。
00:08:17そして1年のうちに私たちは10倍も向上したのです。
00:08:21私を驚かせるのは、このベンチマークが
00:08:23まだ誕生して1年も経っていないということです。
00:08:251年後には500という数字は誤差にすぎなくなり、
00:08:27基準は足元で変わり続けています。
00:08:294.7をテストしましたが、Opus 4.8はさらに優れています。
00:08:35そのため、このチャートはすでに少し古くなっており、
00:08:36それこそがまさに言いたいことなのです。
00:08:37スキルファイルがどう機能すべきか、
00:08:39プロンプトの長さはどれくらいにすべきかといった
00:08:41エンジニアリング上の前提を
00:08:446ヶ月以上前に決めていたとしたら、
00:08:46今の基準ではそれは間違いであり、
00:08:48やり方を再設計すべきだということです。
00:08:52しかし、この話には続きがあります。
00:08:54モデルの「失敗の仕方」が
00:08:59劇的に変化しており、
00:09:00その失敗の仕方が非常に重要だからです。
00:09:02この部分は、実験を始めた当初はまったく予想していなかった結果でした。
00:09:06そして最初はそのせいでテストがすっかり混乱してしまいました。
00:09:07というのも、古い失敗モードは退屈なものだったからです。
00:09:10モデルは単に指示を忘れるだけで、
00:09:13私がどれだけの指示を覚えていて、
00:09:14どれだけ忘れたかを測定することができました。
00:09:16しかし、新しいモデルはそれぞれ独自の、
00:09:17極めてモデルらしい奇妙な方法で崩壊するのです。
00:09:20それでは、これら4つのモデルがどのように失敗するかをご紹介しましょう。
00:09:22DeepSeek 4は従来のモデルです。
00:09:26単に物事を忘れるだけで、
00:09:29ドラマはありません。
00:09:30750個前後のルールから指示を忘れ始め、
00:09:312,000個になると、ほぼ半分の指示が抜け落ちてしまいます。
00:09:35つまり、ただ忘れるだけです。率直に言って、
00:09:38予測可能であるため、これが最も信頼できる失敗モードです。
00:09:41測定が非常に簡単なのです。
00:09:43しかし、他のモデルはこれほど協力的ではありませんでした。
00:09:44Opus 4.7は、
00:09:48このテストが危険であると繰り返し判断するのです。
00:09:52そして何をするかというと、
00:09:54APIレベルでテストの完了を拒否します。
00:09:57Claudeから「できなくはないけれど、やりません」というような
00:09:59ClaudeからそのようなAPIレスポンスが返ってくるとは
00:10:01だが、それはClaudeがサポートしているAPIレベルの応答です。
00:10:03彼らはそれほど安全性を重視しているからです。
00:10:06そして、そんな応答がひっきりなしに返ってくるようになりました。
00:10:09そのようなことが起きる理由は、
00:10:10Claudeのセーフティ分類器が非常に敏感だからです。
00:10:13「炭疽菌」や「シアン化物」のような
00:10:15特定の単語の組み合わせを入力すると、
00:10:16リクエスト全体が危険であると判断して処理を中断してしまいます。
00:10:19私のテストが何をするものか思い出してください。
00:10:22指示ファイルに5,000から10,000語の
00:10:24ランダムな単語を放り込んでいるのです。
00:10:26そのため、ランダムに選ばれた単語の中には、
00:10:27セーフティフィルターにとって
00:10:29危険に見えるような組み合わせの言葉があらゆる種類含まれていました。
00:10:33その結果、私が爆弾の作り方でも尋ねているかのように
00:10:35処理を拒否し続けたのです。
00:10:38セーフティフィルターにとって危険に見えるような
00:10:39あらゆる組み合わせが含まれていました。
00:10:41そのため、ボットの作り方などを
00:10:43要求していると判定され、中断し続けました。
00:10:47ですから、Claudeに処理を続けさせるためには
00:10:52すべての単語を取り出し、
00:10:54OpenAIのセーフティフィルターに通して
00:10:56問題がありそうな単語をすべて排除し、
00:10:58やっと処理を進められるようにする必要がありました。
00:10:59一度それを渡せば、Claudeは本当によく機能しました。
00:11:03しかし問題は、Claudeの方が、
00:11:05ごく早い段階で危険だと判断しやすい点です。
00:11:08例えば200や300の指示の段階ですら、
00:11:11実行しようとしている内容に、例えば
00:11:13医療アドバイスに関連するものが含まれていると、
00:11:15医療系は二面性を持つことが多いためです。
00:11:17危険な場合もあれば、安全な場合もあります。
00:11:20そして3つ目の失敗モードが、Gemini 3.1 Proでした。
00:11:24Geminiは5,000件の指示に至るまで完全に安定しています。
00:11:28極めて優れた動作を見せます。
00:11:30チャート上でも文句なく最高峰の一つです。
00:11:32しかし、それを超えると挙動がおかしくなります。
00:11:35指示を忘れてしまうわけではありません。
00:11:37指示の量に圧倒されてしまうのです。
00:11:39何をするかというと、思考トークンを使用して
00:11:44すべての指示に一度に従っているかを
00:11:45確認しようとします。
00:11:46そして指示の数が膨大になると、
00:11:48思考トークンをすべて消費してしまうのです。
00:11:50思考のためにトークン予算の全体を使い果たし
00:11:53その結果、出力を返さなくなります。
00:11:55なんていうか、まるでこう……
00:11:571万トークン分を与えたとしたら
00:11:599,500トークン分を思考に費やしてしまい
00:12:02残りは500ワードの応答しか返さず
00:12:04肝心のトークンがまったく含まれない
00:12:07つまり、自分で自分の首を絞めてしまい
00:12:09実際に回答するための余裕がなくなるのです。
00:12:10非常にコストがかかる一方で、全く役に立ちません。
00:12:13ある意味、いかにもGeminiらしいと言えますよね。
00:12:19もちろん、こんなことは口が裂けても言えませんが。
00:12:23そして最後に勝者の登場です。GPT 5.5です。
00:12:26GPT 5.5は群を抜いて最高で、精度は99%
00:12:295,000個のルールまで完璧にこなします。
00:12:32しかし、さらに限界まで追い込むと
00:12:33間違いなく一番奇妙な振る舞いをします。
00:12:35露骨に拒否するわけでもなく
00:12:37黙って忘れてしまうわけでもありません。
00:12:38代わりにどうするかというと、フラストレーションを溜め
00:12:41こんなテストはバカげていると伝えてくるのです。
00:12:45レポート作成を開始し、少し進めてから……
00:12:47そう、そこがポイントなんです。
00:12:48最初から「嫌だ」と言い出すわけではありません。
00:12:50まずはレポートを書き始め
00:12:51レポートの作成をスタートし
00:12:52500ワードほど書き進めたところで
00:12:54「いや、これくだらないぞ」と言い出し
00:12:55「もうこんなことはしない」と言い出すのです。
00:12:56そして丁寧に、これはバカげているから
00:12:58もう二度とやらないと告げてきます。
00:13:00これが実際に私に返ってきた応答です。
00:13:02しかも、私が生成を指示したビジネスレポートの
00:13:05作成しろと指示したビジネスレポートのね
00:13:08だから、GPTは間違っていませんよね？
00:13:10私は一貫性のあるビジネスレポートを求めていました
00:13:12特定の主題もなく
00:13:14ランダムな5,000語を含んだものを。
00:13:17GPT、君の言う通りだ。
00:13:19こんなものを要求するなんてバカげている。
00:13:23どう考えても無理のある要求だったわけですが
00:13:25GPTはそれを的確に指摘してきたわけです。
00:13:27それでもテスト上では失敗扱いになります。
00:13:29なぜなら、返ってきた中途半端なレポートには
00:13:31キーワードのほとんどが欠けており
00:13:32おまけに最も検出しにくい失敗だからです。
00:13:35Claudeなら即座に投げ出しますからね。
00:13:36Claudeは「いやだ
00:13:37そんなことはしない」と言います。
00:13:39DeepSeekはベストを尽くします。
00:13:41しかしGPTは、うまくやっているように見せかけておいて
00:13:44レポートの最後まで読み進めないとわからないのです
00:13:46「いや、やっぱりこんなのバカらしいから
00:13:47もう投げ出すよ」と書かれていることに気づきません。
00:13:51こうして4つを並べて全体を見渡してみると
00:13:53DeepSeekは静かに忘れます。
00:13:54Claudeは恐れをなして拒絶します。
00:13:56Geminiは考えすぎて沈黙します。
00:13:58そしてGPT 5.5は半分だけ仕事をやり遂げた後
00:14:00残りは自分の器に合わないと言い放つわけです。
00:14:04大事なのは、どれが一番面白いかということではありません。
00:14:07まあ、本当にちょっと面白いんですけどね。
00:14:09ポイントは「私の指示に従ったか」という点が
00:14:12もはや1つの失敗パターンに収まらないということです。
00:14:144つの異なる方法で失敗しうるのです。
00:14:16その失敗に気づくことはできません
00:14:19その失敗に気づくことはできません。
00:14:23つまり、モデルの性能は10倍向上しましたが
00:14:27失敗の仕方もユニークになったということです。
00:14:29では、自分のデスクに戻ったとき、なぜこれが重要になるのでしょうか？
00:14:31ワークフローにおいて3つのことが変わったからです。
00:14:341つ目は、1年前ならすべてのスキルファイルを極限まで短くするのが賢いやり方でした。
00:14:39200個以下の指示に抑え、サブスキルや、追加のスキルファイルやサブファイルが入り組んだビザンチン的な迷宮へと誘導していました。
00:14:50限られたスペースに収まるよう指示を圧縮していましたが、もうそんなことをする必要はありません。
00:14:57スキルファイルを非常に長くできるのです。
00:14:592つ目は、特定のルールが100個あるいは300個必要な場合、それらをすべてプロンプトに詰め込めるということです。
00:15:06モデルがどのルールを密かに無視したのかと、夜も眠れなくなるような思いをする必要はありません。
00:15:12モデルを使ってきたご自身の経験を振り返れば、きっとお分かりいただけるでしょう。
00:15:21プロンプトがどれほど長くなろうとも、以前ほど心配しなくなっていることに気づいたはずです。モデルが指示に従う能力を本当に10倍向上させたからです。
00:15:32名前付きの制約が2,000個あれば、それはもう完全なスタイルガイドですよね。
00:15:35すべてのブランドルール、すべての法的な免責事項が含まれます。
00:15:381年前なら、これを十数個の特化型エージェントに分割し、それぞれが綺麗に連携してくれることを祈らなければなりませんでした。
00:15:46しかし、今はもうそんな気にする必要はありません。
00:15:48そして3つ目の変更点が非常に重要です。
00:15:50かつての疑問は「モデルにそんなことができるのか？」でした。
00:15:53そして今の答えは、はっきりと「はい」です。
00:15:55まあ、そこそこ確実にと呼べるレベルですが。
00:15:58新たな疑問は「それに値するコストがかかるのか？」です。
00:16:01プロンプトに1万語――失礼、1万個の異なる指示を含めることは可能ですが、それは途方もなく巨大なプロンプトになります。
00:16:07非常にコストのかかるプロンプトになります。
00:16:09そして、非常に処理が遅いプロンプトになります。
00:16:10かつて私たちが直面していた高い壁は、「コストと遅延が増えるトレードオフを冒してまで、これらすべての追加指示を入れる価値があるか？」という緩やかな判断基準へと変わりました。
00:16:19ここで、Q&Aに先立っていくつか注意点を挙げておきます。
00:16:25最初にして最も重要なことですが、先ほども触れたように、これはプロキシタスクです。偽のビジネスレポートにランダムな単語を含めることは、長いスキルファイルが機能するという証拠にはなりますが
00:16:38長いスキルファイルが完全に機能する証明そのものではありません。
00:16:41また、モデルが壁にぶつかるポイントは750から9,000以上まで様々であり、モデルの選定には細心の注意が必要です。
00:16:49私たちのテストで測定していないのは、巨大なプロンプト全体でモデルが明晰な推論を行えているかどうかです。
00:16:57良いニュースとして、私が数週間前にリサーチを行って以降、多くの人がこの分野に参入し、現在では質の高い研究が存在しています。
00:17:05実際の科学者たちが参入し、Chromaが18のモデルを対象にコンテキスト劣化（context rot）の検証を行いました。それによると、長大な入力に対する精度は、コンテキストウィンドウの限界に達するはるか手前で30から50パーセントも低下することが示されています。
00:17:21さらに彼らの発見で奇妙だったのは、指示をランダムな順序にしてシャッフルした場合よりも、一貫性のあるよく構造化されたテキストの方が、そのような失敗モードに陥りやすいということでした。
00:17:33なぜそうなるのかは分かりません。彼らのレポートを詳しく読む必要がありそうです。
00:17:37つまり、モデルは2,000、5,000、あるいは10,000個の指示を追跡できるかもしれませんが、それらを基にして必ずしも明晰な推論ができるとは限らないのです。
00:17:46指示同士が矛盾していたり、緊張関係があったりする場合に、それを必ずしもうまく処理できるわけではありません。
00:17:53そして、先ほど軽く触れたもう一つの問題があります。
00:17:56Claudeの拒否は厄介ですが、非常に明確です。
00:18:00エラーが発生するため、失敗したことが一目で分かります。
00:18:02一方、GPTの丁寧な中途半端なレポートは、本物の回答のように見えるため、はるかに危険です。
00:18:07途中で静かに諦めてしまったことに気づくには、全体をくまなく読まなければならず、つまり出力を信用できないということです。
00:18:13それはつまり、ちゃんと機能しているか確かめるために、毎回出力を隅々まで確認しなければならないということです。
00:18:17そのため、モデルは2,000個のルールを受け入れ、少なくとも最初は自信に満ちた洗練されたものを返してくれますが、途中で音を上げている可能性があるのです。
00:18:30ちなみに、これらすべてにかかった費用をよく聞かれます。
00:18:34すべてのクエリを実行するのにかかった費用は209ドルでした。
00:18:377つのモデルにわたる2,300回の呼び出しで、合計209ドルです。
00:18:43新しい研究というのは、意外とコストがかからないものなのです。
00:18:46そしてここが、モデルが黙って失敗しないとは限らないため、本番環境でしっかりと検証しなければならないと私が伝えていた部分です。
00:18:55私がAriseで働いており、そこでまさにその業務を行っているため、いずれ評価（eval）に言及するだろうとお気づきだったでしょう。
00:19:01ですが、Ariseの宣伝ばかりするわけにもいきません。
00:19:03ですので、1つだけ真実を申し上げます。本物のAIアプリケーションを構築し、本当に厄介なタスクを任せているなら
00:19:10フロンティアモデルでこれらのような失敗モードの1つ以上に必ず直面することになります。
00:19:14APIレベルでClaudeから拒絶される場合を除き、何かがおかしくなったと知る唯一の方法は、別のLLMを使って出力をモニタリングすることです。
00:19:23それが評価（eval）であり、Ariseが提供しているものです。この話はこのくらいにしておきましょう。
00:19:27私たちの調査以降にも、新しい研究が出ていることにはすでに触れましたね。
00:19:30もう一つの重要な研究をご紹介します。
00:19:3146のモデルをテストした論文『指示追従における言語モデルの信頼性の再検証（Revisiting the Reliability of Language Models in Instruction Following）』が発表されました。
00:19:37自分でリサーチを行った後だったので、これには思わず耳をそばだてました。
00:19:41彼らが発見したのは厄介な事実で、モデルが私たちのようなベンチマークで最高の結果を出したとしても、依然として極めて信頼性に欠ける場合があるということです。
00:19:47同じ指示をわずかに異なる表現で言い換えるだけで、指示に従う能力に劇的な違いが生じる可能性があるからです。
00:19:56モデルは2,000個の指示を理解し、見事にこなすことができます。
00:20:00しかし、全く同じ2,000個の指示を異なる順番で配置すると、指示に従う能力が急激に低下することがあるのです。
00:20:08混乱を避けて完璧に従わせるには、指示をどのような順序で並べるべきか、正確にどう実行すべきかという点は、現在も研究が進められている最中です。
00:20:19つまり、処理能力は向上したものの、信頼性は依然として課題なのです。
00:20:24これはちょっとした自慢ですが、私は科学者ではなく、個人的に少しリサーチを行っただけです。
00:20:31その後、多くの本物の科学者たちが参入し、同じ疑問に対して本格的な科学的研究を行ってくれました。
00:20:36現在では、この同じ疑問を測定するためのベンチマークがたくさん登場しています。
00:20:40Firebench、CCRbench、Guidebenchはいずれも同じものを測定しようとしています。
00:20:44それは、現実の複雑で厄介な制約の数々に、モデルがどれほどうまく同時に従えるかという点です。
00:20:49業界全体がこの問題に注目しているため、私の「1万語のランダムな単語」のようなものよりも、本格的な科学的知見を今や得ることができます。
00:20:58それでは、私からの最後のメッセージに移りましょう。
00:21:001年前、スキルを書く上で最も難しかったのは、モデルが文脈を見失わないようにすべてを詰め込むことでした。
00:21:05それは圧縮の問題であり、その圧縮の問題はすでに解消されています。
00:21:08モデルはあなたの2,000個の指示を問題なく保持してくれます。
00:21:11新しく難しくなったのは、モデルが実際にあなたの言った通りに行動したかどうかを知ることであり、それは検証の問題です。
00:21:16検証の問題は、より良いプロンプトを書くことで解決するものではありません。
00:21:20他のコードをテストするのと同様に、毎回出力をチェックすること、すなわち評価（eval）を行うことで解決されます。
00:21:26この1年で、限界値は10倍跳ね上がりました。
00:21:29ですから、プロンプトの長さや指示の規模に関して6ヶ月前に立てた前提を振り返り、見直してみてください。すでに古くなっている可能性があるからです。
00:21:41本日の内容は以上です。
00:21:42すべてのコードとデータを確認したい場合は、こちらのGitHubのURLにあります。
00:21:48そして、もう一つのこちらのQRコードは、マーケティング部門に挿入させられたものです。
00:21:51今夜午後5時から、ワールドカップの観戦パーティーを開催します。
00:21:55ぜひ私たちのパーティーにお越しください。
00:21:56そのリンクは、パーティーに参加できるLumaのページにつながっています。
00:22:01今回の講演が何か新しい情報や、少しでも笑いを提供できていれば幸いです。お時間をいただき、ご清聴ありがとうございました。
00:22:07ありがとうございました。
00:22:08ありがとうございました。

Description

Laurie Voss reran a year old benchmark and the models walked straight through its ceiling without noticing it was there. IFScale asks a model to write a business report containing a list of exact words, then counts how many actually appear. A year ago frontier models started dropping instructions somewhere around 200 to 300, which is a hard limit on how much you can put in a skills file. Voss, head of developer relations at Arize AI and a cofounder of npm, first replicated that result on the three models from the original paper still reachable by API, then pointed the same test at the current frontier. They scored 100 percent immediately. He had to raise the benchmark from 500 words to 10,000 before anything broke at all. The boundary now sits near 2,000 instructions, and for the best model closer to 5,000, roughly a tenfold gain in twelve months. The stranger finding is that the models no longer fail the same way. One simply forgets, shedding nearly half its rules by 2,000. One refuses at the API level, because a pile of random words trips its safety classifier. One spends its whole thinking budget verifying instructions and leaves no room to answer. The last writes five thousand words of the report, decides the request is stupid, says so politely, and stops, which reads like a finished answer unless you get to the end. Voss argues this moves the work: fitting rules into a small budget was a compression problem and it is gone, while knowing whether the model obeyed is a verification problem that only checking outputs solves. The whole study cost 29 dollars. Speaker info: - https://x.com/seldo - https://www.linkedin.com/in/seldo/ - https://seldo.com Timestamps: 0:00 - The 200 instruction ceiling and where it came from 1:49 - Not knowing whether it followed your rules 2:58 - How the IFScale benchmark works 4:19 - Replicating last year's result 6:12 - Pointing the same test at current models 7:07 - The headline, a tenfold jump in a year 9:01 - Four models, four different ways to fail 14:27 - What this changes in your workflow 16:29 - Caveats, and what the test does not prove 19:32 - Capacity went up, reliability did not 21:06 - Compression solved, verification remains

Community Posts

No posts yet. Be the first to write about this video!

Write about this video