LLM System Lab

Summary

Observability(관찰 가능성)는 AI 시스템의 내부 상태를 외부에서 파악할 수 있는 능력이다. 로그, 메트릭, 트레이스를 통해 시스템이 왜 그렇게 동작하는지를 이해하고 문제를 진단한다.

Why It Matters

LLM 시스템은 비결정적(non-deterministic)이다. 같은 입력에도 다른 출력이 나올 수 있고, 환각(hallucination)이 발생할 수 있다. 기존 소프트웨어의 모니터링만으로는 "왜 잘못된 답을 했는가"를 진단할 수 없다. AI 특화 Observability가 필수인 이유다.

Core Diagram

[사용자 요청]
     ↓
[Retrieval] ──→ 검색 품질 메트릭 (Recall, Relevance)
     ↓
[LLM 호출] ──→ 토큰 사용량, 지연 시간, 모델 버전
     ↓
[응답 생성] ──→ 응답 품질 평가 (Faithfulness, Coherence)
     ↓
[사용자 피드백] ──→ 만족도, 수정 요청, 재질문 비율
     ↓
[대시보드] ← 전체 트레이스 시각화

Concept Explanation

Observability의 3가지 기둥

기둥	설명	AI 시스템 적용
Logs	이벤트 기록	프롬프트, 응답, 검색 결과 전문
Metrics	수치 측정	지연 시간, 토큰 수, 비용, 품질 점수
Traces	요청 흐름 추적	검색→생성→응답의 전체 파이프라인

AI 특화 메트릭

검색 품질:

Context Relevance: 검색된 문서가 질문과 관련 있는가
Context Recall: 필요한 정보가 모두 검색되었는가
Chunk Utilization: 검색된 청크 중 실제 사용된 비율

생성 품질:

Faithfulness: 응답이 검색 결과에 근거하는가 (환각 감지)
Answer Relevance: 응답이 질문에 적절한가
Coherence: 응답이 논리적으로 일관적인가

운영 메트릭:

Time to First Token (TTFT): 첫 토큰 생성까지 시간
Tokens Per Second (TPS): 초당 생성 토큰 수
Error Rate: 오류 발생률
Token Usage: 입출력 토큰 사용량

트레이싱 패턴

LLM 파이프라인의 각 단계를 Span으로 기록:

Trace: user-query-12345
├── Span: embedding (12ms)
├── Span: vector-search (45ms)
│   └── metadata: {top_k: 5, threshold: 0.7}
├── Span: reranking (23ms)
├── Span: prompt-construction (2ms)
│   └── metadata: {template: "qa-v3", tokens: 1234}
├── Span: llm-generation (890ms)
│   └── metadata: {model: "gpt-4", tokens_in: 1234, tokens_out: 256}
└── Span: response-evaluation (15ms)
    └── metadata: {faithfulness: 0.92, relevance: 0.88}

System Perspective

LLM Observability 스택:

수집: OpenTelemetry SDK로 로그/메트릭/트레이스 수집
저장: 시계열 DB(Prometheus), 로그 저장소(Elasticsearch), 트레이스 저장소(Jaeger)
분석: LLM 평가 프레임워크(RAGAS, DeepEval)로 품질 자동 평가
시각화: 대시보드(Grafana, Langfuse, Phoenix)로 실시간 모니터링
알림: 품질 하락, 비용 급증, 지연 시간 초과 시 알림

LLM Observability 전문 도구:

Langfuse: 오픈소스 LLM 트레이싱 + 평가
Arize Phoenix: LLM 성능 분석 + 디버깅
Langsmith: LangChain 생태계 Observability
Helicone: LLM API 프록시 기반 모니터링

Practical Insight

프로덕션 전에 Observability를 설계하라 — 나중에 추가하면 비용이 10배
프롬프트와 응답 전문을 저장하되, PII(개인식별정보)는 마스킹 처리
자동 평가(LLM-as-Judge)와 사용자 피드백을 병행하라
대시보드의 핵심 지표: TTFT, 일일 요청 수, 평균 품질 점수, 비용/요청
품질 하락을 감지하는 알림은 즉시 설정하라 — 환각 증가는 매출 손실로 이어진다

Common Misunderstandings

Observability는 모니터링과 다르다 — 모니터링은 "무엇이 문제인가", Observability는 "왜 문제인가"
로그만 쌓는다고 Observability가 아니다 — 구조화된 메트릭과 트레이스가 필수
LLM 품질 평가는 완벽하지 않다 — 자동 평가는 참고 지표이며 인간 평가를 대체하지 못한다
Observability 구축에도 비용이 든다 — 로그/트레이스 저장과 LLM-as-Judge 호출 비용을 고려하라

Connected Topics

이전: RAG Pipeline
다음: Cost Monitoring
관련: Case Study — 운영 가능한 RAG 시스템

Observability — AI 시스템의 관찰 가능성