I think it would be interesting to use an LLM to distill Wikipedia into a set of assertions, then iterate through combinations of those assertions using OpenCyc.
You could look for contradictions between pages on the same subject in different languages, or different pages on related subjects.
You could synthesise new assertions based on what the current assertions imply, then render it to a sentence and fact-check it.
You could use verified assertions to benchmark language parsing and comprehension for new models. Basically unit test NLP.
You could produce a list of new assertions and implications introduced when a new edit to a page is made.
Along with that, a portion of the content of Wikipedia is already available in structured assertion form, thanks to DBPedia[1] and Wikidata[2]. I don't know the exact percentage, but it's a starting point at the very least.
I've tried to use ChatGPT to produce wikidata queries- it sounds like a great combination. Unfortunately it's pretty hard to make it produce valid queries, and to find the wikidata documentation to teach it.
My interest is a little more like flipping that around the other way. Take output from the LLM, get it into structured assertion form, and then use those assertions as part of a query / inference process which pulls in other "known good" (or "ground truth" if you will) assertions from sources like DBPedia or Wikidata. The idea being to either verify the LLM output, or possibly to extend it using inferred conclusions.
I think the way I think about it is somewhat akin to what AWS are doing here, where they talk about using automated reasoning to reduce hallucinations from LLM's:
Very interesting that you’ve done this! I’ve read a few times about people talking about knowledge bases and LLMs and there seems a lot of hand waving around “and at this point the LLM produces the SPARQL query” which feels very much “now draw the rest of the owl” to me
If you can express the DSL SPARQL query as a transformation to JSON Schema, you can have GPT give you the JSON predictably in strict mode, and then reverse the transformation.
Frankly the problem was not in producing a correctly formed SPARQL query; the issue was in the myriad of entity types and relations that the Wikidata project uses and that you need to know about in their detail to use the system. Which often just produces nothing or times out (from the web UI). Not having a previous experience with Wikidata (or SPARQL for that matter) it felt trickier than expected.
Interesting and good to know - the way I've handled similar kinds of things before (for SQL), is if you have a list of predicates or entity types you need to pick from you can populate an enum in a JSON schema. If the list is way too long (it probably is), you can get K nearest neighbor of the entity types to the natural language query and populate the enum with K values (where K might be something reasonable like 10 to 20). You'd need to have a dataset of all entity types stored locally to do this of course.
I know this sounds hand-wavy, but I have had good results doing similar things when trying to pick the correct foreign key out of a table with 1000s of rows.
Think of it like this: don't ask it to construct the query, ask it for the parts of the query, in a predefined format. Then populate one of many pre-defined templates with the values.
For example, you might have ten types of queries. Each query will have parameters and a classification/description. Get the classification, and get the parameters, and stick them into your respective template.
This gives you way more safety and predictability.
I've gone through the whole gamut to do this since first using the GPT's API in early 2023.
As first I was asking for HTML with few-shot since getting reliable JSON was impossible. Then I switched to function calling with JSON mode when that was released later in 2023, but still with fallbacks because sometimes it would spit out markdown with JSON inside, and other fun mistakes. Finally summer 2024 strict mode became available which "guarantees" a well-formed JSON response corresponding to a given schema. I've run hundreds of thousands of queries through that and have not had a formatting issue (yet).
That's exactly one of my project, to use that on my medical anki flashcards, as well as on my many medical pdfs. I'm sure there's a good way to do RAG on it that would be sourced.
Comments
I think it would be interesting to use an LLM to distill Wikipedia into a set of assertions, then iterate through combinations of those assertions using OpenCyc.
You could look for contradictions between pages on the same subject in different languages, or different pages on related subjects.
You could synthesise new assertions based on what the current assertions imply, then render it to a sentence and fact-check it.
You could use verified assertions to benchmark language parsing and comprehension for new models. Basically unit test NLP.
You could produce a list of new assertions and implications introduced when a new edit to a page is made.
Along with that, a portion of the content of Wikipedia is already available in structured assertion form, thanks to DBPedia[1] and Wikidata[2]. I don't know the exact percentage, but it's a starting point at the very least.
[1]: https://www.dbpedia.org/
[2]: https://www.wikidata.org/wiki/Wikidata:Main_Page
I've tried to use ChatGPT to produce wikidata queries- it sounds like a great combination. Unfortunately it's pretty hard to make it produce valid queries, and to find the wikidata documentation to teach it.
My interest is a little more like flipping that around the other way. Take output from the LLM, get it into structured assertion form, and then use those assertions as part of a query / inference process which pulls in other "known good" (or "ground truth" if you will) assertions from sources like DBPedia or Wikidata. The idea being to either verify the LLM output, or possibly to extend it using inferred conclusions.
I think the way I think about it is somewhat akin to what AWS are doing here, where they talk about using automated reasoning to reduce hallucinations from LLM's:
https://aws.amazon.com/blogs/machine-learning/reducing-hallu...
Was looking at prolog and having it shadow the llm activity in order to flag whenever the conversation trips.
Very interesting that you’ve done this! I’ve read a few times about people talking about knowledge bases and LLMs and there seems a lot of hand waving around “and at this point the LLM produces the SPARQL query” which feels very much “now draw the rest of the owl” to me
If you can express the DSL SPARQL query as a transformation to JSON Schema, you can have GPT give you the JSON predictably in strict mode, and then reverse the transformation.
Frankly the problem was not in producing a correctly formed SPARQL query; the issue was in the myriad of entity types and relations that the Wikidata project uses and that you need to know about in their detail to use the system. Which often just produces nothing or times out (from the web UI). Not having a previous experience with Wikidata (or SPARQL for that matter) it felt trickier than expected.
Interesting and good to know - the way I've handled similar kinds of things before (for SQL), is if you have a list of predicates or entity types you need to pick from you can populate an enum in a JSON schema. If the list is way too long (it probably is), you can get K nearest neighbor of the entity types to the natural language query and populate the enum with K values (where K might be something reasonable like 10 to 20). You'd need to have a dataset of all entity types stored locally to do this of course.
I know this sounds hand-wavy, but I have had good results doing similar things when trying to pick the correct foreign key out of a table with 1000s of rows.
Have you done this and had it working reliably for you in practice?
Not for SPARQL, no. But I have done it for other query DSLs like SQL and Opensearch.
Fair enough. Any particular tricks that helped you get valid queries out of it the first time?
Think of it like this: don't ask it to construct the query, ask it for the parts of the query, in a predefined format. Then populate one of many pre-defined templates with the values.
For example, you might have ten types of queries. Each query will have parameters and a classification/description. Get the classification, and get the parameters, and stick them into your respective template.
This gives you way more safety and predictability.
I've gone through the whole gamut to do this since first using the GPT's API in early 2023.
As first I was asking for HTML with few-shot since getting reliable JSON was impossible. Then I switched to function calling with JSON mode when that was released later in 2023, but still with fallbacks because sometimes it would spit out markdown with JSON inside, and other fun mistakes. Finally summer 2024 strict mode became available which "guarantees" a well-formed JSON response corresponding to a given schema. I've run hundreds of thousands of queries through that and have not had a formatting issue (yet).
Very smart approach, thanks
That's exactly one of my project, to use that on my medical anki flashcards, as well as on my many medical pdfs. I'm sure there's a good way to do RAG on it that would be sourced.
I intend to add it in the end to my sophisticated rag system wdoc (https://wdoc.readthedocs.io/en/latest/)
OpenCyc always had that failing that it never felt accessible hidden away. GraphRag for opencyc maybe?
I don't understand why you need OpenCyc for this, you could just chain LLM for both.
I think it would outperform on any language task as language that isn't formal requires interpretation which LLMs excel at.