How can you get transparency from an LLM? They're complete black boxes by architecture.

>How can you get transparency from an LLM? They're complete black boxes by architecture.

You just ask them. I literally just prompted ChatGPT (3.5) to think about its answer again and explain what's wrong with it, and it did. Kept going 2 or 3 times, until it was sure it wasn't doing anything wrong, and magically the script it produced at that stage just worked.

But can you believe that these are the correct explanations? Perhaps it just confabulated an explanation that sounds likely given your prompt, and is not the actual reason it told you what it did?

That'll just give you made up rationalizations, like asking a human to explain an emotional subconscious choice.

For inference? Not really. LLM observability startups are a thing. Arize.ai probably the most well known.

Haven't they recently discovered that Tesla crashes are far more frequent that previous estimations?

Whatever that number is, how does it compare to crashes based on human error?

Tesla won't release the numbers so we don't know.

It’s also weird to compare the Tesla to some ‘99 Toyota. Why not compare across the pool of cars that also have adaptive cruise control, lane keep assist, forward collision prevention, etc..?

I recall the number of deaths from Tesla self-driving being reported as being 10x per mile as regular highway driving. I think it was this article, but it's paywalled. https://www.nytimes.com/2022/06/08/technology/tesla-autopilo...

I believe you. I think for at least some people this might be one of those generational differences.

Wanting to do some things by hand might be increasingly a thing only people over a certain age do.

I know from use that perplexity.ai (which builds atop GPT4) hallucinates very little compared to Bard and ChatGPT.

What are some techniques that these products use apart from bounding context and prompt engineering? ReAct sounds like it might help: https://react-lm.github.io/

Similar to self-driving cars, I think the last 1% of the way is going to be the near-insurmountable barrier that makes widespread implementation difficult or potentially impossible. For tasks where you can plausibly check the results with some kind of external software harness, or defer double-checking to a person, these models will make development quick (if resource-intensive). But any kind of fully-automated complex process where the consequences are important will be tough to hand over to black-box generators.

But is surprisingly good useful?

Suppose you configure your inbox such that you unpredictably don't see a small percentage of important emails. Suppose you miss an email from your boss telling you a very important client needs you to fix a critical bug today, and as a result you start working on that bug slightly later when your boss contacts you another way. Your boss might tell you to uninstall your LLM and just read all your email

The same logic could be applicable to pretty much any other spam filtering mechanism.

No, it's the same category, but the specific values makes all the difference. The logic depends on the probability of error, the predictability of error, and the social acceptability of error.

By analogy it's socially more acceptable to have an outage because AWS is down than because insert_nich_provider is down even if insert_nich_provider has fewer outages. If insert_nich_provider has more outages it's even worse.