LLM-Engineers-Handbook: ein Buch-Repository als Referenzarchitektur für RAG auf AWS

Ein Repository, das ein Buch begleitet, kein Paket

Die erste Erwartungshaltung, die dieses Projekt enttäuscht, ist die eines installierbaren Werkzeugs. Das README beschreibt den Zweck offen: Es ist das offizielle Repository zum Buch LLM Engineer's Handbook von Paul Iusztin und Maxime Labonne. Wer nach pip install sucht, findet stattdessen Poetry, pyenv und eine Verzeichnisstruktur, die man klont und liest. Das ist keine Schwäche, sondern die Gattung. Der Wert liegt darin, dass hier eine durchgehende Kette gezeigt wird: Datensammlung und -generierung, Trainingspipeline, ein einfaches RAG-System, AWS-Deployment, Monitoring sowie ein Test- und Evaluationsrahmen. Diese sechs Punkte stehen im README unter Features und bilden zusammen das, was in vielen anderen Repositories fehlt: die Verbindung zwischen Modelltraining und Betrieb. Die Zielgruppe sind entsprechend nicht Anwendungsentwickler, die eine RAG-Bibliothek einbinden wollen, sondern Engineers, die den Aufbau eines solchen Systems einmal vollständig nachvollziehen möchten. Das README weist ausdrücklich darauf hin, dass der Code aktiv gepflegt wird und vom Buch abweichen kann, mit der Aufforderung, immer das Repository als aktuelle Fassung zu betrachten. Für Leser bedeutet das: Kapitelnummern und Dateipfade im Buch können veraltet sein, das Repository ist die Referenz.

Domain-Driven Design als Ordnungsprinzip im Paket llm_engineering

Das Kernpaket llm_engineering ist nach Domain-Driven Design gegliedert, und das README benennt die vier Schichten konkret: domain für Kernentitäten, application für Geschäftslogik, Crawler und die RAG-Implementierung, model für Training und Inferenz, infrastructure für die Anbindung externer Dienste wie AWS, Qdrant, MongoDB und FastAPI. Entscheidend ist die angegebene Importrichtung: infrastructure → model → application → domain. Das ist eine gerichtete Abhängigkeit, bei der die inneren Schichten nichts von den äußeren wissen. In der Praxis heißt das, dass die RAG-Logik in application nicht direkt den Qdrant-Client importiert, sondern über Schnittstellen arbeitet, die infrastructure implementiert. Wer diesen Aufbau übernimmt, bekommt eine testbare Struktur: Die Domänenlogik lässt sich ohne laufenden Vektorspeicher prüfen. Der Preis ist Boilerplate. Für ein kleines Skript, das drei Dokumente einbettet und eine Frage beantwortet, ist diese Schichtung übertrieben. Das README selbst spricht von einem simple RAG system, was im Kontrast zur aufwendigen Paketstruktur steht. Man sollte das nicht als Widerspruch lesen, sondern als Hinweis darauf, dass die Architektur hier demonstrativen Charakter hat. Sie zeigt, wie man es in einem Team aufsetzt, nicht wie man es minimal hält.

ZenML-Pipelines, Steps und YAML-Konfiguration als Steuerungsebene

Die eigentliche Ausführung liegt nicht im Paket, sondern in pipelines/ und steps/. Das README beschreibt pipelines/ als ZenML-ML-Pipelines und Einstiegspunkt für alle ML-Pipelines, die Datenverarbeitung und Modelltraining koordinieren. steps/ enthält einzelne ZenML-Steps als wiederverwendbare Bausteine für Datenladen, Vorverarbeitung und ähnliche Aufgaben. Getrennt davon liegen in configs/ ZenML-YAML-Dateien, die die Ausführung von Pipelines und Steps steuern. Diese Trennung von Code und Konfiguration ist der praktisch relevanteste Teil des Repositories, weil sie bedeutet, dass man Abläufe ändern kann, ohne Python anzufassen. Der Datenfluss, soweit aus der Struktur ableitbar, verläuft über ZenML als Orchestrator und Artefaktschicht: Steps erzeugen Artefakte, Pipelines verketten sie. ZenML ist im README zugleich als Orchestrator und als artifacts layer benannt, was die Doppelrolle erklärt. Wer bereits einen eigenen Orchestrator betreibt, etwa Airflow, muss die Steps übernehmen und die Pipeline-Definitionen neu schreiben. Das ist keine Kleinigkeit, denn die Step-Signaturen sind auf ZenML-Typen zugeschnitten. Umgekehrt ist genau das der Grund, warum die Beispiele kurz bleiben: Die Orchestrierung ist ausgelagert, die Steps konzentrieren sich auf ihre jeweilige Aufgabe.

Installation: Python 3.11, Poetry, Docker und acht externe Dienste

Das README listet die lokalen Abhängigkeiten mit Versionen: pyenv ab 2.3.36 optional für mehrere Python-Versionen, Python 3.11 als Laufzeitumgebung, Poetry ab 1.8.3 und unter 2.0 für die Paketverwaltung, Docker ab 27.1.1, AWS CLI ab 2.15.42, Git ab 2.44.0. Die Poetry-Obergrenze unter 2.0 ist bemerkenswert, weil sie bedeutet, dass ein Upgrade auf Poetry 2.x nicht vorgesehen ist, ohne die Lock-Datei und möglicherweise das Build-Backend anzupassen. Der Einstieg beginnt mit git clone des Repositorys und cd in das Verzeichnis, danach folgt die Python-Umgebung. Das README bietet zwei Wege: die globale Python-Installation, sofern Version 3.11 vorhanden ist, geprüft über python --version, oder pyenv als empfohlene Variante. Auf der Cloud-Seite stehen HuggingFace als Model Registry, Comet ML als Experiment Tracker, Opik als Prompt-Monitoring, ZenML als Orchestrator, AWS für Compute und Storage, MongoDB als NoSQL-Datenbank, Qdrant als Vektordatenbank und GitHub Actions für CI/CD. Das README sagt, man müsse zunächst nichts tun, Kapitel 2 führe durch die Werkzeuge, Kapitel 10 und 11 durch die Einrichtung. Genau hier liegt die realistische Hürde: Acht Dienste, teils mit eigenen Konten und Zugangsdaten, sind zu konfigurieren, bevor die Pipelines vollständig laufen. Wer nur die RAG-Retrieval-Logik ansehen will, kann das über tools/rag.py tun, das laut README die Nutzung des RAG-Retrieval-Moduls demonstriert.

Was das Repository nicht leistet

Es gibt keinen Hinweis auf Releases, das Repository führt keine veröffentlichten Versionen. Wer es klont, arbeitet auf dem Stand des main-Branches. Das README warnt selbst, dass der Code aktiv gepflegt wird und vom Buch abweichen kann. Für Reproduzierbarkeit heißt das: Man pinnt den Commit selbst, wenn man einen bekannten Stand braucht. Ein zweiter Punkt betrifft die Tests. tests/ enthält laut README einige Beispieltests, die im CI-Pipeline als Beispiele dienen. Es ist keine Rede von einer umfassenden Testsuite, und die Formulierung legt nahe, dass der Umfang bewusst klein gehalten ist. Wer erwartet, hier eine abgesicherte Bibliothek zu finden, wird enttäuscht. Drittens die Abhängigkeit von kostenpflichtigen oder kontobasierten Diensten: AWS, MongoDB, Qdrant, Comet ML und Hugging Face sind alle extern. Das Repository ist damit kein lokal lauffähiges Ganzes, sondern eine Anleitung, die ohne diese Konten nur teilweise funktioniert. Und schließlich: Das trainierte Modell TwinLlama-3.1-8B-DPO liegt auf Hugging Face, das Training selbst setzt aber auf die Pipeline-Infrastruktur. Wer nur das Modell ausprobieren will, braucht das Repository dafür nicht.

Alternative: LangChain oder LlamaIndex statt einer Buchcodebasis

Der naheliegende Vergleich ist eine RAG-Bibliothek wie LangChain oder LlamaIndex. Der Unterschied liegt nicht im Funktionsumfang, sondern im Ansatz. Diese Bibliotheken liefern importierbare Abstraktionen: Loader, Splitter, Retriever, Chains. Man installiert ein Paket und ruft Klassen auf. Das LLM-Engineers-Handbook-Repository liefert dagegen eine ausgeführte Instanz dieser Abstraktionen, eingebettet in eine DDD-Struktur mit ZenML-Pipelines und AWS-Anbindung. Wer eine Bibliothek einbindet, bekommt Versionierung, dokumentierte APIs und eine Community, die Fehler meldet. Wer dem Repository folgt, bekommt eine konkrete Implementierung, die man Zeile für Zeile lesen und anpassen kann, aber keine Zusicherung über Schnittstellenstabilität. Für den Einstieg in RAG ist die Bibliothek der kürzere Weg. Für das Verständnis, wie man Datenaufnahme, Training, Deployment und Monitoring in einem System verbindet, ist das Repository ergiebiger, weil es die Lücken zeigt, die eine Bibliothek hinter ihrer API versteckt. Die Entscheidung hängt davon ab, ob man bauen oder verstehen will. Beides gleichzeitig ist möglich, aber nicht mit demselben Zeitbudget.

Wartung, Lizenz und was vor dem Einsatz zu prüfen ist

Das Repository steht unter der MIT-Lizenz. Das ist die permissivste gängige Variante: Nutzung, Änderung und Weitergabe sind erlaubt, sofern der Copyright-Hinweis und der Lizenztext erhalten bleiben. Für abgeleiteten Code, der in ein eigenes Produkt fließt, ist das unproblematisch. Zu beachten ist allerdings, dass die MIT-Lizenz nur den Code im Repository abdeckt. Die eingebundenen Dienste haben eigene Bedingungen, und das trainierte Modell TwinLlama-3.1-8B-DPO liegt auf Hugging Face unter einer dort angegebenen Lizenz, die separat zu prüfen ist. Wer das Modell produktiv einsetzt, muss diese Bedingungen selbst bewerten. Wartungskosten entstehen vor allem durch die Abhängigkeiten: Poetry unter 2.0, Python exakt 3.11, Docker ab 27.1.1, AWS CLI ab 2.15.42. Jede dieser Untergrenzen ist eine potenzielle Reibungsfläche bei einem Upgrade der eigenen Umgebung. Der Hinweis im README, dass der Code aktiv gepflegt wird und vom Buch abweichen kann, ist doppelt zu lesen: Es ist ein Versprechen laufender Pflege und eine Warnung, dass die schriftliche Fassung nicht die aktuelle ist. Wer das Repository als Grundlage nimmt, sollte den verwendeten Commit festhalten und die configs/-YAML-Dateien als das behandeln, was sie sind: die eigentliche Steuerungsebene, deren Änderungen sich unmittelbar auf die Pipeline-Ausführung auswirken.

Redaktionelles Fazit

Wer eine vollständige, lauffähige Referenzkette von Data Crawling über Fine-Tuning bis zur AWS-Bereitstellung sucht und bereit ist, acht externe Dienste zu konfigurieren, findet hier ein zusammenhängendes Beispiel. Wer eine Bibliothek zum direkten Importieren braucht, ist falsch. Prüfe zuerst, ob Poetry-Version, Python 3.11 und die in configs/ hinterlegten ZenML-YAML-Dateien zu deiner Zielumgebung passen, und lies den Hinweis im README, dass das Repository aktiv gepflegt wird und vom Buchstand abweichen kann.

Offizielle Quellen

1. Issues
2. License: MIT
3. PacktPublishing/LLM-Engineers-Handbook on GitHub
4. Project website
5. README