ロボット開発者がLLMにデバッグを任せてみた結果、結局自分でやる羽目になった話

私が指導するジュニア/ミッドレベル開発者に最初に伝えることの1つは、「コードを読むだけではデバッグできない」ということです。私たちは皆、自分のコードがどう動くかというメンタルモデルを持っていますが、それはたいてい少し間違っています。バグはそれらの間違いが現実世界に現れたものです。コードを読むとき、それはすべて自分のモデルを通してフィルタリングされるため、なぜ予期しないことが起こったのかを見ることができなくなります。何かをデバッグするには、バグが発生する状態にシステムを持っていき、なぜ発生したのかを見る必要があります。

LLMは一般的に、プロンプトで与えられた情報とともにコードを読むことでのみシステムをデバッグします。記事の画像はメタプロンプトです。プロンプトは、AIが「理解」するために使用するビジョンモデルから来るものは何でもです。それは機能しません。何が起こっているかをうまくデバッグするには、はるかに優れた状態情報が必要です。「棚」は説明されていますか？画像のコントラストと影の欠如がビジョンモデルを混乱させていませんか？なぜ「蓋」が画像にないのですか？などなど。

LLMは賢いですが、魔法ではありません。経験の浅いジュニア開発者のように扱ってください。何かの状態について十分なデータを与えて、適切に理解させてください。

私はこれを完全に理解しています。私はロボットハンドに取り組んだことがありますが、5.6/Fable 5は視覚的なデバッグを手伝うのにほとんど役に立ちませんでした。

実際に非常に役立ったのは、モデルにインタラクティブな3Dビューアを作らせることです。そこで移動/ハイライト/ペイント（問題のためにジオメトリに直接ソフトボディペイントし、異なる色が異なる失敗を意味する）を使用します。これにより、ラベル付きスクリーンショットでは伝えにくい物理的な関係や位置を伝えるはるかに良い方法が得られます。

確かにまだ多くの手作業が必要なので、「盲導犬」という説明は確かに当てはまります。しかし、追加のコンテキストでいくつかの例を試した後、モデルは問題を扱うのがはるかに上手くなり、役に立つようになることに気付きました。

少しトピックから外れますが、著者のメインプロジェクトのランディングページ（https://rerun.io/）の小さなロボットが大好きです。

通常、マウス乗っ取りは非難しますが、この実装は許可します。

LLMは特定の種類のデバッグが特に苦手だと気付きましたが、それが何であるかはうまく言葉にできません。

「このコードのバグを見つけてください」という、コードを見てバグらしさとパターンマッチできるものは、本当に得意なようです。

「このログファイルがありますが、何が起こっていると思いますか？」のようなデバッグの一部も驚くほど得意です。

問題はその中間のようなものです——正直に言うと、見ればわかるというのが最も言葉にできる方法です。最近の例として、ネットワークメッセージパーサーで悪いデータを受信しています。すぐにそれが自分の側の問題か相手側の問題かはわかりませんが、LLMに動作を漠然と説明しようとすると、トークンを吐き出し始めることはわかっています。

このような問題に対する私の現在のアプローチは——LLMに、問題を解決するために必要なデータを自分自身に与えるために何をする必要があるかを伝えることです。私の最初の反応は今や「動作していない、バグがある、Xをしていない」ではなく、「さて、これはあまりうまく動作していません。X、Y、Zの周りにデバッグログを追加して、これを解決できるようにしてください」です。これにより、スパイラルを避け、はるかに迅速に状況から抜け出せます。

盲導犬のたとえは実際かなり適切です。著者が可能なら、いくつかのトランスクリプトを見たいです。

編集して追加：私がほのめかしている「もの」は——バグの動作を言葉で明確に表現するのに苦労するなら、おそらくかなりの数の往復が必要になるだろうとわかることかもしれません。[…]