Rodzina 'merceAgents powstała po to, żeby uporządkować powtarzalne procesy w eCommerce i automatyzować je tam, gdzie daje to realną wartość. Customer Support jest pierwszym z tych narzędzi. To dopiero początek, bo kolejne agenty będą rozwijane w następnych obszarach.

'merceAgents Customer Support to kompletne rozwiązanie do automatyzacji obsługi klienta w eCommerce. W jego centrum działa AI Support Specialist, który przejmuje powtarzalne zapytania, odpowiada na podstawie aktualnej bazy wiedzy, pomaga klientom bezpiecznie sprawdzić status zamówienia w trybie tylko do odczytu i w razie potrzeby przekazuje sprawę do konsultanta wraz z pełnym kontekstem. Efekt to krótsze kolejki, spójne odpowiedzi oraz optymalizacja kosztów.

Punktem wyjścia był bardzo konkretny problem operacyjny. W większości eCommerce duża część zgłoszeń do BOK dotyczy tych samych tematów. Klienci pytają o status zamówienia, zwroty, terminy dostaw, adresy salonów. Każda odpowiedź wymaga czasu konsultanta, klient czeka w kolejce, a koszt obsługi rośnie wraz ze sprzedażą.

Dlatego powstało to rozwiązanie. Nie z potrzeby komplikowania, tylko z potrzeby dopasowania do realiów eCommerce. Pomiędzy uniwersalnymi chatbotami a specyfiką obsługi klienta w sprzedaży internetowej jest luka, którą trudno zagospodarować gotowym narzędziem.

Wiele narzędzi automatyzacji BOK działa dobrze tylko wtedy, gdy wcześniej przygotowany jest zestaw scenariuszy pytań i odpowiedzi oraz reguł decyzyjnych. Jeśli takiego scenariusza brakuje, albo klient formułuje pytanie inaczej niż przewidziano, automatyzacja szybko się wyczerpuje i rozmowa kończy się przekierowaniem lub błędną odpowiedzią. Customer Support działa inaczej. AI Support Specialist rozumie język naturalny i kontekst rozmowy, a odpowiedzi buduje na podstawie aktualnej bazy wiedzy i danych systemowych w trybie tylko do odczytu. Dzięki temu rozwiązanie obejmuje znacznie szerszy zakres realnych pytań klientów bez ręcznego projektowania drzewek dialogowych.

To historia tego, jak zbudowaliśmy agenta AI opartego na architekturze RAG, który odpowiada na pytania w czasie rzeczywistym, udostępnia statusy zamówień po uwierzytelnieniu i potrafi przekazać rozmowę człowiekowi, gdy wykryje frustrację rozmówcy lub gdy rozmówca wprost poprosi o kontakt z człowiekiem.

Od problemu biznesowego do decyzji technicznych

Typowy eCommerce obsługuje dziesiątki tysięcy zamówień miesięcznie. Nawet jeśli tylko pięć procent wymaga kontaktu, to i tak tysiące interakcji. Większość z nich nie jest skomplikowana. Klient pyta gdzie jest paczka, jak zwrócić produkt, czy jest salon w danym mieście. Konsultant otwiera system, sprawdza status, kopiuje odpowiedź, czasem dopisuje szczegół. To zajmuje minutę albo dwie. Przy stu takich zgłoszeniach dziennie robią się z tego ponad trzy roboczogodziny ręcznej pracy.

Dodatkowo wiedza jest rozproszona. FAQ na stronie, procedury w intranecie, makra w systemie ticketowym, wewnętrzne regulaminy, aktualizacje prawne. Kiedy coś się zmienia, trzeba pamiętać o aktualizacji w kilku miejscach. Czasem się o tym nie pamięta i przez jakiś czas część zespołu udziela nieaktualnych informacji.

Podczas analizy zidentyfikowaliśmy trzy kluczowe wymagania techniczne:

• Szybkość. Odpowiedź w rozsądnym czasie. Jeśli klient czeka zbyt długo, sens automatyzacji spada.
• Niezawodność. Rozwiązanie musi działać całą dobę przez cały rok. Każda przerwa to kolejka do konsultantów i frustracja klientów.
• Kontrola jakości. Asystent nie może halucynować informacji ani podejmować decyzji, do których nie ma uprawnień. Nie zmienia zamówień, nie rozstrzyga reklamacji, nie wymyśla polityk.

Świadomie ograniczyliśmy zakres. Automatyzujemy powtarzalne zapytania, dostarczamy statusy w trybie tylko do odczytu, integrujemy wiedzę w jednym miejscu, ale nie podejmujemy decyzji biznesowych za ludzi. To był celowy wybór. Chodziło o redukcję ryzyka i złożoności integracyjnej oraz skupienie na tym, co agent AI potrafi najlepiej, czyli udzielanie spójnych odpowiedzi opartych o fakty.

Architektura: RAG, wektorowa baza danych, integracje

Zbudowaliśmy rozwiązanie w oparciu o paradygmat RAG, czyli Retrieval Augmented Generation. To podejście, w którym model językowy nie odpowiada z pamięci, tylko generuje odpowiedzi na podstawie kontekstu zwróconego przez warstwę wyszukiwania. W praktyce działa to tak, że asystent najpierw znajduje właściwe fragmenty dokumentacji, a potem formułuje odpowiedź na ich podstawie.

To rozwiązanie pozwala indeksować teksty jako wektory liczbowe i wyszukiwać semantycznie podobne fragmenty. Przechowujemy dla każdego fragmentu wektor oraz treść, czyli strukturę, która spełnia podstawowe wymagania MVP.

Rdzeń systemu to trzy komponenty, które ściśle ze sobą współpracują:

• Silnik RAG odpowiada za wyszukiwanie wiedzy i generowanie odpowiedzi. Otrzymuje pytanie od użytkownika, szuka w bazie danych fragmentów tekstu pasujących do zapytania pod kątem semantycznym i sortuje wyniki od najbardziej do najmniej trafnych. Na tej podstawie model generuje odpowiedź, która jest zwracana do klienta.
• Interfejs czatu to warstwa, przez którą klient komunikuje się z asystentem. W obecnej wersji jest to własne okno czatu. Gdy sprawa wymaga człowieka, rozmowa może zostać przekazana konsultantowi wraz z historią i kontekstem.
• Centrum Pomocy to źródło prawdy. Wszystkie polityki, FAQ, procedury, informacje o salonach trafiają w jedno miejsce. Każda zmiana automatycznie wyzwala reindeksację, dzięki czemu asystent ma dostęp do aktualnych informacji.

Dlaczego własna implementacja zamiast gotowej bazy wektorowej?

W fazie MVP zdecydowaliśmy się na własną, prostą implementację wektorowej bazy danych zamiast zewnętrznych rozwiązań jak Qdrant czy Pinecone. Każdy fragment tekstu jest przekształcany w wektor, czyli ciąg liczb reprezentujący jego znaczenie semantyczne. Pytanie użytkownika również zostaje przekształcone w wektor. Rozwiązanie porównuje je ze sobą nie na poziomie liter, ale na poziomie pojęć. Dzięki temu jeśli klient zapyta “mogę zwrócić buty”, a w dokumentacji mamy sekcję polityka zwrotów dla obuwia, system to połączy mimo innych słów.

Nasza implementacja używa liniowego przeszukiwania wszystkich zapisanych wektorów. Złożoność wynosi O n. Dla obecnej skali bazy wiedzy to wystarczające, choć przy znaczącym wzroście korpusu będziemy rozważać migrację do dedykowanej bazy wektorowej z algorytmami typu HNSW, które oferują logarytmiczną złożoność wyszukiwania. Do generowania embeddingów używamy OpenAI Embeddings.

Jak przetwarzamy wiedzę: chunking i indeksowanie

Wiedza to nie jeden wielki dokument. To setki sekcji, rozdziałów, procedur i FAQ. Żeby rozwiązanie mogło skutecznie wyszukiwać odpowiedzi, musieliśmy podzielić treści na mniejsze fragmenty, czyli chunki.

Docelowy rozmiar chunka to cztery tysiące znaków z marginesem tysiąca znaków. Margines służy do tworzenia embeddingu z kontekstem, ale sam chunk jest zapisywany bez overlapu. Przechowujemy czystą treść fragmentu wraz z wektorem.

Każdy chunk zawiera dwa elementy. Pierwszy to wektor reprezentujący znaczenie semantyczne. Drugi to treść tekstowa. To minimalistyczna struktura, która spełnia podstawowe wymagania systemu RAG. W przyszłości planujemy rozbudować ją o metadane takie jak źródło, wersja dokumentu, data publikacji czy tagi tematyczne. Pozwoli to na bardziej precyzyjne filtrowanie wyników.

Rozwiązanie obejmuje też aktualizację. Kiedy strona w Centrum Pomocy zostaje zapisana, system automatycznie wyzwala reindeksację całej strony. Generuje nowe embeddingi i zapisuje je do bazy. Stary plik zostanie nadpisany nową wersją.

Pipeline odpowiedzi: od pytania do tekstu

Kiedy użytkownik pisze pytanie, system przechodzi przez kilka kroków, zanim wyśle odpowiedź:

• Wyszukiwanie semantyczne. Zapytanie trafia bezpośrednio do systemu embeddingów bez wstępnego przetwarzania czy normalizacji. Wygenerowany wektor jest porównywany ze wszystkimi wektorami w bazie poprzez obliczenie podobieństwa kosinusowego.
• Generowanie kandydatów. System zwraca dziesięć najbardziej podobnych chunków, posortowanych według wyniku podobieństwa. Wszystkie pasujące fragmenty trafiają do dalszego przetwarzania.
• Montaż kontekstu. Z listy kandydatów wybieramy najlepsze fragmenty, układamy je w logiczną całość i przekazujemy do modelu językowego.
• Generowanie odpowiedzi. Model językowy dostaje system prompt, czyli zasady, ograniczenia i styl komunikacji, oraz złożony kontekst. Generuje odpowiedź, która po zakończeniu jest zwracana do użytkownika. Interfejs pokazuje stan ładowania, a następnie wyświetla pełną odpowiedź.

Statusy zamówień: bezpieczeństwo i uprawnienia

Jedna z bardziej wrażliwych funkcji to udostępnianie statusu zamówienia. Z jednej strony to duże ułatwienie dla klienta. Z drugiej to obszar wymagający ścisłej kontroli, bo dotyczy danych osobowych.

W aktualnej wersji status zamówienia jest udostępniany dopiero po podaniu pełnych danych zamówienia, także wtedy, gdy użytkownik jest zalogowany. Rozwiązanie nie korzysta jeszcze z sesji użytkownika do automatycznego uwierzytelniania. Integracja działa w trybie tylko do odczytu. Asystent może pobierać informacje, ale nie ma możliwości modyfikacji zamówień. Czat nie ma bezpośredniego dostępu do danych zamówień — korzysta wyłącznie z narzędzia, które zwraca zamówienie na podstawie danych identyfikacyjnych. Agent wprost komunikuje, że potrzebuje konkretnych informacji i dopóki rozmówca ich nie poda, nie podejmie próby pobrania zamówienia. Wymagane dane to:

• numer zamówienia,
• numer telefonu,
• kod pocztowy dostawy,
• adres e-mail kupującego.

Dopiero po zebraniu tych informacji agent wywołuje narzędzie i pobiera dane zamówienia. Każde takie odpytywanie jest logowane.

Wydajność: obecny stan i plany optymalizacji

Jednym z ważnych wymagań jest utrzymanie rozsądnego czasu odpowiedzi. W obecnej implementacji MVP czasy odpowiedzi wahają się w zależności od złożoności zapytania. Proste pytania są obsługiwane szybciej, a bardziej złożone mogą wymagać kilku sekund. To obszar, który planujemy optymalizować.

Potencjalne kierunki optymalizacji:

• Migracja do dedykowanej bazy wektorowej z algorytmem HNSW, który oferuje wyszukiwanie w czasie logarytmicznym zamiast liniowego.
• Implementacja cache'a dla często zadawanych pytań i statusów zamówień.
• Streaming odpowiedzi do klienta, żeby użytkownik widział pierwsze słowa odpowiedzi, zanim zostanie wygenerowana w całości.
• Preprocessing zapytań. Normalizacja, lematyzacja, wykrywanie intencji. To może poprawić trafność wyszukiwania.

Samoocena jakości i panel audytu

Agent nie tylko generuje odpowiedzi, ale ocenia też ich jakość. 24 godziny po ostatniej wiadomości w rozmowie agent wykonuje dodatkowe wywołanie modelu, które analizuje przebieg rozmowy. Zwracamy wyniki w prostym formacie. To liczbowy wynik jakości oraz lista powodów uzasadniających ocenę. Zbudowaliśmy też dashboard, który prezentuje pełną historię rozmów z metadanymi. Konsultanci i menedżerowie widzą:

• Transkrypcje rozmów z pełną historią wiadomości.
• Oceny samooceny, score i powody, finalny wynik rozmowy, rozwiązana przez AI albo przekazana człowiekowi.
• Listę eskalacji do konsultanta z danymi kontaktowymi i opisem problemu.

Czego celowo nie zrobiliśmy i dlaczego

Budując asystenta, podjęliśmy kilka świadomych decyzji o tym, czego nie będziemy robić. Nie dlatego, że nie potrafiliśmy, ale dlatego, że nie chcieliśmy wprowadzać ryzyka ani złożoności, której nie jesteśmy w stanie kontrolować.

• Nie daliśmy asystentowi uprawnień do modyfikacji zamówień. Mógłby anulować zamówienie, zmienić adres dostawy, zmodyfikować pozycje. To byłoby wygodne dla klienta, ale też ogromne ryzyko. Każdy błąd modelu to potencjalnie źle wysłana paczka, duplikat zamówienia, strata finansowa. Woleliśmy ograniczyć zakres do tylko do odczytu i skupić się na wysokiej jakości informacji.
• Nie daliśmy asystentowi prawa do rozstrzygania reklamacji. Polityki bywają niejednoznaczne. Czasem trzeba zastosować dobrą wolę, czasem interpretować nietypowy przypadek. To wymaga ludzkiego osądu. Asystent przygotowuje dokumentację, zbiera informacje, proponuje warianty, ale ostateczna decyzja należy do człowieka.
• Nie postawiliśmy na ciężki reranking i długie łańcuchy narzędzi. Cross encodery i wieloetapowa walidacja poprawiają trafność, ale wydłużają czas odpowiedzi.

Naszym zdaniem te ograniczenia to nie słabości. To granice odpowiedzialności. Jasno definiujemy, co asystent robi dobrze i nie próbujemy rozciągać go na obszary, gdzie nie mamy pewności.

Czego nauczyliśmy się w trakcie budowy?

• Inżynieria wiedzy to połowa sukcesu. Precyzyjny podział na fragmenty ma duży wpływ na jakość odpowiedzi. W przyszłości planujemy dodać wersjonowanie, metadane i spójne tagowanie.
• Proste narzędzia, jasne kontrakty. Wywołania do systemów zewnętrznych muszą mieć ścisły kontrakt. Co jest wejściem, co wyjściem, co jest błędem. Logika narzędzi nie może żyć w promptach. Musi być deterministyczna, testowalna i audytowalna. To zmniejsza powierzchnię błędów i ułatwia debugowanie.
• MVP najpierw, optymalizacja później. Zaczęliśmy od prostej implementacji. To pozwoliło szybko zwalidować koncepcję i zidentyfikować rzeczywiste wąskie gardła, zamiast optymalizować na ślepo.
• Panel jakości to konieczność, nie opcja. Samoocena modelu znacząco ułatwia przegląd przypadków brzegowych, a panel audytu zamyka pętlę uczenia się organizacji.
• Sto procent transkrypcji to podstawa. Bez pełnej historii rozmów nie mamy jak wykrywać luk w wiedzy ani kalibrować wyszukiwania. To first party data, która napędza rozwój.
• Bezpieczeństwo to proste zasady, wielokrotnie egzekwowane. Tylko do odczytu, tokeny o ograniczonym zakresie, maskowanie danych osobowych, audyt wywołań. To niewielki koszt implementacyjny, a ogromne ograniczenie ryzyka.

Co dalej?

Rozwiązanie działa, odpowiada na pytania i redukuje obciążenie konsultantów. Ale to nie jest koniec. To początek. Obecna wersja to działające MVP, które planujemy rozbudowywać, np. o migracja do dedykowanej bazy wektorowej z algorytmem HNSW czy poprawę UX.

Obecny wpływ na dział BOK

Wdrożenie asystenta AI w obsłudze klienta to nie tylko kwestia oszczędności kosztów. To zmiana sposobu pracy i jakości komunikacji.

Odciążenie konsultantów:

• Najprostsze zapytania przestają trafiać do zespołu
• Konsultanci koncentrują się na przypadkach trudnych i niestandardowych
• Mniej kopiowania i przeklejania odpowiedzi, więcej rozwiązywania problemów

Lepsza spójność odpowiedzi:

• Odpowiedzi pochodzą z jednej bazy wiedzy
• Zmiana polityki lub procedury nie wymaga przekazywania instrukcji w wielu kanałach
• Każda odpowiedź jest zapisywana w historii rozmów

Skalowanie bez proporcjonalnego wzrostu kosztów:

• Wzrost wolumenu zgłoszeń nie wymaga proporcjonalnego wzrostu zespołu BOK
• Nowe rynki i języki bez powielania całego zespołu konsultantów

Doświadczenie klienta:

• Dostęp do statusu zamówienia o każdej godzinie bez kontaktu z człowiekiem
• Spójne odpowiedzi niezależnie od tego, kto akurat dyżuruje

Customer Support jest pierwszym z narzędzi w rodzinie 'merceAgents. Kolejni agenci będą rozwijani w tym samym podejściu, tak aby obejmować następne obszary operacyjne i sprzedażowe w eCommerce.