bank_support.py

Das Vorzeige-Beispiel: Support-Agent einer Bank mit Dependency Injection (Kundendaten-“DB”), Tool-Aufruf und typisiertem Ergebnis (inkl. Risiko-Score).

Für wen: Blaupause für jeden Business-Assistenten mit Datenzugriff.

Im Detail

Dieses Beispiel aus dem pydantic-ai-Repository zeigt an einem Bank-Support-Agenten, wie ein produktionsnaher KI-Assistent mit echtem Datenzugriff aufgebaut wird: Per Dependency Injection bekommt der Agent Zugriff auf eine simulierte Kundendatenbank, kann darüber Tools aufrufen (etwa Kontostand abfragen) und liefert ein typisiertes Ergebnis inklusive Risiko-Score zurück, statt nur freien Text. Das macht es zur guten Blaupause für jeden Assistenten, der nicht nur chatten, sondern strukturiert mit echten Geschäftsdaten arbeiten soll. Wer noch keine Erfahrung mit typisierten Pydantic-Modellen für Agenten-Ausgaben hat, sollte vorher das einfachere pydantic_model.py-Beispiel durchgehen, bevor Tool-Aufruf und Dependency Injection dazukommen.

Beispiel aus der Praxis

Eine Kundin fragt nach einer verdächtigen Abbuchung; der Agent ruft über die Dependency Injection ihre Kundendaten ab, nutzt ein Tool zur Prüfung des Falls und liefert statt Fließtext ein strukturiertes, typisiertes Ergebnis mit Risiko-Score, anhand dessen die Anwendung automatisch entscheidet, ob eskaliert werden muss.

Praxis-Tipp

Ersetzen Sie die simulierte Kundendatenbank Schritt für Schritt durch eine echte Datenquelle, etwa eine SQL-Abfrage, um das Dependency-Injection-Muster auf reale Daten zu übertragen.

Stolperfallen

Wer nur einen einfachen Chatbot ohne Datenanbindung bauen will, überdimensioniert mit diesem Beispiel – die Dependency-Injection- und Typisierungs-Struktur lohnt sich nur, wenn tatsächlich echte Datenzugriffe und verlässliche, maschinell weiterverarbeitbare Antworten gebraucht werden.

Siehe auch

• pydantic_model.py
• weather_agent.py
• sql_gen.py

Lizenz & Quelle

• Lizenz: MIT
• Quelle: pydantic/pydantic-ai