Як я зробив офлайн голосовий асистент для розумного будинку на Raspberry Pi — і чому відмовився від хмари

Мене звати Іван, я solo-розробник і вже понад рік будую SelenaCore — open-source хаб для розумного будинку, який працює повністю офлайн, підтримує українську мову та не відправляє жодних даних у хмару. Ця стаття — для тих, хто хоче зрозуміти, як влаштований такий проєкт зсередини, які технічні рішення я приймав і з якими реальними проблемами зіткнувся.

Чому я взагалі за це взявся

Все почалося з простого питання: чому мій розумний будинок не розуміє мене українською?

Google Home і Amazon Alexa — хороші продукти, але вони вимагають постійного інтернету, відправляють голосові запити на сервери компанії і не дуже добре розуміють українську. Home Assistant вирішує частину проблем, але голосове управління там — окрема складна тема, і теж переважно через хмарні сервіси.

Я почав думати: а що якщо зробити все локально? STT на пристрої, LLM на пристрої, TTS на пристрої. Без хмари взагалі. Щоб навіть при відключенні інтернету все працювало.

Так з’явився SelenaCore.

Архітектура: як це влаштовано

Загальна схема

Система складається з кількох шарів:

1. Офлайн голосовий pipeline — wake-word детекція → STT → обробка → відповідь через TTS
2. Pluggable LLM layer — підтримує Ollama (локальні моделі) та хмарні провайдери як опцію
3. Модульна система — 21 вбудований модуль для управління пристроями, таймерами, погодою тощо
4. React SPA фронтенд — веб-інтерфейс для управління та моніторингу
5. Docker-based деплоймент — все запускається в контейнерах

Апаратна база — Raspberry Pi 4/5 або NVIDIA Jetson Orin Nano. Вибір залежить від того, чи потрібен LLM inference на борту.

STT: чому Vosk, а не Whisper

Коли я вибирав між Vosk і Whisper для офлайн розпізнавання мовлення, виграв Vosk — і не через якість, а через швидкість і пам’ять.

Whisper дає кращу точність, особливо для нестандартних фраз. Але на Raspberry Pi 4 він занадто повільний для realtime-інтерфейсу. Vosk з моделлю vosk-model-uk дає прийнятну точність і відповідає за 300—500мс, що цілком комфортно для голосового асистента.

Є один важливий нюанс: STT недосконалий. Vosk може розпізнати «включи лампочку» як «включи лампу» або «ввімкни лапку». Це реальна проблема, яка вплинула на всю архітектуру Intent Recognition — але про це нижче.

TTS: Piper і локальні голоси

Для синтезу мови використовую Piper — швидкий офлайн TTS з непоганою якістю Ukrainian голосів. Він працює на CPU без GPU-прискорення і дає затримку ~150—300мс на Pi 4, що прийнятно.

Спочатку я планував просто передавати всі команди напряму в LLM і отримувати відповіді. Але виявилось, що це занадто дорого по латентності і токенах, коли кожен «увімкни світло» йде на LLM з повним контекстом.

Intent Recognition: від простого до three-tier pipeline

Це виявилось найскладнішою частиною проєкту.

Перша версія — regex-based матчинг. Просто: якщо фраза містить «увімкни» і «лампу» — це device.on. Спрацьовувало для простих випадків, але повністю ламалось при будь-яких варіаціях.

Друга версія — LLM для всього. Кожен запит йде в модель. Точність чудова, але затримка 2–4 секунди навіть з Ollama + llama3.1:8b на Pi. Для голосового асистента це критично.

Поточна версія — три рівні:

1. Tier 0: Fuzzy phrase cache — база вже оброблених фраз з fuzzy matching. Якщо «включи лампочку у вітальні» вже зустрічалась і вирішена — відповідь миттєва.
2. Tier 1: Embedding classifier — all-MiniLM-L6-v2 через ONNX (без Python ML залежностей). Класифікує intent по векторній схожості. Працює за ~200мс.
3. Tier 2: LLM — тільки для складних або невизначених запитів, де embedding не впевнений.

Результат: 92.9% точності на тестовому корпусі з 70 українських голосових команд, середня затримка embedding-класифікації ~200мс.

Багатомовність: архітектурне рішення

Одна з ключових фічей — підтримка кількох мов. Але реалізована вона нестандартно.

Вся внутрішня обробка відбувається лише англійською. Переклад відбувається тільки на двох межах:

• Vosk output (будь-яка мова → англійська) через Helsinki-NLP opus-mt-mul-en з CTranslate2 int8 квантизацією (~300MB)
• Перед Piper TTS (англійська → мова користувача)

Чому так? Тому що LLM-промпти, intent-каталог, логіка — все це стабільно і передбачувано англійською. Додати нову мову = додати STT модель + TTS голос. Intent Recognition при цьому не змінюється.

На практиці: «увімкни лампу у вітальні» → переклад → «Turn on the lamp in the living room» → embedding classifier → device.on, entity=light, location=living room → виконання → «Лампу у вітальні увімкнено» через TTS.

Реальні проблеми, з якими я зіткнувся

Проблема 1: «turn the tape on» vs «turn on the light»

Helsinki-NLP перекладає «увімкни стрічку в кабінеті» як «Turn the tape on in your office».

Слово «tape» замість «LED strip» або «light strip» — і embedding classifier плутається між device.on і device.off з margin лише 0.003. Ця крихкість перекладу — реальна проблема офлайн pipeline без LLM семантичного згладжування.

Вирішення поки що часткове: phrase_cache + накопичення правильних перекладів через LLM Tier 2 в базу.

Проблема 2: ambiguous entity names

Якщо в базі є «Кондиціонер» з type=air_conditioner, модель embedding бачить «Turn on the air conditioning» і класифікує це як device.set_mode, бо в тренувальних даних «air conditioning» часто асоційоване з режимами, а не вмиканням.

Рішення: для типів пристроїв (thermostat, air_conditioner) додав explicit override: якщо немає value у параметрах і є базова команда «turn on/off» — форсую device.on/off.

Проблема 3: RAM на Raspberry Pi 4

Pi 4 з 4GB RAM тримає:

• Vosk STT model: ~200MB
• ONNX embedding model: ~90MB
• Helsinki translator: ~300MB
• Piper TTS: ~80MB
• FastAPI сервер: ~150MB
• React SPA: ~50MB

Разом ~870MB тільки для core stack. Ollama з llama3.1:8b ще ~5GB. Тому на Pi 4 Ollama = тільки якщо є swap і ви готові до 3+ секунд inference.

Поточне рішення: Tier 2 LLM може бути хмарним (Claude API) — це опція для тих, хто хоче кращу якість без потужного заліза. Або NVIDIA Jetson Orin Nano — там NVMe + LPDDR5 дозволяє комфортно запускати 8B моделі.

Проблема 4: display stack

Хотів мати гарний fullscreen дашборд. Chromium kiosk mode споживає ~300MB RAM і важко оптимізується на Pi.

Зараз переходжу на WPE WebKit через cog — це ~50MB і набагато легший footprint. Але є нюанс: на NVIDIA Jetson Tegra DRM несумісний з wlroots, тому fallback до Xorg + Chromium там залишається.

Що зараз вміє система

• Управління пристроями через голос: увімкнути/вимкнути світло, регулювати яскравість, колір, температуру
• Підтримка Tuya-сумісних пристроїв через local protocol (без хмари)
• Інтеграція з Home Assistant через WebSocket
• Таймери, будильники, нагадування
• Запит температури з датчиків
• Ідентифікація хто вдома через presence detection
• Радіо (online stream)
• Повністю офлайн режим — все працює без інтернету

Що в планах

Основна мета на наступний квартал — довести translation pipeline до production-ready стану і зробити перший публічний реліз з повноцінними docker-образами для Pi 4, Pi 5 і Jetson.

Також думаю над spell correction через symspellpy для компенсації STT помилок — але це після накопичення достатнього логу реальних фраз.

Висновок

SelenaCore — це доказ того, що повністю офлайн голосовий асистент для розумного будинку з підтримкою української мови реальний на доступному залізі. Це не комерційний продукт і не спроба замінити Home Assistant — це інструмент для тих, кому важлива приватність і хто хоче розуміти, що відбувається всередині.

Проєкт open-source, MIT ліцензія. Якщо вам цікаво — заходьте на GitHub (github.com/dotradepro/SelenaCore) і зірочка буде дуже доречна 🙂

Якщо маєте питання про архітектуру, конкретні рішення чи хочете обговорити — пишіть у коментарях, постараюсь відповісти на все

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті