dual-model-strategy

コアの課題

同じパイプラインが4B OllamaモデルとGPT-5の両方で許容できる結果を生成する必要があります。制約条件(小規模モデル)を考慮して設計し、その後大規模モデルが自然に優れた成果を上げるようにします。

モデル能力マトリックス

能力	4B-8B (Ollama)	GPT-4o / Sonnet	GPT-5 / Opus
構造化出力	format="json" が必要	with_structured_output()	信頼性が高い
スキーマの複雑さ	フラット、<10フィールド	中程度のネスト	深いネスティングもOK
ツール使用	最大1-3個	5-10個	10個以上
コンテキストウィンドウ	4K-8K実用的	128K	200K以上
思考の連鎖(Chain-of-thought)	しばしば悪影響	役に立つ	大幅に役に立つ
温度の最適値	0	0-0.3	0-0.5
プロンプト予算	<1000トークン	<4000トークン	<8000トークン

デュアルモデル向けスキーマ設計

from pydantic import BaseModel, Field

# 良い例: フラットスキーマ、説明的なフィールド、インライン列挙値
class ExtractedEntity(BaseModel):
    name: str = Field(description="Entity name as it appears in text")
    entity_type: str = Field(description="e.g., person, organization, location, event")
    confidence: float = Field(ge=0.0, le=1.0, description="Extraction confidence score")
    tags: list[str] = Field(description="1-4 relevant tags", min_length=1, max_length=4)

# 悪い例: 深くネストされた構造、複雑な型、曖昧なフィールド
class ExtractedEntity(BaseModel):
    metadata: MetadataBlock           # ネスティング = 小規模モデルでは失敗
    attributes: dict[str, list[Any]]  # dict[str, list] は小規模モデルを混乱させる

ルール

• スキーマはフラットに保つ(最大1レベルのネスティング)。
• LLMが生成するフィールドには、Literal/Enum より説明文と例付きの str を使用する。
• 必須文字列に min_length=1 を設定して空の値を捕捉する。
• 無制限のリストではなく、最小値/最大値付きの list[str] を使用する。
• フィールド説明がプロンプト指示を兼ねるように提供する。

プロンプト適応パターン

def build_prompt(task: str, model_size: str) -> str:
    """モデルの能力に応じてプロンプトの複雑さを適応させる。"""
    core = TASK_TEMPLATES[task]  # 共有タスク定義

    if model_size == "small":
        # 推論命令を削除し、厳密なフォーマット仕様を追加
        return f"{FORMAT_SPEC}\n\n{core}\n\n{WORKED_EXAMPLE}\n\n{FORMAT_SPEC}"
    else:
        # ニュアンスを追加し、探索を許可
        return f"{SYSTEM_CONTEXT}\n\n{core}\n\n{CONSTRAINTS}\n\n{FORMAT_SPEC}"

プロバイダー抽象化

# フェーズ固有のプロバイダー選択
providers:
  default: ollama/qwen3:4b-instruct      # 低コストのデフォルト
  discuss: ollama/qwen3:4b-instruct      # ツール有効な探索
  summarize: openai/gpt-4o              # ナラティブ品質
  serialize: openai/o1-mini             # 構造化出力の精度

優先順位: CLIフラグ → 環境変数 → プロジェクト設定 → デフォルト

テスト戦略

ユニットテスト(モデル非依存)

• 手作業で作成したフィクスチャでスキーマ検証をテストする。
• プロンプトテンプレートレンダリングをテストする。
• ツール結果パースをテストする。
• LLM呼び出しなし。高速。無料。

スモークテスト(モデルクラスごと)

• 各ステージを1つの代表的な入力で各モデルサイズで実行する。
• アサーション: 出力がパースされる、必須フィールドが存在する、検証エラーがない。
• 費用がかかる。選択的に実行する。

ベンチマーク

• ステージごとに10-20個の入力テストセット。
• メトリクス: パース成功率、フィールド精度、トークンコスト、レイテンシ。
• モデル間で比較。回帰を追跡する。
• 主な知見: 制約付き生成を使用する場合、小規模モデルは構造化タスクで大規模モデルを上回ることがあります。

コスト最適化

• 開発中の探索/反復には小規模モデルを使用する。
• 大規模モデルは最終品質と難しいタスク(要約、複雑な推論)のみに使用する。
• 決定論的な呼び出し(temp=0、同じプロンプトハッシュ)をキャッシュする。
• 可能な限り関連する呼び出しをバッチ処理する。
• structlogを介してステージごとのトークン使用量を監視する。

フォールバックチェーン

# プログレッシブフォールバック: 低コスト → 高コスト を試す
fallback_order = [
    "ollama/qwen3:4b-instruct",   # 無料、高速
    "ollama/llama3.3:8b",         # 無料、品質向上
    "openai/gpt-4o-mini",         # 低コストクラウド
    "openai/gpt-4o",              # フルクラウド
    "anthropic/claude-sonnet",     # 代替クラウド
]

小規模モデルの出力が使用不可能な場合を検出するように検証を設計し、次のティアに自動的にエスカレートさせます。