Antes de tocar la arquitectura de tu agente, lee sus respuestas. Las que hagan falta.
Antes de plantearte si necesitas RAG o fine-tuning, siéntate y revisa 50 respuestas reales de tu agente, una detrás de otra. Sin ese paso previo, elegir entre ajustar el prompt, añadir recuperación de contexto o reentrenar el modelo es poco más que tirar una moneda al aire.
Llevo un tiempo aplicando ideas del libro Evals for AI Engineers directamente en mi código, y esto es lo que estoy haciendo en la práctica:
Con el system prompt ya definido, someto el agente a todo tipo de entradas a propósito: solicitudes claras, otras ambiguas, algunas incompletas y peticiones que directamente se salen del alcance previsto. Cada ejecución queda registrada en Langfuse, y en cada traza que falla anoto exactamente qué ha salido mal: «se ha inventado un dato», «ha ignorado el formato JSON», «no ha llamado a la herramienta correcta».
Después agrupo esas anotaciones por tipo de error y las cuento. Ese recuento es el que dicta qué hay que tocar, porque cada tipo de fallo tiene su propia solución:
→ Si la instrucción es confusa o está incompleta, el problema se resuelve en el prompt.
→ Si al modelo le falta información para responder bien, la solución es RAG o una tool adicional.
→ Si el fallo está en el parseo, en el retrieval o en la llamada a una herramienta, muchas veces el problema es el código, no el modelo.
→ Si la instrucción es clara, el contexto es el correcto y aun así falla, solo entonces tiene sentido plantearse el fine-tuning o cambiar de modelo.
Además, las trazas etiquetadas se convierten en un conjunto de regresión. Cada vez que modifico el prompt, lo ejecuto contra ellas para comprobar que he arreglado lo que tocaba sin haber roto nada más por el camino.
¿Cuántas trazas revisáis vosotros antes de decidir cambiar algo en la arquitectura?
Evaluación empírica de trazas antes de escalar la arquitectura de un agente LLM
Resumen técnico
El flujo propuesto establece una metodología de evaluación previa a cualquier decisión arquitectónica. Se instrumenta el agente con Langfuse para capturar trazas completas de ejecución. Se generan inputs categorizados: claros, ambiguos, incompletos y fuera de alcance. Cada falla se clasifica en tipos concretos: alucinación de datos, incumplimiento de formato JSON, fallo en llamada a tool o error de retrieval. El conteo por categoría determina la intervención: corrección de system prompt, incorporación de RAG, ajuste de código o, en último término, fine-tuning o sustitución de modelo. Las trazas etiquetadas constituyen un set de regresión reutilizable.
Análisis de implicaciones
Este enfoque desplaza la toma de decisiones del terreno especulativo al empírico. Técnicamente implica que RAG y fine-tuning dejan de ser opciones por defecto y pasan a ser intervenciones justificadas por evidencia cuantitativa. El set de regresión generado a partir de trazas reales introduce un ciclo de validación continua: cada modificación del prompt se evalúa contra casos previos, reduciendo la probabilidad de regresiones silenciosas. Separa además responsabilidades entre modelo, contexto y código, algo crítico para depurar agentes con múltiples tools y cadenas de llamadas.
Aplicación práctica
Con Langfuse se habilita el trazado completo en el agente y se etiquetan manualmente las ejecuciones fallidas con categorías fijas: hallucination, format_error, tool_miss, retrieval_fail. Un mínimo de 50 trazas permite identificar patrones estadísticamente relevantes. Si más del 60% de fallos corresponde a format_error, el problema es de instrucción o parseo, no de conocimiento del modelo. El libro Evals for AI Engineers formaliza este proceso con criterios de puntuación y plantillas de anotación aplicables directamente al código de evaluación.
Contexto del sector
La industria lleva años sobredimensionando soluciones: fine-tuning aplicado donde basta un mejor prompt, o RAG implementado sin diagnóstico previo. El auge de frameworks como LangSmith, Langfuse o Braintrust responde precisamente a la necesidad de hacer observabilidad sistemática antes de escalar. La evaluación basada en trazas reales se consolida como práctica estándar en equipos de AI Engineering maduros, alineada con el movimiento LLMOps.
