LLM 평가용 프롬프트 작성법: LLM-as-a-judge의 판단 오류 원인과 3가지 해결책

LLM의 출력을 다른 LLM에게 평가시키는, 이른바 LLM-as-a-judge를 평가 메커니즘에 통합하고 있습니다. 평가 자동화 관련 글에서는 전체 구성에 대해 다루었지만, 실제로 해보니 판단 프롬프트 작성 방식에 따라 결과가 크게 달라집니다. 이번에는 그 부분에 초점을 맞춰서 쓰겠습니다.

제 운영 경험상으로는 판단 기준의 모호성을 줄임으로써 개선할 수 있었습니다. 효과를 본 해결책은 3가지이며, 모두 '무엇을 충족해야 합격인가'를 명확히 하는 노력이었습니다. 효과는 정성적인 관찰에 그치므로, 사용 모델과 평가 데이터로 직접 확인해 보시길 바랍니다.

프롬프트 이야기에 들어가기 전에 전제를 하나 세우겠습니다. 규칙 기반으로 판단할 수 있는 것은 LLM에게 맡기지 마십시오.

• 포맷 오류, 필수 키 누락 → 스키마 검증(Schema validation)
• 금지어 혼입, 글자 수 초과 → 문자열 처리(String processing)
• 의미적으로 벗어나지 않았는지, 톤이 적절한지 → LLM-as-a-judge

판단에 LLM을 사용한다는 것은 판단 자체에 오류가 발생할 여지가 있다는 것을 전제로 받아들일 수밖에 없습니다. 그렇기 때문에 오류 없이 판단할 수 있는 것을 LLM에게 맡기는 것은 손해입니다. 이 부분을 분리하지 않고 전부를 판단 프롬프트에 밀어 넣으면, 오류의 원인이 어디에 있는지 구분하기 어려워집니다.

아래는 이러한 구분을 거친 후 남은 '의미적 판단'에 대한 이야기입니다.

처음에 작성했던 판단 프롬프트는 다음과 같은 형태였습니다.

다음 출력을 1~5로 평가해 주세요.
5: 매우 좋음 / 1: 매우 나쁨

이것이 가장 오류가 많이 발생했습니다. 동일한 입력을 여러 번 흘려보내도 3과 4를 오갔고, 게다가 무엇이 바뀌어야 4가 5가 되는지 알 수 없었습니다. 점수의 근거를 설명할 수 없기 때문에 임계값을 정하는 것도 불가능합니다.

지금은 관점별로 나누어 Yes/No로 물어보고 있습니다. 아래는 입력에 쓰인 사실만을 사용해서 답변하는 태스크를 위해 기준을 간소화한 예시입니다.

질문・입력・평가 대상 출력을 읽고, 각 항목을 Yes/No로 판단해 주세요.
기준을 충족하면 Yes, 충족하지 못하면 No로 해 주세요.
1. 질문에 답하는 데 필요한 정보가 출력에 포함되어 있는가
...

바뀐 점은 2가지입니다. 단계 평가를 이진 값(binary value)으로 바꾼 것과 하나의 질문에서 한 가지 내용만 물어보도록 한 것입니다.

이 형태로 만들자, 실패했을 때 확인해야 할 부분을 찾기 쉬워졌습니다. '점수 3'만으로는 수정할 점을 알 수 없지만, '항목 2가 No'라면 입력에 없는 고유명사가 나와 있다는 식으로 문제를 추적할 수 있습니다. 이진 값으로 바꾸더라도 기준이 모호한 상태라면 판단은 오류가 발생하므로, 레이블 변경과 기준 구체화는 세트로 생각해야 합니다.

관점을 나누는 것도 같은 이유입니다. '정확하고 읽기 쉬운지'처럼 여러 속성을 한 질문에 섞으면, 어느 것을 충족하지 못했는지 판단 레이블만으로는 알 수 없습니다. 정확성과 가독성을 따로 물어보면 수정할 부분을 좁힐 수 있습니다.

두 번째는 순서의 문제입니다.

# 변경 전
판단: {Yes/No}
이유: {이유}
...

제 운영 경험상으로는, 판단을 먼저 내리게 하면 근거와 판단이 달라지는 경우가 있었습니다. 순서를 거꾸로 해서, 근거를 먼저 쓰게 한 다음 판단하게 하니, 이러한 불일치가 줄었습니다.

다만, 이유가 쓰였다고 해서 올바른 판단이라고 단정할 수는 없습니다. 입력에 없는 내용을 근거로 제시하고 있지는 않은지 확인해야 합니다. 필요한 것은 리뷰에서 대조할 수 있는 짧은 판단 근거입니다.

이유를 쓰게 하는 또 다른 장점은, 판단이 틀렸을 때 원인을 찾을 단서가 남는다는 것입니다. 판단 기준 작성 방식과, 근거로 제시된 입력・출력을 대조할 수 있습니다. 이유 없는 Yes/No만보다 프롬프트의 어느 부분을 수정해야 할지 검토하기 쉽습니다.

세 번째는 기준 작성법입니다. 말(언어)만으로 기준으로 쓰면, 아무래도 해석의 여지가 남게 됩니다.

3. 출력 중 주장하는 모든 내용은 입력 내용에서 뒷받침되는가
질문: 재고 상황을, 입력에 쓰인 사실만을 가지고 한 문장으로 전달해 주세요.
Yes 예시:
...

여기서 '충분'이라는 단어를 빼는 이유는, 재고 3개라는 사실만으로는 충족도를 판단할 수 없기 때문입니다. '재고가 4개'라고 쓰면 입력과의 모순이지만, '재고가 충분하다'는 것은 입력에서 뒷받침되지 않는 판단의 추가에 해당합니다. '모순되지 않은지'만을 기준으로 삼으면, 후자를 제외할 이유를 설명할 수 없습니다. 예시와 판단 기준은 이 차이가 일치하도록 작성해야 합니다.

부적합 예시에 왜 떨어지는지를 첨가하는 것이 중요했습니다. 이유를 쓰면, 기준의 어느 부분에 위반했는지를 구체적으로 전달할 수 있습니다.

제 운영 경험상으로는, 경계가 명확히 구분되는 예시를 한 세트 배치함으로써 개선할 수 있었습니다. 필요한 예시의 개수는 태스크에 따라 달라집니다. 먼저 한 세트로 시도해 보고, 다른 입력에서도 의도한 판단이 되는지 확인한 후에 추가하는 것을 고려합니다.

지금까지의 3가지는 판단 프롬프트를 좋게 만드는 이야기였습니다. 다만, 그 프롬프트가 올바르게 판단하고 있는지는 별도로 확인할 필요가 있습니다.

하는 것은 간단하게, 정답을 알고 있는 케이스를 판별하게 하는 것입니다. 의도적으로 망가뜨린 출력물(입력에 없는 고유명사를 섞은 것, 결론을 뒤집은 것)을 준비하여, 판별 프롬프트가 그것을 걸러낼 수 있는지 확인합니다. 걸러내지 못한다면, 판별 프롬프트 쪽에 문제가 있는 것입니다.

이 확인 과정을 생략하면, '판별이 전부 Yes로 통과하고 있다'는 상태가 품질이 높기 때문인지 아니면 판별이 느슨하기 때문인지 알 수 없게 됩니다. 평가 시스템을 넣었는데도 아무것도 걸러지지 않는 때는, 우선 이것부터 의심해야 합니다.

앞으로 같은 방법을 시도한다면, 망가뜨린 출력물에 더해 합격시키고 싶은 출력물도 검증용으로 준비해 주었으면 합니다. 프롬프트 속의 예시를 그대로 사용하는 것뿐만 아니라, 다른 입력을 사람이 판별하고 그 결과와 대조하는 것입니다. 불합격을 놓치는 경우와, 합격을 잘못 걸러내는 경우 양쪽 모두를 확인할 수 있습니다.

Langfuse 공식 자료에서도 LLM을 이용한 평가를 사용하기 전에, 레이블이 지정된 예시나 사람의 평가와 대조하는 방법을 안내하고 있습니다. 자신이 사용하는 모델, 설정, 프롬프트 버전, 평가 데이터를 기록하고 같은 조건에서 비교할 수 있게 하면, 변경 효과를 추적하기 쉽습니다.

• 규칙 기반으로 판별 가능한 것(포맷, 금지어, 글자 수)은 코드로 검사합니다.

• 5단계 점수제 대신, 관점별 Yes/No로 나눕니다. 걸러졌을 때 무엇이 문제인지 알 수 있는 형태로 만듭니다.

• 하나의 질문으로 한 가지 내용만 묻습니다. 필요한 정보의 누락이나 근거 없는 추가를 구별합니다.

• 판별보다 먼저 짧은 근거를 작성하게 하고, 입력/출력과 대조합니다. 순서 효과는 자신의 평가 데이터로 확인합니다.

• 판별 기준에는 합격 예시와 불합격 예시를 한 쌍씩, 불합격 이유를 덧붙여 배치합니다. 예시가 기준과 일치하는지도 확인합니다.

• 판별 프롬프트 자체도 정답을 아는 다른 입력으로 검증합니다. 합격/불합격 양쪽 모두를 사람의 판별과 대조합니다.

• Langfuse 공식 문서 'LLM-as-a-Judge' — 평가 기준, 입력, 출력 조합 및 사람의 판별과의 대조 방법. 2026년 9월 30일 확인.