Cuándo afinar, solicitar o usar RAG — Un marco de decisión

A los tres meses de construir la capa de extracción de señales de trading de AlgoVesta, quemamos $8,000 en el ajuste fino de GPT-3.5 en 15,000 documentos financieros. La precisión mejoró un 3%. Luego cambiamos a un enfoque de prompting diferente y arquitectura RAG — mismos datos, mismos modelos, estructura diferente. La precisión saltó al 89%. El problema no era la técnica. Era usar la técnica incorrecta para el problema.

El ajuste fino, la ingeniería de prompts y la generación aumentada por recuperación (RAG) no son herramientas intercambiables que compiten por el mismo trabajo. Resuelven diferentes problemas, operan a diferentes costos y requieren diferente carga de mantenimiento. La mayoría de los equipos eligen uno porque les suena familiar o porque leyeron un tutorial, no porque coincida con sus restricciones reales.

Este marco de trabajo corta a través de eso. Está construido sobre fallos de producción repetidos — míos y de otros — no en comparaciones teóricas.

Las Diferencias Clave: Lo Que Realmente Hace Cada Uno

Empieza aquí porque las distinciones importan.

Ingeniería de prompts da forma al comportamiento del modelo sin cambiar sus pesos. Escribes instrucciones, estructuras ejemplos y diseñas el formato de entrada. El modelo en sí permanece congelado. El costo es por token. La latencia es determinista. Los cambios tardan segundos.

Ajuste fino actualiza los pesos del modelo entrenándolo con tus datos específicos. Creas un conjunto de datos, ejecutas un trabajo de entrenamiento (horas a días) y despliegas una nueva versión del modelo. El costo incluye tiempo de entrenamiento inicial, luego inferencia por token. Es permanente a menos que reentrenes.

RAG no modifica el modelo en absoluto. Recupera contexto relevante de una base de datos externa, lo inyecta en el prompt y deja que el modelo base responda con información fundamentada. El costo depende de la velocidad de recuperación y del tamaño del contexto inyectado. Escala con el tamaño de tu base de conocimiento, no con tus datos de entrenamiento.

La distinción parece obvia cuando se expone. En la práctica, los equipos las confunden constantemente. Un error común: alguien entrena un modelo afinado para «mejorar la precisión» cuando el problema real es que el prompt no era lo suficientemente específico. Otro: construir un sistema RAG cuando el ajuste fino sería más rápido y barato.

Cuándo la Ingeniería de Prompts es Suficiente (Y Cuándo Deja de Funcionar)

La ingeniería de prompts es tu primer movimiento. Siempre.

Funciona cuando el modelo base ya entiende el concepto y solo necesita mejores instrucciones. No cuesta nada por adelantado. Obtienes retroalimentación en segundos. Puedes iterar 20 veces en una hora. Para clasificación, resumen y extracción estructurada de texto que el modelo ha visto durante el preentrenamiento, la ingeniería de prompts a menudo resuelve el 70–85% del problema.

Aquí tienes un antes/después real de la extracción de factores de riesgo de presentaciones ante la SEC usando Claude Sonnet 4:

## Prompt malo
Extrae los principales factores de riesgo de este documento.

## Salida
- Las condiciones generales del mercado podrían afectar nuestro negocio
- Nos enfrentamos a la competencia de otras empresas
- Las regulaciones pueden cambiar
- Dependemos de personal clave
(Vago, carece de especificidad, confunde niveles de severidad)

## Prompt mejorado
De la presentación 10-K adjunta, extrae todos los factores de riesgo que aparecen
en la sección "Ítem 1A. Factores de Riesgo". Para cada riesgo:

1. Incluye el encabezado exacto de la presentación
2. Proporciona una afirmación central de 1 oración (¿qué cosa mala podría suceder?)
3. Indica si la empresa cuantifica la probabilidad o el impacto (si es así, inclúyelo)
4. Marca como: MERCADO / OPERACIONAL / REGULATORIO / ESTRATÉGICO / FINANCIERO
5. Si la presentación declara explícitamente que este riesgo disminuyó en comparación con el año anterior,
   notifícalo

Omite riesgos genéricos que aparecen en cada 10-K (por ejemplo, "condiciones económicas generales"). Céntrate en riesgos específicos del negocio de esta empresa.

## Salida
- Brechas de ciberseguridad y pérdidas de datos (OPERACIONAL):
  Podrían comprometer datos de clientes y desencadenar acciones regulatorias.
  La empresa estimó la exposición en "hasta $500M" si ocurriera una "brecha material".
- Pérdida de asociaciones clave (ESTRATÉGICO):
  Específico para esta empresa. Dos de los 5 principales canales de ingresos dependen
  de contratos que se renuevan anualmente.
(Específico, jerárquico, clasificable)

El segundo prompt funciona porque:

• Especifica la estructura de salida (el modelo sigue instrucciones estructuradas mejor que las solicitudes vagas)
• Añade ejemplos negativos (lo que NO incluir ayuda tanto como lo que sí incluir)
• Crea un sistema de clasificación (MERCADO/OPERACIONAL/etc. — esto le da al modelo un árbol de decisión)
• Cuantifica la precisión («afirmación central de 1 oración» no «resume el riesgo»)

La ingeniería de prompts deja de funcionar cuando:

• El concepto está fuera de los datos de entrenamiento del modelo. No puedes arreglar esto con prompts. Si le pides a GPT-4o que extraiga jerga específica del dominio de informes de imágenes médicas y el modelo nunca vio esos datos durante el preentrenamiento, adivinará.
• Necesitas un comportamiento consistente en más de 10,000 consultas similares. La varianza del prompt se acumula. Algunas solicitudes golpearán casos extremos y el prompt no los manejará. Necesitas un reentrenamiento sistemático del comportamiento.
• Tu piso de precisión es ~85–90% pero necesitas 96%+. La ingeniería de prompts se estanca. Pequeñas ganancias después de eso requieren ajuste fino o cambios arquitectónicos (como RAG).
• La tarea requiere hechos que no están en los datos de entrenamiento. Si estás extrayendo precios de productos de 2024 y tu modelo fue entrenado hasta abril de 2023, el prompting no ayudará. RAG sí.

RAG: Cuando Tu Problema Es Contexto Faltante o Desactualizado

RAG resuelve un problema específico y común: el modelo sabe cómo pensar pero carece de los hechos que necesita.

Construyes un sistema RAG cuando:

• Tu conocimiento se actualiza más rápido que los ciclos de entrenamiento del modelo. Si reentrenas un modelo afinado cada semana para añadir nuevos datos, RAG es más barato. Actualizas una base de datos vectorial en su lugar. El costo por consulta es mayor (recuperación + búsqueda de embeddings) pero evitas la sobrecarga de reentrenamiento.
• Tu precisión falla debido a alucinaciones, no a razonamiento. El modelo sabe cómo extraer información y estructurarla — simplemente inventa detalles cuando no sabe algo. RAG lo fundamenta en datos reales.
• Necesitas atribución. «¿De qué documento provino este hecho?» El ajuste fino no puede responder eso. RAG puede porque recupera explícitamente la fuente.
• Tu tarea involucra hechos que el modelo nunca vio realmente. Un modelo afinado no puede aprender algo que no estaba en sus datos de entrenamiento. Un sistema RAG puede recuperarlo de una base de datos.

Ejemplo real de AlgoVesta: procesamos más de 500 informes de investigación al día y extraemos señales de compra/venta. Los informes hacen referencia a métricas y fechas específicas. Los precios y el contexto de las fechas cambian constantemente. Construimos RAG:

1. Dividimos cada informe en secciones de 300–500 tokens (los límites semánticos importan — dividir a mitad de frase mata el contexto)
2. Incrustamos cada sección con text-embedding-3-small de OpenAI (barato, rápido, suficientemente bueno para datos financieros)
3. Almacenamos embeddings + texto original en una base de datos vectorial (Pinecone, en nuestro caso)
4. En el momento de la consulta: incrustamos la pregunta del usuario, recuperamos los 5 fragmentos semánticamente más similares, los inyectamos en el prompt, enviamos a Claude Sonnet 4

La métrica clave: sin RAG, el modelo alucinaba números específicos ~15% de las veces. Con RAG, 1.2%. No afinamos. No mejoramos el prompt (mucho). Simplemente le dimos al modelo el material fuente que necesitaba.

RAG falla cuando:

• Tu lógica de recuperación está rota. Si tu base de datos vectorial devuelve fragmentos irrelevantes, el modelo trabajará con información errónea. Simplemente has trasladado el problema río arriba. Necesitas validar la calidad de la recuperación — examina realmente los 5 mejores resultados para una muestra de consultas.
• Estás inyectando demasiado contexto. La ventana de contexto de Claude Sonnet 4 es de 200K tokens. Suena infinito hasta que inyectas 15 fragmentos × 500 tokens cada uno, más un prompt largo, más la solicitud del usuario. El exceso de contexto causa picos de latencia y costo. Más contexto no siempre mejora la precisión — puede introducir ruido.
• Tu modelo de embeddings no coincide con tu dominio. Si usas un modelo de embeddings de propósito general en datos altamente especializados (contratos legales, registros médicos, señales de trading), la similitud semántica falla. Podrías necesitar embeddings específicos del dominio o recuperadores afinados.
• Tu base de conocimiento es pequeña o estática. Si tienes 50 documentos que rara vez cambian y tus datos son del período de entrenamiento del modelo, RAG añade complejidad para una ganancia mínima. La ingeniería de prompts es más rápida.

Ajuste Fino: Cuando Necesitas un Cambio de Comportamiento Sistemático

El ajuste fino es tu último recurso — no porque sea débil, sino porque es caro y crea una carga de despliegue.

Afinas cuando:

• El modelo base lucha consistentemente con tu formato o dominio específico. Si la ingeniería de prompts te lleva al 75% y has agotado las variaciones de prompts, el ajuste fino puede llevarte al 88–92% reponderando el modelo hacia la distribución de tus datos.
• Necesitas garantías de latencia que la ingeniería de prompts no puede proporcionar. Un modelo afinado es más pequeño, más rápido y más predecible que los modelos base con prompts largos y complejos. Si estás sirviendo 10K consultas/seg y los SLAs de latencia son estrictos, esto importa.
• El costo por consulta es tu restricción, no el costo inicial. El ajuste fino es caro por adelantado ($50–$500 dependiendo del tamaño del conjunto de datos y del modelo) pero la inferencia por token es más barata que la inferencia del modelo base. Si tienes un alto volumen, las matemáticas se invierten.
• Necesitas un comportamiento consistente en casos extremos que tu prompt no puede cubrir. Si has construido un prompt de 2,000 tokens intentando manejar 12 variaciones de entrada diferentes y aún falla el 8% de las veces, un modelo afinado entrenado con esas variaciones será más robusto.

Ejemplo: un equipo de soporte al cliente que usa GPT-4o para clasificar tickets. La ingeniería de prompts les dio un 82% de precisión en 50 categorías de tickets. Etiquetaron manualmente 2,000 tickets, afinaron Mistral 7B (modelo más pequeño, inferencia más rápida) y alcanzaron un 91% de precisión. Por adelantado: 4 horas de etiquetado + $60 de costo de ajuste fino. Ahorros mensuales: $1,200 en llamadas API (se necesitan menos tokens de GPT-4o). Retorno de la inversión: 3 semanas.

El ajuste fino falla cuando:

• No tienes datos de entrenamiento de alta calidad. Si tu conjunto de datos etiquetado es pequeño (<500 ejemplos) o ruidoso, el ajuste fino se sobreajustará o aprenderá patrones espurios. La ingeniería de prompts es más robusta con datos limitados.
• Tu problema es específico del dominio y tu modelo es demasiado general. Afinar GPT-4o en 1,000 ejemplos de clasificación de estructuras moleculares no le enseñará química. Un modelo específico del dominio o un enfoque de embeddings especializado sería mejor.
• Tu distribución de datos cambia frecuentemente. Los modelos afinados se degradan cuando encuentran datos diferentes a su conjunto de entrenamiento. Si afinas hoy y tus patrones de entrada cambian el próximo mes, necesitas reentrenar. RAG maneja mejor el cambio de distribución porque actualizas la base de conocimiento, no el modelo.
• Necesitas desplegar múltiples variantes. Si afinas un modelo para inglés y uno para español y uno para un dominio diferente, ahora administras tres modelos separados, tres despliegues separados, tres pipelines de monitoreo separados. Esta sobrecarga operativa es real.

La Matriz de Decisión: Guía Concreta Para Tu Problema

Usa esta tabla para acelerar el análisis. Encuentra tu restricción a la izquierda, sigue la fila y te indicará la herramienta correcta.

Un Flujo de Decisión Real: Tres Estudios de Caso

Caso 1: Marcado de Riesgos en Contratos Legales

Una startup necesita escanear contratos entrantes y marcar términos inusuales. Tienen 200 contratos etiquetados. Su modelo base (Claude Sonnet 4) capta el 70% de los riesgos pero omite el lenguaje específico del dominio.

Decisión: Empezar con ingeniería de prompts (2 horas, gratis). Resultados: 78%. Luego añadir RAG usando sus contratos etiquetados como base de conocimiento (8 horas de configuración, $50 en costos de embeddings). Resultados: 86%. El techo de precisión parece cercano. El ajuste fino requeriría 1,000+ contratos etiquetados (semanas de trabajo). Decisión: detenerse en RAG. Costo: ~$2/mes en base de datos vectorial. Esto funciona durante 3-6 meses hasta que tengan más datos etiquetados.

Caso 2: Clasificación de Reseñas de Productos (50K reseñas/mes)

Una empresa SaaS necesita clasificar 50K reseñas mensuales en 12 categorías de sentimiento. Los costos de la API de GPT-4o son de $400/mes para la tarea. Etiquetan 3,000 ejemplos y afinan Mistral 7B. Costo: $120 de ajuste fino + $8/mes de inferencia (usando Together AI para inferencia barata). Resultados: 88% de precisión (vs. 82% con ingeniería de prompts). Ahorros mensuales: $370. ROI del ajuste fino: 4 semanas.

Decisión: ajuste fino. Pero aquí está el truco: implementan un nuevo ajuste fino cada mes a medida que llegan nuevas reseñas. Después de 6 meses, han ejecutado 6 ciclos de ajuste fino. Al mes 7, la versión más reciente funciona peor en patrones antiguos (deriva). Deberían haber invertido en RAG o en una estrategia de prompting renovada en su lugar. Vive y aprende.

Caso 3: Preguntas y Respuestas sobre Documentación de la Empresa (más de 1,000 páginas)

El departamento de RRHH quiere que los empleados hagan preguntas sobre beneficios, políticas y procedimientos. Tienen un manual de 1,500 páginas que se actualiza trimestralmente. El modelo base (GPT-4o) alucina detalles de políticas el 12% de las veces.

Opción A: Ingeniería de prompts. Inyectar el manual completo en el prompt. Resultados: más de 100KB de sobrecarga de tokens por consulta. Latencia: 4–5 segundos. Costo: $0.80 por consulta. Alucinaciones: 5%. Insostenible a escala.

Opción B: RAG. Dividir el manual (1,500 páginas = ~1,000 fragmentos). Incrustar una vez. En el momento de la consulta: recuperar los 5 fragmentos relevantes principales, inyectarlos (~2KB tokens), enviar a Claude Sonnet 4. Latencia: 800ms. Costo: $0.12 por consulta. Alucinaciones: 0.8%. Decisión: obvia. Construir RAG. Implementación: Pinecone + Claude Sonnet 4 = dos semanas de principio a fin.

Enfoques Híbridos: Cuando Una Técnica No Es Suficiente

El mundo real rara vez elige uno. Los equipos que tienen éxito los combinan estratégicamente.

Ingeniería de prompts + RAG (común, efectivo)

Usas RAG para fundamentar hechos, luego usas ingeniería de prompts para guiar el razonamiento. Ejemplo: Extraer factores de riesgo de un 10-K (RAG recupera secciones relevantes) y luego clasificar su gravedad usando una plantilla de prompt estructurada (ingeniería de prompts). Costo: sobrecarga de recuperación + inferencia. Latencia: aceptable. Precisión: alta.

Ajuste Fino + RAG (avanzado, caro)

Afinas un modelo para que entienda tu dominio, luego usas RAG para darle hechos actuales. Ejemplo: afinar un modelo médico para clasificar síntomas de pacientes, pero usar RAG para fundamentarlo en datos actuales de interacción de fármacos que no estaban en el entrenamiento. Costo: alto (dos sistemas para mantener). Beneficio: comprensión del dominio + precisión factual. Caso de uso: dominios de alto riesgo donde ambos importan.

Ingeniería de prompts + ingeniería de prompts (en cascada) (infravalorado)

Usas un modelo barato para filtrado inicial, luego un modelo potente para salida refinada. Ejemplo: GPT-3.5 clasifica si un correo electrónico está relacionado con soporte (barato, rápido), luego Claude Sonnet 4 redacta una respuesta solo si lo está (ahorra dinero). Costo: dos llamadas API pero un 70% más barato en general. Latencia: aceptable si el primer modelo es rápido. Funciona bien para tareas de enrutamiento y filtrado.

Benchmarking de Tu Enfoque: Qué Medir

No puedes elegir la técnica correcta sin métricas de referencia. Antes de construir nada, mide:

• Precisión en un conjunto de prueba de retención (50–100 ejemplos en los que no entrenas). La precisión depende del contexto — 80% podría ser genial para algunas tareas, terrible para otras. Conoce tu objetivo.
• Costo por consulta (tokens × precio del modelo). Incluye costos de recuperación si usas RAG. Incluye el ajuste fino amortizado sobre el volumen de consultas esperado si afinas.
• Percentiles de latencia, no promedios (p50, p95, p99). La latencia promedio oculta la lentitud en las colas. Si el 1% de las consultas tardan 30 segundos, rompe la experiencia del usuario incluso si el promedio es de 2 segundos.
• Modos de fallo (no solo la precisión general). Clasifica tus errores: alucinaciones, errores de razonamiento, errores de formato, entrada ambigua. Diferentes técnicas fallan de manera diferente. Las alucinaciones apuntan hacia RAG. Los errores de formato apuntan hacia un mejor prompting o ajuste fino.
• Varianza entre tipos de entrada (no un número de precisión monolítico). Si tu modelo funciona muy bien en entradas cortas pero falla en las largas, tienes un problema estructural, no un problema de técnica.

Ejemplo de AlgoVesta: medimos la precisión de la extracción de señales de trading no como un solo número sino como:

• Precisión en informes recientes (2024): 91%
• Precisión en informes archivados (2020–2022): 73% (brecha de conocimiento)
• Precisión cuando se hace referencia a datos de precios: 88%
• Precisión en tickers de casos extremos: 62% (acciones raras, las alucinaciones se disparan)

Este desglose reveló que RAG resolvió el problema de 2020–2022 y el problema de referencia de precios (están en la base de conocimiento), pero no resolvió el problema de los tickers de casos extremos (el modelo necesita ajuste fino o mejor desambiguación de tickers en el prompt). Un solo número no nos habría dicho eso.

Qué Hacer a Partir del Lunes

Si te enfrentas a esta decisión ahora:

Paso 1: Elige una pequeña muestra (10–50 ejemplos) de tu caso de uso y mide la precisión de referencia con la opción más barata primero: GPT-3.5 Turbo con un prompt simple. Esto toma 30 minutos y te da un piso. Podría ser suficiente. A menudo no lo es.

Paso 2: Escribe un prompt más específico (consulta la sección anterior para las reglas de la plantilla de prompt). Mide de nuevo.** Generalmente una mejora del 5–15% sin costo. Detente si esto logra tu precisión objetivo. No sobrediseñes.