#118 Wie funktioniert eine moderne Suche? Von Indexierung bis Ranking

Explain my like i am five: Die Grundlagen moderner Suchen

Wir, als User, erwarten heutzutage ziemlich viel von einer Suchmaschine. Es soll “magisch” verstehen, was wir eigentlich finden möchten. Egal ob wir das richtige Wort dafür nutzen (aka Synonym-Suche) oder ob der Begriff einen Tippfehler hat (aka “Meinten Sie …?”).

Oft werden Tools wie Elastic- oder OpenSearch, Solr, Algolia und Co. für sowas eingesetzt, denn eine einfache Volltext-Suche mittels eines Wildcard-SQL-SELECT Statement reicht dafür nicht mehr aus. Doch was steckt eigentlich dahinter? Wie funktionieren all diese modernen Suchen eigentlich im Inneren? In dieser Episode geht es um die Grundlagen moderner Suchmaschinen. Wir schmeißen mit Begriffen wie Stemming, Homonyme, BERT, Stopwords, Inverted Index, Suffixbäume, N-Grams, Term Frequency-Inverse Document Frequency, Vector Space Model und Co um uns und erklären das ganze im “Explain me Like I am five”-Stil.

Bonus: Wie Konzepte des Information Retrieval mit Bälle-Bädern erklärt werden.

**** Diese Episode wird von der HANDELSBLATT MEDIA GROUP gesponsert.

Wirtschaft ist nicht immer einfach. Deswegen lautet die Mission der HANDELSBLATT MEDIA GROUP: „Wir möchten Menschen befähigen, die Wirtschaft zu verstehen.“ Mit ihren Kernprodukten, dem Handelsblatt und der WirtschaftsWoche, sowie 160.000 Abonnements, 15 Millionen Besuchern und 3 Milliarden Anfragen in einem Monat leisten sie einen wichtigen Beitrag zur Orientierung und Meinungsbildung in den Bereichen Wirtschaft und Politik und machen damit einen ausgezeichneten Job.

Wenn du Teil dieser Mission sein möchtest, schau auf https://engineeringkiosk.dev/handelsblatt vorbei und werde ein Teil der HANDELSBLATT MEDIA GROUP.

********

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Buzzword-Bingo bei modernen Suchen

(00:04:40) Die Komplexität moderner Such-Systeme

(00:05:55) Die Handelsblatt Media Group (Werbung)

(00:07:00) Die Komplexität moderner Such-Systeme

(00:09:58) Wie funktioniert High-Level eine Suchmaschine?

(00:11:04) Verarbeitung der Such-Daten durch Tokens: Sprache, Stop-Words, Lemmatisierung, Stemming

(00:20:53) Zahlen als Such-Wörter, Embeddings und Bidirektionale Encoder-Repräsentationen von Transformers (BERT)

(00:29:34) Speichern der Daten mit einem Index: Invertierter Index und Suffixbäume

(00:43:07) Daten wirklich finden durchs Ranking: N-Grams, TF/IDFrequency und Vector Space Model

(00:59:54) Wie wählt man ein gutes Such-System aus?

(01:04:20) Wie beeinflusst Generative AI die aktuellen Suchsysteme und Sucht-Grundlagen?

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Email: stehtisch@engineeringkiosk.dev
LinkedIn: https://www.linkedin.com/company/engineering-kiosk/
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:02 - 00:00:07)

Wenn du in dem Suchfeld oben in dem Online-Supermarkt Erdbeere eingibst, Andi, was würdest du dir erwarten?

Andy Grunwald (00:00:07 - 00:00:09)

Die Fruchterdbeere. 500 Gramm.

Wolfi Gassler (00:00:09 - 00:00:37)

Zum Beispiel. Was aber garantiert kommt, sind wahrscheinlich irgendwie die Haribo-Erdbeeren, weil da unten eine extrem lange Liste dranhängt. Das heißt, in dem ganzen Dokument kommt irgendwie 18 Mal Erdbeere vor. Aber deine 500 Gramm Tasse Erdbeere, da kommt Erdbeere nur einmal vor, dieses Wort. Das heißt, es wird komplett schlecht gerankt und davor kommt die Erdbeerschokolade, das Erdbeerjoghurt und die tiefgekühlten Erdbeeren und weiß was ich weiß alles. Also das sind eigentlich schon recht komplexe Anforderungen.

Andy Grunwald (00:00:41 - 00:02:17)

Wir als User erwarten heutzutage ziemlich viel von einer Suchmaschine. Es soll magisch verstehen, was wir eigentlich finden möchten. Egal, ob wir das richtige Wort dafür nutzen, Stichwort Synonymsuche, oder ob der Begriff einen Tippfehler hat, Stichwort meinten Sie? Oft werden Tools wie Elastic und OpenSearch, Solr, Algolia und Co. für sowas eingesetzt. Denn eine einfache Volltextsuche mittels eines Wildcard SQL Statements reicht dafür lange nicht mehr aus. Doch was steckt eigentlich dahinter? Wie funktionieren all diese modernen Suchen eigentlich im Inneren? In dieser Episode geht es um Grundlagen moderner Suchmaschinen. Wir schmeißen mit Begriffen wie Stemming, Homonyme, Baird, Stopwords, Inverted Index, Suffixbäume, N-Grams, Term Frequency, Inverse Document Frequency, dem Backdoor Space Model und weiteren Buzzwords um uns und erklären das Ganze in einem Explain-Me-Like-I'm-Five-Stil. Wir springen direkt rein, viel Spaß, los geht's! Vor wenigen Tagen ist wieder was seltenes in der Tech-Szene passiert. Und zwar gab es wieder einen Börsengang. Und zwar der Börsengang von einer Plattform, die jeder kennt, und zwar Reddit. Und jetzt kann man über Reddit denken, was man möchte. Dafür passiert sehr wahrscheinlich ziemlich viel Schmuh auch auf dieser Plattform. Natürlich ab und zu mal so Dinger, die es auch bis in die Tagesschau schaffen, wie zum Beispiel die GameStop-Aktie bei WallStreetBets. Was man Reddit aber nicht abreden kann, ist, dass diese Plattform sehr faszinierend ist, durch diese ganzen Subreddits. Und es gibt einen Subreddit, den finde ich immer sehr, sehr spannend und da verbringe ich ab und zu auch mal Zeit drin, wenn mir sehr langweilig ist und der heißt...

Wolfi Gassler (00:02:17 - 00:02:20)

Die Sta... Mauersteinwetten.

Andy Grunwald (00:02:20 - 00:04:21)

Mauerstein-Wetten. Mauerstein-Wetten für die Leute, die es nicht kennen, ist das deutsche Wall-Street-Bets. Geht da mal rein. Auch ein paar lustige Storys. Aber ich rede vom Subreddit explainmelikeim5. Und explainmelikeim5, das Tolle daran ist, du kannst da alles fragen und dir wird es von Leuten erklärt, die anscheinend sehr viel Ahnung haben, als wärst du eine Fünfjährige. Und genau das machen wir heute. Denn, da freue ich mich auch so ein bisschen drauf, Die Informatik und die Softwareentwicklung ist ein Riesenfeld und man kann sich einfach nicht mit allem beschäftigen. Und irgendwie gibt's bei Wolfgang und mir in unserer Podcastbeziehung ja auch was Positives, denn man sagt ja immer, man soll sich einen Partner suchen, der einen ergänzt. Und das, was Wolfgang studiert hat, beziehungsweise wo drin er seinen akademischen Titel, seinen Doktortitel gemacht hat in der Doktorarbeit, ist das Feld der Recommender Systems. Recommender Systems, andere Buzzwords gibt es auch, sowas wie Information Retrieval und all das hat sowas mit Suchen zu tun. Suchen aka die Google Suche. Und warum ich davon keine Ahnung habe, erkläre ich euch ganz kurz. Ich habe in einer Software Agentur gelernt und habe da sehr viel mit MySQL und PHP gearbeitet. Und wenn man von Suche und MySQL spricht, dann spricht man meist von Ajax Autocomplete Feldern, also zumindest vor zehn Jahren. Und das sieht wie folgt aus. Select Sternchen from Tabelle, von der ich suchen möchte. Where fällt like Prozentzeichen Wort Prozentzeichen. Und für alle Leute, die schon mal eine solche AKA-Volltextsuche geschrieben haben, die können eigentlich einen Stopp auf ihrem iPhone starten, bis der Kunde anruft und fragt, ja, aber warum funktioniert das nicht so wie Google? Und heute nehme ich Dr. Wolfgang Gassler als meinen Explain-Me-Like-I'm-Five-Experten und lasse mir Suchgrundlagen bzw. Grundlagen von modernen Suchmaschinen erklären. Und darunter fallen Buzzwords wie Natural Language Processing, Stemming, Stopwörter, vielleicht sogar das Suchen in unstrukturierten Daten.

Wolfi Gassler (00:04:21 - 00:04:21)

Merkste?

Andy Grunwald (00:04:22 - 00:04:23)

Da hört es schon bei mir auf.

Wolfi Gassler (00:04:24 - 00:04:29)

Das ist alles, was du noch so rausbekommen hast aus dem Thema, oder? Stemming und NLP ist immer gut.

Andy Grunwald (00:04:30 - 00:04:32)

Wolfgang, wie fühlst du dich als Lehrer?

Wolfi Gassler (00:04:32 - 00:04:40)

Ich wollte gerade sagen in einer ungewohnten Rolle, aber eigentlich bin ich ja auf der lehrenden Seite auch groß geworden an der Uni. Was eher ungewöhnlich ist, dass du mir mal zuhörst.

Andy Grunwald (00:04:40 - 00:05:06)

Ich versuche mich in dieser Episode ein bisschen zurückzuhalten, zumindest von der zeitlichen Komponente beim Sprechen. Aber sprechen wir mal kurz Dacheles. Wenn man heutzutage von Suchen spricht, dann kommen bei mir die Buzzwords Elasticsearch, OpenSearch, Algolia, Solar, Lucene in den Sinn. Das sind zumindest so die Systeme, die ich mit Volltextsuchen heutzutage eigentlich so in Verbindung setze. Bin ich da auf dem richtigen Track?

Wolfi Gassler (00:05:07 - 00:05:25)

Du hast schön die Hierarchie auch schon dargestellt, weil Lucien ist ganz unten und die anderen setzen ganz gern auf Lucien aus. Also Lucien ist so der Klassiker in der ganzen Welt. der aber auch nur natürlich Basisalgorithmen oder ganz klassische Algorithmen aus der Suchwelt und aus der Information-Retrieval-Welt verwendet.

Andy Grunwald (00:05:25 - 00:05:54)

Mein Ziel für diese Episode ist, dass Leute, die eine Suche bauen wollen, beziehungsweise vielleicht sogar schon Elasticsearch, OpenSearch, Lucene, Solr und Co. im Einsatz haben, dass die ein bisschen die Grundlagen verstehen, wenn es mal Probleme gibt. Denn immer wenn so ein System komische Worte ausspuckt, Dann werden ja meist die Entwickler zur Kasse gebeten und sagen, kannst du mir das mal bitte erklären? Warum findet er denn dieses Wort und warum rankt er das denn jetzt höher? Meinst du, du schaffst das, Wolfgang?

Wolfi Gassler (00:05:54 - 00:07:20)

Wir können es zumindestens probieren. Aber du hast natürlich vollkommen recht. Mit dem Like-Prozentzeichen fängt alles an und viele werden sich jetzt vielleicht denken, ah, die Suche, eigentlich ist es ja gar nicht so schwierig. Ich knall da irgendwie ein Like-Suchbegriffstern drauf oder halt die Prozentzeichen in SQL und das funktioniert dann schon. Aber wenn man sich dann mal so überlegt, was nicht möglich ist, beziehungsweise was sehr schnell zu Problemen führt, Wenn du nur denkst an das Wort E-Mail und du suchst nach Mail, ganz geschweige denn davon, dass es dann vielleicht extrem langsam ist, wenn du danach suchst. Was so Sachen ist mit Wörtern, die zusammengesetzt sind. Hochgeschwindigkeitszug zum Beispiel. Findest du den, wenn du dann Zug suchst? Was ist mit Zahlen? Wenn du nach 100.000 suchst, musst du das dann als Zahl eingeben, als String eingeben. Was ist, wenn du irgendwo deine IP-Adresse gespeichert hast in Logfiles und du nach der IP-Adresse suchst? Funktioniert das dann mit den klassischen Pattern? Also man kommt sehr schnell an die Grenzen und da ist es dann interessant, wirklich mal in die Tiefe zu gehen und sich überlegen, was sind da eigentlich die Grundlagen? Was sind die Algorithmen, die dahinterstecken? Wie funktioniert denn Suche überhaupt? Man kommt an diese Grenzen und dann ist es natürlich gut, wenn man versteht, was da im Hintergrund abläuft, hinter so einem simplen Like oder hinter einer Elasticsearch, warum das nicht geht oder warum das da vielleicht auch nur Probleme macht. Und da bin ich jetzt noch gar nicht bei der ganzen Welt zum Beispiel, dass du wahrscheinlich keine Ahnung hast, wenn ich in einem Online-Supermarkt zum Beispiel nach Paradeiser suche und du den implementiert hast, was ich eigentlich gerne rauskriegen wollen würde.

Andy Grunwald (00:08:26 - 00:08:36)

Erstes Bauchgefühl, ein Parasiten, aber ich weiß nicht, warum du bei einem Online-Supermarkt ein Parasiten suchen würdest. Moment mal, ihr habt ganz viele unterschiedliche Wörter für Pfannkuchen.

Wolfi Gassler (00:08:36 - 00:08:46)

Ist das ein Pfannkuchen? Fast. Also ich muss zugeben, es ist nicht tirolerisch, sondern es ist wienerisch, aber im Osten von Österreich sagt man zu Tomaten Paradeiser.

Andy Grunwald (00:08:46 - 00:08:49)

Pfannkuchen und Tomaten ist halt schon ein bisschen was anderes, aber...

Wolfi Gassler (00:08:50 - 00:09:58)

Es ist schon weit weg. Also über die Probleme sprechen wir jetzt noch gar nicht. Die sind ja auf algorithmischer Ebene vielleicht weniger leicht zu lösen, sind aber in der Realität auch ein großes Problem, wenn es um Suche geht. Aber um mal zurückzukommen auf deinen Explain Me Like I'm Five, Ist sehr schön. Ich habe mir den gerade vorgestellt in dem großen Bällebad, weil wir hatten mal an der Uni, wie wir probiert haben bei der Langen Nacht der Forschung, beziehungsweise bei so einem ähnlichen Event, wo ganz junge Kinder auch kommen und man denen die Wissenschaft näher bringen soll, haben wir probiert, Suchmaschinen zu erklären. Und da haben wir einfach ein riesiges Bällebad aufgebaut, haben uns da billige Plastikbälle gekauft und so ein auflassbares Pool und haben dann die Kinder einfach tauchen lassen in diesem Bällebad, um die richtige Kugel zu finden, wo eine Zahl oben steht. Und damit es auch spannender wird, haben wir parallel die Eltern auf Google suchen lassen. Das heißt, die Eltern haben auf Google irgendeine Frage suchen müssen, also die Antwort besser gesagt. Und die Kinder haben derweil die Bälle gesucht, wo die Antwort oben steht. Und dann haben wir gecheckt, wer schneller ist. Funfact, die Kinder waren immer schneller, obwohl da tausende Bälle drin waren. Ist mir immer noch unerklärlich, wie die den einen orangen Ball mit der 37 gefunden haben. Spektakulär.

Andy Grunwald (00:09:58 - 00:10:10)

Kommen wir mal von deinem Traum des Bällebads weg und fangen wir mal an. Wenn ich jetzt mal ganz blauäugig an so ein System rangehen würde, also wie funktioniert high level so eine Suchmaschine?

Wolfi Gassler (00:10:10 - 00:11:04)

Also im Prinzip gibt es drei große Bereiche. Du steckst einmal was in die Suchmaschine, in das Bällebad hinein. Du musst mal die Bälle einfüllen. Dann musst du sie irgendwie intelligent speichern, damit du eben nicht das gesamte Bällebad immer durchsuchen musst mit deinen Bällen, damit du schnell bist. Und du musst am Ende, wenn du viele Bälle rausbekommst, musst du vielleicht entscheiden, was ist der richtige Ball. Das heißt, du hast so drei Bereiche. Einmal die Verarbeitung der Daten und das Ablegen, wie du sie dann intelligent ablegst, mit einem Index zum Beispiel, damit du schneller dann findest und am Ende dann das Ranking machst, wenn du 1000 Webseiten findest, dass du dann sagst, okay, die 10 wichtigsten Webseiten, die jetzt genau für dich wichtig sind, da nochmal ein Ranking drauf zu machen. Also reinlegen und das raussuchen und das sinnvolle Abspeichern. Das sind so die drei großen Blöcke, die man eigentlich bei einem Suchsystem oder ganz allgemein Information Retrieval, also wenn man irgendwo Informationen rausbekommen will aus großen Datenmengen, eigentlich hat.

Andy Grunwald (00:11:04 - 00:11:16)

Okay, bleiben wir mal bei der Analogie des Bällebads. Ich habe eine große Wanne und da müssen Bälle rein. Technisch gesehen ist meine Wanne eigentlich meine Art Datenbank und meine Bälle eigentlich meine Dokumente.

Wolfi Gassler (00:11:16 - 00:11:25)

Ja, es kommt darauf an, also je nachdem, da fängt es sich schon an, wie zerstückelst du deine Dokumente oder deine Daten, weil du hast jetzt vielleicht Dokumente.

Andy Grunwald (00:11:25 - 00:11:28)

Muss ich die denn zerstückeln? Weil ich hätte jetzt gesagt, ein Ball ist ein Dokument.

Wolfi Gassler (00:11:28 - 00:12:13)

Das ist die Frage, nach was du dann suchen willst. Willst du jetzt nur nach dem Titel suchen, nach dem Dateinamen von deinem Dokument, nach dem Word-Dokument? oder willst du eine Volltextsuche, dass du den Inhalt durchsuchst und je nachdem musst du das natürlich anders ablegen. Wenn der Inhalt irrelevant ist und du immer nur nach den Dateinamen suchst, dann kannst du das natürlich rein dateinamenbasiert ablegen und brauchst den Inhalt gar nicht irgendwie verarbeiten oder angreifen. Wenn du natürlich Volltextsuche machen willst, musst du die ganzen Wörter in den Dokumenten verarbeiten und dann sinnvoll ablegen. Du brauchst das natürlich nicht unbedingt, du kannst auch einfach ein Grab über alles machen, das ist halt dann einfach langsam, weil wenn du ein paar Terabyte an Daten hast und ein Grab drüber machst und durch alle Daten durchläufst, um dieses Dokument zu suchen, wo Andy Grundwald drin vorkommt, wird es eine gewisse Zeit dauern.

Andy Grunwald (00:12:14 - 00:12:16)

Okay, was ist denn, wenn ich das jetzt noch nicht weiß?

Wolfi Gassler (00:12:16 - 00:12:27)

Also ich habe jetzt... Dann hast du ein Problem. Du musst im Vorhinein schon wissen, was du am Ende erreichen willst, sonst wird es schwierig. Also jetzt musst du dir am Anfang schon mal überlegen, wie sieht meine Suche aus, nach was will ich eigentlich suchen können?

Andy Grunwald (00:12:27 - 00:12:42)

Naja, nehmen wir mal Google. Google sucht ja auch den Webseiten-Titel und den Webseiten-Body. Und die stellen mir das ja auch da und die sagen vielleicht noch, okay, wenn ich ein Wort im Webseiten-Titel treffe, dann ist das vielleicht besser, als wenn ich ein Wort im Webseiten-Body treffe.

Wolfi Gassler (00:12:42 - 00:13:15)

Ich habe natürlich keine Ahnung, wie Google intern funktioniert, aber grundsätzlich ganz allgemein Suchsysteme, Informational Retrieval Systeme funktionieren alle sehr ähnlich. Das heißt, ich muss als erstes mal die Inhalte, die ich suchen will, die ich durchsuchen will, die Webseiten in dem Fall, zerstückeln in kleinere Bereiche, üblicherweise Wörter, weil du suchst ja am Ende deine Query, da suchst du nach Wörtern. Und du wirst natürlich nicht nur den Webseitentitel durchsuchen, sondern du wirst Andi Grunwald auch finden, wenn der irgendwo in einem Podcast Transcript irgendwo erwähnt wird. Das heißt, du brauchst den gesamten Text.

Andy Grunwald (00:13:15 - 00:13:23)

Muss ich die Zerstücklung machen oder kann ich diesen Balk an Text einfach an das Suchsystem schmeißen und sage, speichere das?

Wolfi Gassler (00:13:23 - 00:14:31)

Natürlich, das Suchsystem an sich kann das natürlich, aber was das Suchsystem im Hintergrund macht, ist eine Dokainisierung, nennt sich das. Das heißt, das Dokument oder die Datei oder alle Daten, was du hast, ganz egal, in kleine Stücke zu zerlegen, in Tokens. Seit JetJPG kennen alle irgendwie Tokens, weil da gibt es diese berühmte Token-Limitierung und jeder sagt, das ist sowas ähnliches wie Wörter, aber nicht wirklich oder es sind so eineinhalb Wörter ungefähr oder beziehungsweise ein Wort hat eineinhalb Tokens. So als Hausnummer oder 1,3 und im Prinzip ist es genau das, dass halt die Wörter zerlegt werden in Tokens und wenn man da wieder das Beispiel von zuerst nimmt, was ich schon erwähnt habe mit dem Hochgeschwindigkeitszug, dann wird der Hochgeschwindigkeitszug wahrscheinlich in mehrere Tokens zerlegt und ist nicht nur ein Wort und darum sind so lange Wörter unter Umständen mehrere Tokens. Aber man kann der Einfachheit halber sagen, man zerlegt einfach mal die Dokumente in Wörter und lasst da die Leerzeichen weg, die Kommas, die Bindestriche, die Slashes, was es auch immer sind, die lasst man mal weg, die sind unwichtig für Suchen und man zerlegt so die Datei und wandelt die in Tokens um.

Andy Grunwald (00:14:31 - 00:14:49)

Eine Zwischenfrage, du sagst grad, die Satzzeichen und Fragezeichen, Ausrufezeichen werden weggelassen. Das bedeutet auch, es geht wirklich nur um die einzelnen Worte, aber nicht um den Kontext der Wörter, ob die jetzt innerhalb einer Frage sind oder innerhalb eines aggressiv gesprochenen Satzes, wenn da ein Ausrufezeichen ist. Ist das richtig?

Wolfi Gassler (00:14:49 - 00:16:07)

Wenn man mal die modernen Technologien wie Embeddings, die jetzt irgendwo in der ganzen KI, AI, Machine Learning Welt unterwegs sind, NLP, Wenn man die mal weglässt und das klassische Information Retrieval betrachtet, dann verliert man da den Kontext und es wird sogar so weit eigentlich vereinfacht, dass man zum Beispiel auch Fälle auf eine Grundform reduziert. Das ist dieses Stemming, das du auch schon erwähnt hast, dass man wirklich sagt, okay, wenn du jetzt Tische hast, dann wandelst du das um zum Token Tisch, weil du willst eigentlich nur die Information haben, Tisch kommt in diesem Dokument vor und es ist eigentlich unwichtig, ob es Tische sind, Mehrzahl oder Einzahl. Oder wenn du irgendwelche Verben hast, dann werden die auf die Grundform zurückgeführt. Also es wird so ein Stemming betrieben, beziehungsweise in dem Zusammenhang gibt es auch die Lemmatisierung, Lemmatization genannt, die probiert dann noch intelligenter, was auf ein Wort zurückzuführen. Das könnte zum Beispiel sein, dass wenn da Paradieser drinsteht, das österreichische Wort für Tomaten, dass das dann auf Tomate umgeändert wird, auf das Token Tomate, damit du da auch einheitlich eine Information dahinter hast. Also Lemmatization macht schon mehr bezüglich der Bedeutung, hingegen Stemming ist ganz dumm, das wendet einfach nur ganz dumm Regeln an, grammatische Regeln, zum Beispiel Mehrzahl, Einzahl, solche Dinge.

Andy Grunwald (00:16:07 - 00:16:23)

Bei dem Lemmetization behält der dann, ich sag mal, das ursprüngliche, ich nenn's mal Synonym, Paradieser für Tomate jetzt? Oder speichert der dann nur Tomate und der vergisst, dass das original Paradieser oder Paradieser hieß? Wusstest du eigentlich, dass Paradieser eigentlich ein Kondom ist? Also ich mein, das ist für mich irgendwie so ein bisschen grad...

Wolfi Gassler (00:16:23 - 00:16:24)

Es ist nicht Barisa.

Andy Grunwald (00:16:25 - 00:16:34)

Stimmt. Er tappt richtig. Aber siehste, wie oft denkt eine männliche Person an Sex? Anscheinend des öfteren.

Wolfi Gassler (00:16:34 - 00:16:37)

Wir können auch Erdäpfel nehmen, ist auch kein Problem. Oder Kaffiol.

Andy Grunwald (00:16:37 - 00:16:39)

Aber wird das Synonym dann behalten?

Wolfi Gassler (00:16:40 - 00:17:15)

Also es kommt wirklich drauf an. Man kann Synonymlisten auch später pflegen, aber ganz oft wird es in dem Schritt auch gemacht. Das ist je nach Implementierung dann und Intelligenz von dem ganzen System oder ob das überhaupt angewandt wird. Also gibt es viele Möglichkeiten im speziellen Umfeld mit Spezialwörtern wird da vielleicht einfach in dem Dictionary, also in dem Wörterbuch, vielleicht werden da auch andere Sachen dann umgeformt. Also es kommt wirklich darauf an, aber die Grunddaten hast du natürlich sowieso immer gespeichert. Also du löscht dieses Dokument hier nicht. Aber es geht darum dann, wenn du den Index aufbaust, den baust du dann mit diesen Tokens auf.

Andy Grunwald (00:17:15 - 00:17:39)

Das bedeutet aber auch, das System, wo ich das dann reinschmeiße, also mein Bällebad, wo ich die Bälle gegenschmeiße, dieses system hat dann kenntnis in diesem fall der deutschen sprache und der österreichischen dialektsprache in diesem fall das bedeutet es gibt dieses system bringt dann irgendeine art paket mit wo es dann den plural von tisch hinterlegt hat und so weiter damit das alles halt weil sonst weiß ist das.

Wolfi Gassler (00:17:39 - 00:17:56)

Ja nicht also, Das musst du unter Umständen als User auch machen. Also du kannst zum Beispiel auch bei Elasticsearch Synonymlisten angeben, da kannst du dann eingeben, dass Killer Bitch auch irgendwie, was sind das eigentlich, Kräuterschnaps oder so, oder? Wie heißt sowas offiziell, ohne Markenbezeichnung?

Andy Grunwald (00:17:56 - 00:17:57)

Ja, ich würde schon sagen Kräuterschnaps, ja.

Wolfi Gassler (00:17:58 - 00:18:16)

Irgend so was in der Richtung, dann hast du die Übersetzung mit dabei, die musst du als User fast bringen, weil das kann das System natürlich nicht wissen. Ganz allgemeine Dinge natürlich aus der deutschen Sprache sind üblicherweise schon in irgendeiner Form drin, aber wenn du mit deinem Spezialwissen dazukommst, dann musst du das natürlich eingeben, was ist ein Paradeiser, was ist ein Erdäpfelkaffiol.

Andy Grunwald (00:18:17 - 00:18:25)

Das bedeutet, wenn ich jetzt eine spezialisierte Firma bin im Maschinenbau, dann muss ich mit hoher Wahrscheinlichkeit diese Wortlisten in irgendeiner Art und Weise in dieses System füttern.

Wolfi Gassler (00:18:25 - 00:19:02)

Genau, die gibst du einfach an als Datei, als Textdatei, als Mapping, was es dann auch immer ist und das brauchst du eigentlich fast bei jeder etwas komplexer in Suche, weil du hast immer mit irgendwelchen Spezialbegriffen eigentlich zu tun oder Synonymen, die du vielleicht brauchst. Abkürzungen sind auch so ein Klassiker. Also wenn ich da zurückdenke an meine Zeit bei Trivago, unsere Teams waren auch für die Suche verantwortlich und da hast du natürlich super viele Abkürzungen, die Flughafencodes, die DUS für Düsseldorf, solche Dinge, die Leute eingeben. Das sind natürlich alles Dinge, die das System von sich aus nicht verstehen kann und braucht natürlich die Zusatzinformation.

Andy Grunwald (00:19:02 - 00:19:38)

Ich kann mir schon gut vorstellen, dass das auch sehr sinnvolle Arbeit ist, je nachdem, was ich da betreibe. Nehme ich jetzt mal einen E-Commerce-Shop, ich sag mal, ziemlich viele Markennamen, da würde es ja schon Sinn machen, wenn ich dann halt diese, ich sag mal, in diesem Kontext Spezialanforderungen von, weiß ich nicht, Klamotten oder sowas und dann vielleicht sogar Produktnamen oder sowas da reinpacke, ne? Also ich meine, es gibt ja Sneaker, gibt ja T-Shirts, gibt ja halblange T-Shirts und so weiter. Ich weiß jetzt nicht, wie gut diese Wortlisten sind, kann man sich wahrscheinlich nachgucken, aber das bedeutet eigentlich auch, umso mehr ich meine spezialisierten Wortlisten pflege, desto bessere Suchergebnisse kann ich natürlich im Endeffekt auch liefern.

Wolfi Gassler (00:19:38 - 00:20:27)

Und vor allem, da sprechen wir überhaupt nicht von dem Suchsystem oder von der Technik oder Technologie. Das ist wirklich, was wir an Metainformationen zur Verfügung stellen. Und man braucht sich da nur einen Supermarkt zum Beispiel vorstellen. Das sind super komplexe Produkte, weil wenn da drin steht, das ist irgendwie 0,5 Liter irgendwie Frischkäse mit 20% Fett, dann suchen Leute vielleicht nach den Fettangaben, nach der Mengenangabe, nach dem 0,5 Liter oder halb Kilo. Und das sind so schwierig verarbeitbare Informationen, weil du kannst es als Einhalb eingeben, du kannst es an 0,5 angeben, du kannst Kilogramm angeben, du kannst Gramm angeben, du kannst Liter angeben, du kannst die Prozent Fett, die werden normal alle rausgefiltert. Also das sind super komplexe Dinge. Und da sprechen wir eben noch gar nicht von den Synonymen, dass der Frischkäse bei uns Topfen heißt oder so.

Andy Grunwald (00:20:27 - 00:20:28)

Topfen?

Wolfi Gassler (00:20:28 - 00:20:35)

Ja, ist eigentlich nicht ganz Frischkäse, ist was eigenes, aber... Quark ist noch am ähnlichsten eigentlich.

Andy Grunwald (00:20:35 - 00:20:38)

Wie sieht es denn mit Groß- und Kleinschreibung aus? Spielt die eine Rolle?

Wolfi Gassler (00:20:38 - 00:20:52)

Ja, die wird normal durch Stemming einfach entfernt. Also das ist dann eh das Einfachste, was wir an Stemming haben, dass wir einfach alles kleinschreiben natürlich. Alles in der Grundform, alles kleinschreiben, möglichst reduziert auf die pure Information, würde ich mal sagen.

Andy Grunwald (00:20:53 - 00:21:15)

Wie sieht es denn eigentlich mit Zahlen im generellen aus? Weil ich meine, es gibt ja ein paar Zahlen, die sind sehr speziell. Pi zum Beispiel. Ich kann das Pi-Zeichen da eingeben. Ich kann 3,14 eingeben. Ich kann Pi eingeben. Dann gibt es noch die E-Zahl. Die E-Zahl ist ja eigentlich ein Buchstabe in der Hinsicht. Wie wird sowas denn verwandelt, nennen wir es mal? Wie wird sowas zum Ball?

Wolfi Gassler (00:21:16 - 00:21:24)

Also ich glaube von allen Beispielen, die es so gibt, hast du dieses verwendet, was am unrealistischsten ist, weil wer sucht nach einem Pi-Zeichen? Ich wüsste nicht mal, wie ich das auf meiner Tastatur eingeben kann.

Andy Grunwald (00:21:27 - 00:21:31)

Ich hätte nach dem Pi-Zeichen gegoogelt und dann hätte ich das irgendwo kopiert. Also ja, geht mir auch so.

Wolfi Gassler (00:21:32 - 00:22:56)

Aber es ist an sich von der Herangehensweise ist es natürlich ein Problem, ganz klar. Man könnte das auch einen Schritt weiter machen. Was ist mit Chinesisch zum Beispiel? Bei Chinesisch hast du überhaupt nur Symbole oder Japanisch oder so Lautsprache eigentlich hast und Symbole dann. Also jede Sprache funktioniert anders und teilweise hast du eben nur ein Zeichen oder hast vielleicht auch keine Leerzeichen dazwischen. Das heißt, man muss dann anderes tokenisieren. Vielleicht jedes Zeichen ist ein Token. Und Pi ist dasselbe. Das ist eigentlich nur ein Synonym, aber halt wieder mit einem Zeichen. Pi ist relativ einfach zu mappen, würde ich mal sagen. Also das Zeichen an sich, weil das Symbol gibt sowieso eigentlich niemand ein und wenn, kann man das super easy matchen. Schwieriger wird es einfach mit anderen Dingen, die halt nicht so klar trennbar sind. Wenn da L steht, ist das jetzt Liter? Ist das wirklich die Abkürzung für Liter? Sucht jemand einfach nach allen Wörtern mit L. Also das ist dann wesentlich komplexer, dass man solche Dinge eigentlich versteht, würde ich mal sagen. Und das geht dann auch zum Beispiel weiter bei Homonyme. Das ist eigentlich das Gegenteil von Synonyme. Das ist sowas wie Bank, die Sitzbank oder Schloss, das Gebäude oder das Schlüssel, Schloss, Leiter, Kiefer, Steuer, also solche Wörter, die mehr bedeuten. Und da hast du natürlich dann das Problem, weil du ja keine Bedeutung kennst, wenn wir mal die Embeddings jetzt wegnehmen von NLP, dann hast du natürlich auch Schwierigkeiten, da die richtigen Dokumente zu finden.

Andy Grunwald (00:22:56 - 00:23:01)

Ich bin mir gar nicht sicher, ob die Embeddings wirklich eine Relevanz spielen für, ich sag mal, die klassische E-Commerce-Suche jetzt bei Zalando oder ähnliches.

Wolfi Gassler (00:23:01 - 00:23:50)

Ich glaube, es kommt langsam, weil du eben den Kontext mit reinnehmen kannst und weil es eigentlich schon relativ gut funktioniert, würde ich mal sagen. BERT ist so das klassische Modell, was es dort gibt und was recht einfach zu verwenden ist. Das nimmt eben auf gut Deutsch den Kontext links und rechts einfach mit, macht eben diese Embeddings und speichert dann eigentlich einen großen Vektor ab. Und da hast du dann eben den Kontext und die Bedeutung durch deine Umgebung mitgenommen. Und dann ist es relativ klar, wenn da Bank steht, ist es eine Bank, das Geldinstitut Bank oder ist es die Bark Bank. Und solche Informationen kannst du dann natürlich mitnehmen und das ist eigentlich auch Dokainisierung. Also wenn du das auf der Dokainisierung Seite machst, dass du diese Vektoren erstellst mit diesen Embeddings, dann hast du am Ende diese Vektoren und dann arbeitest du eben mit diesen Vektoren weiter, wie du sonst mit deinen Tokens weiterarbeitest.

Andy Grunwald (00:23:51 - 00:24:08)

Aber geht das also das bärt hört sich jetzt so ein bisschen an also das als wäre das auch so eine so ein bisschen so eine entitätserkennung ja also ist das jetzt ein ort oder ist das jetzt eine sache oder ähnliches weil du hast jetzt gerade bank gesagt und da klar sitzt bank und bank als finanzinstitut ist das ist das das gleiche oder verwechsel ich da was.

Wolfi Gassler (00:24:09 - 00:24:54)

Du könntest es so verstehen, aber du darfst natürlich nicht denken, dass da jetzt irgendwie ein Verständnis dahinter steckt, weil es ist eigentlich nur statistisch, was ist da außenrum, was ist das für ein Kontext. Aber du kannst davon natürlich noch nicht darauf schließen, dass das wirklich eine Bugbank ist. Aber durch den Kontext hast du dann natürlich, wenn du auch wieder danach suchst, vergleichst du die Kontexte und findest dann das Richtige. Aber da ist natürlich kein Verständnis dabei. Gleich wie Chatshippe, die ja eigentlich nichts versteht, sondern nur statistisch das nächstbeste Wort dann errechnet aus dem Kontext, ohne zu verstehen, dass das da jetzt die Barkbank ist. Aber es ist halt klar, durch den Kontext geht es irgendwie um solche Dinge und dann kommt halt ein Wort wie Bark dazu oder Wiese und dann ist es klar, dass es die Barkbank ist und nicht das Geldinstitut Bank.

Andy Grunwald (00:24:54 - 00:25:05)

Aber theoretisch könnte ich doch auch eine Wortliste hinterlegen, die sagt, okay, das sind alles wirklich Dinge in der realen Welt und das sind irgendwie alle Städte in Deutschland oder so, damit man weiß, dass es ein Ort ist. Also es wäre ja auch möglich, oder?

Wolfi Gassler (00:25:05 - 00:25:14)

Ja, wie machst du das bei Bank? Was machst du da mit deiner Liste, wenn da steht, Bank kann eine Bankbank sein oder eine Geldinstitutbank? Also das kannst du nur aus dem Kontext eigentlich herausfinden.

Andy Grunwald (00:25:14 - 00:25:50)

Vielleicht mach ich so ein zweistufiges System, dass ich erst in die Wortliste gucke, weil das wäre eine Hash-Map, das wäre jetzt schneller. Und wenn da steht, okay, das hat mehr als ein Ergebnis, hinter Bank steht dann Finanzinstitut und Parkbank zum Beispiel, also Count größer 1, dann schmeiße ich das BERT-System an, was dann den Look Back und Look Forward macht, weil das ist ja, ich gehe stark davon aus, dass es recht teuer ist bei der Indexierung, ähnlich wie bei diesem Look Ahead und Look Behind bei Regular Expressions, ist ja auch sehr teuer. Und so könnte ich vielleicht die Speicherung und Indexierung ein bisschen beschleunigen, dass ich nur das BERT-System anschmeiße, wenn ich es wirklich brauche.

Wolfi Gassler (00:25:51 - 00:26:59)

Also die Dokainisierung ist gar nicht so teuer, den Vektor zu erstellen, das geht eigentlich. Natürlich hast du, klar, ein Vektor, der sehr viele Einträge hat, ist natürlich per se teurer, als wenn du jetzt nur eine ID hast zur ID 18, die Bank repräsentiert. Hingegen im Vektor hast du halt keine Ahnung wie viele Float Values in so einem Vektor drin, je nach Modell. Und das braucht natürlich mehr Platz. Indexierung ist teurer, Suche ist teurer und so weiter. Darum ist ja JGPT auch so langsam. auch ein Grund dafür. Also teurer ist es. Zweistufiges System wäre eine Möglichkeit, glaube ich, macht es aber sehr viel komplexer, würde ich mal sagen. Es ist natürlich schon so, dass die Systeme gern kombiniert werden grundsätzlich, dass du eine Suche machst und dann vielleicht mit einem Sprachmodell weiterarbeitest oder umgekehrt. Aber jetzt in dem Schritt, würde ich mal sagen, du hast dann eher Zwei komplett getrennte Systeme, die du kombinierst und weniger, dass du innerhalb der einzelnen Schritte Indexierung, Dokkinisierung, Ranking, dass du da schon irgendwas mischt. Weil es einfach wesentlich komplexer ist und die Systeme halt nicht dafür ausgelegt sind.

Andy Grunwald (00:26:59 - 00:27:03)

Naja gut, also Stemming, Synonyme, Homonyme.

Wolfi Gassler (00:27:03 - 00:27:04)

Homonyme.

Andy Grunwald (00:27:05 - 00:27:26)

Homonyme, ja, schwieriges Wort für mich. BERT, ja. Bidirectional Encoding Representations from Transformers. Ich musste erst googeln, was das heißt. Und Achtung, nach BERT zu googeln, ist nicht geil. Die Sesamstraße lässt grüßen. Das ist ja schon ein komplexes, ein komplexer Indexierungsprozess. Aber noch eine Frage.

Wolfi Gassler (00:27:26 - 00:27:28)

Dokenisierungsprozess. Indexierung ist erst der nächste Schritt.

Andy Grunwald (00:27:29 - 00:28:01)

Okay, Tokenisierung. Okay, ich schmeiße jetzt meine Bälle rein. Aber du hast gerade das magische Wort Vector genannt. Und im ganzen AI-Hype wird ja gerade auch ziemlich viel Vector-Datenbanken besprochen. Ja, keine Ahnung. Auf einmal ist die PostgreSQL-Extension PG Vector wieder ganz vorne dabei. Ist Elasticsearch, OpenSearch und Co. also ganz simpel gesprochen auch eine Art Vector-Datenbank? Oder wird, wenn man jetzt von Quote und Quote, AI und Vektordatenbank spricht, spricht man da von einer anderen Art Vektor? Ich bin kein Mathematiker, wie du merkst.

Wolfi Gassler (00:28:01 - 00:29:33)

Also du kannst natürlich Vektoren verwenden für die Indexierung beziehungsweise für die Repräsentation der eigentlichen Dokumente. Also das ist in der klassischen Information Retrieval Welt ganz typisch auch. Du hast einen Vektor, einen Bag of Words, wie es auch so schön heißt. Das heißt, du hast da alle Wörter, die in deinem Wörterbuch stehen, zum Beispiel in der deutschen Sprache. Kannst du dir so vorstellen, du hast einen ganz großen Vektor und in der Zeile 1 steht Andi, in der Zeile 2 steht immer Wolfgang und so weiter. Alle Wörter und dann ist einfach eine 1, wenn Andi drin vorkommt, eine 1, wenn Wolfgang drin vorkommt und so weiter an den ganzen Positionen. Extrem langer Vektor. Der wird dann nochmal komprimiert und so weiter natürlich. Aber du hast am Ende dann einen Vektor pro Dokument. Und deine Suche ist dann auch wieder so ein Vektor und dann werden die Vektoren verglichen und der Abstand zwischen den Vektoren berechnet. Also das ist auch ein ganz klassisches Suchsystem. Der Unterschied ist jetzt natürlich nochmal, du hast ja bei den Embeddings nochmal auf Vote-Ebene eigentlich auch schon Vektoren. Also das ist schon wesentlich komplexer. Du hast nicht nur auf Dokument-Ebene einen Vektor, sondern eigentlich schon auf der Vote-Ebene bei den Embeddings. Also es ist schon nochmal eine Stufe komplexer als das Ganze, aber klar, du kannst einen Vektor auch verwenden, um ein Dokument darzustellen. Aber das ist schon das Komplexere. Der ganz klassische Ansatz von der Indexierung, wenn du die Dokumente reinbekommst, von dem Dokument, ist der invertierte Index. Und darauf basieren eigentlich fast alle Suchsysteme, so klassisches Lucene. Klar ist das ganz hoch optimiert und hat Verbesserungen und Optimierungen, aber ganz klassisch ist es eigentlich ein invertierter Index.

Andy Grunwald (00:29:34 - 00:29:59)

Okay, lasst uns mal von dem AI-Hype wieder ein bisschen weggehen, weil wir sind ja bei den Fundamentals. Und jetzt habe ich da Mein Dokument gegen das System geschmissen, die Tokenisierung wurde gestartet, abgeschlossen. Und jetzt habe ich mein Dokument in all diese Elemente zerlegt. Und das muss jetzt ja irgendwo mal hingelegt werden. Mal abgeschmeichert werden, damit ich das auch, ich sag mal, querien kann, abfragen kann. Und da kommt jetzt die Indexierung ins Spiel. Ist das richtig?

Wolfi Gassler (00:29:59 - 00:30:06)

Genau. Also ist ganz klassisch, wie man das aus der Datenbankwelt kennt. Man legt die Daten mal irgendwo ab.

Andy Grunwald (00:30:06 - 00:30:07)

Da kenn ich mich aus. Das weiß ich.

Wolfi Gassler (00:30:07 - 00:30:36)

Eben, eben. Man legt die Daten ab, deine Tabellen, deine Spalten. Du legst die Daten grundsätzlich mal ab oder nur Dateien. Und dann bildest du einen neuen Index und der Index ist nur dafür da, für die Suche dann. Also du replizierst in irgendeiner Form deine Daten speziell halt für die Suche. Also du legst die Daten dumm ab und hast dann nochmal eine spezialisierte Form für die Suche. Und da ist der invertierte Index eigentlich der klassische Weg, wie man möglichst einfach so eine Suche realisieren kann oder Daten so ablegen kann, dass ich sie schnell finde.

Andy Grunwald (00:30:37 - 00:30:42)

Okay, wenn du jetzt sagst, invertierter Index, invertiert heißt für mich irgendwie umgedreht oder ähnliches.

Wolfi Gassler (00:30:42 - 00:30:43)

Genau.

Andy Grunwald (00:30:43 - 00:30:57)

Oder umgestülpt. Jetzt erklären wir mal, invertierter Index, like I'm five. Muss kein Bällebad sein, ja? Zusatzinformation, ich bin Lego Kind, nicht Playmobil.

Wolfi Gassler (00:30:57 - 00:31:56)

Also am ehesten würde ich es mal vergleichen mit einem Telefonbuch, wie beim klassischen Index in der Datenbank. Wobei bei einer Suche, das noch ein bisschen spezieller ist, also in einem Telefonbuch habe ich irgendwie Also A und dann würde ich Andi irgendwo finden auf den Seiten mit A. Bei einem invertierten Index gehe ich einen Schritt weiter und speichere mir ab. Okay, da wo jetzt Andi steht in meinem Telefonbuch, habe ich nicht die Telefonnummer, sondern die Dokument-IDs überall wo Andi vorkommt. Das heißt, ich suche zuerst mal nach Andi, weil ich in meiner Suchquerie Andi stehen habe. Finde dann auf der Seite 20 in meinem Telefonbuch A, Andi, dieses Wort Andi und dahinter steht dann, ist in Dokument 48, in Dokument 57, in Dokument 358. Und da habe ich dann sozusagen die Verweise auf die eigentlichen Dokumente, wo Andi überall drin vorkommt. Und das ist eigentlich der invertierte Index. Das ist eine total dumme Herangehensweise eigentlich. So wie wahrscheinlich jeder, wenn man sich ein bisschen überlegen würde, wie man halt so einen Index aufbauen würde. Jetzt rein ohne Computer, in einem Buch, in einem Telefonbuch.

Andy Grunwald (00:31:56 - 00:32:01)

Okay, das bedeutet eigentlich, ich habe eine Art Hashmap und die Values der Hashmap sind Listen.

Wolfi Gassler (00:32:02 - 00:32:08)

Genau. Das ist ein invertierter Index. Und die Keys von deiner HashMap sind eigentlich Tokens.

Andy Grunwald (00:32:08 - 00:32:09)

Meine 1,3 Wörter.

Wolfi Gassler (00:32:09 - 00:32:19)

Genau. Das heißt, da wo du Andi vielleicht tokenisiert hast auf Andreas womöglich, dann suchst du eigentlich immer nach Andreas und dann findest du alle Dokumente, wo Andreas drinsteht.

Andy Grunwald (00:32:20 - 00:32:21)

Uh, das ist interessant.

Wolfi Gassler (00:32:21 - 00:32:26)

Es fühlt sich gerade extrem schlimm an, Andreas auszusprechen. Ich habe die, glaube ich, noch nie Andreas genannt.

Andy Grunwald (00:32:26 - 00:32:46)

Ja, du bist auch eigentlich nicht dazu berechtigt, wenn man es ganz ehrlich ist. Meine Frau, wenn sie sauer ist, ruft dann meist Andreas in erhobener Stimme. Ich glaube, das habe ich schon mal erzählt. Und mein Vater hat es sehr oft gemacht, wenn ich Blödsinn gemacht habe. Also es gibt nicht viele Leute, die mich Andreas nennen. Also für alle Hörer und Hörer, die mich mal im realen Leben treffen, wenn ich Blödsinn gemacht habe, also richtigen Blödsinn, ich sage jetzt nicht irgendwie, was ein Bierchen getrunken ist, kein Blödsinn.

Wolfi Gassler (00:32:47 - 00:32:49)

Darum schickt ihr das Finanzamt immer Briefe an Andreas.

Andy Grunwald (00:32:51 - 00:33:13)

Ja, leider auch die WUZ-Geldstelle, weil ich zu schnell gefahren bin. Aber, das bedeutet auch ganz kurz, Andi und Andreas, das ist ein interessantes Beispiel. Ich geb jetzt Andi in das Query ein. Steht in der Hashmap im invertierten Index Andi mit einem Verweis dann auf den Hashmap-Entry Andreas? Oder wird bei dem Query schon Andi in Andreas umgesetzt, weil das Query weiß, okay, welche Hashmap-Keys ich hab?

Wolfi Gassler (00:33:13 - 00:33:52)

Kommt natürlich auf die Implementierung drauf an, aber das Sinnvollste ist natürlich, wenn du das frühzeitig schon mappst auf Andreas in der Dokainisierung, weil du dann natürlich weniger Hubs hast und mehr Dokumente auf das eine Wort zeigen. Aber in dem Fall, also Andy und Andreas ist jetzt nicht sehr typisch, weil es halt schon Eigentlich schon was anderes ist, aber wenn man mal davon ausgeht, von dem Beispiel, dann würde ich es eher bei der Dokainisierung möglichst früh machen, einfach aus Geschwindigkeitsgründen. Aber es ist natürlich die Frage, wie du es implementierst. Du kannst auch bei der Query das so implementieren, dass die Query umgeschrieben wird auf such mir alles, wo Andy steht und wo Andreas unter Umständen auch noch steht. Also, dass so eine Extension von einer Query Expansion gemacht wird.

Andy Grunwald (00:33:53 - 00:34:01)

Okay, zurück zum inventierten Index. Jetzt haben wir eine HashMap mit einer Liste an Dokumenten-IDs. Und jetzt nehme ich mir ein sehr populäres Wort.

Wolfi Gassler (00:34:01 - 00:34:04)

Andi. Ist wohl populär, hallo? Schüttel nicht so den Kopf.

Andy Grunwald (00:34:04 - 00:34:07)

Ich denke eher an Wein. Ja?

Wolfi Gassler (00:34:07 - 00:34:10)

Okay, dann machen wir mit Wein. Ja, weil gerade neben dir ein Weinglas steht.

Andy Grunwald (00:34:10 - 00:34:24)

So sieht's aus. Und das Problem ist immer, wenn man eine Liste hat, ist durch die Liste zu gehen. Ja? Wir erinnern uns an die Landau-Notation, Big-O-Notation. Ja? Welche Komplexität hat das Suchen in einer Liste, Dr. Wolfgang Gassler? In einer unsortierten Liste.

Wolfi Gassler (00:34:24 - 00:34:29)

Ich wollte gerade sagen, das muss natürlich unsortiert sein. Ja, einfach Länge der Liste.

Andy Grunwald (00:34:29 - 00:34:38)

Ganz genau. Und das ist natürlich bei einem sehr populären Wort, bei sehr vielen Dokumenten, Wein, kann das natürlich sehr inperformant werden.

Wolfi Gassler (00:34:39 - 00:35:08)

Vor allem musst du ja denken, du suchst dir selten nach Wein, sondern du suchst nach rotem Wein. Das heißt, roter Wein wird dann runtergebrochen auf die Tokens Rot und Wein. Und dann suchst du zuerst nach Rot, bekommst eine ganz lange Liste. Und dann suchst du nach Wein, bekommst auch nochmal eine ganz lange Liste. Und dann musst du versuchen, das zu finden, was übereinstimmt, Rot und Wein. Das ist übrigens weißer Wein. Weiß ist übrigens auch ein guter Beispiel. Scharfes Essen war früher ein großes Problem. Mittlerweile geht es besser.

Andy Grunwald (00:35:08 - 00:35:14)

Für alle Hörer und Hörer, die, ihr könnt das Video gerade nicht sehen, weil wir es in der Regel nicht veröffentlichen, ich trinke weißer Wein bei der Vortragsrunde.

Wolfi Gassler (00:35:14 - 00:35:15)

Das hat jeder gehört, kein Problem.

Andy Grunwald (00:35:16 - 00:35:19)

Gibt es eine Alternative zum invertierten Index?

Wolfi Gassler (00:35:19 - 00:36:14)

Es gibt eigentlich keine Alternative in dem Sinne, aber es gibt natürlich Erweiterungen, vor allem je nachdem, was du erreichen willst, weil das Problem natürlich, was du hast, wenn du jetzt zum Beispiel nach Wald suchst und dein Ziel ist, dass du auch Grünwald findest, dann hast du schon ein Problem, weil in deinem invertierten Index steht nur Grünwald. und natürlich Wald, aber das sind ganz was anderes. Das heißt, du müsstest dann durch alle deine Keys durchgehen, durch alle deine Tokens kommt irgendwo Wald in irgendeinem Token vor und dadurch musst du wieder durch alle deine Tokens, was auch super langsam ist. Also wenn du solche Anforderungen hast, dass du so Postfix-Patterns hast, also wo du das Ende suchst und vorne ein Sternchen hast, also such mir alle zusammengesetzten Wörter, aber du willst nur den hinteren Teil definieren in deiner Query, dann hast du mit dem invertierten Index ein Problem. geht schon nicht also das geht nur wenn du ganze wörter suchst beziehungsweise ein anfang der anfang ist vielleicht möglich von.

Andy Grunwald (00:36:14 - 00:36:26)

Daten und bank indexen würde ich jetzt sagen okay irgendeine baumstruktur eine tree struktur klingt so da nach der lösung da muss natürlich wissen wo du dieses wort aufbricht und was dann der prefix und.

Wolfi Gassler (00:36:26 - 00:37:34)

Der suffix ist Also beim invertierten Index hast du normalerweise das ganze sortiert nach dem Anfang von dem Wort. Das heißt, du kannst sehr wohl nach Anfängen suchen. Das heißt A, N, D Sternchen für Andy. Da wirst du etwas finden oder relativ schnell finden. Aber wenn du natürlich Sternchen N, D, Y suchst, dann wirst du keinen Andy finden, außer du hast einen speziellen Index dafür. Und da gibt es zum Beispiel Präfixbäume oder auch Suffixbäume, das ist je nachdem von welcher Seite man das Ganze nimmt, wo dann die Daten in anderer Form abgelegt werden und wo dann wirklich die einzelnen Tile Strings, so in verketteten Baumstrukturen würde ich es nennen, abgelegt werden und dann kann man irgendwo tiefer in den Baum einspringen bei N, D, Y und findet dadurch auch den Andi, obwohl man den ersten Buchstaben nicht angegeben hat. Also das ist dann noch mal aufwendiger natürlich, weil man mehr angeben muss, aber wird sehr gerne eigentlich gemacht, wenn es um klassische String-Suchen geht, wo man einfach Präfix und Zufix-Sternchen haben möchte in der Query. Aber ist natürlich wesentlich speicherintensiver und komplexer üblicherweise das aufzubauen.

Andy Grunwald (00:37:34 - 00:37:49)

Also bedeutet das, in der Praxis bauen wir nicht alle drei Möglichkeiten gleichzeitig auf. Also das bedeutet, wir haben nicht einen invertierten Index und einen Präfixbaum und einen Suffixbaum, weil das in der Regel zu speicherintensiv ist.

Wolfi Gassler (00:37:49 - 00:39:26)

Also wenn du einen klassischen Elasticsearch-Index verwendest oder Lucene, was darunter liegt bei Elasticsearch, oder OpenSearch, wie es ja mittlerweile die Open-Source-Variante heißt, dann hast du keine Möglichkeit, Stern n-dy zu suchen für Andi. Das funktioniert nicht, ja. Da brauchst du dann zusätzliche Indizes. Oder ganz klassisch, was auch ganz oft gemacht wird, sind die sogenannten n-Grams oder n-Gramme. Kann auch Lusin, kannst du einstellen. Der Index wird viel viel größer, weil üblicherweise sind es drei Gramme zum Beispiel. Das heißt, du zerlegst alle Wörter in drei Buchstaben unter substrings. Das heißt, Andy wäre dann a n, a n d, n d y, d y und so weiter. Also zerlegst das in so unter 3er substrings und da baust du dann einen infatierten Index wieder drüber auf und dann musst du aber diese Listen, also du suchst dann wo kommt wo kommt A, N, D vor, wo kommt N, D, Y vor. Diese zwei Listen, um Andi dann zu finden, musst du dann kombinieren und die eigentlichen Dokumente raussuchen. Also das ist viel, viel komplexer und teurer. Also das ist so wie, wenn du die Tokenisierung änderst und auf so Subtokens gehst und da aber wirklich alle Varianten abspeicherst. Bei Andi hättest du sechs Substrings, weil du auch immer die Leerzeichen davor mitnehmen musst. Drei Gramme wären bei Andi am Anfang zum Beispiel Leerzeichen, Leerzeichen, A. Das ist auch schon ein Drei-Gramm. Also zwei Leerzeichen, dann der erste Buchstabe. Und dadurch bekommst du allein bei Andi schon sechs Drei-Gramme. Und da musst du überall wieder den invertierten Index ablegen, die Listen dazu und bei der Suche natürlich alles wieder zusammenbauen, kombinieren und und und.

Andy Grunwald (00:39:26 - 00:39:30)

Wenn man jetzt von Speicher intensiv spricht, spricht man da von RAM oder von Harddisk?

Wolfi Gassler (00:39:31 - 00:40:07)

Beides natürlich. Je nachdem, wie dein System wieder aufgebaut ist. Und beim Suchen ist es halt meistens so, dass du es im Hauptspeicher haben willst. Also es gibt ja auch Systeme, die komplett im Hauptspeicher basieren. Ich habe gerade kürzlich MeliSearch gefunden. Ich glaube, MeliSearch hat jemand bei uns in der Community empfohlen als System. Und die legen zum Beispiel alles im RAM ab. Und da hast du natürlich Probleme, wenn du den Index im RAM brauchst unbedingt, wenn es keine andere sinnvolle Möglichkeit gibt. Also aus Geschwindigkeitsgründen oder Architekturgründen dann bist du natürlich extrem limitiert und wenn du dann einen n-gram Index aufbaust, der halt wesentlich größer ist, dann hast du vielleicht schon ein Problem.

Andy Grunwald (00:40:08 - 00:40:56)

Gibt's die Möglichkeit, dass ich irgendwie, ich sag mal, eine Komplexität pro Wort errechne? Denn so, wie du mir die Ngrams gerade erklärt hast, hört sich das für mich so an, als kann man damit sehr gut dieses Mind-See-Feature umsetzen, wo man vielleicht mit Tippfehlern umgehen kann, weil du zerlegst das Wort ja, ersetzt es mit Sternchen oder Unterstrichen oder Leerzeichen oder was du auch immer nimmst. Aber dass ich sag, okay, wenn ich jetzt Hochgeschwindigkeitszug oder Schifffahrtskapitän, also die ... Die Wahrscheinlichkeit, dass ich da einen Tippfehler habe in dem Wort, ist sehr, sehr hoch, weil es einfach sehr komplex ist, das Wort. Gibt es irgendwie eine Art, ich errechne die Komplexität eines Wortes und umso komplexer das Wort, desto eher errechne ich ein Ngram dafür und speichere nur die komplexen Wörter für Ngram ab? Ist das eine dumme Frage? Bin ich mir gerade gar nicht sicher. Oder habe ich da gerade ein neues Feature für OpenSearch gebaut?

Wolfi Gassler (00:40:57 - 00:41:59)

Also ich glaube, mit dem zu entscheiden, einmal das, einmal das andere, ist, glaube ich, immer sehr gefährlich und wird extrem teuer und ihr habt dann auch nicht alle Features ständig zur Verfügung und einen halben Index kann ich auch nicht aufbauen. Also gefühlt hätte ich jetzt gesagt, es funktioniert nicht. Was man dann eigentlich eher macht, ist natürlich, dass man im Vorfeld einfach schon ein Dictionary hat, was damit umgehen kann und probiert, die DIP-Fehler in der Query schon rauszusuchen, bevor die eigentliche Suche gemacht wird. Aber N-Kramme zum Beispiel, Eignen sich auch dazu, Tippfehler auszubessern bzw. lockerer damit umzugehen, weil du ja die Substrings hast und wenn dann ein kleiner Substring nicht passt, dann kannst du sagen, okay, das toleriere ich und so hast du eine Möglichkeit, da ein bisschen flexibler zu sein in der Suche. Aber ich glaube, die meisten Systeme, die heutzutage so verwendet werden, ist einfach ganz oft, dass das im Vorfeld schon rausgefiltert wird und die eigentliche Suche dann mit dem gestemmten Wort oder mit dem korrigierten Wort dann eigentlich schon gemacht wird. Drum hat man ja das bei Google auch, dass du dann irgendwie automatisch die Korrektur schon bekommst, meinten sie nicht und dann wird eigentlich das schon gesucht.

Andy Grunwald (00:41:59 - 00:42:29)

Mit dem Dictionary meinst du jetzt wieder irgendwo ein Datei, wo ich ganz viele Schreibweisen von Schifffahrtskapitänen habe, wie zum Beispiel Schifffahrt, wird glaube ich mit 3F geschrieben und dann habe ich dann alle möglichen Schreibweisen unter anderem mit D und G, weil D und G sind auf der deutschen Tastatur zumindest neben dem F, und dass man dann alle möglichen Varianten von Schifffahrtskapitän, habe ich glaube ich gerade gesagt, dann in diesem Dictionary schon hat und dann Mapping auf Schifffahrtskapitän auf die richtige Schreibweise hat, richtig?

Wolfi Gassler (00:42:30 - 00:43:07)

Genau. Oder, dass du dann da vielleicht sogar ein n-Gramm-Index auf deinen Dictionary aufbaust oder sowas. Sowas könnte ich mir noch vorstellen. Beziehungsweise, dass du sowas hast, wie die ganz klassische Edit Distance, also wie viele Wörter, sorry, wie viele Buchstaben muss ich drehen oder ändern, rauslöschen aus einem Wort, damit die Ähnlichkeit besteht. So findest du dann ähnliche Wörter. Und erst dann machst du wirklich die Suche, ja genau. Aber je nachdem, wie es implementiert wird. Also du kannst auf allen Ebenen natürlich solche Sachen begegnen und verbessern oder ändern. Und je nachdem, was du für einen Index hast, ist es halt möglich oder nicht möglich. Aber ein ganz klassischer Inverted Index ist halt relativ stur. Da musst du genau dieses Vote treffen.

Andy Grunwald (00:43:07 - 00:43:18)

Okay, wir haben jetzt das Bällebad. Ja, wir haben die Bälle besorgt. Wir haben die Bälle erschaffen mit der Tokenisierung und wir haben mit der Indexierung eigentlich die Bälle in das Becken geschmissen, ist das richtig?

Wolfi Gassler (00:43:18 - 00:43:18)

Korrekt, ja.

Andy Grunwald (00:43:18 - 00:43:21)

Und jetzt muss ich einen Ball in den Bällebad finden.

Wolfi Gassler (00:43:21 - 00:43:28)

Das machst du über den Index. Also sagen wir mal, du hast den Ball dann schon gefunden über den Index, der da irgendwo steht.

Andy Grunwald (00:43:29 - 00:43:30)

Ich habe mehrere Bälle gefunden.

Wolfi Gassler (00:43:30 - 00:43:31)

Genau.

Andy Grunwald (00:43:31 - 00:43:55)

Und jetzt geht es an die Anzeige, an sogenannte Ranking. Okay, zeig mir meine Ergebnisse an. Und beim Ranking kommt mir Googles berühmter PageRank in den Sinn und ganz viele Kundentelefonate. Warum ist mein Wort bei meiner kleinen Suchmaschine hier auf meinem eCommerce Shop nicht auf Platz 1, sondern auf Platz 3? Und jetzt erklären wir mal bitte die Komplexität von Ranking.

Wolfi Gassler (00:43:55 - 00:44:04)

Also Ranking ist halt dann der letzte Schritt. Du hast deine möglichen Treffer und musst halt jetzt entscheiden, du hast nur eine gewisse Anzahl, die du anzeigen kannst.

Andy Grunwald (00:44:04 - 00:44:06)

Das sind die zehn Ergebnisse auf der Google Startseite.

Wolfi Gassler (00:44:06 - 00:44:57)

Genau, oder vielleicht sind es auch 20, je nachdem wo du bist, oder vielleicht sind es auch 100, aber es sind selten halt irgendwie, wenn es vor allem um Web geht, oder so eine Million. Das heißt, du musst da in irgendeiner Form Ranking sortieren, um das Beste nach vorne zu bringen. Ein einfacher Weg ist, du zahlst einfach sehr viel, dann stehst du ganz vorne. Der einfachste Ranking-Algorithmus ist halt ein finanzieller Algorithmus. Wenn ich Google ganz viel zahle, stehe ich halt mit der Werbung ganz oben. Ist auch ein Ranking-Algorithmus. Kann natürlich genauso sein, wird auch ganz oft in irgendwelchen Shops so gemacht. Du suchst nach irgendwas, du suchst in einem Supermarkt, shopp nach einem Produkt und dann steht aus irgendeinem Grund immer Pepsi ganz vorne vor Cola. Weil Pepsi höchstwahrscheinlich einfach irgendwie mehr zahlt und da gibt's ein Invisible Ranking im Hintergrund. Aber das ist natürlich nicht, was du eigentlich haben willst, üblicherweise, würde ich mal sagen.

Andy Grunwald (00:44:58 - 00:45:09)

Okay, jetzt bin ich keine Marketingfirma, hab nicht so viel Geld und jetzt versuche ich das überall, das ganz ehrliche SEO, Search Engine Optimization. Wie komme ich also jetzt auf Platz 1 bei Google im PageRank?

Wolfi Gassler (00:45:09 - 00:46:42)

Wenn ich das wüsste, dann wäre ich wahrscheinlich schon reich, weil das probieren, glaube ich, viele aktuell herauszufinden. Aber wenn man mal in die Vergangenheit zurückgeht und worauf Google ja so im Kern basiert, dieser berühmte PageRank-Algorithmus, den du auch schon erwähnt hast, Der geht ja darauf zurück, dass du so wie im Mittelalter oder auch was heutzutage noch ganz gut funktioniert, Recommendations, Empfehlungen, wenn dir jemand irgendwas empfiehlt, dann ist es wahrscheinlich gut. Und wenn dir das ganz viele Leute empfehlen, ist es noch besser. Und Google hat das halt damals gemacht mit dem PageRank. Wenn es ganz viele Empfehlungen gibt für eine Webseite, dann ist die wichtiger und besser. Und die Empfehlungen waren halt keine Empfehlungen, die verbal ausgesprochen worden sind, sondern waren Links. Und wenn eine Webseite auf eine andere linkt, dann glaubt die Webseite wahrscheinlich, das ist was Gutes da auf der anderen Webseite, darum linke ich ja dorthin. Und wenn jetzt eine Webseite ganz viele Links bekommt, dann ist die wichtiger. Und wenn es auf der Webseite um Fußball geht und tausende Webseiten auf diese eine Fußballseite hinlinken und ich suche nach Fußball, dann ist wahrscheinlich diese Webseite ganz gut, wenn ich die ganz oben rank oder sehr hoch anzeige, weil halt ganz viele Leute hoffentlich im Hintergrund, nicht irgendwelche Robots oder automatisierte Algorithmen, sondern Menschen auf ihrer kleinen Webseite gedacht haben, hey, diese coole Fußballseite vom Andi da, die ist super cool, die ist wichtig und die setzen einen Link drauf. Und damit hat halt Google damals Yahoo und die anderen Suchmaschinen outperformed, weil die das eben nicht hatten und nur ganz dumme technische Suche hatten im Hintergrund.

Andy Grunwald (00:46:42 - 00:46:51)

Naja, Yahoo und AltaVista und Co., die waren ja mehr Dictionary-based, wenn du so möchtest. Die hatten ja mehr einen Katalog als wirklich eine Suche.

Wolfi Gassler (00:46:51 - 00:47:29)

Ja, die hatten im Hintergrund die ganz klassische Suche, so wie es eigentlich heutzutage in irgendeinem Elasticsearch, Lucene, sagen wir nicht im Elasticsearch, die sind ja mittlerweile böse, sagt man so, als Elastic oder zumindest kommerziell. Also gehen wir mal auf das Grundprodukt im Hintergrund oder Library Lucene zurück. Wenn es darum geht, jetzt ganz viele Dokumente zu ranken und ich habe jetzt keine Information von außen, keine Personen, dann muss ich mir irgendwie anhand des Textes überlegen, welches Dokument ist wichtiger. Und was da die Standardherangehensweise ist, so wie der invertierte Index bei Indexierungs- oder die Standardherangehensweise ist, ist es beim Ranking TF-IDF. Hast du es schon mal gehört?

Andy Grunwald (00:47:30 - 00:47:46)

Terraform. Dafür steht auf jeden Fall TF. IDF, ... erinnert mich an ... IDF? Erinnert mich irgendwie an eine MDF-Holzplatte. Hat ja wahrscheinlich mit Terraform und MDF-Holzplatten nix zu tun. Deswegen erleuchte mich bitte.

Wolfi Gassler (00:47:46 - 00:47:53)

Also, DF-IDF heißt Term Frequency Inverse Document Frequency. Klingt komplizierter, als es eigentlich ist.

Andy Grunwald (00:47:53 - 00:47:56)

Was denn jetzt? Term Frequency oder Inverse Term Frequency?

Wolfi Gassler (00:47:56 - 00:48:11)

Es ist Term Frequency Slash ... Inverse Document Frequency. Und das Ganze ist wirklich dividiert, weil da der Score so berechnet wird. Die Grundidee von dem Ganzen ist eigentlich, dass man sagt, wenn Wörter ganz oft vorkommen, sind sie weniger wichtig, weniger relevant.

Andy Grunwald (00:48:11 - 00:48:13)

Wenn die ganz oft vorkommen?

Wolfi Gassler (00:48:13 - 00:48:15)

Genau.

Andy Grunwald (00:48:15 - 00:48:20)

Ist das nicht der klassische SEO-Trick, dass du ein Wort ganz oft erwähnst, deswegen hast du eine höhere Relevanz für das Dokument?

Wolfi Gassler (00:48:21 - 00:50:14)

Das ist eine andere Relevanz, wenn es jetzt um Google oder SEO geht. Aber grundsätzlich, wenn du zählst, wie oft kommt ein Dokument gesamt vor. Jetzt nicht in einem Dokument, sondern gesamt. Das ist die Term Frequency. Also wie oft kommt das Token, wir sind bei Tokens übrigens, nicht bei Words, insgesamt vor, so ein Term. Das heißt, Andi zum Beispiel kommt wahrscheinlich in meinen ganzen vielen Dokumenten, in meinen jetzt vielleicht schon, kommt sehr oft vor, keine Ahnung, aber allgemein weniger. Hingegen, wenn wir irgendein Wort verwenden, wie ist, war, sein, solche Dinge, die kommen ganz oft vor. Das heißt, wenn ich merke, okay, das ist, ist fast in jedem Dokument drinnen, dann ist das wahrscheinlich kein gutes Kriterium, nach dem ich suchen soll, nach dem Wort ist. Hingegen Andy zum Beispiel, Andy kommt in sehr wenigen Dokumenten vor und wenn dann Andy mal in einem Dokument vorkommt, dann ist es wahrscheinlich, höchstwahrscheinlich, irgendein Dokument, was wirklich mit Andi zu tun hat. Und das ist dann gut. Das heißt, umso öfter ein Wort vorkommt, umso mehr kann ich es ignorieren. Dann, wenn aber Andi natürlich zehnmal innerhalb einem Dokument vorkommt, dann ist es natürlich extrem relevant für Andi. Das heißt, gut ist, dass ein Wort oft in einem Dokument vorkommt, wie du richtig gesagt hast, der SEO-Trick. Aber im Gesamten sollte das Dokument selten vorkommen. Und genau das beschreibt die Term Frequency dividiert durch die Inverse Document Frequency, also wie oft kommt es im Dokument vor und wie oft kommt es gesamt in meinem Korpus, also in allen meinen Dokumenten vor. Und diesen Wert vergleiche ich und dadurch kann ich ranken, ob das Dokument jetzt gut ist oder schlecht. Das heißt, wenn Andy in zwei Dokumenten vorkommt und in einem Dokument kommt es einmal vor und im anderen Dokument aber 30 Mal und das Dokument ist vielleicht gar nicht so lang, dann wäre dieses Dokument, wo es 30 Mal vorkommt, eher auf Platz 1 ranken und das andere auf Platz 2.

Andy Grunwald (00:50:14 - 00:50:23)

Ich gebe gerade zu, ich fühle mich so ein bisschen unwohl, wenn ich gerankt werde. Schade, dass wir dieses Beispiel nehmen. Nun gut, muss ich leider mit leben. Der Education wegen.

Wolfi Gassler (00:50:23 - 00:50:26)

Du bist so gut zu dieser Welt, dass du dich opferst, Andi.

Andy Grunwald (00:50:26 - 00:50:32)

Du tust gerade so, als mache ich das freiwillig. Also von daher, du hast das Beispiel genommen. Aber okay, hab ich verstanden.

Wolfi Gassler (00:50:32 - 00:50:44)

Und darauf basieren eigentlich alle Algorithmen heutzutage, mehr oder weniger. Es gibt da Optimierungen, BM25 gibt's Best Matching, da steht das BM. Das ist ein bisschen eine Optimierung noch mal.

Andy Grunwald (00:50:44 - 00:50:55)

Und das BM25, da applyen die hinten einen Limit 25 und gucken sich nur die ersten 25 Dokumente an, oder? Weswegen ist das eine Optimierung?

Wolfi Gassler (00:50:55 - 00:51:11)

So wie Top X, oder? Nein, im Prinzip, es gibt glaube ich auch 12, wenn mir nicht alles täuscht, BM12 und BM11 oder so. Du kannst es so, sind einfach verschiedene Implementierungen. Nennst Versionsnummer, wenn du willst. Hat eigentlich wenig mit irgendeinem Wert oder sowas zu tun.

Andy Grunwald (00:51:11 - 00:51:29)

Kann ich, kann ich denn auch irgendwo angeben, den Ort, wo das Wort drin vorkommt? Nehmen wir jetzt mal, nehmen wir jetzt mal eine Datei, eine PDF-Datei, ja? Der PDF Datei wird per OCR, der Content wird per OCR gescannt und ich übermittle der Suchmaschine, also der Tokenisierung, der Indexierung auch den Titel des Dokumentes.

Wolfi Gassler (00:51:29 - 00:51:31)

So eine Gewichtung im Prinzip.

Andy Grunwald (00:51:31 - 00:51:56)

Ja genau, Steuererklärung 2024. Punkt PDF ist der Titel und der Content ist dann leider meine Steuererklärung, die ich ans Finanzamt geschickt habe. Und jetzt wird mit hoher Wahrscheinlichkeit in dem Dokument irgendwann Steuererklärungen vorkommen, aber ich möchte, dass dieses Dokument, weil das hat ja Steuererklärung im Titel, höher gerankt wird als ein Dokument, wo nur Steuererklärung im Content drin vorkommt, aber nicht im Dokumententitel.

Wolfi Gassler (00:51:57 - 00:52:34)

Ja, mit der Gewichtung ist es gar nicht so einfach, weil diese Algorithmen ja sehr starr sind, würde ich mal sagen, optimiert. Was man früher ganz oft gemacht hat, beziehungsweise man kann es immer noch machen natürlich, wenn man so ein TF-IDF zum Beispiel verwendet und man möchte jetzt da irgendwie eine Gewichtung einbauen, dass man einfach sagt, wenn das der Titel ist, dann kopiere ich den Titel einfach 10 mal in dieses Dokument rein. Bevor ich dieses Dokument abspeichere bei der Tokenisierung, dupliziere ich den Titel einfach 5 mal, 10 mal, je nachdem was ich für Gewicht haben will und dann läuft es durch die ganze normale Maschinerie einfach durch und dadurch es öfters vorhanden ist in dem Dokument, hat das Ganze die Gewichtung.

Andy Grunwald (00:52:35 - 00:52:38)

Mit diesem Hack, der sehr dreckig klingt, der gefällt mir.

Wolfi Gassler (00:52:38 - 00:52:46)

Der aber sehr üblich ist und ich glaube, wahrscheinlich auch noch ganz viel gemacht wird im Hintergrund, weil es einfach keine Änderung im Algorithmus benötigt.

Andy Grunwald (00:52:46 - 00:52:51)

Das bedeutet aber auch, ich muss bei einer Gewichtsänderung die ganze Sache neu tokenisieren und indexieren, richtig?

Wolfi Gassler (00:52:51 - 00:53:44)

Ja, genau. Also du hast natürlich auch in der Query unter Umständen Tokens drin und Felder und Lucin kennt ja auch gewisse Felder und du kannst dann gewissen Feldern ein höheres Gewicht geben. Also du kannst es im Nachhinein schon auch machen. Aber es ist gar nicht so leicht, diese Gewichtung im Nachhinein reinzubringen und vor allem performant reinzubringen, weil alles, was du irgendwie so an Extraschritten hast, macht dein ganzes Modell ja viel komplexer und deinen Algorithmus vielleicht nicht mehr so schnell, weil die haben das halt optimiert. Lucine ist sowas fucking fast schnelles. Es ist unglaublich. Ich habe das mal probiert. Wolfsjabber ist eine ähnliche Variante im Kleinen in C nachzubauen. Ich bin nicht annähernd an den Speed dran gekommen. Also es ist unglaublich optimiert und wenn du da irgendwas änderst oder plötzlich dir denkst, ja da könnt ihr noch eine Berechnung irgendwo draufsetzen oder so, es ist mal schwierig das reinzubekommen, aber wenn du es schaffst, dann wirst du halt womöglich die ganzen Optimierungen überbaut und es ist super langsam.

Andy Grunwald (00:53:44 - 00:54:17)

Okay, tf, edf habe ich verstanden. Jetzt hattest du aber bei der Indexierung auch von Vektoren gesprochen, und zwar wie weit sind gewisse Worte voneinander entfernt. Und jetzt stelle ich mir natürlich die Frage, so verstehe ich unter anderem ja auch Vektordatenbanken teilweise, dass dieser Abstand zwischen zwei Vektoren ja auch für die Suche selbst, also für die Relevanz, dann genutzt wird und nicht nur für die Indexierung, sondern wirklich, okay, wie weit ist das Wort von dem, was ich suche, hier entfernt? Wird das da auch angewandt im Ranking? Die Vektordistanz zwischen diversen Wörtern?

Wolfi Gassler (00:54:17 - 00:55:49)

Genau, das ist dann das Ranking. Also du misst den Abstand zwischen zwei Vektoren. was auch gar nicht so trivial ist. Das heißt, wenn du dir vorstellst in einem dreidimensionalen Raum, wo du x, y, z hast, dann hast du da irgendwo die Punkte, dein Vektor hat drei Elemente x, y, z und dann misst du den Abstand zwischen den Vektoren, also wo das in dem Raum liegt einfach. Wenn du jetzt einen Raum hernimmst mit zwei Meter Höhe, dann kannst du da die Punkte anordnen und misst einfach mit einem Maßband die Abstände zwischen zwei Punkten. So berechnest du, ist was ähnlich oder nicht so ähnlich bei x, y, z, bei drei Dimensionen. Jetzt hast du natürlich bei diesen ganzen Embeddings und Vektoren hast du natürlich hunderte Dimensionen meistens oder vielleicht sogar tausende am Anfang. Das heißt, da musst du natürlich dann Optimierungen finden und es wird wesentlich komplexer, umso mehr Dimensionen du hast, umso komplexer wird das Ganze natürlich und die Abstandssuche ist dann nicht mehr so leicht auf so hochdimensionalen Vektoren, aber im Endeffekt geht es immer klassisch um den Abstand zwischen den Vektoren, weil umso näher die beisammen sind, umso ähnlicher sind die Vektoren und damit der Vektor der Suche ist dann ähnlich zu einem Dokument. Also alle Dokumente, die der Suche entsprechen, ähnlich sind, versammeln sich um die Suche oder in der Nähe. Und darum kannst du einfach den Abstand nehmen. Und das ist das berühmte Vector-Space-Model, wo du einfach die Vektoren in einem Space, in einem Raum anordnest und den Abstand dazwischen misst. Und genau der Abstand ist einfach eine Zahl, die Länge, und nach der kannst du ranken. Umso kleiner die Zahlen, umso besser.

Andy Grunwald (00:55:50 - 00:55:54)

Das klingt alles so einfach, wie du es gerade erklärst, aber ich glaube, die Implementierung ist schon ordentlich komplex.

Wolfi Gassler (00:55:54 - 00:56:14)

Ja, aber da haben sich Mathematiker die Köpfe drüber zerbrochen. Das ist alles implementiert, das geht schon irgendwie. Vor allem brauchst du dann ja auch mathematische Algorithmen, um so Vektoren, die tausende Elemente haben oder Einträge haben, irgendwie kleiner zu machen, weil du kannst nicht mit Vektoren arbeiten, die so riesengroß sind. Also du musst dann das auch runterbrechen, optimieren, komprimieren, aber da gibt es Methoden dafür.

Andy Grunwald (00:56:15 - 00:57:26)

Jetzt wissen wir ja alle, jetzt haben wir das System an den Start gebracht, die Suche ist da, läuft. Und jetzt wollen wir natürlich auch das meiste rausholen aus der Suche. Und umso länger man das System betreibt, desto mehr lernt man darüber natürlich. Jetzt möchte ich natürlich, wenn jemand das Wort Sneaker eingibt und klickt auf das dritte Ergebnis, Dann möchte ich natürlich in irgendeiner Art und Weise mittracken, wie viele Leute auf das dritte Ergebnis geklickt haben, um dann herauszufinden, warum mehr Leute das dritte Ergebnis bei dem Wort Sneaker geklickt haben, anstatt das erste. Weil mit hoher Wahrscheinlichkeit scheint das dritte relevanter zu sein. Also wie lerne ich oder welche Methoden gibt es, dass ich in der Produktentwicklung, in der Suchentwicklung, lerne wie meine user meine suchmaschine benutzen also dass das das klick zur suche ist ein beispiel eine andere sache ist ich trecke einfach mit was die leute suchen und wie viel ergebnisse da rauskommen wenn nur drei ergebnisse rauskommen ist das sehr wahrscheinlich eine doofe suche und dann müsste ich da ein bisschen nachbessern oder vielleicht sogar null ergebnisse, Weil null Ergebnisse bei einer Suche auf einem E-Commerce-Shop ist immer ganz schlecht. Deswegen, was gibt es da so für Möglichkeiten, damit ich die ganze Sache einfach kontinuierlich verbessere?

Wolfi Gassler (00:57:26 - 00:59:22)

Du musst einfach einen Feedback-Loop einbauen in irgendeiner Form. Wie du den implementierst, ist eigentlich ziemlich egal. Du kannst auch wieder ganz dumm dran gehen. Also die banalste Variante, keine Ahnung, ob man die wirklich mal implementiert hat, aber sehr banale Variante wäre, wenn ich jetzt nach Andi suche, um wieder das Beispiel zu bemühen von dir, Und es klickt jemand immer in dritter Position auf Andi Grunwald, dann scheint zu Andi, der Andi einfach sehr wichtig zu sein. Und was du dann einfach machst ist, du fügst Andi öfters in diesem Dokument ein, dass der Andi öfters drin vorkommt und dadurch wandert es natürlich nach oben. Könntest du machen. Pro Klick fügst du einmal Andi hinzu. Wenn du dann DFID erfasst, wandert das irgendwie automatisch nach oben. Sehr banaler Ansatz macht man natürlich jetzt hoffentlich nicht so, aber du baust eine Feedback-Loop und die kannst du verarbeiten wie du willst. Da gibt es natürlich super viele Ansätze und das hat sich in den letzten Jahrzehnten stark verbessert. Dieses ganze Lernen, nennen wir es mal, ich finde es fast ein bisschen übertrieben, Es geht so weit, dass es mittlerweile so einen Standard gibt, der Learning to Rank heißt, wo es genau darum geht, dass eben durch Machine Learning herausgefunden wird, was denn so Kriterien sind, die zum Suchtreffer führen. Das befindet sich dann aber eigentlich im Machine Learning Bereich schon, wo man mehrere Features üblicherweise verwendet, um einen Treffer zu generieren. Und da lernt man dann zum Beispiel, welche Features eigentlich wichtig sind und für dich wichtig sind in der Suche. Da merkst du dann zum Beispiel, wenn du irgendwas vorschlägst bei einem Recommender System, das geht dann schon auch in die Richtung, dass zum Beispiel der Preis bei einem gewissen Produkt gar nicht so wichtig ist, sondern es geht nur darum, dass dein Sneaker aus Leder ist zum Beispiel, dass das eigentlich viel wichtiger ist und dann wird auf dieses Feature optimiert und so hast du einen Zykel drinnen, wo du merkst, okay, der Preis ist eigentlich gar nicht so wichtig, aber das Material ist viel wichtiger und dann verwendest du dieses Feature mit einer höheren Gewichtung in deinen Suchergebnissen oder in deinem Recommendationsystem.

Andy Grunwald (00:59:22 - 00:59:40)

Also für mich als Nicht-Machine-Learning-Engineer klingt das nach einem sehr komplexen System auf einem komplexen System. Aber wenn das der Standard ist, nun gut, machen wir's. Ich hab mal grad kurz gegoogelt, Learning-to-Rank fällt wirklich in die Klasse von Supervised Machine Learning, also dem überwachten Machine Learning.

Wolfi Gassler (00:59:40 - 00:59:43)

Weil du ja den Feedback Cycle eben dadurch hast.

Andy Grunwald (00:59:43 - 00:59:44)

Genau.

Wolfi Gassler (00:59:44 - 00:59:53)

Und Rückmeldungen gibst. Aber es fängt mal immer eigentlich damit an, dass man keine Ahnung hat, ausprobiert, alles ist gleichgewichtet und irgendwann merkt man, hey, Materialeigenschaften von dem Sneaker sind das Wichtigste.

Andy Grunwald (00:59:54 - 01:00:12)

Jetzt sind wir durch die ganzen Steps gegangen und jetzt stelle ich mir aber immer noch die Frage, was sind denn die Attribute, wie ich eigentlich ein gutes System auswähle? Wir haben Elasticsearch als inzwischen proprietäres System. Wir haben OpenSearch als Open-Source-Competitor und offengesprochen, die Features, die wir gieren, schon enorm aktuell.

Wolfi Gassler (01:00:12 - 01:00:22)

Proprietär darf man eigentlich nicht sagen. Eigentlich ist es ja auch Open-Source, also es ist nicht proprietär. Du darfst es nur nicht als Cloud-Hoster betreiben. Du kannst es aber in deinen Produkten und so weiter vollständig verwenden.

Andy Grunwald (01:00:23 - 01:00:24)

Server-Side-License.

Wolfi Gassler (01:00:24 - 01:00:25)

True. Richtig.

Andy Grunwald (01:00:25 - 01:00:31)

Dann haben wir Algolia. Hosted System. Sehr bequem, muss ich zugeben.

Wolfi Gassler (01:00:31 - 01:00:41)

Sieht man auch immer öfters auch so in Dokumentationen. Ganz beliebt, wenn man in Dokumentationen nach Funktionen sucht, wenn dann so ein Riesen-Autocomplete ausklappt. Das ist Algolia. Kennt man vielleicht.

Andy Grunwald (01:00:41 - 01:01:08)

Nutze ich auch sehr viel. Algolia hat zum Beispiel komplett Hacker-News indiziert. Wenn ich mal wieder einen alten Artikel suche. Dann hattest du noch MeliSearch genannt, kannte ich jetzt so noch nicht. Es gibt sehr wahrscheinlich noch ganz viele andere Systeme. Doch was sind denn so die Attribute? Was zeichnet ein gutes System aus? Wie schnell ist das? Also ich meine, da haben wir natürlich wieder dieses Problem mit dem ganzen Marketingmaterial. Was sind deine Tipps, wie du sagen würdest, Hier drauf würde ich achten.

Wolfi Gassler (01:01:09 - 01:01:41)

Also wie du schon mal richtig gesagt hast, die Marketingseiten, wenn ihr da auf Mailesearch zum Beispiel geht, Lightning Fast, Plug and Play, Ultra Relevant, also es wird einem immer alles versprochen, ganz klar. Die Frage ist eigentlich immer, was hast du eigentlich für einen Anwendungsfall? Wie sehen deine Queries aus? Wie groß ist dein Korpus? Was willst du da an Daten reinstecken? Wie oft ändern sich diese Daten? Musst du das im RAM haben, den Index? Musst du nicht im RAM haben? Wie viel RAM hast du zur Verfügung? Wie groß ist eben dein Korpus? Wenn du Terabyte an Daten hast in deinem Korpus, wird der Index natürlich auch größer.

Andy Grunwald (01:01:42 - 01:01:44)

Was ist ein Corpus?

Wolfi Gassler (01:01:44 - 01:03:08)

Einfach alle deine Dokumente, alles, was du durchsuchen willst. Dann hast du da natürlich Limitierungen drauf. Und drum würde ich mir mal sehr genau am Anfang überlegen, was brauche ich überhaupt und was will ich suchen und was suchen meine User? Weil wenn ich jetzt in der Travel-Branche bin und ich muss irgendwie unterstützen, dass da Flughafen-Kurzcodes gesucht werden, das ist natürlich ein super spezieller Use Case. Und da muss ich mir überlegen, hat er dieses Suchsystem irgendwie Möglichkeiten, mich dabei zu unterstützen? Aber eine klassische Volltextsuche bekommen die Systeme alle durch die Bank hin. Die unterscheiden sich halt dann wirklich in so Feinheiten. Ist natürlich schon schwierig, das im Vorhinein zu wissen, was man dann für Probleme irgendwann haben wird. Aber man kann sie mal so grundsätzlich einordnen. Wenn ich meinen Produktindex habe in meinem online Shop, Supermarkt, dann habe ich da meine paar tausend Artikel, das werden nie mehr, weil ich werde in meinem Supermarkt nicht plötzlich drei Millionen Artikel haben, sondern immer ein paar tausend. Dafür habe ich andere Anforderungen, mit meinen Gramm 0,5 Liter und so weiter, da muss ich diese Use Cases checken, kann ich die irgendwie abdecken oder wird da automatisch alles rausgestemmt, alle Stop Wörter entfernt, alle meine Ls von den Litern werden automatisch entfernt und ich habe gar keine Möglichkeit da einzugreifen. dann ist es das falsche System. Also ganz oft sind es nicht so klassische Performance-Dinge, sondern wirklich, wie kann das meinen speziellen Use Case ermöglichen und verbessern? Weil in der klassischen Suche, das schaffen sie alle.

Andy Grunwald (01:03:08 - 01:03:22)

Aber das bedeutet ja eigentlich, dass ich eigentlich so eine Art Proof of Concept machen muss und zu wissen muss, okay, was ist wichtig für mich? Wie du hast gerade gesagt, zum Beispiel großes L für Liter und solche Geschichten, dass ich sowas dann mal im kleinen Rahmen vorher teste. Ist das richtig?

Wolfi Gassler (01:03:22 - 01:04:07)

Also eigentlich das Überlegen, was mein Use Case ist und da die Anforderungen klar spezifizieren. Das ist, glaube ich, ganz wichtig, weil sonst habe ich keine Chance, das in irgendeiner Form zu testen. Weil dass die alle super fast sind und super flexibel und keine Ahnung super performant sind, Ja, das mag alles sein, aber im Endeffekt kommt es dann ganz schwer auf den Use-Case drauf an. Wie oft suche ich? Brauche ich Autovervollständigung zum Beispiel? Das heißt, erwarten sich meine User, wenn ich etwas eintippe, dass ich da sofort Autovervollständigung, die ersten Ergebnisse habe innerhalb von Millisekunden oder ist das mehr eine Suche, wo ich auch mal, keine Ahnung, 20 Sekunden warten kann oder 30 Sekunden, weil das irgendein Archiv ist und dadurch sucht man das nicht so schnell oder keine Ahnung. Also da gibt es, glaube ich, viele Use-Cases und man muss sich wirklich überlegen, in welche Richtung man da geht.

Andy Grunwald (01:04:08 - 01:04:13)

Und die letzte Frage von diesem Explain me like I'm five, how search engine works.

Wolfi Gassler (01:04:14 - 01:04:15)

Jetzt bin ich gespannt.

Andy Grunwald (01:04:15 - 01:04:18)

Ist eine Stereotypenfrage in 2024.

Wolfi Gassler (01:04:18 - 01:04:20)

Hm, KI.

Andy Grunwald (01:04:20 - 01:04:46)

Ja, richtig. Also im Endeffekt ist meine Frage, wir haben jetzt über die Grundlagen gesprochen, die sehr erfolgreiche Systeme auszeichnet inzwischen und auch wie komplex das ist. Und jetzt kommt dieses Generative AI um die Ecke. Führ uns mal bitte in die Zukunft. Was denkst du, wie wird Generative AI diese ganze Thematik der Suchen und Suchgrundlagen, du hattest gerade schon Features wie Embeddings genannt, beeinflussen?

Wolfi Gassler (01:04:46 - 01:06:45)

Also man sieht Embeddings viel, viel mehr im Allgemeinen, wobei klassische Embeddings würde ich jetzt nicht als das klassische Gen-AI oder Sonstiges verstehen, sondern es gibt schon sehr lange, BERT gibt es auch schon ziemlich lange eigentlich, Also das sind Dinge, die jetzt nichts Neues sind, aber die kommen so langsam in der Suche. So gefühlt muss ich aber trotzdem sagen, in der Praxis sieht man das noch sehr wenig. Das haben zwar schon die meisten als Unterstützung, aber was ich so in der Praxis sehe, sind das eher die klassischen Modelle. die da verwendet werden, weil die einfach schnell sind, weil die gut funktionieren. Und das ist relativ schwierig dann, wenn man da in die ganze Machine Learning Embedded Richtung geht. Und wenn man dann noch weiter geht in die ganze Deep Learning Seite und Gen AI Seite, dann geht es halt vor allem in die Kombination von Systemen. Und da sehe ich eigentlich die größte Stärke. Wir hatten das auch kürzlich in der Episode 116 mit der Birgitta. Die hat RAC-Systeme, Retrieval Augmented Generation, erwähnt. wo es eigentlich genau darum geht, die zwei Systeme zu vereinen. Das heißt, ich suche vielleicht nach Andi in meinem System, ganz klassisch, finde alle Dokumente, wo Andi drin vorkommt, und dann schnappe ich mir diese 30 Dokumente, wo Andi drin vorkommt, schmeiße die in ein Sprachmodell und frage dann das Sprachmodell, okay, wie alt ist der Andi? Und das Sprachmodell geht mir dann die ganzen Dokumente durch, wo Andi vorkommt, und probiert herauszufinden, wie alt ist Andi wirklich? Also so, dass man so Kombinationen hat zwischen den Systemen und das eigentlich enriched oder nochmal weiterverarbeitet eigentlich. Also im Prinzip den Ranking-Schritt vielleicht nochmal verfeinert, indem er dann mit Sprachmodellen nochmal was drüberlegt. Und da sehe ich aktuell in der nahen Zukunft eigentlich die meisten Anwendungsbereiche. Langfristig kann es natürlich schon sein, dass irgendein LLM am Ende die ganze Suche ersetzt. Umso intelligenter das wird, umso eher kann man vielleicht die ganze Suche dann durch eine simple Anfrage einer LLM komplett ersetzen. GPT kann auch jetzt schon gewisse Sachen beantworten.

Andy Grunwald (01:06:46 - 01:07:25)

Also aus meinem aktuellen Wissen über AI, generative AI, LLMs, ist natürlich dann die Herausforderung, okay, wie können einzelne Firmen die aktuellen Open Search nutzen, zum Beispiel, denn ihre eigenen LLMs trainieren, ja, Rechenpower und Co. Das ist natürlich dann eine Herausforderung, oder wie kann man ein trainiertes LLM irgendwie zur Verfügung stellen, lizenziert oder ähnliches. Aber weißt du was, dann ist die Zukunft und dann ist das Problem vom Zukunfts-Wolfgang und vom Zukunfts-Andi. Ich meine alternativ, ganz dreckige Implementierung, kann natürlich auch ein OpenSearch einfach ein Chat-GPT-API-Call machen. Also ich meine, super dreckig, ganz klar, nicht zu empfehlen, kostet, glaube ich, enorm.

Wolfi Gassler (01:07:25 - 01:08:12)

Viel Geld, aber das wird ja jetzt, glaube ich, ganz oft auch schon gemacht, dass man einfach ein OpenSearch Core hernimmt, da eine Suche macht und die Ergebnisse filtert man dann in irgendeiner Form. Das kann ja auch zum Beispiel sein, dass man Kategorien filtert. Ich suche nach Schuhen, nach Sneakern, bekomme alle Sneaker und dann filter ich nochmal nach Rot, weil ich in meinem Shop halt auch den Filter Farbe drin hatte. Das kann ich vielleicht bei der Suche noch gar nicht drinnen machen, das filter ich einfach nach. Und so ein Nachfilterschritt könnte eben auch durch GPD oder eine LLM funktionieren. Und ihr habt da auch wieder ein gutes Beispiel aus der Supermarktwelt. Ich finde das super interessant, weil es einfach komplexer ist, als man so denkt, obwohl es nur ein paar tausend Artikel sind. Aber wenn du in dem Suchfeld oben in einem Online-Supermarkt Erdbeere eingibst, Andi, was würdest du dir erwarten?

Andy Grunwald (01:08:12 - 01:08:14)

Die Fruchterdbeere. 500 Gramm.

Wolfi Gassler (01:08:14 - 01:09:17)

Genau. Zum Beispiel. Wäre eine Möglichkeit. Was aber garantiert kommt, sind wahrscheinlich irgendwie die Haribo-Erdbeeren. weil da unten eine extrem lange Liste dran hängt, noch was da drin sind, irgendwelche Erdbeerenrückstände oder so, oder hatte vielleicht zufällig mal Kontakt mit Erdbeeren. Das heißt, in dem ganzen Dokument kommt irgendwie 18 mal Erdbeere vor, aber deine 500 Gramm, das sind Erdbeere, da kommt Erdbeere nur einmal vor, dieses Wort. Das heißt, es wird komplett schlecht gerankt und davor kommt die Erdbeerschokolade, das Erdbeerjoghurt und die tiefgekühlten Erdbeeren und was weiß ich was alles. Und da merkt man schon, wenn man da ein LLM hätte, dass man sagt, okay, ich will jetzt wirklich die Fruchterdbeere oder die frische Erdbeere, dann versteht das das LLM und die blenden dann tiefkühl aus. So ist es aktuell extrem schwierig, das in einem Modell irgendwie klarzustellen, mir geht es da um frische Erdbeeren. Auch für den User, wie kann man suchen, weil frische Erdbeere wird nur gefunden, wenn da irgendwo frisch steht. Also das sind eigentlich schon recht komplexe Anforderungen, die man dann aber mit dem LLM eben lösen kann.

Andy Grunwald (01:09:17 - 01:09:21)

ExplainMeLikeM5, vielen Dank, Lehrer Wolfgang.

Wolfi Gassler (01:09:21 - 01:09:22)

Ich habe jetzt irgendwie Lust in einem.

Andy Grunwald (01:09:22 - 01:10:16)

Bällebad rumzuspielen, muss ich zugeben, aber ich denke du hast auf eine sehr simple art und weise ziemlich viele buzzwords erklären können vielen die bleibt von ich habe auf jeden fall ziemlich viel gelernt stemming stopper synonyme was paradies sind ja tomaten paradise paradise siehst du tomaten homonyme ja das bärt nicht nur eine figur ist der sesamstraße ist sondern, Nämlich auch Kontext links und rechts bei einem Wort mitnimmt. Präfixbäume, Suffixbäume, N-Gramme. Nicht zu vergessen den Inverted Index. Aber auch den Terraform und meine MDF-Platte, nämlich IDF, nämlich Term Frequency und Inverse Document Frequency. Das Vector Space Model und den Supervised Learning Algorithmus Learning to Rank. Auch, finde ich, für mich der schlechteste Name eigentlich.

Wolfi Gassler (01:10:17 - 01:10:18)

Okay, genau das, was es macht.

Andy Grunwald (01:10:18 - 01:10:50)

Ja, das ist, das klingt zu unkompliziert vielleicht. Ich habe eine Menge gelernt. Ich fühle mich ein bisschen selbstsicherer bei der Evaluierung von Suchergebnissen bei OpenSearch. Ich weiß nicht, ob das jetzt hilft. Ich weiß nicht, ob ich das jemals zur Anwendung bringen kann, aber ich fühle mich auf jeden Fall ein bisschen selbstsicherer. Danke Wolfgang und auf dass wir uns irgendwann mal vielleicht in einem Bällebad wirklich begegnen. Vielleicht auf dem Chaos Computer Club Kongress oder vielleicht haben wir auch mal die Chance bei einem im Smallland bei Ikea eingesperrt zu werden. Ich weiß es nicht. Ich weiß es nicht.

Wolfi Gassler (01:10:50 - 01:11:17)

Vielleicht hat die Uni Innsbruck die Bälle noch aufgehalten. Keine Ahnung, ob die das Bällebad noch irgendwie rumliegen haben. Könnte ich mal nachfragen. Auf jeden Fall würde mich auch interessieren, wenn wir auch irgendwas vergessen haben. Wir haben jetzt nur ein paar Suchprodukte genannt. Wenn du noch irgendein Suchprodukt weißt, komm bei uns in der Community vorbei. Wir sind immer froh, da mal was zu hören, was es sonst noch am Markt gibt. Und man hat da weniger am Schirm, als man so denkt. Da gibt es ja doch ganz viele außenrum um den ganzen Open Elasticsearch zu.

Andy Grunwald (01:11:18 - 01:12:11)

In der Community selbst sind natürlich auch ganz viele andere Mitglieder, die deutlich mehr Erfahrung im ganzen Suchspace haben als wir. Aber falls du noch eine Follow-Up-Frage hast, Wolfgang steht da natürlich auch zur Verfügung. Und wenn dir diese Episode gefallen hat, würden wir mal gerne um deine Hilfe bitten. Und zwar kannst du uns unterstützen, indem du uns einfach weiter empfiehlst. Nimm doch einfach mal deine Lieblingsfolge, geh doch mal bei dir in den Firmen-Sled, in das Firmen-Teams oder in den Firmen IRC, falls ihr auf der Schiene unterwegs seid. Und poste doch einfach mal deine Lieblingsepisode und schreib da zwei Sätze, warum die cool ist und warum die anderen Leute sich die anhören sollten. Das würde uns ungemein helfen und vielleicht hilft es auch den ein oder anderen deiner Kollegen. Ansonsten würde ich sagen, vielen lieben Dank und wir hören uns in der nächsten Episode. Bis bald. Tschüss. Ciao.

#118 Wie funktioniert eine moderne Suche? Von Indexierung bis Ranking

Shownotes / Worum geht's?

Links

Sprungmarken

Hosts

Feedback

Transkript

Wolfi Gassler (00:00:02 - 00:00:07)

Andy Grunwald (00:00:07 - 00:00:09)

Wolfi Gassler (00:00:09 - 00:00:37)

Andy Grunwald (00:00:41 - 00:02:17)

Wolfi Gassler (00:02:17 - 00:02:20)

Andy Grunwald (00:02:20 - 00:04:21)

Wolfi Gassler (00:04:21 - 00:04:21)

Andy Grunwald (00:04:22 - 00:04:23)

Wolfi Gassler (00:04:24 - 00:04:29)

Andy Grunwald (00:04:30 - 00:04:32)

Wolfi Gassler (00:04:32 - 00:04:40)

Andy Grunwald (00:04:40 - 00:05:06)

Wolfi Gassler (00:05:07 - 00:05:25)

Andy Grunwald (00:05:25 - 00:05:54)

Wolfi Gassler (00:05:54 - 00:07:20)

Andy Grunwald (00:08:26 - 00:08:36)

Wolfi Gassler (00:08:36 - 00:08:46)

Andy Grunwald (00:08:46 - 00:08:49)

Wolfi Gassler (00:08:50 - 00:09:58)

Andy Grunwald (00:09:58 - 00:10:10)

Wolfi Gassler (00:10:10 - 00:11:04)

Andy Grunwald (00:11:04 - 00:11:16)

Wolfi Gassler (00:11:16 - 00:11:25)

Andy Grunwald (00:11:25 - 00:11:28)

Wolfi Gassler (00:11:28 - 00:12:13)

Andy Grunwald (00:12:14 - 00:12:16)

Wolfi Gassler (00:12:16 - 00:12:27)

Andy Grunwald (00:12:27 - 00:12:42)

Wolfi Gassler (00:12:42 - 00:13:15)

Andy Grunwald (00:13:15 - 00:13:23)

Wolfi Gassler (00:13:23 - 00:14:31)

Andy Grunwald (00:14:31 - 00:14:49)

Wolfi Gassler (00:14:49 - 00:16:07)

Andy Grunwald (00:16:07 - 00:16:23)

Wolfi Gassler (00:16:23 - 00:16:24)

Andy Grunwald (00:16:25 - 00:16:34)

Wolfi Gassler (00:16:34 - 00:16:37)

Andy Grunwald (00:16:37 - 00:16:39)

Wolfi Gassler (00:16:40 - 00:17:15)

Andy Grunwald (00:17:15 - 00:17:39)

Wolfi Gassler (00:17:39 - 00:17:56)

Andy Grunwald (00:17:56 - 00:17:57)

Wolfi Gassler (00:17:58 - 00:18:16)

Andy Grunwald (00:18:17 - 00:18:25)

Wolfi Gassler (00:18:25 - 00:19:02)

Andy Grunwald (00:19:02 - 00:19:38)

Wolfi Gassler (00:19:38 - 00:20:27)

Andy Grunwald (00:20:27 - 00:20:28)

Wolfi Gassler (00:20:28 - 00:20:35)

Andy Grunwald (00:20:35 - 00:20:38)

Wolfi Gassler (00:20:38 - 00:20:52)

Andy Grunwald (00:20:53 - 00:21:15)

Wolfi Gassler (00:21:16 - 00:21:24)

Andy Grunwald (00:21:27 - 00:21:31)

Wolfi Gassler (00:21:32 - 00:22:56)

Andy Grunwald (00:22:56 - 00:23:01)

Wolfi Gassler (00:23:01 - 00:23:50)

Andy Grunwald (00:23:51 - 00:24:08)

Wolfi Gassler (00:24:09 - 00:24:54)

Andy Grunwald (00:24:54 - 00:25:05)

Wolfi Gassler (00:25:05 - 00:25:14)

Andy Grunwald (00:25:14 - 00:25:50)

Wolfi Gassler (00:25:51 - 00:26:59)

Andy Grunwald (00:26:59 - 00:27:03)

Wolfi Gassler (00:27:03 - 00:27:04)

Andy Grunwald (00:27:05 - 00:27:26)

Wolfi Gassler (00:27:26 - 00:27:28)

Andy Grunwald (00:27:29 - 00:28:01)

Wolfi Gassler (00:28:01 - 00:29:33)

Andy Grunwald (00:29:34 - 00:29:59)

Wolfi Gassler (00:29:59 - 00:30:06)

Andy Grunwald (00:30:06 - 00:30:07)

Wolfi Gassler (00:30:07 - 00:30:36)