KLUE NER 의 라벨 id 순서는 B-DT(0) … I-TI(11), O(12) 로 'O' 가 맨 뒤다.
스크립트는 ["O"] + [B-/I- ...] 로 재구성해 써서 전체가 한 칸씩 밀렸다.
tokenize_and_align 은 데이터셋 id 를 그대로 넘기는데 build_metrics 가
어긋난 순서로 해석하면서, 실제 O 구간이 I-TI 엔티티로 집계됐다.
영향 — micro support 14,257(실제 엔티티 수) → 67,056 으로 부풀고
F1 도 함께 올랐다. 학습된 klue_ner_large 를 올바른 매핑으로 재평가하면
0.8123 이며 보고돼 온 0.8750 이 아니다. 전 차수 성적서의 support 62,760
(max_length 절단분 차이) 도 같은 상태였다.
모델 자체는 데이터셋 id 공간에서 일관되게 학습돼 재학습이 필요없다.
잘못된 것은 지표 해석뿐이다.
라벨 목록을 데이터셋에서 직접 가져와 유일한 출처로 삼는다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
성능평가확인서 "4. 결과 측정" 은 최상위 precision/recall/f1_score 와
detailed_report 로 구성된 JSON 을 캡처해 싣는다. 기존 출력은
{model, f1, report} 라 그대로 붙일 수 없었다.
build_scorecard() 로 seqeval 리포트를 성적서 키 구성으로 재배열하고,
indent=4 JSON 을 터미널에도 출력해 캡처 한 장으로 끝나게 한다.
seqeval 의 dict 순서는 엔티티 등장 순서라 실행마다 달라지므로
태그 순서를 DT→LC→OG→PS→QT→TI 로 고정했다.
result.json 은 성적서 형식만 담고, 모델명·하이퍼파라미터는
run_meta.json 으로 분리한다.
전 차수 성적서(GERIR.CE.2511-02.009) 9p 실측값으로 형식 일치를 확인했다.
docs/PERF_EVIDENCE_CAPTURE_2026.md: 3.2.1/3.2.2 항목별 캡처 대상과
소스코드 위치를 HWP 슬롯 순서대로 정리.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
성능지표 #3(메타 데이터 추출 F1) 을 측정할 수 있게 만든다. 전 차수 시험은
저장소의 요소 추출기가 아니라 KLUE NER 토큰 분류 과제였다. 성적서 7~8p 의
모델 구조(BertForTokenClassification, klue/bert-base, 13 labels)와 태그 6종
(DT/LC/OG/PS/QT/TI), 리포트 형식을 그대로 따른다.
재현 결과 support=62760 이 전 차수 성적서와 일치해 같은 과제·같은 측정임을
확인했다. 학습셋을 전체(21,008건) 로 쓰면 0.8113 -> 0.8324 로 오른다.
다만 0.8324 는 목표 0.83 과 0.24%p 차이라 재학습 시 미달 위험이 있어
klue/roberta-large 로 올린다. 0.8750 으로 여유가 생기고, 전 차수에 약했던
LC(0.7563->0.8209) 와 TI(0.7674->0.8308) 가 특히 개선된다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
