Junhyun
포스트

[LLM] 평가 주도 개발 — 프롬프트를 고쳤는데 나아진 걸 어떻게 아나

LLM 애플리케이션에서 평가가 왜 먼저인지 정리합니다. LLM에게 채점을 맡기는 방법의 실제 정확도와, 순서만 바꿔도 판정이 뒤집히는 한계를 근거와 함께 짚습니다.

게시 업데이트
By Junhyun
14 분읽는 시간
[LLM] 평가 주도 개발 — 프롬프트를 고쳤는데 나아진 걸 어떻게 아나

프롬프트를 고쳤습니다. 답이 좋아진 것 같습니다.

그런데 정말 좋아졌을까요? 몇 번 돌려보고 “느낌이 낫다”로 판단하고 있다면, 다음에 또 고칠 때 무엇을 기준으로 비교할지가 없습니다.

이 글은 그 기준을 만드는 이야기입니다.

이게 “가장 중요한 특질”이라는 사람이 있습니다

Andrew Ng 이 AI 엔지니어링 역량 지도를 정리해 공개했습니다. 애플리케이션 구축·배포 아래 여섯 가지를 두었는데, 그중 평가에 대해서는 표현이 다릅니다.

제 경험상 AI 시스템을 잘 만드는 사람을 가르는 가장 중요한 특질은, 개발을 이끄는 훈련된 평가/오류분석 루프를 돌릴 수 있느냐입니다. 이를 통해 성과가 날 가능성이 높은 방향에 반복적으로 힘을 집중할 수 있습니다.

img_fileNg 의 원 도표를 참고해 계층만 남기고 다시 그렸습니다

여섯 중 하나인데 “가장 중요한 특질”이라고 못박은 셈입니다. 그리고 익히기 까다로운 기술이라고 덧붙입니다 — 프로젝트마다, 심지어 같은 프로젝트의 단계마다 맞는 접근이 달라지기 때문이라고요.

이 지도 자체는 감이 아니라 다수의 채용 공고 분석, 구조화된 전문가 인터뷰, 설문 응답으로 만들었다고 밝혀두었습니다.

왜 이게 먼저인가

프롬프트 편들에서 본 것을 떠올려 보겠습니다.

전부 “재봤더니 통념과 달랐다” 는 이야기입니다. 재보지 않으면 알 수 없는 것들이고, 그래서 평가가 프롬프트 기법보다 먼저입니다.

측정 없이 고치는 것은 고치는 게 아니라 바꾸는 것입니다.

무엇으로 재나

세 가지가 있고, 비용과 신뢰도가 반대로 갑니다.

방법신뢰도비용언제
사람이 직접 본다높음매우 높음기준을 처음 세울 때, 최종 확인
규칙으로 검사한다높음(좁음)낮음형식·필수 항목·금지어처럼 딱 떨어지는 것
LLM 에게 채점시킨다중간중간열린 질문의 품질 비교

규칙 검사는 과소평가되기 쉽습니다. JSON 이 파싱되는지, 필수 필드가 있는지, 금지어가 없는지는 모델에게 물어볼 일이 아니라 코드로 확인할 일입니다. 싸고 확실합니다.

문제는 “답이 더 나은가” 같은 열린 질문입니다.

LLM 에게 채점시키기 — 되긴 됩니다

Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena 가 이 방식을 정면으로 검증했습니다.

강력한 LLM 심판이 사람의 선호와 80% 이상 일치한다. 이는 사람들끼리의 일치도와 같은 수준이다.

뒷부분이 중요합니다. 사람 둘에게 같은 답 쌍을 보여줘도 판단이 늘 같지는 않습니다. 그 사람들끼리의 일치 수준만큼 LLM 심판이 사람과 맞았다는 뜻입니다.

그래서 “LLM 에게 채점을 맡긴다”는 게 편법이 아닙니다. 다만 같은 논문이 한계도 함께 적었습니다 — 위치 편향, 장황함 편향, 자기편향, 그리고 제한된 추론 능력.

그런데 채점자도 순서에 흔들립니다

한계 중 첫 번째를 따로 파고든 논문이 있습니다. 제목이 결론입니다.

Large Language Models are not Fair Evaluators

img_file논문 초록의 서술을 그림으로 옮겼습니다. 원문에는 이런 도식이 없습니다

후보 응답의 품질 순위는 맥락에 등장하는 순서를 바꾸는 것만으로 쉽게 조작할 수 있다.

논문이 든 실제 사례입니다. Vicuna-13B 가 ChatGPT 를 80문항 중 66문항에서 이기게 만들 수 있었습니다. 심판도 ChatGPT 였습니다.

답의 내용을 고친 게 아닙니다. 제시 순서만 바꿨습니다.

앞 글들과 같은 자리입니다

여기서 패턴이 보입니다.

어디서무엇이 흔들렸나
few-shot예시 순서에 따라 성능이 최고↔무작위
CoT심어둔 편향을 언급 않고 합리화
여기심판이 제시 순서에 따라 판정을 뒤집음

답하는 모델만 위치에 흔들리는 게 아니라 채점하는 모델도 같습니다. 그리고 평가에서 이게 더 위험합니다 — 틀린 답은 눈에 띄지만, 틀린 채점은 눈에 안 띕니다. 오히려 “측정했다”는 안심만 남습니다.

실무에서

1. 규칙으로 되는 건 규칙으로 한다. 형식·필수 항목·금지어는 코드로 확인합니다. LLM 심판은 열린 질문에만 씁니다.

2. 심판을 쓸 거면 순서를 바꿔 두 번 잰다. A→B 로 한 번, B→A 로 한 번. 판정이 뒤집히면 그 문항은 결론을 내지 않습니다. 위 논문이 그대로 시사하는 대책입니다.

3. 평가셋은 작게 시작한다. 20~30개면 시작할 수 있습니다. 중요한 건 크기가 아니라 실패했던 사례가 들어 있는가입니다.

4. 실패를 모은다. 이상하게 답한 사례를 볼 때마다 평가셋에 넣습니다. 이게 시간이 지날수록 값어치가 커지는 유일한 자산입니다.

5. 바꾸기 전에 먼저 잰다. 기준선이 없으면 개선인지 아닌지 알 수 없습니다.

이건 조직에서도 확인된 방향입니다

스킬 글에서 다룬 Anthropic 의 공개 자료가 같은 곳을 가리킵니다. 내부에서 쓰는 스킬을 아홉 가지로 분류했을 때, 검증 스킬이 출력 품질에 가장 측정 가능한 영향을 줬다고 적었습니다.

이유도 같습니다. 모델은 일을 끝낸 것처럼 보이게 만들 수 있고, 무너지는 지점은 결과를 확인하는 마지막 단계입니다.

읽을 때 붙여야 할 단서

두 논문 다 2023년 자료입니다. GPT-3.5·GPT-4 세대에서 잰 것이고, 이후 모델에서 위치 편향이 줄었는지는 이 논문들이 답하지 않습니다. 줄었다는 근거도 제가 확인하지 못했습니다.

“80% 일치”는 특정 벤치마크 기준입니다. MT-bench 와 Chatbot Arena 의 열린 질문에서 나온 값이고, 도메인이 다르면 달라집니다.

“66/80”은 조작을 시도했을 때의 결과입니다. 평범하게 쓰면 늘 그렇게 뒤집힌다는 뜻이 아니라, 뒤집을 수 있다는 뜻입니다.

평가에도 비용이 듭니다. 심판 호출도 API 호출입니다. 한 번 쓰고 마는 프롬프트에 평가셋을 만들 이유는 없습니다.

정리

프롬프트를 고쳤을 때 나아졌는지 아는 방법은 재보는 것뿐입니다. 최근 글들이 통념을 뒤집을 수 있었던 것도 누군가 재봤기 때문입니다.

LLM 에게 채점을 맡기는 건 실제로 통합니다. 사람 선호와 80% 이상 일치했고, 그건 사람들끼리의 일치 수준입니다.

다만 심판도 위치에 흔들립니다. 순서를 바꾸는 것만으로 순위를 조작할 수 있고, 실제로 열세로 평가받던 모델이 80문항 중 66문항을 이기게 만들 수 있었습니다.

그래서 순서를 바꿔 두 번 재고, 뒤집히면 결론을 유보하는 것이 최소한의 방어입니다.

틀린 답보다 틀린 채점이 더 위험합니다. 틀린 답은 보이지만 틀린 채점은 “측정했다”는 안심으로 덮이기 때문입니다.

참고

Concept
LLM evaluation LLM-as-judge testing
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.