Mitä hallusinaatiot ovat ja miksi niitä ilmenee
Hallusinaatio LLM:ssä on uskottavalta kuulostavan, mutta tosiasiallisesti virheellisen tai perustelemattoman tiedon generointi. Tämä ei ole „virhe” järjestelmävian merkityksessä — se on seuraus kielimallien toimintatavasta. LLM ei „tiedä” samalla tavalla kuin tietokanta — se ennustaa todennäköisimmän seuraavan tokenin, koulutusstatistiikan perusteella. Kun promptissa esiintyy kysymys, johon mallilla ei ole hyvää kattavuutta koulutusdatassa, se generoi „todennäköisimmin kuulostavan” vastauksen. Usein tämä vastaus on oikein. Joskus — ei.
Tyypillisiä hallusinaatioskenarioita liiketoimintasovelluksissa:
- Olemattomien oikeuden päätösten tai lakiartiklojen lainaaminen oikeudellisessa neuvonnassa
- Funktioiden, luokkien tai kirjastojen nimien keksiminen koodia generoidessa
- Virheellisten tilastojen tai päivämäärien antaminen raporteissa
- Kontaktien, osoitteiden, puhelinnumeroiden keksiminen
- Eri yritysten tai samannimisten henkilöiden faktojen sekoittaminen
Kerros 1 — Grounding (RAG)
Tehokkain yksittäinen tekniikka hallusinaatioiden vähentämiseen on grounding — konkreettisten dokumenttien tai datan tarjoaminen mallille kontekstina, josta sen on ammennettava vastauksia. Klassinen RAG (Retrieval-Augmented Generation):
- Käyttäjän kysymys → relevanteimpien dokumenttifragmenttien haku (vector search pgvector / Qdrant / Milvus -kannassa)
- Fragmentit + kysymys → prompt ohjeella „vastaa yksinomaan seuraavien dokumenttien perusteella”
- Mallin vastaus → varmistus, että se sisältää lainauksia/viittauksia lähteisiin
RAG vähentää hallusinaatioita tyypillisesti 60-80% sovelluksissa tyyppiä „vastaa kysymyksiin tietopohjastamme”. Se ei poista niitä kokonaan — malli voi silti „tulkita” dokumentteja luvattomalla tavalla. Tästä syystä tarvitaan lisäkerroksia.
Kerros 2 — Self-consistency ja ensemble
Self-consistency on tekniikka, joka koostuu saman kysymyksen esittämisestä useita kertoja (tai useille eri malleille) ja vastausten vertailusta. Kun vastaukset ovat johdonmukaisia — korkea luottamus. Kun ne eroavat — signaali siitä, että aihe on epävarma.
Käytännön variantti: kysy Claude Sonnetiltä, Llama 70B:ltä ja Bielikiltä samaa kysymystä. Jos kaikki kolme palauttavat saman numeron, päivämäärän, faktan — todennäköisesti oikein. Jos ne eroavat — eskalointi ihmiselle tai kalliimmalle mallille (Opus). Tämä malli, toteutettuna 8-tasoisessa LLM routingissa, yhdistää kustannussäästön luotettavuuden parantamiseen.
Kerros 3 — Evaluation pipelinet
LLM:n tuotantoonotto ilman evaluation pipelinea on kuin koodin kirjoittamista ilman testejä. Konkreettiset metriikat:
- Faithfulness — perustuuko vastaus toimitettuihin dokumentteihin. Mittauksesta vastaa toinen tekoälymalli (LLM-as-judge) tai RAGAS, deepeval -tyyppinen kirjasto.
- Answer relevance — vastaako vastaus käyttäjän kysymykseen.
- Context precision — palauttiko retrieval parhaat fragmentit (vector searchin laatu).
- Groundedness score — niiden vastauksen väitteiden osuus, joille voidaan osoittaa lähde kontekstista.
Jokaisen uuden LLM-pohjaisen sovelluksen buildin tulisi läpäistä 50-500 evaluaatiokysymyksen sarja tunnetulla ground truthilla. Jos faithfulness laskee alle 90% — deployment blocked.
Kerros 4 — Guardrailit ja outputin validointi
Guardrailit ovat sääntöjä, jotka validoivat LLM:n outputin ennen sen toimittamista käyttäjälle. Esimerkkejä:
- Schema validation — outputin on noudatettava tiettyä skeemaa (JSON Schema, Pydantic). Hallusinaatiot tyyppiä „keksityt kentät” havaitaan mekaanisesti.
- Forbidden patterns — kiellettyjen mallien tunnistaminen ja estäminen (PII ilman maskaamista, kontekstin ulkopuolinen taloudellinen data, mahdollisesti haitallinen sisältö).
- Citation enforcement — jokaisella faktuaalisella väitteellä on oltava lähdelainaus. Jos malli ei lainaa — vastaus hylätään.
- Numeric range validation — outputissa olevat numerot tarkistetaan järkevyyden osalta (esim. hinta > 0, päivämäärä ≤ tänään, prosenttiosuus välillä 0-100).
- Cross-reference check — outputin vertailu faktapohjaan (esim. KRS, lakilainausten sanakirja).
Kirjastoja: Guardrails AI, NeMo Guardrails, instructor (schema enforcementiin). Oma toteutus on usein yksinkertaisempi ja halvempi ylläpitää.
Kerros 5 — Human-in-the-loop
Korkean riskin sovelluksille (oikeudelliset, lääketieteelliset, taloudelliset, HR-päätökset) human-in-the-loop -kerros on välttämätön. Tekoälymallit eivät tee lopullista päätöstä — ne tukevat ihmistä. Konkreettiset mallit:
- Draft + review — tekoäly generoi dokumentin/vastauksen ensimmäisen version, ihminen varmistaa ja hyväksyy ennen lähettämistä.
- Confidence threshold — matalan confidence-arvon vastaukset (self-consistencystä tai explicit confidence askingista) eskaloidaan automaattisesti ihmiselle.
- Random sampling QA — 5-10% kaikista LLM-vastauksista auditoidaan manuaalisesti, confidence-arvosta riippumatta — perustason laatumetriikka ajassa.
- Feedback loop — käyttäjä voi merkitä virheellisen vastauksen; järjestelmä oppii ja parantaa retrievalia, prompteja, parametreja.
Mittaus — miten tietää, että vähennys toimii
Konkreettiset tuotannon metriikat, joita kannattaa seurata:
- Hallucination rate — manuaalisessa evaluaatiossa (sampling) hallusinaatioiksi luokiteltujen vastausten osuus. Tavoite: alle 2% business-critical-sovelluksille.
- User feedback rate — käyttäjien osuus, jotka merkitsivät vastauksen virheelliseksi.
- Escalation rate — ihmiselle eskaloitujen kyselyiden osuus. Liian matala (alle 5%) — järjestelmä todennäköisesti sivuuttaa epävarmoja tapauksia. Liian korkea (yli 30%) — järjestelmä ei tarjoa automaatioarvoa.
- Faithfulness score regressiotesteissä — kuukausittainen trendi.
- Time-to-correction — hallusinaation havaitsemisesta korjauksen käyttöönottoon (parempi retrieval, uusi guardrail, fine-tuning).
Johtopäätökset päättäjille
Hallusinaatiot ovat hallittavissa — ne vaativat investointia puolustusarkkitehtuuriin useilla kerroksilla. Yritykset, jotka ottavat LLM:n käyttöön ilman tätä arkkitehtuuria, ennemmin tai myöhemmin törmäävät vakavaan tapahtumaan (virheellisen tiedon julkaiseminen asiakkaalle, väärä päätös hallusinoidun datan perusteella, mainevaurio). Täyden puolustusstackin rakentamisen kustannukset (RAG + evaluation + guardrails + human-in-the-loop) ovat tyypillisesti 15-30% itse LLM:n käyttöönoton kustannuksista — ja se on ehdottoman välttämätön investointi tuotantosovelluksille. Sivuuttamisen seuraukset ovat epäsymmetrisiä: matala toimimattomuuden kustannus 95% tapauksista, katastrofaalinen 5%.