【要約】LLMアプリの計装は、属性名より先に境界を決める──OTel GenAIのPRから見えたこと [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
LLMアプリケーションの計装を行う開発者が、属性名の定義から着手することで、以下のような設計上の問題に直面する。
- ・Spanの重複：SDKとHTTP Clientが同じ通信事実を二重に出力し、データが肥大化する。
- ・情報の欠落：どの層が情報を出すか不明瞭なため、通信失敗などの重要な事実が記録されない。
- ・責務の混同：計装コードに異常検知などの制御ロジックが混入し、コードの保守性が低下する。
- ・境界の曖昧化：ライブラリの出力と検証用データの境目が不明確になり、観測の信頼性が損なわれる。
// Approach
著者は、直接観測可能な層に情報の出力責任を割り当てる設計原則を提唱し、以下の階層分離を行う。
- ・HTTP Client層：HTTPリクエスト/レスポンスや接続エラーの観測を担う。
- ・Handler/SDK層：プロンプト構築、モデル選択、GenAI Spanの生成を担う。
- ・応答解析層：プロバイダの応答を解析し、トークン使用量などのUsage属性を付与する。
- ・分離の徹底：SemConvによる事実の記録と、それを利用した制御ロジックを明確に切り離す。
- ・事前合意：PIIやプロンプトのマスク方針など、標準化しない情報の扱いを事前に定義する。
// Result
この境界設計を導入することで、開発者は以下の恩恵を享受できる。
- ・データの正確性：二重計上や情報の欠落を抑制し、信頼性の高いトレースを実現する。
- ・運用の柔軟性：計装コードが単純化され、バックエンドツールや制御系の変更に強くなる。
- ・ガバナンスの強化：PIIや機密情報の扱いを設計段階で合意でき、安全な計装が可能になる。
- ・設計の普遍性：特定のSDKやバックエンドに依存しない、息の長い設計原則となる。
Senior Engineer Insight
> 現場視点では、属性名の決定よりも「観測の所有権」の定義が運用コストを左右する。特にLLMは多層的な通信が発生するため、設計ミスはノイズの増大とコスト増を招く。SemConvを「事実の記録」に限定し、異常検知等の制御ロジックを分離する設計は、スケーラビリティと保守性の観点からも極めて合理的である。実装前に「誰が何を出すか」をドキュメント化することを強く推奨する。