【要約】運用初日、Slackに208件通知が飛んできた話 #4.5 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が個人開発プロジェクトの運用を開始した際、Slackに膨大な通知が届く問題に直面した。LLMの評価基準が不明確であったため、通知対象が過剰に膨れ上がったことが原因である。
- ・バックログによる未処理記事の一斉送信。
- ・LLMの評価が「3」に集中し、閾値設定が機能しない。
- ・1メッセージに全件が詰まり、可読性が著しく低下した。
// Approach
開発者は、設定の外部化と通知ロジックの細分化によって、通知の質と信頼性を向上させた。
- ・YAMLファイルによる閾値の動的な変更。
- ・重要度に応じた「メイン」と「ストック」の2レーン通知体制の構築。
- ・チャンク単位での送信とDB状態更新による再送制御の実装。
- ・Slack Block Kitを用いたメッセージの視覚的改善。
// Result
運用者にとって、通知の精度とシステムの堅牢性が大幅に向上した。
- ・閾値変更により、通知件数を適切に制御。
- ・重要度の低い記事をストックとして分離し、情報の損失を回避。
- ・送信失敗時の再送範囲を最小化し、効率的なリトライを実現。
- ・Block Kitにより、一覧性の高い通知を実現。
Senior Engineer Insight
> LLMを評価器に使う際、基準（ルーブリック）の欠如は致命的な偏りを招く。段階数を増やすのではなく、定義を言語化すべきだ。また、チャンク単位での状態更新は、分散処理におけるリトライ設計として極めて実戦的である。小規模開発であっても、この粒度の管理は運用コストとデータの整合性を守る上で不可欠な視点である。