Die Entwicklung eines KI-Proxys für ilert

Die Entwicklung eines KI-Proxys für unsere KI-Funktionen war eine der besten Entscheidungen, die wir vor einem Jahr getroffen haben. In diesem Artikel erklären wir, warum das so ist, und welche Herausforderungen wir dabei gemeistert haben.

Diese Gründe sprachen für die Entwicklung eines KI-Proxys

Viel zu enger Kontext

Die ersten Anfänge datieren zurück in das Jahr 2023, als wir gerade erst mit der Implementierung von KI-Funktionen in ilert begannen. Damals waren die Fähigkeiten von ChatGPT schon beeindruckend, aber noch weit von den Möglichkeiten entfernt, die die KI jetzt, Ende 2024, bietet. Zu dieser Zeit begann die generative KI gerade erst, ihren Wert in Geschäftsanwendungen zu beweisen, die ersten Anwender erforschten mögliche Anwendungsfälle im Kundenservice, bei der Content-Erstellung und bei der Datenanalyse. Die ursprüngliche Version von ChatGPT konnte aussagekräftige Erkenntnisse liefern und einige Arbeitsabläufe rationalisieren, hatte jedoch Grenzen bei der Bearbeitung komplexer, domänen- und kontextspezifischer Abfragen. 

‍

Der Kontext war eng - nur 4.000 Token. Unsere erste KI-gestützte Funktion war die automatische Erstellung von Störungsmeldungen. Dieses Feature hilft unseren Kunden, automatisch Nachrichten für ihre Statusseiten zu erstellen, um Nutzer über IT-Störungen zu informieren. Wir wollten uns nicht nur auf eine intelligent formulierte Meldung beschränken, sondern auch Informationen über die betroffenen Dienste einbeziehen und den Status dieser Dienste automatisch identifizieren und von betriebsbereit auf ausgefallen ändern. Unsere Kunden können Tausende von Diensten in ihren Konten haben, aber nur wenige sind tatsächlich von einer Störung betroffen, welche wir automatisch identifizieren müssen. Wir haben auch Kunden in China und Indien, wo die Wörter, die zur Bezeichnung von Diensten verwendet werden, sehr lang sein können. 4.000 Token waren also nicht genug.

Kann ich bitte JSON zurückbekommen?

JSON-formatierte Daten werden häufig für die Machine-to-Machine-Kommunikation (M2M) verwendet. JSON stellt sicher, dass Daten leicht geparst, validiert und über unsere Anwendungen hinweg übertragen werden können, wodurch die Konsistenz gewahrt und die Wahrscheinlichkeit von Fehlern bei der Datenverarbeitung verringert wird. Wie viele andere stießen wir jedoch bei den frühen Versionen von GPT-3 auf einige Herausforderungen im Zusammenhang mit der JSON-Verarbeitung.

‍

Diese Versionen waren in erster Linie für die Erzeugung von Gesprächstext und nicht für die Ausgabe strukturierter Daten konzipiert. Dies führte dazu, dass ChatGPT zwar JSON-ähnliche Antworten verstehen und generieren konnte, aber Probleme mit der strikten Einhaltung des JSON-Formats hatte. Selbst wenn wir also versuchten, die Abfrage in 4.000 Token unterzubringen, ließen die Antworten der frühen Modelle gelegentlich geschlossene Klammern aus oder fügten unerwarteten Text hinzu, was nachgelagerte Prozesse störte, die streng gültiges JSON benötigten. Einfach ausgedrückt, es funktionierte nicht.

Keine Agenten, keine Funktionen

GPT-Agenten, wie wir sie heute kennen, können komplexe Probleme in umsetzbare Schritte zerlegen, Aufgaben priorisieren und sogar Reaktionen miteinander verketten, um ein Ziel zu erreichen. Ohne diese Fähigkeiten mussten wir uns auf statisches Prompt-Engineering verlassen, bei dem jede Interaktion mit der KI isoliert war und präzise Aufforderungen erforderte, um auch nur mäßig komplexe Ergebnisse zu erzielen. Dies machte es schwierig, Funktionen zu entwickeln, die eine Entscheidungsfindung auf Grundlage des vorherigen Kontexts erforderten oder die sich dynamisch an Benutzereingaben anpassen mussten. Nehmen wir als Beispiel die KI-gestützte Erstellung von Dienstplänen: Wir speisen kontextspezifische Daten ein, um einen realisierbaren und flexiblen Kalender für die weitere Verwendung zu erhalten.

‍

Funktionen ermöglichen es dem Modell, über die einfache Textgenerierung hinauszugehen, indem es bestimmte, vordefinierte Aktionen direkt innerhalb eines Systems ausführt. Sie ermöglichen es der KI, mit externen Systemen oder Datenbanken zu interagieren und Daten basierend auf Benutzereingaben abzurufen oder zu aktualisieren. Funktionen befähigen die KI, direkt mit der API von ilert zu interagieren, wodurch Aufgaben wie das Abrufen von ilert-bezogenen Kontextdaten ermöglicht werden. Diese Funktionalität verwandelt die KI von einem passiven Antwortgeber in einen aktiven, aufgabenorientierten Assistenten, der komplexe Arbeitsabläufe autonom bewältigen kann. Es ist kaum zu glauben, aber vor zwei Jahren gab es noch keine Funktionen. 

‍

Zu guter Letzt wollten wir verschiedene LLM-Anbieter wie AWS Bedrock und Azure GPT4 nutzen. Da wir viele Kunden in der EU haben, konnten wir uns nicht nur auf die amerikanische OpenAI-API beschränken. Das Fehlen einer nativen Unterstützung für unsere betrieblichen Anforderungen gab den Anstoß zum Konzept eines KI-Proxys, einer zwischengeschalteten Ebene zur Verwaltung von Anfragen und Antworten über KI-Modelle hinweg und um sicherzustellen, dass jede Interaktion den Leistungsstandards von ilert entspricht. 

Diese Probleme lösen wir mit dem benutzerdefinierten KI-Proxy 

Protokollieren, überwachen und speichern

Anstatt KI-Anfragen direkt an OpenAI oder andere Modelle zu senden (und jedes Mal Gebühren zu zahlen), stellen wir sie über unseren benutzerdefinierten KI-Proxy. So gehen unsere KI-Anfragen – ob Sie nun eine Störungsmeldung für Ihre Kunden vorbereiten, Zeitpläne einrichten oder ein Post-Mortem-Dokument erstellen möchten – durch eine zentrale Anlaufstelle, bei der wir uns um alles Notwendige im Hintergrund kümmern: Protokollierung, Monitoring und ja, auch die Überwachung der wertvollen Tokens und der Kosten.

‍

Durch das Tracken der Token-Nutzung und anderen Kosten-Metriken können wir mit dem KI-Proxy unangenehme Überraschungen bei der Abrechnung vermeiden, und noch besser, wir erfassen alles, was rein und raus geht. Das bedeutet, dass wir die Daten nutzen können, um unsere Modelle zu optimieren, damit die KI mit jeder Interaktion besser wird. Wir protokollieren auch Performancedaten für verschiedene Modellversionen, um die Effektivität, Reaktionszeiten und Genauigkeit jedes Modells unter realen Bedingungen zu bewerten. Darüber hinaus verfolgen wir Leistungsdaten basierend auf dem Feedback unserer Kunden zu spezifischen Anwendungsfällen und deren zugehörigen Modellen, damit wir wissen, ob ein Anwendungsfall auf verschiedenen LLM-Modellen besser oder schlechter abschneidet.

‍

Ein wesentlicher Vorteil unseres KI-Proxys besteht darin, dass wir damit im Handumdrehen zwischen verschiedenen Large Language Modellen wechseln können. Dies ist zum Beispiel für unsere europäischen Kunden, die der Datenlokalisierung eine große Bedeutung einräumen, entscheidend. Viele unserer Kunden benötigen On-Premises-Modelle oder Cloud-Lösungen, die strenge Anforderungen an die Data Residency erfüllen, wie z. B. AWS Bedrock, das in bestimmten Regionen wie Frankfurt oder Stockholm betrieben wird. Durch die lokale Speicherung von Konversations-Threads und Sitzungsverläufen nur für die Dauer der Konversation in unserem Thread-Speicher können wir Anfragen dynamisch zwischen Anbietern wie Azure's GPT-4 und AWS Bedrock umleiten, ohne den Kontext zu verlieren. Circuit Breaker innerhalb des KI-Proxys überwachen die Antwortzeiten und die Konsistenz und leiten den Datenverkehr automatisch um, um eine nahtlose Benutzererfahrung und Zuverlässigkeit zu gewährleisten, wenn Modelle bestimmter Anbieter eine hohe Nachfrage verzeichnen oder zu langsam werden.