LLM Hallucinations in Practical Code Generation
1–10 of 34 posts
Re: LLM Hallucinations in Practical Code Generation
#2I thought this was a very good read about the many of the issues that are faced without having any ground truth to reason against. It is interesting how many different ways people have developed to work around missing information, and the marginal improvements it makes in some benchmarks.
Re: LLM Hallucinations in Practical Code Generation
#3This is great. We need more research into solving this fundamental problem, yet AI companies prefer to chase benchmarks and pump out value-added products.
The RAG-based mitigation is interesting, but quite limited, as mentioned. It would only work if the user can provide ground truth data, which for code generation is relatively straightforward, but it's much more difficult for most other factual information. We can't directly rely on data from the web, since the sources need to be carefully reviewed by a human first, which is the labor-intensive task that requires human domain experts.
So this approach seems like a band-aid, and wouldn't be generally applicable. I'm not in the AI industry, but from the perspective of a user it seems that the hallucination problem requires a much more foundational solution.
Re: LLM Hallucinations in Practical Code Generation
#4On the other hand, I think it's cute when LLMs hallucinate a Python library that doesn't exist, because it probably means it's worth creating into existence.
Re: LLM Hallucinations in Practical Code Generation
#5My favorite is trying to use it to generate an IAM policy and keys are just hallucinated based on expectations of what the keys would be called and are either wrong or they flat out don't exist if you are dealing with more advanced conditions.
Re: LLM Hallucinations in Practical Code Generation
#6I suspect hallucinations in LLMs are the result of contradictions in their training sets which were trained into it.
I suspect it's just like with humans. People who learn quickly and don't carefully curate their knowledge to resolve contradictions as they learn, they tend to make similar mistakes when it comes to subjects which they did not invest much time fully studying.
If I was an AI researcher, what I would try to do is find the highest quality information possible concerning very few axiomatic topics, with as few contradictions as possible, then train it into the LLM until it can generate text and basic reasoning which is fully accurate... Then once we have this basic but fully rational AI, start feeding it new data but, before giving it any piece of data to learn from, you first ask the AI to indicate if this new data contradicts any of its current knowledge. You only let it update its weights with the new data as-is if it does not contradict its existing knowledge. If it does contradict its existing knowledge, either discard it or maybe feed it the data but with some synthetic preamble like "Some people believe that..." so that it's aware of the existence of this belief system but knows that it's not to be internalized as its own beliefs.
Or maybe there is a way to do this to detect contradictions by looking at the weights themselves. You can rollback a round of training if the weights update in a way which suggests that a conflicting piece of information was learned in a specific round of training. Maybe there can be a different ANN which looks at the weights of the LLM during training and it was trained to detect contradictions and decides when to rollback a round of training.
Re: LLM Hallucinations in Practical Code Generation
#7I still don't think hallucinations in generated code matter very much. They show up the moment you try to run the code, and with the current batch of "coding agent" systems it's the LLM itself that spots the error when it attempts to run the code.
I was surprised that this paper talked more about RAG solutions than tool-use based solutions. Those seem to me like a proven solution at this point.
Re: LLM Hallucinations in Practical Code Generation
#8My favorite is trying to use it to generate an IAM policy and keys are just hallucinated based on expectations of what the keys would be called and are either wrong or they flat out don't exist if you are dealing with more advanced conditions.
> keys are just hallucinated based on expectations of what the keys would be called and are either wrong or they flat out don't exist
To be fair this is also how I generally try to write IAM configs without AI.
Re: LLM Hallucinations in Practical Code Generation
#9I suspect hallucinations in LLMs are the result of contradictions in their training sets which were trained into it. I suspect it's just like with humans. People who learn quickly and don't carefully curate their knowledge to resolve contradictions as they learn, they tend to make similar mistakes when it comes to subjects which they did not invest much time fully studying. If I was an AI researcher, what I would try…
> I suspect hallucinations in LLMs are the result of contradictions in their training sets which were trained into it.
A simpler explanation, and I posit a correct one, is people anthropomorphize an algorithm by describing the result of a particular path within a statistical model used to generate tokens as being "hallucinations" due to them being unexpected by the person interpreting the text.
> I suspect it's just like with humans.
Therein lies the problem.
Re: LLM Hallucinations in Practical Code Generation
#10This is great. We need more research into solving this fundamental problem, yet AI companies prefer to chase benchmarks and pump out value-added products. The RAG-based mitigation is interesting, but quite limited, as mentioned. It would only work if the user can provide ground truth data, which for code generation is relatively straightforward, but it's much more difficult for most other factual information. We can'…
I think there's room for more agentic systems that combine RAG, MCP and traditional static analyzer tools
For instance, RAG could be used to provide coding standards and best practices such as sanitizing user inputs used in file system lookups. MCP could be used to integrate with up to date and authoritative (official) docs. Static tools could run and analyze the results and feed errors back into the LLM to correct.
It seems a lot of tools rely on raw LLM queries and expect the IDE or other tools to take over instead of providing a consolidated experience.