Kategorie: Allgemein

Die Entwicklung von spezialisierten Large Language Models (LLMs) für die Softwareentwicklung hat in den letzten Jahren beeindruckende Fortschritte gemacht. Ein neuer Player in dem Spiel ist das Modell NousResearch/NousCoder-14B. Dieses Modell wurde gezielt für die Lösung Programmieraufgaben und die Teilnahme an Programmierwettbewerben (Olympiad Programming) optimiert. Als Open-Source-Alternative bietet es Entwicklern und Unternehmen eine leistungsstarke Basis für automatisierte Code-Generierung und algorithmische Problemlösungen. Einführung in NousResearch/NousCoder-14B Bei NousResearch/NousCoder-14B handelt es sich um ein spezialisiertes Sprachmodell, das auf der Architektur von Qwen2.5-Coder-14B-Instruct basiert. Das primäre Ziel der Entwicklung bestand darin, die Fähigkeiten im Bereich des logischen Schlussfolgerns und der algorithmischen Effizienz zu steigern. Während viele Modelle die Syntax von vielen Programmiersprachen beherrschen, liegt der Fokus hier auf der Bewältigung von Aufgaben, die normalerweise…

In den vorangegangenen Tagen lag der Fokus auf der Konstruktion von Modulen, der Integration von Retrieval-Systemen und der Optimierung durch Teleprompter. An Tag 25 und 26 wird der entscheidende Schritt zum Produkt behandelt: Die Kompilierung des DSPy-Programms in ein statisches Artefakt und dessen Speicherung. Ziel dieses Beitrags ist es, den compile-Prozess theoretisch einzuordnen und praktisch anhand eines RAG-Systems (Retrieval Augmented Generation) umzusetzen. Dabei wird demonstriert, wie ein optimierter Zustand gespeichert und in einer neuen Umgebung wiederhergestellt wird. Der Kompilierungsprozess in DSPy In der klassischen Softwareentwicklung übersetzt ein Compiler menschenlesbaren Code in maschinenlesbare Anweisungen. In DSPy bezieht sich der Begriff „Kompilierung“ auf den Prozess, bei dem ein deklaratives Modul (z. B. dspy.ChainOfThought) mithilfe des Teleprompters und eines Trainingsdatensatzes in eine optimierte…

In der Entwicklung von Anwendungen auf Basis von Large Language Models (LLMs) stellt die Konsistenz der Ausgaben eine zentrale Herausforderung dar. Während LLMs kreativ und flexibel Text generieren, erfordern Software-Schnittstellen strikte Datenformate und logische Konsistenz. Tag 24 der DSPy-Challenge widme ich mich dem Konzept der Assertions und Validierungen. Ich werde prüfen, wie durch definierte Constraints (Einschränkungen) und Validierungslogik sichergestellt wird, dass extrahierte Daten – wie beispielsweise Preise – den formalen Anforderungen entsprechen. Theorie: Assertions und Selbstkorrektur Der Begriff „Assertion“ beschreibt in der Programmierung eine Aussage, die zu einem bestimmten Zeitpunkt wahr sein muss. Im Kontext von DSPy und LLMs dienen Assertions dazu, Annahmen über die Modellausgabe zu überprüfen. Erfüllt eine Ausgabe die definierten Kriterien nicht (z. B. „Der Preis muss…

In der Entwicklung von Anwendungen mit Large Language Models (LLMs) besteht eine Herausforderung darin, die natürlichsprachlichen Ausgaben des Modells in ein maschinenlesbares Format zu überführen. Während LLMs gut darin sind, Texte zu generieren, benötigen nachgelagerte Softwareprozesse (z. B. Datenbanken oder APIs) strukturierte Daten wie XML, JSON oder TOON. DSPy bietet integrierte Mechanismen, die über Prompt Engineering hinausgehen und die Typensicherheit von Python-Bibliotheken wie Pydantic nutzen. Von Text zu Struktur mit Typisierung Traditionell wird versucht, LLMs durch Anweisungen im Prompt (z. B. „Antworte nur im JSON-Format“) zur Ausgabe strukturierter Daten zu bewegen. Dieser Ansatz ist leider oft fehleranfällig, da das Modell invaliden Code oder zusätzlichen Konversationstext generieren kann. DSPy abstrahiert diesen Prozess durch die Verwendung von Typed Signatures (typisierten Signaturen). Anstatt…

In den vorangegangenen Lektionen lag der Fokus auf der Optimierung von Prompts und dem Abruf von Informationen (RAG). Am Tag 22 widme ich mich der Erstellung eines Agenten, der aktiv Werkzeuge nutzen kann. Das ReAct-Konzept: Reasoning and Acting Sprachmodelle (LLMs) besitzen die Fähigkeiten in der Textgenerierung, weisen jedoch Schwächen bei exakten Berechnungen oder dem Zugriff auf Echtzeitdaten auf. Um diese Lücke zu schließen, wurde das ReAct-Paradigma („Reasoning and Acting“) entwickelt. Das Konzept kombiniert zwei Prozesse: Reasoning (Überlegen)Das Modell analysiert die Eingabe und plant die nächsten Schritte (ähnlich wie bei Chain-of-Thought). Acting (Handeln)Das Modell entscheidet, ein externes Werkzeug (Tool) aufzurufen, um spezifische Informationen zu erhalten oder Berechnungen durchzuführen. Ablauf DSPy abstrahiert diesen komplexen Prozess durch das Modul dspy.ReAct. Definition des Werkzeugs…

Large Language Models (LLMs) haben einen Reifegrad erreicht, der über rein quantitative Parameter wie Token-Durchsatz oder Parameteranzahl hinausgeht. Modelle werden zunehmend durch spezifische Antwortcharakteristiken und Verhaltensmuster differenziert, die ich hier unter dem Begriff der „Modell-Persönlichkeit“ zusammengefasse. Diese resultieren primär aus den verwendeten Trainingsdatensätzen, den Verfahren des Reinforcement Learning from Human Feedback (RLHF) sowie den systemseitigen Pre-Prompts. Ich habe in den letzten Monaten und Jahren viele unterschiedliche Modelle genutzt und mis sind dabei folgende Unterschiede bei den Modellen aufgefallen. Google Gemini 3 (Der Oktopus) Gemini 3 zeichnet sich durch eine native Verarbeitung unterschiedlicher Datenmodalitäten aus. Die Architektur ist darauf optimiert, massive Kontextfenster (bis zu 2 Millionen Tokens) systematisch zu erforschen. Aktuell ist es meine erste Wahl, wenn ich bereit bin, die…

Der Tag 21 der DSPy-Challenge dient dem Rückblick auf die dritte Woche und der technischen Vertiefung der Retrieval Augmented Generation (RAG). Nachdem ich in den vergangenen Tagen die Grundlagen von RAG, den Umgang mit Multi-Hop-Fragen und die Integration eigener Daten behandelt habe, liegt der Fokus nun auf der qualitativen Verbesserung des Retrieval-Schritts mit Hilfe von HyDE. Hypothetical Document Embeddings (HyDE) Eine häufige Schwachstelle in RAG-Systemen ist die Diskrepanz zwischen der Suchanfrage und den gespeicherten Dokumenten. Während Fragen oft kurz und prägnant sind, beinhalten die Dokumente detaillierte Kontexte. Dies kann dazu führen, dass die Vektorähnlichkeitssuche keine optimalen Ergebnisse liefert. Eine Lösung für dieses Problem werde ich heute mit Hypothetical Document Embeddings (HyDE) implementieren. Die Kernidee von HyDE besteht darin, nicht die…

Dieser Blog-Beitrag beleuchtet die Evaluierung des KI-Modells IQuest-Coder-V1-40B-Instruct-GGUF. Die Durchführung der Tests erfolgt mittels llama.cpp auf einem HP ZBook Ultra G1a, ausgestattet mit einem AMD Ryzen AI Max+ PRO 395 Prozessor und 128 GB Arbeitsspeicher. Ziel dieser Untersuchung ist es, die Leistungsfähigkeit des Modells unter realen Hardware-Bedingungen zu analysieren. Das IQuest-Coder-V1-40B-Instruct-Modell, entwickelt von IQuestLab, ist ein 40-Milliarden-Parameter-Modell, das auf der CodeLlama-Architektur basiert. Es wurde speziell für Aufgaben im Bereich der Code-Generierung und -Verständnis trainiert. Die Modellbeschreibung hebt dessen Fähigkeiten in verschiedenen Benchmarks hervor, darunter HumanEval, MBPP und GSM8K. Auf dem HumanEval-Benchmark erreicht das Modell eine Pass@1-Rate von 72,1%, während auf MBPP eine Pass@1-Rate von 70,5% erzielt wird. Diese Werte positionieren das Modell im oberen Bereich der verfügbaren Sprachmodelle für Code-Aufgaben.…

Die Implementierung eines Retrieval Augmented Generation (RAG) Systems ermöglicht es großen Sprachmodellen (LLMs), auf spezifisches, nicht im Trainingsdatensatz enthaltenes Wissen zuzugreifen. Während in den vorangegangenen Tagen der Challenge grundlegende RAG-Konzepte behandelt wurden, liegt der Fokus an Tag 20 auf der Integration eigener, lokaler Daten. Dieser Beitrag beschreibt die Erstellung einer RAG-Pipeline in DSPy, die lokale Dokumente indiziert und mithilfe derQdrant Vektordatenbank durchsuchbar macht. Konzept und Architektur Ein RAG-System für eigene Daten besteht in DSPy aus drei Hauptkomponenten: Die DatenquelleUnstrukturierter Text, der in Vektoren (Embeddings) umgewandelt wird. Das Retrieval Model (RM)Eine Komponente, die semantisch relevante Abschnitte sucht. Hierfür wird Qdrant verwendet, eine leistungsfähige Open-Source-Vector-Search-Engine mit der ich in der Vergangenheit schon viel gute Erfahrungen habe. Das DSPy-ProgrammEin Modul, das den Retriever…

In diesem Blogpost teste ich, wie man den neuen VECTOR-Datentyp in MariaDB 11 verwendet. Wie wird er definiert? Wie speichert MariaDB die Daten? Welche Abfragen sind möglich – und wo liegen die aktuellen Grenzen? Ziel ist es, ein Bild davon zu bekommen, ob sich MariaDB mit VECTOR als Backend für moderne KI- und RAG-Szenarien eignet oder ob man weiterhin auf spezialisierte Vektordatenbanken setzen sollte. In der Vergangenheit habe ich meistens Qdrant oder ChromaDB verwendet und musste dann immer 2 Datenbank-Verbindungen in der App managen. Eine SQL Datenbank und eine Vector-Datenbank. Mit dem Datentyp VECTOR in MariaDB könnte das ein Ende haben. Datenbank erstellen und Benutzerrechte vergeben Der erste Schritt ist die Erstellung der Datenbank selbst. In meinem Test nenne ich…