Problem: odpowiedź jest, tylko nie wiadomo gdzie
Regulamin zwrotów leży w folderze na dysku, warunki dostawy w PDF-ie z zeszłego roku, a sprzedaż w ERP, do którego raporty robi jedna osoba. Handlowiec, który chce odpowiedzieć klientowi, pyta kolegę. Kierownik, który chce wiedzieć, jak idzie rekuperacja w lubelskim, czeka na zestawienie.
Po stronie klienta jest podobnie: „gdzie jest moja paczka?”, „czy mogę to zwrócić?”, „urządzenie nie działa”. Odpowiedź wymaga sprawdzenia zamówienia w ERP, śledzenia u kuriera i regulaminu, a potem założenia sprawy w kolejnym systemie.
Typowy chatbot „na dokumentach” rozwiązuje jedną trzecią problemu. Na pytanie o liczby odpowiada zmyśloną kwotą, a sprawy nie załatwi, bo nie ma dostępu do systemów. Dlatego w demo każdy rodzaj pytania obsługujemy inaczej.
Jak to działa
Każde pytanie trafia do modelu językowego z jednym zadaniem: zdecydować, skąd ma przyjść odpowiedź.
- Pytanie o zasady → dokumenty. Model pisze krótką odpowiedź i wskazuje identyfikatory fragmentów, na których się oparł. Serwer sprawdza, czy te fragmenty istnieją. Odpowiedź bez poprawnego cytatu nie jest wyświetlana. Użytkownik widzi cytowany tekst pod odpowiedzią.
- Pytanie o liczby → zapytanie. Model nie liczy. Zwraca opis zapytania: miarę (przychód, zysk, marża, zamówienia), podział (miesiące, regiony, kategorie), filtry i okres. Serwer odrzuca wartości spoza dozwolonej listy, a sumy, marże i trendy liczy zwykły kod. Zapytanie jest widoczne pod wykresem w sekcji „Jak to policzono”.
- Sprawa do załatwienia → systemy. Model rozpoznaje intencję (status, zwrot, reklamacja) i numer zamówienia. Resztę robi kod: pobiera zamówienie, sprawdza reguły regulaminu i proponuje akcję, którą użytkownik musi potwierdzić.
- Brak źródła → uczciwe „nie wiem”. Jeśli odpowiedzi nie ma w żadnym źródle, asystent mówi to wprost. Nie uzupełnia luk wiedzą ogólną modelu.
W demo zapytanie „Jak zmieniała się sprzedaż rekuperacji w lubelskim?” pokazuje wykres z wyraźnym spadkiem od stycznia 2026. Model tego spadku nie „wie”. Wynika on z danych, które przeliczył kod.
Dlaczego liczby liczy kod, a nie model
Model językowy dobrze rozumie pytanie, ale nie jest kalkulatorem. Poproszony o sumę kilkuset wierszy odpowie liczbą, która brzmi wiarygodnie. Podział ról usuwa ten problem:
- model tłumaczy język na strukturę, czyli robi to, w czym jest dobry;
- kod wykonuje obliczenia, zawsze tak samo;
- użytkownik widzi zapytanie i może ocenić, czy asystent dobrze zrozumiał pytanie.
U klienta ta sama zasada działa z bazą danych: zapytanie trafia do widoku w ERP lub hurtowni danych z uprawnieniami danego użytkownika. Model nie dostaje całej tabeli, tylko opis kolumn.
Sprawy klientów: model rozpoznaje, kod decyduje, człowiek zatwierdza
Najciekawsza część demo to obsługa klienta. Trzy przykłady z fikcyjnego konta:
- „Gdzie jest moja paczka?” Asystent nie zgaduje, o które zamówienie chodzi, tylko pokazuje listę zamówień klienta. Po wyborze pobiera status z ERP i zdarzenia od kuriera, a planowaną dostawę liczy na najbliższy dzień roboczy.
- „Chcę zwrócić zamówienie ZM-1044.” Kod sprawdza reguły po kolei: czy towar dostarczono, czy nie był sprowadzany na indywidualne zamówienie, ile dni minęło. Po 14 dniach dolicza opłatę 10% i cytuje paragraf, z którego ona wynika. Zwrot powstaje dopiero po kliknięciu „Zleć zwrot”.
- „Pompa z ZM-1041 wyświetla błąd E3.” Pompy nie można zwrócić, ale można ją zareklamować. Asystent pobiera numer seryjny z ERP, zakłada zgłoszenie w systemie serwisowym i podaje terminy z procedury.
Pod każdą odpowiedzią widać listę wywołań systemów, na przykład ERP · GET /zamowienia/ZM-1044 albo Serwis · POST /zgloszenia. To ważne przy wdrożeniu: asystent ma wąską, jawną listę dozwolonych operacji. Nie może zrobić niczego, czego nie ma na tej liście. Każda zmiana w systemie wymaga potwierdzenia.
Numer zamówienia też jest pilnowany przez kod. Model w testach potrafił „pożyczyć” numer z wcześniejszej rozmowy do nowego pytania. Dlatego serwer przyjmuje numer tylko wtedy, gdy padł w bieżącym pytaniu. W innym przypadku asystent pokazuje listę zamówień.
Co jest w demo, a czego nie ma
Demo działa na fikcyjnej hurtowni instalacyjnej Demo-Instal: 12 fragmentów dokumentów (zwroty, reklamacje, dostawy, rabaty, regulamin pracy), 320 wierszy sprzedaży z 20 miesięcy i konto fikcyjnego klienta z sześcioma zamówieniami. Wszystkie liczby są wygenerowane. Model to Llama 3.3 70B uruchamiany w Cloudflare Workers AI. Pytań nie zapisujemy, a limit to 20 pytań na godzinę z jednego adresu.
Świadome uproszczenia, które w projekcie dla firmy wyglądają inaczej:
- Wyszukiwanie w dokumentach. Przy 12 fragmentach model dostaje wszystkie naraz. Przy setkach dokumentów dochodzi wyszukiwarka, która wybiera właściwe fragmenty, oraz aktualizacja indeksu po zmianie pliku.
- Systemy. ERP, kurier i serwis są symulowane w przeglądarce, a zgłoszenia znikają po odświeżeniu strony. We wdrożeniu te same operacje wołają API systemów firmy po stronie serwera.
- Uprawnienia. Demo jest publiczne. W firmie asystent widzi tylko to, do czego ma dostęp zalogowany pracownik.
- Rozmowa. Asystent pamięta kilka ostatnich wymian, więc rozumie „a w małopolskim?”. Dłuższa pamięć i przekazanie rozmowy konsultantowi to kolejne kroki.
- Weryfikacja. Sprawdzamy, czy cytowane fragmenty istnieją. W pilotażu dochodzi zestaw prawdziwych pytań zespołu z oczekiwanymi odpowiedziami, na którym mierzymy jakość przed uruchomieniem.
Od demo do wdrożenia
Zaczynamy od jednego zespołu lub jednego procesu obsługi klienta, na przykład zwrotów. Podłączamy dokumenty, jeden widok danych i dwa lub trzy systemy, sprawdzamy odpowiedzi na próbce prawdziwych pytań i dopiero wtedy decydujemy o dalszym rozwoju. Tak wygląda nasz pilotaż: jeden scenariusz, jasne kryteria, ocena jakości i kosztu przed większą inwestycją.
Wypróbuj demo albo napisz, o co najczęściej pyta Twój zespół.