입력을 3분의 1로 줄여보니, 고쳤다고 믿었던 게 둘로 갈렸다

2단 처리가 수치 정확도와 누락을 같이 고쳤다. 짧은 입력으로 다시 재보니 하나는 길이 문제였고 하나는 구조 문제였다

2단 처리가 수치 정확도와 누락을 같이 고쳤다. 그런데 테스트셋이 중앙 12,000자였고 실제 경제 기사는 3~4천자다. 같은 문서에서 표와 부록을 떼고 서술부만 남겨 다시 재니, 고쳤다고 믿었던 게 길이 문제 하나와 구조 문제 하나로 갈렸다.

하려던 것

지난 편에서 요약을 두 단계로 나눴다. 1단이 원문에서 수치만 뽑고, 2단은 원문을 다시 읽지 않고 그 목록으로 문장을 쓴다. 한국어에서 수치 실재율이 97.0%에서 99.6%로, 재현율이 51.8%에서 69.8%로 같이 올랐다.

기분 좋게 끝낼 수 있었다. 그런데 테스트셋을 다시 보니 중앙 12,000자였다. SEC 실적 발표문에 재무제표 표가 붙은 분량이다. 실제 경제 기사는 3~4천자다.

고친 게 정말 구조 문제였나, 아니면 그냥 입력이 길어서 생긴 문제였나.

어디서 막혔나

이걸 가르려면 길이만 다른 세트가 필요했다. 영문 경제뉴스 피드를 뒤졌는데 전부 막혔다. 전문을 주는 피드가 없고 설명이 최대 279자다. 기사 페이지를 긁으려니 유료벽과 자바스크립트가 걸린다.

Fed와 SEC 보도자료는 정적 페이지라 받혔다. 진짜 경제 뉴스이고 재배포 제약도 없다. 그런데 재보니 못 쓴다.

길이는 뉴스답게 짧은데 수치가 없다. 수치 충실도를 재는 지표가 성립하지 않는다.

어떻게 풀었나

같은 문서를 잘랐다. 실적 발표문에서 재무제표 표와 부록을 떼고 서술부만 남겼다. 기업이 통신사에 배포하는 실제 기사 원고고, 무엇보다 같은 문서라 길이 변수만 분리된다. 중앙 3,598자, 원본의 29%다.

만드는 과정에서 잔해를 세 번 걷어냈다. 괄호 지역번호 전화가 남아 수치로 잡혔고, 슬라이드 첨부라 면책조항으로 시작하는 문서가 섞였고, 리드를 찾는 정규식이 단어 중간에서 잡혀 FEBRUARY가 EBRUARY로 잘렸다. 122건이 남았다.

정리하면

숫자를 틀리는 건 길이 문제였다. 입력이 짧아지자 1단만으로도 97.0%에서 99.7%로 올라간다. 짧은 입력에는 2단이 필요 없다.

숫자를 빠뜨리는 건 구조 문제였다. 길이를 줄여도 1단은 60.1%에서 멈추고 2단은 82.0%까지 간다. 뉴스 길이에서 2단 이득이 오히려 더 크다. 긴 원문에서 +18.0%p, 뉴스에서 +21.9%p다.

한 요청에 정확하고 빠짐없고 짧게를 동시에 요구하면, 입력이 짧아도 모델은 빠짐없이를 포기한다. 건초더미 문제가 아니라 과제를 한꺼번에 준 탓이다.

그리고 앞서 “영문은 2단 이득이 없다”고 적은 것도 길이 탓이었다. 긴 원문에서 영문 재현율은 56.9%에서 48.6%로 내려갔는데, 뉴스 길이에서는 66.6%에서 74.3%로 올라간다. 긴 영문에서 추출 단계가 수치를 덜 건진 것이었다. 추출 재현율이 66.9%와 83.9%로 갈린다.

배운 점

효과를 봤으면 그게 무엇의 효과인지 갈라야 한다. 2단이 두 지표를 같이 올리는 걸 보고 거기서 멈출 뻔했다. 섞어두면 “2단 처리가 좋다”는 뭉툭한 문장만 남는다. 갈라놓으면 짧은 입력이면 1단으로 충분하고 빠짐없이가 중요하면 2단이 필요하다가 된다. 뒤쪽이 실제로 쓸 수 있는 문장이다.

그리고 테스트셋이 결론을 정한다. 내가 SEC 실적 발표문을 고른 건 전문을 받을 수 있고 숫자가 촘촘해서였다. 그 선택 때문에 12,000자짜리 입력으로 재고 있었고, 실제 쓸 입력의 세 배였다. 세트를 안 바꿨으면 영문 2단은 손해라는 틀린 결론을 그대로 남겼을 것이다.

부수적으로 이 저장소 문서도 고쳤다. 컨텍스트 262,144를 두고 “슬라이딩 윈도우라 동시성 손해 없음”이라고만 적혀 있었다. 그건 처리량 이야기다. 품질은 13,000토큰에서 이미 무너진다. 한계의 5%다. 받아주는 길이와 정확도가 유지되는 길이가 스무 배쯤 다르다는 걸 한 줄로 적어뒀다.

원자료: docs/ECON_MODEL_EVAL.md. 테스트셋 생성은 tests/build_news_testset.py.

#dgx-spark#llm#평가#gemma#로컬llm