「文脈設計（Context Engineering）」による高精度ナレッジグラフ抽出プロンプトの構築

Tech

{ “style”: “professional_technical”, “logic_level”: “high”, “focus”: “context_engineering_and_implementation”, “target_audience”: “prompt_engineers_and_developers” }

本記事はGeminiの出力をプロンプト工学で整理した業務ドラフト（未検証）です。

「文脈設計（Context Engineering）」による高精度ナレッジグラフ抽出プロンプトの構築

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

複雑な技術文書から構成要素と関係性を抽出し、RAG（検索拡張生成）の精度を最大化するための構造化データ（JSON）を生成する。

入出力の型定義：

  • 入力： 非構造化テキスト（技術仕様書、論文等）

  • 出力： JSON形式（nodes: [{id, type, properties}], edges: [{source, target, relation}]）

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

graph TD
A["設計"] --> B["実行"]
B --> C["評価"]
C -->|改善| A

  1. 設計（Design）： 抽出対象のエンティティ定義（スキーマ）と、文脈として与える背景情報の優先順位を決定します。

  2. 実行（Execute）： 長文コンテキスト（Long Context）を活用し、段階的な思考（CoT）を用いて抽出を行います。

  3. 評価（Evaluate）： 抽出された情報の整合性、JSONフォーマットの正当性、および事実に基づかない関係性の有無を検証します。

【プロンプトの実装案】

# Role

あなたは情報工学のエキスパートであり、非構造化データから厳密なナレッジグラフを構築する「コンテキスト・アーキテクト」です。

# Task

入力されたテキストから、エンティティ（ノード）とその相互関係（エッジ）を抽出し、指定のJSON形式で出力してください。

# Constraints


- エンティティの種類は [Person, Organization, Technology, Concept, Event] に限定する。

- 全ての関係性は、必ず入力テキスト内に明示的な根拠があるもののみとする。

- 出力は純粋なJSONのみとし、解説や前置きは一切不要。

# Thought Process (Chain-of-Thought)


1. テキスト全体をスキャンし、定義されたエンティティ型に該当する固有名詞・概念をリストアップする。

2. リストアップしたエンティティ間の動詞や記述的関係を特定する。

3. 各関係を「A -> 関係内容 -> B」の形式で構造化する。

4. 重複を排除し、最終的なJSONスキーマに適合させる。

# Few-shot Example

Input: "OpenAIが開発したGPT-4は、Transformerアーキテクチャを採用している。"
Output:
{
  "nodes": [
    {"id": "OpenAI", "type": "Organization"},
    {"id": "GPT-4", "type": "Technology"},
    {"id": "Transformer", "type": "Technology"}
  ],
  "edges": [
    {"source": "OpenAI", "target": "GPT-4", "relation": "developed"},
    {"source": "GPT-4", "target": "Transformer", "relation": "uses_architecture"}
  ]
}

# Input Text

[ここに解析対象のテキストをペースト]

【評価指標と誤り分析】

評価項目 期待される挙動 失敗パターン（誤り分析） 対策
スキーマ整合性 有効なJSON形式であること カンマ欠落、型定義外のエンティティ生成 json_schema の強制指定
事実忠実性 テキストにない関係を作らない 文脈から推測した過剰な関係性の構築 Negative Promptでの「推論禁止」
網羅性 重要なノードが漏れなく抽出される 代名詞（それ、彼ら）の解析失敗 Coreference Resolutionの指示追加

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

# System Role

Context Engineer (High Precision Extraction Mode)

# Mission

Extract a verifiable knowledge graph from the provided context. Follow the "Entity-Relation-Evidence" triad.

# Definition: JSON Schema

{
  "nodes": [{"id": "string", "label": "string", "metadata": {"description": "string"}}],
  "edges": [{"source": "string", "target": "string", "type": "string", "evidence": "string"}]
}

# Strict Rules


1. DO NOT invent entities.

2. The "evidence" field must contain the exact quote from the text.

3. If no clear relations exist, return empty arrays.

4. Output format: Strictly JSON.

# Processing Steps


1. **Identify**: Extract all instances of [Technology, Project, Protocol].

2. **Relate**: Connect entities based on causal or hierarchical verbs.

3. **Verify**: Check each edge against the "Strict Rules".

# Context Information

[PASTE YOUR DOCUMENT HERE]

# Final Output

【まとめ】

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

  1. 「何をさせるか」より「何を見せるか」： プロンプトの美辞麗句よりも、入力データの構造化（Markdownの見出し活用等）とメタデータの付与が精度を左右する。

  2. 事実のアンカー（根拠）を要求する： 出力に「引用（Evidence）」を含めることで、LLMの幻覚（ハルシネーション）を物理的に抑制する。

  3. トークン効率ではなく情報密度： 長文対応モデル（Gemini 1.5等）では、短く説明するより、豊富な具体例（Few-shot）と明確な制約（Constraints）を敷き詰める方が安定する。

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

コメント

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