Iteré el prompt durante días y lo que subió la precisión fue cambiar de modelo
Pasé de 30,7 % a 100 % de días correctos leyendo cuadrantes de turnos. Casi nada de esa mejora vino del prompt, y la métrica que importaba no era la precisión.
Estaba construyendo un extractor que lee cuadrantes de turnos fotografiados y los convierte en un calendario. Es la pieza central de Turna, y la que decide si el producto sirve: el usuario no es técnico, no quiere otra app y solo va a dar una oportunidad. Si el primer cuadrante sale mal, no hay segundo intento.
Lo primero que hice, antes de la app, fue un banco de pruebas. Sin eso, «va mejor» es una impresión. Con eso es un número.
El banco de pruebas
Tres piezas: imágenes de cuadrantes (fixtures), la verdad de cada día anotada a mano en JSON (expected), y dos scripts, uno que llama al modelo con la imagen y guarda el resultado y otro que compara contra la verdad y genera un informe.
Quince cuadrantes en total. Ocho sintéticos, generados con HTML/CSS y capturados como imagen, para forzar casos concretos: noches con saliente, vacaciones parciales, una captura de WhatsApp con ruido de chat, una fila ambigua con dos personas de nombre parecido en la que el modelo tiene que rendirse en vez de adivinar. Y siete reales, conseguidos en grupos de Facebook: cafeterías y restaurantes españoles con turnos partidos y horas de cierre abiertas, y hospitales de Perú y Colombia con códigos que no significan lo mismo que en España.
Los números
| Corrida | Modelo | Prompt | Escala y consenso | Precisión | Falsos seguros |
|---|---|---|---|---|---|
| 1 | gpt-4o | v1 | — | 30,7 % | 148 |
| 2 | gpt-4o | v2 | — | 35,8 % | 138 |
| 3 | gpt-5.1 | v3 | ×2 + consenso | 68,8 % | 48 |
| 4 | gpt-5.4 | v3 | ×2 + consenso | 100 % | 0 |
| 5 | gpt-5.5 | v2/v3 | — | 96,3 % | 7-8 |
| 6 | gpt-5.5 | v3 | ×2 + consenso | 100 % | 0 |
| 7 | gpt-5.5 | v7, 15 fixtures | ×2 + consenso | 100 % | 0 |
La primera corrida dio 30,7 % de días correctos. Dediqué un buen rato a reescribir el prompt: más contexto, ejemplos, instrucciones más explícitas sobre la leyenda. Subió a 35,8 %. Cinco puntos.
Después cambié de generación de modelo sin tocar nada más y subió a 68,8 %. Un prompt afinado sobre el modelo nuevo, más dos ajustes técnicos, cerró en 100 % con cero falsos seguros. Entre la primera corrida y la última hay más de sesenta puntos, y el prompt explica cinco.
La métrica que de verdad importaba
La precisión es la métrica cómoda. La que decide si el producto sirve es otra: cuántos días lee mal y además afirma con total confianza. En la tabla es la última columna, y es la que había que llevar a cero.
Da igual que el 95 % esté bien si el 5 % restante llega al calendario del usuario sin ninguna marca. Alguien se presenta un domingo que tenía libre y desinstala la app. Un día dudoso y señalado es un incordio menor. Un día mal leído y silencioso es el final de la relación con ese usuario.
El modelo, por sí solo, nunca supo decir que no estaba seguro. Devolvía confianza 1.0 incluso en los días que fallaba. La única red que funcionó fue leer dos veces y comparar: si las dos lecturas no coinciden, el día se marca como dudoso y se pregunta. Es un mecanismo tonto, y es el que sostiene el producto.
Ampliar la imagen al doble
El ajuste que resolvió los últimos fallos no tiene nada que ver con el lenguaje: ampliar la imagen ×2 antes de enviarla.
Los fallos que quedaban no eran de lectura de caracteres, eran de alineación. En una tabla densa el modelo leía bien la celda y la asignaba a la columna de al lado. Con el doble de resolución, la alineación se sostiene. Es la palanca más infravalorada de todo el proyecto, y la más barata.
La regla que salió de una regresión
En una fixture peruana aparecía un código M/T, mañana y tarde combinadas.
Le enseñé al modelo que eso eran dos franjas. Funcionó para esa fixture y
rompió otra: generalizó MN, que es una guardia de 24 horas, como dos
bloques con un hueco en medio que no existía.
De ahí salió una regla que ahora es innegociable: un día tiene dos bloques solo si el documento imprime dos horarios separados, nunca por analogía con el nombre del código. Y otra del mismo tipo: la leyenda impresa en cada documento manda siempre sobre cualquier glosario general. La misma letra significa cosas distintas en centros distintos, y un glosario fijo de español de España rompía la lectura de los cuadrantes latinoamericanos. Ese segundo error, además, estaba en el evaluador, no en el prompt: la corrida v6 pasó de 95,2 % a 98,7 % solo con arreglar quién tenía la razón.
Lo que me llevo
Si estás peleando con un prompt y no avanzas, comprueba primero si el techo es del prompt. Muchas veces el trabajo está en la entrada (la resolución), en el modelo (la generación) o en la arquitectura alrededor (el consenso), y el prompt es donde miras porque es lo que sabes tocar.
Y una regla de proceso que vale más que cualquier hallazgo: ningún cambio de
prompt entra sin correr las quince fixtures completas y confirmar que
ninguna baja respecto a la versión anterior. La regresión de M/T la
detectó el banco, no yo.