評価、デプロイ、振り返り
検索メトリクス、LLM-as-judgeの品質スコア、負荷テストを含む評価ハーネス全体を実行し、クラウドプロバイダーにデプロイして、得られた教訓を記録した振り返りを書きます
「評価、デプロイ、振り返り」はCoddyKit上の無料AI Engineering Academyレッスンです。 これはレッスン4/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはAI Engineering Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AI Engineering Academyコースには全4レッスンが含まれています。
最後の仕上げ：リリース前の評価
実際の環境を想定した条件でエンドツーエンドの評価を行うまで、システムをリリースできる状態とはいえません。最終評価フェーズでは、このトラックで学んだすべての評価手法を組み合わせます。RAG パイプラインが適切なチャンクを見つけることを確認する検索メトリクス、回答品質を確認する LLM-as-judge のスコア、レイテンシー SLA を確認する負荷テスト、堅牢化を確認するセキュリティスキャンです。デプロイを開始する前に、すべてに合格する必要があります。
完全な評価ハーネスの実行
本番環境に近い代表的なクエリサンプルを使用し、ステージング環境に対して完全な評価スイートを実行します。すべてのメトリクスを記録します。検索についてはヒット率、MRR、NDCG、生成については忠実性と回答の関連性、さらにクエリあたりのコスト、p50/p95/p99 レイテンシーを記録します。各メトリクスを、アーキテクチャ設計フェーズで定義した成功基準と比較します。すべての最低基準を満たすまでリリースしないでください。
async def final_evaluation(system_url: str, test_set_path: str) -> dict:
test_cases = load_test_set(test_set_path)
results = []
for case in test_cases:
start = time.perf_counter()
response = await query_system(system_url, case['question'])
latency_ms = (time.perf_counter() - start) * 1000
judge_score = await judge(case['question'], response['answer'], case.get('reference'))
hit = any(case['relevant_doc'] in s for s in response.get('sources', []))
results.append({'latency_ms': latency_ms, 'score': judge_score, 'hit': hit, 'cost': response.get('cost_usd', 0)})
return compute_final_metrics(results)本番システムの負荷テスト
本番稼働前に、現実的な本番トラフィックをシミュレートする負荷テストを実行します。Locust や k6 などのツールを使って、想定されるピーク時の同時実行数（たとえば同時に50ユーザー）まで段階的に負荷を上げ、負荷によってレイテンシーがどう変化するかを測定します。通常の負荷でサーキットブレーカーが作動しないこと、バーストトラフィックに対してレートリミッターが適切な 429 を返すこと、semantic cache のヒット率が目標を上回り続けることを確認します。問題があれば、先に修正してください。
# Locust load test (locustfile.py)
from locust import HttpUser, task, between
import random
QUESTIONS = [
'What is the return policy?',
'How do I cancel my subscription?',
'Where are you located?',
]
class AIUser(HttpUser):
wait_time = between(1, 3) # realistic think time
@task
def query(self):
self.client.post(
'/query',
json={'question': random.choice(QUESTIONS), 'tenant_id': 'load_test'},
headers={'Authorization': 'Bearer test_token'}
)
# Run: locust -f locustfile.py --headless -u 50 -r 5 --run-time 5m本番環境へのデプロイ
ブルーグリーンデプロイを使用してデプロイします。新しいバージョン（グリーン）を既存のバージョン（ブルー）と並行して起動し、グリーンに対してスモークテストを実行してから、ブルーからグリーンへトラフィックを段階的に切り替えます。まずグリーンに5%のトラフィックを流し、10分間エラー率とレイテンシーを監視します。その後、25%、50%、100%と段階的に切り替えます。これにより、問題が発生してもダウンタイムなしでブルーへ即座にロールバックできます。
# Deployment steps (pseudocode for AWS ECS or K8s):
# 1. Build and push new Docker image
# docker build -t qa-assistant:v2.0 . && docker push ...
#
# 2. Deploy green (new) version alongside blue (current)
# kubectl apply -f deploy/green.yaml
#
# 3. Run smoke tests against green
# pytest tests/smoke/ --base-url https://green.internal
#
# 4. Canary traffic shift (ALB weighted routing)
# 5% -> green (monitor 10min)
# 25% -> green (monitor 10min)
# 50% -> green (monitor 10min)
# 100% -> green
#
# 5. Decommission blue after 24h stabilityデプロイ後の監視
デプロイ後の最初の2時間は、主要なメトリクスを積極的に監視します。エラー率（目標 <1%）、p95 レイテンシー（目標 <8s）、キャッシュヒット率（目標 >20%）、クエリあたりのコスト（目標 <$0.05）を監視します。初回デプロイ時には、オンコールの全エンジニアが参加するインシデント対応用の Slack チャンネルを用意します。いずれかのメトリクスが警告しきい値を超えたら調査を開始し、重大なしきい値を超えたら直ちにブルーへロールバックします。
# Post-deploy monitoring dashboard queries:
# (Assuming Grafana + Prometheus)
# Error rate (last 5 min):
# rate(http_requests_total{status=~'5..'}[5m]) / rate(http_requests_total[5m])
# p95 latency (last 5 min):
# histogram_quantile(0.95, rate(query_duration_seconds_bucket[5m]))
# Cache hit rate:
# rate(cache_hits_total[5m]) / rate(queries_total[5m])
# Average cost per query:
# rate(llm_cost_usd_total[5m]) / rate(queries_total[5m])アーキテクチャの振り返り作成
システムを1週間稼働させた後、うまくいったこと、うまくいかなかったこと、別の方法で行うならどうするかを記録した振り返りドキュメントを作成します。優れた振り返りは、失敗について正直に記述し、得られた学びを具体的に示します。将来このドキュメントを読む人（6か月後の自分自身も含みます）は、時間的プレッシャーの中で下した判断の背景や、予期せぬ障害について理解できるため、その恩恵を受けられます。
# RETROSPECTIVE.md structure:
#
# ## What Worked Well
# - Hybrid retrieval improved hit rate from 71% to 89%
# - Semantic cache reduced average cost by 31%
# - LangSmith tracing saved 2 days of debugging
#
# ## What Did Not Work
# - Semantic chunking was 4x slower than recursive chunking
# with only 3% hit rate improvement -- not worth it
# - Cohere reranker had 400ms latency -- too slow for p95 target
# Switched to BGE-reranker-v2 running locally
#
# ## What We'd Do Differently
# - Start with pgvector, not Pinecone (migration cost 3 days)
# - Add semantic cache BEFORE building the agent, not after運用ランブックの文書化
本番環境で発生する可能性のあるすべてのアラートについて、ランブックを作成します。ランブックとは、特定のアラートを診断して解決するための手順を段階的に示したガイドです。少なくとも、これは何を意味するアラートか、考えられる原因は何か、どのように診断するか、どのように修正するかに答えられる内容にします。ランブックによって、インシデント中に診断手順を考える必要がなくなるため、平均復旧時間（MTTR）を数時間から数分に短縮できます。
# runbooks/latency.md
# ## Alert: p95 Latency > 8000ms
#
# ### Likely Causes
# 1. OpenAI API degraded (check status.openai.com)
# 2. Cohere reranker slow (check Cohere status page)
# 3. pgvector query slow (check DB CPU in CloudWatch)
# 4. Redis cache full (check Redis memory usage)
#
# ### Diagnosis
# curl https://api.openai.com/v1/models -H 'Authorization: Bearer $KEY'
# Check LangSmith traces for which step is slow
# SELECT mean(duration) FROM traces GROUP BY step
#
# ### Fixes
# - If OpenAI slow: circuit breaker should auto-failover to Claude
# - If Cohere slow: disable reranking temporarily (env SKIP_RERANK=1)
# - If DB slow: increase pgvector ef_search from 40 to 20ビジネスへの影響測定
本番環境で1か月稼働させたら、技術指標だけでなく、システムの事業への影響を測定します。Q&Aアシスタントの場合、カスタマーサポートへの問い合わせ件数はどの程度減少したでしょうか。AIが回答した問い合わせに対するユーザー満足度はどの程度でしょうか。以前は人間のサポート担当者による対応が必要だった問い合わせを、システムは何件処理したでしょうか。こうした事業指標は投資の妥当性を示すとともに、品質改善と新機能のどちらを優先するか、今後の優先順位付けの指針になります。
# Business impact metrics (month 1):
# Technical:
# - 12,847 queries served, 11,439 (89%) answered without human
# - Avg query cost: $0.031 (within $0.05 budget)
# - System uptime: 99.94%
#
# Business:
# - Support tickets: 1,840/month -> 1,203/month (-35%)
# - Avg resolution time: 4.2h -> 23 seconds for AI-answered
# - User CSAT on AI answers: 4.1/5.0
# - Cost per resolved query: $12 (human) -> $0.031 (AI)
# - ROI: 157% in month 1 at current volumes次のイテレーションの計画
リリースしたシステムが完成することはありません。継続的な改善の土台となるものです。評価データ、ユーザーからのフィードバック、レトロスペクティブで得た知見を活用して、次のイテレーションを計画します。最も重要な指標に最大の効果をもたらす改善を優先してください。検索ヒット率がボトルネックになっている場合は、より良いチャンク分割や別の埋め込みモデルに投資します。検索結果が良好なのにユーザー満足度が低い場合は、プロンプトの品質改善に投資します。
# Next iteration priorities (based on first month data):
NEXT_SPRINT = [
# High impact / high confidence
{
'feature': 'Sentence-window retrieval',
'expected_impact': 'Hit rate 89% -> 93%',
'effort': 'medium',
'evidence': '11% of failures due to answer split across chunks'
},
# High impact / medium confidence
{
'feature': 'Query decomposition for multi-hop questions',
'expected_impact': 'Multi-hop correctness 61% -> 78%',
'effort': 'high',
'evidence': '23% of failures are multi-hop questions'
},
# Low effort quick win
{
'feature': 'Extend cache TTL from 1h to 24h',
'expected_impact': 'Cache hit rate 31% -> 38%',
'effort': 'trivial',
'evidence': 'Same questions asked daily by different users'
}
]知識共有とドキュメント作成
システムの実装における、重要でありながら自明ではない判断についてドキュメントを作成します。具体的には、特定のチャンクサイズを選んだ理由（実験で何が明らかになったかを含む）、セマンティックキャッシュの類似度しきい値をどのように調整したか、現在フィルターが検出できるプロンプトインジェクションのパターンと検出できないパターン、エージェントに新しいツールを追加する方法などです。優れた社内ドキュメントは、新しく参加するコントリビューターのオンボーディングにかかる時間を短縮し、判断の根拠を知らない人によって決定が誤って覆されるのを防ぎます。
# INTERNALS.md — key non-obvious decisions:
#
# ## Chunk Size: 800 tokens with 100 token overlap
# We tested 400, 600, 800, 1200 tokens.
# 800 tokens maximizes hit rate (89%) while keeping context
# small enough for 5 chunks to fit comfortably in 4096 token prompt.
# Larger chunks improved recall but degraded precision.
#
# ## Cache Similarity Threshold: 0.92
# Tested 0.85, 0.90, 0.92, 0.95.
# 0.92 gives 31% hit rate with <2% incorrect cache hits.
# 0.85 gives 41% hit rate but 8% incorrect hits (too aggressive).
#
# ## Reranker Top-N: 3 (from initial 10)
# More than 3 chunks causes context stuffing without quality gain.構築したもの
この総合課題を通じて構築したシステム全体を振り返ってみましょう。そこには、密な検索と疎な検索をリランキングと組み合わせたハイブリッドRAGパイプライン、関数呼び出しと安全対策を備えたストリーミングエージェント、コストを30%削減するセマンティックキャッシュ、自動フェイルオーバーを提供するサーキットブレーカー、CI/CDで継続的に実行されるLLM-as-judge評価、敵対的な入力から保護するプロンプトインジェクション対策が含まれています。これが本番環境向けのAIエンジニアリングです。
# System capabilities summary:
SYSTEM_CAPABILITIES = {
'retrieval': 'Hybrid BM25+dense with Cohere reranking, 89% hit rate',
'generation': 'GPT-4o with Claude fallback, circuit breaker, streaming',
'caching': 'Semantic cache (Redis+embeddings), 31% cache hit rate',
'security': 'Injection filter (2-stage) + output scanning + tenant isolation',
'observability': 'LangSmith traces + Prometheus metrics + PagerDuty alerts',
'evaluation': 'Automated LLM-as-judge in CI, daily full suite, LangSmith evals',
'reliability': '99.94% uptime, circuit breakers, graceful degradation ladder',
'cost': '$0.031/query average, model routing saves 67% vs GPT-4o only',
}理解度チェック
AIシステムの本番環境へのデプロイと評価について、理解度を確認しましょう。
レッスンのまとめ
このレッスンでは、最終評価では、デプロイを開始する前に検索指標、LLM-as-judgeのスコア、負荷テスト、セキュリティスキャンを組み合わせること、ブルーグリーンデプロイメントと段階的なトラフィック移行によって、ダウンタイムなしで即座にロールバックできること、そしてレトロスペクティブとランブックによって組織の知識を蓄積し、将来のインシデント解決にかかる時間を短縮できることを学びました。AI Engineering: LLM, RAG and Agentsトラックの修了、おめでとうございます。
よくある質問
「評価、デプロイ、振り返り」レッスンは無料ですか？
はい。「評価、デプロイ、振り返り」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、AI Engineering Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AI Engineering Academyコースには全4レッスンが含まれています。
「評価、デプロイ、振り返り」で何を学びますか？
検索メトリクス、LLM-as-judgeの品質スコア、負荷テストを含む評価ハーネス全体を実行し、クラウドプロバイダーにデプロイして、得られた教訓を記録した振り返りを書きます ブラウザで直接実行するハンズオンコードでAI Engineering Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
AI Engineering Academyを始めるのに経験は必要ですか？
事前経験は必要ありません。CoddyKitのAI Engineering Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン4/4です。
「評価、デプロイ、振り返り」レッスンにはどのくらい時間がかかりますか？
ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このAI Engineering Academyレッスンでコードを書いて実行できますか？
はい。すべてのAI Engineering Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。