📌

マルチターンLLMの失敗要因と、Phase Loop Dynamics（PLD）による安定化 ― 検証用トレースを公開しました

に公開
LangGraph
agentdrift
openaaissistants
phaseloop
runtimegovernance
tech

最近、LangGraph・Assistants API・Swarm・RAG agents など、マルチターンの自律エージェントを扱うケースが増えてきています。しかし、実際に本番環境に近い条件で動かすと、多くのエージェントは同じ問題につまずきます。

その理由はシンプルです：

多くの場合、問題は 知識不足ではなく、対話が進むほど振る舞いがブレていくこと（Behavioral Drift）。

例として、以下のような挙動がよく発生します：

  • 一度理解した制約を後のターンで勝手に緩める
  • 正しいツール引数だったはずが再試行で壊れる
  • 修正ループに入れず同じ失敗を繰り返す
  • 途中で意図や判断基準が変わる

これらは単一プロンプト調整やLLM精度改善では解決できません。
必要なのは、継続的な観測と修正が可能なランタイム制御です。

🔧 サンプルトレースはこちら → https://github.com/kiyoshisasano/agent-pld-metrics/tree/main/examples/reference_traces
（本文では概要と設計意図を解説します）

Phase Loop Dynamics（PLD）とは？

**Phase Loop Dynamics（PLD）**はマルチターンLLM向けのランタイム行動制御モデルで、以下のフェーズに基づき振る舞いを監視・修復します：

Drift → Repair → Reentry → Continue → Outcome

特徴：

  • モデルやフレームワークに依存しない
  • 非侵襲で既存システム上に載せられる
  • 「正しい出力」ではなく**「継続的に一貫した行動」**を保証

Reference Traces 公開

PLDを理解・検証するため、次のサンプルを公開しました：

ファイル 内容
golden_semantic_repair.jsonl もっとも読みやすい「理想的な修復ループ」
forensic_infra_noise.jsonl タイムアウト、警告、再試行など現実に近いログ
generate_forensic_trace.py 高エントロピーで再生成可能なログジェネレータ

すべて合成生成されたトレースですが、以下を意識して設計しています：

  • 現実的な遅延・並列度・エラー分布
  • UUID / Hash / Span構造
  • OTel・LangGraph・Assistants形式との互換性

例：最小の修復ループ（要点）

// Drift: 制約抜け
{"event_type": "tool_call_attempt", "args": {"amenities": ["wifi"]}}

// Repair: 指摘
{"event_type": "repair_triggered", "missing": ["parking"]}

// Retry: 修正反映
{"event_type": "tool_call_attempt", "args": {"amenities": ["wifi", "parking"]}}

// Outcome: 正常化確認
{"event_type": "evaluation_pass"}

たった数行でも、修復プロセスが明確かつ観測可能になる点が重要です。

なぜトレースが必要なのか？

理由は一文で表現できます：

プロンプトは検証できないが、トレースは検証できる。

マルチターンエージェントは、履歴に基づくフィードバックループによって改善されるシステムです。
そのため、挙動を残すフォーマットこそが技術的基盤になります。

これから

今後は：

  • LangGraph/Assistants 連携サンプル
  • OpenTelemetry Export
  • メトリクス可視化 Notebook
  • Enforcement / Observer Mode 切替例

などを追加予定です。

フィードバック歓迎です。

📂 ソースコード & リファレンスログ：
https://github.com/kiyoshisasano/agent-pld-metrics/tree/main/examples/reference_traces

Discussion