Casi todas las veces que alguien me dice "necesitamos fine-tuning", en realidad necesita mejor contexto. El fine-tuning es la primera palabra que sale porque suena a la solución seria, la que "enseña" al modelo. Pero en producto he cambiado muy pocos comportamientos con fine-tuning y muchísimos con un buen prompt o con RAG bien montado. La regla que me ha funcionado es empezar por lo barato y reversible, y solo subir de escalón cuando el escalón anterior demuestra estar techado. Este artículo es ese árbol de decisión, con los trade-offs que acepto en cada rama y las señales que me dicen cuándo he elegido mal.
Primero pregunto: ¿es un problema de conocimiento o de comportamiento?
Esta es la bifurcación que ordena todo lo demás. Si el modelo falla porque no sabe algo —datos de tu dominio, documentación interna, hechos posteriores a su corte de entrenamiento— es un problema de conocimiento, y el conocimiento se inyecta por contexto, no se hornea en pesos. Ahí RAG es la respuesta por defecto.
Si el modelo sabe lo que necesita pero responde con el formato, el tono o la estructura equivocados de forma consistente, es un problema de comportamiento. Y el comportamiento sí es candidato a fine-tuning… pero solo después de que el prompting se quede corto, que es más tarde de lo que la gente cree.
Confundir estas dos ramas es el error más caro que veo. Nadie arregla con fine-tuning que el modelo no conozca tu catálogo de productos: lo entrenas hoy y mañana el catálogo cambió. Y nadie arregla con RAG que el modelo se niegue a devolver JSON limpio: por muchos documentos que le metas, el problema es de forma, no de datos.
Prompting: el escalón que casi siempre subestimo
Mi punto de partida es siempre prompting, porque es el único cambio que despliego en minutos y revierto en segundos. Antes de tocar nada más, exprimo instrucciones claras, ejemplos few-shot representativos y una estructura de salida explícita. En JXBS, buena parte de lo que parecía pedir un modelo afinado se resolvió con tres ejemplos bien elegidos en el prompt y un esquema de salida estricto.
El coste de esta rama es el contexto: cada ejemplo que metes ocupa tokens que pagas en cada llamada, y un prompt de 20 ejemplos se vuelve caro y lento a escala. Ese es exactamente el síntoma de que quizá toca subir de escalón: cuando necesitas tantos ejemplos que el prompt es la mitad de tu factura, el patrón ya está ahí y puede valer la pena hornearlo.
💡 Si no has intentado resolverlo con prompting durante al menos una tarde, no tienes datos para justificar fine-tuning. "Probamos un prompt y no salió" no es prompting, es una anécdota.
RAG: para conocimiento que cambia y debe ser citable
Cuando el problema es de conocimiento, RAG gana casi siempre por una razón que va más allá de lo técnico: la trazabilidad. Un sistema RAG puede decirte de qué documento salió la respuesta. Un modelo afinado te da la respuesta desde dentro de sus pesos, sin fuente, y cuando alucina no tienes dónde mirar.
// El conocimiento vive fuera del modelo y se actualiza sin reentrenar
const contexto = await buscarFragmentos(pregunta, { topK: 5 });
const respuesta = await llm.completar({
system: 'Responde solo con la información de <contexto>. Si no está, dilo.',
contexto,
pregunta,
});
El trade-off que acepto con RAG es operativo: ahora mantengo un pipeline de ingesta, embeddings, un índice vectorial y una estrategia de chunking. Es más infraestructura que un prompt. A cambio, actualizo el conocimiento cambiando documentos, no reentrenando, y eso en un dominio que se mueve vale oro.
Fine-tuning: el último escalón, y sé por qué subo
Llego a fine-tuning solo cuando se cumplen tres cosas a la vez: el comportamiento que quiero es estable y repetido, prompting me lo da pero a un coste de tokens insostenible, y tengo suficientes ejemplos reales de calidad para entrenar. Si me falta cualquiera de las tres, no subo.
Lo que compro con fine-tuning es un modelo que hace lo que quiero con un prompt corto, más barato y más rápido por llamada. Lo que pago es rigidez: cada cambio de comportamiento es un reentrenamiento, el dataset se convierte en un activo que hay que versionar y cuidar, y he introducido un artefacto que puede quedar obsoleto en silencio. El fine-tuning no elimina RAG, además: lo más potente que he montado combina un modelo afinado en cómo responder con RAG para qué saber.
El error de saltarse escalones
El antipatrón que más me ha costado es empezar por el final. Equipos que montan fine-tuning para un problema que un prompt resolvía, y acaban con un modelo caro de mantener que no rinde mejor que la línea base que nunca midieron. Empezar barato no es ser conservador: es generar la evidencia que justifica el siguiente paso. Cuando por fin haces fine-tuning tras agotar prompting y RAG, sabes exactamente qué estás comprando y por qué. Esa claridad es la diferencia entre una decisión de ingeniería y una compra por moda.
