text-embedding-3-large es el modelo de embeddings de mayor calidad de OpenAI, lanzado el 25 de enero de 2024 junto con el más pequeño text-embedding-3-small. Un modelo de embeddings no genera texto — convierte un fragmento de texto en un vector de números de longitud fija que captura su significado, de modo que dos fragmentos de texto con un significado similar acaban como vectores que quedan próximos entre sí en ese espacio numérico. Esa propiedad es lo que hace útiles los embeddings para la búsqueda semántica, la agrupación (clustering), la deduplicación, la recomendación y la generación aumentada por recuperación (RAG), donde un sistema necesita encontrar los pasajes más relevantes para una consulta antes de pasárselos a un modelo de lenguaje.
Qué gana "large" sobre "small"
Por defecto, text-embedding-3-large produce un vector de 3.072 dimensiones, frente a las 1.536 de text-embedding-3-small. En el propio benchmark MTEB de OpenAI, una suite estándar para evaluar la calidad de embeddings en tareas de recuperación, clasificación y agrupación, large puntúa 64,6 frente al 62,3 de small — una brecha de calidad real pero no enorme. El modelo más grande capta más matices por embedding, lo cual tiende a importar más en las tareas de recuperación más difíciles: distinguir entre documentos estrechamente relacionados, trabajar en dominios o idiomas menos comunes, o clasificar muchos candidatos similares entre sí.
El parámetro dimensions
Ambos modelos soportan un parámetro dimensions que acorta el vector de salida truncándolo, sin necesidad de volver a generar el embedding del texto a través de un modelo distinto. Según OpenAI, un vector de text-embedding-3-large acortado a 256 dimensiones sigue superando al modelo más antiguo y sin acortar text-embedding-ada-002 en sus 1.536 dimensiones nativas. Esto importa a nivel operativo: un vector más corto ocupa menos almacenamiento en una base de datos vectorial y es más barato y rápido de comparar en el momento de la consulta, así que el parámetro dimensions es una palanca real para cambiar una pequeña cantidad de calidad de recuperación por un tamaño de índice y una latencia de búsqueda considerablemente menores — sin cambiar de modelo ni rediseñar la canalización.
Bajo el capó
La longitud máxima de entrada es de 8.192 tokens por solicitud. La salida es solo embedding — no hay generación de texto, ni interfaz de chat, ni uso de herramientas. El modelo recibe texto y devuelve un vector, y nada más, lo que mantiene pequeña su superficie de integración: una única llamada a la API toma una cadena de texto y devuelve un array de tamaño fijo de números en coma flotante.
Cuándo elegir large sobre small
Recurre a text-embedding-3-large cuando la calidad de recuperación sea el cuello de botella: un sistema RAG que pierde pasajes relevantes, una función de búsqueda que devuelve resultados casi correctos en lugar del resultado adecuado, o una tarea de agrupación donde importan las distinciones finas entre elementos similares. También es la opción por defecto más defendible al trabajar en idiomas menos comunes o dominios especializados, donde un espacio de embeddings más pequeño tiene menos margen para representar matices.
Para indexación de volumen muy alto — millones de documentos, o una carga de trabajo donde la latencia de consulta y el coste de almacenamiento dominan el diseño — text-embedding-3-small, o un embedding large truncado mediante el parámetro dimensions, suele ser el punto de partida más práctico. La brecha MTEB entre ambos modelos es real pero modesta, así que vale la pena probar ambos con una muestra representativa de tus propios datos en lugar de recurrir a large por defecto solo por asumir que más grande es mejor.
Alternativas que vale la pena comparar
text-embedding-ada-002 sigue disponible como el modelo de embeddings de la generación anterior de OpenAI, pero ambos modelos actuales lo superan en calidad incluso con una fracción de su dimensionalidad, así que hay pocos motivos para elegirlo en un trabajo nuevo. Fuera de la propia gama de OpenAI, varios otros proveedores ofrecen modelos de embeddings de texto de propósito general con un posicionamiento comparable; la elección correcta suele depender de probar la calidad de recuperación en tu propio corpus más que solo de las puntuaciones de benchmark, ya que el rendimiento en MTEB no siempre se traslada limpiamente a un dominio específico.