Jak przetestować asystenta głosowego AI przed wdrożeniem

Krótka odpowiedź: asystenta głosowego AI przed wdrożeniem trzeba sprawdzić na tych samych zadaniach wykonanych głosem i tekstem, a po każdej operacji ocenić stan danych. Przygotowałem 20 polskich przypadków sprawdzających między innymi numery, kwoty, negację i zgodę na wysyłkę; wyników prób jeszcze nie ma. Punktem wyjścia jest wydanie Open WebUI 0.12.0 z 10 października 2026, w którym rozmowa głosowa zostawia zatwierdzanie narzędzi w czacie. W domyślnej konfiguracji tego wydania narzędzia działają jednak bez pytania o zgodę.

Jeżeli pracownik ma wolne ręce dopiero do chwili, gdy trzeba kliknąć zgodę, firma powinna wiedzieć o tym przed zakupem integracji. Dlatego karta zapisuje też przejścia do klawiatury i czas całej sprawy.

Co zmienia Open WebUI 0.12.0

Nowy tryb rozdziela rozmowę głosową od wykonywania zadania. Według autorów wydania model głosowy sam prowadzi luźną rozmowę, a merytoryczne pytania i zadania przekazuje do modelu wybranego w czacie, wraz z jego historią i narzędziami. Odpowiedź pojawia się również w formie tekstowej. Zatwierdzenia oraz pytania narzędzi nadal wymagają obsługi w czacie.

Zatwierdzenie pojawia się jednak dopiero po dwóch zmianach ustawień. W kodzie wydania 0.12.0, odczytanym 13 października 2026, administrator musi włączyć eksperymentalną opcję „Uprawnienia narzędzi” (Tool Permissions), domyślnie wyłączoną, a w czacie trzeba wybrać „Poproś o zatwierdzenie” (Ask for approval). Bez tego obowiązuje „Pełny dostęp”, w którym narzędzia działają bez pytania. Wybór zapisuje się w ustawieniach użytkownika i w parametrach czatu, więc przy odbiorze sprawdziłbym go w każdym czacie testowym. Ten sam opis wydania wymienia poprawki dwóch błędów, przez które narzędzia mogły działać bez pytania: w czatach tymczasowych mimo włączonego zatwierdzania oraz po przywróceniu szkicu wiadomości, które zmieniało tryb.

Rozdzielenie rozmowy głosowej od wykonania zadania ma dla odbioru prostą konsekwencję: trzeba sprawdzić całą drogę od wypowiedzianego polecenia do wyniku w firmowym systemie. Błąd może pojawić się przy rozpoznaniu numeru, wyborze danych, wykonaniu operacji albo odczytaniu odpowiedzi. Przyczyny da się rozdzielić dopiero z zapisem tych etapów.

Nie uruchamiałem Open WebUI ani płatnej usługi głosowej. Sprawdziłem opis wydania i wskazany w nim kod. Własnym wkładem jest zestaw zadań, danych i kryteriów, z którym firma może odebrać takie rozwiązanie od wykonawcy.

Dlaczego własny interfejs nie oznacza lokalnego głosu

Miejsce instalacji Open WebUI nie rozstrzyga, kto przetwarza audio. W kodzie nowej funkcji domyślny adres API Realtime prowadzi do zewnętrznej usługi OpenAI, a domyślnym modelem rozmowy jest gpt-realtime-2.1-mini z głosem Marin. Model wykonujący zadanie oraz podłączone narzędzia mają własną konfigurację. To wniosek z odczytu kodu 12 października 2026, bez pomiaru ruchu sieciowego.

Przed użyciem danych firmy poprosiłbym wykonawcę o narysowanie faktycznej drogi audio, tekstu i dokumentów. Każdy etap powinien mieć wskazanego dostawcę, zakres przekazywanych danych oraz ustawienia przechowywania, także wtedy, gdy wykonawca zapewnia, że wszystko działa „na naszym serwerze”.

Przy wycenie trzeba również uwzględnić wszystkie wywołania potrzebne do ukończenia sprawy. Rozmowa i wykonanie zadania mogą korzystać z różnych usług. Według cennika OpenAI odczytanego 13 października 2026 domyślny model rozmowy gpt-realtime-2.1-mini kosztuje 10 USD za milion tokenów audio na wejściu i 20 USD na wyjściu, a wywołania modelu czatu liczy się osobno. Cenę pilotażu należy odnieść do ukończonych poprawnie spraw wraz z poprawkami, zgodnie z zasadami wyceny agenta AI.

Jakie zadania powinien przejść asystent głosowy AI

Karta przygotowana 12 października 2026 zawiera 20 przypadków na syntetycznych zamówieniach i kontaktach. Każdy ma polecenie, stan początkowy i kryterium poprawnego zakończenia. OpenAI deklaruje, że gpt-realtime-2.1-mini lepiej niż GPT-Realtime-2 rozpoznaje ciągi liter i cyfr; numery zamówień z karty pozwolą sprawdzić rozpoznawanie takich ciągów w polskich poleceniach, bez porównania obu modeli. Poniższe przykłady pokazują, co oceniać poza brzmieniem odpowiedzi.

W paczce są również brakujący numer przesyłki, nieistniejące zamówienie i ponowiona prośba o wysyłkę. Odpowiedź „gotowe” trzeba porównać z rzeczywistym stanem danych po operacji.

Zgoda w interfejsie i uprawnienie do danych pełnią osobne role. Kliknięcie akceptacji nie powinno przywracać odebranego wcześniej prawa. Część przypadków sprawdza więc całą integrację, w tym firmowe narzędzia. Ewentualnego błędu nie można automatycznie przypisać modelowi głosowemu ani Open WebUI. Jak sprawdzić odebranie prawa w otwartej sesji, pokazuję w teście serwera MCP.

Jak porównać głos z tekstem bez zmiany warunków

Dla każdego z 20 przypadków zaplanowałem dwie próby, głosem i tekstem, czyli 40 pustych wierszy w arkuszu. Oba kanały powinny używać tych samych danych, praw, narzędzi i modelu zadaniowego. Kanał rozpoczynający parę zmienia się naprzemiennie.

Przed każdą próbą trzeba odtworzyć stan początkowy i rozpocząć świeżą rozmowę. Inaczej pierwszy kanał może zmienić zamówienie, a drugi dostać już inne zadanie. Naprzemienna kolejność ogranicza przewagę jednego kanału, ale nie usuwa całego wpływu wprawy operatora.

W karcie koniec próby zależy od zadania: może oznaczać odpowiedź, wykonaną operację, odmowę albo oczekiwanie na zgodę. Poprawne oczekiwanie zalicza scenariusz, lecz nie kończy wysyłki. Czasy porównuj w obrębie tej samej pary; protokół wymaga wspólnego limitu ustalonego przed startem.

Mierz osobno pracę człowieka i czas próby z oczekiwaniem na system. Wlicz poprawianie polecenia, sprawdzanie wyniku i przechodzenie do czatu. Zapisuj także błędne oraz przerwane próby. Dopiero dodatkowy pomiar całego procesu pokaże czas poprawnie zakończonej sprawy biznesowej.

Koszt i czas zapisuje się obok wyniku jakości, bo szybka odpowiedź skierowana do złego odbiorcy liczy się w karcie jako błąd. Więcej o rozdzieleniu oszczędności czasu od pieniędzy piszę w pomiarze efektu wdrożenia AI.

Co pobrać i czego ten zestaw nie rozstrzyga

Udostępniam paczkę odbiorową ZIP, arkusz CSV, protokół i instrukcję. Weryfikator potwierdza kompletność plików i zgodność sum SHA-256. Nie wykonuje testu modelu. Arkusz pozostaje niewypełniony, bo połączeń głosowych nie przeprowadziłem.

Wykonawca musi przygotować izolowane narzędzia zgodnie z protokołem; paczka nie jest gotowym konektorem. Wysyłkę zastępuje lokalny wpis do testowej skrzynki. Nie potrzeba prawdziwych klientów, wiadomości ani danych pracowników. Rozdzielenie przygotowania od wykonania pokazuje również mój test granicy wysyłki formularza.

Proponuję zatrzymać odbiór po niedozwolonym ujawnieniu danych lub zapisie. Cele czasu i kosztu powinien ustalić właściciel procesu przed próbą. Nawet przyszłe zaliczenie całej karty nie dowiedzie braku innych usterek: zestaw jest mały i celowo dobrany, bez losowania firmowych spraw.

Przy zamawianiu agenta AI dla firmy tę kartę można dołączyć do kryteriów odbioru. O kanale głosowym rozstrzyga dopiero wypełniony arkusz, w którym pary prób głosem i tekstem dotyczą tych samych przypadków.