Überspringen und zum Inhalt gehen →

jentsch.io Beiträge

30-Tage-DSPy-Challenge: Tag 16 – Aufbau einer einfachen RAG-Pipeline

Dieser Beitrag beschreibt den Aufbau einer grundlegenden RAG-Pipeline mit dem DSPy-Framework. Das System wird so konzipiert, dass es eine Nutzerfrage entgegennimmt, relevante Passagen aus einem Wikipedia-Datensatz abruft und auf Basis dieser Informationen eine fundierte Antwort generiert. Als Vektordatenbank wird Qdrant und für die Inferenz werden lokal betriebene Modelle eingesetzt. Schritt-für-Schritt-Implementierung Die Implementierung erfordert ein laufendes Setup für die lokalen Modelle (z. B. über einen llama.cpp-Server auf den Ports 8080 und 8081) sowie eine aktive Qdrant-Instanz (z. B. via Docker). Die Docker Instanz kann wie unter https://qdrant.tech/documentation/guides/installation/ beschrieben installiert werden. Nach der Installation kann man in Docker Desktop sehen, dass der Qdrant Server läuft. Ist der Docker Conainer gestartet, kann man im Browser http://localhost:6333/dashboard#/collections aufrufen und sollte das Qdrant Dashboard sehen.…

Kommentare geschlossen

30-Tage-DSPy-Challenge: Tag 15 – Was ist Retrieval Augmented Generation (RAG)?

Nach einer kleinen Weihnachtspause geht es nun endlich weiter mit der 30 Tage DSPy-Challenge. Sprachmodelle (LLMs) besitzen ein breites Allgemeinwissen, das jedoch auf den Daten basiert, mit denen sie trainiert wurden. Dieses Wissen ist statisch und kann veralten oder für spezifische, private Domänen unvollständig sein. Retrieval Augmented Generation (RAG) ist eine Architektur, die dieses Problem löst, indem sie LLMs zur Laufzeit Zugriff auf externe Wissensquellen gewährt. Anstatt eine Frage direkt an das LLM zu senden, wird die Anfrage zunächst genutzt, um relevante Informationen aus einer Wissensdatenbank zu finden. Diese Informationen werden dem LLM dann als zusätzlicher Kontext für die Beantwortung der ursprünglichen Frage bereitgestellt. Die Architektur besteht aus zwei Kernkomponenten: Embedding Die Aufgabe des Retrievers ist es, aus einem großen…

Kommentare geschlossen

30-Tage-DSPy-Challenge: Tag 14 – Wochenrückblick und Vertiefung

Die zweite Woche der Challenge konzentrierte sich auf die Prinzipien, die DSPy von traditionellem Prompt Engineering unterscheiden: die systematische Optimierung und Evaluation von Sprachmodell-Programmen. Wiederholung der Konzepte Optimierung und Evaluation Die Entwicklung robuster LLM-Anwendungen erfordert einen methodischen Ansatz zur Leistungssteigerung. DSPy formalisiert diesen Prozess durch zwei eng miteinander verbundene Konzepte: Evaluation und Optimierung. Die Evaluation ist der Prozess der objektiven Messung der Programmleistung. Sie erfordert drei Komponenten. Ein Programm (dspy.Module), das eine definierte Aufgabe ausführt. Eine Evaluationsmetrik, eine Funktion, die die Qualität der Programmausgabe im Vergleich zu einem erwarteten Ergebnis (Gold-Label) quantifiziert. Ein Evaluationsdatensatz (devset), eine Sammlung von Beispielen, die das Programm zuvor nicht gesehen hat, um eine unverfälschte Leistungsmessung zu gewährleisten. Optimierung (Kompilierung): Die Optimierung, in DSPy auch als…

Kommentare geschlossen

30-Tage-DSPy-Challenge: Tag 13 – Projekt: Optimierung eines Text-Klassifikators

Am 13. Tag der Challenge werden die bisher erlernten Konzepte in einem praxisnahen Projekt zusammengeführt. Ziel ist die Entwicklung, Optimierung und Evaluierung eines Text-Klassifikators für Kundenfeedback. Anstatt manuell Prompts zu iterieren, kommt eine vollständige DSPy-Pipeline zum Einsatz, die einen Datensatz, eine definierte Signatur, eine Metrik und den BootstrapFewShot-Optimizer integriert. Dieses Vorgehen ermöglicht eine systematische Steigerung der Modellgenauigkeit. Eigentlich nichts, was ich nicht schon in den letzten Tagen durchgespielt habe. Aber mal sehen, ob ich dabei noch was neues in DSPy entdecke 🙂 Die Qualität der Optimierung in DSPy hängt maßgeblich von der Qualität und Diversität der Trainingsdaten ab. Ein dspy.Example-Objekt verknüpft Eingabedaten (hier: Kundenfeedback) mit den erwarteten Labels (hier: Sentiment). Die Trennung in Trainings- (trainset) und Evaluationsdaten (devset) ist notwendig,…

Kommentare geschlossen

30-Tage-DSPy-Challenge: Tag 12 – Eigene Module erstellen

Während einfache DSPy-Programme mit einzelnen Prädiktoren wie dspy.Predict oder dspy.ChainOfThought erstellt werden, erfordern komplexe Anwendungen eine andere Herangehensweise. DSPy bietet hierfür das Konzept der Module (dspy.Module). Eigene Module ermöglichen es, mehrstufige Logik, mehrere Prädiktoren und komplexe Datenflüsse in wiederverwendbaren, in sich geschlossenen Komponenten zu kapseln. Kapselung von Logik mit dspy.Module Ein dspy.Module ist konzeptionell an torch.nn.Module aus dem PyTorch-Framework angelehnt. Es dient als Basisklasse für alle programmatischen Blöcke, die eine erlernbare Transformation von Eingaben zu Ausgaben durchführen. Das Erstellen eines eigenen Moduls folgt einem klaren Muster und erfordert die Implementierung von zwei zentralen Methoden wie schon im SimpleClassifier in day11.ipynb gesehen: __init__(self) (Konstruktor) In dieser Methode wird die Architektur des Moduls deklariert. Hier werden alle Sub-Module instanziiert und als Attribute…

Kommentare geschlossen

30-Tage-DSPy-Challenge: Tag 11 – Eigene Metriken zur Evaluation

Die datengesteuerte Optimierung von LLM-Anwendungen erfordert eine Methode zur Bewertung der Leistung der Prompts. Im DSPy-Framework wird diese Funktion durch Metriken erfüllt. Eine Metrik definiert, was als „gutes“ oder „korrektes“ Ergebnis für eine bestimmte Aufgabe gilt. Während DSPy einige Standard-Metriken bereitstellt, ist die Fähigkeit, eigene, aufgabenspezifische Metriken zu definieren, für eine präzise Evaluation und Optimierung unerlässlich. Aufbau und Funktion von Evaluationsmetriken Eine Metrik in DSPy ist im Kern eine Python-Funktion, die eine vom Modell generierte Vorhersage mit dem erwarteten „Goldstandard“-Ergebnis vergleicht. Die Signatur dieser Funktion ist standardisiert und lautet: metric(gold, pred, trace=None) Die Parameter haben folgende Bedeutung: Der Rückgabewert der Metrik-Funktion bestimmt das Ergebnis der Evaluation für einen einzelnen Datenpunkt. Üblicherweise ist dies: Das dspy.Evaluate-Werkzeug führt diese Metrik für jeden…

Kommentare geschlossen

30-Tage-DSPy-Challenge: Tag 10 – Der BootstrapFewShot-Optimizer im Detail

Ziel ist es, den Algorithmus zu verstehen und den Unterschied zwischen einem manuell erstellten und einem automatisch generierten Prompt praktisch aufzuzeigen. Der Mechanismus von BootstrapFewShot Der BootstrapFewShot-Optimizer automatisiert die Erstellung von effektiven Few-Shot-Prompts. Anstatt dass ein Entwickler manuell Beispiele (Demonstrationen) auswählen muss, führt der Optimizer einen datengesteuerten Prozess durch. Der Kernalgorithmus lässt sich in folgende Schritte unterteilen: Iteration über den TrainingsdatensatzDer Optimizer durchläuft jedes Beispiel im bereitgestellten Trainingsset (trainset). Jedes dieser Beispiele wird einmal als zu lösende Aufgabe behandelt. Simulation des LernprozessesFür jedes Trainingsbeispiel simuliert der Optimizer, wie das zu trainierende DSPy-Modul (das „Studenten-Modell“) die Aufgabe lösen würde. Generierung von Kandidaten-Prompts Um dem Studenten-Modell zu helfen, wählt der Optimizer eine kleine Anzahl anderer Beispiele aus dem Trainingsset aus und formatiert…

Kommentare geschlossen

30-Tage-DSPy-Challenge: Tag 8 & 9 – Daten zur Optimierung

Heute mache ich mal Tag 8 und 9 zusammen, da es mir doch etwas wenig erscheint, einfach nur ein Datensatz zu erstellen und ihn nicht zu benutzen. Dafür habe ich dann morgen frei 🙂 – Los geht’s. Anstatt Prompts manuell zu verfeinern, nutzt DSPy sogenannte „Teleprompter“, um diese Aufgabe automatisiert durchzuführen. Die Grundlage für jede dieser Optimierungen ist ein Datensatz, der aus Beispielen besteht mit denen die Prompts optimiert werden. Die Rolle von Beispieldaten (dspy.Example) In DSPy ist ein Datenpunkt kein einfacher Text-String oder ein Dictionary, sondern ein strukturiertes Objekt vom Typ dspy.Example. Ein dspy.Example kapselt alle zu einem Datenpunkt gehörenden Informationen, wie Eingabefelder (z. B. eine Frage) und Ausgabefelder (z. B. die erwartete Antwort). Diese strukturierten Beispiele erfüllen zwei…

Kommentare geschlossen

1.000.000 in 9 Jahren – Eine Bilanz in Schweiß und Daten

Wenn man die Zahl 1.000.000 hört, denkt man meist an Euro auf dem Bankkonto oder Klicks auf YouTube. Aber es gibt eine Währung, die man nicht sparen kann, sondern die man ausgeben muss, um reicher zu werden: Kalorien. Heute werfe ich einen Blick zurück auf einen Zeitraum, der am 1. Januar 2017 begann und bis heute, in den 16. Dezember 2025, reicht. Ein Blick auf mein Polar Flow Tagebuch zeigt nicht nur bunte Balken und Linien, sondern die Geschichte meiner sportlichen Aktivität. Die „Big Data“ der Ausdauer Was bedeutet es, über 9 Jahre hinweg den Sport in den Alltag zu integrieren? Was wurde trainiert? Ein Blick auf die Sportartenverteilung verrät sofort: Mein Herz schlägt für alles, was Räder hat. Gehen…

Kommentare geschlossen

30-Tage-DSPy-Challenge: Tag 7 – Wiederholung und Vertiefung der Kernkonzepte

Der Tag heute dient der Konsolidierung des Wissens aus der ersten Woche. Der Fokus liegt auf der Wiederholung der zentralen Konzepte von DSPy – Signaturen, Module und ChainOfThought – und deren praktischer Anwendung in einem erweiterten Projekt. Kernkonzepte im Überblick Die drei wichtigsten Bausteine, die in der ersten Woche eingeführt wurden, sind Signaturen, Module und die ChainOfThought-Logik. Erweiterung des Zitat-Generators Das bestehende Programm zur Generierung von Zitaten wird nun um eine zusätzliche Funktionalität erweitert. Ich ergänze es um die Bewertung des generierten Zitats. Initialisierung des Sprachmodells Zunächst wird die Verbindung zu einem lokalen Sprachmodell hergestellt. Diese Konfiguration bleibt im Vergleich zum ursprünglichen Skript unverändert. Definition der Signaturen Die bestehende Signatur GenerateQuote bleibt bestehen und es wird eine neue Signatur, ClassifyQuote…

Kommentare geschlossen