51–60 of 93 posts
The LLMs are great at:
- understanding the flow
- making diagrams
- running the code with logging they add to to even better understand the flow
The flow being in Dot (or other machine readable format) makes it even easier for the LLM to use that as a reference going forward.
There seems to be this view in some circles that the LLM should do EVERYTHING. The most extreme version of this was "just commit the prompt, bro".
The more I've used LLMs, the more I think that the LLM should do either:
1. the fuzzy parts as mentioned in the post
2. helping to write deterministic tools to expand the "non-fuzzy" part
For #2, we invented code to run the same instructions the same way over and over again for very, very low cost. The code is also easy to read and modify as needed.
Why we would replace the above with a smart but stochastic system still seems strange to me.
I reached a similar conclusion: LLMs should only really sit at the terminals of request fulfilment. 1. User request understanding: natural language -> a more rigorous representation, in my case Datalog. 2. Result interpretation: facts and derived facts -> natural language. Between those terminals, the work should be mechanical reasoning over some ontology or formal knowledge structure. That connects to another princi…
Datalog seems like a way to "spell" knowledge graph (KG). The article touches on Datalog statements changing over time. One ingredient I think would be good to add to the system is to make every statement carry "providence" metadata. The providence should be sufficient to enable later confirmation that a statement is still valid or if the statement needs to be reformed without the need to remake the entire graph from…
Great work! If anyone is looking for a way to integrate something like this into their own harness or the pi coding agent, then you might be interested in DeepClause [0]. It comes with a Prolog-like language implemented on top of SWI-Prolog (WASM Version). The purpose of the project is to allow for broad experimentation around the intersection of LLMs/Agents and GOFAI. So you could use it to build memory systems like…
btw. your comment is grayed out, not sure what it means. However, thanks for sharing, I'll look into it.
Earlier quoted context omitted.
In general, what all the big LLM providers are doing is moving towards classical & neural (neuro-symbolic) AI - even though they dont publicly admit it because that would counter their claims for years of "scale is all you need" (which has vanished with diminishing returns, see $MS / altman's GPT-5 bet).
How do you know this?
So he's using an LLM to generate data stored in an "is_a" representation. That's so classic AI. Soon, he'll discover that he needs quantifiers. Then that "for all" is too strong sometimes, and he needs "for most". That way lies Cyc. It's not a bad idea. But it does have a history.
In general, what all the big LLM providers are doing is moving towards classical & neural (neuro-symbolic) AI - even though they dont publicly admit it because that would counter their claims for years of "scale is all you need" (which has vanished with diminishing returns, see $MS / altman's GPT-5 bet).
I reached a similar conclusion: LLMs should only really sit at the terminals of request fulfilment. 1. User request understanding: natural language -> a more rigorous representation, in my case Datalog. 2. Result interpretation: facts and derived facts -> natural language. Between those terminals, the work should be mechanical reasoning over some ontology or formal knowledge structure. That connects to another princi…
When i hear “weathering” i think of something slowly eroding away
Earlier quoted context omitted.
When i hear “weathering” i think of something slowly eroding away
I feel like the thing eroding away in this case is a blocker, a friction. Think of a river cutting a path through the mountains.