プロンプトから「コンテキスト設計」へ：外部知識を統合する高精度情報抽出エンジンの構築

Tech

{ “focus”: “Context Engineering for LLMs”, “techniques”: [“CoT”, “Structured Output”, “Few-shot”, “Context Grounding”], “target_models”: [“Gemini 1.5 Pro”, “GPT-4o”], “version”: “1.0.0” } 本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

プロンプトから「コンテキスト設計」へ：外部知識を統合する高精度情報抽出エンジンの構築

【ユースケース定義と課題】

膨大な社内資料をコンテキストとして入力し、事実誤認を排除した上で「結論・根拠・課題」を構造化したJSON形式で抽出する。

  • 入力型: 非構造化テキスト（会議録、技術文書等）

  • 出力型: 厳密なスキーマに基づくJSON

【プロンプト設計のループ】

graph TD
A["設計: コンテキストの構造化"] --> B["実行: 推論と抽出"]
B --> C["評価: 事実整合性と書式"]
C -->|改善: 制約の追加| A

  1. 設計: 単なる命令ではなく、LLMが情報を処理しやすいようタグ（<context>等）で情報を分節化。

  2. 実行: Chain-of-Thoughtを用い、回答前にコンテキストから証拠（Evidence）を引用させる。

  3. 評価: 出力されたJSONのパース可否と、ソース文書に存在しない情報の混入（ハルシネーション）をチェック。

【プロンプトの実装案】

# Role

あなたは高度な情報分析官です。提供されたコンテキストのみに基づき、以下のタスクを遂行してください。

# Task

入力された資料から重要な事実を抽出し、指定のJSONフォーマットで要約してください。

# Constraints


- コンテキストに記載のない情報は絶対に含めない（Know-nothing制約）。

- 回答は必ず有効なJSONオブジェクトのみを出力する。

- 抽出する際は、まず「思考プロセス」として、どの文言を根拠にしたかをリストアップすること。

# Context

<document>
{{INPUT_TEXT}}
</document>

# Output Format

{
  "thought_process": "抽出の根拠となった箇所の抜粋",
  "summary": {
    "conclusion": "結論",
    "evidence": ["根拠1", "根拠2"],
    "next_steps": ["アクション1", "アクション2"]
  }
}

# Example

Input: "プロジェクトAは予算不足により来月から3ヶ月中断する。再開には追加承認が必要。"
Output: {
  "thought_process": "予算不足、来月から3ヶ月中断、再開には追加承認が必要、という記述を確認。",
  "summary": {
    "conclusion": "プロジェクトAの一時中断",
    "evidence": ["予算不足", "来月から3ヶ月間"],
    "next_steps": ["再開のための追加承認取得"]
  }
}

【評価指標と誤り分析】

評価項目 評価基準 (LLM-as-a-Judge) 失敗パターン
事実整合性 抽出された全項目がソース内に存在するか(1-5) 文書外の一般知識による補完
書式適合性 JSONとして正しくパース可能か(0 or 1) Markdownのコードブロック記号の混入
網羅性 重要なネクストアクションが漏れていないか(1-5) 些末な事実のみにフォーカスする

誤り分析: 特に「事実誤認（ハルシネーション）」は、LLMが親切心から「推測」を混ぜることで発生します。これを防ぐには「思考プロセスの分離（CoT）」と「抽出元テキストの明示」が不可欠です。

【改良後の最適プロンプト】

Gemini 1.5 Pro等の長文コンテキストモデルを想定し、システム命令を強化したバージョンです。

# System Instructions


- あなたは情報の真実性を最優先する抽出エンジンです。

- Userが提供する <source_material> タグ内のテキストのみを情報源としてください。

- もし情報源から回答を生成できない場合は、{"error": "Insufficient information"} と出力してください。

# Processing Protocol


1. **Analyze**: <source_material> を精読し、キーポイントを特定する。

2. **Verify**: 特定したポイントが明示的に記載されているか再確認する。

3. **Format**: 指定されたJSONスキーマに流し込む。

# Input Data

<source_material>
{{CONTEXT_DATA}}
</source_material>

# Response Schema (Strict JSON)

{
  "metadata": {
    "source_verified": boolean,
    "confidence_score": 0.0-1.0
  },
  "extracted_data": {
    "key_decision": "string",
    "supporting_facts": ["string"],
    "risk_factors": ["string"]
  }
}

# Output

（思考プロセスを隠し、JSONのみを出力）

【まとめ】

実務でコンテキストエンジニアリングを運用するための3つの鉄則：

  1. 境界の明示: コンテキストを<tag>で囲み、LLMが「どこまでが事実か」を物理的に理解できるようにする。

  2. 思考の外部化: thought_process フィールドを設け、LLMに「証拠のセルフチェック」を行わせる。

  3. スキーマの固定: 自由記述を避け、JSONスキーマを明示することで、後続のシステム（BIツールやDB）との連携を担保する。

ライセンス：本記事のテキスト/コードは特記なき限り CC BY 4.0 です。引用の際は出典URL（本ページ）を明記してください。
利用ポリシー もご参照ください。

コメント

タイトルとURLをコピーしました