С появлением ИИ-агентов стало возможным строить сложные и эффективные…

С появлением ИИ-агентов стало возможным строить сложные и эффективные информационные системы даже с небольшими ресурсами, поэтому такие решения становятся доступны среднему и малому бизнесу. На примере одной своей задачи - распознавания телефонных звонков - расскажу, как была построена такая система. Бизнесу нужно было, чтобы результат распознавания был качественным, недорогим, минимально зависел от внешних факторов, и была возможность мониторинга работы.

Поэтому я разделил систему на оркестратор и GPU-worker.

• Worker выполняет тяжёлую работу: запускает ML-модели, распознаёт записи и возвращает результат. На GPU такие задачи идут кратно быстрее, но постоянно арендовать GPU-сервер дорого. Поэтому worker включается только при наличии очереди и после обработки выключается.

• Оркестратор живёт отдельно на обычном недорогом сервере. Он постоянно доступен: ведёт очередь, управляет запуском GPU, принимает результаты, публикует их и показывает статус. Размещать эту логику на временной GPU-машине нельзя: замороженный сервер не сможет сам себя разбудить, а работающий в простое GPU будет создавать ненужные расходы.

• Сервисы развёрнуты в Docker. Это даёт переносимость: систему можно поднять у другого хостинга без ручной сборки окружения. Контейнеры также упрощают мониторинг, перезапуск и восстановление после сбоев.

• PostgreSQL - единый источник истины. В нём хранятся задания, попытки обработки, результаты, публикации и состояние GPU. Задание выдаётся worker-у атомарно, поэтому два worker-а не получат одну работу. Уникальные ограничения и идемпотентные ключи защищают от повторов при сетевых сбоях. Публикация работает через паттерн outbox: сначала намерение надёжно записывается в БД, затем отдельный процесс доставляет результат с повторами без дублей.

• Наблюдаемость нужна не для отчёта, а для повышения надёжности системы. Дашборд показывает очередь, статусы worker-а и GPU, ошибки и производительность. В Telegram сразу приходят сообщения о потере worker-а, ошибке запуска или остановки. По идентификатору события можно быстро найти связанные журналы, разобраться в причине и быстро принять меры по перезапуску или доработке.

• Внешний контур контроля работает независимо от worker-а: следит за работоспособностью worker-а. Если worker завис или не остановился, он отправляет уведомление и запускает аварийную заморозку GPU. Это защищает бюджет от незаметных списаний и не оставляет систему без сигнала о проблеме.

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