LLMベースのシステム＆プロダクト構築パターン

• 7つの中核パターンを「性能向上 vs. コスト/リスク低減」および「データ志向 vs ユーザー志向」で整理
  • Evals: 性能測定
  • RAG(Retrieval-Augmented Generation): 最新の外部知識を追加
  • Fine-tuning: 特定タスクをよりうまく実行するため
  • Caching: レイテンシとコストを削減
  • Guardrails: 出力品質を保証
  • Defensive UX: エラーを予測して管理するため
  • Collect user feedback: データ・フライホイールを構築

Evals: 性能測定

• Evalsは、タスクにおけるモデルの性能を評価するために使われる一連の測定値
• ベンチマークデータとメトリクスを含む
• システムまたはプロダクトがどれだけうまく動作しているかを測定し、性能低下を検知できる
• 言語モデリング分野には多くのベンチマークがある: MMLU, EleutherAI Eval, HELM, AlpacaEval
• メトリクスは2つのカテゴリに分けられる: Context-dependent または Context-free
• よく使われるメトリクス: BLEU, ROUGE, BERTScore, MoverScore
• 最近のトレンドは、強力なLLMを reference-free metric として使い、他のLLMの生成物を評価すること
  • G-Eval, Vicuna 論文, QLoRA

RAG(Retrieval-Augmented Generation): 最新の外部知識を追加

• ファウンデーションモデルの外部から情報を取得し、そのデータで入力を強化してより豊かなコンテキストを与えることで、出力を改善する
• RAGは取得したコンテキストにモデルを基づかせることで幻覚を減らし、事実性の向上に役立つ
• また、LLMを継続的に事前学習させるよりも、検索インデックスを最新の状態に保つ方が安価
• このコスト効率の良さにより、LLMはRAGを通じて最新データにアクセスできる
• バイアスのある文書や有害な文書のようなデータを更新/削除する必要がある場合も、検索インデックスを更新する方が簡単（LLMをファインチューニングするのに比べて）
• RAGのためには、まずテキスト埋め込みを理解しておくと役立つ
• テキスト埋め込みは、任意の長さのテキストを数値の固定長ベクトルで表現できる、テキストデータの圧縮された抽象表現
  • 通常は Wikipedia のようなテキストコーパスで学習される
  • 類似する項目は互いに近く、類似しない項目はより遠くに位置するテキストの汎用エンコーディングと考えればよい
• 良い埋め込みとは、類似項目検索のようなダウンストリームタスクをうまくこなせるもの
  • Huggingface の Massive Text Embedding Benchmark (MTEB) は、分類、クラスタリング、検索、要約など多様なタスクでモデルを採点する
• ここでは主にテキスト埋め込みについて述べているが、埋め込みはさまざまなモダリティで利用できる
• Fusion-in-Decoder(FiD) は、オープンドメインQAのために生成モデルと検索を組み合わせて使う
• Internet-augmented LM は、既存の検索エンジンを使ってLLMを強化することを提案している
• RAGの適用方法
  • ハイブリッド検索（従来型の検索インデックス + 埋め込みベース検索）は、それぞれ単独の場合よりもうまく動作する

Fine-tuning: 特定タスクをよりうまく実行するため

• ファインチューニングは、事前学習済みモデル（膨大なデータですでに訓練されたモデル）を用い、特定のタスク向けに追加で洗練するプロセス
• モデルが事前学習中にすでに獲得した知識を活用しつつ、通常はより小さなタスク固有データセットを含む特定タスクに適用するためのもの
• 「ファインチューニング」という用語は緩く使われ、さまざまな概念を指す
  • 継続事前学習
  • インストラクション・ファインチューニング
  • 単一タスク・ファインチューニング
  • RLHF
• なぜファインチューニングするのか?
  • 性能と制御:
    • 既製のベースモデルの性能を改善し、サードパーティ製LLMを上回ることも可能
    • LLMの挙動をよりよく制御できるため、システムやプロダクトがより強力になる
    • ファインチューニングによって、単に他社製またはオープンなLLMを使うのとは差別化されたプロダクトを構築できる
  • モジュール化:
    • 単一タスクのファインチューニングによって、それぞれ固有のタスクを専門とする小さなモデル群を作れる
    • この構成により、システムをコンテンツモデレーション、抽出、要約などのタスクへとモジュール化できる
  • 依存性の低減:
    • 自前のモデルをファインチューニングしてホスティングすることで、外部APIにさらされる機密データ（例: PII、社内文書、コード）に関する法的問題を減らせる
    • また、レート制限、高コスト、過度に制限的な安全フィルタといったサードパーティ製LLMの制約も乗り越えられる
• Generative Pre-trained Transformers (GPT; decoder only)
• Text-to-text Transfer Transformer (T5; encoder-decoder)
• InstructGPT
• Soft prompt tuning & Prefix Tuning
• Low-Rank Adaptation (LoRA) & QLoRA
• ファインチューニングの適用方法
  • デモデータ/ラベルを収集
  • 評価指標を定義
  • 事前学習モデルを選択
  • モデルアーキテクチャを更新
  • ファインチューニング手法を選択（LoRA、QLoRA など）
  • 基本的なハイパーパラメータをチューニング

Caching: レイテンシとコストを削減

• キャッシングは、以前に取得または計算したデータを保存する技術
• 同じデータに対する今後のリクエストをより効率的に処理できる
• LLMでは、入力リクエストの埋め込みに対するLLM応答をキャッシュし、次のリクエストで意味的に類似した要求が来たらキャッシュ済み応答を返すことを指す
  • ただし一部の実務者は、これは「災厄が起こるのを待っているようなもの」だと言う。私も同意する
• キャッシングパターンを採用する鍵は、意味的類似性だけに頼るのではなく、安全にキャッシュする方法を見極めること
• なぜキャッシングするのか? : 待ち時間を減らし、LLMへのリクエスト数を減らしてコストを削減するため
• キャッシングを適用する方法は?
  • まずユーザーのリクエストパターンをよく理解することから始めるべき
  • キャッシングが利用パターンに対して有効かを検討する

Guardrails: 出力品質を保証

• LLMの出力を検証し、見た目が良いだけでなく、構文的に正確で事実に基づき、有害なコンテンツを含まないことを確認する
• なぜガードレールが必要なのか?
  • モデル出力が本番利用に耐えるほど信頼でき、一貫しているかを確認する助けになる
  • 追加の安全層を提供し、LLM出力に対する品質管理を維持する
• 1つのアプローチは、プロンプトによってモデルの応答を制御すること
  • Anthropic は、モデルが役に立ち、無害で、正直な（HHH）応答を生成するよう導くために設計されたプロンプトを共有している
• より一般的なアプローチは、出力の妥当性を検証すること（Guardrails パッケージのようなもの）
• Nvidia の NeMo-Guardrails は同様の原則に従うが、LLMベースの対話システムを導くよう設計されている
• Microsoft の Guidance のように、特定の文法に従うよう出力を直接調整することもできる（LLM向けDSLと考えられる）
• ガードレールの適用方法
  • Structural guidance
  • Syntactic guardrails
  • Content safety guardrails
  • Semantic/factuality guardrails
  • Input guardrails

Defensive UX: エラーを予測して管理するため

• 防御的UXは、ユーザーが機械学習またはLLMベースのプロダクトと対話する際に、不正確さや幻覚のような好ましくないことが起こりうると認めるデザイン戦略
• 主な目的は、ユーザー行動を導き、誤用を防ぎ、エラーを適切に処理することで、それらを事前に予測して管理すること
• なぜ防御的UXなのか?
  • 機械学習やLLMは完璧ではなく、不正確な結果を生成することがある
  • 同じ質問に対しても異なる反応を返す
  • 防御的UXは、次のものを提供することで上記の問題の緩和に役立つ
    • アクセシビリティ向上、信頼性向上、Better UX
• 各社が整理したガイドラインを参照
  • Microsoft’s Guidelines for Human-AI Interaction
  • Google’s People + AI Guidebook
  • Apple’s Human Interface Guidelines for Machine Learning
• 防御的UXの適用方法
  • 適切な期待値を設定する
  • 効率的に却下できるようにする（Enable efficient dismissal）
  • Attribution を提供
  • Anchor on familiarity

Collect user feedback: データ・フライホイールを構築

• ユーザーフィードバックを収集すると、ユーザーの好みを知ることができる
• LLMプロダクトに特有のユーザーフィードバックは、評価、ファインチューニング、ガードレール構築に貢献する
• 事前学習用の Corpus、専門家が作成したデモ、報酬モデリングのための人間の選好データは、LLMプロダクトにおける数少ない堀（Moat）である
• フィードバックは明示的なものにも暗黙的なものにもなりうる
  • 明示的フィードバックは、プロダクトからの要求に応じてユーザーが提供する情報
  • 暗黙的フィードバックは、ユーザーが意図的にフィードバックを提供しなくても、ユーザーとの相互作用から学習される情報
• なぜユーザーフィードバックを収集するのか
  • ユーザーフィードバックはモデル改善に役立つ
  • ユーザーが何を好み、何を嫌い、何に不満を持つかを学ぶことで、モデルを改善し、彼らのニーズをよりよく満たせる
  • また、個人の好みに適応することもできる
  • フィードバックループは、システム全体の性能を評価する助けにもなる
• ユーザーフィードバックの収集方法
  • ユーザーが簡単にフィードバックを残せるようにする: ChatGPT のように応答に高評価/低評価を用意する
  • 暗黙的フィードバックも考慮する: ユーザーがプロダクトと相互作用するときに生じる情報

[xguru]

実際の文章では各項目およびアルゴリズム/メトリクスについて詳しく説明していますが、ここでは省略しました。
この記事では要約だけざっとご覧いただき、原文もあわせて参考にしてください