평가, 배포, 회고
검색 지표, LLM-as-judge 품질 점수, 부하 시험을 포함한 전체 평가 도구를 실행하고, 클라우드 제공업체에 배포한 다음, 배운 교훈을 기록한 회고를 작성합니다.
평가, 배포, 회고은(는) CoddyKit의 무료 AI Engineering Academy 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 AI Engineering Academy 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. AI Engineering Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
마지막 단계: 출시 전 평가
실제 환경을 반영한 조건에서 처음부터 끝까지 평가하기 전에는 시스템을 출시할 준비가 되었다고 할 수 없습니다. 최종 평가 단계에서는 이 과정에서 배운 모든 평가 기법을 결합합니다. RAG 파이프라인이 올바른 청크를 찾는지 확인하는 검색 지표, 답변 품질을 확인하는 LLM 평가자 점수, 지연 시간 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 응답을 반환하는지, 시맨틱 캐시 적중률이 목표 이상으로 유지되는지 확인하십시오. 계속 진행하기 전에 모든 회귀 문제를 해결하십시오.
# 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 지연 시간(목표 <8초), 캐시 적중률(목표 >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])아키텍처 회고 작성하기
시스템을 일주일 동안 운영한 후 무엇이 잘 작동했고 무엇이 그렇지 않았으며 무엇을 다르게 했을지 기록하는 회고 문서를 작성하십시오. 좋은 회고는 실패를 솔직하게 다루고 배운 점을 구체적으로 설명합니다. 미래의 독자(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비즈니스 영향 측정하기
운영 환경에 배포한 지 한 달이 지나면 기술 지표를 넘어 시스템의 사업적 영향을 측정하십시오. 질의응답 도우미의 경우 고객 지원 문의 티켓 수가 얼마나 감소했습니까? 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% 절감하는 의미 기반 캐시, 자동 장애 조치를 제공하는 회로 차단기, 지속적 통합 및 지속적 배포 환경에서 지속적으로 실행되는 LLM을 심사자로 사용하는 평가, 적대적 입력으로부터 보호하는 프롬프트 주입 방어가 포함됩니다. 이것이 바로 운영 환경을 위한 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을 심사자로 사용하는 점수, 부하 테스트, 보안 검사를 모두 결합합니다. 블루-그린 배포와 점진적인 트래픽 전환을 사용하면 서비스 중단 없이 즉시 롤백할 수 있습니다. 또한 회고와 운영 절차서는 조직의 지식을 기록하여 향후 장애 해결 시간을 줄입니다. AI 엔지니어링: LLM, RAG 및 에이전트 과정을 완료하신 것을 축하합니다!
자주 묻는 질문
“평가, 배포, 회고” 강의는 무료인가요?
네 — “평가, 배포, 회고” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 AI Engineering Academy 강의 전체를 잠금 해제할 수 있습니다. AI Engineering Academy 강의에는 총 4개의 강의가 포함되어 있습니다.
“평가, 배포, 회고”에서 뭘 배우나요?
검색 지표, LLM-as-judge 품질 점수, 부하 시험을 포함한 전체 평가 도구를 실행하고, 클라우드 제공업체에 배포한 다음, 배운 교훈을 기록한 회고를 작성합니다. 브라우저에서 직접 실행하는 실습 코드로 AI Engineering Academy을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
AI Engineering Academy을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 AI Engineering Academy은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.
“평가, 배포, 회고” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 AI Engineering Academy 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 AI Engineering Academy 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.