JSON Eval 실패: 평가가 왜 폭발하는지와 해결 방법

Source: Dev.to

RAG 및 에이전트 시스템을 위한 평가 파이프라인은 겉보기에는 단순해 보입니다.

• 모델이 JSON을 생성합니다.
• JSON을 파싱합니다.
• 출력에 점수를 매깁니다.
• 결과를 집계합니다.

실제로 이는 워크플로우에서 가장 취약한 부분 중 하나입니다. 하나의 필드가 잘못 배치되거나 포맷이 어긋나면 전체 평가가 신뢰할 수 없게 됩니다. 이 가이드는 JSON 평가가 실패하는 이유와 무음 오류를 방지하는 안정적인 검증 흐름을 구축하는 방법을 설명합니다.

1. 왜 JSON이 평가 붕괴를 일으키는가

LLM은 종종 부분적인 구조를 생성합니다. 필드 이름이 바뀌고, 어떤 샘플에서는 객체가 배열이 되고 다른 샘플에서는 다시 객체가 됩니다. 괄호 하나가 빠지면 전체 점수 산출 스크립트가 중단됩니다. 이 경우 점수 산출 단계는 의미가 없어지고, 모델 품질을 측정하는 대신 포맷 잡음만 측정하게 됩니다.

2. 대부분의 팀이 놓치는 실패 흐름

안정적인 평가 파이프라인은 네 단계가 필요합니다:

1. 모델 출력 – 생성된 원시 JSON을 그대로 캡처합니다. 아직 정리하거나 다시 쓰지 마세요.
2. 구조 검사 – JSON이 유효하고 완전한지 확인합니다. 대부분의 평가가 여기서 폭발합니다.
3. 스키마 검증 – 모든 필드가 존재하고, 타입이 올바르며, 구조가 기대와 일치하는지 확인합니다. 이는 잘못 배치된 답변으로 인한 무음 오류를 방지합니다.
4. 점수 산출 – JSON이 구조와 스키마 검증을 통과한 뒤에만 점수를 계산합니다.
5. 집계 보고서 – 앞 단계가 안정적일 때만 깔끔한 점수 보고서를 만들 수 있습니다.

3. JSON 평가 실패의 실제 예시

한 번은 정확도가 급격히 떨어진 평가 배치를 경험했습니다. 모델이 하룻밤 사이에 퇴보한 듯 보였죠. 원시 출력을 살펴보니 추론은 올바른데, 답변이 answer 대신 result라는 필드에 들어 있었습니다. 스키마 검증이 없었기 때문에 점수 산출 스크립트가 해당 출력을 버렸고, 모델이 악화된 것처럼 보였습니다. 간단한 스키마 검증 단계를 추가하니 문제가 해결되었습니다.

4. 도움이 되는 도구와 패턴

• 엄격한 JSON 스키마 검증기를 사용하세요.
• 점수 산출 단계 이전에 검증기를 실행하고, 이후에 실행하지 마세요.
• 검증기가 명확한 오류 보고서를 제공하도록 하여, 모델이 구조적으로 실패했는지 의미적으로 실패했는지 알 수 있게 하세요.

5. 요약

평가가 불안정하게 느껴진다면 모델이 아니라 JSON이 원인일 가능성이 높습니다. 점수 산출 전에 구조 검사와 스키마 검증을 추가하면 매번 예측 가능한 평가를 얻을 수 있습니다.