Come scegliamo l'AI giusta per ogni funzione
Quando si progetta una funzione basata su intelligenza artificiale, la domanda "quale modello uso" sembra doversi rispondere una volta sola, all'inizio. Nella pratica di NovLore non è andata così: nel tempo ci siamo accorti che compiti diversi del prodotto avevano esigenze così diverse fra loro che un solo fornitore, per quanto buono, non poteva servirle tutte bene. Questo articolo racconta perché, e come è fatto oggi il sistema che ne è nato.
Il problema che ha spinto la scelta
All'inizio Scintilla — l'assistente di scrittura di NovLore — teneva insieme due compiti diversi in un solo canale: la conversazione con l'utente e la generazione del cruscotto dell'opera (personaggi, luoghi, trama) a partire da quella conversazione. Sembravano collegati, ma avevano bisogni opposti: la conversazione ha bisogno di rispondere in fretta, mentre generare dati strutturati coerenti ha bisogno di prendersi il tempo di ragionarci. Un solo fornitore, ottimizzato per uno dei due bisogni, penalizzava sistematicamente l'altro.
La soluzione non è stata cercare un fornitore che facesse bene entrambe le cose. È stata smettere di trattarle come lo stesso compito.
Sei ambiti, non uno
Oggi ogni funzione AI di NovLore dichiara il proprio ambito — correzione, riscrittura, chat, struttura, capitolo, trascrizione — e ogni ambito può avere un fornitore diverso in prima scelta. La chat di Scintilla, per esempio, usa un modello scelto per la rapidità di risposta; la generazione di un capitolo intero, che l'utente lancia sapendo di dover aspettare, usa un modello scelto invece per la qualità della prosa su un compito lungo.
| Ambito | Cosa fa | Cosa conta di più |
|---|---|---|
| Chat | conversazione con l'assistente | velocità di risposta |
| Correzione | refusi e coerenza grammaticale | precisione, costo basso |
| Riscrittura | modifica di un testo selezionato | qualità stilistica |
| Struttura | dati strutturati su personaggi/trama | affidabilità del formato |
| Capitolo | generazione di un capitolo intero | qualità su testo lungo |
| Trascrizione | predisposto, non ancora attivo | — |
Nessuna di queste scelte è definitiva: un pannello di amministrazione permette di cambiare fornitore e riserva per ogni ambito senza toccare il codice, perché il costo e la qualità relativa dei modelli cambiano nel tempo più in fretta di quanto cambi il software.
Perché sette fornitori e non uno "abbastanza buono"
Con un solo fornitore, ogni sua interruzione di servizio — e capita a tutti, anche ai migliori — diventa un'interruzione dell'intero prodotto. La soluzione più comune è avere una riserva; quella meno ovvia, ma più solida, è che la riserva non deve passare dallo stesso canale della prima scelta. Se la prima scelta e la riserva sono due instradamenti diversi verso lo stesso fornitore a monte, un'indisponibilità di quel fornitore porta giù entrambe insieme.
Per questo, quando la prima scelta di un ambito è un aggregatore che dà accesso a più modelli con una chiave sola, la riserva va deliberatamente su un fornitore diretto e indipendente. È una ridondanza vera, non solo sulla carta.
Cosa vede l'utente quando scatta la riserva
Niente, se il sistema funziona come deve. Se il fornitore in prima scelta per un ambito non risponde, il passaggio alla riserva è trasparente: la richiesta va comunque a buon fine, e solo un dato tecnico interno registra che a rispondere è stata la seconda scelta. Sullo streaming — le risposte che compaiono parola per parola, come nella chat — la riserva può scattare solo prima che arrivi il primo pezzo di testo: una volta iniziata la risposta, cambiare fornitore a metà produrrebbe un testo cucito da due stili diversi, peggio che aspettare qualche secondo in più.
La trasparenza della riserva non è un dettaglio tecnico da appassionati di infrastruttura: è la differenza fra un utente che nota un rallentamento occasionale e un utente che vede un errore mentre sta scrivendo il suo romanzo.
Il router come unico punto di passaggio
Perché questo sistema regga nel tempo, ogni funzione AI del prodotto — comprese quelle con output strutturato e quelle in streaming — passa da un unico router interno, mai dai fornitori direttamente. È una scelta che costa disciplina (nessuna scorciatoia, nemmeno per una funzione "temporanea") ma che paga in un modo preciso: quando un fornitore cambia le sue condizioni, o ne arriva uno nuovo che vale la pena aggiungere, il cambiamento si fa in un solo posto, non in dieci endpoint diversi scritti in momenti diversi.
Domande frequenti
Perché non usare sempre il modello più potente disponibile?
Perché "più potente" non è la stessa cosa di "più adatto al compito". Un modello ottimo su testo lungo e creativo può essere lento e costoso per una chat che deve rispondere in un secondo; usarlo ovunque farebbe sembrare lenta anche la parte del prodotto che dovrebbe essere istantanea.
L'utente può scegliere quale AI usare?
Non direttamente sul singolo messaggio: la scelta è per ambito e la gestisce chi amministra il prodotto, in base a qualità e affidabilità osservate nel tempo. È una scelta deliberata — lasciarla all'utente sposterebbe su di lui una decisione tecnica che richiede di monitorare continuamente sette fornitori diversi.
Cosa succede se anche la riserva non risponde?
L'operazione fallisce con un errore esplicito, e nel caso di un'azione a crediti l'addebito viene annullato automaticamente sullo stesso lotto da cui era stato preso: l'utente non paga per una richiesta che non ha ricevuto risposta.
Questo sistema rallenta lo sviluppo di nuove funzioni AI?
Nel breve termine sì, leggermente: aggiungere una funzione richiede di passare dal router invece di chiamare un'API direttamente. Nel medio termine è il contrario, perché ogni nuova funzione eredita gratis la gestione degli errori, la riserva e il tracciamento dei costi già costruiti una volta sola.