Das Entwicklungstempo im Bereich der Large Language Models (LLM) ist in den letzten Monaten explodiert und einer der interessantesten Handlungsstränge war der schnelle Wandel hin zu einem neuen Technologie-Stack, um ein völlig neues Interaktionsmuster mit diesen Sprachmodellen zu unterstützen. In diesem Blogbeitrag werden wir die Änderungen untersuchen, die im LLM-Tech-Stack stattfinden, und was dies für Entwickler bedeutet.

Der bestehende NLP-Tech-Stack

Bis vor kurzem haben sich NLP-Entwickler auf einen Technologie-Stack verlassen, der für NLP-Aufgaben wie Textklassifizierung, Erkennung benannter Entitäten und Disambiguierung benannter Entitäten optimiert ist. Dieser Tech-Stack besteht im Allgemeinen aus einer Datenvorverarbeitungspipeline, einer Pipeline für maschinelles Lernen und verschiedenen Datenbanken zum Speichern von Einbettungen und strukturierten Daten. Diese Architektur funktionierte gut, um große Mengen an Tripeln, Worteinbettungen, Satzeinbettungen, Sequenz-zu-Sequenz-Ausgaben, Sprachmodellwahrscheinlichkeiten, Aufmerksamkeitsgewichtungen und mehr zu generieren. Entwickler speichern diese strukturierten Ausgaben normalerweise in ElasticSearch-, Postgres- oder Neo4j-Datenbanken, die sie als Wissensgraphen verwenden, den Benutzer (oder Dienste) abfragen können.

Diese Architektur eignete sich gut für die Erstellung hochzuverlässiger strukturierter Daten, die in Unternehmenssystemen eingesetzt werden konnten, um Schlüsselprozesse zu automatisieren (z. B. Dokumente klassifizieren, Entitäten und Beziehungen zwischen Entitäten finden usw.). Allerdings hatten sie Schwierigkeiten, eine breite Akzeptanz zu erreichen, da sie sich nur langsam durchsetzten (große Mengen an gekennzeichneten Daten und einiges an Feinabstimmung des Modells erforderten); teuer im Betrieb (häufig verfügen diese Architekturen über mehr als drei Dutzend Modelle in einer Pipeline/einem System); und die Aufnahme- und Modellpipelines waren anfällig für neue Dokumentlayouts und Datentypen.

Der aufstrebende LLM-Tech-Stack

Seit Herbst 2022 entsteht ein neuer Tech-Stack, der das volle Potenzial von LLMs ausschöpfen soll. Im Gegensatz zum vorherigen Tech-Stack zielt dieser darauf ab, die Textgenerierung zu ermöglichen – die Aufgabe, bei der moderne LLMs im Vergleich zu früheren Modellen des maschinellen Lernens besonders gut sind. Dieser neue Stack besteht aus vier Säulen: einer Datenvorverarbeitungspipeline, Einbettungsendpunkten + Vektorspeicher, LLM-Endpunkten und einem LLM-Programmierframework. Es gibt mehrere große Unterschiede zwischen dem älteren und dem neuen Tech-Stack. Erstens: Der neue Tech-Stack ist nicht so sehr auf Wissensgraphen angewiesen, die strukturierte Daten (z. B. Tripel) speichern, da in LLMs wie ChatGPT, Claude und Flan T-5 weit mehr Informationen kodiert sind als in früheren Modellen wie GPT 2. Zweitens: Der neuere Tech-Stack verwendet einen handelsüblichen LLM-Endpunkt als Modell. anstelle einer benutzerdefinierten ML-Pipeline (zumindest für den Anfang). Dies bedeutet, dass Entwickler heute viel weniger Zeit damit verbringen, spezielle Modelle zur Informationsextraktion zu trainieren (z. B. Erkennung benannter Entitäten, Beziehungsextraktion und Stimmung) und Lösungen in einem Bruchteil der Zeit (und Kosten) entwickeln können.

Datenvorverarbeitungspipeline : Die erste Säule des neuen Tech-Stacks ist gegenüber dem älteren Stack weitgehend unverändert: die Datenvorverarbeitungspipeline. Dieser Schritt umfasst Konnektoren zum Aufnehmen von Daten, wo auch immer sie sich befinden (z. B. S3-Bucket oder ein CRM), eine Datentransformationsschicht und nachgelagerte Konnektoren (z. B. zu einer Vektordatenbank). Oftmals sind die wertvollsten Informationen, die in ein LLM eingespeist werden sollen, auch am schwierigsten zu bearbeiten (PDFs, PPTXs, HTML usw.), aber auch Dokumente, in denen der Text leicht zugänglich ist (z. B. DOCX), enthalten Informationen, die Benutzer nicht verwenden Sie möchten nicht an den Inferenzendpunkt gesendet werden (z. B. Werbung, rechtliche Hinweise usw.).

In der Vergangenheit wurde dieser Schritt von Datenwissenschaftlern für jede Anwendung von Hand erstellt. Abhängig von den beteiligten Datentypen können sie handelsübliche OCR-Modelle und Dutzende bis Hunderte benutzerdefinierter regulärer Ausdrücke verwenden, um Daten in natürlicher Sprache für die Verarbeitung in einer nachgelagerten Pipeline für maschinelles Lernen umzuwandeln und zu bereinigen. Bei Unstructured entwickeln wir Open-Source-Tools, um diesen Vorverarbeitungsschritt zu beschleunigen. Dabei nutzen wir eine Reihe von Computer-Vision-Dokumentsegmentierungsmodellen sowie NLP-Modelle, Python-Skripte und reguläre Ausdrücke, um kritische Dokumentelemente (z. B Überschriften, Fließtext, Kopf-/Fußzeilen, Listen und mehr).

Embeddings Endpoint und Vector Store:Die Verwendung eines Embeddings-Endpunkts und eines Vektorspeichers stellt eine bedeutende Weiterentwicklung der Art und Weise dar, wie Daten gespeichert und abgerufen werden. Bisher wurden Einbettungen hauptsächlich für Nischenaufgaben wie das Clustering von Dokumenten verwendet. In der neuen Architektur ermöglicht die Speicherung von Dokumenten und deren Einbettungen in einer Vektordatenbank jedoch kritische Interaktionsmuster durch den LLM-Endpunkt (mehr dazu weiter unten). Einer der Hauptvorteile dieser Architektur ist die Möglichkeit, Roheinbettungen direkt zu speichern, anstatt sie in ein strukturiertes Format zu konvertieren. Dies bedeutet, dass die Daten in ihrem natürlichen Format gespeichert werden können, was schnellere Verarbeitungszeiten und einen effizienteren Datenabruf ermöglicht. Darüber hinaus kann dieser Ansatz die Arbeit mit großen Datensätzen erleichtern, da er die Datenmenge reduzieren kann, die während des Trainings und der Inferenz verarbeitet werden muss.

Durch das Generieren und Speichern von Dokumenteinbettungen zusammen mit JSON-Versionen der Dokumente selbst entsteht ein einfacher Mechanismus für die LLM-Schnittstelle zum Vektorspeicher. Dies ist besonders nützlich für Anwendungen, bei denen eine Echtzeitverarbeitung erforderlich ist, wie beispielsweise Chatbots. Durch die Minimierung der für den Datenabruf erforderlichen Zeit kann das System schneller reagieren und ein besseres Benutzererlebnis bieten. Ein weiterer Vorteil der Verwendung der Einbettungen (und des Dokumentindex) und des Vektorspeichers besteht darin, dass dadurch Techniken wie Transferlernen einfacher implementiert werden können, um eine effizientere Feinabstimmung und eine bessere Leistung zu ermöglichen.

LLM-Endpunkt : Die dritte Säule des neuen Tech-Stacks ist der LLM-Endpunkt. Dies ist der Endpunkt, der Eingabedaten empfängt und LLM-Ausgaben erzeugt. Der LLM-Endpunkt ist für die Verwaltung der Modellressourcen, einschließlich Speicher und Rechenleistung, sowie für die Bereitstellung einer skalierbaren und fehlertoleranten Schnittstelle zur Bereitstellung der LLM-Ausgabe an nachgelagerte Anwendungen verantwortlich.

Obwohl die meisten LLM-Anbieter mehrere verschiedene Arten von Endpunkten anbieten, beziehen wir uns damit auf die Textgenerierungsendpunkte. Wie oben beschrieben, handelt es sich dabei um die neue technologische Möglichkeit, die vielen neuen Anwendungen zugrunde liegt (im Vergleich zu traditionelleren ML-Pipelines). Das ist ein wenig vereinfacht, aber die Schnittstelle, die diese LLM-Endpunkte bereitstellen, ist ein Textfeld als Eingabe und ein Textfeld als Ausgabe.

LLM-Programmier-Framework : Die letzte Säule des neuen Tech-Stacks ist ein LLM-Programmier-Framework. Diese Frameworks bieten eine Reihe von Tools und Abstraktionen zum Erstellen von Anwendungen mit Sprachmodellen. Bei LangChain ist es genau das Framework, an dessen Aufbau wir arbeiten. Diese Frameworks entwickeln sich schnell weiter, was ihre Definition erschweren kann. Dennoch konvergieren wir bei einer Reihe von Abstraktionen, auf die wir im Folgenden näher eingehen.

Eine große Funktion dieser Frameworks ist die Orchestrierung aller verschiedenen Komponenten. Bisher sind im modernen Stack folgende Komponententypen aufgekommen: LLM-Anbieter (siehe Abschnitt oben), Einbettungsmodelle, Vektorspeicher, Dokumentlader und andere externe Tools (Google-Suche usw.). In LangChain bezeichnen wir Möglichkeiten, diese Komponenten zu kombinieren, als Ketten. Wir haben zum Beispiel Ketten für die Qualitätssicherung über einen Vektorspeicher, Ketten für die Interaktion mit SQL-Datenbanken usw.

Alle diese Ketten beinhalten irgendwann den Aufruf des Sprachmodells. Beim Aufruf des Sprachmodells besteht die größte Herausforderung darin, die Eingabeaufforderung zu konstruieren, die an das Sprachmodell übergeben werden soll. Bei diesen Eingabeaufforderungen handelt es sich häufig um eine Kombination aus Informationen aus anderen Komponenten und einer Basis-Eingabeaufforderungsvorlage. LangChain bietet eine Reihe von Standard-Eingabeaufforderungsvorlagen für den Einstieg in diese Ketten, wir konzentrieren uns aber auch auf den Aufbau des LangChainHub – einen Ort, an dem Benutzer diese Eingabeaufforderungen teilen können.

Offene Fragen:

Der beste Weg, Daten zu indizieren: Derzeit nutzt jeder größtenteils Vectorstores als primäre Möglichkeit, Daten zu indizieren, sodass LLMs damit interagieren können. Dies ist jedoch nur der erste Schritt zur Definition, wie diese Interaktionen funktionieren sollen. Ein Bereich aktiver Forschung ist das Ausmaß, in dem Wissensgraphen in Verbindung mit Dokumentindizes und deren Einbettungen die Qualität von Schlussfolgerungen aus LLMs weiter verbessern können. Darüber hinaus werden die meisten Unternehmen in absehbarer Zukunft weiterhin qualitativ hochwertige strukturierte Daten (typischerweise in einer Diagrammdatenbank) benötigen, um sie mit vorhandenen Datensätzen und Business-Intelligence-Lösungen zu verknüpfen. Dies bedeutet, dass Unternehmensanwender mittelfristig tatsächlich sowohl auf Vektor- als auch auf Diagrammdatenbanken zurückgreifen können, um bestehende Anwendungen und Arbeitsabläufe zu unterstützen.

Wie Feinabstimmung/Umschulung aussehen wird: Derzeit werden LLM-Programmierframeworks wie LangChain verwendet, um Ihre eigenen Daten mit einem vorab trainierten LLM zu kombinieren. Eine andere Möglichkeit, dies zu tun, besteht darin, das LLM anhand Ihrer Daten zu optimieren. Feinabstimmung hat einige Vor- und Nachteile. Der Vorteil besteht darin, dass ein Großteil dieser Orchestrierung weniger erforderlich ist. Der Nachteil ist jedoch, dass es kostspieliger und zeitaufwändiger ist, alles richtig zu machen, und dass es regelmäßig durchgeführt werden muss, um auf dem neuesten Stand zu bleiben. Es wird interessant sein zu sehen, wie sich diese Kompromisse im Laufe der Zeit entwickeln.

Verschiedene Arten der Verwendung von Einbettungen: Auch wenn das primäre Verwendungsmuster weiterhin darin besteht, Ihre Daten in einer externen Datenbank zu behalten, anstatt sie zu verfeinern, gibt es andere Möglichkeiten, sie mit LLMs zu kombinieren als die aktuellen Ansätze (die alle die Übergabe an die Eingabeaufforderung beinhalten). ). Am spannendsten sind Ansätze wie RETRO , die Einbettungen für Dokumente abrufen, sich dann aber direkt um diese Einbettungen kümmern, anstatt den Text als Eingabeaufforderungen weiterzugeben. Während diese Modelle hauptsächlich in Forschungsumgebungen verwendet werden, wird es interessant sein zu sehen, ob sie zum Mainstream werden und wie sich dies auf LLM-Programmierrahmen auswirkt.

Abschluss

Der Übergang zu diesem neuen LLM-Tech-Stack ist eine spannende Entwicklung, die es Entwicklern ermöglichen wird, leistungsfähigere NLP-Anwendungen zu erstellen und bereitzustellen. Der neue Stack ist effizienter, skalierbarer und benutzerfreundlicher als der alte Stack und erschließt das volle Potenzial von LLMs. Wir können in den kommenden Monaten und Jahren mit weiteren Innovationen in diesem Bereich rechnen, da Entwickler weiterhin neue Wege finden, die Leistungsfähigkeit von LLMs zu nutzen.