'베이스라인 대비 얼마나 개선되었나요?': 세 가지 벤치마크 주장
최근 일주일 사이 ML 커뮤니티에 세 가지 '성능 개선' 주장이 연달아 등장했습니다. 알리바바 Qwen 팀의 Qwen3.5 오픈소스 LLM이 GPT-5-mini와 Claude Sonnet 4.5를 벤치마크에서 능가한다는 발표, 나이브한 RAG 파이프라인을 1시간에서 30초로 줄였다는 120배 처리 속도 개선 사례, 그리고 벡터 유사도 검색 대신 LLM 추론 기반 인덱싱으로 검색 정확도를 높인다는 벡터리스(vector-less) 아키텍처 제안입니다. 숫자만 보면 인상적입니다. 그런데 제가 항상 먼저 던지는 질문이 있습니다. 근거는 있나요?
Qwen3.5: MoE 구조는 흥미롭지만, 벤치마크 선택이 수상합니다
VentureBeat 보도에 따르면 Qwen3.5-35B-A3B는 MMMLU(지식)와 MMMU-Pro(시각 추론) 항목에서 Qwen3-235B, GPT-5-mini, Claude Sonnet 4.5를 능가한다고 밝혔습니다. 기술 구조 자체는 흥미롭습니다. 총 350억 파라미터 중 활성 파라미터는 단 3억 개뿐인 Sparse MoE 구조에, Gated Delta Networks를 결합했습니다. 4비트 양자화 후에도 정확도를 유지한다는 주장도 있습니다.
그런데 여기서 Hacker News 커뮤니티가 정확하게 짚어낸 문제가 있습니다. SWE-bench 차트에 Claude가 빠져 있다는 점입니다. 이는 단순한 누락이 아니라, 모델이 상대적으로 불리한 벤치마크를 의도적으로 회피했을 가능성을 시사합니다. 실제로 Qwen3.5를 직접 사용해본 사용자들의 반응은 엇갈립니다. 'RTX 4090에서 로컬 코딩 성능이 처음으로 놀라운 수준'이라는 긍정 평가가 있는 반면, 'MBP M3 Max 128GB에서 45분간 돌아가며 부정확한 답을 냈다'는 사례도 있습니다. 이건 correlation이지 causation이 아닙니다—벤치마크 점수가 높다고 해서 사용자의 특정 use case에서도 좋은 성능이 보장되는 건 아닙니다.
Ablation Study 없는 양자화 주장, 어디까지 믿을 수 있나?
'4비트 양자화 후 정확도 손실 없음'이라는 주장도 꼼꼼히 살펴볼 필요가 있습니다. Claude에게 양자화 분석을 시킨 사용자가 '4비트가 99% 유사도를 유지하면서 8비트의 절반 크기'라는 결론을 얻었다고 공유했는데, 이것 자체가 아이러니합니다. LLM으로 LLM 양자화를 평가하는 건 독립적인 검증이 아닙니다. 중요한 건 어떤 태스크에서 측정한 유사도인가, 그리고 Q4_K_M이 최적의 양자화 전략인지에 대한 ablation study 결과입니다. 커뮤니티에서도 'Q4_K_M이 최적의 선택인지 궁금하다'는 질문이 나왔지만, 공식 문서에는 명확한 답이 없습니다.
프로덕션 환경에서의 현실도 냉정합니다. 클라우드 모델(Opus 4.6, Gemini Pro)이 수백만 달러짜리 H200 GPU 클러스터에서 구동되는 반면, 로컬 모델은 열 제약과 VRAM 한계라는 물리적 ceiling이 존재합니다. 'Sonnet 4.5급'이라는 마케팅 문구와 '로컬 GPU에서 45분 소요'라는 현실 사이의 간극이 바로 프로덕션 환경에서의 일반화 성능 문제입니다.
RAG 120배 개선: 재현 가능성 체크리스트
dev.to에 올라온 RAG 파이프라인 최적화 사례는 구체적인 수치와 코드를 제시한다는 점에서 상대적으로 신뢰도가 높습니다. Django + Milvus + Celery 스택에서 시작해, CUDA multiprocessing의 fork() 제약 문제를 발견하고 CPU 큐와 GPU 큐를 분리하는 아키텍처로 전환했습니다. 결과는 1시간 → 30초, 약 120배 개선입니다.
그런데 분석가 관점에서 반드시 물어야 할 것들이 있습니다.
- 샘플 사이즈가 충분한가요? Django 공식 문서 하나의 ingestion job을 기준으로 측정했는데, 이게 다양한 문서 유형과 크기에서도 재현될까요?
- 베이스라인이 얼마나 나이브했나요? 순차적 처리(sequential processing)는 병렬화만으로도 수십 배 개선이 가능합니다. 이미 어느 정도 최적화된 파이프라인 대비 개선 폭은 다를 수 있습니다.
- GitHub API rate limit을 걸지 않았다면? 저자 스스로 'rate limit 때문에 더 빠를 수 있었다'고 인정했습니다. 즉, 120배는 under-estimate일 수도, 통제 변수 미반영일 수도 있습니다.
그래도 아키텍처 설계 원칙은 배울 게 있습니다
수치의 일반화 가능성 문제와 별개로, 이 사례가 보여주는 설계 원칙은 탄탄합니다. 각 컴포넌트를 리소스 제약에 매핑하는 사고방식—CPU 워커는 저렴하니 많이, GPU 메모리는 귀하니 단일 프로세스로 보호, Milvus write는 per-call 비용이 크니 배치로—이 원칙은 어떤 ML 파이프라인에도 적용 가능한 throughput 최적화의 교과서입니다. Feature Store 설계나 embedding 파이프라인 구성 시 참조할 만한 패턴입니다.
벡터리스 인덱싱: '유사도 ≠ 관련성' 문제는 진짜입니다
dev.to의 또 다른 아티클은 전통적인 벡터 기반 RAG의 구조적 한계를 지적합니다. 고정 크기 청킹(chunking)으로 인한 문맥 단절, 'Appendix G 참조'나 'Section 4.2 참조' 같은 크로스레퍼런스를 벡터 유사도가 처리하지 못하는 문제, 그리고 검색이 '수동 매칭'에 머문다는 점입니다. PageIndex(github.com/VectifyAI/PageIndex)라는 오픈소스 구현이 소개되는데, 문서를 트리 구조로 계층화하고 LLM 추론으로 탐색하는 방식입니다.
이 접근법의 핵심 주장은 '관련성은 의미론적(semantic)이기 전에 위치적·논리적(positional and logical)'이라는 것입니다. 재무 보고서, 법률 문서, 연구 논문 같은 고도로 구조화된 문서에서는 이 주장이 설득력 있습니다. 그런데 중요한 질문이 남습니다.
- 정확도 개선을 정량화한 벤치마크가 있나요? 아티클은 구체적인 Precision@K, Recall@K, MRR 수치를 제시하지 않습니다. '더 정확하다'는 주장만으로는 부족합니다.
- LLM 추론 기반 탐색의 latency 비용은 어떻게 되나요? 벡터 검색 대비 추론 단계가 추가되면 p99 latency에 직접 영향을 미칩니다.
- 어떤 문서 유형에서 vector search를 outperform하는지 ablation이 필요합니다. FAQ나 비구조적 지식베이스에서는 기존 벡터 검색이 여전히 우세할 수 있다고 저자 스스로도 인정합니다.
시사점: 벤치마크는 시작점이지 결론이 아닙니다
세 가지 사례를 관통하는 공통점이 있습니다. 측정 환경이 프로덕션과 다릅니다. Qwen3.5의 벤치마크는 클라우드 추론 환경, 실제 사용자는 로컬 GPU의 열 제약과 VRAM 한계를 마주합니다. RAG 120배 개선은 단일 문서 컬렉션과 특정 하드웨어(RTX 4070 Super)에서의 측정입니다. 벡터리스 인덱싱의 정확도 개선은 정량적 근거 없이 아키텍처 우위를 주장합니다.
ML 데이터 분석가로서 제가 권하는 검증 프레임워크는 간단합니다. ①베이스라인을 명확히 정의하고, ②통제 변수를 고정하고, ③내 use case와 유사한 데이터 분포에서 측정하고, ④통계적 유의성을 확인하세요. 'SOTA 달성'이나 '120배 개선'은 그 다음 이야기입니다.
전망: 오픈소스 LLM 품질 수렴과 RAG 아키텍처의 분화
그럼에도 방향성은 읽힙니다. Qwen3.5 커뮤니티 반응 중 가장 의미 있는 코멘트는 '올해 안에 로컬 GPT-5.2급 모델이 나올 것'이라는 기대입니다. 오픈소스 LLM과 클라우드 모델의 성능 격차는 실제로 빠르게 좁혀지고 있으며, 비용 구조는 이미 압도적입니다(Qwen3.5-Flash $0.5 vs Claude Sonnet 4.5 $18, 100만 토큰 기준). 성능이 '충분히 좋아지는' 순간, 비용과 데이터 프라이버시가 선택의 결정 변수가 됩니다.
RAG 아키텍처는 단일 접근법에서 use case별 분화로 향할 가능성이 높습니다. 비구조적 문서는 벡터 검색, 고도로 구조화된 엔터프라이즈 문서는 reasoning-based 인덱싱, 그리고 대규모 처리량이 필요한 파이프라인은 GPU/CPU 큐 분리 아키텍처가 각각의 표준으로 자리잡을 것입니다. 중요한 건 도구가 아니라, 어떤 문제에 어떤 측정 지표를 적용할 것인가라는 질문을 먼저 하는 습관입니다.
벤치마크 숫자는 대화의 시작점입니다. 재현 가능성, 데이터 분포, 프로덕션 환경의 현실—이 세 가지를 함께 보지 않으면 숫자는 마케팅 카피와 다르지 않습니다.