Голосовой орб, который реально управляет сайтом: архитектура ассистента, а не «говорящего FAQ»
Коротко о главном (BLUF)
В этом материале мы разбираем ключевые аспекты работы с нейросетями: актуальные модели, практические советы по промптам и примеры генераций. Читайте дальше, чтобы узнать подробности.
Голосовые ассистенты на сайтах обычно заканчиваются одним из двух: либо это чат-бот, которому приклеили распознавание речи, либо озвучка FAQ. Мы в NeuralSpace пошли от обратной задачи — сделать голос основным способом управления интерфейсом, а не надстройкой над текстом. Ниже разбор архитектуры и решений, которые пришлось принять.
Задача
Пользователь открывает сложную страницу генерации — видео, картинки, музыка — где есть выбор модели, загрузка референса, запрос, параметры. Новичок теряется. Классический онбординг (тур со стрелочками) люди закрывают на втором шаге. Мы захотели, чтобы можно было просто сказать голосом: «хочу оживить это фото», а ассистент сам подсветил нужную кнопку, объяснил и довёл до результата.
Ключевое отличие от чат-бота: орб видит состояние страницы и действует на ней, а не отвечает текстом «нажмите кнопку X где-то там».
Архитектура: три слоя
- Голосовой тракт. Потоковое распознавание речи → модель → синтез ответа. Требование — низкая задержка и возможность перебивать (barge-in): пользователь начал говорить — ассистент замолкает. Без этого диалог ощущается как рация, а не разговор.
- Мозг. Мы сознательно отвязали «личность» ассистента от конкретной языковой модели: модель настраивается на стороне сервера, так что её можно менять под задачу и стоимость без передеплоя фронта. Ассистент получает не только реплику пользователя, но и машиночитаемый снимок текущей страницы: какие элементы есть, какие кнопки, что уже выбрано.
- Executor на клиенте. Модель возвращает не только текст, но и действия: подсветить элемент, прокрутить к блоку, объяснить поле. Клиент исполняет их поверх реального DOM.
Три грабли, на которые мы наступили
Самое интересное — не happy path, а провалы. Мы разобрали логи реальных диалогов и вынесли корневые правила.
1. Галлюцинация возможностей. Ассистент предлагал модели, которых нет на текущей странице, или путал модель для картинок с моделью для видео. Пользователь справедливо злится: «нет такой модели». Фикс — не полагаться на «знание мира» модели: ассистент может называть и переключать только то, что реально есть в снимке текущей страницы. Это классическая проблема grounding — модель нужно жёстко привязать к состоянию интерфейса, иначе она уверенно врёт.
2. Подсветка не той кнопки. Просят показать «загрузить фото» — подсвечивает «Сгенерировать». Причина — нечёткий маппинг «намерение → элемент». Решение: элементы получают семантические якоря, и ассистент обязан подсветить ровно тот, о котором говорит, а не соседний по смыслу.
3. Навязчивость. Модель уже выбрана — ассистент всё равно лезет её менять; пользователь просит «просто напиши запрос» — а он спорит. Правило: если состояние уже подходит или пользователь явно просит не трогать — не действовать и не спорить, сразу делать то, что просят. Меньше инициативы, больше исполнения.
Вывод, который мы бы дали любому, кто строит агента поверх интерфейса: 90% качества — это не модель, а grounding и дисциплина действий. Модель должна видеть точное состояние и не имеет права выходить за его пределы.
Экономика диалога
Голос дороже текста, поэтому у орба есть бесплатное окно, дальше — оплата по факту разговора. Биллинг привязан к длительности голосового взаимодействия, а не к количеству «сообщений».
Тот же орб — на вашем сайте
Мы допилили орб под себя, но задача универсальна: любой сайт с нетривиальным интерфейсом (конфигуратор, личный кабинет, сложная форма, магазин с фильтрами) выигрывает от голосового поводыря, который видит страницу и действует на ней. Поэтому мы вынесли его во встраиваемый виджет — как он ставится и что умеет, разобрано отдельно: голосовой агент на любой сайт.
Если делаете что-то похожее — интересно сравнить подходы к grounding и barge-in. Попробовать орб вживую можно на neuralspace.pro.
🇬🇧 English version
Most on-site voice assistants are either a chatbot with speech recognition bolted on, or FAQ-read-aloud. At NeuralSpace we went the other way: make voice the primary way to drive the interface, not a layer over text. Here's the architecture and, more usefully, the failures — because the happy path taught us nothing.
The problem
Complex generation pages — video, images, music — have model pickers, reference uploads, prompts, params. New users freeze. Guided tours with arrows get closed on step two. We wanted a user to just say “I want to animate this photo” and have the assistant highlight the right control, explain it, and get them to a result.
The key difference from a chatbot: the orb sees the page state and acts on it, instead of replying “click button X somewhere over there.”
Architecture: three layers
- Voice pipeline — streaming speech recognition → model → speech synthesis, with low latency and barge-in (you start talking, it stops). Without barge-in it feels like a walkie-talkie, not a conversation.
- Brain — we deliberately decoupled the assistant's “personality” from any specific model (server-side config), so we can swap the model per task and cost without a frontend redeploy. It receives the user turn plus a machine-readable snapshot of the current page: which elements exist, which buttons, what's already selected.
- Client executor — the model returns not just text but actions: highlight element N, scroll to a block, explain a field. The client applies them over the real DOM.
The three failure modes we actually fixed
Capability hallucination. It suggested models that aren't on the current page, or confused an image model with a video model. Fix: never trust the model's “world knowledge” — it may only name or switch what's actually in the current page snapshot. Classic grounding problem: pin the model hard to UI state, or it confidently lies.
Highlighting the wrong button. Asked to show “upload photo,” it highlighted “Generate.” Fix: elements get semantic anchors, and the assistant must highlight the exact one it's talking about, not the semantically adjacent one.
Pushiness. The model is already selected — it still tries to change it; the user says “just write the prompt” — it argues. Rule: if the state is already fine, or the user says don't touch it, don't act and don't argue — just do what's asked. Less initiative, more execution.
Takeaway for anyone building a UI agent: 90% of quality is grounding and action discipline, not the model. The model must see exact state and may not step outside it.
Dialogue economics
Voice costs more than text, so the orb has a free window; after that you pay for the actual conversation. Billing is tied to the duration of the voice interaction, not to a count of “messages.”
The same orb, on your site
We built this for ourselves, but the problem is universal — any site with a nontrivial interface (configurators, dashboards, filtered e-commerce) benefits from a voice guide that sees the page and acts on it. So we packaged it as an embeddable widget: a voice agent for any website.
If you've built something similar, we'd love to compare notes on grounding and barge-in. Live demo: neuralspace.pro.
Часто задаваемые вопросы (FAQ)
Вопрос: Как получить лучший результат от нейросети?
Ответ: Используйте подробные промпты (описания) на английском языке, задавайте стиль и детали сцены.
Вопрос: Можно ли использовать эти материалы в коммерческих целях?
Ответ: Да, сгенерированный контент полностью принадлежит вам.