Tamaño de incrustación: ¿768, 1536 o 3072 dimensiones?

Claramente, elegir primero entre incrustación de texto-3-pequeño y incrustación de texto-3-grande equivale a elegir entre 1536 y 3072 dimensiones nativas, incluso antes de hablar de truncamiento. La siguiente tabla resume los hechos verificables en los tres niveles que pgvector reconoce de forma nativa en el lado de la indexación y esa ruta de Aurabase.

Fuentes: OpenAI, blog oficial “Nuevos modelos de integración y actualizaciones de API”, 25 de enero de 2024 (puntuaciones MTEB y precios de lanzamiento, consulte la página de precios actual antes de usarlo); aura-ai/src/embeddings/mod.rs, Aurabase (soporte de índices y columnas, verificado el 24 de agosto de 2026).

Una incrustación se almacena como una matriz de números de punto flotante. En pgvector, el tipo clásico vector codifica cada dimensión en 4 bytes (float32): por lo tanto, 768 dimensiones pesan alrededor de 3 KB de datos sin procesar por vector, 1536 dimensiones alrededor de 6 KB y 3072 dimensiones alrededor de 12 KB, incluso antes de contar el encabezado de pgvector y la sobrecarga de la página de Postgres.

Aquí es donde entra en juego el tipo halfvec de pgvector, que codifica cada dimensión en 2 bytes (float16) en lugar de 4. Un vector de 3072 dimensiones almacenado en halfvec pesa alrededor de 6 KB: exactamente el peso de un vector de 1536 dimensiones almacenado en el clásico vector.

Consecuencia directa y poco intuitiva: en Aurabase, pasar de 1536 a 3072 dimensiones no duplica el almacenamiento real en disco, ya que la columna embedding_3072 se consulta mediante una conversión halfvec. Por lo tanto, el costo adicional real de 3072 dimensiones no es principalmente el disco: es el precio del modelo OpenAI asociado y la salida del soporte de índice nativo del tipo vector, que se detalla en la siguiente sección.

El tipo vector de pgvector no permite construir un índice HNSW o IVFFlat más allá de 2000 dimensiones. Por lo tanto, 3072 dimensiones superan este límite: ninguna consulta de búsqueda vectorial en una columna vector(3072) puede basarse en un índice aproximado, sino que recurre a un escaneo secuencial completo, inutilizable en la escala de un corpus RAG en producción.

El código de Aurabase maneja este caso explícitamente: la columna embedding_3072 se convierte en halfvec(3072) en cada consulta de inserción y búsqueda, un tipo que pgvector puede indexar hasta 4000 dimensiones. Las columnas 768 y 1536 siguen siendo nativas vector, sin convertir, ya que no se acercan al límite.

// Para 3072 (>2000), HNSW no indexa el tipo `vector` → emite 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(...), // dimensión no soportada
    }
}

Este detalle también explica por qué una dimensión de incrustación que no figura en [768, 1536, 3072] falla explícitamente en el lado de Aurabase, en lugar de ser aceptada y luego mal indexada: el nombre de la columna siempre proviene de una lista de permitidos fija, nunca de un valor gratuito enviado por el cliente. Para profundizar en la creación de un índice HNSW en Postgres más allá de este caso específico, consulte nuestro artículo Índice HNSW y búsqueda vectorial de Postgres.

A partir de enero de 2024, la API Embeddings de OpenAI acepta un parámetro dimensions que acorta el vector devuelto sin volver a invocar un modelo diferente. La técnica se llama Matryoshka Representation Learning: el modelo está entrenado para concentrar información útil en las primeras dimensiones del vector, de modo que un truncamiento pierda precisión de forma gradual y no abrupta.

OpenAI ilustra la eficacia de esta técnica con un ejemplo específico en su anuncio: text-embedding-3-large, truncado a solo 256 dimensiones, aún supera la puntuación MTEB del antiguo text-embedding-ada-002 utilizado en su tamaño completo de 1536 dimensiones (fuente: OpenAI, blog oficial, 25 de enero de 2024). Un vector 12 veces más pequeño que funciona mejor que un vector completo en este punto de referencia específico.

let body = json!({
    "model": self.embed_model,       // por ej. "incrustación de texto-3-grande"
    "input": text,
    "dimensions": self.embed_dimensions, // trunca 3072 → el valor configurado
});

Un punto importante, y a menudo mal entendido: truncar no reduce el precio cobrado. OpenAI cobra según el modelo consultado, no el tamaño del vector devuelto, ya que el costo real es el cálculo realizado en el texto de entrada. Por lo tanto, solicitar 1536 dimensiones de text-embedded-3-large cuesta el mismo precio que sus 3072 dimensiones nativas (fuente: OpenAI, blog oficial, 25 de enero de 2024); sólo cambian la velocidad de almacenamiento y búsqueda.

Esta es precisamente la elección predeterminada de Aurabase, verificada en config/mod.rs: el modelo configurado por defecto es text-embedding-3-large, pero la dimensión de salida configurada por defecto es 1536, no 3072. Por lo tanto, el servicio paga por la representación del modelo ancho, truncado para permanecer en una columna indexable vector en HNSW nativo, sin la conversión halfvec requerida a 3072.

1536 dimensiones sigue siendo el punto de partida razonable para la mayoría de los proyectos RAG o de búsqueda semántica: la puntuación MTEB de text-embedding-3-small (62,3%) sigue siendo cercana a la del modelo grande, el almacenamiento sigue siendo ligero y el tipo clásico vector de índices pgvector en HNSW sin ninguna configuración particular.

3072 dimensiones se justifica cuando el corpus es ambiguo o técnico, donde la brecha de calidad entre el 62,3% y el 64,6% se traduce en resultados de búsqueda visiblemente mejores en sus propias consultas, no en el punto de referencia general de OpenAI. Varios comentarios del equipo registrados en las discusiones de la comunidad de desarrolladores de OpenAI apuntan en esta dirección: la ganancia de 3072 dimensiones se mide caso por caso, no se puede asumir.

768 dimensiones es especialmente adecuado cuando el volumen tiene prioridad sobre los matices: un corpus grande donde el presupuesto de almacenamiento o cálculo es la restricción real, o el uso de un modelo de incrustación heredado que ya está en 768 dimensiones nativas.

Esta elección de dimensión es parte de una pila RAG más grande, incrustaciones, índice HNSW y búsqueda híbrida, que nuestra página Native AIdocumenta.

Las dimensiones 768, 1536 y 3072 no están divididas en un solo eje. 3072 gana en la puntuación MTEB publicada por OpenAI, pero deja el soporte HNSW nativo de pgvector y paga el precio del modelo grande, cualquiera que sea la dimensión finalmente solicitada. 1536 sigue siendo el saldo predeterminado más común, incluso en Aurabase. 768 sirve para casos en los que el volumen tiene prioridad sobre los matices.

El parámetro dimensions de OpenAI cambia la pregunta a formular: ya no es "qué modelo elegir", sino "qué truncamiento aceptar, para qué ganancia medida en mi corpus". Antes de finalizar una elección en producción, pruebe la calidad de la búsqueda en una muestra real, no sólo en un punto de referencia general. Nuestra guía RAG pipeline con pgvector detalla la configuración completa, desde la ingesta hasta la búsqueda híbrida.