Evaluation
3줄 요약
- Evaluation은 AI 기능이 중요한 케이스에서 계속 기준을 만족하는지 확인하는 장치다.
- prompt, model, RAG, schema, tool 변경은 모두 eval 대상이다.
- 백엔드에서는 eval을 테스트, 배포, rollback, 장애 재발 방지와 연결해야 한다.
핵심 정리
- eval은 모델 비교뿐 아니라 제품 품질 회귀를 잡는 운영 테스트다.
- dataset에는 정상 요청, 엣지 케이스, 권한 경계, 보안 공격, 실패 상황이 포함되어야 한다.
- 규칙 기반 검사와 LLM-as-a-judge를 섞을 수 있지만, 중요한 판단은 사람이 샘플링 검토한다.
- RAG는 retrieval eval과 answer eval을 분리한다.
- 운영 장애나 CS 신고는 eval case로 전환해 재발을 막는다.
헷갈리는 지점
- eval은 모델 벤치마크라고만 생각하기 쉽다.
- 핵심은 제품 변경 회귀를 잡는 테스트라는 점이다.
- prompt 한 줄 변경도 eval 대상이다.
- LLM-as-a-judge 점수가 높으면 충분하다고 생각하기 쉽다.
- 핵심은 judge도 모델이며 편향과 오류가 있으므로 규칙 기반 검사와 human review를 섞어야 한다는 점이다.
확인 질문
- eval을 배포 프로세스에 연결해야 하는 이유는 무엇인가?
- prompt, model, schema, retrieval 변경이 품질 회귀를 만들 수 있기 때문이다.
- RAG eval을 두 단계로 나누는 이유는 무엇인가?
Observability
3줄 요약
- Observability는 운영 중 실제 AI 호출의 입력 맥락, latency, token, source, validation, tool call을 추적하는 일이다.
- trace에는 prompt version, model, retrieval profile, source id, token usage, error type이 연결되어야 한다.
- prompt와 context 원문을 무제한 저장하면 개인정보와 로그 비용 문제가 생긴다.
핵심 정리
- AI observability는 일반 API trace에 model, token, prompt, retrieval, tool 정보를 추가한다.
- OpenTelemetry GenAI semantic conventions는 GenAI 호출을 관측하기 위한 공통 필드 방향을 제공한다.
- trace id는 API 서버, worker, provider 호출, vector search, tool call을 관통해야 한다.
- 고카디널리티 tag와 원문 로그는 비용을 폭증시킬 수 있다.
- observability는 eval과 연결될 때 가장 강하다. 운영 실패를 eval case로 만들 수 있기 때문이다.
헷갈리는 지점
- 로그를 많이 남기면 디버깅이 쉬우므로 좋은 일이라고 생각하기 쉽다.
- 핵심은 prompt/context에는 민감정보가 섞일 수 있고 로그 비용이 커질 수 있다는 점이다.
- 기본은 version, id, count, status 중심이다.
- observability가 있으면 eval이 필요 없다고 생각하기 쉽다.
- 핵심은 observability는 관찰이고 eval은 변경 검증이라는 점이다.
확인 질문
- AI trace에 남기면 좋은 핵심 필드는 무엇인가?
- prompt version, model, token usage, retrieval source id, validation status, tool call, trace id다.
- prompt 원문 로그를 기본값으로 남기면 안 되는 이유는 무엇인가?
- 개인정보, 내부 문서, tool result가 섞일 수 있고 로그 비용도 커질 수 있기 때문이다.
품질 운영 루프
3줄 요약
- 좋은 AI 운영은 eval과 observability를 연결해 품질 문제를 계속 학습한다.
- 운영 trace, 사용자 신고, 장애 입력은 개인정보 제거 후 regression dataset으로 들어가야 한다.
- 점수 하나보다 실패 유형 분류가 개선 방향을 만든다.
핵심 정리
- failure taxonomy는 검색 실패, context 누락, schema 실패, refusal, tool 실패, 권한 실패처럼 나눈다.
- 품질 개선은 prompt, retrieval, model, schema, tool 중 어느 부분을 바꿨는지 기록한다.
- eval 결과는 릴리즈 노트와 함께 남긴다.
- 고객-facing 기능은 자동 평가와 human review를 함께 사용한다.
- 품질 운영 루프가 없으면 AI 기능은 감으로 튜닝된다.
헷갈리는 지점
- 사용자 피드백은 CS 자료일 뿐 개발 테스트와 별개라고 생각하기 쉽다.
- 핵심은 실제 실패 입력이 가장 좋은 eval case라는 점이다.
- 개인정보 제거 후 회귀 테스트로 전환한다.
- 평균 점수만 보면 충분하다고 생각하기 쉽다.
- 핵심은 평균이 좋아도 특정 권한이나 고객군에서 치명적인 실패가 날 수 있다는 점이다.
확인 질문
- failure taxonomy가 필요한 이유는 무엇인가?
- 실패 원인을 분류해야 개선할 대상과 재발 방지 방법을 정할 수 있기 때문이다.
- 운영 trace를 eval로 전환할 때 주의할 것은 무엇인가?
- 개인정보 제거, 권한 정보 보호, 재현 가능한 입력과 기대 결과 정리다.