¿Por qué GPT-4 no sirve para generar embeddings en RAG?
GPT-4 es el modelo más potente de OpenAI — entonces, ¿por qué en RAG hay que usar text-embedding-3-small en lugar de GPT-4? Porque son modelos diseñados para objetivos completamente diferentes. Aquí la diferencia y qué modelo elegir para cada caso.
La lógica que confunde
La pregunta aparece de forma casi inevitable cuando se implementa el primer pipeline RAG: si GPT-4 entiende texto mejor que cualquier otro modelo, ¿por qué no uso GPT-4 para generar los embeddings? ¿Por qué necesito instalar un modelo adicional solo para eso?
La respuesta es que GPT-4 y los modelos de embedding no son versiones distintas del mismo producto — son herramientas diseñadas para objetivos completamente diferentes. Pedirle a GPT-4 que genere embeddings es como pedirle a un chef que mida la temperatura de la sala: puede que sepa hacerlo, pero no es para lo que está optimizado — y además te costaría mucho más caro.
El malentendido de fondo: asumir que "más capaz en lenguaje natural" implica "mejor para todas las tareas relacionadas con texto". Los modelos generativos y los modelos de embedding están entrenados con objetivos de pérdida distintos y producen outputs distintos.
Modelos generativos vs modelos de embedding
Modelo Generativo
Ejemplos: gpt-4o, gpt-3.5-turbo, claude-sonnet-4, llama-3
Output: Texto (tokens)
Uso principal: Chat, resumen, código, razonamiento
Modelo Embedding
Ejemplos: text-embedding-3-small, all-MiniLM-L12-v2, all-mpnet-base-v2
Output: Vector de N dims
Uso principal: Búsqueda semántica, similitud, RAG
Un modelo generativo predice el siguiente token — está entrenado para producir texto coherente y útil. Un modelo de embedding está entrenado para producir un vector que represente el significado semántico del texto de forma que textos similares produzcan vectores cercanos en el espacio vectorial.
# Modelo generativo input → "¿Cuál es la capital de Francia?" output → "La capital de Francia es París." (texto) # Modelo de embedding input → "¿Cuál es la capital de Francia?" output → [0.23, -0.87, 0.41, ..., 0.63] (vector 384 dims)
El flujo RAG usa los dos tipos
En un pipeline RAG completo, los dos tipos de modelo trabajan juntos, cada uno en su rol:
Modelo de embedding
Convierte cada fragmento del documento en un vector y lo guarda en el vector store.
Modelo de embedding
Convierte la pregunta del usuario en un vector con el mismo espacio dimensional.
Vector store
Compara el vector de la pregunta con los vectores almacenados y recupera los más cercanos.
Modelo generativo
Recibe la pregunta + los fragmentos recuperados y genera la respuesta final en lenguaje natural.
El modelo de embedding trabaja en los pasos 1 y 2. El modelo generativo solo entra en el paso 4. Son complementarios, no intercambiables.
¿Qué modelo de embedding elegir?
Para proyectos RAG con LangChain, las opciones más comunes por caso de uso:
all-MiniLM-L12-v2 (384 dims)Recomendado para empezarPrototipo rápido, coste cero, CPU. Buena calidad para la mayoría de casos de documentación técnica en inglés.
all-mpnet-base-v2 (768 dims)Siguiente pasoMayor precisión semántica cuando MiniLM no es suficiente. Más lento y más memoria, pero mejor en tareas de similitud fina.
text-embedding-3-small (1536 dims)Producción con APIProyectos en producción con API OpenAI. Muy buena calidad, soporte multilingüe sólido, coste bajo por token.
Tres puntos clave
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.