Prompt as a Data Type: In-Database LLM Prompt Management and Rewriting

データベースとロボットの秘密の言語

想像してみてください。あなたには、数百万もの事実を保持する、巨大で超整理された図書館（データベース）があり、そこには、あらゆるものを読み解き理解することができる、非常に優秀で話し好きなロボット（大規模言語モデル、またはLLM）がいます。通常、このロボットに図書館の事実を使って仕事を行わせるには、人間が仲介役を務める必要があります。人間は図書館から紙切れを手に取り、ロボットへの特定の指示（「プロンプト」）を書き込み、それを送り、回答を待つのです。問題は、図書館自体が、ロボットがどのような指示に従っているのかを知らないことです。これは、冷蔵庫にどんな食材があるかは正確に知っているけれど、料理人が使っているレシピは見ることができないシェフのようなものです。レシピがカウンターの上のノートの中に隠されているため、シェフは悪いレシピを修正したり、より良い食材を提案したりすることができません。

この論文は、コンピュータサイエンスにおいて、データベースと人工知能が交差する世界へと踏み込みます。それは、現在直面しているある「頭痛の種」に取り組んでいます。それは、現在、AIロボットに与える指示が、多くの場合、データベースの外にある乱雑なコードやノートブックの中に保存されているという問題です。これにより、データベースがその指示が良いものかどうかをチェックしたり、混乱を招くような場合に修正したり、あるいは実行コストを安くしたりすることが難しくなっています。著者らは、ある急進的なアイデアを提案しています。それは、「もしこれらの指示を、名前や数字と同じように、データベースのテーブル内に格納される他のデータと同じように扱ったらどうだろうか？」というものです。指示をデータベースにとって「可視化」されたものにすることで、システムはデータベース自身の知識を用いて、ロボットがより良く仕事を遂行できるように、指示をよりスマートに、より速く、より正確に自動的に書き換えることができるようになるのです。

論文の核心：データとしてのプロンプト

著者であるデニス・メイア・リマ・マルティンス（Denis Mayr Lima Martins）とゴットフリード・フォッセン（Gottfried Vossen）は、PromptDBと呼ばれる新しいシステムを紹介しています。これは、単に事実を保存するだけでなく、AIと対話するための「指示」も保存するデータベースだと考えてください。従来のシステムでは、例えば顧客の苦情（例：「荷物が届きません！」）を分類したい場合、アプリケーションコード内でプロンプトを書き、テキストをデータベースから取得し、それをAIに送信します。データベースにとって、そのテキストは単なる文字列に過ぎず、それが実行されるべき一連の指示であることを知りません。

PromptDBでは、プロンプトは**第一級オブジェクト（first-class citizen）**です。それはPROMPTと呼ばれる特別なデータ型です。指示をノートの中に隠す代わりに、データベースはそれらを、記述対象となるデータと共に、テーブルの行の中に直接保存します。行の構成は以下のようになります：

• チケットID: 1001
• メッセージ: 「荷物が届きません」
• 優先度: 高
• 指示: PROMPT("このチケットを分類してください: {{body}}", output: [refund, delivery, technical, other])

ここでは、指示は構造化されたオブジェクトです。それはテンプレート（「このチケットを分類してください...」）を知っており、行のどの部分を流し込むべきか（body）、そして有効な回答のリスト（output）を知っています。データベースは指示を「見る」ことができるため、スマートなエディターとして機能できるのです。

魔法のエディター：PromptOpt

本当の魔法は、PromptOptと呼ばれるコンポーネントによって起こります。あなたが生徒のエッセイを採点している教師だと想像してください。もし生徒が長々ととりとめもなく書いたなら、「簡潔に書きなさい」と言うかもしれません。もし必要な手順を書き忘れていたら、「足りない手順を追加しなさい」と言うかもしれません。PromptOptは、これをAIプロンプトに対して自動的に行います。

このシステムは、データベース自身の知識を利用して、AIに送る前に指示を書き換えます。これにはいくつかのテクニックがあります：

1. 制約の注入（Constraint Injection）: もしデータベースが、有効な回答は「refund（返金）」または「delivery（配送）」のみであることを知っていれば、PromptOptはプロンプトを書き換え、AIに対して「必ずこれらの正確な言葉のいずれかを選ばなければならない」と明示的に伝えます。これにより、AIが「顧客が悲しんでいる」といった奇妙な回答を生成することを防ぎます。
2. 列の投影（Column Projection）: もし行に50個の列のデータがあっても、AIが「メッセージ」列だけを必要としている場合、PromptOptは他の49個を削ぎ落とします。これにより、コスト（読み取るトークン数）を節約し、混乱を軽減します。
3. フューショット例（Few-Shot Examples）: システムはデータベース内の他の行を調べ、正しい回答の優れた例を見つけ出し、それらをプロンプトに挿入することで、AIに何をすべきかを具体的に示します。

システムは、これらの書き換えを「クエリ最適化器」のように扱います。データベースのオプティマイザがデータを検索する最も速い方法を決定するように、PromptOptはプロンプトの最適な書き方を決定します。それは、コスト（AIがどれだけの言葉を読み書きするか）と品質（回答が正しい可能性）を天秤にかけます。単純なタスクであれば短いプロンプトで十分だと判断することもあれば、難しいタスクであれば、追加のコストを払ってでも例示を加える価値があると判断することもあります。

彼らが発見したこと

著者らは、3つの異なるデータセット（架空のサポートチケット、車の評価データセット、および標準的な業界データセットであるTPC-H）を用いてPromptDBをテストしました。彼らは以下の3つの手法を比較しました：

1. 静的（Static）: プロンプトが一度書かれたら変更されない、従来の方法。
2. 全ルール（All Rules）: あらゆる可能な書き換えルールを盲目的に適用するバージョン。
3. PromptOpt: 特定の仕事に対して最適な書き換えを選択するスマートなバージョン。

結果は、プロンプトをデータとして扱うことが有効であることを示唆しています。

• 品質の向上: タスクが特定の選択肢から選ぶことを要求する場合（例：チケットの分類）、データベースによる書き換えによってAIの精度が大幅に向上しました。「全ルール」のアプローチはしばしば最高の結果を出しましたが、コストがかかりました。
• トレードオフ: PromptOptシステムは、スイートスポットを見つけ出すことができました。常に最も高価で複雑なプロンプトを選ぶわけではありません。代わりに、その仕事にとって「十分な」シンプルなプロンプトを選択し、高品質な結果を維持しながら計算コストを節約しました。例えば、いくつかのテストでは、PromptOptは静的な手法よりも大幅に少ない入力トークン数で、競争力のある品質を達成しました。
• タスクによる違い: 論文は、「一つのサイズがすべてに適合するわけではない」と指摘しています。「セマンティック・フィルタリング（行がルールに一致するかチェックすること）」に役立つ書き換えが、「値の正規化（乱れたテキストのクリーニング）」には役立たないこともあります。システムは、将来のバージョンでは、どのルールをどのタスクに使用すべきかを判断する能力をさらに高める必要があることを示唆しています。

これが意味すること（そして意味しないこと）

この論文は、AIへの指示を、隠された、変更不可能なコードとして扱うのをやめるべきだと主張しています。指示を可視化されたデータにすることで、制約に関する知識、データのフィルタリング能力、そして最適化スキルといったデータベースの強力な能力を活用し、AIとのやり取りをより信頼性が高く、効率的なものにできるのです。

しかし、著者らはこれが完璧に解決された問題であると主張しているわけではない、と注意深く述べています。彼らは、現在のシステムが、プロンプトがどれほど優れているかを正確に知る完全に学習されたAIモデルではなく、単純な「ヒューリスティック（経験則）」に基づいたルール（教育的な推測）を使用して品質とコストを推定していることを認めています。彼らは、プロトタイプがシミュレーションや特定のデータセットでうまく機能している一方で、「品質推定器」はあらゆるタスクを完璧に扱うために、より賢くなる必要があると示唆しています。

要約すると、PromptDBは、データベースが単なる事実の倉庫ではなく、AIのためのアクティブなコーチとなり、リアルタイムで指示を書き換えて、仕事が正しく、速く、かつリソースを無駄にすることなく遂行されるようにする未来を提示しています。これは、AIをブラックボックスのように感じさせるのではなく、データの世界の自然な一部として感じさせるための、一歩となります。