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. 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, 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, donde también tengo el club de lectura en Mataró.
Ahora sí, vamos al lío. Estoy utilizando mucho Decisions API 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. 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 predecible facilita la integración, pero no convierte cada clasificación en infalible. Sigue haciendo falta probar cómo responde con nuestros casos.
Otro ejemplo que os cuento es la moderación de contenido en Wikitas. Me interesa detectar datos de contacto dentro de los textos de los planes, incluso cuando alguien intenta escribir un teléfono de una forma poco habitual. La decisión puede servir para activar un filtro o una revisión dentro de la aplicación. No significa que la API tenga que reescribir por sí sola todo el anuncio.
Podemos aplicar una lógica parecida para detectar insultos, contenido que incumple las normas o mensajes que necesitan una revisión especial. En cada caso, lo útil es decidir qué queremos detectar y qué acción debe realizar el sistema después.
Y aquí entran los umbrales. Una probabilidad no nos obliga a actuar siempre de la misma manera. Podemos establecer cuándo basta con clasificar automáticamente y cuándo preferimos avisar a una persona. En el audio pongo ejemplos con distintos porcentajes y con notificaciones por Slack o Telegram. Son ejemplos para entender el mecanismo, no valores que debamos copiar sin probarlos.
Una de las razones por las que me está gustando tanto es la velocidad y el coste que estoy viendo en mis pruebas. En la grabación comento cálculos de entre uno y cinco céntimos de dólar por cada mil decisiones con entradas pequeñas. No es una tarifa fija por decisión. El consumo depende de los tokens de entrada, así que conviene consultar la tarifa vigente y hacer los números con nuestros propios datos.
También os hablo de Jev, de TypeSafe, otra propuesta que he estado probando para este tipo de trabajo. Me interesa tener alternativas y entender qué aporta cada una, sin dar por hecho que todas ofrecen exactamente las mismas funciones.
Entre las diferencias que comento está box, una función de Jev para localizar un elemento dentro de una imagen mediante un recuadro. No solo se trata de preguntar si aparece un perro, sino de indicar dónde está. TypeSafe presenta esta capacidad, junto con el soporte de imágenes, como experimental en Jev 1.14, así que conviene tenerlo en cuenta antes de llevarla a un proceso importante.
En definitiva, no os recomiendo forzar el uso de una API de decisiones en todos los proyectos. Os recomiendo tenerla en el arsenal de herramientas. Cuando necesitamos clasificar mensajes, repartir solicitudes, priorizar tareas o categorizar gastos, puede encajar mucho mejor que pedir una respuesta larga a un modelo y analizarla después.
Como siempre, muchísimas gracias por vuestras valoraciones de cinco estrellas en Apple Podcasts y Spotify, por estar al otro lado y, especialmente, por suscribiros a los cursos y hacer que todo esto sea sostenible. Nos escuchamos mañana viernes con más marketing online, como siempre, a las siete y siete. ¡Muy buenos días!
More episodes from "Marketing Online"
Don't miss an episode of “Marketing Online” and subscribe to it in the GetPodcast app.
