ИИ-ассистент для бизнеса: как мы внедряем нейросетевых помощников в Bitrix и 1С

Что такое ИИ-ассистент для бизнеса и чем он отличается от чат-бота

Когда к нам приходят с запросом «хотим бота на сайт», в половине случаев нужен не бот, а ассистент. Это принципиально разные сущности. Классический чат-бот идёт по заранее прописанному дереву сценариев: разработчик нарисовал ветки «доставка», «оплата», «возврат», и пользователь обязан в них попасть. Стоит написать «а если я оплатил, но курьер не приехал» — бот теряется, такой ветки в дереве нет. Ассистент на LLM работает иначе: он понимает контекст диалога, держит несколько сообщений в памяти и отвечает не по скрипту, а опираясь на подключённую базу знаний — регламенты, документацию, каталог, историю тикетов.

В нашей практике это особенно заметно на клиентах с живой речью: менеджеры пишут «скинь акт сверки за квартал по ромашке». Скриптовый бот здесь бессилен, а ассистент разбирает и интент, и сущность. Ключевая разница в том, где хранится логика ответа. У бота она в коде и ветвлениях, у ассистента — в базе знаний и промпте, который можно править без переписывания сценариев.

Поэтому мы почти всегда предлагаем начать с аудита: если задача сводится к «нажмите 1 или 2», дешевле и надёжнее останется бот. Если же нужно отвечать на вариативные вопросы по большому объёму данных — это уже территория ассистента.

В e-commerce и внутренних процессах ассистент закрывает задачи, которые боту просто не по силам. Ответы по регламентам: сотрудник спрашивает «сколько дней на согласование отпуска у директора», и ассистент достаёт норму из внутренней базы, а не пересказывает общий ТК.

Отдельная история — помощь менеджеру в CRM. Ассистент подтягивает историю сделки, напоминает про просроченную задачу, готовит черновик письма клиенту по контексту переписки. Здесь важно не то, что он «умный», а то, что он работает с данными системы, а не с абстрактными знаниями из интернета. В проектах с большим каталогом и активным импортом это снимает часы рутины в неделю.

Внедрение ИИ-ассистента: с чего начать и какие данные подготовить

Проблема не в модели. Она в базе знаний. Модель можно поменять за один вечер: переключить endpoint, переписать системный промпт. А пересобрать и вычистить базу знаний, на которой ассистент уже отвечал людям, — это недели и репутационные потери.

Поэтому на старте мы запрашиваем у клиента не «доступ к GPT», а четыре набора данных:

• Регламенты и инструкции — как оформляется возврат, какие сроки гарантии, кто согласует скидку.
• FAQ и скрипты поддержки — реальные формулировки, которыми менеджеры уже отвечают клиентам.
• Историю переписок — выгрузка диалогов из CRM или мессенджеров за 3–6 месяцев.
• Каталог и прайсы — номенклатура, характеристики, актуальные цены и остатки.

Если этих данных нет в структурированном виде — это не повод откладывать проект, но это первый пункт работ. Разберём последовательность, по которой мы ведём внедрение.

1. Провести аудит сценариев — определить 3–5 задач, которые ассистент закроет в первую очередь. Не «отвечать на всё», а конкретно: консультация по наличию товара, статус заказа, типовые вопросы по доставке. Чем уже сценарий, тем быстрее видно результат и тем проще собирать метрики. Расползание на десять тем сразу — верный способ не доделать ни одну.
2. Собрать и очистить базу знаний — выгрузить регламенты, FAQ, историю переписок в единое хранилище. Убрать дубли и противоречия (два документа с разными сроками возврата — гарантированный источник галлюцинаций), удалить устаревшие редакции, вычистить персональные данные клиентов и сотрудников. Файлы разбить на фрагменты по смыслу, а не по 500 символов вслепую.
3. Выбрать провайдера и модель — по критериям вашего проекта, а не по хайпу в лентах. OpenAI — зрелый Assistants API с инструментом file_search и vector stores; YandexGPT и GigaChat — российские провайдеры с хранением данных внутри контура и понятной юрисдикцией; DeepSeek — вариант, когда критична стоимость токенов. Смотреть на три вещи: где физически хранятся данные, есть ли tool-calling и RAG «из коробки», насколько провайдер стабилен по SLA.
4. Запустить пилот на одной команде — подключить ассистента к одной группе поддержки или отделу продаж, собрать метрики (доля решённых без эскалации, время ответа, явные ошибки), по результатам дообучить базу знаний и только потом раскатывать на остальные отделы.

Нейросетевой ассистент: как устроен RAG на vector stores

Распространённая ошибка: подключить к ассистенту модель посвежее и ждать, что он сам разберётся в вашем прайсе и регламентах. На деле без доступа к вашим документам модель отвечает по усреднённому знанию из обучающей выборки — и уверенно выдумывает артикулы, сроки и условия, которых у вас никогда не было. У магазинов с активным импортом это видно сразу: ассистент бодро называет цену, которой нет в каталоге, потому что «видел похожую» в интернете.

Лечится паттерном RAG (Retrieval-Augmented Generation): перед генерацией ответа ассистент ищет релевантные фрагменты в вашей базе знаний и подставляет их в контекст запроса. Ключевой элемент — vector store, хранилище, где документы разбиты на чанки, каждый чанк превращён в эмбеддинг (вектор чисел), и поиск идёт не по словам, а по смысловой близости. Спросили «сколько идёт доставка в Казань» — система найдёт абзац про сроки, даже если там написано «логистика в Республику Татарстан».

Для нас это означает простое: обновляя прайс или регламент, вы обновляете базу знаний, а не переписываете ассистента. Ниже разберём, как это устроено в OpenAI Assistants API v2 и как прикрутить к Bitrix-агенту.

В Assistants API v2 поиск по файлам работает через инструмент file_search и объект vector_stores. У хранилища есть поля id (идентификатор, который вы передаёте при создании ассистента), created_at (Unix timestamp создания) и file_counts — счётчик файлов со статусами: сколько загружено, сколько в обработке, сколько упало с ошибкой. Последнее поле стоит проверять после каждой синхронизации. Тихо упавший файл означает, что ассистент его просто не видит.

Процесс двухшаговый, и это место, где чаще всего путаются. Сначала файл загружается в общее хранилище OpenAI (метод files) — он получает свой file_id. Затем этот file_id привязывается к конкретному vector store. Один и тот же файл можно привязать к нескольким хранилищам: например, общий регламент — и к ассистенту поддержки, и к ассистенту отдела продаж. Удаление файла из хранилища не удаляет его из общего хранилища, это разные сущности.

Под свой проект вы захотите поменять две вещи: стратегию чанкинга (как резать документы) и частоту синхронизации. Для прайсов с табличной структурой чанки делают мельче, чтобы в контекст попадала одна позиция, а не половина прайса. Для регламентов — крупнее, чтобы сохранить смысловой абзац целиком. Синхронизацию вешаем либо на событие обновления инфоблока, либо на агент по расписанию. Если база меняется редко, второго достаточно.

60]);
$http->setHeader('Authorization', 'Bearer ' . Option::get('my.module', 'openai_api_key'));

if ($multipart) {
    // multipart/form-data для загрузки файла
    $http->setHeader('Content-Type', 'multipart/form-data');
    $response = $http->post(OPENAI_BASE . $path, $payload);
} else {
    $http->setHeader('Content-Type', 'application/json');
    $response = $http->post(OPENAI_BASE . $path, json_encode($payload, JSON_UNESCAPED_UNICODE));
}

return json_decode($response, true) ?? [];
}

// 1. Создаём vector store (один раз, id сохраняем в опциях модуля)
$storeId = Option::get('my.module', 'openai_vector_store_id', '');
if ($storeId === '') {
    $store = openaiRequest('POST', '/vector_stores', ['name' => 'knowledge-base']);
    $storeId = $store['id'] ?? '';
    Option::set('my.module', 'openai_vector_store_id', $storeId);
}

// 2. Загружаем файл в общее хранилище OpenAI
$fileContent = file_get_contents($_SERVER['DOCUMENT_ROOT'] . '/upload/kb/prices.pdf');
$file = openaiRequest('POST', '/files', [
        'purpose' => 'assistants',
        'file'    => new \CURLFile($_SERVER['DOCUMENT_ROOT'] . '/upload/kb/prices.pdf'),
    ], true);
$fileId = $file['id'] ?? '';

// 3. Привязываем file_id к конкретному vector store
if ($fileId !== '' && $storeId !== '') {
    openaiRequest('POST', "/vector_stores/{$storeId}/files", ['file_id' => $fileId]);
}

// 4. Проверяем file_counts — нет ли упавших файлов
$storeInfo = openaiRequest('GET', "/vector_stores/{$storeId}");
$failed = $storeInfo['file_counts']['failed'] ?? 0;
if ($failed > 0) {
    AddMessage2Log("Vector store {$storeId}: {$failed} файлов не обработано");
}

Чат-бот ассистент в Bitrix24: как подключить к CRM и задачам

Ассистент в Битрикс24 — это не отдельная сущность, а набор точек входа, куда вы можете его «поселить». У нас в проектах он обычно живёт в четырёх местах: чат портала (личные сообщения сотруднику), открытые линии (клиентские обращения), карточка сделки или лида (подсказки менеджеру прямо в контексте) и мобильное приложение через тот же чат. Каждая точка входа подключается по-своему.

Смысл интеграции с CRM простой: ассистент перестаёт быть «умной игрушкой в чате» и начинает работать с данными. Видит поля сделки, историю переписки, предыдущие звонки, стадию воронки. Без этого он отвечает в вакууме — общими фразами из промпта. С подключением к CRM он может квалифицировать лида по бюджету и отрасли, подсказывать менеджеру следующий шаг, писать резюме звонка в таймлайн. За это бизнес и платит: не за диалог, а за действие в CRM.

Комбинируется такая интеграция обычно с задачами: ассистент не только пишет в сделку, но и ставит задачу менеджеру, переносит дедлайн, создаёт напоминание. Ниже — как это связать технически.

Внутри Bitrix24 ассистент общается с порталом через REST API. Есть два способа доставки событий: входящие вебхуки (быстро, но без тонкой логики) и локальные приложения (полноценный OAuth, права, установка на портал). Для ассистента мы почти всегда выбираем второй вариант — нужны права на чтение сделок и запись в таймлайн, а это уже scope-и.

Ключевые события CRM, на которые подписывается ассистент: onCrmDealAdd, onCrmDealUpdate, onCrmLeadAdd, onCrmLeadUpdate. Они стреляют в момент изменения сущности и приходят с массивом FIELDS — там ID, стадия, ответственный, сумма. Обработчик регистрируется через EventManager, а не через старый AddEventHandler — это D7-идиоматика.

Что менять под свой проект: набор событий (только лиды, только сделки, или оба), точку вызова ассистента (синхронно в обработчике или через агент/очередь), и формат ответа — писать в таймлайн, в поле, или возвращать менеджеру всплывашку. Для нагруженных порталов синхронный вызов API модели в обработчике — плохая идея: событие держит транзакцию. Лучше положить задачу в очередь и обработать агентом.

• Квалификация лида — ассистент читает поля нового лида, задаёт уточняющие вопросы в открытой линии и проставляет балл/стадию в CRM.
• Подсказки менеджеру по сделке — при открытии карточки ассистент подтягивает историю и пишет в таймлайн «следующий шаг: отправить КП, ориентир — бюджет».
• Автоответ в открытой линии — первичные типовые вопросы (цены, сроки, наличие) закрывает ассистент, а сложные эскалирует на оператора с готовым контекстом.

ИИ-помощник для сотрудников: где он реально экономит время

Внутренний ассистент и клиентский — это два разных продукта, хотя под капотом может крутиться одна и та же модель. Клиентский отвечает на «сколько стоит доставка» и «есть ли в наличии», работает с публичным контентом сайта и обязан быть вежливым к анонимному пользователю. Внутренний — совсем другое дело: он ходит в закрытые базы знаний, видит регламенты, товарную матрицу, условия согласования заявок. И требования по безопасности к нему предъявляются другие. Утечка ответа клиентскому боту бьёт по репутации. Утечка ответа внутреннему — это инцидент с персональными данными и коммерческой тайной, разбираться придётся по ФЗ-152, о котором мы подробно говорим ниже.

Когда к нам приходят с задачей «сделать ассистента для сотрудников», почти всегда за этим стоит один и тот же симптом: люди тратят время на поиск информации, которая уже есть в компании, но лежит в десяти местах. Менеджер не помнит, в каком регламенте описана процедура возврата. Новичок в первую неделю дёргает коллег по любому поводу. Кладовщик уточняет, можно ли отгружать позицию, которая числится на стопе. В проектах с каталогом от 20 тысяч SKU и распределёнными командами это превращается в постоянный фоновый шум: вопрос — ответ — уточнение — ответ, и так по кругу.

Внутренний помощник снимает именно этот слой. Он не заменяет ни ERP, ни CRM, ни склад — он садится сверху и отвечает на вопросы, которые раньше уходили в чат к коллеге. Вот пять задач, которые он у нас в проектах забирает чаще всего:

• Поиск по регламентам и внутренним инструкциям — «как оформить возврат от юрлица», «какой срок согласования счёта».
• Онбординг новичков — адаптация по базе знаний вместо бесконечных вопросов наставнику в первый месяц.
• Ответы по товарной матрице — характеристики, аналоги, наличие, привязка к категории, условия поставки.
• Помощь в оформлении заявок — подсказка по полям, обязательным реквизитам, маршруту согласования.
• Расшифровка встреч и звонков — краткое резюме, задачи, ответственные, сроки из записи.

Дальше вопрос не «нужен ли помощник», а «куда его встроить, чтобы сотрудник не бегал в отдельное окно». У нас в проектах это чаще всего Bitrix24: там уже живут задачи, чаты и CRM, и ассистент встраивается прямо в рабочий контур.

Способов встроить три, и выбор зависит от того, насколько глубоко ассистент должен видеть контекст. Локальное приложение — самый гибкий вариант: вы получаете своё окно внутри портала, сами рисуете интерфейс и сами решаете, какие данные отдавать в модель. Бот в чате запускается быстрее всего, работает в личных сообщениях и групповых чатах, но ограничен форматом переписки. Виджет в карточке — самый точечный: помощник появляется прямо в карточке сделки или товара и сразу видит контекст объекта.

Ключевой момент, который чаще всего упускают на старте, — разграничение прав. Ассистент должен отвечать сотруднику только в пределах его полномочий: менеджер склада не должен получать выжимку из финансовых регламентов. В Bitrix это решается через CUser::Authorize при обработке запроса и проверку групп пользователя. Прежде чем отдать контекст в модель, вы определяете, кто именно спрашивает и к каким разделам базы знаний у него есть доступ. Если сотрудник вне группы, ассистент отвечает нейтрально и предлагает обратиться к ответственному, а не подтягивает документ «на всякий случай».

Как интегрировать ассистента с 1С и Bitrix: события, обмен, логирование

Самый частый запрос на эту тему звучит так: «ассистент отвечает клиенту, что товара нет, хотя он лежит на складе». Причина почти всегда одна — ассистент не знает про остатки и цены в 1С, он отвечает по устаревшему снимку каталога. Клиент видит «нет в наличии», уходит к конкуренту. Магазин узнаёт об этом из логов, когда менеджер вручную проверяет переписку.

Чтобы ассистент отвечал актуальными цифрами, ему нужны три вещи из учётной системы: остатки, цены и статусы заказов. Без них любой разговор с клиентом превращается в пересказ описания товара — а это уже не ассистент, а витрина. Поэтому интеграция с 1С — не «дополнительная фича», а базовая часть внедрения. И делать её нужно до того, как ассистент попадёт к клиентам.

Связка здесь двухслойная. 1С — источник правды, Bitrix — рабочая витрина, ассистент — витрина диалоговая. Данные идут так: 1С выгружает изменения, Bitrix их хранит, ассистент читает уже из Bitrix. Напрямую в 1С он не ходит — об этом ниже, в разделе про грабли.

Внутри Bitrix данные приходят через события каталога: OnAfterIBlockElementUpdate, OnAfterIBlockElementAdd, OnSuccessCatalogImport1C. Ловите их и обновляете свой слой данных, из которого отвечает ассистент. Если ассистент работает на D7-запросах, соединение с базой берётся через DataManager::getConnectionName — это тот же пул соединений, что использует ядро, и он корректно работает в рамках транзакций импорта.

<?php
use Bitrix\Main\Loader;
use Bitrix\Main\ORM\Query\Query;
use Bitrix\Main\ORM\Query\Filter\ConditionTree;
use Bitrix\Catalog\Model\ProductTable;

Loader::includeModule('catalog');

$connection = ProductTable::getEntity()->getConnectionName();

$filter = new ConditionTree();
$filter->where('ACTIVE', 'Y')
->whereNull('QUANTITY');

$products = ProductTable::query()
->setSelect(['ID', 'QUANTITY', 'PRICE', 'TIMESTAMP_X'])
->setFilter($filter)
->setOrder(['TIMESTAMP_X' => 'DESC'])
->setLimit(50)
->fetchAll();

foreach ($products as $product) {
    // отдаём ассистенту: остаток, цена, время обновления
    $assistantCache->set($product['ID'], $product);
}

ConditionTree::whereNull здесь фильтрует позиции, у которых остаток ещё не проставлен после импорта — их ассистенту показывать нельзя, иначе он скажет «нет данных» вместо «уточните у менеджера». Логику фильтра легко поменять под свой проект: у кого-то вместо QUANTITY будет AVAILABLE, у кого-то — свойство SKLAD_MOSCOW.

ФЗ-152 и персональные данные: что учесть до запуска ассистента

Как только ассистент получает доступ к переписке с клиентами, к заявкам из CRM или к истории заказов — вы автоматически становитесь оператором персональных данных. Не потому, что вы так решили, а потому что в поток попадают ФИО, телефоны, адреса доставки, email. Всё это позволяет определить конкретного человека. Владельцев сайтов приравнивают к операторам персональных данных уже на этапе форм обратной связи; ассистент, который читает эти формы и отвечает на них, только расширяет периметр обработки.

В наших проектах это всплывает на этапе пилота: ассистент уже отвечает в чате Битрикс24, а юрист приходит с вопросом, на каком основании данные клиента уходят в модель. Если архитектуру не подготовить заранее, переделывать придётся и логирование, и интеграцию, и сам промпт. Разберём, что требует закон и как это ложится на архитектуру ассистента до первого боевого запроса.

Ст. 5 152-ФЗ задаёт три принципа, которые напрямую влияют на то, как вы спроектируете ассистента.

Законная и справедливая основа. У обработки должна быть конкретная законная цель, и под неё — основание: согласие субъекта, договор, законный интерес. Для ассистента это значит, что нельзя «на всякий случай» прогонять через модель всю базу клиентов. Обрабатываем ровно тот минимум, который нужен для ответа на текущий запрос.

Ограничение обработки достижением конкретных целей. Если ассистент подключён к CRM, чтобы отвечать на вопросы по заказам, он не должен попутно обогащать профиль клиента или обучаться на переписке без отдельного основания. Цели фиксируются в политике обработки, и архитектура ассистента должна им соответствовать, а не наоборот.

Хранение не дольше, чем требуют цели. П. 7 ст. 5 прямо говорит: хранить данные в форме, позволяющей определить субъекта, можно не дольше, чем нужно для целей обработки. На практике это означает, что логи диалогов с ассистентом — не «вечное хранилище на всякий случай», а сущность с настраиваемым сроком жизни.

Отсюда три архитектурных следствия. Первое: точка входа ассистента должна уметь передавать контекст согласия — есть ли у клиента действующее согласие на обработку. Второе: перед отправкой в модель данные стоит обезличивать там, где полный контекст не нужен для ответа. Третье: логирование проектируется сразу с TTL, а не «допишем потом».

Чеклист, с которым мы идём в прод:

• Согласие субъекта — получить до первого сообщения в ассистента, хранить факт и дату согласия рядом с профилем.
• Обезличивание перед отправкой в модель — маскировать ФИО, телефоны, email, если они не нужны для формирования ответа.
• Ограничение срока хранения логов — задать TTL для истории диалогов, после которого записи удаляются или анонимизируются.
• Назначение ответственного за организацию обработки персональных данных — приказом, с фиксацией обязанностей.

Как защитить ассистента от галлюцинаций и запрещённых тем

Типичный сценарий: ассистент подключён к базе знаний, отвечает бодро и уверенно — и вдруг сообщает клиенту, что доставка в Казань занимает два дня, хотя в регламенте чёрным по белому «3–5 рабочих дней». Или хуже — называет цену, которой нет ни в одном прайсе. Это галлюцинации, и они остаются главным риском при внедрении ассистента в клиентский контур. Модель не врёт — она достраивает ответ по вероятностям, если не нашла точных данных в контексте. Для внутреннего помощника это досадная неточность. Для открытой линии — потерянный клиент.

У нас в проектах защита строится на простом принципе: ассистент не имеет права отвечать, если ответа нет в источнике. Мы запрещаем модели додумывать цены, сроки, условия акций и юридические формулировки — всё, что влечёт финансовые обязательства. Вместо этого ассистент либо цитирует найденный фрагмент, либо честно отвечает «не знаю, передаю менеджеру». Каждый ответ сохраняем вместе с источниками, чтобы потом разобрать спорный диалог.

Технически защита — это два независимых уровня. Первый — RAG: модель получает только те фрагменты базы знаний, что нашлись по векторному поиску, и в системном промпте жёстко зафиксировано «отвечай исключительно по предоставленному контексту». Второй — rails: внешний слой, который перехватывает запрос до модели и ответ после неё. Для rails мы обычно берём NVIDIA NeMo Guardrails — open-source-инструмент, который добавляет в LLM-приложение программируемые ограничения: фильтрацию запрещённых тем, контроль допустимых сценариев и обнаружение галлюцинаций.

Уровни решают разные задачи. RAG снижает вероятность выдумки, но не исключает её — модель всё равно может переформулировать найденное. Rails работают как страховка: если тема вне разрешённого списка или ответ противоречит источнику, диалог разворачивается на безопасный сценарий. Менять под свой проект придётся прежде всего список тем и правила сравнения ответа с контекстом. Они у каждого бизнеса свои.

from nemoguardrails import RailsConfig, LLMRails

# config/rails.co — правило «не отвечать вне базы знаний»
config = RailsConfig.from_path("./config")
rails = LLMRails(config)

# Колбэк проверки: если в ответе нет ссылки на фрагмент из RAG-контекста —
# подменяем ответ на безопасный.
async def check_grounding(context: dict, response: str) -> str:
    sources = context.get("relevant_chunks", [])
    if not sources:
        return "Уточню у специалиста и вернусь с ответом."
    return response

rails.register_action(check_grounding, "check_grounding")

response = rails.generate(
    messages=[{"role": "user", "content": "Сколько стоит доставка в Казань?"}]
)
print(response["content"])

Голосовой ассистент: как ускорить распознавание речи

Самый частый запрос на эту тему звучит так: «ассистент отвечает умно, но пока он распознает команду — сотрудник уже трижды повторил её и ушёл работать руками». Голосовой интерфейс нужен там, где у человека заняты руки или глаза: на складе кладовщик с терминалом и коробкой в руках, в цеху мастер у станка, у водителя в кабине, у курьера на выдаче. В этих сценариях задержка в 5–15 секунд это не «неприятно», а блокер: человек психологически возвращается к бумажному журналу или кнопкам на экране.

Причина почти всегда одна и та же — облачное распознавание по умолчанию. Библиотека SpeechRecognition в базовой конфигурации гонит аудио на серверы Google, ждёт ответа по сети, и только потом отдаёт текст. Каждый запрос это round-trip до дата-центра, плюс буферизация фразы целиком (движок ждёт паузу, чтобы понять, что вы закончили). На плохом Wi-Fi в ангаре или в подвале склада это легко растягивается до 10–15 секунд. Добавьте сюда, что у нас в проектах ассистент часто привязан к 1С и Bitrix — и вы получаете цепочку «голос → облако Google → наш бэкенд → LLM → ответ», где первое звено самое медленное и самое хрупкое.

Решение — вынести распознавание на устройство или на локальный сервер. Дальше разберём, чем это отличается от облака и когда что выбирать.

Разница между SpeechRecognition и Vosk — это разница между «отправить и ждать» и «слушать потоково». SpeechRecognition работает по модели request-response: вы записали фразу, отправили, получили результат. Vosk построен на движке Kaldi и работает offline: модель лежит локально, аудио обрабатывается чанками по мере поступления, а KaldiRecognizer отдаёт промежуточные результаты (PartialResult) прямо во время речи. Задержка падает до сотен миллисекунд, и она перестаёт зависеть от интернета.

Когда что выбирать. Облако имеет смысл, если у вас длинные диктовки (совещания, расшифровка звонков), где качество важнее скорости, и есть стабильный канал. Vosk — если нужен интерактивный диалог: короткие команды, ответы «да/нет», поиск товара по артикулу, отгрузка. В проектах со складскими терминалами мы почти всегда уходим в offline: там нет стабильного Wi-Fi, а пауза в 5 секунд убивает весь сценарий. Модель под русский язык качается отдельно и весит немного — её спокойно тянет даже маломощный промышленный планшет.

from vosk import Model, KaldiRecognizer
import pyaudio
import json

# модель скачивается заранее и кладётся рядом с приложением
model = Model("model-ru")
rec = KaldiRecognizer(model, 16000)

p = pyaudio.PyAudio()
stream = p.open(
    format=pyaudio.paInt16,
    channels=1,
    rate=16000,
    input=True,
    frames_per_buffer=8000,
)
stream.start_stream()

while True:
    data = stream.read(4000, exception_on_overflow=False)
    if len(data) == 0:
        break
    if rec.AcceptWaveform(data):
        # финальный результат по завершённой фразе
        result = json.loads(rec.Result())
        print("Фраза:", result.get("text"))
    else:
        # промежуточный результат — можно показывать прямо во время речи
        partial = json.loads(rec.PartialResult())
        print("...", partial.get("partial"))

Менять под свой проект здесь придётся три вещи: путь к модели (для русского — model-ru), частоту дискретизации под ваше железо и логику обработки PartialResult — именно она даёт эффект «ассистент слышит меня на лету». Финальный Result уходит дальше в ваш интент-роутер.

Самые частые ошибки при внедрении ИИ-ассистента

За последние проекты у нас сложилась устойчивая выборка: примерно в половине случаев к нам приходят не «с нуля», а дорабатывать ассистента, собранного своими силами или подрядчиком «на скорую руку». Симптомы почти всегда одинаковые — ассистент отвечает не то, утекают данные, никто не понимает, почему вчера работало, а сегодня нет. И почти всегда корень не в модели. Модель как раз работает нормально. Проблемы лежат вокруг: в базе знаний, в правах, в логировании, в юридической обвязке.

Ниже — те грабли, на которые мы наступаем чаще всего, когда разбираем чужую реализацию. Часть из них технические, часть организационные, но все они стоят недель переделок, если заметить их поздно.

Пробегитесь по таблице. Если хотя бы три пункта про ваш проект — это повод остановиться и провести аудит до того, как ассистент уйдёт в прод.

Разобранные случаи на ru.stackoverflow: Быстрое распознавание речи в python, голосовой ассистент с nlp python, при нажатии на кнопку нужно включить некоторые объекты и включить некоторые объе.