プロンプトを直し続けても精度が頭打ちになるとき、何を変えればよいか

LLMを一回呼ぶだけでは終わらない仕組みが、いまや当たり前になりました。まず関連する文書を探し、要点をまとめ、考えて、最後に答えを書く。こうして何段もの工程をつないだAIを動かしてみると、なぜか答えがうまく合いません。

直したいのはやまやまですが、困ったことに、長い工程のどこでつまずいたのかが見えません。多くの人はとりあえずプロンプトの文章を書き直しますが、それは暗闇の中で手探りするのに似ています。直すべき場所が検索なのか、考える部分なのか、答えの書き方なのかも分からないまま、文言だけをいじり続けることになります。

では、どうすれば失敗した場所を正確に見つけ、最小限の手間で直せるのか。本記事で、その考え方を一つずつほどいていきます。

つないだLLMは、どこで失敗したのかが見えない

工程をつないだAIを、ひとまず流れ作業の製造ラインのように思い浮かべてください。一つ目の工程が材料を加工して次へ渡し、それを受け取った工程がまた加工する。最後の工程が、完成品にあたる答えを出します。それぞれの工程は、LLMの呼び出しだったり、ちょっとしたプログラムだったりします。

ここで、完成品に不良があったとします。最終的な答えが間違っている。ところがラインを眺めても、どの工程で不良が混ざったのかは分かりません。検索が必要な文書を取り逃したのかもしれないし、考える工程がつまずいたのかもしれないし、答えの書き方が採点の形式に合っていないだけかもしれません。最後の答えしか見ていないと、原因の見当がつきません。

それでも多くの人は、まずプロンプトを書き直します。ところが、もし不良の原因が検索の取りこぼしなら、考える工程や答える工程のプロンプトをいくら磨いても直りません。欲しい情報がそもそも手元に来ていないからです。これまでのプロンプト改善ツールの多くは、ラインの形を固定したまま指示文だけを言い換えるので、こうした「場所違いの修理」に陥りがちでした。

※本手法を手軽に試すためのエージェントスキルを文末に記載しています。

まず「どこで失敗したか」を見えるようにする

解決の出発点は、とてもシンプルです。各工程が何を出力したかを、すべて記録します。製造ラインの各工程に、検査員を一人ずつ置くようなものです。こうしておけば、完成品が不良だったときに記録をさかのぼり、どの工程で品質が落ちたのかをその場で確かめられます。当てずっぽうで直す代わりに、壊れた工程を名指しできるようになります。

記録の読み方も、難しくありません。たとえば検索の工程なら、答えが書かれた文書をちゃんと拾えていたかを見ます。拾えていなければ、犯人は検索です。検索は正しかったのに答えがだらだらと長い文章になっているなら、犯人は答えの書き方です。途中の工程が空っぽのまま次へ渡していたり、序盤のミスがそのまま後ろまで連鎖していたりするケースも、記録を突き合わせれば見えてきます。

壊れた場所が分かったら、いちばん小さい修理から試します。まずはプロンプトの文言を直す。これがいちばん手軽で、失敗しても影響が小さいからです。それでも直らないという証拠が出て初めて、ラインの組み方そのものに手を入れます。検索の回数を増やす、答えを整える工程を足す、といった変更です。順番をこう決めておくのには理由があります。最初からラインを作り替えてしまうと、どの変更が成績を動かしたのか分からなくなり、仕組みも無駄に複雑になるからです。

記録を読んで原因を見極め、修理して、試して、をひたすら繰り返すのは骨が折れます。そこを、コーディング支援のAIエージェントに丸ごと任せます。流れはこうです。

1. パイプラインを動かし、各工程の出力をすべて記録する（どこで失敗したかを見えるようにするため）
2. 点数の低かったケースを集め、記録から原因を工程ごとに振り分ける（犯人の工程を名指しするため）
3. いちばん多い失敗をねらって、修理案を一つだけ出す（一度に一つなら、何が成績を動かしたか分かるため）
4. まずプロンプトを直し、足りない証拠が出たときだけ構造を変える（小さく安全な修理から試すため）
5. その案を別の役がチェックする（ルール違反やデータの覗き見を防ぐため）
6. 問題なければ動かし直し、成績が上がったときだけ残す（確かに良くなった変更だけを積み上げるため）

これを、改善が頭打ちになるまで何度も繰り返します。

本当に良くなるのか、昔ながらのやり方と比べてみた

この自動の進め方を、昔ながらのプロンプト改善のやり方と正面から比べた実験があります。比較相手は、パイプラインの形は変えずに、指示文の言い換えだけでより良いものを探す手法です。どちらも、まったく同じパイプラインと同じ初期プロンプトから出発します。違うのは直し方だけです。

使用したのは三つのモデルと6種類のタスクです。タスクには、複数の文書をまたいで答えるQA、ある主張が事実かを確かめる検証、決められた形式どおりに答える課題、二種類の数学、個人情報を伏せながら答える課題が含まれます。一回の改善で試せる回数や巡回数には上限を設け、同じ条件で三回ずつ繰り返して平均を取りました。報告する数字は、検証データで最も良かった構成を、本番のテストデータで測ったものです。

結果はこうです。三つのモデルと6種類のタスクを掛け合わせた18通りの勝負のうち、15通りで新しい進め方が上回りました。平均すると、点数は+14.1ポイント上がっています。では、その差はどこで生まれたのか。具体的に何が起きるのかを、ある質問応答のタスクで追ってみます。

出発点のパイプラインは、答えがお手本と一字一句そろっている割合が約39%でした。記録を調べると、失敗は大きく三種類に分かれました。正解は言えているのに前置きが長すぎて不正解扱いになるものが13件、答えられるのに「分かりません」と逃げてしまうものが8件、純粋に間違えているものが17件です。

そこで、まず「答えは短く、余計な言葉を付けない」という指示を足しました。すると割合は65.7%へ跳ね上がります。次に「どんなときも必ず答えを出す」という指示を足すと、70.3%まで伸びました。ここまでは、プロンプトの修理だけでぐんぐん良くなっています。

ところが、その先で記録がこう告げます。残った失敗の多くは、答えそのものを間違えているのではなく、答えの根拠になる文書を検索が拾えていない。この種の失敗は、プロンプトをどう書き換えても直りません。欲しい情報が手元に来ていないからです。ここが、プロンプト改善の壁です。記録があるからこそ、「もうプロンプトでは無理だ」という見極めが、その場でつきます。

このタスクでは、最後までプロンプトの修理だけで十分でした。けれど、別のタスクではそうはいきません。たくさんの文書を渡り歩いて事実を確かめる検証では、記録が「検索がそもそも足りない」と指し示しました。そこで、検索の回数を3回から4〜5回に増やし、いくつもの切り口で探し、取りこぼした固有名詞を拾い直す工程を足しました。決められた形式で答える課題では、形式の崩れが主犯だったので、答えを最後に整える工程を一つ加えました。こうしてラインの組み方に踏み込んだとき、昔ながらのやり方との差は大きく開きます。

ここで思い出したいのは、比較相手はパイプラインの形を変えられないことです。だから、本当の原因が構造にあった課題では、どんなにプロンプトを言い換えても追いつけませんでした。新しい進め方の強みは、記録を頼りに「これはプロンプトでは直らない」と気づき、その一歩先へ進めるところにあります。

もちろん、良いことばかりではありません。ラインの作り替えまで許すと、試すたびに結果のばらつきが大きくなりました。運よく構造の問題を見つけて直せた回と、プロンプトの修理だけで終わった回とで、伸びがだいぶ変わるからです。また今回の比較は、新しい進め方のほうに「構造も変えてよい」という広い裁量を与えています。完全に同じ土俵での公平な勝負ではない点は、差し引いて読むのがフェアです。実際、競技数学の問題だけは、はっきりした上積みが出ませんでした。問題の幅に対して手元のデータが少なく、たまたまそのデータに合わせ込んでしまった可能性があります。

同じ問題でも、モデルが変われば最適なプロンプトは変わる

もう一つ、現場で役立つ発見があります。舞台は、セキュリティ分野の分類タスクです。脆弱性の説明文を読んで、それがどんな種類の弱点にあたるかを当てます。選択肢は200種類を超えます。最後の一行に種類の番号だけを書かせ、それが正解と合っているかで採点します。今回は構造には触れず、プロンプトの修理だけに絞りました。同じ課題に、三種類のモデルで挑みます。

面白いのは、いちばん成績の良かったプロンプトが、モデルごとにまるで違ったことです。大きくて賢い汎用モデルでは、間違えやすい種類の見分け方を細かく書き足すほど正答率が上がり、プロンプトは4行から23行へと膨らみました。ところが小型のモデルでは、同じようにルールを足すと、かえって出力の形式が崩れて成績が落ちます。いちばん良かったのは、要点だけに絞った2行ほどの短いプロンプトでした。出発点の半分の長さで、上げ幅は三つのモデルの中で最大です。別の小型モデルでは、短いプロンプトに一言の言い回しを添えるだけで、単独で約2.9ポイントの差が生まれました。

ルールを足せば足すほど良くなる、とは限りません。賢いモデルですら、序盤こそ書き足すほど伸びたものの、増やし続けると途中から頭打ちになり、さらに足すと逆に成績が下がる場面もありました。プロンプトの作り込みには、モデルごとにちょうどよい塩梅があり、それは実際に試して探すほかありません。一つのプロンプトをすべてのモデルに使い回すと、どこかで損をします。

「考えるモデル」が、古いモデルに負けて見える理由

ここで、見落とすと足をすくわれる落とし穴も紹介します。同じ16,000トークンという出力の上限を二つのモデルに与えても、その上限の数え方が違えば、話はまったく変わります。

推論をしない従来型のモデルでは、この上限はユーザーに見える答えだけにかかります。ところが新しい「考えるモデル」では、頭の中での思考と、ユーザーに見える答えの両方を合わせた上限として扱われます。考えれば考えるほど、答えに回せる分が削られていきます。実際このモデルは、数千件を通じて見える答えが約4,900トークンを超えませんでした。数学の問題では答えがごく短く切れたり形が崩れたりして、ある課題では見える答えの長さの中央値がわずか78トークン。これでは、答えを正確に取り出す採点に引っかかってしまいます。

その結果、出発点の成績では、新しいモデルのほうが低く見えました。性能が劣るからではなく、最後の答えに回すトークンが足りなかっただけです。上限を24,000〜28,000トークンへ引き上げ、思考に使う度合いを調整して、ようやく肩を並べました。モデルを比べるときやトークンの上限を決めるとき、見かけ上は同じ数字でも、答えに使える実際の分量はまるで違うことがあります。

自動で改善させると、答えを丸暗記してしまう危うさ

最後に、自動で改善を回すときの落とし穴にも触れておきます。「点数が上がった変更だけ残す」をひたすら繰り返すと、いつのまにか、手元の例題の答えにだけ都合よく合わせ込んでしまうことがあります。本番では通用しない、いわば一夜漬けの丸暗記です。

これを防ぐ最大のコツは、改善を担うAIに見せる情報と、採点に使う情報を分けておくことです。AIが直接読めるのは練習用のデータだけにし、本番に近い検証やテストでは、個別の答えは見せず、合計点だけを返します。すると、隠された答えそのものに合わせ込む芸当ができなくなります。実際の仕組みでは、四つの歯止めが組み合わされています。

• 改善役が直接見てよいのは練習用データだけにし、検証とテストは合計点しか返さない
• 変えてよい範囲と禁止事項を先に書き出し、提案役と確認役が別々にチェックする
• 試した案と点数、行き詰まった理由を、あとから追える形でログに残す
• 採用しても見送っても、変更のたびに新しいファイルとして保存する

自前で似た仕組みを組むときも、この「見せる情報の切り分け」と履歴の管理が、やりすぎた調整を防ぐ施策になります。

まとめ

何段もつないだLLMは、工程と工程のつなぎ目で失敗します。一つのプロンプトだけを磨いても限界があるのは、本当の原因がもっと手前にあったり、ラインの組み方そのものにあったりするからです。だからこそ、各工程の出力を記録して「中が見える」状態にし、失敗した場所を名指しし、いちばん小さい修理から試し、証拠がプロンプトの限界を示したときにだけ構造へ踏み込む、という順番が生きてきます。記録があれば、直すべき場所と直す順番を、勘ではなく根拠で選べます。

本記事の関連研究