Hace unos meses decidimos rehacer una parte de nuestro producto para que fuera un poco más parecido a lo que tiene que ser y no a lo que nos imaginamos hace 5 años.

El tema es que la película ha cambiado un poco, especialmente en estos 2 años y ahora no tiene sentido diseñar un producto sin incluir a la IA, LLMs —o como lo quieras llamar— en la ecuación. No es hype sino, entre otras cosas, la herramienta de interacción más potente humano-máquina inventada desde el ratón o la pantalla táctil.

El problema es que no todo es tan fácil como nos describen los gurús de Linkedin con bullet points, emojis y frases catchy. Como siempre, cuando te pones a construir algo real, te das cuenta de que nada es trivial, así que he venido yo a contarte mi película: cómo hemos planteado el nuevo diseño de Tinybird, la herramienta definitiva para masajear esos datos que se le atragantan a tu base de datos (qué te voy a decir yo si es lo que me da de comer).

Voy a partir de los principios que aplicamos. Somos bastante antihype, así que:

1. Usar IA sólo cuando y donde tenga sentido. Nada de meter un chat donde no toca, por meter algo.
2. Si puede ser invisible, mejor. A nadie le interesa una mierda la tecnología que uses sino el problema que solucionas. Si sois programadores, cuanto antes lo asumáis, mejor. Creedme.
3. Que sirva para eliminar tareas tediosas, no para reemplazar a personas. Por mucho que a los ejecutivos con mentalidad de tiburón se les haga la boca agua con el potencial ahorro de costes, de momento, estamos lejos de poder sustituir el criterio humano. Así que, diseñamos modelos para potenciar a los profesionales no para reemplazarlos.

1. Hacer el onboarding de nuevos usuarios. Qué mejor que el usuario te diga lo que quiere en vez de decirle tú lo que tiene que hacer para aprender.
2. Simplificar flujos de trabajo.
3. Generar código. Esto es algo más concreto y no todos los productos generan código, pero el nuestro sí.
4. Explorar los datos que el producto tiene disponibles de forma natural. Aquí es donde el chat con herramientas entra en la ecuación.

En general todo esto es sencillo: si usas chatGPT o similar, en unos minutos puedes tener una herramienta que permitirá a un usuario entender tu producto. En realidad no necesitas más que coger tu documentación y pedir a un LLM (usamos Gemini por la longitud de su contexto) que lo resuma. Va a ser capaz de resolver el 90 % de las preguntas de un ser humano. Pero claro, no deja de ser una conversación de persona a «no-persona» y, por mucho que la IA pueda interpretar instrucciones… las herramientas necesitan órdenes claras.

Por ejemplo, si pides a un editor de texto «borra todo el texto hasta el punto», puede borrar hasta el primer punto que se encuentre o hasta el último. Y ahí está el problema.

Déjame que intente explicarte cómo solucionamos nosotros estos problemas a través de un ejemplo, sin ponernos demasiado técnicos.

Cuando aterrizas en nuestro equipo, lo primero que tienes que hacer es crear un proyecto. Antes tenías que leer la documentación y usar un ejemplo, ahora puedes ejecutar directamente:

tb create –prompt “crea un proyecto para trackear las estadísticas de SUPERMONO, go beyond the inbox and build real relationships with your audience”

Para que los no técnicos puedan entenderlo: sería lo mismo que si a un programa de facturación le pidieras «crea una factura de mi empresa por valor de 3500 euros».
 
Y da igual que generemos código o una factura, ambas cosas pueden (y van a) salir mal. ¿Por qué? Por falta de contexto.
 
Bueno, de varios contextos. Primero el LLM necesita saber qué hace tu producto y qué hace tu cliente, aunque muchas veces lo hace mejor que un humano. Por ejemplo, si le pido a Gemini que me cree una factura, acierta bastante, añade el IVA, conceptos, cuenta del banco, fecha de vencimiento, incluso me pone «Servicios de Consultoría Estratégica» (se ve que entiende que daría la talla para trabajar en McKinsey), pero aun así necesita un prompt… el famoso prompt.
 
En el prompt nosotros damos contexto de nuestro producto y añadimos cosas que sabemos del usuario. Por ejemplo, en Tinybird hay una parte del producto que te permite explorar los datos preguntando en un chat. En este caso creamos un contexto con los datos del usuario, como las tablas que tiene en su base de datos, qué pinta tienen, las consultas que ha ejecutado, etc. Tiene un coste —tanto de pasta, como de tiempo— (el modelo necesita más tiempo), pero creemos que merece la pena esperar un poco para tener buena calidad en la respuesta.
 
Cuando lleguéis a este punto, es importante que os aseguréis de que vuestro proveedor de modelo no usa los datos que proporcionas al mismo. Especialmente si esos datos no son tuyos sino de tus clientes.
 
Para que tenga sentido y funcione bien, hemos invertido bastante tiempo. Te enseño qué pinta tiene por si puedo ahorrarte algo del tuyo. Y no porque «seamos seres de luz», sino porque no invertimos ni un segundo en intentar mantener nuestros prompts en secreto.

Es prácticamente imposible impedir que el sistema los filtre de una manera u otra. La clave está en la orquestación, no tanto en el prompt.
 
Otro de los problemas habituales es que los LLMs la lían parda. Se inventan más cosas que un niño de 6 años. Es un problema bien conocido, nada nuevo. Hay varias formas de intentar paliarlo. En nuestro caso, usamos dos: feedback loop y self evaluation.
 
Por un lado, no esperamos que un LLM responda bien a la primera cuando se le pide algo complejo como una consulta optimizada a una base de datos. Por eso, casi siempre, tendremos que meter un feedback loop, o pedirle que estime si el entregable que genera consigue el resultado que se solicitó inicialmente (aquí tienes muchos más detalles técnicos).
 
Por otro, validamos lo que generamos. Por ejemplo, si estuviésemos generando una factura podríamos validar que tiene todo (concepto, CIF, cantidad, IVA…). Puedes hacerlo con procesos manuales o automáticos, pero también puedes poner a otro modelo a validarlo. Un segundo modelo (con otro prompt específico) evalúa el entregable y, si falla, genera un error que el primer modelo puede usar para arreglarlo. No es milagroso, pero si combinas ambos procesos obtienes un sistema relativamente sólido.
 
Usamos otras decenas de cosas, por ejemplo etiquetas de marcado para segmentar la entrada. Especialmente cuando el prompt es largo, ayuda mucho darle «mascadito» cada tema. También usamos etiquetas para la salida, de esta forma podemos pedirle diferentes recursos en cada prompt (por ejemplo, una factura y el correo para enviar el cliente).
 
Otro truco es encadenar llamadas con diferentes prompts para poder enrutar las cosas por donde tocan. Por ejemplo, en nuestro caso, si hay que generar una gráfica, esto se hace con una herramienta específica que se dispara con una segunda petición específica. Esta técnica se denomina LLM chaining, por si os queréis tirar el pisto en las cervezotas de la próxima edición de vuestra conferencia técnica favorita.
 
Porque esto no tiene tanta «magia» como nos quieren hacer creer. Eso sí, requiere una adaptación «de carne a metal» que no es trivial. El criterio humano aún es necesario en todos los pasos, pero no creo que podamos dejar pasar ni un minuto más para usar la IA en nuestros productos y hacer la vida más fácil al usuario.