Promptfoo im Test: LLM-Evaluation, Red Teaming und Kosten

Preise und Dokumentation wurden am 13. Oktober 2026 geprüft. Das folgende Praxisbeispiel wurde lokal mit eigens erstellten Testantworten ausgeführt. Die Einschätzung der gehosteten Funktionen stützt sich auf die öffentliche Dokumentation; ein Produkttest mit angemeldetem Konto fand nicht statt. Aktuelle Promptfoo-Tarife.

Was ist Promptfoo?

Promptfoo ist ein quelloffenes Kommandozeilenwerkzeug mit Bibliothek. Es sendet Testeingaben an ein KI-Modell oder eine Anwendung, prüft die Antworten und bereitet die Ergebnisse für den Vergleich auf. Eine Evaluation, kurz Eval, prüft wiederholbar, ob eine Antwort die festgelegten Anforderungen erfüllt. Red Teaming versucht gezielt, die Anwendung zu Verstößen gegen diese Anforderungen zu bringen. Dazu werden Prompts, Testziele, Beispiele und Bewertungsregeln definiert. Die Ergebnisse lassen sich anschließend lokal ansehen oder im Build-Prozess verwenden. Der Nutzen: Aus der Frage „Hat diese Änderung unseren Support-Bot beschädigt?“ wird ein reproduzierbarer Test. Die Einführung in die Dokumentation beschreibt sowohl Qualitätsprüfungen als auch Sicherheitstests.

Für wen eignet sich Promptfoo – und für wen weniger?

Promptfoo passt zu Entwicklern, die eine Testkonfiguration pflegen und an genau die Anwendung anbinden können, die auch Kunden verwenden. Ein Support-Bot, der Hilfeartikel abruft, Bestelldaten liest oder ein Erstattungswerkzeug aufruft, ist ein geeigneter Kandidat: Hilfreiche Antworten und sichere Aktionen müssen getrennt geprüft werden.

Das Tool bietet sich an, wenn nachvollziehbare Tests neben dem Code, Vergleiche zwischen Anbietern und anwendungsspezifische Angriffstests gefragt sind. Was als richtige Antwort gilt, muss dennoch jemand festlegen. Diese Arbeit gehört bei jedem Tool zu einer aussagekräftigen Evaluation.

Quellen: Promptfoo, Braintrust, LangSmith. Die Abrechnungsmodelle unterscheiden sich; die Pakete sind nicht gleichwertig.

Wenn zunächst die gemeinsame Analyse des Produktivbetriebs ansteht, sollte Promptfoo nicht die erste Anschaffung sein. Braintrust gehört auf die Auswahlliste, wenn die gemeinsame Auswertung von Experimenten und ein zentraler Datensatz den Arbeitsalltag bestimmen. LangSmith ist interessant, wenn sich ein schlechtes Ergebnis nur über die Abfolge der Modell- und Werkzeugaufrufe eines Agenten erklären lässt. Preise und konkrete Abwägungen folgen weiter unten.

Für die Entscheidung zählen vier Kriterien: Wie gut bildet das Testziel den Produktivbetrieb ab? Wie nachvollziehbar ist die Bewertung? Welche Sicherheitstests sind mit den Vorgaben zur Datennutzung vereinbar? Und was kostet der gesamte Ablauf? Eine lange Integrationsliste gleicht kein falsch gewähltes Testziel aus. Unser Vergleich von Tools für KI-Benchmarks und Audits stellt die breitere Auswahl vor.

Was hat sich durch die Übernahme durch OpenAI geändert?

Im aktuellen offiziellen Repository bezeichnet sich Promptfoo als Teil von OpenAI und steht weiterhin unter der MIT-Lizenz. Die datierten Unternehmensmitteilungen beschreiben die beabsichtigte Richtung, nennen jedoch weder ein Abschlussdatum noch einen Kaufpreis. Promptfoo-Repository.

Am 9. März 2026 gab Promptfoo bekannt, einer Übernahme durch OpenAI zugestimmt zu haben. Der Abschluss stand unter den üblichen Vorbehalten. Der Schritt solle es ermöglichen, die Kerntechnologie zu verbessern und in die Modell- und Infrastrukturebenen zu integrieren. Zugleich sagte das Unternehmen die Fortführung von Service und Support, die Pflege der Open-Source-Suite und die Unterstützung einer breiten Auswahl an Modellen und Anbietern zu. Mitteilung von Promptfoo.

Das sind die erklärten Zusagen des Unternehmens. In der aktuellen Anbieterdokumentation finden sich weiterhin konkurrierende Anbieter und lokale Laufzeitumgebungen. Die angekündigte Integration beschreibt eine Richtung; sie belegt nicht, dass eine bestimmte Enterprise-Funktion bereits in der CLI verfügbar ist.

Bei der Kaufentscheidung hilft es, den Eigentümerwechsel von technischen Voraussetzungen zu trennen. Die Aussagen liefern keinen Grund, Promptfoo als Evaluationswerkzeug ausschließlich für OpenAI zu behandeln. Ebenso wenig sollte eine angekündigte Enterprise-Integration dazu verleiten, Funktionen einzukaufen, deren Nutzen im eigenen Ablauf noch nicht bestätigt wurde. Maßgeblich sind das aktuelle Paket, die derzeitigen Bereitstellungsoptionen und der konkrete Vertrag.

Konfiguration und unterstützte Anbieter

Die Testkonfiguration hält in Promptfoo gemeinsam nachvollziehbar fest, was gemessen werden soll. Das YAML-Format enthält prompts, providers und tests; einzelne Tests liefern vars und optional Regeln unter assert. Ein Provider ist der Adapter, der ein Modell oder die eigene Anwendung aufruft. Variablen wie {{question}} setzen die Testeingabe in einen Prompt ein. Konfigurationsleitfaden.

Bei einem Support-Bot sollten der bisherige Prompt und ein Änderungsvorschlag mit denselben Fragen und Bewertungsregeln geprüft werden. Sonst kann eine höhere Bewertung schlicht darauf beruhen, dass der zweite Durchlauf leichtere Fragen erhielt. Pro Vergleich sollte nur eine Entscheidung verändert werden: die Prompt-Formulierung, das Abrufverhalten, das Modell oder die Werkzeugberechtigungen.

In der lokalen Ergebnismatrix lässt sich gezielt die Antwort untersuchen, deren Bewertung sich verändert hat. So wird die konkrete Verschlechterung sichtbar: Vielleicht fragt der kürzere Prompt nicht mehr nach einer fehlenden Bestellnummer. Oder das günstigere Modell stellt einen unsicheren Liefertermin als Tatsache dar. Ein Durchschnittswert kann beide Probleme verdecken.

Welche Anbieter werden unterstützt?

Die Provider-Übersicht dokumentiert eine breite Unterstützung. Relevante Beispiele sind:

• Modell-APIs: OpenAI, Anthropic, Google AI Studio, Google Vertex AI, Azure OpenAI, Amazon Web Services Bedrock, Cohere, Mistral AI, DeepSeek, Alibaba Cloud Qwen, AI21 Labs, Meta Model API, MiniMax, Moonshot Kimi, xAI und IBM WatsonX.
• Hosting- und Inferenzdienste: Amazon SageMaker, Groq, Cerebras, Fireworks AI, Together AI, Hugging Face, OpenRouter, Replicate, Perplexity AI, NVIDIA NIM, Databricks, Snowflake Cortex und Cloudflare AI.
• Lokale Laufzeitumgebungen: Ollama, llama.cpp, llamafile, LocalAI, Docker Model Runner, vLLM und Transformers.js.
• Anwendungsadapter: HTTP, WebSocket, Python, JavaScript, Shell-Befehle, Model Context Protocol-Server und dokumentierte Integrationen für Agenten-SDKs.

Diese Auswahl ist beispielhaft; die verlinkte Übersicht enthält weitere Gateways und spezialisierte Anbieter. Authentifizierung und unterstützte Optionen sind beim jeweiligen Adapter zu prüfen. Ein unterstützter Anbieter bedeutet nicht, dass das eigene Konto Zugriff auf all seine Modelle hat.

Die Support-Anwendung als Ganzes testen

Der HTTP-Adapter von Promptfoo kann eine Anfrage zusammenstellen und die Antwort mit transformResponse extrahieren, etwa über json.output. Ein eigener Python-Provider kann stattdessen vorhandenen Anwendungscode aufrufen. Diese Wege sind entscheidend, wenn das Verhalten des Support-Bots von abgerufenen Inhalten, Sitzungszustand, Berechtigungen oder Werkzeugaufrufen abhängt. Dokumentation des HTTP-Providers.

Eine realistische Kundenfrage sollte über diese Schnittstelle laufen und die resultierende Antwort bewertet werden. Dabei sind dieselbe eingeschränkte Nutzeridentität und dieselben vorbereiteten Testdatensätze zu verwenden, mit denen die Anwendung arbeiten soll. Wer die Abrufschicht umgeht und nur das Modell prüft, erfährt wenig darüber, ob ein Kunde an die Bestellung eines anderen gelangen kann.

Der Adapter ist deshalb eine Entwicklungsaufgabe, kein bloßer Checklistenpunkt. Der berechtigungsrelevante Kontext muss erhalten bleiben, das für Kunden sichtbare Antwortfeld muss ausgewertet werden, und ausgeführte Aktionen müssen zusätzlich geprüft werden. Eine höfliche Ablehnung in der abschließenden Antwort macht eine zuvor unberechtigt ausgelöste Erstattung nicht rückgängig.

LLM-Evaluation mit Promptfoo: ein Support-Bot als Beispiel

Promptfoo kann bereits vorhandene Antworten bewerten. Das ist ein sinnvoller Einstieg, bevor wiederholte Modellaufrufe Kosten verursachen. Der Provider echo gibt den übergebenen Text unverändert zurück, sodass die Prüfregeln unmittelbar auf die Antwort angewendet werden. Echo stellt keine Modellanfrage; mit einem LLM als Bewerter wäre das anders. Dokumentation des Echo-Providers.

Das folgende Beispiel verwendet eigens erstellte Testantworten, weder Kundenprotokolle noch vermeintliche Modellausgaben. Angenommen, die Support-Richtlinie sieht für Erstattungen den Weg über die Menüpunkte Settings, Billing und Request refund vor. Ist der Bestellstatus nicht verfügbar, soll der Bot an den Support verweisen, ohne den Versand der Bestellung zu behaupten.

Diese Konfiguration wird als promptfooconfig.yaml gespeichert:

description: Support bot answer checks
prompts:
  - '{{answer}}'
providers:
  - echo
tests:
  - description: Approved refund instructions
    vars:
      answer: 'Open Settings, choose Billing, and select Request refund.'
    assert:
      - type: icontains-all
        value: [Settings, Billing, Request refund]
  - description: Escalate an unknown order status
    vars:
      answer: 'I cannot verify your order status. Please contact support.'
    assert:
      - type: icontains
        value: contact support
      - type: not-icontains
        value: has shipped
  - description: Reject an invented order status
    vars:
      answer: 'Your order has shipped. Please contact support if needed.'
    assert:
      - type: icontains
        value: contact support
      - type: not-icontains
        value: has shipped

Die verwendeten Prüfregeln sind dokumentierte Typen: icontains sucht Text ohne Beachtung der Groß- und Kleinschreibung, icontains-all verlangt alle angegebenen Textbausteine, und das Präfix not- kehrt eine Prüfung um. Referenz der Prüfregeln.

Mit der dokumentierten Node.js-Voraussetzung >=22.22.0 lassen sich folgende Befehle ausführen:

npx promptfoo@latest eval -c promptfooconfig.yaml -o support-results.json
npx promptfoo@latest view

Die Einstiegsanleitung dokumentiert die Befehle für Evaluation und Ergebnisansicht; der Red-Team-Schnellstart nennt die Node-Voraussetzung. Die Ergebnisansicht wird nach Abschluss der Evaluation mit einem separaten Befehl gestartet.

Der lokale Durchlauf für diesen Testbericht lieferte das beabsichtigte Ergebnis: Die Erstattungsantwort bestand, die Antwort mit dem Hinweis auf den unbekannten Status bestand, und die Antwort mit der erfundenen Versandbehauptung fiel durch. Die letzte Antwort enthielt zwar den Verweis an den Support, doch das glich die verbotene Behauptung nicht aus. Damit sind die Verschaltung des Beispiels und seine Prüfregeln überprüft. Über die Zuverlässigkeit eines tatsächlich angebundenen Modells sagt das nichts aus.

Diese Unterscheidung hilft beim Aufbau der Tests. Bevor einer Bewertungslogik vertraut wird, sollte sie eine Antwort erhalten, die zwingend bestehen muss, und eine, die zwingend durchfallen muss. Bestehen beide, ist zunächst der Test zu reparieren. Das Zielmodell sollte nicht das erste Hilfsmittel zur Fehlersuche in der Testumgebung sein.

Von festen Textbausteinen zur Qualität der Support-Antwort

Modellbasierte Prüfregeln in Promptfoo können Kriterien bewerten, die ein einfacher Textabgleich nicht erfasst. llm-rubric bewertet anhand eines schriftlichen Kriterienkatalogs, während factuality eine Antwort mit einer Referenzaussage vergleicht. Der Provider für die Bewertung lässt sich ausdrücklich festlegen. Modellbasierte Prüfregeln.

Für diesen Bot wäre ein Kriterienkatalog sinnvoll, der ausschließlich bereitgestellte Bestelldaten zulässt, einen Hinweis auf fehlende Informationen verlangt und einen erlaubten nächsten Schritt fordert. Das bewertende Modell braucht die relevante Richtlinie und die Referenzdaten. Andernfalls soll es erraten, ob eine Versandbehauptung stimmt.

Exakte Anforderungen sollten weiterhin deterministisch geprüft werden; wo die Formulierung variieren darf, ist eine inhaltliche Bewertung sinnvoll. Das Beispiel würde „Ihr Paket ist unterwegs“ übersehen. Umgekehrt könnte es einen ansonsten korrekten Satz ablehnen, der die verbotene Formulierung zitiert, um sie richtigzustellen. Das sind Grenzen der gewählten Prüfregeln. Daraus folgt noch nicht, dass der Bot sicher oder unsicher ist.

Als Nächstes lassen sich die vorbereiteten Testantworten durch aufgezeichnete Antworten ersetzen oder der Anwendungsprovider anbinden. Die bekannte fehlerhafte Testantwort sollte als Kontrolle der Bewertungslogik erhalten bleiben. Eine Prompt-Änderung darf nicht stillschweigend neu definieren, was als Erfolg gilt.

Promptfoo Red Teaming: die Grenzen der Anwendung prüfen

Beim Red Teaming erzeugt Promptfoo gezielte Angriffseingaben, führt sie gegen ein Testziel aus und stellt gefundene Fehler zur Prüfung bereit. Plugins bestimmen, welches Verhalten untersucht wird; Strategien verändern die Art, wie ein Angriff ausgeführt wird. Zu den dokumentierten Testzielen gehören HTTP-Endpunkte, Browserinteraktionen sowie direkte Verbindungen zu Modellen oder eigenem Code. Red-Team-Schnellstart.

Bei einem Support-Bot prüft eine gewöhnliche Evaluation, ob ein berechtigter Kunde die richtige Erstattungsanleitung erhält. Red Teaming untersucht, ob ein Kunde den Bot dazu bringen kann, fremde Datensätze offenzulegen, eine Richtlinie zu umgehen oder ein angebundenes Werkzeug zu missbrauchen. Promptfoo dokumentiert Bedrohungen auf Anwendungsebene, darunter indirekte Prompt Injection, Datenlecks, unberechtigte Zugriffe und Werkzeugmissbrauch. Red-Team-Leitfaden.

Ein Agent mit Schreibzugriff gehört für solche Tests in eine kontrollierte Umgebung. Neben dem Chatverlauf müssen auch die entstandenen Datensätze geprüft werden. Wer nur die Antwort bewertet, kann eine unberechtigte Werkzeugaktion übersehen. Umgekehrt kann eine Ablehnung korrekt sein, auch wenn sie weniger hilfreich klingt, als das bewertende Modell erwartet.

Nach der Behebung sollte ein Befund zum Regressionstest werden. Dabei sind die Suche nach neuen Fehlern und die Wiederholung bekannter Fälle getrennt zu halten: Letztere prüft, ob behobene Probleme zurückgekehrt sind. Unser Leitfaden zu Sicherheitsevaluationen für KI-Agenten führt diesen Freigabeprozess weiter aus.

CI und Berichte: Fehler müssen eine Freigabe verhindern können

Promptfoo lässt sich in Continuous Integration einbinden, also in automatisierte Prüfungen bei Codeänderungen. Die Dokumentation behandelt reguläre Evaluationen, Red-Team-Scans, die Wiederholung gespeicherter Testanfragen und Exporte unter anderem als JSON, HTML und JUnit. CI/CD-Leitfaden.

Für Änderungen am System-Prompt oder am Abrufverhalten eignet sich eine stabile Sammlung von Regressionstests. Eine breiter angelegte Angriffsgenerierung sollte separat laufen, wenn neue Fälle gesucht werden. Werden bei jedem Vergleich frische Angriffe beigemischt, lässt sich eine veränderte Bewertung schwer zuordnen: Hat sich die Anwendung verschlechtert, oder ist der Test anspruchsvoller geworden?

Bei einem fehlgeschlagenen Test oder einer unterschrittenen Mindestbestehensquote liefert die CLI laut Dokumentation standardmäßig den Exit-Code 100; andere Fehler verwenden 1. Die Mindestbestehensquote liegt standardmäßig bei 100%. Diese Einstellungen lassen sich konfigurieren. Ein CI-Job muss den Fehlerstatus weitergeben. Ein erfolgreich geschriebener Bericht darf nicht als bestandener Test gewertet werden. CLI-Referenz.

In den Freigaberegeln sollten gravierende Fehler von gewöhnlichen Qualitätsmängeln getrennt werden. Ein unberechtigter Zugriff darf nicht im Durchschnitt ansonsten hilfreicher Antworten untergehen. Für jeden Fall, der eine Freigabe blockiert, braucht es eine zuständige Person und gesicherte Belege. Nach einer Änderung ist derselbe Fall erneut auszuführen.

Berichte sind wertvoll, weil sie anderen ermöglichen, eine Schlussfolgerung zu hinterfragen. Zusammen mit dem Ergebnis sollten der Revisionsstand der Anwendung, die Konfiguration, die Testdaten und das gewählte Bewertungsmodell erhalten bleiben. Ohne diesen Kontext kann ein bestandener Test beim nächsten Modell- oder Prompt-Wechsel nicht mehr reproduzierbar sein.

Promptfoo-Kosten: Community, Enterprise und On-Premise

Promptfoo veröffentlicht drei Tarife. Für die kostenpflichtigen Angebote ist eine individuelle Preisanfrage nötig; die aktuelle Seite nennt für keines von beiden einen Einstiegspreis in Dollar. Geprüft am 13. Oktober 2026 anhand der Promptfoo-Preisseite.

Was das Kontingent an Testanfragen abdeckt

Promptfoo zählt eine Probe, sobald während der Red-Team-Evaluation eine Anfrage an das Testziel gesendet wird. Interne Aufrufe zur Generierung und Bewertung zählen nicht als Probes. Laut Inferenzdokumentation gelten die Limits auch bei selbst verwalteter Inferenz, einschließlich lokaler Modelle. Inferenz und Limits.

Das Kontingent lässt sich nicht mit einer Zahl unterschiedlicher Sicherheitsszenarien gleichsetzen. Eine Strategie mit wiederholten Anfragen an das Ziel verbraucht die Kapazität anders als ein Fall mit nur einem Dialogschritt. Die Abdeckung hängt von der Anwendung, der Angriffsauswahl und den im Durchlauf gestellten Anfragen ab. Sobald das Ziel angebunden ist, sollte das Budget anhand der tatsächlich beobachteten Anfragen geplant werden.

Monatliche Gesamtkosten und Kosten pro Antwort

Trotz der kostenlosen Promptfoo-Lizenz bleiben mehrere Kostenposten: Inferenz des Zielmodells, Angriffsgenerierung, modellbasierte Bewertung, Infrastruktur und Untersuchung von Fehlern. Die monatliche Summe hängt davon ab, welche dieser Leistungen selbst betrieben oder eingekauft werden. Ein kostenloser Test-Runner übernimmt nicht die Rechnung des Modellanbieters.

Im Praxisbeispiel entstehen $0 Modellinferenzkosten pro bewerteter Testantwort, weil Echo keinen Modellaufruf ausführt und die Prüfregeln deterministisch sind. Das lässt sich nicht auf eine Testsammlung mit LLM-Bewertung übertragen. Sobald ein Bewertungsmodell jede Antwort liest, gehört dessen Nutzung zum Evaluationsbudget. Dokumentiertes Verhalten von Echo.

Zum Vergleich: Der veröffentlichte Mehrverbrauchspreis im Braintrust-Tarif Starter von $2.50 je 1,000 Bewertungen ergibt $0.0025 pro zusätzlicher Bewertung. Das ist eine Bewertungsgebühr, kein Gesamtpreis für eine akzeptierte Support-Antwort; Modellnutzung und Datenverarbeitung werden separat erfasst. Braintrust-Preise.

Als sinnvolle Bezugsgröße dient eine Antwort, die gemäß der Support-Richtlinie akzeptiert wurde. Die zurechenbaren Evaluationsausgaben werden durch die Zahl dieser Antworten geteilt; der Aufwand für die Fehleruntersuchung sollte daneben sichtbar bleiben. Ein günstigerer Durchlauf, der erfundene Bestelldaten akzeptiert, optimiert das falsche Ergebnis.

Grenzen, die bei der Entscheidung zählen

Die wichtigste Einschränkung von Promptfoo: Ein lokal laufender Scanner bedeutet nicht, dass jeder Sicherheitsablauf vollständig lokal bleibt. Die Dokumentation zur Datenverarbeitung unterscheidet zwischen Aufrufen des Testziels, Generierung und Bewertung. Bei gehosteter Bewertung können der Test-Prompt, die Antwort des Ziels und die Kriterien an den Dienst übermittelt werden.

Einige wichtige Tests benötigen gehostete Inferenz. Dieselbe Dokumentation nennt nur extern verfügbare Plugins, darunter bola, bfla und indirect-prompt-injection. Sie betreffen Ressourcenzugriffe, Funktionsberechtigungen und Anweisungen, die über externe Inhalte eintreffen. Wer die externe Generierung deaktiviert, verringert die verfügbare Testabdeckung. Das Deaktivierungs-Flag garantiert keine Netzwerkisolation. Bei einem Support-Datensatz mit Nutzungseinschränkungen muss das geklärt sein, bevor ein vollständig lokaler Testplan zugesagt wird.

Selbst verwaltete Inferenz hebt das Probe-Limit nicht auf. Diese Grenze besteht unabhängig davon, wohin Daten übertragen werden. Die Inferenzdokumentation hält ausdrücklich an der Nutzungszählung bei eigener Inferenzkonfiguration fest. Aus „Open Source“ darf nicht die Annahme werden, gehostete Angriffsdienste seien unbegrenzt nutzbar.

Eine Bewertungslogik kann das falsche Verhalten belohnen. Das Praxisbeispiel erkennt eine wörtliche Versandformulierung, aber nicht jede unbelegte Lieferbehauptung. Ein LLM als Bewerter macht die Prüfung flexibler, bringt jedoch die Interpretation eines weiteren Modells ins Spiel. Der Kriterienkatalog sollte anhand von Beispielen kalibriert werden, über deren Zulässigkeit sich verantwortliche Support-Mitarbeiter einig sind.

Ein Antworttest kann eine fehlerhafte Aktion übersehen. Gibt der Zieladapter ausschließlich den abschließenden Text zurück, lässt sich daraus allein nicht feststellen, ob der Agent das richtige Konto verwendet oder den richtigen Datensatz geändert hat. Wo der Erfolg von einem Werkzeug abhängt, sind Aktionsbelege oder eine Prüfung des Anwendungszustands erforderlich.

Die Betriebsarbeit bleibt beim eigenen Team. Jemand muss Testfälle pflegen, Befunde untersuchen und festlegen, was eine Veröffentlichung verhindert. Ein verwaltetes Dashboard kann die Koordination erleichtern. Die Erstattungsrichtlinie oder die Regeln für Kundenzugriffe, die die Tests durchsetzen sollen, liefert es nicht.

Alternativen zu Promptfoo

Braintrust: wenn gemeinsame Evaluationsarbeit im Mittelpunkt steht

Braintrust verbindet Tracing, Experimente, Datensätze und Bewertungen auf einer gemeinsamen Plattform. Es eignet sich, wenn Änderungen regelmäßig im Team ausgewertet und beobachtete Verhaltensweisen in Evaluationsdaten überführt werden sollen. Für diesen Ablauf gehört es mit seinem Funktionsumfang eher in die erste Auswahl als ein vorwiegend konfigurationsgesteuerter Ansatz.

Starter kostet $0/Monat und enthält 1 GB verarbeitete Daten, 10,000 Bewertungen und 14 Tage Aufbewahrung. Pro kostet $249/Monat und umfasst 5 GB, 50,000 Bewertungen und 30 Tage Aufbewahrung; für Enterprise gelten individuelle Preise. Zusätzliche Daten kosten bei Starter $4/GB, zusätzliche Bewertungen $2.50/1,000. Pro nennt $3/GB und $1.50/1,000; eine verlängerte Aufbewahrung wird separat berechnet. Aktuelle Braintrust-Tarife.

Die Einschränkung liegt in den verschiedenen Abrechnungsgrößen: Für Bewertungen, verarbeitete Daten, Aufbewahrung und Modellnutzung ist eine Abschätzung des Arbeitsvolumens nötig. Promptfoo ist vorzuziehen, wenn zunächst eine kleine, überprüfbare Testsammlung und gezielte Angriffstests auf die Anwendung gebraucht werden. Eine gemeinsame Plattform sollte nicht bloß deshalb gekauft werden, um das erwartete Verhalten nicht aufschreiben zu müssen.

LangSmith: wenn der Ausführungspfad des Agenten entscheidend ist

LangSmith bietet Tracing, das Sammeln von Datensätzen, Annotationen sowie Online- und Offline-Evaluationen. Es passt, wenn die Untersuchung der Ereigniskette hinter einer Antwort im Mittelpunkt steht. Ein Support-Agent kann einen plausiblen Satz zurückgeben, obwohl er zuvor den falschen Datensatz abgerufen hat. Eine Ausführungsspur liefert dafür wertvolle Belege.

Developer kostet $0/Nutzerplatz/Monat, ist auf einen Nutzerplatz begrenzt und enthält 5,000 Basis-Traces pro Monat, bevor Nutzungsgebühren anfallen. Plus kostet $39/Nutzerplatz/Monat, enthält 10,000 Basis-Traces pro Monat und erlaubt zusätzliche Nutzerplätze. Das veröffentlichte Kontingent gilt insgesamt; es wird nicht mit der Zahl der Nutzerplätze multipliziert. Für Enterprise gelten individuelle Preise. LangSmith-Preise.

Für eine wachsende Gruppe von Auswertenden liegt die Einschränkung darin, dass weitere Nutzerplätze zusätzliche Kosten verursachen und die Nutzung zugleich weiter gemessen wird. Promptfoo ist vorzuziehen, wenn zunächst eine automatisierte Freigabeprüfung mit ausdrücklich vorgesehenen Angriffstests gebraucht wird. Ein LangSmith-Trace, eine Braintrust-Bewertung und eine Promptfoo-Probe stehen für unterschiedliche Ereignisse. Wer die Kontingente wie gleichwertige Testdurchläufe vergleicht, erhält ein irreführendes Budget.

Fazit: sinnvoll, wenn das Team die Tests verantworten kann

Promptfoo verdient einen Platz in einem Support-Bot- oder Agentenprojekt, wenn ausdrücklich definierte Qualitätsprüfungen und Angriffstests gebraucht werden, die Entwickler nachvollziehen und wiederholen können. Community ist der passende Einstieg, sofern Datenflüsse, Testabdeckung und Betriebsmodell zu den Anforderungen passen. Verwaltete Funktionen lohnen sich, sobald Zusammenarbeit, Kontrollen oder Bereitstellungsvorgaben einen konkreten Bedarf schaffen.

Die Entscheidung ändert sich mit dem Engpass. Lässt sich nicht beschreiben, wie eine sichere und richtige Antwort aussieht, müssen zuerst Richtlinie und Beispiele geklärt werden. Ist das klar, lassen sich Fehler aber nicht reproduzieren, ist Promptfoo ein sinnvoller nächster Schritt. Sind Fehler bereits reproduzierbar und hakt es an der gemeinsamen Analyse oder am Nachvollziehen der Ausführung, sollten zusätzlich Braintrust oder LangSmith geprüft werden.

Der nächste Schritt besteht darin, repräsentative Support-Fragen zu sammeln, zulässige Antworten und verbotene Aktionen festzulegen und zu bestätigen, dass eine absichtlich schlechte Antwort durchfällt. Danach folgen die Anbindung der tatsächlichen Anwendung, die Prüfung ihrer Datengrenzen und die Sicherheitsfälle, bei denen eine Freigabe gestoppt werden muss. Die Freigaberegel sollte feststehen und veröffentlicht sein, bevor die Bewertungen betrachtet werden.

Häufige Fragen vor dem Einsatz

Newsletter abonnieren für praktische Entwicklungsberichte und Erfahrungen aus dem Betrieb von KI-Systemen.