Давно не было постов в серии
#weekend. Хочу рассказать про то, как устроена самая сложная часть голосового ассистента
Homai. Это серверное ядро системы, во второй своей версии, я его сейчас переписываю.
Ядро - это сервер на golang, который отвечает за подключение всех девайсов по WebSocket, координирует их работу, собирает задачи по обработке голосового ввода на своих моделях (ASR), передачу задач на пайплайны ассистентов или выделенным серверам озвучки (TTS), которые тоже используют свои модели.
Во второй версии ядра мы хотели добавить пару улучшений:
(1) полное покрытие системы тестами, возможность запуска системы в режиме симуляции с ускорением времени.
(2) асинхронная работа всех элементов системы, чтобы голосовой ответ начинал идти в режиме стриминга с минимальной задержкой (в идеале - до секунды)
(3) подключение LLM-логики по архитектуре корпоративных AI ассистентов с поддержкой асинхронной работы
(4) нормальное логгирование всего процесса ответа на запросы, с возможностью анализа ошибок и улучшения системы.
(5) запуск локальных моделей на выделенных серверах c GPU и автоматической перебалансировкой нагрузки.
Там еще было много других хотелок. Но самое главное было в том, чтобы ядро брало на себя сложные задачи вроде координации и балансировки, а вся бизнес-логика писалась отдельно в виде простых скриптов на питоне.
Потребовалось прототипов 6, чтобы утрясти всю архитектуру под эти требования. Основные фишки
(1) структурное логгирование встроено в систему с самого начала. Оно используется для отладки системы и написания event-driven тестов (я этот подход
таскаю из проекта в проект)
(2) самая сложная часть - координатор - сделан в виде одного единственного класса Finite State Machine, каждый чих которого покрыт тестами. Он перегягивает всю остальную сложность системы на себя (
см про FSM)
(3) Вся система строится так, чтобы она могла работать в режиме виртуальной симуляции. Например, можно запустить с десяток асинхронных подключений к серверу, добавить случайные обрывы соединений и периодическую перебалансировку GPU. А потом прогнать месяцы работы системы в таком режиме за минуты. Идеей в давном давно поделились инженеры из FoundationDB, которая теперь служит основанием для Apple iCloud (
см хорошее видео тут).
Если интересно, в комментариях я выложу пример отладки системы в одном из режимов симуляции, плюс пример теста.
В разработке и отладке всей системы очень сильно помогают ChatGPT/Claude и даже Copilot, позволяя
разрабатывать ее очень малыми силами. Поэтому архитектура и код адаптированы под такой режим разработки. Структурное логгирование, event-driven tests и симуляция оптимизированы под участие LLM в разработке, это немного похоже на работу
Anithesis.
А у вас есть такие примеры продуктов, когда LLM-ки невероятно помогают в разработке продуктов малыми силами?
Ваш,
@llm_under_hood 🤗
