
When a measure becomes a target, it ceases to be a good measure.
Charles Goodhart, 1975
この引用を、さまざまな文脈で目にしたことがあるでしょう。PR のマージ数やコード行数、そして今ではトークン使用量といった、恣意的な指標に対する不満として語られることが多いものです。しかし、トークンマキシングの時代は、始まる前にすでに終わってしまったのでしょうか? トークンリーダーボードの台頭と、Amazon などの企業におけるトークンリーダーボードの廃止は、わずか 3 ヶ月足らずの間に起きたように見えます!
Cat Hicks on Bluesky から一文を引用すると、Goodhart の法則について語るとき、実際には Campbell の法則 を指していることが多いでしょう。
“The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor.”
本当の「不都合な真実」は、開発者生産性をめぐる議論では、Goodhart よりも Campbell の法則の方がはるかに当てはまるということです。なぜなら、全体的な成果に対するプロセスやポリシーの影響を、極めて限定的な方法以外で切り離して測定することは、ほとんど不可能だからです。
この分野における最も厳密な最近の研究 では、通常推奨されるベストプラクティス(より多くのコードを書く、小さな PR をリリースする、コラボレーションする)が、予想通りにサイクルタイムに影響を与えることが示されました。ただし、その効果は小さく、ほとんどが月ごとの個人内のばらつきによってかき消されてしまうという結果でした。個人の単一の測定値は、その人の典型的なパフォーマンスについてほとんど何も教えてくれません。結論として、デリバリーの改善は個人レベルのスコア管理ではなく、システムレベルの問題であるということです。つまり、誰もが測定したいと思うものは、人に向けられた瞬間にノイズと化すのです。
それでも、私たちはまた一日歳を取り、少しも賢くなっていないまま、新しいソーシャルクレジットスコアを発行して特定の行動を促そうとしています。何も理解していないのに。個人的には、トークン ROI についての議論はかなり愚かなものだと思います。これは、組織がうまく言語化すらできていない、より深い問いに対する隠れ蓑に過ぎません。その問いとは、「インテリジェンスをサービスとして利用する場合、何をすべきか?」というものです。
猿とシェイクスピア、その類の話
無限の猿定理をご存じでしょうか? 無限の時間と無限の文字をタイプする猿が、偶然にもシェイクスピアを含むすべての著作を生み出すというものです。実際の猿を使った実験では証明されていませんが、興味深い思考実験であり、ある程度の手振りを伴うものの直接的な証明も存在します。無限の猿が『ハムレット』を再現する確率は、無限の時間があれば 1 になるのです。
トークンマキシングの主張は、現実味を帯びた無限の猿定理に帰結します。つまり、「テキスト生成で表現可能なドメイン内のあらゆる問題に対して、無限のテキスト生成からどれだけの価値を引き出せるか?」という問いです。これはある程度魅力的な提案です。LLM が、検証可能なテキストの適用によって解決可能なほぼすべての問題に対して、平均的に中央値の解を生成できると仮定するなら、大数の法則により、その一部は分布外で中央値より優れた解になるでしょう。そして、それとは別に、中央値自体が現状よりも優れている可能性が高いのです。
これは全くの愚かな提案ではありません。特にゲーム理論的な観点を取り入れればなおさらです。もし他の人々がトークンマキシングをしているなら、あなたもそうすべきです。なぜなら、潜在的な利益を逃しているかもしれないからです。トークンマキシングにより、1 人の貢献者が 5 人、10 人、100 人、1000 人分の「仕事」をこなせるようになります。唯一の制約が予算と機会費用であるなら、莫大な裁定取引を行うのは理にかなっています。10,000 件の Rust によるコアサービスの書き換えのうち、どれが長年の技術的課題を解決するものになるかは、誰にもわかりません!
トークンマキシング派に対しては、その立場を見て「頭が雲の上で大気圏外にありながら、どうやって息ができるのか不思議だ」と疑問を抱く人々の緩やかな連合が対抗しています。
「反」派の立場として一貫したものが存在するなら、それはたとえ上記のすべてが真実であったとしても、下流のコストと影響がビジネス、チーム、組織全体にネットでマイナスになるというものです。確かに、すべてのアプリケーションを Rust に書き換えることは可能です。しかし、誰も Rust を理解していないなら、それは役に立ちません。バックログを 2 回消化し、望む機能をすべて追加することはできますが、コードベースは管理不能で保守不能な混乱状態になり(さらに多くのトークンを投入して修正しない限り)、UI では 12 種類の異なるセリフフォントが使われることになります。さらに、無限の出力を作り出せたとしても、検証コストも同様にスケールします。潜在的な改善のために 2 倍(あるいはそれ以上)のコストを支払うことになり、それが他のすべての作業に足枷となります。いつでも利用可能なインテリジェンスは素晴らしいですが、判断力は依然として希少な資源なのです。
トークンはトークンに等しくない
私の立場は、どちらの陣営も精査に耐えられない形で極端であるということです。トークンは知能の代替可能な単位ではありません。エージェント工学は、異なるモデルやモダリティ間で膨大な量のトークンを使用します。それは特定の成果物にマッピングすることが困難です。モデルは問題や解決空間を誤解し、実行不可能な道筋に迷い込み、ツールを誤って使用し、人間と同じように一時的な失敗状態に遭遇します。
意思決定者やビジネスリーダーは、きれいで整然としたクラウド請求書の計算された慰めを求めていますが、AI にはそんなものは存在しません。これは「ドルを投入すれば計算が得られる」というものではありません。AI アプリケーションやエージェントのデリバリー においても、100% エラーのないエンゲージメントを保証するガードレールやハーネスはありません。誰かが常に、最善の計画、ガードレール、評価を台無しにすることをするでしょう。
したがって、AI 支出に対するより良いメンタルモデルが必要です。トークンに焦点を当てることは還元主義的であり、おそらく有害です。特に、推論がローカルで実行可能になる世界に向かう中で。メモリとストレージの膨大な要件のため、オンデマンドで利用可能なモデルは常に存在するでしょうが、より制約の強いローカルタスク(検索や一部のツール使用など)には、より小さなモデルに移行し、リクエストをさまざまなエンドポイントにディスパッチできるルーターを備える可能性が高いと思われます。これにより、トークンの計算はさらに複雑になります。
ここには、ストーリーポイントとの非常に興味深い類似点があります。実際、社会が仕事を可視化しようとするほとんどの試みと同様です。私のストーリーポイントはあなたのストーリーポイントとは異なり、数十の要因に影響されます。在職期間、気概、顧客のニーズ、ビジネスのニーズです。これらの指標をビジネスユニット全体で見れば真実が明らかになると想定しますが、実際に踏み込んでみると、異なる人々の生産性を正規化するためにできることは、測定値を中央値に固定しない限りほとんどありません。これはトークンマキシングのジレンマを反映しています。すでに中央値の出力が期待される世界にいるなら、無限の中央値出力を生み出すための単一のダイヤルを回せるというのは、考えるまでもないことのように思えるでしょう!
解読不能な活動
これらの測定が見逃しているのは、これらの粗雑な測定が捉えられない、またはモデル化できない要因が存在するということです。LLM をプロンプトし駆動することはスキルです。良い判断力を持ち、変化率を高めるための社内調整を築くことは才能です。複雑なシステムを頭の中に保持し、暗黙の建築的制約を理解することはアートです。これらはすべて解読不能な活動です! トークンリーダーボードや AI の必須使用といったさまざまなメカニズムを通じて行動をインセンティブ化しようとすると、Campbell の法則が必然的に忍び寄り、測定は腐敗します。
では、何が重要なのでしょうか? 正直に言って、以前から重要だったものと同じです。高パフォーマンスのチームには心理的安全性、実験の余地、堅牢な CI/CD が必要です。本番環境でテストを行い、優れた可観測性を持つ必要があります。私たちは革命の真っ只中にいるかもしれませんが、すべてが一度に革命化されるわけではありません。これは棚卸しをし、何が依然として重要で、どのように重要なのかを問う絶好の機会です。過去の知識が今や無関係になったと仮定してはいけません。
AI 時代の皮肉は、これらのことを達成するための技術的能力が私たちの手の届くところにあるということです。AI エージェントは、計装の追加、テストの記述、CI/CD パイプラインの改善を難なく行えます。トークン予算を内向きに向け、開発者体験を改善することで、アウトサイズな ROI が得られるでしょう。ログを構造化しましょう! コードベース全体に千の Claude を咲かせ、テレメトリーを正規化し、延期していた OpenTelemetry 移行を行いましょう! データを Honeycomb に送信し、Canvas を使ってエージェントの行動を分析しましょう。実際に彼らが何をしているかを見たい場合(詳細は こちらのドキュメントページ を参照)。トークン生成パイプラインを解明し、実際に掘り下げ、理解 しましょう。エージェントと並んで。
重要なのは、出力を数えたり測定したりすることではなく、理解 のシステムを構築することです。生産的なチームの行動や特性を観察することで理解してきたのと同じように、エージェントの出力を観察することでエージェントと一緒に学んでいくのです。測定不能なものを突然測定可能にするわけではありませんが、プロセスに適用できる知識の筋肉を構築することを可能にします。
しかし、私の最大のアドバイスは、これらのことを義務化するのをやめることです。現実には、AI はチーム、会社、組織をより良くするものではありません。すでに存在する違いを強調するだけです。AI を与えることで一部のチームがはるかに生産的になることに気づいたなら、それは素晴らしいことです! それは良いデータポイントです。「AI ができるすごいことを見て!」と叫ぶのではなく、彼らと話し、AI が可能にしたことではなく、以前に何が彼らを妨げていたのかを理解する方がおそらく価値があるでしょう。百のトークンリーダーボードや AI 義務化を通じて得られるものよりも、はるかに有用なことを学べるはずです。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.