Станислав Лялин | Инженерия с ИИ

В последнее время обратил внимание, что многие люди стали ответственнее относиться к своему здоровью: отказываются от вредных привычек, занимаются спортом, следят за питанием, регулярно проходят обследования.

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

1. Каждое утро в нашей семье начинается с чайной церемонии. Она длится около 30 минут и помогает спокойно проснуться, настроиться на день, спланировать его и поговорить о важных вещах, на которые в дневной суете редко находится время.
2. Я много хожу пешком. До работы идти около 30 минут, и эти прогулки мне в радость: специально выбираю разные маршруты, обычно хожу энергично, иногда слушаю книги или музыку.
3. Моё рабочее место на 13-м этаже, и я уже несколько лет поднимаюсь и спускаюсь по лестнице. Начал ходить пешком во времена ковида, чтобы реже пользоваться лифтом, а потом это вошло в привычку. Заметил, что в походах поднимаюсь в горы без одышки.
4. После энергичной прогулки до работы я принимаю контрастный душ. Это уже ежедневный ритуал. В последние годы простуды в межсезонье, если и случаются, проходят легко и не выбивают меня из рабочего ритма.
5. Я часто купаюсь. В этом сезоне насчитал восемь разных мест, в некоторых купался неоднократно.
6. В течение рабочего дня занимаюсь на турнике и делаю самомассаж. Так что турник у меня - не вешалка для одежды 😊 Составил программу занятий с постепенно растущей нагрузкой, следую ей и отслеживаю повторения в приложении. Чувствую себя как заведённая пружина. Отличное чувство!
7. Отдельно занимаюсь растяжкой. Упражнения, особенно для спины, подбирал под себя, прислушиваясь к ощущениям. Записал 16-минутное аудио с зарядкой: оно помогает не пропускать упражнения и выполнять их в нужном ритме. Первое время было ощущение, будто расшевелил что-то древнее, застоявшееся. Но с каждым разом тело становилось гибче и податливее. Даже в зеркале вижу, что амплитуда многих движений выросла, а самочувствие улучшилось.

А про остальные полезные привычки расскажу в следующем посте.

Для себя я понял, что главное - постоянство. Полезные занятия нужно разумно встроить в свой день, и тогда не придётся каждый раз себя заставлять. И ещё одно важное понимание: стоит прислушиваться к себе и выбирать привычки, которые помогают поддерживать здоровье и придают сил. У каждого они будут свои.

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

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

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

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

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

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

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

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

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

В прошлом посте я рассказывал о том, почему полезно хранить контекст вне памяти сессии. Сегодня продолжаем тему и поговорим, почему контекст проекта полезно раскладывать не в одну огромную папку, а как дерево.

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

Ниже - отдельные ветки: исследования, планы, принятые решения. Внутри - исходные материалы: результаты экспериментов, детальные планы, записи обсуждений.

Зачем это нужно? В новую сессию не надо загружать всю историю. Достаточно передать карту проекта и нужную ветку. Агент быстрее находит важное, а мы не тратим контекстное окно на старые детали.

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

На фото - диаграмма такой структуры и скриншот из моего реального рабочего каталога контекстов.

Сегодня хочу рассказать про то, почему необходимо контексты для агента хранить отдельно вне сессии. Это часть моего доклада в Герценке, про который я писал в прошлом посте.

Память современных агентов - так называемое контекстное окно - составляет 200-400 тысяч токенов или примерно 1 том "Войны и мира". Это объём текста, который модель может держать в памяти. И кажется, что этого много. Но бывает, что сессия изобилует блоками кода, обсуждениями разных, порой не связанных друг с другом вопросов. И тогда контекстное окно может переполниться, модель что-то потеряет из виду, а что-то может ошибочно посчитать важным или, наоборот, неважным. Это может привести к неоптимальным решениям, и именно такое поведение я стал наблюдать во время сессий общения с ChatGPT.

Тогда я решил перестроить процесс и вести работу во временных чатах, а в конце дня выгружать контекст беседы в markdown-файлы, которые у меня упорядочены по дате, а в имени содержат суть диалога. И теперь, если мне нужно было продолжить общение с какой-то начальной точки, я просто отдавал модели нужные контексты, и мы продолжали работу.

Такой подход дал мне 2 преимущества:
1. контекстное окно не переполнялось и модель не начинала "сходить с ума".
2. история общения сохранялась в постоянной памяти на диске, и я мог использовать её дальше в работе, например, для создания презентаций, постанализа агентом.

17 сентября я выступал в нашей кировской библиотеке им. Герцена с докладом про ИИ в разработке.

И одним из тезисов, на котором я делал акцент - важность создания качественного AGENTS.md. Это файл с инструкциями для агента, который обычно лежит в корне репозитория.

Сам я не сразу пришёл к понимаю важности этого файла. Но по мере работы с агентом, по мере того, как из раза в раз приходилось повторять для него одни и те же инструкции, я понял, что устал это делать, и нужно важные для меня требования зафиксировать в некотором соглашении. Так я создал и начал заполнять AGENTS.md. Сначала это было банально требование писать короткое тире и прямые кавычки вместо ёлочек. Потом постепенно я расширял набор своих "хотелок" от агента и включил в файл другие важные требования. Например, вот что интересного хранится в моём AGENTS.md
на данный момент:
* разделение разработки на 2 части: реализация и Senior Review, которые выполняются отдельными коммитами;
* Senior Review сопровождается стадией, которую я назвал Code Pruning, по аналогии с усечением деревьев решений в ML. На этой стадии устраняются дублирования, неиспользуемые конструкции, лишние проверки;
* требования к языку: простой, инженерный, без англицизмов;
* если агент при реализации видит, что выходит за лимит плана, обязательно согласует со мной изменение объёма;
* изменения небольшие и логически связанные, как правило не более 300 строк кода, чтобы можно было проверить вручную.

Я постарался сделать файл универсальным, чтобы переиспользовать в разных проектах. Теперь он хранится в отдельном git-репозитории и разворачивается в нужные проекты специальным скриптом с подменой ссылок на актуальные контексты.

В своём предыдущем посте я писал про то, что многие модели машинного обучения намного эффективнее работают на видеокарте - за счёт того, что на видеокарте тысячи небольших процессоров, которые работают параллельно. Это называется массивно-параллельные вычисления. Именно поэтому сейчас, в эпоху развития ИИ, такой спрос на видеокарты. Я провёл эксперимент: выполнял распознавание речи на своём ноутбуке с i5, а затем на видеокарте NVIDIA L4. Ускорение получилось примерно в 20 раз!

Не всегда модели доступны в облаке, как было, например с GigaAM от Сбера. И возникает выбор: либо покупать свою видеокарту, либо арендовать у провайдера. В нашем случае первый вариант был невыгоден: карта стоит около 500 тысяч рублей, необходимо серверное оборудование для её размещения, что ещё увеличивает затраты, а большую часть времени она будет простаивать.

Поэтому я рассмотрел вариант аренды выделенного сервера с видеокартой у провайдера Selectel. Selectel был выбран потому, что позволяет гибко управлять потреблением ресурсов: когда видеокарта не нужна, сервер можно заморозить. При этом на время заморозки тарифицируется только диск и сеть. Этот вариант оказался самым выгодным. Правда в процессе экспериментов я столкнулся с тем, что вместо заморозки сделал выключение сервера, и у меня тарификация шла как с GPU всю ночь. Но зато после этого стал аккуратнее.

Так что если для вас не подходит использование облачного API (например, чувствительные данные не должны уходить во внешний контур) и если не хотите разворачивать собственный сервер с видеокартой, вариант аренды GPU с опцией заморозки - отличный выбор!

Я работаю над проектом, где одним из ключевых компонентов является распознавание русскоязычной речи в телефонных разговорах.
Многие следят за новостями о развитии ИИ-систем и знают, какой огромный шаг за последние годы был сделан в речевых технологиях, а именно в распознавании и генерации речи.

Но среди множества моделей как узнать, какая лучшая? И что значит лучшая? Я выбрал для сравнения следующие критерии:
- Качество сохранения бизнес-контекста. Не ошибается ли модель в таких важных сущностях, как отрицания, числовые параметры, определение потребностей клиента. Не выдумывает ли несуществующие факты.
- Скорость работы - параметр RTF (Real-Time Factor). Если параметр равен 1, значит минуту аудио модель будет распознавать 1 минуту. Желательно, чтобы RTF был намного меньше единицы.
- Доступность. Доступна ли модель для локального запуска или через облачный API. Нет ли риска блокировок, недоступности из-за ограничений трафика или необходимости оплаты иностранной картой?

Эксперимент я строил на сравнении результатов с эталонами, которые вручную размечал с помощью специально созданной программы. А для независимой оценки сохранения бизнес-контекста использовал Qwen и codex, для которых кандидаты были анонимизированы.
Изначально фаворитами были Yandex SpeechKit, Qwen FileTrans от Alibaba и WhisperX от OpenAI. Сложность была в том, что для каждой платформы необходимо было создавать аккаунт, привязывать карту, создавать токен. И, помучившись какое-то время, я открыл сервисы-агрегаторы вроде Eden AI и Replicate. Эти сервисы позволяют один раз создать аккаунт, привязать карту и получить токен и затем через единообразный API тестировать разные модели. Это очень удобно, экономит много времени и сил! Через эти сервисы я протестировал ещё множество моделей.
И вот совершенно случайно мне на глаза попалась новость (https://t.me/toBeAnMLspecialist/1178),
что существует в открытом доступе модель GigaAM от Сбера, которая отлично справляется с русским языком. Протестировал и её.

Результаты.
Оба независимых оценщика поставили GigaAM от Сбер на 1 место. Также высоко были оценены WhisperX и Qwen. На графиках RTF у GigaAM довольно значительный, но при запуске на видеокарте его можно существенно снизить - примерно в 20 раз, поэтому распознаёт модель очень быстро.
Когда-то модель GigaAM была доступна через облачный API, но позже Сбер убрал такую возможность, выложив модель в открытый доступ.

Выводы.
Для нашего проекта я выбрал GigaAM от Сбера. Эта модель даёт лучший результат распознавания, работает быстро, умеет нормализовать текст (исправлять грамматику, числа и т.п.), она свободно доступна, то есть мы не зависим от внешних поставщиков, а платить нужно только за ресурс видеокарты. Из недостатков: необходимо содержать свою инфраструктуру для запуска. И модель не умеет исправлять термины по словарю.
И ещё один важный вывод - я открыл для себя сервисы - Eden AI и Replicate, где можно удобно протестировать различные модели и выбрать подходящую под свою задачу.

Привет! Я Станислав.

Здесь буду писать о практической инженерии с ИИ - не только о моделях и агентах, но и о том, как с их помощью строить работающие системы.

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

Буду разбирать не только инструменты, но и то, как я применяю их в реальных проектах.

Если какая-то тема особенно интересна - напишите в комментариях.