Od "Hej Spark" do Dialogu: Sekret Kompaktowego AI w AvatarSpark

Zależało mi, żeby start rozmowy z awatarem był tak naturalny, jak powiedzenie „cześć” do człowieka. Zamiast szukać przycisku „Start”, użytkownik wypowiada dwa słowa – „Hej Spark” – a awatar płynnie przechodzi w tryb dialogu. Na wierzchu wygląda to banalnie, ale pod spodem stoi porządny kawał inżynierii: przygotowanie danych, zaprojektowanie i wytrenowanie modelu oraz wdrożenie, które działa lokalnie, szybko i bez wysyłania dźwięku do chmury.

Po co to zrobiłem – perspektywa produktu i biznesu

AvatarSpark łączy deterministyczny scenariusz konwersacji (Avatar Story) z warstwą prezentacji wideo i interakcji. Fraza‑klucz „Hej Spark” usuwa tarcie na wejściu: zamiast „odblokuj interfejs i rozpocznij”, jest „powiedz i rozmawiaj”. To natychmiast zwiększa liczbę rozpoczętych sesji, skraca czas do pierwszej odpowiedzi i zmienia nastawienie użytkownika z biernego oglądania na aktywną rozmowę. Każde „Hej Spark” traktuję jak mikro‑konwersję – jasny sygnał intencji. Dalej prowadzi już Avatar Story: z góry zaplanowane gałęzie, cele i mierzalne przejścia.

Dlaczego to wcale nie jest proste

Dwa słowa muszą wygrać z akustyką codzienności: szumem, muzyką w tle, pogłosem open space’u, różnymi mikrofonami i nawykami mówienia. Dochodzą też frazy mylące fonetycznie („hej park”, „hej sparta”). Model nie może budzić awatara za każdym „hej”, ale nie może też przegapić prawdziwego wywołania. W praktyce dążę do wysokiej czułości na właściwy sygnał (TPR) i bardzo niskiej podatności na pomyłki (FPR).

Skąd wzięło się „ucho”, które to rozróżnia – dane, ale mądrze

Punktem wyjścia są dane. Uczę maszynę dwóch rzeczy: jak „Hej Spark” brzmi w dziesiątkach wariantów oraz jak brzmi świat, kiedy tej frazy nie ma. Buduję trzy warstwy materiału: pozytywy („Hej Spark” w różnych głosach, tempie, intonacji, z naturalnymi nieidealnościami), negatywy adwersarialne (zbitki mylące fonetycznie) oraz negatywy „z realnego świata” (zwykła mowa). Zamiast mielić surowe audio, każdy krótki wycinek zamieniam w jego lekki „odcisk palca” – wektor liczb wystarczająco bogaty, by rozróżnić „Spark” od „park”, a dość mały, by liczyć go w locie na urządzeniu końcowym.

Żeby wyjść poza warunki laboratoryjne, mieszam ten materiał z hałasami i pogłosami: gwar rozmów, muzyka tła, szum klimatyzacji, impulsy pogłosowe małych i dużych pomieszczeń, drobne zmiany tempa i wysokości głosu – dokładnie to, co psuje sygnał w prawdziwym świecie. Celem nie jest „ładny dźwięk”, tylko odporność.

Konkret: jakich wolumenów użyłem w treningu

W bazowej iteracji ustawiłem wolumen tak, by uzyskać dużą i zbalansowaną pulę przykładów: 100 000 próbek pozytywnych „Hej Spark”, 100 000 próbek negatywnych adwersarialnych (np. „Hey Mark”, „Hey Park”), 25 000 próbek walidacyjnych, 25 000 próbek testowych pozytywnych oraz 25 000 próbek testowych adwersarialnych. Równolegle dołączałem negatywy „z realnego świata” (ciągła mowa bez frazy), które pełniły rolę „szarego tła”, ucząc model konsekwentnego spania.

Pod maską: jak zbudowałem model „Hej Spark”

Model ma dwie warstwy inteligencji: „ucho” zamieniające dźwięk na poręczne liczby i „mózg” rozpoznający wzorzec w czasie. Na wejściu biorę mono 16 kHz, tnę sygnał na krótkie okna i z każdego wyliczam log‑melspektrogram. Potem przepuszczam go przez niewielki enkoder konwolucyjny – kilka warstw splotów z normalizacją i nieliniowością – zoptymalizowany pod CPU/GPU urządzenia końcowego. W efekcie każda „klatka” zamienia się w zwarty wektor (około 96 liczb).

Te wektory układam w zwięzłe sekwencje (typowo 16 klatek, ok. 200–300 ms dźwięku). Nad nimi pracuje lekki klasyfikator sekwencyjny. W wariancie domyślnym używam dwóch niedużych warstw Transformera (wymiar rzędu 128, cztery głowy uwagi), który „widzi” rytm sylab, akcent i mikropauzy, dzięki czemu odróżnia „Spark” od „spork” czy „park”. Na końcu mam prostą głowicę liniową z sigmoidem, która zwraca pojedyncze prawdopodobieństwo, że w tej porcji padło „Hej Spark”.

Mam też profil oszczędnościowy: trzystopniowe MLP (128→64→1) z uśrednianiem w czasie. Ta wersja ma setki tysięcy parametrów zamiast milionów i świetnie sprawdza się tam, gdzie priorytetem jest minimalny ślad pamięci oraz stabilność na słabszym sprzęcie. Obie wersje trenuję identycznie; różnią się kompromisem między „sprytem” a kosztem obliczeń.

Surowy wynik nie wybudza awatara natychmiast. Wprowadzam wygładzanie i histerezę – prosty filtr czasowy, który ignoruje pojedyncze piki, a faworyzuje stabilny sygnał przez kilka sąsiednich klatek. Decyzję porównuję z progiem, który kalibruję pod kontekst: w cichym otoczeniu pozwalam sobie na większą czułość, w głośnym – gram zachowawczo, by praktycznie wyeliminować fałszywe pobudki.

Jak trenowałem – od alfabetu do odporności

Szkolenie rozdzieliłem na etapy. Najpierw uczyłem podstaw: co jest moją frazą, a co nią nie jest. Potem „dokręcałem śrubę” trudnymi przypadkami: większym hałasem, dłuższym pogłosem, podobnymi brzmieniami urwanymi pauzami. Na końcu stroiłem próg i walidowałem model w scenariuszach, w których realnie będzie pracował: cisza, zwykłe biuro, otwarta przestrzeń. Używałem binarnej entropii krzyżowej z ważeniem klas, dzięki czemu cały świat „nie‑Hej‑Spark” był traktowany surowiej – to najskuteczniejszy sposób na niski FPR. Często zamiast „podkręcać” architekturę, lepiej było dorzucić kilka tysięcy świeżych, dobrze zaprojektowanych negatywów z konkretnego, kłopotliwego środowiska. Dane wygrywają z trikami.

Wdrożenie: szybko, lokalnie, prywatnie

Model kompresuję do małego artefaktu (rzędu 1–2 MB) i eksportuję w formacie działającym po stronie użytkownika – w przeglądarce (WebAssembly/WebGPU) lub w aplikacji natywnej. Opóźnienia liczę w dziesiątkach milisekund, więc reakcja jest odczuwalnie natychmiastowa. Audio nie opuszcza urządzenia, co domyka temat prywatności i uniezależnia doświadczenie od jakości sieci. Integracja z AvatarSpark jest prosta: gdy wynik przekroczy próg, emituję zdarzenie „wake”, które uruchamia odpowiednią scenę w Avatar Story, a analityka zapisuje kontekst (czas, wersję modelu, środowisko).

Co to zmienia w pomiarach i decyzjach

„Hej Spark” to element lejka, nie fajerwerk. W danych widzę, ile sesji startuje głosem, jak różnią się od tych rozpoczynanych dotykiem, które powitania najlepiej wciągają do rozmowy oraz gdzie warto podnieść lub obniżyć próg czułości. Jeśli w jakimś środowisku rosną fałszywe pobudki, reaguję: korekta progu albo dodatkowa porcja adwersarialnych negatywów i szybkie odświeżenie modelu.

Wnioski

• Dane > sztuczki. Dobrze dobrane negatywy adwersarialne mocniej poprawiają FPR niż zmiana architektury.
• Pogłos to nie detal – bez realistycznych IR‑ów wyniki „w świecie” zawsze będą gorsze niż w labie.
• Próg czułości to decyzja produktowa; różne konteksty wymagają innych nastaw.
• Prędkość i prywatność da się pogodzić – lokalny model jest i szybszy, i tańszy, i przewidywalny.

Co dalej

Naturalny kierunek to personalizacja frazy pod markę i język, adaptacyjne progi zależne od tła akustycznego oraz lekkie rozszerzenia, które po „Hej Spark” pozwolą od razu powiedzieć „pokaż nowości” czy „umów demo”. Wciąż z tą samą zasadą: ma działać lokalnie, szybko i bez kompromisów prywatności.

Podsumowanie

Dwa słowa „Hej Spark” to dla użytkownika prosty gest, a dla mnie – dobrze zaprojektowany system od danych, przez architekturę i kalibrację, po wdrożenie i analitykę. Dzięki temu AvatarSpark nie tylko wygląda jak partner do rozmowy. On naprawdę nim jest – od pierwszego „hej”.