이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- AI eval dataset에는 어떤 케이스가 들어가야 하는가?
- prompt와 model 변경을 regression test로 어떻게 검증하는가?
- 자동 평가와 human review는 어떻게 역할을 나누는가?
개요
Evaluation은 AI 기능의 테스트다. 단위 테스트처럼 완전히 deterministic하지는 않지만, 중요한 케이스에서 품질 기준을 계속 만족하는지 확인한다.
LangSmith, promptfoo, DeepEval, Ragas 같은 도구는 eval을 체계화하는 데 도움을 준다. 도구보다 중요한 것은 dataset과 실패 유형이다.
Eval Dataset 구성
포함할 케이스:
- 정상 질문
- 모호한 질문
- 근거 없는 질문
- 권한 없는 문서 요청
- 오래된 문서와 최신 문서 충돌
- JSON schema를 깨기 쉬운 입력
- prompt injection 시도
- 긴 입력
- 빈 입력
- provider refusal 가능 입력
운영 로그에서 만들 때는 개인정보를 제거한다.
Regression Test
다음 변경은 regression eval 대상이다.
- prompt 변경
- model 변경
- schema 변경
- retrieval top-k 변경
- chunking 변경
- reranker 변경
- tool schema 변경
- guardrail 변경
작은 smoke eval은 PR마다, 큰 eval은 release 전이나 nightly로 돌릴 수 있다.
코드로 이해하기
간단한 eval case 포맷이다.
{
"case_id": "doc_qa_001",
"question": "AOP self-invocation은 왜 동작하지 않나요?",
"expected_sources": ["spring-aop-proxy"],
"must_contain": ["Proxy", "this 호출"],
"forbidden_terms": ["AspectJ만 가능"]
}평가는 규칙 기반으로 시작해도 충분하다.
def evaluate_answer(case, answer):
return {
"has_source": set(case["expected_sources"]).issubset(answer["source_ids"]),
"contains_terms": all(term in answer["answer"] for term in case["must_contain"]),
"avoids_forbidden": all(term not in answer["answer"] for term in case["forbidden_terms"]),
}백엔드 설계 판단
- eval을 CI에 넣을 것인가?
- 비용이 큰 eval은 언제 돌릴 것인가?
- 실패 허용 기준은 기능별로 다른가?
- human review가 필요한 기능인가?
- eval 결과를 배포 승인에 연결할 것인가?
장애 상황과 대응
품질 장애가 나면 장애 입력을 eval case로 추가한다. 그래야 같은 문제가 다시 생겼을 때 배포 전에 잡을 수 있다.
인프라 협업 포인트
eval도 provider 비용과 rate limit을 쓴다. production key와 분리하고, nightly job과 queue를 사용해 운영 트래픽에 영향을 주지 않게 한다.
실전 팁
- 처음에는 10개라도 좋다.
- 실패 케이스가 정상 케이스보다 더 가치 있을 수 있다.
- 점수보다 failure type을 남긴다.
- eval dataset도 versioning한다.
위험 신호!
- prompt 변경에 eval이 없다.
- eval dataset이 정상 질문만 있다.
- 운영 장애가 eval에 반영되지 않는다.
- LLM-as-a-judge만 믿는다.
확인 질문
확인 질문
- eval dataset에 실패 케이스가 중요한 이유는 무엇인가?
- 실제 운영 회귀와 장애를 잡는 데 정상 케이스보다 효과적일 수 있기 때문이다.
- eval을 production key와 분리하는 이유는 무엇인가?
- eval 비용과 rate limit이 실제 사용자 트래픽에 영향을 주지 않게 하기 위해서다.
Spring AI 적용 연결
- Spring AI 기능의 eval은 prompt, model profile, advisor, retrieval 결과가 함께 바뀔 수 있음을 전제로 설계한다. 테스트 구조는 10. Evaluation Testing Regression에서 이어진다.
- eval 결과를 운영 장애 대응으로 연결하는 흐름은 11. Observability와 장애 대응 런북을 함께 본다.