Eine neue Architektur für LLM-Anwendungen

• Von a16z zusammengestellte „Referenzarchitektur für den LLM-App-Stack“

Emerging LLM App Stack

Kontextuelle Daten

• Datenpipelines: Databricks, Airflow, Unstructured,..
• Embedding-Modell: OpenAI, Cohere, Hugging Face
• Vektordatenbank: Pinecone, Weaviate, Chroma, pgvector

Few-shot-Beispiele für Prompts

• Playground: OpenAI, nat.dev, Humanloop
• Orchestrierung: Pytion/DIY, LangChain, LlamaIndex, ChatGPT
• APIs/Plugins: Serp, Wolfram, Zapier,...

Abfrage & Ausgabe

• App-Hosting: Vercel, Steamship, Streamlit, Modal
• LLM-Cache: Redis, SQLite, GPTCache
• Logging/LLMops: Weights & Biases, MLflow, PromptLayer, Helicone
• Validierung: Guardrails, Rebuff, Guidance, LMQL

LLM-APIs und Hosting

• Proprietäre API: OpenAI, Anthropic
• Offene API: Hugging Face, Replicate
• Cloud-Anbieter: AWS, GCP, Azure, Coreweave
• Meinungsstarke Cloud: Databricks, Anyscale, Mosaic, Modal, Runpod,...

Designmuster: In-Context Learning

• In-Context Learning: LLMs ohne Fine-Tuning unverändert zu verwenden und dabei intelligentes Prompting sowie Bedingungen auf Basis einiger „kontextueller“ Daten zu nutzen
• Beispiel: Wenn man einen Chatbot bauen will, der Fragen zu juristischen Dokumenten beantwortet, könnte man ihn naiv erstellen, indem man einfach alle Dokumente in ChatGPT lädt und dann Fragen stellt. Das ist aber nur bei kleinen Datensätzen möglich. Selbst das größte Modell von ChatGPT kann nur etwa 50 Seiten verarbeiten.
  Beim In-Context Learning werden nur relevante Dokumente gesendet und daraus Antworten erzeugt
• Daher besteht es aus dem folgenden dreistufigen Workflow
  • Schritt 1. Datenvorverarbeitung / Embedding
  • Schritt 2. Prompt-Erstellung / Retrieval relevanter Dokumente aus der Vektor-DB
  • Schritt 3. Prompt-Ausführung / Inferenz
• Das wirkt nach viel Arbeit, ist aber deutlich einfacher, als das LLM selbst zu trainieren und feinzujustieren

Schritt 1. [Data preprocessing / embedding]

→ Kontextuelle Daten durchlaufen die Datenpipeline, gehen durch das Embedding-Modell und werden in der Vektordatenbank gespeichert

Kontextuelle Daten

• Textdokumente, PDFs, CSVs und SQL-Tabellen
• Meistens werden für das Laden und Transformieren der Daten weiterhin bestehende ETL-Tools (Databricks, Airflow) verwendet
• Teilweise kommen Dokumentenlader zum Einsatz, die in Orchestrierungs-Frameworks wie LangChain oder LlamaIndex integriert sind
• Dieser Teil des Stacks ist aus unserer Sicht noch vergleichsweise wenig entwickelt, und es gibt Chancen für speziell für LLM-Apps gebaute Data-Replication-Lösungen

Embeddings

• Die meisten Entwickler nutzen die OpenAI API (text-embedding-ada-002-Modell)
  • Sie ist einfach zu verwenden, liefert vernünftig gute Ergebnisse und wird zunehmend günstiger
• Einige große Unternehmen prüfen Cohere. In bestimmten Szenarien bietet es bessere Leistung
• Entwickler, die Open Source bevorzugen, nutzen standardmäßig die Sentence-Transformers-Bibliothek von Hugging Face.
• Außerdem ist es möglich, verschiedene Arten von Embeddings zu erzeugen, passend zum jeweiligen Use Case
  • Das ist zwar ein Nischenthema, aber ein vielversprechendes Forschungsfeld

Vektordatenbank

• Der wichtigste Teil der Vorverarbeitungspipeline ist die Vektordatenbank
• Sie speichert, vergleicht und durchsucht effizient bis zu zig Milliarden Embeddings (Vektoren)
• Die gängigste Wahl am Markt ist Pinecone
  • Vollständig in der Cloud gehostet und dadurch leicht zu starten
  • Verfügt über viele Funktionen, die große Unternehmen in der Produktion benötigen (gute Performance, SSO, Uptime-SLAs usw.)
• Es gibt jedoch sehr viele verfügbare Vektordatenbanken. Insbesondere:
  • Open-Source-Lösungen wie Weaviate, Vespa und Qdrant
    • Bieten hervorragende Single-Node-Performance und lassen sich auf bestimmte Apps zuschneiden
    • Sind bei erfahrenen AI-Teams beliebt, die bevorzugt maßgeschneiderte Plattformen bauen
  • Lokale Vektorverwaltungsbibliotheken wie Chroma und Faiss
    • Hervorragende Developer Experience
    • Einfach für kleine Apps und Entwicklungsexperimente zu betreiben
    • Nicht als Ersatz für eine vollständige Datenbank im großen Maßstab gedacht
  • OLTP-Erweiterungen wie pgvector
    • Eine gute Lösung für Vektor-Support für Entwickler, die Postgres in jede Datenbankanforderung einbauen wollen, oder für Unternehmen, die den Großteil ihrer Dateninfrastruktur bei einem einzigen Cloud-Anbieter einkaufen
    • Langfristig ist allerdings nicht klar, ob eine enge Kopplung von Vektor- und Skalar-Workloads sinnvoll ist
• Mit Blick nach vorn entwickeln die meisten Open-Source-Vektordatenbank-Unternehmen Cloud-Produkte
  • Unsere Untersuchungen zeigen, dass es sehr schwierig ist, in der Cloud über verschiedene Use Cases hinweg hervorragende Performance zu liefern
  • Daher könnte sich diese Auswahl kurzfristig nicht ändern, langfristig aber sehr wohl
  • Die Kernfrage ist, ob sich Vektordatenbanken wie bei OLTP- und OLAP-Anwendungsfällen auf ein oder zwei bekannte Systeme konsolidieren werden
• Eine weitere Frage ist, wie sich Embeddings und Vektordatenbanken entwickeln werden, wenn die verfügbaren Kontextfenster der meisten Modelle größer werden
  • Es ist verlockend zu sagen, dass Embeddings überflüssig werden, weil man alle Kontextdaten in den Prompt laden kann,
  • Expertenfeedback dazu lautet jedoch, dass Embedding-Pipelines sogar noch wichtiger werden könnten
  • Große Kontextfenster sind ein mächtiges Werkzeug, verursachen aber erhebliche Rechenkosten. Deshalb ist ihre effiziente Nutzung entscheidend
• Wir werden nun verschiedene Arten von Embedding-Modellen sehen, die zum Standard werden, direkt auf Modellrelevanz trainiert sind und von Vektordatenbanken effizient aktiviert und genutzt werden können

Schritt 2. [Prompt construction / retrieval]

• Strategien zur Integration von LLM-Prompting und kontextbezogenen Daten werden immer komplexer und gewinnen als Quelle der Produktdifferenzierung weiter an Bedeutung
• Die meisten Entwickler beginnen neue Projekte mit einfachen Prompts, die entweder aus direkten Anweisungen (Zero-Shot-Prompting) oder einigen Beispielen (Few-Shot-Prompting) bestehen
• Solche Prompts können gute Ergebnisse liefern, erreichen aber oft nicht das Genauigkeitsniveau, das für den produktiven Einsatz erforderlich ist
• Der nächste Schritt beim Prompting besteht darin, die Antwort des Modells in einer gewissen Wahrheitsquelle zu verankern und dem Modell externen Kontext bereitzustellen, auf den es nicht trainiert wurde
• Der Prompt Engineering Guide fasst 12 fortgeschrittene Prompt-Strategien zusammen
• Hier glänzen Orchestrierungs-Frameworks wie LangChain oder LlamaIndex
  • Sie abstrahieren viele Details des Prompt-Chaining
  • Etwa die Anbindung externer APIs, das Abrufen von Kontextdaten aus Vektordatenbanken oder das Beibehalten von Speicher über mehrere LLM-Aufrufe hinweg
  • Außerdem liefern sie Templates für viele gängige Programme
  • Ihr Output ist ein Prompt oder mehrere Prompts, die an das Sprachmodell gesendet werden
  • Unter Startups und Hobbyentwicklern ist LangChain am weitesten verbreitet
• LangChain ist noch ein junges Projekt (aktuelle Version 0.0.220)
  • Trotzdem sieht man bereits erste Anwendungen, die damit in Produktion sind
  • Einige Entwickler, insbesondere frühe LLM-Adopter, bevorzugen es, in der Produktion auf reines Python umzusteigen, um Abhängigkeiten zu vermeiden
  • Wir glauben jedoch, dass dieser DIY-Ansatz ähnlich wie im Web-App-Stack allmählich zurückgehen wird (die meisten werden Frameworks nutzen)
• Aufmerksame Leser werden bemerkt haben, dass ChatGPT im Orchestrierungs-Block auftaucht
  • Üblicherweise ist ChatGPT keine Entwickler-Tooling, sondern eine App, allerdings per API zugänglich
  • In gewisser Weise verhält es sich ähnlich wie solche Orchestrierungs-Frameworks (Prompt-Abstraktion, Statusverwaltung, Abruf von Kontextdaten per Plugins usw.)
  • Es ist kein direkter Konkurrent zu den hier besprochenen Tools, kann aber als alternative Lösung betrachtet werden. Es kann eine einfache Alternative sein, die sich schnell konfigurieren und nutzen lässt

Schritt 3. [Prompt execution / inference]

• Derzeit ist OpenAI führend unter den Sprachmodellen
• Fast alle Entwickler beginnen die Entwicklung von LLM-Apps mit den Modellen GPT-4 und GPT-4-32k
• Sie sind einfach zu verwenden, in vielen Domänen einsetzbar und benötigen weder Fine-Tuning noch Self-Hosting
• Sobald man in Produktion geht und skaliert, eröffnen sich verschiedene Optionen
  • Wechsel zu gpt-3.5-turbo:
    • Mehr als 50-mal günstiger und deutlich schneller als GPT-4
    • Eine gute Wahl, wenn keine Genauigkeit auf GPT-4-Niveau nötig ist, schnelle Antwortzeiten wichtig sind oder kostenlose Nutzer effizient bedient werden sollen
  • Experimente mit Modellen anderer Anbieter (insbesondere Claude von Anthropic)
    • Claude bietet schnelle Inferenz, Genauigkeit auf GPT-3.5-Niveau, mehr Anpassungsoptionen und ein Kontextfenster von bis zu 100k (bei größerer Länge sinkt die Genauigkeit allerdings)
  • Einen Teil der Anfragen auf Open-Source-Modelle routen
    • Das kann effizient sein bei großen B2C-Use-Cases wie Suche oder Chat mit unterschiedlich komplexen Abfragen oder wenn kostenlose Nutzer kostengünstig bedient werden müssen
• Open-Source-Modelle holen proprietäre Produkte derzeit noch ein, aber die Lücke beginnt sich zu schließen
  • Metas LLaMA-Modell hat einen neuen Maßstab für Open-Source-Genauigkeit gesetzt und zahlreiche Varianten hervorgebracht
  • LLaMA war nur für die Forschung lizenziert, doch viele Anbieter haben sich an das Training alternativer Basismodelle beteiligt (Together, Mosaic, Falcon, Mistral)
  • Meta diskutiert die Veröffentlichung eines wirklich Open-Source-fähigen Modells LLaMa 2
• Sobald Open-Source-LLMs ein Genauigkeitsniveau ähnlich GPT-3.5 erreichen, erwarten wir für Text einen Moment ähnlich Stable Diffusion
  • Groß angelegte Experimente, Teilen und Produktivsetzung feinabgestimmter Modelle usw.
  • Hosting-Unternehmen wie Replicate ergänzen bereits Tools, damit Entwickler solche Modelle leichter nutzen können
  • Unter Entwicklern wächst die Überzeugung, dass kleinere, aber feinabgestimmte Modelle die Genauigkeit modernster Modelle erreichen können
• Die meisten Entwickler, mit denen wir gesprochen haben, sind bei Operations-Tools für LLMs noch nicht sehr tief eingestiegen
  • Caching ist verbreitet, meist mit Redis (zur Verbesserung von Antwortzeit und Kosten)
  • Tools wie Weights & Biases, MLFlow, PromptLayer und Helicone werden ebenfalls häufig genutzt
    • Damit lassen sich LLM-Outputs loggen, verfolgen und evaluieren, um schnelles Prompting, Pipeline-Tuning und Modellauswahl zu unterstützen
  • Auch Tools zur Validierung von LLM-Outputs (Guardrails) oder zur Erkennung von Prompt Injection (Rebuff) erscheinen vermehrt
  • Die meisten dieser Operations-Tools empfehlen, ihre eigenen Python-Clients für LLM-Aufrufe zu verwenden, daher wird es interessant sein zu beobachten, wie sie künftig koexistieren
• Schließlich muss auch der statische Teil des LLMs (alles außer dem Modell) irgendwo gehostet werden
  • Die häufigste Lösung sind Vercel oder große Cloud-Anbieter
  • Es entstehen jedoch zwei neue Kategorien
    • Steamship bietet End-to-End-Hosting für LLM-Apps und stellt Funktionen wie Orchestrierung (LangChain), Multi-Tenant-Datenkontext, asynchrone Tasks, Vektorspeicher und Schlüsselverwaltung bereit
    • Anyscale und Modal ermöglichen es Entwicklern, Modelle und Python-Code gleichzeitig zu hosten

Was ist mit Agenten?

• Das wichtigste fehlende Element in dieser Referenzarchitektur ist ein AI-Agent-Framework
• AutoGPT war in diesem Frühjahr das am schnellsten wachsende GitHub-Repo der Geschichte als „Open-Source-Experiment, um GPT-4 vollständig autonom zu machen“
• Heute enthält praktisch jedes AI-Projekt in irgendeiner Form Agenten
• Die meisten Entwickler, mit denen wir gesprochen haben, sind vom Potenzial von Agenten sehr begeistert
  • Das in diesem Text beschriebene In-Context-Learning-Muster unterstützt Aufgaben zur Inhaltserstellung besser und ist gut geeignet, Halluzinationen und Probleme mit der Aktualität von Daten zu lösen
  • Agenten dagegen verleihen AI-Apps grundsätzlich neue Fähigkeiten
    • Etwa komplexe Probleme zu lösen, in der Außenwelt Aktionen auszuführen oder auch nach dem Deployment aus Erfahrung zu lernen
    • Das geschieht durch eine Kombination aus fortgeschrittenem Reasoning/Planung, Tool-Nutzung, Memory/Rekursion/Self-Reflection usw.
  • Agenten könnten ein zentraler Bestandteil der LLM-App-Architektur werden (wenn man an selbstverbessernde Rekursion glaubt, könnten sie sogar den gesamten Stack einnehmen)
  • Frameworks wie LangChain haben das Agenten-Konzept bereits integriert
  • Es gibt nur ein Problem: Agenten funktionieren noch nicht wirklich richtig
  • Die meisten Agenten-Frameworks befinden sich derzeit noch in der PoC-Phase – beeindruckende Demos sind möglich, aber nicht stabil oder reproduzierbar
  • Wir beobachten aufmerksam, wie sie sich weiterentwickeln

Blick nach vorn

• Vortrainierte AI-Modelle sind die wichtigste architektonische Veränderung in Software seit dem Internet
• Dadurch kann jeder Entwickler in wenigen Tagen AI-Apps bauen, die Supervised-Machine-Learning-Projekte übertreffen, für die große Teams Monate brauchen
• Die hier vorgestellten Tools und Muster sind wahrscheinlich kein Endzustand, sondern eher ein Ausgangspunkt für die Integration von LLMs

[sysmoon]

Das ist ein sehr aufschlussreicher Artikel, bei dem man die tiefe Erfahrung spürt.
Auf dieser Grundlage dürfte er eine große Hilfe bei der Gestaltung einer LLM-App-Architektur sein.

Da es im Ökosystem noch keine klaren Gewinner in den einzelnen Bereichen gibt, existieren viele Lösungen nebeneinander.
Dadurch wird die Auswahl schwieriger, und es scheint der Zeitpunkt gekommen zu sein, an dem die Fähigkeit zählt, die passende Kombination für die eigenen Anforderungen zu finden.

[nicewook]

Das ist ein unglaublich gehaltvoller Artikel. Ich lese ihn gerade in Ruhe.

[cwyang]

Würde es Gurunim die Arbeit erleichtern, wenn man GN einem LLM beibringt? ^^;
Vielen Dank.

[cwyang]

Ah, ihr habt also GN+ erstellt :-o

[xguru]

Es wird wohl bequemer, aber ich glaube, ich werde solche Artikel trotzdem weiter lesen – gewissermaßen zum Lernen. Haha
Wenn GN⁺ alle anderen News für mich erledigt, könnte das sogar den Effekt haben, dass es noch mehr solcher Artikel gibt!

[cosine20]

Vielen Dank für den guten Artikel und die Zusammenfassung.