LLM-Funktionen bauen, die in der Produktion bestehen

Ein Team, mit dem wir gesprochen haben, verbrachte sechs Wochen damit, ein Modell per Fine-Tuning daran zu hindern, falsche Antworten zu geben. Das Fine-Tuning bewegte die Zahlen kaum, denn die falschen Antworten waren nie ein Modellproblem. Das System rief die falschen Dokumente ab, und kein Prompt und kein Gewichts-Update repariert schlechte Eingaben. Zwei Tage Arbeit am Retrieval-Schritt hätten den Großteil der Lücke geschlossen. Sie griffen zuerst zum schwersten Werkzeug im Kasten, und es kostete sie anderthalb Monate.

Das ist der häufigste teure Fehler in der LLM-Funktionsentwicklung, und er entsteht dadurch, dass man die Stufen in der falschen Reihenfolge durchläuft. Die Reihenfolge, die den Kontakt mit echten Nutzern überlebt, ist schlicht: integrieren, dann messen, dann Fine-Tuning. Die dritte Stufe erreichen Sie erst, wenn die Evidenz aus der zweiten es verlangt. In diesem Beitrag geht es um das Sequencing, nicht um die Mechanik. Jede Stufe hat ihren eigenen Vertiefungsartikel; hier geht es darum zu wissen, wann und warum jede ihren Platz verdient.

Warum Teams zuerst zum falschen Werkzeug greifen

Fine-Tuning fühlt sich nach der ernsthaften Antwort an. Es ist das, was ein „echtes“ ML-Team tut. Prompting fühlt sich nach Schummeln an, Retrieval nach Klempnerarbeit, und das Anpassen von Modellgewichten nach echtem Engineering. Also geht die Aufmerksamkeit dorthin: zu dem Hebel, der Kompetenz signalisiert, statt zu dem, der das Problem löst.

Das Problem: Fine-Tuning ist auch der teuerste Hebel, den Sie haben, der langsamste in der Iteration und der am schwersten zu debuggende. Eine Prompt-Änderung ist eine Schleife von dreißig Sekunden. Eine Retrieval-Änderung ist ein Nachmittag. Ein Fine-Tuning ist Stunden GPU-Zeit pro Iteration, ein Datensatz, den Sie aufbauen und pflegen müssen, und ein Feedback-Zyklus in Tagen. Wenn nach einem Fine-Tuning etwas schiefläuft, können Sie die Gewichte nicht lesen, um zu sehen warum. Sie debuggen eine Blackbox, die Sie gerade undurchsichtiger gemacht haben. Zuerst danach zu greifen heißt, die höchsten Iterationskosten im Stack zu zahlen, um ein Problem zu beheben, das Sie noch nicht lokalisiert haben.

Stufe 1: Integrieren — zum Laufen bringen, bevor Sie es gut machen

Die erste Stufe ist ein funktionierender Pfad von der Nutzereingabe zur Modellausgabe, geerdet in Ihren Daten, der unter Last standhält. Drei Dinge tragen hier den Großteil des Gewichts, ungefähr in dieser Reihenfolge des Hebels.

Prompt-Designist der billigste, schnellste Hebel, den Sie besitzen. Eine klare Anweisung, ein paar gut gewählte Beispiele und eine definierte Ausgabeform bringen Sie weiter, als die meisten Teams erwarten, bevor sie überhaupt an Gewichte denken. Schöpfen Sie das zuerst aus, denn die Schleife misst sich in Sekunden.

Retrievalist der Standardweg, um einem Modell Ihre Daten zu geben. Das Modell kennt Ihre Verträge, Ihre Produktdokumentation oder die Tickets des letzten Quartals nicht, also holen Sie die relevanten Teile zur Anfragezeit und legen sie ins Kontextfenster. Hier wohnen die meisten „das Modell liegt falsch“-Beschwerden, und es richtig zu machen ist eine eigene Disziplin. Das vertiefen wir im Leitfaden für RAG-Pipelines in der Produktion.

Die Klempnerarbeitsind die unglamourösen 80 % der echten Arbeit: Streaming, damit sich die Oberfläche lebendig anfühlt; Timeouts und Retries, damit ein langsamer Upstream die Anfrage nicht hängen lässt; Fallbacks, wenn Modell oder Retriever ausfallen; und ein scharfer Blick auf die Token-Kosten, bevor sie Sie auf der Rechnung überraschen. Nichts davon taucht in einer Demo auf, und alles davon taucht in der Produktion auf. Die Verdrahtungsmuster — Anfrageform, Fehlerbehandlung, wo das Modell relativ zu Ihren bestehenden Diensten sitzt — behandeln wir in LLMs in Geschäftssysteme integrieren.

Die meisten Funktionen sollten nach dieser Stufe ausgeliefert werden. Ein gut geprompetes Modell mit gutem Retrieval und solider Klempnerarbeit ist ein echtes Produkt. Sie haben nichts feingetunt, und genau das ist der Punkt.

Stufe 2: Messen — Sie können nicht verbessern, was Sie nicht messen

Bevor Sie irgendetwas ändern, um das System „besser“ zu machen, brauchen Sie einen festen Punkt, der Ihnen sagt, ob eine Änderung tatsächlich geholfen hat. Dieser feste Punkt ist ein Eval-Set: eine Sammlung repräsentativer Eingaben mit bekannten, guten Soll-Ausgaben, die Sie bei jeder Änderung durchlaufen lassen. Ohne es ist „besser“ ein Gefühl. Jemand hat zwei Fragen gut beantworten sehen und Fortschritt verkündet.

Bauen Sie das Eval-Set, bevor Sie irgendetwas feintunen, denn es ist das Einzige, das Ihnen erlaubt, zwei Versionen ehrlich zu vergleichen. Damit sind eine Prompt-Anpassung, eine Retrieval-Änderung und ein Fine-Tuning alle gegen dieselbe Latte messbar. Ohne es fliegen Sie blind und nennen es Intuition. Das Wie — was ins Set gehört, wie man offene Ausgaben bewertet, wie man es ehrlich hält, während das Produkt wächst — ist ein eigenes Thema, behandelt im Praxisleitfaden zur LLM-Evaluierung. Fürs Sequencing gilt eine einfache Regel: kein Eval-Set, kein Fine-Tuning.

Stufe 3: Fine-Tuning, und erst jetzt

Fine-Tuning verdient seinen Platz, wenn die Evidenz aus Stufe 2 zeigt, dass Prompting und Retrieval eine echte Grenze erreicht haben, keine vermutete. Drei Signale rechtfertigen ein LoRA-Fine-Tuning wirklich:

• Eine Fähigkeit, die das Modell per Prompting nicht erreicht, egal wie Sie es formulieren: ein Denkmuster der Domäne oder eine Aufgabenstruktur, die das Basismodell schlicht nicht hat.
• Ein Stil oder Format, den Sie jedes Mal brauchen— ein Hausstil, ein striktes Ausgabeschema, ein Fachdialekt —, den Beispiele im Prompt nur meistens richtig treffen. In die Gewichte eingebrannt wird er zum Standard statt zur Bitte.
• Latenz oder Kosten durch riesige Prompts. Wenn Sie bei jedem Aufruf Tausende Tokens an Anweisungen und Beispielen mitschicken, lässt eingebranntes Verhalten Sie einen weit kürzeren Prompt senden und einmal im Training dafür zahlen statt bei jeder Anfrage.

Wenn Sie diese Stufe erreichen, ist LoRA der praktische Standard. Es passt einen kleinen Satz Parameter an statt des ganzen Modells, was die Iterationskosten und den Hardwarebedarf vernünftig hält. Die Mechanik, die Datensatzarbeit und die Fallstricke stehen im LoRA-Fine-Tuning-Leitfaden.

Die Schleife, nicht die Linie

Integrieren → messen → feintunen liest sich wie eine Linie, aber Sie laufen es als Schleife. Die Evaluierung ist kein einmaliges Tor am Ende; sie kontrolliert jede Änderung. Eine Prompt-Anpassung, ein neuer Retriever, ein Reranker: jede geht durch dasselbe Eval-Set, und Sie behalten die Version, die die Latte bewegt hat.

Sie werden viele Male zwischen Integrieren und Messen pendeln, bevor Fine-Tuning überhaupt zur Sprache kommt. Und die Schleife schließt sich nicht beim Launch. Produktionsfehler — die echten Fragen, die Nutzer stellen und die Ihr System falsch beantwortet — fließen direkt zurück ins Eval-Set, womit die nächste Runde an Änderungen gegen die Fehler messbar wird, die tatsächlich passiert sind, statt gegen die, die Sie sich ausgedacht haben. Das Eval-Set ist ein lebendes Artefakt, kein Häkchen. Die meisten Funktionen erreichen Stufe 3 nie, und das ist ein gesundes Ergebnis, keine Lücke.

Wo das schiefgeht

Jedes davon ist eine Stufe in der falschen Reihenfolge, und zusammen sind sie der Großteil dessen, was wir bei den KI-Projekten sehen, die vor der Produktion scheitern. Die Lösung ist kein klügeres Modell. Sie besteht darin, die billigen Stufen ordentlich zu machen, bevor man zur teuren greift.

Schluss

Die Reihenfolge ist die ganze Disziplin. Integrieren Sie, bis Sie einen echten funktionierenden Pfad haben, messen Sie, damit Sie wissen, was „besser“ heißt, und behandeln Sie Fine-Tuning als das, was Sie zuletzt, selten und nur mit Evidenz tun. Der meiste Wert wohnt in den ersten beiden Stufen, und die meisten verschwendeten Monate wohnen darin, sie zu überspringen.

Weiterführende Lektüre: für die Verdrahtung und die Daten-Klempnerei beginnen Sie mit LLMs in Geschäftssysteme integrieren und dem Leitfaden für RAG-Pipelines in der Produktion. Wenn Sie bereit sind zu messen, ist der Praxisleitfaden zur LLM-Evaluierung der feste Punkt, an dem alles andere gemessen wird.