SymbolicAI : une perspective neuro-symbolique sur les LLM

• SymbolicAI est un framework de programmation neuro-symbolique qui combine naturellement la programmation Python et les LLM
• Grâce à l’objet Symbol, son unité de base, il prend en charge à la fois les manipulations syntaxiques et sémantiques
• La fonctionnalité Contracts applique une validation des données et une logique de correction automatique aux prédictions des LLM afin d’assurer fiabilité et robustesse
• Il peut fonctionner avec divers moteurs externes (OpenAI, Anthropic, huggingface, etc.), la recherche web, la génération d’images et le traitement de la voix
• Il se distingue par un système de gestion de configuration fondé sur des priorités et de puissantes possibilités de personnalisation

---

SymbolicAI : aperçu du projet et importance

• SymbolicAI est une bibliothèque neuro-symbolique (Neuro-Symbolic) qui permet de combiner naturellement la programmation Python classique avec des LLM (grands modèles de langage) différenciés et programmables
• Sa conception modulaire permet facilement l’extension, le remplacement de moteur et l’intégration d’outils
• Connecté à divers outils comme des moteurs locaux, la recherche web ou la génération d’images, il convient aussi bien à des usages expérimentaux que pratiques

Présentation des concepts clés

Primitives

• Les Primitives sont les unités de base, dont l’élément central est l’objet Symbol

• L’objet Symbol prend en charge à la fois les modes syntaxique et sémantique

  • syntaxique : il se comporte comme une valeur Python classique et permet des opérations sûres et rapides comme les comparaisons ou les calculs
  • sémantique : il se connecte au moteur neuro-symbolique pour comprendre le sens et le contexte, et permet des comparaisons/manipulations sémantiques flexibles

• Le mode syntaxique est activé par défaut, et il est possible de basculer vers un traitement sémantique uniquement lorsque le fonctionnement du moteur est nécessaire

Comment basculer entre les modes sémantique/syntaxique

• Spécifier l’option semantic=True lors de la création
• Basculer librement via les attributs .sem (semantic) et .syn (syntactic)
• Conversion automatique en mode sémantique lors de l’appel de fonctions sémantiques (map, etc.)

Exemples d’opérations

• == : en syntaxique, comparaison littérale ; en sémantique, équivalence sémantique (ex. : 'Hi' == 'Hello' donne True)
• +, &, .startswith(), .choice(), .foreach(), .cluster(), .similarity(), etc.
• Il permet des manipulations complexes fondées sur le sens et un enchaînement logique

Contracts

• Adoption du principe Design by Contract pour compenser l’incertitude des LLM
• Les modèles de données et règles de validation sont définis via des décorateurs
• Pour les entrées/sorties incorrectes, il prend en charge diverses fonctions de stabilité comme la correction automatique des erreurs, les nouvelles tentatives et l’accumulation de l’historique
• Compatibilité intégrée avec les modèles de données Pydantic et la validation de champs, génération automatique de prompts, gestion des erreurs, etc.

Principales caractéristiques de la fonctionnalité Contracts

• pre_remedy/post_remedy : correction automatique des erreurs d’entrée/sortie
• accumulate_errors : injection de l’historique des erreurs
• remedy_retry_params : définition des paramètres de nouvelle tentative (nombre d’essais, délai, backoff, etc.)

Des exemples détaillés et des explications complémentaires sont disponibles dans la documentation officielle et sur la page DeepWiki

Moteurs externes et extensibilité fonctionnelle

• Prend actuellement en charge divers moteurs neuro-symboliques comme OpenAI et Anthropic (API/local)
• Exécution locale possible de moteurs propres comme {huggingface, llama.cpp}
• Intégration possible de moteurs supplémentaires pour la voix, l’image, la recherche web, etc. (installation de paquets de dépendances séparés requise)
• Fournit de façon intégrée des fonctions ML/IA concrètes comme la recherche, le clustering, l’OCR et l’indexation

Système de gestion de la configuration

Gestion des fichiers de configuration basée sur les priorités

• Mode debug (dossier du projet) : pour le développement et les tests

• Paramètres par environnement Python ({python_env}/.symai/)

• Paramètres globaux (~/.symai/) : pour les valeurs par défaut / sauvegarde

• Les éléments de plus haute priorité sont appliqués automatiquement parmi ces trois emplacements

Principaux fichiers de configuration

• symai.config.json : gestion des principales options de SymbolicAI
• symsh.config.json, symserver.config.json : paramètres pour le shell et le serveur

Exemples de fichiers de configuration

• Spécification explicite de l’API Key, du nom du modèle, du type de moteur, etc.
• Option SUPPORT_COMMUNITY pour consentir à la collecte de données (à des fins de recherche et d’amélioration de la qualité)
• Les avertissements utilisateur peuvent être activés/désactivés via la variable d’environnement SYMAI_WARNINGS

Configuration de l’environnement et tests

• Des paquets externes comme ffmpeg (voix) et chromedriver (crawler web) sont requis
• Les tests peuvent être exécutés avec pytest, avec prise en charge de la vérification de couverture

Ressources de référence et guide d’utilisation

• DeepWiki et le GitBook officiel proposent de riches ressources de référence et des tutoriels vidéo
• Un article publié sur arXiv détaille la théorie et le framework
• Licence BSD-3-Clause

Conclusion

• SymbolicAI est un framework particulièrement adapté aux services axés sur la fiabilité et à la recherche expérimentale fondés sur les LLM, en combinant la clarté des systèmes symboliques et la flexibilité des réseaux neuronaux
• Grâce à une conception centrée sur la configuration, l’extensibilité et la fiabilité, il offre de nombreuses possibilités d’application aux startups et aux professionnels de l’IT

Support aux développeurs et à la communauté

• Ressources de contribution, coordonnées et canaux de support (e-mail, site web, Discord) largement mis à disposition

[GN⁺]

Commentaires Hacker News

• Ce genre de magie vaudou est vraiment fascinant.
  Un exemple que j’avais trouvé amusant, c’est l’usage sémantique de map lambda,
  par exemple, si S est une liste de Symbol, appeler S.map('convertir tous les fruits en légumes') transforme uniquement les fruits en légumes et laisse le reste inchangé.
  On peut aussi comparer en recevant des paramètres selon le contexte. Par exemple, déterminer si « Hello, good morning! » et « Hi there, good day! » ont le même sens dans le contexte d’une salutation, ou comparer « Good morning, sir. » et « Hey, what’s up? » selon le niveau de politesse.
  Il semble aussi possible de faire des combinaisons logiques sémantiques comme avec des opérateurs binaires. Fusionner des règles et des observations avec & pour en déduire une conclusion, par exemple.
  La fonction interpret() a l’air puissante.
  Je suis curieux de savoir ce qui a inspiré l’OP pour ce projet, dans quels domaines il l’a réellement appliqué, et quel est son cas d’usage préféré.

  • Je recommande Lotus, une bibliothèque dataframe Python.
    Elle permet d’étendre sémantiquement très facilement tous les opérateurs relationnels essentiels.
    Chaque appel devient un point « modèle », ce qui facilite ensuite les extensions côté machine learning.
    J’ai l’impression que le SQL cloud, comme Snowflake, évolue aussi progressivement dans cette direction.
    Nous avons implémenté un système similaire chez louie.ai. On y manipule les données de manière conversationnelle via un notebook IA, un dashboard et une API (Splunk, Databricks, graph db, etc.), et le système identifie automatiquement les opérateurs symbolic + semantic selon le contexte.
    C’est vraiment utile en production.
    Mes principaux use cases sont :
    récupérer des alertes depuis un index Splunk avec un semantic map pour ajouter des drapeaux aux éléments suspects ainsi qu’une description,
    puis résumer le tout avec un semantic reduce afin de produire jusqu’à un rapport en langage naturel.

  • Question : pourquoi une carotte est-elle le résultat de la transformation d’une pomme en légume ?

  • La réponse serait très longue.
    Le projet a commencé fin 2022, mais récemment, les modèles se sont simplement améliorés ; les bases existaient déjà à l’époque de GPT-3.
    Le DbC (Design by Contract), apparu récemment, est vraiment unique.
    Cela a résolu tous les problèmes que j’avais rencontrés avec les agents. En particulier, lorsqu’on enchaîne plusieurs contracts, les guardrails se propagent naturellement, ce qui est très efficace.
    J’ai implémenté presque tous les outils personnalisés moi-même.
    Par exemple, la web search d’OpenAI est bonne, mais pas assez personnalisable, donc j’ai développé et j’utilise mon propre deep research agent.
    Fil d’exemples des résultats du premier jour
    Je dirige une entreprise et j’ai aussi mis en place une automatisation de génération documentaire e2e en chaînant 3 contracts.
    Voir la démo PDF.
    Le prompt d’entrée demandait :
    « analyser les patterns dans les fichiers, comparer globalement divers formats de prompt (XML, markdown, etc.), les tendances à la flatterie, les façons d’utiliser les outils, les garde-fous éthiques, les particularités architecturales, etc., et générer un rapport »
    J’ai présenté les contracts en mars 2025 dans ce post, et ils ont beaucoup évolué depuis, mais l’intention de base et la motivation restent les mêmes.

• Le fait de pouvoir utiliser des opérateurs comme == ou + de manière sémantique donne l’impression de mettre de l’engrais sur des idées originales.
  J’ai ressenti la même excitation que lorsque j’ai découvert pour la première fois l’algèbre des concepts au début de l’ère des word embeddings, avec des exemples comme « King - Man + Woman = Queen ».
  Cela dit, ici, l’intégration entre réseau de neurones et symbolique (logique), comme dans la plupart des systèmes, reste encore superficielle ou cloisonnée.
  Référence
  La vraie innovation deviendra possible quand une intégration bien plus fondamentale aura lieu.
  Dans notre entreprise (Onton), nous faisons aussi de la recherche dans cette direction.
  L’objectif est : 1) une représentation totalement intégrée (ni symbolique ni deep learning), 2) un apprentissage continu avec peu de données bruitées (sans oubli), 3) une fiabilité de 100 % sur les opérations mathématiques et symboliques, 4) zéro hallucination.
  Pour l’instant, assembler plusieurs systèmes façon pistolet à colle est certes utile, mais je pense qu’une architecture intégrée va rebattre les cartes.

• Je partage les liens vers le notebook de code officiel, où les explications et les exemples sont bien présentés, ainsi que vers le PDF de l’article officiel.

• Signalement d’une erreur dans le code (valid_sizes n’est pas défini dans les « correctness contracts »).

  • Merci pour le retour. C’était un vestige laissé pendant le refactoring. C’est corrigé maintenant.

• Merci à tous ceux qui ont donné leur avis sur ce sujet et apporté leur soutien.
  Je ne m’attendais pas à ce genre de réaction, et vous pouvez me contacter à tout moment par mail ou sur X.
  C’était vraiment un plaisir d’échanger avec vous.

• Il y a quelque chose de regrettable.
  Le terme même de « Symbolic AI » est déjà clairement défini.

  • J’ai bien entendu cet avis.
    Je changerai peut-être bientôt le nom.
    J’ai aussi ajouté en note de bas de page dans l’article la raison de cette appellation, et j’ai nommé le projet en hommage à Newell et Simon, qui ont porté la recherche fondatrice dans ce domaine.

• J’ai une question.
  Comment fonctionne la politique de coût ?
  Est-ce qu’on paie en permanence le coût d’inférence du LLM à chaque exécution d’une ligne contenant une opération en langage naturel, surtout si elle utilise une API externe ?
  Par exemple, est-ce aussi le cas si une fonction « symbolic » est appelée en boucle ?

  • Oui.
    Par exemple, si vous utilisez l’API OpenAI, chaque opération sémantique entraîne un appel OpenAI, donc un coût.
    Si vous hébergez directement un LLM local avec llama.cpp, etc., vous n’avez que le coût d’hébergement, sans coût d’inférence séparé.

  • Il faudra forcément quelque chose comme un cache.

• Je ne m’y attendais pas, mais c’est soudain devenu très populaire, donc je suis un peu surpris.
  J’aurais dû être en train de dormir, mais je continue à participer à la discussion en capitalisant sur mon expérience actuelle du manque de sommeil.

• Comme en programmation fonctionnelle (FP), tous les Symbol se comportent comme des valeurs pures.
  Les opérations se composent en un flux propre et traçable.
  Le modèle intervient dans les étapes ambiguës.
  Comme les opérations d’IO en FP, les appels à un modèle génératif sont traités comme des effets de bord délimités.
  En temps normal, le graphe de reasoning est déterministe, et ce n’est que lorsque c’est nécessaire qu’on délègue au modèle.
  La démo est vraiment bluffante.

  • C’est presque ça.
    Le système a été conçu dès le départ de façon fonctionnelle.
    Même au niveau bas niveau, tout suit des principes fonctionnels, et en interne aussi cela s’appelle functional.py ou core.py.
    Les décorateurs sont également utilisés un peu partout, ce qui aide énormément pour le refactoring, l’extension et la gestion des bugs.

• Aujourd’hui, les LLM peuvent même générer tout le code, donc
  je me demande quel avantage apporte une structure comme Symbol, qui embarque le contexte et se manipule facilement avec les opérateurs Python,
  par rapport au fait d’écrire du code à la main en vérifiant chaque étape soi-même.
  Par exemple, on pourrait aussi écrire directement une transformation sémantique avec cette syntaxe, mais on pourrait tout aussi bien demander au LLM de générer un programme qui convertit une liste de fruits en légumes, non ?
  J’aimerais comprendre quelle est la différence fondamentale.

  • Je pense que cela aide à éviter les hallucinations.
    Si on fait générer au LLM un système formel, il est bien plus facile à vérifier qu’un système généraliste.