MIT-Zahl Und Harte Realität

SPEAKER_00 0:01

Im Sommer 2025 hat das MIT eine Zahl veröffentlicht, die wir sehr gerne erwähnen. Unter anderem, weil sie damals in Vorstandsetagen eingeschlagen ist wie eine Bombe. Von den KI-Pilotprojekten in Unternehmen bringen rund 5% einen messbaren Schub. 95% bringen so gut wie nichts. Keine messbare Wirkung auf die Gewinn- und Verlustrechnung. 95% stehen still, nachdem Geld, Zeit und Hoffnung hineingeflossen sind. Jetzt könnte man vermuten, dann taugt die KI eben nichts, aber genau das ist nicht, was die Forscher fanden. Sie schreiben ausdrücklich, das Problem sei nicht die Qualität der Modelle, sondern die Art, wie Unternehmen sie einbinden. Die Analysten von Gartner auf der anderen Seite sagten voraus, dass bis Ende 2025 mindestens 30% aller KI-Projekte nach dem Proof of Concept wieder beerdigt werden. Wir haben uns da ja schon auch ein bisschen die Gründe angeschaut, warum das so ist. Der allererste Grund, den sie nennen, zur Erinnerung, noch vor Kosten und unklarem Nutzen, ist schlechte Datenqualität. Auf Deutsch heißt das, es liegt nicht an der KI, es liegt an dem, womit wir sie füttern. Willkommen zu digitalem Wissensbissen. Neulich ging es darum, wann die KI rät. Heute geht es darum, dass euer Datenbestand der Füllstoff ist, der das verhindert. Aber diese Lösung für das Problem bringt selber wieder ganz eigene Probleme mit. Das Versprechen klingt ja an sich vorführisch und ich glaube, das ist auch das, was wir meistens im Kopf haben, wenn wir von so Firmenanwendungen für KI ausgehen, Firmenanwendung für Large Language Models. Da geht es darum, die KI liest einfach eure Dokumente, ihr schmeißt Verträge rein, Akten, Handbücher, was auch immer ihr so rumliegen habt. Dann fragt ihr in normaler Sprache, in menschliche Sprache, stellt ihr Fragen und bekommt verlässliche Antworten. Es gibt kein Suchen mehr, kein Blättern, ein Ende der Zettelwirtschaft, vielleicht sogar auch kaum noch eigene Dokumentenerstellung, das wird eigentlich alles von der KI übernommen. Und im Prinzip stimmt das ja auch. Man kann solche Anwendungen bauen, man kann auch in eigenen Experimenten mit ChatGPT zum Beispiel das relativ schön nachstellen, wie das aussehen könnte. Aber zwischen im Prinzip und im Betrieb steckt halt die Arbeit, über die keine der Hochglanzfolien noch, keine der LinkedIn-News und so weiter sprechen. Die Demo, die einem gezeigt wird, oder die Beispielanwendung, die zeigt die schöne Frage und die schöne Antwort und nicht das Dazwine. Aber das Dazwischen ist eigentlich ein Großteil der Arbeit und das zwischen ist auch der Punkt dieser Folge. Mal ein Schritt zurück. Warum denkt ihr überhaupt über den Einsatz von Large Language Models nach? In den meisten Fällen, in den sinnvollsten Fällen muss man auch sagen, ist, dass man sagt, wir haben einen Schrank voller Wissen, wir haben Dokumente rumliegen an verschiedensten Stellen. Da steckt Wissen und Arbeit drin und Erfahrung von mehreren Jahren. Für die meisten Firmen ist das so ein ungehobener Schatz, so ein ungehobener Goldschatz. Und es gab immer schon Initiativen, um an diesen Goldschatz wieder sinnvoll ranzukommen. Das Thema Enterprise Search, was so 200, 2006, 2007 so eine Riesenrolle gespielt hat, hat auch genau das versucht zu machen. Es hat versucht, dieses ganze Wissen zusammenzusammeln und durch Suche zugreifbar zu machen. Jetzt haben wir eigentlich das Gleiche wieder, sagen, hey, da haben wir einen Goldschatz, da liegt unser Wissen, da ist ein Schrank voller potenziell wertvoller Erfahrung. Das muss man doch irgendwie verwenden können und wieder effektiv machen. Da haben wir zum Beispiel Verträge, von denen müssten wir eigentlich wissen, was die Fristen sind, wann die auslaufen, wann sie sich automatisch verlängern und so weiter. Da haben wir Schadenakten, da müssten wir eigentlich reinschauen und sagen, was sind denn die Muster, was sind vielleicht auch Probleme, die Leute haben, wenn sie Schäden melden, was wird systematisch falsch gemacht, können wir da irgendwie auch unsere Dokumentation oder unsere Prozesse verbessern? Da gibt es Handbücher, die keine mehr im Kopf hat, die sich aber auf Tools und Software beziehen, die man regelmäßig noch anfassen muss. Darin liegt auf jeden Fall Potenzial. Aber was muss passieren zwischen meinen Dokumenten im Schrank, im übertragenen Schrank natürlich, sein digitaler Schrank, und der ersten verlässlichen Antwort, die ich aus ihnen rausholen kann? In der Realität ist es so, dass 90%, das ist auch schon immer so, hat sich kaum verändert, 90% der Unternehmensdaten unstrukturiert vorliegen. Das heißt, da ist eben nicht eine saubere tabellarische Struktur, das ist sogar eine Datenbank oder irgendwie semantisch annotierte Informationen, sondern das sind PDFs, Word-Dokumente, schlimmstenfalls Scans, ein Haufen Wissen steckt in E-Mails, die sowieso nur in der Inbox von irgendjemandem sind. Da gibt es Verträge, die sehr spezifische Sprachen benutzen. Es gibt Präsentationen, die aber in Wirklichkeit Prozessdokumente sind, weil das wurde halt damals das PowerPoint gemacht und nicht irgendwie anders. Es gibt Formulare, die teils handschriftlich ausgefüllt sind. Das ist kein Randphänomen, das ist der Normalfall. Der Normalfall ist, dass Daten so aussehen. Und zusätzlich zu den inhärenten Formatproblemen, das hat, kommt noch, dass bei der Hälfte ungefähr es auch noch zu einer Siloisierung gekommen ist. Das heißt, man weiß nicht genau, wo sie liegen. Es liegen verschiedene Versionen in verschiedenen Silos. Es gibt ein Bild, es gibt echte Doubletten, es gibt fast Doubletten, es gibt veraltete Fassungen von Verträgen, die unterschrieben wurden, dann gibt es aktualisierte Fassungen, die unterschrieben wurden, die aber zum Teil wiederum andere Dokumente referenzieren. Das führt dazu, dass ungefähr ein Viertel der Dokumente neu erstellt wird, obwohl sie schon vorhanden sind, weil keiner das Vorhandene richtig findet und die, die es finden, wissen nicht, ob sie es verwenden sollen, wie sie es verwenden sollen oder ob das jetzt zum Beispiel die letzte Fassung ist. Mitarbeiter journal mit Dutzenden Werkzeugen müssten aber eigentlich erstmal wissen, was ist denn da und welche Fassung gilt vor allem. Deswegen sagt IDC zum Beispiel, es kann eigentlich keine KI-Strategie geben. Das ist ja also ein Wort, was viele benutzen. Oh, wir haben eine KI-Strategie, wir rollen gerade in der KI-Strategie aus, wir haben ein Center of Excellence, das eine KI-Strategie erstellt. Aber es kann eigentlich keine KI-Strategie geben ohne

Datenqualität Schlägt Nutzenversprechen

SPEAKER_00 5:55

eine inhaltliche Strategie. Eine Datenstrategie, beziehungsweise sogar eigentlich eine Content-Strategie, wenn man so will. Ohne Hoheit über die Inhalte ist jede KI-Strategie aufs Sand gebaut. Da gibt es eine Demo dann, wird vorgezeigt, wie das auf drei handverlesenden Dokumenten funktioniert. Und im Produktivbetrieb scheitert es aber an den 3000 Dokumenten, die in der Realität in so eine Firma vorhanden sind. Weil das handselektierte Dokument für die Demo ist erstaunlicherweise nie ein schiefer Scan oder ein Fax, sondern es ist immer ein toll strukturiertes, händisch erstelltes Textdokument. Zusätzlich zu den Problemen mit der Siloisierung, den Dubletten und so weiter und der inneren Formatproblematik gibt es auch noch Herausforderungen mit der Struktur von Dokumenten. Dokumente werden meistens von Menschen für Menschen geschrieben. Das heißt, sie haben Idiosyncrasien von persönlicher Art, aber auch Idiosynkrasien, die bestimmte Fachbereiche einfach in all ihre Dokumente reintragen. Zum Beispiel ein Vertrag hat immer Anlagen, die Verweisen meistens auf den Vertrag zurück, dann verweisen sie oft auf ein anderes Dokument, manchmal verweisen sie auf eine ältere Fassung von einem anderen Dokument. Für einen Menschen, wenn der das liest, der fädelt das auf, der hat beides offen, guckt hin und her, cross-referenziert sich das, macht sich vielleicht Notizen. Für eine KI ist das ein ziemliches Labyrinth. Eine KI, ein Large Language Model, dem ich dieses Vertragswerk dann füttere, das sieht im schlimmsten Falle nur Fetzen und nicht den roten Faden und rät dann eben wieder. Dann haben wir wieder die Halluzinationen aus der vorletzten Folge, war es, glaube ich, und diesmal haben wir die Halluzinationen dadurch erzeugt, dass wir das Futter für die KI, also das, was eigentlich die Halluzination vermeiden soll, verhindern soll, nicht richtig aufbereitet haben, sodass das Large Language Model auch gut damit klarkommt. Wenn man sich in einem Aktenschrank so einen normalen Vertrag rauszieht oder irgendein anderes rechtliches Dokument, dann hat man oft so Sachen wie in ⁇ 2 steht Haftung gemäß Anlage 7, in Anlage 7 steht Abweichend von AGB Stand März und wie der Name schon sagt, gibt es dieses AGB-Dokument in vier Ständen. Und der gültige Satz ist dann erst in einem Nachtrag per E-Mail, der irgendwie zwei Jahre später geschrieben wurde, um das Ganze klarzustellen. Für einen Menschen ist es auch relativ viel Arbeit, sich da durchzuwühlen. Der Mensch, der an diesem Prozess beteiligt war, weiß es natürlich vielleicht sogar noch. Für eine KI ist es relativ unsortiert und die Wahrscheinlichkeit, dass eine KI aus so einer Kette in einer Live-Anfrage den falschen Stand rauszieht, ist schon sehr, sehr hoch. Verschärfen kommt hinzu, dass diese Problematik dort am häufigsten vorkommt, wo auf der anderen Seite durch den Einsatz von Large Language Models am meisten auf dem Spiel steht. Wenn man sich überlegt, wie Versicherungen arbeiten, Banken, Kanzleien, Pharmaindustrie, das sind die größten, ältesten, verwobensten Bestände an Dokumenten auf der einen Seite. Auf der anderen Seite aber auch das höchste Risiko und die höchsten Kosten, wenn eine Auskunft mal falsch ist. Das heißt, eigentlich kann man sogar allgemein sagen, je schwieriger der Bestand, desto größer ist die Versuchung, Large Language Models draufzuschmeißen und desto folgenreicher ist aber auch oft das Scheitern. Das ist dieselbe Medaille von zwei Seiten. Wie gesagt, der Effekt davon, wenn man das Problem nicht löst, ist, dass selbst mit Dokumenten, die von euch kommen, es zu Halluzinationen kommen kann. Das ist so, wenn man sich so Standard-Rag-Anbieter anschaut, und da gehört auch Microsoft dazu, die haben auch so Standard-Rag-Implementierungen, dann sagen die, hey, wir geben der KI ja eure Dokumente mit. Das ist ein Retrieval, Retrieval Augmented Generation. Da wird zuerst was geholt und dann wird es der KI gegeben und das löst das Halluzinieren. In der Theorie stimmt das eben auch. Wenn man das richtig macht, kann man damit Halluzinationen und viele negative Effekte von Large Language Models sehr, sehr stark runterfahren. Aber in der Praxis ist es so, wenn das nicht gut gemacht wird, funktioniert es nicht. Es gibt ja diese in den USA relativ viele Startups, die sich so in Richtung Legal AI entwickeln, also KI-Tools für Rechtsfragen. Und die sind natürlich immer an echte Gesetzestexte angebunden, an Urteilsdatenbanken angebunden und werden damit halluzinationsfrei oder halluzinationsarm beworben. Und das Ergebnis, wenn man die untersucht, diese Tools, die ja nun unglaublich viel Daten haben, auf die sie zugreifen können. Im Ergebnis ist es immer besser als ein nacktes Modell, also ein Modell ohne Daten oder ohne Dokumente, die angeschlossen sind. Aber dennoch über 17 bzw. 34% der Antworten sind falsch. Je nachdem, welches Tool man jetzt evaluiert. Das ist mehr als jede dritte Antwort. Das heißt, auch angebundene Systeme, Systeme mit Rückgriff auf Datenbestände sind nicht halluzinationsfrei. Und hier reden wir von teuren Spezialwerkzeugen mit kuratierten DBs, also mit kuratierten Datenbanken von Fakten oder Gesetzestexten. Es ist kein Schnellschuss, den jemand mit Claude Code an einem Nachmittag zusammengestümpert hat. Während man sich bewusst machen muss, dass Daten ein Schlüssel sind zu guten Large Language Model-Anwendungen, zu guten KI-Anwendungen in diesem Sinne, ist es auch kein, es ist auf der anderen Seite auch keine Allheilmittel und auch keine Silverbullet. Das funktioniert nicht automatisch. Es gibt noch eine zweite, subtilere Fehlerart, nämlich Missgrounding. Grounding heißt, dass man einem LLM mitgibt, was quasi die Wahrheitsquelle sein soll. Missgrounding heißt, die Quelle existiert, das Large Language Model nimmt die Quelle auch irgendwie her. Aber die Aussage, die rauskommt, passt nicht zur Quelle und wird von dieser Quelle gar nicht getragen. Das heißt, die Fußnote mit der Quellenangabe ist echt, aber der Satz, hinter dem sie steht, ist erfunden. Das ist natürlich besonders heimtückisch, weil es einer oberflächlichen Plausibilitätsprüfung standhält, weil es auch unserem, also dem Prinzip, was wir auch quasi immer erzählen, zwingt die KI ihre Quellen anzugeben, durchaus entspricht und trotzdem keine richtige Antwort hat. Der Grund dafür ist meistens, dass das richtige Dokument zu finden zu schwer bzw. unmöglich ist, steht vielleicht an der falschen Stelle oder ist eben nicht angebunden oder geht unter in dieser Dokumentenmenge und dann bringt das Modell eben die perfekte Antwort auf dem falschen Fundament. Das heißt, lange Rede, kurzer Sinn, ich kann im Large Language Model nicht einfach meinen Aktenschrank hinstellen und sagen, alles andere machst du selber, sondern ich muss meinen Aktenschrank ordnen, sodass das Large Language Model bzw. das System,

Der Wissensschatz Im Dokumentenschrank

SPEAKER_00 12:30

das ich drum herum baue, eine Chance hat, an der richtigen Stelle in diesen Aktenschrank zu greifen. Und nicht einfach alles mal durchzublättern und dabei vielleicht die richtige Akte zu übersehen. Die dritte Falle, die es gibt in diesem Kontext, obwohl man Grounding mithilfe von eigenen Daten betreibt, ist, dass die KI, in dem Falle sollte man sagen, spezifisch Large Language Models, nicht KI im Allgemeinen, Large Language Models sind unterwürfig. Das hat verschiedene Effekte. Am Anfang gab es viele Modelle, die haben nicht mal Nein gesagt oder ich weiß nicht, weil sie immer versucht haben, dem Nutzer zu Diensten zu sein und auf jeden Fall zu antworten. Das war tatsächlich problematisch, weil dazu natürlich auch, das natürlich auch zu vielen Halluzinationen geführt hat. Aber auch jetzt, wo Modelle durchaus man sagen, ich weiß nicht oder ich habe da keine Informationen dazu, haben sie immer noch die Tendenz, dem Nutzer nach dem Mund zu reden. Was bedeutet das? Dass sehr, sehr viele Anfragen, die ich an KI stelle, die ich an Chat-Interfaces von KI-Tools stelle, ChatGPT, Claude und so weiter, sind suggestiv. Das merke ich aber selber gar nicht, sind Suggestivfragen irgendwie. Und dann redet die KI mir natürlich nach dem Mund. Wenn ich eine falsche Annahme in die Frage schon mal reinpacke, dann wird das normalerweise oder oft, sagen wir es so, oft übernommen, statt dass dem widersprochen wird. Deswegen ist es so problematisch, dem Eutzer direkt einen rohen Prompt zu geben und zu sagen, frag da mal selbst. Normalerweise muss man da relativ viel drumherum bauen, um diese Effekte zu verhindern. Im Test von solchen Legal-Tools kam zum Beispiel raus, dass wenn ich eine falsche juristische Prämisse, also eine falsche Annahme, auf der ich dann eine Begründung aufbauen möchte, in die Frage reinformuliere, dann stellen diese Tools sehr, sehr oft diese Annahme nicht in Frage, auch wenn die gar nicht korrekt ist. Sondern sie bauen dann eine juristisch saubere Begründung auf, aber auf der Basis dieser falschen Annahme. Ich habe also in diesen Tools spezifisch nicht nur das Problem, dass unter Umständen die Quellen nicht korrekt eingebunden werden, sondern es wird überhaupt nicht in den Quellen geschaut, wenn ich als Nutzer Suggestivfragen stelle und quasi schon so mitgebe, was ich eigentlich hören will. Der eigentliche Schocker an diesem Beispiel ist natürlich, wenn jetzt schon kuratierte Spezialdatenbanken so abschneiden, wie musste es erst sein, wenn ich mein rohes Netzwerklaufwerk einfach in irgendein KI-Tool einbinde? Man kann da in gewisser Weise eine einfache Selbstdiagnose machen. Erstens fragt euch mal, habt ihr schon mal ein wichtiges Dokument gesehen in eurer Firma, das nur als Bild existiert, als Scan oder als Bild? Zweitens, gab es schon mal den Fall, dass ihr von einem Dokument mehrere Fassungen hattet und keiner weiß oder wusste so genau, welche wirklich gilt. Drittens, kommt es in eurer Firma vor, dass Verträge, Akten, vielleicht auch andere Dokumente stark verknüpft sind, also aufeinander verweisen und solche Begriffe benutzt wie SIA, Anlage, gemäß Paragraf, vorbehaltlich und so weiter. Und viertens, habt ihr manchmal das Gefühl oder konnte ich dir das Gefühl bestätigen, dass das Wissen über die Zusammenhänge in Wirklichkeit nur in wenigen Köpfen von Menschen existiert. Ich würde sagen, wenn man nur zwei dieser Fragen mit Ja beantwortet oder wo man zumindest zögern muss, Nein zu sagen, dann wird das wahrscheinlichste Problem im Einsatz von Large Language Models im Datenbestand sitzen und nicht im Large Language Model. Und die gute Nachricht ist, diese Frage ist natürlich bearbeitbar, beantwortbar in einer gewissen Weise, bevor ein Euro ins Modell fließt. Und die Arbeit, die wir hier jetzt investieren, wird nicht nur die KI besser machen, sondern insgesamt die Zusammenarbeit und alles. Aber es muss bewusst gemacht werden, dass ein Großteil der Arbeit von diesem Rollout wahrscheinlich dann in Bestandspflege und im Strukturieren und Ordnen des Datenbestands liegen wird. Oder vielleicht auch im Zusammenschneiden des Datenbestands. Es ist natürlich viel einfacher, spezialisierte Tools mit wenigen korretierten Dokumenten zu bauen, als allgemeinen Tools mit allen Dokumenten. Und vielleicht sind ja ein Dutzend Spezialtools in manchen Kontexten einfach der bessere Ansatz. Der Zustand dieser Daten ist natürlich per se messbar, benennbar und behebbar. Man muss nur drauf schauen und das in der richtigen Reihenfolge in das Rollout-Projekt einplanen. Gut, was genau muss man denn einplanen? Was heißt aufbereiten? Was heißt es, diesen Datenbestand so vorzubereiten, dass er für Large Language Models wirklich geeignet ist? Das ist leider kein Knopf und auch kein Produkt, es ist jetzt tatsächlich eher Handwerk. Und da geht es um mehrere Schritte. Der erste Schritt muss sein, dass man die Text- also die reine Dokumentenqualität versucht zu maximieren. Das ist natürlich ein automatischer Schritt, das sollte jetzt niemand manuell machen. Aber wenn wirklich zum Beispiel noch Scans und Faxe irgendwo da liegen, dann sollte man die einmal sauber OCR und die OCR-T-Version ablegen, also die Version mit dem Textlayer ablegen. Unter Umständen sollte man Querverweise auflösen, beziehungsweise zumindest Dokumente, die zusammengehören, sinnvoll zusammen ablegen. In manchen Fällen haben wir das auch tatsächlich so gemacht, dass wir sagen, hey, die KI arbeitet nie mit dem Originaldokument, sondern die KI arbeitet mit nur so einer Art denormalisierten Version des Dokuments. Das heißt, sie nimmt in einem Vorverarbeitungsschritt das ganze komplexe Vertragswerk mit den Klausen, Querverweisen in Anlagen und übersetzt das quasi in ein immer natürlich sprachliches Dokument, das diese Querverweise auflöst, sodass einfache Fragen auf diese Struktur beantwortbar werden. Natürlich muss auch die Struktur, die in Dokumenten vorhanden ist, für die Large Language Models sichtbar bleiben und auch verwendbar bleiben. Also Überschrift, Klausel, Klausel, Stichpunkt, solche Beziehungen müssen wir erhalten in der Vorverarbeitung für so eine LLM-Anwendung. Oder auch Fußnoten zum Beispiel. Genauso muss man versuchen, irgendwie den Datenbestand auch einzuteilen in quasi Arbeitsdokumente und Endresultate. Das haben natürlich auch die meisten nicht so wunderbar vorbereitet. Aber wenn ich ein Sharepoint habe mit Projektdokumenten

Unstrukturierte Daten Silos Versionenchaos

SPEAKER_00 18:55

und jedes dieser Projektdokumente hat zehn Versionen, dann ist es für ein Large Language Model gar nicht so leicht zu wissen, welche Version es hernehmen soll. Und die Wahrscheinlichkeit, dass es die falsche nimmt oder dass es dadurch, dass es mehrere Versionen gibt, zu eigenartigen Effekten kommt, ist relativ hoch. Aber das ist hierzu passt, was ich am Anfang gesagt habe. Natürlich profitieren auch Menschen davon, wenn man sich diese Arbeit macht und sagt, okay, wir müssen jetzt mal Ordnung ins Haus bringen und zumindest mal ein Metadatum einführen für versandte Verträge oder gezeichnete Verträge im Gegensatz zu Versionen, die davor kamen. Es lohnt sich auch unter Umständen, manche andere Metadaten im Vorhinein anzulegen, damit man quasi Dokumentenbestände vorsortieren kann, bevor man sie an einem Large Language Model gibt. Also Namen, Daten, Beträge, Fristen und so weiter. Das muss man nicht eigentlich das Large Language Model jedes Mal aus dem Vertrag rausziehen lassen, wenn man eine Frage hat, sondern das kann man auch einmal mit einem Large Language Model rausziehen und parallel ablegen als Metadatum. Wie gesagt, finale Versionen zu markieren, ist extrem lohnend. Dublettenveraltete Fassungen, letzten Endes müssen die raus. Oder müssen zumindest irgendwie ein Archiv und das muss ausgeschlossen werden von der Durchsuchbarkeit für das LLM. Das ist auch deswegen wichtig, weil, wie wir in, glaube ich, vor zwei Folgen gesagt haben, es ist ja sehr wichtig, bei solchen Anwendungen irgendwie auch der Bewegpflicht nachzukommen. Das heißt, ich muss, wenn ich mit Large Language Models Antworten generiere, muss ich irgendwie die Herkunft mitführen. Je besser strukturiert meine Dokumente sind und je besser strukturiert die Dokumentenanlage ist, auf die meine KI-Anwendung zugreift, desto besser kann ich das natürlich auch machen, desto qualitativ hochwertiger funktioniert das, dass ich für jede KI-Antwort auch wirklich generieren kann, dass ich auf die Quelldokumente für diese Antwort zurückkomme. Das ist natürlich unspektakulär, aber das ist der Unterschied zwischen einer Demo und dem Betrieb, den hatten wir glaube ich in der letzten Folge ausführlich diskutiert. Die Statik unter diesem schönen Raum, den man in der Demo sieht, die ist eigentlich das, worauf es ankommt. Die ist unsichtbar, so wie die Statik von einem Haus, aber ohne sie fällt natürlich alles zusammen. Im Ergebnis führt es dann natürlich dazu, dass wenn ich eine Frage stelle, wie welche Kündigungsfrist habe ich in diesem jedem Vertrag, dass da kein flüssiger Absatz kommt, der aber falsch ist, sondern dann kommt eine Antwort mit einer Fundstelle und die Fundstelle bezieht sich auf das richtige Dokument und dann kann ich das auch in 10 Sekunden nachprüfen. Wenn die Antwort sich auf V9 von 20 bezieht und ich aber gar nicht weiß, dass es 20 Dokumente gibt oder 20 Versionen dieses Dokuments gibt, dann kann ich es nicht nachprüfen. Dann weiß ich nämlich gar nicht, ob eine Antwort vielleicht bezogen auf diese eine Dokumentenversion richtig ist, sich aber in späteren Version geändert hätte. Das heißt, der Unterschied zwischen O, das klingt gut versus O, das stimmt nachweislich, entsteht primär in der Vorarbeit und in der peripheren Arbeit in so einem KI-Tool und nicht im Modell. Das haben wir selber bei vielen Kunden und auch wirklich zigmal gesehen, dass es darum geht, dass es wirklich tausende Dokumente gibt, dass die über Jahrzehnte entstanden sind. Sind sich gegenseitig referenzieren, teilweise in Scans da liegen, teilweise drei Fassungen haben, teilweise jedes Jahr aktualisiert werden, die alten Jahre liegen immer mit dabei. Dann passiert immer wieder, dass die ersten KI-G-Versuche nicht an der KI scheitern, sondern eben am Bestand. Da zieht das Modell dann mal eine alte Klausel raus, mal eine Anlage ohne Verweis, die eigentlich gar nicht im Vertrag eingebettet ist, sondern nur daneben liegt und nie verwendet wurde und gibt dann sehr, sehr selbstbewusst falsche Antworten. Für Sachbearbeiter ist das natürlich schlimmer als keine KI. Und ich glaube, das ist auch einer der Gründe, warum so viele KI-Piloten scheitern und warum ja auch Menschen so viele Trust-Issues haben mit KI. Wenn du einmal als Fachbereichsexperte eine selbstbewusste Antwort gesehen hast, die falsch ist, das nachprüfst und es auffliegt, oder du prüfst es nicht nach und es fliegt beim Kunden auf, im Kundenkontakt auf, dann ist dieses verspielte Vertrauen natürlich kaum zurückzuholen. Der Pilot stirbt dann quasi an diesem Vertrauensschock und nicht daran, dass er nichts Sinnvolles tut. Und die Lösung dazu ist, man kann es nicht oft genug sagen, nicht ein besseres Modell. Modelle werden kaum noch besser in der Hinsicht, dass sie Anwendungsfälle wirklich, die in der Realität eine Rolle spielen, so viel besser abbilden. Sondern die Lösung liegt im Bestand. Verweise, Strukturen, Entitäten, Doubletten, Herkunft, das ist, wo wirklich der Eifer reingehen sollte. Wenn man den Bestand aufbereitet, was natürlich wir auch in diesen Fällen gemacht haben und auch mit Hilfe von KI aufbereitet natürlich, dann muss dann nicht unbedingt jemand sich manuell hinsetzen, dann läuft das plötzlich, dann läuft es in Produktion mit dem ganzen Bestand, das gleiche LM, das gleiche Modell, gibt dann in der überwältigenden Mehrzahl der Fälle korrekte Antworten. Ein weiteres Problem an dieser Sache ist natürlich, dass der Bestand dummerweise nicht ein Foto ist, sondern ein Film. Also das heißt, der Bestand lebt. Es gibt täglich neue Verträge, es gibt täglich Nachträge zu existierenden Verträgen, es gibt E-Mail-Kommunikation, die vertragliche Verpflichtungen ändern zum Beispiel. Es gibt von Kundendokumenten verschiedene Fassungen. Es gibt Korrespondenz, in der Requirements festgelegt werden. Das heißt, diese

RAG-Fallen Missgrounding Suggestivfragen

SPEAKER_00 24:20

Aufbereitung ist kein Projekt, diese Aufbereitung ist auch ein Prozess. Die muss mitlaufen, die muss sowohl organisatorisch verankert werden als auch technologisch gelöst, sonst driftet die saubere Basis nach Monaten natürlich wieder zurück ins Knoll. Deswegen ist es auch nicht die Lösung zu sagen, ja, wir ziehen einmal die guten Dokumente raus und legen die irgendwo separat nochmal ab und dann kann die KI da drauf arbeiten. Das wird ja spätestens im nächsten Jahr dann komplett mit der Realität nicht mehr im Einklang sein. Das heißt, eine ehrliche Rechnung, eine ehrliche Kostenlustenrechnung für so ein Tool, muss auch das mit berücksichtigen. Muss aber auch mit berücksichtigen, wenn sie wirklich ehrlich und fair ist, dass diese Arbeit auch für Menschen, die den Dokumentenbestand verwenden, extrem viele Vorteile bringt. Das heißt, wir tun das ja nicht nur für das Large Language Model. Wir tun das auch für unsere Mitarbeiter, die dann auch endlich wissen, welche Version von einem Vertrag denen gilt. Ich habe das tatsächlich selber auch schon erlebt in Projekten, wo wir beratend tätig waren, dass Verträge zwischen Parteien so oft hin und her geschickt wurden und zum Teil auch noch übersetzt, immer hin und her übersetzt, dass am Ende wirklich überhaupt niemand mehr wusste, welche Version jetzt eigentlich gezeichnet werden soll. Also das war dann nochmal so viel Arbeit rauszukriegen, was jetzt eigentlich das Ergebnis dieses Austauschs war, welches das finale Dokument war. Weil das kennt auch, glaube ich, die Mehrzahl der Leute unangenehmerweise aus eigener Erfahrung, dass man den Fehler macht, ein Dokument an zwei Personen zu schicken, beide machen Änderungen und schicken es zurück oder schicken es dann auch noch einander und am Ende weiß überhaupt niemand mehr, wo hinten und vorne ist. Das ist natürlich ein Problem, das kann ich mit einem Large Language Model nicht jetzt einfach lösen. Das muss ich aber für das Large Language Model lösen, damit es weiß, welche Vertragsversion gilt. Gut, sollte man das selbst machen, sollte man ein Cent of Excellence gründen, eine Dateninitiative starten, sollte man ein Werkzeug von der Stange kaufen, sollte man externe Consultants aufrufen. Gut, da wir als Firma natürlich externe Consulting-Dienste anbieten, sind wir in der Hinsicht parteiisch. Aber auch diese MIT-Studie hat gesagt, dass mit spezialisierten Partnern KI-Pilot-Projek natürlich deutlich höhere Erfolgsquoten haben als Eigenbauten. Das ist in dem Sinne kein Verkaufsargument, sondern einfach die nackte Quote. Nicht, weil die internen Leute das nicht hinkriegen, sondern weil die Erfahrung, die man dafür braucht, um das richtig zu machen, man nicht sich in dem Wochenende anlesen kann. Diese Erfahrungen kriegt man natürlich primär im Kontakt mit realen Datenproblemen, mit realen Large Language Model Problemen, mit realen Anforderungen von Kunden und realen Prozessen. Diese Klemmstellen, an denen das hängt, sieht man natürlich, wenn man sie schon dutzendmal gesehen hat, deutlich schneller und einfacher und weiß auch deutlich schneller, wo Lösungen dafür liegen könnten. Es ist tatsächlich leider so, dass die typische Reihenfolge oft ist, dass man sagt, hey, man nimmt irgendein Tool von der Stange, sei es jetzt Copilot, sei es ChatGPT, sei es Claude, baut in zwei Wochen eine Demo auf dem eigenen SharePoint-Server und es stellt dann aber fest, oh, wenn ich meinen echten Bestand damit live verwende und wenn die Mitarbeiter tatsächlich die Fragen stellen, die sie in der Realität beantwortet brauchen, dann kippt das Ganze. Dann kommen falsche Treffer, leere Treffer, selbstbewusster Unsinn und so weiter und so fort. Und dann wird das Ding natürlich meistens still beerdigt. Nicht, weil die KI nichts kann, sondern weil eben die Vorarbeit übersprungen wurde. Und genau die sollte man eben machen, bevor jemand von KI spricht. Ich möchte nochmal wiederholen, es geht ja hier nicht darum, nur für die KI etwas zu tun. Es geht darum, dass ein aufbereiteter Datenbestand kein Wegwerfaufwand ist, sondern ein realer Vermögenswert. Einmal strukturiert, entworren, mit Herkunft. Das trägt nicht nur die eine Anwendung, wo jetzt jemand quasi den Dokumentenbestand interviewen will oder wo Mitarbeiter besser finden wollen, was für Projekte die Firma gemacht hat oder Templates finden wollen für Angebote und so weiter, sondern es trägt auch die nächste Anwendung, Fristenüberwachung, automatisch. Risikoanalyse, automatisch. Quartalsbericht automatisch. Zusammenfassung für den Aufsichtsrat, fast automatisch. Die Modelle tauscht ihr mehrfach, die Anwendungen kommen immer neu hinzu, der Bestand bleibt, der ist das Fundament von all diesen Dingen. Also Investitionen ins Fundament sind kein reiner Projektkostenblock, sondern die strahlen in alle zukünftigen Projekte aus, die auf diesem Datenbestand fußen. Das heißt auch umgekehrt gesagt, erst sich für ein Modell entscheiden und den Dokumentenbestand einfach ignorieren, das ist genau falsch rum. Noch eine Bemerkung in eigener Sache. Wenn euch dieser halbkritische, halb enthusiastische Blick auf KI gefällt, wenn ihr wissen wollt, wie man KI wirklich gut produktiv einsetzen kann, statt Geld in einem Piloten zu stecken, der dann nie zu irgendwas führt. Und wenn ihr wissen wollt, wie man die unleugbaren Probleme in den Griff bekommt, dann abonniert doch bitte gern diesen Podcast, abonniert digitale Wissensbissen, weil genau darüber reden wir eigentlich in jeder Folge. Die meisten KI-Projekte scheitern nicht an der KI. Sie scheitern nicht an dem Ludge Language Model. Sie scheitern an dem, was vor der KI liegt, an dem, womit wir die KI füttern, nämlich einem Dokumentenbestand, der von Menschen für Menschen gemacht wird und nicht mal das gut und der nicht für Maschinen gemacht wurde und der vielleicht auch überhaupt nicht irgendwie bewusst strukturiert oder aufgeräumt wurde jemals. Neun von zehn Daten sind unstrukturiert, liegen in Textform vor oder sogar als Scan, liegen verstreut, verweisen im Kreis. Und selbst einen Large Language Model, das mit diesem Dokumentenbestand perfekt verbunden ist, technologisch, halluziniert oder greift ins Leere,

Aufbereitung Als Prozess Und Nächste Schritte

SPEAKER_00 30:05

wenn diese Datenaufbereitung übersprungen wird. Die gute Nachricht dieselbe wie immer, wenn man das Problem einmal erkannt hat, kann man es auch lösen und dieses Problem ist lösbar, aber man muss es in der richtigen Reihenfolge angehen. Erst der Datenbestand, dann die KI-Implementierung. Wer das umdreht, also erst das teure Prestige-Projekt und dann die Erkenntnis, dass die Daten nichts taugen, zahlt für einen Piloten, der nie in Produktion geht. Wer es richtig rummacht, baut etwas, das trägt und viele zukünftige Projekte und auch viele zukünftige Tools und Prozessoutomatisierung oder Prozessoptimierung ermöglicht. Und das ist kein Hexenwerk, sondern Handwerk und fängt nicht bei der KI an, sondern bei dem, was ihr zu fressen gebt. Investiert jetzt 5 Minuten, anstatt später vielleicht ein fünfstelliges Lehrgeld zu zahlen. Unser kostenloser Check zeigt euch, an welchen sechs Stellen euer KI-Vorhaben in Produktion kippen könnte. Jetzt einfach ausfüllen unter neomo.link schrägrich-check. Den Link findet ihr auch in den Shownotes.