“Un utensile elettrico ha bisogno di un banco da lavoro. Il modello è la lama; il sistema è tutto ciò che ti tiene le dita attaccate.”
Modello sottile, sistema spesso
Una demo è un modello con un prompt. Un prodotto è un modello avvolto in retrieval, tool, guardrail, percorsi di fallback, logging ed eval. Il modello sarà forse il 5% del codice e il 90% della magia, ma il restante 95% del codice è ciò che rende quella magia abbastanza affidabile da poterci far pagare.
Il cambio di prospettiva più utile per costruire con l'IA è questo: smetti di provare a migliorare il modello, e inizia a migliorare il sistema attorno a esso. Di solito non puoi riaddestrare il modello. Puoi sempre migliorare ciò che gli dai in pasto, ciò che gli lasci toccare, e come verifichi il suo lavoro.
I quattro compiti del sistema
Tutto ciò che costruisci attorno al modello svolge uno di quattro compiti: far arrivare le informazioni giuste (retrieval), dare al modello vere capacità (tool), impedire che input e output dannosi causino danni (guardrail), e sapere se tutto questo funziona (eval). Il resto di questo corso dedica un capitolo a ciascun compito, più come spedire e gestire l'insieme.
Nucleo probabilistico, guscio deterministico
Il modello è probabilistico: lo stesso input può produrre output diversi, e non ha alcuna nozione di "corretto". Il tuo sistema dovrebbe essere il più deterministico possibile ovunque altro. Effettua il parsing dell'output del modello in uno schema rigoroso. Validalo. Se fallisce, riprova o ripiega. Non passare a valle un output del modello non validato sperando che vada bene.
Il pattern che funziona in produzione: tratta ogni chiamata al modello come una chiamata di rete a una terza parte inaffidabile. Può essere lenta, sbagliata, malformata o fuori servizio. Avvolgila di conseguenza (timeout, retry, validazione di schema, un percorso di fallback) esattamente come faresti con qualsiasi dipendenza capricciosa.
Inizia dalla cosa meno costosa che potrebbe funzionare
Esiste un ordine naturale di escalation, dal meno costoso al più costoso. Prova prima un prompt migliore. Poi aggiungi esempi. Poi aggiungi il retrieval. Poi aggiungi i tool. Solo dopo che tutto questo fallisce dovresti considerare il fine-tuning: è la leva più costosa, e quella che la maggior parte dei team aziona troppo presto.
- Prompt: pochi minuti, gratis. Prova sempre questo per primo.
- Esempi few-shot: pochi minuti, quasi gratis.
- Retrieval (RAG): qualche giorno, costo moderato. La risposta giusta a "non conosce i nostri dati".
- Tool: qualche giorno, costo moderato. La risposta giusta a "non sa fare i nostri compiti".
- Fine-tuning: settimane, costoso. L'ultima risorsa, non la prima mossa.
Una riga per ciascuno
- Il modello è un componente, non il prodotto. Il sistema attorno è la fonte dell'affidabilità.
- Tieni la parte probabilistica piccola e il guscio deterministico ampio: valida ogni output contro uno schema.
- Tratta le chiamate al modello come chiamate di rete capricciose: timeout, retry, fallback.
- Fai escalation dal meno costoso al più costoso: prompt → esempi → retrieval → tool → fine-tuning.
Dove andare ora