Die schwierigste Frage in dieser Arbeit ist nicht, ob es am Tag der Auslieferung funktioniert. Sondern ob es einen Monat später noch funktioniert, wenn der Modellanbieter etwas geändert hat, die Daten des Kunden gedriftet sind und seit Wochen niemand einen Trace angeschaut hat.
Diese Rolle verantwortet diese Frage. Sie bauen die Evaluations- und Observability-Schicht, die aus unseren Aussagen zur Zuverlässigkeit etwas macht, das wir tatsächlich belegen können, uns selbst und den Kunden gegenüber.
Was Sie tun werden
- Evaluations-Harnesse und Golden Datasets für Kundensysteme bauen, einschließlich der subjektiven Kriterien, die einen LLM-Richter brauchen, und der Kalibrierung, um ihm zu vertrauen
- Tracing vom Prompt bis zur Ausgabe verantworten: jedes Retrieval, jeder Tool-Aufruf und jedes Ergebnis so gut erfasst, dass sich ein Vorfall daraus debuggen lässt
- Regressionen erkennen, bevor Kunden es tun, über Modell-Upgrades, Prompt-Änderungen und Datendrift hinweg
- Leitplanken und Human-in-the-Loop-Kontrollpunkte für die Entscheidungen entwerfen, die zu folgenreich sind, um sie komplett zu automatisieren
- Wiederkehrende Fehlerfälle in Standards verwandeln, nach denen das ganze Delivery-Team arbeitet
Was wir suchen
- Sehr gutes Python und ein wirklich empirischer Instinkt: Sie greifen zur Messung, bevor Sie zur Meinung greifen
- Erfahrung in der Evaluation von LLM-Systemen, einschließlich des Punkts, an dem Offline-Metriken das Produktionsverhalten nicht mehr vorhersagen
- Hintergrund in Observability und Monitoring, ob aus ML oder klassischen verteilten Systemen
- Genug Statistikkenntnisse, um zu wissen, wann ein Unterschied zwischen zwei Läufen nichts bedeutet
- Bereitschaft, die Person zu sein, die sagt, dass ein System noch nicht bereit ist
Schön, wenn Sie das mitbringen
- Sie haben einen LLM-as-Judge-Evaluator gebaut und gegen menschliche Labels validiert
- Erfahrung in regulierten oder sicherheitskritischen Umgebungen
- Data-Engineering-Kenntnisse für die Pipelines hinter Evaluationsdatensätzen
Ihre ersten sechs Monate
- Monat 1: ein laufendes Projekt vom Prompt bis zur Ausgabe instrumentieren und etwas finden, von dem niemand wusste, dass es kaputt ist
- Monat 3: jedes aktive Projekt hat eine Evaluationssuite, die dagegen läuft
- Monat 6: Regressionen werden von unseren Werkzeugen gefangen, nicht von einer Kunden-E-Mail