This may well be very useful, but Claude has ruined me and I have a visceral reaction to ‘gates’ in the opening sentence and couldn’t get any further. If a tool is worth building and sharing, surely it’s also worth writing a brief summary of what it’s supposed to achieve in your own words?
The sentence is near incomprehensible without knowledge of the Claudish robolect. (Here I made up a word. Hopefully its comprehensibility isn't gated too much on language nerdery.)
I have a question for people with knowledge of both LLMs and GOFAI: Why can’t we use LLMs to write as many symbolic rules as needed to fit the data while keeping the ruleset reviewable and maintainable?
Fixing unreliable agents by adding more unreliable agents. It's a shame we can't do something about the tendency of LLMs to give more weight to their weights than to the data they're analysing.
I guess it all comes back to the fact that they don't have a clear division between data they have learned about the world, instructions and data under analysis.
You can ask them only to consider the 5 facts in front of them, but they won't do that, and cannot do that.
> Fixing unreliable agents by adding more unreliable agents.
Depending on how you combine imperfect systems, you can lower or increase error rates.
> data they have learned about the world, instructions and data under analysis.
I don't think there really is a clear distinction between these things though.
And I don't mean this in a gotcha way - these things apply to people too. Not that that means they're like people, but we have successfully built enormous systems out of fallible people, and other imperfect things.
The goal is rarely "eliminate all errors" but "have a thing that's useful, given a possibility of things going wrong".
Depending on how you combine imperfect systems, you can lower or increase error rates.
Well, in principle yes one system can compensate for another, in practice, errors tend to compound and combine in interesting ways, not go away, particularly in systems like this which are unpredictable and generate slightly different responses each time without human intervention. They are not reliable in the way we're used to considering and don't work well without supervision from careful humans at present.
I don't think there really is a clear distinction between these things though.
Yes your second point is an interesting one - the divisions between these things are arbitrarily imposed on the world, but we do have these distinctions for a reason, even if they are not completely objective.
I do think this is a significant problem specific to LLMs though (that I at least see when using them) - we don't have a way to constrain them in what knowledge they consider. This can be a bonus (they are good at connecting faraway bits of maths in interesting ways), but it can be a significant problem when asking for a summary of a data - confabulations and data from outside the context easily leak into the output of the LLM. That is undesirable behaviour and we have no reliable way to constrain it.
I'm not sure that this particular effort is going to help because it doesn't change or constrain the behaviour of the actual machines and the behaviour is the problem, not the data they are fed.
> Well, in principle yes one system can compensate for another, in practice, errors tend to compound and combine in interesting ways, not go away, particularly in systems like this which are unpredictable and generate slightly different responses each time without human intervention.
Ah but the point here IIUC is moving from "let an LLM figure out the right way of querying the data and what you mean with your terms from a wide span of different documents and sources, which it has to perform multiple searches on" to "let an LLM figure out the right way of querying your data with a coherent and machine readable ontology".
While the conversion from "load of data" to "defined structure" is error prone, you now have the second step operating on the same converted thing, and you have ways of fixing that over time (the corrections).
By splitting the task into two distinct phases, you can both interpret and fix the middle step, and remove a large class of mistakes and/or differences caused by different interpretations of the same documents.
There are really two answers to it IMO that this boils down to:
1. This process may be less error prone for that first step than the LLM you're using. That could reduce errors.
2. This process means the first step is run once rather than every time which means you cut out one area where there can be differences each time.
> Yes your second point is an interesting one - the divisions between these things are arbitrarily imposed on the world, but we do have these distinctions for a reason, even if they are not completely objective.
You're right, I think there are useful groupings, but I think any effort to fully isolate them is doomed to fail because they inherently blend. Your instructions contain things that can only be understood in context of world knowledge and the data. The data only makes sense with certain bits of world knowledge.
We also know that these things happen with humans (again just to pre-empt how others may read this and not saying you are accusing me of this, I'm not gotcha-ing here) and so we often have to be careful about how we ask questions, how different cultural backgrounds impact understanding and so forth. We have to take care about how we structure things.
> I'm not sure that this particular effort is going to help because it doesn't change or constrain the behaviour of the actual machines and the behaviour is the problem, not the data they are fed.
I think this effort does address that. A really key thing is that this is about turning human readable questions into SQL that then only query the actual data and you see the result of that query - it allows you to constrain things more (at both points).
I don't know enough about it, would welcome a more informed opinion on that, as a user it's the biggest issue with using them long-term IMO. Perhaps it is fixable somehow, and perhaps 'cannot do that' is a bit strong, what I meant was the current iteration of LLMs cannot do that.
We spend a small fortune trying to get ontology right as it's so critical to real world success of enterprise AI. Curious if this could actually help us.
it's local first, agent-friendly tooling; you have single cli to access it (mcp is there as well if that's your thing)
everything is persisted in simple local text files that you can actually read (or sqlite database if you don't care / have more data)
ie there is no integration, k8s-style nonsense etc, you can just use it on project or on your system user level and know what exactly what's there, you have control over it, you can delete it, move it, extract parts you find useful and move on etc
because it has first class support for uncertainty
evidence is first class concern
supports evolution of belief (statements can be revised, retracted etc. without destroying history)
knowledge is executable (rules, actions, automations – all operate on the same claim model)
it works well for knowledge that keeps changing (including support for querying knowledge as of some past time)
it's great for llm sessions, ie. simple things like comment on a claim being part of a claim itself, which means it appears when working with knowledge, which allows to support weird/human/natural-language aspects that are not directly part of the model
...
rdf/owl/sparql is great for large, public, structured datasets (ie. medical, scientific or some regulatory, standardized ontologies)
cave is great for evolving knowledge, ie. in most cases i use it by just dropping it in and forgetting about it – i don't care how/what llm will model, i just care it'll solve some problems faster when aiding itself with it as a tool
I don't understand this ontology thing. What's the difference between this and a memory system plus skills to collect your enterprise's APIs and CLIs etc?
Ontology is a so-called white-box approach for AI: all dependencies are clearly stated and formalised. If something does not work as you wish, unlike LLMs, in ontology world you can clearly diagnose where the system fails. I understood the NVIDIA's idea this way: we take unreliable LLM and make a "reliable" ontology using it.
If you look back into history, Prolog , was exactly a sort of "memory system" or, better put, a human-friendly database. Ontology is a further development of this concept.
1. What is not in the codebase. Obvious of course, but building an ontology and maintaining it over time forces a company to document what was only living in the head of some experts and never written down. In the case of analytics use cases, think of all the quirks a data analyst might have in mind when querying the data. Very basic e.g. "exclude test accounts whenever you count customers". Every analyst on the team does it without thinking, it's rarely written anywhere, and an agent that doesn't know will happily count them.
2. Related to 1., your codebase or source material may hold different interpretations of the same definition (what "revenue" means can differ between Sales and Finance). The ontology forces you to choose one, or to state when to use each. Without that, the LLM may pick one a bit randomly.
3. It's a governance tool for humans. It gives the company a human-readable, "deterministic" source of truth to agree on what means what, then version it and evolve it.
One issue in a business is what does all the data actually mean? What are the various definitions and how do they relate to each other. What's a customer? Should that include people that have bought things, or anyone who is potentially buying? Do different systems use the same definitions, what are the columns, etc.
An ontology in this kind of context means a more precise machine readable spec of this and how it all relates to each other. You can totally build one by hand. The idea here is I think that it tries to figure it out itself and can take corrections over time, so you can ask natural language questions and get more reliable results rather than hoping an llm works out what "customers this month" means the same way each time over a wide span of data rather than having a much clearer API to work against.
This is what the Matt Pocock /grill-with-docs solves. It helps to build a ubiquitous language that helps with domain modelling. This along with the codebase seems to help agents a lot. I'm not clear on how the Nvidia tool here improves on this, or how it is more reliable?
A memory system is managed by the RL trained behavior, these systems use specific prompts and ordinary software to hardcode a policy. The RL version is usually more efficient, but it can't be improved or made more repeatable.
How about we start by open-sourcing the NVIDIA user-space libraries: libcuda, libcudart, libOpenCL, libnvtx, as well as nvidia-smi and the CUDA and OpenCL profilers.
Shameless plug: we built our own open source equivalent of auto-ontology a few months ago, that doesn't require any API key but your LLM one (or none if you use your coding agent subscription)
The readme seems to be written for enterprise project managers. Does anyone know what philosophy or academic ontology work this ties to, if any? I’m having trouble understanding the specifics, I’ll be honest…
I guess it all comes back to the fact that they don't have a clear division between data they have learned about the world, instructions and data under analysis.
You can ask them only to consider the 5 facts in front of them, but they won't do that, and cannot do that.
Depending on how you combine imperfect systems, you can lower or increase error rates.
> data they have learned about the world, instructions and data under analysis.
I don't think there really is a clear distinction between these things though.
And I don't mean this in a gotcha way - these things apply to people too. Not that that means they're like people, but we have successfully built enormous systems out of fallible people, and other imperfect things.
The goal is rarely "eliminate all errors" but "have a thing that's useful, given a possibility of things going wrong".
Well, in principle yes one system can compensate for another, in practice, errors tend to compound and combine in interesting ways, not go away, particularly in systems like this which are unpredictable and generate slightly different responses each time without human intervention. They are not reliable in the way we're used to considering and don't work well without supervision from careful humans at present.
I don't think there really is a clear distinction between these things though.
Yes your second point is an interesting one - the divisions between these things are arbitrarily imposed on the world, but we do have these distinctions for a reason, even if they are not completely objective.
I do think this is a significant problem specific to LLMs though (that I at least see when using them) - we don't have a way to constrain them in what knowledge they consider. This can be a bonus (they are good at connecting faraway bits of maths in interesting ways), but it can be a significant problem when asking for a summary of a data - confabulations and data from outside the context easily leak into the output of the LLM. That is undesirable behaviour and we have no reliable way to constrain it.
I'm not sure that this particular effort is going to help because it doesn't change or constrain the behaviour of the actual machines and the behaviour is the problem, not the data they are fed.
Ah but the point here IIUC is moving from "let an LLM figure out the right way of querying the data and what you mean with your terms from a wide span of different documents and sources, which it has to perform multiple searches on" to "let an LLM figure out the right way of querying your data with a coherent and machine readable ontology".
While the conversion from "load of data" to "defined structure" is error prone, you now have the second step operating on the same converted thing, and you have ways of fixing that over time (the corrections).
By splitting the task into two distinct phases, you can both interpret and fix the middle step, and remove a large class of mistakes and/or differences caused by different interpretations of the same documents.
There are really two answers to it IMO that this boils down to:
1. This process may be less error prone for that first step than the LLM you're using. That could reduce errors. 2. This process means the first step is run once rather than every time which means you cut out one area where there can be differences each time.
> Yes your second point is an interesting one - the divisions between these things are arbitrarily imposed on the world, but we do have these distinctions for a reason, even if they are not completely objective.
You're right, I think there are useful groupings, but I think any effort to fully isolate them is doomed to fail because they inherently blend. Your instructions contain things that can only be understood in context of world knowledge and the data. The data only makes sense with certain bits of world knowledge.
We also know that these things happen with humans (again just to pre-empt how others may read this and not saying you are accusing me of this, I'm not gotcha-ing here) and so we often have to be careful about how we ask questions, how different cultural backgrounds impact understanding and so forth. We have to take care about how we structure things.
> I'm not sure that this particular effort is going to help because it doesn't change or constrain the behaviour of the actual machines and the behaviour is the problem, not the data they are fed.
I think this effort does address that. A really key thing is that this is about turning human readable questions into SQL that then only query the actual data and you see the result of that query - it allows you to constrain things more (at both points).
Has training them to do it been tried and proven to fail?
[0] https://mirekrusin.com/cave
i want to use these semantic / KG tech but i find them so confusing!
it's local first, agent-friendly tooling; you have single cli to access it (mcp is there as well if that's your thing)
everything is persisted in simple local text files that you can actually read (or sqlite database if you don't care / have more data)
ie there is no integration, k8s-style nonsense etc, you can just use it on project or on your system user level and know what exactly what's there, you have control over it, you can delete it, move it, extract parts you find useful and move on etc
because it has first class support for uncertainty
evidence is first class concern
supports evolution of belief (statements can be revised, retracted etc. without destroying history)
knowledge is executable (rules, actions, automations – all operate on the same claim model)
it works well for knowledge that keeps changing (including support for querying knowledge as of some past time)
it's great for llm sessions, ie. simple things like comment on a claim being part of a claim itself, which means it appears when working with knowledge, which allows to support weird/human/natural-language aspects that are not directly part of the model
...
rdf/owl/sparql is great for large, public, structured datasets (ie. medical, scientific or some regulatory, standardized ontologies)
cave is great for evolving knowledge, ie. in most cases i use it by just dropping it in and forgetting about it – i don't care how/what llm will model, i just care it'll solve some problems faster when aiding itself with it as a tool
2. Related to 1., your codebase or source material may hold different interpretations of the same definition (what "revenue" means can differ between Sales and Finance). The ontology forces you to choose one, or to state when to use each. Without that, the LLM may pick one a bit randomly.
3. It's a governance tool for humans. It gives the company a human-readable, "deterministic" source of truth to agree on what means what, then version it and evolve it.
An ontology in this kind of context means a more precise machine readable spec of this and how it all relates to each other. You can totally build one by hand. The idea here is I think that it tries to figure it out itself and can take corrections over time, so you can ask natural language questions and get more reliable results rather than hoping an llm works out what "customers this month" means the same way each time over a wide span of data rather than having a much clearer API to work against.
How about we start by open-sourcing the NVIDIA user-space libraries: libcuda, libcudart, libOpenCL, libnvtx, as well as nvidia-smi and the CUDA and OpenCL profilers.
https://github.com/GetCassis/ontology-skills