Tamanho de incorporação: dimensões 768, 1536 ou 3072?

Claramente, escolher entre text-embedding-3-small e text-embedding-3-large equivale primeiro a escolher entre 1536 e 3072 dimensões nativas, antes mesmo de falar em truncamento. A tabela abaixo resume os fatos verificáveis ​​nos três níveis que o pgvector reconhece nativamente no lado da indexação e na rota do Aurabase.

Fontes: OpenAI, blog oficial “Novos modelos de incorporação e atualizações de API”, 25 de janeiro de 2024 (pontuações MTEB e preços de lançamento, verifique na página de preços atual antes de usar); aura-ai/src/embeddings/mod.rs, Aurabase (suporte a colunas e índices, verificado em 24 de agosto de 2026).

Uma incorporação é armazenada como uma matriz de números de ponto flutuante. No pgvector, o tipo clássico vector codifica cada dimensão em 4 bytes (float32): 768 dimensões, portanto, pesam cerca de 3 KB de dados brutos por vetor, 1536 dimensões em torno de 6 KB e 3072 dimensões em torno de 12 KB, mesmo antes de contar o cabeçalho pgvector e a sobrecarga da página Postgres.

É aqui que entra o tipo halfvec de pgvector, que codifica cada dimensão em 2 bytes (float16) em vez de 4. Um vetor de 3072 dimensões armazenado em halfvec pesa cerca de 6 KB: exatamente o peso de um vetor de 1536 dimensões armazenado no clássico vector.

Consequência direta e não intuitiva: no Aurabase, passar de 1536 para 3072 dimensões não dobra o armazenamento real em disco, uma vez que a coluna embedding_3072 é consultada por meio de uma conversão halfvec. O custo adicional real das dimensões 3072 não é, portanto, principalmente o disco: é o preço do modelo OpenAI associado e a saída do suporte de índice nativo do tipo vector, detalhado na seção seguinte.

O tipo vector de pgvector não permite construir um índice HNSW ou IVFFlat além de 2.000 dimensões. As dimensões 3072, portanto, excedem esse limite: nenhuma consulta de pesquisa vetorial em uma coluna vector(3072) pode contar com um índice aproximado, ela recorre a uma varredura sequencial completa, inutilizável na escala de um corpus RAG em produção.

O código Aurabase trata esse caso explicitamente: a coluna embedding_3072 é convertida em halfvec(3072) em cada inserção e consulta de pesquisa, um tipo que o pgvector pode indexar até 4.000 dimensões. As colunas 768 e 1536 permanecem nativas vector, não convertidas, pois não se aproximam do limite.

// Para 3072 (>2000), HNSW não indexa o tipo `vector` → converte 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(...), // dimensão não suportada
    }
}

Este detalhe também explica por que uma dimensão de incorporação não listada em [768, 1536, 3072] falha explicitamente no lado do Aurabase, em vez de ser aceita e depois mal indexada: o nome da coluna sempre vem de uma lista de permissões fixa, nunca de um valor livre enviado pelo cliente. Para se aprofundar na construção de um índice HNSW no Postgres além deste caso específico, consulte nosso artigo Índice HNSW e pesquisa de vetor Postgres.

A partir de janeiro de 2024, a API Embeddings da OpenAI aceita um parâmetro dimensions que encurta o vetor retornado sem invocar novamente um modelo diferente. A técnica é chamada de Aprendizagem de Representação Matryoshka: o modelo é treinado para concentrar informações úteis nas primeiras dimensões do vetor, de modo que um truncamento perca precisão gradualmente, e não abruptamente.

A OpenAI ilustra a eficácia desta técnica com um exemplo específico em seu anúncio: text-embedding-3-large, truncado para apenas 256 dimensões, ainda excede a pontuação MTEB do antigo text-embedding-ada-002 usado em seu tamanho total de 1.536 dimensões (fonte: OpenAI, blog oficial, 25 de janeiro de 2024). Um vetor 12 vezes menor com desempenho melhor que um vetor completo neste benchmark específico.

let body = json!({
    "model": self.embed_model,       // por exemplo "incorporação de texto-3-grande"
    "input": text,
    "dimensions": self.embed_dimensions, // trunca 3072 → o valor configurado
});

Ponto importante, e muitas vezes mal compreendido: truncar não reduz o preço cobrado. A OpenAI cobra com base no modelo consultado, não no tamanho do vetor retornado, uma vez que o custo real é o cálculo realizado no texto de entrada. Solicitar 1.536 dimensões de text-embedding-3-large custa, portanto, o mesmo preço que suas 3.072 dimensões nativas (fonte: OpenAI, blog oficial, 25 de janeiro de 2024); apenas a velocidade de armazenamento e pesquisa muda.

Esta é justamente a escolha padrão do Aurabase, verificada em config/mod.rs: o modelo configurado por padrão é text-embedding-3-large, mas a dimensão de saída configurada por padrão é 1536, não 3072. O serviço, portanto, paga pela representação do modelo amplo, truncado para permanecer em uma coluna vector indexável em HNSW nativo, sem o cast halfvec necessário para 3072.

As dimensões 1536 continuam sendo o ponto de partida razoável para a maioria dos projetos RAG ou de pesquisa semântica: a pontuação MTEB de text-embedding-3-small (62,3%) permanece próxima da do modelo grande, o armazenamento permanece leve e o tipo clássico vector de índices pgvector em HNSW sem qualquer configuração específica.

3.072 dimensões justifica-se quando o corpus é ambíguo ou técnico, onde a lacuna de qualidade entre 62,3% e 64,6% se traduz em resultados de pesquisa visivelmente melhores em suas próprias consultas, e não no benchmark geral OpenAI. Vários feedbacks da equipe registrados nas discussões da comunidade de desenvolvedores OpenAI apontam nesta direção: o ganho de 3.072 dimensões é medido caso a caso, não pode ser assumido.

As dimensões 768 são especialmente adequadas quando o volume tem precedência sobre as nuances: um corpus grande onde o orçamento de armazenamento ou cálculo é a restrição real, ou o uso de um modelo de incorporação legado já em dimensões nativas 768.

Essa escolha de dimensão faz parte de uma pilha RAG maior, embeddings, índice HNSW, pesquisa híbrida, que nossa página Native AIdocumenta.

As dimensões 768, 1536 e 3072 não são divididas em um único eixo. 3072 ganha na pontuação MTEB publicada pela OpenAI, mas deixa o suporte HNSW nativo do pgvector e paga o preço do modelo grande, qualquer que seja a dimensão solicitada. 1536 continua sendo o saldo padrão mais comum, inclusive na Aurabase. 768 atende casos em que o volume tem precedência sobre as nuances.

O parâmetro dimensions da OpenAI muda a questão a ser feita: não é mais “qual modelo escolher”, mas “qual truncamento aceitar, para qual ganho medido em meu corpus”. Antes de finalizar uma escolha na produção, teste a qualidade da pesquisa em uma amostra real, não apenas em um benchmark geral. Nosso guia pipeline RAG com pgvector detalha a configuração completa, desde a ingestão até a pesquisa híbrida.