La Brecha entre Capacidad y Fiabilidad
Aquí tienes un patrón que escarmienta a casi todo el mundo que lanza IA a usuarios reales por primera vez:
El modelo hace la cosa a la perfección en tu prueba. Falla en producción. Estás confundido, porque lo viste funcionar.
Con lo que te has topado es con la brecha entre capacidad y fiabilidad.
Capacidad significa que el modelo puede hacer una tarea: produce una salida correcta al menos una vez, bajo algunas condiciones.
Fiabilidad significa que el modelo hace la tarea correctamente de forma consistente: con entradas variadas, en ejecuciones repetidas, ante ligeros cambios de redacción o contexto.
Las demos demuestran capacidad. La producción exige fiabilidad. Son propiedades distintas, y la mayoría de las guías las confunden.
Por qué las demos mienten
Cuando pruebas un prompt, normalmente:
- Lo ejecutas sobre entradas que diseñaste tú mismo
- Lo ejecutas un puñado de veces
- Eliges con pinzas la salida que se ve bien
- Ajustas el prompt hasta que se ve correcto
Este proceso optimiza para la capacidad. El prompt ahora funciona sobre tus ejemplos. Has visto una salida correcta. Lo lanzas.
El problema es que las entradas de los usuarios en producción no son tus ejemplos. Son más desordenadas, más variadas, redactadas de maneras que no anticipaste. El modelo nunca se probó sobre ellas. No tienes ni idea de cómo se comporta con ellas.
Una única salida buena no es una estimación de rendimiento. Es una anécdota.
La varianza es la variable oculta
Los LLM son estocásticos. Ejecuta el mismo prompt dos veces y a menudo obtienes salidas distintas. Esta varianza es normal y suele estar bien. Pero significa que la pregunta relevante no es "¿funcionó?", sino "¿qué fracción de las veces funciona?".
Una tarea en la que el modelo acierta el 95 % de las veces se ve genial en una demo y se rompe con aproximadamente uno de cada veinte usuarios. Una tarea en la que acierta el 60 % de las veces se ve bien cuando eres tú quien la ejecuta. Son situaciones muy distintas, y no puedes diferenciarlas sin medir.
El espectro capacidad-fiabilidad en la práctica
| Dimensión | Capaz pero poco fiable | Fiable |
|---|---|---|
| Entradas probadas | Ejemplos diseñados por el autor | Entradas diversas, de usuarios reales |
| Tamaño de muestra | Unas pocas ejecuciones | Ejecuciones repetidas sobre muchos ejemplos |
| Visibilidad del modo de fallo | Los fallos son raros en pruebas, comunes en producción | Los fallos se miden y se entienden |
| Cómo te enteras de que se rompió | Quejas de usuarios | Tu conjunto de evals |
| Cómo lo mejoras | Adivinar y probar prompts | Seguir la tasa de aciertos, depurar fallos de forma sistemática |
| Confianza al desplegar | Basada en la intuición | Basada en la evidencia |
Las evals son el verdadero foso
Mejores prompts pueden elevar la capacidad. Solo las evals pueden decirte si has elevado la fiabilidad.
Una eval es una prueba estructurada: un conjunto de entradas, salidas esperadas o criterios de evaluación, y una forma de medir la tasa de aciertos. Ejecutas el modelo sobre las entradas, puntúas las salidas y obtienes un número. Luego cambias algo — el prompt, el modelo, la temperatura — y lo ejecutas de nuevo. Ahora tienes una señal.
Esto no es glamuroso. Es la parte del trabajo de producto con IA que la mayoría de los tutoriales se saltan por completo. Pero es la única forma de responder a la pregunta que de verdad importa cuando estás lanzando: "¿Con qué frecuencia funciona esto sobre entradas que no he visto?".
Una forma sencilla de empezar
No necesitas infraestructura para empezar. Aquí tienes un bucle de eval mínimo viable:
-
Construye un conjunto de referencia (golden set). Reúne entre 20 y 50 entradas reales o realistas. Para cada una, escribe cómo es una salida correcta (o los criterios para juzgarla). Estos son tus ejemplos de referencia.
-
Ejecútalo N veces. Ejecuta tu prompt sobre cada ejemplo varias veces. La varianza entre ejecuciones te informa sobre la estabilidad del prompt; la varianza entre ejemplos te informa sobre la cobertura.
-
Sigue la tasa de aciertos. Para cada par (entrada, ejecución), anota acierto o fallo. Calcula la tasa global. Ese número es el comienzo de tu foto de fiabilidad.
-
Conviértelo en un test de regresión. Cada vez que cambies el prompt, ejecuta la eval de nuevo. Si la tasa de aciertos baja, has roto algo. Si sube, has hecho una mejora real.
Eso es todo. Una hoja de cálculo funciona. La disciplina importa más que las herramientas.
Por qué esto es un problema de ingeniería, no de prompting
El instinto cuando un modelo falla es reescribir el prompt. A veces es lo correcto. Pero a menudo es una forma de optimizar para el caso de fallo que viste, a costa de regresionar en casos que no comprobaste.
La ingeniería de fiabilidad para IA se parece a esto:
- Definir qué significa "correcto" antes de ejecutar nada
- Medir contra una distribución de entradas representativa
- Seguir los cambios a lo largo del tiempo con una metodología consistente
- Distinguir "este modelo no puede hacer esta tarea" de "esta tarea está infraespecificada"
La ingeniería de prompts es una herramienta dentro de ese proceso. No es un sustituto de él.
El encuadre honesto
La mayoría de las capacidades de la IA son reales. Los modelos genuinamente pueden hacer cosas notables. La brecha entre capacidad y fiabilidad no es un argumento de que las capacidades sean falsas: es un argumento de que saber que existen no es suficiente.
Si necesitas que una tarea funcione el 95 % de las veces, necesitas evidencia de que funciona el 95 % de las veces. Esa evidencia viene de ejecutar pruebas estructuradas, no de la confianza en la demo.
Los ingenieros que construyen productos de IA duraderos no son necesariamente los que escriben los mejores prompts. Son los que saben qué significa "que funcione" antes de lanzar, y que tienen una medición que les dice si es cierto.