LLM と生成 AI のアプリ

RAG（Retrieval-Augmented Generation、検索拡張生成）は、質問に関係する文書を先に検索し、それを LLM に「この資料をもとに答えて」と渡す方法です。LLM が学習していない社内の情報や新しい情報でも答えられ、根拠の文書を示せます。逆に言えば、正しい文書が検索で見つからなければ、どんなに良い LLM でも正しく答えられません。

基本の流れ：

[準備] 文書 → チャンクに分割 → 埋め込み（ベクトル化）→ ベクトル DB に保存
[質問] 質問 → 埋め込み → 似たチャンクを検索 → 再ランキング → 上位を LLM に渡して回答

生成の側：プロンプトで「資料にないことは分からないと答える」「根拠の文書を示す」と指示し、引用元を画面に出します。これでハルシネーション（もっともらしい作り話）を減らし、利用者が確かめられるようにします。

よくある失敗：表や PDF の段組みが崩れたまま取り込んでいる、古い版と新しい版の文書が両方ヒットする、質問が短すぎて検索が外れる。回答を直す前に、まず「正しいチャンクが上位に入っているか」を確かめます。

チャンクは、文書を検索の単位に切ったものです。チャンクの切り方で、検索で見つかるかどうかが大きく変わります。

正解は文書の種類で違うので、いくつかの切り方で Recall@K（正しいチャンクが上位 K 件に入る割合）を比べて決めます。切り方を変えたら、埋め込みも作り直します。

埋め込み（embedding）は、文章を「意味が近いほど近くなる」数の列（ベクトル）に変えたものです。質問とチャンクを同じモデルで埋め込み、質問に近いチャンクを探すのがベクトル検索です。言い回しが違っても意味が近ければ見つかるのが強みです。

埋め込みは推薦（似た商品）・重複の検出・分類の特徴量にも使えます。下の DB ラボで、pgvector を使った近いもの探しを試せます。

ベクトル検索は意味の近さに強い一方、型番・人名・エラーコードのような固有の文字列は苦手です。そこで、キーワード検索（BM25：単語の出現の多さと珍しさで点数を付ける方法）と組み合わせるのがハイブリッド検索です。

改善の効果は、評価データの Recall@K や NDCG で、ベクトル検索だけの場合と比べて確かめます。

LLM の振る舞いを変える一番手軽な方法がプロンプトです。思いつきで書き足していくと、どこが効いているか分からなくなるので、部品に分けて組み立て、評価データで比べながら直すのが基本です。

LLM の振る舞いを変える方法は、手軽な順に「プロンプトの工夫 → RAG → ファインチューニング（追加学習）」です。まずプロンプトと数件の例（few-shot）で十分かを確かめるのが原則で、それで足りない部分だけ次に進みます。

注意点：ファインチューニングには、質の良い学習データ（数百〜数千件の入力と理想の出力の組）と、学習の前後を比べる評価データが必要です。学習で元の能力の一部を忘れることがあるので、狙った以外の能力も評価します。使うモデルのライセンスと、API の場合は利用規約で学習が許されているかを確認します。

LoRA など：LLM の全部の重みを学習し直すのは、GPU のメモリも時間も大量に必要です。LoRA（Low-Rank Adaptation）は、元の重みは固定したまま、小さな追加の行列だけを学習する方法で、学習する重みの数が元のごく一部になります（LoRA の論文の GPT-3 の例では、学習する数が約1万分の1、GPU のメモリが約3分の1）。必要な GPU が減り、追加分のファイルも小さいので、用途ごとに付け替えられます。元のモデルを4ビットなどに量子化してから LoRA で学習する QLoRA もあります。

LLM アプリは、同じ質問でも答え方がいくつもあり、「正解と完全に一致するか」では測れません。そのため、評価データ・自動の採点・人の確認を組み合わせます。評価の仕組みがないと、プロンプトやモデルを変えたときに「良くなった気がする」で判断することになり、どこかが静かに悪くなっても気づけません。

評価データの作り方：

• 実際の利用から集める：本番やテスト利用のログから、よくある質問・難しい質問・失敗した質問を拾います。まず 50〜200件でも十分役に立ちます。
• 期待する答えか、採点の基準を付ける：模範回答そのものより、「必ず含むべき事実」「言ってはいけないこと」「根拠にすべき文書」を書くほうが採点しやすいです。
• 種類をそろえる：答えのない質問（「分かりません」が正解）、意地悪な入力、長い入力も入れます。
• LLM で質問を作って水増しすることもできますが、人が目を通して、実際の利用と似ているかを確かめます。

回帰テストとしての評価：評価データは、普通のソフトウェアのテストと同じように使います。プロンプト・モデル・検索の設定・チャンクの切り方を変えるたびに、CI などで評価を流し、点数が前回より下がった項目を確認してから出します。モデルの提供元が版を更新したときも同じです。本番で見つかった失敗は評価データに足し、同じ失敗を二度出さないようにします。LLM の出力はばらつくので、温度を下げる・数回流して平均を見る、などで比較を安定させます。

RAG では、検索（正しい文書が上位にあるか：Recall@K）と生成（渡した文書に沿って正しく答えたか）を分けて採点すると、どちらを直せばよいか分かります。

LLM アプリには、普通の Web アプリにない危険があります。代表的なものと対策です。

どの対策も完全ではないので、「LLM がだまされても大きな被害にならない設計」にしておくのが基本です。

コストの管理：料金は、おおむね「入力トークン数＋出力トークン数（出力のほうが単価が高いことが多い）」で決まります。

• モデルの使い分け：分類・抽出・言い換えのような簡単な処理は小さく安いモデル、難しい推論だけ大きいモデルにします。最初に小さいモデルで振り分けるルーティングも使えます。
• キャッシュ：同じ質問への答えを保存して使い回します。毎回同じ長いシステムプロンプトを送る場合は、提供元のプロンプトキャッシュ（毎回同じ先頭部分の処理を使い回し、その分の料金と待ち時間を下げる仕組み）が使えるか確認します。対象になる最小の長さ・保存される時間・割引の率は提供元ごとに違うので、それぞれの説明を確かめます。
• トークンを減らす：渡す文書を必要な分だけにする、会話の履歴を要約する、出力の上限（max tokens）を決める。
• 見える化：機能ごと・利用者ごとのトークン数と費用を記録し、1日の上限やレート制限を設けます。ループするエージェントは、呼び出し回数の上限を必ず付けます。

LLM に「使える道具（ツール）」の名前と引数の形を教えておくと、LLM は必要に応じて「この引数でこのツールを呼んで」と返します。アプリがそれを実行して結果を返し、LLM が続きを考えます。これを何度もくり返して作業を進める仕組みをエージェントと呼びます。

評価は、最終の答えだけでなく、正しいツールを正しい順で呼んだか、無駄な呼び出しがないかも見ます。まずは手順が決まった処理（固定のワークフロー）で足りないかを考え、本当に判断が必要な部分だけエージェントにするのが安全です。