모델보다 평가 프레임워크(Harness)가 당신에게 먼저 거짓말을 할 것입니다

평가 스코어보드에는 두 엔진 모두 실패했다고 나왔습니다.

Llama3.2는 6개 사례 중 5개에서 실패했습니다. Anthropic Sonnet은 6개 사례 모두 실패했습니다.

라벨은 "malformed"였습니다. 하지만 원인은 서로 달랐습니다.

한 가지 실패 원인은 크레딧 소진으로 인한 API 오류였습니다. 또 다른 실패 원인은 CLI 명령에서 발생한 터미널 제어 바이트가 텍스트를 손상시킨 것이었습니다. 또 다른 실패 원인은 파서가 읽을 수 없는 마크다운 펜스(markdown fences)로 감싸진 유효한 JSON이었습니다.

만약 제가 그 첫 번째 요약본을 그대로 게시했다면, 저는 거짓말을 한 셈이 되었을 것입니다. 제 코드의 결함 때문에 발생한 실패를 모델의 탓으로 돌렸을 테니까요.

저는 요약본을 믿는 대신 원시 데이터(raw records)를 직접 확인하여 이 버그들을 찾아냈습니다.

첫 번째 버그는 Ollama를 호출하기 위해 CLI 서브프로세스를 사용했기 때문에 발생했습니다. 명령 실행 시 스피너(spinner)나 커서 이동 같은 터미널 애니메이션이 생성되었고, 이 ANSI 제어 바이트들이 데이터에 포함되었습니다. 파서는 이 보이지 않는 문자들을 인식하고 충돌을 일으켰습니다.

해결책: CLI 서브프로세스 대신 직접적인 HTTP API를 사용하도록 전환합니다.

두 번째 버그는 LLM이 종종 JSON을 마크다운 펜스로 감싸기 때문에 발생했습니다. 제 파서는 원시 문자열에 json.loads()를 사용했는데, 백틱(backticks)을 발견하고 실패했습니다.

해결책: 파싱 전에 코드 펜스를 제거하는 함수를 추가합니다.

파이프라인을 수정하자 진짜 결과가 나타났습니다.

모델들은 "죽은" 것이 아니었습니다. 단지 평가 프레임워크에 의해 데이터가 깨지고 있었을 뿐입니다. 수정 후, 두 모델 간의 품질 차이가 명확하게 드러났고 측정 가능해졌습니다.

AI 평가 파이프라인을 위한 교훈:

  • 원시 출력(raw output)을 보관하세요. 요약본에 "malformed"라고 되어 있다면, 원시 출력이 유일한 진실의 원천입니다.
  • 실패 원인을 기록하세요. 단순히 "malformed"라고만 하지 말고, "API error" 또는 "parse error"라고 명시하세요.
  • 테스트 표준을 고정하세요. 결과를 좋게 보이게 하려고 규칙을 변경하지 마세요.
  • 평가 프레임워크(harness)를 테스트 대상 시스템의 일부로 취급하세요.

심판대에 오르는 것은 모델만이 아닙니다. 당신의 코드 또한 마찬가지입니다.

Source: https://dev.to/kenielzep97/your-harness-will-lie-to-you-before-your-model-does-662

Optional learning community: https://t.me/GyaanSetuAi