Gettoni, crediti, budget e costo totale
Il prezzo di una chiamata non è il costo di un’attività completa.
Cosa imparerai
- Spiegare: il costo appartiene all'intero percorso
- Applica l'idea in un esempio: token, crediti, budget e costo totale
- Riconoscere i limiti e verificare il risultato dell'esercizio
Il prezzo di una chiamata non è il costo di un’attività completa. Conta separatamente l'indicizzazione, la conversazione e gli strumenti.
Puoi seguire questo corso senza un account o una programmazione. Gli esempi utilizzano dati sintetici e i risultati dell’intelligenza artificiale devono essere verificati.
Come funziona, passo dopo passo
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.
Scegli per attività e capacità
Controlla la lingua, il contesto, la chiamata degli strumenti, l'output strutturato e le modalità di input supportate. Confronta modelli su richieste identiche utilizzando la stessa rubrica e un budget realistico. Campionamento dei cambiamenti di temperatura, non verità. Lo sforzo di ragionamento alloca gli sforzi per modelli compatibili e può aumentare tempi e costi; i valori accettati variano. I modelli locali offrono il controllo dell’infrastruttura ma richiedono risorse e manutenzione. I pesi aperti non garantiscono una licenza illimitata o un codice di allenamento completo. Cataloghi e prezzi cambiano; leggere la scheda del modello attuale.
Definire il successo prima di ottimizzare
Preparare richieste rappresentative e risposte o proprietà previste. Includere casi ordinari, ambiguità, dati mancanti ed errori dello strumento. Per RAG, misurare il recupero delle prove separatamente dalla correttezza della risposta. Recall@k misura la quota di prove rilevanti trovate nei primi k risultati; Precision@k misura la quota di risultati restituiti che sono rilevanti. Per gli agenti, monitora anche azioni, autorizzazioni e arresti. Un LLM come giudice può accelerare la valutazione ma necessita di una calibrazione rispetto agli esseri umani. Non modificare prompt, modello e indice contemporaneamente se vuoi capire quali risultati migliorati.
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
Utilizzando prezzi fittizi di 2 per milione di input e 10 di output, 10.000 input e 1.000 output costano 0,03 unità monetarie prima degli strumenti. Questi sono valori di esercizio, non prezzi correnti.
Provalo tu stesso
- Stimare tre chiamate e un'esecuzione di indicizzazione, quindi il costo per attività riuscita.
- Registrare l'input, la fonte e il risultato atteso prima di eseguire l'esperimento. Utilizzare solo i dati fittizi nell'esempio.
- Seguire le fasi del diagramma. Ad ogni passaggio registrare quali informazioni vengono ricevute e prodotte; non confondere il risultato intermedio con il risultato finale.
- Ripetere dopo aver rimosso le informazioni necessarie o reso ambiguo l'input. Controlla se il sistema chiarisce, ferma o inventa una risposta.
- 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
Calcola 0,02 + 0,01 e aggiungi il consumo extra separatamente; confrontare con l'utilizzo effettivo dell'organizzazione. 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
I crediti dell'applicazione e la valuta del fornitore potrebbero avere conversioni diverse. 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
Più chiamate simultanee sono automaticamente più economiche?
No. Il tempo trascorso e il consumo totale sono quantità diverse.
La temperatura zero garantisce la correttezza?
No. Può ridurre la variazione, ma una risposta stabile può comunque essere sbagliata.
Quale risultato dovrebbe produrre questo esercizio?
Calcola 0,02 + 0,01 e aggiungi il consumo extra separatamente; confrontare con l'utilizzo effettivo dell'organizzazione.
Termini da ricordare
- Latență / Latenza: tempo necessario per ottenere un risultato utile.
- Sforzo di ragionamento: un'impostazione dipendente dal modello che controlla lo sforzo di ragionamento.
- Regresia/Regressione: una modifica che interrompe un caso precedentemente corretto.
Fonti e il prossimo passo
Per preparare: E04 — Osservabilità e debugging