임베딩 크기: 768, 1536 또는 3072 차원?

분명히 text-embedding-3-small과 text-embedding-3-large 중에서 먼저 선택하는 것은 잘림에 대해 이야기하기도 전에 기본 크기 1536에서 3072 사이를 선택하는 것과 같습니다. 아래 표에는 pgVector가 인덱싱 측면에서 기본적으로 인식하는 세 가지 수준과 해당 Aurabase 경로에 대한 검증 가능한 사실이 요약되어 있습니다.

출처: OpenAI, 공식 블로그 “새로운 임베딩 모델 및 API 업데이트”, 2024년 1월 25일(MTEB 점수 및 출시 가격, 사용하기 전에 현재 가격 페이지에서 확인) aura-ai/src/embeddings/mod.rs, Aurabase(열 및 인덱스 지원, 2026년 8월 24일 확인).

임베딩은 부동 소수점 숫자 배열처럼 저장됩니다. pgVector에서 클래식 vector 유형은 각 차원을 4바이트(float32)로 인코딩합니다. 따라서 pgVector 헤더와 Postgres 페이지 오버헤드를 계산하기 전에도 768개 차원은 벡터당 약 3KB의 원시 데이터, 1536개 차원은 약 6KB, 3072개 차원은 약 12KB입니다.

여기에서 각 차원을 4가 아닌 2바이트(float16)로 인코딩하는 halfvec 유형의 pgVector가 사용됩니다. halfvec에 저장된 3072차원 벡터의 무게는 약 6KB입니다. 이는 정확히 클래식 vector에 저장된 1536차원 벡터의 무게입니다.

직접적이고 비직관적인 결과: Aurabase에서는 embedding_3072 열이 halfvec캐스트를 통해 쿼리되기 때문에 1536차원에서 3072차원으로 이동해도 디스크의 실제 저장 공간이 두 배가 되지 않습니다. 따라서 3072 차원의 실제 추가 비용은 주로 디스크가 아닙니다. 이는 관련 OpenAI 모델의 가격과 다음 섹션에서 자세히 설명하는 vector유형의 기본 인덱스 지원 출력입니다.

vector 유형의 pgVector는 2000차원을 초과하는 HNSW 또는 IVFFlat 인덱스 구축을 허용하지 않습니다. 따라서 3072 차원은 이 제한을 초과합니다. vector(3072) 열의 벡터 검색 쿼리는 대략적인 인덱스에 의존할 수 없으며 프로덕션에서 RAG 코퍼스 규모에서는 사용할 수 없는 완전한 순차 스캔으로 대체됩니다.

Aurabase 코드는 이 경우를 명시적으로 처리합니다. embedding_3072 열은 각 삽입 및 검색 쿼리에서 halfvec(3072)로 캐스팅됩니다. 이 유형은 pgVector가 최대 4000개 차원을 인덱싱할 수 있는 유형입니다. 열 768 및 1536은 제한에 접근하지 않기 때문에 캐스팅되지 않은 기본 vector상태로 유지됩니다.

// 3072(>2000)의 경우 HNSW는 '벡터' 유형을 인덱스하지 않고 → halfvec를 캐스팅합니다.
fn vec_query_parts(dims: usize) -> AuraResult<(&'static str, &'static str, &'static str)> {
    match dims {
        768  => Ok(("embedding_768",  "", "::vector")),
        1536 => Ok(("embedding_1536", "", "::vector")),
        3072 => Ok(("embedding_3072", "::halfvec(3072)", "::halfvec(3072)")),
        other => Err(...), // 지원되지 않는 측정기준
    }
}

이 세부 정보는 또한 [768, 1536, 3072]에 나열되지 않은 임베딩 차원이 승인되어 제대로 인덱싱되지 않고 Aurabase 측에서 명시적으로 실패하는 이유를 설명합니다. 열 이름은 항상 클라이언트가 전송한 무료 값이 아니라 항상 고정 허용 목록에서 옵니다. 이 특정 사례를 넘어서 Postgres에서 HNSW 인덱스를 구축하는 방법에 대해 더 자세히 알아보려면 HNSW 인덱스 및 Postgres 벡터 검색문서를 참조하세요.

2024년 1월부터 OpenAI의 Embeddings API는 다른 모델을 다시 호출하지 않고 반환된 벡터를 줄이는 dimensions 매개 변수를 허용합니다. 이 기술을 Matryoshka 표현 학습이라고 합니다. 모델은 유용한 정보를 벡터의 첫 번째 차원에 집중하도록 훈련되어 잘림이 갑자기 발생하기보다는 점차적으로 정밀도를 잃습니다.

OpenAI는 발표에서 구체적인 예를 통해 이 기술의 효과를 보여줍니다. text-embedding-3-large는 256차원으로만 잘렸지만 전체 크기인 1536차원에서 사용된 이전 text-embedding-ada-002의 MTEB 점수를 여전히 초과합니다(출처: OpenAI, 공식 블로그, 2024년 1월 25일). 이 특정 벤치마크에서 전체 벡터보다 성능이 더 좋은 12배 작은 벡터입니다.

let body = json!({
    "model": self.embed_model,       // 예를 들어 "텍스트 삽입-3-대형"
    "input": text,
    "dimensions": self.embed_dimensions, // 3072를 자릅니다. → 구성된 값
});

중요한 점이며 종종 오해되기도 합니다. 잘라도 청구된 가격이 줄어들지 않습니다. OpenAI는 반환된 벡터의 크기가 아닌 쿼리된 모델을 기준으로 요금을 청구합니다. 실제 비용은 입력 텍스트에 대해 수행된 계산이기 때문입니다. 따라서 text-embedding-3-large에서 1536개 차원을 요청하면 3072개 기본 차원과 동일한 비용이 듭니다(출처: OpenAI, 공식 블로그, 2024년 1월 25일). 저장 속도와 검색 속도만 변경됩니다.

이는 정확히 config/mod.rs에서 확인된 Aurabase의 기본 선택입니다. 기본적으로 구성된 모델은 text-embedding-3-large이지만 기본적으로 구성된 출력 차원은 3072가 아닌 1536입니다. 따라서 서비스는 halfvec 캐스트가 필요하지 않고 네이티브 HNSW의 인덱싱 가능한 vector 열에 유지되도록 잘린 와이드 모델의 표현에 대한 비용을 지불합니다. 3072.

1536 차원은 대부분의 RAG 또는 의미 체계 검색 프로젝트의 합리적인 시작점으로 남아 있습니다. 텍스트 임베딩-3-소형(62.3%)의 MTEB 점수는 대형 모델의 점수에 가깝고, 저장 용량은 여전히 가벼우며, 특별한 구성 없이 HNSW의 고전적인 vector 유형의 pgVector 인덱스입니다.

3072 차원은 코퍼스가 모호하거나 기술적일 때 정당화됩니다. 여기서 62.3%와 64.6% 사이의 품질 격차는 일반적인 OpenAI 벤치마크가 아닌 사용자의 쿼리에 대해 눈에 띄게 더 나은 검색 결과로 변환됩니다. OpenAI 개발자 커뮤니티 토론에 기록된 여러 팀 피드백은 이 방향을 지적합니다. 3072 차원의 이득은 사례별로 측정되므로 가정할 수 없습니다.

768 차원은 볼륨이 뉘앙스보다 우선할 때 특히 적합합니다. 즉, 저장 또는 계산 예산이 실제 제약인 대규모 코퍼스 또는 이미 768 기본 차원에 레거시 임베딩 모델을 사용하는 경우입니다.

이러한 차원 선택은 페이지 네이티브 AI문서에 포함된 더 큰 RAG 스택, 임베딩, HNSW 인덱스, 하이브리드 검색의 일부입니다.

768, 1536 및 3072 치수는 단일 축으로 분할되지 않습니다. 3072는 OpenAI가 게시한 MTEB 점수에서 이득을 얻었지만 pgVector의 기본 HNSW 지원을 떠나 차원이 궁극적으로 요청한 것과 상관없이 대형 모델의 가격을 지불합니다. 1536은 Aurabase를 포함하여 가장 일반적인 기본 잔액으로 남아 있습니다. 768은 뉘앙스보다 볼륨이 우선하는 경우를 제공합니다.

OpenAI's dimensions parameter changes the question to ask: it is no longer "which model to choose", but "which truncation to accept, for what gain measured on my corpus". Before finalizing a choice in production, test the search quality on a real sample, not just on a general benchmark. Our guide RAG pipeline with pgvector details the complete setup, from ingestion to hybrid search.