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

Проект LUWRAIN — пример именно такой истории. Это платформа для разработки невизуальных приложений, которая тринадцать лет создаётся усилиями энтузиастов. Сегодня у неё появляется шанс сделать рывок — с помощью LLM и инженерных подходов, основанных на открытых технологиях. В случае LUWRAIN, как и в случае многих похожих инициатив, существует поиск правильного соотношения смысла и усилий. Поэкспериментировать и найти баланс в том числе помогла программа грантов Yandex Open Source.

Меня зовут Михаил Пожидаев, я работаю доцентом теоретической информатики в Томском государственном университете. Читаю такие предметы как обработка естественного языка, ОС UNIX, анализ социальных сетей и введение в программную инженерию. В этой статье расскажу о своём опыте создания программных продуктов, которые должны казаться странными и нелогичными в привычных обстоятельствах, но обстоятельства нестандартны.

С чего начался мой опыт разработки для незрячих

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

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

До 2012 года я активно пользовался Emacspeak. А потом окончательно убедился: его нужно переписать. Так появился LUWRAIN — и мы вместе уже 13 лет. За это время проект вырос и изменился, а вместе с ним пришлось задуматься о жизненном цикле и позиционировании.

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

LUWRAIN с самого начала развивался в непростой обстановке из‑за дефицита рабочих рук. Это типично для многих социальных инициатив. Главная трудность в том, что у таких проектов очень узкая и нестабильная аудитория в привычном рыночном смысле. Формально пользователи есть, но для инвесторов эта ниша неинтересна: нет выхода — значит, не будет и входа. Остаётся полагаться только на собственные силы. Найти вовлечённых людей даже в открытой среде опенсорс‑сообщества не так просто — для зрячих разработчиков проблематика кажется слишком далёкой.

Ещё две фундаментальные сложности: 

1. Численность. Незрячие люди есть, но их немного. По разным оценкам, от 300 тысяч и выше, в зависимости от критериев. Даже по верхней планке это сравнительно небольшая аудитория. 

2. Активность. Столкнувшись с серьёзными ограничениями здоровья, очень трудно поверить, что можно жить почти так же, как раньше. И уж тем более — осваивать Linux. Любое стремление к активному образу жизни быстро растворяется, а вместе с ним исчезает и интерес к новым технологиям.

На практике всё сводится к проверенным нормам доступности: метки на веб‑страницах, подписи к картинкам в приложениях и так далее. Новые подходы же оказываются невостребованными. 

Отсюда и замкнутый круг: без спроса нет самоокупаемости, без этого не привлечь профессиональных разработчиков. А LUWRAIN — это кроссплатформенная Java‑разработка со сложной архитектурой и множеством внутренних инструментов. Для её развития нужны серьёзные компетенции.

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

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

На что хотелось привлечь больше ресурсов

В грантовой программе Yandex Open Source можно получить ресурсы на развитие своего проекта, которые разделены на две категории: интеллектуальные движки в Yandex AI Studio и облачные мощности для создания облачного компаньона. Начну с применения LLM.

Читая новости о том, как компании поручают языковым моделям задачи уровня джунов, я решил поэкспериментировать с YandexGPT (сейчас это семейство моделей развивается уже под именем Alice AI LLM) — хотя бы в генерации шаблонного кода. А такого в LUWRAIN немало: проектирование интерфейсов, типовые обработчики и прочее. Мне стало интересно, можно ли хотя бы частично компенсировать дефицит живых рук за счёт LLM.

Для этого я сделал заготовку с типичными и шаблонными примерами кода и начал подставлять её в промпт в YandexGPT. Основное ограничение оказалось в объёме промпта: даже у продвинутой версии он ограничен 32 килотокенами, что примерно соответствует пяти тысячам строк моего кода. Пока я не углублялся ни в файнтюнинг, ни в обучение модели, а просто отбирал нужные фрагменты и формулировал задачу.

Результат оказался обнадёживающим. YandexGPT пишет код не только формально корректный, но и в моём стиле — так, как сделал бы я сам. Я подставляю ей свою заготовку с классами, структурами и оформлением, а дальше формулирую задачу словами: например, «Сгенерируй класс с такими‑то полями». И она пишет.

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

Облачный компаньон — LUWRAIN Social

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

В истории у нас было две попытки завести облачного компаньона, которые мы условно называем LUWRAIN Books и AI Books. Обе по факту провалились. Оба инструмента были ориентированы на адаптацию книг (AI Books очень немало задействовал Yandex SpeechKit), но быстро обнаружилось, что адаптировать чужую литературу для школьников без лицензии правообладателя нельзя. Обидно.

При этом идея сама по себе неплоха. Нечто в облаке может дополнять LUWRAIN так же, как, например, Google Play дополняет Android. Можно собирать расширения для LUWRAIN. То, что он на Java, и расширение будет работать на всех ОС, играет нам на руку. Плюс у нас же втянут движок JavaScript. То есть юзеры могут вообще без Java клепать плагины.

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

В жизни незрячего линуксоида большую роль играют некоторые графические системы, которые позволяют задавать графический контент текстовым описанием. Это прежде всего TeX, Metapost, GNU Plot, PlantUML, Graphviz и др. При этом TeX для многих, вообще‑то, кажется ужасом. То есть заставить школьника писать в TeX нереально. Студента в среднем тоже. 

Я долго думал над этим. В итоге решил поверх TeX сделать надстройку в Markdown. Получается, что TeX выступает как бэкенд для форматирования контента, заданного в Markdown. Его и в HTML тоже потом можно отправить. 

Для TeX предусматриваем готовые шаблоны для ВКР, статьи, книги и пр. И что получаем? Правильно! Получается централизованный облачный сервис для подготовки учебных работ с кроссплатформенным невизуальным клиентом для незрячих. Именно над ним я начал работать в рамках гранта, используя его облачные возможности.

Рассуждаем дальше. Раз мы можем оформлять контент, доставлять его, а ещё у нас есть инструмент для взаимодействия без зрения, почему не подтянуть интеллектуальные инструменты? Переводчик с ИИ, поиск с RAG и похожие вещи сейчас доступны без проблем. С их помощью можно сделать проект более инклюзивным, кроссплатформенным, удобным.

Новые компоненты LUWRAIN

Я сделал конвертер из Markdown в TeX, расширив стандартную нотацию: добавил поддержку математических выражений, ссылок на литературу, перекрёстных ссылок и меток глав. Всё это корректно транслируется в TeX.

Помимо самого TeX, я упаковал в контейнеры набор утилит для подготовки векторной графики. В первую очередь — Metapost (идёт в составе TeX), а также Gnuplot для построения графиков и PlantUML для рисования схем и диаграмм. С Graphviz пока остаются некоторые проблемы, но они решаемы. Собранные компоненты доступны в облаке — как через API, так и через веб‑интерфейс. В результате получился инструмент, позволяющий быстро набрасывать научный контент, который автоматически оформляется как полноценная работа.

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

Собранная инженерия, помимо экспорта в TeX, умеет генерировать и HTML‑версию материалов. Один и тот же Markdown с расширениями можно транслировать и в TeX, и в HTML. Это значит, что статью, диссертацию, книгу или ВКР можно не только собрать в PDF, но и удобно просматривать прямо в браузере.

Добавление интеллектуальных инструментов тоже оказалось логичным шагом. Здесь я протестировал YandexGPT для целого ряда задач. 

Один из ярких сценариев — создание презентаций. Система формирует слайды по тому же пути: Markdown → TeX → PDF. Если задать тему (например, «Микросервисная архитектура») и заголовок — в ответ получается готовый слайд с оформленным текстом, предложенным LLM (пишет она, надо сказать, вполне неплохо).

Есть и любопытный эксперимент: YandexGPT можно попросить превратить математическую формулу в словесное объяснение. Работает пока нестабильно, но направление кажется перспективным. При этом видно, что модель не только умеет генерировать формулы в TeX, но и стабильно воспринимает TeX‑нотацию. Очевидно, что во время обучения математика подавалась именно в таком виде.

В итоге связка TeX + Markdown оказывается особенно удобной для автоматизации научной и учебной работы. Сейчас я хочу собрать всё это в единую, логичную систему.

Что уже готово

Генератор Markdown → TeX планирую выложить на Maven Central. Почти завершена упаковка графических утилит (TeX, MetaPost, Gnuplot и другие) в контейнеры. Реализована структура хранения публикаций, презентаций и сопутствующих материалов — с учётом информационной логики и будущей автоматизации. Интеграция с YandexGPT — дело нехитрое.

Планирую также подключить Yandex SpeechKit: хочу протестировать генерацию аудиоверсий материалов для пользователей с нарушениями зрения с сохранением в форматах DAISY и EPUB.

Технически всё написано в основном на Java. Веб‑фреймворк — Apache Tomcat, брокер сообщений — Apache Kafka®, база данных — PostgreSQL, Redis для кэширования, шаблонизация интерфейса — Apache Velocity™. 

Система распределена по нескольким виртуальным машинам. На входе — балансировщик Nginx. Образы подняты на Ubuntu. В отдельных виртуальных машинах размещены две реплики Apache Tomcat, между которыми Nginx распределяет трафик. Очевидно, что при необходимости я могу нарастить количество реплик Tomcat — сейчас их всего две, и этого достаточно, чтобы процесс обновлений проходил незаметно для внешних пользователей.

Также на отдельных виртуальных машинах развёрнут Apache Kafka — в роли брокера, через который контейнеры обмениваются сообщениями. Я долго размышлял, можно ли как‑то переложить на Kafka функции базы данных. Учитывая её архитектуру, ориентированную на лог‑сегменты (почти как в Event Sourcing или «append‑only» базах), это могло бы быть удобно. Но пока ни одной реалистичной схемы переноса этих функций не придумал — ничего толкового в голову не пришло.

Облачная архитектура и развёртывание

Теперь — о том, как устроено облако и какие инструменты Яндекса мы используем.

База данных — PostgreSQL, которая была развернута как managed‑сервис в Yandex Cloud. И здесь нас ждал сюрприз: поначалу я включил его в отладочном режиме, не думая о расходах, а спустя пару месяцев выяснилось, что PostgreSQL «съедает» львиную долю бюджета — около 11 тысяч рублей в месяц. Для сравнения с другими сервисами это оказалось неоправданно дорого. В итоге я отказался от managed‑решения и поднял собственный инстанс на отдельной ВМ. Да, это добавило забот: мониторинг, бэкапы, контроль состояния. Но выбора просто не было — managed‑вариант для социального проекта невыгоден.

Object Storage, наоборот, очень пригодился в виде сервиса в Yandex Cloud. Туда я перевёл все S3-хостинги, включая материалы личного сайта со своими заметками и материалами лекций для студентов. Теперь он работает полностью через S3: и статические страницы, и логика отдаются оттуда же. Для HTTPS‑сертификатов использовал сервис Certificate Manager. Раньше я ставил Certbot и всё настраивал вручную — было нормально. С новым сервисом автоматизация сработала с меньшими усилиями: всё завелось за пару дней и работает стабильно.

С Serverless‑сервисами в Yandex Cloud ситуация на момент разработки была неоднозначная. Идея красивая: платишь только за фактическое время работы. Но на практике всё оказалось сложнее. На тот момент формально очереди поддерживались, но собрать полноценную цепочку задач было сложно без эффективного оркестратора — получалось громоздко и хрупко. Я пробовал, общался с поддержкой и понял, что пока в продакшн это брать не готов. А оркестратор появился уже позже, в сервисе Workflows.

Есть и другая проблема: холодный старт. Serverless заметно прогревается в случае с Java, а в документации я к тому времени нашёл лишь обходные пути, которые только усложняли архитектуру. Поэтому я оставил этот вариант «на потом» — планировал использовать его для генерации PDF и другой графики, но пока удобнее держать очередь на своей виртуалке.

Обновления и инфраструктура

С точки зрения обновлений получилось достичь очень аккуратной архитектуры. Контейнеры я собираю локально, загружаю в Container Registry, где настроены lifecycle‑политики для удаления старых версий. Обновление автоматизировано: скрипт на Bash поочерёдно перезапускает контейнеры, а Nginx временно выводит хост из работы. Пользователь обновления не замечает.

Для безопасности я завёл несколько сервисных аккаунтов:

• основной — с доступом на запись в S3 и ключевые сервисы,

• read‑only — для безопасного чтения,

• отдельный — для работы с YandexGPT, SpeechKit и другими API.

Сейчас у меня около десятка ВМ, каждая отвечает за свою задачу. Есть специализированные worker‑машины для фоновых задач. Все они пока работают на пониженных мощностях (CPU 25–50%), чего хватает для отладки.

Планы на будущее

Мы прикинули: даже минимальная конфигурация продакшна (с собственным PostgreSQL) будет стоить порядка 30–40 тысяч рублей в месяц. Для нас это приемлемый уровень.

Вопрос с опенсорсом остаётся открытым. Всё, что связано с LUWRAIN — платформой для незрячих, — было и остаётся полностью свободным. А вот разработки, касающиеся научных публикаций, придётся делить: часть пойдёт в опенсорс, часть — закроем ради устойчивости проекта.

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

Итоги

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

Жизнь диктует свои темпы, и приходится делать многое параллельно, но главное — проект живёт и развивается.