Cómo medimos si una funcionalidad de IA funciona de verdad

Una demo de IA se suele preparar con 5 o 6 ejemplos bien elegidos, y con ellos las respuestas salen muy bien. Cuando esa misma funcionalidad tiene que procesar cientos de casos reales, con erratas, fichas a medio rellenar y peticiones que nadie había previsto, los resultados cambian, a veces poco y a veces mucho. Si no hay forma de medirlo, nadie sabe cuál de las 2 cosas está pasando y la decisión de ofrecerla a los clientes se toma a ojo. Así medimos nosotros las funcionalidades de IA, con ejemplos de proyectos reales. Está pensado para quien tiene que decidir si una demo pasa a producción y para quien ha pagado por una funcionalidad de IA y quiere comprobar que hace lo que le prometieron.

Antes de escribir código acordamos con el cliente 3 cosas y las dejamos por escrito.

• Una cifra de negocio. Tiempo ahorrado por tarea, citas conseguidas, fichas completadas, consultas resueltas sin pasar a una persona. Es la cifra que le importa a quien paga el proyecto.
• Una cifra técnica. Normalmente, el porcentaje de aciertos sobre un conjunto de casos de prueba. Nos dice si el modelo hace bien su parte antes de mirar el negocio.
• El umbral. El valor a partir del cual merece la pena. Si una persona cataloga 40 fichas por hora y la IA acierta 6 de cada 10, puede ahorrar tiempo si corregir una sugerencia es más rápido que escribir desde cero, o puede que no. Hay que calcularlo en cada caso.

También tenemos en cuenta el punto de partida, es decir, lo que pasa hoy sin IA o con la solución más sencilla posible. En un recomendador, podríamos partir de una lista de «lo más popular primero», y la IA tiene que mejorarla para que compense la complejidad que añade.

Un conjunto de casos de prueba (en inglés, evaluation set) es una colección de casos reales, cada uno con la respuesta que una persona considera correcta. Con él se compara cada versión de la funcionalidad.

Los casos salen de los datos reales del cliente: documentos, fichas o consultas que ya se han resuelto. Metemos los fáciles, los habituales y los que dan guerra, como imágenes de mala calidad, fichas incompletas o preguntas ambiguas. Para empezar bastan unas pocas decenas bien elegidas, y el conjunto crece cada vez que en producción aparece un error que merece la pena guardar.

Las respuestas correctas las revisa alguien que conoce la materia, por ejemplo una archivera en el caso de las descripciones de carteles o una coordinadora en el de las psicólogas que encajan con cada caso.

El conjunto se vuelve a pasar cada vez que cambia el modelo, las instrucciones que se le dan (el prompt) o los datos con los que trabaja. En Carte, el catálogo de carteles que desarrollamos, se puede elegir desde el panel el modelo de IA de cada funcionalidad. Es cómodo para probar un modelo más nuevo o más barato, y cada cambio es un motivo para repetir la prueba antes de dejarlo puesto. Las trazas y los conjuntos de prueba los guardamos en Langfuse, que permite comparar 2 versiones caso por caso y ver cuáles han mejorado y cuáles han empeorado.

Con la funcionalidad en marcha, lo más útil es saber qué hace la gente con cada respuesta. Puede aceptarla tal cual, corregirla o ignorarla.

Para poder medirlo hay que diseñarlo desde el principio. En Carte, cada campo de la ficha guarda por separado 3 cosas: el dato original del archivo, la sugerencia de la IA y el dato que ha validado una profesional. La IA nunca sobrescribe la ficha original. Como las 3 cosas están separadas, el porcentaje de sugerencias aceptadas sin cambios sale directamente de la base de datos, y también los campos que más se corrigen, que suelen ser los primeros que hay que mejorar.

También miramos los casos que pasan a una persona. Preferimos que la funcionalidad derive el caso cuando no tiene suficiente seguridad a que devuelva siempre una respuesta. La cifra que hay que vigilar es cuántos casos pasan a revisión y si baja a medida que la funcionalidad mejora.

Una respuesta correcta que tarda 20 segundos puede no servir a alguien que está al teléfono con un cliente, y si cada consulta cuesta demasiado, el coste puede superar lo que se ahorra en tiempo. Por eso medimos, para cada versión, el coste medio por respuesta y el tiempo de respuesta junto con los aciertos, y los comparamos con el umbral que se acordó al principio.

Ahí se decide también el cambio de modelo. Cada pocos meses sale un modelo nuevo, muchas veces más barato o más rápido. Antes de cambiar, pasamos el conjunto de prueba con el modelo nuevo y comparamos aciertos, coste y tiempo de respuesta. Si iguala o mejora en los 3, se cambia. Si gana en coste y pierde en calidad, decide el cliente con las cifras delante.

Carte: catalogación con revisión humana

Carte es un catálogo digital de más de 7.500 carteles históricos. La IA analiza cada cartel y sugiere descripciones, iconografía y temas, y una profesional revisa y aprueba cada sugerencia antes de que pase a ser dato validado. Como las sugerencias aceptadas, corregidas y rechazadas se guardan por separado, con ellas se ve dónde ayuda la IA y dónde no. Cuando probamos otro modelo, pasamos los mismos casos de prueba y miramos esas mismas cifras.

La Psicóloga en Casa: recomendación de psicóloga

En La Psicóloga en Casa, la IA propone qué psicólogas encajan con cada caso según sus especialidades y su disponibilidad, y la coordinadora elige. La señal más clara es cuántas veces elige entre las propuestas y cuántas busca fuera. Cada vez que se sale de la lista conviene preguntar por qué: puede que el perfil de una psicóloga esté incompleto o que haya un criterio que el modelo no tiene en cuenta. Lo contamos con más detalle en cómo añadir un sistema de recomendación a tu producto.

Lectura de facturas en una campaña

En una campaña para instaladores, los usuarios suben sus facturas de compra y la IA lee los importes. Cuando no puede leer un importe con suficiente seguridad, la factura pasa directamente a «pendiente de revisión» y la IA no intenta adivinarlo. Aquí miramos cuántas facturas se leen sin problemas y cuántas se quedan pendientes, porque son las que cuestan tiempo.

Si vas a encargar una funcionalidad de IA, o a comprar una ya hecha, haz estas preguntas al proveedor antes de firmar.

• ¿Cómo sabremos que funciona? ¿Con qué cifra de negocio y qué cifra técnica, y a partir de qué umbral merece la pena?
• ¿Qué casos de prueba vais a usar, de dónde salen y quién los revisa?
• ¿Qué pasa cuando cambiéis de modelo o de instrucciones? ¿Repetís las pruebas antes de publicar el cambio?
• ¿Qué se registra en producción? ¿Puedo ver qué respuestas se aceptaron, se corrigieron o se ignoraron?
• ¿Qué hace la IA cuando no está segura? ¿Pasa el caso a una persona?
• ¿Cuánto cuesta cada respuesta, cuánto tarda y cómo me lo vais a contar?

Si la mayoría de las respuestas son vagas, no habrá forma de comprobar si la funcionalidad hace lo que promete. Es el mismo principio que aplicamos en los proyectos de RAG corporativo y en todo nuestro trabajo de desarrollo de IA a medida.

Si tienes una funcionalidad de IA y no sabes si funciona, cuéntanos qué hace y te decimos cómo lo mediríamos.