Su equipo tiene indicaciones repartidas por todo el código base. Algunos están en archivos de configuración. Algunas son cadenas codificadas. Algunos de los más importantes se encuentran en un documento de Google que mantiene una sola persona. Nadie recuerda por qué el mensaje del sistema para la función de resumen dice "responda como un útil bibliotecario británico", pero eliminar esa frase empeora el resultado, por lo que permanece.
Así es como la mayoría de los equipos administran los mensajes, y es aproximadamente el equivalente a escribir código sin control de versiones en 2005. Funciona hasta que deja de funcionar, y cuando deja de funcionar, no tienes idea de qué cambió o cómo solucionarlo.
Las retrospectivas de ingeniería inmediatas aportan la misma disciplina a las interacciones LLM que las retrospectivas de ingeniería aportaron al desarrollo de software: revisión sistemática, aprendizaje compartido y mejora incremental. Aquí se explica cómo hacerlo realmente.
El problema de las indicaciones ad hoc
La mayoría de los equipos desarrollan indicaciones a través de un ciclo que se parece a este: alguien escribe una sugerencia, la prueba con algunos ejemplos, la envía y continúa. Cuando la calidad de la salida se degrada o aparece un nuevo modo de falla, alguien modifica el mensaje basándose en el caso de falla específico, tal vez rompa otros tres casos en el proceso y el ciclo se repite.
Los problemas con este enfoque son:
Sin historia. Cuando cambia un mensaje, la versión anterior desaparece. Si la nueva versión es peor, no podrás revertirla fácilmente. Si alguien pregunta "¿por qué el mensaje dice esto?", nadie lo sabe.
Sin aprendizaje compartido. La persona que descubrió que agregar "pensar paso a paso" al mensaje de razonamiento mejoraba la precisión por un margen notable no comparte esa idea. La persona que escribe el siguiente mensaje aprende la misma lección desde cero.
Sin pruebas sistemáticas. Las indicaciones se prueban con cualquier ejemplo que se le ocurra, que suelen ser los casos fáciles. Los casos extremos, los insumos contradictorios y los cambios de distribución no se prueban hasta que fallan en la producción.
Sin medida. "El resultado se ve mejor" es el método de evaluación más común. ¿Mejor cómo? ¿Comparado con qué? ¿Medido por quién? Sin una evaluación consistente, no se puede saber si los cambios son realmente mejoras.
Una retrospectiva periódica aborda estos cuatro problemas.
Qué revisar en una retrospectiva inmediata
Reúna su evidencia
Antes de la retrospectiva, reúna:
Fallos de producción. Cualquier caso en el que una función impulsada por LLM produjo un resultado incorrecto que un usuario notó. Capture la entrada, el mensaje y la salida. Si tiene comentarios de los usuarios (aprobación, quejas, correcciones), inclúyalos.
Cambios rápidos desde la última retro. ¿Qué indicaciones cambiaron, cuál fue la intención detrás del cambio y qué sucedió después? Si está controlando la versión de sus mensajes (debería hacerlo), esta es una revisión de diferencias. Si no es así, este es el primer elemento de acción de tu retro.
Tendencias de métricas de calidad. Si realiza evaluaciones automatizadas (más sobre esto a continuación), mencione las tendencias. ¿Están mejorando las cosas? ¿Está empeorando? ¿Departamento?
Datos de costes y latencia. Las indicaciones afectan directamente a ambos. Un mensaje detallado del sistema que mejora la calidad por un pequeño margen pero duplica el uso de tokens es una compensación que vale la pena discutir explícitamente.
La conversación
Una buena retrospectiva rápida cubre tres preguntas:
1. ¿Dónde fallan nuestras indicaciones y por qué?
Clasifica tus fracasos. Categorías comunes:
- Instrucciones siguientes: El modelo no hizo lo que se le pidió. Generalmente significa que la instrucción es ambigua o contradice otra parte del mensaje.
- Violaciones de formato: El modelo devolvió JSON cuando quería texto sin formato, o viceversa. Generalmente se puede solucionar con especificaciones y ejemplos de formato más claros.
- Alucinación: El modelo generó información no respaldada por el contexto proporcionado. Esto podría ser un problema inmediato (instrucciones de conexión a tierra débiles) o una limitación del modelo.
- Deriva de tono/estilo: La salida suena diferente de lo previsto. Suele ocurrir cuando las indicaciones son largas y las instrucciones de estilo quedan ocultas.
- Fallos en casos extremos: El mensaje funciona con entradas típicas pero falla con las inusuales. Aquí es donde más duele la falta de pruebas sistemáticas.
Para cada categoría de falla, pregunte: ¿es este un problema rápido, un problema modelo o un problema de entrada? La solución es diferente para cada uno.
2. ¿Qué hemos aprendido sobre cómo impulsar este modelo?
Cada modelo tiene peculiaridades. GPT-4 responde de manera diferente al mismo mensaje que Claude y ambos cambian de comportamiento con las actualizaciones. Su equipo acumula conocimientos sobre estas peculiaridades a través del trabajo diario; la retrospectiva es donde ese conocimiento se comparte y documenta.
Cosas útiles para capturar:
- Técnicas que mejoran de manera confiable la producción (y para qué tipos de tareas)
- Enfoques que parecían que deberían funcionar pero no lo hicieron
- El comportamiento del modelo cambia después de las actualizaciones del proveedor.
- Patrones de indicaciones que funcionan bien para sus casos de uso específicos
Esto crea una base de conocimientos en equipo que evita que todos redescubran las mismas lecciones.
3. ¿Qué deberíamos cambiar o probar a continuación?
A partir de los fracasos y aprendizajes, identificar experimentos específicos. Buenos experimentos son:
- De alcance limitado (cambiar una cosa a la vez)
- Medible (defina qué significa "mejor" antes de realizar la prueba)
- Time-boxed (ejecutado por un período específico o número de evaluaciones)
Ejemplo: "Probaremos si agregar dos ejemplos del formato de salida deseado al mensaje de servicio al cliente reduce las infracciones de formato del 12 % a menos del 5 %, medido en más de 200 consultas de producción".
Construyendo una práctica de gestión rápida
Las retrospectivas son más efectivas cuando se cuenta con una gestión rápida básica. No necesita herramientas sofisticadas para comenzar, solo algunas prácticas.
Controle la versión de sus mensajes
Trate las indicaciones como código. Guárdelos en su repositorio, revise los cambios en PRs y etiquete las versiones. Esto le brinda historial, capacidad de reversión y supervisión de revisión. Si un cambio rápido degrada la calidad, puede ver exactamente qué cambió y revertirlo.
Para equipos con muchas indicaciones, considere una estructura de directorio dedicada:
indicaciones/
resumen/
sistema.txt
ejemplos-de-pocos-tiros.json
servicio al cliente/
sistema.txt
reglas-de-escalada.txt
clasificación/
sistema.txt
definiciones-de-etiqueta.json
Construir un conjunto de evaluación
Para cada mensaje importante, mantenga un conjunto de casos de prueba: pares de entrada-salida donde sepa cómo se ve una buena salida. No es necesario que sea enorme: entre 20 y 50 casos por mensaje que cubren el uso típico, casos extremos y modos de falla conocidos.
Ejecute su conjunto de evaluación cada vez que cambie un mensaje. Esto detecta las regresiones antes de que alcancen la producción. Inicialmente lleva tiempo desarrollarlo, pero ahorra mucho más tiempo que depurar fallas de producción.
Documente sus decisiones
Cuando realice un cambio rápido, escriba una breve nota: cuál fue el problema, qué cambió y por qué esperaba que ayudara. Esto parece una sobrecarga hasta tres meses después, cuando estás mirando un mensaje y te preguntas por qué incluye una instrucción aparentemente aleatoria que resulta ser crítica.
Formatos retrospectivos rápidos que funcionan
No todos los retro tienen por qué ser iguales. Aquí hay dos formatos que funcionan bien en diferentes cadencias:
La revisión rápida (30 minutos, cada dos semanas)
Para equipos que iteran rápidamente. Revise las fallas de producción desde la última sesión, analice los cambios de las indicaciones que se realizaron, comparta una idea de las indicaciones con cada uno y elija el experimento de mayor prioridad para las próximas dos semanas. Mantenlo ajustado y orientado a la acción.
The Deep Dive (90 minutos, mensual)
Para cuando necesites dar un paso atrás y mirar el panorama más amplio. Revise las métricas de calidad y las tendencias en todas las indicaciones. Elija el mensaje con peor rendimiento y realice un análisis exhaustivo: analice las fallas, analice la causa raíz, haga una lluvia de ideas sobre enfoques y diseñe un experimento adecuado. Revise también su biblioteca de mensajes y la documentación para ver si están obsoletos: ¿algunos mensajes están desactualizados o no se utilizan?
La revisión del incidente (ad-hoc)
Cuando una falla inmediata causa un incidente real que enfrenta al usuario, realice una revisión enfocada dentro de unos días. ¿Qué sucedió, por qué falló el mensaje, por qué nuestras pruebas no lo detectaron y qué agregamos a nuestro conjunto de evaluación para evitar este tipo de falla?
Errores comunes
Indicaciones de ingeniería excesiva. Las indicaciones más largas no siempre son mejores. Cada instrucción que agregue puede interactuar con todas las demás instrucciones de manera impredecible. Si su mensaje tiene más de 500 palabras, considere si está tratando de hacer demasiado en un mensaje y debería dividirlo en una cadena.
Optimización para la métrica incorrecta. Un mensaje que obtiene una buena puntuación en métricas automatizadas pero produce resultados que los usuarios encuentran inútiles no es un buen mensaje. Incluya la evaluación humana en su proceso, no solo la puntuación automatizada.
Ignorando el costo. Es posible que las mejoras inmediatas que dupliquen el uso de tokens no valga la pena por el aumento de calidad. Realice un seguimiento del costo por consulta junto con la calidad y haga concesiones explícitamente.
Solucionar síntomas en lugar de causas. Si sigue parcheando el mismo mensaje para nuevos modos de falla, es probable que el mensaje necesite un rediseño en lugar de otra curita. Sus datos retrospectivos mostrarán este patrón: un aviso que aparece en las listas de fallas en múltiples retrospectivas necesita una atención más fundamental.
No realizar pruebas con aportaciones adversas. Tus usuarios harán cosas que no esperas. Su retrospectiva debe incluir periódicamente una revisión de lo que sucede cuando el mensaje recibe entradas inusuales, hostiles o fuera de alcance. No espere a que se produzca un incidente de producción para descubrir que su aviso no tiene barreras de seguridad.
Empezando
No es necesario tenerlo todo resuelto para empezar. Aquí hay un primer paso mínimo:
- Elija su característica más importante impulsada por LLM.
- Recopile 10 fallas recientes (malos resultados, quejas de usuarios, cualquier cosa que no sea óptima).
- Pasa 30 minutos con tu equipo clasificando por qué falló cada uno.
- Identifique el patrón de falla más común y diseñe un experimento para abordarlo.
- Ejecute el experimento y revise los resultados en dos semanas.
Esa es su primera retrospectiva inmediata. Hazlo una y otra vez y desarrollarás el músculo. Los equipos con la mejor calidad de salida de IA no son los que tienen las indicaciones más inteligentes: son los que aprenden sistemáticamente de sus fracasos y nunca cometen el mismo error dos veces.
Prueba NextRetro gratis — Clasifique los fallos rápidos en categorías, vote sobre prioridades y realice un seguimiento de los experimentos de mejora en los sprints.
Última actualización: febrero 2026
Tiempo de lectura: 7 minutos
