[{"data":1,"prerenderedAt":740},["ShallowReactive",2],{"blog-pgvector-hu":3},{"slug":4,"published":5,"minutes":6,"category":7,"tags":8,"keywords":14,"about":21,"sources":27,"cover":42,"og":43,"expertise":44,"locales":45,"lang":48,"title":49,"description":50,"coverAlt":51,"metaTitle":52,"takeaways":53,"faq":59,"toc":72,"blocks":97,"others":488},"pgvector","2026-09-21",10,"rag",[9,10,11,12,13],"Vector search","Postgres","HNSW","RAG","Quantisation",[4,15,16,17,18,19,20],"pgvector vs qdrant","postgres vector search","hnsw index postgres","iterative index scans","binary quantization postgres","vector database postgres",[22,24],{"name":4,"url":23},"https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector",{"name":25,"url":26},"PostgreSQL","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FPostgreSQL",[28,30,33,36,39],{"title":29,"url":23},"pgvector README",{"title":31,"url":32},"pgvector changelog","https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector\u002Fblob\u002Fmaster\u002FCHANGELOG.md",{"title":34,"url":35},"PostgreSQL news: pgvector 0.8.2 released","https:\u002F\u002Fwww.postgresql.org\u002Fabout\u002Fnews\u002Fpgvector-082-released-3245\u002F",{"title":37,"url":38},"AWS: Scale pgvector with binary quantization","https:\u002F\u002Faws.amazon.com\u002Fblogs\u002Fdatabase\u002Fscale-pgvector-with-binary-quantization-on-amazon-aurora-postgresql\u002F",{"title":40,"url":41},"pgvector licence","https:\u002F\u002Fgithub.com\u002Fpgvector\u002Fpgvector\u002Fblob\u002Fmaster\u002FLICENSE","\u002Fimages\u002Fblog\u002Fpgvector\u002Fcover.webp","\u002Fimages\u002Fblog\u002Fpgvector\u002Fog.jpg","ai-engineer",[46,47,48],"en","de","hu","pgvector, értékelés: az a vektordatázis, amelyet nem kell üzemeltetned","Értékelés a pgvector 0.8.7-ről: iteratív indexszkennelés szűrt kereséshez, HNSW és IVFFlat, bináris kvantizálás 100 millió vektornál, és a CVE, amely az indexépítést javítási tétellé tette.","Álló henger három egymásra rakott sávval, balra négyzetes modul, felül pajzs.","pgvector: vektorkeresés Postgresben · Balázs Csorba",[54,55,56,57,58],"A pgvector a PostgreSQL licenc alatt álló bővítmény, így a vektorok sima táblákban laknak, az ügyfélszűrők, JOIN-ek és kaszkádos törlések pedig tranzakciók maradnak.","Az iteratív indexszkennelés, ami 0.8.0 óta létezik, a szűrt keresés megoldása: nélküle a sorok 10%-át eltaláló szűrő alapértelmezett ef_search 40 mellett körülbelül négy sort ad vissza.","A AWS 367 GB-os HNSW-indexet mért 100 millió 768 dimenziós vektornál, szemben egy 38 GB-os, binárisan kvantizált indexszel, amely 1,1 óra alatt épült meg 16,1 helyett.","A CVE-2026-3172, amelyet 2026 februárjában a 0.8.2 javított, puffer-túlcsordulás volt a párhuzamos HNSW-indexépítésben, amely más relációk adatait szivárogtathatta ki; a javításhoz nem kell újraindexelés.","A korlát a memória, nem az API: ha az index nem fér már a shared_buffers-be, a válaszok a halfvec, a bináris kvantizálás, a particionálás vagy egy második rendszer.",[60,63,66,69],{"q":61,"a":62},"Ingyenes a pgvector használata?","Igen. A PostgreSQL licenc alatt jelenik meg, díj, open-core szétválasztás és fizetős terv nélkül, és egyre több hosztolt Postgres-szolgáltatónál előre telepítve érkezik. A lényeg a verzió: az iteratív indexszkenneléshez 0.8.0 vagy újabb kell.",{"q":64,"a":65},"Mikor érdemes HNSW-t használni IVFFlat helyett?","A HNSW jobb sebesség-találati arányt ad, üres táblán is létrehozható, mert nincs edzési lépése, viszont lassabban épül és több memóriát igényel. Az IVFFlat gyorsabban épül, de előbb adat kell hozzá; a README szerint lists = rows \u002F 1000 egymillió sorig, afölé sqrt(rows), a probes pedig sqrt(lists)-zel kezdve.",{"q":67,"a":68},"Működik a pgvector WHERE feltétellel?","Igen, de közelítő indexnél a szűrő az indexszkennelés után fut, így egy szelektív feltétel kevesebb sort adhat vissza, mint amennyit a LIMIT kér. A dokumentált megoldások: B-tree a szűrőoszlopon, iteratív indexszkennelés a hnsw.iterative_scan kapcsolóval, részleges index értékenként és listaparticionálás sok különböző értékhez.",{"q":70,"a":71},"Hány vektort kezel a pgvector?","Egyetlen táblát a PostgreSQL 32 TB-os relációkorlátja és az határoz meg, mennyi fér a memóriába; a AWS 367 GB indexet mért 100 millió 768 dimenziós vektornál, és milliárdos nagyságrenden particionálást javasol. Efölött a README replikákat, Citust, PgDogot vagy listaparticionálást ajánl beépített shard-réteg helyett.",[73,76,79,82,85,88,91,94],{"id":74,"title":75},"what-it-is","Mi ez",{"id":77,"title":78},"how-it-works","Hogyan működik",{"id":80,"title":81},"filtered-search","Szűrt keresés",{"id":83,"title":84},"getting-started","Első lépések",{"id":86,"title":87},"performance","Teljesítmény",{"id":89,"title":90},"where-it-shingles","Ahol megakad",{"id":92,"title":93},"verdict","Ítélet",{"id":95,"title":96},"sources","Források",[98,102,105,108,111,184,185,196,202,213,214,217,252,267,268,271,273,280,294,295,298,350,353,359,385,386,389,433,439,440,443,458,464,465],{"type":99,"content":100},"paragraph",[101],"A pgvector egy PostgreSQL-bővítmény, amely vektorokat egy sima tárolóba tesz, és SQL-lel keres azokban. Nem egy rácsavarozott lekérdezésnyelvű vektordatbázis: négy oszloptípust, hat távolságoperátort és két indextípust ad ahhoz a adatbázishoz, amelyet a legtöbb csapat amúgy is üzemeltet, a PostgreSQL licenc alatt, amely a lehető legmegengedőbb. Az itt képviselt álláspont: ez a helyes alapértelmezés szinte minden, legfeljebb néhány tízmillió vektorig terjedő előkeresési feladathoz, és aki ekkora méretnél külön vektordatázist épít, nem képességet vesz, hanem üzemeltetési terhet.",{"type":99,"content":103},[104],"A Qdranttal, a Weavitate-val, a Chromával és a teljesen felhőben üzemeltetett vektor szolgáltatásokkal versengez, valamint minden olyan hosztolt Postgresszel, amely ma már alapból szállítja a bővítményt. Ami megszűnik, az egy teljes infrastruktúra-kategória: nincs második szolgáltatás, nincs második kommunikációs protokoll hitelesítésre, nincs második mentési ütemezés, nincs eltérés a sorok és azokat leíró beágyazások között. Ami megmarad, az a Postgres minden korlátja: egy csomópont memóriája, egy csomópont vacuumja, egy csomópont írási teljesítménye. És ezek válnak a tervezési paraméterekké abban a pillanatban, amikor az index már nem fér a RAM-ba.",{"type":106,"level":107,"id":74,"text":75},"heading",2,{"type":99,"content":109},[110],"Az első kiadás, a 0.1.0, 2021. április 20-án jelent meg, a jelenlegi kiadás pedig a 2026. október 1-i 0.8.7; a repository ellenőrzéskor 23.300 csillagot és 1.300 forkot mutatott. A PostgreSQL 13 és újabb verzióit támogatja, Docker-imageként, PGXN-en, APT-n, Yumon, Homebrew-en és conda-forge-on át kapható, és egyre több hosztolt szolgáltatónál előre telepítve érkezik. Ez azért számít, mert a régi verzión ragadt felhős szolgáltatás a leggyakoribb oka annak, hogy egy csapat úgy hiszi, megvan egy biztonsági javítása, ami nincs meg.",{"type":112,"ordered":113,"items":114},"list",false,[115,122,128,147,156,182],[116,117,121],"Licenc: ",{"tag":118,"children":119},"strong",[120],"a PostgreSQL licenc",", ugyanaz a megengedő szöveg, amelyet maga a PostgreSQL használ. Nincs open core, nincs kereskedelmi szint, nincs fizetős terv mögé rejtett funkció.",[123,124,127],"A 0.8.7-es kiadás 2026. október 1-jén; a 0.8-as széria ",{"tag":118,"children":125},[126],"iteratív indexszkennelést"," ad 2024 októbere, a 0.8.0 óta, és ez a funkció tette kiszámíthatóvá a szűrt keresést.",[129,130,134,135,138,139,142,143,146],"Négy típus: ",{"tag":131,"children":132},"code",[133],"vector"," dimenciónként 4 bájttal, ",{"tag":131,"children":136},[137],"halfvec"," 2-vel, ",{"tag":131,"children":140},[141],"bit"," dimenciónként egy bittel, és ",{"tag":131,"children":144},[145],"sparsevec"," ritka vektorokhoz legfeljebb 1000 nem-nulla elemmel.",[148,149,151,152,155],"Két indextípus: ",{"tag":118,"children":150},[11]," a legjobb sebesség-találati arányért, edzési lépés nélkül, ",{"tag":118,"children":153},[154],"IVFFlat"," gyorsabb építéshez és kisebb memóriaigényhez.",[157,158,161,162,165,166,169,170,173,174,177,178,181],"Hat operátor, közvetlenül az ORDER BY-ban: L2 (",{"tag":131,"children":159},[160],"\u003C->","), belső szorzat (",{"tag":131,"children":163},[164],"\u003C#>","), koszinusz (",{"tag":131,"children":167},[168],"\u003C=>","), L1 (",{"tag":131,"children":171},[172],"\u003C+>","), Hamming (",{"tag":131,"children":175},[176],"\u003C~>",") és Jaccard (",{"tag":131,"children":179},[180],"\u003C%>",").",[183],"A tárolás és a hozzáférés magától a Postgrestől jön: ACID, WAL-alapú replikáció, pillanatnyi visszaállítás, JOIN-ek és soronkénti biztonság ugyanabban a táblában, mint a beágyazások.",{"type":106,"level":107,"id":77,"text":78},{"type":99,"content":186},[187,188,191,192,195],"Index nélkül a vektor-lekérdezés szekvenciális szkennelés, távolságfüggvényre rendezett ORDER BY-jal: pontos eredmény, tökéletes találati arány, és a tábla méretével növekvő költség. Ezt a játszmát egy közelítő index megváltoztatja. A HNSW többrétegű grágot épít a vektorok fölé, és azon jár kicsit gyengébb találati arányért cserébe, a költség viszont többé nem nő a táblával; az IVFFlat vektorokat listákba rendez, és csak egy részüket vizsgálja. A mindent eldöntő részlet, hogy a lekérdezéstervező csak akkor nyúl az indexhez, ha a lekérdezés így néz ki: ",{"tag":131,"children":189},[190],"ORDER BY embedding \u003C=> $1 LIMIT n",". Ugyanez ",{"tag":131,"children":193},[194],"ORDER BY 1 - (embedding \u003C=> $1) DESC"," alakban a README szerint nem használ indexet.",{"type":197,"src":198,"alt":199,"wide":200,"caption":201},"image","\u002Fimages\u002Fblog\u002Fpgvector\u002Fdiagram-7.webp","Három végrehajtási út egyetlen vektor-lekérdezéshez A távolságoperátoros ORDER BY-t és LIMIT-et hordozó lekérdezés felül három útra bontakozik. Balra, nincs index: szekvenciális szkennelés tökéletes találati aránnyal, aminek a költsége soronként nő. Középen, HNSW: járás egy többrétegű gráfon, alapértelmezett m = 16 és ef_search = 40 mellett, ahol a WHERE feltétel csak az indexszkennelés jelöltjei után fut. Jobbra, IVFFlat: vektorok listákba rendezve, csak a legközelebbi listák vizsgálva, az adatok betöltése után építve, az ivfflat.probes állítva, gyengébb sebesség-találati arány mellett. Alul egy sáv: az iteratív indexszkennelés, ami 0.8.0 óta addig fut, amíg a szűrő sorokat ejt, strict_order vagy relaxed_order módban, a hnsw.max_scan_tuples által korlátozva, alapértelmezett 20.000.",true,"A szűrő csak a közelítő index munkája után fut, ezért vitatkozik egymással a szelektív WHERE és az approximatív index, amíg a szkennelésnek nem szabad továbbmennie.",{"type":99,"content":203},[204,205,208,209,212],"A második részlet, hogy hol fut a ",{"tag":131,"children":206},[207],"WHERE"," feltétel. A közelítő index jelölteket állít elő, a szűrő pedig csak utána fut rajtuk, így a szelektivitás és a találati arány összefonódik: az alapértelmezett ",{"tag":131,"children":210},[211],"hnsw.ef_search"," 40-es értékénél és egy a sorok 10%-át eltaláló feltétnél körülbelül négy sor jön vissza. Semmi nem hibás, az index egyszerűen sosem látta az ejtett sorokat. Ez a viselkedés a leggyakoribb oka annak, hogy valaki kevesebb találatot jelez vissza, és erre létezik dokumentált megoldás, nem pedig kerülőút.",{"type":106,"level":107,"id":80,"text":81},{"type":99,"content":215},[216],"A szűrés itt nem utólagos gondolat, hanem elsőrendű probléma, és a dokumentáció négy lépést vesz végig abban a sorrendben, amelyben egy áttekintő kipróbálná őket. Hogy melyik érvényes, attól függ, mennyire szelektív a szűrő, mennyi találati arányra van valójában szükség, és hány különböző értéket vesz fel a szűrő: egy 50.000 értékes ügyfél-azonosító máshogy viselkedik, mint egy nyolc értékes országkód.",{"type":112,"ordered":113,"items":218},[219,226,236,250],[220,221,224,225],"Először a szűrő oszlopára sima ",{"tag":118,"children":222},[223],"B-tree"," index kerüljön",". Ha a feltétel a sorok kis hányadát éri el, ez pontos legközelebbi szomszédokat ad közelítő index érintése nélkül, és a README épp ezt nevezi kiindulópontnak.",[227,228,231,232,235],"Ha a szűrő széles marad, kapcsoljuk be az iteratív indexszkennelést a ",{"tag":131,"children":229},[230],"SET hnsw.iterative_scan = relaxed_order"," paranccsal: a gráf addig jár, amíg a LIMIT betelik, és ",{"tag":131,"children":233},[234],"strict_order"," akkor jön, amikor a távolsági sorrendnek pontosnak kell lennie.",[237,238,241,242,245,246,249],"Korlátozzuk a munkát. A ",{"tag":131,"children":239},[240],"hnsw.max_scan_tuples"," alapértelmezett értéke 20.000, a ",{"tag":131,"children":243},[244],"hnsw.scan_mem_multiplier"," pedig a ",{"tag":131,"children":247},[248],"work_mem"," egy szorzója, így a szelektív szűrő véges szkenneléssé romlik, nem végtelenné.",[251],"Sok különböző értéknél részleges index kell értékenként, vagy listaparticionálni kell a táblát. A README azt is megjegyzi, hogy az egy közelítő indexet megosztó ügyfelek egymás találati arányát is befolyásolják, ez tehát partitionálási, nem hangolási érv.",{"type":253,"variant":254,"title":255,"body":256},"callout","note","A találati arány az a mérőszám, amit senki nem mér",[257],[258,259,262,263,266],"A dokumentáció saját módszere ugyanazt a lekérdezést egy tranzakción belül futtatni ",{"tag":131,"children":260},[261],"enable_indexscan = off"," mellett, és a közelítő eredménnyel összehasonlítani. A csapatok a késleltetésre hangolják az ",{"tag":131,"children":264},[265],"ef_search"," értéket, az összehasonlítást pedig kihagyják, és épp így lesz a tíz sorból négyet visszaadó index gyorsnak kikiáltva.",{"type":106,"level":107,"id":83,"text":84},{"type":99,"content":269},[270],"A teljes felület SQL, és ez az oka annak, hogy egy saját API-val dolgozó rendszer helyett ezt érdemes választani. Az alábbi kódrészlet egy éles tábla formája: rögzített dimenziójú oszlop, pontos index a szűrőre, közelítő index a vektorra, és az az egy beállítás, amely eldönti, hogy a szűrt lekérdezés röviden tér-e vissza.",{"type":131,"code":272},"CREATE EXTENSION IF NOT EXISTS vector;\n\n-- The dimension is part of the type, so every row has to match it.\nCREATE TABLE chunks (\n  id         bigserial PRIMARY KEY,\n  tenant_id  text       NOT NULL,\n  embedding  vector(1536)\n);\n\n-- Exact index on the filter first: for a selective tenant it answers the\n-- whole query and the approximate index is never consulted.\nCREATE INDEX ON chunks (tenant_id);\n\n-- Bulk load with COPY, then build the approximate index on top of the data.\nCREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops)\n  WITH (m = 16, ef_construction = 64);\n\n-- A filter matching 10% of rows with ef_search = 40 returns about four rows,\n-- so the scan has to be allowed to continue past its first pass.\nSET hnsw.iterative_scan = relaxed_order;\nSET hnsw.ef_search = 100;\n\nSELECT id\nFROM chunks\nWHERE tenant_id = 'acme'\nORDER BY embedding \u003C=> (SELECT embedding FROM chunks WHERE id = 42)\nLIMIT 10;",{"type":99,"content":274},[275,276,279],"Három döntés érdemes a védelmére az alábbi kódban. A dimenzió a típus része, így egy másik beágyazó modell által írt sor már az ",{"tag":131,"children":277},[278],"INSERT"," nél bukik, nem a lekérdezés idején. A közelítő index az adatok után épül, mert egy üres táblán létrehozott HNSW-gráfnak nincs mit összekötnie, és úgyis újraépítenék. A próbavektor pedig subselectből jön, abból a formából, amit a lekérdezéstervező elfogad; ugyanez a lekérdezés kifejezéssel az ORDER BY-ban figyelmeztetés nélkül szekvenciális szkennelésre esik vissza.",{"type":253,"variant":281,"title":282,"body":283},"warn","Frissíts, mielőtt indexet építesz",[284],[285,286,289,290,293],"A CVE-2026-3172, amelyet a 2026. február 25-i 0.8.2 javított, puffer-túlcsordulás volt a párhuzamos HNSW-indexépítésben, amely más relációk adatait szivárogtathatta ki, vagy a szervert összeomlaszthatta. A javítás egy bővítmény-frissítés, ",{"tag":131,"children":287},[288],"ALTER EXTENSION pgvector UPDATE",", újraindexelés nélkül; ameddig a frissítés nem lehetséges, a ",{"tag":131,"children":291},[292],"max_parallel_maintenance_workers = 0"," beállítása az építés idejére a dokumentált megoldás. Későbbi kiadások további puffer-túlcsordulásokat javítottak az IVFFlat-építésben, a 0.8.6-ban, majd a 2026. október 1-i 0.8.7-ben is. Érdemes elolvasni a felhős szolgáltatónál ténylegesen futó verziót, nem feltételezni.",{"type":106,"level":107,"id":86,"text":87},{"type":99,"content":296},[297],"A memória az egész teljesítmény-történet. Egy vektoroszlop dimenciónként 4 bájtot és 8 bájtos fejlécet foglal, így 1536 dimenzió index nélkül körülbelül 6 KB soronként, és a AWS mérése szerint egy 100 millió 768 dimenziós vektorral dolgozó teljes pontosságú HNSW-index 367 GB, nagyjából 3,7 GB milliónként. A többi típus pontosan ezért a számért lett kitalálva.",{"type":299,"head":300,"rows":309},"table",[301,303,305,307],[302],"Típus",[304],"Bájt dimenciónként",[306],"Indexelhető korlát",[308],"Mit jár érte",[310,320,330,340],[311,314,316,318],[312],{"tag":131,"children":313},[133],[315],"4",[317],"2.000 dim",[319],"az alap; a rajta végzett pontos keresés pontos találati arányt ad",[321,324,326,328],[322],{"tag":131,"children":323},[137],[325],"2",[327],"4.000 dim",[329],"feleakkora index, a AWS mérése szerint szinte nulla találati arány-veszteség",[331,334,336,338],[332],{"tag":131,"children":333},[141],[335],"1\u002F8",[337],"64.000 dim",[339],"Hamming a előjel-biteken, a találati arányhoz újrasorrendezés kell",[341,344,346,348],[342],{"tag":131,"children":343},[145],[345],"8 nem-nulla elemenként",[347],"1.000 nem-nulla",[349],"ritka beágyazások, L2, koszinusz, belső szorzat és L1",{"type":99,"content":351},[352],"A AWS a legtisztább nyilvános számokat közölte erről: VectorDBBench v0.3.4, top_k=100, Aurora PostgreSQL 18.4, pgvector 0.8.0. A 768 dimenziós LAION 100M esetén egy 128 GB-os r8g.4xlarge egy 367 GB-os, teljes pontosságú HNSW-indexet tárolt, amelyet nem tudott a gyorsítótárban tartani: 3,4 lekérdezés másodpercenként hidegen, 10 párhuzamos kapcsolat mellett, 3.336 melegen, 0,965 találati arány, 16,1 óra építés. Az újrasorrendező bináris kvantizálás 38 GB-ra és 1,1 órára vitte le az indexet, másodpercenként 13,5 hideg és 895 meleg lekérést ért el, és ezt a találati arány fizette meg: 0,931-re.",{"type":99,"content":354},[355,356,358],"Ugyanez a mérés hordozza az ellenpéldát is, ezért a számait a módszertanukkal együtt kell olvasni. A Cohere 10M esetén, ahol a 768 dimenziós beágyazások a nulla közel csoportosulnak, a bináris kvantizálás 3000 jelölt újrasorrendezésével ért csak 0,93 találati arányt, és másodpercenként 16 lekérdezésre esett vissza 1640 ms p99 mellett, míg egy 384 GB-os gépen a teljes pontosságú HNSW 6930 lekérést adott 0,952 találati aránnyal. A kvantizálás eloszlásfüggő: validálni kell a saját beágyazásokon, vagy ",{"tag":131,"children":357},[137]," használni, és felezni az indexet találgatás helyett.",{"type":112,"ordered":113,"items":360},[361,367,377,383],[362,363,366],"Az ",{"tag":131,"children":364},[365],"maintenance_work_mem"," értékét emelni kell HNSW-index építése előtt; a Postgres Notice-t ír, amikor a gráf már nem fér bele, és a README óva int attól, hogy a kiszolgáló memóriájáig emeljük.",[368,369,372,373,376],"Töltsünk ",{"tag":131,"children":370},[371],"COPY"," paranccsal, indexeljünk utána, és éles környezetben ",{"tag":131,"children":374},[375],"CREATE INDEX CONCURRENTLY"," használjunk, hogy az építés ne blokkolja az írásokat.",[378,379,382],"A HNSW-index VACUUM-ja eltarthat egy ideig; a dokumentált gyorsítás, hogy előbb ",{"tag":131,"children":380},[381],"REINDEX INDEX CONCURRENTLY",", utána vacuum.",[384],"A vízszintes skálázást kölcsönözzük, nem építjük: a replikáció és a pillanatnyi visszaállítás a WAL-ból jön, a shardoláshoz pedig a README a Citusra, a PgDogra vagy a listaparticionálásra mutat.",{"type":106,"level":107,"id":89,"text":90},{"type":99,"content":387},[388],"A gyengeségek strukturálisak, nem befejezetlenek. Minden egy Postgres-csomóponton fut, így az index, a heap és a gyorsítótár ugyanazért a memóriáért verseng, és amelyik index nem fér bele, az előbb I\u002FO-probléma lesz, csak utána találati arány-probléma. A közelítő keresés és a szelektív szűrők iteratív szkenneléssel is vitáznak, mert a véges szkennelés véges marad. A vacuum és az indexkarbantartás ennek az adatbázisnak a munkája, nem valaki másé. Beépített shardolás pedig nincs: a vízszintes skálázás replikákat, particionálást vagy egy bővítményt jelent.",{"type":299,"head":390,"rows":399},[391,393,395,397],[392],"Alternatíva",[394],"Üzemeltetési forma",[396],"Üzemeltetési teher",[398],"Hol jobb",[400,411,422],[401,405,407,409],[402],{"tag":118,"children":403},[404],"Qdrant",[406],"Külön Rust-szerver vagy a gyártó felhője",[408],"Még egy kluster javításra, mentésre, biztonságra",[410],"Payload-szűrés és kvantizálás nagy volumenű találati arányra hangolva",[412,416,418,420],[413],{"tag":118,"children":414},[415],"Weaviate",[417],"Külön szerver GraphQL API-val vagy a gyártó felhője",[419],"Ugyanez még egyszer, plusz saját modulkonfiguráció",[421],"Hibrid keresés és vektorosítás egy helyen konfigurálva",[423,427,429,431],[424],{"tag":118,"children":425},[426],"Chroma",[428],"Beágyazva a folyamatba vagy kis önálló szerverként",[430],"Szinte semmi, de Postgres sincs",[432],"A legrövidebb út a prototípustól a futó rendszerig",{"type":99,"content":434},[435,436,438],"A őszinte határ: a pgvector addig nyer, amíg a vektorok a csapat amúgy is tárolt adatainak egy oszlopa, és akkor veszít, amikor egy lekérdezésnek ugyanabban a memóriában kell tartania egy nagy gráfot, egy szűrt szkennelést és az alkalmazás munkakészletének többi részét. A AWS ezt a határt 100 millió vektornál 367 GB indexben mérte meg, és kvantizálással, valamint particionálással kerülte meg. Akik ezt a cserét nem akarják magukra vállalni, négy kijáratuk van: ",{"tag":131,"children":437},[137],", újrasorrendezéssel együtt futó bináris kvantizálás, ügyfél szerinti particionálás vagy egy külön rendszer, az első kettő pedig elég olcsó ahhoz, hogy a negyedikről való beszélgetés előtt ki kell próbálni.",{"type":106,"level":107,"id":92,"text":93},{"type":99,"content":441},[442],"A pgvector legyen az alapértelmezett válasz arra, hová kerüljenek a beágyazások, minden olyan csapatnál, amely már futtat Postgrest, és egy külön vektordatázisnak magának kell megindokolnia, miért kerüljön sorra. A bővítménynek van egy szokatlan tulajdonsága: a hibái azok a hibák, amiket a csapat már ismer egy adatbázisból — memónynyomás, karbantartási ablakok, egy csomópont írási teljesítménye. Mást csak akkor válassz, ha a méret vagy a késleltetési cél megnevezhető.",{"type":112,"ordered":200,"items":444},[445,447,449,451,456],[446],"Válaszd a pgvector-t, ha a vektorok olyan sorokat írnak le, amelyeket a csapat amúgy is tárol, és az ügyfélszigetelés, a kaszkádos törlés vagy a forrástáblával való JOIN tranzakciónak kell lennie.",[448],"Válaszd, ha az anyag legfeljebb néhány tízmillió vektorból áll, és a szűrő elég szelektív ahhoz, hogy a szűrőoszlopon lévő B-tree vigye a lekérdezés java részét.",[450],"Válaszd, ha az alternatíva egy második éles rendszer: a bővítmény örökli a már meglévő mentést, replikációt, megfigyelést és hozzáférés-kezelést, és nem ad hozzá új üzemeltetnivalót.",[452,453,455],"Ne válaszd, ha egyetlen lekérdezésnek több száz gigabájtos gráfot és az alkalmazás munkakészletét is a memóriában kell tartania, hacsak a ",{"tag":131,"children":454},[137]," vagy a bináris kvantizálás nincs már megmérve a valós beágyazásokon.",[457],"Ne válaszd, ha az igény több csomóponton át tartó folyamatos írási teljesítmény, vagy alacsony késleltetésű szűrt keresés több százmillió vektoron; az particionálás vagy kifejezetten erre épített rendszer, és a halogatás később migrációt fizettet.",{"type":459,"content":460},"quote",[461,462,463],"Nem minden beágyazó modell olyan vektorokat ad, amelyek jól kvantizálhatók. Döntés előtt a saját adatokon kell validálni."," ","— AWS Database Blog, 2026. augusztus 18.",{"type":106,"level":107,"id":95,"text":96},{"type":112,"ordered":200,"items":466},[467,472,476,480,484],[468],{"tag":469,"href":23,"children":470},"a",[471],"pgvector README: típusok, indexelés, szűrés és skálázás",[473],{"tag":469,"href":32,"children":474},[475],"pgvector changelog, 0.1.0-tól 0.8.7-ig",[477],{"tag":469,"href":35,"children":478},[479],"PostgreSQL hír: megjelent a pgvector 0.8.2 (CVE-2026-3172)",[481],{"tag":469,"href":38,"children":482},[483],"AWS: pgvector skálázása bináris kvantizálással Aurora PostgreSQL-en",[485],{"tag":469,"href":41,"children":486},[487],"pgvector licenc: a PostgreSQL licenc",[489,563,622,679],{"slug":490,"published":491,"minutes":492,"category":7,"tags":493,"keywords":497,"about":510,"sources":520,"cover":557,"og":558,"expertise":44,"locales":559,"lang":48,"title":560,"description":561,"coverAlt":562},"embedding-model-selection-2026","2026-10-17",9,[494,12,495,9,496],"Embeddings","MTEB","Model selection",[498,499,500,501,502,503,504,505,506,507,508,509],"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",[511,514,517],{"name":512,"url":513},"Word embedding","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FWord_embedding",{"name":515,"url":516},"Information retrieval","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FInformation_retrieval",{"name":518,"url":519},"Discounted cumulative gain","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FDiscounted_cumulative_gain",[521,524,527,530,533,536,539,542,545,548,551,554],{"title":522,"url":523},"Enevoldsen et al.: MMTEB, Massive Multilingual Text Embedding Benchmark (2025)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2502.13595",{"title":525,"url":526},"Hugging Face: Introducing RTEB, a new standard for retrieval evaluation (Oct 2025)","https:\u002F\u002Fhuggingface.co\u002Fblog\u002Frteb",{"title":528,"url":529},"OpenAI: Vector embeddings guide","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fguides\u002Fembeddings",{"title":531,"url":532},"OpenAI: API pricing","https:\u002F\u002Fdevelopers.openai.com\u002Fapi\u002Fdocs\u002Fpricing",{"title":534,"url":535},"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":537,"url":538},"Voyage AI: Text embeddings documentation","https:\u002F\u002Fdocs.voyageai.com\u002Fdocs\u002Fembeddings",{"title":540,"url":541},"Voyage AI: Pricing","https:\u002F\u002Fdocs.voyageai.com\u002Fdocs\u002Fpricing",{"title":543,"url":544},"Google: Gemini API embeddings documentation","https:\u002F\u002Fai.google.dev\u002Fgemini-api\u002Fdocs\u002Fembeddings",{"title":546,"url":547},"Google: Gemini API pricing","https:\u002F\u002Fai.google.dev\u002Fgemini-api\u002Fdocs\u002Fpricing",{"title":549,"url":550},"Cohere: Embed models documentation","https:\u002F\u002Fdocs.cohere.com\u002Fdocs\u002Fcohere-embed",{"title":552,"url":553},"Qwen: Qwen3-Embedding-8B model card","https:\u002F\u002Fhuggingface.co\u002FQwen\u002FQwen3-Embedding-8B",{"title":555,"url":556},"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",[46,47,48],"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":564,"published":491,"minutes":6,"category":7,"tags":565,"keywords":569,"about":581,"sources":591,"cover":616,"og":617,"expertise":44,"locales":618,"lang":48,"title":619,"description":620,"coverAlt":621},"contextual-retrieval-late-chunking",[12,566,494,567,568],"Chunking","Contextual retrieval","Late chunking",[570,571,572,573,574,575,576,577,578,579,580],"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",[582,585,588],{"name":583,"url":584},"Retrieval-augmented generation","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FRetrieval-augmented_generation",{"name":586,"url":587},"Okapi BM25","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FOkapi_BM25",{"name":589,"url":590},"Sentence embedding","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FSentence_embedding",[592,595,598,601,604,607,610,613],{"title":593,"url":594},"Anthropic: Introducing Contextual Retrieval (Sep 2024)","https:\u002F\u002Fwww.anthropic.com\u002Fnews\u002Fcontextual-retrieval",{"title":596,"url":597},"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":599,"url":600},"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":602,"url":603},"Voyage AI: Introducing voyage-context-3 (Jul 2025)","https:\u002F\u002Fblog.voyageai.com\u002F2025\u002F07\u002F23\u002Fvoyage-context-3\u002F",{"title":605,"url":606},"Voyage AI: voyage-context-4 (Jun 2026)","https:\u002F\u002Fblog.voyageai.com\u002F2026\u002F06\u002F29\u002Fvoyage-context-4\u002F",{"title":608,"url":609},"Voyage AI: Contextualized chunk embeddings documentation","https:\u002F\u002Fdocs.voyageai.com\u002Fdocs\u002Fcontextualized-chunk-embeddings",{"title":611,"url":612},"Anthropic: Claude API pricing","https:\u002F\u002Fplatform.claude.com\u002Fdocs\u002Fen\u002Fabout-claude\u002Fpricing",{"title":614,"url":615},"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",[46,47,48],"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":623,"published":491,"minutes":492,"category":7,"tags":624,"keywords":628,"about":641,"sources":649,"cover":673,"og":674,"expertise":44,"locales":675,"lang":48,"title":676,"description":677,"coverAlt":678},"rag-access-control-permissions",[12,625,626,627,9],"Access control","Security","Multi-tenancy",[629,630,631,632,633,634,635,636,637,638,639,640],"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",[642,645,648],{"name":643,"url":644},"Access-control list","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FAccess-control_list",{"name":646,"url":647},"Multitenancy","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FMultitenancy",{"name":583,"url":584},[650,653,656,658,661,664,667,670],{"title":651,"url":652},"OWASP GenAI Security Project: LLM08:2025 Vector and Embedding Weaknesses","https:\u002F\u002Fgenai.owasp.org\u002Fllmrisk\u002Fllm082025-vector-and-embedding-weaknesses\u002F",{"title":654,"url":655},"PostgreSQL documentation: Row Security Policies","https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fddl-rowsecurity.html",{"title":657,"url":23},"pgvector README: filtering and iterative index scans",{"title":659,"url":660},"Qdrant: Multitenancy and partitions guide","https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Fguides\u002Fmultiple-partitions\u002F",{"title":662,"url":663},"Pinecone: Implement multitenancy using namespaces","https:\u002F\u002Fdocs.pinecone.io\u002Fguides\u002Findex-data\u002Fimplement-multitenancy",{"title":665,"url":666},"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":668,"url":669},"OpenFGA: RAG authorization use case","https:\u002F\u002Fopenfga.dev\u002Fdocs\u002Fuse-cases\u002Frag-authorization",{"title":671,"url":672},"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",[46,47,48],"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":680,"published":491,"minutes":6,"category":7,"tags":681,"keywords":686,"about":698,"sources":706,"cover":733,"og":734,"expertise":735,"locales":736,"lang":48,"title":737,"description":738,"coverAlt":739},"rag-product-catalog-pim-data",[12,682,683,684,685],"PIM","Product data","B2B e-commerce","Metadata filtering",[687,688,689,690,691,692,693,694,695,696,697],"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",[699,702,703],{"name":700,"url":701},"Product information management","https:\u002F\u002Fen.wikipedia.org\u002Fwiki\u002FProduct_information_management",{"name":583,"url":584},{"name":704,"url":705},"ETIM (standard)","https:\u002F\u002Fwww.etim-international.com\u002Fclassification\u002F",[707,710,713,716,718,721,724,727,730],{"title":708,"url":709},"Akeneo API: Products, product values, metric values and product models","https:\u002F\u002Fapi.akeneo.com\u002Fconcepts\u002Fproducts.html",{"title":711,"url":712},"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":714,"url":715},"Pimcore documentation: Classification Store","https:\u002F\u002Fdocs.pimcore.com\u002Fplatform\u002FPimcore\u002FObjects\u002FObject_Classes\u002FData_Types\u002FClassification_Store\u002F",{"title":717,"url":705},"ETIM International: Classification",{"title":719,"url":720},"ETIM International: ETIM releases and the IXF format","https:\u002F\u002Fetim-international.com\u002F?p=754",{"title":722,"url":723},"Reddy et al.: Shopping Queries Dataset, a large-scale ESCI benchmark for improving product search (2022)","https:\u002F\u002Farxiv.org\u002Fabs\u002F2206.06588",{"title":725,"url":726},"Amazon Science: esci-data repository","https:\u002F\u002Fgithub.com\u002Famazon-science\u002Fesci-data",{"title":728,"url":729},"Qdrant documentation: Filtering","https:\u002F\u002Fqdrant.tech\u002Fdocumentation\u002Fconcepts\u002Ffiltering\u002F",{"title":731,"url":732},"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",[46,47,48],"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.",1792261159165]