프롬프트를 고칠수록 LLM-as-a-Judge 점수는 올랐는데, 무엇이 효과가 있었을까
사내 AI Fluency 세션을 준비하면서 같은 HR 소개 문구의 프롬프트를 여러 번 고쳐봤습니다. 맥락을 보충하고 작업 단계를 나눈 뒤, 모델의 역할을 정하고 답변을 내기 전에 스스로 검토하도록 요청했습니다.
당시 Langfuse의 LLM-as-a-Judge는 명확성, 명료함, 정확성, 톤 적절성, 행동 유도를 각각 5점 척도로 평가했습니다. 화면에 표시된 다섯 항목의 평균은 4.70, 4.74, 4.78, 4.80, 4.82 순서로 올랐습니다.
세션에서는 이 방식이 꽤 유용했습니다. 참가자가 수정 전후의 결과를 바로 비교하면서 다음 프롬프트를 직접 고쳐볼 수 있었기 때문입니다. 그런데 이 과정을 글로 옮기면서 “그래서 어떤 요소가 효과가 있었는가”를 설명하려니, 당시의 비교로는 답할 수 없다는 걸 알게 됐습니다.
세션에서는 앞선 변경을 유지하며 프롬프트를 고쳤다#
실습은 기준 프롬프트에 맥락을 추가하고, 그 결과에 작업 단계를 더하고, 다시 역할과 출력 전 검토를 추가하는 순서로 진행했습니다. 앞에서 넣은 조건은 그대로 둔 채 다음 조건을 쌓아가는 방식이었습니다.
이 방식은 최종 프롬프트 후보를 빠르게 찾아가는 데 잘 맞았습니다. 세션에서 궁금했던 것도 “조건을 더했을 때 결과가 어떻게 달라지는가”였습니다. 짧은 시간 안에 여러 조합을 보여주기에는 자연스러운 흐름이었습니다.
문제는 같은 결과를 두고 “역할 지시가 효과가 있었다”거나 “출력 전 검토가 점수를 올렸다”고 말하려 할 때 생겼습니다. 작업 단계를 추가한 프롬프트에는 이미 맥락이 들어 있었고, 마지막 프롬프트에는 앞선 조건이 모두 남아 있었습니다. 점수의 차이가 어느 조건에서 나온 것인지는 나눠볼 수 없었습니다.
같은 비교로 개별 요소의 효과까지 말할 수는 없었다#
누적 비교가 잘못된 것은 아니었습니다. 최종 조합을 탐색하는 비교와 각 요소의 효과를 알아보는 비교가 서로 다른 질문에 답한다는 점을 구분하지 못했던 것 같습니다.
질문이 달라지면 비교할 프롬프트도 달라집니다.
| 확인하려는 질문 | 비교 방법 | 알 수 있는 범위 |
|---|---|---|
| 전체 조합이 기준보다 나은가 | baseline과 full prompt 비교 | 선택한 입력과 평가 조건에서 두 조합의 차이 |
| 기준에 한 요소를 더하면 어떤 차이가 생기는가 | baseline과 baseline + element 비교 | 기준점에서 요소를 추가했을 때의 차이 |
| 최종 프롬프트에서 한 요소가 기여하는가 | full prompt와 full prompt - element 비교 | 최종 조합에서 요소를 제거했을 때의 차이 |
| 두 요소를 함께 쓸 때 달라지는가 | 여러 요소 조합을 포함한 비교 | 실험에 포함한 조합 안에서의 결합 효과 |
세션에서 사용한 누적 방식과 요소별 효과를 확인하는 방식은 다음처럼 달랐습니다.
| 누적해서 조합을 찾는 방식 | 기준에서 한 요소씩 비교하는 방식 |
|---|---|
baseline | baseline |
baseline + context | baseline + context |
baseline + context + steps | baseline + steps |
baseline + context + steps + role | baseline + role |
baseline + context + steps + role + review | baseline + review |
두 방식 중 하나가 더 올바른 것은 아닙니다. 누적 비교는 어떤 조합을 다음 후보로 가져갈지 살펴보는 데 쓰고, 요소별 비교는 기준점에서 한 조건을 추가했을 때의 차이를 확인하는 데 사용할 수 있습니다.
한 번에 하나씩 바꾸면 충분할까#
처음에는 한 번에 하나만 바꾸면 각 요소의 효과를 분리할 수 있을 거라고 생각했습니다. 하지만 이 방법도 요소가 서로 영향을 주는 경우까지 보여주지는 못합니다.
예를 들어 역할 지시는 단독으로는 차이를 만들지 않지만, 작업 단계와 함께 있을 때만 영향을 줄 수 있습니다. baseline + role만 비교하면 이 관계는 보이지 않습니다. NIST의 실험 설계 안내에서도 한 번에 한 요소를 바꾸는 방식은 요소 사이의 상호작용을 확인하기 어렵다고 설명합니다.
따라서 먼저 한 요소씩 비교해볼 수는 있지만, 함께 사용할 때의 효과가 중요하다면 여러 조합도 다시 비교해야 합니다. 모든 조합을 확인하기 어렵다면 어떤 조합을 제외했고, 그 결과 어떤 관계까지는 알 수 없는지도 해석에 남겨야 합니다.
점수를 만든 조건도 실험의 일부였다#
세션이 끝난 뒤 기록을 다시 보니 프롬프트 내용과 다섯 항목의 평균만으로는 결과를 재현하기 어려웠습니다. 같은 프롬프트라도 생성 모델과 파라미터가 달라지면 출력이 달라지고, 평가 모델과 판정 프롬프트가 달라지면 점수도 달라질 수 있습니다. 반복 실행 없이 한 번 관찰한 차이는 실행 간 변동과 구분하기도 어렵습니다.
Langfuse에서는 평가 기준별로 판정 프롬프트를 만들고 입력과 생성 결과를 변수로 연결할 수 있습니다. 아래 화면은 특정 프롬프트가 좋아졌다는 증거라기보다, 어떤 설정이 점수를 만들었는지 확인할 수 있는 평가 구조를 보여줍니다.
실행 결과 화면에서는 입력별 점수와 판정 근거를 다시 볼 수 있습니다. 평균만 보는 것보다 어떤 입력에서 차이가 생겼는지 살펴보는 편이 다음 수정 방향을 찾는 데 더 도움이 됐습니다.
다시 비교한다면 프롬프트 버전과 변경한 요소뿐 아니라 입력 데이터, 생성 모델과 평가 모델의 버전, 파라미터, 원본 응답과 판정 근거를 하나의 실행 기록으로 남기려고 합니다. 변형별 반복 횟수와 실행 식별자도 있어야 같은 조건의 결과를 모아볼 수 있습니다.
동일한 입력을 모든 변형에 사용하면 평균뿐 아니라 어떤 입력에서 결과가 달라졌는지도 대응해서 볼 수 있습니다. 반복 횟수는 미리 정답처럼 정하기보다 예비 실행에서 확인한 변동과 평가 비용을 보고 정하는 편이 맞을 것 같습니다.
LLM이 매긴 점수도 다시 확인해야 했다#
세션에서는 LLM-as-a-Judge를 빠른 피드백 도구로 사용했습니다. 톤 적절성이나 행동 유도처럼 코드로 판단하기 어려운 항목을 바로 비교할 수 있어서 실습을 이어가기에는 편했습니다. 하지만 판정자도 LLM인 만큼 그 점수를 그대로 정답으로 받아들일 수는 없습니다.
LLM 판정자를 분석한 연구에서는 답변의 위치와 길이에 따라 판정이 달라질 수 있다고 설명합니다. 이 연구가 당시 점수의 원인을 대신 설명해주는 것은 아니지만, 평가 모델과 판정 프롬프트도 함께 확인해야 할 조건이라는 점은 알 수 있었습니다.
Langfuse의 LLM-as-a-Judge 안내처럼 일부 결과는 사람이 직접 평가하고 LLM의 판정과 비교해볼 수 있습니다. 형식 준수, 금칙어, 허용 목록 밖의 기능처럼 답이 명확한 조건은 코드로 확인하고, 문장의 설득력이나 사용자 관점처럼 의미 판단이 필요한 부분은 LLM 평가와 사람 검토를 함께 쓰는 편이 자연스러웠습니다.
누적 비교는 교육에는 유효했고, 효과를 설명하기에는 부족했다#
돌이켜보면 세션에서 필요했던 것은 참가자가 프롬프트를 고치도록 돕는 빠른 피드백이었습니다. 누적 비교는 그 목적에 잘 맞았고, 실습 자체를 잘못 설계한 것은 아니었습니다. 다만 그 결과로 각 요소의 효과까지 설명하려고 하면서 비교가 답할 수 있는 범위를 넘어갔습니다.
프롬프트 실험에서 가장 먼저 정해야 하는 것은 한 번에 몇 개를 바꿀지가 아니라, 그 비교로 어떤 질문에 답하고 싶은지인 것 같습니다. 질문을 먼저 정하면 비교할 프롬프트와 입력 데이터, 반복 실행, 평가 방법도 따라옵니다. 이후에는 점수의 높낮이를 해석하기 전에 그 점수를 만든 비교가 어떤 질문에 답할 수 있는지부터 확인하려고 합니다.
이 실험의 출발점이 된 사내 교육은 AI 협업 기준을 함께 이야기한 사내 세션에서, 평가할 제품 경계를 프롬프트에 넣은 과정은 프롬프트에 행동 조건을 적어본 글에서 다룹니다.