Hacker News Reader

Comment by camgunz | Hacker News Reader

TFA says "no hallucinations" but you can't fix hallucinations with rules or other models. I know I'm screaming into the void but whatever.

View on HN

I can't remember who it was I spoke to recently, but it was some startup for doing code reviews. So I asked how they're handling larger diffs and especially when a code change is related to something requiring knowing a lot of context. Will it hallucinate things that make the review low-quality, etc. I was told "no it's been given guardrails to prevent hallucinations. it doesn't hallucinate." but I was thinking, that's not really how LLMs do or do not hallucinate, is it? (I'm not an AI person so I really don't know).

Guardrails can and do help but they don't prevent hallucinations entirely. I generate trivia questions for my app. Questions are true/false and I tell it you must include an explanation of why the question is true for false. I also tell it to give me supporting links which validate its claim. I've had it make up explanations and invent plausible looking URLs. But I wrote a checker that pulls the content of the URL and asks a different model if the URL supports the claim. LLM's are much better at something like that than pulling a trivia question out of thin air. Reviewing diffs can be much the same. It isn't having to write the code but just evaluate if it matches what the commit comments claim it does. You are right, though. Without good comments on PR's and commits (i.e. context) the diff review is going to be a lot of assumptions made by the AI which is where hallucinations get more common.

This is a good/fast/cheap tradeoff, but in the form of accurate/precise/creative, or something in that ballpark anyway.

You can constrain the AI to be more accurate by having it a) equivocate (lose precision) or b) turning the temperature to effectively zero, thus losing "intelligence" and creativity.

There's no such thing as a free lunch. The models perform best out of the box, and everything you add into context makes them perform worse generally, but more likely to do what you want. Every token is a burden, but without those constraints the generation won't do anything.

So by that standard, hallucination is something completely core - you can't get rid of it without losing what makes them useful. You can make different tradeoffs, or use a very smart model in a way that is completely locked down (or adversarially verified, same result) which results in far more tokens used than if you just let the model do it's thing and validated for hallucination independently, outside of the generation loop.

It's like the frog prompting the scorpion not to sting him as they cross the river. Or like when image models used to routinely draw human hands incorrectly and you'd see these "prompt hacks" that would essentially be stuffed with phrases like NO DEFORMED FINGERS, NO ELDRITCH HORRORS!

You can reduce hallucinations with appropriate grounding checks. You can’t really get rid of them though, so feedback loops with verification are essential.

Error percentages compound. Having an LLM do something with a 5% hallucination rate, then having an LLM (same or different) with a 5% error rate check it means there's a 10% chance of error, not .25%. Prompting can't save you here; it's the fundamental math.

Your fundamental math is wrong

no ur wrong

Well you both seem like well educated people, so can we bring in some thinking here and determine whether it is 2.5% or 10%?

How could this be verified?

I don't think I'm good enough at math and ai research to find a reliable way.

This reminds of sensitivity vs. specificity for medical tests. You essentially have a 2x2 matrix: Error vs. non-error on one axis, and detected vs. not detected on the other. If we assume that a reviewer LLM has 95% accuracy, meaning that it produces the correct result 95% of the time it (identifying errors as errors, and identifying non-errors as non-errors), you get the following: Of 100 cases, the output of 5 is wrong, and the output of 95 is correct. Of the 5 wrong outputs, the LLM correctly identifies 4.75 (95%) as wrong. But it will also create 4.75 false positives (5% of 95). Of the 95 correct ones, the LLM correctly identifies 90.25 (95%) as correct. Therefore it creates 0.25 false negatives. So the positive predictive value is low: When the reviewer LLM flags an error, it's actually only an error 50% of the time. On the other hand, the negative predictive value is high, so in ~99.7% of cases, there will be no error if the reviewer LLM didn't catch one. All of that is assuming that the actual accuracy of the reviewer LLM is truly a flat 95% and that the base error rate is truly only 5%. I think that in reality, LLMs perform better with a certain type of tasks / errors and 5% error rate is just an average.

How errors add depend upon how you treat them.

Two independent task? You have a 95% chance of each task being correct, so total success is .95^2 = 90.25% correct.

Having two AIs verify the same task with each being 95% correct? That's a 5% error per each, so 1-(.05^2) = 99.75% correct.

That is assuming fully independent error rates, which is the real issue. If it is pure hallucinations, then that is an okay assumption, but if there are issues in the underlying prompt/data causing the error rates, then it becomes a very dangerous assumption and I think more human involvement is recommended to better understand and resolve the underlying data problem.

The real interesting bit is that more AI's mean the 2 in the above equations gets bigger, so the error rate gets worse or better depending upon which equation is in play. So if you are in an in-between landscape where you aren't sure there is independence or not (or how much independence between errors), it also becomes unclear if more AI makes the error rate better or worse.

Upvoted for real math

This. The math of coincident errors is why we can get reliable AI, but it really is a matter of how the errors manifest and how they are detected.

I’ve written a bit about this and my approach is based on clean room and N-versions.

Reliable AI is an oxymoron and deeply misleading. Even if you can stack models the efficiency tanks. Also, just looking at the Wikipedia page (https://en.wikipedia.org/wiki/N-version_programming#:~:text=...), don't LLMs already have all these problems?

You aren’t thinking this through. You were just told that this wasn’t stacking but you keep insisting it is. N-versions is explicitly not stacking, and the same solutions that solve the Knight and Leveson issue for humans solves it for LLMs as well (they can be wrong about the same part of the specification, but will very unlikely be wrong about it in the same way, so you try to measure scalar rather than Boolean outcomes).

> You aren’t thinking this through.

No need to be so polite; I might just be very stupid.

> You were just told that this wasn’t stacking but you keep insisting it is.

Having an LLM generate something and then asking another LLM to generate that something is asking for 2 hallucinations, not 1. This doesn't go away the more LLMs you throw in there. The only reason this works at all for things like ChatGPT is their prompts are super different (and the editor LLM is way cheaper, of course).

And you still have to check for hallucinations (before you say throw another hallucinating LLM at it know I will make you pay infinite forum shame points if you do).

> the same solutions that solve the Knight and Leveson issue for humans solves it for LLMs as well

No, LLMs are plagued by the same problems: https://arxiv.org/abs/2606.20158. After all what are you gonna do, say "build me a SQLite, but definitely not like [other model X] would"? The solution is a very unambiguous spec, but that asymptotically approaches code soooooo....

Finally, I think you're hand-waving NVX. A program that can digest any spec and measure how well any program meets it is pretty wild. Good luck with that one.

Doing a loop and having the model review its own earlier output tends to solve this stuff, and for code requiring good test coverage catches them before they even hit that phase.

So while you can't remove "hallucinations" they're corrected before the process is complete, albeit at the cost of more tokens for verification.

Good point, thanks. Of course I was not able to fully eliminate hallucinations, but significantly reduce

You can reduce hallucinations with rules and guardrailes for sure.

And Anthropic clearly shows that we can reduce hallucination in models. Progress is made which you can see in benchmarks.

And at the end of the day, a normal human being doesn't 'hallucinate' but 'missunderstand' things or just doesn't know what they are missing.

A LLM doesn't has to be perfect, it just has to be cheaper with the min. same quality as a human.

So why are you screaming into the void? Because LLM leave deterministic world? A lot of people don't even life in that world anyway.

you can by making a different - usually local small - model ask for verification

I hear you! I read the article and thought the same thing because I've actually built a surprisingly similar pipeline myself, but it culminates with Human review. I've got a trivia app (Hedge Calibrated Trivia) whose whole content pipeline is built on a similar architecture of models evaluating models. I didn't want the same trivia that every other app has and I naively imagined that it would be easy to ask an LLM to give me questions. Turns out when you ask an LLM for trivia questions, the FIRST thing it gives you are the same questions every other app asks!

After iterating into many of the same problems OP describes I settled into a similar pipeline. I generate questions with Gemini 3.5 flash and review with Claude. The different vendor generation and validation eliminates training holes in a single model solution. This is True/False trivia so I ask for an equal mix of True/False questions and also ask for alternate phrasing of the question to the opposite variant. Each statement must provide an explanation and sources which back up the claim. I pass in my existing dataset as questions to avoid, but found the model then rewording the questions or category shopping the questions into related categories in an attempt to re-use them. That led to using Claude Sonnet to check for duplicate "themes" and similar topics. Claude also acts as a critic of the question and the explanation. Sometimes Gemini's "thoughts" leak into the explanation. The critic catches these leaks and also catches "weak" questions (basically shapes that I have identified via examples as lazy or projecting the answer in the question). Once the comparative models have stripped out anything obviously bad, my server curls the source URLs and uses Sonnet to verify that the fetched source supports the claim. Any URL that doesn't resolve throws up flags, and I found Gemini was particularly bad at inventing source URLs for sports trivia. Updated prompting directed it to prefer Wiki links over its fabricated deep links into league websites, which helped immensely. Still one of the biggest tells in review is that the URLs don't resolve or don't confirm the statement.

But review is the entire point here. I have to review them all. A question that lands in the app and is wrong reflects terribly. So while I have a trivia app on the App Store, the real complex App is my private admin app that lets me sit on the couch swiping through each and every question sorted by the model's confidence in its own quality and correctness (weakest first). No question makes it into my bank without me reading, checking all the indicators that came from the models and potentially even rewriting the question to make it better. It all happens in the admin app and exists entirely to prevent hallucinations from reaching real users. Early on I was maybe accepting 1 in 3 questions generated, but I'm probably closer to 2/3rds now. Of course not every dismissed question is wrong. The quality checks I've put in the pipeline are probably giving me 80% questions that are correct and sourced, but sometimes they just aren't what I'm looking for or don't meet my standard.

The best thing I ever did was make an app to review these questions though. Sitting on the couch, kick off a question generation, come back 20 minutes later with 50+ questions in the queue. Sort through them and pull out the 30 best when I have the time. That's the real anti-hallucinations pipeline.

Very similar experience. The review UI might actually be the most important part of the whole pipeline. Does the confidence ranking match what you end up rejecting?

It's a future evaluation for me, as I'm keeping the app with a "Data Not Collected" App Store label for now. Once I have some visibility to stats of how people answer each question and at which confidence level I expect it to reveal bad/poorly worded questions that made it through my pipeline.

Also on my to do list is an upgrade similar to my de-duplication logic. Currently I pass in my approved set of questions as a list of topics and questions to avoid. It works well especially when combined with the more deterministic comparison of generated questions vs approved question by the separate model. The upgrade would be to pass in the questions REJECTED by me. These are question which made it through ever automated gauntlet of models and code, yet still ultimately were sent to the waste bin by human review.

I'm imagining that by including the list of examples of what NOT to do, it could inform the initial Generation to be smarter. I currently have a limited list of a hand picked "bad question shapes" where I provide the question and why its bad kept statically in my prompt. But I've realized sorting through thousands of questions, I've probably built implicit data through rejection that I may not actually recognize myself which the model may pick up on.

Reply on news.ycombinator.com