Richtige Größenwahl von LLMs: Routing, Abruf und Bewertung statt reiner Modellgröße
Ermitteln Sie, wie Sie je nach Arbeitslast zwischen kleinen und großen Sprachmodellen wählen können, messen Sie die Kosten pro erfolgreich abgeschlossener Aufgabe und wenden Sie zunächst Routing, RAG, Caching sowie Validierung an.
Die Anzahl der Parameter ermöglicht einfache Schlagzeilen, und es ist verlockend, sie als Indikator für die Produktqualität zu betrachten: Ein 70B-Modell muss einem 7B-Modell überlegen sein, daher ist das größte Modell, das man sich leisten kann, die sichere Wahl. In der Produktion funktioniert dieser Kurzweg jedoch schnell nicht mehr. Größere Modelle kosten in der Regel mehr pro Aufruf, reagieren langsamer, belasten die Infrastruktur zusätzlich und lösen oft Probleme, die Ihre Anwendung ursprünglich gar nicht hatte. Diese Anleitung zeigt, wie man ein Modell anhand der Arbeitslast statt der Größe auswählt, wie man Kosten, Latenz und Ausfälle zusammen betrachtet sowie welche architektonischen Ansätze (Routing, Abruf, Validierung, Caching und reiner Code) in der Regel mehr bringen als ein einfacher Upgrade.
Warum „größer ist besser“ in der Produktion nicht mehr funktioniert
Die Intuition ist verständlich. Softwareentwickler haben jahrzehntelang beobachtet, wie sich Hardware-Upgrade auszahlen: eine schnellere CPU, mehr RAM, größere Festplatten und eine neuere GPU sind fast immer Verbesserungen. Als Sprachmodelle größer und leistungsfähiger wurden, schien es selbstverständlich, dieses Denkmuster weiterzuverwenden. Wenn ein Modell besser denkt als ein anderes, warum sollte jemand dann absichtlich das schwächere wählen?
Die Antwort zeigt sich in dem Moment, in dem ein Modell hinter einer echten Aufgabe steht. Die gestellte Frage wandelt sich von „Welches Modell ist das klügste?“ zu „Welches Modell liefert für diese spezifische Aufgabe das beste Ergebnis?“ Das sind völlig unterschiedliche Fragen. Das größte Modell kann zwar möglicherweise eine leicht bessere Antwort liefern, ist dabei jedoch deutlich langsamer. Es kann mehrere Male so teuer sein. Für einen einfachen Klassifizierungsprozess kann es sinnlos sein, längere Antworten erzeugen, als Ihre Benutzeroberfläche anzeigen kann, Ihren Kontextbudget aufbrauchen und die Implementierung verkomplizieren. Am wichtigsten ist, dass es dabei um eine Lösung eines Problems gehen könnte, das Sie eigentlich gar nicht haben.
Fangen Sie mit der Arbeitslast an, nicht mit der Anzahl der Parameter
Eine zuverlässigere Methode zur Auswahl eines Modells beginnt mit einer Beschreibung der Aufgabe selbst. Bevor Sie Modelle vergleichen, beantworten Sie folgende Fragen:
- Wie sieht die Eingabe aus?
- Welches Ergebnis wird erwartet?
Die letzte Frage ist die eigentliche ingenieurtechnische Frage, und der Rest dieses Leitfadens dient dazu, sie zu beantworten: Warum das größte Modell nicht automatisch das beste ist, wie man zwischen kleinen und großen Modellen entscheidet, wann ein großes Modell seinen Preis wirklich rechtfertigt und wie eine sinnvolle Produktionsarchitektur aussieht.
Ein Support-Produkt, zwei völlig unterschiedliche Arbeitslasten
Betrachten wir eine Unternehmensunterstützungsanwendung. Ein Benutzer tippt „Mein Passwort zurücksetzen.“ Was sollte die KI-Schicht in diesem Fall tun? Wahrscheinlich erkennt sie lediglich die Absicht und ordnet sie einer Etikette zu, wie unten gezeigt, damit die Anwendung an einen festgelegten, deterministischen Arbeitsablauf weiterleiten kann.
PASSWORD_RESET
Es ist kein aufwändiges Reasoning-Modell erforderlich, um zu dieser Etikette zu gelangen. Die Weiterleitung dieser Anfrage über ein solches Modell wäre eine fragwürdige Designentscheidung, da bereits ein leichtgewichtiges Modell oder sogar das Abgleichen von Schlüsselwörtern und Regeln ausreichen könnten, um die Anfrage zu verarbeiten.
Stellen Sie sich nun eine andere Nachricht vor: Seit der gestrigen Bereitstellung haben europäische Kunden wiederholt Zahlungsfehler, und der Benutzer möchte, dass das System den Unterschied zur vorherigen Version mit den Logs des Zahlungsdienstes vergleicht, mögliche Fehlermuster ermittelt, prüft, ob ein neuer Wiederholungsmechanismus beteiligt ist, und einen Rollback-Plan vorschlägt. Für diese Anfrage sind weitaus mehr Ressourcen nötig:
- Auswertung der relevanten Bereitstellungsänderungen und Protokolle
- eine große Menge an Kontextinformationen
- die Fähigkeit, Code zu lesen und zu verstehen
- Analysierung der Protokolldaten
- Logisches Denken über mehrere Schritte hinweg
- Korrelation von Ereignissen in verschiedenen Systemen
- eine klare technische Erklärung
- ehrliche Handhabung von Unsicherheiten
Hier kann ein leistungsstärkeres Modell tatsächlich Wert hinzufügen. Der Fehler besteht nicht darin, ein großes Modell zu verwenden, sondern darin, diese beiden Anfragen so zu behandeln, als wären es dieselbe Arbeitslast.
Eine praktische Definition des Modellwerts
Eine nützliche Art, die Entscheidung zu strukturieren, ist eine grobe Heuristik:
Modellwert = Fähigkeit × Zuverlässigkeit × Nützlichkeit ÷ Kosten
Das ist keine Formel, die man ausrechnet. Es handelt sich um eine Denkweise. Ein Modell, das zu 10 Prozent leistungsfähiger ist, aber fünfmal teurer und dreimal langsamer, ist nicht automatisch die bessere Produktionslösung. Ebenso ist ein Modell, das extrem günstig ist, aber für Ihre Aufgabe unzuverlässig ist, eine schlechte Wahl. Was Sie optimieren sollten, ist nicht die maximale Intelligenz, sondern die nützlichste Intelligenz pro Kosten-, Latenz- und Komplexitätseinheit.
Warum große Modelle verlockend sind – und wo die Einschränkungen auftreten
Der Vorzug großer Modelle ist nicht irrational, denn sie bringen echte Vorteile mit sich. Sie bewältigen oft komplexe Überlegungen besser, leisten bei unterschiedlichen Aufgaben gleichmäßiger, interpretieren vage Anweisungen geschickter, navigieren in komplexen Codebasen effektiver, benötigen weniger an die Aufgabe angepasste Anreize und können bei wirklich schwierigen Aufgaben weitaus leistungsfähiger sein.
Warum also nicht überall das leistungsstärkste Modell verwenden? Weil die Produktion Einschränkungen mit sich bringt, die in den Ranglistenwerten selten zum Vorschein kommen. Stellen Sie sich einen Endpunkt vor, der täglich 100.000 Anfragen verarbeitet. Wenn das größere Modell pro Aufruf deutlich teurer ist, ist dieser Unterschied nicht mehr abstrakt – er zeigt sich im Infrastrukturbudget. Wenn das größere Modell außerdem langsamer ist, bemerken es die Nutzer. Falls es zu ausführlichen Antworten neigt, steigen die Kosten für die Ausgabe-Tokens. Und wenn die Anwendung Tausende kleiner Aufgaben ausführt, ist es einfach Verschwendung, jede einzelne an ein fortschrittliches Reasoning-Modell zu senden.
Die Auswahl eines Modells ist ein Optimierungsproblem, kein Wettbewerb um Beliebtheit.
Das Modell an der Spitze einer Benchmark-Tabelle ist nicht unbedingt das, das die beste Anwendung erzeugt.
Die Anzahl der Parameter ist nur eine Dimension
Vergleiche zwischen Modellen konzentrieren sich tendenziell auf die Größe: 7B, 13B, 34B, 70B – Hunderte von Milliarden. Allein die Größe sagt wenig über die Eignung aus. Ein praktischer Vergleich betrachtet mehrere Aspekte gleichzeitig, beispielsweise:
- die Leistungsfähigkeit für Ihre spezifische Aufgabe
- die Latenz, sowohl die Zeit bis zum ersten Token als auch die Gesamtgenerierungszeit
- die Kosten pro Anfrage und pro erfolgreich abgeschlossener Aufgabe
- die Durchsatzleistung unter der erwarteten Last
- die tatsächlich benötigte Kontextgröße für die Aufgabe
- die Zuverlässigkeit und Konstanz bei wiederholten Ausführungen
- die Deployment-Möglichkeiten, einschließlich lokaler oder privater Hosting-Lösungen
- die Steuerbarkeit
Die Steuerbarkeit verdient besondere Aufmerksamkeit, da sie leicht übersehen wird. Ein Modell kann äußerst leistungsfähig sein, doch schwer in Grenzen zu halten. In Unternehmensworkflows ist ein vorhersehbares Verhalten oft wertvoller als Kreativität.
Strukturierte Extraktion ist ein anderes Ziel
Nehmen wir die Rechnungsextraktion. Die Funktion benötigt eine feste Struktur wie die unten gezeigte, nicht einen ausführlichen Aufsatz über das Dokument.
{
"invoiceNumber": "...",
"invoiceDate": "...",
"vendor": "...",
"total": 0
}
Wichtig ist hier eine zuverlässige, gut formatierte Ausgabe, die vom nachgelagerten Code jedes Mal verarbeitet werden kann. Das ist ein eigenständiges Optimierungsziel im Vergleich zur allgemeinen Schlussfolgerungsfähigkeit, und kleinere oder eingeschränktere Modelle erfüllen es oft gut – insbesondere in Kombination mit Schema-Validierung.
Latenz: die erste Produktionsfalle
In einer Demo wirkt eine Wartezeit von sechs Sekunden in Ordnung. Die Antwort ist beeindruckend, man teilt sie mit dem Team, und alle sind zufrieden. Setzt man denselben Vorgang hinter einen Button in einer echten Anwendung, ändert sich das Erlebnis: Der Benutzer klickt, ein Ladeindikator erscheint, und drei, fünf oder acht Sekunden vergehen. Zu diesem Zeitpunkt bewundert niemand mehr die Intelligenz des Modells – stattdessen fragen sich alle, warum die Anwendung so langsam ist.
Latenz ist eine Eigenschaft des Produkts und spielt in interaktiven Softwarelösungen eine äußerst wichtige Rolle.
Warum größere Modelle tendenziell langsamer reagieren
Der genaue Zusammenhang hängt von vielen Faktoren ab: Modellarchitektur, Hardware, die Bereitstellungsstack-Technologie, Quantisierung, Batching, wie viele Tokens erzeugt werden, Größe der Eingabeanfrage sowie das Modelldesign. Im Allgemeinen benötigen jedoch rechenintensivere Modelle mehr Ressourcen pro Token und können daher die Ergebnisse langsamer liefern. Das ist besonders relevant bei:
- Chatt-Interfaces
- Programmierhilfen und Autocomplete-Funktionen
- Stimmenassistenten
- Werkzeuge für Kundensupport
- Interaktive Dashboards
- Agentenbasierte Arbeitsabläufe, bei denen Wartezeiten zwischen den Schritten anwachsen
Autocomplete macht diesen Punkt deutlich. Ein Codevorschlag, der fünf Sekunden dauert, ist keine Autocomplete-Funktion mehr – er stellt vielmehr eine Störung dar. Ein kleineres Modell, das fast sofort antwortet, ist oft weitaus nützlicher als ein leistungsstärkeres Modell, das den Entwickler warten lässt.
Streaming verbessert die Wahrnehmung, nicht die Rechenleistung
Streaming ist die gängige Methode, um Wartezeiten kürzer erscheinen zu lassen. Ohne es sieht der Benutzer nichts, bis die vollständige Antwort bereit ist:
[wait...]
Hello! Here is the answer...
Mit Streaming erscheint der Text auf dem Bildschirm schrittweise, je nachdem, wie neue Daten ankommen:
Hello
Hello, here
Hello, here is
Hello, here is the
Hello, here is the answer...
Halten Sie die Unterscheidung klar. Streaming verringert die wahrgenommene Latenz, da die ersten Wörter schnell angezeigt werden, reduziert es jedoch weder die benötigte Rechenleistung noch die Gesamtzeit bis zur Fertigstellung der Antwort. Es handelt sich um eine Verbesserung der Benutzererfahrung, nicht um eine Leistungsoptimierung, und es hilft bei nicht-interaktiven Schritten wie einem Klassifikator innerhalb eines Pipelines in keiner Weise.
Kosten: messen Sie sie pro erfolgreich abgeschlossener Aufgabe
Viele Prototypen verwandeln sich genau an diesem Punkt in teure Systeme. Während der Entwicklung erscheinen die Kosten unbedeutend: Ein Entwickler sendet einige Anfragen, und niemand denkt an die Rechnung. Dann trifft echter Traffic ein, und jede Anfrage kann weitaus mehr enthalten als nur die Nachricht des Benutzers:
- viele gleichzeitige Benutzer
- mehrere Anfragen pro Sitzung
- lange Anfragen
- heruntergeladene Dokumente
- Ergebnisse von Tools
- Gesprächshistorie
- erstellte Antworten
Das Volumen der Tokens wächst schnell, und die Wahl des Modells wird immer wichtiger.
Eine ehrlichere Kennzahl als der Preis pro Aufruf ist die Kosten für die korrekte Erledigung der Aufgabe. Vergleichen wir zwei hypothetische Modelle (die Zahlen dienen nur zur Veranschaulichung und sind keine Benchmark-Ergebnisse):
- Modell A: 0,01 $ pro Anfrage, 90 % Genauigkeit bei der Aufgabenerledigung, etwa 1,11 Anfragen pro Erfolg, rund 0,011 $ pro erfolgreich erledigter Aufgabe.
- Modell B: 0,05 $ pro Anfrage, 96 % Genauigkeit bei der Aufgabenerledigung, etwa 1,04 Anfragen pro Erfolg, rund 0,052 $ pro erfolgreich erledigter Aufgabe.
Die erwartete Anzahl der Versuche beträgt einfach eins geteilt durch die Erfolgsrate, wodurch die Kosten pro Erfolg aus dem Anfragenpreis geteilt durch die Genauigkeit ergeben. Wenn Modell B fünfmal so teuer ist, aber die Ergebnisse nur geringfügig verbessert, kann das Unternehmen vernünftigerweise Modell A bevorzugen. Die Situation ändert sich, wenn eine falsche Antwort kostspielig ist – beispielsweise dann, wenn sie eine Rückerstattung, ein Konformitätsproblem oder einen Ausfall auslöst. Deshalb muss die Kosten immer zusammen mit den Folgen eines Scheiterns abgewogen werden, und nicht isoliert betrachtet.
Überdimensionale Modelle für unterdimensionierte Probleme
Ein häufiges Anti-Muster sieht so aus: Jede eingehende Nachricht wird als Beschwerde, Frage oder Rückerstattungsanfrage klassifiziert, und jede von ihnen wird an das leistungsstärkste verfügbare Modell weitergeleitet. Der Grund ist der Komfort – eine API, ein Prompt, ein Modell, fertig. Doch Architektur bedeutet nicht, dass ein einziger Komponent alles bewältigen soll; vielmehr geht es darum, jede Aufgabe mit der geeigneten Komponente zu verknüpfen. Für einfache Klassifizierungen stehen folgende Optionen zur Verfügung:
- deterministische Regeln
- Embeddings
- ein kleines Sprachmodell
- ein spezieller Klassifikator
- ein größeres Modell, das für Fälle mit geringer Zuverlässigkeit reserviert ist
Die letzte Option führt zu einem der effektivsten Produktionsmuster.
Escalation: Das teure Modell als Ausnahmehandler
Das naive Design leitet alles direkt an das große Modell weiter:
Every request
↓
Large model
Durch ein Eskalationsdesign kann zunächst ein günstigeres Modell versuchen, die Aufgabe zu lösen, und wird dabei überprüft, wie zuverlässig es ist:
Every request
↓
Small/cheap model
↓
Confidence check
↓
┌───────────────┐
│ │
High confidence Low confidence
│ │
Fast answer Large model
Antworten mit hoher Zuverlässigkeit werden sofort zurückgegeben; nur unsichere Fälle werden an das leistungsstärkere Modell weitergeleitet. Das teurere Modell ist nicht mehr der Standardweg, sondern dient nur noch als Ausnahmehandler. Dieses Muster setzt voraus, dass es ein zuverlässiges Signal zur Bewertung der Zuverlässigkeit gibt – beispielsweise eine kalibrierte Klassifizierungsscore, Übereinstimmung zwischen verschiedenen Methoden oder ein Validator, der fehlerhafte Ausgaben ablehnen kann. Messen Sie daher, wie oft qualitativ schlechte Antworten trotz „hoher Zuverlässigkeit“ durchgehen, bevor Sie sich darauf verlassen.
Ausliefern von Anfragen an verschiedene Modellstufen
Sobald man so denkt, sehen Modelle nicht mehr wie Konkurrenten aus, sondern eher wie spezialisierte Arbeiter. Ein Anfragerouter kann vor mehreren Ebenen stehen und für jede Anfrage die richtige auswählen, wobei vor dem Erreichen des Benutzers eine gemeinsame Validierungsstufe stattfindet:
User Request
|
v
Request Router
|
+-----------+-----------+
| | |
v v v
Simple Medium Complex
| | |
v v v
Small LLM Mid Model Large Model
| | |
+-----------+-----------+
|
v
Validation Layer
|
v
Response
Der Router benötigt eine Vorstellung von Komplexität. Die einfachste Version besteht aus einer kleinen Anzahl von Kategorien:
SIMPLE
MEDIUM
COMPLEX
Die Verteilungslogik kann dann genauso einfach sein wie ein Schalter basierend auf dem Urteil des Klassifizierers. Das untenstehende Beispiel ist in C# geschrieben, doch die Sprache spielt dabei keine Rolle; dieselbe Struktur eignet sich genauso gut für einen TypeScript-Dienst.
public async Task<string> ProcessAsync(Request request)
{
var complexity = await classifier.ClassifyAsync(request);
return complexity switch
{
Complexity.Simple =>
await smallModel.GenerateAsync(request),
Complexity.Medium =>
await mediumModel.GenerateAsync(request),
Complexity.Complex =>
await largeModel.GenerateAsync(request),
_ => throw new InvalidOperationException()
};
}
Wichtig ist die architektonische Aussage, die der Code trifft: Nicht jeder Anfrage steht maximale Intelligenz zu. Wenn diese Entscheidung konsequent umgesetzt wird, kann sie die Wirtschaftlichkeit eines KI-Systems dramatisch verändern. Beachten Sie, dass der Klassifikator selbst zu jeder Anfrage einen Aufruf sowie etwas Latenz hinzufügt; daher sollte er viel günstiger sein als die Modelle, zu denen er weiterleitet. Eine unbekannte Kategorie sollte laut fehlschlagen, wie es hier der Standardweg tut.
Wenn die Lücke im Wissen liegt, nicht in der Intelligenz
Ein weiterer häufiger Reflex ist: „Das Modell kennt unsere interne Dokumentation nicht, also wechseln wir zu einem größeren Modell.“ Größe behebt kein fehlendes Wissen. Wenn die Informationen proprietär, aktuell oder stark fachspezifisch sind, liegt das Problem im Zugang zum Wissen und nicht in der Rechenleistung. Genau das adressiert Retrieval-Augmented Generation (RAG). Der grundlegende Ablauf sieht so aus:
User Question
|
v
Embedding / Retrieval
|
v
Relevant Documents
|
v
Prompt + Retrieved Context
|
v
Language Model
|
v
Answer
Falls ein Benutzer nach der internen Rückerstattungspolitik Ihres Unternehmens für Unternehmenskunden fragt, kennt kein allgemeingültiges Modell – egal wie groß es auch ist – die Antwort. Sie müssen den relevanten Text selbst im Prompt bereitstellen. Für eine detailliertere Erklärung, wie dieser Abrufvorgang funktioniert, lesen Sie unseren Leitfaden zu wie RAG-Systeme frisches Wissen auf Anfrage abrufen.
Bessern Sie die Informationspipeline vor dem Modell
Dies führt zu einem Prinzip, das als Regel übernommen werden sollte:
Bessern Sie zunächst das, was Sie dem Modell liefern, bevor Sie das Modell selbst aktualisieren.
Teams versuchen oft, mangelhafte Antworten zu beheben, indem sie auf ein größeres Modell wechseln – obwohl die eigentliche Ursache woanders liegt:
- schwacher Informationsabruf
- irrelevante Dokumente
- Fehlende Metadaten
- schlechtes Aufteilen in Abschnitte
- unzureichender Kontext
In solchen Fällen ist das Modell nicht das Engpassproblem; der Informationsfluss ist es.
Qualität des Kontexts über Quantität
Große Kontextfenster sind beeindruckend, aber mehr Kontext bedeutet nicht automatisch eine bessere Leistung. Wenn einem Modell 200 Seiten Dokumentation übergeben werden, obwohl die Antwort in nur zwei Abschnitten steht, erhält es zwar technisch gesehen die notwendigen Informationen, doch in der Praxis wird die Aufgabe dadurch schwieriger, da es nun das Wesentliche im Lärm finden muss. Ein zu großer Kontext führt tendenziell dazu, dass:
- der Tokenverbrauch steigt
- die Latenz zunimmt
- die Kosten ansteigen
- Ablenkungen entstehen
- die Wahrscheinlichkeit von widersprüchlichen Informationen erhöht wird
Ein besseres Ziel ist die kleinste Menge an hochwertigem Kontext, die dem Modell immer noch ermöglicht, korrekt zu antworten. Deshalb investieren ausgereifte RAG-Systeme so viel in die Suchschicht, unter Verwendung von Techniken wie:
- semantische und hybride Suche
- Filtern nach Metadaten
- Umschreiben der Anfrage des Benutzers
- Neubewerten der potenziellen Passagen
- Aufrechterhalten von Aktualität der Dokumente
- Erstellung gut strukturierter Textabschnitte
Halluzinationen erfordern Überprüfung, nicht ein größeres Modell
Eine unangenehme Wahrheit: Der Einsatz eines ausreichend leistungsstarken Modells führt nicht dazu, dass Halluzinationen verschwinden. Stärkere Modelle liefern tatsächlich häufig mehr korrekte Fakten und handhaben Aufgaben besser, doch ein Sprachmodell bleibt weiterhin ein Textgenerator – niemals eine Quelle der Wahrheit, die wie eine Datenbank abgefragt werden kann. Daher muss die Lösung im Design liegen: Man sollte explizite Überprüfungsmechanismen in den Ablauf einbauen, zum Beispiel:
User Request
↓
Retrieve Evidence
↓
Generate Answer
↓
Validate Claims
↓
Return Response
Bei wertvollen Arbeitsabläufen kann man dies durch Folgendes verstärken:
- Zitaten, die auf Beweise verweisen
- strukturierte Ausgaben, die gegen ein Schema überprüft werden
- Validierung nach Geschäftsregeln
Lassen Sie das Modell argumentieren und die Software die Regeln durchsetzen
Dies schafft eine wichtige Trennlinie in der Architektur. Wenn ein Modell aufgefordert wird, den Gesamtbetrag einer Rechnung zu berechnen, gibt es keinen Grund, seiner Arithmetik zu vertrauen, wenn Ihre Anwendung die Berechnung genauso genau durchführen kann. Teilen Sie die Verantwortlichkeiten stattdessen auf:
Model:
Extract line items
Application:
Calculate subtotal
Application:
Calculate tax
Application:
Calculate total
Model:
Explain the result
Das Modell extrahiert die Posten und erklärt das Ergebnis; die Anwendung berechnet den Bruttobetrag, die Steuern und den Gesamtbetrag. Jeder Teil erledigt das, wofür er zuverlässig ist, und die von dem Benutzer eingesehenen Zahlen sind durch ihre Konstruktion immer korrekt.
Wo kleine Modelle glänzen und wo sie versagen
Kleine Sprachmodelle werden oft als „weniger intelligent“ abgetan, was in vielen Fällen technisch gesehen zutrifft. Doch Ingenieurwesen dreht sich nicht allein um Intelligenz, und kleine Modelle bieten konkrete Vorteile:
- niedrigere Inferenzkosten
- niedrigere Latenzzeiten
- einfachere lokale Implementierung
- geringere Anforderungen an die Infrastruktur
- möglicherweise höhere Durchsatzraten
- einfacheres Skalieren
- gute Eignung für spezifische Aufgaben
- Nützlichkeit in Edge-Szenarien
- möglicherweise bessere Privatsphäre bei lokaler Ausführung
Sie sind insbesondere für Klassifizierung, Extraktion, Zusammenfassung, Routing, Autocomplete, einfache Transformationen sowie domain-spezifische Arbeitsabläufe attraktiv. Wenn Sie sich genauer mit diesem Trend beschäftigen möchten, behandelt unsere Übersicht zu kleinen spezialisierten Modellen, die riesige LLMs übertreffen dieses Thema ausführlicher.
Klein bedeutet jedoch nicht automatisch besser. Einige Aufgaben übersteigen das, was ein kleines Modell zuverlässig leisten kann: anspruchsvolles Reasoning aus vielen Quellen, komplexe Codeanalyse, schwierige Planungsprobleme oder feinfühlige Interpretationen. In solchen Fällen rechtfertigt ein leistungsstärkeres Modell seinen Preis. Beide Extreme sind schlechter Rat: „Immer das Größte verwenden“ verschwendet Geld, während „Immer das Kleinste verwenden“ zu minderwertigen Ergebnissen führt. Die bessere Regel lautet:
Verwenden Sie das kleinste Modell, das den Qualitätsanforderungen Ihrer Anwendung entspricht.
Arbeitslasten, die ein großes Modell rechtfertigen
Nichts davon ist ein Argument gegen große Modelle. Sie sind äußerst nützlich, und bestimmte Arbeitslasten lohnen die zusätzlichen Fähigkeiten eindeutig.
Komplexe mehrschrittige Schlussfolgerungen
Wenn eine Funktion von aufeinanderfolgenden Schlussfolgerungen abhängt, kann ein leistungsstärkeres Modell deutlich bessere Ergebnisse liefern.
Hartkodierungsaufgaben
Große Modelle sind bei komplexen Anforderungen, unbekannten Codebasen, architektonischen Entscheidungen und schwierigen Debugging-Sitzungen unverzichtbar.
Ambige Natursprache
Manche Anfragen passen nicht in vorgefertigte Kategorien. Ein leistungsstärkeres Modell ist in der Regel besser darin, Nuancen und Absichten zu erkennen.
Synthese aus vielen Dokumenten
Wenn die Antwort die Kombination von Informationen aus vielen Quellen erfordert, spielt die Leistungsfähigkeit des Modells eine wichtigere Rolle.
Agentenbasierte Arbeitsabläufe
Ein Agent muss in der Regel Folgendes tun:
- eine Aufgabe verstehen
- Aktionen planen
- Werkzeuge auswählen
- Ergebnisse überprüfen
- von Fehlern wiederherstellen
- den Plan überarbeiten
- die Aufgabe abschließen
Das ist weitaus schwieriger als Klassifizierung, und ein leistungsstärkeres Modell ist durchaus gerechtfertigt. Der Test in jedem Fall bleibt derselbe: Nutzen Sie große Modelle, wenn ihre zusätzliche Leistungsfähigkeit einen messbaren Wert schafft.
Die Betriebskosten einer cleveren Architektur
Es gibt eine Kostenart, die in Benchmarks nie angezeigt wird: die architektonische Komplexität. Die einfachste mögliche Konfiguration besteht aus einer Anwendung, einem großen Modell und einer Antwort:
Application
↓
Large Model
↓
Response
Stellen Sie sich nun vor, alles auf einmal zu optimieren:
Application
↓
Router
↓
Classifier
↓
Small Model
↓
Confidence Evaluator
↓
RAG
↓
Reranker
↓
Large Model
↓
Validator
↓
Fallback Model
↓
Human Review
Diese Pipeline könnte tatsächlich ein besseres System hervorbringen, führt aber auch zu vielen mehr Komponenten, wobei jede Komponente Folgendes mit sich bringt:
- zusätzliche Überwachung und Protokollierung
- neue Ausfallmöglichkeiten
- eine größere Testfläche
- zusätzliche Infrastruktur zum Betrieb
- komplexere Bereitstellungen
- mehr Wissen, das das Team zum Betrieb benötigt
Daher sollte die Optimierung bewusst erfolgen. Der Aufbau einer sieben-Modell-Architektur, um ein paar Cent pro Anfrage zu sparen, ist selten ein guter Kompromiss; fügen Sie jede Schicht nur dann hinzu, wenn Messungen zeigen, dass sich deren Wartung lohnt.
Bewerten Sie anhand Ihrer eigenen Arbeitslast, nicht anhand von Ranglisten
Öffentliche Benchmarks sind ein Ausgangspunkt, keine Entscheidungsgrundlage. Ihre Anwendung hat ihren eigenen Benchmark – und nur dieser zählt. Für einen AI-Code-Review-Assistenten könnte ein Bewertungssatz beispielsweise Folgendes umfassen:
- SQL-Injektionsanfälligkeiten
- Rennbedingungen
- Null-Referenzfehler
- Autorisierungsfehler
- Fehlerhafte Exception-Verarbeitung
- Leistungsprobleme
- Architektonische Verstöße
Für einen Kundenservice-Assistenten würden Sie verschiedene Aspekte messen:
- Bereinhaltung der Richtlinien
- Faktische Genauigkeit
- Tonfall
- Genauigkeit bei der Eskalation
- Verhalten bei Ablehnungen
- Gültigkeit der strukturierten Ausgabe
Der Bewertungssatz sollte möglichst dem Produktivverkehr ähneln.
Eine Vergleichsplattform erstellen
Das grundlegende Verfahren ist einfach: Sammeln Sie prompte Anfragen im Produktivumfeld mit erwarteten Ergebnissen, führen Sie jedes Testmodell damit durch und vergleichen Sie die Ergebnisse.
Production-like prompts
↓
Expected outcomes
↓
Run Model A
↓
Run Model B
↓
Compare
↓
Measure
Nützliche Metriken zur Dokumentation jeder Ausführung:
- Korrektheit und Vollendung der Aufgabe
Sobald dies festgelegt ist, wird die Auswahl eines Modells zu einer ingenieurtechnischen Entscheidung statt zu einem Ratenversuch, und Sie können denselben Test immer wieder durchführen, sobald ein Anbieter eine neue Modellversion veröffentlicht.
Ein vierstufiger Prozess zur Modellauswahl
Für eine neue KI-Funktion eignet sich ein einfacher, wiederholbarer Prozess hervorragend.
Schritt 1: Die Aufgabe genau definieren
Fangen Sie nicht mit „Welches Modell sollten wir verwenden?“ an. Beginnen Sie mit „Was muss das Modell genau erreichen?“ und schreiben Sie die Antwort in konkreten Begriffen auf:
Input:
Customer email
Output:
Intent + urgency + recommended workflow
Eine solche Spezifikation mit klarem Eingang und klarer Ausgabe ist weitaus nützlicher als ein vager Zielvorgabe.
Schritt 2: Definieren, was „gut genug“ bedeutet
Legen Sie vor dem Testen jeglicher Funktion explizite Akzeptanzkriterien fest. Zum Beispiel:
Intent accuracy >= target threshold
Structured output must always validate
Response should normally arrive within target latency
Die genauen Schwellenwerte hängen von der Anwendung ab; wichtig ist, dass sie bereits vor dem Vergleich der Modelle vorhanden sind, damit die Ergebnisse später nicht rechtfertigt werden können.
Schritt 3: Versuchen Sie zunächst das kleinste funktionierende Modell
Das ist der Schritt, den Teams am häufigsten überspringen. Beginnen Sie klein, messen Sie die Leistung und stoppen Sie, wenn das Modell funktioniert. Erhöhen Sie nur den Anspruch, falls es versagt:
Small Model
↓
Evaluation
↓
Pass? ── Yes → Ship
|
No
↓
Larger Model
↓
Evaluation
↓
Pass? ── Yes → Ship
|
No
↓
Stronger architecture/model
Im Grunde steigen Sie Stufe für Stufe eine Leistungsladder hinauf, wobei jede Stufe durch eine fehlgeschlagene Bewertung erlangt werden muss.
Schritt 4: Optimieren Sie das umgebende System
Bevor Sie auf die nächste Stufe wechseln, überprüfen Sie den Rest des Systems:
- Liefert die Abfrage das richtige Material?
- Ist die Anweisung eindeutig formuliert?
- Ist jeder Kontextteil tatsächlich relevant?
- Wird die Ausgabe vor der Verwendung überprüft?
Verbesserungen in diesem Bereich beseitigen manchmal völlig die Notwendigkeit für ein größeres Modell.
Weitere Hebel, die vor einem Upgrade in Betracht gezogen werden sollten
Aufforderungen als Verträge
Prompt-Engineering ist keine Magie, aber eine schlecht formulierte Aufgabe kann selbst ein leistungsstarkes Modell falsch handeln lassen. Vergleichen Sie eine vage Anweisung:
Analyze this customer message.
mit einer, die die erwartete Ausgabe sowie die Regeln für Unsicherheiten definiert:
Analyze the customer message.
Return JSON with:
- intent
- urgency
- sentiment
- recommended_action
Do not invent information that isn't present.
If the intent is unclear, return "unknown".
Die zweite Version gibt dem Modell einen klaren Vertrag vor: benannte Felder, ein expliziter Verbotsklausel für erfundene Fakten sowie einen definierten Ersatzwert. Das Hinzufügen einiger Beispiele verbessert die Ergebnisse oft weiter. Es gibt jedoch eine Obergrenze – keine Anzahl an Prompt-Formulierungen kann dem Modell Fähigkeiten verleihen, die es im Grunde nicht besitzt, und wenn eine Fähigkeit fehlt, bringen Anpassungen an den Prompts nur noch geringe Verbesserungen. Betrachten Sie das Erstellen von Prompts als eine Schicht im Optimierungsprozess, nicht als die gesamte Lösung.
Fine-Tuning, RAG oder Validierung?
Eine weitere häufige Reaktion auf schwache Ergebnisse ist „lasst uns fine-tun“. Manchmal ist das genau richtig, aber diagnostizieren Sie zunächst das Problem:
- Falls dem Modell aktuelles oder firmenspezifisches Wissen fehlt, wie beispielsweise die heutigen Richtlinien, ist das Abrufen von Informationen in der Regel eine bessere Option als Fine-Tuning, da sich Wissen ändert und das Umtrainieren Zeit in Anspruch nimmt.
Die richtige Lösung für das tatsächliche Problem spart Zeit und Geld.
Caching: die langweilige, aber wirksame Optimierung
Caching ist unspektakulär, aber äußerst effektiv. Wenn Nutzer ständig fragen „Wie ist Ihre Rückgabepolitik?“, gibt es keinen Grund, jedes Mal ein Modell anzurufen. Wenn die Antwort stabil ist, sollte sie im Cache gespeichert werden. Das untenstehende C#-Beispiel prüft zunächst den Cache, ruft das Modell nur bei einem Fehlschlag auf und speichert das Ergebnis für 30 Minuten:
public async Task<string> GetAnswerAsync(string question)
{
var key = CreateCacheKey(question);
var cached = await cache.GetStringAsync(key);
if (cached is not null)
return cached;
var answer = await model.GenerateAsync(question);
await cache.SetStringAsync(
key,
answer,
TimeSpan.FromMinutes(30));
return answer;
}
Echte semantische Caching-Methoden sind komplexer als eine genaue Zeichenkettenvergleich, da zwei unterschiedlich formulierte Anfragen dieselbe Antwort erhalten können – daher ist eine Strategie erforderlich, um Antworten zu ungültig zu machen, wenn sich die zugrundeliegenden Fakten ändern. Die grundlegende Idee bleibt bestehen:
Die schnellste KI-Anfrage ist die, die man gar nicht stellt.
Das gleiche Prinzip gilt für die Eliminierung von Doppelungen, Vorkalkulation, deterministische Antworten, die Wiederverwendung von Suchergebnissen, das Prompt-Prefix-Caching, sofern der Anbieter es unterstützt, sowie die einfache Wiederverwendung von Antworten. Bevor man mehr Rechenleistung bezahlt, sollte man zunächst die nicht benötigte Rechenleistung beseitigen.
Betrachten Sie Tokens als Ressourcenbudget
Sobald man ein KI-System als verteiltes System betrachtet, werden Tokens zu einer weiteren Ressource, die verwaltet werden muss. Traditionelle Dienste kümmern sich um CPU, Speicher, Netzwerk und Speichersysteme. KI-Anwendungen fügen Eingabetokens, Ausgabetoken, Kontextgröße sowie Inferenzzeit hinzu, wodurch die Gestaltung von Anfragen zu einer Leistungsfrage wird.
Betrachten Sie den Versand der gesamten Konversationshistorie mit jeder Anfrage. Die Anfragen werden immer länger, und dazu kommen noch abgerufte Dokumente, Tool-Ausgaben, Systemanweisungen sowie frühere Aktionen des Systems. Eine einfache Frage kann letztendlich eine enorme Datenmenge enthalten. Ein effizienteres Design wählt vor der Abfrage nur die relevanten Informationen aus und erstellt einen kompakten Kontext:
Conversation
↓
Relevant history selection
↓
Retrieval
↓
Compact context
↓
Model
anstatt alles weiterzuleiten, was das System je gesehen hat:
Everything we've ever seen
↓
Model
Mehr Kontext ist niemals kostenlos: Man zahlt dafür mit Geld, Latenzzeit und oft auch mit der Qualität der Antworten.
Agenten multiplizieren jede dieser Entscheidungen
Agentebasierte Systeme machen die Modellauswahl noch bedeutender. Eine einzige Benutzeranfrage kann sich in viele Schritte aufteilen:
User Request
↓
Planning
↓
Tool Selection
↓
Search
↓
Database Query
↓
Code Execution
↓
Analysis
↓
Final Response
Falls jeder Schritt mit dem teuersten Modell ausgeführt wird, können die Kosten in die Höhe schießen. Doch die Schritte benötigen selten dieselben Fähigkeiten. Eine gemischte Zuweisung könnte so aussehen:
Intent classification → Small model
Simple tool selection → Small model
Complex planning → Large model
Data extraction → Small model
Final explanation → Medium model
Das ist eine heterogene KI-Architektur – dorthin entwickeln sich viele Produktionsysteme: nicht ein riesiges Modell, das alles erledigt, sondern mehrere Modelle, Tools, deterministische Komponenten, Abrufpipelines und Validatoren, die zusammenarbeiten. Unsere Analyse zu warum die Kosten bei agenterbasierten KI-Systemen in die Höhe schießen untersucht diese Aspekte der Kosten genauer.
Betrachten Sie Modelle als Teammitglieder
Eine nützliche Analogie: Stellen Sie sich drei Ingenieure vor. Einer ist sehr erfahren, teuer und überlastet. Ein anderer ist erfahren und effizient. Der Dritte ist Junior, arbeitet aber sehr schnell bei repetitiven Aufgaben. Man würde nicht jede Aufgabe dem erfahrenen Ingenieur übertragen – man verteilt die Arbeit nach Schwierigkeitsgrad:
Simple repetitive task
→ Engineer C
Normal feature
→ Engineer B
Complex architecture problem
→ Engineer A
Modelle können auf dieselbe Weise behandelt werden. Ein kleineres Modell ist nicht „schlecht“; es passt möglicherweise einfach besser zu einer engeren Aufgabenstellung. Die entscheidende Fähigkeit besteht darin, die Arbeit in Teile zu zerlegen. Anstatt nach einem Modell zu suchen, das alles bewältigt, sollte der Arbeitsablauf so aufgeteilt werden, dass jedes Komponente die Aufgabe übernimmt, bei der es am besten ist. Diese Denkweise lässt sich viel besser skalieren.
Zusammenfassung: Eine Referenzarchitektur
Indem man diese Ideen kombiniert, könnte ein Unternehmens-AI-Assistent wie folgt strukturiert werden:
User
|
v
API / Gateway
|
v
Request Router
|
+-------------+-------------+
| |
v v
Simple Request Complex Request
| |
v v
Small Model Planner
|
+------------+------------+
| | |
v v v
Search Database Tools
| | |
+------------+-------------+
|
v
Context
|
v
Strong Model
|
v
Validator
|
+------+------+
| |
Valid Invalid
| |
v v
Response Retry/Fallback
Achten Sie darauf, was nicht geschieht: Das größte Modell wird nicht gebeten, alles zu erledigen. Einfache Anfragen gehen an ein kleineres Modell. Komplexe Anfragen werden durch einen Planer geleitet, der Beweise aus Suchmaschinen, Datenbanken und Tools sammelt, und erst danach arbeitet ein leistungsstärkeres Modell mit einem sorgfältig ausgewählten Kontext. Ein Validator überprüft die Ausgabe, und ungültige Ergebnisse führen zu einem Neversuch oder einer Fallback-Lösung. Das Design stützt sich auf:
- einen Router, der den richtigen Weg wählt
- Methoden zur Abrufung von Beweisen sowie entsprechende Tools
- deterministische Systeme für präzise Arbeit
- Modelle, die je nach Rolle spezialisiert sind
- Validierung sowie Strategien für Neversuche und Fallbacks
Hier ist das Modell nur ein Teil des Systems und nicht das gesamte System.
Zehn häufig wiederkehrende Fehler
- Zuerst ein Modell auswählen und das Problem erst später beschreiben. Diese Reihenfolge ist falsch; bestimmen Sie zunächst die Arbeitslast, bevor Sie weitermachen.
Checkliste zur Entscheidungsfindung bei der Auswahl eines Modells
Wenn eine Entscheidung bezüglich eines Modells ansteht, gehen Sie nacheinander diese Fragen durch:
- Kann deterministischer Code das Problem lösen? Wenn ja, schreiben Sie Code. Verwenden Sie KI nicht einfach nur, weil sie verfügbar ist.
- Ist die Aufgabe einfach und repetitiv? Versuchen Sie es mit einem kleinen Modell.
Diese Checkliste ist weitaus nützlicher als die Frage, welches Modell am größten verfügbar ist.
Eine Frage, die man Senior-AI-Engineern stellen sollte
Eine aufschlussreiche Interviewfrage für eine Stelle in der AI-Architektur lautet: „Warum wählt man nicht einfach das leistungsstärkste Modell auf dem Markt für alles?“
Eine schwache Antwort beschränkt sich auf den Satz „Kleinere Modelle sind günstiger.“ Das stimmt zwar, ist aber unvollständig. Eine starke Antwort berücksichtigt die Leistungsfähigkeit für die spezifische Aufgabe, Zuverlässigkeit und Latenz sowie Durchsatz, Kosten, die benötigte Menge an Kontextinformationen, den Routing-Vorgang zwischen Modellen, das Abrufen von Daten, die Aufgaben, die der Code erledigen soll, die Bewertung, die Kosten bei Fehlern sowie die betrieblichen Belastungen.
Die logische Folgefrage lautet: „Wie würden Sie nachweisen, dass das von Ihnen gewählte Modell gut genug ist?“ Die Antwort sollte sich auf Bewertungen beziehen – nicht auf Meinungen, Social-Media-Beiträge, Screenshots von Leaderboards oder Präsentationen der Anbieter. Entscheidend sind Ihre Arbeitslast, Ihre Daten sowie Ihre Metriken.
Schrittweise Optimierung einer bestehenden Anwendung
Falls eine KI-Funktion zu langsam oder zu teuer ist, widerstehen Sie dem Drang, sofort ein anderes Modell einzusetzen. Untersuchen Sie stattdessen systematisch:
- Messen. Sammeln Sie Anfragenzahlen, Eingangs- und Ausgabetoken, Latenzzeit, Fehlerquote, Erfolgsrate der Aufgaben sowie den Modellkosten.
- Die teuren Arbeitslasten ermitteln. Bestimmen Sie, welche Anfragetypen am meisten Ressourcen verbrauchen.
- Unnötige Aufrufe entfernen. Nutzen Sie Caching, deterministische Logik, Deduplizierung und Vorkalkulation.
- Den Kontext verkleinern. Entfernen Sie irrelevante Historien und Dokumente.
- Die Abrufleistung verbessern. Liefern Sie bessere Belege anstelle von mehr Belegen.
- Einen kleineren Modell versuchen. Überprüfen Sie, ob die Qualität weiterhin akzeptabel bleibt.
- Routing einführen. Senden Sie nur schwierige Fälle an leistungsstärkere Modelle.
- Was wichtig ist, validieren. Wenden Sie bei Bedarf Schemata, Regeln, Tools sowie menschliche Überprüfung an.
Falls Ihnen das vertraut vorkommt, sollte es das auch. Im Grunde handelt es sich um dieselbe Disziplin, die zur Optimierung herkömmlicher Software verwendet wird.
Die beste KI-Architektur ist in der Regel hybrid
Das Bild einer KI-Anwendung als Frontend, das eine LLM-API aufruft und die Antwort zurückgibt, verliert an Bedeutung:
Frontend
↓
LLM API
↓
Response
Reale Anwendungen ähneln zunehmend eher einem Gateway, das Regeln, Abrufmechanismen, Modelle, Tools und Validierungen koordiniert:
Application
|
v
AI Gateway
|
+-----------+-----------+
| | |
v v v
Rules Retrieval Models
| | |
+-----------+-----------+
|
v
Tools
|
v
Validation
|
v
Application
Ein solches Design verbindet klassische Softwareentwicklung mit Maschinellem Lernen, Sprachmodellen und Abrufmechanismen sowie Datenbanken, APIs, Sicherheit, Überwachbarkeit und als Code geschriebener Geschäftslogik. Das sind gute Nachrichten für Softwareentwickler: KI-Engineering ersetzt die Softwareentwicklung nicht, sondern fügt ihr einen leistungsstarken neuen Bestandteil hinzu.
Eine damit verbundene Perspektivänderung hilft: Hören Sie auf, zu fragen, welches Modell am intelligentesten ist, und fangen Sie an, zu fragen, welches System am intelligentesten ist. Ein brillantes Modell innerhalb eines schlecht entworfenen Systems kann schreckliche Ergebnisse liefern, während ein mäßig leistungsstarkes Modell innerhalb einer gut konzipierten Architektur ein hervorragendes Produkt ermöglichen kann. Gute Systeme kompensieren die Schwächen eines Modells durch Suchfunktionen und Tools, Routing und Caching, strukturierte Ausgaben und Validierung, Code für präzise Aufgaben sowie kontinuierliche Bewertung. In diesem Sinne ist die KI-Fähigkeit eine Eigenschaft der Architektur und nicht nur des Modells.
Fangen Sie klein an und eskalieren Sie mit Beweisen
Eine sinnvolle Standardstrategie für jede neue KI-Funktion ist in diesem Ablauf dargestellt:
Start
|
v
Define the workload
|
v
Can code solve the problem?
/ \
Yes No
| |
Use code v
Try small model
|
v
Evaluate
|
+----------+----------+
| |
Pass Fail
| |
Ship v
Improve architecture
|
v
Evaluate
|
v
Try stronger model
|
v
Evaluate
Es verhindert einen sehr häufigen Fehler: Geld auszugeben für ein Problem, das durch bessere Ingenieurskunst gelöst werden könnte.
Mannchmal ist das richtige Modell kein Modell
Die Botschaft ist nicht, dass kleine Modelle besser sind; das wäre genauso falsch wie die gegenteilige Behauptung. Das richtige Modell ist das, welches die Anforderungen der Aufgabe erfüllt und dabei Leistungsfähigkeit sowie Zuverlässigkeit gegenüber Latenz, Kosten und Komplexität abwägt. Manchmal ist das ein kleines Modell, manchmal eines große, manchmal eine Kombination – und manchmal überhaupt kein KI-Modell. Wenn eine Anfrageart mit einer einfachen Struktur wie dieser abgewickelt werden kann, gibt es keinen Grund, ein LLM einzusetzen:
if (request.Type == "PasswordReset")
{
return StartPasswordResetWorkflow();
}
Das ist kein Anti-KI-Ansatz; es handelt sich um gute Ingenieurspraxis. Man würde schließlich keinen Server mit unbegrenzter CPU für einen Dienst kaufen, der nur zwei Kerne benötigt, oder ein Terabyte an Speicher für einen Prozess bereitstellen, der 4 GB verwendet. Derselbe Grundsatz gilt auch für Modelle: Eine Leistungsfähigkeit, die man nicht benötigt, bedeutet Kosten, die man ebenfalls nicht benötigt.
Haupterkenntnisse
- Ersetzen Sie „Welches ist das größte Modell, das wir uns leisten können?“ durch „Welche ist die einfachste Architektur, die dieses Problem zuverlässig löst?“ Diese Frage führt Sie von selbst zu Themen wie Routing, Abrufverfahren, Caching, deterministischem Code, Bewertung, Latenz und Fehlerbehandlung.
- Bewerten Sie Modelle anhand der Kosten pro erfolgreich abgeschlossener Aufgabe im Verhältnis zu den Folgen einer falschen Antwort – und nicht anhand des Preises pro Aufruf oder der Anzahl der Parameter.
- Betrachten Sie fehlendes Wissen als ein Abrufproblem und Arithmetik oder Regeln als ein Softwareproblem; weder das eine noch das andere lässt sich durch ein größeres Modell lösen.
- wählen Sie standardmäßig das kleinste Modell, das eine auf Ihren eigenen Produktionsdaten basierende Bewertung bestehen kann, und wechseln Sie nur dann zu einem größeren Modell, wenn es entsprechende Belege gibt.
- Lassen Sie die Architektur so einfach wie möglich sein, solange die Einsparungen dies rechtfertigen, und messen Sie weiterhin nach dem Start, da sich Modelle, Anfragen und Nutzer ständig ändern.
Zuerst das Problem im Blick haben und anschließend ein Modell wählen, das zu diesem Design passt. Manchmal ist dieses Modell sehr umfangreich, manchmal überraschend klein – und manchmal ist die klügste Entscheidung überhaupt kein Modell zu verwenden.
Verwandte Artikel
- Retrieval-Augmented Generation erklärt: Wie man Wissenslücken bei LLMs behebt — Erfahren Sie, warum LLMs Halluzinationen erzeugen und veraltet werden, und sehen Sie anschließend Schritt für Schritt, wie RAG Anfragen abruft, in Blöcke teilt, einbettet und erweitert, um dieses Problem zu lösen.
- RAG gegen Agentic RAG gegen Graph RAG: Wie man die richtige Abfragesystemarchitektur wählt — Erfahren Sie, warum einfaches RAG bei mehrstufigen Fragen und strukturierten Daten versagt, sowie wie agentebasierte Schleifen und graphbasiertes Abrufen jeweils unterschiedliche Schwächen beheben.