LLM hallucinációk elleni 7 védekezés produkciós AI rendszerekben

Az LLM-ek hallucinálnak — nem hiba, hanem a generatív modellek természete. Az autoregresszív modellek minden token-választást valószínűségi distribution alapján döntenek, és semmi nem garantálja, hogy a választás faktually helyes. A produkciós AI-rendszernek nem azt kell ígérnie, hogy nincs hallucinatio (mert ezt senki nem tudja garantálni), hanem hogy a hallucinatio rate mérhető és elfogadható szinten van.

Ebben a cikkben 7 bevett védekezést mutatok, amelyek együtt 60-70%-os baseline pontosságról 92-95%-ra emelnek a legtöbb domainen. A technikák stack-elődnek — nem alternatívák, hanem kiegészítők.

Mi a hallucinatio és hol jelentkezik

A „hallucinatio" gyűjtőfogalom — három különböző jelenséget takar:

1. Factual hallucinatio: a modell olyan tényt állít, ami nem igaz. Pl. „A 2024-es szállítási SLA Q4 lemorzsolódási küszöbje 8%" — miközben a dokumentumban 12% szerepel.
2. Source hallucinatio: a modell forrásra hivatkozik, ami nem létezik. Pl. „A 4.2.1-es szabályzat-pont szerint..." — de nincs 4.2.1-es pont.
3. Reasoning hallucinatio: a modell helyes adatból helytelen következtetést von le. Pl. „Mivel a szabadságkeret 25 nap, és X már 24-et felhasznált, nincs joga ezen a héten szabadságra" — de a szabályzat 30 napot ír.

A három különböző védekezést igényel. A factual-t RAG és citation kezeli, a source-t schema-validation és forrás-ellenőrzés, a reasoning-t self-consistency és human-in-the-loop.

Hol jelentkezik produkciós-szinten

Tapasztalataink szerint a hallucinatio leginkább az alábbi 4 helyzetben jön elő:

• Out-of-domain query — a felhasználó olyan kérdést tesz fel, amire nincs forrás a vector DB-ben. A modell „kitölti a rést" fantázia-válasszal.
• Részleges forrás — a forrás-chunk csak részben tartalmazza a választ, és a modell extrapolál.
• Konfliktuáló források — két chunk eltérő infót ad, a modell az egyiket választja, vagy összeolvaszt.
• Long-tail edge case — szokatlan, ritka kérdés, amire a training-data alig fedte.

A 7 védekezés ezen 4 forgatókönyvre van designolva.

1. Context grounding (RAG)

A leghatékonyabb technika: ne hagyd az LLM-et szabadon generálni — mindig adj neki kontextust. A Retrieval-Augmented Generation lényege, hogy a vector DB-ből kihúzott releváns dokumentumokat ad át a system prompt-ban, és explicit instruktálja: „csak a forrásokból válaszolj".

Az alap pattern

system_prompt = """
You are a documentation assistant.
ONLY answer based on the SOURCES below.
If the sources don't contain the answer, say "I don't know".

SOURCES:
[1] {source_1}
[2] {source_2}
[3] {source_3}

Question: {user_query}
"""

A „csak a forrásokból" instrukció önmagában nem garancia — de a precizitást baseline-hoz képest 20-30 ponttal emeli. A RAG-pipeline részletes implementációja: RAG chatbot építése.

Negatív promptolás

Az „I don't know" expliciten engedélyezett kimenet kell, hogy legyen. Az LLM-ek default-hajlama az „is segítőkész", ami arra ösztönöz, hogy minden kérdésre adjon választ. Ezt felül kell írni:

"""
IMPORTANT:
- If the sources don't contain the answer, output EXACTLY: "Nem találtam egyértelmű választ a dokumentumokban."
- Do NOT speculate or guess.
- Do NOT use general knowledge from your training data.
- Do NOT combine information from sources unless they explicitly support each other.
"""

Ezek az anti-instrukciók 15-20 pp-pal csökkentik a factual hallucinatio rate-et.

Source attribution required

A system prompt-ban explicit követelmény, hogy minden válasz hivatkozzon legalább egy forrásra. Ha nincs forrás, a válasz nem engedélyezett.

Mérhető hatás

Setup	Factual accuracy (eval-szet)
LLM only (no RAG)	45-55%
RAG with naive prompt	70-78%
RAG with grounding instructions	85-92%

2. Citation requirement

Ne csak választ kérj az LLM-től, hanem forrás-azonosítót is. Két előny: (1) az LLM kevésbé találja ki a választ, mert tudja, hogy forrás-linket kell adnia, (2) a felhasználó tudja ellenőrizni.

Implementáció

system_prompt = """
For EVERY factual claim in your answer, cite the source ID in square brackets, e.g. [1].
If you cannot cite a source for a claim, do not make the claim.
If a sentence has no citation, you are not allowed to write it.

Format example:
"A szabadságkeret 25 nap [2]. Ezt minden évre január 1-jével adják ki [2, 5]."
"""

Post-processing validation

import re

def validate_citations(response: str) -> dict:
    sentences = re.split(r"(?<=[.!?])\s+", response.strip())
    factual_sentences = [s for s in sentences if not is_intro_or_summary(s)]
    
    no_citation = [
        s for s in factual_sentences
        if not re.search(r"\[\d+(?:,\s*\d+)*\]", s)
    ]
    
    return {
        "total_sentences": len(factual_sentences),
        "uncited_sentences": no_citation,
        "passes": len(no_citation) == 0,
    }

Ha vannak uncited_sentences, a válasz nem engedi át a quality gate-en. Vagy újra-generation, vagy human-handoff.

Citation gyakoriság mérése

Egy jól tunolt rendszerben a mondatok 80-90%-a citation-nal jön. Ha ez 50% alatt van, a modell ignorálja az instrukciót — promptot finomítani kell.

Tipp: A citation-igény mellékhatása a tömörebb válasz. Az LLM-ek hosszú, „szakértőnek tűnő" magyarázatokat szeretnek generálni — ezek 60-70%-a citation nélkül marad. A citation-enforcement automatikusan rövidíti a válaszokat a hivatkozható részekre.

3. Temperature és top_p tuning

A temperature és top_p paraméterek határozzák meg a modell „kreativitását". Magas érték = több variabilitás = nagyobb hallucinatio-kockázat. Alacsony érték = deterministic-ebb = kevesebb hallucinatio.

A két paraméter

• temperature (0.0-2.0): a logit-distribution flatness-je. 0 = mindig a top-1 token, 2 = közel uniform.
• top_p (0.0-1.0): a kumulatív valószínűségi cutoff. 0.1 = csak a top 10% valószínűségű tokenek közül választ.

Egyszerre csak az egyiket állítsd be (a másikat hagyd default-on). Az OpenAI dokumentáció is ezt javasolja.

Per-use-case ajánlás

Use case	Javasolt temperature	Javasolt top_p
RAG factual Q&A	0.0-0.2	0.1-0.3
Doc summarization	0.1-0.3	0.2-0.4
Tutorial / explanation	0.2-0.4	0.3-0.5
Marketing copy	0.5-0.7	0.6-0.8
Brainstorming, divergent	0.7-1.0	0.8-0.95
Code generation	0.0-0.2	0.1-0.3

Megjegyzés a temperature=0-ról

temperature=0 nem garantálja a deterministic output-ot — a token-tie-break maradhat stochastic, és az LLM-providerek nem mindig hoznak teljes determinizmust. A seed paraméter (OpenAI támogatja) segít, de nem 100%.

Kód példa

response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[...],
    temperature=0.1,
    seed=42,  # for reproducibility
    max_tokens=500,
)

4. Self-consistency checking

Kritikus válaszokra futtasd le a generation-t 3 különböző seed-del (temperature=0.3, 3 különböző random seed). Ha mindhárom ugyanazt mondja, magas confidence. Ha eltérés van, jelezzük a felhasználónak vagy human-in-the-loop fallback.

Implementáció

def self_consistency_check(prompt: str, seeds: list[int] = [42, 100, 7]) -> dict:
    responses = []
    for seed in seeds:
        response = llm.generate(
            prompt,
            temperature=0.3,
            seed=seed,
            max_tokens=500,
        )
        responses.append(response)
    
    return {
        "responses": responses,
        "consistent": all_semantically_equivalent(responses),
        "majority_vote": majority(responses),
    }

A all_semantically_equivalent egy második LLM-hívással mérhető (egy „judge" LLM, ami megnézi, hogy a 3 válasz lényegében ugyanazt mondja-e), vagy egyszerű substring-overlap-pel (ROUGE-L score > 0.85).

Költség és mikor használd

3x annyi API-call mint a sima single-generation. Csak kritikus döntésekre (orvosi, jogi, pénzügyi). Egy egyszerű FAQ-chatbot-on overkill.

Aggregation strategy

Ha a 3 válasz eltér:

• Majority vote: ha 2 azonos, 1 eltérő → a többségi.
• Hedge: ha mindhárom eltér → „A válaszra több értelmezés is létezik. [forrás-citáció a mindhárom esetre]."
• Escalate: kritikus kontextusban azonnal human-handoff.

5. Output validation (JSON schema, regex)

Ha az LLM strukturált adatot ad ki (kategória, score, JSON-objektum), validáld a schema ellen. Az OpenAI JSON mode és Anthropic tool use már API-szinten kényszerít schema-t, de a post-validation továbbra is kell.

Pydantic + OpenAI

from pydantic import BaseModel, Field
from typing import Literal
import openai

class LeadClassification(BaseModel):
    category: Literal["technical", "commercial", "complaint", "partnership"]
    urgency: int = Field(ge=0, le=100)
    confidence: float = Field(ge=0.0, le=1.0)
    follow_up_draft: str = Field(max_length=500)
    reasoning: str = Field(max_length=200)

response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[...],
    response_format={"type": "json_object"},
    temperature=0.1,
)

try:
    result = LeadClassification.model_validate_json(
        response.choices[0].message.content
    )
except ValidationError as e:
    # Retry, fallback, or human queue
    handle_invalid_output(e)

Structured Output (OpenAI 2024+)

Az OpenAI 2024-ben bevezette a response_format mellé a Structured Outputs feature-t. A schema kötelező betartása provider-szinten garantált:

response = openai.chat.completions.create(
    model="gpt-4o-2024-08-06",
    messages=[...],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "lead_classification",
            "schema": LeadClassification.model_json_schema(),
            "strict": True,
        },
    },
)

A strict: True mellett a schema-violation gyakorlatilag eliminálható.

Retry strategy

Ha a validation fails, retry max 2x. A 2. retry-ban explicit a system prompt-ban jelezzük az előző hibát:

def call_with_retry(prompt, schema, max_retries=2):
    for attempt in range(max_retries + 1):
        response = llm.generate(prompt)
        try:
            return schema.model_validate_json(response)
        except ValidationError as e:
            if attempt < max_retries:
                prompt = augment_prompt_with_error(prompt, e)
            else:
                return fallback_default()

Mérhető hatás

Schema-validation nélkül a malformed-JSON rate 3-8% production-szinten. Schema-validation-nel ez < 0.5%.

6. Confidence scoring + threshold

Kérd meg az LLM-et, hogy adjon confidence score-t a saját válaszára. Nem perfect (az LLM hajlamos overconfident lenni), de gyakran mégis jelzi az edge case-eket.

System prompt

After your answer, output a confidence score on a scale of 0-100:
- 90-100: Sources clearly and completely support the answer
- 70-89: Sources support, but some inference needed
- 50-69: Partial support, some details missing
- 30-49: Weak support, significant gaps
- <30: Insufficient sources, answer is uncertain

Output format:
ANSWER: [your answer with citations]
CONFIDENCE: [0-100]
REASONING: [why this confidence level]

Threshold-based routing

def route_by_confidence(response: dict) -> str:
    if response["confidence"] >= 80:
        return "auto_send"
    elif response["confidence"] >= 50:
        return "auto_send_with_flag"  # "Ellenőrizd:"
    elif response["confidence"] >= 30:
        return "human_review_queue"
    else:
        return "explicit_not_found"

A 4 fokú routing produkciós-tapasztalat alapján működik a legjobban. A „flag" verzió hasznos a marketing-szövegekre — az LLM 60% confidence-en gyakran helyes, csak nem teljesen biztos.

Calibration ellenőrzés

Az LLM-ek 80-90%-os confidence-en gyakran csak 60-70% accuracy-t hoznak — overconfident. Ezt manuálisan kalibrálni kell. Tipikus tuning:

Modell-confidence	Tényleges accuracy	Use case
90-100	88-95%	Auto-send
70-89	75-85%	Auto-send (flagged)
50-69	55-70%	Human review
30-49	30-50%	Explicit „nem találtam"
<30	<30%	Explicit „nem találtam"

Az eval-szet alapján mérhető, és threshold-ot ehhez kell igazítani.

Tipp: A confidence score nem helyettesíti az eval-szettet. Egy modell mondhat 95% confidence-et, de a valódi accuracy 70%. A két számot külön kell tracking-elni.

7. Human-in-the-loop fallback

A 6 fenti technika sem lesz 100%. Tervezz egy rugalmas escalation path-t:

A 4 sávos modell

┌─────────────────────────────────────────────────────────┐
│ High confidence + citation + schema valid               │
│   → Auto-response                                       │
├─────────────────────────────────────────────────────────┤
│ Medium confidence (50-70) + valid                       │
│   → Auto-response, flag "Kérlek, ellenőrizd"            │
├─────────────────────────────────────────────────────────┤
│ Low confidence (<50) OR uncited sentences               │
│   → Human review queue                                  │
├─────────────────────────────────────────────────────────┤
│ No sources found OR validation fails 2x                 │
│   → Explicit "nem találtam információt" + ticket-nyitás │
└─────────────────────────────────────────────────────────┘

Implementáció

def handle_query(query: str) -> dict:
    response = generate_with_rag(query)
    
    if not response["citations"]:
        return {"action": "queue", "reason": "no_citations"}
    if not response["schema_valid"]:
        return {"action": "queue", "reason": "invalid_schema"}
    if response["confidence"] < 50:
        return {"action": "queue", "reason": "low_confidence"}
    if response["confidence"] < 70:
        return {"action": "auto_with_flag", "flag": "verify_recommended"}
    return {"action": "auto", "response": response["text"]}

Queue management

A human-review queue tipikus mérete: 5-15% a teljes forgalomnak. Az ügyfél belső csapata (sales, support) gyorsan ellenőriz (átlag 30-60 másodperc / case), és a tanulság az eval-szet bővítéséhez kerül.

Feedback loop

A human-review során elutasított / korrigált válaszok két helyre kerülnek:

1. Eval-szet bővítés: ez most már egy ismert „nehéz" eset.
2. Prompt-fine-tune: ha 5+ hasonló típusú hiba, a system prompt-ba beépítjük az exceptiont.

Eval-szett — a kulcs mindenhez

A 7 technika önmagában csak akkor mérhető, ha van eval-szett. Min. 50-200 manuálisan címkézett input-output pár, balanszolt a use case eloszlásra.

Minimum struktúra

eval_dataset = [
    {
        "id": "eval_001",
        "query": "Mit ír a 2024-es szállítási SLA a Q4 lemorzsolódásról?",
        "expected_keywords": ["Q4", "lemorzsolódás", "12%"],
        "expected_citation": ["doc_42_chunk_3"],
        "category": "factual_extraction",
        "difficulty": "easy",
    },
    {
        "id": "eval_002",
        "query": "Mikor változott a szállítási SLA?",
        "expected_keywords": ["nincs egyértelmű választ"],  # negative case
        "expected_citation": [],
        "category": "out_of_domain",
        "difficulty": "medium",
    },
    # ...
]

Metrikák

Metrika	Definíció	Cél
Faithfulness	A válasz csak a forrásokra támaszkodik-e	95%+
Answer relevancy	A válasz a feltett kérdésre szól-e	90%+
Context precision	A retrievelt chunkok relevánsak-e	80%+
Citation accuracy	A citation-ok valós forrásra mutatnak-e	99%+
Schema validity	A JSON output schema-konform-e	99%+
Confidence calibration	Confidence vs accuracy korreláció	±10%

A Ragas framework ezeket a metrikákat automatizálva számolja.

Karbantartás

Az eval-szet karbantartása napi feladat:

• Új edge case-ek → eval-szet (a hyper-care alatt 5-10 új case / hét tipikus).
• Felhasználói feedback (negatív) → eval-szet — egy „rossz válasz" report mindig kiindulópont.
• Promptváltozások → regression-teszt az eval-szet ellen. Ha pontosság < threshold → blocked deploy.

A CI/CD pipeline-ban:

# .github/workflows/eval.yml
on:
  pull_request:
    paths:
      - "prompts/**"
      - "src/llm/**"
jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run eval suite
        run: python eval/run.py --threshold 0.92
      - name: Block on failure
        if: failure()
        run: exit 1

Mérési framework — Ragas és társai

A 2025-2026-ban kiérlelt open-source eval-framework-ök:

• Ragas: RAG-specifikus metrikák. Python alapú, OpenAI/Anthropic API-ra építve. Default választás.
• DeepEval: Pytest-szerű asserting framework LLM-output-ra. Jó CI-integrációra.
• promptfoo: Web UI-alapú prompt-comparison tool. Jó a manuális tuning fázisra.
• OpenAI Evals: OpenAI saját framework-je, kicsit nehézkesebb.

A Corevanix-projekteken Ragas + DeepEval kombinációt használunk: Ragas a quality-metrikákra, DeepEval a CI-blocking assert-ekre.

Összefoglaló — a 7 technika kombinálva

A 7 technika nem helyettesíti egymást — együtt működnek. Egy production-grade rendszerben jellemzően:

Technika	Cost-impact	Accuracy-impact	Kötelező?
1. Context grounding (RAG)	$$$	+25-30 pp	Kötelező
2. Citation requirement	$	+5-8 pp	Kötelező
3. Temperature tuning	$0	+3-5 pp	Kötelező
4. Self-consistency	$$$$	+5-10 pp	Csak kritikus
5. Schema validation	$	+2-3 pp	Kötelező strukturált output-ra
6. Confidence scoring	$	+5-8 pp (routing-on)	Erősen ajánlott
7. Human-in-the-loop	n/a	+10-15 pp (effective)	Kötelező első hónapokban

A teljes stack: +60-70 pp javulás a baseline-hoz képest. Ez gyakran az „45% accuracy → 92%+ accuracy" ugrást jelenti.

Mérési metrikák — ROUGE, BERTScore, és tovább

A klasszikus NLP-metrikák (ROUGE, BLEU) szöveg-overlap-ot mérnek, ami LLM-output-ra nem mindig informatív. A modern alternatívák:

• ROUGE-L: longest common subsequence. Tömör, kevés strukturált válaszra jó.
• BERTScore: kontextuális embedding-similarity. Semantic-equivalence-re érzékenyebb.
• LLM-as-a-Judge: egy második („judge") LLM értékel. Drágább, de a legközelebb a human judgment-hez.

A Corevanix-projekteken LLM-as-a-Judge + BERTScore kombinációt használunk az eval-szetre, plus regex-based exact-match metrikákat strukturált output-ra.

Domain-specifikus megfontolások

Orvosi / jogi / pénzügyi

Extra szigorú: minden esetben citation, minden esetben self-consistency, minden „uncited" sentence emberi review-ra. Az automatic-rate jellemzően 30-50%, a többi human-queue.

Marketing / kreatív

Lazább: temperature 0.5-0.7 megengedett, citation nem kötelező, self-consistency kihagyható. A „hallucinatio" itt gyakran feature, nem bug — kreatív megoldásokat akarunk.

Technical support / dokumentáció

Standard: RAG + citation + low temperature + schema + confidence + threshold. Self-consistency csak ritka, high-stakes esetekre.

Lezárás

Hallucination-mentes AI-t senki nem tud ígérni 2026-ban — de a 7 fenti technika együtt egy produkciós-grade rendszert ad. A baseline 60-70% → 92-95% pontosság-ugrás reális, és mérhető.

A 7 technika közül 4 (RAG, citation, temperature, schema) kötelező minden produkciós AI-rendszerben. A többi 3 (self-consistency, confidence, human-in-the-loop) use case-függő.

A legnagyobb hiba: a 7 technika közül 1-2-t bevezetni és „kész". A védekezés stackelt. RAG + citation együtt jó, magában gyengébb. Confidence + human-handoff együtt működik, külön-külön majdnem haszontalan.

Az eval-szet a projekt gerinc. Eval-szet nélkül nem tudod, hogy a tegnapi prompt-változás javított vagy rontott — a produkció vakon van.

Témához kapcsolódó saját cikkeink: RAG chatbot építése — a context-grounding mély bemutatása. Lead asszisztens AI — éles projekt-tapasztalat 94%-os eval-accuracy-vel. AI implementáció magyar KKV-knál — KKV-specifikus eval-strategy és ROI.

Hivatalos doc-ok és további olvasmányok:

• OpenAI Structured Outputs — schema enforcement
• Anthropic Prompt Engineering — Claude-specifikus tippek
• Ragas dokumentáció — eval metrikák
• „Why Language Models Hallucinate" paper (2024) — academic context

Ha AI-rendszert tervezel produkcióba, beszéljük át a discovery-n, hogy a 7 technikából melyik kombináció illik a use case-edhez. A discovery-fázis (200-400k Ft) tipikusan tisztázza, melyik szint van indokolva — egy belső FAQ-chatbot-hoz nem ugyanaz a stack kell, mint egy ügyfél-tanácsadó rendszerhez.