Soll ein Service qualitativ hochwertig und effizient sein, dann brauchen die Agenten eine Wissensdatenbank, um alle Anfragen personenunabhängig in der gleichen Weise zu beantworten. So eine Wissensdatenbank ist in der Regel eine Menge Inhalt, der genau für den Zweck als Wissensdatenbank geschrieben sind. FAQ-Datenbanken, wie man es auch gerne nennt.

Da steht für jede Frage eine Antwort, oder wenigstens sind die Fragen in den Inhalten vorgedacht. Wenn es auf Antwortgenauigkeit ankommt, dann ist das auch wichtig. Gerade in Branchen wie Finanzdienstleistern, Gesundheit oder Behörden ist eine genaue Antwort zwingend. Und mit einem passenden RAG Verfahren und einer passenden AI kann man die richtige Antwort einfach finden und verwenden.

In technischen Bereichen hingegen kommt es darauf an, Lösungen für eine Symptomatik zu finden. Da funktioniert der Rechner nicht richtig, da mag der Drucker nicht, da klappt es mit der Steuerung eines Systems nicht so gut, und jetzt soll der Service eine Lösung finden.

Es ist schwierig, hier alle „FAQs“ in einer Wissensdatenbank zu hinterlegen. Zumal es nicht nur FAQs sind, sondern Symptome, Diagnose und Lösungen. Und davon gibt es unglaublich viele mögliche Varianten und Alternativen.

Abhängig vom Leser muss eventuell auch Grundlagenwissen hinterlegt werden, damit Diagnose- und Lösungsanweisungen überhaupt verstanden werden. Und ändert sich die Grundlagentechnologie beispielsweise bei einem Betriebssystemupdate oder einem neuen Steuergerät, dann muss man das Hintergrundwissen in alle Dokumente überarbeiten.

Den meisten Organisationen fehlen die Ressourcen, um den hier notwendigen Redaktionsaufwand zu erbringen.

Hier bietet sich die Nutzung der Reasoning-Fähigkeiten der Large Language Models an.

Das Prinzip:

• Man hinterlegt als Wissensdatenbank bestehende Inhalte wie Handbücher, Anweisungen und technische Dokumente.
• Man beschreibt die Systemarchitektur mit dem Ziel dem LLM zu verdeutlichen, welches Wissen für die Beantwortung von Fragen eingesetzt werden kann. Ist beispielsweise dem System bekannt, dass eine Funktion im Browser läuft, kann das System allgemeine http-Fehlercodes interpretieren.
• Und man nutzt die Reasoning-Fähigkeit des LLMs, um Antworten auf Fragen zu finden.

Das funktioniert ziemlich gut und man spart unglaublich viel Redaktionsaufwand. Aber wie sieht genau die Bilanz dieses Verfahrens verglichen mit einer FAQ-basierten Wissensdatenbank aus?

Antwortzeit und Genauigkeit

Da Reasoning recht viel Aufwand benötigt sind die Antwortzeiten deutlich länger und die Betriebskosten höher als bei einfachen Q&A Wissensdatenbanken. Und damit auch der CO2 Fußabdruck, was auch erwähnt werden muss.

Zudem: Es kann passieren, dass falsche Antworten auftreten. Da Reasoning je nach LLM, Komplexität und Dokumentation auch mal fehlschlagen kann, sind fehlerhafte Antworten nicht ausgeschlossen.

Oder besser: In einer Q&A-Situation kann man durch entsprechende Maßnahme eine sehr hohe Verlässlichkeit erreichen, die auch hohen Anforderungen genügt. In einer Reasoning-basierten Wissensdatenbank ist dies nicht möglich. Zudem kann man wesentliche Edge Cases testen, um eine Aussage über die zu erwartende Qualität zu erreichen (so sind ja auch unsere Benchmarks konzipiert, siehe https://rely-qa.de/benchmarks/). Aufgrund der Vielfalt ist auch diese Testabdeckung in Reasoning-basierten Systemen nicht möglich.

Geht es jedoch um Lösungen, die man einfach mal „probieren“ kann, dann ist das in der Regel kein großes Risiko. Ist beispielsweise ein Lösungsversuch eines IT Service Centers erfolglos, dann wird eben eine andere Lösung probiert. In Falle einer Finanzberatung ist das keine gute Vorgehensweise. Daher eignen sich Reasoning-basierte Wissensdatenbanken gerade für technische Service Center. Für verbindliche Zusagen im Finanzbereich eignen sie sich beispielsweise eher nicht.

Redaktionskosten

Versucht man eine Lösungsdatenbank für technische Systeme mit einer Q&A-basierten Wissensdatenbank zu realisieren, dann benötigt man unglaublich viele Dokumente. In der Praxis konzentriert man sich meistens auf eine ganz konkrete Persona und auf eine konkrete Bearbeitungsstufe, meist den 1st Level oder Self Service. Und auch da sind einige tausend Dokumente notwendig.

Während Q&A basierte Wissensdatenbanken meistens konkrete Dokumente in der Form „Frage / Symptom / Lösung“ benötigen, kann Reasoning auch auf Handbüchern und technischer Dokumentation aufsetzen. Das heißt, man verwendet einfach bestehende Inhalte um konkrete Fragen zu beantworten. Das erspart das Erstellen zusätzlicher Dokumente.

Auch die kontinuierliche Pflege ist einfacher: Ändern sich technische Plattformen wie Betriebssystem, Kommunikationsprotokolle oder Endgeräte, dann müssen Q&A-basierte Lösungen komplett überarbeitet werden. Im Reasoning-Fall ist das nicht notwendig. Ändert sich beispielsweise die Authentifizierung von einer anwendungsspezifischen zu Single Sign On, dann genügt dem Reasoning diese Zusatzinformation und man kann die bestehenden Dokumente direkt weiter verwenden. Im Q&A Fall müssen die entsprechenden Inhalte neu erstellt werden.

Automatischer Lernprozess

Während in Q&A-basierten Wissensdatenbanken Neues und Geändertes permanent in allen betroffenen Dokumenten nachzutragen ist, können Reasoning-basierte Wissensdatenbanken auch kommentarähnliche Anmerkungen integrieren, die sich aus Interaktionen ergeben.

Ergibt sich beispielsweise aus einem Dialog ein Learning bezüglich des Bedienverhaltens oder von Performanceproblemen, dann kann dieses einfach als kurzer Textabschnitt dokumentiert werden. Es ist nicht notwendig, dieses Wissen in jedem Dokument zu hinterlegen. Das macht das Reasoning schon von allein. Entsprechend ist der Pflegeaufwand deutlich kleiner und die Wissensdatenbank viel effizienter.

Fazit

Reasoning-basierte Wissensdatenbanken sind eine in der Praxis noch kaum gezogene Option. Gerade im technischen Umfeld jedoch bieten sie eine elegante Lösung, über die man nachdenken sollte.

Man kann sich recht einfach einen Prototypen mal selbst erstellen. Hier der Link zu einem Blueprint: Link.