.@AnkythShukla maakte een scherp onderscheid dat de meeste AI-bouwers missen. "Een eval kan alles zijn, toch? Als we dit heel eenvoudig uitleggen, kan het elke soort test zijn. Het kan een unittest zijn in de oude taal. Het kan gewoon een telling van woorden hier zijn. Of in de meest geavanceerde vorm, zoals we hebben laten zien, kan het een LLM-rechter zijn, die een beetje die menselijke intuïtie repliceert die we in die prompt hebben gecodeerd die we zagen." Dit herformuleert het hele gesprek over AI-evals. De meeste teams horen "evals" en denken aan complexe LLM-als-rechter-pijplijnen. Ze raken geïntimideerd. Ze slaan het over. Ze verzenden zonder metingen. De realiteit uit deze aflevering van @aakashgupta's podcast: > Een eval kan zo eenvoudig zijn als een functie voor het tellen van woorden of een unittest. De drempel om te beginnen is laag. De kosten van het overslaan zijn hoog. > Een LLM-rechter is de geavanceerde vorm - het coderen van menselijke intuïtie in een prompt die AI-uitvoer op schaal beoordeelt. > Het spectrum loopt van deterministische codecontroles tot subjectieve kwaliteitsbeoordeling. Beide tellen. Beide zijn belangrijk. > Dit sluit direct aan bij waarom prototypes op schaal falen. @AnkythShukla identificeerde vijf redenen, maar twee springen eruit: Data-afwijking: het product is gebouwd voor één realiteit. Gebruikers leven in een andere. Zonder continu draaiende evals vang je nooit de divergentie. Kosten: SaaS heeft bijna geen marginale kosten per gebruiker. AI niet. Elke oproep kost geld. Zonder evals die je vertellen welke oproepen werken en welke verspild zijn, lopen de kosten op zonder proportionele waarde. De boodschap: AI-evals zijn geen kwaliteitsluxueus. Ze zijn de operationele infrastructuur die bepaalt of je prototype een product wordt of een statistiek in de 95% faalkans.