시도하고자 했던 것
사례글을 대량으로 걸러내는 판정기를 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이 좋은 건지도 확정할 수 없습니다.
모델을 한 번도 안 바꿨습니다. 전 실험 동일 모델 고정입니다.
이 결과는 제 판정 규칙에 대한 것이지 모든 판정 작업에 일반화되지 않습니다. 산수처럼 정답이 확정되는 과제는 애초에 이런 붕괴가 없습 니다.
