.@AnkythShukla ha fatto una netta distinzione che la maggior parte dei costruttori di AI ignora. "Un eval può essere qualsiasi cosa, giusto? Se dovessimo spiegare questo in modo molto semplice, potrebbe essere qualsiasi tipo di test. Potrebbe essere un test unitario nel linguaggio di una volta. Potrebbe semplicemente essere un conteggio di parole qui. O nella forma più avanzata, come abbiamo mostrato, può essere un giudice LLM, che in un certo senso replica parte di quell'intuizione umana che abbiamo codificato in quel prompt che abbiamo visto." Questo riformula l'intera conversazione sugli evals di AI. La maggior parte dei team sente "evals" e pensa a pipeline complesse LLM-come-giudice. Si sentono intimiditi. Lo saltano. Spediscono senza misurazione. La realtà da questo episodio del podcast di @aakashgupta: > Un eval può essere semplice come una funzione di conteggio parole o un test unitario. La soglia per iniziare è bassa. Il costo di saltarlo è alto. > Un giudice LLM è la forma avanzata - codificare l'intuizione umana in un prompt che valuta le uscite dell'AI su larga scala. > Lo spettro va dai controlli di codice deterministici alla valutazione della qualità soggettiva. Entrambi contano. Entrambi sono importanti. > Questo si mappa direttamente al motivo per cui i prototipi falliscono su larga scala. @AnkythShukla ha identificato cinque motivi, ma due spiccano: Deriva dei dati: il prodotto è stato costruito per una realtà. Gli utenti vivono in un'altra. Senza evals che funzionano continuamente, non si riesce mai a catturare la divergenza. Costo: SaaS ha un costo marginale quasi zero per utente. L'AI no. Ogni chiamata costa denaro. Senza evals che ti dicono quali chiamate funzionano e quali sono sprecate, i costi aumentano senza un valore proporzionale. La conclusione: gli evals di AI non sono un lusso di qualità. Sono l'infrastruttura operativa che determina se il tuo prototipo diventa un prodotto o diventa una statistica nel tasso di fallimento del 95%.