text-embedding-3-small es el modelo de embeddings más pequeño y económico de OpenAI, lanzado el 25 de enero de 2024 junto con el más grande text-embedding-3-large. Un modelo de embeddings convierte texto en un vector de números de longitud fija que representa su significado, en lugar de generar texto nuevo — dos pasajes con un significado similar producen vectores que quedan próximos entre sí en ese espacio numérico. Esa propiedad sustenta 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 clasificar pasajes almacenados por relevancia frente a una consulta antes de que un modelo de lenguaje los vea siquiera.
Para qué está construido
Por defecto, text-embedding-3-small produce un vector de 1.536 dimensiones. En el propio benchmark MTEB de OpenAI — una suite de evaluación estándar que cubre recuperación, clasificación y agrupación — puntúa 62,3, por delante del 61,0 del modelo más antiguo text-embedding-ada-002 a pesar de que ada-002 usa las mismas 1.536 dimensiones. Dicho de otro modo, esta generación mejoró la calidad manteniendo el mismo tamaño de vector, lo cual es una mejora directa para cualquiera que todavía use la generación anterior.
La longitud máxima de entrada es de 8.192 tokens por solicitud, igual que en el modelo más grande. La salida es solo embedding: sin chat, sin generación, sin uso de herramientas — una única llamada toma una cadena de texto y devuelve un array de tamaño fijo de números en coma flotante.
El parámetro dimensions
Igual que su hermano mayor, text-embedding-3-small soporta un parámetro dimensions que trunca el vector de salida a una longitud más corta sin volver a generar el embedding a través de otro modelo. Acortar el vector reduce el almacenamiento en una base de datos vectorial y acelera las comparaciones de similitud en el momento de la consulta, lo cual resulta útil cuando el índice es lo bastante grande como para que el almacenamiento y la latencia de búsqueda empiecen a dominar el coste — una situación habitual una vez que un corpus alcanza los millones de documentos.
Dónde se gana su lugar
El argumento principal a favor de text-embedding-3-small es el volumen: recuentos altos de documentos, reindexación frecuente y un patrón de consultas donde los presupuestos de latencia son ajustados. Su menor coste por llamada y su tamaño de vector por defecto más pequeño se acumulan a escala — cada documento indexado y cada consulta convertida en embedding conlleva un coste real y continuo de almacenamiento y cómputo, y para corpus grandes eso suma independientemente de lo buena que sea la calidad por embedding.
También es una opción por defecto razonable para tareas de recuperación que no son adversarias ni de grano fino: búsqueda general de documentos, coincidencia de preguntas frecuentes, deduplicación de contenido casi idéntico y canalizaciones RAG donde el paso de recuperación necesita ser "suficientemente bueno" más que máximamente preciso, porque el modelo de lenguaje que lee los pasajes recuperados puede tolerar algo de ruido en lo que se recupera.
Dónde se muestran los límites
La brecha MTEB con text-embedding-3-large es real, aunque modesta, y tiende a ampliarse en las tareas de recuperación más difíciles — distinguir entre pasajes estrechamente relacionados, trabajar en idiomas menos comunes o clasificar con precisión muchos candidatos similares. Para un sistema RAG que de forma medible está perdiendo pasajes relevantes, o una función de búsqueda que devuelve resultados casi correctos, la solución suele ser cambiar al modelo más grande en lugar de seguir ajustando el más pequeño.
Alternativas que vale la pena comparar
text-embedding-3-large es la ruta de mejora natural cuando el cuello de botella es la calidad de recuperación, no el coste. text-embedding-ada-002 sigue disponible pero este modelo lo supera en calidad con el mismo tamaño de vector, así que hay pocos motivos para elegirlo en un trabajo nuevo. Fuera de OpenAI, varios proveedores ofrecen modelos de embeddings de propósito general comparables; probar la calidad de recuperación frente a una muestra representativa de tu propio corpus es una guía mejor que solo las puntuaciones de benchmark, ya que el rendimiento de los embeddings no siempre se traslada de forma uniforme entre dominios.