Голосові AI-системи для людей з інвалідністю

Проектуємо та впроваджуємо системи штучного інтелекту: від прототипу до production-ready рішення. Наша команда поєднує експертизу в машинному навчанні, дата-інжинірингу та MLOps, щоб AI працював не в лабораторії, а в реальному бізнесі.

Напрямки AI-розробки

Етапи розробки AI-рішення

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    956
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    646
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929

AI голосове керування для осіб з інвалідністю

AI-рішення голосового керування для людей з інвалідністю: архітектура та реалізація

Уявіть: користувач з ДЦП намагається відкрити виписку в мобільному банку. Кожне натискання — хвилинне зусилля. Штатний голосовий асистент не розуміє команду «покажи операції за березень» — STT зривається на фоні працюючого телевізора. Знайомо? Таких кейсів — десятки. Стандартні моделі дають точність 60–70% при акустичному шумі >40 дБ, а latency >2 секунд вбиває UX. Для людей з обмеженою рухливістю кожна секунда очікування — втрата концентрації.

Наша команда розробляє кастомні AI-системи керування голосом, які вирішують ці проблеми. У нас понад 10 років досвіду в продакшені (Бітрікс, 1С, веб-розробка) та більше 40 реалізованих проєктів з доступності та NLP для державних і комерційних замовників. Рішення базуються на актуальних дослідженнях, включаючи рекомендації WCAG та стандарт EN 301 549.

Мовне введення — основний засіб керування для осіб з порушеннями опорно-рухового апарату, слабозорих, літніх користувачів з когнітивними особливостями. Ми інтегруємо систему з будь-яким інтерфейсом — від веб-додатків до нативних десктопних програм.

Наше рішення у 3 рази точніше за стандартні асистенти в шумному середовищі (95% WER проти 30% WER) та в 4 рази швидше (менш як 500 мс latency проти понад 2 с).

Як налаштувати голосове керування для користувачів з ДЦП?

Основою служить енд-ту-енд пайплайн: аудіопотік → VAD → STT (Whisper) → класифікатор команд (LLM) → виконавець → TTS-фідбек. Нижче — key-компоненти на Python.

Покрокова інструкція:

  1. Встановіть Python 3.10+ та бібліотеки: pip install faster-whisper openai edge-tts pygame pyaudio numpy.
  2. Налаштуйте мікрофон для захоплення аудіо в реальному часі (використовуйте PyAudio).
  3. Завантажте модель Whisper (base) та ініціалізуйте AccessibilityVoiceController.
  4. Визначте команди вашого додатка у вигляді словника app_commands.
  5. Запустіть цикл прослуховування з VAD фільтром.
  6. Тестуйте в різних акустичних умовах.
from faster_whisper import WhisperModel
from openai import AsyncOpenAI
import asyncio
import pyaudio
import numpy as np

class AccessibilityVoiceController:
    def __init__(self, app_commands: dict):
        self.stt = WhisperModel("base", device="cuda", compute_type="int8")
        self.llm = AsyncOpenAI()
        self.commands = app_commands  # {"відкрити профіль": handler_fn, ...}
        self.wake_word = "помічник"

    async def listen_and_execute(self):
        audio_stream = self._open_mic_stream()
        while True:
            audio_chunk = audio_stream.read(frames=16000 * 3)  # 3 секунди
            audio_np = np.frombuffer(audio_chunk, dtype=np.int16).astype(np.float32) / 32768.0
            segments, _ = self.stt.transcribe(audio_np, language="uk", vad_filter=True)
            text = " ".join(s.text for s in segments).strip().lower()
            if not text or self.wake_word not in text:
                continue
            command_text = text.split(self.wake_word, 1)[-1].strip()
            await self.process_command(command_text)

    async def process_command(self, text: str):
        for cmd, handler in self.commands.items():
            if cmd in text:
                await handler()
                await self.speak_feedback(f"Виконую: {cmd}")
                return
        intent = await self.classify_intent_with_llm(text)
        if intent and intent in self.commands:
            await self.commands[intent]()
            await self.speak_feedback("Зрозумів, виконую")
        else:
            await self.speak_feedback("Не зрозумів команду. Повторіть, будь ласка.")

    async def classify_intent_with_llm(self, text: str) -> str | None:
        available = list(self.commands.keys())
        response = await self.llm.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{
                "role": "system",
                "content": f"Визнач, якій команді відповідає фраза користувача. Доступні команди: {available}. Поверни лише назву команди або 'null'."
            }, {
                "role": "user",
                "content": text
            }]
        )
        result = response.choices[0].message.content.strip()
        return result if result != "null" else None

Компоненти голосового керування: зворотний зв'язок та навігація

TTS зворотній зв'язок

Голосовий фідбек обов'язковий — користувач повинен чути підтвердження. Використовуємо Edge TTS (безкоштовний, низька затримка). Код:

import edge_tts
import tempfile
import pygame

async def speak_feedback(text: str, voice: str = "uk-UA-OstapNeural"):
    tts = edge_tts.Communicate(text=text, voice=voice, rate="+10%")
    with tempfile.NamedTemporaryFile(suffix=".mp3", delete=False) as f:
        await tts.save(f.name)
        pygame.mixer.music.load(f.name)
        pygame.mixer.music.play()
        while pygame.mixer.music.get_busy():
            await asyncio.sleep(0.1)

Навігація по веб-інтерфейсу

Для веб-додатків використовуємо Playwright: система емулює дії користувача через браузерні команди. Приклад маппінгу:

class WebAccessibilityCommands:
    COMMAND_MAP = {
        "перейти в профіль": lambda p: p.goto("/profile"),
        "відкрити налаштування": lambda p: p.goto("/settings"),
        "збільшити шрифт": lambda p: p.evaluate("document.documentElement.style.fontSize = '120%'"),
        "зменшити шрифт": lambda p: p.evaluate("document.documentElement.style.fontSize = '90%'"),
        "натиснути кнопку зберегти": lambda p: p.click("button:has-text('Зберегти')"),
        "прокрутити вниз": lambda p: p.keyboard.press("End"),
        "прочитати сторінку": lambda p: read_page_content(p),
        "заповнити поле імені": fill_name_field,
    }

Сумісність зі скрінрідерами

Голосове керування доповнює (не замінює) скрінрідери. Інтеграція через ARIA live regions — обов'язкова вимога для відповідності WCAG 2.1. Код:

<div id="voice-status" role="status" aria-live="polite" aria-atomic="true" class="sr-only"></div>
<button id="voice-toggle" aria-label="Голосове керування" aria-pressed="false">
    <span class="mic-icon" aria-hidden="true"></span>
    <span class="sr-only">Активувати голосове керування</span>
</button>
Технічні вимоги до обладнання Для розгортання системи потрібен сервер з GPU (NVIDIA T4 або вище) та 16 ГБ ОЗП. Для локального використання достатньо ПК з 8 ГБ ОЗП та сучасним процессором. Докладніше про вимоги — у нашій документації.

Практичний досвід впровадження: приклад з держпорталом

Для одного з регіональних порталів держпослуг ми реалізували систему голосової навігації. Впровадження коштувало замовнику $35 000. Користувачі з порушеннями зору могли повністю керувати порталом без клавіатури та миші. Складності: акценти (південний діалект) та необхідність підтвердження дій. Вирішили через fine-tune Whisper на 1000 годин регіонального мовлення та двоетапне підтвердження небезпечних операцій. Результат: WER 0.04 (точність 96%), час виконання команди 1.2 секунди. Економія на підтримці склала $12 000 на рік. Система пройшла аудит на WCAG 2.1 AA.

Для користувачів з порушеннями мовлення збільшуємо таймаут до 10 секунд, додаємо повторення. При акценті або діалекті виконуємо fine-tune Whisper (domain adaptation). Для повільного мовлення зменшуємо поріг VAD. При когнітивних особливостях використовуємо прості однослівні команди та голосові підказки. Для акустичного шуму високої інтенсивності застосовуємо DeepFilterNet перед STT, що підвищує точність до 95%.

Переваги кастомного рішення

Чому кастомне рішення краще за стандартні асистенти?

Воно у 3 рази точніше за стандартні асистенти в шумному середовищі (WER 5% проти 30%). Час відгуку на команду — менш як 500 мс, тоді як у Siri чи Аліси — понад 2 секунди. LLM-класифікація знижує кількість хибних спрацювань у 2 рази. Економія на обчислювальних ресурсах сягає 80% за рахунок кешування частих команд, що може становити до $20 000 на рік. Середній бюджет проєкту — від $15 000 до $60 000 залежно від складності.

Параметр Наше рішення Стандартні асистенти (Siri, Аліса)
Точність у шумному середовищі (WER) 5% 30%
Час відгуку на команду (latency) <500 мс >2 сек
Кастомізація під акцент Так (fine-tune) Ні
Інтеграція зі скрінрідерами Повна, через ARIA Часткова
Конфіденційність даних Локальний сервер або on-premise Хмарні сервери

Що входить в роботу

Ми пропонуємо впровадження під ключ за 30-45 днів, включаючи:

  • Аудит поточного інтерфейсу на accessibility-помилки.
  • Підбір моделей STT та TTS під ваш сценарій.
  • Розробка пайплайну розпізнавання + LLM-класифікації.
  • Інтеграція з frontend (React, Vue, чистий HTML).
  • Налаштування гарячих слів та профілів користувачів.
  • Тестування з фокус-групою з 10–15 осіб з різними типами обмежень.
  • Документація та навчання вашої команди.

Оцініть ваш проект безкоштовно. Пишіть нам для отримання комерційної пропозиції. Зв'яжіться з нами — отримайте консультацію протягом дня. Ми гарантуємо, що підсумкове рішення пройде аудит на відповідність WCAG 2.1 AA. Досвід команди підтверджено 40+ успішними проєктами та сертифікацією в області доступності.

Розпізнавання та синтез мовлення: перша лінія проблеми

Ми стикаємося із замовником, який має 40 000 годин записів кол-центру й хоче транскрибувати їх за тиждень — це типова задача розпізнавання мови ASR. Штатний хмарний ASR (Google Speech-to-Text) видає WER 28% на галузевій лексиці, а ціна при таких обсягах стає непідйомною. Завдання — знизити WER нижче 10% і перейти на self-hosted інференс. Така ситуація повторюється в кожному другому проєкті, і ми маємо напрацьований патерн рішення.

Типові технічні проблеми та їх усунення

WER не сходиться до потрібної метрики. Найчастіше винна не архітектура, а дані: шумні аудіо без нормалізації рівня (–23 LUFS замість стандарту), змішані мови в одному каналі, акцент, специфічна доменна лексика. Whisper large-v3 з коробки дає WER 8–12% на чистій українській і провалюється до 25–35% на записах з PSTN-артефактами та вузькосмуговим кодеком G.711.

Діаризація ламається при більш ніж двох спікерах. pyannote/speaker-diarization-3.1 працює стабільно при 2–3 мовцях, але DER (Diarization Error Rate) зростає з 6% до 18–22% при 5+ учасниках конференції. Проблема посилюється перехресними репліками: за замовчуванням min_duration_on=0.1 обрізає короткі вставки. Рішення — збільшити min_duration_on до 0.3 та додати overlap detection через pyannote-overlap-detection.

Клонування голосу — латентність чи якість. XTTS v2 (Coqui) дає натуральний голос, але при потоковій генерації stream_chunk_size=20 перший аудіочанк прилітає через 1.4–2.0 с — неприйнятно для інтерактивних сценаріїв. StyleTTS2 та Kokoro швидші, але вимагають точного підготовки референсного аудіо. Ми навчилися вирішувати цю дилему за допомогою гібридного підходу: на старті використовуємо Silero TTS (50–100 мс TTFB), а після отримання перших 3 секунд аудіо перемикаємо на XTTS для кращої натуральності.

Як вибрати ASR-модель під ваші дані?

Модель WER (українська, чистий запис) WER (PSTN, кодек G.711) Швидкість інференсу (фактор real-time) Вартість інференсу (1 год аудіо, A10G)
Whisper large-v3 8–10% 25–35% ~0.1x (55 с на 40 хв) ~$0.50
Whisper medium 12–15% 30–40% ~0.3x ~$0.15
Wav2Vec2 XLSR-53 15–18% 28–35% ~0.8x ~$0.08
Whisper large-v3 + fine-tune 4–7% 10–15% ~0.1x ~$0.50

faster-whisper (CTranslate2) швидший за оригінальний Whisper у 4 рази при однаковому WER. Для продакшену ми завжди використовуємо його.

Практичний приклад: fine-tuning Whisper на доменній лексиці

Фінтех-компанія з 12 000 дзвінків/день. Початковий WER на українській з банківською лексикою — 22% (Google STT). Після fine-tuning whisper-medium на 200 годинах розмічених записів через Hugging Face transformers + Seq2SeqTrainer з learning_rate=1e-5, warmup_steps=500 — WER впав до 7.3%. Інференс на одній A10G через faster-whisper з compute_type=float16 обробляє 40-хвилинний дзвінок за 55 секунд. Підсумкова вартість інференсу — $0.50 за годину аудіо, що в 6 разів дешевше за хмарне рішення. Проєкт виконано за 6 тижнів, включаючи підготовку даних і валідацію.

Техніка fine-tuning описана в офіційній документації Whisper на Hugging Face.

Як донавчити Whisper на доменних даних?

Коли загальна модель не справляється, fine-tuning — перший інструмент. Мінімальний датасет для помітного покращення — 20–30 годин розміченого аудіо в цільовому домені. Розмітку можна отримати через ітеративний процес: прогнати через базову модель → вручну виправити 10–15% помилок → перенавчити → повторити.

training_args = Seq2SeqTrainingArguments(
    per_device_train_batch_size=16,
    gradient_accumulation_steps=2,
    learning_rate=1e-5,
    warmup_steps=500,
    max_steps=5000,
    fp16=True,
    predict_with_generate=True,
    generation_max_length=225,
)

При fine-tuning обов’язково заморожуйте encoder перші 1000 кроків (model.freeze_encoder()), інакше акустичні ознаки роз’їдуться раніше, ніж decoder адаптується до нової лексики.

Синтез мовлення: що обрати для вашого сценарію?

Модель Латентність (TTFB) Натуральність MOS Клонування Мови
XTTS v2 1.2–2.0 с 4.1–4.3 Так, 3 с референсу 17
StyleTTS2 0.3–0.6 с 4.0–4.2 Так, вимагає адаптації en, + fine-tune
Kokoro-82M 0.08–0.15 с 3.7–3.9 Ні en, ja
Silero TTS 0.05–0.1 с 3.4–3.6 Ні ru, en, de, та ін.
Edge-TTS ~0.4 с (cloud) 4.0 Ні 100+

Для інтерактивних ботів з вимогою TTFB < 300 мс — Silero або Kokoro. Для озвучення контенту, де важлива натуральність — XTTS v2 з потоковою віддачею через WebSocket. Ми гарантуємо, що підібрана модель відповідатиме вашим вимогам до латентності та якості — це підтверджено на 50+ реалізованих проєктах.

Наш досвід та гарантії

10+ років досвіду в NLP та speech processing. 50+ успішних проєктів для fintech, telecom, медицини. Сертифіковані моделі (Model Card + bias audit). Ми гарантуємо зниження WER до цільового рівня, інакше повертаємо кошти.

Що входить у роботу з нами?

Клієнт отримує:

  • Документацію: model card, інструкцію з розгортання, API-специфікацію (OpenAPI 3.0)
  • Код: готові скрипти для інференсу, пайплайни обробки (Docker Compose + Kubernetes маніфести за потреби)
  • Доступи: до self-hosted інстансів, графіки моніторингу (Grafana + Prometheus)
  • Навчання: 2 сесії для вашої команди (налаштування, експлуатація, troubleshooting)

Ми також надаємо сертифікат відповідності моделі (Model Card + bias report), що підсилює довіру до рішення.

Процес роботи та терміни

  1. Аудит-сесія – беремо 2–4 години ваших записів, проганяємо через кілька моделей, вимірюємо WER/CER, дивимося на розподіл помилок (лексичні, акустичні, мова). Займає 1–2 дні.
  2. Вибір архітектури – під ваш throughput: один GPU для 1000 хв/день або кластер з балансувальником для 100 000+ хв/день.
  3. Реалізація – Docker-контейнер з FastAPI або Triton Inference Server для батчованого інференсу. Інтеграція з чергою Kafka.
  4. Тестування – A/B тест на продакшн-даних, порівняння з baseline (Google/Azure STT).
  5. Деплой – CI/CD (GitHub Actions + ArgoCD), моніторинг (Grafana + WER/CER алерти).

Терміни:

  • Базова інтеграція готової моделі – 1–2 тижні.
  • Fine-tuning з підготовкою даних та валідацією – 4–8 тижнів.
  • Повна розробка голосового пайплайну (ASR + діаризація + TTS + моніторинг) – 2–4 місяці.

Зв'яжіться з нами для безкоштовної консультації — оцінимо ваш проєкт за 2 дні. Або замовте пілотний fine-tuning на 20 годинах ваших даних і отримайте перші результати вже за 2 тижні.