Eine hierarchische Karte der Konzepte der KI-Engineering und wann sie von Bedeutung sind
Erfahren Sie, welche Konzepte der KI-Engineering bestimmen, ob ein System überhaupt funktioniert, welche von Bedeutung sind, sobald Sie für die Produktion entwickeln, und welche warten können.
Eine Liste von Substantiven behandelt alle zwanzig Einträge als gleichwertig, obwohl das offensichtlich nicht der Fall ist. Sechs davon bestimmen darüber, ob Ihr System überhaupt funktioniert. Weitere sieben werden relevant, sobald Sie an der Entwicklung für die Produktion arbeiten. Die letzten sieben sind Dinge, die man im Gespräch erkennen sollte, deren tieferes Verständnis man jedoch sicherlich ein Jahr lang aufschieben kann – und leider sind das meist die Themen, an denen die Leute ihre Freizeit verbringen.
Im Folgenden wird das gleiche Thema behandelt, wobei zu jedem Konzept drei Aspekte hinzugefügt werden: Was es Ihnen tatsächlich bringt, ab welchem Punkt es wichtig wird, und eine Möglichkeit, zu überprüfen, ob man es wirklich versteht und nicht nur den Begriff kennt.
Die Überprüfungen sind der Teil, dem man Aufmerksamkeit schenken sollte. Die meisten Menschen merken erst, dass sie monatelang nur zustimmend genickt haben, wenn sie versuchen, das Thema zum ersten Mal laut zu erklären.
Kategorie 1: Die sechs Faktoren, die darüber entscheiden, ob Ihr System funktioniert
1. Embeddings und Vektorabfrage
Was es Ihnen bietet: Fast alles, was mit der Datenerfassung zu tun hat, hängt von diesem Konzept ab – Fehler bei seiner Anwendung führen zu Ausfällen, die keine Fehlermeldungen auslösen.
Die Überprüfung: Zwei Embedding-Modelle erzeugen jeweils 1024-dimensionalen Vektoren. Erklären Sie, warum ein Klassifikator, der auf den Ausgaben eines Modells trainiert wurde, weiterhin fehlerhafte Ergebnisse liefert, wenn ihm Vektoren des anderen Modells vorgegeben werden.
Falls die Übereinstimmung der Dimensionen als Zeichen für Kompatibilität erscheint, liegt genau darin das Missverständnis. Ein Embedding-Modell definiert seine eigene Geometrie. Zwei verschiedene Modelle platzieren denselben Satz an völlig unterschiedlichen Positionen in Räumen, die lediglich zufällig dieselbe Form haben. Nichts in Ihrer Systemarchitektur warnt Sie davor.
2. Qualität der Datenerfassung – das ist nicht dasselbe wie RAG
Was es Ihnen bietet: Fast die gesamte Antwortqualität in einem auf Suchfunktionen basierenden System – wobei fast keine dieser Qualitätsmerkmale vom Sprachmodell selbst stammt.
Die Überprüfung: Nennen Sie die drei Punkte, an denen ein RAG-Pipeline bereits vor dem Aufruf des Sprachmodells versagen kann.
Die Antworten entstehen durch Chunking, Embedding und Ranking. Teilen Sie ein Dokument an der falschen Stelle auf, verlieren Sie den genauen Satz, der die Frage beantwortet hat. Verwenden Sie ein Embedding-Modell, das für den falschen Bereich trainiert wurde, landet Ihr Fachjargon in der falschen Region des Vektorraums. Überspringen Sie den Reranker, liefert Ihr Suchsystem Ergebnisse, die thematisch verwandt sind, aber faktisch irrelevant. Teams, die glauben, ein Problem mit Halluzinationen zu haben, haben in der Regel vielmehr ein Suchproblem – und sie verbringen oft einen Monat damit, Prompts anzupassen, bevor sie das überprüfen.
3. Bewertung
Was es Ihnen bietet: Die Fähigkeit, festzustellen, ob eine Änderung tatsächlich etwas verbessert hat – das ist es, was Ingenieursarbeit von Vermutungen unterscheidet.
Die Überprüfung: Beschreiben Sie die Goldstandards, anhand derer Sie bewerten – wie viele Beispiele es gibt, woher sie stammen, nach welchen Kriterien sie bewertet werden und wer die Bewertungen überprüft.
Falls Sie nicht mit konkreten Zahlen antworten können, handelt es sich bei dem, was Sie haben, nicht um eine echte Bewertung, sondern nur um Eindrücke sowie eine Demo, die zufällig am Dienstag funktioniert hat. Ein angemessener Ausgangspunkt sind etwa zweihundert bis fünfhundert echte Prompt-und-Antwort-Paare aus dem tatsächlichen Betriebsverkehr, die nach einer Reihe definerter Kriterien bewertet werden und bei denen ein Mensch einen Teil der Ergebnisse überprüft. Es ist außerdem wichtig zu wissen, dass, wenn Sie ein Modell als Bewertungsinstanz verwenden, dieses Modell selbst eine eigene Bewertung benötigt – ein rekursives Problem, das unangenehm, aber unvermeidlich ist.
4. Strukturierte Ausgabe und Tool-Nutzung
Was es Ihnen bietet: Die Verbindung zwischen einem System, das Text erzeugt, und einem System, das tatsächlich Aktionen ausführt.
Die Überprüfung: Das Modell gibt JSON zurück, das gegen Ihr Schema nicht validiert werden kann. Beschreiben Sie genau, was Ihr System anschließend tut.
Viele Menschen hören bei „Wir versuchen es erneut“ auf, doch genau da beginnen die eigentlichen Fragen. Wie oft wird es versucht, mit welcher Backoff-Strategie – und beinhaltet der erneute Versuch den Validierungsfehler, damit das Modell die Möglichkeit hat, seinen eigenen Fehler zu beheben? Was passiert nach dem endgültigen Misserfolg – sieht der Benutzer eine Fehlermeldung oder eine eingeschränkt, aber nutzbare Antwort? Ein Tool-Aufruf ist im Grunde eine Funktionsaufrufung über eine Grenze, die Fehlinformationen liefern kann; daher gelten hier genauso streng alle gängigen Praktiken zur Validierung unzuverlässiger Eingaben.
5. Kosten- und Latenzkontrolle
Was es Ihnen bietet: Den Unterschied zwischen einer tatsächlich veröffentlichten Funktion und einer Demo, die aus finanziellen Gründen abgelehnt wird.
Die Überprüfung: Nennen Sie Ihre aktuellen Kosten pro Anfrage und dann fünf Möglichkeiten, diese um die Hälfte zu senken, sortiert nach dem jeweiligen Einfluss.
Fünf Ansätze sollten bereitstehen. Senden Sie einfache Anfragen an ein günstigeres, kleineres Modell anstelle des Standardmodells. Cachen Sie Antworten für Anfragen, die semantisch den bereits beantworteten ähneln – nicht nur identische. Kürzen oder komprimieren Sie alles, was Sie in den Prompt eingeben. Gruppieren Sie alles, was keine Echtzeitantwort benötigt, zu Batches und verarbeiten Sie es offline. Kürzen Sie außerdem die Ausgaben des Modells, da die von ihm generierten Tokens in der Regel teurer sind als die von Ihnen eingegebenen. Laut Berichten zahlte Stripe diesen Monat mehr als 7 Milliarden Dollar für OpenRouter – ein Unternehmen, dessen Kernprodukt im Grunde die ersten beiden dieser Maßnahmen automatisiert – was darauf hindeutet, dass die Branche Kostenkontrolle nicht mehr als unwichtiges Detail betrachtet.
6. Kontextverwaltung
Was es Ihnen bietet: Vorhersehbares Verhalten, wenn die Eingabe die Kontextfenstergröße überschreitet – etwas, das in der Produktion ständig vorkommt und in Demos fast nie.
Die Überprüfung: Was wird verworfen, wenn das Kontextfenster voll ist – und wer trifft diese Entscheidung?
Eine solide Antwort nennt eine konkrete Strategie: Zuerst die ältesten Einträge entfernen, zuerst die am wenigsten bewerteten abgerufenen Teile verworfen, den mittleren Teil zusammenfassen oder die Anfrage ganz ablehnen. Eine besorgniserregende Antwort lautet, dass das Framework sich darum kümmert – was in der Regel bedeutet, dass etwas Wichtiges stillschweigend weggeworfen wird und niemand tatsächlich überprüft hat, was das ist.
Ebene 2: Die sieben Dinge, die man beim Erstellen echter Anwendungen lernt
Diese Aspekte werden relevant, sobald ein System im Einsatz ist und reale Benutzer damit interagieren. Es schadet nicht, sie bereits früher zu untersuchen, doch die Betrachtung vor dem ersten Einsatzschritt setzt die Bemühungen in den falschen Rahmen.
7. Prompts als versionierte Artefakte
Die Fähigkeit, Prompts geschickt zu formulieren, erhält weitaus mehr Aufmerksamkeit, als sie verdient, während die ingenieurtechnischen Aspekte rund um Prompts deutlich weniger Beachtung finden. Tatsächlich benötigt man ein Register, festgelegte Versionen, eine Seite-an-Seite-Vergleichsmöglichkeit sowie die Fähigkeit zum Rollback – schließlich sind Prompts im Grunde Code, der in die Produktion gelangt, ohne jemals durch einen Compiler zu gehen.
8. Chunking-Strategie
Die Aufteilung von Text in Fenster fester Größe, die Trennung entlang semantischer Grenzen sowie das Hinzufügen von Überschneidungen zwischen den Blöcken stellen alle unterschiedliche Kompromisse zwischen Erinnerungskraft und Präzision dar. Die richtige Wahl hängt davon ab, wie die zugrunde liegenden Dokumente strukturiert sind – nicht davon, welche Einstellungen ein Tutorial zufällig empfiehlt.
9. Neubewertung
Das übliche Vorgehen besteht darin, zunächst eine umfangreiche, günstige Kurzliste zu erstellen und anschließend diese Kurzliste mit einem aufwändigeren Bewertungsschritt zu verarbeiten. Das Auslassen dieses zweiten Schritts ist wahrscheinlich der häufigste Grund dafür, dass ein Suchprozess Ergebnisse liefert, die fast, aber nicht ganz korrekt erscheinen.
10. Schutzmaßnahmen und Prompt-Injektion
Dies erfordert schichtweise Absicherungen: günstige Filter am Eingangspunkt sowie teurere Überprüfungen in der Nähe des Modells selbst. Jeder Text, der von einem Benutzer oder aus einem Dokument stammt, das Ihr System heruntergeladen hat, sollte als potenziell feindlicher Eingabedaten behandelt werden – niemals als vertrauenswürdige Anweisungen.
11. Überwachbarkeit für nichtdeterministische Systeme
Was Sie hier benötigen, sind Spuren, nicht nur einfache Protokolle. Die wirklich wichtige Frage ist, welche Datenblöcke heruntergeladen wurden und welche Prompt-Version zum Zeitpunkt einer bestimmten schlechten Antwort vor drei Tagen aktiv war – nur detaillierte Spuren können diese Frage beantworten.
12. Wahl zwischen Prompting, Abruf und Feinabstimmung
Diese Entscheidung hat weitaus größeres Gewicht als das Beherrschen einer einzelnen Technik. Das Abrufen liefert Wissen, die Feinabstimmung steuert Formen, Verhalten und Ausgabeformat, während das Anleiten alles andere abdeckt, was man ohne diese beiden Methoden bewältigen kann. Ein häufiger Fehler besteht darin, auf die Feinabstimmung zurückzugreifen, um ein Problem zu lösen, das eigentlich durch mangelndes Abrufen entsteht.
13. Agentenschleifen und Werkzeugauswahl
Ein einzelner Agent, der mit einer gut ausgewählten Werkzeugkiste sowie einer begrenzten Ausführungsschleife ausgestattet ist, kann erstaunlich viele der Probleme bewältigen, die Menschen sonst durch den Einsatz von Mehr-Agenten-Architekturen lösen möchten.
Ebene 3: Die sieben, die man erkennen und auf später verschieben sollte
Für diese Ebene reicht es aus, das Vokabular gut genug zu kennen, um eine Diskussion darüber folgen zu können. Ein tieferes Eindringen kann warten, bis ein konkretes Problem dies notwendig macht – für viele Praktiker kommt dieser Moment jedoch nie.
14. Mehr-Agenten-Orchestrierung
Dies ist der am meisten überbewertete Eintrag in der Liste. Es gibt immer mehr Schriften, die untersuchen, warum diese Systeme nach der Implementierung versagen, und das wiederkehrende Fazit ist, dass Koordinationsaufwände sowie sich summierende Fehlerraten dazu führen, dass sie in den meisten Anwendungsfällen schlechter abschneiden als ein einzelner, gut definierter Agent. Kennen Sie den Begriff, wenden Sie dieses Muster nur als letztes Mittel an.
15. Quantisierung und Optimierung der Bereitstellung
Dies ist von großer Bedeutung, wenn Sie Ihre eigenen Modellgewichte hosten, aber kaum relevant, wenn Sie einfach nur eine API aufrufen.
16. Interna von Transformern
Aufmerksamkeitsmechanismen, Positionskodierungen sowie der Rest der Architektur tauchen in Interviews weitaus häufiger auf als im täglichen Arbeitsalltag. Es lohnt sich, sie einmal zu lernen, doch ein tiefes Verständnis ändert überraschenderweise kaum etwas daran, wie man Systeme entwickelt.
17. Destillation
Dies wird nützlich, sobald man bereits ein funktionsfähiges, aber teures System hat und Kosten senken muss – ein Problem, das man sich erarbeitet, anstatt es von Anfang an zu haben.
18. Semantisches Caching
Eine leistungsstarke Technik mit ernsthaften Nachteilen: Ein Cache-Hit bei einer nahezu übereinstimmenden Abfrage liefert eine falsche Antwort, die mit voller Überzeugung bereitgestellt wird.
19. Wissensgraphen und GraphRAG
Diese bieten echte Vorteile, wenn die zugrundeliegenden Daten tatsächlich relationell sind – doch um diese Vorteile zu nutzen, erfordern sie erhebliche zusätzliche Komplexität.
20. Anpassung der Präferenzen und die RLHF-Familie
Dies betrifft hauptsächlich Teams, die tatsächlich Modelle trainieren, und nicht Teams, die Anwendungen auf bereits vorhandenen Modellen entwickeln.
Der unangenehme Teil
Blickt man auf die drei Ebenen zurück, fällt einem etwas Ungewöhnliches auf.
Multi-Agenten-Orchestrierung, interne Abläufe von Transformern sowie die Formulierung von Prompts sind die Themen, die den größten Teil der Lernanstrengungen in Anspruch nehmen, und alle drei gehören zur Stufe 2 oder 3. Währenddessen bestimmen die Bewertung, die Qualität der Informationsabrufung sowie die Kostenkontrolle tatsächlich, ob ein echtes System funktioniert, erhalten sie jedoch nur einen Bruchteil der Aufmerksamkeit – hauptsächlich weil keines dieser Aspekte eine überzeugende Demonstration ermöglicht.
Es gibt einen klaren Grund für diese Lücke, und es ist sinnvoll, ihn direkt zu nennen anstatt als Kritik. Themen der Stufe 3 sind leicht verdaulich – man kann während der Fahrt zum Arbeitsplatz über Multi-Agent-Orchestrierung lesen und das Gefühl haben, etwas gelernt zu haben. Die Bewertung hingegen zwingt einen dazu, ein perfektes Datensatz zu erstellen, mit einem Teamkollegen darüber zu streiten, was überhaupt „gut“ bedeutet, und manchmal einzusehen, dass das eigene System nie so stark ist, wie die Demo es erscheinen lässt. Eine dieser Aktivitäten ist angenehm – die andere ist tatsächlich hilfreich.
Wie man diese Themen wirklich lernt anstatt sie nur sammelt
Die Falle bei einer solchen Liste besteht darin, sie als Lernplan zu betrachten, den man durchliest. Das Lesen bringt einen nur bis zum Erkennen, und dieses Erkennen bricht zusammen, sobald jemand eine Nachfrage stellt.
Zwei Gewohnheiten sind weitaus wirksamer als das alleinige Lesen.
Zuerst bauen Sie ein kleines System von Anfang bis Ende, um es anschließend absichtlich zu zerstören. Richten Sie einen Abrufprozess auf Dokumente aus, die Ihnen wirklich wichtig sind, und sabotieren Sie jede Phase absichtlich. Teilen Sie den Text unvorsichtig in Abschnitte auf und beobachten Sie, wie die Qualität der Antworten nachlässt. Entfernen Sie den Neubewertungsmechanismus und beobachten Sie, welche Veränderungen eintreten. Führen Sie einen Versuch einer Prompt-Injektion durch und sehen Sie, welche Informationen durchsickern. Ein Wochenende auf diese Weise verbracht zu haben, bringt mehr bei als ein Monat des Lesens – denn was übrig bleibt, sind Erinnerungen an konkrete Fehler, nicht abstrakte Definitionen.
Zweitens sollten Sie dieses Wortschatzwissen anhand realistischer Fragen überprüfen. Die in diesem Text beschriebenen Überprüfungen basieren auf den Arten von Fragen, die tatsächlich in der Praxis auftauchen, und das Bearbeiten echter Aufgaben im Stil des Systemdesigns ist der schnellste Weg, um Lücken in Ihrem Verständnis aufzudecken – vor allem weil echte Fragen oft Nachfragen beinhalten, und genau bei diesen Nachfragen reicht oberflächliches Erkennen nicht mehr aus.
Wo ich mich möglicherweise irren könnte
Diese Rangliste ist ein subjektives Urteil, das von den hier untersuchten spezifischen Systemen geprägt wird, und nicht das Ergebnis einer formalen Umfrage; daher ist es ehrlicher, sie als eine vertretbare Anordnung statt als die endgültige zu bezeichnen.
Zwei Einträge verdienen es, offen diskutiert zu werden. Die Multi-Agent-Orchestrierung befindet sich in Tier 3, teilweise weil die aktuellen Erkenntnisse darüber, wie diese Systeme in der Praxis funktionieren, nicht besonders positiv sind – ein wirklich solides Framework, das in naher Zukunft erscheint, könnte sie leicht nach oben verschieben. Die Interna von Transformern rangieren hier niedrig, da die Arbeit mit KI-Modellen zunehmend eher einer Integrationsaufgabe als einer Modellierungsleistung entspricht; wer direkt mit den Modellen arbeitet, sollte dieses Thema um mehrere Plätze nach oben setzen.
Der Eintrag, den man am entschiedensten verteidigen sollte, ist die Bewertung auf Platz drei – es gibt jedoch gute Gründe dafür, sie anstelle dessen auf Platz eins zu setzen. Ohne sie wird jeder andere Punkt auf dieser Liste zur Spekulation, denn man kann das nicht verbessern, was man nicht messen kann. Nur sehr wenige Teams, die heute auf Modellen aufbauen, können tatsächlich sagen, ob eine Veränderung von letzter Woche die Dinge verbessert oder verschlechtert hat.
Falls man diese Rangliste umordnen würde, liegen die interessantesten Meinungsverschiedenheiten vermutlich an der Grenze zwischen Tier 1 und Tier 2. Eine nützlichere Diskussion wäre es, zu benennen, welchen Eintrag man nach oben verschieben würde und was diese Änderung tatsächlich bringt, anstatt einfach wieder eine Liste mit zwanzig Begriffen zu erstellen.
Verwandte Artikel
- Das Management von LLMs als Richter als lebendiges Produktionsystem — Erfahren Sie, wie Netflix’ vierstufiger Lebenszyklus – Daten mit gesicherter Genauigkeit, auf Kriterien abgestimmte Schulung, sicheres Einführen sowie kontinuierliche Überwachung – dazu beiträgt, dass LLM-Richter in großem Maßstab präzise bleiben.