Überspringen und zum Inhalt gehen →

Autor: Michael

30 Tage DSPy-Challenge – Tag 19: Umgang mit widersprüchlichen Informationen

In komplexen RAG-Systemen (Retrieval Augmented Generation) stammt der Kontext oft aus heterogenen Quellen. Dies führt zwangsläufig zu Situationen, in denen abgerufene Informationen inkonsistent sind oder sich direkt widersprechen. Ein robustes System darf diese Widersprüche nicht ignorieren oder willkürlich eine Information priorisieren, sondern muss sie erkennen und transparent machen. Strategien zur Konfliktbewältigung in RAG-Systemen Sprachmodelle tendieren dazu, Antworten zu glätten. Werden einem LLM widersprüchliche Fakten im Kontext präsentiert (z. B. „Die Hauptstadt ist X“ und „Die Hauptstadt ist Y“), versucht das Modell oft, eine der beiden Optionen ohne Begründung zu wählen oder beide unlogisch zu vermischen. Dies führt zu Halluzinationen oder faktisch falschen Aussagen. Um die Zuverlässigkeit zu erhöhen, müssen Strategien implementiert werden, die den Umgang mit Ambivalenz steuern: Explizite Instruktion…

Kommentare geschlossen

30 Tage DSPy-Challenge – Tag 18: Multi-Hop-Fragen beantworten

In den vorangegangenen Einheiten habe ich eine einfache RAG-Pipeline (Retrieval Augmented Generation) implementiert. Diese Systeme funktionieren gut, solange die Antwort auf eine Frage in einem einzigen Textabschnitt zu finden ist. In der Realität erfordern viele Anfragen jedoch das Verknüpfen von Informationen aus unterschiedlichen Quellen. Am 18. Tag der Challenge liegt der Fokus auf sogenannten Multi-Hop-Fragen. Es wird erläutert, wie die Architektur eines DSPy-Moduls angepasst werden muss, um iterative Suchprozesse durchzuführen und komplexe Zusammenhänge aufzulösen. Theorie: Die Herausforderung von Multi-Hop-QA Eine Multi-Hop-Frage ist eine Anfrage, die nicht durch einen einzelnen Abrufschritt (Retrieval) beantwortet werden kann, sondern logische Zwischenschritte erfordert. Ein klassisches Beispiel lautet: „In welcher Stadt wurde der Autor von ‚Harry Potter‘ geboren?“ Ein Standard-RAG-System führt eine Vektorsuche basierend auf der…

Kommentare geschlossen

30-Tage-DSPy-Challenge: Tag 17: Optimierung deiner RAG-Pipeline

An Tag 17 der 30-Tage-DSPy-Challenge liegt der Fokus auf der systematischen Verbesserung einer bestehenden Retrieval Augmented Generation (RAG) Pipeline. Eine RAG-Pipeline habe ich gestern bereits implementiert. Nun probiere ich, wie der DSPy-Optimizer genutzt werden können, um die Qualität der generierten Antworten automatisiert zu steigern. Die Rolle von Optimizern in DSPy Ein DSPy-Optimizer, auch Teleprompter genannt, ist ein Algorithmus, der die Prompts automatisch optimiert. Anstatt Prompts manuell zu verfeinern (Prompt Engineering), lernt der Optimizer aus Daten, wie die Anweisungen an das Sprachmodell (LLM) formuliert sein müssen, um die bestmögliche Leistung zu erzielen. Der Prozess funktioniert wie folgt: TrainingsdatensatzDer Optimizer benötigt einen Satz von Beispiel-Fragen und den dazugehörigen, qualitativ hochwertigen Antworten. EvaluierungsmetrikEine Metrik ist erforderlich, um die Qualität der vom LLM generierten…

Kommentare geschlossen

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