시도하고자 했던 것
사례글을 대량으로 걸러내는 판정기를 3주째 쓰고 있었습니다. 대표 수치로 "판정 일치율 94.1%"를 들고 다녔고요.
그런데 그 숫자가 무엇을 재고 있었는지 확인해 봤습니다. 94.1%는 재현성이 아니었습니다. 같은 라운드 안에서 서로 다른 판정자가 얼마나 겹치는지였고, 다시 돌렸을 때 같은 답이 나오는지는 한 번도 잰 적이 없었습니다.
그래서 이번 주 과제로 잡은 것은 하나입니다 — 같은 글을 두 번 판정시키면 같은 답이 나오는가, 안 나온다면 무엇 때문인가.
진행 방법
1단계 — 에이전트를 더 붙여 봤습니다 (전부 실패)
재현성이 낮으면 보통 이렇게 대응합니다. 저도 그랬습니다.
① 팬아웃 vs 단독 — 같은 6건을 ①에이전트 1개가 전부 ②에이전트 6개가 1건씩 판정.
조건
정답지 대비
토큰
시간
단독
40.0%
127,848
443초
팬아웃 6개
40.0%
313,420
204초
소수점까지 같았습니다. 얻은 것은 속도 2.2배뿐이고 토큰은 2.45배 썼습니다.
② 인용 강제 — 점수마다 본문 인용을 필수로. 최종 판정 재현성 67% → 67%, 변화 0. 토큰만 15% 추가.
③ 그냥 두 번 반복 — 역시 67%.
세 가지가 전부 무력했습니다. 지금 보면 이유가 명확합니다 — 셋 다 같은 정보원(LLM의 인상)을 재배열했을 뿐, 외부 신호를 하나도 추가하지 않았습니다.
2단계 — 표본을 24건으로 늘렸더니 46%
n=6은 얇아서 24건으로 늘려 독립 2회를 돌렸습니다.
최종 판정 일치 11/24 = 45.8%, κ = 0.148
개별 항목(칸) 단위 일치는 80.8%
이 두 숫자의 관계가 눈에 띄었습니다. 저희 규칙은 5개 항목을 합쳐 하나의 판정을 냅니다. 0.808⁵ = 34.5%인데, 5칸이 모두 맞은 비율이 실제로 33%였습니다.
개별 판정은 쓸 만한데 묶는 순간 곱셈으로 무너지고 있었습니다.
3단계 — 여기서 함정을 밟을 뻔했습니다
임계값을 바꿔 봤습니다. 경계 구간을 없앴더니 일치율이 46% → 71%로 뛰었습니다. 25%p 개선이니 정답처럼 보였습니다.
κ를 보니 0.148 → 0.045로 폭락했습니다. 대부분이 한쪽으로 몰려 우연 일치가 부푼 것뿐이었습니다. 우연 보정을 안 했으면 그대로 채택했을 겁니다.
4단계 — 자료를 고정해 봤습니다
여기까지 저는 "점수 척도가 불안정한 게 범인"이라고 결론 냈습니다. 틀렸습니다.
마지막으로 한 가지만 바꿨습니다. 판정자가 각자 웹에서 글을 가져오는 대신, 한 번 받아 파일로 굳혀 놓고 그 파일만 읽게 했습니다. 규칙도 모델도 그대로입니다.
조건
패턴 칸
점수 칸
최종 판정
κ
각자 가져오기
80.8%
68.1%
46%
0.148
고정 파일
92.5%
91.7%
83%
0.648
점수 칸이 68% → 92%로 뛰었습니다. 척도가 흔들린 게 아니라 판정자들이 매번 다른 렌더링·다른 분량의 텍스트를 보고 있었던 겁니다. 그 차이가 고스란히 "판단 차이"로 집계되고 있었습니다.
5단계 — 기계는 얼마나 정확한가 (처음 재봤습니다)
깨달은 게 하나 더 있습니다. 지금까지 잰 모든 숫자가 LLM 대 LLM이었습니다. 94.1%도 46%도 "다른 실행과 겹치나"였지 "맞았나"가 아니었습니다.
그래서 코드가 정답을 확정할 수 있는 문항을 만들었습니다. 같은 파일에 대해 — 코드블록이 있는가 / 표가 있는가 / 백분율이 있 는가 / 외부 링크가 있는가. 전부 파일 구문으로 답이 확정됩니다.
그리고 같은 에이전트가 같은 파일을 읽고, 이 문항들과 기존 판단 문항에 동시에 답하게 했습니다. 그러면 에이전트 편차·자료 차이가 전부 통제되고 질문의 종류만 변수로 남습니다.
결과: 4문항 전부 정확도 100%, 재현성 100%, κ = 1.000. 24건 × 4문항 = 96칸에 오답 0.
기계는 멀쩡했습니다. 질문이 확정적이면 완벽하게 답합니다. 흔들린 건 정답이 존재하지 않는 칸에 숫자를 채우라고 시켰기 때문입니다.
결과와 배운 점
제 오라클도 두 번 틀렸습니다
이 부분을 빼면 정직하지 않을 것 같습니다.
첫 번째 — "본문에 외부 링크가 있는가"를 정규식으로 셌더니 9건 중 2건이 오탐이었습니다. 에디터가 파일명을 자동으로 링크로 바꿔 놓은 것이었습니다: http://SOUL.md, http://watch.py. 사람이 보면 링크가 아닌데 코드는 링크로 셌습니다.
두 번째 — "코드블록이 있는가"에서 인라인 코드 표시를 코드블록으로 셌습니다. 질문 정의 자체가 모호했습니다.
코드는 환각하지 않습니다. 대신 틀린 질문을 정확히 실행합니다. 손으로 표본을 검산하지 않았으면 그대로 "정답지"로 썼을 겁니다.
제가 철회한 것 들
냈던 결론
정정
"점수 척도가 불안정의 원인"
철회 — 원인은 자료 불안정. 고정하니 κ 0.79~0.92
"게이트 전체가 0.8ⁿ으로 무너진다"
축소 — 개별이 92%면 0.92ⁿ. 항목 7개 이상이면서 정답 확정 수단이 없는 게이트만 해당
"최종 판정을 만들지 말고 플래그만 보여주자"
보류 — κ 0.648이면 압축해도 쓸 만함
그리고 하나 더: "개별 판정은 꽤 정확하다(80.8%)"고 썼는데, 그건 정확도가 아니라 재현성이었습니다. 정답지가 없는 상태에서 나온 숫자에 "정확"이라는 말을 붙였습니다.
바로 쓸 수 있는 것 3가지
① 판정 대상은 한 번 받아 고정한 사본에서만 읽게 하세요. 에이전트마다 각자 가져오면 서로 다른 텍스트를 봅니다. 저는 이것만으로 κ가 0.148 → 0.648이 됐습니다. 비용은 거의 0입니다.
② 채점 항목을 만들 때 "이 질문의 답을 자료에서 지목할 수 있는가"를 먼저 물으세요. 못 하면 척도를 붙이지 말고 이진으로 바꾸거나 "확인 못 함"으로 사람에게 넘기세요.
③ 재현성이 낮을 때 에이전트를 늘리지 마세요. 팬아웃도 인용 강제도 반복도 제 데이터에서는 최종 판정을 전혀 못 움직였습니다. 늘어난 건 토큰뿐이었습니다.
이 글이 보장하지 않는 것
n=24, 독립 2회입니다. κ<0.3 같은 방향성은 견고하지만 "0.148"이라는 점추정은 아닙니다.
마지막 단계에서 세 가지가 동시에 바뀌었습니다 — ①각자 가져오기→고정 파일 ②손 전사→구조화 출력 ③확정 문항을 먼저 물음. 점수 칸을 68→92%로 올리려면 72칸 중 17칸이 전사 오류여야 하는데 그건 실현성이 낮아 ①을 지배적 원인으로 봅니다만, 분리 실험은 안 했습니다.
사람 기준선이 없습니다. 같은 24건을 사람 둘이 판정하면 κ가 얼마인지 모릅니다. 그게 없으면 0.648이 좋은 건지도 확정할 수 없습니다.
모델을 한 번도 안 바꿨습니다. 전 실험 동일 모델 고정입니다.
이 결과는 제 판정 규칙에 대한 것이지 모든 판정 작업에 일반화되지 않습니다. 산수처럼 정답이 확정되는 과제는 애초에 이런 붕괴가 없습니다.
