Blog/Webfejlesztés
Vizuális keresés B2B webshopokban: képbeágyazások, cikkszámok és őszinte korlátok
Vizuális keresés B2B webshopban: képbeágyazások, OCR a cikkszámokhoz, kép-szöveg keresés, szűrők, költségek és saját fotókon mért értékelés.
Balázs Csorba··11 perc olvasás
- Visual search
- Image embeddings
- OCR
- Part numbers
- Hybrid search

A lényeg röviden
- Egy fotó három különböző feladatot takar: egy címke vagy cikkszám fotóját, egy olyan alkatrész fotóját, amelynek a neve ismeretlen, és egy kopott alkatrészt, amelyhez átnézett keresés kell.
- A képbeágyazások jól rögzítik a megjelenést és a típust, a pontos karaktereket viszont rosszul, ezért a címkefotóhoz a cikkszótár által korlátozott OCR kell.
- A kép-szöveg útvonal a webshop meglévő szövegkeresését használja, és gyakran a legolcsóbb első kiadás; a levezetett kifejezés maradjon látható és szerkeszthető.
- A tulajdonságszűrők és a pontos kódokra épülő kulcsszavas egyezés többet javít a találatok minőségén, mint a beágyazási modell cseréje.
- Az indulás előtt saját, címkézett fotókon mérje feladatonként a top-1, top-5, recall@10 értéket és a találat nélküli arányt, negatív halmazzal együtt.
A vizuális keresés lehetővé teszi, hogy a vevő egy fotóval kezdjen gépelt lekérdezés helyett: egy adattábla képével, egy kopott alkatrész fotójával vagy egy bevásárlólista pillanatképével. B2B webshopban ez vonzó funkció, és túlzottan eladott is. Egy fotó nem egy probléma. A címke elsősorban katalógus-korlátos OCR-probléma, az ismeretlen alkatrész képi hasonlósági probléma, a kopott alkatrész pedig olyan keresés, amelyben a kép csak támpontot ad. Egyetlen modell sem kezeli jól mind a hármat, és ezek némelyikére a meglévő szövegkeresés a jobb eszköz.
Ez a cikk a képi modalitást végigvezeti: mit igényel az egyes feladat, miben különbözik a képbeágyazás és a kép-szöveg keresés, hogyan olvashatók ki a cikkszámok egy fotóról, hogyan kombinálhatók a képi találatok szöveggel és szűrőkkel, mennyibe kerül, hogyan értékelhető, és mikor nem érdemes megépíteni. Ott folytatja, ahol a szemantikus termékkeresés B2B-re cikk a szövegkeresésnél megáll, és feltételezi, hogy ismeri a beágyazási modell kiválasztását. A vektortárolásról a pgvector cikk szól. A platform- és árinformációk 2026 októberére vonatkoznak.
Mire jó a vizuális keresés egy B2B webshopban?
A vizuális keresés három feladatnál térül meg. A vevő lefényképez egy címkét vagy adattáblát, és a pontos cikkszámra van szüksége. A vevő lefényképez egy alkatrészt, amelynek nem ismeri a nevét, és hasonló termékeket keres. Egy helyszíni szerelő lefényképez egy kopott vagy törött alkatrészt, és azt a pótalkatrészt keresi, amelyhez tartozik. Mindegyik feladat más jelzésre épül: az elsőnél karakterekre, a másodiknál alakra és megjelenésre, a harmadiknál kontextusra és pótalkatrész-katalógusra.
A rövid válasz az, hogy a vizuális keresés a címke- és az ismeretlen alkatrész feladatára éri meg, és csak akkor, ha a gépelt keresés már jól működik. Cikkszám helyettesítésére gyenge. Egy kopott csapágy fotóján ritkán látszanak azok a részletek, amelyek két szinte azonos méretet megkülönböztetnek, ezért a találati listánál egy embernek kell megerősítenie az egyezést, és ezt az oldalon az üzletnek ki kell mondania.
| Feladat | Fő módszer | Elég a szövegút? | Mérendő mutató |
|---|---|---|---|
| címke- vagy adattábla-fotó | OCR, majd illesztés a cikkszótárral | gyakran, ha a gépelt számok hibatűrő illesztést kapnak | pontos egyezési arány OCR után |
| egész alkatrész, név ismeretlen | képbeágyazás és vektoros keresés | nem; itt ad a kép többletet | top-5 és recall@10 |
| kopott vagy sérült alkatrész | kép-szöveg támpont, majd átnézett keresés | nem; a kép csak támpont | megerősített találati arány |
| bevásárlólista- vagy kosárfotó | látómodell kinyeri a sorokat, katalógusillesztés soronként | részben | helyesen kitöltött sorok |
| vonalkódos csomagolás | vonalkód-dekódolás és GTIN-ellenőrzés | igen; a vonalkód-dekóder minden modellnél jobb | dekódolási sikerarány |
Hogyan teszi kereshetővé a fotót a képbeágyazás?
A képbeágyazó modell egy képet vektorra, a szöveget pedig ugyanabban a térben lévő vektorokra képez le, így egy fotó koszinuszhasonlósággal összevethető a termékvektorokkal. A jelenlegi lehetőségek többsége kontrasztív előtanításból származik. A CLIP azt tanulta meg, hogy melyik képaláírás melyik képhez tartozik, az internetről gyűjtött 400 millió kép-szöveg párral. Zero-shot átvitelben az eredeti ResNet-50 szintjét érte el az ImageNeten úgy, hogy az ImageNet 1,28 millió tanítópéldájából egyet sem használt fel (Radford és munkatársai). A SigLIP 2 megtartja ezt a megközelítést, és szemantikai megértésre, lokalizációra és sűrű jellemzőkre vonatkozó célokat ad hozzá. Többnyelvű családként jelent meg, 86 millió és 1 milliárd paraméter között, dinamikus felbontású változattal (Hugging Face).
Egyetlen modell sem nyer mindenhol. A MIEB 38 nyelvet, nyolc kategóriába sorolt 130 feladatot és 50 modellt fed le, és azt állapítja meg, hogy egyetlen módszer sem dominál minden feladatkategóriában, bizonyos területeken pedig egyértelmű gyengeségei vannak (MIEB). Saját termékein teszteljen, ne a ranglista győztesét válassza.
A tér a durva megjelenést és a típust kódolja: az alakot, a színt, az anyagot, és azt, hogy valami csapágynak vagy tömlőcsatlakozónak látszik-e. A pontos karaktereket, darabszámokat vagy sorozatszámokat nem kódolja megbízhatóan. Egy csapágyról készült fotóra indított legközelebbi-szomszéd keresés vizuálisan hasonló, de más furatú csapágyat adhat vissza, és a távolság ezt nem árulja el. Ehhez a korláthoz kell tervezni, mert a finomhangolás nem szünteti meg.
A folyamat rövid. Minden termékképet egyszer ágyazzon be, és a vektort tárolja együtt azzal a modellverzióval, amely előállította. Lekérdezéskor ágyazza be a vevői fotót, futtasson közelítő legközelebbi-szomszéd keresést, majd szűrjön. A PostgreSQL-ben a pgvector vector és halfvec oszlopokat kínál HNSW és IVFFlat indexekkel. A README szerint a HNSW lekérdezési teljesítménye jobb az IVFFlat-énál, de lassabban épül fel és több memóriát használ (pgvector).
Egyszerűbb-e a kép-szöveg keresés, mint a beágyazás?
Gyakran igen. A 2026-ban jól működő megoldás az, hogy a képből szöveget készít, és a webshop meglévő szövegkeresését használja. Egy vizuális nyelvi modell megnézi a fotót, és keresési kifejezést vagy terméknevet ad vissza, a többit a szokásos keresés intézi. A Spryker Search by Image is ezt a mintát követi. Elemzi a feltöltött fotót, keresési kifejezést von le, és alapértelmezésben a katalógus találati oldalára irányítja a vevőt, vagy az első illeszkedő termékoldalra. JPEG, PNG, WebP és GIF formátumot fogad el. A dokumentáció két esetet nevez meg: egy kopott vagy hibás alkatrész azonosítását gépeken a helyszínen, valamint termékek azonosítását, ha a címkék, vonalkódok vagy csomagolások hiányoznak vagy olvashatatlanok (Spryker).
A kompromisszum az, hogy a szöveges lépés örökli a szövegkeresés minden gyengeségét, és egy téves kifejezés a vevőnek nem ad látható jelzést. Mutassa meg a levezetett kifejezést, engedje a vevőnek szerkeszteni, és jelenítse meg a találatok mellett az illeszkedő kifejezést, hogy egy téves tipp egy kattintással javítható legyen.
A Spryker Visual Add to Cart ugyanezt az elvet alkalmazza a gyorsrendelési oldalon lévő bevásárlólistára. A modell felismert termékeket és mennyiségeket ad vissza. Minden nevet konfigurálható szövegességi küszöbbel egyeztet a katalógussal, amelynek alapértéke 30% szóátfedés, az űrlap pedig SKU-kkal és mennyiségekkel töltődik ki. Az alapértékek JPEG vagy PNG, legfeljebb 10 MB és képenként 20 termék; a rendszerprompt a Back Office-ban szerkeszthető (Spryker). Először a küszöböt hangolja: túl alacsony esetben egy téves SKU kap mennyiséget, túl magas esetben a vevő találatlanok listáját látja.
A vektorindexes változat a középső lépést beágyazási kereséssel helyettesíti. Mindkét változat ugyanabba a katalógusba és ugyanarra a találati oldalra fut, így a webshop többi része nem változik.
Hogyan olvasható ki egy címke vagy cikkszám egy fotóról?
A karaktereket OCR-rel olvassa ki, de a nyers kimenetben ne bízzon vakon. A felhős OCR a leggyorsabb út a működő prototípushoz. A Google Cloud Vision képenként, funkciónként számláz: havi első 1000 egység ingyenes, utána 1,50 USD / 1000 egység 5 millió egységig, e fölött 0,60 USD / 1000, 2026 októberétől (Google Cloud). Saját üzemeltetésű motor akkor érdemes, ha a fotók olyan adatot tartalmaznak, amelyet nem küldhet harmadik félnek, vagy ha a mennyiség miatt az egységárazás a rossz modell. A költség ilyenkor a fejlesztésbe és a GPU-időbe kerül át.
A hibák kiszámíthatók. A betűtípusok összekeverik az O-t és a 0-t, az I-t és az 1-et, valamint a B-t és a 8-at. A domborított fémtáblák tükröződnek, a ferdén fotózott címkéről pedig a karakterlánc fele jön vissza. Két ellenőrzés segít. Ha a szám szabványos felépítésű, ellenőrizze: a GTIN ellenőrző számjegyet hordoz, a python-stdnum pedig az EAN, UPC és GTIN számítást valósítja meg (python-stdnum). A gyártói cikkszámoknak általában nincs ellenőrző számjegyük, ezért a gyakorlati javítás a katalógussal való illesztés. A SymSpell rögzített szerkesztési távolságon belül végez szótári keresést, MIT licencű, így a saját alkatrészlistáján futtatható (SymSpell). Adja vissza a legjobb jelölteket konfidenciaértékkel, és hagyja, hogy a vevő válasszon, ahelyett hogy az első tippet fogadná el.
Hogyan kombinálhatók a képi találatok szöveggel és szűrőkkel?
A tisztán képi hasonlóság olyan dolgokat ad vissza, amelyek jól néznek ki, de nem vásárolhatók meg. A minőség fő eszköze a tulajdonságszűrő: kategória, menetszabvány, anyag, elérhetőség, jóváhagyott beszállító. A jelöltöket több jelzésből gyűjtse: a képvektorból, a begépelt szavakból képzett szövegvektorból és egy kulcsszavas indexből, a tulajdonságszűrőket pedig ugyanabban a lekérdezésben alkalmazza. A kulcsszavas egyezés azért fontos, mert egy pontos furatméret vagy szabványjel gyakran a döntő elem, amelyet a vektor elmos. Az alábbi két ág mutatja, hol találkozik a kép- és a szövegjelzés.
Ellenőrizze a modell licencét, mielőtt egy modell webshopba kerül. A jina-clip-v2 képes, többnyelvű modell, de CC-BY-NC-4.0 licenc alatt jelent meg, amely külön megállapodás nélkül nem engedi a kereskedelmi használatot (Jina AI). Ugyanezen szállító multimodális újrarangsoroló modellje ugyanilyen licencet hordoz. Válasszon megengedő licencű modellt, vagy előbb kérjen írásos engedélyt.
Multimodális újrarangsorolót a végére tegyen, ne az elejére. Az első szakasz legjobb 50 jelöltjét újra pontozza a fotóhoz képest, így költsége az 50-hez skálázódik, nem a katalógushoz. Mérje meg a címkézett halmazon, változtat-e a top-5-ön. Kis katalógusnál csak késleltetést adhat. Az alábbi lekérdezés az első szakaszt mutatja a szűrőkkel ugyanabban az utasításban.
-- Candidates by image vector and attribute filters; the reranker only sees the top 50
SELECT p.sku, p.name, e.embedding <=> $1::halfvec AS distance
FROM product_image_embeddings AS e
JOIN products AS p ON p.sku = e.sku
WHERE e.model_version = $2
AND p.category_id = $3
AND p.is_orderable
AND p.thread_standard = $4 -- optional attribute filter
ORDER BY e.embedding <=> $1::halfvec
LIMIT 50;Teszteljen bekapcsolt szűrőkkel. Egy közelítő index szelektív szűrővel kombinálva kevesebb sort adhat vissza, mint amennyit a limit megenged, ezért a találatszámot és a recallt reális szűrőkombinációkon ellenőrizze, ne csak szűrés nélkül.
Mennyibe kerül, és hogyan mérhető?
Egy fotó beágyazása olcsó, a nagyobb tétel a tárolás. A Voyage AI multimodális modelljei 2026 októberében millió szöveges tokenenként 0,12 USD, milliárd pixelenként 0,60 USD áron szerepelnek, az első 200 millió szöveges token és 150 milliárd pixel ingyenes. A 50 000 pixel alatti képeket 50 000 pixelként számlázzák, a 2 megapixel fölötti képeket pedig kicsinyítik (Voyage AI). Egymillió, 1 megapixeles termékfotó nagyjából egymilliárd pixel, azaz körülbelül 0,60 USD a listaáron. Az egyszeri visszatöltés ezért kicsi a fejlesztési időhöz képest. A visszatérő költség a lekérdezési forgalom, valamint a modellcserénél szükséges újraszámítás.
A tárolás számolás. A pgvector a halfvec értékeket 2 × dimenzió + 8 bájton, a vector értékeket 4 × dimenzió + 8 bájton tárolja (pgvector). Egymillió SKU 1152 dimenziós halfvec beágyazással az index előtt nagyjából 2,3 GB táblaadat. Ez számítás, nem mérés, ezért a saját indexméretét mérje meg. Modellverziónként tartson külön beágyazási táblát, hogy migráció közben két modellt futtathasson egymás mellett.
Saját, címkézett fotókon értékeljen, ne nyilvános ranglistán. Nincs nyilvános benchmark ipari alkatrészkatalógusokra, és az adattáblák OCR-pontossága az adathalmazok között nagyon eltérő, ezért egy tanulmány száma nem vihető át a webshopjára. Gyűjtsön fotókészletet feladatonként, címkézze a helyes SKU-t, és külön jelentse feladatonként a top-1, top-5 és recall@10 értéket, a találat nélküli aránnyal együtt. Adjon hozzá negatív halmazt olyan termékek fotóiból, amelyek nincsenek a katalógusban. Az a keresés, amely mindig ad valamit, ezen a halmazon megbukik.
Mikor ne építsen vizuális keresést?
Először a szövegutat építse meg. A keresőmezőbe gépelt vagy beillesztett cikkszám hibatűrő illesztési probléma. Az Elasticsearch fuzzy lekérdezése már illeszt kifejezéseket Levenshtein-szerkesztési távolságon belül, a fuzziness: AUTO beállítással, valamint előtag- és bővítési korlátokkal (Elastic). Adjon szinonimákat a régi és új cikkszámokhoz, rendes tulajdonságmodellt és keresési elemzést: a keresésből való kilépési arányt, a találat nélküli lekérdezéseket és az átfogalmazásokat. Ez a három jelentés megmutatja, hogy a képek egy valódi azonosítási hibát javítanának-e, vagy csak egy adathiányt.
Hagyja ki a vizuális keresést, ha a találat nélküli lekérdezések többsége hiányzó termékekre vagy tulajdonságokra vonatkozik, mert egy modell sem talál olyan alkatrészt, amely nincs a katalógusban. Hagyja ki, ha a vevőknek ritkán van kéznél fotó, vagy ha a tipikus fotót gyenge fényben, olvasható címke nélkül készítenék telefonnal. Építse meg, ha a szövegút azonosításnál bizonyítottan elbukik, és a három feladat legalább egyike gyakori a forgalmában.
A tanácsom, a Spryker- és Pimcore-katalógusokon szerzett munkám alapján, az, hogy cikkszám-toleranciával és szinonimákkal kezdjen, és a keresésből való kilépési arányt mérje, mielőtt bármilyen beágyazásba fektet. Egy gyenge katalógusra épülő képi funkció csak nehezebben láthatóvá teszi a gyengeséget.
Hogyan néz ki egy megvalósítási ellenőrzőlista?
Az alábbi listát tekintse egy első kiadás minimumának.
- Felvétel: képeket elfogadó fájlmező, feltöltés előtti előnézet és egyértelmű újrafotózási lehetőség.
- Szerveroldali ellenőrzés: a kiterjesztés helyett a valódi fájltípust nézze, korlátozza a méretet, és utasítsa el, amit a dekóder nem tud megnyitni.
- Metaadatok eltávolítása: távolítsa el az EXIF-adatokat, köztük a GPS-koordinátákat, mielőtt a fotó tárolásra vagy modellhez kerülne.
- Sor: a termékképeket háttérfeladatban indexelje, a vevői fotókat pedig ugyanezen a soron ágyazza be, ha a késleltetési keret engedi.
- Verziónált beágyazások: modellverziónként egy tábla, minden sorban a modell nevével, hogy a modellcsere visszatöltés legyen, ne átírás.
- Találat nélküli út: mutassa a levezetett kifejezést, kínáljon szövegmezőt, és egy kategóriaoldalra mutató linket üres rács helyett.
- Katalógus-korlátos OCR: az OCR-kimenetet konfidenciaértékekkel a cikkszótárral egyeztesse, és alacsony érték esetén soha ne tegye automatikusan a kosárba.
- Adatvédelmi átvilágítás: rögzítse, mit fotóznak a vevők, meddig őrzik a fotókat, és mely szolgáltatók kapják meg őket.
- Értékelési kapu: a címkézett halmaz a negatív esetekkel együtt minden modell- vagy küszöbváltoztatás előtt lefut.
A saját Nuxt-oldalamon, ahol LLM-funkciók futnak, a modellkimenetet ellenőrizetlen bemenetként kezelem: ellenőrzöm a formátumot, korlátozom a méretet, és mindig marad út a találat nélküli válaszhoz. Ugyanez a fegyelem vonatkozik a webshop kameragombjára. Ha B2B katalógus keresését tervezi, és azt szeretné, hogy a szövegút mérhető legyen, mielőtt képmodell kerül mellé, nézze meg a B2B e-kereskedelmi munkámat.
Források
- CLIP: Learning Transferable Visual Models From Natural Language Supervision (2021)
- Hugging Face: SigLIP 2 release (2025)
- MIEB: Massive Image Embedding Benchmark (2025)
- jina-clip-v2 model card (CC-BY-NC-4.0)
- pgvector: README
- Spryker docs: Search by Image
- Spryker docs: Visual Add to Cart
- Google Cloud: Vision API pricing
- Voyage AI: pricing
- python-stdnum: EAN, UPC and GTIN module
- Elasticsearch: fuzzy query
- SymSpell (GitHub)
Gyakori kérdések
Azonosíthat-e a vizuális keresés B2B alkatrészt fotó alapján?
Néha. Egy olvasható címkét OCR-rel ki lehet olvasni, és a cikkszótárral egyeztetni, ez jól működik, ha a szótár teljes. Egy címke nélküli alkatrész fotója általában hasonló termékek csoportjára szűkíti a keresést, a pontos cikkszámot viszont továbbra is egy embernek kell megerősítenie.
Elegendőek a CLIP vagy SigLIP modellek a cikkszámokhoz?
Nem. A kontrasztív kép-szöveg modellek a megjelenést és a durva jelentést kódolják. A pontos karaktereket, darabszámokat vagy sorozatszámokat nem olvassák megbízhatóan, ezért a szöveghez OCR kell, a beágyazást pedig hasonlósági jelként kezelje.
Olcsóbb-e a kép-szöveg keresés, mint a képbeágyazás?
Ez a forgalomtól és a katalógus méretétől függ. A katalógus beágyazása egyszeri költség, plusz az újraszámítás modellcserénél, míg a vizuális nyelvi modell hívása minden vevői fotónál megtörténik. Az egy sikeres azonosításra jutó költséget hasonlítsa össze, ne az egy hívásra jutót.
Küldhetők-e vevői fotók harmadik féltől származó MI-szolgáltatásnak?
Mielőtt bármelyik kép elhagyja a rendszereit, ellenőrizze a szolgáltató adatfeldolgozási feltételeit, az adatvédelmi tájékoztatóját és az ügyfelekkel kötött szerződéseit. A fotókon személyek, dokumentumok vagy bizalmas berendezések szerepelhetnek, ezért távolítsa el a metaadatokat, és korlátozza a megőrzési időt.