.@AnkythShukla hat eine klare Unterscheidung getroffen, die die meisten AI-Entwickler übersehen. "Eine Eval kann alles sein, oder? Wenn wir das wirklich einfach erklären würden, könnte es jede Art von Test sein. Es könnte ein Unit-Test in der alten Sprache sein. Es könnte einfach eine Zählung von Wörtern hier sein. Oder in der fortgeschrittensten Form, wie wir gezeigt haben, kann es ein LLM-Richter sein, der eine Art von menschlicher Intuition repliziert, die wir in diesen Prompt kodiert haben, den wir gesehen haben." Das stellt die gesamte Diskussion über AI-Evals neu dar. Die meisten Teams hören "Evals" und denken an komplexe LLM-als-Richter-Pipelines. Sie fühlen sich eingeschüchtert. Sie überspringen es. Sie liefern ohne Messung aus. Die Realität aus dieser Episode im Podcast von @aakashgupta: > Eine Eval kann so einfach sein wie eine Wortzählfunktion oder ein Unit-Test. Die Hürde, um zu beginnen, ist niedrig. Die Kosten, es zu überspringen, sind hoch. > Ein LLM-Richter ist die fortgeschrittene Form - menschliche Intuition in einen Prompt kodieren, der AI-Ausgaben in großem Maßstab bewertet. > Das Spektrum reicht von deterministischen Codeprüfungen bis hin zu subjektiven Qualitätsbewertungen. Beides zählt. Beides ist wichtig. > Das erklärt direkt, warum Prototypen im großen Maßstab scheitern. @AnkythShukla hat fünf Gründe identifiziert, aber zwei stechen hervor: Datenabweichung: Das Produkt wurde für eine Realität entwickelt. Die Nutzer leben in einer anderen. Ohne kontinuierlich laufende Evals fängt man die Abweichung nie auf. Kosten: SaaS hat nahezu null Grenzkosten pro Nutzer. AI hat das nicht. Jeder Aufruf kostet Geld. Ohne Evals, die dir sagen, welche Aufrufe funktionieren und welche verschwendet werden, steigen die Kosten ohne proportionalen Wert. Die Erkenntnis: AI-Evals sind kein Qualitätsluxus. Sie sind die operationale Infrastruktur, die bestimmt, ob dein Prototyp ein Produkt wird oder eine Statistik in der 95%-Fehlerrate wird.