모벤MOVE BEYOND

RAG 정확도 96%는 무엇을 잰 숫자인가 — 채점 기준과 근거 출력

정확도 숫자를 채점 기준과 함께 적고, 남은 오답을 검색·생성·채점으로 나누고, 계산된 값 옆에 근거와 파라미터 버전을 붙이는 방법.

RAG · 성능 측정 · LLM 평가3

"정확도 96%"는 그 자체로는 아무것도 말하지 않습니다. 무엇을 몇 개, 어떤 채점 기준으로 쟀는지가 붙어야 비교가 됩니다.

숫자는 채점 기준과 한 쌍으로 적는다

기술문서를 벡터 검색과 로컬 LLM으로 질의응답하는 대시보드에서 저희는 50문항 평가셋으로 답변 정확도를 쟀습니다. 채점 키워드 임계값을 40%에서 60%로 올린 상태에서 92.0% → 96.0%였고, 같은 평가셋에서 평균 벡터 검색 응답은 21.1ms → 15.2ms였습니다. 기준을 낮추면 점수는 언제든 오르기 때문에, 개선을 말할 때는 채점 기준을 같은 문장에 적습니다.

측정 조건이 기록에 없으면 없다고 적습니다. 폐쇄망에서 도는 문서 번역 파이프라인은 289페이지 기술문서 1건 기준으로 처리 시간이 35분에서 13분이 됐고(양자화를 낮춰 GPU에 100% 적재), 문서 단위 용어 캐시 도입 전후로 용어 일관성 지표가 70.5에서 86.5로 올랐습니다. 이 두 값은 평가셋 크기와 측정 환경이 기록에 남아 있지 않아, 인용할 때마다 그 사실을 함께 붙입니다.

남은 오답은 방어하지 말고 분류한다

기준을 세게 잡은 뒤 남은 오답 2건을 열어 보니 검색 실패가 아니라 채점 기준 미달이었습니다. 벡터 검색은 정답 문서를 반환하고 있었습니다. 오답이 검색·생성·채점 중 어디서 났는지로 나누면 다음에 손댈 곳이 정해집니다. 지표를 방어하는 것보다 한계를 나누는 쪽이 다음 작업을 만듭니다. 같은 시스템에서 열람 이력 805건을 전수 자동 검증(검증 항목 2,415개)으로 돌린 것도 같은 이유입니다. 표본으로 본 값과 전수로 본 값은 다른 주장입니다.

값 옆에 근거와 파라미터 버전을 붙인다

자동 계산도 같습니다. 저희가 자체 제작해 배포한 세액 계산 데모는 귀속연도 파라미터 테이블을 바꾸면 코드 수정 없이 화면의 모든 숫자가 다시 계산되고, 각 숫자에 단계별 계산 근거와 적용한 파라미터 버전이 따라붙습니다. 자동으로 판정한 건과 사람이 봐야 하는 건은 배지와 사유로 갈라 뒀습니다. 검토자가 "왜 이 값인가"를 코드가 아니라 화면에서 확인할 수 있으면, 정확도 숫자 하나보다 훨씬 오래 쓰입니다.

다른 노트

비슷한 문제를 앞두고 계시면, 저희가 만들어 둔 화면을 먼저 열어 보시는 편이 빠릅니다.