Hacker News new | past | comments | ask | show | jobs | submit login
The IDP Knowledge Base System (idp-z3.be)
71 points by this_was_posted 6 months ago | hide | past | favorite | 18 comments



I'm glad to see the design of the knowledge base language is aware of context (here called a domain). This is better than other systems, like what is used to parse / dump data from Wikipedia, where the context is basically "the real world right now". However, it doesn't seem like they wanted systems to be able to use and switch between domains easily, nor be able to backtrack (where you have inferred some knowledge, and you are trying to figure out what domain(s) you should be operating inside).

Contextual reasoning is very important for many situations, because time is one of the most important contexts. You can have a fact like "the iPhone is the best selling phone". This fact is true or false based on the context. It is definitely false in the real world year 2006 and before, because the first iPhone was not released yet. While the fact may be true right now in a global context, if we are talking about a specific country or region, it may be false. For example, I would expect that satellite-capable phones may be more popular in a highly remote (non-urban) country or region.


I really want to see an open knowledge base project tackle exactly what you're describing. Cyc has a pretty solid foundation for accomplishing this using what they call microtheories (personally a weird term to me). It's a great step in the right direction but its a closed ecosystem with a huge amount of cognitive overhead to do anything against. A lot of other projects seem to do better with the ingestion and updating of information (albeit with less automated tooling).

I've been refreshing myself on ontology design and knowledge representation lately. I'm kind of surprised that is hasn't moved very much in the last two decades. I'm guessing we're about to hit an inflection point there as it becomes a cool topic with the current AI trends.


Formal knowledge representation and any sort of formal reasoning is not the way the industry is going right now with LLMs though.

It occurs to me that if we want LLMs to be able to reason better, we may need to write texts that explicitly embody the reasoning we desire, and not just use a bunch of books or whatever scraped from the Internet.


While I agree with your statement I would add "yet" to the end of it. Language models are powerful tools on their own, but we're already augmenting their knowledge with external data stores. Personally I think the next stage is going to blend in knowledge graphs.

Populating these Ontologies is very manual and time-consuming right now. LLMs without any additional training (I'm currently using a mix of the various size Lllama2 models, along with GPT 3.5 and 4 for this) are capable of few-shot generation of ontological classification. Extending this classification using fine-tuning is doing REALLY well.

I'm also seeing a lot of value in using LLMs to query and interpret proofs from deductive reasoners against these knowledge graphs. I have been limiting the scope of my research around this to two domains that have a kind of eccentric mix of formal practices, explicit "correct" knowledge, and common sense rules of thumb to be successful. Queries can be quite onerous to build which a fine-tuned model can help with, and LLMs can both assist in interpreting those logic chains and doing knowledge maintenance to add in the missing common sense rules or remove bad or outdated rules. Even selecting among possible solutions produced by the reasoners is really solid when you include the task, desires, and constraints of what you're trying to accomplish in the prompt performing the selection.

The formal process and knowledge is handled very well by knowledge graphs along with a deductive reasoning engine, but they produce very long winded logic chains to reach a positive or negative conclusion where a simpler chain might have sufficed (usually due to missing rules, or a lack of common sense rules) and are generally incapable of "leaps" in deduction.

LLMs on their own are capable of (currently largely low-level) common sense reasoning, and some formal reasoning but are still very prone to hallucinations. A 20% failure rate when building rules that human lives may depend on is a non-starter. This will improve but I don't think a probabilistic approach will ever fully remove them. We can use all of our tools together in various blends to augment and verify knowledge, fully automatically, to make more capable systems.


This is what I've been thinking for the past year. Do you have any more resources where I can explore what you're talking about?

* What are some deductive reasoning engines out there?

* How are you storing the rules in a graph? Using triples?

* What query languages are you using for this?


Sorry missed this comment. There are a surprising number of them, basically any formal solver is a deductive reasoning engine. Prolog is itself a deductive reasoning engine (and if you're going to implement a reasoning system, its probably worth going through the WAM Book over a weekend, search Google for wambook.pdf, its a publicly released book with the title "Warren's Abstract Machine: A Tutorial Reconstruction". The harder ones are inductive and abductive reasoners, which I'm not aware of any opensource ones only old papers that all do little tiny bits. A lot of deductive reasoners boil down to just depth-first-search with backtracking.

How I'm storing them is maybe interesting... Graph databases that support tagged or typed relations get you most of the way to a basic reasoning system. I'm currently storing the graph content of the knowledge base in a database called SurrealDB with the RocksDB backend (this is new to me). Learning SurrealDB has been giving me a bit of Deja Vu around building simple reasoners, there is a lot of overlap between graph theory and formal reasoning.

Rules are encoded in the program. I find it beneficial to think about this as building up lots of small tools that are aware of what they're capable of and can indicate whether they think they can make single step progress towards the goal. You might have a small tool that if you have a location and you're looking for a different location (its prerequisites for "knowing" it may be useful) you could have that tool walk your graph finding the smallest shared domain that both are a part of that can become part of the context. Building up context and learning to disambiguate things using that context is kind of the "hard part" if you want to optimize your solvers or ask complex questions.

For the Rules to be meaningful you need to have an Ontology for your database. Your Rules will be operating on top of fixed concepts, and known relation types between them. Ontologies are a BIG subject that has also faded into the mist a bit, there are some samples on http://ontologydesignpatterns.org but there are a lot of dead links on there as well. The more complex your Ontology the harder to write and/or less useful the individual tools become as they will probably have fewer opportunities to run.

Hope this helps!


My personal exploration has me moving in the direction of using LLMs as a Language Model and some sort of structured knowledge representation as a Knowledge Model. So using knowledge graphs to store facts and data and LLMs to interface with it. I wish there was more focus on this, right now I'm just using RDF graphs and SPARQL to try to create my own knowledge engine.


I've read the entire landing page and I'm still not sure what IDP is or does. Which, to be fair, is a common failure pattern with many landing pages.


looks potentially interesting but a lot of it is kind of baffling, assumes a lot of familiarity with fairly esoteric topic, not clear where to start

the tutorial page https://www.idp-z3.be/tutorial.html is a bit more enlightening

as is https://interactive-idp.gitlab.io/ learning material

but I didn't find those first, I found the docs first (via the four "learn more" links on the landing page)

and I don't think they are the best starting point

https://docs.idp-z3.be/en/latest/introduction.html

> IDP-Z3 can be installed using the python package ecosystem.

> install python 3, with pip3, making sure that python3 is in the PATH.

> use git to clone https://gitlab.com/krr/IDP-Z3 to a directory on your machine

> (For Linux and MacOS) open a terminal in that directory and run the following command

First thought is... why isn't it published to PyPI?

But then elsewhere https://docs.idp-z3.be/en/latest/IDP-Z3.html

> the idp_engine package available on Pypi.

And looking in the git repo it seems like this is the same package published as https://pypi.org/project/idp-engine/

Why not just say "pip install idp-engine"...?


Thanks for the feedback. We'll see how we can improve the communication.

Quick response: with pypi, you can only install the reasoning engine. By cloning the repository, you get the full suite of tools, including the "interactive consultant".


I see...

I think it could probably be evolved so that they can be pip installed too.

e.g. instead of git clone and `poetry run python3 main.py` maybe your pip package could provide its own cli frontend for running the server.


> Why not just say "pip install idp-engine"...?

(I have nothing to do with IDP-Z3) This is the general pattern:

* If you are a developer: get sources and work on sources, because, probably, you want to add to them or modify them etc. Part of this experience may be creating a package and installing it with pip or some other package installation program, but it's not usually what other developers (contributors) would be working on.

* If you are a user: use the supported package manager to obtain the package and use it through documented interface.

I'm honestly not sure if this is why or how these instructions came to be, but this is a fairly common thing to do, so, w/o looking, I'd guess this is what it is.


I read through the syntax tutorial, and based on that alone I'm guessing this thing would be a huge pain to work with. The operators `=<`, `<=`, `>=`, and `=>` are easily confusable/typo-able, and I have to imagine the for-all operator is `!` only because someone had already decided to use `?` for there-exists, since who in their right mind would use a `!` prefix to mean anything other than boolean negation?


It seems it has a lot in common with Lamport's TLA+, can someone compare?


Hi, I'm one of the main devs. TLA+ is useful to prove properties of programs. By contrast, IDP-Z3 is a reasoning engine that can be used as a module in a program. It is closer to a constraint solver, but offers more functionality than a traditional CSP solver. For example, it can compute what are relevant questions, given some inputs. This is useful to build "interactive consultants".

For example, you give IDP-Z3 the formula that links a tax-free amount, a tax rate and a tax-included amount, and the values of any two of its parameters, and it will compute the missing parameter. You do not need to write 3 different formula, one for each case. If you give him only one parameter, it will say that the other two parameters are relevant.


So it's layer on top of the z3-solver right? That's a way to see it?


Yes. It uses a more convenient language than SMT-Lib to express "knowledge", and offers more functionality.


This looks beautiful. hope I have chances to try it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: