A RAG chatbot with pgvector and OpenAI GPT-4o, integrated into an existing Shopify storefront. 38% of support tickets close automatically; customer satisfaction didn't drop.
Background
The client is a Hungarian e-commerce retailer in the garden tools and home goods segment, with ~3200 SKUs and a B2C focus. The 3-person support team handles 80–120 tickets per day: the most common are product-spec questions ('does this fit my X machine?'), shipping status and product recommendations.
The client noticed support volume grew linearly with sales. Instead of hiring, they wanted a self-service solution. The existing FAQ page and Shopify chatbot integration didn't give meaningful answers on product specifications.
Challenge
Product-spec chatbots are one of the harder AI use cases. The catalogue is dynamic (weekly 30–50 new products, 100+ price updates), and questions are contextual: 'does this disc fit my X mower' demands a shared understanding of the catalogue text, the compatibility matrix and the user's setup.
Second challenge: hallucination control. If the chatbot says 'sure, it fits' on a non-matching product, that triggers returns and unhappy customers. The client's explicit requirement: every chatbot answer needs a source link, and uncertainty has to route to a human.
Approach
We built a RAG (Retrieval-Augmented Generation) architecture with pgvector on Supabase. The retrieval pipeline uses 4 chunk types per product: 1) name + parent category, 2) description, 3) technical spec, 4) compatibility information (where available).
The chatbot LLM is OpenAI GPT-4o with an explicit system prompt: 'only answer if it's in the sources; otherwise route to a human'. The eval set has 80 real ticket histories labeled manually, and the regression test runs on every prompt change.
Solution
The chatbot embeds as a Next.js widget into the Shopify storefront (the client didn't want a Shopify-native integration because they're more constrained). The Shopify Storefront API gives real-time product data (price, stock) to the bot, so recommendations are always current.
The pipeline: user query → embedding (OpenAI text-embedding-3-small) → pgvector top-k (k=8) retrieval → context for GPT-4o → response generation with source links. Every interaction is logged in PostHog (anonymized), and Sentry tracks backend errors.
An n8n workflow syncs the Shopify catalogue into the pgvector index daily: embedding new products, re-embedding updated descriptions, removing deleted ones. The index lags 2–3 hours behind the catalogue — acceptable trade-off between real-time queries and embedding cost.
Tech decisions
We picked OpenAI text-embedding-3-small (over -large) because: 1) it's 5x cheaper and faster, 2) on the Hungarian-language retrieval eval set it gets 92% recall@8 — enough for the use case, 3) multiple retrievals (k=8) compensate for the precision gap.
pgvector vs Pinecone: pgvector won because the client team already used Postgres elsewhere, and the self-hosted option simplifies GDPR. 3200 products × 4 chunks × 1536 dim fits Supabase's free tier easily, but we run production on a hot tier.
GPT-4o vs Claude Sonnet: we re-evaluated both per side. GPT-4o was better at precise Hungarian-language source quoting (95% precision vs Claude's 87% on the eval set). Claude was better at longer conversational answers, but source precision matters more for this case.
Bumps
First hurdle: the Hungarian catalogue copy is uneven. Some products have 2-sentence descriptions, others 2 pages. We added a 'content quality' score per product, and on low-content products the bot proactively routes to a human.
Second: hallucination edge cases. The eval set's 80 tickets hit 95% precision, but a blind sample of 200 production tickets only 87%. The difference: production users phrase questions much more variously. We iterated on the system prompt and added a 'confidence threshold' — if top-1 cosine similarity falls below 0.7, automatic human handoff.
Third: cost monitoring. In early weeks token usage was 40% above expectation — the system prompt was being sent on every retrieval, which inflated context. We added prompt caching and monthly LLM cost dropped 28%.
Results
Four months after go-live: 38% of support tickets no longer reach a human (the bot closes them or the user gets the info and doesn't open a ticket). Support CSAT didn't drop (4.3/5 baseline, 4.3/5 today).
Average chatbot response time is 2.4s (median), 4.8s (p95). On uncertain questions (confidence < 0.7), human handoff happens within 9 minutes. The support team freed 1 FTE to focus on inbound sales (the pre-purchase enquirer segment), generating an additional HUF 800k–1.2M of monthly revenue.
Stack
The surprise wasn't the chatbot's accuracy, but how quickly the team learned to use the analytics dashboard. We can now see for the first time what customers don't understand in the catalogue.
Head of Support — E-commerce
The quote represents typical client feedback; it is not a verbatim citation.
Related
We replaced manual lead handling and email-based customer flows with a Next.js webshop on a WooCommerce catalogue and an n8n + OpenAI lead classifier. Sales recovered 30–40 minutes of daily admin per person.
Read detailsWe rebuilt the landing site for a 12-person Hungarian B2B SaaS startup on Next.js with static generation, hreflang HU/EN and PostHog A/B testing. Free-trial conversion went from 2.1% to 3.4% in 6 weeks.
Read detailsCase studies are based on real projects, anonymized at our clients' request. Numbers are approximations; specific business data remains confidential.