どうも！RAG開発中であるITエンジニアのオロポンです！
最近どこの企業でも生成AI利活用が盛んに行われていますね！
しかし、皆様の中で実際にAI使ってみたけど、「なんか思ってたアウトプットと違う…」って経験ありませんか？
実はそれ、AIの性能の問題じゃないことが多いんです。 プロンプト（AIへの指示文）を変えるだけで、結果がガラッと変わるんですよね！
今日は、オロポンが社内ノウハウのRAG構築で実際にハマったこと、そこから学んだ「プロンプトの書き方」について話したいと思います！
社内ドキュメントがカオスすぎて、LLMに整理させることにした
現在、社内ドキュメントを使ったRAG（社内知識をAIに持たせる仕組み）システムを作ろうとしているのですが、ドキュメントをかき集めてみたら…想像以上のカオスが(T . T)
- ファイル名の命名規則がない
- 2008年の稟議書と2024年の仕様書が同じフォルダに共存
- 営業資料なのか経営企画のレポートなのか、ファイル名だけでは全く判別できない
これをそのまま処理してRAGを構築しても検索精度が出るはずがない！ということで、軽量LLMにドキュメント前半部分を読ませて、部署名・文書種別・作成年などのメタデータを自動抽出させる作戦に出ました。
「役割とルールだけ渡せばOKでしょ」→ 甘かった(^^;)
最初に書いたプロンプトは至ってシンプルなもの。LLMに与える役割と抽出項目を書いて、「JSON形式で返してね」と指示しただけです。
#プロンプトイメージ
あなたは社内ドキュメントのメタデータを抽出するアシスタントです。
以下のドキュメントを読んで、次の情報をJSON形式で返してください。
- document_type: ドキュメントの種類（例：議事録、仕様書、報告書など）
- department: 作成部署
- estimated_year: 作成年（推定）
ドキュメント:
{document_content}「これでもある程度いけるでしょ！」と思ってたんですが、動かしてみると2つの問題が…
問題① 出力の表現がバラバラ
同じ仕様書なのに「仕様書」「技術仕様」「Technical Spec」と毎回違う表現が返ってくる。もしくは、ドキュメント内に記載はあるのに何も抽出できなかったり…
こんなんですと、RAG構築して「仕様書」で検索しても「Technical Spec」や抽出できなかったドキュメントがヒットしないので、メタデータとして使い物にならないですよね(T_T)
問題② 再現性が低い
同じファイルを何度流しても、結果が微妙に変わる。department が「システム部」になったり「情報システム部」になったり「IT部門」になったり…。
どちらもAIの出力結果には、あるあるな問題ですよね。
オロポンも「どう直せばいいんだ！?」って、しばらく頭を抱えていました(^_^;)
解決策は「制約」と「例示」
ネットで情報収集したり、AI相手にディスカッションした末に辿り着いた答えが「制約」と「例示」でした！
① 選択肢を制約として明示する
例えば、document_typeに使っていい値をリストで指定してあげる。
#プロンプトイメージ
- document_type: ドキュメントの種類
※必ず以下から選択：議事録 / 仕様書 / 報告書 / 提案書 / マニュアル / その他これだけで「仕様書」だったり「Technical Spec」みたいな表記揺れや自由表現が大幅に抑えられます。
② 期待する出力のサンプルをプロンプトに直接書く
百聞は一見にしかずって言いますが、AIに対しても全く同じです。実際のドキュメント内容を人間が分析して、「こういう入力のときはこう返してね」という例を見せてあげるだけで、出力の”型”が一気に安定します。
#プロンプトイメージ
【出力例】
入力：
「2023年10月 第3回プロジェクト定例会議 議事録
出席者：田中（営業部）、鈴木（開発部）…」
出力：
{
"document_type": "議事録",
"department": "営業部,開発部",
"year": 2023
}この2つの内容をプロンプトに加えることで軽量LLMの動作が安定したため、安心してメタデータ抽出を丸投げできるようになりました(^o^)
「たったこれだけで！？」って思うかもしれないですが、LLMの動き方を考えると意外と納得できる話なんです
なぜ「制約」と「例示」でここまで変わるの？
LLMは、ざっくり言うと「次にくる言葉を予測する」仕組みです。
大量のテキストから文脈を読んで、「この流れならこういう言葉が来るはず」と推論して出力しているんですね。
制約（選択肢の指定） があると…
テキストの中に「Technical Spec」と記載がある。document_typeは、「Technical Spec」だろう。
でも、リストの選択肢にはないから、リストの中で一番意味が近い「仕様書」と出力！
と出力の範囲を絞ることができます。自由に表現を選ばせると毎回ブレるのが、選択肢を明示することでピタッと安定するんです！
例示（出力サンプル） があると…
テキストの中に「出席者：田中（営業部）、鈴木（開発部）」と記載がある。
色んな部署の人が出席してるから、departmentは「複数部署」？
でも、今回みたいな入力に対して、全部署名を抽出するように例示がある。
なら、「営業部,開発部」と出力！
とLLMが出力の”型”をより具体的に掴めるようになります！
人間でも、「プレゼンは簡潔にまとめてください」と言われるより「こういうスライドのイメージです」と見本を見せてもらったほうが断然わかりやすいですよね？AIも全く同じなんです。
ちなみにこの具体例を実際にプロンプトに書く手法ですが、Few-shot Prompting（フューショット・プロンプティング） 呼ばれている様なので、もっと詳しく知りたい方は調べてみてください！
まとめ：「AIが使いづらい」と感じたら、まずプロンプトを見直してみよう！
今回の経験で改めて実感したのが、プロンプトはAIが考えるための文脈を設計するものということです。
「役割の説明」「抽出ルール」だけでは出力が安定しなかったのが、「出力例の提示」を加えてはじめて安定した出力をしてくれる様になりました！
「AIを使ってみたけど、思ってたのと違う結果が返ってくる…」という方は、ぜひこの2つを試してみてください！
- 出力の選択肢を制約として明示する
- 期待する出力や禁止する出力の例を1〜3個、プロンプトに記載する
同じAIでも、プロンプト次第でまったく別の挙動をします。 「このAIモデル使えないな」と嘆く前に、まず「お願いの仕方」を変えてみてください！
高性能モデルの利用はコストが上がってしまいますが、プロンプトを変えるコストはほぼゼロです！
でもリターンは思った以上に大きいので、ぜひ皆さんの用途にあったプロンプトを準備してみましょう！
