Ein häufiges Muster: Ein Team erstellt einen KI-Workflow – für Content-Entwürfe, die Klassifizierung von Supportanfragen oder die Erstellung von Vertriebs-E-Mails. In Woche 1 funktioniert er gut, das Team ist begeistert und führt ihn ein.
Drei Monate später stimmt etwas nicht mehr. Die Qualität scheint schlechter, Kunden beschweren sich und Vertriebsmitarbeitende nutzen den Workflow nicht mehr. Niemand weiß, wann oder warum sich etwas verändert hat.
Die Ursache ist fast immer dieselbe: Niemand hat gemessen. Der Workflow kann sich schleichend verschlechtert haben, das zugrunde liegende Modell wurde vielleicht geändert, die Prompts sind abgedriftet oder die Verteilung der Eingaben hat sich verschoben. Ohne Messung fällt dies erst auf, wenn Nutzer sich beschweren – und dann ist Vertrauen bereits verloren.
Die Lösung ist Evals – systematische Messung der Qualität von KI-Ausgaben. Evals werden in der Regel als technisches Problem betrachtet, aber jedes Team, das KI-Workflows betreibt, benötigt sie. Und die Grundlagen sind ohne Code zugänglich.
Dieser Artikel erklärt, was Evals sind, warum sie wichtig sind und wie Sie sie ohne technischen Hintergrund für jeden KI-Workflow einrichten.
Evals sind kein Berichtstheater. Ein nützliches Eval führt zu einer Entscheidung: veröffentlichen, zurückhalten, zurücksetzen oder untersuchen. Kann ein Wert die Handlung des Teams nicht verändern, vereinfachen Sie das Eval, bis er es kann.
Was Evals sind (und was sie nicht sind)
Ein Eval ist eine Methode, um systematisch zu messen, wie gut die Ausgaben Ihrer KI sind, anhand von Beispielen, die Sie kontrollieren.
Die Komponenten:
- Ein Datensatz. Eine Menge von Eingaben (die Dinge, die Ihre KI verarbeitet).
- Erwartetes Verhalten. Was Sie mit diesen Eingaben von der KI erwarten.
- Eine Bewertungsmethode. Wie Sie messen, ob die KI es richtig gemacht hat.
- Ein Durchlauf und Bericht. Der Datensatz wird verarbeitet, jede Ausgabe bewertet und das Ergebnis zusammengefasst.
Der Zweck ist, eine wiederholbare Methode zu haben, um zu fragen: „Tut die KI, was ich will, mit der Qualität, die ich erwarte?“ – und um zu erkennen, wenn sich die Antwort ändert.
Evals sind nicht:
- Einmalige Tests während der Erstellung.
- Stichproben, wenn etwas seltsam wirkt.
- Nutzerfeedback (hilfreich, aber reaktiv, langsam und verzerrt).
- Bauchgefühl („die Ausgabe wirkt richtig“).
Echte Evals laufen nach einem festen Zeitplan mit einem definierten Datensatz und konsistenter Bewertung. Sie liefern Signale, selbst wenn sich niemand beschwert.
Warum Entwicklerwerkzeuge für die meisten Teams ungeeignet sind
Eine Google-Suche nach „LLM-Evals“ liefert Artikel über Promptfoo, LangSmith, Braintrust und Helicone. Diese Tools sind leistungsfähig, richten sich aber an Entwickler, die LLM-basierte Produkte in großem Maßstab betreiben.
Für die meisten Teams, die KI-Workflows betreiben – Marketing, Vertrieb, Betrieb, Support – sind diese Tools übertrieben. Sie benötigen etwas Einfacheres: eine Möglichkeit, Ihre spezifischen Workflows zu messen, ohne ein Tooling-Stack zu lernen.
Die gute Nachricht: Eine Tabellenkalkulation und ein LLM genügen. Das ist weniger ausgereift als LangSmith, erkennt aber die meisten Qualitätsprobleme.
Die vier Eval-Muster
Es gibt vier gängige Eval-Muster. Jedes passt zu einem anderen Typ Workflow.
Muster 1: Exakte Übereinstimmung
Verwenden Sie dies, wenn es eine einzige korrekte Antwort gibt.
Beispielworkflow: Klassifizieren von Kundensupporttickets in 8 Kategorien.
Datensatz: 50 Tickets mit ihrer korrekten Kategorie. Bewertung: Die Antwort der KI stimmt entweder mit der korrekten Kategorie überein (1 Punkt) oder nicht (0 Punkte). Ausgabe: % korrekt.
Dies funktioniert gut für Klassifizierung, Extraktion, einfache strukturierte Ausgaben.
Muster 2: Referenzvergleich
Verwenden Sie dies, wenn es eine bekannte gute Antwort gibt, mit der verglichen werden kann.
Beispielworkflow: Erstellung von Produktbeschreibungen.
Datensatz: 30 Produkte mit „Referenz“-Beschreibungen, die Sie geschrieben haben. Bewertung: Wie nahe ist die Beschreibung der KI der Referenz in Dimensionen wie Genauigkeit, Ton, Vollständigkeit?
Sie können manuell bewerten – ein Mensch liest beide Texte und vergibt 1–5 Punkte – oder ein LLM als Bewertungsmodell einsetzen. Referenzvergleiche sind der Goldstandard für Content-Workflows.
Muster 3: LLM als Bewertungsmodell
Verwenden Sie dies, wenn die Ausgabe viele gültige Formen hat, aber die Qualität beurteilbar ist.
Beispielworkflow: Erstellung personalisierter Verkaufs-E-Mails.
Datensatz: 30 Zielgruppenprofile. Bewertung: Ein LLM beurteilt anhand der Eingabe und Ausgabe Dimensionen wie Spezifität, Professionalität, Länge und Übereinstimmung mit der Markenstimme.
Ein LLM als Bewertungsmodell ist wirkungsvoll, erfordert aber eine sorgfältige Prompt-Gestaltung. Ein gängiges Muster:
You are evaluating a sales email for quality. Score it on these dimensions:
1. Specificity (1-5): Does it reference specific facts about the prospect, not generic flattery?
2. Professionalism (1-5): Does it sound like a peer rather than spam?
3. Length appropriateness (1-5): Is it concise (40-80 words)?
4. Voice match (1-5): Does it match our voice (direct, no buzzwords)?
For each dimension, give the score and a one-sentence reason.
Output JSON: {"specificity": {"score": N, "reason": "..."}, ...}
Prospect profile: [input]
Email to evaluate: [output]
Das Bewertungs-LLM bietet eine Konsistenz, die menschliche Prüfer kaum erreichen: ein Modell und ein Prompt, einheitlich angewendet. Ein nie überprüftes Bewertungsmodell ist jedoch nur eine zweite Meinung unbekannter Qualität. Kalibrieren Sie es deshalb einmal gründlich:
- Nehmen Sie 50 Beispiele, die Ihr Team bereits bewertet hat (bestanden/nicht bestanden oder anhand Ihrer Skala). Verwenden Sie echte Fälle aus Ihrer Prüfwarteschlange, keine synthetischen Beispiele.
- Wenden Sie das Bewertungsmodell auf dieselben 50 Beispiele an und messen Sie die Übereinstimmung. Bei mehr als etwa 85 % können Sie es für Routineprüfungen verwenden und Menschen nur eine Stichprobe prüfen lassen. Zwischen etwa 70 % und 85 % untersuchen Sie jede Abweichung: Meist ist die Bewertungsrubrik zu unklar. Präzisieren Sie sie und wiederholen Sie den Durchlauf. Unter etwa 70 % misst das Modell etwas anderes als Ihr Team; automatisieren Sie damit nicht.
- Betrachten Sie die Richtung der Fehler, nicht nur ihre Häufigkeit. Ein Modell, das schlechte Ausgaben freigibt, ist gefährlich; eines, das gute Ausgaben beanstandet, lediglich lästig. Legen Sie den Schwellenwert entsprechend fest.
- Kalibrieren Sie mit 20–30 neuen Beispielen neu, sobald Sie das Bewertungsmodell, den Bewertungs-Prompt oder die Rubrik ändern. Jede dieser Änderungen verschiebt die Übereinstimmungsrate unbemerkt.
Diese Bereiche sind ein empfohlenes Startprotokoll, kein Naturgesetz. Nicht verhandelbar ist, dass die Kalibrierung erfolgt, bevor Bewertungen Entscheidungen blockieren oder freigeben.
Muster 4: Eigenschaftsprüfung
Verwenden Sie dies, wenn Sie „gut“ als spezifische, testbare Eigenschaften ausdrücken können.
Beispielworkflow: Erstellung von Produkttiteln für einen E-Commerce-Shop.
Datensatz: 50 Produkte. Eigenschaften, die auf jeder Ausgabe geprüft werden:
- Länge liegt zwischen 30 und 70 Zeichen.
- Enthält den Markennamen.
- Enthält mindestens eines der wichtigsten Produktmerkmale.
- Verwendet keine verbotenen Marketingwörter („fantastisch“, „best“, „revolutionär“).
Jede Eigenschaft ist ein Ja/Nein-Test. Der Wert entspricht dem Anteil der über alle Ausgaben bestandenen Prüfungen.
Eigenschaftsprüfungen eignen sich hervorragend für strukturierte Vorgaben, die immer eingehalten werden müssen. Sie laufen schnell und erkennen konkrete Abweichungen.
Wie Sie Ihren ersten Eval einrichten
Eine praktische Einrichtung ohne technische Vorkenntnisse:
Schritt 1: Wählen Sie den Workflow
Wählen Sie einen Workflow aus und versuchen Sie nicht, alles gleichzeitig zu evaluieren. Beginnen Sie mit dem Workflow, dessen Qualität Ihnen die größten Sorgen bereitet oder dessen Folgen am schwerwiegendsten sind.
Beispiel: „Die KI, die eingehende Kundensupporttickets nach Themen klassifiziert.“
Schritt 2: Erstellen Sie den Datensatz
Erstellen Sie eine Liste mit 20–50 repräsentativen Beispielen. Berücksichtigen Sie:
- Einfache Fälle (klar Kategorie A).
- Schwierige Fälle (könnten A oder B sein).
- Grenzfälle (passen in keine Kategorie eindeutig).
- Häufige Varianten (unterschiedliche Formulierungen derselben Absicht).
Speichern Sie sie in einer Tabellenkalkulation oder in Google Sheets:
| ID | Eingabe | Erwartete Ausgabe |
|---|---|---|
| 1 | „Mein Passwort funktioniert nicht“ | „account-access“ |
| 2 | „Ich möchte mein Abonnement kündigen“ | „billing“ |
| 3 | „Ihr neuestes Update hat meinen Workflow beschädigt“ | „bug“ |
| … | … | … |
Dieser Datensatz ist Ihr Eval-Set. Er sollte nicht oft geändert werden – sein Zweck ist, eine stabile Referenz zu sein.
Schritt 3: Definieren Sie die Bewertung
Legen Sie für jedes Beispiel präzise fest, was als korrekte Antwort gilt.
Für Klassifizierung: exakte Übereinstimmung der Kategorie. Für Content: eine Bewertung von 1–5 in jeweils 2–4 benannten Dimensionen. Für Extraktion: jedes Feld als korrekt oder fehlerhaft bewerten.
Schreiben Sie die Bewertungskriterien auf. Halten Sie sich an sie.
Schritt 4: Führen Sie den Workflow auf dem Datensatz durch
Führen Sie Ihren KI-Workflow auf jedem Beispiel im Datensatz durch. Speichern Sie die Ausgabe in einer neuen Spalte.
Für Klassifizierung können Sie dies in einer Tabellenkalkulation mit einer Funktion wie der GPT-Integration von Google Sheets oder durch manuelles Kopieren und Einfügen tun.
Für komplexere Workflows, geben Sie die Eingaben in ein Tool wie Promptfoo oder führen Sie einfach eine Batch-Aufgabe einmal pro Woche durch.
| ID | Eingabe | Erwartet | Tatsächlich |
|---|---|---|---|
| 1 | … | „account-access“ | „account-access“ |
| 2 | … | „billing“ | „billing“ |
| 3 | … | „bug“ | „feature-request“ |
| … | … | … | … |
Schritt 5: Bewerten
Bei exakter Übereinstimmung fügen Sie eine Spalte „Übereinstimmung“ hinzu: 1, wenn Erwartet = Tatsächlich, andernfalls 0. Die Summe ergibt Ihre Genauigkeit.
Beim LLM als Bewertungsmodell führen Sie den Bewertungs-Prompt für jede Ausgabe aus und speichern die Ergebnisse.
Für Eigenschaftsprüfung: führen Sie jede Eigenschaft als separaten Test durch. Aggregieren Sie sie.
Minimale praxistaugliche Scorecard
Erfassen Sie beim ersten Eval wenige Dimensionen, sorgen Sie aber dafür, dass jede zu einer konkreten Handlung führt.
| Dimension | Frage | Schwellenwert zum Bestehen | Aktion bei Unterschreitung |
|---|---|---|---|
| Richtigkeit | Hat der Workflow die richtige Antwort oder Klassifizierung erzeugt? | 90 % | Prüfen Sie Fehler vor der Veröffentlichung |
| Sicherheit | Hat es verbotenen Inhalt, nicht unterstützte Aussagen oder risikoreiche Aktionen vermieden? | 100 % | Veröffentlichung blockieren |
| Format | Hat es die erwartete Struktur zurückgegeben? | 95 % | Prompt/Schema vor der Veröffentlichung beheben |
| Nutzen | Würde ein Nutzer diese Ausgabe vernünftigerweise akzeptieren? | 4/5 Durchschnitt | Beispiele oder Anweisungen überarbeiten |
| Regression | Sind bekannte frühere Fehler behoben geblieben? | 100 % | Veröffentlichung blockieren |
Die Scorecard sollte einen Verantwortlichen und eine Freigaberegel nennen. „Unter 90 % Richtigkeit prüft der Produktverantwortliche“ ist verbindlicher als „Richtigkeit verfolgen“.
Schritt 6: Zusammenfassen
Eine Zusammenfassungstabelle wie:
| Eval-Datum | Score | Notizen |
|---|---|---|
| 2026-05-01 | 47/50 (94 %) | Baseline. 3 Fehler: Tickets 8, 23, 41. |
| 2026-05-08 | 46/50 (92 %) | Stabil. 4 Fehler. |
| 2026-05-15 | 44/50 (88 %) | Abgefallen. Neue Fehler bei Tickets 12, 35. |
Mit der Zeit entsteht so ein Qualitätsverlauf. Rückgänge lösen eine Untersuchung aus.
Schritt 7: Terminieren
Führen Sie den Eval auf einem regelmäßigen Zeitplan durch. Wöchentlich ist für die meisten Workflows ausreichend. Nach jeder Änderung an den Prompts oder dem Modell führen Sie ihn vor der Veröffentlichung durch.
Machen Sie daraus eine wöchentliche 30-Minuten-Routine. Richten Sie einen wiederkehrenden Kalenderblock ein und lassen Sie ihn nicht ausfallen.
Die zu diesem Artikel verlinkte Scorecard ist für diesen ersten wöchentlichen Durchlauf konzipiert.
Eine Freigabesperre hinzufügen
Evals entfalten den größten Wert als Kontrolle vor einer Änderung. Verwenden Sie bei jedem KI-Workflow, der Kunden, betriebliche Datensätze oder Teamentscheidungen betrifft, eine einfache Freigabesperre:
- Baseline. Der aktuelle Produktionsworkflow hat einen aufgezeichneten Score.
- Kandidat. Ein neuer Prompt, ein anderes Modell, Tool oder ein neuer Workflow-Schritt wird mit demselben Eval-Datensatz geprüft.
- Vergleich. Der Kandidat muss die Sicherheits- und Regressionswerte halten und darf den primären Qualitätswert nicht stärker als vereinbart verschlechtern.
- Entscheidung. Veröffentlichen, zurückhalten, überarbeiten oder rückgängig machen. Dokumentieren Sie den Grund.
- Prüfung nach der Veröffentlichung. Wiederholen Sie das Eval nach der Einführung mit einer kleinen Stichprobe realer Fälle.
Dies muss am ersten Tag nicht automatisiert sein. Eine Tabelle mit einem benannten Freigabeverantwortlichen genügt, wenn sie ungemessene Änderungen zuverlässig vom Produktivbetrieb fernhält.
Was tun, wenn die Scores sinken
Evals sollen Qualitätsverluste erkennen. Tritt einer auf, untersuchen Sie ihn systematisch.
Eine einfache Untersuchung:
Schritt 1: Identifizieren Sie die fehlgeschlagenen Fälle. Was ist spezifisch schiefgelaufen?
Schritt 2: Suchen Sie nach Mustern. Sind die Fehler gruppiert (ähnliche Eingaben)? Oder verstreut (verschiedene Arten von Eingaben)?
Schritt 3: Diagnose.
- Muster → wahrscheinlich eine konkrete Schwäche (Prompt-Problem, fehlendes Wissen).
- Verstreut → wahrscheinlich ein allgemeiner Qualitätsverlust (Modelländerung, Drift).
Schritt 4: Hypothese über die Ursache.
- Hat sich das zugrunde liegende Modell kürzlich geändert? Prüfen Sie das Änderungsprotokoll des Anbieters.
- Hat sich der Prompt kürzlich geändert? Setzen Sie ihn zurück und testen Sie erneut.
- Hat sich die Eingabeverteilung geändert? Untersuchen Sie aktuelle reale Daten.
- Ist der Datensatz veraltet? Aktualisieren Sie Beispiele.
Schritt 5: Testen Sie die Lösung. Machen Sie eine Änderung. Führen Sie den Eval erneut durch. Hat sich die Situation erholt?
Dieser systematische Ansatz schlägt Panik und Spekulation.
Den Datensatz im Laufe der Zeit aufbauen
Ihr anfänglicher Datensatz ist ein Ausgangspunkt. Verbessern Sie ihn im Laufe der Zeit durch:
Hinzufügen realer Fehlfälle. Wenn ein echter Kund:innenfall eine schlechte Ausgabe erzeugt, fügen Sie ihn dem Eval-Set hinzu. Jetzt ist es ein Regressionstest – Sie erkennen diesen spezifischen Fehler, wenn er erneut auftritt.
Veraltete Fälle entfernen. Wenn sich Ihr Workflow weiterentwickelt, werden einige Testfälle irrelevant. Entfernen Sie sie.
Abdeckung erweitern. Enthält Ihr Eval-Set 20 „account-access“-Tickets, aber nur 1 „billing“-Ticket, ist es unausgewogen. Stellen Sie ein ausgewogeneres Verhältnis her.
Neue Grenzfälle ergänzen. Dazu gehören neue Beschwerdemuster, Produktfunktionen und Kategorien.
Ein guter Eval-Datensatz ist lebendig – er spiegelt die aktuelle Realität, nicht die historische.
Häufige Fehler
Einige Muster, die Eval-Programme zum Scheitern führen:
Fehler 1: Vor dem Start ein perfektes Eval bauen. Ein Datensatz mit 50 Beispielen und aufwendiger Bewertung wirkt einschüchternd. Ein Datensatz mit 10 Beispielen und einfacher Bewertung ist heute machbar. Beginnen Sie klein und iterieren Sie.
Fehler 2: Nur den regulären Erfolgsfall bewerten. Ausschließlich einfache Beispiele decken reale Fehler nicht auf. Nehmen Sie schwierige Fälle, Grenzfälle und bekannte frühere Fehler auf.
Fehler 3: Eval-Datensatz-Drift. Das Aktualisieren des Eval-Datensatzes jedes Mal, wenn sich der Workflow ändert, macht den Score bedeutungslos. Der Eval-Datensatz sollte selten geändert werden; der Workflow kann häufiger geändert werden. Der Punkt ist, den Workflow zu messen, nicht den Eval.
Fehler 4: Dem LLM-Bewertungsmodell blind vertrauen. Solche Modelle weisen Verzerrungen auf und gewichten oberflächliche Merkmale wie Länge und Format oft zu stark. Kalibrieren Sie das Modell regelmäßig anhand menschlicher Bewertungen. Bei Abweichungen muss der Bewertungs-Prompt verbessert werden.
Fehler 5: Bewerten, ohne zu handeln. Evals wöchentlich auszuführen, ohne auf die Daten zu reagieren, ist Theater. Ein Rückgang muss eine Untersuchung auslösen, sonst verschwenden Sie Ihre Zeit.
Fehler 6: Nur eine Dimension bewerten. „Mein Eval zeigt 95 % Genauigkeit!“ – aber vielleicht ist die Qualität der Antwort schlechter geworden, oder die Antwortzeit langsamer, oder die Halluzinationsrate höher. Verfolgen Sie mehrere Dimensionen, wo sie zählen.
Hilfreiche Tools (aber nicht erforderlich)
Wenn Sie von Tabellenkalkulationen abrücken möchten, gibt es einige zugängliche Optionen:
Promptfoo. Open Source, konfigurierbar über YAML, läuft auf Ihrem Laptop oder CI. Ausgezeichnet für das Testen von Prompts und deren Vergleich.
Braintrust. Gehostete Eval-Plattform mit einer guten Benutzeroberfläche. Teurer, aber leistungsfähig.
LangSmith. Speziell an LangChain-Workflows gebunden; gut, wenn Sie dieses Ökosystem verwenden.
Helicone. Protokollierung und Analyse von LLM-Aufrufen mit Eval-Funktionen.
OpenAI Evals. Open-Source-Framework, stärker auf Entwickler ausgerichtet.
Für die meisten nicht technischen Teams genügen eine Tabellenkalkulation plus ChatGPT oder Claude. Promptfoo ist das zugänglichste professionelle Werkzeug für den nächsten Schritt.
Ein vierwöchiges Eval-Programm
Ein realistischer Plan für ein Team, das bei null beginnt:
Woche 1: Wählen und definieren.
- Wählen Sie einen Workflow aus.
- Erstellen Sie einen Datensatz mit 20 Beispielen.
- Definieren Sie die Bewertung (exakte Übereinstimmung, LLM-Bewertungsmodell oder Eigenschaften).
Woche 2: Erste Baseline.
- Führen Sie den Eval durch. Speichern Sie die Baseline-Bewertung.
- Identifizieren Sie offensichtliche Fehlschläge.
- Ändern Sie nichts – beobachten Sie einfach.
Woche 3: Iterieren.
- Nehmen Sie eine Änderung vor, von der Sie eine Qualitätsverbesserung erwarten.
- Führen Sie den Eval erneut durch.
- Ist der Score gestiegen? Gefallen? Gleich geblieben? Untersuchen Sie, warum.
Woche 4: Terminierung.
- Planen Sie wöchentliche Durchläufe.
- Dokumentieren Sie den Eval-Prozess.
- Erklären Sie dem Team die Bedeutung der Werte und welche Schwellenwerte Handlungen auslösen.
Nach vier Wochen verfügen Sie über ein funktionierendes Eval. Erweitern Sie anschließend das Programm um weitere Workflows, vertiefen Sie den Datensatz und verfeinern Sie die Bewertung.
Die kulturelle Veränderung
Evals erfordern eher einen Kulturwandel als eine technische Veränderung. Teams, die KI-Workflows bisher einführen, „weil sie zu funktionieren scheinen“, müssen systematische Messung akzeptieren.
Die Veränderung umfasst:
Sinkende Werte akzeptieren. Manchmal verschlechtert eine Änderung, von der Sie überzeugt waren, die Qualität. Evals zeigen dies, und Sie müssen bereit sein, die Änderung zurückzusetzen.
In Kalibrierung investieren. Planen Sie im ersten Monat eines neuen Evals Zeit für Datensatz, Bewertung und Prompts ein.
Eine Vorher-nachher-Gewohnheit entwickeln. Jede nicht triviale Änderung an einem KI-Workflow durchläuft vor der Produktivsetzung das Eval. Dies wird zur Selbstverständlichkeit.
Die Qualitätsgrenze verteidigen. Wenn Werte sinken, beheben Sie die Ursache oder setzen die Änderung zurück. Veröffentlichen Sie nicht mit verschlechterter Qualität, nur weil eine Frist drängt.
Diese kulturelle Veränderung ist der schwierigste Teil. Sobald sie vorhanden ist, ist der Tooling-Teil einfach.
Ein Workflow, zwanzig Beispiele, eine halbe Stunde pro Woche
Evals unterscheiden KI-Workflows, denen Sie langfristig vertrauen können, von solchen, die unbemerkt in Mittelmäßigkeit abdriften.
Zum Einstieg benötigen Sie weder Entwickler noch ML-Fachwissen oder aufwendige Tools. Es genügen ein messenswerter Workflow, ein kleiner Datensatz, eine Bewertungsmethode und eine halbe Stunde pro Woche.
Wählen Sie diese Woche einen Workflow aus. Erstellen Sie ein Eval mit 20 Beispielen, führen Sie es aus und betrachten Sie das Ergebnis. Wiederholen Sie den Durchlauf in der nächsten Woche. Achten Sie auf die Disziplin, die dadurch entsteht.
In sechs Monaten werden die Teams mit Evals KI-Workflows haben, die tatsächlich verbessert wurden. Die Teams ohne Evals werden Workflows haben, die genauso aussehen wie vor sechs Monaten – nur schlechter.
