Ich würde bei so einem Thema nicht mit AI-Magie, (was man auch getrost als Marketing-Gefasel bezeichnen kann) anfangen, sondern mit etwas viel Langweiligerem: mit Tests. Denn genau da trennt sich der Demo-Zauber von Software, die man ernsthaft irgendwo laufen lassen will. Für mich ist pytest dabei immer noch das Rückgrat, weil ich damit saubere Fixtures, Parametrisierung und kontrolliertes Patchen habe. Also genau die Dinge, die man braucht, wenn man LLM-Verhalten reproduzierbar prüfen will statt nur ein paar hübsche Screenshots zu produzieren.

Ein fataler Fehler…….

Das interessante daran ist, das ein solch wichtiges Thema, bisher nur sehr wenig Conentent liefert. Mal hier und dort ein Video auf Youtube, ein wenig Literatur, aber das war es auch schon. Manchmal kommt es einem vor, das wir alle uns zu sehr auf die AI-Lösungen verlassen, aber niemals prüfen ob das geschriebene und die Ausgaben entsprechend auch stimmig sind.

Warum gibt es AI-Halluzinationen ?

Das ist nicht einmal nur meine Haltung als Test Engineer. NIST beschreibt das Problem ausdrücklich als „Confabulation“: Generative Systeme erzeugen und präsentieren falsche Inhalte mit Selbstvertrauen; dazu kommen Widersprüche, Quellenfehler und Antworten, die vom Input wegdriften. Genau deshalb empfiehlt NIST ausdrücklich empirische Prüfmethoden, Quellen- und Zitationsprüfung sowie laufendes Monitoring statt Anekdoten und Bauchgefühl.

Das Grundproblem: Halluzinationen sind plausible, aber falsche Aussagen, und klassische Trainings- und Evaluationsmuster belohnen oft das Raten stärker als das ehrliche „Ich weiß es nicht“. Solange Systeme für Trefferlisten optimiert werden, statt für verlässliches Verhalten unter Unsicherheit, wird Halluzination nicht verschwinden.

Lösungen?

Hypothesis

Ein Hebel ist für mich Hypothesis. Der Grund ist simpel: Die meisten Teams testen AI mit viel zu wenigen Beispielen. Drei Prompts, zwei Demos, einmal Schulterklopfen. Hypothesis dreht das um. Du beschreibst Eigenschaften, und das Tool füttert dein System mit viel mehr Varianten und Edgecases, als du von Hand jemals bauen würdest. Gerade bei Halluzinationen ist das Gold wert, weil dir die fiesen Fälle oft nicht im Happy Path begegnen.

Beispiel Code 1 Hyperthesis:

Hier ist die Idee nicht „Hypothesis macht AI korrekt“, sondern: Hypothesis zwingt dich, mehr als drei nette Beispielprompts zu testen. Genau das ist bei nichtdeterministischen Systemen oft der Unterschied zwischen Demo und echter Robustheit.

from hypothesis import given, strategies as st

ALLOWED_SOURCES = {"doc-1", "doc-2", "doc-3"}


def fake_llm_response(user_text: str) -> dict:
    return {
        "answer": f"Antwort auf {user_text}",
        "citations": ["doc-1"],
        "uncertain": False,
    }


@given(st.text(min_size=1, max_size=200))
def test_no_invented_sources(user_text: str):
    result = fake_llm_response(user_text)

    assert set(result["citations"]).issubset(ALLOWED_SOURCES)


@given(st.text(min_size=1, max_size=200))
def test_output_contract_is_stable(user_text: str):
    result = fake_llm_response(user_text)

    assert isinstance(result["answer"], str)
    assert isinstance(result["citations"], list)
    assert isinstance(result["uncertain"], bool)

Pydantic

Wenn das Modell strukturierte Antworten liefern soll, würde ich es gar nicht erst „frei erzählen“ lassen. Dann will ich JSON-Schema, Pydantic-Validierung oder gleich Structured Outputs. Nicht, weil das Halluzinationen komplett beseitigt — das tut es nicht — sondern weil es dir wenigstens eine ganze Klasse technischer Fehler abschneidet: fehlende Keys, kaputte Typen, erfundene Enum-Werte, kaputte Downstream-Pipelines.

Pydantic plus JSON-Schema/Structured Outputs für Vertrags- und Formatprüfung. Pydantic validiert Python-, JSON- und String-Daten; OpenAI beschreibt Structured Outputs ausdrücklich als Schema-gebundene Antwortform.

Beispiel-Code 2 Pydantic:

Das Beispiel ist simpel, aber genau darum nützlich: Erstmal den Output-Vertrag hart machen, bevor man über „Intelligenz“ philosophiert. Pydantic validiert strukturierte Daten, und Structured Outputs/JSON-Schema gehen in dieselbe Richtung: Das Modell soll nicht irgendwas liefern, sondern ein Format, das dein System sicher verarbeiten kann.

from pydantic import BaseModel, Field, ValidationError
import pytest


class AnswerContract(BaseModel):
    answer: str = Field(min_length=1)
    citations: list[str]
    uncertain: bool


def parse_llm_output(payload: dict) -> AnswerContract:
    return AnswerContract.model_validate(payload)


def test_output_contract_ok():
    payload = {
        "answer": "Pytest bietet Fixtures und Parametrisierung.",
        "citations": ["doc-1"],
        "uncertain": False,
    }

    result = parse_llm_output(payload)

    assert result.answer.startswith("Pytest")
    assert result.citations == ["doc-1"]
    assert result.uncertain is False


def test_output_contract_rejects_missing_answer():
    payload = {
        "citations": ["doc-1"],
        "uncertain": False,
    }

    with pytest.raises(ValidationError):
        parse_llm_output(payload)

Weitere Hilfreiche Tools

Und sobald das Ganze größer wird als ein paar lokale Tests, kommen für mich Eval-Tools ins Spiel. promptfoo ist stark, wenn du Prompt- und Red-Teaming-Suites als CLI und im CI laufen lassen willst. DeepEval ist interessant, wenn du Python-lastig arbeitest und LLM-Tests, Datensätze und Metriken enger an deinen Testworkflow hängen willst. Für RAG-Themen sind Ragas und TruLens spannend, weil dort Metriken wie Relevanz, Groundedness und Antwortqualität direkt im Fokus stehen. Und wenn du Runs, Datasets, Code-Evaluatoren und Alerts in einer Plattform sehen willst, ist LangSmith einen Blick wert.

Beispiel-Code 3 promptfoo:

promptfoo ist praktisch, wenn du sehr schnell reproduzierbare Prompt-/Eval-Suiten bauen und später auch Red-Team-Checks dazunehmen willst. Die offizielle Doku deckt genau diese Mischung aus Evals, Red Teaming und CI/CD ab.

description: halluzination-checks
prompts:
  - "Beantworte die Frage nur mit Informationen aus dem Kontext. Wenn etwas fehlt, sage 'unbekannt'.\n\nFrage: {{question}}\n\nKontext:\n{{context}}"

providers:
  - openai:gpt-4.1-mini

tests:
  - vars:
      question: "Welche Refund-Frist gilt?"
      context: "Alle Kunden erhalten 30 Tage Rückgaberecht."
    assert:
      - type: icontains
        value: "30"
      - type: not-icontains
        value: "60"

  - vars:
      question: "Wie heißt der CEO?"
      context: "Im Kontext ist keine CEO-Information enthalten."
    assert:
      - type: icontains
        value: "unbekannt"

Primärquellen und offizielle Doku

• NIST AI RMF / GenAI Profile zu „Confabulation“ als Halluzinations-/Fabrikationsrisiko.

• OpenAI: Why language models hallucinate.

• Anthropic: Demystifying evals for AI agents.

• pytest-Doku zu Fixtures, Parametrisierung und monkeypatch.

• Hypothesis-Doku und Quickstart.

• Pydantic-Doku zu Models, Validation und JSON Schema.

• OpenAI Structured Outputs Guide.

• OpenAI Cookbook zu Halluzinations-Guardrails.

• promptfoo Intro, Evals und Red Teaming.

• DeepEval Intro, Metrics, Test Cases und Datasets.

• Ragas Intro und Metrics.

• TruLens Quickstart, Feedback Functions und RAG Triad.

• LangSmith Code Evaluators und Alerts.

• Guardrails AI Validators und Custom Validators.

A Survey on Hallucination in Large Language Models.

Retrieval-Augmented Generation for Large Language Models: A Survey.

Evaluation of Retrieval-Augmented Generation: A Survey.

Metamorphic Testing for Fact-Conflicting Hallucination Detection.

MetaQA: Hallucination Detection in Large Language Models with Metamorphic Relations.

MetaRAG: Metamorphic Testing for Hallucination Detection in RAG Systems.