SymbolicAI: Eine neuro-symbolische Perspektive auf LLMs

 (github.com/ExtensityAI)
2 Punkte von GN⁺ 2025-06-29 | 1 Kommentare | Auf WhatsApp teilen
  • SymbolicAI ist ein neuro-symbolisches Framework, das klassische Python-Programmierung mit der differenzierbaren und programmierbaren Natur von LLMs verbindet und darauf abzielt, sich natürlich innerhalb von Python verwenden zu lassen
  • Zentrale Konzepte sind auf dem Symbol-Objekt basierende Primitives sowie Verträge (contracts), die LLM-Ergebnisse validieren und korrigieren; das Standardverhalten startet aus Sicherheits- und Geschwindigkeitsgründen im syntaktischen Modus
  • Symbol verhält sich im syntaktischen Modus wie ein normaler Python-Wert und verarbeitet im semantischen Modus Kontext und Bedeutung; der Wechsel ist über semantic=True, .sem oder semantische Funktionsaufrufe wie .map() möglich
  • Das Vertragssystem wendet die Prinzipien von Design by Contract auf LLM-Workflows an und behandelt Eingabevalidierung, Zustandsänderungen, LLM-Generierung, Ausgabevalidierung und Ersatzantworten bei Fehlern in einem einzigen dekoratorbasierten Ablauf
  • Die Installation beginnt mit pip install symbolicai; für die praktische Nutzung sind jedoch die Konfiguration mit symconfig und symai.config.json erforderlich, und die neuro-symbolische Engine ist für die Nutzung des symai-Pakets zwingend notwendig

Das Modell, auf das SymbolicAI abzielt

  • SymbolicAI ist ein neuro-symbolisches Framework, das gewöhnlichen Python-Code und LLM-basierte semantische Verarbeitung gemeinsam behandelt
  • Durch ein modulares Design lässt es sich je nach Bedarf erweitern und anpassen
  • Unterstützt werden die Integration eigener Engines, das Hosting lokaler Engines sowie Werkzeuge wie Websuche und Bildgenerierung
  • Der Projektname versteht sich als Würdigung der grundlegenden Arbeiten von Allen Newell und Herbert Simon

Das Symbol-Primitive

  • Im Zentrum von SymbolicAI steht das Symbol-Objekt, mit dem sich kleine kombinierbare Operationen wie native Python-Syntax verwenden lassen
  • Symbol kennt zwei Betriebsarten
    • Syntactic: verhält sich wie ein normaler Python-Wert wie ein übergebener String, eine Liste oder eine Ganzzahl
    • Semantic: ist mit der neuro-symbolischen Engine verbunden und verarbeitet Bedeutung und Kontext
  • Der Standardwert ist der syntaktische Modus
    • Python-Operatoren wie ==, ~ und & sind in symai überladen
    • Würde man bei jedem Vergleich oder Bitshift sofort die Engine aufrufen, wäre das langsam und könnte unerwartete Nebenwirkungen verursachen
    • Sicherheit und Geschwindigkeit bleiben erhalten, indem semantisches Verhalten nur an den nötigen Stellen aktiviert wird

So wechselt man in den semantischen Modus

  • Gibt man beim Erzeugen semantic=True an, arbeitet das Objekt von Beginn an als semantisches Symbol
    • Im Beispiel behandelt Symbol("Cats are adorable", semantic=True) "feline" in S als True
  • Bei Bedarf lässt sich über die .sem-Projektion in semantisches Verhalten wechseln und über .syn wieder in syntaktisches Verhalten zurückkehren
    • Derselbe Wert "Cats are adorable" ergibt in S.sem, dass "feline" in S.sem True ist, während es im Standard-S False ist
  • Operationen in Punktnotation wie .map() oder andere Aufrufe semantischer Funktionen schalten das Symbol automatisch in den semantischen Modus
    • Im Beispiel werden bei Anwendung von convert all fruits to vegetables auf eine Fruchtliste nur die Früchte in Gemüse umgewandelt, während cat und dog erhalten bleiben
  • Die Projektionen .sem und .syn legen unterschiedliche Verhaltensebenen über dasselbe zugrunde liegende Objekt, sodass sich syntaktische und semantische Operationen auf einem Symbol verketten lassen

Beispiele für bereitgestellte Operationen

  • SymbolicAI unterstützt verschiedene Primitives; die Dokumentation dazu findet sich unter primitives
  • == prüft im syntaktischen Modus auf wörtliche Übereinstimmung und behandelt im semantischen Modus unscharfe oder konzeptionelle Gleichwertigkeit wie zwischen "Hi" und "Hello"
  • + ist im syntaktischen Modus Zahlen-, String- oder Listenaddition und führt im semantischen Modus bedeutungsvolle Kombinationen, Mischungen oder konzeptionelle Zusammenführungen aus
  • & ist im syntaktischen Modus bitweises oder logisches AND und behandelt im semantischen Modus logische Verknüpfung, Schlussfolgerung und Kontextfusion
  • Zu den rein semantischen Funktionen gehören .choice(cases, default), .foreach(condition, apply), .cluster(**clustering_kwargs?) und .similarity(other, metric?, normalize?)
    • .cluster() gruppiert Daten semantisch und verwendet DBSCAN aus sklearn
    • .similarity() berechnet die Ähnlichkeit zwischen Embeddings

Wie Verträge mit LLM-Ausgaben umgehen

  • SymbolicAI wendet die Prinzipien von Design by Contract auf die Welt der LLMs an, ausgehend von der Einsicht, dass LLMs halluzinieren können, Code jedoch nicht
  • Verträge verlassen sich nicht nur auf nachgelagerte Tests, sondern bündeln Datenmodelle und Validierungsrestriktionen in Dekoratoren, um Korrektheit bereits auf Designebene zu behandeln
  • Der Vertragsdekorator im Beispielcode verwendet die folgenden Optionen
    • pre_remedy=True: versucht, ungültige Eingaben automatisch zu korrigieren
    • post_remedy=True: versucht, ungültige LLM-Ausgaben automatisch zu korrigieren
    • accumulate_errors=True: übergibt bei jedem Wiederholungsversuch den Fehlerverlauf
    • verbose=True: zeigt den Fortschritt im Terminal an
    • remedy_retry_params: verwendet tries=3, delay=0.4, max_delay=4.0, jitter=0.15, backoff=1.8, graceful=False
  • Der High-Level-Ablauf der mit Verträgen versehenen Expression-Klasse sieht wie folgt aus
    • prompt: eine statische Beschreibung der Aufgabe für das LLM und zwingend erforderlich
    • pre: prüft die Eingabe und ist optional
    • act: verändert den Zustand und ist optional
    • LLM: Die SymbolicAI-Engine erzeugt die erwartete Antwort
    • post: prüft, ob die Antwort die semantischen Regeln erfüllt, und ist optional
    • forward: zwingend erforderlich; gibt bei erfolgreichem Vertrag ein typvalidiertes LLM-Objekt zurück und bei Fehlschlag eine graceful fallback-Antwort
  • Dokumentation zu Verträgen findet sich unter DeepWiki der contract validation system und features/contracts

Installation und optionale Funktionen

  • Die Basisinstallation erfolgt per pip
pip install symbolicai
  • Alternativ kann man das Repository klonen und mit uv >= 0.9.17 eine Python-Virtual-Environment einrichten
git clone git@github.com:ExtensityAI/symbolicai.git
cd symbolicai
uv sync --python x.xx
source ./.venv/bin/activate
  • SymbolicAI verwendet mehrere Engines zur Verarbeitung von Text, Sprache und Bildern und umfasst auch den Zugriff auf Such-Engines für Webinformationen
  • Optionale Abhängigkeiten lassen sich als funktionsspezifische Extras installieren
    • bitsandbytes, hf, lean, llama_cpp, ocr, qdrant, scrape, search, serpapi, services, solver, whisper, wolframalpha
  • Alle optionalen Abhängigkeiten lassen sich auch auf einmal installieren
pip install "symbolicai[all]"
  • uv sync --frozen installiert die im bereitgestellten Lockfile fixierten Abhängigkeiten
  • Einige optionale Abhängigkeiten können zusätzliche Installationsschritte erfordern, und manche werden derzeit nur experimentell unterstützt und funktionieren möglicherweise nicht wie erwartet

Konfigurationsverwaltung und erforderliche Engine

  • SymbolicAI verwendet ein prioritätsbasiertes Konfigurationsverwaltungssystem
  • Konfigurationen werden aus drei Orten in Prioritätsreihenfolge geladen
    • Debug-Modus im aktuellen Arbeitsverzeichnis: höchste Priorität und gilt nur für symai.config.json
    • Umgebungsspezifische Konfiguration der Python-Umgebung: liegt unter {python_env}/.symai/ und eignet sich für projektspezifische Einstellungen
    • Globale Konfiguration im Home-Verzeichnis: liegt unter ~/.symai/ und dient als Standard-Fallback
  • Es gibt drei verwaltete Konfigurationsdateien
    • symai.config.json: Hauptkonfiguration von SymbolicAI
    • symsh.config.json: Shell-Konfiguration
    • symserver.config.json: Server-Konfiguration
  • symconfig zeigt Konfigurationsorte, den aktiven Konfigurationspfad und die aktuelle Konfiguration mit ausgeblendeten sensiblen Informationen an und startet das anfängliche Package-Caching sowie die Initialisierung der Konfigurationsdateien
  • Für die Nutzung des symai-Pakets ist eine neuro-symbolische Engine zwingend erforderlich
  • Gibt man Engine-Eigenschaften in der symai.config.json im Projektpfad an, ersetzen sie Umgebungsvariablen
    • Die Beispielkonfiguration enthält als Wert für NEUROSYMBOLIC_ENGINE_MODEL claude-sonnet-4-6, als Embedding-Modell text-embedding-3-small, als TTS-Modell tts-1, als OCR-Modell mistral-ocr-latest, als Indexing-Engine qdrant und weiteres
  • Benutzerwarnungen sind standardmäßig aktiviert und lassen sich über die Umgebungsvariable SYMAI_WARNINGS=0 deaktivieren

Tests, Dokumentation, Lizenz

  • Beispiele zum Ausführen von Tests:
pytest tests
pytest -m mandatory
pytest --cov=symbolicai tests
  • Vor dem Testen muss die Konfiguration korrekt eingerichtet sein
  • Als nächste Schritte können die SymbolicAI-DeepWiki-Seite, das Paper und die Video-Tutorials hilfreich sein
  • Die Zitierinformationen verweisen auf das arXiv-Preprint von 2024 mit dem Titel Symbolicai: A framework for logic-based approaches combining generative models and solvers
  • Die Projektlizenz ist die BSD-3-Clause License

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-06-29
Hacker-News-Kommentare

  • Diese Art von voodooartiger Funktionalität finde ich am spannendsten
    Wenn man zum Beispiel auf ['apple', 'banana', 'cherry', 'cat', 'dog'] ein semantisches map mit „ersetze alle Früchte durch Gemüse“ anwendet, kommt etwas wie ['carrot', 'broccoli', 'spinach', 'cat', 'dog'] heraus, und equals() liefert je nach Kontext unterschiedliche Vergleichsergebnisse, etwa bei context='greeting context' oder context='politeness level'
    Sogar Bit-Operatoren werden wie semantische logische Verknüpfungen verwendet, sodass horn_rule & observation zu einer Inferenz führt, daher wirkt interpret() ziemlich mächtig
    Mich würde interessieren, was der Auslöser für die Entwicklung war, wo es in der Praxis eingesetzt wird und welcher Anwendungsfall bisher am besten gefallen hat

    • Lotus könnte auch interessant sein: https://github.com/lotus-data/lotus
      Dort wurden zentrale relationale Operatoren als semantische Varianten umgesetzt, indem Python-Dataframe-Bibliotheken erweitert wurden, und jeder Aufruf wird zu einem „Modell“-Punkt für spätere, komplexere Aufgaben wie lernbasierte Ansätze
      Auch im Cloud-SQL-Bereich wie bei Snowflake scheint es in diese Richtung zu gehen, und bei louie.ai wurde mit AI-Notebooks/Dashboards/APIs (MCP usw.) ein ähnlicher Ansatz verwendet, bei dem man mit Daten in Splunk, Databricks oder Graph-DBs spricht und dann kontextabhängig symbolische + semantische Operatoren ermittelt; in der Praxis war das ziemlich nützlich
      Die wichtigsten 80-%-Anwendungsfälle bestehen darin, mit einem semantischen map ein angereichertes Dataframe zu erzeugen, etwa mit „Hole alle Warnmeldungen aus dem Splunk-Index xyz und füge eine Spalte hinzu, die verdächtige Einträge markiert, sowie eine Spalte, die den Grund erklärt“, und danach mit einem semantischen reduce wie „Fasse zusammen, was du gefunden hast“ eine natürlichsprachliche Erklärung zu erhalten
    • Ich frage mich, warum beim Umwandeln von apple in Gemüse ausgerechnet carrot herauskommt
    • Das wird wahrscheinlich eine sehr lange Antwort
      Seit dem Start des Projekts Ende 2022 hat sich nicht allzu viel grundlegend verändert; die Modelle sind nur besser geworden, und viele der primitiven Operationen gab es schon seit den GPT-3-Tagen
      Wichtiger in letzter Zeit war der DbC-Beitrag: Dass sich Verträge verketten lassen und Guardrails sich sauber fortpflanzen, ist ziemlich einzigartig und hat fast jedes Problem gelöst, das ich im Agentenbereich darauf geworfen habe
      Perplexity ist wegen der OpenAI-Websuche weniger nützlich geworden, und auch die OpenAI-Websuche reicht nicht an etwas heran, das man selbst direkt angepasst hat, deshalb habe ich einen eigenen Deep-Research-Agenten gebaut: https://x.com/futurisold/status/1931751644233945216
      Auch im Unternehmen habe ich drei Verträge verkettet, um eine End-to-End-Dokumenterstellung zu bauen; ein Beispiel für die Ausgabe gibt es hier: https://drive.google.com/file/d/1Va7ALq_N-fTYeumKhH4jSxsTrWD...
      Die Eingabe war die Aufforderung, die System-Prompts der wichtigsten AI-Anbieter vergleichend zu analysieren und Unterschiede bei Formaten wie XML/Markdown/JSON, bei sycophantischen oder manipulativen Anweisungen, Einschränkungen bei Tool-Nutzung, ethischen Guardrails und Alignment-Design herauszuarbeiten und als technischen Bericht zusammenzuführen; die generierten Anweisungen wurden dann zu konkreten Fragen erweitert, die Struktur und sprachliche Frameworks der System-Prompts sowie operative Einschränkungen von OpenAI, Google, Anthropic, xAI usw. vergleichen
      Die Verträge wurden im März-Beitrag vorgestellt und haben sich seitdem stark weiterentwickelt, aber die Grundlage und Motivation sind gleich geblieben: https://futurisold.github.io/2025-03-01-dbc/

  • Es würde dem Verständnis helfen, das Paper und das Beispiel-Notebook gemeinsam zu verlinken
    https://github.com/ExtensityAI/symbolicai/blob/main/examples...
    https://arxiv.org/pdf/2402.00854

  • Cool
    Wenn man Operatoren wie == oder + nicht syntaktisch, sondern als semantische Operatoren verwenden kann, könnte das ein Dünger für neue Ideen sein, ähnlich wie damals bei den ersten Wort-Embeddings, als diese lockere Form konzeptueller Algebra wie „King - Man + Woman = Queen“ aufkam
    Allerdings wirkt die Integration von neuronalen Netzen und Symbolik hier, wie bei den meisten Systemen, ziemlich flach und durch Firewalls getrennt und fällt klassifikatorisch eher in Type 3 / Neuro;Symbolic: https://harshakokel.com/posts/neurosymbolic-systems
    Die echte Magie wird wohl erst bei einer grundlegenderen Integration entstehen, und auch wir in unserem Unternehmen (https://onton.com) denken über Systeme nach dem LLM nach, die eine integrierte Repräsentation besitzen, die weder rein symbolisch noch eine dichte Gleitkommamatrix ist, die mit kleinen Mengen verrauschter Daten inkrementell lernen können, ohne catastrophic forgetting zu erleiden, die verlässliche mathematische und symbolische Operationen bieten und nicht halluzinieren
    Das Verkleben bestehender Systeme wie mit einer Heißklebepistole ist ebenfalls nützlich, aber eine integrierte Architektur wird wohl alles verändern

  • Im Teil zu den Genauigkeitsverträgen gibt es einen Bug
    Nach valid_opts = ['A', 'B', 'C'] kommt if v not in valid_sizes:, aber valid_sizes ist nicht definiert

    • Das war ein Überbleibsel vom Refactoring und ist inzwischen behoben

  • „Symbolic AI“ ist bereits ein gut definierter Begriff, daher finde ich das etwas schade: https://en.m.wikipedia.org/wiki/Symbolic_artificial_intellig...

    • Das verstehe ich
      Vielleicht ändern wir den Namen noch, und im Paper gibt es eine Fußnote zur Namenswahl
      Die Absicht war, damit die grundlegende Arbeit von Newell und Simon zu würdigen, die dieses Projekt inspiriert hat

  • Mich interessiert die Kostenstruktur.
    Fallen jedes Mal LLM-Inferenzkosten an, wenn eine Zeile mit Natural-Language-Berechnung ausgeführt wird, und wird bei Nutzung einer externen API wirklich bei jedem Aufruf abgerechnet?
    Zum Beispiel frage ich mich, was passiert, wenn man innerhalb einer Schleife eine „symbolic“-Funktion aufruft.

    • Ja.
      Wenn man zum Beispiel OpenAI nutzt, wird jede bedeutungsbasierte Operation zu einem OpenAI-API-Aufruf.
      Wenn man mit llama.cpp ein lokales LLM hostet, fallen außer den Modell-Hosting-Kosten keine zusätzlichen Inferenzgebühren an.
    • Dafür scheint in irgendeiner Form ein Cache nötig zu sein.

  • Da Code heutzutage oft von LLMs erzeugt wird, frage ich mich, welchen Vorteil eine spezielle syntaktische Struktur wie Symbol bringt, die Kontext trägt und sich mit Python-Operatoren manipulieren lässt, verglichen mit gewöhnlichem Python-Code, den Menschen schreiben, um Prüfungen und Nebenbedingungen anzuweisen.
    Man könnte zum Beispiel statt einer Syntax zu verwenden, die Obst in Gemüse umwandelt, auch einfach ein LLM per Prompt anweisen, ein Programm zu schreiben, das eine Liste von Obst entgegennimmt, intern das LLM aufruft und die entsprechenden Gemüse zurückgibt.
    Ich möchte den Unterschied verstehen.

    • Vermutlich geht es um Halluzinationsdämpfung.
      Wenn man das LLM ein formales System erzeugen lässt, ist es sehr viel leichter zu verifizieren als ein allgemeines Programm.

  • Mich würde interessieren, ob auch neuronale-symbolische KI in Betracht gezogen wurde, die sich weiterentwickeln kann.
    https://deepwiki.com/dubprime/mythral/3.2-genome-system
    Oder wie es mit einer Richtung aussieht, die Emotionen empfindet?
    https://deepwiki.com/search/how-do-emotives-work_193cb616-54...
    Mich würde auch interessieren, ob du Marvin Minskys Society of Mind gelesen hast.

    • Die kurze Antwort ist: ja, auf alles.
      Ich habe auch mit Experimenten gearbeitet, die von einer Theory of Mind zu Emotionen übergehen, aber im Moment habe ich das Gefühl, dass die Modelle dafür noch nicht weit genug sind, sodass der Ertrag im Verhältnis zum Aufwand sinkt und ich es deshalb gestoppt habe.
      Man könnte es leicht wieder aufgreifen, aber Minsky ist nicht mein Favorit; innerhalb dieser Generation zieht es mich eher zu Newell/Simon.
    • Wichtig ist trotzdem, ob es erklärbar ist oder eine magische Blackbox bleibt.

  • Ich habe ein wenig mit symbolischer Regression experimentiert, bei der ein LLM Dokumente prüft und rohe Operatoren erzeugt, die dann in PySR auf GitHub (github.com/MilesCranmer/PySR) aufgenommen werden, also im Grunde Operatoren erstellt.
    Ich bin nicht sehr weit gekommen, weil es schwierig war, alles miteinander zu verbinden, aber mit so einem Werkzeug könnte ich es noch einmal versuchen.

    • Das ist definitiv möglich.
      Ich würde empfehlen, Contracts zu verwenden.
      Ich habe einmal einen ähnlichen Ansatz mit Contracts verwendet, die iterativ einen kaputten Ontologie-Graphen „zusammenflicken“.
      Als möglicherweise inspirierendes Datenmodell gab es Strukturen wie Merge, Bridge, Prune und Operation, wobei jeweils die zu verschmelzenden Cluster-Indizes, Ober-/Unterklassen-Beziehungen und eine Liste der zu beschneidenden Klassen definiert wurden; anschließend erzwang ein Validator die Bedingungen für binäre bzw. unäre Operationen.
      Analog dazu könnte man ein Modell für Operatoren bauen, den Contract jeweils genau einen Operator lösen lassen und diesen Operator dann anwenden.