기준을 못 박고, 그 기준을 검수받다 — AI 결과물 검수 스터디 1주차

소개

지피터스 23기 AI 결과물 검수 스터디 1주차 기록입니다.

검수 대상으로 삼은 건 제가 따로 굴리고 있는 온톨로지 방법론 서베이 워크스페이스입니다. arXiv 논문을 모아 요약하고, 그중 검증을 통과한 것만 내부 위키에 정본으로 승격시키는 파이프라인입니다. 현재 규모는 수집 997편 → 전문 확보 116편 → 요약 초안 61편 → 위키 정본 26편.

1주차 커리큘럼 목표는 명확했습니다.

검수할 결과물 한 종류를 ingest하고, 무엇을·어떤 기준으로 검수할지를 문서로 못 박는다.

학습 항목은 다섯 개(의도 정렬 / ingest / 할루시네이션 3종 / 판정 3분류 / 골드 Eval Set)였고, 다섯 개 다 채웠습니다. 그런데 다 만들고 나서 걸린 게 하나 있었습니다.

골드셋도, 지표도, 판별식도 전부 제가 혼자 만들었습니다.

만든 좌석이 자기 것을 채점하면 producer ≠ evaluator 원칙에 정면으로 걸립니다. 기준점이 틀려 있으면 그 위에서 재는 모든 숫자가 무의미해집니다. 그래서 3주차 항목인 독립 외부모델 리뷰와 Loop 배선을 1주차 검증에 앞당겨 끌어왔습니다.

이 글의 초점은 5번 항목입니다. 기준점을 만드는 것보다, 그 기준점이 맞다는 걸 확인하는 게 실제로 훨씬 어려웠습니다. 독립 좌석에 5라운드 검수를 받았고 기준점 자신의 결함 11건이 나왔습니다.

진행 방법

사용한 도구

핵심은 producer 좌석과 reviewer 좌석을 다른 모델로 물리적으로 분리한 것입니다. 같은 세션 안에서 "이제 검수 모드로 봐줘"는 검수가 아니라 자기 확인입니다.

1) ingest — "넣었다"와 "검수 가능하게 넣었다"는 다르다

요약만 있으면 검증할 수 없고, 원문만 있으면 검증할 대상이 없습니다. 결과물↔근거를 한 쌍으로 넣어야 합니다.

초록만으로는 본문 표의 수치를 검증할 수 없어서 전문 116편을 따로 확보했습니다. 요약이 Table 3을 인용했는데 초록에 그 표가 없으면 검사기가 "원문에 없다"고 잘못 판정하니까요.

2) 할루시네이션 3종 → 검사 계층에 판정 권한 배분

"틀릴 수 있다"로는 아무것도 못 만듭니다. 유형을 먼저 나누고 층별로 권한을 달리 줬습니다.

L2에 거부 권한을 주지 않은 이유는 실측 때문입니다. 문자 유사도로는 충실한 의역(0.39)과 왜곡(0.39)이 겹칩니다. 권한을 주면 정상 의역을 대량 거부합니다. 이 "잡을 수 없으면 물러난다" 원칙이 1주차에만 다섯 번 반복 적용됐습니다(커버율·STR·부재 문항·L2·R-002).

3) 판정 3분류 — FAIL을 "대응이 갈리는 단위"로

FAIL이 전부 한 등급이라 매번 원문을 다시 열어야 했습니다. 고치는 방법이 정반대인데도요.

# 실측 — 원문 100-200 이 100200 으로 병합 추출된 사고 파일
[CONTRADICTED] Evidence 수치 원문 부재: '200' — 원문 '100200'(p.2)에 병합, 추출 손상
[INSUFFICIENT]  Evidence 수치 원문 부재: '777' ← 발명 수치

판별식을 세 번 갈아엎었습니다. "근방에 비슷한 수치가 있으면 CONTRADICTED"로 잡았더니 발명 수치 999가 원문의 1000 때문에 뒤집혔습니다. 지어낸 값을 "원문과 다를 뿐"으로 격하시키는 — 가장 위험한 오분류입니다. 최종적으로 L0 추출 검사가 신고한 병합 후보에만 한정했습니다. L0는 이미 실측으로 오탐을 102편 → 2편까지 좁혀둔 코드라, 새로 만들지 않고 그대로 재사용했습니다(이중 구현 금지).

4) 골드 Eval Set — 18문항을 무작위가 아니라 층화로

전부 "있는 것"만 물으면 적중률이 부풀려집니다. 층마다 다른 걸 측정하게 설계했습니다.

부재 층이 핵심 발견을 냈습니다. 있는 것만 물었다면 "80% 적중"으로 끝났을 겁니다. 부재 문항을 넣자 3/3 전건 실패 — 검색기는 답이 없어도 항상 무언가를 1위로 반환합니다. RAG에서 이게 할루시네이션 입구입니다.

차단 임계를 걸까 검토했는데, 걸면 안 됐습니다. 구조적 이유가 있었습니다.

python

# wiki_query.rerank()
rrf_norm = rrf_scores[i] / max_rrf   # 질의 '내부' 최대값으로 정규화
# → 1위 점수는 언제나 1.0. 점수에 "답이 있는가"의 정보가 애초에 없다.

대안(렉시컬 겹침)도 실측했습니다. 임계 0.18에서 부재 2/3 차단·실재 4/15 손실, 0.31에서 부재 3/3 차단·실재 10/15(67%) 손실. 부재 질문도 어휘는 공유하기 때문입니다 — 없는 건 그 조합이지 어휘가 아닙니다. 측정은 유지하고 차단은 하지 않기로 했고, 게이트 임계는 실재 15문항만으로 재고했습니다. 대신 매 실행마다 한계 경고를 출력합니다. 리포트에만 묻히면 "측정했다"가 "해결했다"로 오독되니까요.

5) 검수 의뢰문을 도구로 만들기 (프롬프트 전문)

quality_gates.md의 cold-read 계약은 검수 좌석에 ①산출물 ②공개 스펙만 주고 저자 의도·세션 히스토리 주입을 금지합니다. 문제는 손으로 프롬프트를 쓰면 제 관점이 반드시 샌다는 것입니다. 그래서 의뢰문을 결정론으로 조립하는 도구를 만들었습니다.

markdown

당신은 아래 산출물(검색 평가용 골드 Eval Set)의 냉독(cold-read) 검수자입니다.

[전제]
- 당신은 이 산출물의 저자가 아닙니다. 저자의 의도·작업 이력·기대하는 답을
  일절 전달받지 않습니다.
- 판정은 오직 아래 '공개 스펙'과 첨부 원문만으로 내립니다.
- 스펙에 임계가 정의되지 않은 항목은 판정하지 말고 **'보류'로 표기**하십시오.

[공개 스펙]
R1. 정답 노트는 질문에 대한 답을 실제로 담아야 한다
    (expected_evidence 문자열이 노트 '본문'에 존재해야 함)
R2. 근거는 질문이 묻는 지표와 일치해야 한다
    (precision을 물으며 recall 수치를 근거로 달지 않는다)
R3. 제3자가 첨부만으로 재현·감사할 수 있어야 한다
R4. 단일 정답 — 다른 노트가 '같은 층위의 답'을 담으면 위반
    (관련 주제를 다루는 것만으로는 위반이 아니다)
R5. 층 내 중복 0 — 한 층에서 같은 노트가 정답으로 2회 이상 쓰이면 위반

[검수 대상]
```
{골드셋 18문항 전문 + 위키 전 노트 본문이 여기 자동 삽입}
```

[출력 형식]
규칙 번호별로 — 위반 여부 / 근거가 된 원문 구절 / 확신도(high·medium·low).
임계가 없어 판정 불가한 경우 '보류'와 사유.

python

# coldread_request.py — 누출 검사, 걸리면 생성 자체를 거부(fail-closed)
_LEAK = "설계 근거 | 기대하는 답 | 정답은 …"

$ coldread_request.py --target summaries
cold-read 계약 위반 — 의뢰문에 저자 관점이 섞였다: '설계 근거'

그런데 이게 오탐이었습니다. 논문 요약 본문에 나온 "설계 근거"(그 논문의 설계 근거)를 잡은 겁니다. 검사가 템플릿과 검수 대상을 구분하지 못했습니다. 산출물 블록을 검사에서 제외하도록 고쳤습니다. 검수 장치 자신도 검수 대상이라는 걸 여기서 배웠습니다 — 안 고쳤으면 그 산출물은 영원히 검수 불가였습니다.

6) cold-read 5라운드 — 7 → 3 → 3 → 3 → 2

2차 지적이 3차 발견을 낳았습니다. 기대 노트만 첨부했을 땐 "다른 노트에도 답이 있는가"를 원리적으로 확인할 수 없었습니다. 전체를 넣자 κ 0.519가 3개 노트에 교차참조돼 있어 그 수치를 묻는 질문은 정답이 셋이었다는 게 드러났습니다.

1차에서 보류한 R4·R5는 스펙에 임계를 명시한 뒤 재판정해 종결했습니다. 결과는 둘 다 위반 확인 — concept 층 문항 6개에 고유 노트가 4개뿐이었고(deer-benchmark 2회, selfcheckgpt 2회), "기초 LLM만으로 충분한가"에는 다른 논문도 같은 층위로 답하고 있었습니다. 감으로 고쳤다면 3~5차에서 나온 6건은 영영 못 봤을 겁니다.

7) Loop — 고친 것이 다음 세션에 자동으로 실리게

검수로 규칙을 얻어도 다음 세션이 안 읽으면 무의미합니다.

1 판정      게이트 FAIL·REJECTED
2 기록 ★    append-only 원장 — 사유를 그대로, 재가공 금지
3 집계 ★    유형별 정규화 — 수치만 다른 건 한 유형으로
4 승격      ★ 사람이 규칙 확정 (자동 승격 없음)
5 주입 ★    세션 진입점 3곳 · 40줄 상한

이번 주 실측: 원장 108건 → 승격 규칙 4건 → 주입 3곳(phase_contracts §5 / coldread_request.py 공개 스펙 / session-memory.md).

4번만 사람이 합니다. 게이트 FAIL 대부분은 그 산출물 하나의 문제이지 절차 결함이 아닙니다. 절차 결함은 반복으로만 드러나고 그 판별은 사람 몫입니다. 자동 승격이었다면 이번에 원장을 독점한 커버율 WARN 50건(98%) 이 "[P1] 승격 후보"로 포장돼 규칙이 됐을 겁니다. 실제로는 지표 결함이었습니다 — 초록은 영어, 요약은 한국어라 knowledge↔지식이 원리적으로 안 겹치는, 임계 조정으로 교정 불가능한 문제였습니다.

📸 캡처 첨부 위치 — 발표자료 05p(판정 3분류 실측 출력), 08p(부재 문항 임계 손익표), 09p(fail-closed 거부 화면), 13p(Loop 배선도)

결과와 배운 점

숫자

적중률이 오른 건 검색기를 한 줄도 안 고쳤는데 나온 결과입니다. 기존 미스의 일부는 검색기가 아니라 골드셋 자신의 결함이었습니다. 정답이 둘이었던 문항은 검색기가 무엇을 반환해도 절반은 틀린 것으로 집계됐으니까요. 지표를 훼손해서 숫자를 올린 게 아니라, 기준이 정합해지자 지표가 제 값을 찾았습니다.

배운 점 네 가지

01. 자기 산출물은 자기가 못 본다. 골드셋을 만든 뒤 여러 번 검증했는데도, precision을 물으면서 recall 수치를 근거로 단 문항은 못 봤습니다. 노트 바로 다음 줄에 맞는 수치가 있었는데도요. producer ≠ evaluator는 규범이 아니라 실측으로 확인된 필요였습니다.

02. 검수 입력이 검수 품질을 결정한다. 기대 노트만 줬을 때와 전체를 줬을 때 발견되는 결함이 달랐습니다. "무엇을 보여줄 것인가"가 이미 검수 설계의 일부입니다.

03. 잡을 수 없으면 물러난다. 부재 문항, L2 의미 채널, R-002 게이트 확장 — 셋 다 측정은 하되 차단하지 않기로 했습니다. 과차단이 미탐지보다 나쁠 수 있습니다.

04. 확신 낮은 지적은 기각도 수용도 아닌 '보류'가 답일 수 있다. 기준이 없는 상태에서 고치면 그건 기준 없이 고치는 겁니다. 스펙을 먼저 정의하니 같은 지적이 확정 판정으로 바뀌었습니다.

시행착오

• 의뢰문 생성기가 자기 자신 때문에 막혔다 — 위 5)의 오탐. 검사 대상은 "내가 쓴 지시문"이지 "검수 대상 본문"이 아닙니다.

• 채점기 크래시 — 부재 문항(null)을 상정하지 않아 터졌습니다. 경로를 신설했습니다.

• 재현성 결손 1건(정직하게) — 반입 쿼리 12개 중 4개 문자열이 미기록이었습니다. git 차집합으로 2개는 복원했지만 나머지 2개는 부분 일치(20/29·17/33)에 그쳐 추정 복원을 거부했습니다. 재현성은 데이터가 아니라 기록 설계의 문제입니다 — 스키마에 출처 필드가 없으면 역산도 불가능합니다.

• 기각도 무해하지 않다 — Codex의 None vs null 지적은 사실이 아니었지만(저장 파일은 실제 null), 검수 좌석이 헛것을 보게 만든 건 의뢰문 렌더 잘못이라 생성기를 고쳤습니다.

가장 값진 순간은 이거였습니다. 채점기의 fail-closed 검사가 제가 쓴 검증 스크립트의 오탐을 잡았습니다. 저는 파일 전체를 검색해서 "위반 0"이라고 했는데, 채점기는 본문만 봐서 2건을 거부했습니다. 그 2건은 문구가 frontmatter 제목에만 있었습니다. 골드셋을 만드는 과정에서 골드셋의 게이트가 유효하다는 게 증명된 셈입니다.

도움이 필요한 부분

두 가지 논의를 청합니다.

1. 골드셋 층화 표본을 어떻게 설계하시는지. 18문항 4층은 제 임의 설계입니다. 층 비율이나 문항 수를 정하는 더 나은 근거가 있는지 궁금합니다.

2. RAG의 abstention(기권)을 어떻게 다루시는지. 부재 문항 0/3이 남은 한계인데, 점수 정규화 구조상 임계로는 못 막습니다.

그리고 AI 검수 체계를 보실 때 이 질문을 한 번 던져보시길 권합니다 — "그 기준점은 누가 검수했습니까?"

앞으로의 계획

2주차는 판정 출력 계약(score · PASS/FAIL/HUMAN_REVIEW · JSON), 인용·수치 검증(단위 정규화와 재계산 분리), 리뷰 루브릭, 지식베이스 4칸 구조입니다. 기준선이 섰으니 다음 주부터는 정량 비교가 가능해집니다.

남긴 한계도 적어둡니다. 부재 문항 0/3(측정만), R-002 따옴표 검사가 Evidence 절만 봄(60편 269건 무검사 — 지금 켜면 일괄 FAIL이라 전환 기간 설계 후 적용), 표본은 워크스페이스 1개·노트 26편.

도움 받은 글 (옵션)

• 지피터스 23기 AI 결과물 검수 스터디 1~4주 커리큘럼

• 산출물 워크스페이스: ontology-methodology / 검수 엔진: verifier-kit

• 본문의 모든 수치는 워크스페이스 실측값입니다.