Как я разработала AgroPilot AI: от бизнес-задачи до измеримого Voice AI MVP
Кейс о разработке AgroPilot AI: архитектура голосового ассистента, серверный Realtime-пайплайн, telephony-ready MVP, измерение задержки первого аудиоответа, benchmark и выводы о скорости, надёжности и развитии продукта для реального агротехнологического бизнеса заказчика.
Постановка задачи и проблема голосовой задержки
Работа над AgroPilot AI началась с задачи, которая на первый взгляд могла показаться обычной разработкой сайта для компании, работающей с сельскохозяйственными дронами. Однако почти сразу стало понятно, что основная ценность проекта находится не в каталоге оборудования и не в презентационном интерфейсе. Заказчику требовался технологический MVP, способный показать, как голосовой искусственный интеллект может применяться в реальном бизнес-сценарии, и одновременно решить одну из самых заметных проблем голосовых ассистентов — задержку между окончанием вопроса пользователя и началом ответа модели.
В текстовом чате ожидание в одну или две секунды часто воспринимается нормально: пользователь видит индикатор загрузки, поток текста или хотя бы понимает, что система обрабатывает запрос. В голосовом и особенно телефонном диалоге такая же пауза ощущается значительно сильнее. Человек не знает, услышал ли его ассистент, не прервалась ли связь и нужно ли повторить вопрос. Из-за этого разговор теряет естественность, а сама технология производит впечатление медленной и ненадёжной. Поэтому я сформулировала ключевую цель проекта предельно конкретно: создать платформу, которая не просто разговаривает с пользователем, а измеряет и помогает сокращать время от окончания речи до первого слышимого фрагмента ответа.
Как я сформировала MVP проекта
Первым этапом стала декомпозиция требований. Я отделила обязательные функции MVP от идей, которые могли увеличить сроки, стоимость и архитектурную сложность, но не доказывали основную гипотезу. В обязательный контур вошли публичный сайт, база знаний, формы заявок, текстовый AI-чат, голосовой web-интерфейс, серверный Realtime pipeline, подготовка к телефонному каналу и отдельный benchmark dashboard. Такой подход позволил не превращать эксперимент в бесконечную разработку универсальной платформы и удерживать внимание на проверяемом результате.
Для реализации я выстроила последовательный процесс: архитектура, frontend-дизайн, разработка, техническое ревью и исправление найденных проблем. Перед каждым этапом фиксировались ограничения и критерии приёмки. Отдельно проверялись отмена запроса, разрыв соединения, сохранение контекста, безопасность ключей и корректность серверно-клиентских границ.
Разработка интерфейса и текстового AI-чата
Клиентская часть была построена на Next.js и React. На сайте появились каталог агродронов, база знаний, формы заявок, текстовый помощник и голосовой ассистент. Пользователь мог открыть диалог, задать вопрос и услышать ответ, а система параллельно сохраняла сообщения, транскрипты, статусы и метрики.
Одной из важных проблем оказался контекст разговора. В интерфейсе пользователь видел полную историю, однако модель могла забыть имя, номер телефона или детали предыдущего сообщения. Анализ показал две причины: часть контекста обрезалась при построении системного запроса, а новый conversationId мог создаваться на каждом ходе. Я проследила движение данных от клиентского хука до серверного builder и слоя базы данных, после чего история сообщений, идентификатор разговора и дополнительные сведения стали передаваться согласованно. Этот этап особенно показателен: визуально корректный чат ещё не означает, что диалог действительно сохраняет память на уровне модели.
Реализация голосового Realtime-канала
Голосовой канал потребовал другой архитектуры. Я реализовала server-side Realtime pipeline, в котором браузер передаёт аудио, сервер управляет Realtime-сессией, а критическая конфигурация остаётся недоступной клиенту. Соединение с OpenAI Realtime устанавливается через серверный WebSocket. Системный промпт, база знаний, правила поведения и API-ключи не отправляются в браузер. Для проекта использовалась доступная в аккаунте модель gpt-realtime-2.1-mini, предварительно разрешённая на уровне OpenAI API Project.
Подготовка проекта к телефонии
Следующим направлением стала подготовка к телефонии. Полноценное подключение оператора, SIP-номера и коммерческой линии не входило в доступный бюджет, но отсутствие оплаченного канала не должно было блокировать архитектурную часть. Я разработала provider-neutral слой TelephonyAdapter и RealtimeCallBridge. Он описывает жизненный цикл звонка: входящий вызов, ожидание, принятие, подключение, завершение или ошибка. Для каждого перехода определены допустимые состояния, отдельно обрабатываются отмена, ошибка и отключение абонента, а повторный hangup исключён.
Телефонные сообщения и транскрипты сохраняются в общей модели данных с каналом telephony. Для тестирования использовался аудиоформат PCMU 8 kHz, характерный для телефонной связи, а в метрики было добавлено время транскодирования. Такой результат я обозначила как telephony-ready MVP. Это означает, что серверный мост, жизненный цикл и формат аудио готовы к подключению провайдера, но проект не выдаётся за действующую PSTN- или SIP-линию. Честная терминология здесь особенно важна, поскольку техническая готовность интеграционного слоя и реально работающая телефония — разные уровни завершённости.
Как проводился benchmark
Ключевым доказательством результата стал benchmark. Я отказалась от субъективных формулировок вроде «ассистент отвечает быстро» и определила конкретные события, которые можно зарегистрировать: готовность сессии, окончание пользовательской речи, получение первого аудиофрагмента, финальную расшифровку и завершение всего хода. Главной метрикой стало время Speech end → first assistant audio. Дополнительно измерялись p50, p95, общая длительность, успешность, тип ошибки и время транскодирования.
Для сравнения были подготовлены два режима: baseline и optimized. Baseline представлял более консервативную конфигурацию, ориентированную на стабильность. В optimized использовались настройки, сокращающие внутреннюю обработку и ускоряющие определение конца речи. Сценарии строились на фактах из базы знаний: цена конкретной модели, производительность, рекомендуемая площадь применения, общие вопросы и запросы, на которые система не должна отвечать без подтверждённых данных.
Результаты baseline и optimized
Финальный server-side запуск включил 44 реальные платные попытки, из которых 40 завершились полным аудиоответом. Общая успешность составила 90,9%. В web-voice сценарии медианная задержка до первого аудио снизилась с 1239 до 721 миллисекунды, то есть примерно на 42%. В телефонном аудиоформате показатель снизился с 902 до 607 миллисекунд, примерно на 33%. При этом baseline завершил все попытки успешно, а optimized показал 83,3% успешности: четыре отмены возникли в сценарии с неизвестными данными.
Эти результаты позволили сделать более полезный вывод, чем простое утверждение о победе одного режима. Оптимизированная конфигурация действительно быстрее, но выигрыш в скорости сопровождается снижением устойчивости в отдельных сценариях. Baseline подходит как надёжный режим по умолчанию, а optimized требует дополнительной стабилизации перед production-внедрением. Такой вывод помогает принимать инженерное решение на основе баланса между скоростью и надёжностью, а не выбирать конфигурацию только по минимальному значению задержки.
Методологические ограничения
После получения цифр я провела методологический аудит benchmark. Аудиофикстуры в server-side тесте отправлялись пакетно, без имитации естественного темпа живой речи. В измерения не входили задержки микрофона, браузерный WebRTC, Opus-кодирование, jitter buffer, мобильная сеть и реальный SIP/PSTN-тракт. Следовательно, опубликованные значения нельзя называть полной задержкой коммерческого телефонного звонка. Они измеряют влияние конфигурации OpenAI Realtime внутри контролируемого серверного pipeline.
Каждый значимый этап проходил цикл реализации, ревью и исправлений. Для текстового модуля итоговая проверка включала 266 успешно пройденных тестов, чистую типизацию и lint. Дополнительно проверялись безопасность session token, корректная отмена потоков, сохранение метрик и отсутствие утечки внутренних ошибок.
Результат проекта и дальнейшее развитие
Для меня профессиональный результат — это не демонстрация, в которой всё выглядит безупречно только один раз. Это система с понятными границами, воспроизводимыми метриками, сохранёнными данными и планом дальнейшего развития. Следующим логичным этапом для AgroPilot AI станет тестирование с естественным realtime pacing, подключение реального телефонного провайдера, измерение end-to-end задержки и стабилизация optimized-режима на неизвестных и пограничных запросах.
Уже на текущем этапе проект выполняет главную задачу: превращает абстрактный разговор о «быстром голосовом AI» в измеримый инженерный результат. AgroPilot AI объединяет публичный сайт, базу знаний, текстовый и голосовой интерфейсы, server-side Realtime bridge, telephony-ready архитектуру и benchmark dashboard. Проект стал прочной основой для следующего пилота и показал, что скорость голосового ассистента нужно оценивать вместе с надёжностью, архитектурной безопасностью и честностью эксперимента. Результат уже готов для демонстрации.