LLMツールの失敗：根本原因は3つのみ – 値、条件、意図

誰がフォームに記入するか — モデルが下書きしたものに署名するだけ尋ねてください、知らないなら。誰もがプロンプトにそれを入れます。そしてモデルは尋ねます。値が欠落している場合、ユーザーに尋ねます。問題は上流にあります。モデルは何について尋ねるかを決定します。それは、欠落しているように見えるものについて尋ねます。したがって、自分が何かを知らないことを認識できない場合、尋ねず、空のスロットを自分で埋めた場合、尋ねるべきことは何も残りません。指示がどれほど強く書かれていても、同じ点で立ち往生します。署名は残ったが、下書きは移動したフォームにはかつて5つのステップがありました。ユーザーはいつ、どのような条件で行動するかを決定し、フォームを選択し、値を入力し、それらの値がどこから来たかを確認し、必須フィールドがすべて埋まっていることを確認しました。値の入力も人間のタスクでした。人が各空欄を見て、記入し、そして確認を押しました。人はまだ最後に確認します。承認はなくなっていません。移動したのは最初の下書きです。モデルがフォーム内の値を埋めます。人は今、提示されたフォームを見て署名します。したがって、チェックの性質が変わります。それはもはや「これは正しいか？」ではなく、「進めてよいか？」となります。前者は判断を必要としますが、後者は単なる通過です。誰かに見せたものを承認するように頼むと、レビューではなくクリックを通過します。さらに悪いことに、フォームはきれいに見えます。もしそれが乱雑に見えたら、すぐに気づくでしょう。しかし、検索された値と発明された値は同じように見えるため、フォームを読んでも何もわかりません。そして、欠落している条件はフォームにまったく現れません。あなたが実際に確認しなかったフィールドを承認していることが、何も明らかにしません。したがって、取り戻す必要があるのは署名ではありません。それは下書きです。シフト実行前のことを検証ではなく、外部リストを使用して質問する場所として扱います。バリデーターとして見ると、作業は判定の基準を洗練することになります。質問する場所として見ると、作業は何が質問されるかということになります。モデルをより正確にすることで解決する → 外部リストが何を質問するかを決定し、モデルが質問をします。その一行がこの論点の主張です。既存のアプローチはすでに質問をしています。重要なのは、何を質問するかを決定するものです。存在するものについての信頼性を尋ねることができます。欠けているものについての認識を尋ねることはできません。だからこそ、経験豊富な外科医でさえチェックリストを使用するのです。フォームに入るものは推測するものではなく、調べるものです。そして、そのためには、調べる唯一の場所はユーザーです。より良い計算は、欠けている情報が存在するようにしません。エラーが現れます。間違った計算は目に見える痕跡を残しませんが、尋ねると、ユーザーは「いいえ」と言います。修正パスが現れます。そして、ここでリストの役割が決まります。何を質問するかは外部で定義されていない場合、その判断はモデルに戻ります。目標を変える2つの用語があらかじめ定義されています。スロットは、この実行のために確認されなければならない1行の項目です。不明は、指定されたすべてのソースがチェックされた後も空のままでしたスロットです。計算の目標を、実行するかどうかの決定ではなく、不明のリストにすることです。実行するかどうかは、そのリストの長さから導き出されます。それ自体が目標ではありません。間違った答えを修正することも、1つのスロットを埋める問題になります。目標が実行である場合、スロット間に順序が現れます。目標がリストである場合、スロットは互いに関連しなくなります。ステップを追加することは、遅くなるように聞こえますが、それは逆です。ルックアップは並列で実行され、追加の推論呼び出しではなくメモリ比較であり、1つずつ空欄について尋ねるラウンドトリップは1つにまとまります。目標がリストである場合、判定は実行から分離されます。実行が記録された判定のみを基盤として受け入れる場合、それなしで実行されるパスはありません。残りはここから導き出されます。必要なもののリストがあり、それがどこにあるかによって分割されなければなりません。では、どのリストですか？今日、実行が間違って進む方法は3つあります。誤った実行 — 値が間違っていました。発明された口座番号、発明されたID。指示されていない実行 — 条件がありませんでした。権限やタイミングを確認せずに実行されました。ターゲット外の実行 — 意図が捉えられませんでした。それはユーザーが意図したことではありませんでした。したがって、リストも3つのものが必要です。値、条件、意図。これらのうち2つはすでに存在します。ツールのリストと入力スキーマです。新しいものを構築する必要はありません。追加情報はここにあります。値だけでは不十分です入力スキーマは値のみを保持します。しかし、実行前に条件も満たされなければなりません。残高は十分ですか？受信者は存在しますか？これはいつ起こりますか？どのような状況下で？権限はありますか？安全上の考慮事項は対処されましたか？ここにすべての引数が存在し、すべての型チェックアウトしていますが、アクションはまだ実行されないはずです。値と条件を同じリストに置くと、両方を処理する1つの方法があります。どちらもスロットであり、それぞれが満たされているか、そうでないかのどちらかです。条件のための別個のメカニズムは必要ありません。誰かに条件をゼロから書くように頼む必要はありません。プロバイダーはすでにツールの説明にそれらを書いています。モデルが自由テキストを認識し、それに基づいて行動したことを確認する方法がまったくありません。意図も同様にスロットになります。ユーザーがアクションと呼ぶもの、そしてユーザーが望む変更です。これらのスロットが空のままツールが選択された場合、結果はターゲット外の実行になります。名前はラベルです。ツールができることは別です。あるプロバイダーは「リビングルームのライトを消す」をturn_off_lightと呼び、別のプロバイダーはset_device_powerと呼び、light_controlは明るさしか調整できないかもしれません。したがって、マッチングは、ツールがユーザーが望む状態変化を生成できるかどうかに基づいて行われる必要があり、名前のマッチングではありません。したがって、リストの編成は次のようになります。スロットを分割する軸は、誰がそれに答えることができるかです。固定チェックリスト — 各実行に添付されます。どのツールを選択するか実行条件が満たされているか — タイミングと状況ユーザーがこのアクションを何と呼ぶかプロバイダーチェックリスト — ツールごとに異なります。必須フィールド、タイプとフォーマット、実行前確認、禁止条件、追加承認条件実行した場合に何が変わるか — このツールが生成できる状態変化ユーザーチェックリスト — ユーザーと環境ごとに異なります。意図、現在のコンテキスト、実行制限、実行前確認、設定どこを見るかルックアップは、各スロットに指定されたソースがある場合にのみルックアップです。ユーザーの回答 → 指示 → 事前設定された値 → 観察された値 → 前の状態これは検索順序であり、信頼ランキングではありません。早いソースがより信頼性が高いことを意味するわけではありません。それは、回答が見つかった場合、そこで停止することを意味します。すべてのソースをチェックした後も空の場合は、不明です。それはモデルが知らないと宣言しているわけではありません。それは検索が終わった後に残ったものです。値が必要な場合は、ユーザーに尋ねてください。必要な値はユーザーによって回答されます。推論はありません。除外するように指示しても機能しません。調べる場所を与えても機能します。推論を除外して検索する」という指示は機能しません。除外されたものは外部からは見えず、指示を実行することはできません。取得された値と発明された値は同じように見えるため、モデルに除外するように依頼することは、事後的に自身の出力を分類するように依頼することになり、その分類は再び推論です。したがって、ブラックリストではなくホワイトリストである必要があります。そうではなく：すべてを見て、推論を差し引く。代わりに：調べることができるものを定義し、一度に1つのアイテムを追加し、ソースを記録します。そうすれば、分類する必要のあるものはありません。スロットリストも同様です。「確認する必要のあるものを省略しない」ではなく、確認する必要があるすべてを書き出すことです。何も省略しないという指示は、何を省略しているかを知っている人に対してのみ機能します。