LLMに複雑なタスクを実行させるとき、多くの文脈を入力する必要があることが多い。新機能の設計を考えるには、ユーザーにどのように見えるかという説明、実装に関するガイドライン、参照すべき外部システムに関する情報などが必要になる。これらはすべて、数ページのマークダウンになることもある。これを行う明らかな方法は、人間がこの文脈を書くことだが、代替手段として、LLMを使って人間にインタビューした後にこの文脈を書かせる方法がある。

これを行う方法は、LLMに私を尋問するようプロンプトすることだ。適切な文脈を作成するために必要なすべての質問を私に尋ねるべきだ。必要な情報の多くは提供でき、自分では解決できない場合は参照すべき他の情報源を伝えることができる。完了したら、別のセッション（おそらく別のモデル）で次のステップを実行するための文脈レポートを作成できる。

このアプローチの適切な説明を初めて見たのは、Harper Reedのブログだった。彼のアプローチで印象的なのは、LLMに一度に1つの質問しかさせないよう主張している点だ。（実際に試してみると、頻繁にこれを思い出させる必要があった。）

尋問型LLMのもう一つの使い方は、ドメインに関する知識を捉えた文書（ソフトウェア仕様書など）をLLMに与え、その文書が正確かどうかを判断するために人間の専門家にインタビューさせることだ。これは、人間の専門家に文書を読ませてレビューさせる代替手段となる。レビューは難しいと感じる人が多いので、特に文書がうまく書かれていない場合は、LLMとの会話の方が実りが多いかもしれない。

当然ながら、これらの両方を使用できる。1つの尋問型LLMを使って文書を作成し、次に他の尋問型LLMを使って他の専門家と一緒にレビューすることができる。

上記は、LLMの特定の用途のための文脈を作成または評価させることだ。しかし、この手法はより広く適用可能だ。私は生来の書き手であり、思考の重要な一部として書く行為を捉えている。何かを本当に理解するには、それについて書く必要がある。しかし、人によって異なる。多くの人は書くことを難しいと感じ、しばしば非常に難しいと感じる。これは、誰かの頭の中にある情報を他の人間が消費できる形にする必要があるときに、本当の問題になるかもしれない。そのような人にとっては、自分で文書を書くよりも、LLMにインタビューさせる方が簡単かもしれない。確かに結果は、私のような人が身震いするようなAIライティングのニュアンスを持つことになるだろう。しかし、急いで書いたり、全く書かなかったりして情報自体が得られないよりはましだ。