Console CX: RAG to nie jest lekarstwo na wszystko. Szczególnie w e-commerce.

Każda pozycja to elementy elektroniczne:
➡️ rezystory
➡️ kondensatory
➡️ układy scalone
➡️ tranzystory

Każdy produkt ma zestaw parametrów:
➡️ wartość nominalna
➡️ obudowa
➡️ napięcie
➡️ pojemność
➡️ tolerancja
➡️ zakres temperatur

Pierwszy problem: użytkownicy wpisują zapytania tak, jak im wygodnie:
„10kom 0603 1%”, „rezystor 10k 0805”, „zamiennik bc547” itd.

Wyszukiwanie musiało być szybkie i bezbłędne.

Na początku poszliśmy standardową ścieżką:
- podzieliliśmy opisy produktów na chunki
- stworzyliśmy embeddingi
- wdrożyliśmy wyszukiwanie wektorowe

Spędziliśmy sporo czasu na iteracjach i szukaniu „idealnych” ustawień RAG.
Finalnie - w tym przypadku to się po prostu nie sprawdziło.

Zapytanie „rezystor 10 kΩ 0805”:
- mogło zwrócić 10 kΩ, ale w innej obudowie
- albo 100 kΩ
- albo nawet kondensator

Dlaczego:
- embeddingi słabo rozróżniają liczby i jednostki chunking:
- duże chunki → rozmycie wyników
- małe chunki → utrata kontekstu (np. tolerancja, moc)

❎ Efekt:❎
- niska trafność
- wyższy czas odpowiedzi
- niestabilne wyniki

Przetestowaliśmy praktycznie wszystkie hipotezy, które mogły dać 100% trafności - bez sukcesu.

Zrezygnowaliśmy z RAG (dla danych produktowych i ich parametrów) i uprościliśmy podejście.

✅ 1. Klasyczna baza danych
PostgreSQL, gdzie:
jeden rekord = jeden produkt:
typ
wartość nominalna
obudowa
tolerancja
SKU
link do datasheetu

✅ 2. Normalizacja zapytania (z użyciem AI + słownika klienta)
Przed wyszukiwaniem standaryzujemy zapytanie:
- usuwamy zbędne spacje
- zamieniamy na małe litery
- normalizujemy jednostki:
- „kom” → „kΩ”
- wyciągamy wartości liczbowe i parametry

❇️ Przykład:
"10kom 0603 1%" → "10 kΩ 0603 1%"
3. Wyszukiwanie bez wektorów

❇️ Budujemy pole tekstowe:
typ + wartość nominalna + obudowa + tolerancja
I korzystamy z klasycznego wyszukiwania pełnotekstowego z indeksem.

❇️ Wynik
~20 ms czasu odpowiedzi
ok. 95% trafności

✅ Dodaliśmy:
- tabelę synonimów
- proste reguły zamiany

• To wystarczyło, żeby przy dziesiątkach tysięcy produktów uzyskać bardzo precyzyjne wyniki.

W przypadku katalogu e-commerce z jasno zdefiniowanymi parametrami:
RAG okazał się zbędny - klasyczne wyszukiwanie działa lepiej.

Bo tutaj liczy się:
Dokładne dopasowanie wartości a nie „podobieństwo” semantyczne.
Gdzie RAG ma sens.

✅ RAG zostawiliśmy do:
- danych nieustrukturyzowanych (teksty, artykuły)
- zapytań ogólnych

• - przypadków, gdzie dokładność liczb nie jest kluczowa