Tudásforrás-kötés (grounding)

A Nortinia AI Asszisztens szigorúan tenant-saját tudásbázist (KB) használ minden kérdésre, ami nem közismereti vagy nem in-app művelet. Ez a cikk leírja a retrieval-then-generate folyamatot, a hallucináció-elleni guard-ot, és a 2026 májusi eval eredményeit.

A tudásbázis felépítése

Minden tenant feltöltheti a saját dokumentumait (PDF, DOCX, Markdown, HTML) az asszisztens-admin felületen. A feltöltött anyag a háttérben:

1. Chunkolva — átlag 800 token darabokra vágjuk, 100 token átfedéssel a határoknál.
2. Embeddelve — OpenAI text-embedding-3-large modellel vektorizáljuk.
3. Indexelve — pgvector-on tároljuk, tenantId-vel scope-olva.
4. Citáció-metaadattal ellátva — dokumentum-cím, page-range, feltöltés-dátum, feltöltő.

A tenant tipikusan 20-200 dokumentumot tölt fel: ÁSZF, GDPR-szabályzat, belső eljárások, termék-katalógus, gyakori kérdések.

Retrieval-then-generate

Minden tudásalapú kérdésnél ("mi a visszatérítési politikánk?", "hány nap a szállítás Slovákiába?") a flow:

1. Retrieval — a felhasználói kérdést embeddeljük, és lekérdezzük a top-5 leginkább releváns chunk-ot a tenant KB-jéből.
2. Relevance check — ha a top-1 chunk cosine-similarity-je < 0.72, a rendszer NEM hív LLM-et a generálásra, hanem visszaadja: "Erre a kérdésre nem találtam információt a tudásbázisában."
3. Generate — ha van releváns chunk, az LLM kap egy szigorú prompttal: "válaszolj KIZÁRÓLAG a megadott kontextus alapján, idézz citációval, ha nincs benne az infó, mondd, hogy nincs."
4. Citation embedding — a válaszban minden tényállítás után automatikusan ott a [1], [2] hivatkozás, ami a chunk forrására mutat (dokumentum + oldal).

A hallucináció-elleni guard

Az LLM válaszát egy második modell (post-process step) ellenőrzi: minden tényállítást párosít a hivatkozott chunk-kal, és ha a chunk-ban nincs benne az állítás, jelez. Ha 2 vagy több jelzés van, az asszisztens átfogalmazza a választ szűkebbre, vagy "nem találtam" választ ad.

Ez extra latency (átlag +400ms), de a hallucinációt 96.4%-ra csökkentette (lásd lent).

A 412-kérdéses eval

2026 májusban összeállítottunk egy 412-kérdéses reference set-et 5 tenant ügyfél-KB-jén. A kérdéseket úgy építettük, hogy:

• 60% — egyértelmű "van a KB-ben" típus (válasz citációval várt)
• 30% — "nincs a KB-ben" típus ("nem találtam" válasz várt)
• 10% — "félrevezető" típus (KB-ben van hasonló, de nem pontos válasz)

A mérés:

• Grounded-only válaszok aránya: 96.4% (398/412)
• Hibás citáció: 1.7% (7/412) — a válasz jó, de rossz chunk-ra hivatkozott
• Hallucinált válasz: 0.5% (2/412) — KB-ben nem létező tényt állított
• Túl konzervatív ("nem találtam" amikor lett volna): 1.4% (6/412)

A 0.5%-os hallucinációs ráta már GA-küszöb alatt van. Összehasonlításul: ugyanaz a kérdéssor egy nyers gpt-5-en, KB nélkül, 38% hallucinációs rátát adott.

Mit nem grounding-olunk

Két dolgot szándékosan ráhagyunk az LLM "saját" tudására:

1. Közismereti tények — "hány hónap van egy évben", "mi a HU áfa kulcs általában". Itt a grounding overhead nem éri meg.
2. In-app műveletek — "navigálj a számlához", "hozz létre refund-ot". Itt nem tudás-kérdés van, hanem MCP tool-hívás. Külön út.

A határ-eset ("mi a HU EU-belüli áfa kulcs 2026 júliusától") tudás-kérdésnek számít, és ha a tenant KB-ben nincs benne, a rendszer azt mondja: "nem találtam, javaslom a NAV-honlapot ellenőrizni".

Per-tenant izoláció

Az egyik legfontosabb szabály: tenant A KB-je SOHA nem szivárog tenant B felé. A pgvector lekérdezésen kötelező tenant_id = $current filter van; két integration-test minden release-ben (és egy chaos-test havonta) garantálja, hogy ez a filter nem törhető át prompt injectionnel sem.

Mi a roadmap

Két nagy fejlesztés van soron: (1) cross-document reasoning — ha a válasz két különböző dokumentum chunk-jának kombinációja kell, a retrieval mostani top-5 nem mindig hozza mindkettőt; multi-hop retrieval kell. (2) auto-refresh KB — naponta scan-elés, hogy a tenant Drive-jában új doksi került-e, és auto-import (opt-in).