Mendeteksi dan Mengurangi Halusinasi

A hallucination is when an LLM produces text that is fluent and confident but factually wrong or unsupported by any source.

Because the output looks authoritative, hallucinations are dangerous in user-facing apps.

LLMs predict the most likely next token, not the truth. With no grounding, they fill gaps with plausible-sounding inventions.

• Missing knowledge in training data
• Ambiguous or leading prompts
• Pressure to always answer

Two broad categories:

• Factual: wrong dates, fake citations, invented APIs
• Faithfulness: answer contradicts the provided context (common in RAG)

The strongest defense is grounding: give the model trusted source text and instruct it to answer only from that text.

Ask the model to cite which passage supports each claim. Unsupported sentences become easy to spot and verify.

Higher temperature increases creativity — and invention. For factual tasks, set a low temperature so the model stays close to high-probability, well-grounded tokens.

Generate the answer several times. If the model gives different facts each run, the claim is likely a hallucination. Agreement is a weak but useful signal of reliability.

Use a second model call to check whether the answer is supported by the context. The judge returns a faithfulness verdict you can act on.

When outputs are structured, validate them. A cited URL should resolve, a quoted number should match the source, a JSON field should match a schema.

Give the model permission to say I do not know. Removing the pressure to always answer measurably reduces fabricated content.

For medical, legal, or financial outputs, route low-confidence or uncited answers to a human before showing them to users. Automation plus oversight beats either alone.

You learned to fight hallucinations: ground answers in trusted context, force citations, lower temperature, use self-consistency and LLM-as-a-judge checks, validate outputs programmatically, allow abstention, and add human review for high-stakes cases.