Una aplicación necesita responder con políticas internas que cambian cada semana. Otra debe clasificar reclamos siempre con el mismo esquema. Una tercera analiza un contrato completo que cabe en la ventana de contexto. Las tres usan modelos de lenguaje, pero no necesitan la misma arquitectura.
La comparación suele reducirse a RAG vs. fine-tuning. Ese atajo mezcla problemas distintos. RAG sirve para recuperar conocimiento externo; el fine-tuning modifica el comportamiento del modelo mediante ejemplos; el contexto largo permite enviar más información en cada solicitud. Antes de elegir, conviene definir qué tiene que cambiar: el conocimiento disponible, la conducta del modelo o el material que debe leer en una tarea puntual.
Qué resuelve cada alternativa
Prompting y ejemplos en contexto
Es el punto de partida. Las instrucciones y unos pocos ejemplos pueden fijar formato, tono o criterios sin agregar infraestructura ni entrenar un modelo. Funciona bien cuando la tarea es clara, el volumen de variantes es manejable y el modelo base ya tiene la capacidad necesaria.
Su límite aparece cuando el prompt crece, los ejemplos se contradicen o el comportamiento sigue siendo inestable. Antes de saltar al fine-tuning, conviene probar si el problema está en instrucciones ambiguas, ejemplos pobres o un modelo base inadecuado.
Contexto largo
Si el corpus es acotado, cambia poco y cabe completo en la solicitud, enviarlo al modelo puede ser más simple que construir un sistema de recuperación. Es útil para resumir un contrato, comparar un conjunto cerrado de documentos o analizar una base de código delimitada.
La simplicidad no elimina los costos. Cada consulta puede volver a procesar una gran cantidad de tokens, salvo que exista caching. Tampoco garantiza que el modelo encuentre todas las piezas relevantes: la documentación de Google sobre contexto largo advierte que el rendimiento puede caer cuando hay que recuperar múltiples datos dispersos dentro del mismo contexto.
RAG
Retrieval-augmented generation busca fragmentos relevantes en una fuente externa y los agrega al prompt antes de generar la respuesta. La ventaja principal es operativa: los documentos pueden actualizarse sin volver a entrenar el modelo. También permite conservar el vínculo entre una respuesta y el material recuperado.
En una implementación habitual, los archivos se dividen en fragmentos, se convierten en embeddings y se guardan en un índice. Ante una consulta, el sistema recupera los fragmentos más cercanos, arma el contexto y llama al modelo. La guía de Retrieval de OpenAI describe ese flujo con vector stores; la arquitectura de Microsoft muestra que la calidad depende de muchas decisiones: ingestión, chunking, metadatos, embeddings, búsqueda y evaluación.
RAG no elimina las alucinaciones. Puede recuperar un fragmento incorrecto, omitir el documento necesario o entregar contexto insuficiente. Un filtro de permisos mal aplicado, metadatos incompletos o un chunking que separe una condición de su excepción también pueden degradar la búsqueda. El modelo, además, puede interpretar mal una fuente correcta. Por eso hay que medir la recuperación y la respuesta final por separado.
Fine-tuning
El fine-tuning supervisado entrena al modelo con pares de entrada y salida que representan el comportamiento deseado. Puede mejorar clasificación, formato, traducción especializada o consistencia en una tarea repetitiva. La documentación de OpenAI lo describe como entrenamiento con ejemplos correctos y exige evaluar el resultado contra el modelo base.
No es una buena base de conocimiento para información que cambia con frecuencia. Actualizar precios, políticas o catálogo mediante fine-tuning obliga a preparar datos y volver a entrenar. Además, el modelo no ofrece por sí solo una referencia al documento que sostiene cada respuesta. La disponibilidad también depende del proveedor y del modelo. Al corte de esta guía, la documentación de OpenAI indicaba que su plataforma de fine-tuning estaba cerrándose para usuarios nuevos, un ejemplo de por qué la decisión no debería quedar atada a una sola plataforma.
Matriz de decisión
| Necesidad principal | Opción inicial | Motivo |
|---|
|—|—|—|
| Responder con documentos que cambian seguido | RAG | Actualiza la fuente sin reentrenar y permite recuperar evidencia |
|---|---|---|
| Analizar un corpus cerrado que cabe en una solicitud | Contexto largo | Reduce infraestructura y mantiene el documento completo disponible |
| Mejorar la consistencia de un formato o conducta especializada | Fine-tuning | Entrena el patrón con ejemplos representativos |
| Resolver una tarea simple con pocos ejemplos | Prompting | Es la alternativa más rápida y reversible |
| Combinar conocimiento actualizado con conducta especializada | RAG + fine-tuning | Permite trabajar por separado la recuperación y el comportamiento del modelo |
La tabla sirve como punto de partida, no como veredicto. La elección real depende de seis variables.
Seis preguntas antes de construir
1. ¿El problema es conocimiento o comportamiento?
Si el sistema falla porque no conoce una política reciente, necesitás una fuente actualizable. Si conoce los datos pero responde con el formato equivocado o clasifica mal una categoría estable, el problema puede ser de comportamiento. RAG y fine-tuning no son sustitutos perfectos porque intervienen en capas distintas.
2. ¿Con qué frecuencia cambian los datos?
Un catálogo diario, documentación viva o normativa interna favorecen RAG. Un conjunto de ejemplos que define una tarea estable puede justificar fine-tuning. Un documento único o un corpus que se renueva pocas veces puede resolverse con contexto largo.
3. ¿La respuesta necesita evidencia visible?
Cuando una persona debe verificar la fuente, RAG ofrece una ruta más clara. Pero mostrar una cita no prueba que la respuesta sea correcta: hay que comprobar que el fragmento recuperado sostenga la afirmación y que los permisos impidan exponer material que el usuario no puede ver.
4. ¿Cuál es el costo por tarea aceptada?
Contexto largo aumenta tokens de entrada. RAG suma almacenamiento, embeddings, búsquedas y más componentes operativos. Fine-tuning tiene costo de preparación, entrenamiento y mantenimiento. Compará el costo total por resultado útil, no solo el precio de una llamada al modelo.
5. ¿Qué latencia tolera el producto?
RAG agrega al menos una etapa de búsqueda. Un contexto enorme también puede ralentizar la respuesta. Un modelo ajustado puede reducir instrucciones repetidas, aunque esa ventaja debe medirse. Si la interacción es en tiempo real, probá la cadena completa con tráfico representativo.
6. ¿El equipo puede operar la solución?
Una demo de RAG puede montarse rápido; sostenerla exige controlar calidad de documentos, reindexación, permisos, observabilidad y regresiones. Fine-tuning requiere datasets limpios, ejemplos consistentes y evaluaciones. La arquitectura más sofisticada no sirve si el equipo no puede mantenerla.
Cuándo conviene combinar RAG y fine-tuning
El enfoque híbrido tiene sentido cuando el sistema necesita dos cosas a la vez: recuperar conocimiento fresco y ejecutar una tarea especializada. Por ejemplo, un asistente puede buscar la versión vigente de una política con RAG y usar un modelo ajustado para devolver una salida estructurada que alimente otro sistema.
La comparación de AWS contempla esa combinación, pero agregar capas también agrega puntos de falla. Si el prompt y RAG ya alcanzan el nivel esperado, entrenar el modelo puede ser complejidad sin retorno.
Un experimento mínimo para decidir
No elijas arquitectura por una demo aislada. Prepará un conjunto pequeño pero representativo de consultas, incluidas preguntas sin respuesta, documentos extensos y casos con permisos diferentes. Después compará tres configuraciones:
- modelo base con un prompt claro y ejemplos;
- contexto largo o RAG, según el tamaño y la frecuencia de actualización del corpus;
- fine-tuning solo si persiste un fallo de comportamiento que los ejemplos pueden enseñar.
Medí calidad, evidencia, latencia, costo y esfuerzo operativo. Si usás RAG, separá la precisión de recuperación de la calidad de la respuesta. Si usás fine-tuning, reservá ejemplos que no participaron del entrenamiento para comparar contra el modelo base.
La decisión termina donde empieza la validación del producto. Una vez elegida la arquitectura, necesitás evaluar el piloto de IA antes de llevarlo a producción con casos reales, criterios definidos y límites operativos.
Regla práctica
Empezá por la opción más simple que pueda resolver el problema. Usá prompting para instrucciones y ejemplos; contexto largo para un corpus cerrado y manejable; RAG para conocimiento actualizable y recuperable; fine-tuning para conducta estable que pueda enseñarse con buenos ejemplos. Combiná técnicas solo cuando una prueba muestre que una sola capa no alcanza.