
# Lekérdezés‑támogatott generálás adaptív kérdésmintákkal a biztonságos kérdőív‑automatizáláshoz

A SaaS megfelelőség gyorsan változó világában a biztonsági kérdőívek minden új szerződés kapuját jelentik. A csapatok még mindig óriási mennyiségű időt töltenek politikai dokumentumok, bizonyíték‑tárolók és korábbi audit‑anyagok átkutásával, hogy olyan válaszokat készítsenek, amelyek megfelelnek a szigorú auditorok elvárásainak. A hagyományos, AI‑segítségű válaszgenerátorok gyakran elmaradnak, mivel statikus nyelvi modellel dolgoznak, amely nem tudja garantálni a hivatkozott bizonyítékok frissességét vagy relevanciáját.  

**A Retrieval‑Augmented Generation (RAG)** áthidalja ezt a szakadékot azáltal, hogy a nagy nyelvi modellel (LLM) valós időben, a kontextus‑specifikus dokumentumokat adja meg a lekérdezéskor. Amikor a RAG‑ot **adaptív kérdésmintákkal** párosítjuk, a rendszer dinamikusan alakíthatja a lekérdezést az LLM felé a kérdőív tartománya, kockázati szintje és a lekért bizonyíték alapján. Az eredmény egy zárt hurokú motor, amely **pontos, auditálható és megfelelőségi** válaszokat generál, miközben az emberi compliance‑tiszthez is visszacsatol a validáció érdekében.

Az alábbiakban végigvezetjük az architektúrát, a prompt‑mérnöki módszertant és a működési legjobb gyakorlatokat, amelyekből ez a koncepció egy termelés‑kész szolgáltatássá alakul bármely biztonsági kérdőív‑folyamatban.

---

## 1. Miért nem elég csak a RAG?

Egy egyszerű RAG‑pipeline általában három lépést tartalmaz:

1. **Dokumentum‑lekérdezés** – Vektoros keresés egy tudásbázison (policy PDF‑ek, audit‑logok, beszállítói nyilatkozatok) a legrelevánsabb **k** szakasz visszaadásával.  
2. **Kontekstus‑betáplálás** – A lekért szakaszokat a felhasználói kérdéssel összefűzik, és egy LLM‑nek adják.  
3. **Válaszgenerálás** – Az LLM szintetizál egy választ, időnként idézve a lekért szöveget.

Bár ez a tényszerűséget növeli a tiszta LLM‑hez képest, gyakran **prompt brittleness‑t** (széteső promptot) eredményez:

- Különböző kérdőívek hasonló koncepciókat kérdeznek, de finom eltérések a megfogalmazásban. Egy statikus prompt túlgenerálhat vagy hiányozhat a szükséges megfelelőségi megfogalmazás.  
- A bizonyíték relevanciája változik, ahogy a policy‑k frissülnek. Egyetlen prompt nem tud automatikusan alkalmazkodni az új szabályozási nyelvhez.  
- Az auditorok **nyomonkövethető idézeteket** igényelnek. A tiszta RAG gyakran idéz anélkül, hogy egyértelmű hivatkozási szintaxist biztosítana, ami az audit‑nyomvonalhoz szükséges.

Ezek a hiányosságok indokolják a következő réteget: **adaptív kérdésminta‑sablonok**, amelyek a kérdőív kontextusával együtt fejlődnek.

---

## 2. Az adaptív RAG tervrajzának fő komponensei

```mermaid
graph TD
    A["Incoming Questionnaire Item"] --> B["Risk & Domain Classifier"]
    B --> C["Dynamic Prompt Template Engine"]
    C --> D["Vector Retriever (RAG)"]
    D --> E["LLM (Generation)"]
    E --> F["Answer with Structured Citations"]
    F --> G["Human Review & Approval"]
    G --> H["Audit‑Ready Response Store"]
```

- **Risk & Domain Classifier** – Egy könnyű LLM vagy szabály‑alapú motor címkézi minden kérdést kockázati szint (magas/közepes/alacsony) és domén (hálózat, adat‑magánélet, identitás stb.) szerint.  
- **Dynamic Prompt Template Engine** – Egy újrahasználható prompt‑töredékek (intro, policy‑specifikus nyelv, idézet‑formátum) könyvtárát tárolja. Futásidőben a klasszifikátor kimenet alapján választja ki és állítja össze a töredékeket.  
- **Vector Retriever (RAG)** – Hasonlósági keresést végez egy *verziózott* bizonyíték‑tárolón. A tároló beágyazásokkal és metaadatokkal (policy verzió, lejárati dátum, ellenőr) van indexelve.  
- **LLM (Generation)** – Lehet egy saját modell vagy nyílt forráskódú LLM, amely a compliance‑nyelvre finomhangolt. Tiszteletben tartja a strukturált promptot, és markdown‑stílusú válaszokat ad explicit idézet‑azonosítókkal.  
- **Human Review & Approval** – Egy UI szakasz, ahol a compliance‑elemzők ellenőrzik a választ, szerkesztik az idézeteket, vagy kiegészítő narratívát adnak hozzá. A rendszer minden szerkesztést naplóz a nyomonkövethetőség érdekében.  
- **Audit‑Ready Response Store** – A végső választ a pontos bizonyíték‑pillanatképekkel együtt tárolja, lehetővé téve egy **egyes forrás igazságát** bármely jövőbeli audit számára.

---

## 3. Adaptív kérdésminta‑sablonok felépítése

### 3.1 Sablon‑granularitás

A kérdés‑töredékeket négy ortogonális dimenzió szerint kell rendezni:

| Dimenzió | Példaértékek | Ok |
|----------|--------------|----|
| **Kockázati szint** | `magas`, `közepes`, `alacsony` | Meghatározza a részletesség és a szükséges bizonyíték‑szám szintjét. |
| **Szabályozási kiterjedés** | `[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)`, `[ISO 27001](https://www.iso.org/standard/27001)`, `[GDPR](https://gdpr.eu/)` | Beilleszti az adott szabályozás jellegzetes megfogalmazását. |
| **Válasz stílusa** | `rövid`, `narratív`, `táblázatos` | Illeszkedik a kérdőív elvárt formátumához. |
| **Hivatkozás módja** | `beleágyazott`, `lépészet`, `függelék` | Teljesíti az auditorok preferenciáit. |

Egy sablon‑töredéket egyszerű JSON/YAML katalógusban lehet tárolni:

```yaml
templates:
  high:
    intro: "Jelenlegi kontrolljaink alapján megerősítjük, hogy"
    policy_clause: "Tekintse meg a **{{policy_id}}** policy‑t a részletes irányelvekért."
    citation: "[[Bizonyíték {{evidence_id}}]]"
  low:
    intro: "Igen."
    citation: ""
```

Futásidőben a motor a következőt állítja össze:

```
{{intro}} {{answer_body}} {{policy_clause}} {{citation}}
```

### 3.2 Prompt összeállítási algoritmus (pseudokód)

```goat
func BuildPrompt(question Question, evidence []Evidence) string {
    risk := ClassifyRisk(question)
    scope := IdentifyRegulation(question)
    style := ChooseStyle(question)
    tmpl := LoadTemplate(risk, scope, style)

    // Dinamikus mezők beillesztése
    prompt := strings.ReplaceAll(tmpl.intro, "{{policy_id}}", evidence[0].PolicyID)
    prompt = strings.ReplaceAll(prompt, "{{answer_body}}", "{{USER_ANSWER}}")
    prompt = strings.ReplaceAll(prompt, "{{evidence_id}}", evidence[0].ID)

    return prompt
}
```

A **`{{USER_ANSWER}}`** helyőrzőt később az LLM‑generált szöveg fogja helyettesíteni, biztosítva, hogy a végső kimenet pontosan a sablonban meghatározott szabályozási nyelvet kövesse.

---

## 4. Auditálható bizonyíték‑tár tervezése

Egy megfelelőségi bizonyíték‑tárnak három alapelvet kell betartania:

1. **Verziózás** – Minden dokumentum beillesztése után immutábilis; a frissítések új verziót hoznak létre időbélyeggel.  
2. **Metaadat‑gazdagítás** – Tartalmazzon mezőket, mint `policy_id`, `control_id`, `effective_date`, `expiration_date`, és `reviewer`.  
3. **Hozzáférési audit** – Minden lekérdezési kérést naplózzon, a lekérdezés hash‑ét összekapcsolva a kiszolgált dokumentum pontos verziójával.

Gyakorlati megvalósításként egy **Git‑alapú blob‑tárolót** kombinálhatunk egy vektor‑indexszel (pl. **FAISS** vagy **Vespa**). Minden commit a bizonyíték‑könyvtár egy pillanatképét jelenti; ha az auditor egy adott dátumra vonatkozó bizonyítékot kér, a rendszer visszakapcsol a megfelelő commit‑hoz.

---

## 5. Ember‑a‑hurok (Human‑in‑the‑Loop) munkafolyamat

Még a legfejlettebb prompt‑mérnöki megoldásoknál is egy compliance szakembernek kell jóváhagynia a végső választ. Egy tipikus UI‑folyam:

1. **Előnézet** – Megjeleníti a generált választ kattintható idézet‑azonosítókkal, amelyek kibontják az alapszöveget.  
2. **Szerkesztés** – Lehetővé teszi a szakembernek, hogy finomhangolja a megfogalmazást vagy egy frissebb dokumentummal cserélje az idézetet.  
3. **Jóváhagyás / Elutasítás** – Jóváhagyáskor a rendszer rögzíti minden idézett dokumentum verzió‑hash‑ét, egy immutábilis audit‑nyomvonalat hozva létre.  
4. **Visszacsatolás** – A szerkesztéseket egy **reinforcement learning** modulba tápláljuk, amely a jövőbeli prompt‑kiválasztási logikát finomítja.

---

## 6. Siker‑mérés

Egy adaptív RAG‑megoldás bevezetését mind a **sebesség**, mind a **minőség** mutatók alapján kell értékelni:

| KPI | Definíció |
|-----|-----------|
| **Átfutási idő (TAT)** | Átlagos percek száma a kérdés beérkezésétől a jóváhagyott válaszig. |
| **Idézet‑pontosság** | Az idézeteknek az auditorok által helyesnek és naprakésznek ítélt aránya. |
| **Kockázati‑súlyozott hibaarány** | Hibák súlyozása a kérdés kockázati szintje szerint (magas‑kockázatú hibák nagyobb büntetést kapnak). |
| **Megfelelőségi pontszám** | Egy audit‑eredményekből származó összetett pontszám, negyedévente frissítve. |

Korai pilot projektekben a csapatok **70 %‑os csökkenést** értek el az átfutási időben, és **30 %‑os javulást** az idézet‑pontosságban, miután bevezették az adaptív promptokat.

---

## 7. Implementációs ellenőrzőlista

- [ ] Minden meglévő policy‑dokumentum katalogizálása és verziózott tárolása.  
- [ ] Vektor‑index felépítése a legújabb modell (pl. **OpenAI text‑embedding‑3‑large**) beágyazásaival.  
- [ ] Kockázati szintek definiálása, és a kérdőív mezőinek mapping‑ja ezekhez a szintekhez.  
- [ ] Prompt‑töredék‑könyvtár létrehozása minden szint, szabályozás és stílus kombinációra.  
- [ ] Prompt‑összeállító szolgáltatás fejlesztése (stateless micro‑service ajánlott).  
- [ ] LLM‑endpoint integráció, amely támogatja a rendszer‑instrukciókat.  
- [ ] UI kialakítása az emberi felülvizsgálathoz, amely minden szerkesztést naplóz.  
- [ ] Automatikus audit‑riport generálás, amely a választ, az idézeteket és a bizonyíték‑verziókat tartalmazza.  

---

## 8. Jövőbeli irányok

1. **Multimodális lekérdezés** – A bizonyíték‑tár kibővítése képernyőképekkel, architektúra‑diagramokkal és videó‑bemutatókkal, multimodális vision‑LLM‑ekkel gazdagabb kontextus elérése érdekében.  
2. **Ön‑javító promptok** – LLM‑vezérelt meta‑tanulás bevezetése, amely automatikusan javasolja az új prompt‑töredékeket, ha egy adott domainben hibaarány nő.  
3. **Zero‑Knowledge proof integráció** – Kriptográfiai garanciák nyújtása, hogy a válasz pontosan egy meghatározott dokumentum‑verzióból származik, anélkül, hogy a teljes dokumentumot közzétenné, ami a legszigorúbb szabályozott környezetben is megfelel.

A **RAG** és az **adaptív prompting** egyesülése a következő generáció compliance‑automatizálásának sarokköve lehet. Egy moduláris, auditálható pipeline felépítésével a szervezetek nem csak felgyorsíthatják a kérdőív‑válaszadást, hanem a folyamatos fejlesztés és a szabályozási reziliencia kultúráját is beágyazhatják működésükbe.