Un modelo de embedding más grande no siempre es mejor: nuestra experiencia con documentos corporativos

¿Qué son los embeddings y por qué su dimensión afecta a su negocio

Cuando un sistema de IA busca una respuesta en sus documentos, no lee cada archivo cada vez. En cambio, preconvierte cada fragmento de texto en una "huella digital" numérica: un vector. Esto es un embedding.

Imagine que cada párrafo de su contrato o instrucción se convierte en una coordenada en un espacio multidimensional. Cuando un empleado hace una pregunta, el sistema busca no por palabras clave, sino por la similitud de estas coordenadas. Es por eso que la búsqueda de IA encuentra el punto correcto en un contrato, incluso si la consulta está formulada de manera diferente al texto.

La dimensionalidad es la cantidad de números en dicho vector. El modelo text-embedding-3-small de OpenAI genera vectores con 1536 valores, mientras que text-embedding-3-large lo hace con 3072. Podría pensarse: más números significan una búsqueda más precisa. Pero en la práctica, todo es más complejo.

¿Por qué es esto importante para el negocio? Porque la dimensionalidad afecta directamente a tres cosas: la velocidad de búsqueda, la cantidad de memoria del servidor y el costo de procesamiento de documentos. Y si elige una dimensionalidad "de reserva", la pagará a diario.

Por qué las empresas pagan de más por una dimensionalidad que no necesitan

Cuando empezamos a trabajar con un nuevo cliente, una de las primeras preguntas que discutimos es qué dimensionalidad de vector será adecuada para su archivo. Y casi siempre escuchamos la misma idea: "Tomemos 3072, es mejor tener más, ¿verdad?"

Es una lógica absolutamente comprensible. Más dimensiones, parece más detalles, búsqueda más precisa. Pero en la práctica, no siempre es así. Y explicamos por qué, con números.

Según un estudio sobre la optimización del almacenamiento de vectores en sistemas RAG (arxiv, 2025), un millón de documentos con vectores de 1536 dimensiones ocupa ~6.1 GB de RAM. Con 3072 dimensiones, ocupa el doble, más de 12 GB. En la infraestructura en la nube, la RAM es un factor de costo directo cada mes.

Al mismo tiempo, el aumento en la calidad de la búsqueda es mínimo. Un análisis comparativo de modelos de embedding de 2026 muestra que el paso de 1536 a 3072 dimensiones solo aporta de 2 a 4 puntos de nDCG en benchmarks de recuperación. "La curva de calidad se aplana muy rápidamente después de 768 dimensiones para la mayoría de las tareas", a un costo de almacenamiento seis veces mayor.

Así se ve la comparación en cifras:

Para una PYME con un archivo de 50.000–200.000 documentos —el tamaño típico de un bufete de abogados, un centro médico o un distribuidor—, la diferencia de costos al año puede ascender a varios miles de dólares. Sin ninguna mejora perceptible en la calidad de las respuestas.

La conclusión es simple: "más" en el caso de los embeddings no siempre es "mejor". Es "más caro" y "más lento". Y para la mayoría de los documentos corporativos, la calidad de búsqueda con 1536 dimensiones es perfectamente suficiente.

Lo que obtuvimos con 1536 en un producto real

En AskYourDocs, hemos pasado por esta elección no en teoría, sino en un producto real con clientes reales. Compartiremos honestamente: cómo llegamos a 1536, qué nos aportó y cuáles fueron las dificultades.

Nuestro stack: Spring Boot, Java 21, PostgreSQL con la extensión pgvector, OpenRouter como gateway a LLMs. Infraestructura — Railway EU West (Ámsterdam), almacenamiento de archivos — Cloudflare R2 en jurisdicción de la UE. Para los embeddings, elegimos text-embedding-3-small con una dimensionalidad de 1536.

Por qué 1536 y no 3072

Al principio, también nos preguntamos: ¿quizás deberíamos elegir un modelo más grande, por si acaso? Pero cuando calculamos los costos reales a escala y observamos los benchmarks para nuestro tipo de documentos (contratos legales, reglamentos internos, documentos de RRHH, manuales), quedó claro: la diferencia en la calidad de búsqueda entre 1536 y 3072 para textos corporativos homogéneos en un solo idioma es mínima. Y la diferencia en costos es sustancial.

Qué cambió después de elegir 1536

Lección importante: la dimensionalidad no es la variable principal

Cuando la precisión de la búsqueda era baja (17%), el problema no era que eligiéramos 1536 en lugar de 3072. El problema era la calidad del reconocimiento OCR: los PDFs escaneados daban "basura" como entrada, y ninguna dimensionalidad de embedding podría haberlo salvado.

Después de implementar Vision OCR (GPT-4o-mini para reconocimiento con reintento automático a 90°/180°/270° para escaneos invertidos), la precisión de la búsqueda aumentó a un nivel aceptable. Con las mismas 1536 dimensiones.

Esto confirma una idea simple: la calidad de los datos de entrada es más importante que la dimensionalidad del vector. Basura en la entrada, basura en la base de datos vectorial, independientemente de si son 1536 o 3072.

Aclaración: las cifras presentadas son el resultado de nuestro despliegue específico y del tipo de documentos de nuestros clientes. Sus resultados dependerán del volumen del archivo, el idioma de los documentos y la calidad de los archivos de entrada.

Cuándo 3072 está realmente justificado, y cuándo es un gasto innecesario

Deliberadamente no decimos que 3072 sea siempre malo. Sería deshonesto. Hay escenarios donde una mayor dimensionalidad está realmente justificada, y nosotros mismos la recomendamos a los clientes cuando vemos las condiciones adecuadas. Pero hay menos casos de estos entre las PYMEs de lo que parece a primera vista.

Cuándo tiene sentido 3072

Documentos multilingües en un mismo chunk. Si en su archivo hay documentos donde en un mismo párrafo se mezclan dos idiomas, por ejemplo, una especificación técnica con términos en inglés y una descripción en español, o un contrato con citas de legislación extranjera, una dimensionalidad mayor captura mejor las relaciones semánticas entre idiomas. 1536 puede funcionar, pero con pérdidas notables en la búsqueda multilingüe.

Terminología de dominio compleja. Protocolos médicos, artículos científicos, documentación de patentes: textos donde la formulación es fundamentalmente importante y términos similares en sonido significan cosas diferentes. Aquí, una mayor dimensionalidad proporciona una mejor "resolución" entre conceptos cercanos.

Archivos de millones de documentos con búsqueda crítica para el negocio. Si tiene entre 2 y 5 millones de documentos y la pérdida de un solo resultado relevante cuesta dinero o reputación, la diferencia de 2-4 puntos nDCG en los benchmarks se vuelve notable en escenarios reales. A esta escala, vale la pena probar ambas opciones.

Hay presupuesto de infraestructura. Si la RAM y el almacenamiento no son una limitación, y el equipo está preparado para mayores costos operativos, 3072 ofrece un margen de precisión "por si acaso".

Cuándo 1536 es suficiente

Documentos homogéneos en un solo idioma. Reglamentos internos, contratos laborales, documentos de RRHH, manuales para el personal, listas de precios: este es el tipo de archivo más común entre nuestros clientes. Aquí, 1536 proporciona una calidad de búsqueda prácticamente indistinguible de 3072 en la práctica.

Archivo de hasta 500,000 documentos. La escala típica de un bufete de abogados, un centro médico o un distribuidor. Con este volumen, la diferencia entre modelos en consultas reales es ruido estadístico, no un efecto de negocio.

Despliegue en recursos limitados. Si despliega el sistema en sus propios servidores o en un entorno cerrado (Hetzner, on-premise), una huella de RAM dos veces menor con 1536 puede significar la diferencia entre uno o dos servidores en un rack.

La velocidad de respuesta es importante. Menor dimensionalidad = similarity search más rápido con el mismo hardware. Para productos donde el usuario espera una respuesta en tiempo real, esto es perceptible.

Dato curioso que desafía la intuición

Como señala la documentación oficial de OpenAI, text-embedding-3-large, reducido a 256 dimensiones, sigue superando a text-embedding-ada-002 de tamaño completo (1536) en el benchmark MTEB. Es decir, los modelos modernos han aprendido a empaquetar información de manera más eficiente, y la dimensionalidad máxima ya no es sinónimo de máxima calidad.

Es importante entender esto: ya no vivimos en la era de "más dimensiones = mejor". Vivimos en la era de la codificación eficiente, donde un modelo bien entrenado con 1536 dimensiones gana a un modelo obsoleto con 3072.

En resumen: matriz de elección

Cómo elegir la dimensión adecuada para su archivo de documentos — Checklist

Esta es la sección más práctica del artículo. Si ahora se enfrenta a la elección de un modelo de embedding para su sistema de IA, responda a las seis preguntas siguientes. Después de cada pregunta encontrará ejemplos concretos de nuestra experiencia para que pueda identificar su escenario.

Pregunta 1: ¿Cuál es el idioma de sus documentos?

Esta es la primera y más importante pregunta. La dimensión del embedding influye significativamente en la calidad de la búsqueda, especialmente en el contexto lingüístico.

• Un archivo — un idioma (todos los contratos en ucraniano, todas las instrucciones en alemán) → 1536 es suficiente. El modelo maneja bien el contenido lingüístico homogéneo.
• Documentos en diferentes idiomas, pero en archivos separados (parte del archivo en ucraniano, parte en inglés) → 1536 es suficiente, siempre que la búsqueda se realice en el idioma del documento.
• Mezcla de idiomas en un mismo fragmento (documentación técnica donde en un mismo párrafo hay términos en inglés y explicaciones en ucraniano) → vale la pena probar 3072.

Ejemplo de nuestra experiencia: un cliente — una firma de abogados ucraniana, con un archivo de 40 000 contratos en ucraniano. Eligieron 1536. La búsqueda por el contenido de las cláusulas contractuales funciona correctamente, el cliente está satisfecho con el resultado.

Otro ejemplo: un distribuidor con documentación de proveedores extranjeros — algunos archivos en inglés, otros en ucraniano, algunos con una mezcla en tablas de especificaciones. Aquí recomendamos probar ambas opciones antes de la elección final.

Pregunta 2: ¿Cuál es el tamaño del archivo?

El tamaño del archivo influye en dos factores simultáneamente: el coste de indexación (llamadas a la API) y el coste de almacenamiento de los vectores en la base de datos.

Importante: el coste de indexación es un pago único. Pero el coste de almacenamiento de los vectores en RAM es mensual. Con 3072 dimensiones, es el doble. Lea también: cómo preparar correctamente los documentos para la búsqueda con IA — la estructura de los archivos influye en el tamaño de los fragmentos y, en consecuencia, en el número de vectores en la base de datos.

Pregunta 3: ¿Qué formatos de documentos hay en su archivo?

Esta es una pregunta que a menudo se ignora al elegir la dimensión, y con razón. La calidad del texto de entrada es más importante que la dimensión del vector.

• PDF y archivos de Word digitales → el texto es limpio, la indexación es directa. 1536 ofrecerá calidad completa.
• PDF escaneados (documentos en papel escaneados) → el problema principal aquí no es la dimensión, sino la calidad del OCR. Un OCR deficiente produce "basura" en la entrada, y ninguna dimensión lo salvará. Primero, solucione el problema del reconocimiento y solo después evalúe los vectores. Más detalles al respecto en nuestro caso: cómo Vision OCR mejora la precisión de búsqueda en documentos escaneados.
• Archivo mixto (parte digital, parte escaneada) → se necesita un pipeline separado para los documentos escaneados antes de la indexación.

Ejemplo de nuestra experiencia: tuvimos un caso en el que la precisión de la búsqueda en un archivo escaneado era del 17%. Intentamos cambiar los parámetros, pero no ayudó. El problema era que el OCR producía texto distorsionado con caracteres de sustitución. Tras implementar Vision OCR, la precisión aumentó a ~50% — con las mismas 1536 dimensiones. La dimensión en este caso no fue una variable en absoluto.

Pregunta 4: ¿Cuál es el presupuesto para la infraestructura?

La pregunta no es solo sobre el coste de la API, sino sobre el coste total de mantenimiento del sistema (TCO): RAM del servidor, almacenamiento en la base de datos vectorial, coste del hosting.

Pregunta 5: ¿Qué tan crítica es la precisión de la búsqueda para su negocio?

Seamos honestos: para la mayoría de las tareas corporativas, la diferencia entre 1536 y 3072 en la práctica es imperceptible. Pero hay excepciones.

• Búsqueda en normativas internas, documentos de RR. HH., instrucciones → la precisión de 1536 es más que suficiente. El empleado encontrará el punto deseado.
• Búsqueda legal en contratos → 1536 es suficiente. Lo más crítico es el correcto fragmentado (chunking) y la calidad del OCR.
• Protocolos médicos con terminología específica → vale la pena probar 3072, especialmente si términos similares significan procedimientos diferentes.
• Búsqueda crítica para el negocio, donde un resultado omitido = riesgo financiero o legal → pruebe ambas opciones con su archivo real antes del lanzamiento.

Pregunta 6: ¿Tiene recursos para realizar pruebas?

Si tiene dudas, la respuesta más honesta es: realice una prueba A/B en su archivo real. Tome 50-100 consultas típicas de futuros usuarios, indexe una muestra de documentos con ambos modelos y compare los resultados. Esto le llevará unas horas y le dará un resultado más preciso que cualquier benchmark.

Si no tiene recursos para realizar pruebas, guíese por la siguiente tabla: