프롬프트 비교 평가: 더 좋은 답변을 고르는 실전 기준

프롬프트를 바꿨더니 답변이 더 좋아 보일 때가 있습니다. 문장이 길어지거나 표가 생기면 완성도가 높아진 듯 느껴지기도 합니다. 하지만 원문에 없는 내용을 덧붙였거나 중요한 조건을 놓쳤다면 실무에서는 개선이라고 보기 어렵습니다. 프롬프트 비교는 “어느 답변이 마음에 드는가”에서 출발하되, 무엇을 잘해야 하는지 확인할 수 있는 기준으로 이어져야 합니다.

1. 좋은 답변의 기준부터 적는다

가상의 회의 메모를 요약하는 작업을 생각해 보겠습니다. 필요한 결과가 결정 사항, 담당자별 할 일, 아직 정하지 못한 항목이라면 이 세 가지를 평가 기준으로 삼을 수 있습니다. “명확하고 훌륭하게 요약”처럼 넓은 주문보다 “원문에 없는 담당자나 마감일을 만들지 않기”처럼 확인 가능한 조건이 유용합니다.
예를 들어 메모에 “안내문은 다음 회의에서 담당자를 정한다”라고 적혀 있다면 좋은 요약은 담당자 미정 상태를 유지해야 합니다. 매끄러운 문장을 만들기 위해 임의의 담당자를 넣으면 실패로 처리합니다. 글자 수와 말투도 중요하지만, 사실을 지키는 조건을 먼저 정해 두면 나중에 취향 때문에 판정이 흔들리는 일을 줄일 수 있습니다.

2. 같은 입력과 조건으로 비교한다

프롬프트 A는 “회의 내용을 간단히 요약해 주세요”, B는 “결정 사항, 할 일, 미정 항목을 나누고 원문에 없는 정보는 만들지 마세요”라고 가정하겠습니다. 비교할 때는 두 프롬프트에 같은 회의 메모를 넣어야 합니다. A에는 짧은 메모를, B에는 자세한 설명을 주면 프롬프트 차이와 입력 차이를 구분하기 어렵습니다.

같은 입력을 두 프롬프트에 제공하고 결과를 비교하는 과정을 설명하는 그림입니다.
가능한 범위에서 모델, 출력 길이 설정, 추가 자료, 대화 이력도 맞춥니다. 대화형 서비스에서는 앞선 답변이 다음 요청에 영향을 줄 수 있으므로 새 대화에서 비교하는 방법을 쓸 수 있습니다. 다만 서비스가 내부 조건을 모두 공개하지 않는다면 완전히 통제된 실험이라고 표현하기보다, 맞춘 조건과 확인하지 못한 조건을 함께 기록하세요.
한 번 나온 결과만 고르지 않는 것도 중요합니다. 같은 요청에서도 표현과 누락 여부가 달라질 수 있습니다. 처음에는 몇 개 입력을 같은 횟수로 반복해 보되, 반복 횟수와 전체 결과를 남깁니다. 가장 잘 나온 답변 하나씩만 비교하면 평소의 안정성을 알기 어렵습니다.

3. 쉬운 문제와 까다로운 문제를 섞는다

평가용 메모에는 결정과 담당자가 분명한 사례뿐 아니라, 일정이 두 번 바뀌거나 같은 사람에게 여러 일이 배정된 사례도 넣습니다. “금요일로 이야기했지만 최종 날짜는 미정” 같은 표현은 날짜를 확정해 버리는 실수를 찾는 데 도움이 됩니다. 정보가 적은 짧은 메모도 별도의 유형으로 포함해 보세요.

다양한 난이도의 사례와 최종 확인용 사례를 나누어 준비하는 평가 구성을 설명하는 그림입니다.
가령 입력 열 개로 작은 비교를 시작할 수는 있습니다. 그러나 열 개면 충분하다는 통계적 기준은 아닙니다. 실제 작업의 종류와 실패 비용에 맞춰 사례를 늘려야 합니다. AI에게 시험용 메모를 만들어 달라고 했다면 사람이 내용을 살피고, 기대하는 답이 정말 원문에서 나오는지 확인합니다. 생성된 정답도 검증 대상입니다.
프롬프트를 고칠 때 계속 보던 예시와 마지막 확인에 쓸 예시를 나눠 두면 좋습니다. 익숙한 문장만 잘 처리하도록 다듬었는지 확인하기 위해서입니다. 최종 확인용 입력을 수정 과정에서 반복해서 들여다봤다면, 새 사례를 준비해 다시 점검하는 편이 낫습니다.

4. 문장 취향과 필수 조건을 나눠 채점한다

처음부터 복잡한 총점을 만들 필요는 없습니다. 필수 정보 포함 여부, 근거 없는 추가 여부, 요청한 형식 준수 여부를 통과와 실패로 기록해 보세요. 같은 기준으로 평가한 뒤 읽기 쉬움이나 간결함을 별도로 비교하면, 유창하지만 부정확한 답변이 높은 점수로 가려지는 일을 줄일 수 있습니다.

두 답변을 사실 충실도와 완전성, 요청 길이 같은 기준으로 대조하는 그림입니다.
담당자와 마감일을 잘못 만든 답변에는 “담당자 오류”처럼 구체적인 사유를 붙입니다. 원문이 애매해서 사람이 봐도 판단하기 어려운 경우에는 억지로 정답을 정하지 말고 검토 필요로 남깁니다. 평가표 자체가 잘못 설계되었다면 좋은 답변도 오답이 될 수 있습니다.
간결함을 평가한다면 기준 길이와 반드시 남겨야 할 내용을 함께 적으세요. 짧다는 이유만으로 필요한 정보가 빠진 답변을 선택하지 않도록 하기 위해서입니다. 중요 항목 하나를 틀린 경우와 표현이 조금 어색한 경우도 같은 무게로 다루지 않는 것이 좋습니다.

5. AI 채점은 사람의 판단과 맞춰 본다

결과가 많아지면 다른 AI에게 두 답변을 비교하게 할 수 있습니다. 이때 원문, 평가 기준, 답변 두 개를 함께 제공하고 어느 문장이 어떤 기준에 맞거나 어긋나는지 짧은 근거를 요청하세요. “더 나은 것을 골라 줘”만으로는 길거나 격식 있는 답변을 선호하는 결과가 나올 수 있습니다.

답변의 이름과 순서를 조정하고 사람이 AI의 채점 결과를 함께 확인하는 과정을 설명하는 그림입니다.
평가자가 A와 B의 이름만 보도록 하고, 보여 주는 순서도 바꿔 확인하면 위치에 따른 편향을 살피는 데 도움이 됩니다. 동률이나 둘 다 실패라는 선택지도 남겨 두세요. 순서를 바꿨는데 판정이 뒤집힌다면 차이가 확실한지 다시 읽어야 합니다.
AI가 채점한 일부 결과는 사람이 직접 대조합니다. 사람과 AI의 판정이 자주 어긋나는 항목은 기준을 더 명확히 하거나 사람 검토 대상으로 둘 수 있습니다. AI 점수는 비교를 돕는 자료이며, 민감한 판단을 자동으로 확정하는 근거로 쓰기에는 추가 검증이 필요합니다.

6. 평균 점수보다 실패 유형을 남긴다

마지막에는 전체 통과 비율과 함께 실패 목록을 봅니다. B가 평균적으로 읽기 쉬워졌더라도 일정이 모호한 메모에서 날짜를 자주 만들어 낸다면 그 문제부터 고쳐야 합니다. 응답 시간과 출력 길이도 기록하면 품질 개선이 실제 작업 시간에 어떤 영향을 주는지 살펴볼 수 있습니다.
프롬프트 원문, 사용한 모델과 날짜, 입력 묶음, 채점 기준, 결과를 한 세트로 보관하세요. 다음 수정에서는 바뀐 조건을 적고 같은 평가를 다시 실행합니다. 좋은 프롬프트는 한 번 멋진 답변을 만든 문장보다, 필요한 상황에서 중요한 조건을 꾸준히 지키는 문장에 가깝습니다. 평가 기록이 쌓이면 수정할 곳도 훨씬 구체적으로 보입니다.