업무용 검색과 RAG를 붙일 때 임베딩 길이는 품질만의 문아닙니다. 벡터가 길면 저장과 연산, 메모리 사용량이 함께 늘어나고 API 호출 비용과 검색 지연도 커집니다.
임베딩 API 차원 축소는 모델이 학습한 앞쪽 좌표만 남겨 길이를 줄이는 설정입니다. OpenAI는 dimensions로 출력 길이를 지정하고, Gemini는 output_dimensionality로 같은 일을 합니다. 길이를 줄이기 전에 기본 차원과 권장 값을 먼저 확인하는 편이 안전합니다.
임베딩 차원이 검색 품질과 비용에 미치는 영향
더 큰 임베딩을 벡터 스토어에 두면 검색과 저장에 비용·연산·메모리·스토리지를 더 씁니다. OpenAI 기준으로 text-embedding-3-small 기본 차원은 1536이고 text-embedding-3-large는 3072입니다.
차원이 길면 가까운 문서를 가려내는 여유는 커지지만 인덱스 비교 횟수와 디스크 사용량도 같이 늘어납니다. 검색 품질만 보고 최대 길이로 고정하면 지연과 인프라 비용이 먼저 한계에 닿습니다. 업무용 RAG에서는 재현율 목표와 스토어 한도를 함께 맞춰 길이를 고르는 편이 실무에 맞습니다. 1536과 3072를 같은 질의로 비교하면 비용 증가가 품질 이득을 넘는지 바로 보입니다.
OpenAI·Gemini 등 API에서 차원을 줄이는 방법
(출처: Coding Crash Courses)
OpenAI와 Gemini는 생성 시점에 출력 길이를 지정하는 쪽이 기본 경로입니다. 이미 받아 둔 벡터의 끝만 자르는 방식은 정규화와 모델 세대 확인이 필요합니다. 벡터 DB가 1024차원까지만 받을 때도 모델은 그대로 두고 출력만 줄이면 됩니다.
Python Embeddings API의 dimensions는 text-embedding-3 이후 모델에서만 지원됩니다. Gemini는 output_dimensionality로 크기를 제어하며 기본은 3072입니다. 권장 값은 768, 1536, 3072입니다. 구형 ada 계열에는 dimensions를 넣어도 동작하지 않습니다.
dimensions 파라미터로 벡터 길이를 지정하기
OpenAI 가이드는 개념 표현을 유지한 채 길이를 줄이려면 dimensions를 넘기라고 적습니다. text-embedding-3-large에 dimensions=1024를 넣으면 3072에서 1024로 줄여 1024 제한 스토어에도 넣을 수 있습니다.
다만 길이를 줄이면 정확도와 크기 사이에 트레이드오프가 생깁니다. API에서 짧게 만드는 방법이 수동 절단보다 안전합니다. 3-large를 256차원으로 줄여도 MTEB에서 단축하지 않은 ada-002 1536보다 낫다고 나와 있습니다. 작은 스토어 한도에 맞출 때 모델을 내리는 대신 차원만 조정하면 됩니다.
이미 받은 벡터를 잘라 쓸 때 주의점
3세대 임베딩은 벡터 끝부분 숫자를 제거하는 단축을 해도 개념 표현을 유지하도록 학습됐습니다. 그래도 OpenAI는 API의 dimensions로 생성하는 쪽을 권장합니다. 끝부분을 잘라 쓰는 작업은 같은 모델, 같은 정규화 규칙을 모든 문서와 질의에 동일하게 적용해야 합니다.
생성 후 직접 자르면 임베딩을 정규화해야 합니다. 정규화를 빼면 코사인 유사도와 내적 점수가 어긋나 순위가 흔들립니다. 예전 모델 벡터를 같은 방식으로 자르면 품질이 급격히 떨어질 수 있으니 모델 세대를 먼저 확인하십시오. 질의 벡터와 문서 벡터의 절단 길이가 다르면 비교 자체가 무의미해집니다.
Matryoshka 임베딩으로 한 번에 여러 길이를 쓰는 법
Gemini의 gemini-embedding-001과 gemini-embedding-2는 Matryoshka Representation Learning으로 학습되어 앞쪽 prefix만으로도 유용한 저차원 임베딩이 됩니다. 고차원 벡터의 초기 구간이 같은 데이터의 단순한 버전입니다.
한 번 받은 3072차원에서 768이나 1536만 잘라 인덱스별로 나눠 쓸 수 있습니다. 질의와 문서는 같은 앞구간 길이를 써야 점수가 맞습니다. 권장 값 밖 길이는 품질 손실이 커질 수 있어 768, 1536, 3072를 우선합니다. 별도 모델 호출 없이 길이만 바꿔 실험할 수 있어 재임베딩 부담이 줄어듭니다.
업무 검색·RAG에서 차원 축소 전후 비교하는 기준
차원 축소 전후는 한 지표만 보지 말고 업무 질의 세트에서 같이 재봅니다. 정답 문서가 상위 k에 남는 비율, 검색 지연, 임베딩 토큰 비용, 인덱스 용량을 한 표에 모아 두면 판단이 빨라집니다. OpenAI 3-large 256과 기본 3072처럼 간격이 큰 값은 단계적으로 비교하는 편이 안전합니다.
축소 후에도 재현율이 목표를 지키면 짧은 차원을 채택합니다. 재현율이 떨어지면 길이를 한 단계 올리거나 청크 단위를 먼저 손봅니다. 모델 교체와 차원 축소를 한 번에 바꾸면 원인 추적이 어려워집니다. 실험 로그에 모델명과 dimensions 값을 남기면 나중에 재현이 쉽습니다.
| 항목 | 축소 전 | 축소 후 확인 |
|---|---|---|
| 재현율 | 기본 차원 상위 k | 동일 질의에서 정답 유지 여부 |
| 지연시간 | 인덱스 검색 시간 | 짧아졌는지 측정 |
| 토큰 비용 | 임베딩 API 과금 | 호출 단가와 재임베딩 횟수 |
| 저장 비용 | 벡터 용량 | 차원 비율만큼 감소했는지 |
재현율·지연시간·토큰 비용을 같이 보기
재현율만 올리면 차원이 긴 쪽이 유리해 보이기 쉽습니다. 지연시간과 벡터 저장 비용을 같이 보면 중간 길이에서 업무 기준을 충족하는 경우가 많습니다. 상위 10개와 상위 50개를 나눠 보면 짧은 차원의 손실이 어디에 모이는지 드러납니다. 한 주 치 업무 질의 20~50개면 경향은 충분히 갈립니다.
토큰 비용은 차원과 별도로 입력 토큰에 붙는 경우가 많아 길이만 줄인다고 호출 단가가 바로 내려가지 않을 수 있습니다. 그래도 인덱스 메모리와 디스크는 차원에 비례해 줄어듭니다. RAG 임베딩 설정은 이 세 값을 한 질의 세트로 같이 기록할 때 설득력이 생깁니다.
차원만 줄이면 안 되는 경우와 대안
청크가 너무 길거나 질의와 문서 도메인이 어긋난 상태에서는 차원만 줄여도 순위가 개선되지 않습니다. 중복 문서와 빈약한 메타데이터도 짧은 벡터의 한계를 가립니다. 이 경우에는 차원을 되돌리기 전에 청크 경계와 질의 전처리를 먼저 점검합니다.
하이브리드 검색, 리랭커, 청크 재분할이 차원 축소보다 먼저인 경우가 있습니다. 구모델 벡터를 잘라 쓰는 방식은 정규화와 모델 지원 여부를 빼면 위험합니다. 품질이 목표 아래로 떨어지면 768에서 1536으로 올리는 편이 대안이 됩니다. 리랭커를 쓰면 1차 검색 차원을 더 줄여도 상위 정답이 회복되는 경우가 있습니다.
임베딩 API 차원 축소 실무 정리
임베딩 API 차원 축소는 검색 품질과 저장 비용을 맞추는 설정입니다. OpenAI는 dimensions로 출력 길이를 정하고, 수동 절단 시에는 정규화가 필요합니다. Gemini는 output_dimensionality와 Matryoshka 앞구간을 씁니다.
실무에서는 1536·768·256처럼 단계적으로 줄이며 재현율과 지연, 토큰 비용을 같이 봅니다. 벡터 DB 한도가 있으면 그 길이에 맞춰 API에서 생성합니다. 차원이 원인인지 청크가 원인인지를 나누지 않으면 설정만 복잡해집니다. 권장 차원 밖에서 임의로 자르기 전에 공식 권장 값부터 시험합니다.
