Inference, contesto, eval: principi prima dei modelli

Quando un team inizia a costruire con AI, la conversazione cade quasi subito sulla scelta del modello. Meglio Fable, GPT, Gemini, Claude, un modello open source, un routing ibrido? È una domanda legittima, ma spesso arriva troppo presto.

Il modello conta. Sarebbe ingenuo dire il contrario. Ma in molti prodotti AI la differenza tra una demo interessante e un sistema affidabile non nasce solo dalla scelta del modello. Nasce da come gestisci inferenza, contesto, eval, fallback e review.

Sono parole meno spendibili in una headline, ma sono quelle che decidono se il sistema resta utile quando esce dal laboratorio.

L’inferenza non è una chiamata API

Nel linguaggio quotidiano, “fare inferenza” rischia di diventare sinonimo di chiamare un modello. In realtà, per un prodotto AI l’inferenza è il momento in cui una richiesta entra in un sistema e produce una risposta che qualcuno userà per decidere, scrivere, cercare, correggere o agire.

Dentro quel momento ci sono molte scelte: quale modello usare, con quale effort, con quale contesto, con quali strumenti, con quale memoria, con quale schema di output, con quali limiti di sicurezza e con quale fallback. Due team possono usare lo stesso modello e ottenere risultati molto diversi perché hanno progettato in modo diverso tutto ciò che sta intorno alla chiamata.

Questo è il motivo per cui la domanda “qual è il modello migliore?” spesso non basta. La domanda più utile è: migliore per quale task, con quale contesto, a quale costo, con quale margine di errore accettabile?

Harnessing: il sistema intorno al modello

Uso “AI harnessing” in senso operativo: non come slogan, ma come strato che tiene insieme modello, strumenti, contesto, limiti e responsabilità umana. Un modello potente senza harness resta una chiamata isolata; può rispondere bene in demo, ma diventa fragile quando deve lavorare dentro un processo reale.

Per un team questo significa progettare cosa entra nella richiesta, quali tool può usare il modello, quali output sono accettabili, quali passaggi richiedono review e quali condizioni devono fermare il flusso. Il valore non sta solo nel chiedere meglio al modello. Sta nel costruire il contesto operativo che gli permette di essere utile senza spostare il controllo fuori dal team.

Il contesto è parte del prodotto

I modelli non lavorano nel vuoto. Rispondono a quello che ricevono: istruzioni, esempi, documenti, memoria, tool, dati recuperati da retrieval, vincoli scritti nel prompt o nel sistema. Se il contesto è vago, sporco o incompleto, il modello può comunque produrre una risposta elegante. Ed è proprio lì che diventa pericoloso.

Un prodotto AI affidabile non tratta il contesto come un allegato. Lo tratta come materiale di prodotto: versionato, verificabile, aggiornato, ridotto quando è troppo rumoroso, arricchito quando manca ciò che serve. Nel caso di un assistant interno, ad esempio, la domanda non è solo “abbiamo collegato la knowledge base?”. Serve sapere chi la mantiene, come vengono gestite fonti vecchie, come si separa ciò che è certo da ciò che è obsoleto.

Lo stesso vale per Claude Code o per un coding agent. Il contesto non è solo il repository. Sono anche AGENTS.md, convenzioni, test, decisioni architetturali, vincoli di sicurezza, cose che il team dà per scontate ma che il modello non può indovinare.

Gli eval sono il punto in cui il prodotto smette di essere una demo

Hamel Husain ha scritto che molti prodotti AI falliscono perché non costruiscono sistemi di valutazione solidi. È una frase che risuona molto con quello che succede nei team: all’inizio si migliora con prompt engineering e tentativi manuali, poi il sistema cresce e il miglioramento diventa whack-a-mole. Sistemi una cosa, ne rompi un’altra.

Gli eval servono a uscire da quel ciclo. Non devono essere per forza sofisticati all’inizio. Possono partire da casi reali, esempi buoni e cattivi, controlli manuali, log di conversazioni, rubriche semplici. L’importante è che il team smetta di valutare il sistema solo con la sensazione del momento.

Un eval utile risponde a domande pratiche: il sistema recupera la fonte giusta? Rispetta i vincoli? Ammette quando non sa? Produce un output che qualcuno può usare senza riscriverlo da zero? Fallisce in modo leggibile? Migliora rispetto alla versione precedente?

Se queste domande non sono scritte da nessuna parte, ogni cambio modello, prompt o retrieval diventa una scommessa.

Fallback e review non sono dettagli difensivi

Molti sistemi AI vengono progettati immaginando il caso in cui tutto funziona. L’utente chiede, il modello capisce, il contesto è corretto, la risposta è buona. Ma il valore operativo si vede soprattutto quando qualcosa non torna.

Che cosa succede se il retrieval non trova abbastanza contesto? Se il modello è bloccato da una policy? Se il costo della chiamata supera il valore del task? Se un output sembra corretto ma tocca dati sensibili, codice critico o decisioni commerciali? Qui entrano fallback e review.

Un fallback non è una sconfitta. Può essere un modello diverso, una richiesta di chiarimento, un passaggio a un workflow umano, una risposta più prudente, un ticket. La review non è burocrazia se protegge i punti in cui l’errore costa davvero.

La maturità di un sistema AI si vede anche da come fallisce.

Cosa cambia per un PM builder

Il PM che costruisce con AI non deve diventare ricercatore di modelli. Deve però capire questi principi abbastanza bene da non delegare tutto alla scelta del vendor. Se l’unica decisione presa è “usiamo il modello più forte”, il prodotto resta fragile. Lo si vede bene anche nei modelli frontier: il caso Fable 5 mostra quanto contino accesso, safeguard, eval e fallback oltre alla capacità pura.

La parte interessante del lavoro è disegnare il sistema intorno al modello: quale contesto fornire, quali task affidare, quali errori sono accettabili, come misurare qualità, quando fermarsi, quando chiedere a una persona. Questo è prodotto tanto quanto è tecnica.

Un modello migliore può aumentare il margine. Ma se mancano contesto, eval e review, quel margine viene spesso consumato da errori più difficili da vedere.