Dal prototipo all'assistente rivolto al visitatore

Il lancio richiede più di una demo. Termina con un widget, un budget, limiti di accesso e un processo di manutenzione.

Questi passaggi si riferiscono alle funzionalità identificate nel codice dell'applicazione. Questo materiale non è stato convalidato su un'istanza live; controlla la documentazione e le opzioni nella tua versione.

Come funziona, passo dopo passo

Controllare l'accesso prima dell'uso

Le autorizzazioni devono essere applicate dai server e dal livello dati. Non lasciare che sia il modello a decidere se un utente può vedere un documento. Filtra le fonti prima che entrino nel contesto, non dopo aver generato la risposta. Utilizza credenziali di accesso minimo, tienile lontane da prompt, screenshot e codice del browser e ruota le chiavi esposte. Una lista consentita di domini widget non sostituisce l'autenticazione API. L'autenticazione ti identifica; l'autorizzazione determina le operazioni e i dati che puoi utilizzare. Prova anche l'accesso negato.

Gli errori necessitano di percorsi espliciti

Un timeout è diverso da un errore di autorizzazione. Riprova solo errori temporanei, con tentativi limitati e ritardi crescenti. Un'operazione con effetti collaterali può essere eseguita prima che la sua risposta venga persa; riprovare senza una chiave di idempotenza può duplicare l'effetto. Lo streaming mostra l'avanzamento ma non garantisce il completamento. I checkpoint possono consentire la ripresa delle fasi non riuscite entro i limiti di runtime. Memorizza l'identificatore dell'esecuzione, la fase, la durata e l'errore rimuovendo i segreti dai log. Misura i percorsi lenti e le medie.

Il costo appartiene all'intero percorso

Conta le chiamate ai modelli, i token di input e output, gli incorporamenti, la riclassificazione, la visione e gli strumenti. Il ragionamento può consumare token fatturabili senza una risposta visibile altrettanto lunga. I costi di indicizzazione e i costi di conversazione differiscono. Utilizza i prezzi correnti anziché un numero permanente di un corso. Una stima semplice è token/1.000.000 × prezzo più operazioni aggiuntive; i crediti dell'applicazione possono avere la propria conversione. Confronta i costi per attività riuscita, non solo per chiamata. L'esecuzione parallela può ridurre la latenza aumentando al contempo il consumo totale. Un budget necessita di una condizione di arresto verificata.

Lo schema esplicativo

Seguire le frecce continue per il flusso principale. Le frecce blu tratteggiate forniscono dati o contesto; le frecce rosa tratteggiate mostrano feedback o risultati restituiti. Colori e forme distinguono modelli, negozi, decisioni e risultati. Su schermi piccoli, scorri in orizzontale per seguire l’intero schema.

Un esempio completo

Il widget dichiara il suo ruolo, viene eseguito su domini consentiti e utilizza un target testato. Controlla fonti, errori, dispositivi mobili e costi, quindi definisci chi esamina le politiche.

Provalo tu stesso

1. Controlli completi di accesso, qualità, dominio, dispositivi mobili, budget e manutenzione prima della pubblicazione.
2. Registrare l'input, la fonte e il risultato atteso prima di eseguire l'esperimento. Utilizzare solo i dati fittizi nell'esempio.
3. Seguire le fasi del diagramma. Ad ogni passaggio registrare quali informazioni vengono ricevute e prodotte; non confondere il risultato intermedio con il risultato finale.
4. Ripetere dopo aver rimosso le informazioni necessarie o reso ambiguo l'input. Controlla se il sistema chiarisce, ferma o inventa una risposta.
5. Confrontare con la soluzione spiegata. Conserva la configurazione, la data, il risultato e una spiegazione delle differenze. Cambia una cosa e riprova.

Una soluzione spiegata

Fornire integrazione, test consentiti/negati, criteri di lancio e una data di revisione. Un esercizio riuscito ti consente di mostrare la connessione tra input, fasi e risultato. Quando mancano le informazioni, una risposta cauta è più utile dei dettagli inventati. Confrontare non solo stile: verificare anche condizioni, fonti e operazioni.

Quando è utile e quali sono i suoi limiti

Non promettere ai visitatori funzionalità di pianificazione o approvazione non confermate. Scegli questo approccio quando migliora un bisogno misurato. Mantieni una linea di base semplice e confronta i risultati utilizzando input identici. Un esempio di successo non stabilisce l’affidabilità in ogni situazione.

Verifica ciò che hai imparato

Perché rimuovere una fonte privata dopo aver risposto è troppo tardi?

I dati sono già entrati nel contesto del modello e possono essere divulgati.

Un timeout dimostra che l'operazione non è stata eseguita?

No. Controlla lo stato prima di ritentare un'azione con effetti collaterali.

Quale risultato dovrebbe produrre questo esercizio?

Fornire integrazione, test consentiti/negati, criteri di lancio e una data di revisione.

Termini da ricordare

• Autorizzare/Autorizzazione: verifica del diritto di accesso a un'operazione o risorsa.
• Idempotenza: Ripetizione controllata senza duplicare un effetto.
• Latență / Latenza: tempo necessario per ottenere un risultato utile.

Fonti e il prossimo passo

• OWASP — Iniezione di prompt
• LangGraph — flussi di lavoro e agenti
• OpenRouter — token di ragionamento

Per preparare: A03 — Un agente connesso alla conoscenza · R03 — Naive RAG: la tua linea di base · D04 — Buone domande per testare RAG · U02 — Il parco giochi come laboratorio · U05: un widget AI sul tuo sito web · E05 — Gettoni, crediti, budget e costo totale · S01: Iniezione rapida e dati non attendibili · S02 — Autorizzazioni e protezione dei dati