SymbolicAI: Eine neuro-symbolische Perspektive auf LLMs

• SymbolicAI ist ein neuro-symbolisches Programmier-Framework, das Python-Programmierung und LLMs nahtlos verbindet
• Über das Symbol-Objekt als Grundeinheit unterstützt es sowohl syntaktische als auch semantische Manipulationen
• Die Contracts-Funktion wendet Datenvalidierung und automatische Korrekturlogik auf LLM-Vorhersagen an und sorgt so für Zuverlässigkeit und Robustheit
• Die Anbindung an verschiedene externe Engines (OpenAI, Anthropic, huggingface usw.), Websuche, Bilderzeugung und Sprachverarbeitung ist möglich
• Kennzeichnend sind ein prioritätsbasiertes Konfigurationsmanagementsystem und starke Anpassungsmöglichkeiten

---

SymbolicAI: Projektüberblick und Bedeutung

• SymbolicAI ist eine neuro-symbolische (Neuro-Symbolic) Bibliothek, die die natürliche Verbindung von klassischer Python-Programmierung und differenzierbaren, programmierbaren LLMs (Large Language Models) unterstützt
• Dank des modularen Designs sind Erweiterungen, Engine-Wechsel und Tool-Integrationen einfach möglich
• Durch die Anbindung an verschiedene Werkzeuge wie lokale Engines, Websuche und Bilderzeugung eignet es sich sowohl für experimentelle als auch für praktische Anwendungen

Einführung in die wichtigsten Konzepte

Primitives

• Primitives sind die grundlegenden Bausteine; im Zentrum steht das Symbol-Objekt

• Das Symbol-Objekt unterstützt sowohl den syntaktischen als auch den semantischen Modus

  • syntaktisch: verhält sich wie ein normaler Python-Wert und ermöglicht sichere, schnelle Operationen wie Vergleiche und Berechnungen
  • semantisch: ist mit einer neuro-symbolischen Engine verbunden, versteht Bedeutung und Kontext und erlaubt flexible semantische Vergleiche und Manipulationen

• Der syntaktische Modus ist standardmäßig aktiv; nur wenn eine Engine-Ausführung nötig ist, kann auf semantische Verarbeitung umgeschaltet werden

Wechsel zwischen semantischem und syntaktischem Modus

• Beim Erzeugen die Option semantic=True angeben
• Freier Wechsel über die Attribute .sem (semantic) und .syn (syntactic)
• Automatische Umwandlung in den semantischen Modus bei Aufrufen semantischer Funktionen (map usw.)

Beispiele für Operationen

• == : syntaktisch bedeutet Literalvergleich, semantisch semantische Gleichwertigkeit (z. B. 'Hi' == 'Hello' ergibt True)
• +, &, .startswith(), .choice(), .foreach(), .cluster(), .similarity() usw.
• Komplexe bedeutungsbasierte Manipulationen und logisches Chaining sind möglich

Contracts

• Einführung des Prinzips Design by Contract, um die Unsicherheit von LLMs zu kompensieren
• Datenmodelle und Validierungsregeln werden per Decorator festgelegt
• Für fehlerhafte Ein- und Ausgaben werden verschiedene Stabilitätsfunktionen unterstützt, darunter automatische Fehlerkorrektur, Wiederholungsversuche und Historienakkumulation
• Kompatibilität mit Pydantic-Datenmodellen sowie integrierte Feldvalidierung, automatische Prompt-Erzeugung und Fehlerbehandlung

Wichtige Merkmale der Contract-Funktion

• pre_remedy/post_remedy: automatische Korrektur von Ein-/Ausgabefehlern
• accumulate_errors: Übergabe der Fehlerhistorie
• remedy_retry_params: Angabe von Steuerparametern für Wiederholungsversuche (Anzahl der Versuche, Verzögerung, Backoff usw.)

Detaillierte Beispiele und weitere Erklärungen finden sich in der offiziellen Dokumentation und auf der DeepWiki-Seite

Externe Engines und funktionale Erweiterbarkeit

• Derzeit werden verschiedene neuro-symbolische Engines wie OpenAI, Anthropic usw. unterstützt (API/lokal)
• Eigene Engines wie {huggingface, llama.cpp} können lokal betrieben werden
• Zusätzliche Engines für Sprache, Bilder und Websuche können angebunden werden (separate Abhängigkeitspakete erforderlich)
• Praxisnahe ML-/AI-Funktionen wie Suche, Clustering, OCR und Indexierung werden integriert bereitgestellt

Konfigurationsmanagementsystem

Prioritätsbasierte Verwaltung von Konfigurationsdateien

• Debug-Modus (Projektordner): für Entwicklung und Tests

• Python-umgebungsspezifische Einstellungen ({python_env}/.symai/)

• Globale Einstellungen (~/.symai/): für Standard- und Backup-Zwecke

• Aus diesen drei Speicherorten werden Einträge mit höherer Priorität automatisch angewendet

Wichtige Konfigurationsdateien

• symai.config.json: Verwaltung zentraler SymbolicAI-Optionen
• symsh.config.json, symserver.config.json: Konfigurationen für Shell und Server

Beispiel für Konfigurationsdateien

• Explizite Angabe von API Key, Modellname, Engine-Typ usw.
• Einwilligung zur Datenerfassung über die Option SUPPORT_COMMUNITY (für Forschung und Qualitätsverbesserung)
• Benutzerwarnungen können über die Umgebungsvariable SYMAI_WARNINGS ein- und ausgeschaltet werden

Umgebungssetup und Tests

• Externe Pakete wie ffmpeg (Audio) und chromedriver (Webcrawler) werden benötigt
• Tests lassen sich mit pytest ausführen; Unterstützung zur Überprüfung der Coverage ist vorhanden

Referenzmaterialien und Nutzungshinweise

• DeepWiki und das offizielle GitBook bieten umfangreiche Referenzmaterialien und Video-Tutorials
• Ein auf Arxiv veröffentlichtes Paper erläutert Theorie und Framework im Detail
• Lizenz: BSD-3-Clause

Fazit

• SymbolicAI kombiniert die Klarheit symbolischer Systeme mit der Flexibilität neuronaler Netze und ist damit ein sehr geeignetes Framework für zuverlässigkeitsorientierte LLM-basierte Services und experimentelle Forschung
• Das auf Konfiguration, Erweiterbarkeit und Zuverlässigkeit ausgerichtete Design eröffnet Startups und IT-Praktikern vielfältige Anwendungsmöglichkeiten

Unterstützung für Entwickler und Community

• Ressourcen für Contributions sowie Kontakt- und Support-Kanäle (E-Mail, Website, Discord) werden aktiv offengelegt

[GN⁺]

Hacker-News-Kommentare

• Diese Art von Voodoo-Magie ist wirklich faszinierend.
  Ein Beispiel, das ich spannend fand, war die Verwendung von semantischem map lambda:
  Wenn man zum Beispiel eine Symbol-Liste S hat und S.map('alle Früchte in Gemüse umwandeln') aufruft, werden nur die Früchte zu Gemüse geändert und alles andere bleibt unverändert.
  Man kann je nach Kontext auch Parameter annehmen und Vergleiche durchführen. Zum Beispiel lässt sich im Kontext von Begrüßungen beurteilen, ob „Hello, good morning!“ und „Hi there, good day!“ dieselbe Bedeutung haben, oder man kann anhand des Höflichkeitsgrads „Good morning, sir.“ und „Hey, what’s up?“ vergleichen.
  Außerdem scheinen semantisch logische Verknüpfungen ähnlich wie mit Bit-Operatoren möglich zu sein. Man kann Regeln und Beobachtungen stichpunktartig mit & kombinieren und daraus Schlussfolgerungen ableiten.
  Die Funktion interpret() wirkt sehr leistungsfähig.
  Mich würde beim OP interessieren, was dieses Projekt inspiriert hat, in welchen Bereichen es tatsächlich eingesetzt wurde und was sein Lieblings-Anwendungsfall ist.

  • Ich empfehle Lotus, eine Python-DataFrame-Bibliothek.
    Damit kann man alle wichtigen relationalen Operatoren leicht semantisch erweitern und verwenden.
    Jeder Aufruf wird zu einem „Modell“-Punkt, wodurch spätere Erweiterungen in Richtung Machine Learning ebenfalls einfacher werden.
    Selbst Cloud-SQL wie Snowflake scheint sich allmählich in diese Richtung zu bewegen.
    Bei louie.ai haben wir ein ähnliches System umgesetzt. Über ein AI-Notebook, Dashboard und eine API lassen sich Daten (Splunk, Databricks, Graph-DBs usw.) dialogorientiert bearbeiten, und symbolische + semantische Operatoren werden kontextbasiert automatisch erkannt.
    Das hilft im praktischen Einsatz wirklich sehr.
    Mein wichtigster Use Case ist:
    Mit semantischem map Warnungen aus einem Splunk-Index holen, verdächtige markieren und auch eine Beschreibung hinzufügen,
    und das dann mit semantischem reduce zusammenfassen, um am Ende sogar einen Report in natürlicher Sprache zu erzeugen.

  • Die Frage, warum ausgerechnet eine Karotte das Ergebnis der Gemüse-Umwandlung eines Apfels ist.

  • Das wäre eine sehr lange Antwort.
    Das Projekt begann Ende 2022, aber in letzter Zeit sind vor allem die Modelle besser geworden; grundlegende Teile gab es schon zu GPT-3-Zeiten.
    Das kürzlich aufgekommene DbC (Design by Contract) ist wirklich einzigartig.
    Es löst alle Probleme, die ich mit Agenten erlebt habe. Besonders wenn man mehrere Contracts in einer Kette verbindet, werden Guardrails natürlich weitergereicht, was sehr effektiv ist.
    Fast alle Custom-Tools habe ich selbst implementiert.
    OpenAIs Websuche ist zum Beispiel gut, aber zu wenig anpassbar, deshalb habe ich meinen eigenen Deep-Research-Agent entwickelt und im Einsatz.
    Thread mit Ergebnissen vom ersten Tag
    Ich betreibe ein Unternehmen und habe durch die Verkettung von drei Contracts auch eine End-to-End-Automatisierung für die Dokumentenerstellung aufgebaut.
    Siehe Demo-PDF.
    Der Eingabe-Prompt lautet:
    „Erstelle einen Report, der Muster in Dateien, verschiedene Prompt-Formate (XML, Markdown usw.), Tendenzen zum Schmeicheln, die Art der Tool-Nutzung, ethische Guardrails, architektonische Besonderheiten und mehr insgesamt vergleicht.“
    Contracts habe ich im März 2025 in diesem Beitrag vorgestellt; seitdem hat es sich stark weiterentwickelt, aber die Grundidee und Motivation sind gleich geblieben.

• Die Möglichkeit, semantische Operatoren wie == oder + zu verwenden, fühlt sich an wie Dünger für frische Ideen.
  Das ist ähnlich aufregend wie damals in der Frühzeit der Word Embeddings, als ich zum ersten Mal Konzept-Algebra wie „King - Man + Woman = Queen“ gesehen habe.
  Allerdings ist die Integration von neuronalen und symbolischen (logischen) Systemen hier wie bei den meisten Systemen noch eher flach oder getrennt.
  Referenz
  Die echte Innovation wird wohl erst möglich, wenn künftig eine viel grundlegendere Integration erreicht wird.
  Auch wir in unserem Unternehmen (Onton) forschen in diese Richtung.
  Unser Ziel ist 1) eine vollständig integrierte Repräsentation (weder rein symbolisch noch rein Deep Learning), 2) kontinuierliches Lernen auch mit wenig verrauschten Daten (ohne Vergessen), 3) 100%ige Zuverlässigkeit bei Mathematik-/Symboloperationen, 4) null Halluzinationen.
  Im Moment ist dieses Heißkleber-Zusammenfügen vieler Systeme zwar nützlich, aber eine integrierte Architektur wird das Feld wahrscheinlich umkrempeln.

• Hier sind das offizielle Code-Notebook mit guten Erklärungen und Beispielen sowie das offizielle Paper als PDF.

• Meldung eines Fehlers im Code (valid_sizes ist in den „correctness contracts“ nicht definiert)

  • Danke für das Feedback. Das war ein Überbleibsel aus dem Refactoring-Prozess. Ist jetzt behoben.

• Danke an alle, die zu diesem Thema ihre Meinung geteilt und Unterstützung gezeigt haben.
  Mit so einer Reaktion hatte ich nicht gerechnet, und man kann mich jederzeit per Mail oder Tweet erreichen.
  Es war wirklich schön, mit euch allen zu sprechen.

• Ich habe allerdings einen Einwand.
  Der Begriff „Symbolic AI“ selbst ist bereits klar definiert.

  • Diese Meinung habe ich oft genug gehört.
    Vielleicht benenne ich es bald um.
    Im Paper habe ich auch in einer Fußnote erklärt, warum ich diesen Namen gewählt habe, und die Benennung ist als Zeichen des Respekts gegenüber Newell und Simon gedacht, die diese Grundlagenforschung geprägt haben.

• Ich habe eine Frage.
  Wie sieht das Kostenmodell aus?
  Ist es so aufgebaut, dass bei jeder ausgeführten Zeile mit natürlicher Sprachoperation – erst recht bei Nutzung externer APIs – fortlaufend Kosten für LLM-Inferenz anfallen?
  Zum Beispiel auch dann, wenn eine „symbolic“-Funktion in einer Schleife wiederholt aufgerufen wird?

  • Ja.
    Wenn man zum Beispiel die OpenAI-API nutzt, entsteht bei jeder semantischen Operation ein OpenAI-Aufruf und damit ein Kostenpunkt.
    Wenn man ein lokales LLM selbst hostet, etwa mit llama.cpp, fallen nur die Hosting-Kosten an und keine separaten Inferenzkosten.

  • Dann braucht man auf jeden Fall so etwas wie Caching.

• Ich hatte damit nicht gerechnet, aber plötzlich ist das Ganze sehr populär geworden, was mich etwas überrascht.
  Eigentlich hätte ich schlafen sollen, aber ich mache mit meiner aktuellen Schlafmangel-Erfahrung weiter in der Diskussion mit.

• Wie in der funktionalen Programmierung (FP) verhält sich jedes Symbol wie ein reiner Wert.
  Die Operationen werden zu einem sauberen, nachvollziehbaren Flow zusammengesetzt.
  In mehrdeutigen Schritten greift das Modell ein.
  Wie IO-Operationen in FP werden Aufrufe generativer Modelle als bereichsgebundene Seiteneffekte behandelt.
  Normalerweise ist der Reasoning-Graph deterministisch und delegiert nur bei Bedarf an das Modell.
  Die Demo ist wirklich erstaunlich.

  • Fast richtig.
    Es wurde von Anfang an funktional entworfen.
    Auch auf Low-Level-Ebene folgt alles funktionalen Prinzipien, und intern heißen Dinge ebenfalls functional.py oder core.py.
    Außerdem werden überall Decorators verwendet, was bei Refactoring, Erweiterung und Bug-Management sehr hilft.

• Heutzutage erzeugen LLMs ja oft schon den kompletten Code.
  Mich würde interessieren, welchen Vorteil eine Struktur hat, die Kontext wie Symbol enthält und sich mit Python-Operatoren leicht manipulieren lässt, verglichen damit, wenn Menschen den Code Zeile für Zeile selbst prüfen und schreiben.
  Man könnte semantische Transformationen doch auch direkt mit so einer Syntax ausdrücken, aber genauso gut einfach ein LLM bitten, ein Programm zu schreiben, das eine Liste von Früchten in Gemüse umwandelt.
  Ist das nicht im Grunde dasselbe? Ich würde gern den wesentlichen Unterschied verstehen.

  • Ich denke, das hilft dabei, Halluzinationen zu vermeiden.
    Wenn man ein LLM ein formales System erzeugen lässt, ist das viel leichter zu verifizieren als ein allgemeines System.