프롬프트를 고친 뒤 더 좋아졌는지 어떻게 확인할까

프롬프트를 바꾼 뒤 답변 하나가 좋아졌다고 곧바로 전체 업무에 적용하기는 어렵다. 같은 입력을 이전 버전과 수정 버전에 넣고, 미리 정한 기준으로 비교해야 개선된 부분과 새로 망가진 부분을 구별할 수 있다. 이전에 통과하던 사례가 변경 후에도 통과하는지 확인하는 것이 프롬프트 회귀 평가의 핵심이다.

거대한 벤치마크를 먼저 만들 필요는 없다. 실제 업무를 대표하는 입력, 중요한 예외, 판정 기준과 버전 기록부터 갖추면 된다. 다만 적은 사례의 통과를 전체 정확도나 운영 성공률로 확대해서는 안 된다.

좋은 답변의 조건을 수정 전에 적는다

Anthropic의 평가 설계 문서는 업무에 맞는 구체적이고 측정 가능한 성공 기준과 예외 입력을 포함한 평가를 설명한다. “더 자연스럽다” 같은 인상만 남기기보다, 실제 사용자가 얻어야 할 결과를 판정할 수 있게 정하는 것이 출발점이다.

예를 들어 회의 메모에서 할 일을 추출한다면 ‘담당자와 기한을 구분한다’, ‘원문에 없는 기한을 만들지 않는다’, ‘확정되지 않은 할 일은 확인 필요로 남긴다’처럼 적을 수 있다. 문장 길이와 말투도 평가할 수 있지만, 기한을 만들어 내는 결함을 유창함으로 상쇄하지 않도록 별도 항목으로 둔다.

평가 전에 기준을 적어야 수정 버전의 답에 맞춰 합격 조건을 바꾸는 일을 줄일 수 있다. 사람이 읽어도 합의하기 어려운 입력은 먼저 모호한 사례로 표시한다. 평가자의 의견 차이를 모델 오류와 섞어 세지 않는 편이 낫다.

가상 사례: 기한 추출을 고쳤더니 미정 상태가 사라진 경우

다음은 실제 모델을 실행해 얻은 결과가 아닌 설명용 가상 비교다. 회의 메모의 담당자와 기한을 추출하는 프롬프트에 “모든 할 일에 기한을 채워라”라는 문장을 추가했다고 가정한다.

같은 평가 입력	기대하는 행동	가정한 이전 버전	가정한 수정 버전
“지수가 11월 4일까지 초안 작성”	담당자·기한을 원문대로 추출	기한 누락	정상 추출: 개선
“민호가 일정 확인 후 다시 공유”	기한 미정 유지	미정으로 표시	임의 기한 생성: 새 실패
“초안 작성, 담당자는 다음 회의에서 결정”	담당자 미정 유지	담당자 미정 표시	담당자 미정 표시: 유지

첫 번째 입력만 보면 수정이 성공한 것처럼 보인다. 세 입력을 함께 비교하면 누락 하나를 고치는 대신 새로운 추정 오류가 생겼다는 사실을 알 수 있다. 이 표의 건수나 결과는 성능 통계가 아니며, 이런 방식으로 결과를 읽는 방법을 보여주기 위한 예다.

대표 입력과 어려운 입력의 역할을 나눈다

일상적으로 자주 들어오는 입력은 실제 사용 상황을 대표하게 고른다. 드물어도 중요한 입력은 별도 묶음으로 추가한다. 원문에 답이 없는 경우, 여러 조건이 충돌하는 경우, 길이가 긴 경우, 출력 형식이 흔들리는 경우를 생각할 수 있다.

Hugging Face의 평가 고려사항은 데이터 분리와 불균형한 집단에서 평균 지표를 해석할 때의 한계를 설명한다. 여기서는 그 원칙을 프롬프트 수정에 적용해, 수정하면서 계속 들여다본 사례와 마지막 확인용 사례를 구별할 것을 제안한다. 이미 답을 보고 문구를 맞춘 사례의 통과만으로 새로운 입력에도 잘 작동한다고 판단하지 않는 것이다.

어려운 사례를 의도적으로 많이 넣은 묶음의 실패율은 실제 사용 빈도를 반영한 실패율과 다르다. 대표 입력의 결과와 예외 묶음의 결과를 따로 보고, 어떤 분모로 계산했는지 남겨야 비교가 흔들리지 않는다. 평가용 데이터에 개인정보가 있다면 이용 권한을 먼저 확인하고 불필요한 식별정보를 제거한다.

점수 하나보다 바뀐 실패를 먼저 읽는다

기존 성공이 새 실패로 바뀐 사례, 기존 실패가 개선된 사례, 두 버전 모두 실패한 사례를 나누면 다음 수정의 이유가 구체적이 된다. 통과율이 같아도 실패한 업무가 달라질 수 있으므로 평균 점수만으로 교체를 결정하지 않는다.

Google Cloud의 생성형 AI 평가 문서는 명시적인 평가 기준, 계산 기반 지표, 개별 응답과 집계 결과의 검토를 구분한다. 이 구분을 실무에 적용하면 다음처럼 역할을 나눌 수 있다.

• 필수값·자료형·허용값은 가능한 범위에서 결정적인 규칙으로 검사한다.
• 원문에 없는 조건을 만들었는지, 요약이 의미를 바꿨는지는 원문과 결과를 대조한다.
• AI 평가자를 쓴다면 판단 기준과 이유를 남기고, 중요한 실패나 의견 충돌은 사람이 확인한다.

비교할 때는 모델 식별자, 프롬프트 판본, 입력 자료 판본, 생성 설정과 평가 기준을 함께 남긴다. 한 번에 프롬프트와 모델을 모두 바꾸면 무엇이 개선 원인이었는지 분리하기 어렵다. 같은 입력에서도 결과가 달라진다면 반복 결과와 변동도 기록한다. 반복 횟수는 업무 위험과 변동성에 맞춰 정하며 보편적인 합격 숫자로 두지 않는다.

적용 판단에는 품질과 운영 조건을 함께 넣는다

치명적 오류가 남았는지 먼저 보고, 개선된 항목과 악화된 항목을 함께 판단한다. 그다음 같은 조건에서 측정한 응답 시간과 관측 가능한 사용량을 비교한다. 비용을 관측하지 못했다면 0으로 적거나 더 저렴해졌다고 결론 내리지 않는다.

기존 글 LLM 품질 문제를 좁히는 운영 신호가 실제 장애의 원인을 찾는 데 초점을 둔다면, 이 글의 비교는 변경을 적용하기 전에 같은 사례에서 퇴행이 생겼는지 확인하는 절차다. 오프라인 평가를 통과했어도 실제 트래픽의 입력 분포·지연·후속 업무까지 검증한 것은 아니다. 적용 범위를 정하고 이후 실제 실패를 새 평가 사례로 반영해야 한다.

자주 묻는 질문

평가 사례는 몇 개면 충분한가요?

업무 범위와 입력 다양성에 따라 달라진다. 처음에는 대표 상황과 중요한 예외부터 준비하되, 작은 묶음의 결과를 전체 성능으로 주장하지 않는다. 빠진 상황과 새 실패가 드러나면 평가 범위를 보완한다.

AI에게 두 답 중 더 좋은 것을 고르게 하면 되나요?

보조 평가로 쓸 수 있다. 다만 그럴듯한 표현을 사실 정확성보다 높게 평가할 수 있으므로 항목과 근거를 명시하고 중요한 판정은 원문과 확인한다. 평가 모델의 점수가 실제 사용자의 성공을 대신하지는 않는다.

전체 통과율이 올라도 교체를 보류할 수 있나요?

그렇다. 드물지만 중요한 조건에서 새 오류가 생겼거나 운영 비용·지연을 감당하기 어렵다면 보류할 수 있다. 무엇이 좋아지고 무엇이 나빠졌는지를 남겨야 다음 변경도 같은 기준으로 비교할 수 있다.

출력을 자동 처리한다면 평가 항목에 AI JSON의 실행 전 검증의 형식·근거 검사를 포함할 수 있다.

문서를 읽는 업무라면 외부 문서 속 지시문을 구별하는 방법도 정상 문서와 함께 시험해야 한다.