약속이 아니라 측정.
Klorn이 공개하는 수치, 각 수치의 출처, 그리고 각 수치가 말해 주지 못하는 것. 여기 나오는 데이터셋과 스크립트는 모두 공개 저장소에 있습니다.
세 가지 수치와 출처
- ≥90%긴급 메일 재현율 (CI 하한)
합성 게이트셋에서 긴급 메일 재현율을 90% 아래로 떨어뜨리는 분류기 변경은 빌드가 실패합니다.
출처: eval-floors.ts - 95.5%Silent 정밀도
직접 라벨링한 실제 메일 세트에서 측정: Klorn이 Silent로 보낸 22건 중 21건이 실제로 Silent 라벨이었습니다. 2026-08-26 세 번 실행, 매번 같은 결과.
출처: eval/README.md - 0미승인 실행
전송·영구 삭제·외부 전달은 승인을 기다리고, 나간 내용의 해시가 박힌 영수증을 남깁니다. 직접 만든 자동 답장 규칙은 그 승인으로 칩니다.
코드로 강제: attention-floor.ts
대표 정확도는 싣지 않습니다. 실제 메일 세트는 Meeting·Info 레인이 생기기 전에 만들어졌습니다. 라벨이 세 레인뿐이라 나머지 두 레인을 채점할 수 없고, 다섯 레인 기준으로 다시 라벨링해야 합니다. 그 전까지는 이 세트에서 나온 대표 정확도를 싣지 않습니다. 위의 Silent 정밀도도 같은 세트에서 나왔고 같은 한계를 갖습니다.
평가는 이렇게 돌아갑니다
커밋된 데이터셋
packages/api/eval/에 두 세트가 있습니다. 실제 메일 세트(real-eval-set.json)는
직접 라벨링하고 개인정보를 지운 실제 메일 53건입니다. 합성 게이트셋(judge-eval-set.json)은 개인정보가 없는
가상의 메일 56건입니다.
실행기
packages/api에서 pnpm eval:real을 실행하면 실제 메일 세트로 분류기를 채점합니다.
pnpm eval:judge는 합성 세트로 같은 일을 합니다.
CI 게이트
분류기를 바꾸는 모든 풀 리퀘스트는 합성 게이트셋을 모델에 돌리고, 세 하한을 강제합니다: 전체 80%, 긴급 메일 재현율 90%, Silent 정밀도 90%. 하나라도 못 미치면 실패합니다. 포크에서 온 풀 리퀘스트처럼 모델 키가 없으면 통과가 아니라 안내와 함께 건너뜁니다.
모델이 필요 없는 두 번째 검사는 모든 CI 테스트 실행에서 돕니다. 규칙 기반 빠른 경로와 키워드 대체 경로가 같은 세트에서 70%에 닿아야 하고, 놓친 긴급 메일은 Silent가 아니라 Queue로 떨어져야 하며, 마케팅 메일은 절대 긴급으로 분류되면 안 됩니다.
실제 메일 세트도 같은 풀 리퀘스트에서 채점하지만 보고용입니다. 긴급 레인 라벨이 4건뿐이라 90% 하한이 의미를 갖기 어렵습니다.
2026-10-14에 저장소 기준으로 확인했습니다. 틀린 내용이 있나요? 알려 주세요.