업무용 RAG에서 답이 빗나가는 이유는 생성 모델보다 검색에 쓰는 임베딩이 다른 경우가 많습니다. 같은 매뉴얼을 넣어도 모델과 차원이 바뀌면 상위 문서 순위가 달라집니다. 검색이 틀리면 생성 단계는 틀린 근거를 자연스럽게 이어 붙입니다. 실무 점검에서는 검색 순위를 먼저 봅니다.
이 글은 임베딩 모델 선택 API로 후보를 같은 질의에 호출하고 한국어 검색과 비용·지연시간을 함께 보는 순서를 안내합니다. 벡터 검색 API와 RAG 임베딩 선택 기준을 업무 문서에 맞춰 정리합니다. 파일럿 질의 로그와 정답 문서만 있으면 바로 적용할 수 있습니다. 스테이징 전에 이 순서를 끝냅니다.
임베딩 모델 선택 API가 필요한 업무 장면
사내 FAQ와 계약서, 제품 매뉴얼을 찾을 때 생성 모델만 바꾸면 문장은 매끄러워져도 근거 문단이 어긋납니다. 임베딩 모델 선택 API로 같은 질의와 같은 청크를 여러 모델에 넣고 상위 문서를 비교하면 원인을 빨리 가릅니다. 조항 번호가 비슷한 문서가 많을수록 이 차이가 뚜렷합니다.
한국어 임베딩 모델과 영문 특화 모델을 섞으면 재현율이 크게 달라집니다. 파일럿에서 이 차이를 고정하지 않으면 이후 전량 재임베딩이 생깁니다. 업무 담당자와 개발이 같은 질의 로그를 보면 교체 여부를 합의하기 쉽습니다. 질의에 제품 코드가 섞이면 토큰화 방식도 함께 적어둡니다.
선택 기준을 먼저 정하는 방법: 언어·도메인·지연시간
(출처: Codedeck)
모델을 호출하기 전에 언어 범위, 문서 도메인, 허용 지연시간을 숫자로 적어둡니다. 한국어만 볼지 다국어를 볼지에 따라 영어·코드 특화 모델과 다국어 모델이 갈립니다. 지연시간은 p95처럼 백분위 기준으로 적는 편이 운영과 맞습니다. 도메인 예시는 실제 파일 경로로 적습니다.
실시간 응답이 필요하면 고차원보다 축소 차원을 먼저 시험합니다. 기준이 없으면 임베딩 모델 비교 숫자만 보고 바꿔도 업무 체감이 남지 않습니다. 도메인이 법률·의료처럼 용어가 고정되면 일반 웹 벤치 점수만으로 고르지 않습니다. 허용 오차는 담당자가 틀린 근거를 몇 건까지 볼지로 정합니다.
한국어 검색 품질을 우선할지 다국어를 볼지
사내 문서가 한글 위주면 한국어 검색 품질을 1순위로 둡니다. Google Cloud 문서에서 text-embedding-004와 text-embedding-005는 768차원·최대 2048토큰이며 영어·코드 특화로 구분됩니다. 영문 코드 주석이 많은 저장소와 한글 규정집은 모델이 갈라집니다.
다국어 코퍼스는 text-multilingual-embedding-002를 쓰라는 안내가 있습니다. Gemini Enterprise RAG Engine도 기본은 text-embedding-005, 다국어는 002를 권장합니다. 한 코퍼스에 언어가 섞이면 기본 모델부터 넣지 않습니다. 언어 태그를 청크 메타데이터에 남깁니다.
짧은 질의 vs 긴 문서 청크에 맞는 차원 수
짧은 검색어와 긴 청크를 같은 차원으로 두면 유사도 검색 품질이 한쪽으로 치우칩니다. OpenAI text-embedding-3-small은 기본 1536차원, 3-large는 3072차원이며 dimensions로 줄일 수 있습니다. 질의는 짧고 청크는 긴 경우가 업무 검색의 기본입니다. 차원 수는 저장 단가와 함께 고릅니다.
3-large를 256차원으로 줄여도 MTEB에서 1536차원 ada-002보다 높다고 공식 문서가 밝힙니다. 청크가 길면 입력 한도도 함께 확인해야 잘린 문장이 검색에 섞이지 않습니다. 차원을 줄인 뒤에는 반드시 업무 질의로 순위를 다시 봅니다. 축소 차원은 저장 비용을 바로 낮춥니다.
OpenAI·Gemini·Claude 계열과 오픈소스 임베딩 비교 포인트
OpenAI 가이드의 MTEB는 text-embedding-3-small 62.3%, 3-large 64.6%, ada-002 61.0%이며 최대 입력은 약 8192토큰입니다. Anthropic은 자체 임베딩을 내지 않고 Voyage AI API 사용을 안내합니다. Claude로 답을 쓰더라도 검색 벡터는 다른 제공자를 써야 합니다.
| 제공자 | 대표 모델 | 기본 차원 | 입력 한도 |
|---|---|---|---|
| OpenAI | text-embedding-3-small / 3-large | 1536 / 3072 | 약 8192토큰 |
| text-embedding-005 | 768 | 2048토큰 | |
| Voyage AI | voyage-4 계열 | 1024, 256·512·2048 선택 | 32000토큰 |
voyage-4 계열은 컨텍스트 32000토큰, 기본 차원 1024에 256·512·2048 선택이 있습니다. 오픈소스 모델은 호스팅 지연시간과 라이선스를 따로 재야 합니다. 사내 GPU 대기열까지 포함해 비교하면 공개 리더보드와 한글 질의 순위가 자주 어긋납니다. 라이선스 조항이 상용 제한이면 후보에서 뺍니다.
API로 후보 모델을 호출하고 유사도 품질을 점검하는 흐름
OpenAI Embeddings Create API는 입력 배열을 한 요청에 넣습니다. 모델당 입력 상한은 8192토큰이고 요청 합산은 30만 토큰입니다. 같은 질의셋과 같은 청크를 각 모델에 보내 코사인 유사도 상위 k를 맞춥니다. 배치 한도를 넘기면 요청을 나눠야 하므로 측정 스크립트에 재시도를 넣습니다.
정답 문서가 상위 5개에 들어오는지 오답이 얼마나 끼는지 기록합니다. 벡터 검색 API 응답 시간까지 남기면 품질과 지연을 같이 고를 수 있습니다. 실패 질의는 그대로 재사용해야 모델 교체 효과가 드러납니다. 모델 이름은 응답 JSON에 남겨 재현 실험을 쉽게 합니다.
동일 질의셋으로 리랭킹 전후 차이를 보는 법
임베딩만으로 뽑은 상위 문서와 교차 인코더 리랭킹 뒤 순위를 나란히 둡니다. 리랭킹 전에 이미 정답이 상위권이면 임베딩 교체 이득이 작습니다. 이 경우에는 청크 경계나 메타데이터 필터를 먼저 손봅니다. 평가 질의마다 상위 10개를 저장합니다.
리랭킹 후에만 오르면 1차 검색 재현율이 부족한 상태입니다. 질의 20~50개 규모로도 모델 간 차이는 드러나므로 전량 색인 전에 이 비교를 끝냅니다. 리랭킹 비용이 크면 1차 후보 수만 줄이는 쪽을 먼저 봅니다. 전후 순위를 질의 단위로 남겨 두면 재검토가 빨라집니다.
비용·토큰·재임베딩 부담을 줄이는 운영 팁
차원이 클수록 저장·검색 비용이 늘고 모델 교체 때 전량 재임베딩이 생깁니다. OpenAI처럼 개념 표현을 유지한 채 차원을 줄이는 옵션이 있으면 파일럿에서 256~512를 먼저 봅니다. 색인 용량이 커지면 근사 검색 파라미터도 같이 흔들립니다. 재임베딩 창구를 분기 배포에 맞추면 부담이 줄어듭니다.
청크 길이를 입력 한도 안에 고정해야 잘림으로 품질이 떨어지지 않습니다. 모델 ID와 차원, 청크 규칙을 설정에 잠가 두면 임베딩 차원 비용을 예측할 수 있습니다. 색인 버전을 나누어 두어야 롤백도 가능합니다. 월 토큰 예상치는 재임베딩 주기와 곱해 봅니다.
임베딩 모델 선택 API 활용 정리와 다음 단계
업무 RAG는 생성 모델보다 임베딩 모델 선택 API로 검색 축을 먼저 고정하는 편이 안전합니다. 언어·도메인·지연시간을 적은 뒤 OpenAI·Gemini·Voyage 후보를 같은 질의셋으로 호출합니다. 표의 입력 한도를 넘기는 청크는 미리 잘라 둡니다. 후보가 3개를 넘기지 않게 좁힙니다.
유사도 검색 품질과 토큰·재임베딩 비용을 같이 보고 차원을 줄일지 결정합니다. 다음 단계에서는 선택한 모델을 스테이징 색인에 올리고 주간 질의로 상위 문서 이탈을 확인하면 됩니다. 이탈이 늘면 모델보다 청크와 질의 정규화를 먼저 점검합니다.
