[{"data":1,"prerenderedAt":733},["ShallowReactive",2],{"blog-multimodal-rag-colpali-hu":3},{"slug":4,"published":5,"minutes":6,"category":7,"tags":8,"keywords":14,"about":25,"sources":35,"cover":72,"og":73,"expertise":74,"locales":75,"lang":78,"title":79,"description":80,"coverAlt":81,"metaTitle":82,"takeaways":83,"faq":89,"toc":105,"blocks":133,"others":480},"multimodal-rag-colpali","2026-10-01",10,"rag",[9,10,11,12,13],"ColPali","Multimodal RAG","Late interaction","Multi-vector embeddings","Visual document retrieval",[15,16,9,17,18,19,20,21,22,23,24],"multimodal RAG ColPali","multimodal RAG","visual document retrieval","ColQwen2","ColQwen3","late interaction MaxSim","multi-vector embeddings","ViDoRe benchmark","page image embeddings","multivector vector database",[26,29,32],{"name":27,"url":28},"Retrieval-augmented generation","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FRetrieval-augmented_generation",{"name":30,"url":31},"Vector database","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FVector_database",{"name":33,"url":34},"Vision-language model","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FVision-language_model",[36,39,42,45,48,51,54,57,60,63,66,69],{"title":37,"url":38},"ColPali: Efficient Document Retrieval with Vision Language Models (arXiv:2407.01449)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2407.01449",{"title":40,"url":41},"ViDoRe V2 benchmark (arXiv:2505.17166)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2505.17166",{"title":43,"url":44},"ViDoRe V3 benchmark (arXiv:2601.08620)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2601.08620",{"title":46,"url":47},"EVIE: storage and benchmark analysis for ColQwen-family models (arXiv:2610.11553)","https:\u002F\u002Farxiv.org\u002Fhtml\u002F2610.11553v1",{"title":49,"url":50},"Vespa: scaling ColPali to billions","https:\u002F\u002Fblog.vespa.ai\u002Fscaling-colpali-to-billions\u002F",{"title":52,"url":53},"Qdrant documentation: vectors, multivectors and the max_sim comparator","https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Fconcepts\u002Fvectors\u002F",{"title":55,"url":56},"Qdrant: ColPali optimization with pooling and two-stage retrieval (2024)","https:\u002F\u002Fqdrant.tech\u002Fblog\u002Fcolpali-qdrant-optimization",{"title":58,"url":59},"Qdrant: turbo4 multivector search tutorial","https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Ftutorials-search-engineering\u002Fturbo4-multivector-search\u002F",{"title":61,"url":62},"Sentence Transformers v6.0.0 release notes","https:\u002F\u002Fgithub.com\u002Fhuggingface\u002Fsentence-transformers\u002Freleases\u002Ftag\u002Fv6.0.0",{"title":64,"url":65},"illuin-tech\u002Fcolpali repository and model table","https:\u002F\u002Fgithub.com\u002Filluin-tech\u002Fcolpali",{"title":67,"url":68},"MUVERA: multi-vector retrieval via fixed dimensional encodings (NeurIPS 2024)","https:\u002F\u002Fproceedings.neurips.cc\u002Fpaper_files\u002Fpaper\u002F2024\u002Ffile\u002Fb71cfefae46909178603b5bc6c11d3ae-Paper-Conference.pdf",{"title":70,"url":71},"VectorChord documentation: indexing with MaxSim operators","https:\u002F\u002Fdocs.vectorchord.ai\u002Fvectorchord\u002Fusage\u002Findexing-with-maxsim-operators.html","\u002Fimages\u002Fblog\u002Fmultimodal-rag-colpali\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fmultimodal-rag-colpali\u002Fog.jpg","ai-engineer",[76,77,78],"en","de","hu","Multimodális RAG ColPalival: oldalképek, többvektoros költségek és mikor nyernek","Multimodális RAG ColPalival: oldalkép-beágyazások, MaxSim-pontozás, többvektoros tárhelyköltségek, tömörítés és mikor múlják felül a feldolgozott szöveget.","Kis mezőkre osztott oldal, néhány mező nagyítóhoz kapcsolódik.","Multimodális RAG ColPalival · Balázs Csorba",[84,85,86,87,88],"A bildalapú visszakeresés az OCR-t, az elrendezés-felismerést, a képleírást és a darabolást egyetlen látás-nyelvi kódolóval és patch-szintű indexszel helyettesíti.","A MaxSim lekérdezési tokenenként összegzi a legjobb skaláris szorzatot az oldal vektorai között; ez magyarázható pontszámokat ad, a tárolás viszont a fő költségtényező lesz.","Egy ColPali-oldal nagyjából 1030 vektort hordoz; float16-ban ez oldalanként körülbelül 257,5 KB, nagyjából harmincszor a BGE-M3 egy darabja.","A poolozás, a bináris vagy 4 bites kvantálás és a jelöltekre épülő, majd újrarangsorolt kétszakaszos felépítés kezelhető tartományba hozza az indexet.","Az oldalképek táblázatoknál, ábráknál és szkenneknél nyernek; a feldolgozott szöveg a tiszta, digitálisan készült dokumentumoknál, a pontos szűrőknél és az olcsó idézeteknél.",[90,93,96,99,102],{"q":91,"a":92},"Mi az a ColPalival készült multimodális RAG?","Renderelt oldalképeken alapuló visszakeresés. Egy PaliGemma-szerű látás-nyelvi modell minden oldalt körülbelül 1030 patch-vektorra kódol, a lekérdezést pedig késői interakciós MaxSimmel pontozza ezekkel szemben. Vizuálisan gazdag dokumentumoknál az OCR-t, az elrendezés-feldolgozást és a darabolást helyettesíti.",{"q":94,"a":95},"Mekkora tárhely kell egy ColPali-indexhez?","A ColPali-tanulmány oldalanként 257,5 KB-ot ad meg float16-ban, ez nagyjából harmincszorosa egy BGE-M3 darabjának. Egymillió oldal, oldalanként 1024 vektor 128 dimenzióval float32-ben körülbelül 512 GB; a Qdrant kvantálási példái ezt 1 bitnél 16 GB-ra csökkentik az utólagos újrapontozás előtt.",{"q":97,"a":98},"Jobb a ColPali, mint a feldolgozott szövegen alapuló RAG?","A ViDoRe v1-en 81,3 nDCG@5 pontot ért el, szemben a tanulmány legjobb szövegfeldolgozó pipeline-jának 67,0 pontjával. A legnagyobb különbségek táblázatoknál, ábráknál és infografikáknál voltak. Tiszta, digitálisan készült szövegnél a feldolgozott darabok gyakran ugyanolyan jók, és sokkal olcsóbb az indexelésük és lekérdezésük.",{"q":100,"a":101},"Mely vektoradatbázisok támogatják a MaxSimet?","A Qdrant a v1.10.0 óta natív többvektoros mezőt kínál max_sim összehasonlítóval, a Vespa pedig tenzoros rangsorolási kifejezésként írja le a MaxSimet. Postgresben a MaxSim-operátort a VectorChord bővítmény adja, mert a pgvectornak nincs natív többvektoros típusa.",{"q":103,"a":104},"Használható a HNSW többvektoros beágyazásokkal?","Nem a szokásos módon. A Qdrant dokumentációja szerint többvektornál a HNSW általában ki van kapcsolva, így a MaxSim a jelöltekre brute-force módon fut. A kétszakaszos felépítések poolozott vagy bináris vektorokkal dolgozó jelölt-szakaszt használnak, a pontos MaxSimet pedig az újrarangsorolásra tartják fenn.",[106,109,112,115,118,121,124,127,130],{"id":107,"title":108},"what-multimodal-rag-colpali-changes","Mit vált ki a ColPali alapú multimodális RAG?",{"id":110,"title":111},"how-late-interaction-maxsim-works","Hogyan működik a MaxSim késői interakciós pontozás?",{"id":113,"title":114},"why-multivector-storage-explodes","Miért lesz ilyen nagy a többvektoros tárolás?",{"id":116,"title":117},"compression-and-two-stage-retrieval","Hogyan lesz a többvektoros visszakeresés megfizethető?",{"id":119,"title":120},"serving-multivector-models","Mivel szolgálhatók ki ezek a modellek 2026-ban?",{"id":122,"title":123},"when-page-images-win-and-when-to-stay-text","Mikor nyernek az oldalképek a feldolgozott szöveggel szemben?",{"id":125,"title":126},"vector-store-support","Mely vektoradatbázisok támogatják a többvektorokat?",{"id":128,"title":129},"decision-checklist","Hogyan döntsön, és mit teszteljen először?",{"id":131,"title":132},"sources","Források",[134,143,146,149,152,160,166,169,170,173,180,183,186,187,190,193,240,243,244,247,280,283,287,288,303,304,307,310,317,320,321,340,397,400,401,404,418,441,442],{"type":135,"content":136},"paragraph",[137,138,142],"A ",{"tag":139,"children":140},"strong",[141],"multimodális RAG ColPalival"," a dokumentumok visszakeresésének első lépését változtatja meg ott, ahol a jelentés az elrendezésben van: szkennelt űrlapok, diák, táblázatok és ábrák. Oldalanként nem szöveget és darabokat állítunk elő, hanem az oldalt képként rendereljük, egy látás-nyelvi modellen futtatjuk, és képpatchenként egy beágyazó vektort tartunk meg. A lekérdezést ezekkel a patch-vektorokkal hasonlítjuk össze a MaxSim nevű késői interakciós pontszámmal. A pipeline elveszíti az OCR-t, az elrendezés-felismerést, a képleírást és a darabolást, cserébe jóval nagyobb indexet és nehezebb lekérdezési utat kap.",{"type":135,"content":144},[145],"A csere mindkét irányban valós. A ViDoRe v1-en, az oldalszintű benchmarkon, amelyet a ColPali vezetett be, a modell 81,3 nDCG@5 pontot ér el, a papírban szereplő legjobb szövegfeldolgozó pipeline 67,0 pontjával szemben; a különbség ábráknál, infografikáknál és táblázatoknál a legnagyobb. Ugyanez a felépítés oldalanként nagyjából 260 KB float16 tárhelyet igényel, és lekérdezéskor brute-force pontozást kényszerít ki. Ez a cikk bemutatja a mechanizmust, a tárhelyszámításokat, a gyakorlativá tevő tömörítési lehetőségeket, a támogató vektoradatbázisokat, és azokat az eseteket, ahol a feldolgozott szöveg még mindig nyer. A számok 2026 októberére vonatkoznak, hacsak a forrás másként nem datálja őket.",{"type":147,"level":148,"id":107,"text":108},"heading",2,{"type":135,"content":150},[151],"A feldolgozási pipeline-t cseréli le vizuálisan gazdag oldalaknál. Egy hagyományos PDF-pipeline elrendezés-felismerést, OCR-t, képleírást és darabolást futtat, mielőtt bármely szövegmodell látná az oldalt; minden lépés késleltetést ad, hibát termel, és olyan hely, ahol egy táblázat elveszítheti az oszlopfejléceit. A ColPali-megközelítés ezt az egészet kihagyja. Az oldalkép egyenesen egy látás-nyelvi modellbe kerül, a kimenet pedig olyan vektorhalmaz, amely képrégiókhoz kötve marad.",{"type":135,"content":153},[154,155,159],"A tanulmány indexelési számai mutatják a változás nagyságrendjét. Egy GCP g2-standard-8 gépen NVIDIA L4-gyel a feldolgozási út (elrendezés 0,81 s, OCR 2,67 s, képleírás 3,71 s, kódolás 0,03 s) oldalanként 7,22 s; a ColPali oldalanként 0,39 s, a SigLIP-alapvonal 0,12 s. A feldolgozás kihagyása a legnagyobb egyedi költségmegtakarítás, és egyben kiveszi azokat az OCR-hibákat, amelyek különben beépülnének az indexbe (",{"tag":156,"href":38,"children":157},"a",[158],"ColPali-tanulmány",").",{"type":161,"src":162,"alt":163,"wide":164,"caption":165},"image","\u002Fimages\u002Fblog\u002Fmultimodal-rag-colpali\u002Fdiagram-5.webp","Indexelés feldolgozás nélkül Négy doboz balról jobbra: a renderelt oldalkép egy látás-nyelvi kódolóba kerül, amely oldalanként nagyjából 1030, 128 dimenziós vektort ad; ezek oldalindexként tárolódnak a MaxSim-pontozáshoz. OCR-, elrendezési vagy darabolási lépés nem szerepel.",true,"Indexelés feldolgozás nélkül: oldalanként egy kódolói menet patch-vektor-mátrixot ad, amelyet a MaxSim lekérdezéskor pontoz.",{"type":135,"content":167},[168],"A csere nem ingyenes. Ugyanaz az oldal most mintegy ezer vektort állít elő egy vagy néhány darab helyett, a lekérdezési oldalon pedig szintén kell egy látás-kódoló. A tanulmányban a lekérdezés kódolása 1-es kötegméretnél kb. 30 ms, szemben a BGE-M3 körülbelül 2 ms-ával, a késői interakciós pontozás pedig 1000 oldalonként nagyjából 1 ms-ot ad hozzá. Az indexelés olcsóbb lesz, a lekérdezés drágább, a tárhelyköltség a kettő között van.",{"type":147,"level":148,"id":110,"text":111},{"type":135,"content":171},[172],"A MaxSim úgy pontozza a lekérdezést egy oldallal szemben, hogy minden lekérdezési token megkeresi a legjobb találatát az oldal vektorai között, majd ezeket a legjobb találatokat összegzi. Lekérdezési tokenenként vegyük az összes oldalvektorra vett skaláris szorzat maximumát, a maximumokat pedig adjuk össze. Az oldalakat egyszer, offline kódoljuk. Lekérdezéskor csak a kérdés kódolódik, az illesztés a tárolt patch-vektorok ellen történik. Ezért hívják késői interakciónak: a lekérdezés és az oldal csak a pontozáskor találkozik, nem a kódolón belül.",{"type":135,"content":174},[175,176,179],"A ColPaliban a PaliGemma-3B egy SigLIP-So400m látás-kódolóval minden oldalt 32 × 32 = 1024 patch rácsra oszt. Hat utasítástokent fűzünk hozzá, és mind az 1030 vektort 128 dimenzióra vetítjük. A ",{"tag":156,"href":50,"children":177},[178],"Vespa-leírás"," ugyanezt a felépítést írja le. A pontozás magja rövid:",{"type":181,"code":182},"code","import numpy as np\n\ndef maxsim(query_vecs, page_vecs):\n    # query_vecs: (query_tokens, 128), page_vecs: (patches, 128)\n    sims = query_vecs @ page_vecs.T      # (query_tokens, patches)\n    return sims.max(axis=1).sum()        # best patch per query token, summed",{"type":135,"content":184},[185],"Mivel a pontszám a lekérdezési tokenenkénti maximumok összege, az is visszakereshető. Látható, melyik patch nyert az egyes tokenekért, és hőtérképet rajzolhatunk az oldalra. Ez segít a visszakeresés hibakeresésében, és megmutatja az olvasónak, miért adtunk vissza egy oldalt, ami fontos, ha a választ idézni kell.",{"type":147,"level":148,"id":113,"text":114},{"type":135,"content":188},[189],"Az egyvektoros index dokumentumonként egy vektort tárol, így mérete a dokumentumok számával nő. A többvektoros index tokenenként vagy patchenként egy vektort tárol, így mérete a dokumentumok száma szorozva dokumentumonkénti vektorszámmal nő. A ColPali-tanulmány oldalanként 257,5 KB-ot ad meg float16-ban, szemben a BGE-M3 darab-beágyazás 8,60 KB-jával. Ez nagyjából harmincszoros, a tanulmány maga pedig a poolingot és a binarizálást jelöli meg orvosságként.",{"type":135,"content":191},[192],"Egymillió oldalra vetítve a táblázat mutatja a különbséget. Az adatok az EVIE-tanulmány tárolási elemzéséből származnak (arXiv 2610.11553), amely a jelenlegi ColQwen-jellegű ellenőrzőpontokat hasonlítja össze egy 2048 dimenziós egyvektoros alapvonallal.",{"type":194,"head":195,"rows":204},"table",[196,198,200,202],[197],"Index",[199],"Vektor oldalanként",[201],"Dimenzió",[203],"Tárhely 1 millió oldalra",[205,214,223,231],[206,208,210,212],[207],"single-vector baseline",[209],"1",[211],"2048",[213],"3.81 GiB",[215,217,219,221],[216],"colqwen3.5-4.5B-v3",[218],"768",[220],"320",[222],"457.76 GiB",[224,226,228,229],[225],"tomoro-colqwen3-embed-8b",[227],"1,280",[220],[230],"762.94 GiB",[232,234,236,238],[233],"nemotron-colembed-vl-8b-v2",[235],"2,304",[237],"4,096",[239],"17,578 GiB",{"type":135,"content":241},[242],"Ebből két dolog következik. Először: a költséget az oldalankénti vektorszám hajtja, nem önmagában a dimenzió, így a 2304 vektort 4096 dimenzióval használó modell egészen más tárhelyosztályba esik, mint a 768 vektor 320 dimenzióval. Másodszor: a HNSW-gráfok rosszul kezelik a MaxSimet. A Qdrant dokumentációja megjegyzi, hogy többvektornál a HNSW általában ki van kapcsolva, így a lekérdezések a jelölteket közvetlenül pontozzák, nem gráfon járnak be. Ez néhány száz jelölt-vektoros lekérdezésnél elfogadható, nagy korpusz teljes átvizsgálásánál viszont drága.",{"type":147,"level":148,"id":116,"text":117},{"type":135,"content":245},[246],"Három eszköz végzi a munka nagy részét: kevesebb vektor oldalanként, kevesebb bit vektoronként, és egy olcsó első szakasz, amely szűkíti a jelöltek körét, mielőtt a pontos MaxSim lefut. A gyakorlatban a csapatok ezeket kombinálják.",{"type":248,"ordered":249,"items":250},"list",false,[251,256,261,266,275],[252,255],{"tag":139,"children":253},[254],"Token-poolozás."," A szomszédos patch-vektorok átlagolása csökkenti a számukat. A ColPali saját mérése szerint a 3-as poolfaktor a vektorok 66,7%-át eltávolítja, és a teljesítmény 97,8%-át megtartja. A Sentence Transformers v6 hierarchikus token-poolozást kínál alapfunkcióként; az 4874 szakaszos NQ-példában a 3-as faktor 608 414 vektort 204 407-re csökkent (311,5 MB-ról 104,7 MB-ra, float32-ben).",[257,260],{"tag":139,"children":258},[259],"Kvantálás."," Qdrant példája egymillió dokumentumra, dokumentumonként 1024 × 128 vektorral, float32-ben 512 GB-ot igényel. 1 bitnél 16 GB, 1,5 bitnél 21,3 GB, 2 bitnél 32 GB, mindez az utólagos újrapontozás előtt. A turbo4 adattípus vektoronként 4 bitet tárol a lemezen; öt BEIR-adatkészleten, ColBERT-többvektorokkal a float32 NDCG@20 99,6%-át tartja meg ugyanazon a MaxSim-újrapontozási úton. Az 1 bites kvantálás turbo4 fölé kapcsolva több minőséget veszít (Recall@20 4,1%-kal csökken) és 27,5%-os mediánlatenciát ad hozzá.",[262,265],{"tag":139,"children":263},[264],"Bináris Hamming-távolsággal."," A Vespa szerint a Hamming-távolságot használó bináris vektorok 32-szer kevesebb tárhelyet igényelnek, és mintegy 3,5-szer gyorsabbak a float skaláris szorzatnál. DocVQA nDCG@5 mutatón a float alapvonal 52,4, a tisztán bináris 49,5, a bináris float-újrapontozással 51,6.",[267,270,271,159],{"tag":139,"children":268},[269],"PLAID."," A ColBERTv2 motorja, a PLAID maradékkompresszióval a késői interakció tárhelyigényét hatszorosára–tízszeresére csökkenti (",{"tag":156,"href":272,"children":273},"https:\u002F\u002Farxiv.org\u002Fabs\u002F2112.01488",[274],"ColBERTv2, arXiv 2112.01488",[276,279],{"tag":139,"children":277},[278],"MUVERA."," A NeurIPS 2024-es munka minden többvektoros halmazt rögzített dimenziós kódolássá alakít, így egy egyvektoros MIPS-index adhat jelölteket, majd pontos MaxSim-újrarangsorolás következik. A tanulmány a PLAID-hez képest körülbelül 10%-kal magasabb visszahívást és körülbelül 90%-kal kisebb késleltetést említ.",{"type":135,"content":281},[282],"A kétszakaszos visszakeresés az a forma, amely működik. A Qdrant 2024-es kísérlete 20 000 oldalon oldalanként az 1030 vektort 38-ra vonta össze, a legjobb 200-at visszakérte, és azokat teljes felbontású MaxSimmel újrapontozta. A bejegyzés 13-szoros visszakeresési gyorsulást közöl. Ez egy szállító 2024-es benchmarkja, nem általános állandó; a lényeg a szerkezet: az olcsó szakasz dönt a visszahívásról, a pontos szakasz a sorrendről.",{"type":161,"src":284,"alt":285,"wide":164,"caption":286},"\u002Fimages\u002Fblog\u002Fmultimodal-rag-colpali\u002Fdiagram-21.webp","Kétszakaszos vizuális visszakeresés Négy doboz balról jobbra: a kérdés-tokenek tokenként egy-egy vektorként kódolódnak, és egy jelöltszakaszba kerülnek, amely poolozott vagy bináris oldalvektorokat használ; a legjobb 200 jelölt teljes felbontású MaxSim-újrarangsorolást kap, a legjobb 20 oldal pedig a generátorhoz kerül.","Kétszakaszos visszakeresés: egy olcsó jelöltszakasz határozza meg a visszahívást, a pontos MaxSim a végső sorrendet.",{"type":147,"level":148,"id":119,"text":120},{"type":135,"content":289},[290,291,294,295,298,299,302],"A tanulmány szerzőinek könyvtára, a colpali-engine elavult; új projektekhez a Sentence Transformers v6 az ajánlott. Ennek MultiVectorEncoder osztálya betölti a ColPali, ColQwen2, PyLate és ColBERTv2 ellenőrzőpontokat, és a ",{"tag":181,"children":292},[293],"maxsim"," vagy a ",{"tag":181,"children":296},[297],"meanmaxsim"," függvénnyel számolja a MaxSimet. A Sentence Transformers v6.0.0 transformers v5-öt és legalább 2.2-es torch-ot követel meg. Nagyobb léptékű kiszolgáláshoz a vLLM-ben van ColQwen3 implementáció ",{"tag":181,"children":300},[301],"token_embed"," poolinggal és MaxSim-pontozással, így a kódoló ugyanazon az inferenciaveremen futhat, mint a RAG-rendszer többi része. Szállítás előtt ellenőrizze a licenceket: a ColPali a Gemma feltételei alatt áll, a ColQwen2 és ColQwen2.5 ellenőrzőpontok és a colSmol Apache-2.0 licencűek, a TomoroAI colqwen3 modellek szintén Apache-2.0-sak.",{"type":147,"level":148,"id":122,"text":123},{"type":135,"content":305},[306],"Az oldalképek akkor nyernek, ha a válasz az elrendezéstől vagy nem szöveges tartalomtól függ: egy ábra, egy diagram jelmagyarázata, összevont fejlécű táblázat, egy szkennelt űrlap. A ViDoRe v1 tanulmányában 79,1 szemben 35,7 az ArxivQA-n, 81,8 szemben 71,9 az InfoVQA-n és 83,9 szemben 69,1 a TabFQuAD-on (nDCG@5). A benchmark kifejezetten ábrákat és táblázatokat vizsgál, így a különbségek azt tükrözik, amit mér.",{"type":135,"content":308},[309],"A benchmarkok tovább léptek. A ViDoRe v1 közel telített, a vezető modellek 90 nDCG@5 fölött vannak. A ViDoRe v2 vakon kontextuális kérdéseket, hosszú és dokumentumokon átívelő kérdéseket, valamint négy többnyelvű adatkészletet ad hozzá. A ViDoRe v3 (ACL 2026) lényegesen nehezebb: tíz adatkészlet, körülbelül 26 000 oldal, 3099 emberi ellenőrzésű kérdés hat nyelven. A vizuális visszakeresők felülmúlják a szövegalapúakat, és a késői interakció javítja a rangsorolást, de a jelenlegi modellek még elbuknak a nem szöveges elemeken és a finom vizuális hivatkozáson. A legjobb közölt eredmény körülbelül 66,75 nDCG@10 (EVIE-8B), szemben a tomoro-colqwen3-embed-8b 61,60 pontjával. Ezek tanulmányi számok; mielőtt rangsort idéz, ellenőrizze a modellkártyákat és a benchmark oldalait, mert az élő nézetek változnak.",{"type":311,"variant":312,"title":313,"body":314},"callout","warn","Maradjon szövegnél, ha",[315],[316],"a szöveg digitálisan született és tisztán tagolt, pontos kulcsszó- vagy mezőlogikára van szükség, idézhető szövegrészletekre van szükség, nincs GPU-keret, vagy a korpusz kicsi. Ilyenkor egy jó parser és a BM25 olcsóbban fut és könnyebben hibakereshető. Gyakori a hibrid megoldás: a mezőkhöz feldolgozott szöveg, a táblázatokhoz és ábrákhoz oldalkép.",{"type":135,"content":318},[319],"A szövegnél maradás esetei valósak. A digitálisan készült PDF-ek tiszta szövegrétegekkel ritkán igényelnek látásmodellt a megfelelő bekezdés megtalálásához, a pontos egyezésen vagy mezőszintű szűrőn pedig szöveges alapon könnyebb gondolkodni. A feldolgozott darabok emellett idézhető szakaszt adnak. Néhány ezer oldal CPU-s gépen rossz illeszkedés egy többvektoros indexhez. Az OCR-t megterhelő írásrendszerek tesztelendő kérdés, nem bizonyított előny: egyetlen ViDoRe-felosztás sem CJK-korpusz, ezért ezeket a saját oldalain teszteljék.",{"type":147,"level":148,"id":125,"text":126},{"type":135,"content":322},[323,324,328,329,332,333,336,337,159],"A támogatás egyenetlen. A Qdrant a v1.10.0 óta natív többvektoros mezőt kínál max_sim összehasonlítóval, és kikényszeríti azt a korlátot, hogy az alvektorok száma szorozva a dimenzióval 1 048 576 alatt maradjon; egy 128 dimenziós ColPali-oldal ezt könnyedén teljesíti. A Vespa MaxSimet tenzoros rangsorolási kifejezésként írja le, és támogatja a Hamming-távolságú bináris vektorokat. Postgresben a pgvectornak nincs natív többvektoros típusa; a ",{"tag":156,"href":325,"children":326},"https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector\u002Fissues\u002F970",[327],"970-es funkciókérés"," dokumentálja a megkerülő megoldásokat: tokenenként egy sor, alkalmazásoldali MaxSim. A VectorChord adja a termelési útvonalat: vektortömbök, a MaxSimhez való ",{"tag":181,"children":330},[331],"@#"," operátor és ",{"tag":181,"children":334},[335],"vchordrq"," index (",{"tag":156,"href":71,"children":338},[339],"VectorChord-dokumentáció",{"type":194,"head":341,"rows":352},[342,344,346,348,350],[343],"Tároló",[345],"Többvektoros primitív",[347],"Pontozás",[349],"Index vagy tömörítés",[351],"Megjegyzés",[353,364,375,386],[354,356,358,360,362],[355],"Qdrant",[357],"többvektoros mező, max_sim összehasonlító (v1.10.0-tól)",[359],"MaxSim",[361],"HNSW általában ki (m=0); kvantálás 1 bitig, turbo4",[363],"alvektorok × dimenzió \u003C 1 048 576",[365,367,369,371,373],[366],"Vespa",[368],"tenzormezők és rangsorolási kifejezések",[370],"MaxSim tenzorkifejezésként",[372],"bináris vektorok Hamming-távolsággal",[374],"nincs PLAID; a centroidválasztás nem illik valós idejű indexeléshez",[376,378,380,382,384],[377],"Postgres with VectorChord",[379],"vector(n)[] oszlopok",[381],"@# operator",[383],"vchordrq index",[385],"bővítmény, nem a Postgres magja",[387,389,391,393,395],[388],"pgvector",[390],"nincs natív típus",[392],"MaxSim az alkalmazásban (tokenenként egy sor)",[394],"nincs",[396],"a 970-es issue dokumentálja a megkerülést",{"type":135,"content":398},[399],"A táblázat csak azt tükrözi, amit a hivatkozott források igazolnak. Mielőtt egy funkcióra építene, ellenőrizze az egyes termékek aktuális verzióját.",{"type":147,"level":148,"id":128,"text":129},{"type":135,"content":402},[403],"Kezdje a saját oldalaival, ne egy ranglistával. Építsen egy kis kiértékelő halmazt 100–300 valódi kérdéssel oldalszintű címkékkel, futtassa a feldolgozott szöveget és az oldalképeket ugyanazzal a visszakeresési keretrendszerrel, és hasonlítsa össze a visszahívást azon a küszöbön, amelyet a generátora ténylegesen használ. Ezután ellenőrizze:",{"type":248,"ordered":164,"items":405},[406,408,410,412,414,416],[407],"Korpuszméret és növekedés: oldalak × vektorok oldalanként × bájt vektoronként, mielőtt adatbázist választ.",[409],"Oldalösszetétel: hány oldal függ táblázatoktól, ábráktól vagy szkenektől, és hány tiszta, digitális szöveg?",[411],"GPU-keret: a tanulmány felállásában a lekérdezés kódolása a szöveges út körülbelül tizenötszöröse; ezt a lekérdezési úton tervezze be, ne csak az indexelésnél.",[413],"Újrarangsorolás: döntse el, hogy a poolozott vagy bináris vektorokkal dolgozó jelöltszakasz táplál-e pontos MaxSim-újrarangsorolást.",[415],"Licencek: ellenőrizze, hogy az ellenőrzőpont licence engedi-e a felhasználását.",[417],"Hivatkozások: győződjön meg róla, hogy a válasz oldalrégióra tud mutatni, és a válasszal együtt az oldalképet is visszaadja.",{"type":135,"content":419},[420,421,426,427,431,432,435,436,440],"Ha ebből demót építenék, a saját Nuxt-oldalamon lévő, renderelt oldalakra mutató keresőmezővel kezdeném, ahol már futtatok LLM-funkciókat. Ez terv, nem működő rendszer. A szöveges kiindulóponthoz olvassa a ",{"tag":422,"to":423,"children":424},"link","\u002Fblog\u002Fpdf-document-parsing-for-rag",[425],"PDF-feldolgozás RAG-hoz"," és a ",{"tag":422,"to":428,"children":429},"\u002Fblog\u002Fembedding-quantization-binary-matryoshka",[430],"beágyazás-kvantálás bináris és Matryoshka módszerrel"," cikket; a tárolóoldalhoz a ",{"tag":422,"to":433,"children":434},"\u002Fblog\u002Fqdrant",[355]," cikk az egyvektoros beállítást írja le, amely továbbra is az alapértelmezés. A MI-mérnöki munkámat a ",{"tag":422,"to":437,"children":438},"\u002Fexpertise\u002Fai-engineer",[439],"MI-mérnök"," oldal foglalja össze.",{"type":147,"level":148,"id":131,"text":132},{"type":248,"ordered":164,"items":443},[444,447,450,453,456,459,462,465,468,471,474,477],[445],{"tag":156,"href":38,"children":446},[37],[448],{"tag":156,"href":41,"children":449},[40],[451],{"tag":156,"href":44,"children":452},[43],[454],{"tag":156,"href":47,"children":455},[46],[457],{"tag":156,"href":50,"children":458},[49],[460],{"tag":156,"href":53,"children":461},[52],[463],{"tag":156,"href":56,"children":464},[55],[466],{"tag":156,"href":59,"children":467},[58],[469],{"tag":156,"href":62,"children":470},[61],[472],{"tag":156,"href":65,"children":473},[64],[475],{"tag":156,"href":68,"children":476},[67],[478],{"tag":156,"href":71,"children":479},[70],[481,557,614,672],{"slug":482,"published":483,"minutes":484,"category":7,"tags":485,"keywords":491,"about":504,"sources":514,"cover":551,"og":552,"expertise":74,"locales":553,"lang":78,"title":554,"description":555,"coverAlt":556},"embedding-model-selection-2026","2026-10-17",9,[486,487,488,489,490],"Embeddings","RAG","MTEB","Vector search","Model selection",[492,493,494,495,496,497,498,499,500,501,502,503],"best embedding model 2026","how to choose an embedding model","embedding model comparison","MTEB leaderboard explained","RTEB benchmark","open source embedding model","multilingual embedding model","voyage-4 vs openai embeddings","Qwen3-Embedding","EmbeddingGemma","embedding model for RAG","switching embedding models re-embed",[505,508,511],{"name":506,"url":507},"Word embedding","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FWord_embedding",{"name":509,"url":510},"Information retrieval","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FInformation_retrieval",{"name":512,"url":513},"Discounted cumulative gain","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FDiscounted_cumulative_gain",[515,518,521,524,527,530,533,536,539,542,545,548],{"title":516,"url":517},"Enevoldsen et al.: MMTEB, Massive Multilingual Text Embedding Benchmark (2025)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2502.13595",{"title":519,"url":520},"Hugging Face: Introducing RTEB, a new standard for retrieval evaluation (Oct 2025)","https:\u002F\u002Fhuggingface.co\u002Fblog\u002Frteb",{"title":522,"url":523},"OpenAI: Vector embeddings guide","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fembeddings",{"title":525,"url":526},"OpenAI: API pricing","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fpricing",{"title":528,"url":529},"Voyage AI: The Voyage 4 model family, shared embedding space with MoE architecture (Jan 2026)","https:\u002F\u002Fblog.voyageai.com\u002F2026\u002F01\u002F15\u002Fvoyage-4\u002F",{"title":531,"url":532},"Voyage AI: Text embeddings documentation","https:\u002F\u002Fdocs.voyageai.com\u002Fdocs\u002Fembeddings",{"title":534,"url":535},"Voyage AI: Pricing","https:\u002F\u002Fdocs.voyageai.com\u002Fdocs\u002Fpricing",{"title":537,"url":538},"Google: Gemini API embeddings documentation","https:\u002F\u002Fai.google.dev\u002Fgemini-api\u002Fdocs\u002Fembeddings",{"title":540,"url":541},"Google: Gemini API pricing","https:\u002F\u002Fai.google.dev\u002Fgemini-api\u002Fdocs\u002Fpricing",{"title":543,"url":544},"Cohere: Embed models documentation","https:\u002F\u002Fdocs.cohere.com\u002Fdocs\u002Fcohere-embed",{"title":546,"url":547},"Qwen: Qwen3-Embedding-8B model card","https:\u002F\u002Fhuggingface.co\u002FQwen\u002FQwen3-Embedding-8B",{"title":549,"url":550},"Google Developers Blog: Introducing EmbeddingGemma (Sep 2025)","https:\u002F\u002Fdevelopers.googleblog.com\u002Fen\u002Fintroducing-embeddinggemma\u002F","\u002Fimages\u002Fblog\u002Fembedding-model-selection-2026\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fembedding-model-selection-2026\u002Fog.jpg",[76,77,78],"Embedding-modell választása 2026-ban: ranglisták, költségek és összehasonlító teszt a saját adatokon","Hogyan válassz embedding-modellt RAG-hoz 2026-ban: mit mond az MTEB és az RTEB, API vagy nyílt súlyok, árak, dimenziók és egy egyhetes összehasonlító teszt.","Három oszlop egymásra rakott kockákból, középen a legmagasabb, mindegyik rövid sávval mérve.",{"slug":558,"published":483,"minutes":6,"category":7,"tags":559,"keywords":563,"about":575,"sources":583,"cover":608,"og":609,"expertise":74,"locales":610,"lang":78,"title":611,"description":612,"coverAlt":613},"contextual-retrieval-late-chunking",[487,560,486,561,562],"Chunking","Contextual retrieval","Late chunking",[564,565,566,567,568,569,570,571,572,573,574],"contextual retrieval","anthropic contextual retrieval","late chunking","contextual chunk embeddings","contextual embeddings rag","contextual bm25","chunk context rag","voyage-context-3","voyage-context-4","late chunking vs contextual retrieval","rag chunking context loss",[576,577,580],{"name":27,"url":28},{"name":578,"url":579},"Okapi BM25","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FOkapi_BM25",{"name":581,"url":582},"Sentence embedding","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FSentence_embedding",[584,587,590,593,596,599,602,605],{"title":585,"url":586},"Anthropic: Introducing Contextual Retrieval (Sep 2024)","https:\u002F\u002Fwww.anthropic.com\u002Fnews\u002Fcontextual-retrieval",{"title":588,"url":589},"Günther et al.: Late Chunking, Contextual Chunk Embeddings Using Long-Context Embedding Models (2024, rev. 2025)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2409.04701",{"title":591,"url":592},"Jina AI: Late Chunking in Long-Context Embedding Models (Aug 2024)","https:\u002F\u002Fjina.ai\u002Fnews\u002Flate-chunking-in-long-context-embedding-models\u002F",{"title":594,"url":595},"Voyage AI: Introducing voyage-context-3 (Jul 2025)","https:\u002F\u002Fblog.voyageai.com\u002F2025\u002F07\u002F23\u002Fvoyage-context-3\u002F",{"title":597,"url":598},"Voyage AI: voyage-context-4 (Jun 2026)","https:\u002F\u002Fblog.voyageai.com\u002F2026\u002F06\u002F29\u002Fvoyage-context-4\u002F",{"title":600,"url":601},"Voyage AI: Contextualized chunk embeddings documentation","https:\u002F\u002Fdocs.voyageai.com\u002Fdocs\u002Fcontextualized-chunk-embeddings",{"title":603,"url":604},"Anthropic: Claude API pricing","https:\u002F\u002Fplatform.claude.com\u002Fdocs\u002Fen\u002Fabout-claude\u002Fpricing",{"title":606,"url":607},"Qu, Tu and Bao: Is Semantic Chunking Worth the Computational Cost? (2024)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2410.13070","\u002Fimages\u002Fblog\u002Fcontextual-retrieval-late-chunking\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fcontextual-retrieval-late-chunking\u002Fog.jpg",[76,77,78],"Kontextuális visszakeresés és késleltetett chunkolás: a RAG-chunkok visszakapják a kontextusukat","A chunkok elveszítik a dokumentumukat. Hogyan javít ezen a contextual retrieval, a late chunking és a kontextusos embedding, mennyibe kerül, és mikor hagyd ki.","Négy szabad négyzet, alul széles kapocs fogja össze, mindegyik felfelé egy nagy laphoz kapcsolódik.",{"slug":615,"published":483,"minutes":484,"category":7,"tags":616,"keywords":620,"about":633,"sources":641,"cover":666,"og":667,"expertise":74,"locales":668,"lang":78,"title":669,"description":670,"coverAlt":671},"rag-access-control-permissions",[487,617,618,619,489],"Access control","Security","Multi-tenancy",[621,622,623,624,625,626,627,628,629,630,631,632],"rag access control","permission aware rag","document level security rag","rag multi tenancy","vector database access control","pgvector row level security","security trimming azure ai search","openfga rag authorization","qdrant multitenancy","pinecone namespaces multitenancy","owasp llm08 vector and embedding weaknesses","rag data leakage",[634,637,640],{"name":635,"url":636},"Access-control list","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FAccess-control_list",{"name":638,"url":639},"Multitenancy","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FMultitenancy",{"name":27,"url":28},[642,645,648,651,654,657,660,663],{"title":643,"url":644},"OWASP GenAI Security Project: LLM08:2025 Vector and Embedding Weaknesses","https:\u002F\u002Fgenai.owasp.org\u002Fllmrisk\u002Fllm082025-vector-and-embedding-weaknesses\u002F",{"title":646,"url":647},"PostgreSQL documentation: Row Security Policies","https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fddl-rowsecurity.html",{"title":649,"url":650},"pgvector README: filtering and iterative index scans","https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector",{"title":652,"url":653},"Qdrant: Multitenancy and partitions guide","https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Fguides\u002Fmultiple-partitions\u002F",{"title":655,"url":656},"Pinecone: Implement multitenancy using namespaces","https:\u002F\u002Fdocs.pinecone.io\u002Fguides\u002Findex-data\u002Fimplement-multitenancy",{"title":658,"url":659},"Microsoft Learn: Document-level access control in Azure AI Search","https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Fsearch\u002Fsearch-document-level-access-overview",{"title":661,"url":662},"OpenFGA: RAG authorization use case","https:\u002F\u002Fopenfga.dev\u002Fdocs\u002Fuse-cases\u002Frag-authorization",{"title":664,"url":665},"Morris et al.: Text Embeddings Reveal (Almost) As Much As Text (EMNLP 2023)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2310.06816","\u002Fimages\u002Fblog\u002Frag-access-control-permissions\u002Fcover.webp","\u002Fimages\u002Fblog\u002Frag-access-control-permissions\u002Fog.jpg",[76,77,78],"Hozzáférés-kezelés RAG-hoz: jogosultságtudatos visszakeresés dokumentumszivárgás nélkül","Hogyan szivárogtatnak dokumentumot a RAG-asszisztensek, és hogyan állítsd meg: ACL minden chunkon, előszűrés, sorszintű biztonság pgvectorban, jogszinkron.","Hét kártya sorban, haton lakat jelvény, a csupasz kártya nyilat küld kifelé.",{"slug":673,"published":483,"minutes":6,"category":7,"tags":674,"keywords":679,"about":691,"sources":699,"cover":726,"og":727,"expertise":728,"locales":729,"lang":78,"title":730,"description":731,"coverAlt":732},"rag-product-catalog-pim-data",[487,675,676,677,678],"PIM","Product data","B2B e-commerce","Metadata filtering",[680,681,682,683,684,685,686,687,688,689,690],"rag product catalog","rag pim data","llm product data","product catalog chatbot","akeneo rag","pimcore ai search","rag structured data","metadata filtering rag","product attributes embeddings","b2b product assistant","etim classification ai",[692,695,696],{"name":693,"url":694},"Product information management","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FProduct_information_management",{"name":27,"url":28},{"name":697,"url":698},"ETIM (standard)","https:\u002F\u002Fwww.etim-international.com\u002Fclassification\u002F",[700,703,706,709,711,714,717,720,723],{"title":701,"url":702},"Akeneo API: Products, product values, metric values and product models","https:\u002F\u002Fapi.akeneo.com\u002Fconcepts\u002Fproducts.html",{"title":704,"url":705},"Akeneo Help Center: What about products with variants?","https:\u002F\u002Fhelp.akeneo.com\u002Fserenity-take-the-power-over-your-products\u002Fserenity-what-about-products-with-variants",{"title":707,"url":708},"Pimcore documentation: Classification Store","https:\u002F\u002Fdocs.pimcore.com\u002Fplatform\u002FPimcore\u002FObjects\u002FObject_Classes\u002FData_Types\u002FClassification_Store\u002F",{"title":710,"url":698},"ETIM International: Classification",{"title":712,"url":713},"ETIM International: ETIM releases and the IXF format","https:\u002F\u002Fetim-international.com\u002F?p=754",{"title":715,"url":716},"Reddy et al.: Shopping Queries Dataset, a large-scale ESCI benchmark for improving product search (2022)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2206.06588",{"title":718,"url":719},"Amazon Science: esci-data repository","https:\u002F\u002Fgithub.com\u002Famazon-science\u002Fesci-data",{"title":721,"url":722},"Qdrant documentation: Filtering","https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Fconcepts\u002Ffiltering\u002F",{"title":724,"url":725},"Sui et al.: Table Meets LLM, can large language models understand structured table data? (WSDM 2024)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2305.13062","\u002Fimages\u002Fblog\u002Frag-product-catalog-pim-data\u002Fcover.webp","\u002Fimages\u002Fblog\u002Frag-product-catalog-pim-data\u002Fog.jpg","b2b-ecommerce-developer",[76,77,78],"RAG termékkatalógusra: PIM-adatokból megbízható válaszok","A termékadat strukturált, ezért a PDF-szerű chunkolás itt elbukik. Hogyan sorosítsd a PIM-attribútumokat, és hogyan küldd a specifikációs kérdéseket szűrőkhöz.","Kilenc négyzetből álló keret apró jelekkel, alatta tölcsér egyetlen kártyához.",1792337025788]