SymbolicAI: una perspectiva neuro-simbólica sobre los LLM

• SymbolicAI es un framework de programación neuro-simbólica que combina de forma natural la programación en Python con los LLM
• A través del objeto Symbol como unidad básica, admite tanto manipulaciones sintácticas como semánticas
• La función de Contratos (Contracts) aplica validación de datos y lógica de autocorrección a las predicciones del LLM para garantizar confiabilidad y robustez
• Permite integrarse con diversos motores externos (OpenAI, Anthropic, huggingface, etc.), búsqueda web, generación de imágenes y procesamiento de voz
• Se distingue por un sistema de gestión de configuración basado en prioridades y potentes funciones de personalización

---

SymbolicAI: visión general del proyecto y su importancia

• SymbolicAI es una librería neuro-simbólica que facilita de manera natural la combinación entre la programación clásica en Python y LLM programables y diferenciados (modelos de lenguaje de gran tamaño)
• Gracias a su diseño modular, permite extender, cambiar motores e integrar herramientas con facilidad
• Se integra con herramientas como motores locales, búsqueda web y generación de imágenes, por lo que resulta adecuada tanto para usos experimentales como prácticos

Introducción a los conceptos principales

Primitives

• Primitives son las unidades básicas de construcción, y el núcleo es el objeto Symbol

• El objeto Symbol admite tanto el modo sintáctico como el semántico

  • Sintáctico: funciona como un valor normal de Python y permite implementar operaciones seguras y rápidas, como comparaciones y cálculos
  • Semántico: se conecta con el motor neuro-simbólico para comprender significado y contexto, lo que permite comparaciones y manipulaciones semánticas flexibles

• El modo sintáctico es el predeterminado, y solo cambia al procesamiento semántico cuando se requiere la operación del motor

Cómo cambiar entre modo semántico y sintáctico

• Especificar la opción semantic=True al crear el objeto
• Cambiar libremente con las propiedades .sem (semantic) y .syn (syntactic)
• Conversión automática al modo semántico al llamar funciones semánticas (map, etc.)

Ejemplos de operaciones

• ==: en modo sintáctico compara literales; en modo semántico evalúa equivalencia semántica (ej.: 'Hi' == 'Hello' True)
• +, &, .startswith(), .choice(), .foreach(), .cluster(), .similarity(), etc.
• Permite manipulaciones complejas basadas en significado y encadenamiento lógico

Contracts

• Introduce el principio de Design by Contract para compensar la incertidumbre de los LLM
• Los modelos de datos y reglas de validación se especifican mediante decoradores
• Para entradas/salidas incorrectas, ofrece varias funciones de estabilidad, como autocorrección de errores, reintentos automáticos y acumulación de historial
• Incluye compatibilidad con modelos de datos de Pydantic, validación de campos, generación automática de prompts y manejo de errores

Características principales de la función de Contratos (Contract)

• pre_remedy/post_remedy: corrección automática de errores de entrada/salida
• accumulate_errors: incorpora el historial de errores
• remedy_retry_params: permite especificar parámetros de control de reintentos (número de intentos, retraso, backoff, etc.)

Para ejemplos detallados y explicaciones adicionales, se puede consultar la documentación oficial y la página de DeepWiki

Motores externos y capacidad de expansión funcional

• Actualmente admite varios motores neuro-simbólicos como OpenAI y Anthropic (API/local)
• Permite ejecutar motores propios en local, como {huggingface, llama.cpp}
• También puede integrarse con motores adicionales para voz, imágenes y búsqueda web (requiere instalar paquetes de dependencias por separado)
• Ofrece de forma integrada funciones prácticas de ML/AI como búsqueda, clustering, OCR e indexación

Sistema de gestión de configuración

Gestión de archivos de configuración basada en prioridades

• Modo debug (carpeta del proyecto): para desarrollo y pruebas

• Configuración por entorno de Python ({python_env}/.symai/)

• Configuración global (~/.symai/): para valores predeterminados/respaldo

• Aplica automáticamente la configuración de mayor prioridad entre estas tres ubicaciones

Archivos de configuración principales

• symai.config.json: gestiona las opciones principales de SymbolicAI
• symsh.config.json, symserver.config.json: configuraciones para shell y servidor

Ejemplo de archivos de configuración

• Permiten especificar explícitamente API Key, nombre del modelo, tipo de motor, etc.
• Opción SUPPORT_COMMUNITY para consentir la recolección de datos (con fines de investigación y mejora de calidad)
• Las advertencias al usuario pueden activarse/desactivarse mediante la variable de entorno SYMAI_WARNINGS

Configuración del entorno y pruebas

• Se requieren paquetes externos como ffmpeg (voz) y chromedriver (rastreador web)
• Las pruebas se ejecutan con pytest, con soporte para verificar cobertura

Material de referencia y guía de uso

• DeepWiki y el GitBook oficial ofrecen abundante material de referencia y videotutoriales
• En el paper publicado en Arxiv se explican en detalle la teoría y el framework
• Se distribuye bajo licencia BSD-3-Clause

Conclusión

• SymbolicAI es un framework muy adecuado para servicios centrados en la confiabilidad y para investigación experimental basada en LLM, al combinar la claridad de los sistemas simbólicos con la flexibilidad de las redes neuronales
• Su diseño, enfocado en configuración, escalabilidad y confiabilidad, ofrece múltiples posibilidades de aplicación para startups y profesionales de IT

Soporte para desarrolladores y comunidad

• Publica activamente recursos de contribución, contactos y canales de soporte (correo electrónico, sitio web, Discord)

[GN⁺]

Comentarios de Hacker News

• Este tipo de magia vudú de verdad me parece fascinante.
  Un ejemplo que me gustó mucho fue usar un map lambda semántico;
  por ejemplo, si tienes una lista de símbolos S, al llamar S.map('convierte todas las frutas en verduras'), solo las frutas se cambian por verduras y lo demás se mantiene igual.
  También se pueden recibir parámetros según el contexto para comparar. Por ejemplo, dentro del contexto de un saludo, determinar si 'Hello, good morning!' y 'Hi there, good day!' significan lo mismo, o comparar 'Good morning, sir.' y 'Hey, what’s up?' por nivel de cortesía.
  Además, parece posible hacer combinaciones lógicas semánticas como si fueran operadores de bits. Como bullets, combinar reglas y observaciones con & para sacar una conclusión.
  La función interpret() se ve poderosa.
  Me da curiosidad saber qué inspiró al OP para este proyecto, en qué áreas lo ha aplicado realmente y cuál es su caso de uso favorito.

  • Recomiendo Lotus, una librería de dataframes en Python.
    Permite extender semánticamente con mucha facilidad todos los operadores relacionales principales.
    Cada llamada se convierte en un punto de “modelo”, así que luego también es fácil ampliarlo hacia machine learning.
    Siento que incluso SQL en la nube, como Snowflake, va cada vez más en esta dirección.
    En louie.ai implementamos un sistema parecido. A través de un AI notebook, dashboard y API, manejamos datos de forma conversacional (Splunk, Databricks, graph DB, etc.) y detectamos automáticamente operadores simbólicos + semánticos según el contexto.
    En el trabajo ayuda muchísimo.
    Mis principales casos de uso son:
    usar semantic map para traer alertas desde índices de Splunk, marcar las sospechosas y agregar una descripción,
    y luego resumir todo eso con semantic reduce para incluso generar un reporte en lenguaje natural.

  • Pregunta sobre por qué una zanahoria sería el resultado de convertir una manzana en verdura.

  • Responder eso daría para algo muy largo.
    El proyecto empezó a finales de 2022, pero últimamente lo que ha mejorado son los modelos; las bases ya existían desde la época de GPT-3.
    Lo realmente único que apareció hace poco es DbC (Design by Contract).
    Me resolvió todos los problemas que había tenido con agentes. En especial, cuando encadenas varios contracts, los guardrails se propagan de forma natural y eso resulta muy efectivo.
    Casi todas las herramientas personalizadas las implementé yo mismo.
    Por ejemplo, la web search de OpenAI está bien, pero como no permite mucha personalización, desarrollé y uso mi propio deep research agent.
    Hilo con un ejemplo de resultados del primer día
    Estoy operando una empresa y también construí una automatización e2e para generación de documentos conectando 3 contracts.
    Ver demo en PDF.
    El prompt de entrada pide
    “analizar patrones en archivos, comparar en general distintos formatos de prompt (XML, markdown, etc.), tendencias a la adulación, forma de uso de herramientas, guardrails éticos, particularidades arquitectónicas y generar un reporte”.
    Presenté los contracts en esta publicación de marzo de 2025, y aunque desde entonces han evolucionado mucho, la idea base y la motivación siguen siendo las mismas.

• Poder usar operadores semánticos como == o + se siente como echarle fertilizante a ideas nuevas.
  Me dio una emoción parecida a cuando conocí por primera vez el álgebra conceptual en los inicios de los word embeddings, con cosas como ‘King - Man + Woman = Queen’.
  Aun así, aquí la integración entre redes neuronales y símbolos (logic), como en la mayoría de los sistemas, sigue siendo superficial o está separada.
  Referencia
  La verdadera innovación llegará cuando haya una integración mucho más fundamental.
  En nuestra empresa, Onton, también investigamos hacia eso.
  El objetivo es: 1) una representación completamente integrada (ni simbólica ni deep learning), 2) aprendizaje continuo incluso con pocos datos ruidosos (sin olvido), 3) confiabilidad del 100% en matemáticas y operaciones simbólicas, 4) cero alucinaciones.
  Por ahora pegar varios sistemas con hot glue sí es útil, pero creo que una arquitectura integrada va a cambiar por completo el panorama.

• Comparto enlaces al notebook oficial de código, que tiene buenas explicaciones y ejemplos, y al PDF oficial del paper.

• Reporte de error en el código (valid_sizes no está definido en ‘correctness contracts’).

  • Gracias por el feedback. Era un resto del proceso de refactorización. Ya quedó corregido.

• Gracias a todos los que dieron su opinión sobre este tema y mostraron apoyo.
  No esperaba esta reacción, y en cualquier momento pueden contactarme por correo o por Twitter.
  De verdad fue un gusto conversar con ustedes.

• Hay algo que me deja inconforme.
  El término ‘Symbolic AI’ como tal ya está claramente definido.

  • He escuchado bastante esa opinión.
    Puede que pronto le cambie el nombre.
    En el paper también puse en una nota al pie por qué lo llamé así, y nombré el proyecto como una muestra de respeto hacia Newell y Simon, quienes lideraron la investigación fundacional.

• Tengo una duda.
  ¿Cómo funciona la política de costos?
  ¿La estructura es tal que cada vez que se ejecuta una línea con operaciones en lenguaje natural —más aún si usa una API externa— se paga continuamente el costo de inferencia del LLM?
  Por ejemplo, ¿también pasaría si una función “symbolic” se llama repetidamente dentro de un bucle?

  • Sí.
    Por ejemplo, si usas la API de OpenAI, cada operación semántica hace una llamada a OpenAI y genera un costo.
    Si alojas tú mismo un LLM local con llama.cpp, solo pagas el costo de hosting y no hay un costo de inferencia aparte.

  • Definitivamente va a necesitar algo como caché.

• No me lo esperaba, pero de repente esto se volvió muy popular, así que estoy un poco sorprendido.
  Se suponía que debía estar durmiendo, pero ahora sigo participando en la conversación aprovechando mi experiencia acumulada de falta de sueño.

• Como en programación funcional (FP), cada Symbol funciona como un valor puro.
  Las operaciones se componen en un flujo limpio y trazable.
  En las partes ambiguas interviene el modelo.
  Igual que las operaciones de IO en FP, las llamadas al modelo generativo se tratan como efectos secundarios acotados.
  Normalmente el grafo de razonamiento es determinista y solo delega al modelo cuando hace falta.
  La demo está realmente impresionante.

  • Casi exacto.
    Desde el principio lo diseñé de forma funcional.
    Incluso a bajo nivel todo sigue principios funcionales, y por dentro también se llama functional.py o core.py.
    Además usamos decoradores por todas partes, lo cual ayuda mucho con refactorización, expansión y manejo de bugs.

• Hoy en día los LLM incluso pueden escribir todo el código,
  así que me pregunto qué ventaja tiene una estructura como Symbol, que encapsula contexto y se manipula fácilmente con operadores de Python,
  frente a escribir código revisándolo todo manualmente.
  Por ejemplo, una transformación semántica así podría implementarse directamente con esa sintaxis, pero también podrías simplemente pedirle a un LLM que te genere un programa que convierta una lista de frutas en verduras.
  Quiero entender cuál es la diferencia esencial.

  • Creo que ayuda a prevenir alucinaciones.
    Si haces que el LLM genere un sistema formal, verificarlo es mucho más fácil que validar un sistema de propósito general.