Ohne Wissensbasis kein brauchbarer Agent

Wenn wir mit einem Team über einen Support- oder Service-Agenten sprechen, geht das erste Gespräch fast immer um das Modell: welches Sprachmodell, wie gut formuliert es, wie schnell antwortet es. Das zweite Gespräch, das eigentlich das wichtigere ist, dreht sich um eine langweiligere Frage: Woher weiß der Agent, was er antworten soll? Bei Essential Bag war genau das der Punkt, an dem das Projekt tatsächlich Zeit gekostet hat, nicht beim Bau des Agenten selbst.

Der Agent ist selten das Problem, die Wissensbasis schon

Ein modernes Sprachmodell formuliert eine Antwort, sobald es die richtigen Fakten hat, zuverlässig gut. Das eigentliche Risiko liegt nicht in der Formulierung, sondern in den Fakten: Wenn die Rückgabefrist im System veraltet ist oder eine Ausnahmeregel nirgends steht, formuliert der Agent eine flüssige, überzeugende und falsche Antwort. Das ist kein Modellfehler, das ist ein Datenproblem, das jedes Modell gleichermaßen betrifft.

Das macht die Fehlersuche auch schwerer, als sie bei einem klassischen Softwarefehler wäre. Ein Programmierfehler wirft meistens eine Fehlermeldung, eine falsche Antwort aus lückenhaftem Wissen klingt dagegen genauso selbstsicher wie eine richtige. Wer nicht gezielt nach der Quelle einer Antwort fragt, merkt den Unterschied oft erst, wenn sich ein Kunde beschwert, und das ist spät.

Was eine Wissensbasis für einen Agenten wirklich braucht

Eine gute Wissensbasis für einen Agenten ist selten eine besonders raffinierte Datenbank. Sie ist vor allem eine mit klaren Eigenschaften: ein Eintrag pro Thema statt verstreuter Informationen über mehrere Dokumente, ein Datum, wann er zuletzt geprüft wurde, und eine eindeutige Person, die für die Aktualität verantwortlich ist. Ohne diese drei Punkte entsteht über Monate dasselbe Problem, das vorher schon existierte, nur jetzt digital statt in Köpfen.

Genauso wichtig wie der Inhalt ist die Größe der einzelnen Einträge. Ein Dokument mit fünfzig Seiten Produktinformationen ist für einen Menschen durchsuchbar, für einen Agenten, der nur den relevanten Ausschnitt braucht, eher hinderlich als hilfreich, weil sich Widersprüche und veraltete Absätze darin leichter verstecken. Kurze, in sich abgeschlossene Einträge pro Thema lassen sich einzeln prüfen, einzeln aktualisieren und einzeln testen, ein langes Dokument nicht.

• Ein Thema, ein Eintrag: Rückgabebedingungen stehen an genau einer Stelle, nicht in drei Dokumenten mit unterschiedlichem Stand
• Ein sichtbares Aktualisierungsdatum pro Eintrag, damit alte Ausnahmen nicht als aktuelle Regel behandelt werden
• Eine benannte verantwortliche Person pro Themenbereich, die Änderungen einpflegt
• Eine Testfrage pro Eintrag, mit der sich prüfen lässt, ob der Agent die richtige Antwort daraus ableitet

Der teuerste Schritt: Wissen aus Köpfen holen

Bei Essential Bag lag ein Großteil des Produkt- und Prozesswissens nicht in einem Dokument, sondern bei den zwei Mitarbeitenden, die den Support seit dem Start gemacht hatten. Dieses Wissen aufzunehmen bedeutete: Interviews, mitlaufen bei echten Tickets, Rückfragen, wenn eine Antwort nicht zur dokumentierten Regel passte. Das ist die Arbeit, die in einem Projektplan gern unterschätzt wird, weil sie sich nicht wie Technik anfühlt, aber ohne sie hat der schönste Agent nichts, worauf er eine gute Antwort stützen könnte.

Auffällig war dabei, wie oft die beiden Mitarbeitenden bei derselben Frage leicht unterschiedlich antworteten, nicht aus Nachlässigkeit, sondern weil sich eine Ausnahme im Alltag eingeschlichen hatte, die nirgends festgehalten war. Genau diese kleinen Abweichungen mussten zuerst sichtbar gemacht und dann bewusst entschieden werden, bevor sie in die Wissensbasis kamen. Ein Agent kann nur eine Version einer Regel befolgen, die Klärung, welche das ist, kann ihm niemand abnehmen.

Für uns war das der Moment, in dem aus einem technischen Projekt kurzzeitig ein organisatorisches wurde: Bevor der Agent eine einheitliche Antwort geben konnte, musste das Team sich selbst auf eine Regel einigen. Das kostet Gesprächszeit, die in keinem Angebot als eigener Posten auftaucht, aber ohne die kein Agent besser wird als das uneinheitliche Wissen, aus dem er gespeist wird.

Wer die Wissensbasis pflegt, wenn das Projekt vorbei ist

Eine Wissensbasis, die beim Projektabschluss fertig aussieht, veraltet in der Praxis innerhalb weniger Monate, wenn niemand sie danach pflegt. Ein neues Produkt, eine geänderte Versandregel, eine neue Ausnahme im Reklamationsprozess, all das muss jemand nachtragen, sonst beginnt sich langsam wieder die Lücke zu öffnen, die der Agent eigentlich schließen sollte. Genau deshalb gehört die Frage "wer pflegt das in sechs Monaten" für uns zum Projekt dazu, nicht zu den Dingen, die man nach der Übergabe klärt.

In der Praxis hat sich bewährt, die Pflege an denselben Moment zu koppeln, an dem sich ohnehin etwas im Unternehmen ändert, etwa die Produktfreigabe. Wird ein neues Produkt live geschaltet, gehört ein Blick in die Wissensbasis zum Prozess dazu, nicht als separate Zusatzaufgabe, die im Kalender leicht untergeht. Wo die Pflege an einen bestehenden Prozess andockt, bleibt sie eher lebendig, als wenn sie ein eigener, isolierter Termin ist.

1. Eine feste Person oder Rolle, die neue Einträge und Änderungen freigibt
2. Ein fester Anlass, bei dem die Basis geprüft wird, etwa bei jeder neuen Produktkategorie
3. Eine einfache Möglichkeit für den Support, eine Lücke zu melden, wenn eine Antwort im Alltag fehlschlägt

• Wissensbasis
• KI-Agenten
• Knowledge Base
• Kundenservice