仕組みの名前が安心材料として使われる
「RAGを使っているので正確です」。仕組みの名前が、確認の代わりに置かれることがあります。名前が出た時点で質問が止まるなら、その名前は説明ではなく安心材料として機能しています。
技術の名前が出てくること自体は正常です。問題は、名前が出た時点で議論が終わる場合です。「RAGを使っています」という説明は、構成の情報であって品質の保証ではありません。
型1 ― 「RAGを使っているから正確」
最も頻繁に見られる型です。RAGは回答時に文書を参照させる方式であり、参照が成功した場合に根拠のある回答が得られる、という仕組みです。参照が失敗した場合の振る舞いは、別途設計しなければ保証されません。
表の第2章で挙げた限界を、確認項目として並べ直します。
| 限界 | 確認する質問 | 答えがない場合の意味 |
|---|---|---|
| 検索漏れ | 必要な文書が見つからなかった場合、どう振る舞いますか | 推測で答える設定のままである可能性 |
| 出典の表示 | 回答の根拠となった文書を利用者が確認できますか | 利用者が検証できない |
| 文書の版 | 新旧の版が混在している場合、どちらを使いますか | 古い規程を根拠に答え得る |
| 文書の更新 | 参照文書を更新する担当と頻度は決まっていますか | 時間とともに回答が古くなる |
| 権限 | 利用者が見てよい文書だけが参照対象になりますか | 権限のない情報が回答に混じる |
| 矛盾 | 複数の文書が異なることを述べている場合の扱いは | どちらが選ばれるか不定 |
この6問のうち、最初の1問が最も重要です。「わからない」と答える設定がなければ、根拠がない場合でも推測で答えます。RAGを使っているかどうかとは無関係な設計事項です。
型2 ― 不要な場面でのファインチューニング提案
ファインチューニングはモデルの振る舞いを変える手法であり、知識を追加する手段としては適さない場面が多くあります(表の第2章)。にもかかわらず、「社内情報に基づいて答えさせたい」という要望に対してファインチューニングが提案される例があります。
この提案が問題になる理由は3つです。
- 初期費用が高い ― 学習と検証の工数がかかります。
- 更新のたびに再学習が必要 ― 規程が年数回改定される場合、そのたびに費用が発生します。
- 依存が深まる ― 追加学習済みモデルは移行が難しく、依存の段階が最も深くなります(第10章、表の網羅版 第10章「事業継続・ベンダー依存リスク管理」)。
切り分けの質問
次の1問で判断できます。
「足したいのは知識ですか、変えたいのは振る舞いですか」
知識(社内規程、製品仕様、最新の情報)であればRAGです。振る舞い(出力形式の固定、文体の統一、業界固有の分類基準)であればファインチューニングが選択肢に入ります。
この質問に対して「両方必要です」という回答が返る場合は、どちらから着手するかを確認してください。多くの場合、RAGを先に構築して不足を確認してから、ファインチューニングの必要性を判断するほうが費用が小さくなります。
型3 ― 「エージェント」という語の空証文化
エージェントは、目的から手順を決めて複数の操作を実行する仕組みです(表の第2章)。この語が、次のような場合にも使われることがあります。
- 単一の処理を順番に呼び出しているだけの構成
- あらかじめ決めた手順を実行するだけの自動化(AIが手順を決めていない)
- 複数のプロンプトを連続して実行する構成
これらが劣っているわけではありません。むしろ手順が固定されているほうが、検証も運用も容易です。問題は、「エージェント」という語が、実態より高度な自律性を示唆することです。
確認と、確認したほうがよい理由
次の2問で実態が分かります。
- 「手順はAIが決めますか、あらかじめ決まっていますか」
- 「AIが実行できる操作の一覧を見せてもらえますか」
2問目が実務上重要です。エージェント型では使える道具の一覧がそのまま権限の一覧になります(表の網羅版 第21章「セキュリティ」)。この一覧を示せない提案は、権限設計を行っていない可能性があります。逆に、一覧が示されれば、承認を挟むべき操作を自社で判断できます。
「マルチエージェントで精度を高めています」という説明を受けたときは、工程数と、それによる費用・応答時間の増加を確認してください。役割を分けて検証させる構成には利点がありますが、工程が増えるほど費用と待ち時間が増え、障害時の切り分けも難しくなります。単一の処理で足りるものを多段にしている場合、増えているのは複雑さと費用だけです。
型4 ― プロンプトを「魔法の言葉」として売る
指示の書き方は結果を変えます。しかし変わるのは指示した範囲の中身だけで、指示しなかった観点は出力に現れません(表の第2章・第11章)。この限界を踏まえない売り方があります。
- 「このプロンプトで業務が変わる」 ― プロンプト単体では、参照データ・権限・確認工程・費用管理は解決しません。
- プロンプト集の販売・研修 ― 有用な場合もありますが、自社の業務データで検証しない限り効果は不明です。使用しているモデルの系統によって有効な技法が違う点も踏まえる必要があります。
- 「言い方次第で精度が上がる」を精度検証の代わりにする ― 検証セットでの比較が省略されます。
実務的な扱い
プロンプトは実質的にコードの一部です(表の網羅版 第13章「AIシステムのアーキテクチャ設計」)。したがって扱いも同じにします。
- 本番で使うものはコードと同じ場所で管理し、変更履歴を残す
- 変更したら検証セットを流し、他の項目を悪化させていないか確認する
- 効果は感覚ではなく数値で判定する
- 外部から入手したプロンプトは、内容を確認してから使う(第21章のサプライチェーン)
この扱いにすると、「魔法の言葉」という位置づけが自然に消えます。効果があるものは数値で残り、ないものは残りません。
型5 ― 推論モデルを万能として説明する
推論モデルは、応答前に内部で長く検討することで精度を上げる系統です(表の第2章)。多段の判断を要する処理では明確な差が出ますが、性質としてのトレードオフがあります。
説明で省略されやすい点を挙げます。
- 応答時間が長くなる ― 対話型の用途では利用率に影響します。既存システムのタイムアウト設定に当たる場合もあります。
- 費用が高くなる ― 内部の検討分も課金対象になるため、同じ入力でも費用が変わります。
- 単純な処理には過剰 ― 定型の抽出や分類に使うと、費用と待ち時間だけが増えます。
確認は「この処理は多段の判断を含みますか」で足ります。含まない処理に推論モデルが提案されている場合、費用の見積もりが実態より大きくなっている可能性があります(表の第3章の桁感)。
五月十二日の社内ナレッジ検索のコンペで、クラウゼル・テクノロジーズは朝凪専用にファインチューニングした独自モデルを提案しました。規程は年に数回変わり、今年も旅費規程がすでに1回変わっています。情報システム課の倉田の整理では、足したいのは知識で、文書を検索して渡すRAGで足ります。三日後、アストラム・データとの打ち合わせでAI推進室の瀬尾が「必要な文書が見つからなかった場合、どう答えますか」と聞くと、技術者は、標準設定では近い文書から推測して答える、「該当する文書が見つかりません」と返す設定もできる、と答えました。瀬尾はこの問いと出典の表示を、3社共通の質問票に入れました。判断に効いたのは、改定のたびの再学習の費用が要らなくなること以上に、改定時の作業が文書の差し替えだけで済むことでした。
この場面は網羅物語之巻 第2章「RAGと言われても」に出てきます。
この章の確認質問
- 「必要な文書が見つからなかった場合、どう振る舞いますか」 ― RAGの説明を受けたとき。
- 「回答の根拠となった文書を利用者が確認できますか」 ― 出典表示の有無。
- 「参照文書を更新する担当と頻度は決まっていますか」 ― 運用の設計。
- 「足したいのは知識ですか、変えたいのは振る舞いですか」 ― 手法の切り分け。
- 「手順はAIが決めますか、あらかじめ決まっていますか」 ― エージェントの実態。
- 「AIが実行できる操作の一覧を見せてもらえますか」 ― 権限設計の有無。
- 「この処理は多段の判断を含みますか」 ― 推論モデルの必要性。
- 「プロンプトの効果は、どの検証で確認しましたか」 ― 数値による裏付け。
8問すべてを毎回聞く必要はありません。提案の中で強調されている技術の名前に対応する質問を1つ選べば足ります。