Bot na Telegramie: pytasz głosem, dostajesz odpowiedź głosem

Problem

Firmowy system wie wszystko, co trzeba, ale mieszka w przeglądarce. Żeby sprawdzić jedną liczbę, trzeba wyjąć laptopa, zalogować się, znaleźć właściwy ekran i odczytać. W biurze to trzydzieści sekund. W samochodzie, między spotkaniami albo z telefonem w jednej ręce — to się po prostu nie dzieje, więc pytanie zostaje bez odpowiedzi do wieczora.

Zadanie: dostęp do tych samych danych z komunikatora, którego i tak używa się codziennie. Pytanie zadane głosem w drodze, odpowiedź w tej samej formie.

Co powstało

Bot przyjmuje wiadomość głosową albo tekst, potrafi odpowiedzieć głosem albo tekstem, przyjmuje zdjęcia i prowadzi pamięć rozmowy osobno dla każdego rozmówcy, więc pytanie „a ile było w zeszłym miesiącu?” ma się do czego odnieść. Odpowiedź przychodzi w 2,5 do 5 sekund. Całość to 48 elementów w jednym przepływie, działa produkcyjnie i została sprawdzona na prawdziwych rozmowach, a nie na trzech przykładach z dokumentacji.

Dwie decyzje projektowe, które warto skopiować

Odpowiedź dłuższa niż 600 znaków wraca tekstem, nie głosem. Nikt nie chce słuchać czytanej na głos listy dwudziestu pozycji — po czwartej i tak przestaje się słuchać, a przewinąć nagrania do konkretnego miejsca się nie da. Krótka odpowiedź głosem jest wygodna, długa jest karą. Ten jeden warunek zdecydował o tym, czy bot jest używany, czy porzucony.

Dostęp ograniczony listą dozwolonych rozmówców. Bot bez takiej listy to otwarty automat, za którego wywołania modeli płaci właściciel. Ktoś znajdzie go przypadkiem albo celowo i wygeneruje rachunek, o którym dowiesz się z faktury. To nie jest ostrożność przesadzona — to jest jedyna wersja, którą wolno wypuścić.

Najciekawszy fragment: bot wymyślił dane, brzmiąc całkowicie wiarygodnie

Na pytanie kontekstowe — „a ile z nich było z Poznania?” — bot podał rozbicie na miasta. Ładne, konkretne, z liczbami. Żadne z jego narzędzi takiego rozbicia nie zwróciło. Wymyślił je, bo pytanie sugerowało, że taka informacja powinna istnieć, a odpowiedź brzmiąca kompetentnie jest dla modelu językowego łatwiejsza niż przyznanie się do braku danych.

To jest najgroźniejszy rodzaj błędu w takim narzędziu, bo nie wygląda na błąd. Zła odpowiedź z komunikatem o awarii jest nieszkodliwa. Zła odpowiedź podana pewnym tonem trafia na spotkanie.

Naprawa polegała na zaostrzeniu instrukcji: odpowiadaj wyłącznie na podstawie tego, co faktycznie zwróciły narzędzia, a jeżeli czegoś nie ma — powiedz wprost, czego nie ma. Efekt był mocniejszy, niż się spodziewałem: bot, mając poprzednią odpowiedź nadal w pamięci rozmowy, sam odwołał swoją wcześniejszą liczbę i wyjaśnił, że nie ma dostępu do takiego rozbicia.

Model, który zamiast czytać — odpowiadał

Drugi zaskakujący moment dotyczył zamiany tekstu na mowę. Model dostawał instrukcję „przeczytaj ten tekst dosłownie, nie komentuj”, a zamiast czytać — odpowiadał na jego treść. Zamiast odczytać nazwę klienta, mówił coś w rodzaju „Rozumiem, Fabryka Pływania… Czy potrzebujesz pomocy?”. Brzmiało to jak usterka, a było nieporozumieniem co do roli.

Okazało się, że ta klasa modeli ignoruje instrukcje systemowe — czyli tę warstwę polecenia, w której zwykle opisuje się, kim model ma być. Ta sama instrukcja przeniesiona do zwykłej wiadomości zadziałała bez zmian. Warto to pamiętać, bo objaw („model nie słucha poleceń”) kieruje uwagę na treść polecenia, a przyczyna leży w tym, w którym miejscu je umieszczono.

Ślepa uliczka: świetny głos bez polskiego

Po drodze trafiłem na model mowy, który brzmiał wyraźnie lepiej od reszty i obsługiwał osiem języków. Polskiego wśród nich nie było, więc do polskiego tekstu stosował obcą fonetykę — zrozumiale, ale z akcentem, który natychmiast zdradzał automat. Odrzucony po odsłuchu. Zapisuję to, bo lista obsługiwanych języków w opisie narzędzia nie zastępuje posłuchania, jak to brzmi po polsku, a w produkcie mówiącym do klienta akcent nie jest szczegółem.

Wątek diagnostyczny: co czwarte połączenie przepadało

Bot potrafił zawiesić się na minuty. Wyglądało to na problem z modelem albo z przeciążeniem serwera, ale pomiar pokazał co innego: 20–25 procent połączeń z serwera do usługi komunikatora po prostu przepadało. Przy czym kontrole do innych adresów były czyste, a te same adresy odpytywane z innej sieci odpowiadały bezbłędnie. Czyli ani serwer, ani usługa po drugiej stronie nie były winne.

Prześledzenie trasy pakietów wyjaśniło wszystko. Ruch rozkładał się u operatora na cztery równoległe ścieżki, a jedna z nich była uszkodzona. Jedna zepsuta z czterech daje dokładnie te obserwowane ćwierć strat — liczba, która wcześniej wyglądała na przypadek, okazała się podpisem konkretnej usterki.

Gorsza część odkrycia dotyczyła ponawiania. System operacyjny, ponawiając nieudane połączenie, używa tego samego portu źródłowego — a to oznacza, że pakiet leci tą samą zepsutą ścieżką. Cierpliwe czekanie na odpowiedź nie miało więc żadnej wartości: po 129 sekundach kończyło się tym samym, czym po piętnastu. Skrócenie czasu oczekiwania ze 129 do 15 sekund nie naprawiło sieci operatora, ale sprawiło, że bot dowiaduje się o porażce osiem razy szybciej i może zareagować, zamiast wisieć.

Efekt

• odpowiedź w 2,5–5 sekundy, głosem lub tekstem, z pamięcią rozmowy per rozmówca,
• 129 s → 15 s — tyle zajmuje teraz stwierdzenie, że połączenie padło,
• halucynacja wykryta i wyeliminowana; bot mówi wprost, czego nie ma w danych,
• dostęp ograniczony listą rozmówców, więc rachunek za modele nie jest publiczny,
• 48 elementów w przepływie, działa produkcyjnie na prawdziwych rozmowach.

Co z tego wynika dla firmy

Największa wartość takiego bota nie leży w tym, że mówi. Leży w tym, że skraca drogę do danych z „wyjmij laptopa, zaloguj się, znajdź ekran” do jednego pytania zadanego w komunikatorze, którego i tak używasz. Reszta to szczegóły wykonania.

Trzy pytania, które warto zadać każdemu, kto proponuje asystenta na firmowych danych: co robi, gdy nie zna odpowiedzi (patrz historia z halucynacją), kto ma do niego dostęp (i kto płaci za cudze pytania) oraz po jakim czasie przyznaje się, że coś nie zadziałało. Trzecie pytanie brzmi technicznie, ale to ono decyduje, czy narzędzie się zawiesza, czy uczciwie melduje awarię.

Stack: n8n jako warstwa wykonawcza (48 elementów w jednym przepływie), bot komunikatora jako interfejs, rozpoznawanie mowy i synteza mowy przez modele wywoływane jednym dostawcą, model językowy z dostępem do narzędzi odpytujących firmową bazę, pamięć rozmowy trzymana w bazie danych osobno dla każdego rozmówcy. Wdrożenie na własnej infrastrukturze.

Inne case studies