Itera el prompt antes de actualizar el modelo

La demo de este video fue grabada en agosto de 2026. Se ejecutó en Claude Haiku 4.5, Claude Sonnet 5 y Claude Opus 5. Los resultados serán distintos en modelos más nuevos. La demo de cada lección es una ejecución de evaluación independiente, por lo que sus puntuaciones y costos no coincidirán con los de otras lecciones.

Una puntuación de evaluación baja indica que un modelo se equivocó en demasiados casos, pero no dice si la culpa es del modelo o de tu prompt.

Revisa primero el prompt, porque un modelo más grande eleva el precio de cada solicitud que envíes después del cambio. Cambiar el prompt toma unos minutos, y puedes probar el cambio de inmediato.

Meridian, una consultoría de ingeniería ficticia, tiene un prompt que extrae tres campos de cada informe mensual de proyecto: el ID del proyecto, el estado del cronograma y el riesgo principal. Su evaluación es una prueba de 50 casos, cada uno un informe emparejado con su respuesta esperada.

Claude Sonnet 5 y Claude Opus 5 acertaron los 50. Claude Haiku 4.5 cuesta lo menos de los tres, pero solo obtuvo 84%, por debajo del umbral de precisión, que es el 90% que Meridian exige antes de usar un modelo.

Antes de que Meridian gaste más en un modelo más grande, sigue cinco pasos:

1. Leer los casos fallidos y encontrar lo que tienen en común.
2. Elegir correcciones para las respuestas no respaldadas.
3. Escribir los cambios en el prompt.
4. Volver a ejecutar los 50 casos en los tres modelos.
5. Revisar cada columna y luego decidir sobre una actualización.

Leer los casos fallidos y encontrar lo que tienen en común

Ordena los casos fallidos por el tipo de informe que es cada uno y por el campo en el que falló. Una puntuación cuenta los fallos, pero no puede explicarlos. Leer lo que falló te muestra qué salió mal y por qué, y así es como aprendes si culpar al modelo o al prompt.

Los 50 casos de Meridian son 30 informes típicos, 10 que abarcan varios proyectos y 10 casos de riesgo faltante, donde el informe no tiene sección de riesgo. La tabla muestra cómo le fue a Haiku 4.5 con el prompt antiguo, el que Meridian usaba al inicio.

Haiku 4.5 con el prompt antiguo falló en 8 de los 50 casos.

Cinco de los ocho fallos son casos de riesgo faltante, todos en top_risk. Cada uno debería haber devuelto null, pero el modelo escribió una oración nombrando un riesgo cada vez. El caso r045 es uno de ellos.

El permiso solo recibe una nota de rutina, y el propio informe dice que no se espera ningún problema, pero aun así el modelo lo eligió como el riesgo principal.

La línea de top_risk del prompt antiguo terminaba en "o null", lo cual permitía null pero nunca le decía al modelo cuándo aplica. Cuando los fallos se agrupan en un tipo de informe y un campo, suelen compartir una causa, y aquí el prompt omitió algo.

Elegir correcciones para las respuestas no respaldadas

Elige tus correcciones entre cinco formas estándar de hacer que las respuestas no respaldadas sean menos frecuentes. Una respuesta no respaldada, una que el documento no sustenta, también se llama alucinación. Las primeras tres formas a continuación son pasos básicos que reducen la frecuencia de las alucinaciones.

1. Permitir que diga "no lo sé". Indícale al modelo qué debe devolver cuando el documento no contiene la respuesta, que para Meridian es null.
2. Citar antes de responder. Haz que el modelo extraiga primero la oración que respalda su respuesta, y luego responda a partir de esa oración.
3. Citar de vuelta al documento. Después de que el modelo responda, haz que encuentre una cita que respalde cada afirmación y retire cualquier afirmación que no pueda respaldar. Una persona puede entonces verificar cada afirmación que quede.
4. Agregar un paso de verificación. Envía una segunda solicitud cuyo trabajo sea verificar la respuesta que dio la primera solicitud.
5. Restringir el conocimiento externo. Indícale al modelo que responda solo a partir del documento y que deje fuera lo que aprendió durante el entrenamiento.

Meridian usa las dos primeras, porque la primera cubre exactamente el vacío que encontró el paso 1. La segunda hace que cada respuesta coincida con una oración del informe. Ambas requieren solo una línea o dos agregadas al prompt que Meridian ya tiene.

Escribir los cambios en el prompt

Indica en el prompt cuándo null es la respuesta correcta, y pide la cita antes de la respuesta. El recuadro a continuación contiene el nuevo prompt, que es el prompt de Meridian con ambos cambios hechos. Encuentra la línea que hace cada trabajo, y una nota indica qué cambió.

Toma de nuevo el caso r045. Ahora el modelo debe señalar una oración que muestre un riesgo, y las propias palabras del informe no muestran ninguno: "el equipo no anticipa ningún problema con la renovación." Cuando un informe no contiene una oración así, el nuevo prompt indica qué devolver: <source>none</source>, luego null.

Tu código tiene también una tarea nueva. Dado que ahora la cita aparece primero en la respuesta, el texto completo ya no es JSON válido, y json.loads sobre él falla. Analiza solo lo que sigue a la etiqueta de cierre </source>.

answer = json.loads(text.split("</source>")[-1])

Volver a ejecutar los 50 casos en los tres modelos

Vuelve a ejecutar la evaluación con el nuevo prompt, manteniendo los mismos 50 casos y los mismos tres modelos.

La proporción de casos en los que Haiku 4.5 acertó, con el prompt antiguo y con el prompt nuevo.

Ninguna de las cinco respuestas no respaldadas volvió a aparecer, y Haiku 4.5 ahora puntúa por encima del umbral de precisión.

En la siguiente tabla, el costo de ejecución es el precio de una pasada de un modelo por los 50 casos, y el costo por tarea completada divide eso entre el número de respuestas correctas.

Los tres modelos con el nuevo prompt en 50 casos, frente a un umbral de precisión del 90%, a los precios estándar de agosto de 2026. Consulta los precios actuales.

Ahora todos los modelos superan el umbral, así que eliges según el costo por tarea completada, y el de Haiku 4.5 es el más bajo.

Revisar cada columna, y luego decidir sobre una actualización

Observa cada columna en ambas ejecuciones, no solo la que te propusiste corregir. Un cambio que ayuda a un tipo de caso puede romper otro, así que verifica eso después de cada cambio.

Cuenta las respuestas no respaldadas y cualquier respuesta correcta que se haya vuelto incorrecta. Meridian no perdió ninguna de sus respuestas correctas.

Los tres casos típicos que habían fallado en schedule_status pasaron esta vez, aunque ningún cambio tocó la línea de ese campo. Un modelo puede responder al mismo caso de forma distinta de una ejecución a otra, así que ejecuta cada configuración dos o más veces antes de confiar en una puntuación.

Sigue cambiando el prompt y volviendo a ejecutar mientras la puntuación se mueva. Cuando deje de moverse por debajo de tu umbral de precisión, al modelo le falta una capacidad, y es entonces cuando toca actualizar.

La conclusión

1. Comienza leyendo los casos fallidos, agrupados por el tipo de informe que es cada uno y el campo en el que falló.
2. Corrige lo que el prompt omite indicando qué devolver cuando el documento no tiene respuesta y pidiendo la cita primero.
3. Vuelve a ejecutar los mismos casos dos o más veces, y verifica que las respuestas no respaldadas disminuyan mientras ninguna respuesta correcta se vuelva incorrecta.
4. Actualiza a un modelo más grande solo una vez que los cambios de prompt dejen de mover la puntuación.