Fine-tuning o RAG: cómo elegir sin quemar presupuesto

La pregunta está mal planteada

“¿Fine-tuning o RAG?” es la pregunta que llega en cada arranque de proyecto, y casi siempre es la equivocada. Presupone que son dos caminos hacia el mismo sitio y que hay que elegir uno. No lo son. Resuelven problemas distintos, y muchas veces la respuesta correcta es “los dos” o, más a menudo de lo que parece, “ninguno todavía”.

La forma útil de verlo es separar dos cosas que el lenguaje natural mezcla: lo que el modelo sabe y cómo el modelo se comporta. RAG toca lo primero. El fine-tuning toca lo segundo. Cuando alguien intenta arreglar un problema de conocimiento con fine-tuning, o un problema de forma con RAG, el resultado es caro y frágil.

Qué cambia cada uno

RAG no modifica el modelo en absoluto. Deja los pesos intactos y le acerca contexto relevante en el momento de la pregunta: recuperas los fragmentos que hacen falta, los metes en el prompt y el modelo responde con esa información delante. Es memoria externa, consultable y actualizable. Si mañana cambia un precio, actualizas el documento y el sistema ya responde con el dato nuevo. No hay reentrenamiento.

El fine-tuning sí modifica el modelo: ajusta sus pesos con ejemplos hasta que interioriza un patrón de comportamiento. No sirve para meterle datos frescos —eso lo hace fatal y se le olvida—, sirve para fijar una forma de responder: un formato de salida estricto, un tono de marca, una taxonomía de clasificación, una manera de razonar sobre un dominio muy concreto. Es enseñar un oficio, no dictar un temario.

La regla que evita el 90 % de los errores: si la respuesta correcta cambia con el tiempo, es conocimiento y va en RAG. Si lo que cambia es la manera de responder y esa manera es estable, es comportamiento y puede ir en fine-tuning.

El coste real no es el que crees

El motivo por el que tanta gente se equivoca es que calcula mal el coste. Miran el precio de una tanda de entrenamiento —hoy, casi ruido— y concluyen que el fine-tuning es barato. El entrenamiento nunca fue la parte cara.

Lo caro del fine-tuning es todo lo demás: reunir y limpiar cientos o miles de ejemplos de calidad, versionarlos, evaluar si el modelo ajustado mejora de verdad y no ha empeorado en otras tareas, y repetir ese ciclo cada vez que el comportamiento deseado cambia. Es un pipeline de datos con mantenimiento, no un botón. Y si intentaste meter conocimiento por esa vía, ese ciclo se dispara: cada dato que cambia te obliga a reentrenar.

RAG tampoco es gratis, pero su coste es de otra naturaleza: infraestructura de recuperación —chunking, embeddings, una base vectorial, reranking— y tokens de contexto en cada llamada. Es coste de operación continuo y bastante predecible, frente al coste de proyecto, a golpes, del fine-tuning.

Esa última fila pesa más de lo que parece en producción. Con RAG puedes mostrar de qué documento salió cada respuesta; con fine-tuning, el conocimiento queda disuelto en los pesos y no hay forma limpia de auditarlo ni de corregir un dato concreto.

Antes de tocar nada, agota el prompt

Hay un tercer camino que suele ganar a los dos y casi nadie prueba a fondo: el prompt. Un buen prompt de sistema, unos cuantos ejemplos few-shot bien elegidos y un formato de salida explícito resuelven una parte enorme de lo que la gente cree que necesita fine-tuning. Es lo más barato, lo más rápido de iterar y lo que deberías agotar antes de plantearte ajustar pesos.

# Antes de fine-tunear un formato de salida, prueba a pedirlo bien.
# Esto sustituye a muchos fine-tunings "para que responda en JSON".

SYSTEM = """Eres un clasificador de tickets de soporte.
Devuelve SOLO un JSON con esta forma, sin texto alrededor:
{"categoria": "facturacion|tecnico|comercial", "urgencia": "alta|media|baja"}"""

EJEMPLOS = [
    {"in": "No me llega la factura de junio",   "out": '{"categoria":"facturacion","urgencia":"media"}'},
    {"in": "La app se cierra al abrir informes", "out": '{"categoria":"tecnico","urgencia":"alta"}'},
]

# few-shot: le enseñas el patrón sin tocar los pesos.
mensajes = [{"role": "system", "content": SYSTEM}]
for e in EJEMPLOS:
    mensajes += [{"role": "user", "content": e["in"]},
                 {"role": "assistant", "content": e["out"]}]
mensajes.append({"role": "user", "content": ticket_del_usuario})

Solo cuando el prompt se queda corto de forma repetida —el modelo se desvía del formato pese a los ejemplos, o necesitas meter tantos ejemplos que el contexto se hace caro— tiene sentido subir el peldaño al fine-tuning. Entonces sí: has demostrado que el problema es de comportamiento estable y que el prompt no basta.

Lo normal es combinarlos

El planteamiento de “o uno o el otro” cae del todo cuando ves un sistema serio. Lo habitual es fine-tuning para la forma y RAG para el fondo: ajustas el modelo para que responda siempre con el tono, el formato y la estructura que tu producto necesita, y le acercas por RAG los hechos concretos de cada consulta. El modelo ajustado ya sabe cómo contestar; RAG le dice qué contestar hoy.

Un asistente de soporte es el ejemplo de manual. El fine-tuning le da la voz de la marca y la disciplina de citar siempre la fuente; RAG le pone delante la documentación actual del producto, que cambia cada semana. Ninguna de las dos piezas hace el trabajo de la otra, y por eso encajan.

Qué hacer el lunes

Empieza por el camino barato y súbelo solo cuando choques con un muro. Monta primero RAG con un prompt bien trabajado; cubre casi todo lo que parece necesitar algo más sofisticado, y te deja el sistema trazable desde el día uno. Mide con casos reales antes de añadir complejidad.

Reserva el fine-tuning para cuando tengas una prueba concreta de que el problema es de comportamiento —un formato que se te escapa, un tono que no consigues fijar con ejemplos— y no de conocimiento. Si dudas de en qué caja cae tu problema, hazte la pregunta del reloj: ¿la respuesta correcta cambiará el mes que viene? Si sí, es RAG. Si lo que cambia es solo la manera de decirlo, quizá sea fine-tuning. Y si aún no lo has probado con un buen prompt, no es ninguno de los dos: es prompt.