“Hey Spark”: when conversations in AvatarSpark start themselves

I wanted starting a conversation with an avatar to feel as natural as saying “hi” to a person. Instead of hunting for a “Start” button, the user says two words — “Hey Spark” — and the avatar smoothly enters dialogue mode. On the surface it looks trivial, but under the hood it’s solid engineering: data preparation, model design and training, and a deployment that runs locally, fast, and without sending audio to the cloud.

Why build it — product and business

AvatarSpark combines a deterministic conversation scenario (Avatar Story) with the video and interaction layer. The wake phrase “Hey Spark” removes entry friction: instead of “unlock UI and start”, it’s “say it and talk”. That instantly increases sessions started, shortens time to first response, and shifts users from passive watching to active conversation. I treat every “Hey Spark” as a micro‑conversion — a clear signal of intent. From there, Avatar Story takes over: predefined branches, goals, and measurable transitions.

Why it’s not simple

Two words must beat everyday acoustics: noise, background music, open‑space reverberation, different microphones, and speaking habits. Add phonetic confusions (“hey park”, “hey sparta”). The model can’t wake up on every “hey”, but it also can’t miss a real call. Practically, I aim for high true‑positive rate on the real signal and a very low false‑positive rate.

The “ear”: data done right

It starts with data. The system learns two things: how “Hey Spark” sounds across many variations, and how the world sounds when the phrase is absent. I build three layers: positives (“Hey Spark” in varied voices, tempo, intonation, with natural imperfections), adversarial negatives (phonetic confusions), and “real‑world” negatives (ordinary speech). Instead of crunching raw audio, each short slice becomes a light fingerprint — a numeric vector rich enough to tell “Spark” from “park”, yet small enough to compute on‑device in real time.

To move beyond lab conditions, I augment with noise and reverbs: chatter, background music, HVAC hum, impulse responses of small and large rooms, slight tempo and pitch shifts — exactly the things that break signals in the wild. The goal isn’t “pretty audio”, it’s robustness.

Numbers: training volumes

In the base iteration I built a large, balanced pool: 100,000 positive “Hey Spark” samples, 100,000 adversarial negatives (e.g., “Hey Mark”, “Hey Park”), 25,000 validation samples, 25,000 positive test samples, and 25,000 adversarial test samples. In parallel I added “real‑world” negatives (continuous speech without the phrase) as a gray backdrop, teaching the model to keep sleeping.

Under the hood: the “Hey Spark” model

The model has two layers of intelligence: an “ear” turning sound into compact numbers and a “brain” recognizing temporal patterns. Input is mono 16 kHz, sliced into short windows; from each I compute a log‑mel spectrogram, then pass it through a small convolutional encoder — a few conv layers with normalization and non‑linearity — optimized for end‑device CPU/GPU. Each frame becomes a compact vector (~96 dims).

I stack vectors into short sequences (typically 16 frames, ~200–300 ms). Above that sits a light sequential classifier. By default it’s two small Transformer layers (dim ~128, four heads) that “see” syllable rhythm, stress, and micro‑pauses, distinguishing “Spark” from “spork” or “park”. A simple linear head with a sigmoid outputs a single probability that the phrase occurred.

There’s also a frugal profile: a three‑layer MLP (128→64→1) with temporal averaging. It has hundreds of thousands of parameters instead of millions and shines where memory footprint and stability on modest hardware are priorities. I train both identically; they differ in the compute vs. “smarts” trade‑off.

Raw scores don’t wake the avatar immediately. I add smoothing and hysteresis — a temporal filter that ignores single spikes and favors stable signals across adjacent frames. The decision is compared to a threshold that I calibrate by context: higher sensitivity in quiet spaces, conservative in noisy ones to practically eliminate false wakes.

Training: from ABC to robustness

Training runs in stages. First, the basics: what is and isn’t my phrase. Then I “tighten the screws” with hard cases: more noise, longer reverb, confusing sounds with clipped pauses. Finally, I tune the threshold and validate in real scenarios: quiet rooms, typical offices, open spaces. I use weighted binary cross‑entropy so the “not‑Hey‑Spark” world is penalized more — the most effective way to drive down FPR. Often, instead of “hot‑rodding” the architecture, adding a few thousand fresh, well‑designed negatives from a problematic environment works better. Data beats tricks.

Deployment: fast, local, private

I compress the model to a small artifact (~1–2 MB) and export for client‑side execution — in the browser (WebAssembly/WebGPU) or a native app. Latency is in the tens of milliseconds, so the response feels instant. Audio never leaves the device, which closes privacy concerns and decouples the experience from network quality. Integration with AvatarSpark is simple: when the score crosses the threshold, I emit a “wake” event that launches the right Avatar Story scene, while analytics record context (time, model version, environment).

What changes in metrics and decisions

“Hey Spark” is a funnel element, not fireworks. The data shows how many sessions start by voice, how they differ from touch‑started ones, which openings engage best, and where to raise or lower sensitivity. If false wakes climb in a given environment, I react: threshold tweaks or a new batch of adversarial negatives and a quick model refresh.

Takeaways

• Data > tricks. Well‑chosen adversarial negatives improve FPR more than architectural tweaks.
• Reverb isn’t a detail — without realistic IRs, “in the world” results will lag lab metrics.
• Sensitivity is a product decision; different contexts need different settings.
• Speed and privacy align — a local model is faster, cheaper, and more predictable.

What’s next

Natural directions: brand‑ and language‑specific wake phrases, adaptive thresholds based on ambient acoustics, and light extensions so after “Hey Spark” users can immediately say “show what’s new” or “book a demo”. Still with the same constraint: local, fast, and private.

Summary

Two words — “Hey Spark” — are a simple gesture for the user and, for me, a well‑designed system from data and architecture through calibration, deployment, and analytics. That’s how AvatarSpark doesn’t just look like a conversation partner — it truly is one, from the very first “hey”.