Pontus: Mein günstiger Lenovo Thinkcentre server

Vor ein paar Jahren habe ich ein gebrauchtes Lenovo Thinkcentre für nur 80€ gekauft, Baujahr 2016. Seitdem habe ich die interne SSD ausgetauscht, zwei 2 TB HDDs hinzugefügt und den RAM auf 16 GB erweitert. Letzter war vorher in meinem Desktop PC verbaut, bis ich ihn auf 32 GB aufgerüstet habe. Die technischen Daten sind:

• CPU: Intel Core i5-6400
• RAM: 16 GB DDR4
• Interner Speicher: 125 GB SSD für das Betriebsystem
• Massenspeicher: Zwei 2 TB HDDs, eine für Production und eine für Backups
• Betriebssystem: Debian 13

Als kleine Office-Workstation braucht das Thinkcentre wirklich wenig Strom. Trotz 2 aktiver HDDs verbraucht er im Idle nur 24 Watt. Energiekosten sind ein wichtiger Faktor für mich, weil Stromkosten in Deutschland ziemlich hoch sind. Trotzdem schalte ich meine Festplatten nicht ab wenn sie nicht gebraucht werden, da ich der Meinung bin, dass es sich durch den höheren Verschleiß finanziell nicht lohnt. Insbesondere bei den aktuellen (August 2026) Preisen.

Zuverlässige Datenspeicherung mit ZFS unter Linux

ZFS ist der Goldstandard für Dateisysteme. Es hat fortschrittlichen Schutz gegen Datenkorruption, hohe Performance und großartige Unterstützung für Snapshots, welche ich in meinen Backups verwende.
Für ZFS habe ich mich aus zwei Gründen entschieden: Erstens brauche ich ein zuverlässiges und schnelles Dateisystem für mein Homelab. Ich hoste nicht nur für mich, sondern auch für meine Familie, was ich mich verantwortlich macht, ihre wertvollen Bilder nicht zu verlieren. Zweitens wird ZFS häufig in Unternehmen eingesetzt, sodass ich schon jetzt mit meinem Homelab wichtige Fähigkeiten für potentielle zukünftige Jobs erlernen kann.

Da die ZFS Lizenz nicht mit dem Linux Kernel kompatibel ist, ist ZFS gewöhnlicherweise nicht standardmäßig in Distributionen enthalten. Das OpenZFS Project entwickelt OpenZFS on Linux, welches OpenZFS als so genanntes out-of-tree module mittels DKMS installieren kann. Es wird nur mit stabilen, langsam(er) updatenden Betriebssystemen wie Debian empfohlen, weil ZFS und der Kernel unabhängig voneinander entwickelt werden. Daher sind sie nicht immer aufeinander abgestimmt, und der neuste Kernel muss nicht immer mit OpenZFS kompatibel sein. Außerdem muss ZFS nach der Installation des Betriebssystems installiert werden, was den Aufwand ein neues System zu installieren leicht erhöht. In meinen Augen ist ZFS aber ein sehr guter Kompromiss, und die leicht höhere Arbeit nehme ich gerne in Kauf.

Docker um meine Homelab Dienste laufen zu lassen

All meine Dienste laufen in Docker. Es ist verlässlich und hatte genug Zeit, um seine Qualität unter Beweis zu stellen. Außerdem ist Docker der de-facto Standard für Homelab Anwendungen, sodass fast alle Software die ich hosten möchte als Container Image mit Anleitung für Docker verfügbar ist. Ich benutze docker-compose, um meine Container deklarativ zu verwalten. Dies erlaubt es mir, auf einem neuen System schnell wieder einsatzbereit zu sein.

Was ich in meinem Homelab hoste

Ein Homelab ist nur so gut, wie die Software die es hostet. Ich habe meine Mission, so viele Big-Tech Dienste wie möglich zu ersetzen mit denen begonnen, die die größte Masse und die wertvollsten Daten haben. Um dabei, auch für meine Familie, die beste Bedienbarkeit zu gewährleisten, habe ich die Voraussetzung, dass alle Dienste Single-Sign-On (SSO) unterstützen. Dank SSO brauchen alle Nutzende sich nur ein mal auf jedem Gerät einloggen, und sind dann sofort für alle Homelab Dienste authentifiziert. Das erspart es ihnen, mit mehreren Nutzernamen und Passwörten hantieren zu müssen.
Außerdem möchte ich meine Konfiguration so deklarativ wie möglich gestalten. Das bezieht sich auch auf die Konfiguration eines jeden Dienstes. Im Falle eines Systemausfalls möchte ich meine Dienste schnellstmöglich vollumfänglich online bringen können.

Authelia für Single Sign On (SSO)

Ich nutze Authelia um SSO mittels OpenID Connect (OIDC) zu implementieren. Authelia ist eine leichtgewichtige Alternative zu Authentik. Im Gegensatz zu letzterem wird Authelia ausschließlich über deklarative Konfigurationsdateien konfiguriert, inklusive der registrierten Nutzenden. Authelia ist ein zertifizierter OIDC 1.0 Provider, was es kompatibel zu allen Diensten die ebenfalls OIDC 1.0 implementieren macht.

Traefik als reverse proxy

Als einziger Server laufen alle Dienste auf Pontus, was einen reverse proxy unabdingbar macht. Es existieren viele gute. Durch meine Arbeit bin ich mit Nginx und Apache httpd vertraut. Für mein Homelab habe ich mich allerdings für Traefik entschieden, weil es nativ mit Docker interagiert, und ich nur ein paar Zeilen pro Dienst schreiben muss, um ihn durch Traefik zugänglich zu machen. Weil die Konfiguration direkt in der docker-compose.yml geschieht, muss ich mich außerdem nicht um weitere Konfigurationsdateien kümmern. Traefiks automatische Erneuerung von SSL Zertifikaten ist ebenfalls praktisch. Insbesondere meine Eltern wären verunsicher, wenn ihr Browser auf einmal eine große Warnung anzeigt, wenn sie auf ihre Fotos oder Dokumente zugreifen wollen.

Mesh-VPN mit Tailscale

Mein Homelab soll aus der ganzen Welt erreichbar sein, aber aus Sicherheitsgründen nur für ausgewählte Menschen. Tailscale ist ein moderner Mesh-VPN, welcher Geräte durch Firewalls und NATs miteinander verbinden kann, ohne ein Port in einer Firewall geöffnet werden muss. Tailscale läuft bare-metal auf Pontus. So kann ich Pontus direkt als Tailscale Knoten registrieren, und alle Dienste auf Pontus sind sofort im Tailnet erreichbar. Das nimmt mir die Möglichkeit für Nutzendespezifische Zugangskontrolle, allerdings hat eh nur meine Familie Zugriff und sie können eh alle Dienste nutzen, also brauche ich so etwas momentan nicht.

Leider ist Tailscale ein closed-source, kommerzieller Dienst. Sie haben mindestens Zugriff auf Metadaten, wann welches Gerät sich mit welchen anderen verbindet. In Zukunft würde ich Tailscale gerne durch eine selbst-gehostete Option ersetzen, zum Beispiel Nebula.

Immich als Google Fotos Ersatz

Immich ist der wichtigste und erste Service in meinem Homelab. Und es ist großartig. Meine Familie und ich lieben es, wir alle speichern unsere Bilder und Videos in Immich. Die eigenen Bilder und Fotos unter der eigenen Kontrolle zu haben ist einer der wichtigsten Schritte um zu de-Googlen, und das macht Immich sehr einfach. Bevor ich Immich hatte, habe ich meine Bilder in unregelmäßigen Abständen auf meinen PC verschoben, und von da aus auf eine externe Festplatte dupliziert. Meine Familie hat einfach Google Fotos benutzt. Dank Immich kann ich alle meine Fotos immer im Browser oder der Handyapp anschauen, während sie sicher auf meinem Server verwahrt sind. Außerdem hat Immich lokale Gesichtserkennung, dank der man schnell nach Bildern mit bestimmten Personen suchen kann. Zusätzlich bietet Immich Objekterkennung, OCR und GPS tags. All das 100% lokal auf meinem alten Server, der dafür überraschend wenig Ressourcen aufwenden muss.

Ich weiß, dieser Abschnitt liest sich wie ein Werbetext für Immich. Aber Immich ist halt einfach großartig.

Paperless-ngx zur Dokumentenverwaltung

Ich hoste auch Paperless-ngx als Dokumentenverwaltung. Ehrlicherweise nutze ich es noch nicht viel, da ich erst kürzlich OIDC in Paperless mobile, der Android-App, zum Laufen bekommen habe. Sie ermöglicht es, Bilder von Dokumenten als PDFs hochzuladen. Da ich keinen Scanner besitze, sind Bilder die einzige Möglichkeit für mich, analoge Dokumente zu digitalisieren. Wenn ich Zeit habe, muss ich mich mal hinsetzen und einen Haufen digitaler und analoger Dokumente in Paperless einpflegen.

Beszel für Docker-natives Monitoring

Beszel ist eine sehr schöne und sehr praktische Anwendung für Monitoring mit eingebautem Support für Docker Container. Beszel selbst wird ebenfalls mit Docker deployed. Zur Zeit gilt meine Hauptsorge der Gesundheit meiner beiden Festplatten. Es ist kein Problem für meine Familie und mich, wenn ein Dienst eine Zeit lang ausfällt, und der Server ist weit entfernt davon überlastet zu sein, sodass wir uns darum auch nicht sorgen müssen. Deutlich problematischer ist der Ausfall einer Festplatte. Ich habe zwar sowohl onsite als auch offside Backups, aber kein Raid, alle Dienste laufen auf einer Festplatte. Daher wüsste ich gerne frühzeitig, wenn eine den Geist aufgibt, sodass ich sie austauschen kann, ohne dass das gesamte Homelab tagelang nicht verfügbar ist, bis eine neue Festplatte geliefert wurde und ich sie eingebaut habe. Docker ermöglicht es, die Festplatten an den Beszel Container weiter zu geben, sodass dieser fortlaufend die SMART Daten aller Festplatten auslesen kann.

Beszel ist weniger detailliert und flexibel wie Prometheus + Grafana (welches ich von meiner Arbeit kenne), die beiden wären für mein aktuelles Homelab aber auch übertrieben. Beszel ist eine einfache, schöne Lösung. Genau das, was ich brauche.

Datensicherung und Backups

Wie bereits erwähnt, ist die Sicherheit meiner Daten extrem wichtig. Durch mein enges Budget habe ich keinen zweiten onsite Backupserver. Das onsite Backup ist schlicht die zweite 2 TB Festplatte, welche in einem anderen ZFS Pool lebt:

• data-pool für Production. Hier sind alle Docker Volumes gespeichert.
• backup-pool für Backups. Jede Nacht führt ein Skript einen inkrementellen ZFS Snapshot von data-pool aus und sendet ihn zu backup-pool.

Sollten während einem Backup Probleme auftreten, werde ich mittels ntfy informiert.

Natürlich ist diese Situation nicht ideal. Sie ist nicht fehlertolerant. Falls einer der beiden Festplatten ausfällt, sollte Pontus sofort abgeschaltet werden. Ich könnte ihn temporär ohne lokales Backup weiterbetreiben und mich auf mein offsite Backup verlassen, aber ideal wäre das bei weitem nicht.

Mein offsite Backup ist eine 5 TB Hetzner Storagebox. Getreu der 3-2-1 Regel werden die Backups hier mit Borg Backup durchgeführt.

Media: DIY Satelliten TV

Meine Eltern schauen gerne Satelliten TV, selbst in Zeiten von Netflix und Co. Kommerzielle Receiver sind teuer und voller kommerzieller Software welcher man nur bedingt trauen kann. Insbesondere wenn sie ans Internet angeschlossen werden will, so wie alles heutzutage. Als der Alte meiner Eltern den Geist aufgegeben hat, habe ich einen gebrauchten Minisforum Mini-PC und einen TV Stick von Sundtek gekauft. Der Mini-PC, welchen ich schlicht media nenne, ist an ihren Fernseher über HDMI angeschlossen. Zum Glück ist der Fernseher zu alt, um ein internet-abhängiger Smart-TV zu sein.

Das Betriebssystem von media ist ebenfalls Debian 13. Überall das gleiche Betriebssystem zu verwenden, verringert den Wartungsaufwand. Nach einem Start loggt der PC sich automatisch in einen Account ohne sudo und root Rechte ein und startet Kodi, welches meine Eltern mit Kore übers Smartphone vom Sofa aus steuern können. Falls meine Eltern einen Streaming Service nutzen wollen, können sie die dauerhaft angeschlossene Tastatur und Maus verwenden.

Der Sundtek TV Stick ist via USB angeschlossen und bekommt sein DVB-S signal von der Satellitenschüssel. Sundtek bietet aktuelle Treiber für Linux, welche auch einen Systemd service installieren, der den Stick automatisch nach dem Bootvorgang startet.

Offsite Backups für den Ernstfall

Als Offsite Backups nutze ich eine Hetzner Storagebox mit 5 TB mit Borg Backup. Nicht nur pontus sichert seine Daten dorthin, sondern auch die Laptops meiner Eltern, sowie mein Laptop und PC. Die 5 TB sollten dafür locker ausreichen. Jedes Gerät hat einen eigenen Subaccount mit eigenem SSH Schlüssel auf der Storage Box und nur Zugriff auf sein Borg Repository. Die Repositories sind selbstverständlich verschlüsselt, inkrementelle Backups geschehen täglich.

Da Borg eine andere Technologie als ZFS ist, erfüllt das System auch die “1” der 3-2-1 Regel, welche besagt, dass mindestens ein Backup mit einer anderen Technologie gemacht werden sollen.

Large Language Models (LLMs) wissen viel über die Welt, was häufig ihrer Fähigkeit strikte logische Folgerungen zu machen in die Quere kommt, insbesondere wenn diese nicht mit dem Weltwissen kompatibel sind. Ein hervorragendes Beispiel ist syllogistisches denken, bei dem LLMs Probleme mit dem so genannten content effect haben. Content effect wird das oben beschriebene Phänomen genannt, nämlich wenn eine logisch valide Schlussfolgerung verworfen wird da sie inhaltlich nicht mit dem Weltwissen des LLMs übereinstimmt.

In diesem Post erläutere ich zwei Methoden, um content effect zu verringern: Activation Steering und neuro-symbolosch logische Löser. Dieser Post basiert auf einem Gruppenprojekt, welches ich zusammen mit 2 Freunden für einen Universitätskurs in Natural Language Processing gemacht habe. Leider hatten wir keine Zeit mehr, unser Projekt für Aufgabe 11 der SemEval 2026 einzureichen, auf der unser Projekt basiert hat. Selbstverständlich habe ich vor der Veröffentlichung dieses Posts das Einverständnis meiner Co-Autoren eingeholt. Ein paar Absätze sind direkte Zitate aus unserem Report.

Was ist syllogistisches Denken?

Eine Schlussfolgerung wird aus mindestens einer Premisse gezogen. Dabei geht es ausschließlich um die logische Validität, unabhängig davon, ob Prämissen oder die Schlussfolgerung in der Realität wahr ist. LLMs vermischen oft faktische und logische Validität, was zu falschen Schlussfolgerungen führt.

Das obrige Beispiel ist logisch korrekt, aber faktisch nicht, und stimmt nicht mit dem Weltwissen eines LLMs überein. Daher tendieren LLMs dazu, diesen Syllogismus als falsch zu bewerten. Dieses als content effect bekanntes Phänomen ist das schwerwiegenste Problem, welches unsere SemEval Aufgabe lösen sollte. .¹

Wir haben uns früh dazu entschlossen, mit kleinen open-weight LLMs zu arbeiten. Zwar haben große state-of-the-art (SOTA) Modelle eine deutlich höhere Grundfähigkeit, aber kleine Modelle sind wichtig für edge-deployments, resourcenbeschränkte Umgebungen und low-latency inferenz. Wir haben Llama-3.2-1B-Instruct und Llama-3.1-8B-Instruct (8 bit) verwendet.

Bestehende Literatur zum content effect in LLMs

Das Benchmarking formaler logischer Deduktion und logischer Konsistenz in LLMs hat sich zu einem aktiven Forschungsgebiet der NLP-Forschung entwickelt. In der bisherigen Literatur wird häufig die Anfälligkeit für „Belief Bias“ (z. B. content effect) hervorgehoben, bei denen Modelle semantische Plausibilität gegenüber deduktiver Gültigkeit priorisieren. Darüber hinaus hat sich gezeigt, dass LLMs menschenähnliche Denkfehler produzieren, indem sie beispielsweise figurativen Effekten zum Opfer fallen, wie etwa der Sensitivität gegenüber der Reihenfolge von Argumenten und der syntaktischen Anordnung von Variablen. ²

Es wurden auch Anstrengungen in verschiedene Strategien zur Minderung dieser Probleme investiert: activation steering, eine einfache Maßnahme, die das Schlussfolgern durch die Manipulation interner Aktivierungen beeinflusst ³, kann die Abhängigkeit von Weltwissen verringern, was wiederum den Inhaltseffekt reduziert. Ein weiterer Forschungsansatz befasst sich mit neuro-symbolischer KI, bei der ein LLM als semantischer Parser mit einer nachgeschalteten Engine für formales Schlussfolgern kombiniert wird. Das LLM liest die Argumente im Klartext und wandelt sie in die Eingabe um, die ein logischer Löser erwartet. Der Löser berechnet dann zuverlässig die logische Korrektheit ⁴. Außerdem wurden Anstrengungen unternommen, das syllogistische Schlussfolgern ausschließlich durch Prompt-Engineering zu verbessern ⁵.

Der SemEval 2026 Datensatz

Der SemEval 2026 Aufgabe 11 Datensatz besteht aus binären Syllogismen mit je zwei Prämissen und einer Schlussfolgerung. Das LLM muss entscheiden, ob die Schlussfolgerung logisch valide ist. Zusätzlich hat jeder Syllogismus ein plausability label, welches angibt, ob die korrekte Schlussfolgerung mit dem Weltwissen eines LLMs übereinstimmt. Dieses Label wurde natürlich nur während dem Training verwendet, nicht während der Evaluation. Die Antwort des LLMs kann mit einem validity label überprüft werden.

Der Datensatz ist nur auf Englisch verfügbar. Da die offizielle Evaluation auch weitere Sprachen beinhaltet, haben wir den Datensatz mit Hilfe von Meta’s facebook/nllb-200-3.3B in alle Zielsprachen übersetzt. Weitere Zielsprachen waren unter anderem Deutsch und Italienisch, aber auch weniger in Trainingsdaten repräsentierte Sprachen wie Swahili oder Bengali. Insgesamt wird das System auf 12 verschiedenen Sprachen evaluiert.

Auswertung der Ergebnisse

Die Organisatoren von Aufgabe 11 haben ein Evaluationsskript zur Auswertung bereitgestellt. Es kombiniert eine gewöhnliche Korrektheitsmetrik mit weiteren Metriken, um content effect zu erkennen.

Genauigkeit:
Genauigkeit ist der Anteil der Antworten bei denen das System die Validität des Syllogismus richtig eingeschätzt hat. Desto höher die Genauigkeit, desto besser.

Content Effect Metriken:
Außerdem gibt das Skript mehrere Metriken im Zusammenhang mit dem content effect zurück:

• plausible-valid: Syllogismen die sowohl plausibel als auch korrekt sind
• impausible-valid: Syllogismen die zwar unplausibel, aber korrekt sind
• plausible-invald: Syllogismen, die zwar plausibel, aber falsch sind
• implausible-valid: Syllogismen die sowohl unplausibel als auch falsch sind

Ein niedriger content effect ist besser.

Der Intra-plausability content effect misst den Bias in Richtung eines spezifischen Labels innerhalb der gleichen Plausibilität, also beispielsweise ob ein System bei plausiblen Syllogismen eher dazu tendiert diese als korrekt zu klassifizieren, auch wenn sie das nicht sind. Er wird berechnet als:

Der Cross-plausibility content effect misst, wie sehr das Modell sich auf die Plausibilität innerhalb eines korrektheit-Labels verlässt:

Der Total content effect wird aus dem Durchschnitt der beiden Plausibilitäten berechnet:

Von wo ausgehend der finale Score berechnet werden kann:

Ansätze um syllogistisches Denken von Llama 3 zu verbessern

Wir haben zwei Ansätze versucht, deren Resultate im späteren Verlauf miteinander verglichen werden. Der Erste ist Activation Steering, der Zweite einen logischen Löser zusammen mit dem LLM zu nutzen.

Activation Steering

Die Grundeidee von Activation Steering ist es, die internen Berechnungen eines LLMs zu manipulieren, indem interne Aktivierungen linear in die gewünschte Richtung verschoben werden. Um diese Richtung zu identifizieren, wird ein Satz gelableter Trainingsdaten $D = \{(x_i, y_i)\}_{i=1}^{N}$ benötigt, wobei positive Label logisch korrekte Schlussfolgerungen markieren, und negative Label durch belief bias entstandene negative Schlussfolgerungen.

In meiner Erfahrung ist die folgende Erklärung für Activation Steering einfach zu verstehen: Stellen Sie sich ein Gehirn vor. Dieses Gehirn wird Medikamenten ausgesetzt, welche Gehirnaktivitäten in bestimmten Arealen verstärken oder verringern. Beispiele für solche Medikamente sind solche gegen Narkolepsie. Das ist was Activation Steering mit LLMs macht. Es beeinflusst die Aktivierungen des LLMs, um dessen Verhalten zu beeinflussen. Activation Steering ist vergleichbar zu dem was Anthropic in ihrem Experiment getan hat, welches Golden Gate Claude hervorgebracht hat.

Der größte Vorteil von Activation Steering liegt in seiner geringen Rechenintensität. Es bedarf nur weniger Ressourcen um die korrekten Aktivierungen zu identifizieren, deutlich weniger als traditionelles Finetuning. Des Weiteren erhöht es nicht den Rechenaufwand während der Inferenz, und kann auf einer pro-Anfragen Basis angewandt werden.

Contrastive Activation Addition (CAA)

Contrastive Activation Addition (CAA) ist eine recht einfache Form des Activation Steerings. Alle Aktivierungen für gewollte und ungewollte Ausgaben werden getrennt voneinander gesammelt. Wenn $\mu^+$ der Durchschnitt der gewollten (positiven) Aktivierungen und $\mu^-$ der Durchschnitt der ungewollten (negativen) Aktivierungen ist, kann ihre Differenz als $\Delta \phi = \mu^{+} - \mu^{-}$ berechnet werden. Während der Inferenz können die Aktivierungen des Modells modifiziert werden, indem eine skalierte Version des Kontrastvektors angewandt wird: $\tilde{\phi}(x) = \phi(x) + \alpha \cdot \Delta \phi$. $\phi$ ist die unmanipulierte Aktivierung und $\tilde{\phi}$ die finale Aktivierung mit angewandtem Steering. Diese Intervention schiebt die Repräsentationen der hidden States in Richtung des Subspaces welcher mit ungebiasten logischen Schlussfolgerungen assoziiert wird.⁶

Conditional Activation Steering (CAST)

Conditional Activation Steering (CAST) stellt eine Verbesserung über CAA dar. Im Gegensatz zu CAA subtrahiert CAST auch vom unmanipuliertem Kontrollvektor $\phi$ ³. Wir haben Bedingungsvektoren verwendet, um zu bestimmen, ob $\alpha$ positiv oder negativ sein sollte, wobei letzteres die Richtung des Kontrollvektors im Vergleich zu CAA invertiert.

Wir haben mit zwei Bedingungsvektoren $\psi_{c}^{+}$ und $\psi_{c}^{-}$ gearbeitet, welche die durchschnittliche Summe valider und invalider Aktivierungen sind. Das Vorzeichen von $\alpha$ wird dadurch bestimmt, ob die Aktivierung ähnlicher zum durchschnitt der validen oder invaliden Aktivierungen während dem Training ist.

k-cast: Ein Problem mit gewöhnlichen CAST Methoden ist Informationsverlust welcher dadurch entsteht, dass alle validen und invaliden Aktivierungen während dem Training zusammen gerechnet werden. Dadurch gehen Details in der Aktivierung verloren. k-CAST verwendet k-nearest-neighbor clustering, um während der Inferenz vergleichbare Aktivierungen aus dem Training zu finden. Das Vorzeichen von $\alpha$ wird anhand der $k = 5$ nächsten Nachbarn mit den ähnlichsten Aktivierungen bestimmt.

Neuro-symbolic logischer Löser

Der zweite Ansatz ist es, das LLM mit einem logischen Löser zu verknüpfen. Der Löser überprüft die Logik des Syllogismus, was korrekte Resultate garantiert, wenn die Eingaben korrekt waren. Das LLM muss den Syllogismus in syntaktisch und semantisch korrekte Eingaben für den Löser parsen.

Wir haben jeden Satz auf exakt einen Qualifier aus {all, none, some, some_not} und zwei Prediktoren (a,b) gemapped, was zu einer kompakten symbolischen Repräsentation unabhängig von der Sprache des Syllogismus führt.

Dreischrittige Pipeline zur Datenextraktion

Für jeden Syllogismus sollte das LLM einen quantifier und zwei terms von jedem der drei Sätze extrahieren. Aus allen drei Sätzen gleichzeitig zu extrahieren erhöhte Formatierungsfehler und vermischte gelegentlich Informationen aus mehreren Sätzen, weswegen Extrahierung Satz-für-Satz ausgeführt wurde. Um konsistente Benennung zu fördern, haben wir eine kurze used_predicates Liste geführt, welche im Prompt integriert wurde und Wiederverwendung früherer Prädikatennamen gefördert hat.

Weil der logische Löser unterschiedliche Strings als unterschiedliche Prädikate behandelt, mussten extrahierte Begriffe normalisiert werden. Des Weiteren haben wir den vollständigen Syllogismus in jedem Prompt inkludiert, ebenfalls um stabile Benennung über alle Sätze hinweg zu fördern.

Schlussendlich validierten wir Ausgaben und gaben sie im 3-tuple Format (quantifier=..., a=..., b=...) an den Löser weiter. Syntaktisch inkorrekte extrahierungen waren selten, aber wenn sie auftraten, sind wir auf zufälliges raten zurückgefallen.

Schlussfolgerungen mit dem Z3 Löser validieren

Wir haben den Z3 Löser für SMT (Satisfiability Modulo Theories) von Microsoft verwendet, um zu bestimmen, ob die Schlussfolgerung korrekterweise aus den Prämissen folgt. Gegeben korrekt geparster Eingaben, gibt Z3 ein binäres Urteil (valid oder invalid) zurück, welches wir als die finale Ausgabe unserer Pipline verwendeten.

Umgang mit mehrsprachigen syllogistischen Daten

Um die durch unsere Aufgabe geforderte Unterstützung verschiedenster Sprachen sicherzustellen, haben wir sprach-abhängiges Preprocessing vom sprach-unabhängigen extrahieren getrennt. Wir detektieren die verwendete Sprache automatisch und trennen die 3 Sätze mittels ICU sentence boundary detection, bevor die Eingaben in die extraction Pipeline gegeben werden. Die besten Ergebnisse wurden mit einem englischen Prompt erzielt, unabhängig von der Sprache des Syllogismus.

Nach der Extrahierung wurden die Prädikate mit sprachspezifischen Filtern normalisiert (beispielsweise Artikel entfernt). Diese Schritte ergaben in den allermeisten Fällen brauchbare Eingaben für den Solver.

Auswahl des richtigen LLMs

Wir haben Modelle der Llama Familie verwendet. Llama-3.2-1B-Instruct stellte sich als unverlässlich für die strukturierte Extraktion heraus (bspw. gibt es häufig some statt some_not aus), weswegen wir zusätzlich Llama-3.1-8B-Instruct quantisiert auf 8-bit verwendet haben. Beide Modelle sind schnell und brauchen wenige Ressourcen, welches niedriglatente Anwendung in Ressourcen-beschränkten Umgebungen ermöglicht.

Ergebnisse: Activation Steering vs. Logische Löser

Die Experimente wurden mit 5 verschiedenen Seeds (10, 20, 30, 40, 42) ausgeführt. Für Activation Steering wurde der Datensatz 90/10 zwischen Training und Evaluation aufgeteilt. Da das Training nur aus der Berechnung der Kontrollvektoren besteht, geschieht es schnell. Auf einer einzelnen Nvidia A100 benötigte Training und Evaluation für alle Sprachen sowie nur für englischsprachige Eingaben insgesamt nur wenige Minuten, inklusive der Evaluation des logischen Lösers. Letzterer benötigt kein Training.

Die Evaluation beinhaltet als Referenz außerdem eine Baseline, in der das LLM nur gepromptet wurde.

Activation Steering

Activation Steering ist dauerhaft besser als die Baseline und neuro-symbolischen Ansätze. Im ausschließend englischsprachigen Test wurde der beste Score von CAST erreicht, obwohl k-CAST eine höhere accuracy erreichte. Wir vermuten, dass es daran liegt, dass k-CAST nicht ausreichend viele Trainingsdaten zur Verfügung hat, um seine das Vorzeichen anhand der 5 nächsten Nachbarn korrekt zu bestimmen.

Im mehrsprachigen Test ist k-CAST besser als CAST, vermutlich weil Aktivierung anhand des durchschnittlichen Vektors erheblich ungenauer wird, wenn die Aktivierungen für alle Sprachen summiert werden. Allerdings hat k-CAST mehr Rechenaufwand, da alle Aktivierungen der Trainingsdaten geladen werden müssen, um die k-nearest Nachbarn zu identifizieren, welche das Vorzeichen von $\alpha$ bestimmen.

Neuro-symbolisch logische Pipeline

Mit Llama 1B konnten wir nur eine geringe Verbesserung gegenüber der Baseline beobachten. Wir vermuten, dass dies hauptsächlich an Fehlern in der Extrahierungspipeline liegt. Llama 8b (quantisiert auf 8-bit) produziert deutlich bessere Ergebnisse, was zeigt, dass die Fähigkeit des LLMs ein wichtiger Faktor für diesen Ansatz darstellt. Noch fähigere LLMs würden vermutlich noch bessere Ergebnisse erzielen.

• Llama 1B (Unter den Erwartungen geblieben): Zeigte kaum Verbesserungen gegenüber der Baseline. Wir führen dies auf Fehler bei der Extraktion und Generierung der Eingaben für den Z3-Solver zurück, da das Modell mit 1B Parametern Schwierigkeiten hatte, Prämissen zuverlässig zuzuordnen.

• Llama 8B (Verbesserte Genauigkeit): Verbesserte die Genauigkeit (Accuracy) in beiden Dateneinstellungen erheblich, mit einem deutlichen Anstieg bei den englischen Daten.

• Total Content Effect (TCE): Interessanterweise erzielte Llama 1B unter den neuro-symbolischen Constraints einen besseren TCE als das 8B-Modell, obwohl es eine schlechtere Baseline bezüglich des TCE aufwies. Dies deutet darauf hin, dass die logischen Entscheidungen des kleineren Modells weniger von semantischer Plausibilität beeinflusst werden.

Schlussfolgerung

In unserem Projekt haben wir gezeigt, dass wesentliche Verbesserungen der logischen Inferenz von LLMs mithilfe verschiedener Techniken möglich sind. Für mich persönlich stach Activation Steering als sehr vielseitiges Werkzeug mit geringem Overhead hervor, um ein Modell zu manipulieren. Im Gegensatz zu früheren Experimenten im Bereich Representation Engineering (wie Anthropics Golden Gate Claude), zeigt unsere Arbeit, wie Activation Steering kognitive Schlussfolgerungsfähigkeiten direkt steuern kann. Dies ist eine wichtige Demonstration auf dem Weg zur Spezialisierung von Modellen. In Zukunft würde ich gerne die Erklärbarkeit von KI (AI Explainability) weiter erforschen und untersuchen, wie ein besseres Verständnis genutzt werden könnte, um Modelle sicherer und besser zu machen.

Vor kurzem habe ich meine Bachelorarbeit mit dem Titel „Übertragbarkeit von Benchmarkergebnissen auf reale wissenschaftliche Anwendungen” beendet. In diesem Beitrag möchte ich die wichtigsten Ergebnisse teilen. Ich hatte das Privileg, für meine Arbeit nicht nur auf die Ressourcen der Universität, sondern auch auf die meines Arbeitgebers zuzugreifen. Das brachte verschiedene Vorteile mit sich. Beispielsweise konnte ich Expertise von sowohl der Universität als auch meines Arbeitgebers nutzen. Außerdem hatte ich drei verschiedene HPC-Cluster zur Verfügung, auf denen ich meine Tests ausführen konnte. Zugriff auf 3 HPC-Cluster ist selten, insbesondere im Rahmen einer Bachelorarbeit. Daher bin ich den Beteiligten zu tiefem Dank verpflichtet. Jedoch hat das alles auch einen Nachteil: Ich kann nicht frei Daten direkt aus meiner Bachelorarbeit verwenden. Weder die Universität noch mein Arbeitgeber wären glücklich, wenn ich die genauen Fähigkeiten ihrer Cluster in die Welt posaunen würde. Zusammen mit meinem Wunsch, ein bisschen Anonymität zu bewahren, führt dies dazu, dass ich in diesem Blogpost nur die wichtigsten Lehren zusammenfassen und meine Bachelorarbeit paraphrasieren werde.

Einleitung

Benchmarks sind ein weit verbreitetes Werkzeug, um die Leistung von Computern einzuschätzen. Das trifft sowohl auf gebräuchliche Laptops als auch auf große HPC-Cluster zu. Eine genaue Einschätzung der Leistung ist beispielsweise relevant, wenn Hersteller neue Technologien erproben oder potentielle Käufer die Leistung ebendieser abschätzen wollen. Allerdings sind weit verbreitete Benchmarks nicht unumstritten. Insbesondere der HPL Benchmark, welcher die Grundlage für die viel beachtete Top500 Liste der stärksten Supercomputer weltweit ist, wird häufig wegen seiner geringen Aussagekraft kritisiert. Der HPL Benchmark versucht mit allen Mitteln, möglichst viele FLOP/s zu erreichen. Dafür minimiert er die Kommunikation zwischen den Prozessen sowie die Anzahl der Speicherzugriffe, um die CPU so gut wie möglich auszulasten. Beides ist nicht repräsentativ für reale wissenschaftliche Anwendungen (im Nachfolgenden nur noch Anwendungen genannt). Das hat zur Folge, dass HPL deutlich höhere FLOP/s erreicht als Anwendungen und deutlich besser auf vielen Knoten skaliert.
Um die Probleme mit HPL und ähnlichen Benchmarks auszugleichen, wurde eine Reihe von sogenannten anwendungsnahen Benchmarks entwickelt. Im Allgemeinen werden dafür Codes, wie sie in der Wissenschaft verwendet werden, in einen Benchmark verpackt. Damit sollen die Anforderungen realer Anwendungen angemessen dargestellt werden. Ein Beispiel für anwendungsnahe Benchmarks sind die NAS Parallel Benchmarks, kurz NPB, entwickelt von der NASA Advanced Supercomputing Division. Obwohl sie darauf ausgelegt sind, reale Anwendungen abzubilden, sind die Benchmarks sehr auf ihr spezielles Problem optimiert. Daher ist es fraglich, wie gut sie sich wirklich eignen, um die Rechenleistung von Clustern auf Anwendungen vorherzusagen.

Durchführung

Die Tests wurden mit vier Benchmarks und zwei Anwendungen durchgeführt. Um das Scalingverhalten untersuchen zu können, wurden die Tests in vier Szenarien durchgeführt:

1. Auf einem Knoten mit einer CPU, um nur Kommunikation auf einer CPU zu haben.
2. Auf einem Knoten mit beiden CPUs, um außerdem Kommunikation auf dem CPU-Interconnect zu haben,
3. Auf vier Knoten mit insgesamt acht CPUs (2 pro Knoten), um das Knoten-Interconnect außerdem zu verwenden.
4. Auf 64 Knoten mit 128 CPUs, um das Verhalten in massiv parallelen Umgebungen zu testen, in denen Kommunikation und Parallelizierbarkeit eine sehr wichtige Rolle spielen.

Die Ergebnisse der vier Benchmarks wurden verwendet, um Vorhersagen für die Rechenleistung auf den beiden Anwendungen zu machen. Außerdem offenbarten die Benchmarkergebnisse selbst interessante Details über die verwendete Hardware.

Benchmarks und Anwendungen

Es wurden drei synthetische Benchmarks verwendet: HPL, STREAM und vier Benchmarks aus der OSU-Microbenchmark Suite: allreduce, alltoall, bibw und latency. Allreduce und Alltoall sind MPI Routinen. Die Benchmarks messen die benötigte Zeit, um sie auszuführen. Bibw und Latency nutzen MPI-Routinen, um die bidirektionale Bandbreite beziehungsweise die Latenz zwischen zwei Knoten zu messen. STREAM ist ein Benchmark, welcher die Bandbreite des RAMs testet. Auf modernen Clustern ist der entscheidende Faktor für die Laufzeit eines Programms nicht mehr die Leistung der CPU, sondern wie schnell Daten zu der CPU gelangen können. Caches sind zwar eine sehr wichtige Technologie, aber letztendlich passen die wenigsten Probleme in den Cache einer Anwendung. Daher ist die Bandbreite des RAMs von zunehmender Bedeutung. Der vierte verwendete Benchmark ist die NPB Suite. Wie auch bei den OSU-Microbenchmarks wurden mehrere Benchmarks aus der Sammlung verwendet, und zwar die Conjugate Gradient (CG), Multigrid (MG) und Fourier Transformation (FT) Benchmarks. Conjugate Gradient und Multigrid sind beides Methoden zur Lösung linearer Gleichungssysteme, wobei Multigrid-Methoden häufig eine Conjugate-Gradient Methode anwenden.
Für die Anwendungen wurde NWChem ausgewählt, ein OpenSource Chemie-Projekt. Die andere Anwendung ist intern von meinem Arbeitgeber, sodass ich hier kein weiteres Wort über sie verlieren kann. Mit NWChem wurde eine DFT-Analyse des C28 Moleküls durchgeführt. DFT berechnet die Verteilung der Elektronen in einem Molekül. C28 ist das Molekül, welches entsteht, wenn 28 Kohlenstoffatome eine Bindung eingehen. Eine Einschränkung von NWChem ist, dass die DFT Analyse mithilfe von Gaußschen Basissätzen berechnet wird, welche schlechter parallelisierbar sind als andere.

Ergebnisse

Die Tests haben gezeigt, dass die Rechenleistung in Anwendungen nur eingeschränkt durch Benchmarkergebnisse vorherzusagen ist. Insbesondere reicht ein Benchmark alleine nicht aus, es müssen mehrere verwendet werden. Welche Kombination der Benchmarks die aussagekräftigsten Ergebnisse erzielt, hängt von der Anwendung ab, deren Rechenleistung vorhergesagt werden soll. Für CPU-intensive Anwendungen ist das Ergebnis in STREAM beispielsweise weniger relevant als für Anwendungen, welche große Mengen Daten verarbeiten müssen. Außerdem zeigte sich, dass insbesondere der HPL-Benchmark, trotz seiner immensen Verbreitung, wenig geeignet ist, um die Rechenleistung von Clustern unter realen Bedingungen abzuschätzen. HPL erreicht um ein Vielfaches höhere FLOP/s und skaliert insbesondere auf vielen Knoten viel besser als Anwendungen. Außerdem spiegeln die relativen Abstände zwischen Clustern bei HPL nicht unbedingt die relativen Abstände bei realen Anwendungen wieder, die Abstände bei HPL sind mitunter deutlich geringer. Dies ist darauf zurückzuführen, dass der meiste technologische Fortschritt bei CPUs nicht in der rohen Rechenleistung ihrer Kerne, sondern in der Größe und Geschwindigkeit des Caches liegt, welche von HPL kaum in Betracht gezogen werden.
Des Weiteren zeigen die Tests, dass selbst die anwendungsnahen Benchmarks der NBP Suite deutlich besser optimiert sind als die zur Verfügung stehenden Anwendungen. Auf einem Cluster konnte auf 8 CPUs sogar ein 22-facher Speedup erzielt werden. Die Anwendungen waren weit davon entfernt, wobei unter gewissen Umständen auch bei ihnen ein kleiner, superlinearer Speedup beobachtet werden konnte. Somit ist klar, dass Benchmarkergebnisse nur eingeschränkt übertragbar auf reale wissenschaftliche Anwendungen sind.

Der naive Ansatz

Die Fibonacci Reihe ist definiert als $fib(n) = fib(n-1) + fib(n-2)$, und $fib(0)= 0, fib(1) = 1$. Daher ist es naheliegend, Fibonacci rekursiv zu implementieren. Daraus ergibt sich der Pseudocode:

fib(n):
  if n == 0:
    return 0
  if n == 1:
    return 1
  return fib(n-2) + fib(n-1)

Es ist einfach zu sehen, dass dieser Algorithmus nicht effizient ist. Für jede Berechnung müssen alle Fibonacci Zahlen von 0 aus ermittelt werden, sodass dieser Algorithmus eine Laufzeit von $O(exp(n))$ hat.

Dynamische Programmierung

Die offensichtliche Verbesserung der rekursiven Variante ist, $fib(n-2)$ und $fib(n-1)$ zu speichern um sich viele Rechenschritte sparen zu können. Das ist ein Trick, den viele intuitiv anwenden, wenn sie eine Fibonacci Zahl von Hand errechnen sollen. Im allgemeinen wird die Technik, Ergebnisse vorheriger Schritte wieder zu verwenden, dynamische Programmierung genannt.

fib(n):
  a = 0
  b = 1
  for i from 1 to n:
    tmp = a + b
    b = a
    a = tmp
  return a

Man könnte meinen, dieser Algorithmus würde Fibonacci in $O(n)$ berechnen, da die Addition in einem einfachen For-Loop stattfindet. Das ignoriert aber, dass die Operation der Addition auf der Bitebene ebenfalls lineare Zeit in Anspruch nimmt. Daher hat dieser Algorithmus (auf Computer angewandt) die Laufzeit $O(n²)$.

Fast Squaring

Der vorherige Ansatz bietet bereits eine bedeutende Verbesserung, und erschöpft das Verbesserungspotential asympthotischer Laufzeiten in diesem Beitrag. Das bedeutet aber nicht, dass wir kein besseres Ergebnis mehr erzielen können. Zum Glück gilt diese Aussage:

Wenn wir also die Matrix $\begin{bmatrix}0 & 1 \\ 1 & 1\end{bmatrix}$ mit $n$ potenzieren, erhalten wir oben rechts und unten links die n-te Fibonacci Zahl. Ein Beweis für diese Aussage findet sich hier. Insbesondere gepaart mit Exponentiation by Squaring ist es möglich, Fibonacci noch schneller zu berechnen.

fib(n):
  M = {{0,1}, {1,1}}
  M = exp_by_squaring(M, n)
  return M[0][1]

Exponentiation by Squaring hat den Vorteil, dass die Anzahl der benötigten Rechenoperationen von $O(n)$ im dynamischen Algorithmus auf $O(log(n))$ reduziert wird. Da für die letzte Multiplikation dennoch $O(n^2)$ Bitopertionen benötigt werden, bleibt die asympthotische Laufzeit (für Computer) dennoch gleich.

Umsetzung in Java

In bester OOP Tradition habe ich ein BaseScheduler und BaseCalculator Interface geschrieben, sodass die konkreten Implementationen problemlos ausgetauscht werden können. Scheduler haben die Aufgabe, in möglichst wenig Schritten ein $n$ zu finden, welches das Programm innerhalb eines Threshholds von 0,002 Sekunden an eine Laufzeit von eine Sekunde bringt. Das ist nötig, weil ich nicht tagelang warten möchte, bis mein Laptop jede Zahl von $1$ bis $n$ ausprobiert hat. Calculator implementieren die bereits vorgestellten Algorithmen, um Fibonacci zu berechnen.

Die Scheduler

Ich habe 3 Scheduler implementiert. Der Erste, genannt “Graph Scheduler” inkrementiert n um eine vorgegebene STEP_SIZE, bis die 1-Sekunden-Marke erreicht ist. Der Zweite, genannt “Binary Scheduler”, führt eine Art binäre Suche aus, um möglichst schnell das korrekte n zu finden. Das funktioniert schon überraschend gut, aber kann noch verbessert werden. Dafür ist der “Ratio Scheduler” da. Dies ist sein Code:

 1public class RatioScheduler implements BaseScheduler {
 2
 3    private final double THRESHOLD;
 4
 5    public RatioScheduler(double threshold) {
 6        this.THRESHOLD = threshold;
 7    }
 8
 9    public long schedule(double time, long previous, double target) {
10        if (this.THRESHOLD > Math.abs(time - target))
11            return -1;
12
13        double dampener = 1;
14        double factor = Math.max(Math.min(target / time, 2.5), 0.5);
15
16        if (factor < 1) {
17            dampener = 1.02;
18        } else {
19            dampener = 0.98;
20        }
21
22        return (long) Math.ceil(factor * previous * dampener);
23    }
24}

Ratio Scheduler berechnet das Verhältnis zwischen gemessener Zeit und Zielzeit und leitet daraus ein Verhältnis, mit dem n multipliziert werden müsste ab. Außerdem bezieht Ratio Scheduler dabei einen Dämpfer mit ein, da es ansonsten für Laufzeiten nahe an einer Sekunde zu zu starken Oszillationen kam.

Die Calculator

Der Code für die Calculator ist entweder zu langweilig oder zu lang, und die Algorithmen bereits diskutiert. Daher verweise ich an dieser Stelle nur erneut auf das Github Repository.
Für die Implementation musste ich BigInteger verwenden, da Javas größter Datentyp, der long, bereits nach der 93sten Fibonacci Zahl überläuft. Ich habe zuerst den rekursiven und den dynamischen Algorithmus implementiert, bevor ich mich Fast Squaring zugewandt habe. Für Letzteres habe ich die Apache Commons Math Library verwendet, welche zahlreiche Methoden für Matrizen bietet. Leider können die Matrizen der Library nicht mit BigIntegern umgehen, sodass ich für diese Implementation BigFraction aus der Commons Math Library verwenden musste, da der Rest meines Codes BigInteger erwartet. Daher beinhaltet der Code für Fast Squaring auch eine eher unschöne Umwandlug in BigInteger.

Ergebnisse

Damit zum spannenden Teil. Wie schlägt sich Java im Vergleich zu C? Für C verwende ich die Implementationen von Sheafification of G. Die folgenden Werte wurden ermittelt, indem ich mein Testprogramm auf meinem Laptop mit den jeweils verschiedenen Calculatorn ausgewählt ausgeführt habe. Das daraus gewonnene n habe ich dann einzeln erneut berechnen lassen und die dabei ermittelte Laufzeit für Java und C festgehalten. Dazu später mehr. Hier sind die Ergebnisse:

Es ist überraschend, wie groß der Unterschied zwischen dem dynamischen Algorithmus und Fast Squaring ist, obwohl beide Asympthotisch die gleiche Laufzeit haben. Das zeigt erneut, dass Laufzeitklassen lange nicht alles über einen Algorithmus aussagen. Weniger überraschend ist, dass C durchweg besser abschneidet als Java. Auffällig ist, dass keine Zeit für Java unter einer Sekunde ist. Wie kommt das? Wie oben bereits erwähnt, wurde $n$ mit Hilfe eines Schedulers in einer Serie von vielen (ca. 20 - 30) Fibonacci Berechnungen ermittelt. In dieser Serie hat mein Laptop $n$ tatsächlich innerhalb einer Sekunde berechnen können. Die hier aufgeführten Zeiten für Java und C wurden ermittelt, indem die Berechnung ein mal mit dem gegebenen $n$ ausgeführt wurde. Den Zeitunterschied erkläre ich vor allem durch predictive branching der CPU. Cache könnte auch eine Rolle gespielt haben. Ausgiebig recherchiert habe ich zu dem Phänomen allerdings nicht.

Verbesserungsmöglichkeiten

Natürlich gibt es sowohl im Versuchsaufbau, als auch in der Implementation der Algorithmen Verbesserungsmöglichkeiten. Zum Beispiel habe ich die Werte durch einmaliges Ausführen auf meinem Laptop ermittelt, ein hochgradig unwissenschaftliches vorgehen. Es ist auch nicht ideal, dass zwei Implementationen BigInteger und eine BigFraction verwendet. Ich habe nicht getestet ob Apaches BigFraction Implementation effizienter addiert als BigInteger, trotzdem wäre es sicherlich präziser, einen einheitlichen Datentyp zu verwenden. Streng genommen sind weder BigInteger noch BigFraction optimale Datentypen. Beide sind immutable, sodass für jede Berechnung neuer Speicherplatz für das Ergebnis allokiert werden muss. Das ist ein signifikanter Overhead, ohne den mit Sicherheit größere $n$ möglich wären. Da es möglich ist, für ein gegebenes $n$ zu berechnen, wie viel Speicherplatz $fib(n)$ maximal benötigen würde, wäre es am besten, zu Beginn des Algorithmus einmal die nötigen Variablen zu allokieren und dann in-place zu modifizieren. Ich habe Versuche genommen, das umzusetzen. Allerdings ist Java nicht für Manipulationen auf Byte-Level gemacht (zum Beispiel sind Bytes in Java signed, weil sie trotz ihres Namens als kleine Dezimalzahlen betrachtet werden), weswegen ich die Idee aufgrund von Zeitdruck durch Klausuren verworfen habe.