Unverzichtbarer Leitfaden zur Sicherstellung von Stabilität bei der Einführung von Natural-Language-APIs in Produktion (Microsoft Developer Community)

Kernprinzipien

• Beim Aufbau von Natural-Language-APIs für den produktiven Einsatz ist die Trennung von semantic parsing und execution essenziell
• LLMs werden ausschließlich für die Umwandlung von natürlicher Sprache in strukturierte Anfragen (canonical structured requests) verwendet
• Natürliche Sprache darf nur als Eingabe behandelt werden und nicht als API-Vertrag dienen (Sprache ist fragil)

Probleme bei der direkten Verwendung natürlicher Sprache

• Nichtdeterministisches Verhalten (nondeterministic behavior)
• Prompt-basierte Business-Logik → schwer zu debuggen und zu reproduzieren
• Implizite API-Verträge → schon kleine Änderungen verändern das Verhalten
• Stille Fehler (silent failures) treten auf, das System wird anfällig

Architektur: Trennung in zwei Schichten

1. Semantic Parse API (natürliche Sprache → Struktur)

• Nimmt Texteingaben von Nutzern entgegen
• Extrahiert mit einem LLM Intent und Entities
• Vervollständigt ein vordefiniertes Schema
• Stellt bei fehlenden Informationen Rückfragen zur Klärung (Ausführung von Business-Logik verboten)
• Agiert wie ein Compiler (z. B. “blue backpack but cheaper” → {intent: “recommend_similar”, reference_product_id: “blue_backpack_123”, price_bias: -0.8})

2. Structured Execution API (Struktur → Ausführung)

• Akzeptiert nur strukturierte Eingaben
• Deterministisch, versionierbar und testbar
• Keine Verarbeitung natürlicher Sprache, sondern ein stabiles Backend

Zentrale Elemente: Canonical Schemas

• Im Code definierte Verträge pro Intent (Pflicht-/optionale Felder, Wertebereiche, Validierungsregeln)
• Fangen Varianten natürlicher Sprache ab → sorgen für konsistente Ausgaben
• Dienen als Rückgrat des API-Vertrags

Schema Completion (Klärung)

• Bei fehlenden Informationen Antwort “needs_clarification” (fehlende Felder, gezielte Frage, aktueller Zustand)
• Speicherverwaltung über ein Zustandsobjekt (die API ist stateless)
• Der Client übergibt den Zustand und hält so den Dialog aufrecht → bei Vervollständigung wird canonical_request ausgeführt

Orchestrierung: Einsatz von LangGraph

• Modellierung strukturierter Workflows (Intent-Klassifikation → Entity-Extraktion → Schema-Zusammenführung → Validierung → Routing zu Vervollständigung/Klärung)
• Entscheidungen werden codebasiert getroffen, das LLM macht nur Vorschläge
• Klare Zustandsübergänge, gute Beobachtbarkeit und sichere Wiederholungsversuche

Sicherheitsmechanismus: Confidence Gates

• Für LLM-Ausgaben wird ein Confidence Score verlangt
• Wird der Schwellenwert nicht erreicht, wird die Ausführung blockiert und eine Klärung angefordert (z. B. mehrdeutiges “the bag” → geringe Konfidenz → Zusatzfrage)
• Verhindert stille Fehlinterpretationen

Normalisierung: Lightweight Ontologies

• Codebasiert (zulässige Intents, Synonym-Mappings, feldübergreifende Validierung)
• Vom LLM vorgeschlagene Werte → per Code normalisiert (z. B. “cheaper” → price_bias: -0.7)
• Bei logischen Widersprüchen erfolgt eine Klärung (z. B. Rückfrage zur Priorität zwischen günstig und hoher Qualität)

Leistungsaspekte

• Latenz: Intent-Klassifikation ~40 ms, Entity-Extraktion ~200 ms, Validierung 1 ms → insgesamt 250300 ms
• Für Chat-UX akzeptabel und günstiger als die Kosten von Fehlern

Wichtigste Erkenntnisse (Key Takeaways)

• Sprache ist kein API-Vertrag, sie muss in Struktur umgewandelt werden
• Die serverseitige Schema-Vervollständigung muss dem Server gehören
• LLMs nur für Discovery und Extraktion einsetzen, nicht für die Ausführung
• Sicherheit und Determinismus haben höchste Priorität
• Basierend auf praktischer Erfahrung beim Aufbau realer Systeme mit Azure OpenAI + LangGraph

https://aisparkup.com/posts/9012