Produktwissen für Large-Language-Models bereitstellen
KI-Agenten erfreuen sich zunehmender Beliebtheit und sind sehr gut dazu geeignet Versicherungsangebote zu beauskunften. Damit dies gelingt, muss die Versicherungsgesellschaft die Eigenschaften des Produkts in strukturierter Form bereitstellen. Die erfolgt optimaler Weise über Knowledge-Graphen bzw. Linked-Data.
Da die Produkte sich nach Abschlusszeitpunkt und Vertriebskanal unterscheiden und genaue Auskünfte erforderlich sind, müssen sie über Schnittstellen bereitgestellt werden. Auch Validierungen und Berechnungen müssen über Schnittstellen erfolgen. Die Bereitstellung dieser Funktionen kann über proprietäre Schnittstellen des jeweiligen LLM-Anbieters erfolgen oder über Model Context Protocol (MCP).
Was ist MCP?
Das Model Context Protocoll (MCP) ist ein neu entstandener Standard, um Schnittstellen in Large-Language-Models einzubetten. Hauptsponsor ist Anthropic. Er wird derzeit von einigen LLM-Providern unterstützt.
Welche Vorteile bietet die Einbettung von Schnittstellen wie MCP?
- Konsistenz und Aktualität:
- LLMs greifen zur Laufzeit auf aktuelle Produktstände zu
- Deterministische Berechnungen / Regeln aus zentralen Engines
- Gutes Produktverständnis des Agenten
- Nachvollziehbarkeit und Compliance:
- Jede Antwort kann Produkt, Version und Stichtag nennen
- Auditierbare Tool-Aufrufe, reproduzierbare Ergebnisse
- Sicherheit:
- Least-Privilege-Zugriff, PII-Schutz, kontrollierte Exposition
- Kein Leaken von proprietären Logiken in Trainingsdaten
- Wirtschaftlichkeit und Agilität:
- Produktänderungen wirken sofort in Beratung und Antrag, ohne LLM-Neutrainings
- Klare Verträge (Schemas), einfaches Testen und Rollback
Wie kann formales Versicherungsproduktwissen über MCP bereitgestellt werden?
Über MCP wird Produktwissen als klar abgegrenzte Ressourcen (lesbar) und Tools (ausführbar) bereitgestellt. Die Logik bleibt in den Quellsystemen, LLMs greifen zur Laufzeit kontrolliert darauf zu.
- Ressourcen (read-only):
- Verweise auf Versicherungsbedingungen und Produktinformationen
- Vokabular, Dictionaries, Ontologien
- Produktkatalog (Produktstände, Tarifstände)
- Tools (operationale Funktionen):
- Verkaufsoffene Produkte: a priori Wissen zu Produkten für einen Stichtag
- Produkt-Modell: strukturiertes Produktmodell inkl. Bausteinen/Abhängigkeiten
- Berechnung: Prämienberechnung
- Offerterstellung
- Antragserstellung und -einreichung: fachliche Validierung inkl. Pflichtfeldern, Abhängigkeiten, Grenzen
- Dokumente: konsistente Dokumentverweise passend zum Stand
Umsetzung mit Knowledge-Graph/Linked-Data
Wenn Produktwissen als Knowledge-Graph (Linked-Data) vorliegt, lässt es sich besonders einfach in LLMs einbinden, da LLMs oft bereits auf die Verarbeitung von Knowledge-Graphen ausgelegt sind. Welche Schritte sind dafür notwendig?
- Domänenmodell sichten:
- Relevante Klassen/Properties identifizieren (Produkt, Deckung, Ausschluss, Parameter, Regel, Dokument)
- Gültigkeiten und Versionierung im Graphen prüfen (z. B. Gültig-ab/-bis, Produktstand/Tarifstand)
- Shapes und Constraints definieren:
- SHACL-Shapes für Eingaben (Antrag) und Produktstruktur
- Mapping von Geschäftsregeln auf SHACL/Rule-Representations oder Referenzen auf externe Engines
- Abfrage-Layer erstellen:
- SPARQL-Queries/Views für häufige Lesezugriffe (Produktlisten, Detailansichten, Dokumentlinks)
- Materialisierte JSON-Views (wo Performance nötig ist), inkl. Stichtag-Filter
- MCP-Ressourcen modellieren:
- Resources, die SPARQL-Views als JSON liefern (read-only, versioniert)
- Quellenangabe: Graph-IRI, Dataset-Version, Commit/Build-Info
- MCP-Tools anbinden:
- calculatePremium/validateApplication leiten Requests an Tarif-/Regel-Engines weiter
- Parameter-/Faktormodelle aus dem Graph lesen, Ergebnisse in JSON mit SHACL-Validierungsbefunden zurückgeben
- Versionierung & Stichtage:
- Stand-Parameter in jedem Tool/Resource-Aufruf erzwingen
- Semantische Versionen des Datasets; Breaking Changes via neue Resource-/Tool-Versionen