문서 요약 SaaS에서 GPT-4o와 Claude Sonnet을 실트래픽 절반씩 한 달 A/B 돌린 결과

PDF를 올리면 핵심을 뽑아주는 1인 SaaS를 운영합니다. 모델을 못 정하고 미루다가, 실사용 트래픽을 절반씩 갈라 한 달 돌렸습니다. 벤치 점수가 아니라 "한국어 표가 섞인 PDF"라는 제 워크로드에서 실제로 뭐가 나은지가 궁금했습니다.

제 워크로드에서 갈린 핵심은 표였습니다. 표가 많은 한국어 PDF에서 GPT-4o는 셀 병합을 잘못 풀거나 행을 통째로 빠뜨리는 일이 주기적으로 나왔고, Sonnet은 그 빈도가 눈에 띄게 낮았습니다. 요약 SaaS에서 표 한 행이 빠지면 사용자가 바로 알아채는 종류의 결함이라 이 차이가 컸습니다.

품질 평가는 트래픽이 늘면서 눈으로 다 못 보게 돼 LLM-judge로 넘겼는데, 여기서 함정이 하나 있었습니다. judge가 자기 계열(같은 벤더) 출력을 미세하게 후하게 줬습니다. 그래서 평가 모델은 생성 모델과 다른 벤더로 분리했습니다. 이게 정석인지는 단정 못 하지만, 자기편 들기는 줄었습니다.

비용에서 제일 컸던 결정은 한 모델로 다 막으려던 걸 포기한 것입니다. Sonnet을 기본으로 두되, 짧고 단순한 요청만 더 싼 모델로 라우팅했습니다. 모델 단가를 깎으려 애쓰는 것보다, 난이도로 트래픽을 쪼개 비싼 모델 호출 자체를 줄인 게 청구서를 더 내렸습니다.

다만 이건 '표 많은 긴 한국어 PDF'라는 제 워크로드 한정 결론입니다. 일반화하지 마시고, 본인 트래픽을 반 갈라 직접 한 달 돌려보시는 게 트위터 벤치 백 개보다 정확합니다.