17 · Prompt vs RAG vs fine-tune
Tres formas de adaptar un LLM a tu problema — y NO son intercambiables. El prompting cambia el comportamiento, RAG inyecta conocimiento fresco, el fine-tuning fija estilo y habilidad. Un marco de decisión, no echar una moneda al aire.
Hay tres palancas para adaptar un LLM. El PROMPTING cambia el comportamiento y el formato de salida solo con palabras (sin entrenar). RAG inyecta HECHOS frescos o privados en el contexto en tiempo de consulta. El FINE-TUNING re-pesa el modelo para que un ESTILO, FORMATO o HABILIDAD sea el comportamiento por defecto. Cada uno resuelve un problema distinto; elegir mal cuesta dinero o falla de plano.
Sin esto:
Sin el marco, la gente hace fine-tuning para agregar hechos (que no funciona de forma fiable y se vuelve obsoleto), o llena un prompt gigante de conocimiento que RAG debería traer bajo demanda — pagando por la herramienta equivocada en cada llamada.
Tienes un LLM base y un problema. Antes de escribir una línea de código, debes elegir cómo vas a adaptar el modelo — y hay exactamente tres palancas, cada una arreglando un tipo distinto de brecha.
1. Prompting — cambia el comportamiento con palabras, sin entrenar nada. Editas el system prompt, agregas ejemplos few-shot, le das una persona o una especificación de formato. Esto cambia cómo se comporta el modelo sobre el conocimiento que ya tiene. Es instantáneo, gratis de iterar y reversible. No puede enseñarle hechos que nunca vio.
2. RAG (Generación Aumentada por Recuperación) — inyecta conocimiento en el contexto en tiempo de consulta. Recuperas los chunks relevantes de tus documentos y los pegas en el prompt para que el modelo responda desde tus datos. Es la herramienta correcta cuando la brecha son hechos faltantes: documentos privados, datos frescos que cambian a diario, cualquier cosa que deba citarse. El conocimiento vive fuera del modelo, así que siempre está actualizado y lo actualizas cambiando un archivo.
3. Fine-tuning — re-entrenas de verdad (una porción de) los pesos con tus ejemplos, para que un estilo, formato o habilidad sea el comportamiento por defecto del modelo. Es la herramienta correcta cuando la brecha es un comportamiento consistente que el prompt no puede asegurar de forma fiable: una voz de marca, un esquema JSON estricto en miles de llamadas, una habilidad de clasificación especializada. Es lento y costoso de producir, y se vuelve obsoleto en cuanto cambian tus hechos — por eso justamente NO se hace fine-tuning para agregar conocimiento.
El error clásico es usar fine-tuning para memorizar hechos. Los modelos son malos recordando hechos específicos del fine-tuning, y en cuanto un hecho cambia hay que re-entrenar. Hechos → RAG. Comportamiento/formato → prompting primero, fine-tuning si el prompting no es suficientemente fiable.
Convirtamos el marco en código. La función de abajo toma los requisitos de una funcionalidad — ¿necesita datos frescos? ¿datos privados? ¿un formato rígidamente consistente? ¿cuántos datos de entrenamiento tienes? ¿qué tan ajustado es el presupuesto de latencia? — y aplica las reglas de decisión de arriba para recomendar una estrategia con justificación. Lo importante no es la redacción exacta; es que la elección es consecuencia determinista de unas pocas preguntas sí/no que puedes responder antes de construir nada.
Python (in browser)
El marco de decisión como código: hechos → RAG, formato/comportamiento → prompting (barato) o fine-tuning (cuando tienes datos). Nota que el escenario 1 solo usa RAG, mientras los otros se apoyan en prompting/fine-tuning.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Una regla pragmática más de orden, porque es la que más dinero ahorra: agota siempre primero las palancas más baratas. Iterar un prompt toma segundos y cuesta centavos; construir un índice RAG toma un día; producir un dataset de fine-tuning limpio y entrenar toma semanas y se repite cada vez que el comportamiento deba cambiar. Sube la escalera solo cuando el peldaño de abajo realmente no alcanza.
Python (in browser)
La escalera de adaptación. RAG es la única palanca que agrega hechos sin volverse obsoleta; el fine-tuning es la única que reformula el formato de forma fiable — y la más cara de mantener.
Python runs entirely in your browser via Pyodide (~6 MB on first Run, cached after).
Un equipo legal quiere que el asistente responda preguntas sobre SUS contratos, que son privados y se actualizan semanalmente. ¿Qué palanca es la elección principal correcta?
- Tres palancas, tres brechas: el prompting cambia el comportamiento, RAG inyecta hechos, el fine-tuning fija estilo/formato/habilidad.
- Hechos → RAG (nunca se vuelve obsoleto, se actualiza editando archivos); comportamiento/formato → prompting primero, fine-tuning solo si el prompting no es suficientemente fiable.
- Agota primero las palancas más baratas — el prompting itera en segundos, RAG en un día, el fine-tuning se repite en semanas. Las palancas se apilan.
Todo producto con LLM toma esta decisión en el diseño; los sistemas maduros apilan un modelo de formato afinado, una capa de conocimiento RAG y un prompt de guardrails — cada uno elegido por la brecha que cierra.
Si lo quitas: Sin el marco, los equipos hacen fine-tuning para hechos (obsoleto, poco fiable) o meten conocimiento en los prompts (caro en cada llamada), gastando semanas y dólares en la palanca equivocada.