Collegare OpenAI o Anthropic al vostro prodotto: la scelta, il prompt, e il contesto che nessuno mette a budget

«Quale fornitore - OpenAI o Anthropic» viene chiesto in quasi ogni chiamata di kickoff come se fosse la decisione più grande del progetto. Quasi mai lo è. Entrambe le API fanno output strutturati, entrambe fanno tool/function calling, entrambe trasmettono in streaming, e le differenze che contano davvero - dimensione della finestra di contesto, prezzo per token, quanto rigorosamente un modello segue uno schema, come si comporta con istruzioni ambigue - si decidono testando i vostri prompt reali sui vostri dati reali, non con una classifica di benchmark.

Le decisioni che davvero plasmano la build arrivano dopo: come il prompt viene scritto e versionato come codice invece di essere ritoccato in un playground e dimenticato, come una risposta viene validata prima che la vostra app se ne fidi, e come gestite il contesto quando una conversazione, un documento o un job batch supera ciò che entra in una chiamata.

1. OpenAI contro Anthropic è raramente la decisione che conta

Scelgo in base al lavoro, non per fedeltà di marca: chi ha un supporto per gli output strutturati più rigoroso per una pipeline carica di schemi, chi ha una finestra di contesto che contiene davvero il documento in questione, quale livello di prezzo regge il volume di chiamate atteso, e - sottovalutato - chi ha un comportamento di rifiuto adatto a un caso d’uso vicino a un tema sensibile. Due fornitori diversi possono entrambi «funzionare» in una demo e divergere bruscamente non appena utenti reali inviano casi limite reali.

Tengo il fornitore dietro un unico adattatore sottile nel codice proprio perché questa decisione resti reversibile. Un cliente che chiede di cambiare fornitore dopo sei mesi per un cambio di prezzi, un rate limit o la deprecazione di un modello dovrebbe ottenere una modifica di configurazione e un giro di test di regressione dei prompt, non una riscrittura.

2. Il prompt engineering è una specifica, testata come tale

Un prompt che vive nella testa di un solo sviluppatore, viene ritoccato in un playground di chat, e va in produzione appena «sembra giusto» su tre esempi, è una passività non appena il traffico cresce oltre quei tre esempi. Scrivo i prompt come file versionati, con un piccolo set di test di input reali e forme di output attese, e li testo in regressione come farei con una funzione - specialmente prima di cambiare modello o fornitore.

Gli output strutturati e il tool/function calling sono ciò che rende un prompt testabile in primo luogo: invece di valutare testo libero a occhio, controllo che un payload JSON corrisponda a uno schema e che i valori al suo interno soddisfino le regole di business. Questo è il vero risultato del «prompt engineering» in un progetto reale, non un paragrafo azzeccato.

3. Gestione del contesto: la parte che nessuno mette a budget

Ogni integrazione LLM prima o poi incontra una conversazione, un documento o un job batch più grande della finestra di contesto, e ciò che succede dopo decide se la funzionalità resta economica e accurata o diventa lenta e inizia ad allucinare. Aggiungere ingenuamente ogni messaggio alla history funziona in demo e poi si rompe silenziosamente: i costi salgono a ogni turno, la latenza sale con loro, e oltre un certo punto il modello inizia a perdere di vista la domanda reale sepolta sotto i turni vecchi.

La soluzione è un mix di tagliare i turni vecchi, riassumere ciò che è venuto prima invece di ripeterlo, e recuperare solo la fetta rilevante tramite embeddings e un database vettoriale quando la fonte è un documento invece di una conversazione. L’input multimodale - un’immagine o una pagina PDF - è solo un altro tipo di contesto da gestire allo stesso modo: conta contro la stessa finestra e richiede la stessa disciplina su cosa deve davvero starci.

Conclusione: la chiamata API è la parte più piccola dell’integrazione

Collegare un LLM a un prodotto per lo più non riguarda la chiamata al modello - è l’adattatore che rende il fornitore sostituibile, il prompt trattato come una specifica testata, lo schema che cattura una risposta malformata prima che raggiunga un utente, e la strategia di contesto che continua a funzionare dopo la prima facile conversazione demo. Costruisco tutto questo attorno a quale tra OpenAI e Anthropic si adatta davvero al lavoro. Scrivete tramite il modulo cosa volete che l’LLM faccia dentro il vostro prodotto, e vi dirò di cosa ha davvero bisogno l’integrazione.