Tienes un problema que necesita que un LLM lo resuelva. Ahora te enfrentas a tres caminos: ajustar un modelo, diseñar un mejor prompt o construir un pipeline de generación aumentada por recuperación (RAG). Cada uno cuesta diferentes cantidades de tiempo y dinero. Cada uno falla de diferentes maneras. Elegir mal te quema semanas.
La Tensión Central: Comportamiento vs. Conocimiento vs. Ambos
Antes de elegir, comprende qué cambia realmente cada enfoque.
Ingeniería de Prompts modifica cómo un modelo razona a través de una solicitud única. No estás cambiando los pesos del modelo. Estás cambiando la entrada.
RAG cambia el contexto que ve el modelo. Recuperas documentos o datos relevantes, los inyectas en el prompt y dejas que el modelo trabaje a partir de esa información fundamentada en lugar de depender de datos de entrenamiento de hace 6 meses.
Ajuste Fino cambia el modelo en sí. Reentrenas los pesos con ejemplos específicos de la tarea hasta que el modelo internaliza los patrones que te importan. Este es el único enfoque que realmente hace que el modelo recuerde algo nuevo.
Estos no son competidores. Son capas. Y la mayoría de los sistemas de producción usan dos o los tres.
Cuándo Gana la Ingeniería de Prompts (A Menudo Es Suficiente)
Empieza aquí. En serio. La ingeniería de prompts es gratis si ya estás pagando por acceso a la API.
Funciona cuando:
- El modelo ya sabe cómo resolver el problema — solo necesita instrucciones más claras
- Los fallos son de razonamiento inconsistente, no de conocimiento faltante
- Tu tarea implica razonar sobre información con la que el modelo fue entrenado
Ejemplo: Necesitas que Claude Sonnet 4 extraiga datos estructurados de correos electrónicos de clientes. Un prompt crudo falla el 15% de las veces porque el modelo omite campos o inventa valores.
Prompt malo:
Extrae datos del cliente de este correo electrónico:
{email_text}Prompt mejorado:
Extrae datos del cliente de este correo electrónico. Devuelve solo JSON válido. Si un campo no está presente en el correo electrónico, usa null. No inventes valores.
Campos requeridos: nombre, email, teléfono, empresa, categoría_incidencia
Correo electrónico:
{email_text}
JSON:La segunda versión reduce la tasa de error al 3% en la mayoría de los casos. Sin reentrenamiento. Sin bases de datos vectoriales. Solo especificidad sobre el formato, las restricciones y qué hacer cuando falta información.
Costo: 30 minutos de iteración.
Cuándo RAG Soluciona lo que el Prompting No Puede
RAG no es para problemas de razonamiento. Es para problemas de conocimiento.
Usa RAG cuando:
- Al modelo le falta la información que necesita (está en tus documentos, tu base de datos, tu historial de Slack, publicado después del corte de datos de entrenamiento del modelo)
- Necesitas que el modelo cite fuentes o haga referencia a documentos específicos
- Tu base de conocimiento cambia más rápido que las actualizaciones del modelo (documentos de producto trimestrales, precios en vivo, políticas específicas del cliente)
Escenario real: El equipo de soporte necesita un LLM para responder preguntas sobre tu producto SaaS. Tu producto se actualizó tres veces desde los datos de entrenamiento de GPT-4o. El modelo inventa características que no existen y omite las nuevas.
La ingeniería de prompts no ayudará — el modelo literalmente no lo sabe. El ajuste fino es excesivo para algo que cambia cada mes. RAG es la respuesta: incrusta tus documentos más recientes, recupera secciones relevantes, inyéctalas en el prompt.
Ejemplo de configuración RAG en Python:
from anthropic import Anthropic
import json
client = Anthropic()
# Tus documentos como una base de conocimiento simple
KNOWLEDGE_BASE = {
