Czy mały model potrafi wywoływać funkcje z polskiego głosu?

Chciałem sprawdzić, czy mały model multimodalny potrafi usłyszeć polskie polecenie i zamienić je na poprawne wywołanie funkcji. Bez osobnego rozpoznawania mowy, bez wysyłania nagrania do chmury. Jeden model, który słucha, rozumie i działa.

Okazało się, że rozpoznanie zamiaru to najmniejszy problem. Modele zwykle wiedzą, jaką funkcję wywołać. Gorzej z argumentami. Gubią odmianę imion, mylą daty względne i nie radzą sobie z potocznymi określeniami czasu. „Kwadrans” potrafi być trudniejszy niż całe polecenie.

Najbardziej interesowało mnie jednak coś innego: czy model źle rozumie polski, czy po prostu źle go słyszy?

Jeden model czy dwa?

Testowałem lokalnie rodzinę Gemma 4: małe warianty E2B i E4B oraz większy 12B. Wszystko na RTX 3060, przez llama.cpp.

Przygotowałem polskie polecenia głosowe wygenerowane przez Piper z użyciem trzech głosów. Sprawdzałem, czy model wybiera właściwą funkcję i przekazuje jej wszystkie argumenty. Samo trafienie nazwy narzędzia nie wystarczało.

Najpierw podałem modelom polecenia jako tekst. Potem te same polecenia jako dźwięk.

Różnica była duża. Najmniejszy E2B poprawnie wykonywał około 63% wywołań z tekstu, ale tylko 44% z głosu. E4B radził sobie lepiej, jednak również tracił sporo skuteczności po przejściu na audio.

Co ciekawe, nazwy funkcji były zwykle poprawne. Model rozpoznawał, że chodzi o ustawienie przypomnienia czy wykonanie innej czynności. Problem zaczynał się przy ustalaniu szczegółów.

Żeby znaleźć przyczynę, dołożyłem drugi wariant: Whisper turbo rozpoznawał mowę, a Gemma dostawała już gotowy tekst.

To był ważny test, którego zabrakło w pierwszej wersji eksperymentu. Zwrócił na to uwagę panel modeli recenzujących moje wyniki.

Kaskada z Whisperem poprawiła skuteczność wszystkich badanych wariantów. E2B odzyskał znaczną część strat, E4B poprawił się mniej, a największa różnica pojawiła się w modelu 12B.

Wniosek: duża część błędów nie wynika z niezrozumienia polecenia, tylko z tego, co model usłyszał. W przybliżeniu dwie trzecie utraconej skuteczności można przypisać problemom ze słuchem.

Nie oznacza to jednak, że wystarczy lepszy transkrypter. Nawet po otrzymaniu poprawnego tekstu małe modele nadal popełniają błędy w argumentach.

Większy model, który prawie nie słyszy

Największym zaskoczeniem był Gemma 4 12B.

Z tekstem radził sobie zdecydowanie najlepiej. Natomiast bezpośrednio z polskiego głosu poprawnie wykonywał mniej niż co dziesiąte polecenie. Po dodaniu Whispera skuteczność wzrosła do niemal 85%.

Testy samej transkrypcji potwierdziły problem. Model 12B na polskich nagraniach potrafił odmawiać odpowiedzi albo zapisywać rozpoznany tekst cyrylicą.

Początkowo próbowałem sprawdzić słuch modeli za pomocą polskiego syntezatora espeak. To okazało się błędem metodologicznym. Nawet E4B, który dobrze radził sobie w innych próbach, uzyskiwał na nim fatalne wyniki. Zastąpiłem więc tę kontrolę polskim zbiorem FLEURS i angielskim espeak.

Różnice między modelami utrzymały się.

Istotna jest tutaj architektura. E2B i E4B mają osobny enkoder audio. Wariant 12B przetwarza dźwięk inaczej, przekazując jego fragmenty bezpośrednio do głównego modelu językowego.

Nie wiem jednak, co dokładnie odpowiada za tak słaby wynik 12B. Może to być architektura, kwantyzacja Q4 albo eksperymentalna obsługa audio w llama.cpp. Nie mogłem sprawdzić modelu w pełnej precyzji, bo zabrakło pamięci GPU.

Nie traktuję więc tego wyniku jako dowodu, że 12B z definicji źle rozpoznaje polską mowę. To wynik konkretnej konfiguracji.

Co naprawdę warto poprawić?

Przyjrzałem się też rodzajom błędów. Najmniejszy model szczególnie często gubił zdrobnienia, daty względne i potoczne określenia godzin. Przy poleceniach głosowych z „kwadransem” nie trafił ani razu, choć z tekstu czasami sobie radził.

Większy 12B znacznie lepiej rozumiał te same konstrukcje zapisane tekstem. To sugeruje, że problem nie jest nierozwiązywalny, choć samo zwiększenie modelu nie gwarantuje lepszego rozpoznawania głosu.

Sprawdziłem również wpływ kwantyzacji. W E2B przejście z Q8 na Q4 niemal nie pogorszyło wyników audio. Za to w pobocznym teście dokumentów zauważalnie ucierpiała część wizyjna, szczególnie odczytywanie kwot. Nie można więc zakładać, że kwantyzacja wpływa jednakowo na wszystkie możliwości modelu.

Zgodnie z regułą ustaloną przed eksperymentem do dalszej pracy wybrałem E2B i wywołania funkcji z głosu. To największa luka, którą mogę próbować zamknąć bez dodatkowych kosztów. Obecne 44% jest daleko od przyjętego progu 80%.

Nie mam jeszcze wyników, które pozwoliłyby ocenić skuteczność dostrajania LoRA. Pozostaje też ważniejsze ograniczenie: wszystkie polecenia pochodziły z syntezatora. Model nauczony na takich nagraniach może dopasować się do Piper, a nie do rzeczywistej polskiej mowy.

Nie zmierzyłem również kosztu energetycznego ani wydajności kaskady na telefonie. Porównanie Whispera na CPU z Gemmą na GPU mówi na razie tylko o jakości.

Na dziś wniosek jest prosty: mały model potrafi zrozumieć, co chcę zrobić, ale nie zawsze potrafi poprawnie usłyszeć szczegóły. Osobne rozpoznawanie mowy pomaga, czasem bardzo mocno. Nie usuwa jednak problemów z interpretacją polskich konstrukcji.

Dlatego dalsze eksperymenty powinny skupić się nie na samym rozpoznawaniu intencji, lecz na poprawności argumentów. To one decydują, czy polecenie głosowe rzeczywiście zostanie wykonane tak, jak chciałem.