Andrena entwickelt – Der Podcast

Thema: Produktentwicklung mit generativer KI: Probleme und Lösungen bei der Verwendung von generativer KI in Softwareprodukten

[Musik spielt]

Einzelne Zitatausschnitte als Intro

Intro-Jingle: andrena entwickelt. Der Podcast von andrena Objects. Von EntwicklerInnen für EntwicklerInnen.

Andreas: Hallo und willkommen bei einer weiteren Folge andrena entwickelt. Ich bin Andi und bei mir ist heute mein Co-Host Thomas. Hallo Thomas.

Thomas: Hi.

Andreas: Heute zu Gast bei uns ist die Axinia. Magst du dich kurz vorstellen?

Axinia: Hi. Genau, ich bin Axinia. Ich arbeite seit acht Jahren circa bei andrena als Softwareentwicklerin und habe jetzt seit circa einem Jahr noch eine Sonderrolle bekommen als KI-Beauftragte bei uns im Unternehmen. Sprich, ich beschäftige mich mit dem Thema KI intensiv, mache im Prinzip Abschätzung darüber, was es für das Unternehmen bedeutet, was die Entwicklung für unsere Softwareentwickler auch bedeutet, schult unsere Mitarbeiter und darf unsere KI-Expertise auch nach außen präsentieren.

Andreas: Danke dir für die Vorstellung. Ja, und genau um das Thema wird es auch in der Folge geben. Spezifisch wollen wir uns anschauen, wie die Entwicklung von KI-basierten Anwendungen aussieht, gerade im Vergleich zu der eher traditionellen Softwareentwicklung. Also wo liegen da die Unterschiede und die Herausforderungen? Vielleicht kannst du uns da schon einen kleinen Abriss ausgeben.

Axinia: Genau, vielleicht vorneweg. Wenn wir heute über KI sprechen, dann sprechen wir über generative KI, nur um das abzugrenzen. KI ist ja ein weit gefächerter Begriff. Genau, aber heute beschränken wir uns auf das Thema generative KI. Genau, und was sind im Prinzip so die zentralen Unterschiede? Wir haben im Gegensatz zu klassischer Software ein System, was nicht deterministisch arbeitet und mit den LLMs haben wir einfach auch Modelle, wo wir nicht das Feature-Set im Prinzip kennen, was normalerweise auch anders ist bei normalen Software-Bibliotheken. Das hat natürlich verschiedene Folgen. Man arbeitet anders, man geht anders vor, man muss anders testen und darauf würde ich heute gerne mit euch eingehen.

Thomas: Du hast jetzt schon das Stichwort generative KI verwendet. Was unterscheidet denn so eine generative KI von den anderen Machine Learning Modellen, die man so kennt vielleicht?

Axinia: Genau, also wie der Name auch schon sagt, geht es eben um eine künstliche Intelligenz, die Dinge generiert. Im Prinzip, wir haben ja verschiedene Modi, wir haben Bildgenerierungs-KIs, wir haben Audiogenerierungs-KIs. Mein Spezialthema ist aber im Prinzip die Sprachmodelle.

Thomas: Also so das, was man jetzt mittlerweile ganz typisch unter ChatGPT kennt im Prinzip.

Axinia: Ja, das sind ja sogar multimodale Modelle. Hinter ChatGPT, da gibt es ja den Voice-Mode, da gibt es die Bildgenerierung auch. Das heißt, das ist eigentlich ein multimodales Modell, was sowohl Text als auch Bild als auch Audio generieren kann. Genau, aber vom Feature-Set her ist wahrscheinlich das Wichtigste, dass es eben Text generieren kann. Und ich glaube auch, genau, ein wichtiger Unterschied zu klassischen KI-Modellen oder klassischen Machine Learning Modellen ist eben, dass wir hier mit nicht-deterministischen Modellen arbeiten. Sprich, bei gleichem Output kommt nicht immer das Gleiche raus. Das ist auch so, wenn man so Dinge macht, dass man die Temperatur auf Null setzt und so. Das hat zum Teil, ist es begründet darin, wie die Modelle aufgebaut sind, dass die ebenso eine Mixture of Experts Architektur haben und je nach Auslastung verschieden Experten überhaupt angesprochen werden. Zum anderen hat das aber auch, also liegt es an der, daran, wie die Outputs berechnet werden. Die Grafikkarten haben mittlerweile verschiedene Optimierungen drin, sodass man nicht garantieren kann, dass halt beim gleichen Input immer das gleiche, der gleiche Output rauskommt.

Thomas: Okay, das ist ja nochmal ein ganz anderes Level von Nicht-Determinismus als irgendwelche Timing-Probleme, die man so aus der Softwareentwicklung sonst kennt. Was sind denn Wege, um mit solchem Nicht-Determinismus umzugehen?

Axinia: Das ist, finde ich, noch ein ziemlich ungelöstes Problem auf jeden Fall. Ich meine, es macht bei uns auf jeden Fall die Softwareentwicklung deutlich schwieriger, gerade auch, wenn wir in Richtung Testen und so denken. Man schreibt Tests, die werden halt dann manchmal grün, manchmal nicht grün. Damit muss man eben im Prinzip umgehen können und eben definieren, okay, was, plötzlich arbeite ich halt mit Schwellwerten. Wenn 95 Prozent meiner Tests grün werden, dann ist es okay. Und ansonsten versucht man eben viel auch mit Output-Filtern zu arbeiten. Muss immer schauen. Also im Prinzip muss man immer validieren, was kommt beim LLM raus. Also je nachdem, in welchem Umfeld ich mich befinde. Aber eigentlich muss ich immer schauen, was ist jetzt wirklich der Output? Weicht er ab von meinem erwarteten Output? Und blocke ich das dann gegebenenfalls ab?

Thomas: Wenn ich jetzt aber durch diesen Nicht-Determinismus solche Probleme habe, warum will ich dann überhaupt so LLMs in der Softwareentwicklung einsetzen? Also was sind denn die Vorteile oder warum eignet sich das überhaupt in Softwareprodukte einzubauen?

Axinia: Mit LLMs kriegen wir halt neue Features, die es bisher so nicht gab. LLMs sind im Prinzip, wir sind Alleskönner, also alles können sie natürlich nicht, aber es sind halt generelle, also so generalisierte Modelle, die nicht speziell für irgendwas trainiert wurden, sondern ganz allgemein trainiert wurden und jetzt eigentlich für verschiedenste Aufgaben eingesetzt werden können. Zusätzlich haben sie eine gewisse Autonomie, also sie bringen eine gewisse Autonomie mit. Sie können selbst Entscheidungen treffen, sie können im Prinzip bei Prozessen eingesetzt werden, wo nicht vorher definiert werden muss, wie die KI zu einer Lösung kommen kann oder kommen soll. Und das ist im Prinzip das große Feature von den LLMs, dass sie eigenständig Probleme lösen können, für die sie nicht explizit programmiert wurden. Plus natürlich können LLMs natürliche Sprache verstehen. Das sind im Prinzip die ersten Modelle, die wirklich ein gewisses Sprachverständnis haben und eben auch natürliche Sprache generieren können. Das heißt, damit mache ich auch nochmal ein viel größeres Feature-Set auf. Immer wenn ich eben mit Menschen interagiere, mit menschlicher Sprache, mit natürlicher Sprache, wo wir normalerweise eben, wo immer eine Übersetzungsschicht im Prinzip nötig war, also eine menschliche Übersetzungsschicht, sage ich mal. Genau, da können wir jetzt plötzlich LLMs einsetzen und daraus, also das dann in die Software einbinden.

Thomas: Gibt es denn Unterschiede bei den LLMs? Also gibt es bestimmte Modelle, die sich für das eine Problem mehr eignen und andere Modelle, die für das andere Problem besser sind? Worauf sollte ich da achten?

Axinia: Ja, es gibt viele verschiedene Modelle. Also die sprießen ja auch gerade seit Jahren jetzt schon aus dem Boden. Ich würde, glaube ich, auf zwei Parameter vor allem eingehen. Zum einen haben wir kleinere Modelle und größere Modelle. Die unterscheiden sich natürlich stark in ihrem Feature-Set. Die kleinen können nicht so viel wie die Großen. Dafür sind sie schneller, dafür sind sie günstiger. Und das andere sind jetzt eben die Reasoning-Modelle, die seit einem Jahr, Dreivierteljahr etwa, aufkamen, die eben nochmal deutlich komplexere Aufgaben lösen können, weil sie eben dieses Reasoning mit drin haben, dieses künstliche Nachdenken, wenn man so möchte. Damit kann ich dann eben deutlich schwierige Aufgaben lösen.

Thomas: Jetzt hast du ja schon gesagt, dass es viele Modelle gibt und auch ständig wieder neue Modelle und kurze Entwicklungszyklen. Wenn ich dann so ein Modell in mein Produkt eingebaut habe und dann habe ich ja im Prinzip eine Abhängigkeit zu diesem Modell. Wenn ich dann, da kommt eine neue Version raus, dann kann ich typischerweise nicht reinschauen in die Modelle. Weiß nicht genau, was hat sich geändert? Wie gehe ich damit um?

Axinia: Ja, das ist auf jeden Fall noch ein Riesenproblem, weil man aktuell, also wie gehe ich mit so einem Modell um? Ich prompte ganz viel. Ja, da ist ganz viel natürliche Sprache dabei. Ich sage dem Modell in natürlicher Sprache, was es tun soll. Und da ist auch ganz spannend, es gibt ja Firmen wie Anthropic und so, die veröffentlichen ihre System-Prompts zum Beispiel. Und da ist schon krass der Unterschied zwischen den verschiedenen Modellarten, wie sich die Prompts unterscheiden. Das heißt, da sieht man ganz klar, dass jedes Modell im Prinzip seinen eigenen speziellen Prompt braucht. Und dass nur weil ein Prompt für das eine Modell funktioniert, funktioniert er noch nicht, also noch lange nicht für das andere Modell. Und das heißt, im Prinzip muss dann bei jedem Modell-Update müssen die Prompts nochmal validiert werden, muss nochmal validiert werden. Wie gut funktionieren die Prompts? Wie gut kann auch das neue Modell mein bisheriges Problem lösen? Wie gut ist das für meinen bisherigen Use Case? Da gehe ich natürlich nicht mit jedem kleinen Update mit, weil das einfach pro Update viel Aufwand bedeutet. Es ist aber auch schon immer wieder vorgekommen, also eigentlich hauen die Anbieter ihre Timestamps da dran und eigentlich ist die Ansage, dass sich die Modelle dann nicht mehr verändern. Das ist aber definitiv nicht immer gegeben, auch wenn sie es eigentlich versprechen. Das heißt, man ist trotzdem damit konfrontiert, dass sich die Modelle im Zweifelsfall ändern können und auch ohne Ankündigung, weil vielleicht nochmal irgendwelche Regeln verschärft werden mussten, irgendwie nachgeschärft werden musste. Und das kann das Verhalten von meiner Anwendung plötzlich stark beeinflussen.

Thomas: Das spricht ja dann eigentlich dafür, dass Testen in der Kombination mit KI-Integration in meiner Anwendung nochmal deutlich wichtiger wird, wenn ich da ausschließen muss, dass sich einfach ohne mein Wissen irgendwie was ändert in der Anwendung und ich Interaktionen mit Menschen habe die ganze Zeit eigentlich.

Axinia: Definitiv. Das finde ich auch wirklich so den großen Unterschied zu Standard-Libraries, die ich irgendwie einbinde in meine Software. Ich binde jetzt irgendwie ein LLM ein und muss das aber mittesten. Bei Standard-Libraries weiß ich, kenne ich das Feature-Set und ich vertraue darauf, wenn die sagen, diese Features gibt es, dann funktionieren die. Bei LLMs weiß ich nicht, was ich einbinde. Ich habe keinen Überblick über das Feature-Set. Klar gibt es Benchmarks, die versuchen, die Modelle irgendwie einzuordnen und so ein bisschen rauszukitzeln, was können die vielleicht ein bisschen besser, was können sie schlechter als andere. Aber ich kann halt für explizit die Use-Cases kann ich nicht sagen, ja, das kann das LLM oder das kann das nicht. Das heißt, mein Testing ist eh schon total aufgebläht an der Stelle, weil ich eine externe Library mittesten muss und die auch noch sehr exzessiv mittesten muss, weil ich eben mit natürlicher Sprache arbeite. Das heißt, meine Use-Cases sind auch eigentlich unendlich groß. Also mein Input-Raum ist im Prinzip unendlich groß. Dann den Output zu validieren, ist auch nicht ganz einfach. Je nachdem, wie man es einsetzt, kann man halt nicht immer sagen, ah ja, das ist jetzt ein richtiger Output oder das ist ein falscher Output, sondern es ist dann oft eine Qualitätsmessung auch, ist die Antwort, die ich bekomme, qualitativ gut oder schlecht und ist sie besser oder schlechter als das, was ich mir vielleicht wünsche. Genau, das heißt, da haben wir an ganz vielen Stellschrauben wirklich viel mehr Testing als bei klassischer Software und auch deutlich schlechter zu handeln. Da kommt natürlich auch noch der Nicht-Determinismus rein. Das heißt, ich kann nicht einfach einen Run mit dem letzten vergleichen und sagen, ah ja, es wurde jetzt ein bisschen besser oder ein bisschen schlechter. Das hat noch nicht unbedingt was zu bedeuten, weil es kann auch einfach an der Schwankung vom LLM liegen. Genau, das heißt, da brauche ich eigentlich viele Runs. Ich muss schon einigermaßen viele Ergebnisse gesehen haben, um einschätzen zu können, was für Veränderungen sind überhaupt relevant und wo sehe ich hier wirklich eine Veränderung in meiner Anwendung und nicht nur leichte Schwankungen.

Thomas: Ich finde das ein sehr interessantes Thema, weil ich kann mir noch nicht so richtig vorstellen, wie die Integration funktioniert, was das Testing angeht. Ich bin aus meiner Softwareentwicklung irgendwie gewohnt, ich habe da so eine CICD-Pipeline, ich ändere was an meinem Code, ich pushe es auf den Feature-Branch, Tests werden angetriggert und gebe mir irgendwie ein Ergebnis. Ist das gut? Ist das schlecht? Kann ich meinen Code mergen? Und jetzt habe ich diese externe Abhängigkeit drin, ich habe den Nicht-Determinismus drin, die Tests laufen wahrscheinlich lange, wie geht man damit organisatorisch um?

Axinia: Das ist eine gute Frage. Ja, also wir haben, also in meinem letzten Projekt, da haben wir ein Chatbot aufgebaut, da haben wir nochmal eine ganz neue Testing-Schicht quasi aufgebaut, die Evaluierung. Also das ist auch ein Standardbegriff, den man auf jeden Fall kennen muss, weil bei Evaluierung, das ist wirklich Testen auf Qualitätsniveau. Also wir testen Qualität und wir testen keine Korrektheit an der Stelle. Das heißt, man baut hier nochmal eine neue Schicht auf, die sehr umfangreich ist und mit der man eben anders umgehen muss. Also wo es dann kein klares, das fällt oder das geht durchgibt, sondern wo ich eigentlich wissen muss, okay, ich schraube jetzt gerade an Dingen rum, die das Verhalten von dem Modul, wo die KI drinsteckt, verändert. Wenn ich das weiß, dann muss ich eben auf die Evaluierung mit drauf schauen. Also wir haben die einfach immer nächtlich laufen lassen, weil die braucht extrem lang auch, das hast du ja auch schon gesagt. Die läuft nicht in meiner Standard-Branch-Pipeline mit, sondern die muss extern laufen, weil sie halt ihre ein, zwei Stunden braucht und auch recht teuer ist. Das kommt da auf jeden Fall auch noch dazu. Und das heißt, ich habe hier eigentlich auch nochmal einen neuen Prozess, wo ich dann jeden Morgen auch mal auf die Pipeline gucken muss, schauen muss, ob sich Werte stark verändert haben.

Thomas: Was gibt es denn da so für Methoden, um die Qualität von so einem Output zu bewerten? Also ich kann mir das nicht so einfach vorstellen, dass ich ganz einfach sagen kann, jetzt eine Ausgabe von einem generativen Modell ist jetzt irgendwie besser als die davor. Also was gibt es dafür Möglichkeiten, das in so Testing-Umgebungen automatisiert zu machen, ohne dass jetzt jemand drüber schauen muss und das menschlich bewertet?

Axinia: Man arbeitet damit Metriken, die können ganz verschieden aussehen. Also es gibt recht einfache Metriken, wie sowas, wie viele Sätze sind zum Beispiel im Output oder wie viele Wörter, die also zum Beispiel, genau, einfach die Länge vom Output berechnen. Und das kann ich zum Beispiel in die Metrik packen, wenn ich weiß, ich will eigentlich kurz und knapp antworten, dann kann ich da sehen, ob das sich irgendwie verändert. Dann gibt es aber auch Metriken aus dem klassischen Machine Learning, wo ich mit Ähnlichkeiten arbeite, also wo ich erstmal zu meinem Testset definiere, wie sehen denn meine optimalen Outputs aus? Und dann kann ich vergleichen, also dann habe ich eine semantische Ähnlichkeit zwischen dem eigentlichen Output und dem optimalen Output. Und dann gibt es noch die Möglichkeit, den Output wiederum von einem LLM evaluieren zu lassen. Da bin ich natürlich sehr flexibel. Dem LLM kann ich da an der Stelle alles sagen. Ich kann sagen, passt die Tonalität von dem Output? Ist das ein korrekter Output, so von deinem Wissensstand her? Werden da vielleicht folgende Regeln eingehalten oder nicht eingehalten? Also da bin ich sehr frei. Aber es ist halt im Prinzip wieder mehr Unsicherheit, was ich reinbringe mit so einer LLM-Metrik, weil die natürlich auch wieder schwankt. Das heißt, ich habe hier so eine Doppelschwankung drin.

Andreas (fortfahrend): Ich will ja dann auch vermutlich möglichst viel abdecken in meinen Testfällen. Das heißt, ich brauche eine große Menge an Daten. Gibt es da irgendwie Möglichkeiten, die Daten künstlich zu erzeugen oder muss ich da vorher eine große Datensammlung anfangen? Also wie mache ich das, wenn ich sowas noch nicht habe, so eine Datensammlung am Anfang?

Axinia: Ja, also es ist im Prinzip recht einfach, mit LLMs auch Testdaten zu generieren. Aber das Problem ist an der Stelle wirklich die Qualität der Testdaten. Da hat sich schon in der Praxis gezeigt, am Ende müssen Menschen nochmal über die Testdaten drüber schauen, die validieren, damit das Testdatenset sinnvoll ist, beziehungsweise also insofern sinnvoll ist, als dass sie meinen Use Case wirklich abdeckt. Was wir jetzt auch viel gemacht haben, ist mit Personas zu arbeiten. Das macht man ja oft auch bei Produkten. Man definiert sich Personas, also als Nutzer. Ich habe verschiedene Nutzergruppen. Da kann ich schön definieren, kann sie dann im LLM mitgeben, kann dann sagen, okay, formuliere folgende Use Cases mal so, um dass sie quasi von dieser Person gesprochen wurden oder geschrieben wurden. Damit kriege ich nochmal deutlich mehr Variationen mit rein. Genau, aber am Ende ist halt wirklich superwichtig, dass da fachlich nochmal jemand drüber schaut, dass da fachlich auch Input kommt und nicht einfach alles vom LLM generiert wird, sodass wir da eine wirkliche Qualitätssicherung haben. Ansonsten ist die Aussagekraft von der Evaluierung fragwürdig.

Thomas: Was ich mich da noch frage, ist, man kann ja eigentlich nur das testen, von dem man weiß. Das ist ja auch in der klassischen Softwareentwicklung schon ein Problem. Man kann eine Anwendung haben, die super Testabdeckung hat. Man deployt sie, man lässt echte Nutzer darauf los und sie finden halt trotzdem Wachs. Und da gibt es ja oft dann Wege damit umzugehen, explorative Tests. Man versucht irgendwie, Leute explizit die Anwendung hacken zu lassen. Wie sieht es bei KI-basierten Anwendungen aus?

Axinia: Ja, man versucht ja eigentlich schon bei klassischen Anwendungen immer früh rauszugehen, früh an den Nutzer ranzutreten. Das ist bei KI-Anwendungen, finde ich, nochmal deutlich wichtiger, weil man eben sehr schwer einschätzen kann, wie wird die Anwendung wirklich genutzt. Also gerade, wenn ich sowas wie ein Chatbot habe, wo ich einfach in natürlicher Sprache alles Fragen könnte, da schafft man es ja im Vorfeld niemals, sich zu überlegen. Also auch fachliche Experten werden sich nie ganz überlegen können, was die Nutzer jetzt alles Fragen. Das heißt, da lohnt es sich auf jeden Fall, früh rauszugehen, früh Daten zu sammeln. Also vielleicht auch erstmal in einem Testing-Lab mit Versuchspersonen, vielleicht in einer Close-Beta, wo ich erstmal mit Friendly-Usern arbeite. Aber trotzdem bekomme ich da schon mal erste wichtige Testdaten. Genau. Und die Daten kann ich natürlich dann auch wieder in meinen Testdatensatz einfließen lassen und sollte ich auf jeden Fall auch.

Thomas: Das heißt, dass ich am besten meine Testdaten auch iterativ immer wieder aktualisiere und erweitere?

Axinia: Genau. Das ist ganz wichtig.

Thomas: Jetzt ist wahrscheinlich nicht nur das Testing ein wichtiges Thema, wenn ich solche KI-Modelle benutze mit Nicht-Determinismus, sondern ich habe typischerweise ja auch vielleicht dann personenbezogene Daten, wenn ich mit Menschen interagiere. Also das Thema Security ist da doch bestimmt dann auch sehr relevant.

Axinia: Auf jeden Fall. Und auch sehr schwierig. Ich finde, am besten zeigt es, dass die großen Player, also die Hersteller von den LLMs, selbst die haben ihre LLMs überhaupt nicht im Griff. Na, die machen ja auch, sind ständig dabei, die LLMs sicherer zu machen. Es gibt ja ganz klare Regeln, an die sich eigentlich die LLMs halten sollen, aber die werden ständig gebrochen. Das heißt, Security-mäßig ist es einfach eine offene Flanke, die niemand hinbekommt, also die niemand aktuell schließen kann. Und das ist auch was, das Risiko muss mir bewusst sein, wenn ich das, wenn ich ein LLM in meine Anwendung mit einbaue, dass ich eben mir dieses Risiko auch mit reinhole. Da kann ich natürlich versuchen, dagegen zu arbeiten. Zum einen technisch, dass ich eben mit Input-Filtern arbeite. Okay, ich schaue, ich muss mir anschauen, was kommt überhaupt rein. Darf das vielleicht nicht einfach so weitergeben ans LLM, wie du sagst, auch mit personenbezogenen Daten. Da muss man Filter davor bauen, aber entsprechend auch mit dem Output. Der Output, da kann halt auch, da können auch Dinge dabei sein, die entweder so nicht rausgegeben werden dürfen an den Kunden oder die im schlimmsten Fall auch, wenn der Output maschinell weiterverarbeitet werden wird, kann es natürlich, kann man da auch schön in Sicherheitslücken reinrutschen. Und deshalb, ich glaube, man fährt dann immer zweigleisig. Man versucht eben diese technischen Hürden zu bauen, die technischen Filter zu bauen, um das ein bisschen mehr in den Griff zu bekommen. Also man bekommt es nicht ganz in den Griff, aber zumindest lässt man es nicht unversucht. Und zum anderen ist eben aber auch die Kommunikation an den Nutzer ganz wichtig. Es ist ein LLM, es ist eine KI, wir haben hier keine hundertprozentige Garantie, dass da das Richtige rauskommt, dass sich die KI so verhält, wie wir das wollen. Also da ist eben ganz wichtig, dass man das auch gut kommuniziert an den Nutzer. Und ich glaube, da sind wir aktuell auch noch nicht so richtig mit dem Mindset. Also das merkt man ja auch immer wieder, wie Diskussionen laufen über LLMs, über KI. Man hat halt diese, man ist es gewohnt, dass Software eigentlich funktioniert. Also zumindest, wenn sie was tut, dann weiß man, was sie tut. Und dann hat man eine Garantie, dass sie auch das Richtige tut. Und die hat man hier halt gar nicht gegeben. Und das den Nutzern auch klarzumachen, ist schwierig, aber muss gemacht werden.

Thomas: Wir haben jetzt dann viel über Nachteile und Schwierigkeiten und Komplexitäten geredet. Hast du vielleicht auch ein paar Erfolgsstories zu erzählen, wie das in Projekten gut funktioniert hat? Also, dass es sich tatsächlich gelohnt hat, so eine KI dann einzubauen?

Axinia: Also, was ich viel beobachtet habe, oder jetzt auch auf Konferenzen und so, wenn man da Berichte hört, was ganz gut funktioniert, ist, wenn man sich erstmal interne Tools mit KIs baut. Dass man hier wirklich friendly User hat, die eben nicht versuchen, das System auszutricksen und die dann auch entsprechend geschult werden können, mit dem Output richtig umzugehen. Ich glaube, so das klassische Beispiel ist ein internes RAG, also ein Chatbot, der auf internen Daten zugreifen kann und mit dem man dann eben über internes Wissen chatten kann. Genau, dieser Schritt, dann nach außen zu gehen, das erfordert einfach nochmal mehr Expertise, mehr Filter, mehr Sicherheit. Das ist ein deutlich schwierigerer Schritt. Aber gerade wir in der Entwicklung sehen ja auch schon wirklich Tools, die gut funktionieren. Die Coding-Assistenten poppen gerade auch viel auf, gibt es auch ständig was Neues und die werden ja, also wenn man vergleicht, was wir heute haben und was wir noch vor einem Jahr hatten mit einer leichten Line-Completion, Code-Completion und mittlerweile haben wir wirklich Coding-Agenten, denen man nur noch Sachen hinwirft und die fähig sind, größere Features auch zu entwickeln. Dann sehen wir schon auch, also eine sinnvolle Entwicklung ist eine, also da ist auch eine Erfolgsstory dahinter.

Andreas: Ja, zu diesem Thema werden wir auch bald eine Podcast-Folge aufnehmen, also stay tuned. Da gehen wir nochmal tiefer auf Entwicklungsprozesse mit AI ein.

Thomas: Wie erlebst du das so im Umgang mit Kunden? Sind alle ganz heiß darauf, jetzt irgendwie KI einzubauen und wenn ja, sind die sich dann den Konsequenzen bewusst oder muss man die dann erstmal noch Schulen in die Richtung mit, das ist gar nicht so einfach und ihr habt hier vielleicht einige Sachen noch gar nicht bedacht? Oder sind die eher skeptisch und sagen, das ist schon alles ein bisschen zu unsicher und zu schwierig?

Axinia: Also wir erleben eigentlich, dass der Hype auf jeden Fall bei unseren Kunden angekommen ist. Viele wollen erstmal, also wollen darüber sprechen. Viele haben aber noch keine guten Ideen, was sie wirklich umsetzen wollen mit KI, wo wirklich sinnvolle Use Cases sind. Dafür werden wir auch immer wieder in die Unternehmen geholt, um mit denen deren Prozesse anzuschauen, deren Produkte anzuschauen und zu gucken, wo sind wirklich Use Cases, die sinnvoll von der KI umgesetzt werden können und die auch in einem überschaubaren Aufwand umgesetzt werden können. Dann den Schritt zu wagen, das auch wirklich zu tun, das ist sehr unterschiedlich. Also da distanzieren sich ein paar Unternehmen wirklich noch ziemlich davon, weil es ihnen noch zu unsicher ist, weil noch nicht klar genug ist, wie viele Vorteile dann die KI auch bringt oder ob das eher mehr Probleme bringt. Die warten erst noch darauf, wie das bei anderen läuft. Ein paar sind deutlich mutiger, die dann zum Teil aber auch mit so einem Innovationsteam KI-Themen vorantreiben und da ein bisschen mehr probieren.

Thomas: In welchen Bereichen warst du da jetzt konkret involviert? Also du hattest vorhin ja schon den Chatbot angeteasert. Gab es noch andere Projekte?

Axinia: Genau, ich war noch bei einem Projekt dabei, wo es konkret darum ging, um aus einem technischen Bericht eine PowerPoint-Präsentation am Ende zu machen, also eine Abschlusspräsentation, wo dann der eigentliche Mehrwert wirklich darin bestand. Okay, wir haben das Dokument eingelesen und wir haben geschaut, dass aus dem LLM-Output eine PowerPoint-Präsentation erstellt werden kann. Und aber was wirklich inhaltlich in diese Präsentation kommt, das lag halt rein bei der KI. Und das ist ein ganz schöner Use Case, wo man nochmal sieht, okay, die Fähigkeiten von so einem LLM. Ich kann einfach das Wissen nutzen. Also das LLM hat im Prinzip Domänenwissen, technisches Wissen, was wir direkt nutzbar machen können, ohne dass wir sagen müssen, also irgendwie definieren müssen, wie wir finden, also ja, also spezifizieren müssen, wie diese technischen Berichte aussehen, was da inhaltlich drinsteht und wie das aufzubereiten ist. Sondern das überlassen wir alles der KI an der Stelle. Und da kommen ziemlich gute Ergebnisse raus.

Andreas: Ja, also gerade um schnell auf den Markt zu kommen, ist das, glaube ich, extrem gut. Wenn ich mir vorstellen müsste, für solche technischen Spezifikationen ein Domainmodell zu entwerfen, dann wäre ich bestimmt schon lange beschäftigt.

Axinia: Genau. Und ein anderes Beispiel war das Ausfüllen von Formularen. Also wo es darum ging, man bekommt Mails von seinen Kunden und im Prinzip sind da Mitarbeiter, die nichts anderes machen, als die Mails zu lesen. Oft dann mit PDF oder einfach nur Bild anhängen, wo irgendwelche Dokumente fotografiert wurden und aus denen Daten die wichtigen zu extrahieren und in ein Formular einzugeben. Und dafür wurde dann auch die KI genutzt. Zum einen, um den Text auszulesen, dann um die Dokumente auch auszulesen. Mittlerweile sind ja auch die, also die Bildeinlesungen ja wirklich auch so gut, dass da Text, also Text nämlich fehlerfrei extrahiert werden kann, je nach Qualität. Und dann spare ich mir da halt wirklich diese manuelle, den manuellen Aufwand, das zu lesen und einzutragen in die Formulare.

Andreas: Wir haben jetzt gesehen, dass wir viele Use Cases mit der KI relativ kostengünstig umsetzen können, aber das bezog sich ja eher auf den Entwicklungsaufwand. Du hattest ja schon mal am Anfang angesprochen, dass die Tests für die KI nachts laufen und halt sehr teuer sind. Wie sieht es denn bei dem Betrieb von so einem System aus? Aus Produktion wird ja bestimmt deutlich mehr Traffic auch drauf sein.

Axinia: Genau, das ist halt deutlich teurer als klassische Software, muss man ganz klar sagen. Zumindest, wenn man mit größeren Modellen auch arbeitet und wenn man mit externen Dienstleistern arbeitet, weil ich halt dann wirklich pro Anfrage bezahle und deutlich mehr Compute-Time bezahle. Zum Beispiel bei dem Chatbot, wo ich mitgearbeitet habe, da waren wir dann schon bei ein, zwei Cents pro Aufruf, was schon ziemlich viel ist. Also da war halt nicht nur ein LLM-Aufruf dahinter, sondern durch Input- und Output-Filter hat es sich ziemlich aufaddiert. Es gab mehrere Requests und dann ist das schon was, wenn das skalieren soll, das geht dann absolut ins Geld. Also das muss man sich auch vorher auf jeden Fall überlegen. Genau, und wie du auch angesprochen hattest, die Evaluierung, das Testing ist auch deutlich teurer. Auch da muss man, das muss man mit berechnen, wenn man so eine LLM-Anwendung plant.

Andreas: Ich glaube, wir haben jetzt einen guten Abriss darüber, wie KI-basierte Softwareentwicklung so aussieht und wie sie sich von eher der traditionellen Softwareentwicklung unterscheidet. An der Stelle würde ich dann den Podcast beenden. Ich würde mich gerne bedanken bei Exinia, unserem Gast, und meinem Co-Host Thomas. Wenn ihr Feedback habt, könnt ihr gerne eine Mail schreiben an podcast-feedback@trainer.de und in diesem Sinne bis zum nächsten Mal.

Thomas: Ciao.

Axinia: Ciao und danke, dass ich da sein durfte.

[Musik spielt]