モデル、コンテキスト、誤った回答

能力と利用可能な情報を区別する

言語モデルは、学習したパターンと、タスク中に渡された情報を使います。現在のモデルは、複雑な推論や有用なソフトウェア開発作業を行えます。一方で、誤った仮定に基づく詳細な回答を出すこともあります。

「frontierモデル」は、時代とともに変わる能力水準を表します。その呼び名は、モデルがリポジトリを読んだ証拠ではありません。依存関係のバージョンや、文書化されていない業務ルールを知っている証拠にもなりません。タスクの環境から、これらの事実を与える必要があります。

適切なツールを持つエージェントは情報を取得できます。アクセス権のないチャットではリポジトリを調べられません。回答が誤っているように見えたら、二つ確認します。正しい情報があれば、このモデルは問題を解けますか？その情報はモデルに渡されましたか？

前者には、別のモデルが役立つかもしれません。後者には、不足していたポリシーの提供や、依存関係の確認が役立ちます。

コンテキストとは、現在の回答に使える情報です。指示、提供されたファイル、関連する会話、ツールの結果が含まれます。製品によって、これらの情報を選び、保持する方法は異なります。以前の内容を要約することもあります。

アップロードしたフォルダーの全ファイルを、モデルが読むとは限りません。長いセッションの間、最初の指示が常に利用できるとも限りません。使ったファイルと指示を、ツールに明示させてください。

コンテキストを増やせば、必ず回答が改善するわけではありません。無関係なソースファイルより、現在のアーキテクチャ判断のほうが役立つ場合があります。古い移行ガイドが権威ある情報に見えると、誤った回答の原因になり得ます。

架空のアカウント設定機能を考えます。ルート、認可ミドルウェア、関連するデータモデル、既存のテストを渡します。さらに「メンバーは自分の表示名を変更できる。ただし、組織内の自分のロールは変更できない」という具体的な制約を追加します。これで、守るべきルールがモデルに明示されます。

「ミドルウェアが所有者を確認するため、このエンドポイントは安全です」という回答があるかもしれません。その主張を構成する各要素を検証します。

リポジトリへの参照は、調べる場所を示します。参照があるだけでは、説明がコードと一致している証拠にはなりません。

APIの推奨にも同じ方法を使います。生成されたコードが、インストール済みのパッケージにはないメソッドを呼び出すことがあります。依存関係を置き換える前に、バージョンと公式ドキュメントを確認してください。根拠のない仮定に従うと、不要な移行につながることがあります。

「正確に答えてください」は検証計画ではありません。仮定、必要な証拠、結果が誤っていた場合の影響を特定します。

例えば「このエンドポイントのテナント分離は未検証です。リクエストハンドラーを調べてください。別テナントの利用者が同じレコードを要求するテストを追加してください」と指示します。これなら、具体的な調査と観察可能な結果をエージェントに示せます。

実装に関する疑問では、実際のシステムのバージョンを調べます。文書は意図した動作を説明している場合があります。コードの調査とテストで、現在の動作を確認します。両者が異なる場合は、責任者が解決するまで差を記録します。都合のよい答えを黙って選んではいけません。

マネージャーは、コードの変更をすべて読まなくても、この方法を使えます。チームがどの仮定を確認したか尋ねてください。未確認の仮定と、その担当者を特定します。モデル名よりも、この情報のほうがリリースの判断に直接役立ちます。