Live data from Hacker News

SymbolicAI: A neuro-symbolic perspective on LLMs

github.com

41–50 of 66 posts

Re: SymbolicAI: A neuro-symbolic perspective on LLMs

#41

Since code is generated by LLM these days, how does specific syntactic constructs like a Symbol which essentially carries the context and can be manipulated with python operators help when compared to a normal python code generated by LLM with all the checks and balances instructed by a human? For example, I can write in this syntax to convert all fruits to vegetables or I can simply prompt an LLM to construct a prog…

Hallucination obstruction, I'd imagine. When you have an LLM create a formal system, it can be verified way easier than a general purpose one

Yes. That seems to be the case. While it may not be saving any time compared to generating general python code vs. specific symbolic code, the real value could be that it has an engine to enforce the contract on LLM responses with the library or even do the calls to the LLM as a common piece of code making it less error prone and bringing consistency in the interactions with the LLM.

Re: SymbolicAI: A neuro-symbolic perspective on LLMs

#42
Very cool. Being able to use semantic (as opposed to syntactic) operators like `==`, `+`, etc. feels like fertilizer for some novel ideas. Sort of like when word embeddings first came out and there was a loose concept algebra introduced with it ("King - Man + Woman = Queen").

That said the neuro + symbolic integration here is, like most systems, pretty shallow/firewalled (taxonomically, Type 3 / Neuro;Symbolic — https://harshakokel.com/posts/neurosymbolic-systems). I think the real magic is going to come when we start heading toward a much more fundamental integration. We're actually working on this at my company (https://onton.com). How do we create a post-LLM system that: 1) features an integrated representation (neither purely symbolic nor dense floating point matrix); 2) can learn incrementally from small amounts of noisy data, without being subject to catastrophic forgetting; 3) can perform mathematical and other symbolic operations with bulletproof reliability; and 4) is hallucination-free?

The cobbling together of existing systems hot-glue style is certainly useful, but I think a unified architecture is going to change everything.

Re: SymbolicAI: A neuro-symbolic perspective on LLMs

#45
post #43

What bums me out a bit - "Symbolic AI" is already well defined: https://en.m.wikipedia.org/wiki/Symbolic_artificial_intellig...

We hear you. We might end up renaming it. In the paper we have a footnote about the name choice -- it's meant to credit the foundational work of Newell and Simon that inspired this project.

Re: SymbolicAI: A neuro-symbolic perspective on LLMs

#46

One question, OP, how does cost for this work? Do you pay the LLM inference cost (quite literally if using an external API) every time you run a line that involves natural language computation? E.g. what happens if you call a "symbolic" function in a loop.

Yes, that's correct. If using say openai, then every semantic ops are API calls to openai. If you're hosting a local LLM via llama.cpp, then obviously there's no inference cost other than that of hosting the model.

Re: SymbolicAI: A neuro-symbolic perspective on LLMs

#47
post #29

Earlier quoted context omitted.

Why is carrot the vegetablefication of apple?

I think it's interpreting the command as "replace each fruit with a vegetable", and it might intuit "make the resulting vegetables unique from one another" but otherwise it's not trying to find the "most similar" vegetable to every fruit or anything like that.

This is the correct view. Since the instruction was ambiguous, the LLM did its best to satisfy it -- and it did.

Re: SymbolicAI: A neuro-symbolic perspective on LLMs

#48
post #30
post #29

Earlier quoted context omitted.

Why is carrot the vegetablefication of apple?

Also if you run it twice, is it gonna be a carrot again?

It's subjected to randomness. But you're ultimately in control of the LLMs's hyperparams -- temperature, top_p, and seed -- so, you get deterministic outputs if that's what you need. However, there are downsides to this kind of LLM deterministic tweaks because of the inherent autoregressive nature of the LLM.

For instance, with temperature 1 there *could be* a path that satisfies your instruction which otherwise gets missed. There's interesting work here at the intersection of generative grammars and LLMs, where you can cast the problem as an FSM/PA automaton such that you only sample from that grammar with the LLM (you use something like logits_bias to turn off unwanted tokens and keep only those that define the grammar). You can define grammars with libs like lark or parsimonious, and this was how people solved JSON format with LLMs -- JSON is a formal grammar.

Contracts alleviate some of this through post validation, *as long as* you find a way to semantically encode your deterministic constraint.

Re: SymbolicAI: A neuro-symbolic perspective on LLMs

#49
post #36

what are the implicaitons and actual real world application of this? better agents? more accurate, debuggable LLM answers?

I'd argue it's all of them. Contracts simply make better agents. I believe it also gives a very nice bias on how to talk about agents -- as apps obeying contracts. If you find time, please read this blog post; it gives the underlying motivation for using contracts in agent design: https://futurisold.github.io/2025-03-01-dbc/

Re: SymbolicAI: A neuro-symbolic perspective on LLMs

#50
post #36

what are the implicaitons and actual real world application of this? better agents? more accurate, debuggable LLM answers?

Hey, I think I am not using this framework to its full potential, but I have been using it as my main framework for 2 years now. Advantages for me are, that I can easily develop integrations myself. I like the concept of contracts, that I can first make a detailed output model using their LLMDataModel class (an extension of pydantic), I can validate every field both syntactically and semantically using their semantic operations and raise exceptions in case of failures with meaningful messages (and those will be considered via the LLM for retries). So I like this clean separation of actual business logic and all things validation, hallucinations checking and I don’t have to worry about retries and error handling, because that is done by framework as long as I provide a good output data model. It makes my code much more clean and secure and it also makes it easier for me to analyse by just looking at the output model how secure it is. Also I liked that I can basically inject any python logic,be multimodal without overcomplicating everything with DAGs etc. I like having low level control of what is going on. Also once I started out building my main issue with most frameworks was speed. I wanted to create complex multistep workflows using LLMs and still be very fast and I can’t really stand when my code looks messy. I had a data set of 50 million news and a very small compute budget. After some experiments, decided to go with symbolicai, because it was easier for me to speed it up with batching my agent workflows.
Post reply on HN