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 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.