Azure OpenAI und eure Atlassian-Daten

Einen Business Case für AI entwickeln

Bei neuer Technologie ist ein schneller Einstieg wichtig. Deshalb wollten wir einen möglichst einfachen Business Case entwickeln. Nach sorgfältiger Abstimmung und Arbeit kam ich zu dem Schluss, dass wir wissen müssen, wer das schon einmal gemacht hat. Eine einfache Frage, die jedoch oft mehrere Antworten hat.

Theoretisch können wir das mit JQL umsetzen, da alle Daten in Jira Service Management liegen. Dabei wird jedoch nur das Feld für den Bearbeiter berücksichtigt, nicht etwa unsere Zeiterfassungsdaten aus Tempo.

Wenn ihr die AI also fragt: „Wer hat zuvor mit Exalate gearbeitet?“, erhaltet ihr zehn Namen und wisst, wen ihr um Hilfe bitten könnt. Wir gingen davon aus, dass dies monatlich Stunden spart, da ihr oft nur die richtige Person braucht, die euch den Einstieg in einen Fall erleichtert. Unser Marketing hat weitere Business Cases für mich, darunter die „25 am häufigsten auftretenden Probleme“. Wenn wir diese Frage beantworten können, wären sie zufrieden.

Azure OpenAI und die Einrichtung eigener Daten

Eine schnelle Skizze der Architektur, die zeigt, was wir für Azure OpenAI benötigen.

Das Ergebnis mit Azure OpenAI sieht für das Testen eurer Daten und Chats vor dem Livegang so aus. Das bedeutet, dass wir hier nur wenige Komponenten haben.

In diesem Abschnitt konzentrieren wir uns auf Cognitive Services sowie Azure Search mit Blob Storage und AI Studio. Anschließend betrachten wir die Integrationen und sprechen zum Abschluss über den Livegang eurer AI.

Alles beginnt damit, den Zugriff auf OpenAI für eure Organisation zu beantragen. Dafür müsst ihr ein Formular ausfüllen und euch verpflichten, ethische AI-Richtlinien einzuhalten. Dadurch wird Azure OpenAI für euer Abonnement aktiviert. Danach können wir mit der Arbeit am Produkt beginnen. Ich habe zunächst Azure OpenAI Studio geöffnet und im Chat Playground unsere erste Abfrage ausgeführt und getestet. Unten seht ihr das Ergebnis des Chats mit der AI.

Wie ihr links sehen könnt, gibt es ein Feld für unsere Daten. Dabei handelt es sich um die Public-Preview-Funktion, mit der ihr eure eigenen Daten in das System einbringt. Dafür müssen eure Daten in Azure auf eine der akzeptierten Arten vorliegen: derzeit über Azure Search (Blob Storage), Azure CosmosDB oder über eine URL bzw. einen Link zu den Daten. Wir haben zunächst Azure Blob Storage und einen Container für die Daten eingerichtet. Die Daten müssen in einem bestimmten Format vorliegen; ich empfehle .pdf.

Bevor wir die Daten verwenden können, müssen sie indexiert und durchsuchbar sein. Daher müssen wir den Azure-Search-Service bereitstellen.

In OpenAI Studio könnt ihr Suchindizes nicht wiederverwenden, sondern müsst sie jedes Mal neu erstellen. Bei größeren Datenmengen wird das zum Problem. Deshalb empfehle ich, klein anzufangen und in der UI eine geplante Indexierung einzurichten, die beispielsweise täglich ausgeführt wird. In eurer Produktionsanwendung (dazu später mehr) verwendet ihr dann den bestehenden Index. So könnt ihr einen größeren Datenbestand nutzen, ohne acht Stunden warten zu müssen – das habe ich auf die harte Tour gelernt.

OpenAI Search mit eigenen Daten trainiert das Modell nicht. Wie ihr oben sehen könnt, durchsucht es Azure Search, gibt eine bestimmte Anzahl von Dokumenten zurück (im Bild oben 5) und erstellt auf Grundlage dieser Dokumente Antworten. Dazu werden sie in das von euch gewählte Modell eingefügt und die Antwort wird generiert. Hinweis: Das Bild oben zeigt, dass die Einschränkung für den enthaltenen GPT-Datensatz nicht aktiviert wurde.

Das bedeutet, dass ihr größere statt kleiner Dateien bereitstellen solltet. Darauf gehen wir im Abschnitt zu Jira ein. Für spezifische Fragen liefert mir das sehr gute Antworten. Allgemeinere Fragen werden natürlich nicht gut beantwortet, da der Datenbestand, aus dem Informationen abgerufen werden, meist sehr klein ist.

Diese Phase wird häufig als Aufbau von RAG oder Retrieval Augmented Generation bezeichnet. Der Begriff wurde vom Facebook-AI-Team geprägt. Dabei verbinden wir ein LLM-Modell (Large Language Model, beispielsweise ChatGPTs GPT3.5 oder GPT4) mit einer Suchmaschine beziehungsweise Wissensdatenbank.

Die nächsten beiden Phasen werden als Aufbau der KB oder Wissensdatenbank bezeichnet. Hier erstellen wir die Daten und Indizes für die Suchmaschine, damit die zuvor beschriebene Engine funktionieren kann.

Eigene Daten aus Confluence einbringen

Jetzt, da wir unsere AI testen und ausführen können: Wie bringen wir aussagekräftige Daten zur Analyse ein?

Wir möchten Antworten aus unseren eigenen Daten erhalten und die Informationen aufbauen, nach denen Menschen suchen. Confluence war der erste Ort, aus dem ich Daten beziehen wollte. Da die meisten Daten in Confluence recht statisch sind, entschied ich mich für Bereichsexporte als schnelle Lösung. Ich benötigte nur etwa zehn Bereiche, damit meine AI erste Antworten liefern konnte.

Für einen schnellen PoC habe ich sie manuell in den Blob Storage in AI hochgeladen. So konnte ich diesen Service in weniger als einer Stunde nach der Freigabe durch Microsoft für die OpenAI-Nutzung starten. Diese schnelle Demo wurde dann mit den unten aufgeführten Methoden bereitgestellt, um die verschiedenen Ansätze zu testen.

Für die Produktion werden wir eine geeignete Datenpipeline aufbauen und die Daten über Azure-Datentools aus Confluence exportieren. Daran wird derzeit gearbeitet; dazu erscheint später ein separater Blogbeitrag. Confluence erlaubt derzeit keine automatischen Bereichsexporte in der Cloud. Daher könnt ihr dies nicht direkt automatisieren, sondern benötigt eine individuelle Lösung wie ScriptRunner für Confluence.

Das Datenformat des Bereichsexports schien sich sehr gut für die Nutzung mit OpenAI zu eignen. Ich empfehle daher, Seiten nicht einzeln hochzuladen, sondern den größeren Kontext vollständiger Bereichsexporte zu nutzen.

Eigene Daten aus Jira einbringen

Wie beginnt man überhaupt mit dem Testen von Jira-Daten? Was muss ich tun? Wie strukturiere ich sie? Was ist ein schneller PoC? Über diese Fragen dachte ich nach, denn mein Business Case hing von den Jira-Daten ab. Ich hatte das oben erwähnte Aufbereiten der Daten nicht wirklich verstanden: dass Daten in größeren Zusammenhängen vorliegen sollten.

Python ist für mich eine vertraute Sprache, daher habe ich letztlich ein Skript geschrieben, das mit einer JQL-Abfrage und meinem persönlichen Jira-Access-Token alle Issues abruft und in den Blob Storage überträgt. Das Skript unterstützt das Speichern von .txt-Dateien im Blob Storage. Aufgrund von Problemen mit Cognitive Search hatte ich jedoch Schwierigkeiten, .txt-Dateien zum Laufen zu bringen, deshalb habe ich ein weiteres Skript geschrieben, das meine .txt-Dateien in .pdf konvertiert. Nach meiner Prüfung sollte dieses Problem inzwischen behoben sein. Da meine .pdf-Daten funktionieren, habe ich es jedoch nicht mit demselben Datensatz verifiziert.

Letztlich habe ich 60.000 Issues in das System übertragen, was mit den Standardeinstellungen zu einem Timeout des Indexers führte. Indexiert daher zunächst einen kleineren Batch und richtet die Timeouts und Caches des Indexers ein, bevor ihr die große Datenmenge übertragt. So könnt ihr die Daten auch in der richtigen Reihenfolge speichern. Ich empfehle, jedes Skript auf einem Server oder in einer Azure Function auszuführen.

Mein Skript benötigte sechs Stunden für die Ausführung gegen den Jira-Server. Die Anzahl der Abfragen pro Jira-Issue ist beträchtlich: Zuerst müsst ihr die Daten über die JQL-Abfrage abrufen, dann die Issue-Details für benutzerdefinierte Felder und detaillierte Issue-Informationen abfragen, Kommentare anfordern und in meinem Fall die Worklog-Daten über die Tempo API abrufen. Mit drei API-Abfragen pro Ticket und einer Seitengröße von 50 Tickets kam ich pro Ausführung des Skripts auf rund 200.000 API-Anfragen an Jira.

Seit ich mehr mit OpenAI arbeite, würde ich dies möglicherweise auf eine projektbezogene Indexierung umstellen. So wären umfassendere Antworten auf Basis des Projektkontexts statt des Issue-Kontexts möglich. Der Issue-Kontext führt zu sehr spezifischen Antworten, weshalb auch die Fragen an OpenAI ebenso spezifisch sein müssen. Die Suche im Projektumfang habe ich allerdings noch nicht getestet.

Um die Suche auf eure Daten abzustimmen, könnt ihr die Systemnachricht an die Anforderungen eurer AI anpassen. Standardmäßig lautet sie: „Du bist ein AI-Assistent, der Menschen hilft, Informationen zu finden.“ Das funktioniert für diese Anwendungsfälle recht gut, doch mit einem besseren Priming könnt ihr bessere Ergebnisse erzielen. Wenn eure AI nicht korrekt funktioniert oder ihr ihre Antworten optimieren möchtet, kann eine Änderung dieser Nachricht eure Ergebnisse erheblich beeinflussen. Wir haben erlebt, dass aus einem unbrauchbaren Bot ein funktionierender wurde.

Azure OpenAI Studio für meine Zielgruppe bereitstellen

Jetzt haben wir zwei unterschiedliche Chatfenster in Azure OpenAI Studio, und ich möchte sie veröffentlichen. Zunächst dachte ich daran, den automatisch generierten Code aus der UI zu übernehmen und einen Slackbot zu entwickeln. Doch mein Kollege wies darauf hin, dass Danswer vielleicht eine Lösung sein könnte, da es sich automatisch in Slack und Azure OpenAI integriert.

Ich habe Danswer schnell einsatzbereit gemacht, indem ich es über die Quickstart-Anleitung auf meinem Laptop bereitgestellt und so angepasst habe, dass es Azure OpenAI für die Analyse nutzt. Leider unterstützt es Azure Search derzeit nicht als Dokumentenindexer, sodass ich es nicht für meinen Anwendungsfall einsetzen konnte. Da die Lösungen jedoch schon so weit waren, dachte ich: „Vielleicht sollte ich den Quick-Deploy-Button von Microsoft ausprobieren.“ Leider funktioniert das Bot Framework derzeit nur mit Teams. Da wir Teams aktuell nicht für unsere Kommunikation nutzen, entschied ich mich, das Deployment der Webanwendung auszuprobieren – und das war genau das, wonach ich gesucht hatte!

Ihr bekommt ein sehr einfaches Deployment-Formular und habt nach 10 bis 15 Minuten ein funktionierendes Chatfenster. Die Azure-AD-Authentifizierung verhindert dabei die unbefugte Nutzung, und ihr könnt festlegen, wer Zugriff auf die UI hat.

Damit hatte ich eine sehr schnelle Möglichkeit, unsere Endnutzer die Anwendungsfälle testen zu lassen. (Weiter unten erfahrt ihr, wie ihr die Anwendung bereitstellt. Beachtet, dass die Verlaufsdaten CosmosDB erfordern, was etwa 5.000 US-Dollar pro Monat kostet. Für die Entwicklung eines Business Case empfehle ich, zur Kostenersparnis einfach Endnutzer zu interviewen – es sei denn, ihr geht direkt mit mehreren hundert Nutzern in Produktion.)

Hat mein Business Case funktioniert?

Hat es also funktioniert? Ehrlich gesagt: Meiner Meinung nach nein. Aus Sicht der Endnutzer jedoch ja, denn sie sind zufrieden.

Wie geht es weiter? Über Azure Entra verfolge ich unsere Logins und die Nutzung des Services, um zu verstehen, welche unserer Experten ihn nutzen und warum. Einer unserer Experten hat den OpenAI-Code übernommen und arbeitet daran, ihn in Jira zu integrieren, um die Issues, die wir sehen, zu klassifizieren und hoffentlich neue Geschäftslösungen für uns zu entwickeln. Was hat funktioniert? Mit dem Azure OpenAI Service kann man schnell starten, und mit der Webanwendung war ich im Handumdrehen in „Produktion“, um Datensätze mit unseren Experten zu testen.

Woran ich als Nächstes arbeiten möchte: Datenformat und Priming der Daten. Auf Basis unserer kurzen Reviews mit Experten funktioniert es in bestimmten Bereichen gut, liefert jedoch falsche Informationen, wenn Daten falsch geprimt sind oder Azure OpenAI beziehungsweise ein LLM wie ChatGPT Annahmen trifft. Doch tatsächlich ist es keine Datenbank. Es aggregiert oder analysiert keine Daten und erstellt keine fertigen Reports. Das müsst ihr auf JQL-/Datenbankebene erledigen, da es sich dabei um Datenaggregationen handelt. Es kann jedoch erklären, wie wir dieses Issue beim letzten Mal beantwortet haben.

Insgesamt bin ich zuversichtlich, dass wir damit langfristig Mehrwert für unsere Experten und Kunden schaffen können. Es ist jedoch kein Allheilmittel und erfordert Zeit und Fokus, um zu verstehen, was wir tun. Frohes neues Jahr – hoffentlich inspiriert es euch, Azure OpenAI mit euren Daten auszuprobieren.