I love seeing the term "AI" used in the classic sense. Old AI is full of fascinating developments. Expert systems, A* search, genetic algorithms over S-expressions for creating arbitrary solutions, and SAT algorithms were once thought to be that which would eventually scale into AGI.
I suspect that the next big AI breakthrough will result at least in part from constraining LLM decisions with old AI approaches. Frank Coyle presented the idea of ontologies constraining LLM output about a month ago: https://www.youtube.com/watch?v=Sir59K8ZDPU
Going beyond that, I wonder if an agent could keep a running list of assumptions & known facts (with confidence levels/intervals), test them (actively & passively), update them when observations contradict them, and act based on them -- not merely as an emergent behavior, but as a provably correct (old AI based) algorithm embedded in the transformer architecture.
> I suspect that the next big AI breakthrough will result at least in part from constraining LLM decisions with old AI approaches.
AFAIK bridging deductive and inductive AI has been understood as the trick for "AGI" for a long time, probably even before it was called AGI.
I really want this winter of deductive AI to be short. We need both sides and can't afford a long winter like the one inductive AI suffered.
FWIW when I first studied automatic theorem proving as a (high school) student in 2013, this was already widely discussed. They were trying to add neural networks inside the solvers, rather than current paradigm of a neural networks using theorem provers as tools. Presumably the history of logic + natural language computers would go back a lot further.
> I suspect that the next big AI breakthrough will result at least in part from constraining LLM decisions with old AI approaches.
> Going beyond that, I wonder if an agent could keep a running list of assumptions & known facts (with confidence levels/intervals), test them (actively & passively), update them when observations contradict them, and act based on them
I don’t think that’s “going beyond that”. It’s a blackboard system from the 1980s (https://en.wikipedia.org/wiki/Blackboard_system)
Didn't old-school blackboard systems sort of evaporate into a modern combination of a persistence layer, a task queue, pub-sub, and bespoke code for evaluating/scheduling/executing tasks?
That's not really what I was referring to. I meant more of a system of working assumptions (call them first-class axioms, propositions, facts, whatever) that govern behavior and can be updated when observations occur that contradict them -- not a task queue or a database of all known facts. Sort of like human core beliefs that dictate how we see the world.
> I suspect that the next big AI breakthrough will result at least in part from constraining LLM decisions with old AI approaches. Frank Coyle presented the idea of ontologies constraining LLM output about a month ago: https://www.youtube.com/watch?v=Sir59K8ZDPU
Interesting, thanks for sharing!
I plan to give it my own shot with vibing my own harness; I plan to use https://glean.software/ as the central database for everything code, then for documentation. After that, it could be used for bookkeeping for reasoning in a style similar to what you describe; after all, Angle, the query language of Glean, is a https://en.wikipedia.org/wiki/Datalog with some extras (I don't know which yet), so stuff like onthologies could be queried quite well, I would guess.
If you mean letting an LLM generate code for a Prolog planner from an English problem description, that has been done successfully already with last year's models eg [1].
[1]: https://quantumprolog.sgml.net
Appreciate the link! That is not what I had in mind though; for them, the Prolog Code is the goal, for me, Prolog is an interface language within a system I build. That code could be generated on the fly, but I lean more towards fixed templates that can be instantiated by input some variables by the LLM that is doing agentic code, rather than having that LLM reproducing that query code completely on the flow.
The reasoning behind it is that I want to put as much logic as possible into the harness where it is deterministic, controled and fast - My goal is to make agentic coding usable for my purposes even with small local LLM models. Those might botcher generating Prolog queries sometimes, but they might might be able to used my API/interface/whatever reliably (and then the harness does everything else under the hood, including instantiating the Prolog templates and running the queries)