AIの生成結果を検証する際に切り分けるべき2つの検査
AIの生成結果をコードで検査する場合とモデルに評価を委ねる場合では、確認できる事柄が異なります。タスクに適した検証基準を考察しました。
AI・テックAIが生成した結果を何で検査すべきか
数年前までは、プロンプトエンジニアリングが主に注目を集めていました。モデルが意図通りに動くまで、1つの文を修正し続ける作業でした。昨年には同じ作業にコンテキストエンジニアリングという新しい名前が付き、今年のスレッドではループエンジニアリングと呼ばれています。その下にはいつも同じフレーズが添えられます。「いまやボトルネックはモデルではなく、検証者(ベリファイア)にある」。
名称が変わるたびに、開発者たちは判を押したように反応します。「本当に何かが変わったのか? それとも有料講座を売りたいだけで名前を付け替えたのか?」。この疑念はおおむね的を射ています。AIツールの用語は、それが指し示す課題そのものよりもはるかに速いペースで消費されていくからです。
私が着目しているのは、作業のスコープが広がったという点です。指示文を書く作業から、モデルに投入する資料を選び、生成と検査を繰り返すプロセス全体を設計する作業へと関心が移りました。 ただし、最新の呼び名が指し示す課題自体は本物であるものの、名前を付けたからといってその課題が解決するわけではありません。
作業単位がプロンプト1文だった時代
2022年から2024年までを振り返ってみましょう。多くのユーザーはプロンプトの文面を推敲することに集中していました。フューショット1の例を入れ、役割を与え、「ステップバイステップで考えてみて」と付け加え、何を先に尋ねるか順序を入れ替える、といった工夫です。検索結果を連携させたりツールを使わせたりする方法もありましたが、一般のユーザーにとって最も身近な改善策はプロンプトを書き直すことでした。
当時を振り返ると、ノウハウのほぼすべてが「1文をどう書くか」に集約されていました。例をいくつ入れるか、どのような順序で問いかけるか、いかに役割を与えるか。現在でもこの感覚は有効です。優れたプロンプトが優れた出力の出発点であることに変わりはないからです。しかし現在では、指示文の工夫だけで解決するのが難しいタスクを任せるケースが増えています。