自己紹介

LLM時代のデータ活用

プロダクト全体の最適化

• ファインチューニング（FT）
• 強化学習（RL）
• プロンプト最適化

ユーザー個人への最適化（パーソナライズ）

• コンテキストエンジニアリング
• RAG

ユーザーごとにモデル保持するのは非現実的なので、基本このパターンになるはず

モデル学習の種類とイメージ

STEP: 事前学習 → ファインチューニング → 強化学習

LLMを使う多くの企業は、プロンプトチューニングとファインチューニングだけやる

ファインチューニングと強化学習の比較

ファインチューニング

事前学習済みモデルを特定タスクに微調整する

低ランクの小さな重みを付け加えるPEFT（Parameter-Efficient Fine Tuning）のLoRA（Low-Rank Adaptation）が主流

強化学習（スキップするかも）

プロンプト自動最適化

入出力データセットを与えるとプロンプトを調整してくれるもの:

• DSPy
• Vertex AI プロンプト オプティマイザー

やる意義

• ユーザー提供して集まったデータをアノテーションし、更に良いプロダクトへ
• プロンプトチューニング地獄からの解放
• モデルリプレース時のチューニングの自動化

最近Gemini-2.5系の廃止計画が発表されたり、GPT-4o APIの廃止計画が発表されたり...
→ LLMをプロダクトに組み込んでいると、一斉にモデルリプレース作業に追われる

DSPyでプロンプト自動最適化

文章から趣味を抽出するtoy-problemで試してみた
モデル: gemma3、初期プロンプト: "趣味は？"（あえてテキトーなものに）
データセット (train: 56件, validation: 14件, test: 28件):

  {"sentence": "映画鑑賞が趣味で、毎週1本は必ず観ています", "hobby": "映画鑑賞"},
  {"sentence": "休日に散歩して鳥の写真を撮ります", "hobby": "バードウォッチング"}

【結果】 accuracy: 78.6% ← 手動チューニングだとなかなかここまでいけない

Given a sentence describing a person’s activity, 
identify and state the hobby being practiced. 
Output only the hobby.

{"sentence": "週末は公園でスケッチをして過ごします", "hobby": "スケッチ"},
{"sentence": "陶芸教室に通って、自分で器を作っています", "hobby": "陶芸"},
{"sentence": "旅行が好きで、日本全国を巡っています", "hobby": "旅行"}

プロンプト自動最適化の課題

API呼び出し回数が多いのでRateLimitに引っかかりやすい

• Vertex AI プロンプト オプティマイザーはResource Exhaustedで失敗
  • プロビジョンド スループットの購入が必要かも
• DSPyはローカルモデルGemma3で乗り切った

評価指標を定めるのが難しい

• 先程のtoy-problemのように完全一致や明確に答えがあるものは楽
• でも、実際に最適化したい需要って「日本語の自然さ」や「カジュアルさ」「適切にアドバイスできているか」など言語化しにくい曖昧なケースも多い
  • 評価をLLM as a Judgeにするにしても、そもそも評価モデルを作るのが難しい
    推論モデルを作るために評価モデルをチューニングするという鶏卵感...

参考: Geminiのファインチューニングは簡単にできる

コンテキストエンジニアリングの必要性

LLMの限界

• コンテキストウィンドウ（入力上限）がある（小説8冊分とか入る）
• 詰め込みすぎると指示を無視したり、性能劣化する

↓ LLMに与える情報を管理してあげる必要がある

コンテキストエンジニアリング

無数に増えていく（ユーザーの）情報を

• どう保存するか（そのまま？ラベル付け？集計？圧縮？）
• どう検索するか（最新N件？関連度？重要度？）

プロダクト作りで気にするところ

• データ取得時の検索クエリ / データ保存時の加工処理が案件ごとの設計ポイント！

RAG（Retrieval-Augmented Generation）

• 外部データを検索して応答する

典型的なRAGシステムの全体像：

• RAGはコンテキストエンジニアリングの一種と言える
• LLMは応答インターフェースでしかない（いかにうまく情報取ってこれるか勝負）

RAGの構成要素: 1. クエリ拡張

• ユーザーの曖昧な入力を、LLM等を使って具体的かつ検索しやすい形に変換する

USER: 社内の経費精算の締め切りはいつ？
AI: 月末です
USER: それを過ぎたらどうなる？

USER: PCが重いときの対処法は？

RAGの構成要素: 2. ハイブリッド検索

• DBの情報すべてLLMに渡すのは無理なので、LLMに渡す情報の絞り込み

全文検索: 文字列完全一致で検索（インデックスで高速化）
ベクトル検索:

RAGの構成要素: 3. リランキング 4. グラウンディング

3. リランキング: さらなる絞り込み！

• 検索でヒットした多数の候補から、本当に関連する文書を高精度なモデルで並び替え、上位のものだけを抽出
• 高精度なモデル
  • クロスエンコーダー（入力: 質問と文書のペア, 出力: 関係度スコア）
    • semantic-ranker, Qwen3-Reranker, hotchpotch/japanese-reranker など
  • 多段階にするならLLMが使われることも

4. 応答 + グラウンディング:

• 抽出した情報をコンテキストに入れて、ユーザーの質問に応答
• グラウンディング: 情報ソースとの紐づけ（回答の根拠）

RAGの前処理: ドキュメント保存時の前処理

• 必要な情報をうまく検索するためには、保存の仕方も重要になる

チャンキング:

• ドキュメントをチャンクに分割してDBに格納
• 切り方: ファイル単位、文書構造単位（章とか）、文字数、意味のまとまり
• 切られて文脈が途切れる問題への対策例:
  • チャンクを階層的にして親チャンクをLLMに渡す
  • チャンクに「全体から見たそのチャンクの要約や文脈」を含める
  • Agenticに足りない情報を取りに行く

あらかじめ想定質問を生成しておくパターンもある（工夫はいろいろあるようだ）

ReAct（Reasoning + Acting） Agent

• エージェントの基礎
• ReAct: Thought (思考)→Action (行動)→Observation (観察)

ツール群: Web検索, コード実行, 画像生成, ファイル検索, コンテキスト取得
→ ツール群にコンテキスト取得が入るとAgentic RAGになる

Reflexion（内省）

• Reflexion: 結果の振り返りを行い次の試行に活かす

• 先程のReActと組み合わせることもできる

Adaptive Planning

• AdaPlanner: プランを立てて結果に基づきプランを修正する

• CursorやClaude Codeもプラン立てて修正しながら動きますよね

世の中の賢いエージェントはこうした工夫を取り入れて設計されている

LangChainのAgentの動きを見てみよう

@tool
def func_add(a: int, b: int) -> int:     # 自作関数
    """足し算をする"""                     # Agentは、docstringを読んで判定してくれる
    print("called func_add")
    return a + b
@tool
def func_mul(a: int, b: int) -> int:
    """掛け算をする"""
    print("called func_mul")
    return a * b
agent = create_agent( # 関数を渡す
    model=ChatVertexAI(model="gemini-2.5-flash-lite"), tools = [func_add, func_mul]
)
result = agent.invoke(
    {"messages": [("human", "3と4を足した値に1+3を足した値同士を掛け算するとどうなる？")]}
)

たとえばこんな例だと中身はどうなるでしょうか？

LangSmithでAgentをトレース

Deep Researchの設計（ワークフロー型）

自然に考えるとこう書けるでしょう：

オープンソースでもいくつか出ています

• gemini-fullstack-langgraph-quickstart
• open_deep_research

Deep Researchの設計（エージェント版）

• エージェントがライブラリで提供される場合、
  実装箇所は「ツール群」と「システムプロンプト」だけで楽そう

ワークフロー型 vs エージェント

プロダクト実装で特定のタスクを実装する場合、
応答速度や制御性の観点からワークフロー型になるケースが多い気がする

マルチエージェント設計パターン

まとめ

• モデル最適化: ファインチューニング・強化学習でプロダクト全体を改善
• パーソナライズ: コンテキストエンジニアリングでユーザーごとに最適化
• エージェント: ツールを使って複雑なタスクを自律的に解決するが速度は遅め