저는 한동안 한국어 PDF를 대상으로 로컬 RAG(Retrieval-Augmented Generation)를 실행해 왔는데, 그때까지의 평가는 '응답이 괜찮아 보인다' 정도였습니다. 마침내 Allganize가 제공하는 한국어 RAG 세트를 사용하게 되었는데, 이 세트는 모든 질문에 정답과 해당 페이지가 알려져 있는(300개 질문, 64개의 PDF, MIT) 매우 체계적인 데이터셋입니다. 저는 모든 모델에게 동일한 상위 5페이지와 동일한 프롬프트를 제공했습니다.
저는 qwen3.6 27B를 심사관(judge)으로 사용했지만, 자체 계열에 대해서는 관대할 수 있다고 생각하여 Opus 5.5도 함께 평가하게 했습니다. Qwen3.8 27B (추론 과정 포함 시)는 77.3%의 점수를 받았고, Opus 5.5는 76.6%를 받았습니다. McNemar 테스트에서 p값은 0.82로, 이는 동률을 의미합니다. Opus가 심사한 결과는 각각 80.6% 대 80.3%로, 역시 비슷한 수준이었습니다. 다만, 추론 과정(thinking)을 사용하지 않으면 Qwen의 점수가 약 6점 하락하므로 이 부분은 놓치지 마세요.
저를 더 놀라게 한 것은 Opus가 실패한 지점을 분석했을 때였습니다. 총 70개의 오류 중 22개는 텍스트 레이어가 없는 단순 스캔 이미지 페이지였고, 23개는 검색기(retriever)가 올바른 페이지를 가져오지 못한 경우였으며, 실제로 모델이 잘못 작동한 경우는 단 25개에 불과했습니다. 따라서 솔직히 말해, 저에게는 더 이상 모델 자체가 병목 지점이 아니라 PDF 파싱(parsing) 과정입니다.
같은 세트를 사용한 2024년 상용 시스템(Alli + Claude 3.5 Sonnet)이 있는데, 이 시스템은 오직 스캔된 페이지(19개 대 1개)에서만 제 설정보다 나은 결과를 보였습니다. 저는 OCR(광학 문자 인식)을 사용하지 않았거든요. 하하.
또한 BM25를 단순 공백 분할(plain whitespace splitting)로 사용했을 때는 hit@5가 56%였지만, 적절한 한국어 형태소 토크나이저를 사용하자 80%까지 올랐습니다. 돌이켜보면 당연하지만, 저는 몇 달 동안 공백 기반 방식을 사용하고 있었습니다.
gpt-oss 20B는 처음에는 매우 형편없어 보였습니다(57.5%). 그러다가 빈 답변들이 많은 것을 발견했습니다. 제 1024 토큰 제한(token limit)이 모델이 추론을 하는 도중에 잘려나갔던 것입니다. 이를 8192로 늘리자 69.6%까지 상승했습니다. 이 부분은 제가 미흡했던 점입니다.
그 후 KRAFTON의 새로운 Raon-1 mini 프리뷰(30B MoE, 약 4B 활성)를 사용해 보았습니다. 이 모델은 74~75% 수준에 도달하며, 3090에서 초당 96 토큰을 처리하는 좋은 성능을 보여줍니다. 하지만 온도(temp) 0에 추론 과정을 적용했을 때, 320개 질문 중 16개 질문에서 루프에 빠지는 문제가 있었습니다 (이 320개에는 제가 만든 답변 불가능한 질문 20개가 포함되어 있습니다).
제가 확신하지 못하는 몇 가지 점들이 있습니다. 모든 것은 temp 0으로 한 번의 실행 결과이며, 같은 모델을 다른 하드웨어에서 실행했을 때 11개의 판결이 뒤집혔기 때문에, 1점 차이는 아무 의미가 없습니다.
그리고 그 답할 수 없는 20개의 질문들은 너무 쉬웠다. 모든 모델이 하나도 답변하지 않았기 때문에, 나는 거기서 아무것도 배우지 못했다. 더 어려운 것들을 작성해야 할 필요가 있다. 스크립트, 질문별 판결(verdicts), 그리고 전체 표는 누구나 살펴보고 싶다면 여기에 있습니다: https://bric.pe.kr/blog/local-rag-27b-ties-opus-korean-documents-300-questions submitted by /u/Front-University4363 [link] [comments]