Eine AI-Native-Firma aufbauen

• Anfang der 2020er Jahre konzentrierte sich viel Aufmerksamkeit auf generative KI
  • Im Mittelpunkt standen vor allem Diskussionen darüber, wie generative KI-Tools uns prägen würden und welche Auswirkungen sie auf Schreiben, Programmieren, Animation und unseren Informationskonsum haben würden
  • Über die Form unserer Tools selbst wurde jedoch nicht besonders viel gesprochen
• Ende der 1960er Jahre standen Informationssysteme vor dem Problem, dass die Suche nach relevanten Informationen aufgrund der riesigen Datenmengen immer kostspieliger wurde
• In den 1980er- und 90er-Jahren wurden relationale Datenbanken zur dominierenden Lösung
  • Sie boten intuitives Indexing und gewährleisteten effiziente Abfragen
  • Relationale Datenbanken ermöglichten es, Daten als Sammlung von Tabellen mit strukturierten Beziehungen darzustellen
  • Über Abfragesprachen wie SQL machten sie einen schnelleren Datenabruf möglich
• Im Verlauf der Weiterentwicklung der Datenbankarchitektur festigten bestimmte Unternehmen wie IBM, Oracle, Sun Microsystems und MongoDB ihre Position in den jeweils entstehenden Märkten
• Oracle führte zwar die Welt der relationalen Datenbanken an, doch die Art und Weise, wie Menschen Informationen speichern und darauf zugreifen, hat sich weiter verändert
  • Mit jeder neuen Aufgabe entwickelten Menschen neue Architekturen, um sie zu bewältigen
• Die jüngste Evolution von Datenbanken entstand aus dem Bedarf, unstrukturierte Daten zu verarbeiten
  • In den vergangenen mehr als 50 Jahren waren Schemata überwiegend auf strukturierte Datenbeziehungen ausgerichtet
  • Doch immer mehr Menschen benötigten Tools, die mit Datenmehrdeutigkeit deutlich besser umgehen konnten
  • Daraus entstanden Vektordatenbanken
• Transformer-basierte Large Language Models (LLMs) wie GPT können langfristige Abhängigkeiten in Texten erfassen
  • Die Fähigkeit zum Verständnis langer Texte aufrechtzuerhalten, kann jedoch rechnerisch teuer sein
  • Vektordatenbanken können das Kontextfenster solcher Modelle erweitern
• Vektordatenbanken können für AI-Anwendungsfälle zwar leistungsstark sein, sind aber immer noch dumme Infrastruktur, die durch Eingaben und Ausgaben gesteuert wird
  • Ihnen fehlt die Fähigkeit, Daten zu verstehen oder zu interpretieren
  • Sie fungieren lediglich als Speicher, der Daten wie angewiesen speichert und abruft, ohne inhärente Intelligenz oder Kontextbewusstsein
• Mit der Veröffentlichung von GPT-3 im Jahr 2020 wurde es zunehmend möglich, AI nicht nur als Anhang zu Unternehmensprodukten, sondern als deren Kern zu nutzen
  • Die Transformer-Architektur, größere Datenmengen und Leistungsverbesserungen legten die Grundlage für die Entwicklung AI-basierter Produkte
• Mit der wachsenden Zahl und Größe AI-Native-Unternehmen steigt auch der Bedarf an Tools, die AI-basierte Anwendungsfälle unterstützen
  • Die erste Welle AI-zentrierter Unternehmen konzentrierte sich hauptsächlich auf Inferenz mit bestehenden Modellen
• Doch durch leistungsfähigere Modelle, insbesondere leicht zugängliche Open-Source-Modelle, können Unternehmen ihre Fähigkeiten als AI-basierte Businesses deutlich tiefer aufbauen
  • Diese Skalierbarkeit eröffnet eine Welt von Möglichkeiten dafür, wie ein AI-basierter Technologie-Stack aussehen könnte

Die Tools, die uns prägen (The Tools that Shape Us)

• 1967 sagte John M. Culkin, ein Freund von Marshall McLuhan: "Wir formen unsere Tools, und danach formen unsere Tools uns"
  • Beim Aufbau von Technologie ist es nicht anders
  • Die Infrastruktur, die wir zum Erstellen von Software nutzen, hat sich ständig entsprechend unseren Anforderungen weiterentwickelt, und anschließend wird unser Bauen von der Infrastruktur geprägt, die wir geschaffen haben
• Anfang der 2020er Jahre konzentrierte sich viel Aufmerksamkeit auf generative KI
  • Der Fokus lag insbesondere auf den Ergebnissen: erzeugter Text oder Code, gerenderte Bilder, produzierte Deepfakes und synthetisierte Musik
  • Im Mittelpunkt standen Diskussionen darüber, wie diese Tools uns prägen würden und welche Auswirkungen sie auf Schreiben, Programmieren, Animation und unseren Informationskonsum haben würden
  • Diskutiert wurden die vergleichende Leistungsfähigkeit offener und proprietärer Large Language Models, die Risiken von Halluzinationen, die Debatte Plattform vs. Feature sowie die Debatte etablierte Unternehmen vs. Startups
• Über die Form unserer Tools selbst wurde jedoch nicht besonders viel gesprochen
  • Grundsätzlich wurde die Art und Weise, wie wir Technologie aufbauen, immer von der Infrastruktur geprägt, die wir dafür bereitgestellt haben
  • Die Verbreitung von SaaS wurde durch das Internet beschleunigt, die Allgegenwärtigkeit des Smartphones ermöglichte Mobile Development, und Cloud Computing förderte die Skalierbarkeit einer Generation von Anwendungen
• Wie allgegenwärtig AI in Anwendungen wird, hängt von Rechenleistung, Modellfähigkeiten und der Orchestrierung dieser Modelle innerhalb geschäftlicher Anwendungsfälle ab
  • Dieser Text wird sich auf den Orchestrierungsaspekt konzentrieren
  • Einer der zentralen Bausteine bei der Orchestrierung sämtlicher AI-Anwendungsfälle ist die Datenbank eines Unternehmens
  • Der Ort, an dem Daten gespeichert, bearbeitet und aufgerufen werden, ist ein wichtiger Teil des Puzzles
  • Doch wie gezeigt werden soll, ist die Geschichte der Datenbanken größtenteils die Geschichte dummer Infrastruktur
  • Um den Nutzen von AI zu maximieren, müssen Datenbanken so gebaut werden, dass sie Teil der generativen Gleichung werden

Eine Grundlage für Daten (A Base For Data)

• Im Mai 1959 wurde CODASYL (Conference on Data Systems Languages) erstmals einberufen, mit dem Ziel, eine „universelle Sprache zum Erstellen von Business-Applikationen“ zu entwickeln
  • Ende der 1960er standen Informationssysteme angesichts riesiger Datenmengen vor dem Problem, dass die Suche nach relevanten Informationen immer kostspieliger wurde
• Der Einsatz von Mainframe-Computern führte im Allgemeinen mit zunehmender Nutzung zu steigenden MIPS-Kosten (Million Instructions Per Second), bedingt durch Wartung von Applikationen, Patches und Upgrade-Kosten zur Aufrechterhaltung der Performance
  • Aufgrund der Komplexität des Datenbankmanagements, starrer Hierarchien und aufwendiger Abbildung von Navigationsstrukturen benötigten Unternehmen oft technisches Fachwissen, um auf ausgewählte Informationen zuzugreifen; manche Entwickler mussten sogar ganze Programme schreiben, um an relevante Informationen zu gelangen
• 1970 veröffentlichte E. F. Codd „A Relational Model for Large Shared Data Banks“ und schlug damit ein Modell vor, in dem Tabellen über gemeinsame Eigenschaften verknüpft werden konnten (d. h. Primärschlüssel zur Identifikation eindeutiger Datensätze und Fremdschlüssel zur Herstellung von Beziehungen zwischen Tabellen)
  • Dadurch wurde es möglich, Daten aus heterogenen Tabellen mit einer einzigen Query abzurufen
  • Codds relationale Datenbank basierte auf den Beziehungen zwischen Datenelementen und ermöglichte so Flexibilität bei Datenmanipulation und -nutzung
• 1973 begann eine Gruppe von Programmierern im IBM San Jose Research Laboratory mit dem System-R-Projekt, um zu beweisen, dass relationale Datenbanksysteme die für den produktiven Einsatz nötigen vollständigen Funktionen integrieren und dennoch hohe Performance liefern können
  • Das Team entwickelte einen kostenbasierten Optimierer für Datenbankeffizienz, und die aus System R hervorgegangenen Entwicklungen führten später zur Einführung von IBMs erstem relationalen Datenbankprodukt SQL/DS
• In den 1980er- und 1990er-Jahren wurden relationale Datenbanken zur dominierenden Datenbanklösung
  • Sie boten intuitives Indexing und sorgten für effiziente Queries
  • Relationale Datenbanken ermöglichten es, Daten als Sammlung von Tabellen mit strukturierten Beziehungen darzustellen
  • Über Query-Sprachen wie SQL ermöglichten sie eine schnellere Datenabfrage
• Relationale Datenbanken wurden unter der Annahme entwickelt, dass sie auf einer einzelnen Maschine laufen
  • Mit der breiten Internet-Adoption in den 1990er- und 2000er-Jahren strömten jedoch enorme Datenmengen herein, was zu Workloads führte, die für einen einzelnen Computer zu groß waren
  • Traditionelle SQL-Datenbanken waren für den Betrieb auf einem einzelnen Server ausgelegt, und Nutzer mussten die physische Hardware entsprechend der Speicherkapazität erweitern, was sich für Unternehmen mit größeren Workloads als sehr kostspielig erwies
• In den 2010er-Jahren nahmen Daten und Nutzerzahlen für OLTP (Online Transaction Processing) exponentiell zu, was zu einem breiten Anstieg verteilter Datenbanken, Data Warehouses und OLAP (Online Analytical Processing) führte
• Relationale Datenbanken und SQL waren für das benötigte Ausmaß und die Komplexität von Applikationen nicht länger geeignet, und NoSQL-Datenbanken entstanden als Mittel zur Leistungssteigerung — unter Aufgabe von ACID-Eigenschaften
  • Relationale Datenbanken konnten strukturierte Daten speichern und manipulieren, doch angesichts des Overheads von Joins und der Kosten von CRUD-Operationen war es schwierig, Beziehungen zwischen Daten aufrechtzuerhalten
  • Relationale Datenbanken eigneten sich gut für relationale Daten mit logischen oder diskreten Anforderungen, waren aber in der Regel auf Legacy-Systeme zugeschnitten, die speziell für relationale Strukturen entwickelt worden waren
  • NoSQL entstand als Möglichkeit, unstrukturierte Big Data zu verarbeiten, und bot Entwicklern über einen nicht relationalen Ansatz Datenpersistenz
  • Anstatt SQL als primäre Query-Sprache zu verwenden, bot NoSQL Zugriff über APIs und gewährleistete damit höhere Skalierbarkeit, verteiltes Computing, geringere Kosten und Schema-Flexibilität
  • NoSQL-Datenbanken arbeiten mit effizienten Architekturen, die sich horizontal skalieren lassen; um Speicher- oder Rechenkapazität zu erhöhen, braucht es daher nur mehr Server oder Cloud-Instanzen
  • Für Unternehmen mit Daten-Workloads, die eine schnellere Verarbeitung oder Analyse unstrukturierter Daten erfordern, wurden NoSQL-Datenbanken bevorzugt

Die ursprünglichen Datenbankkriege

• Während sich Datenbankarchitekturen weiterentwickelten, konnten sich bestimmte Unternehmen in den jeweiligen entstehenden Märkten festsetzen
  • Kurz nach der Veröffentlichung von System R durch IBM las der 33-jährige Larry Ellison dieselbe Arbeit von Codd über relationale Datenbanken
  • Ellison und seine beiden Mitgründer wollten ein Unternehmen aufbauen, das mit System R kompatibel war, doch IBM machte das äußerst schwierig
  • Infolgedessen baute das Trio sein Geschäft rund um ein neues Flaggschiffprodukt auf: Oracle Databases
  • Seitdem ist Oracles Datenbank zum führenden Produkt geworden; im Mai 2024 lag ihr Marktanteil bei etwa 28,7 %
• In den Jahren vor Oracles IPO 1986 trat ein weiteres Unternehmen in den Datenbankmarkt ein
  • Sun Microsystems begann 1982 mit dem Verkauf verschiedener Computerkomponenten, wurde aber durch Beiträge wie die Programmiersprache Java und das Network File System bekannt
  • Entscheidend ist, dass Sun Microsystems 2008 MySQL übernahm, ein Open-Source-Datenbankmanagementsystem
  • Nur zwei Jahre später übernahm Oracle Sun Microsystems einschließlich MySQL
  • Fast 15 Jahre später, im Mai 2024, sind die führenden Datenbanken Oracle (Marktanteil 28,7 %) und MySQL (etwa 17,3 %)
• Obwohl Oracle die Welt relationaler Datenbanken dominierte, hat sich die Art und Weise, wie Menschen Informationen speichern und darauf zugreifen, weiter verändert
  • Mit jeder neuen Aufgabe entwickelten Menschen neue Architekturen, um sie zu bewältigen
  • Von Dokumentenspeichern wie MongoDB (2007) und Databricks (2013) über Zeitreihendatenbanken wie InfluxDB (2013) und Prometheus (2012) bis hin zu Graphdatenbanken wie Neo4j (2007) und Cosmos (2017) wächst die Liste spezialisierter Datenbanken ständig weiter
  • Mit dem stetigen Rückgang der Beliebtheit relationaler Datenbanken entstanden unterschiedliche Lösungen für diese neuen Nischenanforderungen
• Die jüngste Entwicklung bei Datenbanken entstand aus der Notwendigkeit, unstrukturierte Daten zu verarbeiten
  • In den vergangenen mehr als 50 Jahren waren Schemata hauptsächlich auf strukturierte Datenbeziehungen ausgerichtet
  • Doch immer mehr Menschen brauchten Werkzeuge, die mit Datenmehrdeutigkeit deutlich besser umgehen konnten
  • So entstanden Vektordatenbanken

Der Aufstieg der Vektordatenbanken

• Mit der breiten Verbreitung großer Sprachmodelle (LLMs) und generativer AI haben sich Vektordatenbanken als Werkzeuge etabliert, die unstrukturierte multimodale Daten verarbeiten können
  • Während klassische relationale Datenbanken (Postgres, MySQL) am besten für strukturierte Schemata geeignet sind, eignen sich Vektordatenbanken für das Speichern und Abfragen von Vektor-Embeddings (numerische Darstellungen von Daten, die Bedeutung relativ zu den Gewichten eines Sprachmodells enthalten)
  • Anstelle der in relationalen Datenbanken üblichen Zeilen und Spalten stellen Vektordatenbanken Daten als Punkte in einem mehrdimensionalen Raum dar und gleichen Daten auf Basis von Ähnlichkeit statt exakter Werte ab
• Je nach Embedding-Modell können Daten in unterschiedlichen Vektorräumen und mit verschiedenen Dimensionen dargestellt werden
  • Vektor-Embeddings erfassen die Bedeutung von Datenpunkten und ermöglichen es, ähnliche Objekte zu finden, indem in einer Vektordatenbank die nächstgelegenen Objekte gesucht werden
• Beispielsweise ordnet Word2Vec Wörter Vektoren zu und hilft dabei, Bedeutung, semantische Ähnlichkeit und kontextuelle Beziehungen zu anderen Texten zu erfassen
  • Dieser Algorithmus verwendet flache neuronale Netze, um aus einem größeren Textkorpus die Bedeutung eines bestimmten Wortes abzuleiten, und identifiziert über logistische Regression Synonyme
  • Es gibt auch Methoden wie Singulärwertzerlegung (SVD) und Hauptkomponentenanalyse (PCA), die beim Extrahieren von Embeddings helfen, ohne auf tiefe neuronale Netze angewiesen zu sein
• Distanzmetriken helfen dabei, die relative „Entfernung“ zwischen Punkten im Vektorraum zu bestimmen; gängige Verfahren sind euklidische Distanz, Manhattan-Distanz, Kosinus-Distanz und Jaccard-Ähnlichkeit
  • K-Nearest Neighbors (KNN) und Approximate Nearest Neighbors (ANN) helfen, Ähnlichkeitssuchen für Bilder, Videos oder andere multimodale Eingaben zu vereinfachen und die Laufzeit zu verbessern
• Reine Vektordatenbanken wie Weaviate, Chroma, Qdrant und Pinecone helfen Entwicklern beim Umgang mit großen Datenmengen, insbesondere wenn es darum geht, die Suche über unstrukturierte Eingaben zu erleichtern
  • Anders als klassische relationale Datenbanken oder NoSQL-Datenbanken sind Vektordatenbanken speziell für die Verarbeitung von Vektor-Embeddings ausgelegt
  • Während herkömmliche Datenbanken Daten als Skalare speichern, speichern Vektordatenbanken ausschließlich Vektoren und nutzen Indexierungstechniken wie Quantisierung und Clustering, um Suchvorgänge zu optimieren
• Transformer-basierte LLMs wie GPT können langfristige Abhängigkeiten in Texten erfassen
  • Allerdings kann es rechnerisch teuer werden, das Verständnis für lange Texte aufrechtzuerhalten
  • Moderne LLMs können globale Abhängigkeiten zwischen Token-Paaren über die Eingabe hinweg erfassen, doch Zeit- und Raumkomplexität führen zu Problemen beim Rechenaufwand und begrenzen dadurch sowohl die Länge des Eingabetexts beim Training als auch das effektive Kontextfenster bei der Inferenz
• In mehrdimensionalen Fällen ist relative Positionskodierung schwer umzusetzen, und die meisten Ansätze zur Kodierung relativer Positionen erfordern starke Positions-Embedding-Mechanismen, die während der Inferenz zu Leistungseinbußen beitragen
  • Auch wenn die Textlänge zunimmt, können Vektordatenbanken wichtig sein, um als Langzeitgedächtnis des Modells zu fungieren
  • Mit Vektordatenbanken lassen sich Aufgaben wie Textvervollständigung oder Zusammenfassung vereinfachen, bei denen der vollständige Satzkontext für die Erzeugung präziser Ergebnisse erforderlich sein kann
• Vektordatenbanken können Retrieval-Augmented Generation (RAG) unterstützen, wobei die Vektordatenbank genutzt werden kann, um den an das LLM übergebenen Prompt zu verbessern, indem sie zusätzlichen Kontext zusammen mit der ursprünglichen Anfrage bereitstellt
  • Da LLMs häufig auf selbstüberwachtem Lernen basieren, haben sie oft Schwierigkeiten mit domänenspezifischen Aufgaben, die spezielles Wissen oder höhere Genauigkeitsschwellen erfordern
  • RAG kann helfen, Halluzinationen zu reduzieren, die durch fehlenden Kontext für die jeweilige Anfrage entstehen können, und zugleich nachvollziehbar, verfolgbar oder erklärbar machen, wie eine Antwort zustande gekommen ist
• Entwickler können Wissensgraphen und Vektorsuche kombinieren, um LLMs über die Daten hinaus zu erweitern, auf denen sie trainiert wurden
  • Tools wie GraphRAG von Microsoft Research erleichtern die Prompt-Erweiterung bei der Suche in privaten Datensätzen
  • Da grundlegendes RAG oft Schwierigkeiten hat, verdichtete semantische Konzepte über große Datensammlungen ganzheitlich zu verstehen, erstellen Tools wie LlamaIndex und GraphRAG Wissensgraphen auf Basis privater Datensätze
• Je nach konkreten Anforderungen oder Anwendungsfall kann für Entwickler die Nutzung von Wissensgraphen gegenüber RAG sinnvoller sein
  • Vektordatenbanken eignen sich für Ähnlichkeitssuche und sind am besten für Dokumenten- oder Bildsuche sowie die Erstellung von Empfehlungen geeignet, während Wissensgraphen sich für Schlussfolgerungen eignen (besonders nützlich bei der Datenerfassung, bei der Extraktion von Entitäten zusammen mit miteinander verknüpften Beziehungen und beim Traversieren dieser Beziehungen)
• Für Anwendungen, die Echtzeit- oder Beinahe-Echtzeit-Datenverarbeitung benötigen, können Vektordatenbanken wegen ihrer Abfragen mit geringerer Latenz bevorzugt werden
• Durch das Erfassen und Speichern von Embeddings ermöglichen Vektordatenbanken schnellere Suchvorgänge bei Ähnlichkeitssuchen, indem sie eingegebene Prompts mit ähnlichen Embeddings abgleichen
• Ähnlichkeitsranking unterstützt eine Vielzahl von Machine-Learning-Aufgaben, von Empfehlungssystemen über semantische Suche und Bilderkennung bis hin zu weiteren Anwendungen der natürlichen Sprachverarbeitung
• Vektordatenbanken spielen eine wichtige Rolle bei der Verbesserung der Leistung von LLMs, indem sie die effiziente Speicherung und Suche von Vektor-Embeddings ermöglichen
  • Dadurch kann natürliche Sprache in großem Maßstab automatisch verstanden werden
• Vektor-Embeddings stellen jedoch nur eine N+1-Innovation dar
  • Es handelt sich um ein früheres Datenformat wie relationale oder Zeitreihendaten
• Legacy-Datenbankanbieter haben begonnen, Vektorfunktionen einzuführen, etwa Atlas Vector Search von MongoDB, die Vektordatenbank von SingleStore und den Vector Search Index von Neo4J
• Auch wenn Vektordatenbanken für AI-Anwendungsfälle leistungsstark sein können, bleiben sie letztlich dumme Infrastruktur, die von Ein- und Ausgaben gesteuert wird
  • Ihnen fehlt die Fähigkeit, Daten zu verstehen oder zu interpretieren
  • Sie dienen lediglich als Speicher, der Daten nach Anweisung speichert und abruft, ohne inhärente Intelligenz oder Situationsbewusstsein
• Für moderne AI-basierte Anwendungen wird das allein nicht ausreichen
  • Unternehmen bauen zunehmend mit AI-Modellen im Kern
  • Daher wird die Infrastruktur dieselben intelligenten Fähigkeiten benötigen, wenn Anwendungen zunehmend intelligentere Funktionen zeigen sollen

KI-native Unternehmen der ersten Generation

• Seit die Wissenschaft 1956 am Dartmouth College erstmals mit der Erforschung künstlicher Intelligenz begann, haben praktische Anwendungsfälle dieses Feld vorangetrieben
  • So entwickelte Joseph Weizenbaum Ende der 1960er Jahre ein Computerprogramm namens ELIZA, bei dem ein einfacher, auf Musterabgleich basierender Ansatz zur Simulation von Gesprächen für Dialoge verwendet wurde, die einer primitiven Therapie ähnelten (der erste Chatbot)
• Während des größten Teils der Geschichte von AI in geschäftlichen Anwendungsfällen verlief die Verbesserung von AI schrittweise
• Bevor der Begriff AI populär wurde, wurde häufiger der Begriff Machine Learning verwendet, um dieselbe Technologie zu bezeichnen
  • Das heißt: „statistische Algorithmen, die aus Daten lernen und auf ungesehene Daten generalisieren können und Aufgaben ohne explizite Anweisungen ausführen können“
• In der öffentlichen Wahrnehmung erreichte AI am 30. November 2022 einen Wendepunkt, als OpenAI ChatGPT veröffentlichte, doch aus technischer Sicht hatte dieser Umbruch schon viel früher begonnen
• Im November 2017 erstellte das internationale Regulierungsgremium Financial Stability Board (FSB) einen Überblick über die Auswirkungen von Machine Learning auf Finanzdienstleistungen
  • Unternehmen im Finanzdienstleistungssektor konnten zunehmend Machine Learning einsetzen, um Aufgaben wie die „Bewertung der Kreditqualität“ zu erledigen und damit „zu einem effizienteren Finanzsystem beizutragen“
  • Mit anderen Worten: Es konnte die Effizienz steigern, stellte aber keine existenzielle Notwendigkeit dar
• Gleichzeitig wurde Machine Learning immer besser, und im Mai 2018 veröffentlichte OpenAI eine Studie zur Geschichte der für das Training großer Modelle benötigten Rechenleistung, die zeigte, dass diese seit 2012 alle 3,4 Monate auf das Doppelte gestiegen war — insgesamt also um das 300.000-Fache
• Im darauffolgenden Monat, also im Juni 2018, veröffentlichte OpenAI die erste Einführung in das GPT-Modell
• Zwischen zwei Lagern entstand eine Debatte
  • Einerseits glaubten viele, dass das anhaltende Wachstum immer größerer Modelle dem Gesetz des abnehmenden Ertrags unterliegen würde
  • Das andere Lager, zu dem OpenAI gehörte, glaubte, dass sich die Leistung mit zunehmender Skalierung weiter verbessern würde
• Im Januar 2020 veröffentlichte Jared Kaplan, OpenAI-Forscher und Professor an der Johns Hopkins University, gemeinsam mit anderen die Arbeit „Scaling Laws for Neural Language Models“, in der es heißt:
  • „Die Leistung von Sprachmodellen verbessert sich gleichmäßig und vorhersagbar, wenn Modellgröße, Daten und Rechenleistung angemessen skaliert werden. Wir erwarten, dass größere Sprachmodelle besser abschneiden als aktuelle Modelle und eine höhere Sample-Effizienz aufweisen.“
• Im Mai 2020 veröffentlichte OpenAI das Paper „Language Models are Few-Shot Learners“ zu GPT-3, das eine reibungslose Skalierung der Leistung mit zunehmender Rechenleistung zeigte
• OpenAI stellte außerdem fest, dass mit zunehmender Größe auch die Generalisierungsfähigkeit steigt, und behauptete, dass „die Skalierung großer Sprachmodelle die aufgabenunabhängige Few-Shot-Leistung stark verbessert und dadurch mitunter mit bisherigen State-of-the-Art-Fine-Tuning-Ansätzen konkurrieren kann“
• Der unabhängige Forscher Gwern Branwen formulierte in einem Blogbeitrag die Scaling-Hypothese und schrieb:
  • „GPT-3, das OpenAI im Mai 2020 vorgestellt hat, ist das bislang größte trainierte neuronale Netz und ist um mehr als eine Größenordnung größer ... Entgegen den Erwartungen vieler Menschen (mich selbst eingeschlossen) brachte dieser enorme Größenzuwachs weiterhin die von OpenAI prognostizierten Skalenvorteile, ohne auf die abnehmenden oder gar negativen Erträge zu stoßen, die viele erwartet hatten.“
• Die Überraschung, die Branwen dabei empfand, markierte einen Wandel der Landschaft
• AI konnte zunehmend nicht nur als Anhängsel eines Unternehmensprodukts, sondern als dessen Kern eingesetzt werden
• Die Transformer-Architektur, die wachsende Datenmenge und das höhere Leistungsniveau schufen zusammen die Grundlage für die Entwicklung AI-basierter Produkte
• Kurz nach der Veröffentlichung von GPT-3 im Mai 2020 entwickelten Unternehmen wie Writer und Jasper Copywriting-Produkte, bei denen AI-Modelle im Zentrum des Geschäfts standen
• Unternehmen wie Harvey und EvenUp bauten Legal Tech rund um AI auf
• Unternehmen wie DeepScribe und Freed bauten medizinische Transkription rund um AI auf
• Doch genauso wie neue Anwendungsfälle in der Vergangenheit zur Weiterentwicklung von Datenbanken führten, bedeutete die Entstehung AI-basierter Produkte auch, dass sich die Infrastruktur hinter dem Tech-Stack jedes Unternehmens verändern und anpassen musste

AI-Native Database

• Mit der wachsenden Zahl und Größe AI-basierter Unternehmen steigt auch der Bedarf an Tools, die AI-basierte Anwendungsfälle unterstützen
• Die erste Welle AI-zentrierter Unternehmen konzentrierte sich vor allem auf Inferenz mit bestehenden Modellen
  • Mit zweckgebundenen Workflow-Tools für Anwendungen wie Copywriting, medizinische Transkription und mehr
  • Der Kern des Produkts war der Output, etwa vom Modell generierter Text oder generierte Bilder
• Nach dem DevDay von OpenAI im November 2023 begann sich das Meme „OpenAI ruined my startup“ zu verbreiten
  • Bestimmte spezialisierte GPTs oder AI-Agenten schienen die Rolle dieser frühen AI-basierten Startups zu übernehmen, weil sie sich auf die Inferenz bestehender Modelle konzentrierten
  • OpenAI wurde damit unbeabsichtigt sowohl zum Anbieter des Modells als auch der Anwendung
• Innovationen rund um Modellfähigkeiten schritten so schnell voran, dass sie sich für Startups zunehmend wie eine Bedrohung anfühlten
• Umgekehrt ermöglichten leistungsfähigere Modelle — insbesondere leicht zugängliche Open-Source-Modelle — Unternehmen jedoch, ihre Fähigkeiten als AI-basiertes Business tiefer auszubauen
• Einen AI-basierten Tech-Stack aufzubauen bedeutet mehr, als nur Komponenten rund um das Modell hinzuzufügen
  • Wie würde zum Beispiel eine speziell für AI entwickelte Datenbank aussehen?
  • Wenn Inferenz der entscheidende Output ist, darf eine AI-basierte Datenbank nicht nur Daten speichern und abrufen, sondern muss auch kontextbezogene Anweisungen dafür aufnehmen können, was mit den gespeicherten Daten geschehen soll
• Ein Beispiel dafür könnte die Personalisierung von Produktbeschreibungen im E-Commerce sein
  • Eine Vektordatenbank könnte nicht nur Vektor-Embeddings für Produkt-SKUs und Beschreibungen speichern, sondern auch Embeddings für Nutzer-Personas
  • Unter Verwendung all dieser kontextbezogenen Daten in der Datenbank könnte die Infrastruktur für eine Abfrage von Produktbeschreibungen auch eine Abfrage der relevanten Nutzer-Persona auslösen und anschließend eine generative Feedbackschleife nutzen, um auf Basis dieser relevanten Nutzer-Persona die Produktbeschreibung zu verfassen
• Ebenso kann Sprache als generative Feedbackschleife genutzt werden
  • Nutzer könnten zum Beispiel Produktbeschreibungen in verschiedenen Sprachen erzeugen wollen
  • Es können Produktbeschreibungen erzeugt werden, die nicht nur auf den Nutzer zugeschnitten, sondern auch in die vom Nutzer gewählte Sprache übersetzt sind
  • Solche Arten von Anweisungen können direkt in die Datenbank eingebaut werden, da Anwendungsfälle wie generative AI zunehmend zur Kernfunktion von Anwendungen werden
• Die Infrastruktur entsprechend den Anwendungsfällen weiterzuentwickeln, ist nichts Neues
  • Ursprünglich bauten Entwickler mit JavaScript Anwendungen im Browser, um Websites interaktiv und dynamisch zu machen
  • Als Entwickler dann erkannten, dass sie dies auch ins Backend bringen konnten, entstand node.js
  • Danach, als Entwickler immer mehr mobile Anwendungen zu bauen begannen, entstand JSON (JavaScript Object Notation), das dynamischere, reaktivere und datengetriebene Anwendungen ermöglichte
  • MongoDB passte perfekt zu dieser Welle als Unternehmen, das entstand, um den sich wandelnden Infrastrukturbedarf zu adressieren
• Mit AI wiederholt sich die Geschichte
  • Wenn sich die Anforderungen ändern, muss sich die Infrastruktur weiterentwickeln, um diese Anforderungen zu erfüllen
  • Die größte Frage wird sein, welche Art von Unternehmen die Menschen aufbauen wollen und welche Art von Infrastruktur für solche Unternehmen am besten geeignet ist
  • Wie Bob im Interview mit Matthew Lynley sagte:
    • „Ich bin fest davon überzeugt, dass alle Anwendungen der Zukunft AI enthalten werden. In manche Anwendungen wird AI eingestreut sein, bei anderen wird AI im Zentrum der Anwendung stehen. Nimmt man AI heraus, existieren sie nicht mehr. Wenn Sie eine Web-App bauen und AI darüberstreuen wollen, verwenden Sie MongoDB. Vor allem, wenn Sie es ohnehin schon nutzen ... Wenn Sie AI-native Anwendungen bauen wollen, bei denen AI der Kern der Anwendung ist, dann ist es Zeit, Weaviate in Betracht zu ziehen.“
• Künftig werden Unternehmen entscheiden müssen, ob sie Produkte mit AI als Anhängsel bauen wollen — oder, wie Bob sagte, als „sprinkle“ — oder ob AI zum Kern des Produkts werden soll

AI-Native Tech-Stack

• Für Unternehmen, die AI als Kernbestandteil ihres Produkts aufbauen wollen, ist bestehende Infrastruktur wahrscheinlich nicht geeignet
  • Mit Legacy-Tools werden Datenspeicherung, -aufbereitung und -ausführung in einem Silo aufgebaut, während Automatisierung in einem anderen Silo aufgebaut wird
  • Der Nachteil dieses Ansatzes ist, dass Kontext verloren geht, etwa in generativen Feedback-Loops, die das Produkt besser informieren und verbessern könnten
• Bei Unternehmen, die aus einem „AI-adjacent“-Stack kommen, ist die Inferenz eines bestimmten Modells oft durch das Kontextfenster begrenzt
  • Manche glauben, dass Vektor-Datenbanken ersetzt werden könnten, wenn die Kapazität eines gegebenen Kontextfensters wächst
  • Wahrscheinlicher ist jedoch das umgekehrte Szenario: dass sich Vektor-Datenbanken so weiterentwickeln, dass sie das Kontextfenster ersetzen können
  • Vektor-Embeddings sind für generative Modelle äußerst wichtig, und die Infrastruktur für generative Ergebnisse muss Vektor-Embeddings als erstklassigen Bestandteil behandeln
• Statt einfach nur die Größe des Kontextfensters zu erhöhen, lassen sich Vektor-Datenbanken in das Modell integrieren, um das kontextuelle Verständnis des Kontextfensters mit der Zuverlässigkeit und Skalierbarkeit einer Datenbank zu verbinden
  • Insbesondere gilt: Je allgemeiner ein Modell ist, desto geringer ist die Wahrscheinlichkeit, dass es für eine bestimmte Aufgabe maßgeschneidert ist
  • AI-basierte Vektor-Datenbanken werden spezifischere Funktionen ermöglichen
• Allgemeine Modelle wie GPT-4 wurden so entwickelt, dass sie Wissen bewusst verallgemeinern
  • Wenn ein Produkt auf ein wenig einfaches Fine-Tuning angewiesen ist, wird das Basismodell nicht der einzigartig wertvolle Teil dieses Geschäfts sein
  • Der Aufbau eines AI-basierten Produkts wird neben der Nutzung von Modellen auch bedeuten, das Produkt rund um einen enger integrierten Stack aufzubauen
  • Dieser Stack wird die Größenordnung einer Datenbank und die Fähigkeiten eines Modells bereitstellen und dadurch leistungsfähigere Produkte hervorbringen

[savvykang]

Ich hoffe, dass noch mehr Beispiele für die Erstellung von Vektor-Embeddings und Einsatzfälle für Vector-DBs auftauchen, damit sich ein standardisierter Workflow herausbildet. Muss man dafür wohl etwa ein Jahr warten?