Smetti di scegliere tool AI prima di conoscere il problema

Ogni settimana qualcuno ci chiede quale strumento AI dovrebbe usare. GPT-4, Claude, Gemini, un modello open-source, un prodotto SaaS verticale con AI integrata. La lista cresce di continuo, e la domanda continua ad arrivare.

La risposta è sempre la stessa: dipende da cosa state cercando di risolvere. E nella maggior parte dei casi, chi fa la domanda non lo ha ancora capito.

La tentazione di partire dallo strumento è forte. Esce un nuovo modello, i benchmark sembrano impressionanti, e all’improvviso tutti vogliono costruire qualcosa con quello. Il problema è che partire dallo strumento significa progettare la soluzione attorno ai punti di forza dello strumento invece che attorno al vostro problema reale.

Un’azienda potrebbe scegliere GPT-4 perché è il modello più conosciuto, per poi rendersi conto tre mesi dopo che il proprio caso d’uso richiedeva solo una classificazione veloce ed economica. Hanno speso troppo in token, hanno sovra-ingegnerizzato la pipeline, e si sono ritrovati con qualcosa di più lento di quanto sarebbe stato un modello più piccolo e fine-tuned.

Succede più spesso di quanto si ammetta. Lo strumento diventa la strategia, e il problema di business reale passa in secondo piano.

Prima di valutare un qualsiasi strumento, rispondete a questa domanda: quale processo specifico nella vostra azienda è lento, costoso, soggetto a errori o impossibile da scalare con il team attuale?

Siate specifici. Non “vogliamo usare l’AI per il marketing”. Piuttosto: “Il nostro team dedica 12 ore a settimana a categorizzare manualmente i ticket di assistenza, e il 30% viene indirizzato al reparto sbagliato.” Quello è un problema risolvibile.

Una volta definito chiaramente il problema, potete lavorare a ritroso fino ai requisiti. La soluzione deve gestire immagini o solo testo? Deve funzionare in tempo reale o può girare in batch? Quanto deve essere precisa? Cosa succede quando sbaglia?

Sono queste domande a determinare lo strumento, non il contrario.

Dopo aver definito il problema e i requisiti, valutate gli strumenti rispetto a tre criteri.

Primo, adeguatezza funzionale. Lo strumento fa davvero ciò che vi serve? Non quello che potrebbe teoricamente fare, ma quello che fa in modo affidabile oggi, in produzione, ai vostri volumi. Leggete la documentazione, non la pagina marketing.

Secondo, costo totale. Non solo il prezzo per token, ma il tempo di ingegnerizzazione per integrarlo, la manutenzione continua, il costo degli errori e il costo di cambiare in seguito se non funziona. Un modello più economico che richiede il doppio del tempo di ingegnerizzazione non è più economico.

Terzo, flessibilità. Potete sostituire il modello sottostante senza ricostruire l’intero sistema? Se costruite tutto attorno all’API di un singolo provider, siete vincolati. Quando un modello migliore arriverà il prossimo trimestre — e arriverà — vorrete poterlo inserire, non ricominciare da capo.

A volte lo strumento giusto è il modello frontier più costoso. A volte è un modello open-source fine-tuned che gira sulla vostra infrastruttura. A volte non è affatto AI. Un sistema basato su regole ben progettato può superare un language model per certi compiti, e non costa nulla per inferenza.

Il punto non è evitare l’AI. Il punto è partire dal problema, definire i requisiti, e poi scegliere lo strumento adatto. Quell’ordine conta. Invertitelo, e vi ritroverete con una soluzione costosa alla ricerca di un problema per giustificare la propria esistenza.

Il vostro team merita di meglio. E anche il vostro budget.