Description
Hoy os explico cómo utilizo Decisions API para clasificar información, detectar urgencias y automatizar decisiones con IA de forma rápida y económica.
Pero antes, recordemos que esta semana seguimos con el curso de Bunny.net (https://boluda.com/curso/bunny-net/) . Esta mañana trabajamos con el reproductor, incorporamos subtítulos e integramos los vídeos en WordPress. Por la tarde vemos cómo gestionar vídeos privados y consultar su analítica. Y mañana cerramos el curso con bases de datos y la API con Edge Scripting. ¡Todo preparado para trabajar con nuestros propios contenidos!
Hoy dedico el programa a quienes os habéis interesado por la quedada de podcasting que propongo en Mataró. La he llamado Pantumaca y podcast (https://wikitas.com/pantumaca-podcasts) , aunque el nombre y los churros están por decidir. La idea es reunir un mínimo de veinte personas para una jornada informal. Os hablo de esta propuesta en Wikitas (https://wikitas.com/) , donde también tengo el club de lectura en Mataró (https://wikitas.com/plan/club-de-lectura-en-mataro/) .
Ahora sí, vamos al lío. Estoy utilizando mucho Decisions API (https://developers.openai.com/api/docs/guides/decisions) en los proyectos que voy creando con inteligencia artificial. Es una herramienta de OpenAI, basada en Luna, que me viene especialmente bien cuando no necesito una explicación larga, sino una decisión concreta que pueda utilizar dentro de una automatización.
Imaginemos que recibimos un correo y queremos saber si es positivo, negativo o neutro. Podemos preguntárselo a un modelo conversacional, claro. Pero, si después un programa tiene que actuar según la respuesta, no me interesa recibir un párrafo diferente cada vez. Quiero una salida que el código pueda interpretar directamente.
La gracia está en pasar de una respuesta para leer a un resultado para actuar. No busco que me felicite por el correo recibido ni que me explique durante tres párrafos por qué parece positivo. Necesito clasificarlo, puntuarlo o comprobar una condición para que el siguiente paso del proceso sepa qué hacer.
Un ejemplo muy claro es el soporte. Si alguien pregunta por las características de un producto que todavía no ha comprado, quizá tenga sentido enviar el mensaje al equipo comercial. Si ya es cliente y necesita ayuda con lo que utiliza, puede corresponder al equipo técnico. Podemos tener un único punto de entrada y repartir los mensajes después de interpretar su contenido.
Lo mismo ocurre con las urgencias. No es igual preguntar por una ampliación de alojamiento que avisar de que la web y el correo han dejado de funcionar. Las dos consultas pueden ser importantes, pero no requieren la misma respuesta ni el mismo circuito de atención.
En el episodio distingo tres tipos de preguntas. El primero es predicate, que estima la probabilidad de que una condición sea verdadera. Podemos preguntar si hay un gato en una imagen o si un mensaje requiere atención urgente. El resultado permite trabajar con un valor entre cero y uno, en lugar de interpretar una frase.
Aquí importa el contexto. Pedir una factura no suele ser una urgencia, pero puede serlo si el mensaje explica que hay que presentarla dentro de tres horas. La utilidad no está solamente en encontrar una palabra, sino en valorar la situación descrita.
El segundo tipo es choice, que permite elegir entre las opciones que hemos definido. Este es el que utilizo para las compras de Amazon que os contaba en el episodio sobre control de gastos con IA (https://boluda.com/podcast/3203-control-de-gastos-con-ia/) . Le paso el detalle del pedido y las categorías de mi aplicación para decidir dónde encaja.
Si he comprado una lámpara, puede ir a hogar. Si he comprado algo para una afición, puede ir a ocio. Lo importante es que podemos clasificar el gasto por lo que hemos comprado y no quedarnos únicamente con el nombre de Amazon que aparece en el banco. Y podemos hacer algo equivalente con departamentos, tipos de consulta o categorías de contenido.
El tercer tipo es score, pensado para valorar una entrada según niveles ordenados y criterios definidos. En el audio pongo ejemplos como el potencial comercial de un mensaje, la dificultad de una pregunta o la relevancia de una noticia para nuestro negocio. En la API conviene definir bien esos niveles, no limitarse a pedir una nota sin explicar qué significa.
También podemos plantear varias preguntas independientes sobre la misma información en una sola petición. Con un correo podemos evaluar la urgencia, decidir el departamento y valorar su interés comercial. Si una pregunta depende de la respuesta anterior, en cambio, debemos organizarlo en pasos separados. Así evitamos confundir compartir una entrada con encadenar decisiones dependientes.
La respuesta llega estructurada en JSON y la aplicación puede utilizarla para continuar. En lugar de buscar si el modelo ha escrito «sí», «efectivamente» o «de acuerdo», trabajamos con campos definidos. Un formato pred...