Über RAG hinaus: KI-Agenten mit Echtzeit-Kontext

Wir sprechen viel über die Vorteile des Einsatzes von KI im Kundenservice. Sie kann ein echter Wendepunkt sein, wenn es darum geht, den Umsatz zu steigern und gleichzeitig die Betriebskosten zu senken. Es ist jedoch wichtig, sich daran zu erinnern, dass KI kein Zauberstab ist, der ohne die richtige Implementierung alle Probleme lösen kann.

Stellen Sie sich diese übliche Szene im E-Commerce-Kundenservice vor:

Ein treuer Kunde, der sich über eine verspätete Lieferung ärgert, fragt einen Chatbot: "Meine Bestellung ist verspätet, kann ich eine Rückerstattung bekommen?" Der Chatbot prüft seine Datenbank, die zuletzt vor Stunden aktualisiert wurde, und antwortet zuversichtlich: "Ihre Bestellung ist als 'Zu liefern' gekennzeichnet und liegt im Zeitplan".

Aber hier ist das Problem: Nur zehn Minuten vor dieser Interaktion protokollierte der Logistikpartner ein Ereignis "delivery_exception". Das KI-System wusste jedoch nichts von dieser wichtigen Aktualisierung.

Dies ist ein häufiges Problem im heutigen KI-Kundenservice. Es deutet auf einen großen Konstruktionsfehler hin: kontextuelle Blindheit. Die Antwort des Systems war aufgrund seiner veralteten Informationen technisch korrekt, aber diese Informationen waren völlig losgelöst von der Realität.

Dieses Problem der kontextuellen Blindheit führt zu einem negativen Kundenerlebnis:

- Sie treffen oft auf ineffektive Agenten, die einfach nicht die richtigen Informationen haben, um ihre Probleme zu lösen.

- Dies führt zu dem, was man als"Agentenkarussell" oder Gesprächsschleife bezeichnet - Kunden werden mehrfach weitergeleitet und müssen ihr Problem immer und immer wieder wiederholen.

Die Achillesferse der konventionellen Agenten: Veraltete Kontexte

Entscheidend ist, dass es sich hierbei nicht um ein kleines Problem handelt, das durch die Verwendung eines etwas besseren Large Language Model (LLM) behoben werden kann. Das eigentliche Markenzeichen wirklich fortschrittlicher KI-Agenten sind nicht nur ihre logischen Fähigkeiten, sondern auch ihr tiefes Echtzeit-Bewusstsein (bis auf die Millisekunde genau) für das Geschäftsumfeld, in dem sie agieren.

Die Effektivität eines jeden intelligenten Agenten wird grundsätzlich durch die Qualität und Aktualität der Informationen begrenzt, auf die er zugreifen kann. Eine Versandaktualisierung von gestern ist nicht nur weniger wertvoll. Für einen Kunden, der sich heute nach seiner Lieferung erkundigt, ist sie aktiv irreführend und kontraproduktiv. Dies ist die Herausforderung der Datenlatenz und der Kontextabweichung, die Achillesferse herkömmlicher KI-Agentenarchitekturen.

Herkömmliche Systeme, die oft auf Batch-Verarbeitungsparadigmen aufbauen, sind von Natur aus ungeeignet für die Anforderungen der agentenbasierten KI in Echtzeit. In einer stapelgesteuerten Architektur werden Daten gesammelt, verarbeitet und nach einem regelmäßigen Zeitplan - in der Regel nachts - in Analysesysteme geladen.

Architekturentwurf für kontextabhängige agentenbasierte KI

Der Schlüssel zur Weiterentwicklung der agentenbasierten KI liegt im Aufbau eines kontextbezogenen Systems - einer ereignisgesteuerten Echtzeitarchitektur, die das "Gehirn" des Agenten (das LLM) mit einem kontinuierlichen Strom von Informationen über den Zustand des Unternehmens versorgt. Wir werden einen architektonischen Einblick in die Kernkomponenten und ihre synergetischen Rollen geben:

pgvector & Semantische Suche: Hierbei handelt es sich um das Langzeitgedächtnis des Agenten, eine Wissensbasis vergangener Interaktionen und Lösungen, die einen tiefgreifenden historischen Kontext liefert, um die aktuelle Entscheidungsfindung zu informieren und zu verbessern.

‌

Diese Architektur stellt sicher, dass der KI-Agent Zugriff auf den Kundenkontext in Echtzeit hat, was aktuelle und personalisierte Antworten im Kundenservice ermöglicht.

Den Stapel abbauen

Das Echtzeit-Backbone: Kafka und Flink

Das Herzstück dieser Architektur ist Apache Kafka, das als zentrales, dauerhaftes und hochskalierbares Protokoll für alle Geschäftsereignisse dient. Kafka fungiert als einzige Quelle der Wahrheit für Daten in Bewegung und entkoppelt die Systeme, die Daten produzieren (z.B. das E-Commerce-Backend, die APIs der Versanddienstleister, CRM) von den Systemen, die sie konsumieren (wie unsere Flink-Anwendung). Diese Entkopplung ist entscheidend für den Aufbau einer skalierbaren und widerstandsfähigen Architektur, in der sich die Komponenten unabhängig voneinander weiterentwickeln können.

Während Kafka den Ereignisstrom liefert, stellt Apache Flink das Framework für dessen Verarbeitung bereit. Flink ist nicht nur ein Tool zur Datentransformation. Es ist ein leistungsstarkes zustandsorientierte Stream-Verarbeitungsmaschine. Diese Zustandsabhängigkeit ist der Grundstein der Architektur. Flink nutzt Ereignisströme von Kafka, um einen umfangreichen, speicherinternen "Status" für jede aktive Entität innerhalb des Unternehmens zu erstellen und kontinuierlich zu pflegen, z. B. die aktuelle Sitzung jedes Kunden oder jede offene Bestellung. Dieser Status stellt den aktuellsten, umfassendsten Kontext dar, der zu einem bestimmten Zeitpunkt verfügbar ist und wird mit einer Latenzzeit von Millisekunden aktualisiert, sobald neue Ereignisse eintreffen.

CREATE
TEMPORARY VIEW enriched_clicks AS
SELECT c.event_time, c.user_id, c.url,c.event_type, c.event_properties, cust.tier
FROM clickstream_events AS c
        JOIN customers FOR SYSTEM_TIME AS OF c.event_time AS cust ON c.user_id = cust.customer_id;

Reichern Sie den Clickstream mit Kundendaten an, indem Sie einen Temporal Join verwenden. So entsteht eine kontinuierliche Ansicht der Klicks, jetzt mit Informationen zur Kundenebene.

Flink dient nicht nur der Vorverarbeitung von Daten für den Agenten. Seine reichhaltige API ermöglicht es Ihnen, Echtzeitanwendungen mit Cross-Stream-Joins, komplexen ereignisgesteuerten Pipelines und zustandsabhängigen Analysen zu erstellen - ob über eine High-Level-SQL-Schnittstelle oder eine programmatische API. Wenn der Agent handeln muss, muss er nicht mehrere langsame, unterschiedliche Quellsysteme abfragen. Stattdessen kann er sofort mit einem vorberechneten Snapshot davon versorgt werden.

INSERT INTO customer_session_summary
SELECT
    window_start,
    window_end,
    user_id,
    MAX(tier) AS tier, -- Tier is constant within the session
    COUNT(*) AS clicks_in_session -- Example calculated aggregate
FROM
    TABLE(
        SESSION(
            TABLE enriched_clicks,
            DESCRIPTOR(event_time),
            INTERVAL '1' MINUTES
        )
    )
GROUP BY
    window_start,
    window_end,
    user_id;

Aggregieren von Benutzerereignissen in Sitzungen, die durch die Zeit der Inaktivität des Benutzers definiert sind. Neben der SQL-Syntax bietet Apache Flink auch eine umfangreiche programmatische API

Der kognitive Kern des Agenten: Orchestrieren mit LangGraph und Reasoning mit Gemini

Mit einem Echtzeit-Backbone, das einen kontinuierlichen Kontext liefert, besteht die nächste Herausforderung darin, einen kognitiven Kern aufzubauen, der diesen Kontext zum Denken, Planen und Handeln nutzt. Kundendienstgespräche sind selten linear - sie umfassen Schleifen (z.B. "Kann ich Ihnen sonst noch helfen?"), bedingte Logik (z.B. "Wenn der Artikel beschädigt ist, leiten Sie eine Rücksendung ein, andernfalls prüfen Sie die Garantie") und ständige Zustandsänderungen. Eine einfache, lineare Kette von LLM-Aufrufen ist für die Bewältigung dieser Komplexität nicht ausreichend.

An dieser Stelle wird ein Framework wie LangGraph unverzichtbar. LangGraph wurde für die Erstellung zustandsabhängiger Anwendungen entwickelt, die als Graphen und nicht als Ketten modelliert werden. Das LangGraph-Framework basiert auf ein paar Schlüsselkonzepten:

‌

Graph stellt einen zyklischen Arbeitsablauf für einen einzelnen KI-Agenten dar. Das Herzstück ist ein Entscheidungsknoten, der bewertet, ob ein Werkzeug verwendet werden sollte, und wenn ja, das entsprechende Werkzeug aus einer Reihe von registrierten Werkzeugen auswählt. Der Arbeitsablauf ist zustandsabhängig, mit Zugriff auf AgentState

Gemini als Denkmaschine

Innerhalb des reasoning_node dient ein leistungsstarker LLM wie Googles Gemini (gemini-2.5-pro oder ähnlich) als "Gehirn" des Agenten. Er empfängt den gesamten AgentState als seinen Eingabekontext. Dazu gehören die anfänglichen Echtzeitdaten von Flink (z.B. "Auftrag #123 ist verzögert wegen WAREHOUSE_SCAN_MISSED") und der gesamte Verlauf der Konversation. Geminis fortschrittliche Argumentations- und Funktionsaufruffähigkeiten ermöglichen es, diesen reichhaltigen Kontext zu analysieren und einen präzisen Aktionsplan zu formulieren, z.B. den Aufruf eines bestimmten Tools mit den richtigen Parametern.

Ein einzigartiger Vorteil dieser Architektur ist die Möglichkeit der dynamischen Erstellung von Werkzeugen. Der von Flink gelieferte Echtzeitkontext kann verwendet werden, um die dem Agenten für eine bestimmte Interaktion zur Verfügung stehenden Tools dynamisch zu erstellen oder zu ändern. Wenn aus dem Kontext beispielsweise hervorgeht, dass es sich bei dem Kunden um einen 'VIP' handelt und seine Bestellung 'verspätet' ist, kann das System dynamisch ein grant_service_credit-Tool erstellen und der Liste der Funktionen hinzufügen, die dem Gemini-Modell präsentiert werden. Dies macht den Agenten hochgradig anpassungsfähig und stattet ihn mit genau den Fähigkeiten aus, die zur Lösung einer Situation erforderlich sind, ohne dass unnötige oder irrelevante Funktionen angezeigt werden.

Das Gedächtnis des Agenten: Hybride Datenabfrage mit pgvector

Während das Flink- und Kafka-Backbone den Agenten mit seinem kurzfristigen Echtzeit-Kontext versorgt, benötigt ein effektiver Agent auch ein Langzeitgedächtnis (LTM). Er muss aus der Vergangenheit lernen, um Probleme in der Gegenwart zu lösen. In unserer Architektur wird dieses LTM mithilfe einer PostgreSQL-Datenbank implementiert, die mit der pgvector-Erweiterung erweitert wurde. Diese Datenbank speichert vektorisierte Darstellungen (Einbettungen) von historischen Support-Tickets, deren Lösungen und FAQs des Unternehmens.

Der Prozess der Befüllung dieser LTM beinhaltet eine unkomplizierte Pipeline zur Erzeugung von Einbettungen. Unter Verwendung des LangChain-Frameworks können Sie die Klasse GoogleGenerativeAIEmbeddings mit einem Gemini-Einbettungsmodell wie gemini-embedding-001 nutzen. Vektoren, die zuvor in einer Vektorspalte in einer PostgreSQL-Tabelle gespeichert wurden, sind bereit für die Abfrage mit einer similarity_search_with_score-Methode von vector store:

# Search for similar problems with similarity scores
results = self.vector_store.similarity_search_with_score(
    problem_description,
    k=1  # Only return the most similar result
)

if not results:
    logger.info("No similar problems found in database")
    return None
# Get the best match
document, similarity_score = results[0]

# Convert distance to similarity (cosine distance: 0 = identical, 2 = opposite)
similarity_score = 1 - (similarity_score / 2)

# Check if similarity meets threshold
if similarity_score < self.similarity_threshold:
    logger.info(f"Best match similarity {similarity_score:.3f} below threshold {self.similarity_threshold}")
    return None

return {
    'problem_description': document.metadata.get('problem_description', document.page_content),
    'resolution': document.metadata.get('resolution', ''),
    'category': document.metadata.get('category', ''),
    'similarity_score': similarity_score
}

Zusammenfassung

Das Verstehen und Vermeiden von Kontextblindheit kann viel Zeit sparen, wenn Sie planen, ein Kundendienstsystem zu produzieren. Wir haben die Architektur eines kontextbewussten Echtzeit-KI-Agenten erforscht, die auf drei Säulen beruht:

Zusammen bilden diese Komponenten ein System, das die Informationen ständig aktualisiert und in den richtigen Kontext setzt und so das Risiko von KI-Halluzinationen drastisch reduziert. Wir haben ein paar Beispieltechnologien beschrieben, die diese Aufgabe erfüllen. Aber es gibt eine Vielzahl von Technologien auf dem Markt, aus denen Sie wählen können - wählen Sie mit Bedacht und verpassen Sie nicht das Wichtigste, was Sie aus dieser Erkundung mitnehmen können:

Der Aufbau eines effektiven KI-Kundendienstes erfordert ein Echtzeit-Backbone.Möchten Sie sehen, wie KI-Agenten in Echtzeit arbeiten? Melden Sie sich für eine kostenlose Demo an!