A probléma

Tanácsadási munkáink során gyakran találkozunk azzal a helyzettel, hogy egy vektoradatbázisra „ültetett” AI asszisztens azért hallucinál, mert a beérkező dokumentumblokkok (chunk) nem, vagy csak kis részben relevánsak a felhasználó legutolsó kérdésének fényében.

Mik a leggyakoribb irányok a probléma kezelésére?

• Több dokumentum blokkot hozni vissza az adatbázisból – de ez a kontextus minőségének romlásához vezet [1].
• Felhasználói kérdés gazdagítása (enrichment, rewriting, expansion) – egy hosszabb beszélgetés adott pontján a felhasználó nem fogja a kereséshez ideális esetben szükséges összes információt belefoglalni a következő kérdésbe, így az AI asszisztens feladata, hogy az előzmények és a legutolsó kérdés felhasználásával optimális keresési kérdést készítsen az adatbázis-lekérdezéshez.
• Reranking/filtering alkalmazása – a vektoradatbázisból visszaérkező nagyobb mennyiségű dokumentum blokk relevanciájának értékelése egy erre a feladatra optimalizált neurális hálóval (ld. Cross-Encoder modellek [2]), sorrend kialakítása az eredmények alapján, majd a top-n blokk továbbítása az asszisztensnek.
• Relevancia ellenőrzése – LLM alapú kiválogatása a ténylegesen releváns blokkoknak.

Fontos közös tulajdonsága ezeknek az irányoknak, hogy már a keresés indítását követően igyekeznek maximalizálni visszaérkező információ relevanciáját. De biztosak lehetünk abban, hogy az információ megfelelően elő van készítve a kereséshez?

Szemantikusvektor-reprezentáció

A dokumentum blokkokból készített szemantikus vektorok (embedding) gyakran külső kötöttségként kerülnek szóba az AI alapú fejlesztésekben. Egy API híváson keresztül le kell őket generálni, aztán egy másik híváson keresztül pedig meg lehet mondani a keresőnek, hogy vegye őket figyelembe.

Ha azonban csak a „fejlesztői szemüvegen” keresztül nézzük az embedding komponenst, hatalmas lehetőséget hagyunk ki a keresés optimalizálására.

A gyakorlatban ez azt jelenti, hogy pl. a használt keretrendszerhez alapértelmezettként beállított embedding modellt választjuk anélkül, hogy alternatívákat keresnénk, és ezeket számszerűsíthető módon össze is hasonlítanánk.

Érdemes felvenni a machine learning szemüveget és megérteni, hogyan jönnek létre a dokumentum blokk-szintű szemantikus vektorok, illetve, hogy mik a korlátai és lehetőségei a vektoros keresésnek. Hogy csak néhányat említsük:

Előnyök:

• A tartalom nyelvfüggetlen leképezése.
• A vektoros reprezentáció független a megfogalmazástól, tehát nem a dokumentum formai jellemzői alapján (konkrét szóválasztás, alkalmazott stílus) lehet vele keresni, hanem a tartalom alapján.
• A vektor leképezi a szövegben foglalt szándékot, fogalmazásbéli finomságokat.

Korlátok:

• A vektor nem kezeli jól a nagyon ritka vagy szakterület-specifikus kifejezéseket, illetve nem erőssége az egzakt kifejezésegyezések megtalálása.
• A vektorizálható dokumentum blokk méretének korlátja van.

Példa

Példaként egy ipari területről származó dokumentum korpuszból épített adatbázis indexeken futtattunk tesztkérdéseket (64 szintetikus teszteset, melyeket a spanyol nyelvű dokumentum korpusz klaszterezésével (HDBSCAN [3]) és reprezentatív mintavétellel, illetve a mintában foglalt dokumentumok szemantikus gráf alapú  összekapcsolásával létrehozott hálózatból nyertünk ki, illetve szakterületi szakértővel ellenőriztettünk).

A teszt során igyekeztünk minden „zavaró tényezőt” kizárni, hogy ténylegesen csak magának az embedding-választásnak a hatását vizsgálhassuk, így tehát: azonos dokumentum blokkokokat használtuk a különböző embedding modellekkel; nem hibrid kereséseket futtattunk, csak vektoralapút; nem filtereztük és nem rangsoroltuk újra az eredményeket.

Az értékeléshez csak a ’recall’ [4] metrikát alkalmaztunk, hiszen a keresési lánc első szintjén ez sokkal fontosabb mutató, mint például az MRR [5]. Ha a releváns információ meg sem jelenik a visszakeresett blokkok között (alacsony recall), az LLM kénytelen nem létező információból válaszolni – ez a hallucináció egyik fő forrása RAG-alapú rendszereknél.

A két vizsgált modell:

• Az OpenAI text-embedding-3-large modellje: mely egy általános célú modell, többnyelvű és 3.072 komponensű vektorokat használ. 8.191 token a feldolgozható blokk maximális mérete.
• A Cohere Embed 4 modellje [6], amely egy célzottan szakterületi adatokon (ipar, egészségügy, pénzügy) optimalizált modell, mely szintén többnyelvű, 128k token a feldolgozható blokk maximális mérete. Mi az 1.024 komponensű vektoros változatot használtuk (a maximum 1.536).

Értékelés

Text-embedding-3-large (OpenAI)				Embed 4 (Cohere)
Metrika		ES	EN	ES	EN
Recall@	5	36.5%	20.6%	63.5%	60.3%
Recall@	10	60.3%	30.2%	68.3%	60.3%
Recall@	20	69.8%	38.1%	73.0%	60.3%
Recall@	30	79.4%	47.6%	79.4%	69.8%

• Mint a számokból is látható, annak ellenére, hogy az Embed 4 csupán harmadannyi komponensre képezi le a jelentést, mégis dominálja a keresési eredményeket. Az eredeti (spanyol) nyelven történő keresés esetén majdnem minden ’k’ értéknél túlteljesíti az OpenAI modellt, csak a Recall@30 esetében egyenlítődik ki az eredmény.
• A Cohere modellje sokkal robusztusabb, ha a keresett kifejezés és a dokumentum blokkok nyelve eltérő. Recall@30 esetén csak 10 százalékponttal teljesít rosszabbul, mint a natív nyelv esetén, míg az OpenAI modelljénél ez a szám több mint 30 százalékpont.

Fontos megjegyezni, hogy a vektoros keresés jellemzői miatt létezik egy felső korlátja az eredményességnek, de éppen ezért nem önmagában alkalmazzuk ezt az eszközt (ld. hibrid keresés).

Zárszó

E rövid cikknek nem az a célja, hogy a Cohere Embed 4 dominanciáját megállapítsa az OpenAI text-embedding-3-large modelljével szemben, hanem hogy felhívja a figyelmet arra, hogy bár sokszor elkerüli a figyelmet, a megfelelő embedding modell kiválasztása jelentős javulást hozhat a keresési eredmények tekintetében. A lehető legjobb minőségű vektorok mellé aztán felzárkózhatnak egyéb optimalizálási technikák, melyek a jobb minőségi inputra épülve még jobb minőségű outputot eredményezhetnek.

Hivatkozások

[1]         „Context Rot: How Increasing Input Tokens Impacts LLM Performance”. Elérés: 2026. március 9. [Online]. Elérhető: https://research.trychroma.com/context-rot

[2]         „Cross-Encoders — Sentence Transformers documentation”. Elérés: 2026. március 9. [Online]. Elérhető: https://sbert.net/examples/cross_encoder/applications/README.html

[3]         „HDBSCAN”, scikit-learn. Elérés: 2026. március 9. [Online]. Elérhető: https://scikit-learn.org/stable/modules/generated/sklearn.cluster.HDBSCAN.html

[4]         „Accuracy vs. precision vs. recall in machine learning: what’s the difference?” Elérés: 2026. március 9. [Online]. Elérhető: https://www.evidentlyai.com/classification-metrics/accuracy-precision-recall

[5]         „Mean Reciprocal Rank (MRR) explained”. Elérés: 2026. március 9. [Online]. Elérhető: https://www.evidentlyai.com/ranking-metrics/mean-reciprocal-rank-mrr

[6]         „Introducing Embed 4: Multimodal search for business | Cohere Blog”, Cohere. Elérés: 2026. március 9. [Online]. Elérhető: https://cohere.com/blog/embed-4

Szerző – Horváth Attila