Retrieval Augmented Generation und Cache Augmented Generation

Wie gut schlagen sich kleine Sprachmodelle bei der Verarbeitung längerer Texte? Es existieren hierfür zwei bekannte Ansätze, Retrieval-Augmented Generation (RAG) und Cache-Augmented Generation (CAG).

Retrieval-Augmented Generation (RAG)

Bei diesem Ansatz wird zunächst ein Retrieval-Schritt durchgeführt, bei dem relevante Textstellen gesucht und anschließend an das Sprachmodell übergeben werden. Häufig kommen dabei Word Embeddings und Vektordatenbanken zum Einsatz. Allerdings gab es bei meinen eigenen Tests Hinweise darauf, dass diese Methode speziell bei deutschen Texten nicht immer gut funktioniert. Klassisches Retrieval (z. B. durch Suchalgorithmen) könnte hier eine bessere Alternative sein. Zugegebenermaßen handelt es sich hier um anekdotische Evidenz, ein systematischer Test könnte hier Klarheit bringen.

Cache-Augmented Generation (CAG)

Hier wird ein potenziell großes Dokument in den Kontext in das Modell geladen. Dafür ist ein großes Kontextfenster nötig, weshalb ja auch schon in Teil 1 erwähnt wurde, dass für diesen Test Modelle mit entsprechend großer Kapazität ausgewählt wurden. In einem aktuellen Artikel wird jedoch auf das Problem des „Context Rot“ hingewiesen, was bedeutet, dass bei einem großen Kontext die Qualität der Antworten eines Modells degeneriert.

Die getesteten Modelle

Eine positive Überraschung war, dass Qwen3 doch geeignet ist um mit langen Texten umzugehen! Die bisher betrachtete MLX-Version hatte, wie schon in den vorherigen Teilen erwähnt, Probleme mit einem großen Kontext. Die trifft jedoch erfreulicherweise nicht auf die „unsloth“-Version zu. Da diese auf dem Mac allerdings nicht die MLX-Schnittstelle nutzt, ist sie langsamer und liegt damit in puncto Geschwindigkeit auf einem ähnlichen Niveau wie GPT-OSS.

Gemma blieb außen vor, da es bei langen Kontexten sehr lange braucht, um den Prompt zu verarbeiten. Dies ist zunächst einmal normal, allerdings waren anderen die anderen Modelle nur bei der ersten Anfrage, in der also tatsächlich mit einem sehr langen Prompt der Kontext eingebracht wurde, langsam. Danach antworteten sie in normaler Zeit. Gemma dagegen brauchte oftmals auch danach noch sehr lange, um weitere Anfragen zu beantworten.

In diesem Test wurden daher die folgenden drei Modelle betrachtet:

• GPT-OSS
• Qwen3 (in der „unsloth“-Version)
• Mistral 3.2 Small

Einstellungen

Bei allen Modellen ist darauf zu achten, dass die context length hoch gedreht wird (z.B. bei LM Studio ist sie standardmäßig bei lediglich 4096 Tokens) und, damit das Speicher-Limit nicht gesprengt wird, Flash Attention und Cache Quantization aktiviert wird. (Den Hinweis, dass die Einstellung Context Length ignoriert wird, wenn KV Cache Quantization aktiviert wird, kann man übrigens selbst ignorieren… Wenn Context Length nicht trotzdem erhöht wird, werden große Prompts nicht akzeptiert.)

Die Testdaten

Neben zwei wissenschaftlichen Arbeiten wurden drei Wikipedia-Einträge als Grundlage genommen:

• Frankfurt-Nordend
• Charles Babbage
• Richard von Weizsäcker (ehemaliger Bundespräsident)

Sowohl beim Frankfurter Nordend (siehe Tests in den vorherigen Teilen) als auch bei Charles Babbage kam es, wenn die Modelle nur ihr Weltwissen zur Verfügung hatten, zu Halluzinationen.

Wurden die Artikel komplett in den Kontext geladen, konnten jedoch alle Modelle alle Fragen korrekt beantworten!

Herausforderungen bei Richard von Weizsäcker

Der Artikel über Richard von Weizsäcker war deutlich länger und stellte die Modelle vor größere Herausforderungen. Hier mussten Flash Attention und KV Cache Quantization zum Einsatz kommen.

Testfrage 1: Wo war Richard von Weizsäcker Ehrenbürger?

• Problem: Bonn, Stuttgart und Berlin wurden zusammen erwähnt, Danzig erst später.
• Ergebnis: Die Modelle fanden Danzig nicht immer. Allerdings verbesserte sich die Trefferquote, wenn der Prompt geschickt formuliert wurde (z. B. mit der Forderung, auch scheinbar gefundene Informationen weiter zu überprüfen).

Testfrage 2: Wie ist Fritz von Weizsäcker gestorben?

Fritz von Weizsäcker ist ein Sohn Richards.

• Problem: Im Text stand nur das Sterbejahr, Dass sein Tod ein Mord war, wurde lediglich in einer einzigen Angabe im Literaturverzeichnis erwähnt (Verweis auf den Artikel „Brutale Bluttat in Berlin: Das steckt hinter dem Mord an Fritz von Weizsäcker„)
• Ergebnis:
  • Qwen3 und GPT-OSS gaben keine Auskunft darüber.
  • Mistral halluzinierte das genaue Sterbedatum und Umstände des Mordes, die nicht den Tatsachen entsprachen. Bei Nachfrage gab Mistral jedoch zu, dass es sich um eine Halluzination handelte.

Wissenschaftliche Arbeiten und Halluzinationsprobleme

Ein weiteres Problem zeigte sich bei der Verarbeitung wissenschaftlicher Texte:

• GPT-OSS erfand in einem Fall eine Skala von 1–5, die so nicht beschrieben war. In Wahrheit wurde in der Arbeit ein rein qualitativer Ansatz beschrieben.
• Mistral und Qwen3 machten diesen Fehler nicht.

Besonders auffällig war, dass GPT-OSS selbst bei der Verarbeitung nur des einzelnen Abschnitts, in der dies beschrieben war, die numerische Skala erfand. Diese Beobachtung führt zu einer wichtigen Erkenntnis: Hier wäre ein RAG-Ansatz auch keine Lösung gewesen. Da das Problem hier offensichtich nicht an der Länge des Kontextes lag, hätte auch die gezielte Auswahl relevanter Textstellen durch Retrieval nichts geändert.

Fazit

Prinzipiell eignen sich die drei betrachteten Modelle für Cache Augmented Generation, allerdings mit Einschränkungen. In allen Fällen muss beachtet werden, dass Halluzinationen trotzdem auftreten können, auch wenn die korrekten Antworten im Kontext stecken. Dies ist ein größeres Problem, wenn auch der Kontext größer ist, aber das GPT-OSS-Beispiel zeigt, dass es auch sonst auftreten kann. Mit geeigneten Prompts, in denen die Modelle angewiesen werden, Textstellen zu zitieren, in denen das behauptete steht, lässt sich diese Gefahr verkleinern, wenn auch nicht komplett ausräumen. Interessanterweise beachteten Qwen3 und Mistral die Anweisungen bedeutend besser als GPT-OSS, das die Anweisung, Textstellen zu zitieren, weitgehend ignorierte.

Aus diesen Gründen würde ich GPT-OSS für diesen Anwendungsfall eher nicht verwenden. Qwen3, in der „unsloth“-Version, funktionierte dagegen erstaunlich gut, was für mich überraschend war, da die MLX-Version durch eine große context length noch zum Absturz gebracht werden konnte. Qwen3 ist trotz der Leistungseinbußen durch die Verwendung der GGUF- statt MLX-Schnittstelle außerdem mmer noch deutlich schneller als Mistral.

OpenAI’s gpt-oss 20B

Mitten in meinen Praxistests kommt auf einmal OpenAI und stellt eine neue Version von gpt mit „open weights“ zur Verfügung. Auch wenn es als Reasoning-Modell eigentlich nicht in das Schema dieses Vergleichs passt, lässt sich ein Modell von OpenAI natürlich nicht einfach ignorieren! Zudem ist die Reasoning-Phase recht kurz und wenn man in LM Studio einstellt, dass reasoning_content und content in der API getrennt werden, funktioniert es auch mit der Editor-Integration in Zed.

Aber ist das Modell auch gut?

Spoiler: Nein.

Direkt die erste Testfrage liefert eine negative Überraschung: gpt wertet das aktuelle Datum aus, weiß also, dass gerade August 2025 ist, und antwortet trotzdem, dass Joe Biden Präsident der USA sei.

Die Antworten zu den anderen Testfragen (siehe Teil 2) sind unauffällig. gpt macht auf Deutsch Fehler, so ist bei der Frage nach dem Gesetzgebungsprozess statt vom Vermittlungsausschuss vom „Konkiliationsausschuss“ die Rede. Auch in der Inge-Wenzel-Geschichte sind ein paar merkwürdige Formulierungen.

Bei der Frage nach Sehenswürdigkeiten im Frankfurter Nordend (zum Test von Halluzinationen aus dem Modellwissen) schneidet gpt-oss ziemlich schlecht ab.

	genannte Orte	davon tatsächlich existent	weitgehend korrekt beschrieben	davon tatsächlich im Nordend
Gemma3-12B	17	10	9	2
Gemma3-27B	20	9	8	2
Mistral Small 3.2	10	9	9	3
gpt-oss 20B	15	2	1	0
Qwen3 30B	7	0	0	0
EXAONE 4.0	nach 200 abgebrochen	?	?	0

Immerhin ist es schnell. Hier der durchschnittliche Token/Sekunde-Wert über die 8 Testfragen (auch wieder aus Teil 2):

Modell	Tokens/Sekunde
Qwen3 30B	67
gpt-oss 20B	60
Gemma3 12B	31
Mistral Small 3.2	20
Gemma3 27B	13
EXAONE 4.0	12

Bei den Programmieraufgaben funktionierten Tic-Tac-Toe, Minesweeper und Vier Gewinnt ohne Computergegner ohne Fehler. Vier Gewinnt mit Computergegner funktionierte dem ersten Anschein nach schon, allerdings hatte die Logik, nach der der Computer zieht, einen Fehler. Sofern der menschliche Spieler einzügig gewinnen kann, sollte der Computer das eigentlich blockieren, was das gpt-Programm jedoch nicht tat. Der Versuch, gpt das Problem selbst korrigieren zu lassen, schlug fehl. Nach einer kleinen händischen Debugging-Session bekam ich heraus, dass es sich um einen banalen „off-by-one“-Fehler handelte und der Computer einfach immer eine Spalte zu weit links setzt als die tatsächlich berechnete. Spaßeshalber habe ich mal Qwen3 Coder und Devstral das Programm analysieren lassen um zu sehen, ob die vielleicht den Fehler finden. Qwen3 Coder tappte dabei völlig im Dunkeln. Devstral gab recht allgemeine Antworten und schlug vier Möglichkeiten vor, woran es vielleicht liegen könnte, und eine davon war tatsächlich, dass es sich um einen off-by-one-Fehler handeln könnte. Konkret konnte aber auch Devstral den Fehler nicht finden.

Das große Problem von gpt-oss

Das große Problem von gpt-oss 20B ist aber, dass es stärker als die anderen Modelle (außer dem eh schon disqualifizierten Exaone) halluziniert.

Und das nicht nur im Modellwissen, sondern auch bei Fragen nach Fakten, die im Kontext stehen!

Das betrifft sowohl in den Kontext geladene große Texte als auch per Tool-Nutzung aus Wikipedia geholte Texte. (gpt-oss ist für Tool-Nutzung optimiert und kann aus LM Studio heraus Wikipedia abfragen.)

Damit ist es für Retrieval Augmented Generation und Cache Augmented Generation (kommt im nächsten Teil etwas genauer dran) ungeeignet!

Das passiert zwar bei anderen Modellen einschließlich Mistral auch gelegentlich, aber nicht so deutlich und so falsch wie bei gpt-oss 20B. Noch schlimmer: Wenn man bei Mistral noch mal nachfragt, wo das behauptete denn nun eigentlich im Text steht, bemerkt es meistens den Fehler. gpt-oss dagegen bleibt fest in der Halluzination gefangen und erfindet Textstellen.

Fazit

Diesen Ergebnissen nach fühlt sich gpt-oss in fast allen betrachteten Kriterien wie eine schlechtere Version von Qwen3 an. Es ist ein bisschen langsamer, beim Programmieren ein bisschen schlechter, beide halluzinierten viel und ist beide sind für die Verarbeitung eines größeren Context-Window nicht geeignet; Qwen3 nicht, weil es sich aufhängt (siehe Teil 4) und (siehe Teil 6 für die Korrektur!) gpt-oss 20B nicht, weil es zu stark halluziniert und deswegen den Sinn eines großen Kontexts ad absurdum führt.

Wie immer beziehen sich alle Ergebnisse auf Tests, die ich mit LM Studio auf meinem MacBook Pro mit M2 Max und 32 GB RAM durchgeführt habe und bei gpt-oss kam die 20B-Version zum EInsatz. Bei den Optionen wurde die context-length hoch gedreht und Flash Attention und KV-Quantization (diesmal FP16) aktiviert.

Qwen3 Coder vs. Devstral: Ein Vergleich der Sprachmodelle für die Programmierung

In diesem Teil habe ich mit zwei Sprachmodellen gearbeitet, die sich speziell für Programmieraufgaben eignen: Qwen3 Coder 30B A3B Instruct und Devstral Small 2507 jeweils in der MLX-Version über LM Studio. Beide Modelle sollen Entwicklern bei der Erstellung, Fehlerbehebung und Optimierung von Code helfen. Doch wie schlagen sie sich im direkten Vergleich? Hier sind meine Erfahrungen aus verschiedenen Tests.

Test 1: C++-Programmierung mit Zed und LM Studio

Für den ersten Test habe ich beide Modelle in Zed, einem modernen Code-Editor, getestet. Die Prompts wurden auf Englisch direkt im Editor-Fenster gestellt. Ich ließ mir fünf Programme generieren:

1. Tic Tac Toe (erst normal, dann mit zufällig spielendem Gegner)
2. Vier gewinnt (erst normal, dann mit nicht-zufälligem Gegner)
3. Minesweeper

Ergebnisse:

• Tic Tac Toe:
  • Beide Modelle liefern fehlerfreie C++-Programme.
• Tic-Tac-Toe mit Computer-Gegner:
  • Devstral hatte hier einen Fehler: Es wurden zwei Variablen, innerhalb eines do-Blocks deklariert und dann versucht, in der abschließenden while-Bedingung darauf zuzugreifen, wo sie allerdings nicht mehr sichtbar sind. Devstral konnte den Fehler jedoch selbst korrigieren, indem ich die Compiler-Fehler mitgab und die entsprechende Funktion markierte.
  • Qwen3 Coder hatte keine Fehler.
• Vier gewinnt:
  • Beide Modelle generierten den Code ohne Fehler, sowohl für die Zwei-Spieler-Variante als auch für eine Version mit Computer-Gegner, der diesmal nicht rein zufällig spielen durfte.
• Minesweeper:
  • Qwen3 Coder lieferte einen fehlerfreien Code.
  • Devstral generierte und zeigte zunächst nur ein „board for reference“. Nach der Aufforderung, das Spiel spielbar zu machen, generierte es einen Code, bei dem am Anfang bereits die Zahlen (aber nicht die Bomben) aufgedeckt waren. Zudem gab es gelegentlich einen segmentation fault. Ich habe diese Fehler nicht weiter analysiert.

Fazit des C++-Tests:

Qwen3 Coder hat die Nase vorn. Während beide Modelle bei einfachen Aufgaben gut funktionierten, zeigte Qwen3 Coder eine höhere Zuverlässigkeit, insbesondere bei komplexeren Anforderungen wie Minesweeper. Außerdem ist Qwen3 Coder deutlich schneller.

Test 2: Python-Libraries für XQuery

Im zweiten Test habe ich beide Modelle in Zed, diesmal im Chatfenster des rechten Docks, nach Python-Libraries für XQuery gefragt. Bei diesem Nischen-Thema hatte ich vor etwa anderthalb Jahren noch mit keinem Sprachmodell zielführende Hinweise bekommen, daher hatte ich an sich nicht viel Hoffnung, aber es kam anders…

Ergebnisse:

Qwen3 Coder funktionierte zunächst nicht im Zed Chatfenster. Eine Fehlermeldung wies auf ein Problem mit dem Prompt-Template hin. Der Fix bestand darin, in LM Studio das Prompt-Template des normalen Qwen3 zu verwenden.

Qwen3 Coder suchte dann mit pip nach möglicherweise passenden Paketen und hätte mir fast auf Verdacht lxml installiert (nein, das kann kein XQuery, nur XPath!).

Aus einem leeren Projekt heraus gestartet zeigte Devstral aus Modellwissen im Chat teils nützliche, aber auch inzwischen eingestellte Projekte.

Aus LM Studio heraus (ohne Systemprompts und Toolzugriff über Zed) lieferten beide Modelle teils eingestellte Projekte als Vorschläge oder Hinweise auf Packages, die nur so heißen, als könnten sie XQuery und in Wahrheit etwas ganz anderes sind, aber auch teils nützliche Hinweise!

Bis zu diesem Punkt lief das schon mal bedeutend besser als vor anderthalb Jahren. Das ist noch nicht super, aber der eine Hinweis auf ein existierendes Package das tatsächlich XQuery kann und auch noch maintained wird, war auf jeden Fall hilfreich.

Als ich später den Test aus einem in Zed geöffneten Python-Projekt heraus wiederholte, schauten übrigens erst mal beide Modelle meinen Code durch, ob ich nicht schon etwas hatte, und fanden das dann auch.

Aber erst mal musste das Programm ja geschrieben werden, deswegen ließ ich nach der Auswahl eines Python-Packages für XQuey beide Modelle Code generieren, der aber zunächst nicht funktionierte.

Beim Versuch, das Programm unter Angabe der Fehlermeldung sowie mit der in den Chat hineinkopierten Dokumentation von der Webseite zu korrigieren, trat dann ein unerwartetes Problem auf:

Qwen3 Coder zeigte bei größerem Kontext (wie eben hier dem Auszug aus der Dokumentation) seltsames Verhalten: Es wiederholte Teile des Kontextes endlos. Dies könnte mit dem Context-Window zusammenhängen, das in Wahrheit nur 32K zu sein scheint (obwohl eigentlich 256K einstellbar ist). Auf der Model Card bei Huggingface gibt es einen Hinweis: „If you encounter out-of-memory (OOM) issues, consider reducing the context length to a shorter value, such as 32,768.“ Dies deckt sich mit meiner Beobachtung. Auch wenn es bei mir zu keinem Abbruch mit Fehlermeldung kam, war eine Arbeit mit mehr als ca. 32K Tokens nicht möglich. (Korrektur: Dies scheint die MLX-Version zu betreffen, die „unsloth“-Version, die GGUF verwendet, scheint zu funktionieren, siehe Teil 6.)

Devstral lieferte dagegen auf die gleiche Anfrage hin ein korrigiertes Programm, sowohl aus LM Studio als auch aus Zed. (Dort allerdings erst im zweiten Anlauf nach einer Korrekturrunde.)

Generell ist beim Arbeiten mit großem Context-Window zu beachten, dass die Verarbeitung des Prompts dann lange dauert und bis zur ersten Antwort mehrere Minuten vergehen können. Weitere Anfragen werden dann aber normalerweise wieder schneller beantwortet.

Fazit des XQuery-Tests:

Qwen3 Coder war schon irgendwie hilfreich, aber auch sehr holprig. Das Context-Window ist in Wahrheit nur 32K groß, und für die Nutzung aus dem Zed-Chatfenster war eine manuelle Anpassung des Prompt-Templates in LM Studio nötig. Nur Devstral war in der Lage, mit großem Kontext zu arbeiten.

Gesamtfazit

Insgesamt ist das Ergebnis also nicht eindeutig:

• Qwen3 Coder ist deutlich schneller als Devstral (das Verhältnis ähnelt dem zwischen Qwen3 und Mistral) und bei C++-Aufgaben besser.
• Allerdings kann das zu kleine Context-Window problematisch werden, (Korrektur: siehe Teil 6, das für Qwen3 gesagte gilt sinngemäß auch für Qwen3 Coder) und für die Nutzung aus dem Zed-Chatfenster war eine manuelle Anpassung erforderlich.
• Beide Modelle können Projekte durchsuchen und Tools nutzen, z. B. kann Qwen3 Coder auch pip verwenden, um zu sehen, welche Packages in Python installiert sind.

Fazit: Beide Modelle haben ihre Stärken und Schwächen. Qwen3 Coder ist schneller und zuverlässiger bei C++-Aufgaben, während Devstral bei Python-Fragen manchmal die bessere Lösung bietet und mit einem größeren Kontext arbeiten kann. Die Wahl des Modells hängt also vom konkreten Anwendungsfall ab.

Im übrigen habe ich mir auch für diesen Beitrag wieder von Mistral 3.2 helfen lassen, aus Stichpunkten Fließtext zu generieren. Ich würde sagen, das kann man schon sehr gut produktiv einsetzen.

Nachtrag: Vergleich mit nicht-coding-optimierten Modellen

Um zu untersuchen, ob die nicht auf Programmieren optimierten Modelle prinzipiell auch für Coding-Aufgaben geeignet wären, habe ich zusätzlich Qwen3 (nicht Coder), Mistral Small und Gemma3 mit der Minesweeper-Aufgabe getestet, um einen umfassenderen Eindruck zu gewinnen.

Qwen3 lieferte wie Qwen3 Coder einen fehlerfreien Code. Dies ist zunächst keine große Überraschung, da Qwen3 Coder auf dem gleichen Modell basiert.

Bei Mistral gab es ähnliche Probleme wie bei Devstral, auch das ist nicht überraschend, da auch diese beiden Modelle eine ähnliche Architektur haben.

Auch bei Gemma3 gab es Fehler. Die 27B-Version war besser als die 12B-Variante.

Die nicht für Coding optimierten Modelle sind also prinzipiell ebenfalls benutzbar, haben allerdings den Nachteil, dass sie nicht auf Tool-Unterstützung trainiert sind. Dass sie stattdessen Bildverarbeitung unterstützen bringt, für die Programmierung nichts.

Meine Empfehlung für Anwendungen in der Programmierung bleibt daher weiterhin Qwen3 Coder oder Devstral, letzteres insbesondere wenn das zu kleine Context-Window von Qwen3 Coder zum Problem wird.

Nach der Absteckung des Untersuchungsrahmens in Teil 1 werden nun die ersten Testergebnisse vorgestellt. Dazu gehören jeweils vier Testfragen in englischer und deutscher Sprache, wie sie bereits im ersten Teil beschrieben wurden:

1. Who is the current president of the United States?
2. What does ideation mean?
3. Please explain how the German parliament makes laws.
4. What is „closed book-case information retrieval“? Please cite scientific sources!
5. Was versteht man unter dem „Fishbowl“-Format?
6. In einem Raum sind drei Menschen. Linda liest ein Buch. Paul spielt Schach. Was macht Anna?
7. Es wurde gesagt, dass eines Abends Guido van Rossum vor der Wahl stand, entweder Objektorientierung in Python zu machen oder Bier trinken zu gehen. Man sagt weiter, er habe dann einfach beides gemacht. Wie ist das zu verstehen?
8. Erzähle eine Geschichte ‚Inge Wenzel auf dem Weg nach Rimini‘. Inge Wenzel ist eine junge Frau und fährt mit dem Schlafwagen nach Rimini. Sie hat im Zug eine interessante Begegnung.

Dabei wurden die vier englischsprachigen Anfragen in dieser Reihenfolge nacheinander in einer Session gestellt. Somit waren die jeweils vorangegangenen Anfragen und Antworten jeweils noch im Kontext. In den meisten Fällen hatte das anscheinend keinen Einfluss, allerdings gab es eine Ausnahme, die gleich noch diskutiert wird.

Die ersten drei deutschsprachigen Anfragen wurden ebenfalls in einer Session gestellt, die Anfrage nach der Geschichte über Inge Wenzel in einer eigenen Session. Über Inge Wenzel soll es erst im dritten Teil gehen, die Kluft zwischen Absurdität und schöner Erzählung verdient einen eigenen Teil.

Da sich aus den Antworten der 3. (englischen) Testfrage noch etwas Nachforschungsbedarf, speziell was Halluzinationen bei Fragestellungen mit Bezug zu lokalen Themen angeht,ergeben hatte, wurden noch folgende zwei vorher nicht geplante Zusatzfragen aufgenommen:

1. In welchen deutschen Bundesländern ist der 1. November ein Feiertag?
2. Welche Sehenswürdigkeiten gibt es im Frankfurter Nordend?

Getestet wurden:

• Gemma3 12B und 27B
• Mistral Small 3.2
• EXAONE 4.0 32B
• Qwen3 20B 2507

Die auf Coding und Entwicklung spezialisierten Modelle Qwen3 Coder und Devstral wurden für diese allgemeinen Fragen nicht untersucht.

Bei der qualitativen Bewertung wurde hauptsächlich auf folgende Fragen geachtet:

• Halluziniert das Modell? Unter welchen Umständen?
• Ist die Antwort in sich logisch?
• Wie gut geht das Modell mit Deutsch um?

Dabei sollen gezielt Besonderheiten (und teils auch Absurditäten) der verschiedenen Modelle beleuchtet werden.

Qualitative Betrachtung

Who is the current president of the United States?

Alle untersuchten Modelle nennen erwartungsgemäß noch Joe Biden als Präsidenten. Mistral, Exaone und Qwen schreiben direkt dazu, an welchem Datum ihr Training abgeschlossen war und weisen darauf hin, dass die Information möglicherweise nicht mehr aktuell ist. Dabei fiel auf, dass als einziges Modell Mistral in der Lage ist, das aktuelle Datum korrekt auszuwerten und in die Antwort einzubeziehen. Auf die Frage „Welcher Tag ist heute?“ antworten die beiden Gemmas und Exaone mit konkreten Daten aus 2024, wo immerhin noch Wochentag und Datum zusammenpassen, mehr aber auch nicht. Qwen gibt zu, keine Echtzeit-Daten zu haben. Nur Mistral wertet offenbar tatsächlich die offenabr irgendwo in der Schnittstelle versteckt übergebene Systemzeit aus und antwortet korrekt!

What does ideation mean?

Hier gab es keine Auffälligkeiten. Qwen und Mistral sind etwas weniger geschwätzig als die anderen und die Antworten fallen kürzer aus.

Please explain how the German parliament makes laws.

Die Modelle kennen die wichtigen Verfassungsorgane Bundestag, Bundesrat und den Bundespräsidenten und erklären den grundlegenden Ablauf mit drei Lesungen im Bundestag, der Rolle der Ausschüsse und des Bundesrats.

Bei dieser Frage gibt es aber tatsächlich deutliche Unterschiede in der Qualität der Antworten.

Die Antwort von Mistral gefällt mir subjektiv etwas besser als die der beiden Gemmas, aber alle sind so weit korrekt. Bei Mistral gefällt mir nur das Detail nicht so gut, dass es heißt, der Bundesrat könne einen Gesetzentwurf ablehnen, aber dies sei „rare due to constitutional constraints“. Man könnte wohl argumentieren, dass hier vielleicht die Rolle des Vermittlungsausschusses gemeint ist, dies wird allerdings in der knappen Antwort von Mistral nicht näher ausgeführt.

Die Antwort von Qwen enthält kleinere sachliche Fehler.

Mit deutlichem Abstand am schlechtesten ist die Antwort von Exaone. Nicht nur sind grobe sachliche Fehler darin, sie ist auch nicht immer in sich logisch. Da wird mal behauptet, dass, falls keine Einigung zwischen Bundesrat und Bundestag erzielt wird, das überstimmt werden kann mit einer „absolute majority in both houses and ¾ of state votes“, aber dann wäre ja wieder Einigkeit… Manchmal sind dann auch zwei Drittel das selbe wie drei Viertel. Überhaupt sind die Antworten auch nicht besonders „stabil“ in dem Sinne, dass sie sich teilweise deutlich unterscheiden, je nachdem ob vorher Kontext da war oder nicht oder auch wenn die Frage nur ganz leicht umformuliert wird.

Tatsächlich ist die Antwort, wenn die Frage in einer eigenen Session als erstes gestellt wird, sogar noch schlechter! Ganz gruselig sind dann noch die in der englischsprachigen Antwort in Klammern genannten deutschen Begriffe. Da wird dann aus dem Vermittlungsausschuss die „Mittelungskommission“, es ist von einem „Körperschiftengesetz“ die Rede (was auch immer das sein soll) und die „Federal Law Gazette“, was die korrekte englische Übersetzung für das Bundesgesetzblatt ist, wird dann zum „GemeindeBlatt der Bundesrepublik Deutschland“.

Es drängt sich der Verdacht auf, dass Mistral hier als französisches Produkt wahrscheinlich auf einem eher euro-zentrischen Datensatz trainiert wurde und deswegen Fragen mit Bezug zu Europa und Deutschland besser beantworten kann. Ein kleiner Zusatztest scheint das zu bestätigen:

Zusatzfrage: In welchen deutschen Bundesländern ist der 1. November ein Feiertag?

Als erste Frage in der Session ohne vorherigen Kontext antworten Mistral 3.2 und Gemma3 27B korrekt (Baden-Württemberg, Bayern, Nordrhein-Westfalen, Rheinland-Pfalz und Saarland). Gemma3 12B nennt statt dem Saarland falsch Sachsen. Qwen3 erfindet für einige Bundesländer lokale Regelungen, die nicht existieren, so sei angeblich in Hessen der 1.11. nur im Odenwald ein Feiertag. Exaone ist noch mal deutlich schlechter und schreibt nur Unsinn, z.B. dass der 1. November im Bundesland Braunschweig als der „Tag der Wiedererlangung des Stadtstreichs“ (sic!) gefeiert wird.

Bei der Auswertung der Antworten auf konkrete Fragen muss man beachten, dass nicht alle Modelle immer gleich antworten und je nach Kontext die Antwort mal Fehler enthalten kann und mal nicht. Mistral 3.2 fügte in weiteren Tests auch manchmal noch Sachsen hinzu, lag also nicht immer richtig.

Wird die Anfrage nach dem Feiertag nicht als erstes in der Session, sondern mit anderem Kontext gestellt, fängt Qwen recht früh, zu halluzinieren und steigert sich dann immer weiter rein, wenn der Chat fortgesetzt wird. Exaone schreibt sogar noch größeren Blödsinn.

Die Halluzinationen lassen sich deutlich reduzieren, wenn den Modellen mittels Tools Zugriff auf Wikipedia oder das ganze Web gewährt wird. Das klappt in LM Studio allerdings nicht immer mit allen Modellen und Tools zuverlässig.

Zusatzfrage: Welche Sehenswürdigkeiten gibt es im Frankfurter Nordend?

An dieser Stelle bot sich ein weiterer Zusatztest an, um zu prüfen, ob die Modelle stärker halluzinieren, wenn nach sehr spezifischen Informationen gefragt wird, die dennoch aus dem Modellwissen beantwortet werden sollen. Bei der konkreten Frage nach Sehenswürdigkeiten im Frankfurter Nordend lässt sich die Güte der Antworten sogar ein Stück weit quantifizieren, als der Anteil der von den Modellen in der Antwort genannten Sehenswürdigkeiten, die tatsächlich auch existieren.

Viele Sehenswürdigkeiten, die von den Modellen genannt werden, existieren tatsächlich, liegen aber nicht im Nordend, worauf auch manchmal hingewiesen wird. Folgende Tabelle fasst das Ergebnis kurz in Zahlen zusammen:

	genannte Orte	davon tatsächlich existent	weitgehend korrekt beschrieben	davon tatsächlich im Nordend
Gemma3-12B	17	10	9	2
Gemma3-27B	20	9	8	2
Mistral Small 3.2	10	9	9	3
Qwen3 30B	7	0	0	0
EXAONE 4.0	nach 200 abgebrochen	?	?	0

Die einzige von Mistral genannte Sehenswürdigkeit, die nicht wirklich existiert, war die „Stadtteilbibliothek Nordend“. Das Nordend ist tatsächlich einer der Stadtteile, der keine eigene Stadtteilbibliothek hat, da die Stadtbibliothek in der Innenstadt nicht weit ist. Allerdings ist im Frankfurter Nordend einer der beiden Standorte der Deutschen Nationalbibliothek. Bei den Sehenswürdigkeiten, die nicht im Nordend liegen, wurde aus dem „Kunstverein Familie Montez“ bei Mistral der „Kunstverein Familie Montezza„. Zwei Punkte auf der Liste waren allerdings recht vage, so wird z.B. allgemein auf Cafés und Restaurants sowie kleine Kirchen und historische Gebäude verwiesen.

Bei Exaone wurde darauf verzichtet, alle >200 Ergebnisse zu prüfen, zumal sich viele Einträge gleich mehrmals wiederholten. Auf den ersten Blick waren ein paar wenige tatsächlich in Frankfurt existierende Sehenswürdigkeiten dabei, aber tatsächlich keine davon aus dem Nordend.

Bei den beiden Zusatzfragen zeigt sich, dass Mistral noch am wenigsten halluziniert, in diesem Test dicht gefolgt von Gemma. Qwen3 erfindet viel dazu und Exaone liefert völligen Unsinn.

What is „closed book-case information retrieval“? Please cite scientific sources!

Alle Modelle halluzinieren, liefern aber immerhin eine in sich konsistente Definition. Gemma3 lässt in der 12B-Version stillschweigend das Wort „case“ fallen. Mistral halluziniert, weist aber wenigstens darauf hin, keinen Zugriff auf wissenschaftliche Quellen zu haben. Qwen lässt ebenfalls das Wort „case“ fallen, weist aber darauf hin.

Also so ungefähr auf dem Niveau wie ChatGPT im Dezember 2022.

Was versteht man unter dem „Fishbowl“-Format?

Die Antworten sind zumeist ganz gut. Die Antwort von Gemma3-27B fällt etwas länger aus. Exaone macht viele sprachliche Fehler.

In einem Raum sind drei Menschen. Linda liest ein Buch. Paul spielt Schach. Was macht Anna?

Bei diesem Logikrätsel gilt als die richtige Antwort, dass Anna mit Paul Schach spielt, da Schach ein Zwei-Personen-Spiel ist und Linda ein Buch liest und somit nicht mit Paul Schach spielt.

Gemma3-12B, Mistral und Qwen beantworten die Frage auch in diesem Sinn. Gemma3-27B behauptet dagegen, dass Anna Linda und Paul beobachtet. So ähnlich sieht das Exaone, geht dabei aber noch einen Schritt weiter: Da diese Frage im selben Kontext wie die Fishbowl-Frage gestellt wurde, behauptet Exaone, dass Anna den Personen im Fishbowl zusieht…

Stellt man Exaone die Frage in einer neuen Session ohne Kontext, stellt es sehr lange krude Spekulationen auf, ob das Rätsel wohl was mit den Anfangsbuchstaben oder so zu tun hat und bricht dann nach einem sehr langen Gefasel ab.

Es wurde gesagt, dass eines Abends Guido van Rossum vor der Wahl stand, entweder Objektorientierung in Python zu machen oder Bier trinken zu gehen. Man sagt weiter, er habe dann einfach beides gemacht. Wie ist das zu verstehen?

Alle Modelle interpretieren diese Aussage ähnlich. Es sei hier einfach mal Mistral zitiert:

Der Witz spielt darauf an, dass van Rossum die objektorientierten Konzepte so elegant in Python eingebaut hat, als wäre es eine einfache Entscheidung gewesen – fast so, als hätte er gleichzeitig „beides“ gemacht: objektorientierte Programmierung implementieren und entspannt ein Bier trinken gehen.

An dieser Stellen vielen Dank an F.C. für die Inspiration zu diesem Test. 😁

Gemma3-27B meint übrigens, das sei „eine beliebte Geschichte in der Python-Community, die oft erzählt wird“ und Qwen3 findet, das sei ein „berühmtes technisches Insider-Joke“ und legt van Rossum das vermutlich erfundene Zitat in den Mund: „Ich habe Python gemacht, während ich Bier trank.“.

Nachwort zu EXAONE

Die Antworten waren zwischenzeitlich so absurd, dass ich schon der Meinung war, ein falsches Modell heruntergeladen zu haben. Also habe ich mir nach der MLX-Version von der lmstudio-community noch dne GGUF-Version von LGAI besorgt. Alllerdings ist die auch nicht wirklich besser, nur langsamer, weil sie auf meinem Rechner nicht mehr komplett auf der GPU läuft.

Damit ist Exaone nun wegen nahezu völliger Unbrauchbarkeit erst mal raus. Möglicherweise leidet das Modell unter der 4-Bit-Quantisierung, aber da es in diesem Test ja ausdrücklich um Modelle gehen soll, die mit maximal 20 GB auskommen, sind größere Versionen außen vor und wären dann ja auch nicht mehr wirklich vergleichbar mit den anderen. Trotzdem reiche ich in Teil 3 noch eine Exaone-Version der Inge-Wenzel-Geschichte nach, die ist einfach zu lustig…

Geschwindigkeit

Die Antwortgeschwindigkeit der Modelle in Tokens/Sekunde hängt naturgemäß von der Rechenleistung der verwendeten GPU ab. Außerdem spielt die Größe des im Speicher befindlichen Kontexts eine Rolle. Auf einem MacBook Pro mit M2Max gemessen ergaben sich bei den 8 eingangs genannten Testfragen folgende Durchschnittswerte, von schnell nach langsam:

Modell	Tokens/Sekunde
Qwen3 30B	67
Gemma3 12B	31
Mistral Small 3.2	20
Gemma3 27B	13
EXAONE 4.0	12

Die Geschwindigkeit von Qwen3 überrascht im Verhältnis zur Parameter-Zahl. Wahrscheinlich ist es der Mixture-of-Experts-Ansatz von Qwen3, der dafür verantwortlich ist. Dass Gemma3 mit 12 Mrd. Parametern schneller ist als die größeren Modelle (außer Qwen3) war dagegen zu erwarten. Exaone enttäuscht leider sehr.

Subjektive Zusammenfassung

Nach den dokumentierten Ergebnissen stellt sich für meine Anwendungsfälle die Situation wie folgt dar:

Die schon etwas älteren Gemma3-Modelle sind ganz solide, wobei sich für meinen Geschmack die größere 27B-Version gegenüber der 12B-Version kaum lohnt und gelegentlich sogar schlechtere Ergebnisse liefert.

Qwen3 besticht durch die im Verhältnis zur Größe des Modells hohe Geschwindigkeit.

Was die Qualität der Ergebnisse angeht hat Mistral Small für mich aber die Nase vorn, insbesondere in deutscher Sprache.

Gemma3 funktioniert auch ganz gut auf Deutsch, aber Qwen3 macht hier zu viele Fehler.

Bei Exaone weiß ich nicht, ob ich nicht doch irgendwas falsch mache. Aber in den Konfigurationen, wie ich sie hier getestet habe, ist es völlig unbrauchbar.

Nachtrag: Intelligence Index und Peformance

Im Nachgang zu dieses Tests fand ich dann doch sehr auffällig, dass sich meine Beobachtungen doch sehr deutlich von dem Unterscheiden, was in der im ersten Teil erwähnten Rangliste „LLM Leaderboard“ steht und zwar sowohl in Bezug auf die Qualität der Antworten als auch bei der Geschwindigkeit! In absoluten Zahlen wäre die Tokens/Sekunde-Angabe natürlich sowieso nicht zu vergleichen, aber ich hätte schon erwartet, dass die Abstände in etwa gleich bleiben. Nach den Angaben aus dem Leaderboard hätte aber Mistral Small das mit deutlichem Vorsprung schnellste Modell sein sollen, mit einem Vorsprung auf Qwen von fast 75%, gefolgt von Exaone. Gemma 27B sollte laut Leaderboard angeblich weniger als ein Drittel der Geschwindigkeit von Mistral erreichen. Woher diese Abweichung kommt, ist ohne tiefere Nachforschung schwer nachzuvollziehen. Sofern die Unterschiede – selbst in der relativen Rangfolge – nur wegen unterschiedlicher Konfigurationen zustande kommen, verlieren allgemeine Angaben doch sehr an Aussagekraft und man kommt nicht mehr um eigene Tests für den eigenen Anwendungsfall herum.

Ähnliches gilt sinngemäß für die inhaltliche Qualität der Antworten. In Anbetracht der Ergebnisse meiner eigenen Tests erscheint es unverständlich, dass laut des „Intelligence Index“, der eine Zusammensetzung mehrerer anderer Benchmarks ist, Exaone einen deutlichen Vorsprung auf Mistral haben soll, während es sich in meinen Tests als komplett unbrauchbar erwiesen hat. Hier könnte man möglicherweise noch argumentieren, dass die deutschsprachigen Tests Exaone benachteiligen, aber die englischsprachigen Antworten sind ebenfalls schlecht und wenn Modellwissen gefragt ist voller faktischer Fehler. Als einen weiteren kleinen Test habe ich Exaone und zum Vergleich Qwen (was ja bei deutschen Anfragen auch nicht ganz so gut war) nach dem politischen System in Irland gefragt („Tell me about the political system in Ireland and the election process.„) und wieder kam von Exaone viel Stuss, von Qwen dagegen ordentliche Antworten.

Fortsetzung folgt…

Im nächsten Teil begleiten wir Inge Wenzel auf ihrem Weg nach Rimini.

Leistung und Grenzen unter 20 GB

Einleitung

In diesem Artikel werfen wir einen Blick auf Sprachmodelle, die bis zum 1. August 2025 erschienen sind und sich durch ihre kompakte Größe auszeichnen. Konkret betrachten wir Modelle, die unter 20 Gigabyte groß sind – oder bei einer Quantisierung auf 4 Bit etwa 30 Milliarden Parameter umfassen. Diese Größenbeschränkung ist kein Zufall: Sie ermöglicht es, die Modelle auf Rechnern in der Größenordnung eines Apple M2 Max oder vergleichbarer Hardware effizient zu nutzen.

Es handelt sich hier um eine subjektive Einschätzung, die auf praktischen Erfahrungen und Tests basiert. Wir möchten herausfinden, wie sich diese „kleinen“ Sprachmodelle in verschiedenen Anwendungsgebieten schlagen. Dazu gehören:

• Allgemeine Texterstellung: Wie gut eignen sie sich für kreative oder informative Texte?
• Dokumentenanalyse: Wir testen ihre Fähigkeiten bei der Verarbeitung von Dokumenten mit einem Umfang von etwa 80 A4-Seiten. Dabei beobachten wir besonders, wie sie mit größerer Context-Length umgehen – also ob es zu Geschwindigkeitsverlusten oder Abbrüchen kommt.
• Deutsche Sprache: Ein besonderer Fokus liegt auf der Leistung in Bezug auf die deutsche Sprache, da viele Modelle primär auf Englisch trainiert werden.
• Programmieren in C++: Wie nützlich sind diese Modelle für Entwickler, die Code in C++ schreiben oder optimieren möchten?
• Weltwissen: Sind bestimmte Fakten bekannt? Bis zu welchem Stand wurde trainiert?
• Halluzinationen: Wie äußern sie sich? Wie oft kommen sie vor?

Diese Punkte helfen uns, ein umfassenderes Bild davon zu bekommen, wie zuverlässig und nützlich kleine Sprachmodelle im Alltag sein können.

Grundlage für die Auswahl der Modelle

Für diese Analyse haben wir uns auf das LLM Leaderboard von Artificial Analysis gestützt, um die relevanten Sprachmodelle zu identifizieren. Konkret haben wir uns auf Modelle konzentriert, die in der Kategorie „Small“ (unter 20 GB bzw. ca. 30 Mrd. Parameter bei 4 Bit) gelistet sind und Open Weights besitzen – also frei verfügbare Modelle, die ohne Einschränkungen genutzt werden können.

Ein weiterer wichtiger Filter war die Nicht-Einbeziehung von Reasoning-Modellen. Diese spezialisierten Modelle sind oft auf logisches Schlussfolgern optimiert und unterscheiden sich in ihrer Architektur von allgemeinen Sprachmodellen. Da wir uns auf die breite Anwendbarkeit konzentrieren, haben wir sie bewusst ausgeschlossen. Zudem weisen Reasoning-Modelle in der Regel deutlich längere Antwortzeiten auf, was sie für viele praktische Anwendungen weniger geeignet macht.

Die Top-Platzierungen in dieser Kategorie geben uns eine gute Orientierung, welche Modelle aktuell als führend gelten und sich für unsere Tests eignen. Die Auswahl umfasst sowohl etablierte Modelle als auch neuere Entwicklungen, die bis zum 1. August 2025 veröffentlicht wurden.

Ausgewählte Modelle für den Vergleich

Basierend auf den genannten Kriterien haben wir fünf besonders vielversprechende Modelle für unseren Vergleich ausgewählt:

Qwen3 30B A3B (2507)

• Eine überarbeitete Version des Qwen-Modells, das im April 2025 veröffentlicht wurde. Diese spezielle Variante (A3B) ist besonders für ihre Effizienz und Leistung bekannt.
• Der „Artificial Analysis Intelligence Index“ liegt bei über 50, was auf eine hohe allgemeine Leistungsfähigkeit hinweist. (Stand 1.8.25, die Angaben ändern sich ständig…)

EXAONE 4.0 32B

• Ein weiteres Top-Modell, das im Juli 2025 erschienen ist und ebenfalls einen Intelligence Index über 50 erreicht.
• EXAONE hat sich in verschiedenen Benchmarks als besonders stark in der Verarbeitung von natürlicher Sprache erwiesen.

Mistral-Small-3.2-24B-Instruct-2506

• Eine spezielle Version des Mistral-Modells, das im Juni 2025 veröffentlicht wurde. Diese Variante ist für ihre Effizienz und Anpassungsfähigkeit bekannt.

Gemma 3 27B & Gemma 3 12B

• Die 27B-Version des Gemma-Modells ist eine der aktuellsten Varianten von 2025 und erreicht einen Intelligence Index von 38.
• Die 12B-Version dient als Vergleich, um zu sehen, wie sich eine kleinere Variante schlägt. Mit einem Index von 34 liegt sie nur knapp darunter, was interessante Einblicke in die Skalierungseffekte kleinerer Modelle verspricht.

Qwen3 Coder 30B A3B Instruct

• Diese Version des Qwen3-Modells wurde am 31. Juli 2025 bei LM Studio veröffentlicht und ist eine non-reasoning Variante, die sich besonders für Codegenerierung eignet.
• Als Instruct-Version ist sie darauf ausgelegt, präzise Anweisungen zu verstehen und umzusetzen – ideal für Aufgaben in der Softwareentwicklung.

Devstral Small 2507

• Ein weiteres Modell, das im Juli 2025 erschienen ist und auf der Mistral-Architektur basiert.
• Devstral Small wurde speziell für Programmieraufgaben entwickelt und bietet eine gute Balance zwischen Größe und Leistung.

Diese Auswahl bietet uns eine breite Palette an Modellen, um ihre Stärken und Schwächen in den verschiedenen Anwendungsgebieten zu evaluieren.

Getestete Anfragen: Allgemeine Wissensabfrage (Englisch & Deutsch)

Um die Leistungsfähigkeit der ausgewählten Sprachmodelle zu bewerten, haben wir eine Reihe von Testanfragen in Englisch und Deutsch durchgeführt. Diese umfassen sowohl Faktenwissen als auch komplexere Erklärungen und kreative Aufgaben.

Englische Testanfragen:

„Who is the current president of the United States?“

• Diese Frage prüft, ob das Modell aktuelles Weltwissen besitzt und korrekte Fakten liefern kann.

„What does ideation mean?“

• Hier geht es darum, ob das Modell Begriffe präzise erklären kann und dabei auch Nuancen berücksichtigt.

„Please explain how the German parliament makes laws.“

• Eine komplexere Anfrage, die Zusammenhänge und Prozesse verständlich darstellen soll.

„What is ‚closed book-case information retrieval‘? Please cite scientific sources!“

• Diese Frage testet, ob das Modell Fachbegriffe erklärt und dabei auch wissenschaftliche Quellen einbezieht.

Hintergrund der englischen Testfragen

Die ersten drei englischen Fragen stammen aus einem Performance-Test, der von Midhad Blazevic entwickelt wurde. Blazevic ist wissenschaftlicher Mitarbeiter an der Hochschule Darmstadt und hat die Fragen im Rahmen des Programms „Volontariat zum/zur wissenschaftlichen Dokumentar/in und Information Specialist“ erstellt.

Der Ursprung dieser Fragen liegt in einem Hackathon, bei dem mit Sprachmodellen gearbeitet wurde. Blazevic nutzte sie jedoch ausschließlich für einen Geschwindigkeitstest (tokens/sec) auf verschiedenen Rechnern. Es gab keine Auswertung von Faktenwissen, Textqualität oder anderen Kriterien – der Fokus lag rein auf der reinen Generierungsgeschwindigkeit.

Wir haben diese Fragen übernommen, um einen objektiven Vergleich der Tokens-per-Sekunde-Leistung zwischen verschiedenen Modellen und Hardware-Konfigurationen zu ermöglichen. Dieser Ansatz zeigt, wie schnell die Modelle in der Praxis arbeiten können – ein wichtiger Faktor für Anwendungen, bei denen Echtzeit-Antworten entscheidend sind.

Die Auswahl der Testfragen ist bewusst subjektiv und anekdotisch gewählt, um praktische Erfahrungen mit den Sprachmodellen zu simulieren. Sie erhebt keinen Anspruch auf Vollständigkeit oder wissenschaftliche Objektivität, sondern dient vielmehr dazu, typische Anwendungsfälle zu testen und mögliche Stärken oder Schwächen der Modelle aufzudecken.

Ein besonderes Beispiel dafür ist die englische Frage: „What is ‚closed book-case information retrieval‘? Please cite scientific sources!“

Diese Frage wurde absichtlich so formuliert, weil sie einen bekannten Fall von Halluzinationen bei älteren Sprachmodellen (wie dem großen ChatGPT im Dezember 2022) aufdeckte. Damals wurde der Begriff „closed-book IR“ fälschlicherweise als etablierter Fachbegriff behandelt, obwohl es sich in Wirklichkeit um „closed-book question answering“ handelt – ein Konzept aus dem Bereich der NLP-Forschung.

Durch diese Frage testen wir, ob die Modelle:

• Fachbegriffe korrekt erkennen (oder ob sie Halluzinationen erzeugen),
• wissenschaftliche Quellen richtig einordnen können,
• und ob sie zwischen etablierten Begriffen und fiktiven Konzepten unterscheiden.

Diese Art von Test zeigt, wie zuverlässig die Modelle mit unklaren oder absichtlich falsch formulierten Anfragen umgehen – ein wichtiger Aspekt für die Praxis.

Deutsche Testanfragen:

„Erzähle eine Geschichte ‚Inge Wenzel auf dem Weg nach Rimini‘. Inge Wenzel ist eine junge Frau und fährt mit dem Schlafwagen nach Rimini. Sie hat im Zug eine interessante Begegnung.“

• Eine kreative Aufgabe, die Textgenerierung und Erzählfähigkeit prüft.

„Was versteht man unter dem ‚Fishbowl‘-Format?“

• Eine spezifische Frage zu einem Bildungskonzept, die Fachwissen erfordert.

„Es wurde gesagt, dass eines Abends Guido van Rossum vor der Wahl stand, entweder Objektorientierung in Python zu machen oder Bier trinken zu gehen. Man sagt weiter, er habe dann einfach beides gemacht. Wie ist das zu verstehen?“

• Eine humorvolle, aber technisch anspruchsvolle Frage, die Programmierwissen und kulturelle Referenzen abfragt.

„In einem Raum sind drei Menschen. Linda liest ein Buch. Paul spielt Schach. Was macht Anna?“

• Diese Frage ist eine klassische Logikaufgabe, die darauf abzielt, ob das Modell implizite Informationen erkennt und logische Schlussfolgerungen ziehen kann.

Getestete Programmierungsaufgaben

Um die Fähigkeiten der Modelle im Bereich Codegenerierung und -anpassung zu bewerten, haben wir zwei spezifische Aufgaben in C++ gestellt:

Tic-Tac-Toe (textbasiert, Konsole)

• Die Aufgabe bestand darin, ein einfaches Tic-Tac-Toe-Spiel zu implementieren, das vollständig in der Konsole läuft.
• Getestet wurde, ob das Modell:
  • Korrekte Syntax und Logik für das Spiel generiert.
  • Benutzerinteraktionen (z. B. Eingabe von Spielzügen) korrekt abbildet.
  • Spielregeln (Gewinnbedingungen, Unentschieden) korrekt umsetzt.

Erweiterung: Zufälliger Computergegner

• Als zweite Aufgabe sollten die Modelle den Code erweitern, sodass ein zufälliger Computergegner hinzugefügt wird.
• Getestet wurde hier:
  • Ob das Modell existierenden Code verstehen und erweitern kann.
  • Ob es Pseudozufallsgenerierung (z. B. für den Computerspieler) korrekt implementiert.
  • Ob die Logik des Spiels nach der Erweiterung weiterhin funktioniert.

Hintergrund der Programmieraufgaben: Vergleich mit Anfängerwissen

Ein weiterer Grund für die Auswahl dieser C++-Programmieraufgaben ist, dass sie sich besonders gut mit dem Wissensstand von Studierenden im ersten Semester vergleichen lassen – eine Zielgruppe, die ich selbst unterrichte.

• Tic-Tac-Toe ist eine klassische Übung in der Einführung in die Programmierung, da es grundlegende Konzepte wie:
• Variablen und Schleifen,
• Bedingungslogik (z. B. Gewinnbedingungen),
• und Benutzerinteraktion (Eingabe/Ausgabe) abdeckt.
• Die Erweiterung um einen Computergegner erfordert zusätzliches Wissen über:
• Zufallsgenerierung,
• und die Anpassung bestehender Code-Strukturen.

Durch diesen Vergleich können wir:

• Ermitteln, ob die Modelle Code generieren, der für Anfänger verständlich und nachvollziehbar ist.
• Abschätzen, ob sie als Lernhilfe für Studierende sinnvoll eingesetzt werden könnten.
• Verstehen, wo die Grenzen der Modelle liegen, z. B. bei komplexeren Logikänderungen.

Praktische Implikationen für die Lehre: Code-Generierung und Plagiatsprävention

Ein weiterer wichtiger Aspekt dieser Tests ist die Bewertung, ob Sprachmodelle in der Lage sind, vollständige Programmieraufgaben zu lösen – und was das für die Lehre bedeutet.

• Code-Generierung vs. Lernen:
  Wenn Studierende einfach vollständige Lösungen von Sprachmodellen übernehmen, verlernen sie möglicherweise grundlegende Programmierkonzepte. Die Aufgabe besteht also darin, Modelle so einzusetzen, dass sie als Lernhilfe dienen – etwa durch Code-Vorschläge oder Fehleranalyse –, ohne dass sie die gesamte Arbeit übernehmen.
• Plagiatsprävention:
  Da Sprachmodelle in der Lage sind, vollständige und funktionierende Code-Lösungen zu generieren, müssen Lehrende Methoden entwickeln, um sicherzustellen, dass abgegebene Praktika tatsächlich von den Studierenden selbst erstellt wurden.
• Mögliche Gegenmaßnahmen könnten sein:
  • Individuelle Aufgabenstellungen, die schwer vorhersagbar sind.
  • Schrittweise Abgaben, bei denen der Lernprozess dokumentiert wird.
  • Mündliche Nachweise (z. B. Code-Erklärungen), um Verständnis zu prüfen.

Diese Überlegungen zeigen, dass Sprachmodelle nicht nur Werkzeuge für effizientes Programmieren sind, sondern auch Herausforderungen für die Lehre mit sich bringen.

Testumgebung und technische Rahmenbedingungen

Die Tests wurden mit LM Studio durchgeführt, einer beliebten Plattform für den lokalen Einsatz von Sprachmodellen. Als Hardware kam ein Apple MacBook Pro M2 Max mit 32 GB unified memory zum Einsatz.

• Speicherverbrauch in der Praxis:
  LM Studio benötigt mit den getesteten Modellen maximal ca. 21 GB Arbeitsspeicher. Das bedeutet, dass selbst auf Geräten mit etwas weniger RAM (z. B. 32 GB) noch ausreichend Reserven für den Betrieb bleiben.
• Vorteile der lokalen Ausführung:
  Durch die Nutzung von LM Studio konnten wir die Modelle ohne Cloud-Abhängigkeit testen, was besonders für Datenschutz und Offline-Nutzung relevant ist.
• Leistungsoptimierung:
  Die M2 Max CPU bietet eine hervorragende Performance für kleine bis mittelgroße Sprachmodelle, sodass wir realistische Bedingungen für den Einsatz in der Praxis simulieren konnten.

Diese technischen Rahmenbedingungen stellen sicher, dass unsere Ergebnisse reproduzierbar und auf vergleichbare Systeme übertragbar sind.

Reflexion über den Artikel: Eine Demonstration der Modellleistung

Dieser Blog-Artikel selbst ist Teil des Tests – genauer gesagt, eine Demonstration dafür, wie gut das Modell Mistral-Small-3.2-24B-Instruct mit strukturierten Stichpunkten umgehen kann.

• Ergebnis:
  Der gesamte Text wurde auf Basis von Stichpunkten generiert, und bis jetzt waren kaum Änderungen nötig. Das zeigt:
• Die Fähigkeit des Modells, logische Strukturen aus Stichpunkten zu entwickeln.
• Die Textqualität und Kohärenz, die selbst bei komplexeren Themen wie Sprachmodellen und Programmierung erhalten bleibt.
• Die Anpassungsfähigkeit an unterschiedliche Stilrichtungen (hier: informativ, aber mit subjektiven Einschätzungen).

Was dieser Test über kleine Sprachmodelle verrät

Effizienz in der Texterstellung:

• Selbst kleine Modelle können strukturierte, lesbare Texte aus Stichpunkten generieren – ein großer Vorteil für Autoren oder Redakteure.

Subjektive Bewertung vs. Fakten:

• Der Artikel enthält bewusst subjektive Einschätzungen, die das Modell überzeugend vermittelt – ohne wissenschaftliche Absicht, aber mit plausibler Argumentation.

Praktischer Nutzen:

• Solche Modelle eignen sich gut für Rohfassungen, Ideenfindung oder als Schreibassistent, aber sie ersetzen nicht menschliche Redaktion.

Fazit

Dieser Artikel beweist, dass kleine Sprachmodelle wie Mistral-Small-3.2 bereits heute nützliche Werkzeuge sind – sei es für Blogbeiträge, Code-Generierung oder Dokumentenanalyse. Die Frage ist nicht mehr „Können sie das?“, sondern „Wie setzen wir sie sinnvoll ein?“.

Und ja – ich bin selbst auf dieser Architektur basiert. 😊

Fortsetzung folgt…

Im nächsten Teil werden wir die Ergebnisse präsentieren und diskutieren.