RAG chatbot pgvector vektor-DB-vel és OpenAI GPT-4o-val, integrálva a meglévő Shopify storefront-ba. A support-tickek 38%-a automatikusan zárul, az ügyfél-elégedettségi score nem romlott.
Háttér
Az ügyfél egy magyar e-commerce kereskedő, kerti eszközök és háztartási termékek szegmens, ~3200 SKU, B2C fókusz. A support-csapat 3 fős, napi 80-120 ticket-et kezel: leggyakoribbak a termék-spec kérdések ('illik-e ez X gépemhez?'), szállítás-státusz, és termék-ajánlás.
A megrendelő látta, hogy a támogatási volumen lineárisan nő a forgalommal, és a csapat-bővítés helyett önkiszolgáló megoldást keresett. A meglévő FAQ-oldal és a Shopify chatbot integration nem ad érdemi választ a termék-spec kérdésekre.
Kihívás
Termék-spec chatbot az egyik legnehezebb AI use case. A katalógus dinamikus (heti szinten 30-50 új termék, 100+ ár-frissítés), a kérdések pedig kontextusosak: 'illik-e ez a tárcsa az X kaszálógépemhez' típusú kérdés a katalógus-szöveg, a kompatibilitási mátrix, és a felhasználói képesség közös megértését igényli.
A második kihívás: hallucination kezelés. Ha a chatbot 'biztos vagyok benne, illik' választ ad egy nem illeszkedő termékre, az visszaküldést és elégedetlen ügyfelet generál. A megrendelő explicit követelménye: minden chatbot-válaszhoz forrás-link, és bizonytalanság esetén explicit átirányítás emberhez.
Megközelítés
RAG (Retrieval-Augmented Generation) architektúrát építettünk, pgvector-rel a Supabase-en. A retrieval pipeline minden termék 4-féle 'chunk'-jából dolgozik: 1) név + szülő kategória, 2) leírás, 3) műszaki specifikáció, 4) kompatibilitási információk (ha van).
A chatbot LLM-je OpenAI GPT-4o, system prompt explicit instruktálva: 'csak akkor mondj választ, ha a forrásokban szerepel; egyébként irányítsd át emberhez'. Az eval-szettre 80 valós ticket-történetet címkéztünk manuálisan, és minden prompt-változás után újrafutott a regression teszt.
Megoldás
A chatbot Next.js widget-ként ágyazódik be a Shopify storefront-ba (a megrendelő nem akart Shopify-natív integrációt, mert tipikusan kötöttebb). A Shopify Storefront API real-time termék-adatot ad a chatbotnak (ár, készlet), így az ajánlások mindig aktuálisak.
A pipeline: felhasználói kérdés → embedding (OpenAI text-embedding-3-small) → pgvector top-k (k=8) retrieval → kontextus-építés a GPT-4o-nak → válasz generálás source-link-ekkel. Minden interakció logolva PostHog-ban (anonimizálva), és Sentry tracking a backend errorokra.
A n8n workflow naponta szinkronizálja a Shopify-katalógust a pgvector indexbe: új termék embed-elése, frissített leírás re-embed-elése, törölt termékek eltávolítása. Az index 2-3 órás késéssel követi a katalógus-állapotot — elfogadható trade-off a real-time queryk és az embedding-költség között.
Technológiai döntések
OpenAI text-embedding-3-small modellt választottunk (a -large helyett), mert: 1) 5x olcsóbb és gyorsabb, 2) a magyar nyelvű retrieval-eval-szetten 92% recall@8 — elegendő a use case-re, 3) a fontossági különbséget több retrieval (k=8) kompenzálja.
pgvector vs Pinecone: pgvector nyert, mert a megrendelő-csapat már használt Postgres-t (más célokra), és a self-hosted megoldás GDPR-szempontból egyszerűbb. A 3200 termék × 4 chunk × 1536 dim méret bőven elfér a Supabase ingyenes tier-en is, de production hot tier-en futott.
GPT-4o vs Claude Sonnet: oldalanként újra-evaluáltuk a két modellt. A GPT-4o jobb volt a magyar nyelvű forrás-utáni precíz idézésben (95% pontosság vs Claude 87%-a az eval-szetten). A Claude jobb volt a hosszabb, beszélgető válaszokban, de a use case-re a forrás-pontosság fontosabb.
Buktatók
Az első buktató: a magyar nyelvű katalógus-szövegek minősége vegyes. Egyes termékeknél a leírás 2 mondat, másoknál 2 oldal. Bevezettünk egy 'tartalom-quality' score-t minden termékre, és a kevés-tartalmú termékeknél a chatbot proaktívan emberhez irányít.
A második: hallucination-edge case-ek. Az eval-szet 80 ticket-en 95% pontosság, de a vakon kihúzott 200 production-traffic ticket-en csak 87%. A különbség: a production-en sokkal többféle kérdés-megfogalmazás. Iteráltunk a system prompton, és bevezettünk egy 'confidence threshold' mechanizmust — ha a retrieval top-1 cosine similarity 0,7 alatt, automatikus átirányítás.
A harmadik: költségmonitorozás. Az első hetekben a token-felhasználás vártnál 40%-kal magasabb volt — kiderült, hogy a system prompt minden retrieval után újra elment, ami feleslegesen hosszú context. Bevezettünk prompt caching-et, és a havi LLM-költség 28%-kal csökkent.
Eredmények
Go-live után 4 hónappal: a support ticketek 38%-a már nem ér el emberi support-hoz (chatbot zárja le, vagy a felhasználó kapja meg az infót és nem nyit ticket-et). A támogatási CSAT (customer satisfaction) score nem romlott (4,3/5 a baseline, 4,3/5 ma).
A chatbot átlagos válaszidő 2,4s (median), 4,8s (p95). A bizonytalan kérdéseknél (confidence < 0,7) átirányítás emberhez 9 percen belül megtörténik. A support-csapat 1 fő kapacitást fel tudott szabadítani inbound értékesítésre (a vásárlás előtt érdeklődő ügyfél-csoportra), ami havi 800-1200 ezer Ft addicionális forgalmat eredményezett.
Stack
A meglepetés nem a chatbot pontossága volt, hanem hogy a csapatunk milyen gyorsan megtanulta használni az analytics dashboardot. Most látjuk először, hogy a vásárlók mit nem értenek a katalógusban.
Head of Support — E-commerce
Az idézet a tipikus ügyfél-feedbacket reprezentálja, nem szó szerinti idézet.
Kapcsolódó
Manuális lead-kezelést és emailes ügyfél-flow-t váltottunk Next.js webshopra WooCommerce katalógussal, n8n + OpenAI lead-osztályozóval. A sales 30-40 percnyi napi adminisztrációt nyert vissza.
RészletekEgy 12 fős, magyar-bázisú B2B SaaS startupnak újraépítettük a landing oldalt Next.js-en statikus generálással, hreflang HU/EN, PostHog A/B tesztelő infrastruktúrával. A free-trial konverzió 6 hét alatt 2,1%-ról 3,4%-ra emelkedett.
RészletekAz esettanulmányok valós projektek alapján készültek, anonimizálva az ügyfelek kérésére. A számok közelítések; a konkrét üzleti adatok titoktartás alatt állnak.