Pblog.pistamond
← 목록으로
RAG2026.09.10 20:42

RAG 임베딩 모델, OpenAI와 BGE-M3와 E5 중 무엇을 쓸까

리더보드 점수로 고르면 대체로 후회합니다. 한국어, 차원 수, 그리고 실제로 재야 하는 지표를 기준으로 정리했습니다.

후보들의 실제 스펙

OpenAI 3-small OpenAI 3-large BGE-M3
차원 1536 3072 1024
최대 입력 8191 토큰 8191 토큰 8192 토큰
가격 (100만 토큰당) 27원 174원 자체 호스팅
다국어 지원 지원 100개 이상 언어
검색 모드 dense dense dense + sparse + multi-vector

가격은 달러 표시 단가($0.02 / $0.13)를 환율 1달러 = 1,340원(2026년 9월 10일)으로 환산한 세전 값입니다. 원화 정가는 없고, 매달 환율만큼 청구액이 달라집니다.

E5 계열(multilingual-e5)은 오픈 웨이트 다국어 모델로 같은 부류에 들어갑니다.

리더보드로 고르면 안 되는 이유

MTEB 같은 벤치마크는 유용하지만, 당신의 데이터로 매긴 점수가 아닙니다.

  • 벤치마크 코퍼스는 대개 위키·뉴스·웹 문서입니다. 사내 문서, 법률 문서, 코드, 고객 문의는 분포가 완전히 다릅니다.
  • 상위권 모델들의 점수 차이는 대개 1~3점입니다. 당신 데이터에서 그 순서가 유지된다는 보장이 없습니다.
  • 한국어 성능은 다국어 평균 점수에 묻힙니다.

실제로 갈리는 지점 세 가지

1. 한국어

한국어는 교착어라 형태소가 붙습니다. "결제하다 / 결제했습니다 / 결제가 / 결제를"이 전부 다른 토큰열입니다. 영어 위주로 학습된 모델은 이 변화를 같은 개념으로 묶는 데 상대적으로 약합니다.

BGE-M3가 이 지점에서 흥미로운 이유는 dense 하나만 주는 게 아니라는 데 있습니다. sparse(어휘 매칭, BM25에 가까운 토큰 가중치)와 multi-vector(ColBERT식 토큰 단위 상호작용)를 같이 냅니다.

이게 왜 중요하냐면 — 고유명사와 코드에서 dense 검색이 자주 실패하기 때문입니다. "PG-4021 오류"를 물었을 때 dense 벡터는 "결제 관련 오류"라는 의미로 뭉개서 엉뚱한 문서를 가져옵니다. sparse는 PG-4021이라는 토큰을 정확히 잡습니다. 사내 문서에는 이런 식별자가 아주 많습니다.

같은 효과를 OpenAI 임베딩 + 별도 BM25 인덱스로 만들 수도 있습니다. 다만 그건 인덱스를 두 개 운영한다는 뜻입니다.

2. 차원 수 = 저장·검색 비용

차원은 그냥 숫자가 아니라 인프라 비용입니다.

문서 100만 청크를 float32로 저장할 때:

1024차원 → 1M × 1024 × 4B ≈ 4.1 GB
1536차원 → 1M × 1536 × 4B ≈ 6.1 GB
3072차원 → 1M × 3072 × 4B ≈ 12.3 GB

벡터 DB는 이걸 메모리에 올리려 합니다. 3배 차이는 인스턴스 등급 차이로 직결되고, 검색 지연에도 영향을 줍니다.

3-large의 3072차원이 성능 대비 값을 하는 경우는 생각보다 드뭅니다. OpenAI 임베딩은 차원 축소를 지원하니, large를 쓰더라도 1024로 줄여서 비교해 볼 가치가 있습니다.

3. 운영 부담

API 자체 호스팅
초기 키 하나 GPU, 서빙, 배치 튜닝
최초 색인 100만 청크 약 54,000원 (small 기준, 청크당 2천 토큰 가정) 인스턴스 시간
재색인 다시 54,000원 다시 인스턴스 시간
모델 교체 파라미터 하나 재배포
데이터 반출 있음 없음

마지막 줄이 자체 호스팅의 진짜 이유인 경우가 많습니다. 비용이 아니라 문서를 외부로 보낼 수 없어서입니다.

그래서 어떻게 고르나

30분짜리 평가를 만드세요. 이게 리더보드 읽는 것보다 훨씬 빠르게 답을 줍니다.

1단계. 실제 사용자 질문 50개를 모읍니다. 없으면 팀원에게 물어보세요. 지어내지 마세요 — 지어낸 질문은 너무 잘 검색됩니다.

2단계. 각 질문에 대해 "이 문서가 나와야 한다"를 사람이 표시합니다. 질문당 1~3개면 됩니다.

3단계. 후보 모델별로 색인하고 recall@k를 잽니다.

recall@5 = (상위 5개 안에 정답 문서가 들어온 질문 수) / 전체 질문 수

4단계. 여기서 대부분 결론이 납니다. 그리고 자주 이런 결과가 나옵니다 — 모델 간 차이보다 청킹 전략의 차이가 더 큽니다. 800토큰으로 자르느냐 2,000토큰으로 자르느냐, 문단 경계를 지키느냐가 임베딩 모델 선택보다 recall을 크게 흔듭니다.

실무 권장 순서

  1. OpenAI 3-small로 시작하세요. 100만 토큰에 27원이면 실험을 막지 않는 가격이고, 인프라가 0입니다.
  2. recall을 재세요. 만족스러우면 끝입니다. 대부분 여기서 끝납니다.
  3. 한국어 고유명사·코드 검색이 약하면 sparse를 더하세요. BM25 하이브리드든 BGE-M3든.
  4. 데이터가 외부로 나갈 수 없으면 처음부터 자체 호스팅입니다. 이건 성능 문제가 아닙니다.
  5. 차원을 줄여보세요. 성능이 유지되면 인프라 비용이 그대로 절감됩니다.

정리

  • 리더보드 순위는 당신 데이터의 순위가 아닙니다.
  • 한국어에서는 dense 단독보다 sparse를 섞는 것이 고유명사·식별자 검색을 살립니다.
  • 차원 수는 성능 지표가 아니라 저장·메모리 비용입니다.
  • 모델을 바꾸기 전에 청킹부터 보세요. 대개 그쪽 영향이 더 큽니다.
  • 자체 호스팅의 진짜 이유는 비용이 아니라 데이터 반출 금지입니다.

여러분은 어떤 모델을 쓰고 계시고, 한국어 검색에서 어떤 케이스가 잘 안 되던가요?

출처

  1. OpenAI API 가격 — 임베딩 단가.
  2. BAAI/bge-m3 모델 카드 — BGE-M3의 다국어·하이브리드 검색 스펙.
  3. OpenAI, Embeddings 가이드 — 차원 축소(dimensions) 옵션과 입력 한도.
  4. MTEB 리더보드 — 본문에서 "그대로 믿지 말라"고 한 그 리더보드. 무엇을 재는지 확인하는 용도로는 유용합니다.
#RAG#임베딩#한국어#검색