Módulo 7: El lazo de datos y de retroalimentación

6. Prompt vs RAG vs fine-tune como decisión arquitectónica

Siguiente →

Descripción

Al terminar esta lección vas a poder tomar la decisión que aparece cada vez que el feedback te dice que el componente falla: ¿mejoro el sistema ajustando el prompt, montando un RAG, o entrenando un fine-tune? Son las tres palancas clásicas para mejorar un componente de IA, y la tesis de la lección es que elegir entre ellas es una decisión arquitectónica —no una decisión de implementación— porque cada una tiene un perfil distinto de latencia, costo, frescura de datos y mantenimiento, y ese perfil, no la moda, es lo que debe decidir. Cambiar el prompt es barato, instantáneo y reversible; RAG trae datos frescos en cada consulta a cambio de un salto de recuperación; fine-tune hornea el conocimiento en el modelo —prompts cortos, inferencia barata— pero se congela al entrenar. La decisión correcta depende de qué necesita tu feature, y el error más caro del módulo en esta dimensión es saltar a fine-tune cuando prompt o RAG bastaban.

Esto importa porque las tres palancas se confunden con frecuencia, y "fine-tune" tiene un aura de solución seria que atrae a los equipos hacia la opción más cara y más rígida por las razones equivocadas. Fine-tune suena a "de verdad enseñarle al modelo", mientras que ajustar un prompt suena a un parche. Pero en la mayoría de los casos reales, la jerarquía correcta es la inversa: empieza por el prompt, sube a RAG si necesitas conocimiento fresco o grande, y considera fine-tune solo cuando prompt y RAG no alcanzan y el comportamiento es estable y de alto volumen. Elegir la palanca por su perfil arquitectónico —y no por su prestigio— es lo que separa un sistema que mejora rápido y barato de uno que gasta meses entrenando un modelo que se queda obsoleto en cuanto cambia una política.

Conexión con el módulo: esta lección abre las palancas que las lecciones 5 y 7 conectan con el feedback. En la lección 5 cerraste el lazo hacia el eval-set y viste que el feedback tiene tres destinaciones (eval, prompt, retrieval); aquí examinas a fondo el perfil de cada palanca de mejora para poder elegir bien. La lección 7 usará esta decisión para enrutar cada tipo de fallo a su palanca. Y la frontera de este módulo es aquí más dura que nunca: NO vas a aprender a construir un RAG, a calcular embeddings, ni a correr un fine-tune —eso es la mecánica, y es del ecosistema AI Engineering—. Vas a aprender a decidir entre las tres tratándolas como cajas con propiedades arquitectónicas. La regla mental: "¿cómo indexo el vector store o cómo entreno el modelo?" es AI Engineering; "¿debo usar prompt, RAG o fine-tune para esta feature?" es de aquí.

Analogía: cómo le das información a un empleado nuevo

Imagina que contratas a un empleado competente pero que no conoce tu empresa, y tienes que darle la información que necesita para atender a los clientes. Tienes tres formas de hacerlo, y cada una tiene un costo y un perfil distinto.

La primera es decírselo cada vez, en el momento: antes de cada llamada, le pasas una nota con los datos que va a necesitar ("este cliente pidió tal producto, la política de envío es esta"). Es instantáneo —le cambias la nota y ya tiene la información nueva— y no requiere ninguna preparación previa. Pero la nota tiene un límite de tamaño: no puedes pasarle un manual de 500 páginas antes de cada llamada. Esto es el prompt: el conocimiento va dentro de la instrucción, cambia al instante, pero está limitado por cuánto cabe en la nota (la ventana de contexto).

La segunda es darle acceso a un archivero bien organizado: no memoriza nada, pero cuando necesita un dato, va al archivero, busca la carpeta correcta y la consulta. El archivero puede ser enorme (millones de documentos) y siempre está actualizado —cuando cambia una política, actualizas la carpeta y el empleado ya consulta la versión nueva—. El costo es que cada consulta toma un momento extra (ir al archivero y volver). Esto es RAG: el conocimiento vive en un índice externo que el modelo consulta en el momento; frescura excelente, conocimiento ilimitado, a cambio de un salto de recuperación por consulta.

La tercera es mandarlo a un curso de capacitación intensivo: durante semanas, le metes todo el conocimiento y el estilo de la empresa hasta que lo tiene interiorizado y responde rápido sin consultar nada. Después del curso, es velocísimo —no necesita nota ni archivero, ya lo sabe—. Pero el curso fue caro y lento, y aquí está el problema: el día que cambia una política, el empleado sigue enseñando la vieja, porque lo que aprendió en el curso quedó fijo. Para actualizarlo, tienes que mandarlo a otro curso. Esto es fine-tune: el conocimiento y el estilo quedan horneados en el modelo —inferencia rápida y barata, prompts cortos— pero congelados en el momento del entrenamiento; actualizar exige re-entrenar.

La decisión arquitectónica es exactamente elegir entre estas tres formas de darle información al empleado, y la respuesta depende de tu situación. ¿La información cambia seguido? La nota (prompt) o el archivero (RAG), nunca el curso (fine-tune, que se queda obsoleto). ¿Es muchísima información viva? El archivero (RAG). ¿Es poca y quieres empezar hoy? La nota (prompt). ¿El estilo es estable, el volumen enorme, y ni la nota ni el archivero logran el comportamiento que necesitas? Ahí, y solo ahí, el curso (fine-tune) se justifica.

Ejemplo trabajado: el perfil de cada palanca, y el recomendador

No vamos a decir cuándo conviene cada palanca: vamos a modelar su perfil arquitectónico y a ejecutar un recomendador que elige por feature. Modelamos cada opción con sus propiedades —latencia extra, tokens por consulta, esfuerzo de actualización, frescura de datos— y calculamos su costo mensual; luego un recomendador decide, para cuatro escenarios de Mercado, cuál palanca conviene. Fíjate en que la frescura de datos suele decidir primero.

# Leccion 06 (M7) — prompt vs RAG vs fine-tune como DECISION ARQUITECTONICA. SIMULADO.
# Cero red, cero API, cero claves. Determinista.
#
# NO enseñamos la mecanica (indexar embeddings, entrenar) — eso es AI Engineering.
# Modelamos las PROPIEDADES ARQUITECTONICAS de cada opcion y decidimos cual conviene
# segun los requisitos de la feature: latencia, costo, FRESCURA de datos y mantenimiento.

# --- Perfil arquitectonico de cada opcion (numeros ilustrativos, no mecanica). ---
# added_latency_ms : latencia extra que suma la opcion por request
# freshness_lag    : cuanto tarda un dato NUEVO en reflejarse en las respuestas
# update_effort    : que cuesta incorporar informacion nueva (0=trivial, 10=carisimo)
# setup_effort     : que cuesta ponerlo en pie la primera vez
# per_query_tokens : tokens tipicos por request (mas tokens = mas costo/latencia)
APPROACHES = {
    "prompt": dict(
        added_latency_ms=0, freshness_lag="instantaneo (editas el prompt)",
        update_effort=1, setup_effort=1, per_query_tokens=1200,
        nota="el conocimiento va DENTRO del prompt; limitado por la ventana de contexto"),
    "rag": dict(
        added_latency_ms=120, freshness_lag="minutos (actualizas el indice)",
        update_effort=2, setup_effort=5, per_query_tokens=1500,
        nota="recupera datos frescos en cada query; suma un salto de retrieval"),
    "finetune": dict(
        added_latency_ms=-40, freshness_lag="dias (hay que RE-ENTRENAR)",
        update_effort=9, setup_effort=9, per_query_tokens=400,
        nota="el conocimiento/estilo queda HORNEADO; prompts cortos, pero congelado"),
}

print("=== Perfil arquitectonico de cada opcion ===")
print(f"{'opcion':<10}{'lat_extra':>10}{'tok/query':>11}{'update':>8}{'setup':>7}  frescura")
for name, p in APPROACHES.items():
    print(f"{name:<10}{p['added_latency_ms']:>+9}ms{p['per_query_tokens']:>11}"
          f"{p['update_effort']:>8}{p['setup_effort']:>7}  {p['freshness_lag']}")
print()

# --- El costo mensual estimado por opcion (tokens -> USD, consistente con M2). ---
USD_PER_1K = 0.006   # precio mezclado in/out por 1000 tokens (ilustrativo)
QUERIES_MONTH = 100_000
print(f"=== Costo mensual estimado ({QUERIES_MONTH:,} queries/mes) ===")
for name, p in APPROACHES.items():
    cost = QUERIES_MONTH * (p["per_query_tokens"] / 1000) * USD_PER_1K
    print(f"  {name:<10}: ${cost:>8,.0f}/mes   ({p['per_query_tokens']} tok/query)")
print("  (fine-tune abarata POR QUERY con prompts cortos, pero su costo real esta")
print("   en el RE-ENTRENAMIENTO cada vez que un dato cambia — no en la inferencia.)")
print()

# --- El recomendador: dada la NECESIDAD de la feature, elige la opcion. ---
# La regla dura de diseño: si los datos CAMBIAN seguido, fine-tune queda descartado
# (su frescura es "dias / re-entrenar"). Si el conocimiento es GRANDE y vivo, RAG.
# Si es pequeño y quieres iterar rapido, prompt. fine-tune solo si el
# comportamiento es ESTABLE, de ALTO volumen y prompt+RAG no alcanzan.
def recommend(need):
    if need["data_changes"] in ("horas", "dias"):
        # Frescura manda: fine-tune queda fuera (se congela al entrenar).
        return "rag" if need["knowledge_size"] == "grande" else "prompt"
    # Datos estables:
    if need["knowledge_size"] == "grande":
        return "rag"
    if need["stable_behavior"] and need["volume"] == "alto":
        return "finetune"      # estilo estable + alto volumen amortiza el entrenamiento
    return "prompt"

SCENARIOS = {
    "Agente de soporte (politicas de envio/devolucion cambian cada semana)":
        dict(data_changes="dias", knowledge_size="mediano", stable_behavior=False, volume="alto"),
    "Busqueda sobre catalogo vivo (millones de productos, cambian a diario)":
        dict(data_changes="horas", knowledge_size="grande", stable_behavior=False, volume="alto"),
    "'Describe tu producto' con tono de marca FIJO y volumen enorme":
        dict(data_changes="nunca", knowledge_size="pequeno", stable_behavior=True, volume="alto"),
    "Prototipo rapido de un clasificador de tickets (iterar hoy)":
        dict(data_changes="nunca", knowledge_size="pequeno", stable_behavior=False, volume="bajo"),
}

print("=== El recomendador: la opcion segun la necesidad ===")
for scenario, need in SCENARIOS.items():
    choice = recommend(need)
    print(f"  -> {choice.upper():<9} | {scenario}")
print()
print("Regla arquitectonica: la FRESCURA de datos suele decidir primero.")
print("  datos que cambian seguido  -> prompt o RAG (NUNCA fine-tune: se congela)")
print("  conocimiento grande y vivo -> RAG")
print("  comportamiento estable + alto volumen + prompt/RAG no alcanzan -> fine-tune")

Qué esperar. Al correrlo, la salida es exactamente esta:

=== Perfil arquitectonico de cada opcion ===
opcion     lat_extra  tok/query  update  setup  frescura
prompt           +0ms       1200       1      1  instantaneo (editas el prompt)
rag            +120ms       1500       2      5  minutos (actualizas el indice)
finetune        -40ms        400       9      9  dias (hay que RE-ENTRENAR)

=== Costo mensual estimado (100,000 queries/mes) ===
  prompt    : $     720/mes   (1200 tok/query)
  rag       : $     900/mes   (1500 tok/query)
  finetune  : $     240/mes   (400 tok/query)
  (fine-tune abarata POR QUERY con prompts cortos, pero su costo real esta
   en el RE-ENTRENAMIENTO cada vez que un dato cambia — no en la inferencia.)

=== El recomendador: la opcion segun la necesidad ===
  -> PROMPT    | Agente de soporte (politicas de envio/devolucion cambian cada semana)
  -> RAG       | Busqueda sobre catalogo vivo (millones de productos, cambian a diario)
  -> FINETUNE  | 'Describe tu producto' con tono de marca FIJO y volumen enorme
  -> PROMPT    | Prototipo rapido de un clasificador de tickets (iterar hoy)

Regla arquitectonica: la FRESCURA de datos suele decidir primero.
  datos que cambian seguido  -> prompt o RAG (NUNCA fine-tune: se congela)
  conocimiento grande y vivo -> RAG
  comportamiento estable + alto volumen + prompt/RAG no alcanzan -> fine-tune

Lee la salida en tres partes, porque cada tabla instala una parte de la decisión.

El perfil revela el trade-off central: latencia/costo por query vs frescura y mantenimiento. Mira la primera tabla con cuidado. El prompt no suma latencia extra (+0 ms), es trivial de actualizar (update 1) y de montar (setup 1), y su frescura es instantánea —editas el prompt y ya—. El RAG suma un salto de recuperación (+120 ms) y algo de setup (5), pero su frescura es de minutos (actualizas el índice) y maneja conocimiento ilimitado. El fine-tune es el más extraño: resta latencia (-40 ms, porque el conocimiento horneado permite prompts cortos y hasta un modelo más pequeño) y usa muchísimos menos tokens por query (400 vs 1200-1500), pero su update_effort es 9 y su setup 9 —carísimo—, y su frescura es de días porque actualizar exige re-entrenar. Ahí está el trade-off entero: fine-tune optimiza la inferencia (rápida, barata por query) a costa de la frescura y el mantenimiento (rígido, caro de actualizar).

El costo por query engaña; el costo real de fine-tune está en el re-entrenamiento. La segunda tabla parece darle la victoria a fine-tune: $240/mes contra $720 del prompt y $900 de RAG, porque sus prompts cortos consumen menos tokens. Y es cierto —por query, fine-tune es el más barato—. Pero lee la nota: ese cálculo no incluye el costo del re-entrenamiento, que es donde vive el gasto real de fine-tune. Cada vez que una política cambia, hay que armar un dataset nuevo y correr un entrenamiento (tiempo de ingeniería + cómputo), y eso no aparece en el costo por query. Para una feature cuyos datos cambian seguido, el costo de re-entrenar una y otra vez supera con creces el ahorro por query. Por eso el costo por query es una trampa: hace ver barato a fine-tune justo cuando su costo oculto (mantenimiento) lo hace caro.

El recomendador demuestra que la frescura decide primero. La tercera tabla es la decisión en acción. El agente de soporte (políticas que cambian cada semana) → prompt: los datos cambian, así que fine-tune queda descartado, y como el conocimiento es mediano (no enorme), cabe en el prompt. La búsqueda sobre catálogo vivo (millones de productos, cambian a diario) → RAG: los datos cambian y son enormes, así que RAG es la única que da frescura sin límite de tamaño. El generador "describe tu producto" con tono de marca fijo y volumen enorme → fine-tune: aquí sí, porque el comportamiento (el tono) es estable —no cambia— y el volumen es enorme, así que el estilo horneado se justifica y amortiza el costo de entrenar. El prototipo de clasificador para iterar hoy → prompt: rápido de montar, rápido de cambiar. Fíjate en el patrón: en tres de los cuatro casos, lo primero que se preguntó fue "¿los datos cambian?", y esa pregunta sola descartó o eligió la palanca. La frescura de datos es, casi siempre, la primera compuerta de la decisión.

El perfil de cada palanca, a nivel de diseño

El ejemplo modeló los perfiles; vale la pena entender qué gobierna cada palanca a nivel arquitectónico, sin entrar en su mecánica.

Prompt (in-context): la palanca por defecto. Poner el conocimiento y las instrucciones en el prompt es la opción más barata, más rápida de cambiar y más reversible. Su frescura es perfecta (editas el prompt y el cambio es instantáneo) y su costo de mantenimiento es mínimo. Su límite es el tamaño: solo cabe lo que entra en la ventana de contexto, y meter mucho texto en cada prompt sube los tokens (costo y latencia). Cuándo es la respuesta: conocimiento pequeño o mediano, cambios frecuentes, iteración rápida, o simplemente como primer intento —casi siempre vale la pena probar el prompt antes de nada más—. Es el equivalente de la nota que le pasas al empleado antes de cada llamada.

RAG (retrieval-augmented): la palanca de la frescura y el volumen. RAG recupera, en el momento de la consulta, los documentos relevantes de un índice externo y se los da al modelo. Su gran virtud arquitectónica es doble: frescura (actualizas el índice y el cambio se refleja en la siguiente consulta, sin tocar el modelo) y volumen (el índice puede ser enorme, mucho más de lo que cabría en un prompt). Su costo es un salto de recuperación por consulta (latencia extra) y algo más de tokens (los documentos recuperados van al prompt). Cuándo es la respuesta: conocimiento grande y/o que cambia seguido —un catálogo, una base de documentos de políticas, una wiki viva—. Es el archivero siempre actualizado. Cómo se construye el índice (embeddings, chunking, recuperación) es AI Engineering; que RAG es la palanca correcta cuando necesitas frescura sobre mucho conocimiento es de aquí.

Fine-tune: la palanca del comportamiento estable y el alto volumen. Fine-tune ajusta el modelo mismo con ejemplos, horneando conocimiento o —más útil— un estilo/comportamiento en él. Su virtud es la inferencia: prompts cortos (no hay que incluir el conocimiento ni muchos ejemplos), baja latencia, bajo costo por query, y a veces la posibilidad de usar un modelo más pequeño. Su gran defecto es la rigidez: lo que aprende queda congelado al entrenar, así que actualizarlo exige re-entrenar —caro y lento—. Cuándo es la respuesta, y solo entonces: el comportamiento es estable (no cambia seguido), el volumen es alto (para amortizar el costo de entrenar), y prompt+RAG no logran el comportamiento que necesitas (un estilo muy específico, un formato muy consistente, una tarea especializada). Es el curso de capacitación: caro, lento, pero deja al empleado interiorizando el estilo. Cómo se entrena (dataset, hiperparámetros, evaluación) es AI Engineering; que fine-tune se justifica solo con comportamiento estable + alto volumen + prompt/RAG insuficientes es de aquí.

Y la jerarquía que resume la decisión, que es el antídoto contra el error de saltar a fine-tune:

La escalera de palancas (sube solo cuando el escalon anterior no alcanza):

  1. PROMPT      ── empieza SIEMPRE aqui. Barato, instantaneo, reversible.
       │            ¿No alcanza? (conocimiento muy grande o muy cambiante)
       ▼
  2. RAG         ── sube si necesitas frescura sobre MUCHO conocimiento.
       │            ¿Sigue sin alcanzar? (necesitas un estilo/comportamiento
       │             que ni el prompt ni el contexto recuperado logran, y el
       ▼             comportamiento es estable y el volumen alto)
  3. FINE-TUNE   ── SOLO aqui, y sabiendo que lo congelas y sera caro de actualizar.

  La gravedad de la decision: sube un escalon solo con una razon arquitectonica,
  nunca por prestigio. La mayoria de las features viven en el escalon 1 o 2.

Errores comunes

Saltar a fine-tune cuando prompt o RAG bastaban (de sobreingeniería). Qué pasa: el equipo tiene un problema de calidad y su primer instinto es "entrenemos un modelo con nuestros datos", saltándose el prompt y RAG. Invierte semanas en armar un dataset y correr entrenamientos, cuando un ajuste de prompt (media hora) o un RAG sobre sus documentos (unos días) habría resuelto el problema —y con mejor frescura—. Peor: el fine-tune queda obsoleto en cuanto cambia una política, y hay que re-entrenar. Por qué pasa: fine-tune tiene prestigio ("de verdad entrenamos el modelo") mientras el prompt suena a parche; la jerarquía de esfuerzo está invertida respecto a la de prestigio. Cómo detectarlo: si estás planeando un fine-tune y no has agotado el prompt ni RAG, casi seguro estás sobre-invirtiendo. Cómo corregirlo: sube la escalera en orden —prompt primero, RAG si necesitas frescura/volumen, fine-tune solo si los dos anteriores no alcanzan y el comportamiento es estable y de alto volumen—.

Elegir fine-tune para datos que cambian (de frescura). Qué pasa: el equipo entrena un modelo con el conocimiento de la empresa —políticas, catálogo, precios— y lo despliega. Funciona bien... hasta que una política cambia, y el modelo sigue respondiendo con la vieja, porque lo que aprendió quedó congelado en el entrenamiento. Ahora cada cambio de política exige un re-entrenamiento, y el sistema siempre va atrasado respecto a la realidad. Por qué pasa: no se pensó en la frescura al elegir la palanca; se optimizó el costo por query sin ver el costo de mantenimiento. Cómo detectarlo: si tu conocimiento cambia con más frecuencia de la que puedes re-entrenar, fine-tune te va a dejar siempre desactualizado. Cómo corregirlo: para conocimiento que cambia, usa prompt (si cabe) o RAG (si es grande) —las palancas con frescura—; reserva fine-tune para lo que no cambia (un estilo, un formato, una tarea estable). La frescura de datos es la primera pregunta de la decisión.

Mirar solo el costo por query y creer que fine-tune es "el más barato" (de contabilidad incompleta). Qué pasa: el equipo compara las opciones por su costo por query, ve que fine-tune usa menos tokens (prompts cortos) y concluye que es la opción más económica. Ignora el costo de re-entrenar cada vez que algo cambia, que es donde vive el gasto real de fine-tune. Para una feature con datos que cambian, ese costo oculto supera con creces el ahorro por query, y la "opción más barata" resulta la más cara. Por qué pasa: el costo por query es visible y fácil de comparar; el costo de mantenimiento es difuso y se pasa por alto. Cómo detectarlo: si tu comparación de costos no incluye "¿cuánto cuesta actualizar esto cuando algo cambie, y cada cuánto cambia?", está incompleta. Cómo corregirlo: cuenta el costo total —inferencia más mantenimiento— y pondéralo por la frecuencia de cambio; ahí fine-tune suele perder su aparente ventaja de costo.

Ejercicios

Ejercicio 1 — El empleado nuevo. Para cada una de las tres formas de darle información al empleado, di qué palanca representa, cuál es su virtud principal y cuál su límite. Luego, para el agente de soporte de Mercado —cuyas políticas de envío y devolución cambian cada semana— di cuál forma elegirías y por qué, conectándolo con el resultado del recomendador.

Ver solución
  • Pasarle una nota antes de cada llamada → el prompt. Virtud: instantáneo (le cambias la nota y ya tiene lo nuevo), sin preparación previa. Límite: el tamaño de la nota (la ventana de contexto) —no le puedes pasar un manual entero—.
  • Darle acceso a un archivero organizado → RAG. Virtud: conocimiento ilimitado y siempre actualizado (actualizas la carpeta y consulta la versión nueva). Límite: cada consulta toma un momento extra (el salto de recuperación).
  • Mandarlo a un curso intensivo → fine-tune. Virtud: rapidísimo después (ya lo sabe, no consulta nada), inferencia barata. Límite: el curso fue caro y lento, y queda congelado —cuando cambia una política, sigue enseñando la vieja hasta que lo mandas a otro curso—.

Para el agente de soporte cuyas políticas cambian cada semana, elegiría el prompt (la nota), y coincide con el recomendador. La razón es la frescura: como las políticas cambian seguido, fine-tune (el curso) queda descartado —se congelaría con las políticas viejas y habría que re-entrenar cada semana—. Entre prompt y RAG, el conocimiento del agente es mediano (cabe en el prompt), así que la nota basta y es lo más barato y rápido de actualizar; si el conocimiento fuera enorme (millones de documentos de política), subiría a RAG (el archivero). La frescura decidió primero (descartó fine-tune), y el tamaño decidió entre las dos restantes.

Ejercicio 2 — La trampa del costo por query. Un compañero argumenta: "el recomendador dice que para el agente de soporte usemos prompt, pero fine-tune cuesta $240/mes contra $720 del prompt —fine-tune es tres veces más barato, deberíamos entrenarlo—". Explica por qué el argumento está incompleto y qué costo le falta considerar, dado que las políticas del agente cambian cada semana.

Ver solución

El argumento está incompleto porque compara solo el costo por query (inferencia) e ignora el costo de mantenimiento (re-entrenamiento), que es donde vive el gasto real de fine-tune. Los $240/mes de fine-tune son ciertos por inferencia —sus prompts cortos consumen menos tokens—, pero ese número no incluye lo que cuesta actualizar el modelo cuando las políticas cambian.

Y aquí está el detalle que mata el argumento: las políticas del agente cambian cada semana. Con fine-tune, cada cambio de política exige armar un dataset nuevo y correr un re-entrenamiento —tiempo de ingeniería más cómputo—, y eso pasaría cada semana. Ese costo recurrente de mantenimiento supera con creces los $480/mes que fine-tune "ahorra" en inferencia frente al prompt. Con el prompt, en cambio, actualizar una política es editar texto (minutos, costo ~cero) y el cambio es instantáneo. Así que, contando el costo total (inferencia + mantenimiento, ponderado por la frecuencia de cambio semanal), el prompt es más barato, no más caro —y además da frescura instantánea, que fine-tune no puede—. El costo por query es una trampa que hace ver barato a fine-tune justo cuando su rigidez lo hace caro. Fine-tune sería la opción barata si las políticas no cambiaran (como el generador de descripciones con tono fijo), pero cambian cada semana, y eso lo descalifica.

Ejercicio 3 — ¿Qué palanca para cada feature nueva? Para cada feature nueva de Mercado, di qué palanca (prompt, RAG o fine-tune) recomendarías y por qué, siguiendo la escalera. (a) Un asistente que responde preguntas sobre las miles de reseñas de un producto, que llegan nuevas cada hora. (b) Un formateador que convierte descripciones de vendedores al estilo y estructura exactos de la marca Mercado, un estilo que no ha cambiado en años y que se aplica a millones de productos. (c) Un clasificador que etiqueta un ticket de soporte en una de cinco categorías, para un experimento que arranca esta semana.

Ver solución
  • (a) Asistente sobre miles de reseñas que llegan cada hora → RAG. El conocimiento es grande (miles de reseñas por producto, millones en total) y cambia constantemente (nuevas cada hora). Eso descarta fine-tune (se congelaría, y re-entrenar cada hora es absurdo) y descarta el prompt (no caben miles de reseñas en la ventana de contexto). RAG es la única que da frescura sobre mucho conocimiento: indexas las reseñas y recuperas las relevantes en cada consulta. La frescura y el volumen mandan.
  • (b) Formateador al estilo de marca, estable, millones de productos → fine-tune (el caso que lo justifica). Aquí sí. El comportamiento (el estilo y estructura de la marca) es estable —no ha cambiado en años—, el volumen es enorme (millones de productos, alta amortización), y es un estilo/formato que un prompt con ejemplos podría lograr pero de forma menos consistente y con prompts largos (costosos a ese volumen). Fine-tune hornea el estilo: prompts cortos, inferencia barata a escala masiva, y como el estilo no cambia, la rigidez no duele. Cumple los tres requisitos: estable, alto volumen, y prompt/RAG subóptimos. (Aun así, valdría la pena probar primero el prompt con ejemplos y medir si alcanza —subir la escalera en orden—.)
  • (c) Clasificador de 5 categorías, experimento de esta semana → prompt. Poco conocimiento (cinco categorías con sus definiciones caben de sobra en el prompt), y sobre todo, quieres iterar hoy. El prompt es instantáneo de montar y de ajustar mientras experimentas con las categorías. Montar RAG o fine-tune para un experimento de esta semana sería sobreingeniería —empieza por el prompt, y solo sube la escalera si el experimento madura y el prompt no alcanza—.

El patrón: (a) frescura+volumen → RAG; (b) estable+volumen+necesita el estilo horneado → fine-tune; (c) pequeño+iterar rápido → prompt. Y en los tres, la escalera dice: no subas de escalón sin una razón arquitectónica.

Resumen y siguiente paso

En esta lección aprendiste a tomar la decisión arquitectónica prompt vs RAG vs fine-tune: cada palanca tiene un perfil distinto de latencia, costo, frescura de datos y mantenimiento, y ese perfil —no el prestigio— es lo que debe decidir. Lo viste con la analogía del empleado nuevo (la nota instantánea = prompt, el archivero siempre actualizado = RAG, el curso intensivo que se congela = fine-tune) y lo mediste: el perfil de cada opción, su costo por query (donde fine-tune engaña porque oculta el costo de re-entrenar), y un recomendador que eligió por feature —prompt para el agente de políticas cambiantes, RAG para el catálogo vivo, fine-tune solo para el estilo estable de alto volumen—. Entendiste la escalera de palancas (empieza por el prompt, sube a RAG por frescura/volumen, fine-tune solo como último recurso) y el antídoto contra el error más caro: no saltes a fine-tune por prestigio; súbelo solo con una razón arquitectónica, sabiendo que lo congelas.

Antes de avanzar deberías poder: describir el perfil de cada palanca (latencia, costo, frescura, mantenimiento); explicar por qué la frescura de datos suele decidir primero; reconocer la trampa del costo por query (fine-tune oculta el costo de re-entrenar); aplicar la escalera de palancas; y ubicar la frontera dura (la mecánica de RAG/fine-tune/embeddings es AI Engineering; la elección es de aquí).

Lo que sigue es la síntesis del módulo: enrutar la señal de feedback a la palanca correcta. Ya sabes capturar el feedback (lección 4), cerrarlo hacia el eval (lección 5) y cuáles son las palancas (esta lección). En la lección 7 vas a juntarlo todo: el feedback se agrupa por tipo de fallo, cada grupo se enruta a su palanca —dato que faltó → retrieval, tono sistemático → prompt, clase estable que prompt+RAG no cubren → considerar fine-tune—, y todo fallo va también al eval-set. Vas a ejecutar el lazo completo y ver el score subir de 0.43 a 0.86 al aplicar las palancas correctas. Es el paso de "conozco las palancas" a "sé cuál palancar mover para cada tipo de fallo, y cómo verificar que funcionó".

Recursos

  • Anthropic — documentación de Claude — la guía conceptual de cuándo poner el conocimiento en el prompt, cuándo recuperarlo (retrieval) y cuándo considerar afinar el modelo; la referencia de las propiedades de cada enfoque, sin fijar versión de modelo. En inglés.
  • Chip Huyen — AI Engineering (O'Reilly) — el tratamiento a fondo de prompt engineering, RAG y fine-tuning con sus trade-offs de latencia, costo y frescura; el libro para la mecánica de las palancas que esta lección solo enseña a elegir (la frontera con AI Engineering).
  • martinfowler.com — "Emerging Patterns in Building GenAI Applications", Bharani Subramaniam y Martin Fowler — el catálogo de patrones ubica RAG y fine-tuning como decisiones de arquitectura con sus consecuencias; el marco de esta lección. En inglés.
  • Ecosistema AI Engineering (remisión) — para construir cada palanca: cómo se indexa y recupera en RAG (embeddings, chunking), cómo se arma el dataset y se corre un fine-tune, cómo se hace prompt engineering serio. Este módulo enseña a elegir la palanca; AI Engineering enseña a construirla.
← Anterior5. Cerrar el lazo: el feedback se vuelve el eval-setSiguiente →7. Enrutar la señal de feedback a la palanca correcta