같은 질문에 대한 두 답변을 평가자에게 보여줬다. 처음에는 A를 선택했는데, 답변의 순서를 바꿔 보여주자 또 A를 선택했다. 평가자가 같은 답변을 골랐다고 볼 수 있을까?

A가 화면상의 첫 번째 자리를 뜻한다면 두 번의 A는 서로 다른 답변이다. 내용을 그대로 두고 위치만 바꿨는데 선택이 바뀐 셈이다.

쌍대 평가에서는 결과 라벨뿐 아니라 그 라벨이 가리키는 실제 답변을 추적해야 한다.

앞선 회귀 테스트 글에서는 고정된 입력과 기준으로 판정 변화를 비교했다. 이번에는 입력 내용은 유지하고 제시 순서만 바꿨을 때 무엇을 기록해야 하는지 살펴본다. 아래 사례와 숫자는 모두 설명용 가상 데이터이며 모델을 호출해 얻은 결과가 아니다.

위치 편향이란 무엇인가

위치 편향은 평가자가 답변의 내용 외에 제시된 위치에 영향을 받아 특정 위치를 선호하는 현상이다.

위치 편향을 분석한 연구는 반복 안정성, 위치에 대한 일관성, 선호의 공정성을 구분해 평가한다. 연구에서는 편향의 양상이 평가 모델과 과제에 따라 달랐고, 답변 사이의 품질 차이도 영향을 주었다.

이를 “LLM은 항상 첫 번째 답변을 좋아한다”로 일반화하면 안 된다. 어느 위치를 얼마나 선호하는지, 그 경향이 실제 비교하려는 과제에서도 나타나는지는 별도로 확인해야 한다.

답변 ID와 표시 위치를 분리한다

가상의 도서관 안내문 요약 두 개를 비교한다고 하자.

  • answer-01: 운영 시간과 월요일 휴관, 어린이 자료실의 조기 종료를 모두 포함한 요약
  • answer-02: 일반 운영 시간만 포함하고 휴관일과 예외 시간을 빠뜨린 요약

두 답변의 ID는 고정하고, 평가자에게 보여줄 때만 A와 B를 붙인다.

평가 A 위치 B 위치 평가자의 선택 실제 선택된 답변
정방향 answer-01 answer-02 A answer-01
역방향 answer-02 answer-01 A answer-02

표시 라벨만 보면 A가 두 번 이겼다. 하지만 답변 ID로 정규화하면 승자가 뒤집혔다.

반대로 정방향에서 A, 역방향에서 B를 선택했다면 두 번 모두 answer-01을 선택한 것이다. 라벨은 달라졌지만 내용에 대한 선택은 유지됐다.

평가 요청과 함께 다음 매핑을 저장하면 집계에서 혼동을 줄일 수 있다.

{
  "pair_id": "library-pair-01",
  "presentation": "reversed",
  "slots": {"A": "answer-02", "B": "answer-01"},
  "raw_verdict": "B",
  "normalized_winner": "answer-01"
}

이 기록도 설명용이다. 실제 구현에서는 정규화된 승자를 평가 모델이 임의로 작성하게 두기보다, 저장한 슬롯 매핑과 반환 라벨로 코드에서 계산하는 편이 명확하다.

한 번 뒤집혔다고 위치 편향이 입증되는 것은 아니다

순서를 바꾼 두 호출에서 선택이 달라졌다는 사실은 불안정성을 보여준다. 그러나 그 원인이 위치뿐이라고 단정할 수는 없다. 같은 순서로 반복해도 판정이 달라지는 평가자라면 생성 변동이 함께 섞여 있다.

원인을 살피려면 두 종류의 비교를 구분한다.

비교 고정하는 것 확인하는 것
같은 순서 반복 질문·답변·순서·기준 반복 호출 자체의 변동
순서 교환 질문·답변 내용·기준 위치 변경에 따른 선택 변화

비교할 때는 답변 내용과 평가 기준, 모델 버전, 생성 설정을 유지한다. 역방향 평가에 첫 번째 판정이나 설명을 함께 넣으면 독립적인 재평가가 아니라 기존 판정에 영향을 받는 검토가 될 수 있으므로, 새 대화에서 평가하도록 설계할 수 있다.

여러 표본에 걸쳐 반복 변동과 위치별 선택 경향을 함께 확인해야 위치의 영향을 더 설득력 있게 설명할 수 있다. 작은 표본의 단일 역전만으로 모델 전체에 대한 결론을 내리지 않는다.

동점과 판단 불가를 별도로 남긴다

평가자가 항상 A나 B 중 하나를 골라야 한다면 거의 같은 답변에도 억지 승자가 생긴다. 다음 네 종류의 반환값을 허용하는 설계가 가능하다.

  • A 우세
  • B 우세
  • 동점: 비교할 근거가 있고 우열이 없다고 판단
  • 판단 불가: 자료 부족 등으로 비교할 수 없음

API 오류와 형식 오류는 판단 불가와 별개의 실행 실패로 기록한다.

순서를 바꾼 결과도 세분화한다. 두 번 모두 같은 답변을 고른 경우, 두 번 모두 동점인 경우, 서로 다른 답변을 고른 경우, 한쪽만 동점인 경우, 판단 불가나 실행 실패가 포함된 경우를 구분한다.

불일치를 모두 동점으로 바꾸면 안 된다. “비슷한 품질이라고 판단했다”와 “평가자가 일관된 판정을 내리지 못했다”는 다른 정보다.

분모가 보이는 집계표를 만든다

가상의 답변 쌍 10개를 정방향·역방향으로 각각 평가했다고 하자.

결과 유형 답변 쌍 수
같은 답변 선택 5
두 방향 모두 동점 1
서로 다른 답변 선택 2
한 방향만 동점 1
판단 불가 포함 1
실행 실패 포함 0

이 표에서는 두 방향 모두 A/B/동점으로 판정된 쌍이 9개다. 그중 정규화한 결과가 같은 쌍은 6개이므로, 이 글에서 정의한 순서 교환 일치 비율은 6/9다. 전체 요청 쌍 10개 중 1개가 판단 불가를 포함했다는 사실도 따로 표시한다.

이 지표는 설명을 위해 정한 집계 방식이며 논문의 지표를 그대로 재현한 것은 아니다. 평가 결과가 일치하더라도 두 번 모두 틀렸을 수 있으므로 정확도를 뜻하지 않는다.

승률을 계산한다면 동점에 반 점을 줄지, 판단 불가와 불일치를 어떻게 처리할지 먼저 정해야 한다. 비교 후 유리한 결과만 남기는 방식으로 분모를 정해서는 안 된다. 불일치 쌍을 제외했다면 제외 규모와 남은 표본의 특성도 함께 제시한다.

순서 교환은 점검 장치이지 정답 생성기가 아니다

두 방향을 평가하면 호출 수가 늘어난다. 처음에는 대표 표본과 품질 차이가 작은 사례를 나눠 점검할 수 있다. 다만 어려운 사례만 모은 결과를 전체 입력의 오류율처럼 해석하면 안 된다.

순서를 무작위로 섞는 것은 특정 모델이 항상 같은 위치에 놓이는 문제를 줄이는 방법이다. 하지만 개별 판정의 정확성까지 보장하지 않는다. 두 방향 결과를 합치는 방식도 처리 규칙을 정해야 하며, 편향이 완전히 상쇄된다고 가정해서는 안 된다.

불일치가 큰 경우에는 평가 기준이 모호한지, 두 답변이 사실상 동등한지, 평가자가 확인할 근거가 충분한지 살펴본다. 사람 검토를 할 때도 모델명은 가리고 같은 기준으로 평가하는 편이 좋다.

평가 시스템에는 원본 판정, 답변 ID, 슬롯 매핑, 실행 조건을 함께 남겨야 한다. 그래야 “A가 이겼다”라는 한 줄을 실제 내용에 대한 판단으로 되돌려 확인할 수 있다.

다음 글에서는 위치가 아니라 답변 안에 들어 있는 문장이 평가자를 움직이는 문제, 평가 대상에 포함된 프롬프트 주입을 살펴본다.

참고 자료