> The problem it’s trying to solve is that generating valid SQL doesn’t necessarily produce the right answer. An AI might find a column called revenue, but still choose the wrong dataset or misunderstand whether that figure includes things like refunds. Auto Ontology adds information about what the data means to help it make those decisions.

and then the one paragraph summary at the end:

> My reading: it’s a database chat application built around a reusable catalogue of business meaning. The question worth testing is whether that catalogue makes answers measurably more correct—and how much human work it takes to get the definitions right.

https://github.com/NVIDIA/auto-ontology/blob/main/auto_ontol...

Seriously though, it'd be nice if we started using a more shared and less vendor-specific jargon to refer to what these latest features are. We're getting into JVM vs. .NET Execution Engine distinctions and they just muddy the water on what goes on in the market.

It looks a lot like English, but it doesn't have the same rhythm human English has. It's as if a human tried and failed to be concise.

And nvidia probably doesn’t want to say “probabilistic responses including hallucinations preclude reliable ai analytics”

As it is the sentence communicates very little. Things are unreliable for a lot of different reasons. Hardware? Software? Users? Intentional and required use of RNGs? Claude presumes the reader has all the same weights activated.

Now there are times when I let the model keep its own docs in its own language, for its own future reference; but, it is not intended for human distribution due to its odd selection of words and phrases (aka slop).

Just adding a few words takes it so far...

What? now I can't draw boxes and arrows without it being slop?

It's quite common for LLMs to mix up values between columns in a table. It's often referred to as a structural hallucination, since it can happen with all kinds of relationships that form structures, not just columns in a table.

It has a utility in the same way that raw ingredients have a utility in a kitchen. The chef doesn’t just drop a messy pile of uncooked meat and vegetables onto your plate and tell you to figure it out. That’s exactly what people are doing when they vomit out a bunch of impenetrable slop and expect the reader to do the hard work of comprehending it on their behalf.

You can’t expect others to care about what you’re saying if you’ve not spent a moment considering how best to say it. The reader’s time is no less valuable than your own. If you think composing a readme for your project is worth zero minutes of your time, that’s the appropriate amount of time for readers to allocate to it.

For whatever it’s worth, I also cancelled my Claude subscription recently and shifted back to OpenAI solely because I find its outputs far more readable. I’ll even accept a slight hit on model performance as a trade-off. If I’m unwilling to read Claude-speak when I’m being paid an hourly rate, you can be sure I’m not reading it for free.

Computer systems, though, can have that distinction. If you read data supplied by the user, and then process it via behavior in code, and process that result against administratively-set data in the database, the separation between user-supplied data, administratively-configured data, and instructions (code) is extremely clear. Even if you are doing something that could be nondeterministic, e.g. incorporating randomness or doing sentiment analysis or whatnot.

I don't think the oft-repeated "AI is fallible just like humans are" applies here. Computer systems are an area where that separation can be achieved. We know this because we've achieved it a lot. LLMs, powerful as they are, are a massive step back in that regard. Their benefits might outweigh that compromise, but it is, as they say, "worth naming" anyway.

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.

But you are putting broad but is more opinionated design structure around it. I will have a look thanks.

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 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; if i want some structured dataset out of it i may occasionally ask it to model it around homogeneous schema i can extract, but in most cases i really don't care