Digitale Wissenswissen

Intro 0:01

Welche Technologie kann meinen Geschäftsprozessen auf die Sprünge helfen ? Ist generative KI schon reif für den Unternehmenseinsatz ? Wie kommt meine Applikation in die Cloud und was habe ich davon ? Diese und weitere Fragen am Schnittpunkt von Business und Tech beantworten wir im Podcast Digitale Wissenswissen .

Johannes Stiehler 0:22

Ich mache seit eigentlich 25 Jahren primär Suche . Es hört sich zwar langweilig an , und Suchtechnologie ist auch ein bisschen mittlerweile eine Commodity geworden . Letzten Endes reden wir von entweder Open-Source-Implementierung oder Suchanwendung-Technologien , die sowieso schon in Portalen enthalten sind , oder in solchen Produkten wie Microsoft 365 . Aber erstaunlicherweise ist seit 25 Jahren Suche ein ungelöstes Problem . Das zeigt sich auch daran , dass jetzt im Zuge von generativer KI und solchen Technologien im Prinzip wieder über Suche diskutiert wird , nämlich der Gestalt , dass sich Leute fragen ist das jetzt das Ende von Google ? Ist OpenAI das Ende von Google ? Ist OpenAI das Ende von Google ?

Johannes Stiehler 1:06

Weil eben doch auch die Google-Suche , die jetzt schon so lange optimiert wird , die schon so lange existiert und die schon so lange auch wahnsinnig viele Millionen Nutzer anzieht , immer noch nicht perfekt ist in dem Sinne , dass man wirklich zufrieden wäre mit den Ergebnissen . Das heißt , die Leute schauen sich jetzt OpenAI und ChatGPT und ähnliche Tools an , auf der Suche nach besseren Möglichkeiten , um Informationen zu finden . Für mich war immer die beste Möglichkeit , informationen zu finden , oder potenziell die beste Möglichkeit eigentlich die Suche in einem Portal , das heißt die Suche auf den eigentlichen Webseiten , die Suche zum Beispiel auf spiegelde oder auf süddeutschede oder auf FAZnet . Diese Suchschlitze sollten doch eigentlich die beste Erfahrung bieten , weil sie am nahesten am Inhalt dran sind , weil diese Suchen implementiert wurden von Leuten , die genau wissen , mit welchen Inhalten sie umgehen , die genau wissen , worauf sie Wert legen im Bereich Suche und was eigentlich gefunden werden soll . Schockierenderweise sind diese Suchen auf diesen Portalen , diese Suchimplementierung zum Teil so schlecht , dass die Leute lieber mit Google von außerhalb drauf schauen . Das ist ein Phänomen , das wir auch häufig gesehen haben bei Leuten , die später Kunden geworden sind , war , dass viele , viele Menschen lieber zu Google gehen und dann sagen süddeutsche Artikel über XYZ , statt dass sie auf dem Portal der Süddeutschen , auf dem Portal der NZZ oder wie auch immer direkt nach dem suchen . Weil die Suche auf den Portalen meistens noch ungenauer , noch unpräziser ist als die Suche auf Google . Das ist interessant, weil wir beschäftigen uns mit dem Thema schon sehr lange . Wir als Firma, NEOMO sowieso, aber auch das ganze Internet ist im Prinzip mittlerweile rund um Suche aufgebaut . Und irgendwann, so 2007 so da hatten sich Internetsuchtechnologien schon, – oder 2005 eher – sehr stark durchgesetzt . Google hatte im Prinzip schon sich Richtung Monopol mehr oder weniger aufgemacht, kam Suche auch in den Firmen an . 2007,, die in der Firma auf Servern verteilt lagen , oder in irgendwelchen frühen Document-Management-Systemen , dass man die indexiert und eine gemeinsamen Suche zur Verfügung gestellt

Johannes Stiehler 3:25

hat .

Johannes Stiehler 3:25

Enterprise-Suche war ein Key-Enabler , eine Infrastrukturkomponente letzten Endes für völlig neue Geschäftsprozesse . Man konnte damals erstmals Geschäftsprozesse bauen , die davon abhingen , dass man existierende Informationen verlässlich und wiederholbar wiederfand , egal wo sie abgelegt worden waren . Und auch diese Enterprise-Se , enterprise Search Projekte hatten die gleichen Probleme , die man jetzt auf Portalsuchen wieder sieht . Es ist im Prinzip immer nur ein Relevansthema . Also es beginnt mit der Frage , ob überhaupt alle Inhalte in der Suche verfügbar sind .

Johannes Stiehler 3:57

Das sollte natürlich gewährleistet sein . Aber schon das nächste Problem ist wie relevant sind die Ergebnisse , die ich sehe , wenn ich etwas suchee mit einem Suchbegriff anfrage ? wie wahrscheinlich ist es , dass das , was ich dann zu Gesicht bekomme , tatsächlich das ist , was mein Problem löst ? Das ist auch der Grund , warum natürlich solche Dinge wie generative KI so viel beliebter sein könnten als Suche auf Dauer , weil man da die Antwort ja quasi direkt schon präsentiert bekommt und sich gar nicht mehr fragen muss .

Johannes Stiehler 4:23

Beantwortet das meine Frage auch ? Im Prinzip muss man sich nur noch fragen , ob die Antwort korrekt ist , weil natürlich generative KI im Gegensatz zur Suchmaschine auch einfach Dinge erfindet , wenn sie im Dokumentenbestand nicht vorhanden sind . Warum ist das jetzt so schwierig ? Warum sind Portalsuchen immer noch so schlecht ? Warum ist auch in der Firma die Suche immer noch so schlecht ?

Johannes Stiehler 4:46

Warum ist das so ein kompliziertes Problem ? Weil eigentlich heißt es ja nur ich nehme ein Dokument , alle Wörter , die da drin vorkommen , schmeiße ich in einen Suchindex . Wenn jetzt ein Nutzer mit dem gleichen Begriff sucht , dann bekommt er alle Dokumente , in denen dieser Begriff vorkommt . Ich glaube , dass genau da das Problem liegt . Suche wird zu sehr als eine Art binäres Matching-Problem gesehen , als gäbe es ein ich finde einen Term , oder ich finde keinen Term , oder ich finde einen Term , oder ich finde einen Term nicht , und damit wäre das Ganze schon erledigt .

Johannes Stiehler 5:17

Meiner Meinung nach ist es viel produktiver , wenn man über Suche nachdenkt , als ein Übersetzungsproblem , weil nämlich die meisten Nutzer nicht mit der gleichen Sprache suchen , die die Dokumente verwenden . Was meine ich damit ? Ich meine damit nicht Mehrsprachigkeit , ich meine nicht .

Johannes Stiehler 5:35

Ich suche auf Deutsch , und Dokumente sind in Englisch . Das gibt es natürlich auch , aber total häufig hat der Nutzer in seinem Kopf eine bestimmte Art , dinge zu formulieren , hat auch einen bestimmten Kontext , in dem er denkt , hat auch einen bestimmten Kontext , in dem er denkt , und in dem Dokument ist aber der gleiche Fakt , der gleiche Kontext , der gleiche Begriff völlig anders repräsentiert , und ich muss aus dem einen das andere übersetzen . Es gibt ein Beispiel , ein sehr plakatives Beispiel , das ich von meinem Professor an der Uni geklaut habe . Der hat mal gesagt wenn ich suche auf einem Jobportal , wenn ich dazu was suche wie Java-Entwickler in Süddeutschland , dann sind das eigentlich tausende Queries , die ich machen muss , weil auf dem Jobportal in den eigentlichen Stellenanzeigen steht nicht Java-Entwickler in Süddeutschland , das ist mein persönlicher Fokus , sondern da steht J2E-Entwickler in Süddeutschland , das ist mein persönlicher Fokus , sondern da steht J2E Entwickler in Memmingen , da steht Spring , entwickler in München und so weiter . Das heißt beide Begriffe , die ich verwende Java , entwickler , undonymen oder Hyponymen , das heißt übergeordneten oder untergeordneten Begriffen . Und diese Übersetzung aus meiner Nutzerintention gucke ich drauf und sage hey , ich suche einen Job als Java-Entwickler , wahrscheinlich nicht in Süddeutschland , weil ich werde nicht umziehen , sage ich mal in Oberbayern , und umgekehrt . Das , was jemand in eine Stellenausschreibung schreibt , was wahrscheinlich eher sowas ist wie JTRE-Entwickler in München , das muss ich ineinander übersetzen . Und 90% der Suchimplementierung meiner Meinung nach sind Mist , weil sie das nicht berücksichtigen .

Johannes Stiehler 7:21

90% der Suchimplementierung benutzt eine Out-of-the-Box-Funktionalität . Da wird ein Elasticsearch oder ein Solr draufgeschmissen , und dann wird einfach die Nutzerquery genommen und als so ein leichtes Oder mit Stopp-Wörtern gegen die Dokumente gematcht . Wenn da nicht Java drinsteht , dann matche ich das auch nicht . Wenn da nicht Entwickler drinsteht , sondern Engineer , matche ich das nicht . Wenn da nicht Süddeutschland drinsteht , sondern München , matche ich das auch nicht .

Johannes Stiehler 7:40

Diese Übersetzungen zwischen der Anfragesprache und der Dokumentensprache , anfragesprache und der Dokumentensprache sind das , was eine Suche wirklich großartig machen kann . Manche von diesen Übersetzungen , manche von diesen Prozessen , von der einen Sprache in die andere Sprache zu übersetzen , sind sehr regelhaft sehr linguistisch . Dazu gehört sowas wie Formen behandeln . Wenn ich also suche nach Lebensversicherungen und im Dokument steht Lebensversicherung , dann kann man das regelhaft abbilden . Und im Dokument steht Lebensversicherung , dann kann man das regelhaft abbilden . Dann kann ich einfach sagen okay , sowohl in der Anfragesprache als auch in der Dokumentensprache übersetze ich immer implizit in die Grundform .

Johannes Stiehler 8:17

Dann steht auf beiden Seiten Lebensversicherung , und es gibt ein Match . Es kann aber auch sein , dass ich nach Lebensversicherung suche , und das Dokument spricht von Risikolebensversicherung . Im Deutschen ist es unseligerweise auch ein Wort . Das heißt , da muss ich schon weitergehen , da muss ich eine sogenannte Composite-Behandlung einführen und sagen okay , ich zerlege diese Wörter In Risikolebensversicherung , zerlege ich in Risiko , leben und Versicherung .

Johannes Stiehler 8:38

Zum Beispiel Meine Anfrage Lebensversicherung zerlege ich in Leben und Versicherung , und dann matchen zwei von zwei Termen in diesem Dokument Risikolebensversicherung . Auch das ist noch relativ simpel . Zugegeben , viele machen schon diese Basics falsch Auf vielen Portalsuchungen . Ich will jetzt gar keine Namen nennen , aber wir haben kürzlich erst auf YouTube ein Video veröffentlicht , wo wir eine Suche getestet haben . Wenn ich da suche nach irgendwelchen ganz banalen Dingen , kriege ich Matches , die beweisen , dass diese einfachen Sachen nicht umgesetzt wurden . Aber oft dort , wo es interessant wird , sind diese Übersetzungen super fachspezifisch .

Johannes Stiehler 9:13

Zum Beispiel , den Java-Entwickler zu übersetzen in seine Unterbegriffe J2E-Entwickler , spring-entwickler , meinetwegen auch Kotlin-Entwickler , was irgendwie mehr so ein Parallelbegriff ist , das erfordert Wissen über eine Fachdomäne , nämlich über die Domäne der Stellenbezeichnungen im Umfeld von Programmierungen . Das Gleiche gilt für Anfragen , die situativ sind , auf Versicherungsportalen zum Beispiel . Es gibt ja im Portfolio fast jeder Versicherung eine Reiserücktrittskostenversicherung . Die kann ich abschließen , wenn ich eine Reise buche , um mich abzusichern gegenüber unerwarteten Hinderungsgründen , die mich davon abhalten , diese Reise anzutreten .

Johannes Stiehler 9:50

Wenn ich auf einem Versicherungsportal zum Beispiel also eingebe krank vor Reise also was passiert , wenn ich krank werde vor der Reise , krank vor Reise , sagen wir mal , als Query , dann implizit will ich auf einem Versicherungsportal Ergebnisse anzeigen zum Begriff Reiserücktrittskostenversicherung , ein Begriff , der in dieser Abfrage gar nicht vorkommt . Wenn ich aber auf einem Reiseveranstalterportal suche nach Krankvorreise , dann suche ich wahrscheinlich nicht nach Reiserücktrittskostenversicherung , sondern ich suche nach Stornierungsbedingungen . Auch da ist der Begriff Krankvorreise oder die Phrase Krankvorreise nicht unbedingt auf der Seite vorhanden , aber der implizite Wunsch des Nutzers ist , hier Stornierungsbedingungen zu finden . Wenn ich auf einem allgemeinen Gesundheitsportal danach suche , dann interessiert mich vielleicht , mit welchen Infektionen ich auf keinen Fall fliegen darf .

Johannes Stiehler 10:36

Das hört sich total weit hergeholt an , aber wenn man sich selbst mal beobachtet , merkt man , dass man selber , auch wenn man Suchen benutzt , total oft Annahmen darüber macht , wie Queries , wie Abfragen interpretiert werden von der Suchmaschine , und ganz oft erwischt man sich dann dabei , wenn man versucht , sich bewusst zu machen , was man da gerade gesucht hat , dass man schon von so einer Suchmaschine sehr viel Wissen über den eigenen Kontext und über den eigenen Hintergrund erwartet . Das ist natürlich wirklich herausfordernd und schwierig , und letzten Endes das korrekt umzusetzen , lässt sich nur eigentlich erreichen , indem ich wahnsinnig viel darüber lerne , wonach meine Nutzer auf meinem Portal suchen , das heißt , wenn ich wahnsinnig viel die Abfragelogs anschaue , was suchen Nutzer wirklich in meinem Suchfeld ? Das Lustige ist bei vielen Prospects , mit denen wir reden , wo wir sagen hey , dann lasst uns doch mal zusammen aufs Quilllog schauen , auf die Abfragen , die auf dem Portal so ankommen , stellen wir fest , dass ich würde sagen , konservativ geschätzt drei Viertel dieser Prospects gar nicht ein Query-Log schreiben , ein vollständiges . Manche haben ein Google-Pixel . Da kommt man dann an die letzten 500 oder die häufigsten 500 Queries ran . Das mag reichen , mag aber auch nicht reichen .

Johannes Stiehler 11:51

Man kommt natürlich über die Hintertour auch an alle anderen ran , aber die meisten schauen nur die häufigsten 500 an . Es kann aber durchaus sein , dass ein Großteil , der größte Teil der Abfragen tatsächlich nicht in den Top 500 ist , sondern dass es ganz , ganz viele Abfragen gibt , die selten mit ein oder zwei Instanzen vorkommen , und die muss ich dann schon auch irgendwie anschauen und zusammenfassen und sinnvoll behandeln . Also eine Analyse des Abfrage-Logs ist eigentlich der sicherste Weg , um zu lernen , was Leute wirklich von meiner Suche erwarten . Und es ist interessanterweise und das kann ich eigentlich gar nicht deutlich genug betonen es ist auch eigentlich der beste Weg zu lernen , was meine Nutzer überhaupt von meinem Portal erwarten , oder zumindest von manchen Viel Usability-Testing betrieben . Es wird verpixelt , es wird geschaut wie ist die Customer Journey ? Wie geht der von der einen Seite auf die andere ? Geht er in die Antragsstrecke , füllt er das aus , bricht er da ab , lässt er einen Warenkorb zurück Und so weiter und so fort .

Johannes Stiehler 12:49

Alles in dem Versuch , möglichst viel zu verstehen über dass die Suche , das Suchfeld , der eine Ort ist auf einem Portal oder auch in einer internen Enterprise-Suchumgebung , in einem Document-Management-System , was auch immer man da anschauen will , wo Nutzer mir direkt wörtlich sagen , was sie von mir erwarten , wörtlich sagen , was sie von mir erwarten . Es ist die eine Sache , zu sagen hey , ich gebe euch mal einen Button , und mit diesem Button kommt ihr direkt zur Reise-Rücktrittskostenversicherung , und wenn da viel draufgeklickt wird , gehe ich davon aus , dass das einfach viel Interesse erzeugt . Es ist eine ganz andere Sache , ein Suchfeld zu haben und dieses Suchfeld auch prominent zu spielen , sodass es verwendet wird . Weil dort sagen mir die Leute suche ich nach Reiserücktrittskostenversicherung , oder suche ich nach Risikolebensversicherung , oder suche ich eher nach ganz anderen Dingen Hier ? dieses Suchfeld für mich widerspricht , wenn ihr das anders seht .

Johannes Stiehler 13:45

Aber für mich war das Suchfeld immer der eine Ort in einem Portal , wo man tatsächlich eine echte , sozusagen einseitige Konversation mit seinem Nutzer hat , wo tatsächlich ein Nutzer einem freiwillig Informationen darüber gibt , was er von meinem Portal erwartet . Und gerade da besteht dann natürlich die Chance , es besser als Google zu machen , weil hier kann man jetzt anschauen was will ein Nutzer spezifisch auf meinem Portal ? Das heißt , potenziell ist das natürlich auch etwas , wofür man SEO machen möchte , dann im Nachgang . Aber es ist auch etwas , wo man verstehen kann , was wird hier eigentlich gesucht , was wird hier versucht vom Nutzer , und wie kann ich dem Nutzer damit entgegenkommen ?

Johannes Stiehler 14:27

Und das komme ich , indem ich seine Anfragesprache in meine Portal-Inhaltssprache übersetze , entweder indem ich meine Texte umschreibe . Das kann man natürlich auch machen , dass sie näher an der Sprache der Nutzer sind . Das würde man sich bei vielen gerade Produktportalen wünschen , dass die mehr die Sprache der Nutzer reden und viel , viel weniger die Sprache derer , die diese Produkte erstellen , oder aber , dass ich die Suche so implementiere , dass sie diese Übersetzung für mich vornimmt , nicht eine syntaktische , eine tokenbasierte Suche , sondern eigentlich wollen wir eine Suche , die semantisch ist , das heißt , wo die Bedeutung der Query die Bedeutung im Dokument trifft oder die Bedeutung in den Portalinhalten trifft , und nicht die oberflächliche Repräsentation dieser Semantik . Das heißt , wenn ich Java-Entwickler suche , dann möchte ich auch J2E-Engineer treffen . Wenn ich Süddeutschland suche , möchte ich auch München treffen . Die Semantik zählt , die Bedeutung .

Johannes Stiehler 15:22

In letzter Zeit hat sich in der Hinsicht auch viel getan . Ich meine , früher mussten wir Semantik zum Teil immer noch . So mussten wir Semantik sehr manuell machen , mit Pflege von Synonymlisten , pflege von Ontologien , die tatsächlich semantische Beziehungen abbilden . Durch die Entwicklung im Bereich von Large Language Models gibt es jetzt quasi als Abfallprodukt sehr , sehr qualitativ hochwertige semantische Embeddings . Das bedeutet letzten Endes mathematische Repräsentationen von Bedeutung , die man direkt aus Wörtern erzeugen kann . Die sind nicht immer total präzise und total korrekt , aber die haben uns deutlich näher an das Thema semantische Suche rangebracht , als wir vorher je waren . Das Problem ist nicht völlig gelöst . Also ja , java-entwicklung in Süddeutschland kriegt man damit nicht vollständig expandiert , aber es ist deutlich näher an einem Matchen von Bedeutung zu Bedeutung , als wir das in der Vergangenheit

Suche Und Generative KI Synergieren

Johannes Stiehler 16:12

waren .

Johannes Stiehler 16:12

Die Voraussetzung dafür , dass das funktioniert , ist auf der anderen Seite , dass die Abfragen relativ lang sind . Also , kurze Abfragen mit Semantic Embeddings , mit Vektoren zu behandeln , ist meistens sehr , sehr unpräzise , und dann bekommt man sehr , sehr viel unrelevanten Quark . Aber für zum Beispiel Textabschnitte versus Textabschnitte funktioniert das hervorragend . Das Lustige ist ja Suche , also Dinge zu finden , dokumente zu finden auf Basis von Abfragen , würde heutzutage gar niemand mehr KI nennen . Früher war das anders . Gerade semantische Suche mit Synonymen und so weiter hat man schon eher unter künstliche Intelligenz subsumiert . Aber KI-nahe Technologien , die Technologien , die jetzt zum Beispiel aus der generativen KI rausfallen , die können uns tatsächlich näher an eine Suche bringen , die tatsächlich nutzerorientiert ist , die diese Übersetzungsleistung abbildet von Portalsprache , von Inhaltsspr . Meisten Implementierungen , produktiven Implementierungen von KI , von generativer KI auch immer eine Suchkomponente haben . Das ist eigentlich meistens Retrievable Augmented Generation in irgendeiner Form . Das heißt , da spielt Suche immer auch eine Rolle mit . Das heißt , das sind zwei Felder , die sich enorm gegenseitig unterstützen können und unterstützen . Und gerade in dieser Zusammenarbeit zwischen Suche und generativer KI liegen meiner Meinung nach die wertvollsten Anwendungsfälle verborgen .

Johannes Stiehler 17:47

Das war digitale Wissenswissen . Bleib dran , um mehr über Trends und Technologien und deren praktischen Nutzen für dein Unternehmen zu erfahren . Danke fürs Zuhören und bis zur nächsten Episode .