RAG chatbot építése saját dokumentumokra: gyakorlati guide

Egy „kérdezz a dokumentumainktól" típusú chatbot 2026-ban már nem kísérleti use case. A megrendelők elvárják, az LLM API-k stabilak, a vector DB-k olcsók. A nehéz rész nem a működő prototípus, hanem a megbízható produkciós rendszer — amely ténylegesen a forrás-dokumentumokból válaszol, nem hallucinál, és mérhetően pontos.

Ebben a cikkben a tényleges termelési RAG-stack-et nézzük: architektúra, eszközválasztás, ingestion pipeline, hallucination-kezelés és költség. A példák egy közepes méretű vállalati tudásbázisra (5000-50000 dokumentum) optimalizáltak. Olyan implementációkból dolgozunk, amelyeket éles forgalom alatt mértünk, nem konferencia-slide-okról.

Mi az a RAG és miért nem elég egy sima ChatGPT API hívás

A „Retrieval-Augmented Generation" (RAG) az LLM-nek azt a problémáját oldja meg, hogy az alapmodell nem ismeri a te dokumentumaidat. Ha közvetlenül megkérdezed a GPT-4o-tól, hogy „mit ír a 2024-es szállítási SLA dokumentum a Q4 lemorzsolódási küszöbről", a válasz vagy „nem tudom", vagy egy életszerű, de kitalált szám. A modell nem volt jelen, amikor a dokumentum készült — a training cut-off után publikált anyagok láthatatlanok számára.

A RAG három lépésben dolgozik. Először a felhasználói kérdést átalakítja egy magas-dimenziós vektorrá (embedding), másodszor a vector DB-ben megkeresi a top-k legközelebbi dokumentum-darabot, harmadszor pedig az LLM ezt a kontextust kapja meg a kérdéssel együtt, és a kontextus alapján válaszol. A „sima ChatGPT API hívás" csak a 3. lépést csinálja — kontextus nélkül.

Miért nem elég a fine-tuning?

A fine-tuning egy alternatív irány, de más problémát old meg. A modell stílusát, formátumát és a domain-tudás reflexeit állítja be, viszont friss tartalmat nem hoz. Ha a vállalati SLA-dokumentum holnap változik, a fine-tunolt modell ettől nem tud róla, amíg újra nem trainelsz — egy 10-20 ezer dollárba kerülő művelet, ami napokat vesz igénybe a teljes loopra.

RAG ezzel szemben azonnal frissíthető: amint a vector DB-be beimportálod az új dokumentumot, a modell hozzáfér. A két technikát gyakran kombináljuk: fine-tuning a hangszínre, RAG a tartalomra. A produkciós rendszerek többségében RAG önmagában elég, fine-tuning csak akkor jön be, ha a tone és a strukturált output egyértelműen el van rontva.

Miért nem elég a hosszú context window?

A 2026-os GPT-4o és Claude Sonnet 4 modellek 200K+ token context-tel rendelkeznek. Adódhat a kérdés: minek a vector DB, ha az egész dokumentum-corpust bedobálhatjuk a promptba? Három ok miatt:

1. Költség. 50 ezer dokumentum × átlag 1000 token = 50 millió token query-nként. Egy GPT-4o input-token 2.5 dollár / 1M token tarifán = 125 dollár / kérdés. Ezt senki nem fizeti meg.
2. Latency. 200K input-token feldolgozása 8-15 másodperc. A felhasználó addig már bezárta a tab-et.
3. Pontosság. Hosszú context-en a „lost in the middle" effect érvényesül: a középső 50%-ban szereplő info gyakran nem reflektálódik a válaszban. A RAG-gal kiválasztott top-k darab koncentrált relevancia.

Tipp: A RAG nem helyettesíti a fine-tuningot és a hosszú context-et — három különböző problémát oldanak meg. A produkciós rendszerekben gyakran mindhárom jelen van: fine-tuned base model + RAG retrieval + targeted long-context (pl. summary generation).

Architektúra áttekintés — három layer + eval

Három fő réteg minden RAG-rendszerben:

1. Ingestion — dokumentum-import, chunkolás, embedding-számítás, vector DB-be írás. Általában offline (batch) folyamat. Naponta vagy heti frissítéssel fut.
2. Retrieval — felhasználói kérdés érkezik, embedding-számítás, vector DB top-k lekérdezés. Online, latency-érzékeny (cél: < 200ms).
3. Generation — LLM kapja a kontextust + kérdést, és válaszol forrás-hivatkozással. Online, latency 2-5s tipikus.

Mellettük szükséges egy eval-pipeline, ami 50-200 manuálisan címkézett kérdés-válasz pár alapján mér pontosságot. Eval nélkül nem tudod, hogy a tegnapi prompt-változás javított vagy rontott — a produkció vakon van.

Layer 1 részletesen: ingestion

Az ingestion pipeline minimum 4 lépésből áll: dokumentum-betöltés (PDF, Word, HTML, Markdown), tisztítás (header/footer eltávolítás, OCR-fixek), chunkolás (lásd később), embedding-számítás (batch-elt API-hívások), vector DB-be írás. Egy közepes corpus (50 ezer dok) első import-ja 2-6 órás folyamat, frissítések inkrementálisak.

A buktatók itt rejtőznek. Egy 200 oldalas PDF-ből generálható 600 chunk; ha 10%-uk fejléc-zaj, már 60 hasznavehetetlen vektor szennyezi a search-result-jaidat.

Layer 2 részletesen: retrieval

A retrieval-layer csak külsőre triviális (jön kérdés → embedding → vector DB → top-k). A valóságban itt rejlik a legtöbb finomhangolási lehetőség: query expansion, hybrid search (BM25 + vector), metadata-filter, reranking. Erről részletesen lejjebb.

Layer 3 részletesen: generation

A generation-layer a system prompt, a context-injection és a citation-enforcement kombinációja. A model paraméterek (temperature, top_p, max_tokens) szintén itt élnek. Egy jól designolt generation-layer 60-70%-os baseline-ról 90%+ pontosságra emeli a végeredményt — de csak akkor, ha a retrieval is rendben van.

Chunking strategy — a legtöbb projektet itt rontják el

A „minden dokumentumot beemelünk a vector DB-be" gondolat hozza a 60-70%-os pontosságot — a tényleges produkciós eredményhez chunk-strategia kell.

Fixed-size chunking

A legegyszerűbb: minden N karakter (vagy token) után vágsz. Gyors, deterministic, könnyen reprodukálható.

def fixed_chunks(text: str, size: int = 800, overlap: int = 120):
    chunks = []
    start = 0
    while start < len(text):
        end = min(start + size, len(text))
        chunks.append(text[start:end])
        start += size - overlap
    return chunks

Probléma: a vágás középmondaton történhet, a kontextus félbeszakad. „A szerződés egyenként megtérítendő..." — itt vége. Az LLM nem tudja, mi a folytatás.

Recursive character splitting

A LangChain RecursiveCharacterTextSplitter ennél okosabb: egy hierarchikus separator-listát követ. Először paragraphusoknál próbál vágni (\n\n), ha az túl nagy, mondat-szinten (. ), végül szavaknál ( ).

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=120,
    separators=["\n\n", "\n", ". ", " "],
    length_function=len,
)

chunks = splitter.split_documents(documents)

A chunk_size=800 karakter (~150 token) és a chunk_overlap=120 ipari standard. Az overlap biztosítja, hogy ha a vágás rossz helyen történt, a következő chunk-ban újra szerepel az érintett mondat.

Semantic chunking

A 2025-2026-os generáció: az LLM-mel vagy embedding-modellel detektáljuk a szemantikus határokat. Ahol a környező mondatok cosine similarity-je hirtelen csökken (>0.2 drop), ott vágunk.

from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai.embeddings import OpenAIEmbeddings

text_splitter = SemanticChunker(
    OpenAIEmbeddings(model="text-embedding-3-small"),
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=95,
)

chunks = text_splitter.create_documents([long_text])

Drágább (minden mondat embed-elt egyszer), de a koherenciát megőrzi. KKV-méretű domainen +5-8 pp pontosság-javulást ad a recursive splittinghez képest.

Document-type-specific chunking

Nem minden dokumentum azonos. Egy szerződés-szöveg más struktúrájú, mint egy marketing-FAQ:

Dokumentum-típus	Chunk size	Overlap	Megjegyzés
PDF, jogi szöveg	500-600	150	Sok cross-reference, nagy overlap kell
Műszaki specifikáció	800	100	Jól strukturált, kisebb overlap elég
Marketing tartalom, FAQ	1200	80	Önálló paragraphok, alacsony overlap
Kód-dokumentáció	600	200	Code blocks integritását meg kell őrizni
Email-archívum	400	50	Rövid üzenetek, minimal overlap

A document-type detektálását egyszerűbb metadata-vezérelten csinálni, mint LLM-mel: a documents/legal/*.pdf mappa-struktúra adja a hint-et.

Figyelem: A chunking nem a végén állítható. Ha a vector DB-d már fel van töltve, és változtatsz a chunk-size-on, minden dokumentumot újra kell embed-elni — és az embedding-cost számolható. Egy 50K-dokumentumos corpus újrachunkolása ~$10-30, plus 2-4 óra runtime.

Embedding modell választás

A három fő döntés: vector DB, embedding modell, LLM. Az embedding modell sokszor a legkevésbé tárgyalt, pedig a retrieval-quality-t alapvetően ez határozza meg.

Modell	Dimenzió	Költség / 1M token	Magyar nyelv	Megjegyzés
OpenAI text-embedding-3-small	1536	$0.02	Jó	Default választás
OpenAI text-embedding-3-large	3072	$0.13	Kiváló	Drágább, marginal gain
Cohere embed-multilingual-v3	1024	$0.10	Kiváló	Multi-lang fókusz
Voyage AI voyage-3	1024	$0.06	Jó	Új, gyors
BAAI/bge-large-en-v1.5 (open-source)	1024	$0 + infra	Közepes (english-first)	Self-hosted
intfloat/multilingual-e5-large (open-source)	1024	$0 + infra	Kiváló (95+ nyelv)	Self-hosted

A magyar nyelvű tartalomra a text-embedding-3-small vagy a Cohere embed-multilingual-v3 a legmegbízhatóbb. A text-embedding-3-large 6x drágább, de a real-world precision-gain csak 1-2 pp a small-hoz képest egy hagyományos KKV-domainen.

Self-hosted opció: intfloat/multilingual-e5-large jó (~85-90% precision a managed alternatíváknak), és a GDPR-felelős domain-eken az adat soha nem hagyja el a saját szervert.

Embedding model swap — drágább, mint hinnéd

Ha menet közben váltasz embedding-modellt (mert pl. text-embedding-3-small-ról text-embedding-3-large-ra mozdulsz), az összes vektort újra kell számolni. Egy 50K-chunkos corpus ~$50 a re-embedding-en, plus 1-2 óra runtime. Tervezd be a discovery-fázisban.

Vector DB választás — összehasonlító mátrix

A vector DB market 2026-ban érett. Öt fő opció, mindegyik más use case-re.

DB	Self-hosted	Managed	Filter-support	Hibrid (BM25+vec)	Pricing belépő	GDPR EU
pgvector (Postgres)	Igen	Supabase/Neon	Kiváló (SQL)	Igen (pg_trgm + vec)	$0 self / $25 Supabase	Igen
Pinecone	Nem	Igen	Jó	Igen (hybrid index)	$70/hó	EU region opt-in
Weaviate	Igen	Weaviate Cloud	Jó	Igen	$0 self / $25 cloud	Igen
Qdrant	Igen	Qdrant Cloud	Jó	Igen	$0 self / $25 cloud	Igen
Chroma	Igen	Chroma Cloud	Közepes	Limited	$0 self	Igen self
Milvus	Igen	Zilliz Cloud	Jó	Igen	$0 self / $99 cloud	Igen

pgvector — a Corevanix-default

A legtöbb KKV-projekten pgvector-t választunk. Hét okból:

1. A Postgres már fent van. A meglévő DB-szerverre CREATE EXTENSION vector; és kész. Nincs új vendor, új monitoring, új backup-stratégia.
2. SQL filter natívan. WHERE metadata->>'category' = 'legal' AND created_at > '2025-01-01' egyszerű SQL.
3. Tranzakcionális garanciák. Ha az embedding-számítás és a chunk-mentés egy tranzakcióban van, részleges hibák nem hagynak árva chunkokat.
4. Backup és disaster recovery rutin. A meglévő Postgres backup pipeline-ban a vector data is benne van.
5. Költség. 50000 dokumentum × 4 chunk × 1536 dim × 4 byte ≈ 1.2 GB. Egy 25 dolláros Supabase-projektben elfér.
6. GDPR-friendly. EU-régióban hostolt Postgres, az adat soha nem mozdul USA-szerverre.
7. Migration-easy. Ha valaha váltani kell Pinecone-ra (mert pl. 10M+ chunkot tárolsz), egy SELECT-szel kiexportálható.

Pinecone — mikor jobb?

Ha 10M+ chunkot tárolsz, vagy sub-100ms p99 latency kell, vagy a sharding-szervezés terhe nem fér a csapatba, akkor Pinecone vagy Qdrant Cloud kerüljön elő. KKV-méretben (50K-2M chunk) pgvector bőven elég.

Index-típus: HNSW vs IVF

Mindkét gyakori opció (HNSW: Hierarchical Navigable Small World; IVF: Inverted File Index). HNSW pontosabb és gyorsabb query-időben, de drágább memóriában. IVF olcsóbb, de paraméterezést igényel (nprobe, nlist).

KKV-méretű corpusra: HNSW default, m=16, ef_construction=64 paraméterekkel. 10M+ chunkon érdemes IVF-PQ-ra (quantized) lépni a memory-cost miatt.

-- pgvector HNSW index
CREATE INDEX ON chunks
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

Query handling és context injection

Ha a felhasználói kérdés rövid ("SLA"), az embedding nem lesz informatív. Ha hosszú és tele van zajjal ("szia, csak gyorsan kérdezem, hogy a Q4-es SLA-ban..."), az embedding ugyanolyan rossz. Két technika a megoldásra: query rewriting és HyDE.

Query rewriting

Az LLM-mel parafrazáljuk a kérdést 2-3 változatra, mindegyik retrieval-be megy, és union-oljuk a top-k-t.

expansion_prompt = """
Adj 3 alternatív megfogalmazást a következő kérdésre,
amelyek vektoros kereséshez hasznosak.
Mindegyik 1-2 mondatos, kulcsszó-orientált.

Kérdés: {user_query}

Csak a 3 alternatívát írd ki, soronként, számozás nélkül.
"""

alternatives = llm.generate(expansion_prompt.format(user_query=q)).split("\n")
all_chunks = []
for alt in [q] + alternatives:
    embedding = embed(alt)
    chunks = vector_db.search(embedding, top_k=10)
    all_chunks.extend(chunks)

deduplicated = deduplicate_by_chunk_id(all_chunks)
top_k = rerank_or_truncate(deduplicated, k=5)

A query rewriting +6-10 pp recall-javulást ad átlagos domainen, cserébe 1 extra LLM-hívás kell — $0.001-0.005 / query.

HyDE — Hypothetical Document Embeddings

Egy fejlettebb technika: az LLM-mel fantázia-választ generáltatunk a kérdésre, és annak az embedding-jét használjuk retrievalra. A logika: a fantázia-válasz hipotetikusan ugyanazon a szókincsen szól, mint a valós forrás-dokumentum.

hyde_prompt = """
Az alábbi kérdésre képzelj el egy 3-5 mondatos választ,
mintha egy belső dokumentumból másoltad volna.
Legyen technikai és specifikus, akkor is, ha kitalált.

Kérdés: {user_query}
"""

fake_answer = llm.generate(hyde_prompt.format(user_query=q))
query_embedding = embed(fake_answer)  # NEM az eredeti q-t embed-eljük
chunks = vector_db.search(query_embedding, top_k=5)

HyDE +5-12 pp recall-improvement-et ad nehéz domainen (jogi, orvosi, technikai). De ne kombinálj túl sokat: query rewriting + HyDE + reranking együtt lassítja a pipeline-t, és a marginal gain csökken.

Hybrid search — BM25 + vector

A pure vector search jól kezeli a szinonimákat és kontextust, de ritka, specifikus kulcsszavakra rosszul reagál. „A KÜL-2024-7 körrendelet" típusú lekérdezésnél a klasszikus full-text search (BM25) jobb.

A megoldás: hibrid search. Mind a BM25, mind a vector search lefut, az eredmények reciprocal rank fusion-nel egyesülnek.

def reciprocal_rank_fusion(results_lists, k=60):
    scores = {}
    for results in results_lists:
        for rank, doc in enumerate(results):
            doc_id = doc["id"]
            scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)
    sorted_docs = sorted(scores.items(), key=lambda x: -x[1])
    return [doc_id for doc_id, _ in sorted_docs]

bm25_results = bm25_search(query, top_k=20)
vector_results = vector_search(query_embedding, top_k=20)
fused = reciprocal_rank_fusion([bm25_results, vector_results], k=60)
final = fused[:5]

A pgvector-on a hibrid search egy SQL CTE-vel implementálható:

WITH semantic AS (
  SELECT id, 1 - (embedding <=> $1) AS sim
  FROM chunks ORDER BY embedding <=> $1 LIMIT 20
),
keyword AS (
  SELECT id, ts_rank(to_tsvector('simple', content), plainto_tsquery($2)) AS rank
  FROM chunks WHERE to_tsvector('simple', content) @@ plainto_tsquery($2) LIMIT 20
)
SELECT id, COALESCE(sim, 0) * 0.7 + COALESCE(rank, 0) * 0.3 AS score
FROM semantic FULL OUTER JOIN keyword USING (id)
ORDER BY score DESC LIMIT 5;

A 0.7 / 0.3 súlyozás use case-függő. Jogi domainen 0.4 / 0.6 (BM25-erősebb), marketing-domainen 0.8 / 0.2 (vector-erősebb).

Reranking — az utolsó 10 pp precíziójavulás

A vector search a top-20-ban gyakran hozza a releváns chunkot, de nem az 1. helyen. A reranker-modell egy második pass: a 20 jelölt chunkot finomabban rangsorolja, és kiválasztja a top-5-öt.

A két mainstream opció:

• Cohere Rerank 3 — managed API, $1 / 1000 rerank-call, kiváló minőség, magyar nyelven is jó.
• BAAI/bge-reranker-large — open-source, self-hostable, ingyenes, jó minőség (~5-10% gyengébb mint Cohere).

import cohere

co = cohere.Client(api_key="...")

reranked = co.rerank(
    model="rerank-multilingual-v3.0",
    query=user_query,
    documents=[c["content"] for c in top_20_chunks],
    top_n=5,
)
final_chunks = [top_20_chunks[r.index] for r in reranked.results]

Reranking +8-15 pp precision-javulást ad nehéz domainen. A latency-cost ~100-200ms (Cohere) vagy 50-100ms (self-hosted BGE GPU-n).

Tipp: Reranking nélkül a top-5 chunk-od helyett gyakran a top-2 és top-7 a tényleg releváns. Egy 5-elemű context-injection-nél ez különbség az „a válasz benne van" és az „a válaszhoz közeli, de hibás" között.

Citation és confidence scoring

A kontextus-injekció: a top-k chunk-ot a system prompt-ban adjuk át, és explicit instruktáljuk a modellt, hogy csak a forrásokból válaszoljon, és forrást citáljon.

Te egy belső dokumentum-asszisztens vagy.
Csak az alábbi FORRÁSOKBAN szereplő információ alapján válaszolj.
Ha a források nem tartalmaznak választ, mondd hogy:
"Nem találtam egyértelmű választ a dokumentumokban."

Minden állítást egy citation-nal támassz alá: [chunk_X]
A citation kötelező, nem opcionális.

A válasz végén adj egy CONFIDENCE score-t 0-100 skálán:
- 90-100: A források egyértelműen alátámasztják
- 70-89: Alátámasztva, de részleges következtetés
- 50-69: Részleges support, néhány részlet hiányzik
- <50: Elégtelen forrás, válasz bizonytalan

FORRÁSOK:
[chunk_1] {content_1}
[chunk_2] {content_2}
[chunk_3] {content_3}
[chunk_4] {content_4}
[chunk_5] {content_5}

KÉRDÉS: {user_query}

A post-processing-ben két ellenőrzés fut:

def validate_response(response: str) -> dict:
    citations = re.findall(r"\[chunk_\d+\]", response)
    confidence_match = re.search(r"CONFIDENCE:\s*(\d+)", response)
    confidence = int(confidence_match.group(1)) if confidence_match else 0
    return {
        "has_citations": len(citations) > 0,
        "citation_count": len(citations),
        "confidence": confidence,
        "valid": len(citations) > 0 and confidence >= 50,
    }

Ha valid=False, automatic „nem találtam egyértelmű választ" output, plus log a human-review queue-ba.

Hallucination management — 3 layer védelem

A 7-réteges hallucination-védelmről külön cikkben írunk részletesen: LLM hallucinációk elleni 7 védekezés. Itt a RAG-specifikus része:

1. Confidence threshold: ha a top-1 cosine similarity 0.7 alatt van, automatikus „nincs releváns válasz" output. Ez független az LLM válaszától — a retrieval-szintű jelzés.
2. Citation requirement: a system prompt explicit kéri a forrás-azonosítót. Ha az LLM nem ad ilyet, post-process-szel kiszűrjük (lásd fenti kód).
3. Self-consistency: kritikus válaszokra 3 különböző seed-del lefut a generation; ha eltérés van, jelezzük a felhasználónak vagy human-handoff.

A három layer együtt 60-70%-os baseline-ról 92-95%-ra emeli a precíziót egy közepes méretű domainen — eval-szet alapú méréssel.

Eval pipeline — a project gerinc

Eval nélkül a RAG-pipeline vakon van. Minimum 50, ideálisan 100-200 manuálisan címkézett kérdés-válasz pár kell:

eval_dataset = [
    {
        "question": "Mit ír a 2024-es szállítási SLA Q4 lemorzsolódási küszöbről?",
        "expected_answer_keywords": ["Q4", "lemorzsolódás", "8%"],
        "expected_chunks": ["doc_42_chunk_3", "doc_42_chunk_4"],
    },
    # ... 100+ further
]

def eval_run(rag_pipeline, dataset):
    results = []
    for case in dataset:
        response, retrieved_chunks = rag_pipeline.answer(case["question"])
        keyword_hit = all(kw in response for kw in case["expected_answer_keywords"])
        chunk_hit = any(
            c["id"] in retrieved_chunks for c in case["expected_chunks"]
        )
        results.append({
            "question": case["question"],
            "keyword_pass": keyword_hit,
            "chunk_recall": chunk_hit,
        })
    return results

Az eval-szet CI-ben fut minden prompt- vagy config-változáskor. Ha a precision < 90% (vagy az adott projekt-target), a deploy blokkolva.

Megjegyzés: Az eval-szet maga is karbantartást igényel. Új use case-ek, edge case-ek, user-feedback alapján bővítjük. A discovery fázisban a partner-csapattal 50-100 valós kérdést gyűjtünk, és azt címkézzük.

Deployment stack — két irány

Vercel / Cloud-managed (default)

A legtöbb projekten ezt javasoljuk:

• Frontend / API: Next.js Vercel-en
• Vector DB: Supabase pgvector (EU-region)
• Embedding: OpenAI text-embedding-3-small
• LLM: OpenAI GPT-4o vagy Anthropic Claude Sonnet
• Monitoring: Sentry + PostHog
• Cache: Vercel KV (semantic cache 24h TTL)

Setup-idő: 1-2 hét MVP-ig. Havi cost: $50-200 KKV-méretű forgalmon.

Self-hosted (GDPR-prioritás)

Adatérzékeny domain-eken:

• Frontend / API: Next.js Docker, internal Kubernetes
• Vector DB: Postgres + pgvector, on-prem
• Embedding: Ollama + intfloat/multilingual-e5-large GPU-instance-on
• LLM: Ollama + Llama 3.3 70B (vagy Qwen 2.5 72B, magyarra jó)
• Monitoring: Sentry self-hosted + Prometheus + Grafana

Setup-idő: 3-6 hét. Havi cost: $300-800 (GPU-instance + ops). A token-cost nincs, helyette infra-cost van.

Költségbecslés — 50K dokumentum, 200 query/nap

Tétel	Cloud (managed)	Self-hosted
Embedding ingestion (50k × egyszeri)	$10	$0 + 2-4 óra runtime
Embedding query (200/nap × 30)	$5	$0 + GPU
LLM generation (GPT-4o, ~1500 token átlag)	$120	$0 + GPU
Vector DB hosting	$25 (Supabase Pro)	$0 + Postgres VM
Reranking (Cohere, 200/nap)	$6	$0 + BGE GPU
Frontend / API hosting	$0 (Vercel free)	$20 VM
GPU-instance (self-host LLM, A100 24/7)	n/a	$400-700
Monitoring	$0 (free tier)	$25 (self-host alert manager)
Havi total	~$166	~$445-770

A self-hosted opció rosszabb cost-arányt mutat alacsony forgalmon, de >1000 query/nap felett az LLM-token-cost felülmúlja a GPU-cost-ot. Ettől a ponttól a self-hosted gazdaságosabb.

Cost-optimalizáció — semantic cache

Ha sok user kérdez hasonló dolgot („mi a szabadság-politika?", „hány nap szabadságom van?"), érdemes egy semantic cache-réteget bekapcsolni. A bejövő kérdést embed-eljük, és ha a cache-ben van olyan korábbi query, ami 0.9+ cosine similarity-vel közel áll, visszaadjuk a cached választ.

def get_cached_response(query: str, threshold: float = 0.9):
    query_emb = embed(query)
    closest = cache_db.search(query_emb, top_k=1)
    if closest and closest[0]["similarity"] > threshold:
        return closest[0]["response"]
    return None

Tipikus cache-hit-rate: 25-40% repetitív domain-eken. Ez nettó 25-40% token-cost-csökkenést jelent.

Prompt caching — provider-szintű kedvezmény

Az OpenAI és Anthropic API-k 2024-2025-ben bevezették a prompt caching-et. Az ismétlődő system prompt 50-90%-os kedvezménnyel számolódik. Ez automatic, csak akkor kell figyelni rá, hogy a system prompt-ot ne változtasd query-nként.

Monitoring és observability

Production-szintű RAG-rendszerhez monitoring három dimenzióban:

• Latency: p50, p95, p99 a teljes round-tripre. Cél: p95 < 3s, p99 < 5s.
• Cost: token-felhasználás per query, napi és havi, model-bontásban.
• Quality: eval-szet pontosság minden release-en (automated CI). Plus user-feedback (thumbs up / down) gyűjtése.

import sentry_sdk
from posthog import Posthog

posthog = Posthog(api_key="...", host="https://eu.posthog.com")

def track_rag_event(user_id, query, response, latency_ms, tokens, cost):
    posthog.capture(
        distinct_id=user_id,
        event="rag_query",
        properties={
            "query_length": len(query),
            "response_length": len(response),
            "latency_ms": latency_ms,
            "input_tokens": tokens["input"],
            "output_tokens": tokens["output"],
            "cost_usd": cost,
            "has_citations": "[chunk_" in response,
        },
    )

A user kérdéseit elemezve láthatod, melyik dokumentum-darabok hiányoznak: top-k similarity score alacsony, vagy a felhasználó negatívan értékel. Ezek a gap-ek a következő ingestion-batch input-jai.

További olvasmány: az OpenAI evals repository és a Ragas framework — utóbbi pontosan RAG-specifikus metrikákra (faithfulness, answer relevancy, context precision).

Mikor NEM kell RAG?

Néhány eset, amikor a RAG túl-engineerelés:

• <100 dokumentum, ritkán változik. Egyszerűbb az egészet bedobni a long-context promptba (Claude 200K).
• Felhasználói kérdés nagyon strukturált. Pl. „termék X ára?" — itt egy SQL-query a katalógus-DB-re jobb.
• A válasznak kreatívnak kell lennie. Marketing copy, ötletelés — itt a forrás-kötés gátol.
• Real-time streaming feed. Hírek, social media — embedding-pipeline lassú; használj LLM + web-search tool calling-ot.

Lezárás

A RAG nem rocket science 2026-ban — a működő prototípus egy hét. A nehéz rész az eval-szett karbantartása, az edge case-ek lefedése és a költség-monitorozás. Ha komolyan akarod használni, tervezz be egy 8-12 hetes projektet, ami a discovery → PoC → MVP → production lánc:

1. Hét 1-2: Discovery, dokumentum-corpus audit, eval-szet (50-100 case) építése.
2. Hét 3-4: PoC — alap ingestion + retrieval + generation, eval-szet ellen mérve.
3. Hét 5-7: MVP — hybrid search, reranking, citation, monitoring.
4. Hét 8-10: Hyper-care — éles forgalmon iteratív finomhangolás, eval-szet bővítés.
5. Hét 11-12: Handover, dokumentáció, support-runbook.

A teljes cost (build + 3 hó hyper-care): 2.5-5M Ft KKV-méretben. A havi üzemeltetés ($150-700) ezután jön.

Ha AI projektet tervezel, beszéljük át egy 30 perces hívásban. A discovery után konkrét scope-ot és fix árazást adunk. További olvasmány: a lead asszisztens case study konkrét éles projektből hoz tanulságokat, az AI implementáció KKV-knál cikk pedig a KKV-specifikus ROI-számítás.