69 replies
12h44m
You just have to double check the results whenever you tell Claude to extract lists and data.
99.9% of it will be correct, but sometimes 1 or 2 records are off. This kind of error is especially hard to notice because you're so impressed that Claude managed to do the extract task at all -- plus the results look wholly plausible upon eyeballing -- that you wouldn't expect anything to be wrong at all.
But LLMs can get things ever slightly wrong when it comes to long lists/tables. I've been bitten by this before.
Trust but verify.
(edit: if the answer is "machine verifiable", one approach to ask an LLM to write a Python validator which it can execute internally. ChatGPT can execute code. I believe Sonnet 3.5 can too, but I haven't tried.)
The "off by one" predilection of LLMs is going to lead to this massive erosion of trust in whatever "Truth" is supposed to be, and it's terrifying and going to make for a bumpy couple of years. (Or the complete collapse of objective knowledge, on a long enough time horizon.)
It's one thing to ask an LLM when George Washington was born, and have it return "May 20, 2020." It's another thing to ask it, and have it matter-of-factly hallucinate "February 20, 1733." At first glance, that... sounds right, right? President's Day is in February, and has something to do with his birthday? And that year seems to check out? Good enough!
But it's not right. And it's the confidence and bravado with which LLMs report these "facts" that's terrifying. It just misstates information, calculations, and detail work, because the stochastic model compelled it to, and there wasn't sufficient checks in place to confirm or validate the information.
Trust but verify is one of those things that's so paradoxical and cyclical: if I have to confirm every fact ChatGPT gives me with... what I hope is a higher source of truth like Wikipedia, before it's overrun with LLM outputs... then why don't I just start there? If I have to build a validator in Python to verify the output then... why not just start there?
We're going to see some major issues crop up from this sort of insidious error, but the hard part about off-by-ones is that they're remarkably difficult to detect, and so what will happen is data will slowly corrupt and take us further and further off course, and we won't notice until it's too late. We should be so lucky that all of LLMs' garbage outputs look like glue on pizza recommendations, but the reality is, it'll be a slow, seeping poisoning of the well, and when this inaccurate output starts sneaking into parts of our lives that really matter... we're probably well and truly fucked.
This is semi-offtopic, but "trust but verify" is an oxymoron. Trusting something means I don't have to verify whether it's correct (I trust that it is), so the saying, in the end, is "don't verify but verify".
A better phrase would be “Use it but verify”, simply.
Yes, which boils down to "verify".
It's possible to trust (or have faith) in my car being able to drive another 50k miles without breaking down. But if I bring it to a mechanic to have the car inspected just in case, does that mean I never had trust/faith in the car to begin with?
"I trust my coworkers write good code, but I verify with code reviews" -- doing code reviews doesn't mean you don't trust your coworker.
Yet another way to look at it: people can say things they believe to be true but are actually false (which isn't lying). When that happens, you can successfully trust someone in the sense that they're not lying to you, but the absence of a lie doesn't guarantee a truth, so verifying what you trust to be true doesn't invalidate your trust.
We're getting into the definition of trust, but to me trust means exactly "I don't need to verify".
If I say I trust you to write correct code, I don't mean "I'm sure your mistakes won't be intentional", I mean "I'm sure you won't have mistakes". If I need to check your code for mistakes, I don't trust you to write correct code.
I don't know anyone who will hear "I trust you to write correct code, now let me make sure it's correct" and think "yes, this sentence makes sense".
If you use the slightly weaker definition that trust means you have confidence in someone, then the adage makes sense.
The issue here is that the only value of the adage is in the sleight of hand it lets you perform. If someone asks "don't you trust me?" (ie "do you have to verify what I do/say?"), you can say "trust, but verify!", and kind of make it sound like you do trust them, but also you don't really.
The adage doesn't work under any definition of trust other than the one it's conflicting with itself about.
I think I just provided an example where it makes sense.
Specifically: I have confidence in your ability to execute on this task, but I want to check to make sure that everything is correct before we finalize.
“I trust that you believe your code is correct, now let’s double check”.
Or maybe the proverb needs to be rewritten as “feign trust and verify”
Or assume good faith but, since anyone can make mistakes, check the work anyway.
That's a bit wordy but I'm sure someone can come up with a pithy phrase to encapsulate the idea.
"Trust, but verify"?
It's a matter of degrees. Absolute trust is a rare thing, but people have given examples of relative trust. Your car won't break down and you can trust it with your kids' life, almost never challenging its trustworthiness, but still you can do checkups or inspections, because some of the bult-in redundancies might be strained. Trusting aircraft but still doing inspections. Trusting your colleagues to do their best but still doing reviews because every fucks up once in a while.
The idea of trusting a next-token-predictor (jesting here) is akin to trusting your System 1 - there's a degree to find where you force yourself to enable System 2 and correct biases.
I always wondered about that
French armed forces have a better version of this saying. “Trust does not exclude control.” They’re still going to check for explosives under cars that want to park in French embassies.
It’s interesting to notice that etymologically speaking the French and English words have completely different roots and therefore evokes slightly different ideas which are lost in translation.
Trust shares its root with truth. It’s directly related to believing in the veracity of something.
Confiance comes from the Latin confidere which means depositing something to someone while having faith they are going to take good care of it. The accent is on the faith in the relationship, not the truthfulness. The tension between trust and control doesn’t really exist in French. You can have faith but still check.
Would you mind sharing your reference on that? All the etymology sites I rely on seem to place the root in words that end up at "solid" or "comfort".
Definitely and that’s not incompatible with what I’m saying.
You are indeed looking far back to the Proto-Indo-European where words are very different and sometimes a bit of guesses.
If you look at the whole tree, you will see that both trust, truth and true share common Germanic roots (that’s pretty obvious by looking at them) which is indeed linked with words meaning “solid” and then “promise, contract”.
What’s interesting is that the root is shared between “truth” and “trust” while in French it’s not (vérité from veritas vs confiance from confere).
I think a better translation of "control" in that saying is "checking" or "testing". "Control" in present-day English is a false cognate there.
This is not quite true. "Trust" is to give a permission for someone to act on achieving some result. "Verify" means assess the achieved result, and correct aposteriori the probability with which said person is able to achieve the abocementioned result. This is the way Bayesian reasoning works.
Trust has degrees. What you have brought is "unconditional trust". Very rarely works.
This would make the sentence "I asked him to wash the dishes properly, but I don't trust him", as your definition expands this to "I asked him to wash the dishes properly, but I didn't give him permission to achieve this result".
If you say "I asked someone to do X but I don't trust them", it means you aren't confident they'll do it properly, thus you have to verify. If you say "I asked him to do X and I trust him, so I don't need to check up on him", it's unlikely to leave people puzzled.
It's surprising to me to see this many comments arguing against the common usage of trust, just because of a self-conflicting phrase.
Why could I not say "I trusted him to do the dishes properly, after he was done, I verified, it's a good thing I trusted him to do the dishes properly, my supervision would have been unwarranted and my trust was warranted?"
I trusted someone to do their task correctly, after the task was done, I verified my trust was warranted.
What would be different if you didn't trust them to do it correctly?
Is it an oxymoron to generate an asymmetrical cryptographic signature, send it to someone, and that someone verify the signature with the public key?
Why not just "trust" them instead? You have a contact and you know them, can't you trust them?
This is what "trust but verify" means. It means audit everything you can. Do not really on trust alone.
An entire civilization can be built with this methodology. It would be a much better one than the one we have now.
Of course not. I verify because I don't trust them.
No, the risk of trust is too high against the cost of spending a second verifying.
Your comment just showed an example of something I don't trust and asked "why not trust instead"? The question even undermines your very point, because "why not trust them instead?" assumes (correctly) that I don't trust them, so I need to verify.
No, it wouldn't. Trust is an optimization that enables civilization. The extreme end of "verify" is the philosophy behind cryptocurrencies: never trust, always verify. It's interesting because it provides an exchange rate between trust and kilowatt hours you have to burn to not rely on it.
Pragmatically, the statement was made famous in English by a conservative US president, addressing the nation, including his supporters, who trusted him, but not the Soviets with whom he was negotiating.
Saying, in effect: "you trust in me, I'm choosing to trust that it makes sense to make agreement with the USSR, and we are going to verify it, just as we would with any serious business, as is proverbially commonsensical" is a perfectly intelligible.
There is nothing cunning about clinging to a single, superficial, context free reading of language.
Human speech and writting is not code, ambiguity and containing a range of possible meanings is part of its power and value.
So "trust me, but verify others"? Where have you seen this adage used in this sense? It's not even used like that in the original Russian, where Reagan lifted it from.
I think that’s a rather peculiar interpretation. I always thought it was pretty obvious that Reagan was just saying that he didn’t trust the soviets, and found a polite excuse not to in the form of the Russian proverb.
Yep.
https://en.m.wikipedia.org/wiki/Trust,_but_verify
It basically means "trust, but not too much."
That's only one possible meaning of the word "trust," i.e. a firm belief.
Trust can also mean leaving something in the care of another, and it can also mean relying on something in the future, neither of these precludes a need to verify.
Edit: jgalt212 says in another reply that it's also the English translation of a Russian idiom. Assuming that's true, that would make a lot of sense in this context, since the phrase was popularized by Reagan talking about nuclear arms agreements with the USSR. It would be just like him to turn a Russian phrase around on them. It's somewhat humorous, but also conveys "I know how you think, don't try to fool me."
I believe it’s going to become counter productive sooner than anyone might think, and in fairly frustrating ways. I can see a class of programmers trading their affinity with the skill for a structurally unstable crutch.
I was using Perplexity with Claude 3.5 and asked it how I would achieve some task with langchain and it gleefully spat out some code examples and explanations. It turns out they were all completely fabricated (easy to tell because I had the docs open and none of the functions it referred to existed), and when asked to clarify it just replied “yeah this is just how I imagine it would work.”
One technique to reduce hallucinations is to tell the LLM "don't make things up, if you don't know then say so". Make a habit of saying this for important questions or questions for which you suspect the LLM may not know.
It's hit and miss, for the same reason Google is (and increasingly more so). If you try and search for 'langchaingo' then you might get lucky if you add enough into the query to say you're working with go, but otherwise it'd just see 'langchain'.
Google is pretty much useless for the same reason.
They're not actually more intelligent, they're more stupid, so you have to provide more and more context to get desired results compared to them just doing more exact searching.
Ultimately they just want you to boost their metrics with more searches and by loading more ads with tracking, so intelligently widening results to do that is in their favour.
Maybe it will be analogous to steel. For most of the post-nuclear age, steel has been contaminated with radionuclides from atmospheric nuclear weapon use and testing. To get "low background" steel you had to recycle steel that was made before 1945. Maybe to fact-check information we'll eventually have to go to textbooks or online archives that were produced before 2023.
(Steel contamination has slowly become less of an issue as most of the fallout elements have decayed by now. Maybe LLMs will get better and eventually the hallucinated "facts" will get weeded out. Or maybe we'll have an occasional AI "Chernobyl" that will screw everything up again for a while.)
Because of llm Internet we have today, I already do go out of my way to find books and information that I can audit were written by a human before GPT.
Agree with this sentiment, erosion of trust and potential issues. The illusion of facts and knowledge is a great moral hazard that AI companies are willing to step around while the market share battles play out. More responsible AI companies, stronger government policy, better engineering and less dumb users are all part of the solution here.
This is more solvable from an engineering perspective if we don't take the approach that LLMs are a hammer and everything is a nail. The solution I think is along the lines of breaking the issue down into 2-3 problems: 1) Understand the intent of question, 2) Validating the data in resultset and 3) provide a signal to the user of the measure to which the result matches the intent of the intention.
LLMs work great to understand the intent of the request; To me this is the magic of LLM - when I ask, it understands what I'm looking for as opposed to google has no idea, here's a bunch of blue links - you go figure it out.
However, more validation of results is required. Before answers are returned, I want the result validated with a trusted source. Trust is a hard problem..and probably not in the purview of the LLM to solve. Trust means different things in different contexts. You trust a friend because they understand your worldview and they have your best interest in mind. Does an LLM do this? You trust a business because they have consistently delivered valuable services to their customers, leveraging proprietary, up-to-date knowledge acquired through their operations, which rely on having the latest and most accurate information as a competitive advantage. Descartes stores this mornings garbage truck routes for Boise IA in its route planning software - thats the only source I trust for Boise IA garbage truck routes. This, I believe is the purpose for tools, agents and function calling in LLMs, and APIs from Descartes.
But this trust needs to be signaled to the user in the LLM response. Some measure of the original intent against the quality of the response needs to be given back to the user so that its not just an illusion of the facts and knowledge, but a verified response that the user can critically evaluate as to whether it matches their intent.
yea, I seen it alot on social media where people use ChatGPT as a source for things it possible cant know. Often with leading questions.
This is why I don't use code LLM code generators for citing or outputting a solution that includes the current code, because it's inclined to remove parts that it thinks don't matter, but rather matter a lot further down the line. And if it's not caught in code reviews, that can cause severe and difficult to debug issues. I'm sure there will be an epidemic of these issues in a few years, because developers are definitely lazy enough to rely on it.
Because there are many categories of problems where it's much easier to verify a solution than it is to come up with it. This is true in computer science, but also more generally. Having an LLM restructure a document as a table means you have to proofread it, but it may be less tedious than doing it yourself.
I agree that asking straightforward factual questions isn't one of those cases much like I agree with most of your post.
Off topic, but a funny thing about asking about George Washington's birthday is there are two possible answers because of British calendar reform in 1750 (although we've settled on recognizing the new-style date as his birthday).
footnote [a] on wikipedia: https://en.wikipedia.org/wiki/George_Washington#cite_note-3
This sounds like searching for truth is a bad thing, but instead is what has triggered every philosophical enquiry in history.
I'm quiet bullish, and think that LLMs will lead to a Renaissance in the concept of truth. Similar to what Wittgenstein did, Plato's cavern or late middle age empiricists.
Already quite a while ago I was entertained by a particular British tabloid article, which had been "AI edited". Basically the article was partially correct, but then it went badly wrong because the subject of the article was about recent political events that had happened some years after the point where LLM's training data ended. Because of this, the article contained several AI-generated contextual statements about state of the world that had been true two years ago, but not anymore.
They quietly fixed the article only after I pointed its flaws out to them. I hope more serious journalists don't trust AI so blindly.
Isn't asking an LLM "to write a Python validator" suffers from the 99.9% (or whatever the error rate for validators written by Claude) problem?
The difference is that you're asking it to perform one intellectual task (write a program) instead of 100 menial tasks (parse a file). To the LLM the two are the same level of complexity, so performing less work means less possibility of error.
Also, the LLM is more likely to fail spectacularly by hallucinating APIs when writing a script, and more likely to fail subtly on parsing tasks.
In addition to what you say, it can also be easier for a (appropriately-skilled) human to verify a small program than to verify voluminous parsing output, plus, as you say, there's the semi-automated "verification" of a very-wrong program failing to execute.
All tests have this problem. We still write them for the same reasons we do double-entry bookkeeping.
Kind of a noob question, is it possible to design a GAN type network with LLM, where one (or many) LLMs generate outputs, while a few other LLMs validate or discriminate them and thus improving generator LLMs accuracy.
Yes, you can use AI to spot errors in AI output. Done before with good results, but it requires to run 2 different, but equally good, AI models in parallel, which is way more expensive than 1 model.
"which is way more expensive than 1 model."
In this case "way more" means exactly 2x the cost.
That's far better than I would do on my own.
I doubt I'd even be 99% accurate.
If it's really 99.9% accurate for something like this - I'd gladly take it.
The problem is that people could be impressed and use it for things where 0.01% could lead to people getting hurt or even get killed.
They are just human.
They aren't the same as humans. They definitely work differently.
Also they've been trained to say something as plausible as possible. If it happens to be true, then that's great because it's extra plausible. If it's not true, no big deal.
While I have worked with one awful human in the past who was like that, most thankfully aren't!
Have two LLMs do the task and compare.
Or three or four or five! https://openreview.net/pdf?id=zj7YuTE4t8
It would be interesting to see how well does a human do it? Are they correct more than 99.9% of the time?
There's also the problem that they are tuned to be overly helpful. I tried a similar thing described in the OG article with some non-English data. I could not stop Claude from "helpfully" translating chunks of data into English.
"include description from the image" would cause it to translate it, and "include description from the image, do not translate or summarize it" would cause it to just skip it.
Can solve that to have a similar or lower error probability as a human by running the results through a verification agent.
Google's Gemini dev docs contain a few of such warnings. For a good reason, these models make stuff up and the domain where ROI is positive is small.
Yes, probably better to get the LLM to write the script.
Example, I was trying out two podcast apps and wanted to get a diff of the feeds I had subscribed to. I initially asked the LLM to compare the two OPML files but it got the results wrong. I could have spent the next 30 minutes prompt engineering and manually verifying results, but instead I asked it to write a script to compare two LLMs, which turned out fine. It's fairly easy to inspect a script and be confident it's _probably_ accurate compared to the tedious process of checking a complex output.
Sonnet on Claude.ai can not execute code, although it often pretends otherwise.
I completely agree. If correctness matters, then it’s probably better to use LLMs to write the code than to let LLMs be the code.
If it’s correct 99.9% of the time, and the piano lessons are every two weeks, that’s one error in piano lesson scheduling over 40 years. That sounds good enough to me to not verify.
I wonder if tool-calling to output schema'd json would have a low error rate here. For each field, you could have a description of what is approximately right, and that should anchor the output better than a one-off prompt.
Can Claude tdd itself ? Lean-Claude
Well for my case, I have 0 trust in chatgpt ( or local LLM) to extract properly data from a PDF file, especially if it's over a few pages.