Fehlerhafte Ausgaben validieren und erneut versuchen
Sie implementieren eine Validierungsschicht, die extrahierte Daten anhand von Geschäftsregeln prüft, bei fehlgeschlagener Validierung automatisch einen korrigierenden Retry ausführt und Fehlermuster protokolliert.
Fehlerhafte Ausgaben validieren und erneut versuchen ist eine kostenlose AI Engineering Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des AI Engineering Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der AI Engineering Academy-Kurs umfasst insgesamt 4 Lektionen.
Warum LLM-Ausgaben validiert werden müssen
Selbst bei strukturierten Ausgaben und Pydantic-Schemas kann die LLM-Extraktion Ausgaben erzeugen, die syntaktisch gültig, aber semantisch falsch sind. Ein Konfidenzwert von 1,5 (außerhalb des Bereichs von 0 bis 1), ein Preis von -99,99, eine nicht parsebare Datumszeichenfolge oder eine Telefonnummer mit Buchstaben – all dies besteht zwar das JSON-Parsing, verletzt aber Ihre Geschäftsregeln.
Validierung ist ein von der Extraktion getrenntes Anliegen. Die Extraktion fragt: „Haben wir strukturierte Daten erhalten?“ Die Validierung fragt: „Sind die strukturierten Daten korrekt und verwendbar?“ Für eine produktionsreife Pipeline sind beide Ebenen erforderlich. Stellen Sie sich das als zweistufigen Filter vor: Das LLM extrahiert, Ihr Validator akzeptiert oder verwirft.
Validierungsebenen
Ein robustes System zur Validierung von Ausgaben arbeitet auf mehreren Ebenen:
- Schema-Validierung (Pydantic): korrekte Feldtypen, vorhandene Pflichtfelder und zulässige Enum-Werte – wird automatisch durch strukturierte Ausgaben übernommen
- Formatvalidierung: Telefonnummern entsprechen einem Regex, E-Mail-Adressen sind gültig, Datumsangaben lassen sich parsen und Beträge liegen in realistischen Bereichen
- Validierung der Geschäftslogik: Die Rechnungssumme entspricht der Summe der Positionen, das Enddatum liegt nach dem Startdatum und die Menge ist eine positive Ganzzahl
- Feldübergreifende Validierung: Der Wert eines Feldes hängt vom Wert eines anderen Feldes ab (z. B. darf der Rabattprozentsatz 100 nicht überschreiten)
- Semantische Validierung: Der extrahierte Unternehmensname entspricht einem bekannten Unternehmen in Ihrer Datenbank
Pydantic-Validatoren für Formatprüfungen
Mit dem field_validator-Decorator von Pydantic können Sie benutzerdefinierte Validierungslogik hinzufügen, die bei der Instanziierung des Modells ausgeführt wird. Verwenden Sie ihn für Prüfungen auf Formatebene, etwa die Regex-Validierung von Telefonnummern und E-Mail-Adressen, das Parsen von Datumsangaben sowie Bereichsprüfungen für numerische Felder.
from pydantic import BaseModel, Field, field_validator
from typing import Optional
import re
from datetime import datetime
class ExtractedInvoice(BaseModel):
vendor: str
invoice_number: Optional[str]
amount: float = Field(gt=0, description='Must be positive')
currency: str = Field(min_length=3, max_length=3)
invoice_date: str
@field_validator('currency')
@classmethod
def currency_must_be_uppercase(cls, v):
return v.upper()
@field_validator('invoice_date')
@classmethod
def parse_date(cls, v):
# Try to parse common date formats
for fmt in ('%Y-%m-%d', '%d/%m/%Y', '%m/%d/%Y', '%B %d, %Y'):
try:
datetime.strptime(v, fmt)
return v
except ValueError:
continue
raise ValueError(f'Cannot parse date: {v}')
@field_validator('amount')
@classmethod
def reasonable_amount(cls, v):
if v > 10_000_000:
raise ValueError(f'Amount {v} seems unreasonably large. Flag for review.')
return round(v, 2)Das Muster „Wiederholung mit korrigierendem Feedback“
Wenn die Validierung fehlschlägt, ist die effektivste Wiederherstellungsstrategie eine Wiederholung mit korrigierendem Feedback: Senden Sie die Validierungsfehlermeldung als Kontext an das Modell zurück, erklären Sie, was schiefgelaufen ist, und bitten Sie es, nur die fehlerhaften Felder zu korrigieren. So erhält das Modell die nötigen Informationen, um seine Ausgabe zu korrigieren, anstatt lediglich blind einen weiteren Versuch zu unternehmen.
import openai
from pydantic import BaseModel, ValidationError, Field
client = openai.OpenAI()
class PriceExtraction(BaseModel):
product: str
price_usd: float = Field(gt=0, lt=100000)
quantity: int = Field(ge=1)
def extract_with_retry(text: str, max_retries: int = 3) -> PriceExtraction:
messages = [
{'role': 'system', 'content': 'Extract product pricing information.'},
{'role': 'user', 'content': text}
]
for attempt in range(max_retries):
result = client.beta.chat.completions.parse(
model='gpt-4o-mini',
messages=messages,
response_format=PriceExtraction
)
msg = result.choices[0].message
if msg.refusal:
raise ValueError(f'Model refused: {msg.refusal}')
try:
return msg.parsed # Pydantic validates on parse
except ValidationError as e:
if attempt == max_retries - 1:
raise
# Add corrective feedback for the next attempt
messages.append({'role': 'assistant', 'content': msg.content})
messages.append({'role': 'user', 'content': f'The previous extraction failed validation: {e}\nPlease correct and try again.'})
print(f'Attempt {attempt+1} failed. Retrying with feedback...')Validierung der Geschäftslogik
Die Validierung der Geschäftslogik prüft Eigenschaften, die sich über mehrere Felder erstrecken oder von externen Datenquellen abhängen. Pydantics model_validator wird nach allen feldbezogenen Validatoren ausgeführt und kann auf das vollständig befüllte Modell zugreifen. Damit ist er der richtige Ort für feldübergreifende Prüfungen.
from pydantic import BaseModel, Field, model_validator
from typing import List
class LineItem(BaseModel):
description: str
quantity: int = Field(ge=1)
unit_price: float = Field(ge=0)
line_total: float
@model_validator(mode='after')
def check_line_total(self):
expected = round(self.quantity * self.unit_price, 2)
actual = round(self.line_total, 2)
if abs(expected - actual) > 0.02: # Allow 2-cent rounding tolerance
raise ValueError(
f'Line total {actual} does not match quantity*price={expected}'
)
return self
class Invoice(BaseModel):
line_items: List[LineItem]
subtotal: float
tax: float
total: float
@model_validator(mode='after')
def check_invoice_total(self):
expected_total = round(self.subtotal + self.tax, 2)
if abs(expected_total - round(self.total, 2)) > 0.02:
raise ValueError(
f'Invoice total {self.total} != subtotal+tax ({expected_total})'
)
return selfValidierungsfehler protokollieren
Jeder Validierungsfehler ist ein Hinweis darauf, an welcher Stelle Ihre Pipeline Probleme hat. Protokollieren Sie jeden Fehler mit: dem Eingabetext (oder aus Datenschutzgründen einem Hash davon), der extrahierten Ausgabe, dem konkreten Validierungsfehler und der Versuch nummer. Fassen Sie diese Protokolle zusammen, um systematische Muster zu erkennen: Liegt das Modell bei einem Feld durchgehend falsch? Gibt es eine Dokumentklasse, die Fehler verursacht? Diese Daten bilden die Grundlage für gezielte Prompt-Verbesserungen.
import logging
from pydantic import ValidationError
logger = logging.getLogger(__name__)
def extract_with_logging(text: str, doc_id: str) -> dict:
result = None
for attempt in range(3):
try:
result = run_extraction(text) # Your extraction function
logger.info('Extraction success', extra={
'doc_id': doc_id,
'attempt': attempt + 1
})
return result
except ValidationError as e:
logger.warning('Validation failure', extra={
'doc_id': doc_id,
'attempt': attempt + 1,
'errors': e.errors(),
'error_count': len(e.errors())
})
# All retries failed
logger.error('Extraction failed after max retries', extra={'doc_id': doc_id})
return {'error': 'extraction_failed', 'doc_id': doc_id}
def run_extraction(text):
pass # Placeholder for actual extraction logicKonfidenzwerte und Schwellenwerte
Fügen Sie Ihrem Extraktionsschema ein Feld confidence hinzu und weisen Sie das Modell an, seine Konfidenz für jede Extraktion mit einem Wert zwischen 0 und 1 zu bewerten. Wenden Sie anschließend abhängig von der Konfidenz Geschäftsregeln an: Extraktionen mit hoher Konfidenz werden direkt in Ihrer Datenbank gespeichert, Extraktionen mit mittlerer Konfidenz werden zur stichprobenartigen Prüfung markiert, und Extraktionen mit niedriger Konfidenz werden einer Warteschlange zur manuellen Prüfung zugewiesen.
Dieser probabilistische Ansatz ist wesentlich praxisnäher, als vom LLM eine Genauigkeit von 100 % zu verlangen — Sie entwerfen Ihre Pipeline so, dass sie Unsicherheit angemessen verarbeitet, anstatt so zu tun, als gäbe es sie nicht.
from pydantic import BaseModel, Field
from typing import Optional
class ExtractedWithConfidence(BaseModel):
value: Optional[str]
confidence: float = Field(ge=0.0, le=1.0)
reason: Optional[str] = None # Why confidence is low, if below threshold
class DocumentExtraction(BaseModel):
vendor_name: ExtractedWithConfidence
invoice_amount: ExtractedWithConfidence
due_date: ExtractedWithConfidence
def route_by_confidence(extraction: DocumentExtraction, threshold=0.85):
low_confidence_fields = []
for field_name, field_val in extraction.model_dump().items():
if isinstance(field_val, dict) and field_val.get('confidence', 1.0) < threshold:
low_confidence_fields.append(field_name)
if not low_confidence_fields:
return 'auto_approve'
elif len(low_confidence_fields) > 2:
return 'human_review'
else:
return f'spot_check: {low_confidence_fields}'Fallback-Strategien bei fehlgeschlagenen Wiederholungsversuchen
Wenn alle Wiederholungsversuche ausgeschöpft sind und die Validierung weiterhin fehlschlägt, benötigen Sie eine Fallback-Strategie. Optionen in absteigender Priorität:
- Teilergebnis: Geben Sie die Felder zurück, deren Validierung erfolgreich war, und setzen Sie die fehlerhaften Felder auf null
- Warteschlange zur manuellen Prüfung: Fügen Sie das Dokument einer Warteschlange zur manuellen Prüfung hinzu, insbesondere bei Dokumenten mit hohem Wert
- Extraktion mit geringerer Detailtreue: Wechseln Sie zu einem einfacheren Schema, das weniger Felder anfordert, und akzeptieren Sie zugunsten der Robustheit eine weniger strukturierte Ausgabe
- Speicherung des Rohtexts: Speichern Sie den Originaltext mit Metadaten zur späteren erneuten Verarbeitung, sobald Sie Ihre Extraktionspipeline verbessert haben
Verwerfen Sie das Dokument niemals stillschweigend. Protokollieren Sie den Fehler immer und stellen Sie sicher, dass Sie später darauf zurückgreifen können.
Semantische Validierung anhand externer Daten
Für einige Validierungsregeln sind Abfragen externer Daten erforderlich, die nicht innerhalb von Pydantic-Validatoren ausgeführt werden können. Sie können beispielsweise prüfen, ob ein extrahierter Firmenname in Ihrem CRM vorhanden ist oder ob eine extrahierte Produkt-SKU in Ihrem Inventar existiert. Diese Prüfungen gehören in einen Validierungsschritt nach der Extraktion, der ausgeführt wird, nachdem die Pydantic-Validierung erfolgreich war.
from typing import Optional
# Simulated external data source
KNOWN_VENDORS = {'acme corp', 'techsupplies inc', 'globex corporation'}
def validate_against_crm(extraction: dict) -> dict:
vendor = extraction.get('vendor', '').lower()
warnings = []
if vendor and vendor not in KNOWN_VENDORS:
warnings.append({
'field': 'vendor',
'issue': f'Vendor "{vendor}" not found in CRM',
'severity': 'warning'
})
# Optionally suggest closest match
# from difflib import get_close_matches
# matches = get_close_matches(vendor, KNOWN_VENDORS, n=1, cutoff=0.8)
# if matches: warnings[-1]['suggestion'] = matches[0]
return {
'extraction': extraction,
'warnings': warnings,
'requires_review': len(warnings) > 0
}
print('Semantic validation pattern defined')Ihre Validierungspipeline testen
Ihre Validierungslogik benötigt eine eigene Testsuite, getrennt von den Extraktionstests. Schreiben Sie Unit-Tests, die bekannte fehlerhafte Ausgaben an Ihre Validatoren übergeben und überprüfen, ob die korrekten Fehler ausgelöst werden. Testen Sie Grenzfälle: Beträge an den Grenzwerten, Datumsangaben in ungewöhnlichen Formaten, Felder mit unerwarteten Leerzeichen sowie Felder, die numerische Zeichenketten statt Zahlen enthalten.
Diese Validierungstestsuite wird ohne API-Aufrufe ausgeführt und lässt sich daher bei jeder Codeänderung schnell und kostengünstig ausführen. Sie ist außerdem die beste Dokumentation Ihrer Validierungsregeln — die Testfälle machen jede von Ihrer Pipeline erzwungene Format- und Geschäftsanforderung ausdrücklich sichtbar.
from pydantic import ValidationError
def test_extraction_validation():
# Test cases: (input_data, should_pass)
test_cases = [
({'vendor': 'ACME', 'amount': 150.00, 'currency': 'USD', 'invoice_date': '2025-01-15'}, True),
({'vendor': 'ACME', 'amount': -50.00, 'currency': 'USD', 'invoice_date': '2025-01-15'}, False), # negative
({'vendor': 'ACME', 'amount': 150.00, 'currency': 'EURO', 'invoice_date': '2025-01-15'}, False), # 4-char
({'vendor': 'ACME', 'amount': 150.00, 'currency': 'USD', 'invoice_date': 'yesterday'}, False), # bad date
]
passed = failed = 0
for data, should_pass in test_cases:
try:
# ExtractedInvoice(**data) # Your Pydantic model
if should_pass:
passed += 1
else:
print(f'MISSED: Should have failed for {data}')
failed += 1
except (ValidationError, ValueError):
if not should_pass:
passed += 1
else:
print(f'UNEXPECTED FAIL for {data}')
failed += 1
print(f'Tests: {passed} passed, {failed} failed')
test_extraction_validation()Analyse wiederkehrender Fehler und Optimierung von Prompts
Nachdem Sie Ihre Extraktionspipeline auf einer Stichprobe echter Dokumente ausgeführt und Validierungsfehler überprüft haben, werden Sie wahrscheinlich feststellen, dass 80 % der Fehler auf wenige gemeinsame Hauptursachen zurückzuführen sind. Häufige Ursachen sind, dass das Modell Datumsangaben aus einer bestimmten Region wiederholt falsch formatiert, den Steuerbetrag mit dem Gesamtbetrag verwechselt oder Telefonnummern ohne Bindestriche erzeugt, obwohl Ihr Validator Bindestriche erwartet.
Aktualisieren Sie für jedes wiederkehrende Fehlermuster Ihren Extraktionsprompt mit einem konkreten Beispiel und einer Einschränkung, die diesen Fehler verhindert. Führen Sie anschließend Ihre vollständige Testsuite erneut aus, um zu bestätigen, dass die Korrektur die Genauigkeit verbessert hat, ohne andere Fälle zu verschlechtern. Durch diesen iterativen Zyklus aus Prompt-Anpassung und Bewertung erreichen produktive Extraktionspipelines bei realen Daten eine Genauigkeit von über 95 %.
Schnelltest
Testen Sie Ihr Verständnis der AI-Engineering-Konzepte aus dieser Lektion.
Zusammenfassung der Lektion
In dieser Lektion haben Sie gelernt: Validierung findet auf mehreren Ebenen statt — Schema, Format, Geschäftslogik und Semantik — und für jede Ebene sind unterschiedliche Implementierungsansätze erforderlich, Wiederholungsversuche mit korrigierendem Feedback liefern dem Modell einen konkreten Fehlerkontext, damit es seine Ausgabe effizient korrigieren kann, und Konfidenzwerte ermöglichen eine probabilistische Weiterleitung an Warteschlangen zur automatischen Freigabe, zur stichprobenartigen Prüfung oder zur manuellen Prüfung, abhängig von der Sicherheit der Extraktion. Sie haben nun den Kurs zu Structured Output und JSON Mode abgeschlossen. Als Nächstes beschäftigen wir uns mit Vektor-Embeddings — der Grundlage jedes RAG-Systems.
Häufig gestellte Fragen
Ist die Lektion „Fehlerhafte Ausgaben validieren und erneut versuchen“ kostenlos?
Ja — der vollständige Text von „Fehlerhafte Ausgaben validieren und erneut versuchen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des AI Engineering Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der AI Engineering Academy-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Fehlerhafte Ausgaben validieren und erneut versuchen“?
Sie implementieren eine Validierungsschicht, die extrahierte Daten anhand von Geschäftsregeln prüft, bei fehlgeschlagener Validierung automatisch einen korrigierenden Retry ausführt und Fehlermuster… Du übst AI Engineering Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um AI Engineering Academy zu starten?
Keine Vorkenntnisse erforderlich. AI Engineering Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.
Wie lange dauert die Lektion „Fehlerhafte Ausgaben validieren und erneut versuchen“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser AI Engineering Academy-Lektion Code schreiben und ausführen?
Ja. Jede AI Engineering Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- JSON-Modus und response_format
- Strukturierte Ausgaben mit Pydantic
- Daten aus unstrukturiertem Text extrahieren
- Fehlerhafte Ausgaben validieren und erneut versuchen