En els últims mesos gairebé tots els clients que arriben a Liquid ens pregunten per IA en algun moment de la conversa. A vegades és un chatbot, a vegades és automatitzar respostes, a vegades és generar contingut. Ens ho pregunten tant startups que volen validar una funció ràpid com empreses que volen posar IA en un procés que ja fa anys que fan d'una altra manera. Tant se val el cas concret: hi ha un seguit de preguntes que gairebé ningú es fa al principi i que, quan el projecte ja està en producció, es converteixen en un problema.
Nosaltres mateixos hem passat per això construint eines internes amb IA per al nostre propi ús, i algunes de les preguntes que plantegem aquí les vam aprendre perquè ens va tocar resoldre-les sobre la marxa.
Què passa amb les dades que envies al model?
Quan connectes el teu producte a un model de llenguatge, part de la informació dels teus usuaris surt de la teva infraestructura i viatja a un tercer. Pot ser text que escriuen, documents que pugen, dades del seu compte que fas servir per personalitzar la resposta. Abans de fer aquest pas convé saber exactament què s'envia, on es processa i si aquest proveïdor guarda aquestes dades per entrenar els seus propis models o les descarta després de respondre. La majoria de proveïdors seriosos ho deixen força clar a la seva documentació, però cal llegir-ho, no donar-ho per fet.
Què passa si el model respon malament?
Els models fallen. A vegades de forma evident, a vegades de forma subtil i molt més perillosa: responen amb seguretat una cosa que no és correcta. Abans de llançar qualsevol funcionalitat amb IA val la pena pensar què passa en aquest escenari. L'usuari pot notar l'error? Hi ha alguna manera que aquest error tingui conseqüències reals, com un preu mal calculat o una recomanació mèdica o legal? Com més crítica sigui la decisió que pren el model, més falta fa un pla B per quan s'equivoqui.
Qui revisa el que genera?
Aquí és fàcil caure en dos extrems. Un és no revisar res i confiar que el model encerta sempre, cosa que tard o d'hora surt malament. L'altre és revisar-ho absolutament tot a mà, cosa que mata l'avantatge d'haver automatitzat. El punt intermedi passa per decidir amb criteri què mereix revisió humana abans de publicar-se o enviar-se, i què es pot deixar passar directament perquè el cost d'un error allà és baix. Aquesta decisió canvia segons el projecte i convé prendre-la de forma conscient.
Com es controla el cost quan això creix?
Un prototip amb IA sol costar poc perquè s'utilitza poc. El problema apareix quan aquest prototip funciona i l'ús es multiplica. El cost per crida al model, multiplicat per milers d'usuaris, pot convertir-se en una partida de despesa seriosa. Val la pena calcular aquest escenari abans de comprometre's amb una arquitectura concreta, i deixar marge per canviar de model o de proveïdor si el cost es dispara. En el nostre propi side project ens vam trobar precisament amb això: el que funcionava bé amb pocs usuaris de prova s'havia de replantejar en quant l'ús va començar a créixer de debò.
Quina part del procés continua necessitant una persona?
Gairebé cap projecte d'IA elimina del tot el treball humà, el redistribueix. Algú ha de definir què ha de fer el model, revisar els casos límit, ajustar el comportament quan alguna cosa no funciona com s'esperava i decidir quan cal apagar o limitar una funcionalitat. Tenir això clar des del principi evita la sorpresa de descobrir, mesos després del llançament, que l'equip continua dedicant tant temps com abans, només que a tasques diferents.
Abans de decidir, una segona opinió ajuda
Cap d'aquestes preguntes té una resposta universal. Depèn del producte, del pressupost i del risc que es pugui assumir en cada cas. El que sí compensa és plantejar-se-les abans d'escriure la primera línia de codi, quan encara es poden canviar les coses sense que ningú noti el canvi. A Liquid fa temps que ajudem a prendre aquestes decisions amb criteri, i si vols una segona opinió abans de posar IA al teu producte, aquí pots veure com treballem l'assessorament d'IA.
