Las dos preguntas
Cuando un sistema de IA llega a una empresa se hace siempre la misma pregunta: ¿funciona? Y se contesta siempre igual: alguien lo prueba un rato en la reunión, le parece que sí, y se aprueba.
Hay dos problemas con eso, y el segundo es peor.
El primero es que probar un rato no es medir. En la reunión se pregunta lo fácil, nadie anota lo que salió raro y a la semana siguiente nadie recuerda qué se preguntó.
El segundo es que nadie hace la otra pregunta, la de cuánto cuesta cada respuesta. Y esa es la que apaga proyectos que funcionaban 😐
Cómo se comprueba que funciona
Con una lista. Nada más que eso, y es sorprendente lo poco que se hace.
Te sientas con quien sabe del tema y escriben veinte preguntas de las que ya conocen la respuesta correcta. Reales, de las que llegan de verdad, incluidas las incómodas. Se guardan en un archivo, con su respuesta al lado.
Después se le pasan al sistema y se cuenta cuántas contestó bien. Ese número es tu punto de partida, y no vale nada por sí solo. Lo que vale es lo que viene después: cada vez que alguien cambie algo, se vuelven a pasar las veinte. Ahí sabes si el cambio mejoró o empeoró, que es la pregunta que de verdad se hace todas las semanas.
A esa lista se le dice golden set en las propuestas, y a la práctica entera de medir así se le dice evals. Los nombres son en inglés y lo que hay debajo es un archivo con preguntas y respuestas.
Añade cinco preguntas más, de un tipo distinto: cinco cuya respuesta NO esté en ningún sitio. Esas miden si el sistema sabe decir "no lo sé", que es la mitad de lo que quieres de él, y es el fallo dos del capítulo 10 📄
Quién corrige las respuestas
Acá aparece la parte incómoda. Veinticinco preguntas se corrigen a mano sin drama. Doscientas, cada semana, no.
Lo que se hace entonces es usar otro modelo para corregir: se le da la respuesta correcta y la que dio el sistema, y se le pide que diga si coinciden. En las propuestas a eso le dicen juez automático o LLM as a judge.
Funciona razonablemente y tiene una trampa que conviene que sepas: el juez también se equivoca. Antes de confiarle la corrección, alguien tiene que corregir a mano un puñado de casos y comparar si el juez opinó lo mismo. Si el juez y la persona coinciden casi siempre, se le puede soltar la mano. Si no, estás midiendo con una regla torcida y con mucha confianza.
Y ahora la factura
Esta parte casi no se explica en español, así que vamos despacio.
Los modelos no se cobran por consulta ni por usuario. Se cobran por tokens, que son los pedacitos en que se parte el texto: más o menos tres cuartos de una palabra en castellano, a veces una sílaba, a veces una palabra entera.
Y se cobran dos veces, que es lo que sorprende a todo el mundo: se paga lo que entra y se paga lo que sale. Lo que entra suele ser mucho más de lo que crees, porque incluye las instrucciones del sistema, el historial de la conversación y, si hay RAG, los pedazos de documento que se le pegaron.
De ahí sale la cuenta que le puedes pedir a tu proveedor en una línea:
lo que cuesta una consulta, por las consultas que esperas al mes.
Si nadie te sabe decir la primera mitad, todavía no hay presupuesto. Hay una esperanza 🐣
Las tres formas de bajarla, sin tocar la calidad
Una: no le pases lo que no hace falta. Un sistema que le pega diez pedazos de documento a cada pregunta cuando con tres bastaba paga por siete de más, en cada consulta, todos los días.
Dos: no uses el modelo caro para todo. Los proveedores tienen varios modelos a precios muy distintos. Clasificar un correo en tres categorías lo hace bien el barato; redactar la propuesta al cliente quizá pida el caro. Repartir según la dificultad de la tarea se llama routing, y es donde está la mayor parte del ahorro.
Tres: guarda las respuestas que se repiten. Si cuarenta clientes preguntan lo mismo, no hace falta pagar cuarenta veces por generar lo mismo. Se guarda la primera y se sirve a las otras treinta y nueve. Eso es caché y es tan viejo como la informática.
Las tres las hace quien programa, y ninguna requiere que tú entiendas cómo. Lo que sí te toca es preguntar si están hechas, porque por defecto no lo están 🔌
La cifra que tiene que caber en una línea
Si te llevas una sola cosa del capítulo, que sea esta: un proyecto de IA en producción tiene que poder decir cuánto cuesta una respuesta y cuántas respuestas da al mes.
Con esas dos cifras se hace todo lo demás. Se compara contra lo que costaba hacerlo a mano, que es la cuenta del capítulo 18. Se ve venir el mes en que se abre a más gente. Y se sabe si tiene sentido crecer o no.
Sin esas dos cifras hay un sistema que funciona y una factura que sorprende. Y ya viste cómo termina eso.
Practica 💪
Cinco casos, tres de medir y dos de pagar 🐣
1. El acierto que no dice nada
Un proveedor te dice que su asistente acierta el 94%. ¿Qué preguntas antes de que esa cifra signifique algo?
Sobre qué preguntas, y quién las escribió. Un 94% sobre casos que eligió el proveedor no dice nada sobre tus casos.
La versión útil es al revés: le pasas tus veinticinco preguntas, las que escribiste tú con tu gente, y que la cifra salga de ahí. Y si el proveedor se resiste a que la prueba la escribas tú, eso ya es una respuesta.
2. El cambio que arregló una cosa y rompió otra
El asistente contestaba mal las consultas de garantía. El proveedor ajusta las instrucciones y ahora las contesta bien. Dos semanas después, las de facturación empezaron a salir raras. ¿Qué faltó?
Volver a pasar la lista entera después del cambio. Ese es el uso real del golden set y por eso la lista se guarda: no para saber cómo estamos hoy, sino para saber qué se rompió cuando se arregló otra cosa.
Pasa muchísimo. Las instrucciones de un sistema así se pisan entre ellas, y sin una lista fija no hay forma de notarlo hasta que se queja un cliente.
3. Las cinco que no tenían respuesta
De tus cinco preguntas cuya respuesta no existe en ningún documento, el sistema contestó las cinco con algo razonable. ¿Bien o mal?
Mal, y es el resultado más peligroso de toda la prueba. Un sistema que nunca dice "no lo sé" va a inventar el día que le pregunten algo que no está, y va a hacerlo con la misma voz de siempre.
Y fíjate que en la métrica de "cuántas contestó" esto ni aparece: contestó cinco de cinco. Por eso las cinco se cuentan aparte y se miden al revés.
4. La factura de la trampa
Vuelve al caso de arriba: 80 dólares con 200 consultas. ¿Cuánto costaba cada consulta y qué habría pasado si alguien lo mira antes de abrirlo a clientes?
40 centavos de dólar por consulta. Con esa cifra sobre la mesa, la pregunta "¿cuántas consultas esperamos al mes cuando lo abramos?" se hace sola, y 9.000 por 0,40 son 3.600 dólares antes de abrir nada.
Nadie habría cancelado el proyecto por eso. Se habría hecho lo del apartado de arriba: bajar lo que se le pasa, mandar las consultas simples al modelo barato y cachear las repetidas. Todo eso se hace antes, no después del susto.
5. El historial que se paga entero
Un asistente de atención mantiene la conversación completa con cada cliente, y algunas llegan a cuarenta mensajes. ¿Por qué el mensaje número cuarenta cuesta bastante más que el primero?
Porque se paga lo que entra, y lo que entra es toda la conversación otra vez. Cada mensaje nuevo se manda con los treinta y nueve anteriores pegados para que el modelo tenga contexto.
Por eso conversaciones larguísimas cuestan mucho más de lo que la gente supone, y por eso una de las cosas que hace quien programa es resumir lo viejo en vez de arrastrarlo entero.
6. Quién escribe las preguntas
Te toca armar la lista de veinticinco. ¿A quién sientas en esa reunión?
A quien contesta esas preguntas hoy. La persona de soporte, la del mostrador, quien lleva diez años respondiendo el teléfono. No al jefe del área y no al proveedor.
Porque las preguntas que hacen fallar a un sistema no son las del manual: son las raras que llegan de verdad, las que traen dos cosas mezcladas, las que están mal escritas. Esas solo las conoce quien las recibe.
Y hay un premio escondido: esa persona sale de la reunión sabiendo cómo se va a medir el sistema que le van a poner al lado, que es la mejor forma que conozco de que no lo reciba como una amenaza 🐣
Lo que te llevas
- Probar un rato no es medir. Se necesita una lista escrita de preguntas cuya respuesta ya conoces.
- Veinte con respuesta y cinco sin ella. Las cinco miden si sabe callarse, que es la mitad del trabajo.
- La lista se vuelve a pasar entera con cada cambio. Ahí es donde sirve de verdad.
- El juez automático se puede usar, pero antes hay que comprobar que opina lo mismo que una persona.
- Se cobra por tokens y se cobra dos veces: lo que entra y lo que sale.
- Se baja pasando menos, usando el modelo barato donde alcanza y cacheando lo repetido.
- Un proyecto en producción tiene que poder decir cuánto cuesta una respuesta y cuántas da al mes. Sin esas dos cifras no hay presupuesto.
Comprueba que se entendió
Comprueba que lo tienes
Vas a probar si el asistente de tu empresa responde bien. ¿Cuál de estas formas te dice algo de verdad?
- Escribir 20 preguntas cuya respuesta correcta ya conoces, guardarlas, y volver a pasarlas cada vez que alguien cambie algo
- Probarlo un rato en la reunión y ver si contesta bien
- Pedirle al proveedor su porcentaje de acierto
- Preguntarle al propio asistente si está seguro de su respuesta
Ya sabes si funciona y cuánto cuesta. Falta la pregunta fea: qué pasa cuando alguien de fuera quiere que tu sistema haga algo que tú no querías 🐥