{% extends 'admin/base.html.twig' %} {% block title %}Eval-Case erstellen{% endblock %} {% block body %}

Eval-Case erstellen

Neue Regression-Cases separat anlegen, ohne die Eval-Suite-Übersicht aufzublähen.
Zurück zur Eval Suite
{% for label in ['success', 'danger', 'warning', 'info'] %} {% for message in app.flashes(label) %}
{{ message }}
{% endfor %} {% endfor %} {% if case_draft.source_label|default('') %}
Vorlage geladen: {{ case_draft.source_label }}
Bitte Case-ID, Prompt und Assertions prüfen, bevor du den Case speicherst.
{% endif %}
Neuer Eval-Case
Der Typ entscheidet, in welche Datei geschrieben wird: tests/evals/cases/<type>.ndjson.
Eindeutig über alle Eval-Typen. Erlaubt: Buchstaben, Zahlen, _ und -.
Exakt der Nutzerprompt, der abgesichert werden soll. Tippfehler bewusst so eintragen, wenn sie Teil des Tests sind.
Muss ein gültiges JSON-Objekt sein. Beispiel: {"expected_query":"testomat 808"}.
Für Follow-up-Cases empfohlen. Muss eine JSON-Liste sein. Leer lassen für direkte Prompts.
Normalerweise leer lassen. Für reguläre Regressionen lieber History-JSON verwenden.
Abbrechen
Feld-Checkliste
  • retrieval: richtiges Dokument / richtige Chunks prüfen.
  • shop_query: direkte Shopquery prüfen.
  • followup: Prompt plus History prüfen.
  • answer_guard: No-Answer- oder Evidenzfälle prüfen.
Häufige Assertions
Exakte Query:
{
  "expected_query": "testomat 808"
}
Begriffe müssen enthalten sein:
{
  "must_include_terms": [
    "testomat",
    "808"
  ]
}
Dokument muss enthalten sein:
{
  "min_results": 1,
  "must_include_one_of_document_ids": [
    "DOKUMENT-ID"
  ]
}
Empfehlung

Ein guter Eval-Case prüft genau einen Zweck. Lieber mehrere kleine Cases anlegen als einen großen, empfindlichen Case.

{% endblock %}