Prompt Engineering

LLM運用の可観測性を実装する：OpenTelemetryでつくるPrompt/Token/Latency監視の実践 LLMアプリは「動く」だけでは本番品質になりません。運用を始めると、次のような問題が必ず発生します。 昨日まで 1.2 秒だった応答が突然 4 秒台になる コストが月末に急増したが、どの機能が原因かわからない 回答品質が落ちたと言われるが、どのプロンプト変更が影響したか追えない リトライ回数や外部API待ちの偏りが可視化されていない この課題を解く鍵が「可観測性（Observability）」です。本記事では OpenTelemetry を軸に、LLM アプリの監視をゼロから構築する実装を、実際に運用で使える粒度で説明します。 なぜ APM だけでは LLM を見切れないのか 従来の Web アプリ監視（CPU、HTTP レイテンシ、エラーレート）だけでは、LLM 特有の故障点が見えません。理由は、LLM の品質とコストが「入力テキスト」と「推論設定」に強く依存するためです。 少なくとも次の軸が必要です。 Prompt 可視化: システム/ユーザー/ツール呼び出しの構成 Token 可視化: input/output token、モデル別単価、キャッシュヒット率 推論経路可視化: retrieval → rerank → generation の各ステップ時間 品質シグナル: hallucination 率、参照文書一致率、ユーザー評価 つまり、HTTP 1 本のログでは不十分で、トレース単位で LLM 実行を分解する必要があります。 アーキテクチャの全体像 最初に、実装対象を次の構成とします。 API: FastAPI LLM: OpenAI / Azure OpenAI（抽象化） RAG: pgvector + reranker Observability: OpenTelemetry SDK + OTLP Exporter + Grafana Tempo/Loki/Prometheus 処理フローは次の通りです。 ...