ИИ в химии: история участия в хакатоне и рефлексия после

Всем привет! Меня зовут Константин Ушенин, я — ведущий научный ^[1] сотрудник в AIRI, занимаюсь приложениями искусственного интеллекта ^[2] в химии и фармакологии. В конце марта 2026 года мы с коллегами выиграли суточный хакатон от Сбера, ИТМО и СПБ ГБУ Молодёжного пространства «ПРОСТО» по созданию ИИ‑ассистента для планирования синтеза в лаборатории органической химии. Мероприятие прошло три месяца назад, однако мы завершили рефлексию результата только сейчас и решили сделать полный разбор.

В этом посте вы узнаете про этапы нашей подготовки, выработку ^[3] победной стратегии, решение проблем, возникавших по ходу соревнований, и наш подход к подготовке финальной презентации. В конце проведен анализ наших правильных и неправильных решений, а также дана оценка того, как реальное продуктовое решение должно отличаться от созданного на хакатоне.

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

В общем, получилось довольно остросюжетно, приятного чтения!

Начало истории

То, что ИТМО проводит хакатоны по актуальным технологиям, я знал очень давно, но не участвовал ни в одном из них. В начале марта 2026 года друзья скинули мне в личные сообщения ссылку на сайт хакатона ^[4], и оказалось, что это один из немногих конкурсов, в котором можно участвовать без жестких требований по возрасту и обучению ^[5] в вузе.

Хакатон разбит на кейсы и меня заинтересовал кейс № 4: мультиагентный ассистент химика‑органика для планирования синтеза в лаборатории. Далее цитирую сайт:

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

Требования: разработать архитектуру МАС и реализовать набор инструментов, позволяющих автоматизировать и связать ключевые этапы лабораторного цикла

Стек: LLM, LangGraph, LangChain, RAG

Требования к участникам: Для лиц от 14-35 лет.

К началу 2026 года я уже два года занимался близкими темами на работе, у меня были статьи в хороших журналах по хемоинформатике, а также свои оригинальные лекции по «ИИ в Химии» ^[6], которые я читал на интенсивах в Томском государственном университете. Решение участвовать и собирать команду стало очевидным.

Сбор команды

Я сразу же позвонил Артёму Голубеву — тимлиду компании BIOCAD, у которого был реальный опыт ^[7] внедрения ИИ‑технологий в процесс поиска и разработки лекарственных препаратов. Он также имел образование химика‑органика и по уровню технических навыков был фулл‑стеком.

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

Далее мы скинули информацию самым сильным в России специалистам по теме, которых знали. По разным причинам почти все отказались. Большинство не захотели ехать из Москвы или Казани в Санкт‑Петербург. На хакатоне отсутствовал денежный приз, по этой причине мероприятие не выглядело привлекательным для людей с уже реальным рабочим опытом. Тогда мы перешли на студентов и написали в чат студенческого семинара Михаила Медведева в Институт органической химии РАН (ИОХ РАН).

В итоге к нам присоединился Станислав Малашкеевич, который учится в МГУ, и сотрудник ИОХ РАН Степан Остарков. Последний позднее пригласил Всеволода Каримова из Сколтеха. Таким образом, к нам присоединились топовые студенты, у каждого из которых уже были научные статьи и какой‑то опыт создания ИИ-технологий. 

Я думаю, мы собрали самую лучшую из возможных команд, которую можно собрать под тему кейса за одну неделю. У нас получилось два чистых айтишника и три химика с опытом проведения экспериментов. Три студента, аффилированных с тремя разными организациями, а также тимлид и кандидат физ.‑мат. наук. Все участники умели программировать, вайб‑кодить, а также имели опыт научной работы по теме кейса. При этом команда была разнообразной по опыту и видению проблемы.

Подготовка

За неделю до поездки мы провели анализ ситуации и выявили основные риски, которые можно было предусмотреть заранее: 

• Мы не сможем коммуницировать — состав команды видел друг друга не более одного‑двух раз в жизни, и никто не знает, как работать вместе.

• У нас могут быть слишком разные подходы к вайб‑кодингу и созданию технологий.

• Состав команды не доедет, доедет не вовремя или приедет не выспавшимися.

• Члены команды не знают, как в целом как создавать AI‑first и AI‑native решения. Все видели за свою жизнь тысячи примеров сайтов, но единицы — мультиагентных систем.

В связи с этими пунктами было решено подготовиться к кейсу заранее и как можно лучше. Для этого мы провели две предварительные встречи. На первой встрече все познакомились друг с другом. Далее составили таблицу с ФИО, телефонами и параметрами поездки. Сразу же оказалось, что все пользуются разными системами. У нас оказалось две Windows, один Mac, одна Ubuntu и одна Manjaro. По вайб‑кодингу средства тоже не совпали, три участника пользовались чатом ChatGPT как есть, один Github Copilot и один Claude Code. В итоге мы приняли решение не переучиваться в последний момент и оставить наши инструменты на усмотрение членов команды. 

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

Я выслал новым коллегам свои лекции про «ИИ агентов в Химии» и выдал подборку статей. Все вместе мы составили большой список научных статей и технологий для ИИ‑ассистентов. Так как все участники команды работали и учились, то из списка мы реально посмотрели меньше 10%, но этого было достаточно. Мы заранее подняли ChemCrow и CACTUS — ИИ‑агентов для химии. Почти все попробовали LangChain и LangGraph заранее. 

Далее мы провели обсуждение и поняли, чем НЕ БУДЕМ заниматься. Задача MolelucalOCR (распознование молекулы по картинке) выглядела нереалистичной для реализации на хакатоне. Также все варианты мультимодальных агентов для распознавания спектров были отложены, потому что на бенчмарках у самых топовых LLM в этих задачах были ужасно низкие оценки. Среди нас не было ни одного специалиста по докингу, а на вычислительных ресурсах, которые принадлежат нам лично (а не нашим компаниям‑работодателям), невозможно сделать хорошее решение с квантово‑химическими расчетами. Оба направления потребовали бы хороших CPU‑серверов и реализации распределённой очереди задач на множестве серверов. К имплементации решения такой сложности мы были не готовы. Также мы запросили доступ к API у проекта OdanChem, который мог бы помочь с анализом спектров, но его авторы не успели принять решение об открытии API для нас до начала соревнований.

Очень быстро мы пришли к пониманию, что AI‑чат с инструментами — это самая простая и достижимая форма решения. Артём Голубев за несколько дней до хакатона сделал бойлерплейт, это не было запрещено правилами, и мы были уверены, что все остальные участники сделают тоже самое. Он взял популярный шаблон решения — Full Stack FastAPI Template. С помощью Claude Code в него был добавлен базовый чат. Однако, никакой дополнительной AI части до начала соревнований добавлено не было.

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

Мы подготовили общий чеклист поездки, которому все следовали:

Наш чеклист

Рекомендации от команды:

• паспорт (без него не пустят)

• ноутбук

• зарядка для ноутбука

• телефон

• зарядка для телефона

• наличные деньги

• способ общения при введённых ограничениях

Рекомендации пространства:

• паспорт (без него не пустят)

• набор канцелярии

• ноутбук и зарядка

• сменная одежда и спальный мешок

Куда ехать:

• набережная реки Карповки, 5АК, Санкт‑Петербург

• регистрация с 09:00 до 10:00. В 10:00 начало

Контакты ответственного:

+79XXXXXXXXX
+79XXXXXXXXX

Дополнительно перед поездкой мы закупили маски для сна ^[8] и беруши для всех участников, разные снеки и напитки для поддержания боевого духа ночью. Также были куплены два походных одеяла, для тех, у кого не было гостиницы или спальника.

Начало соревнования

Оказавшись на месте, мы осознали, что нам дали самый неудобный стол из возможных. Он находился на самом проходе, а не в закрытой комнате, и вокруг нас постоянно ходили толпы людей. Также стол был таким маленьким, что мы едва за него помещались и некоторые члены команды предпочли отсесть в отдельное место. Другая неприятность заключалась в том, что первоначальное расписание хакатона было сдвинуто. Фактически, вместо полутора суток на работу у нас осталось 24 часа до финальной оценки с момента окончания презентации организаторов.

В 10:00 мы получили финальное описание задачи и критерии оценивания:

Финальное описание задачи и критерии оценивания

Пайплайн — 20 баллов

Архитектура MAC и оркестрация — 20 баллов

Инструменты и интеграции — 20 баллов

Тестирование и сравнение — 15 баллов

Воспроизводимость и качество кода — 15 баллов

Презентация — 10 баллов

Обеспечение безопасности — 5 баллов

Тестирование системы — 5 баллов

Предлагаемые варианты решений от жюри:

• Агент структур и свойств

• Агент ретросинтеза

• Агент поиска методов

• Агент‑валидатор

• RAG‑агент по литературе

• Агент реагентов

Возможные функциональные блоки

• Генерация и отбор молекул

• Прогноз свойств

• Ретросинтез

• Поиск и сравнение методик

• Подбор реагентов и проверка доступности

• Прогнозы и анализ спектральных свойств

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

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

Выработка стратегии

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

Так как наш бойлерплейт работал с самого начала и был выложен в открытый доступ, то мы уже что‑то получали в оценках «Воспроизводимость и качество кода» и «Тестирование системы». Мы также были уверены, что справимся с презентацией, и я просто попросил всех в ходе работы делать красивые скрины работающих решений и присылать в общий чат. Очевидной стратегией для нас стало покрытие всех функциональных блоков, которые хочет жюри.

Жюри также явным образом хотело RAG. С самого начала нам было понятно, что с настоящим RAG для химии мы не справимся. RAG — это технология‑оборотень. В самом деле, для того чтобы сделать наивный RAG на 20–30 тестовых чанках текста, достаточно любого ИИ-помошника и 10 минут времени. Однако в ML считается, что что‑то реально работает только тогда, когда это бьёт метрики против базового решения. И тут начинаются проблемы… 

В сети очень много информации о химии, и LLM уже из коробки отвечают на вопросы про простой синтез, но при этом безбожно галлюцинируют на чём‑то сложном. С оффлайн частью RAG для химии тоже есть проблемы — огромная часть информации по химии не в статьях и патентах, а в учебниках и справочниках 1980-х годов на 300–600 страниц. Часть этой информации ещё и в картинках! Сама по себе постановка настолько большая, что команда из пяти человек для достижения минимального работающего решения должна была бы работать 40 часов, а не 24. 

В итоге мы решили, что сделаем Advanced RAG и покажем метрики хоть на чём‑нибудь. Если получится сделать реально хорошо — то хорошо, не получится — у нас будет решение близкое к SoTA и все необходимые тесты. Все члены команды с химическим образованием пообщались друг с другом и решили, что нужно сделать руками датасет по синтезу индолов. Для тестирования мы остановились на Ragas.

День первый. Бешеный темп

Как я уже отмечал ранее, с самого начала у нас был бойлерплейт, сделанный Артёмом на основе общедоступного шаблона. У прототипа было три функции: регистрация пользователя, форма чата и старт всех сервисов с Docker Compose. В качестве основного паттерна ИИ-технологии мы использовали одного агента с ReAct петлёй. Решением можно было пользоваться с самого начала, но оно не содержало в себе ничего химического. Примерно с такого же уровня можно было начать, используя ChainLit, Open WebUI или похожие простые решения для ИИ‑чатов.

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

В качестве ИИ‑решения мы использовали систему с одним агентом на основе фреймворков LangChain/LangGraph и локальные тулы, встроенные в эту систему. Вызовы происходили в том же легковесном потоке, в котором готовился ответ пользователю. Однако для реализации работы тулов мы поднимали REST API сервера с внутренними независимыми базами, то есть архитектура с самого начала была почти микросервисной. 

За первые два часа мы очень сильно увеличили возможности системы. Степан взял локальные тулы написанные на Langchain из ChemCrow и полностью перенёс их в наше решение используя кодинг-агента. Таким образом при минимальных усилиях произошло мощнейшее увеличение возможностей системы. В это же время Артём сделал инструмент для ретросинтеза. Он обернул AiZynthFinder в сервис и инструмент для ИИ‑агента. А Станислав добавил в интерфейс Ketcher — виджет с открытым исходным кодом для рисования молекул. 

Далее наступило время более оригинальных решений, адаптированных под химию. Станислав подготовил систему предупреждения об опасности веществ, взяв список ядов из отечественного законодательства. В этом списке есть хлороформ (CHCl₃), о котором, очевидно, знает любой член жюри. У него простая формула, и с его помощью легко демонстрировать систему предупреждения об опасности и рисках. Далее Станислав перевёл список в английские названия, подтянул сведения о токсичности и условиях работы с веществами, после чего обогатил этот список альтернативными номенклатурами и названиями веществ. В итоге в коде появился статический json, по которому искались все слова из чата. Если слово появлялось, мы выдавали предупреждения и условия работы с веществом. Это сделало наш чат специфичным под область «ИИ в химии».

В этот момент я сделал простой инструмент для ADMET (Absorption, Distribution, Metabolism, Excretion, and Toxicity) предсказаний. Кастомный код под RDKit был обёрнут условиями, это давало модели информацию про вещества и его базовые свойства. Далее я обернул такое решение в REST API сервис и подключал его как локальный инструмент LangСhain к ИИ‑агенту.

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

Далее мы захотели выбить побольше баллов по пунктам «Пайплайн», «Архитектура MAC и оркестрация», «Инструменты и интеграции». Одним из способов достичь этого было добавление мультимодальности к агентам и усложнение паттернов. Мы заранее договорились, что не обрабатываем картинки, и наша архитектура не соответствовала требованиям для внедрения таких изменений быстро. Однако мы могли генерировать и выводить картинки. Станислав добавил инструменты для генерации изображений и визуализации их на стороне клиента. Далее он добавил инструмент, который строил спектры ЯМР (ядерного магнитного резонанса) по веществу. 

Усложнением пайплайна для получения баллов по критерию «Пайплайн» занимался я. Самый сложный паттерн — это LLM Council. Помимо общего дерева ретросинтеза (привет AiZynthFinder) в химии также есть описание синтеза в виде списка действий: что с чем смешивать, при какой температуре, каком давлении и с каким катализатором. Мы передавали во многие LLM запросы про синтез веществ, они генерировали текстом протоколы синтеза, потом оценивали мнения друг-друга. Далее LLM‑председатель комбинировал ответы и выбирал лучшее. Первое решение было параллельным и работало очень‑очень долго. Я потратил значительное время чтобы переписать его под асинхронные обращения и обернуть в сервис.

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

Перед вторым чекпоинтом мы снова сильно увеличили мультимодальную часть агента и добавили элементы для получения баллов по критерию «Обеспечение безопасности». Станислав добавил гайрдрейл для защиты от опасных вопросов через библиотеку llm‑guard. В итоге наше решение стало частично защищено от простых и очевидных инъекций‑промптов. 

Примерно к этому же моменту Степан настроил наблюдаемость через LangFuse, в результате мы могли просматривать вызовы тулов и запросы к API LLM‑провайдера, что впоследствии пригодилось нам при изучении трейсов пользователей.

Параллельно какие‑то наработки по RAG появились у Всеволода. RAG сразу был в варианте Advanced RAG, с плотным поиском, разреженным поиском и реранкером. К Всеволоду подключился Степан, и вместе они сделали мини‑датасет на синтез индолов, который включал 40 вопросов.

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

День первый. Начало проблем

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

В итоги у нас появились паттерны слияния веток:

• Станислав → Артём 

• Степан → Артём 

• Константин → Станислав → Артём 

• Всеволод → Степан → Артём 

Как видите, в конце каждой цепочки стоял Артём Голубев. Артём сливал ветки кода и релизил решение на сервер каждые 30 минут. И это прекрасно работало с 11:00 утра до 11:00 вечера. Далее наше решение отказалось собираться и работать. Так как каждый делал свой docker‑compose файл и упаковывал своё решение в API endpoint, то к ночи у нас было около двенадцати контейнеров. Их порты и зависимости, естественно, начали конфликтовать и Claude Code не мог с этим справиться.

Ситуацию попытался спасти Степан, он подсел к Артёму, и они последний раз сделали релиз в 04:00. В этот момент стало понятно, что вся команда полностью мертвая и не может продолжать работать сегодня. Усиленно отрывая коллег от экранов, я убедил всех пойти спать.

День второй. Реальные пользователи и провал IT‑безопасности

Проснулись мы приблизительно в 07:00–08:00 и сразу же принялись доделывать решения. Артём в течении двух часов сделал публичный релиз на сервер с белым IP адресом. Станислав и Степан сразу же кинули ссылки по своим друзьям, а я — в общий чат хакатона. К нам одновременно зашли несколько десятков человек. Пиковое количество обращений к чату достигло 80 в минуту. После чего сервис с единственной точкой доступа к моделям начал ужасно тормозить и в логи FastAPI полетели отказы в обслуживании из‑за перегрузки сервера.

Зато теперь у нас теперь были настоящие трейсы пользователей. Пользователи начали спрашивать про области химии, в которых мы вообще ничего не понимали. После этого в личные сообщения начала прилетать обратная связь. Нам кидали скриншоты ошибок, плохих ответов и комментарии по поводу качества решения. Примерно 30% содержали ругательства. Но мы были не расстроены, это было прекрасно. Все материалы мы показали жюри, и всем было очевидно, что это действительно реальные люди, которые пользуются нашей системой (LLM‑ки так неграмотно и по‑злому не пишут;)

В этот же момент Всеволод и Степан довели RAG‑решение на своих машинах до рабочего состояния и прогнали Ragas первый раз на оригинальном датасете по синтезу индолов. Естественно, метрики никак не улучшились по сравнению с реально сильной топовой LLM. Однако теперь у нас было что‑то для демонстрации по критерию «Тестирование системы». Мы могли показать жюри, что мы пробовали и хотя бы теоретически сделали рабочую систему.

С таким решением мы пришли к третьему чекпоинту. Оставалась только финальная презентация.

Степан за час до защиты добавил загрузку статей из Semantic Scholar и их разбиение на чанки, которые далее хранились и доставались из базы по запросу. С этого момента RAG-решения и поиск в интернете (ограниченный) запускались из отдельных веток кода. И RAG, и поиск по статьям были оформлены как инструменты в LangChain, однако работало это только на личных машинах.

Далее у нас начались очень серьёзные проблемы с IT‑безопасностью решения. Так как решение было развернуто на публичном IP, и все знали где оно находится, то нас очень быстро «ломанули». Хакер зарегистрировался в системе и начал массово отправлять слово test в AI‑чат, возможно просто через команду curl в терминале. Так как это всё жило на моей подписке, деньги стали улетать со скоростью примерно 2000 рублей в час. Мы видели ID пользователя по трейсам в LangFuse и знали, что это происходит с одного аккаунта. Однако, у нас не было админки, и этот ID никак не сопоставлялся с пользователем в базе. Соответственно, мы не могли забанить конкретную регистрацию. Всё это произошло за 15 минут до начала защит, и в панике мы не смогли справиться с ситуацией.

День второй. Подготовка презентации и выступление

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

Шаблон презентации нам не выдали. Я загрузил логотип мероприятия в ИИ‑чат и попросили дать шаблон, включив максимальный режим рассуждений. Через 12 минут я получил какой‑то шаблон в хорошей цветовой схемой. Далее я выставил направляющие и переделал позиции блоков под стандарты презентаций AIRI. В отличие от многих других команд, мы не делали презентации в стиле «анонсов новых iPhone», а сфокусировались на чём-то, что ближе к консалтинговым презентациям. На каждом слайде мы привели чёткие аргументы, почему наше решение лучшее, и согласовали темы слайдов с назначаемыми баллами и ожиданиями жюри.

В итоге мы пришли на финальную презентацию со следующими материалами:

• Презентацией, сделанной в очень хорошем стиле, с выровненным контентом и вычитанным текстом.

• Полумёртвым сайтом, который лежал из‑за DOS атаки. Однако он работал какое‑то время и жюри им успело попользоваться на третьем чекпоинте. Также им реально пользовались люди, и жюри об этом тоже знало.

• Поднятыми решениями на персональных компьютерах, в которых был RAG и инструменты загрузки статей через Semantic Scholar.

• Результатами замеров через Ragas, а также кучей полуготовых блокнотов, которые мы не успели внедрить в решение, но которые видело жюри.

Мы отправляли презентацию последними, таким образом наше выступление стало последним в очереди. Выступления других команд длилось два часа, в течении которых Артём боролся за жизнеспособность развёрнутого решения, Степан доделывал RAG и онлайн‑поиск статей (через Semantic Scholar) на личной машине, а я запоминал каждое слово конкурентов чтобы неявно перебивать аргументы оппонентов в последнем выступлении. Сразу после выступления мы подошли к жюри и принесли работающее решение на личных ноутбуках к ним на стол, чтобы они могли опробовать сами.

Финал

В итоге — мы выступили, отбились от вопросов, и через 30 минут нас назвали победителями по кейсу № 4. Далее был финальный кофе‑брейк, фотосессия команд и интервью. От Сбера каждый из нас получил умную колонку Салют. Однако на самом деле приз был не в этом. 

В конце хакатона Региональный директор Сбера Андрей Власов в течении часа отвечал на наши вопросы по поводу ИИ‑агентов, ИИ‑решений, изменения рынка труда в РФ и мире, сдвигах в парадигмах программирования и методах менеджмента IT‑команд. Также он рассказал про бизнес-модели с участием агентов, архитектуры IT-решений и ещё много всего интересного.

В итоге, мы приехали за опытом и достигли поставленной цели по максимизации его получения. В особенности важный урок мы получили по теме IT‑безопасности))

Рефлексия по итогам хакатона

Сейчас, когда прошло три месяца, можно спокойно подвести итоги.

Что мы сделали правильно:

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

• Члены команды работали параллельно, и у нас не появлялось блокирующих задач. Разработка инструментов для агентов и создание REST API точек доступа (REST API endpoints) — это то, что очень хорошо параллелится на этап разработки и объединяется вместе.

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

• Мы с самого начала имели хороший базовый код (boilerplate) и быстро добавили LangFuse — решение для наблюдаемости (observability). Наблюдаемость — это критически важный элемент для любого проекта с LLM, даже самого маленького.

• Микросервисная архитектура (с оговорками по поводу очереди и полного разделения баз) — это хорошо. Так как каждый контейнер был в изолированном окружении, то, когда сайт лёг, мы хотя бы имели доступ к LangFuse и могли смотреть за состоянием системы и минимально расследовать инциденты. 

Что мы сделали НЕ правильно:

• Про IT‑безопасность нужно думать всегда и закладывать её во все части решения. Нужно было с самого начала иметь инфраструктуру для администратора и возможность бана пользователей, а также защиту от DOS и DDOS атак. Если вас можно поломать — вас поломают и сделают это таким способом, что вам потом будет стыдно:(

• Мы приняли решение использовать те системы и инструменты разработки, которые каждому удобны. Вероятно, мы могли бы сделать в 2–3 раза больше, если бы сразу писали в Claude Code или Cursor по спецификациям. Например, используя методологию AI‑Disrupt PDLC от Сбера ^[9]. Для этого достаточно было провести ещё одну предварительную встречу, раздать всем подписки и показать базовые подходы. То же самое можно сказать про железо и операционные системы. Windows 11 у одного из нас отказывался поддерживать Docker, что привело к значительной задержке между разработкой инструмента и тестированием его в реальной системе

• DevOps — это критически важная роль в современной разработке. На хакатоне это особенно видно, так как именно DevOps создаёт итоговое решение из наработок команды. Работа с конфигурациями требует большой концентрации внимания ^[10], которую невозможно сохранять более 12 часов. Правильным решением было бы выделить двух DevOps. Первый работал бы в первый день с начала хакатона в течении 8 часов, а потом во второй день с пробуждения и до защиты проекта. Второй DevOps мог бы работать в диапазоне 8 часов от начала и до конца первого дня. 

• Нужно было с самого начала делать очередь задач. Она уже есть в последнем стандарте для MCP-серверов. В нашем бойлерплейте была Celery, которую легко подключить к Redis. Это было бы полезно и для настоящей полноценной микросервисной архитектуры, и для долгих задач на вычисления, но мы не сделали этого.

• В любого ИИ‑агента с инструментами можно очень легко добавить систему лёгких скиллов (без кода, как commands в Cursor). Даже поддержка полноценного SKILLS.md формата и его загрузка на сервер — это не очень большая проблема, так как у нас не было инструментов, изменяющих внутреннее состояние системы и вызывающих bash. Поддержку скиллов стоило сделать, но мы не сделали.

Что правильно делали другие участники:

• У некоторых участников были намного более красивые визуальные дизайны решений. Контент в этих решениях строился на синтетических заглушках, но они выглядели очень хорошо.

• У некоторых участников были сильные решения с ретросинтезом. Они итеративно обходили дерево и передавали в LLM этапы синтеза, чтобы проверить исполнимость решения на практике. Такая концепция имеет много потенциальных возможностей.

• Было решение, подтверждённое реальным опытом химика‑синтетика. Привязка к реальному юзеру и логам настоящего использования в лаборатории даёт решению много очков в глазах жюри.

Что неправильно делали другие участники:

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

• Большинство команд вообще не готовилось к хакатону несмотря на то, что правилами это никак не ограничивалось. Даже если про тему хакатона неизвестно вообще ничего, то к нему стоит готовиться.

• Многие участники не спали ночью. В суточных хакатонах необходимо спать хотя бы четыре часа. Это дает сильное увеличение производительности на утро и позволяет быстрее доделывать решение в последний момент.

• Замена реальной работы на планирование. Это серьезная проблема команд, в которых только студенты без опыта работы. Они зачастую рисуют общие схемы и рассуждают о том, что и как должно работать. При этом за то же время уже можно было написать спецификацию в виде текста и передать кодинг‑агенту для получения результата.

• Выступление на защите проектов командой. Это всегда будет выглядеть плохо. Финальное решение должен представлять один, хорошо подготовленный и выделенный для этой роли человек. В случае затруднений при ответах на технические вопросы можно передать микрофон компетентным коллегам из команды.

Что должно быть в реальном продуктовом решении:

• В первую очередь нужен сервис для проксирования LLM‑запросов. Синхронное API не подходит для создания даже внутрикорпоративных сервисов, так как может выдержать десятки, но не сотни запросов. Нужны методы проксирования трафика и поддержания сессий для попадания в kv‑cache одного LLM‑провайдера. Так же нужны запасные точки доступа на случай отказа основных.

• Многие инструменты и сервисы, связанные с хемоинформатикой, обращаются в PubChem или ChEMBL. Таким образом, ответ инструментов ИИ‑агента зависит от внешних условий. Лучше данные от таких сервисов иметь внутри своего решения.

• Более правильная архитектура всплывающих виджетов, которая поддерживает мультимодальный ввод и вывод, например, для файлов и изображений. Очевидно, что любое серьёзное решение в виде ИИ‑помощника будет двигаться в сторону мультимодальных агентов при увеличении количества пользователей и увеличении их ожиданий от системы.

• У нас не было системы фильтрации набора инструментов под задачи пользователя, на самом деле, многие тулы вообще никогда не вызывались. А хоть что‑то работало из‑за того, что решение использовало самую сильную модель из возможных. Такой подход невозможен в реальном продукте. Фильтрация инструментов обязана быть частью реального продуктового решения.

Спасибо что дочитали до конца! Рекомендую всем участвовать в хакатоне ИТМО в следующем году.

GitHub решения: https://github.com/arqoofficial/itmo-chemcrow2 ^[11]