Medium의 Towards AI에 처음 게시했던 글의 코드 중심의 짧은 버전입니다.

만약 당신이 합계, 날짜, 금액과 같은 특정 필드를 추출하기 위해 LLM을 문서 더미에 적용해 본 적이 있다면, 그 불편한 상황을 잘 알고 있을 것입니다. LLM은 모든 문서에 대해 똑같이 확신에 찬 답변을 내놓지만, 그중 일부는 틀립니다. 정답(Label)이 없기 때문에 일일이 수동으로 확인할 수도 없습니다. 정답이 없다는 사실 자체가 바로 모델을 사용하게 된 이유이기 때문입니다. 결국 잘못된 결과물들이 조용히 배포됩니다.

저는 이 문제에 몇 주를 투자했고, '변형 테스트 (Metamorphic Testing)'라고 불리는 오래된 아이디어에서 빌려온 도움이 되는 방법을 찾아냈습니다.

비결: 변하지 않아야 할 것을 테스트하라
보통 정답을 변화시키지 않아야 하는 요소들을 알고 있습니다:

• 영수증의 품목 순서를 바꿔도 합계는 변하지 않아야 합니다.
• 관련 없는 푸터 (Footer)를 추가해도 변하지 않아야 합니다.
• 통화 기호를 제거해도 변하지 않아야 합니다.

따라서 시스템을 두 번 실행하십시오. 한 번은 원래 입력값으로, 다른 한 번은 "영향을 주지 않아야 할" 변형된 입력값으로 실행한 뒤 비교하십시오. 만약 출력이 서로 다르다면, 시스템이 스스로 모순을 일으킨 것입니다. 이것은 레이블(Label) 없이도 찾아낼 수 있는 버그입니다.

from wobbly import check, Relation, unchanged
import random

...

실제로 무언가를 잡아낼 수 있을까요?
저는 의도적으로 분리된 두 단계로 535개의 실제 스캔된 영수증 (ICDAR-SROIE) 데이터셋에 이 방법을 실행했습니다. 첫 번째 단계에서는 레이블을 전혀 읽지 않고 영수증에 플래그(Flag)를 표시했고, 그 다음 단계에서만 레이블을 열어 플래그의 정확도를 점수화했습니다.

홀드아웃 데이터 (Held-out data)에서, 이 시스템이 플래그를 표시한 영수증은 표시하지 않은 영수증보다 실제로 틀렸을 확률이 2.7배 더 높았습니다. 이 모든 과정은 레이블 없이 결정되었습니다.

솔직한 평가
이것은 스팟 체크 (Spot-check)이지, 안전망 (Safety net)은 아닙니다. 재현율 (Recall)은 낮습니다 (이 데이터셋에서 약 8%) — 즉, 대부분의 버그를 놓칩니다. 하지만 정밀도 (Precision)는 높습니다 (약 75%): 플래그가 표시된 항목 4개 중 약 3개는 실제 오류입니다. 따라서 이는 실제 테스트 세트를 대체하는 것이 아니라, 그렇지 않으면 조용히 배포되었을 버그들을 드러내 주는 저렴하고 레이블이 필요 없는 방법입니다.

쉽게 실수할 수 있는 한 가지

검증(Check)은 올바른 시스템이 이를 통과할 때만 유용합니다. 제가 처음 만든 "행 재정렬(reorder lines)" 변환(transform)은 모든 행을 무작위로 섞어버렸고, 이로 인해 올바른 추출기(extractor)들까지 망가뜨렸습니다. 실제 추출기들은 TOTAL과 같은 힌트(cue)와 그 다음 줄의 값을 쌍으로 묶기 때문입니다. 72개의 플래그 중 68개가 실제 버그가 아닌 잘못된 변환으로 인한 인위적인 결과물(artifacts)이었습니다. 해결책은 독립적인 블록들(헤더 / 항목 / 합계)을 하나의 단위로 순열(permute)하는 것이었습니다. 오직 실제 결함(defect)만이 검증을 통과하지 못하도록 변환을 설계하십시오.

직접 시도해보기
의존성 없는 작은 Python 라이브러리, MIT 라이선스:

pip install wobbly
코드: https://github.com/tarunagarwal1981/wobbly
전체 실험 과정 (실수 포함): https://medium.com/towards-artificial-intelligence/your-llm-extracted-10-000-numbers-which-ones-are-wrong-7a5d54050dd3

정답(ground truth)이 없을 때 여러분은 LLM의 출력을 어떻게 검증하고 계신가요? 사람들이 실제로 무엇을 하고 있는지 진심으로 궁금합니다.