8134
правки
Изменения
Новая страница: «В понедельник 20.04 участвовал и выступал на [https://aiconf.ru/2026 AIconf] – конференция онтико по AI и M…»
В понедельник 20.04 участвовал и выступал на [https://aiconf.ru/2026 AIconf] – конференция онтико по AI и ML. Один день, 425 человек на площадке и 485 online в Технограде на ВДНХ, параллельно с Golang Conf.
Основное впечатление было получено на обсуждениях в кулуарах конференций – они общие. '''За полгода сформировалась общая оценка, что разработка с копилотами существенно поднимает эффективность''', мидл с копилотом делает существенно больше, чем без него, работает примерно как раньше сеньор, а на сеньоре остается архитектура. Позицию джуна не обсуждали.
При этом '''эффективность команд разработки поднялась настолько, что узким местом становятся продакты''': если раньше один продакт мог работать с несколькими командами, а некоторые команды жили без продакта, то теперь ограничение по обработке бэклога на нем. Это не значит, что бэклог опустел, он по-прежнему длинный и повышение производительности разработки в большинстве компаний не означает сокращений, однако продакт делал определенную работу по каждой задаче, и он не справляется.
В целом ничего удивительного, над эффективностью разработки с помощью копилотов много работали, а над повышением производительности продакта – нет. У него, конечно, тоже есть помощь от ИИ – он может использовать чат, но в этом вместе эффективность меньше. Впрочем, думаю, что с этим тоже справятся. Отмечу, что полгода назад, на обсуждениях в кулуарах Highload и Teamlead такого общего мнения не было, были разные эксперименты, у одних – более успешные, у других – менее, и было достаточно много скепсиса наряду с энтузиазмом. Теперь скепсис ушел.
Правда, это среди руководителей разработки и активно интересующихся технологиями – на конференции ходят они. Что касается основной массы разработчиков, то ситуация, как с любыми новыми технологиями, как в свое время была с теми же вики-системами вместо ворд: энтузиастов 10-15%, остальных надо драйвить. И если в компании до 150 человек, то драйв передается просто за счет того, что люди друг друга знают и активные объединяются, специальной организации не требуется, и достаточно поддерживать процесс, и то когда их разработчиков 1500 и более, то уже надо специально организовывать пилотные зоны и демонстрировать в них эффективность другим. Но технологии принципиально не отличаются.
'''Произошедшие изменения меняют требования к разработчикам: они должны уметь работать с копилотом'''. Правда, в описание компетенции это пока не преобразовано, выступлений на эту тему не было. И на других конференциях я тоже не слышал конкретизации. Впрочем, это – достаточно общая вещь про soft skill компетенции, что такое «хорошая коммуникация» тоже раскрывают редко.
Если же говорить про выступления, то там – аналогично другим конференциям: практиками делятся, ИИ-агентов технологично встраивают в пайплайн разработки. Кстати, может, это я с опозданием заметил, но в обсуждении процесса разработки workflow поменялся на pipeline, такое прорастание devops-терминологии. И еще, забегая вперед – для технологичной встройки в пайплайн уже недостаточно описать процесс с помощью доски, требуется более детализированное описание с помощью n8n или аналогичных инструментов. Но это впечатления уже следующей конференции, SQAdays, подробности будут в отчете с нее.
Еще в терминологии звучит «кожаные мешки» про людей, при этом ИИ «жестянкой с болтами» не называют. И это такое «мы», из которого говорящий себя исключает, он говорит про других, не про себя. Ну, примерно как в обсуждении общественных тем употребляют «быдло». Так что я бы такой слэнг явно возвращал говорящему как оценку и пусть подумает.
Еще из общих впечатлений: на конференции было два выступления про научные публикации. И есть впечатление, что этот жанр окончательно стал разновидностью масс-медиа. Научная значимость публикации определяется исключительно появлением на нее ссылок, ни о какой научной новизне или других характеристиках речи не идет. Что практически размывает границы науки до полной неопределенности. В принципе, в этом нет особой проблемы, если рассматривать науку просто как сообщество. Но это – сообщество, которое претендует на общественную полезность и, на этом основании, финансирование от государства, а вот судить предлагает именно на основании публикаций. На мой взгляд, получается не очень хорошо. Впрочем, доклады были не о месте науки, они лишь давали практические советы: что изменилось в подходе к публикациям, и как их сделать, если тебе хочется или нужно играть в игру научной значимости.
Ну а теперь про выступления. Презентации уже выложены на сайте, записи будут для участников и купивших видео.
== Максим Цепков. IT-ландшафт будущего: как китайские tech-гиганты и культура меняют мир ==
[https://aiconf.ru/2026/abstracts/17449 Выступление на сайте конференции]
Мое выступление [[IT-ландшафт будущего: как китайские tech-гиганты и культура меняют мир (AIconf-2026)|IT-ландшафт будущего: как китайские tech-гиганты и культура меняют мир]] было посвящено осмыслению опыта моей осенней поездки по китайским технологическим компаниям: Baidu, Xiaomi, Little Red Book, SenseTime и другим, и последующем осмыслению темы.
Фокус выступления был именно на корпоративную культуру и практики разработки, а также отношение к ИИ, которое в Китае сильно отличается от нашего. Там в инфополе отсутствует тема замены человека на ИИ и связанных с этим страхах, и разработчики тоже думают не о том, как заменить человека, а о том, как ему помочь, повысить его производительность. И, отмечу, такие задачи решать гораздо проще, чем полную замену, что позитивно влияет на скорость прогресса в целом. И возмущения глупостью LLM тоже нет: недостаточную сообразительность воспринимают как естественное в период обучения, и полагают, что роль человека как раз в том, чтобы поскорее научить ИИ, чтобы он мог лучше помогал людям. В общем, ИИ – партнер, а не конкурент. Подробности – на слайдах презентации и в других моих статьях. И в моей новой книге: я надеялся успеть выпустить ее к конференции, но не успел, выйдет в мае. А еще можно смотреть вебинар [[Влияние технологий на изменение мирового порядка и глобальную конкуренцию]], там, правда, меньше ИТ-фокуса, зато больше раскрыта тема развития мира в целом ходе технологических революций.
== Дарья Шатько. Как мы внедрили LLM-судей в автоматизациях клиентского сервиса: подход, грабли, уроки ==
[https://aiconf.ru/2026/abstracts/id10704551 Выступление на сайте конференции]
Дарья – из Yandex Crowd Solutions – поддержка Яндекса: 80+ сервисов, 4.5 млн обращений, 2700 операторов. Задачи ИИ – ботик, помощь оператору, агенты. И надо оценивать качество работы ИИ, для этого создан ИИ-судья, который оценивает качество. Не всех ответов, а выборочно, и его оценки сопоставляются с оценками экспертов, на которую отправляется 3-5% оценок судьи. То есть такая постоянная система мониторинга и оценки качества, нацеленная на выявление проблемных мест для дальнейшего улучшения. В выступлении – рассказ о настройке ИИ-судьи. Я бы отметил, что это не сильно отличается от настройки организационной системы для качественной поддержки, просто она теперь состоит не только из людей, которых мы обучаем, но и из LLM-агентов, которых мы настраиваем.
Контекст формируем через поиск по документной базе и обогащение контекста. С помощью агентов добавляем информацию о клиенте и его заказах.
Чатбот – понятная история. Flow: кнопка «чат с поддержкой» → сообщение в свободной форме → классификатор интента → (ответ | кнопки | уточнение) → (LLM-рефраз по шаблону | ответ RAG | ответ агента) → Вопрос решен? → (завершение | оператор)
Как замерять качество? Есть классические метрики бота: CSAT удовлетворенность пользователя (очень полезная, в ней разные сценарии), AR доля решений ботом (80%), возвращаемость – повторные обращения по той же причине, ART – время решения проблемы пользователя. Метрики – понятные, но соотношение CSAT и AR может быть любым и надо погружаться внутрь.
Способ – посмотреть на Flow и оценивать шаги.
* Первое – классификация интентов. Там есть свои метрики для классификаторов. Но есть вопрос: откуда брать ground truth – что было на самом деле. Для этого LLM может постфактум посмотреть диалог и провести классфикацию – сравнить и начальной.
* LLM перефразировала ответ по шаблону: насколько здорово она это сделала, насколько хорошо сработал промпт. Смотрят расстояние Левенштейна – был ли перефраз вообще. А если сработал – то насколько хорошо: тон ответа, учет контекста диалога и галлюцинации.
* Поиск о RAG: что-то нашли, насколько поиск был релевантным: точность, релевантность и полнота индекса, по которому поиск. Полнота очень важна, какая-то информация может просто отсутствовать в индексе, и ее никогда не найдут.
* Проверка ответа: good-middle-bad.
Для агента – тоже ответ, как RAG. А еще адекватность использования инструментов по trace: правильность выбора, хорошая работа самого инструмента (быстро и правильно выдал ответ) и эффективность шагов – у агента могут быть циклы, стоимость и скорость. А еще количество эскалаций агентом на человека и качество плана.
Итого, как устроить оценку качества? Нужны диалоги, данные и контекст клиента, историю обращений, маршрут клиента в диалоге и диалог с оператором.
Критерии хорошо-плохо. И разметка – ее может делать эксперт, но интересно, чтобы ее делала LLM, возможно – другая. Почему проверка той же самой LLM работает, если ответить она не смогла? потому что даем больше контекста, у нас есть полный диалог, и мы не ограничены временем ответа. А еще нам надо лишь оценить ответ, а не решить задачу.
Судья может сравнивать ответы – это на этапе настройки, пилоты и эксперименты. А в проде – оценка по критериям, потому что там нет правильного ответа. Но если решал оператор, то его ответ можно рассматривать как целевой.
Структура промта – есть статьи, где уже приведены шаблоны. Там задача, критерии и рассуждения про шаги, которые можно сгенерить. И если есть потоки – можно альтернативно взвешивать. Фреймворки Ragas, DeepEval, Langfuse – там много заготовок, можно от них стартовать. И там же подходы по логированию и интерфейсы. Это дает quick start.
Как подключать в прод? Количественные метрики – смотрим на дашборд. Проверка на судью – не 100%, а какая-то доля. И не весь диалог, а по кусочкам. И 3-5% из потока на судей идут на экспертный контроль качества для проверки и донастройки самого судьи.
Улучшение промпта. Качество смотрим по отношению к экспертной разметке, и сравниваем. Промпт-инжиниринг для судьи – как для обычных промптов. SGR пробовлаи, не помогло, а DSPy как библиотека улучшений – помог.
Калибровка. Смотрим распределение судьи и экспертов. Например, может оказаться, что судья более строгий, чем эксперты. И можно корректировать оценку качества от судьи статистически. Только надо учитывать, что экспертная оценка не всегда чистая, есть разногласия. Замечу, что это прикольно: не исправить судью, а откорректировать его оценку – как нормировка для ЕГЭ, и лично я смысла тут не вижу, уш лучше коридор доп3устимого честно менять.
Перефраз – оптимизация по DSPy – смотрим оценки судьи. И калибровка – таблички работы и пояснения, как с этим работать.
Кейс. Агент в поддержке промокодов – ответ на вопрос «почему я не получил бонус»? Как проверить агента? Вычитывают агента, и дальше закладываем в типы ошибок, чтобы был мониторинг. Но если много вычиток, то 10 вариантов – это 10 оценок, это тяжело. Вместо этого группируют критерии в граф, и идут по нему, проблемы ловят, не доходя до конца. Более того, часть проверок можно сделать rule based без LLM, вплоть до 9 из 10 на правилах.
Самая частая проблема при настройке судьи: мы подсунули диалог судье, сверяем с экспертами, но не учитываем, что эксперты имеют гораздо больше доступа к контексту, чем дали судье – они никогда не сойдутся.
Судья – это тоже часть автоматизации. У него есть стоимость. Для полноты ответа судье тоже хорошо бы подкинуть контекст, качество поиска – ограничение для агента. Надо держать разумную оценку. Если судью построили – его тоже на дашборд, мониторим сходимость с экспертами, она может разъехаться в любой момент.
Монетизации в мониторинге нет, но в углубленной аналитике они это смотрят, в том числе ответы судей учитывают.
Обновление промпта для судьи. Хотелось бы автомата: мы смотрим на ручеек от экспертов, и как разъезжается – запускаем докрутку. Однако, изменения чаще всего из-за изменений в продукте, о которых эксперты знают, а LLM почему-то нет. То есть надо не промпт усовершенствовать, а контекст увеличивать, тут другой процесс.
== Виктория Костерина. Разметка против реальности: как фрод выявляет слабые места датасета ==
Система контроля работы курьеров. В процессе выполнения заказов курьеры делают множество фото, по ним ИИ контролирует соблюдение ими правил работы: опознание самого курьера, выполнение требований по ношению формы и так далее. В целом – понятный процесс: есть оценка ИИ и выборочные проверки людьми, следят за сходимостью метрик, а когда они начинают расползаться – значит в модели какой-то провал, надо его выявить и дообучить модель.
Люди – изобретательны, форму просто накидывают, подставляют фото вместо реального лица, делают крупное фото 3d-модели артефакта крупным планом и так далее. При этом часто это уже есть в датасете, просто надо сначала с помощью ручной разметки и ML найти такие фото, затем на них дообучить модель, которая классифицирует поток фото от курьеров.
== Дана Миндзаева из Cloud.ru. ИИ в enterprise: на что вы тратите миллионы ==
Cloud.ru предоставляет облака, в том числе – для хостинга ИИ-агентов, и они совместно с Высшей школой бизнеса провели исследование об использовании ИИ. Опросили 100+ специалистов, провели 30 глубинных интервью и 15 анализов кейсов внедрения. Я бы сказал, что часть результатов – очевидные, а другие – не обоснованы. Что очевидно: 96% организаций планируют расширять внедрение ИИ, при этом 2/3 проектов остаются на стадии пилота. На мой взгляд, это – логично.
Из этого делают вывод, что ИИ-агенты на пике ожиданий, хотя обоснованность такого вывода сомнительна: вполне может быть, что до пика еще далеко. А то, что 2/3 проектов по новой экспериментальной технологии не выходят из стадии пилота – вообще нормально. Потому что проект по новой технологии – это же исследовательская штука, он далеко не всегда завершается успехом. То, что любой проект должен быть успешен – дурацкая идея, хотя и распространенная в корпоративной и государственной среде, не только российской.
То, что компании тратят на эти проекты миллионы, цифрами не подтверждено. Повышение производительности – показано, хотя и оговорено, что «с измерением есть трудности». В презентации – диапазоны, 10-45%, а среднюю цифру в 30% я слушал во множестве источников. При этом получается срок окупаемости в 5-7 лет и это – основание для закрытия проектов. У меня тут понятный вопрос: а что, такой срок был не очевиден для старта проекта? Потому что если 30% производительности дают 5 лет окупаемости, то что, были какие-то основания предполагать многократный рост? Или не учли какие-то очевидные вложения? Или об этом вообще не думали на старте, кто-то просто осваивал бюджет исследований?
О низком качестве проектов как таковых, и чистой работе по освоению бюджета говорит и то, что в ходе проекта вскрывалось низкое качество или отсутствие процессов или отсутствие данных. Это, конечно, может быть не очевидно на входе, но это надо проверять сразу и обычно для этого достаточно 1-2 дней работы аналитика, в крайнем случае – недели. Вряд ли в обследовании были проекты, которые закрыли через неделю работы одного человека, обычно такую штуку проектом не называют. Отмечу, что среди многочисленных проблем с проектами внедрения ИИ низкое качество самих проектов упомянуто не было.
Способы увеличить шансы на успех в презентации были, но они – очевидные и без каких-либо метрик и кейсов, которые бы говорили, в какой доле проектов именно они применялись и как повлияли. Среди них прикольно смотрится «поддержка руководства без ожидания окупаемости» – понятно, что если руководство просто согласно лить деньги без ожидания результата, то проект будет вечно успешен. Равно как и проблемы тоже перечислены без какой-либо статистики, а их формулировки напоминают типичные оправдания, потому что большинство таких причины можно было проверить на старте.
== Панель от хайпа к прибыли – встройка ИИ в продукт ==
Спикеры обсуждали практическое применение ИИ и вайбкодинг. Я делал заметки, и дальше – некоторое обобщение без авторства. Я его делаю для себя, чтобы выделить главное, уложить в свою картину. И наверняка там много интерпретаций.
ИИ – разнообразен и часть из него – давно известное и успешное, приносящее деньги: рекомендательные системы, классификация, облегчение генерации текстов, например, при подаче объявлений в авито, и так далее. С ними – понятно, и надо прагматично мерить эффект, что рекомендации реально помогают пользователю, а не превращаются в навязчивую рекламу, от которой он идет на другой сайт.
Другие – новые, например, быстро создать прототип вайбкодингом, и с ними тоже достаточно понятно: мы сокращаем время и стоимость проверки гипотезы. И в этой области происходит качественный переход: такой прототип или MVP может создать человек без технических скилов, раньше была нужна помощь разработчика или инфраструктура. И это меняет рынок, вместо того, чтобы приспосабливаться к ограничениям промышленных CRM и платить подписку, люди смогут использовать небольшие собственные решения или дорабатывать чужие.
Впрочем, я бы это рассматривал просто как очередной такт по снижению точки входа: раньше и для создания сайта нужна была помощь разработчика, а теперь люди сами справляются. Ну а теперь они еще будут создавать простую CRM или таск-трекер для своих конкретных задач. Или даже собственную систему обработки заказов – на панели был пример.
Принципиальная разница в том, что ты не должен менять процессы под коробку, а можешь сделать решение под свои процессы. И даже когда привлекаешь разработку, а не делаешь сам, стоимость снижается: «нужна система управления заказами» теперь не 20 бэков и 10 фронтов, а 2-3 разработчика для руководства агентами. Кстати, аналогичный кейс рассказывали на курглом столе по вайбкодингу на Merge: три года назад некоторую систему пришлось заказывать студии разработки, они делали год и до конца оно не взлетело, а осенью 2025 аналогичную систему на новых технологиях один разработчик сделал за пару месяцев с помощью вайбкодинга. Правда, система была аналогичной, то есть было представление о требуемом решении, менялась технология – это сильно упрощает задачу.
То, что написано с помощью вайбкодинга, можно развивать и поддерживать. Тут нужны технические скилы, но не для того, чтобы что-то сделать руками, а чтобы грамотно поставить задачу на вайбкодинг – чтобы было покрытие тестами, мониторинг, логирование, разворачивание продукта и так далее. ИИ это умеет, но ему надо грамотно ставить задачу. Так что это получается и без прямого участия человека в конкретном проекте, может быть платформа-настройка. Именно поэтому cloud не просто GPU сдают в аренду, а делают AI-factor.
Отмечу, что это тренд этого года Андрей Карапатый в 2025 придумал термин «вайбкодинг», а теперь говорит про agentic engineering.
При этом понятно, что так создавать будут относительно небольшие продукты, увязывая их скриптами, встраивая Excel или боты для взаимодействия с человеком, помимо простых форм и так далее. Такой следующий этап микросервисов, когда они не только в бэке, но и на фронте получаются. Это тоже меняет рынок.
При этом с вендорскими продуктами с этой точки зрения далеко не превосходно, многие из них не имеют обвязки, позволяющей их подключить к современным средствам мониторинга или развертывания, надо ковырять для этого дырочки, и это – недешево. Так что свежий вайбкодинг может быть и лучше старого legacy. Более того, ИИ хорошо анализируют легаси, есть кейсы, когда анализ нашел «несущие швабры», которые люди могли бы и пропустить.
Стоимость ИИ-разработки – разная, зависит от того, разворачиваешь ли на своем железе или арендуешь его в облаке, или арендуешь платишь за токены. В целом это аналогично расчету для инфраструктуры, которая тоже может быть своя или в облаке и с разной оплатой, просто там появились дополнительные развилки и новый вид расхода – токены для арендуемых моделей. За год стоимость токена упала в 50 раз.
И это – не только на этапе разработки, важно сводить стоимость при эксплуатации. Если ты встроил LLM в CJM и он что-то делает для клиента – дает ли это экономический эффект или просто дополнительную статью расходов для тебя? И бывает, что делаешь пилот на Gemini, вдохновляешься, а на простой модели фигня получается.
Я тут отмечу, что ИИ на минималках тоже работает, на ArchDays был доклад при использовании ИИ как части облачного решения для сайтов интернет-магазинов, и там прод обеспечивают 2 арендованных full time GPU с простыми моделями, которые учат с помощью Qwen и других более сложных, арендуя под них свободные мощности GPU по необходимости.
При этом качество моделей постоянно повышается, успешный пилот на топовых моделях может через полгода стать реальностью на простых.
Ответственность при использовании ИИ – на человеке. Когда встраиваем в продукт – фильтр информации, цензура адекватности, контроль данных пользователей, защита от промпт-инъекций. Претензии-то будут к продукту. А когда используешь копилот, то ответственность на разработчике, мало ли что он тебе посоветовал. Когда с помощью ИИ пишешь письма или презентации – тоже самое. Это не значит, что нельзя использовать, наоборот, используешь, потому что эффективно, но проверяешь с его же помощью. При этом только ты понимаешь, насколько качественно нужно проверять, или достаточно посмотреть по диагонали – собственно, как с драфтом, который написал новичок.
ИИ усиливает сотрудника и в плохом и хорошем. Тут интересная модель, сотрудников при работе со смыслами можно представить как призмы: рассеивающая, фокусирующая и прямая. И вот '''усиление ИИ рассеивания смыслов сотрудником приводит к тому, что сотрудник становится не пригоден''', реально с некоторыми пришлось расстаться. Раньше это не так проявлялось. К разработчикам появились дополнительные требования по взаимодействию ИИ, включая ответственность. Поэтому конверсия найма уменьшилась.
По проектам – разработчики побежали быстрее, а как ускорить всех. Генеративную часть – дизайн, код – ускорилась, а согласование с бизнесом или безопасность – нет, и надо перестраивать процессы. И меняются ожидания каждой роли, включая использование ИИ. ИИ является акселератором, тупых делает тупее, а умных – умнее. Есть проекты, которые делают без аналитика – руководителя с ИИ достаточно, есть продукты без дизайнера, вопрос тестирования не решен, и непонятно, больше их будет или меньше. Есть проекты, где вместо 5 – 2, и есть большие, где вместо 5+5+5 сидит 1+1+1.
Изменения идут очень быстро, сильно меняется норма и какой она станет – неизвестно. Однако, ИИ – интересно, и это драйвит людей, тут плюс. Вообще есть три аспекта организации: принуждение (нормы, регламенты), поощрение (культура, интересные задачи) и поддержка (менторство). Нужны все три, два дают ленивых котов или выжженное поле.
Полтора года назад поставили практику: если кто-то уходит, не открываем вакансию, а пробуем заместить ИИ. И еще ИИ – обязательно для роста, есть 2 часа в пятницу на ИИ. При этом HR – передовики, они больше кандидатов отсматривают.
'''Что будет самым важным изменением в 3-6 месяцев?''' Это кажется короткий срок, но смотришь, что было осенью, и понимаешь, что изменения велики.
* В отдельных отраслях наступит похолодание и разочарование – вложенные средства не дают отдачи. Но где-то он будет показывать эффект: кодинг с помощью ИИ качественно меняет эффективность. И еще в каких-то увидим изменения.
* В России не очень хорошо в экономике, и это будет идти. Сокращать будут тех, кто рассеивает. Можно попробовать использовать ИИ для удержания своего табурета.
* Токены – еще подешевеют, подтянутся открытые модели к фронтирным. Все будет обвешено агентами для решения рабочих и личных задач.<br />
* Увидим рост в продуктах, где ИИ направят на сокращение пользовательского пути. От «хочу сайт» до «есть сайт». А хочется – чтобы научились считать профит.
В командах интересные изменения: появился контекст-инженер, его задача – взаимодействие с бизнесом, а дальше он заказывает в разработке отдельные ручки, а результат собирает сам. Я бы лично назвал эту позицию аналитиком, и я помню времена, когда были мечты о полном конструировании приложения аналитиком или даже бизнесом в каком-6нибудь дизайнере. Недавно на той же волне пришел low-code/no-code, а сейчас получается следующая волна.
== Александр Панов. Жизнь научной статьи по ИИ: от идеи до A* ==
Александр – из института искусственного интеллекта AIRI. В выступлении – рассказ о том, как сейчас устроено написание статей. У него перавя статья была в 2002 на школьную конференцию про реальный эксперимент, потом – во время учебы в Новосибирске (2009), а с 2016 он кандидат, и уровень журналов и конференций, на которых он выступает, все время повышается. Основной тезис: можно активно публиковаться, если поставить это своей задачей и научиться это делать.
При этом понимать, что публикации влияют на твою репутацию как ученого, и как именно. Тут Александр говорил, что будущее науки определяют люди, которые выбирают путь серьезного исследования, а не быстрой публикации. Может, это и так, но у меня из выступления сложилось впечатление, что репутация в научном мире сейчас ничем не отличается от журналистов или писателей: большинство смотрят на список публикаций, и не читает дальше названия, иногда заглядывают в аннотацию, а читать дальше – большая редкость. И, кстати, ИИ тоже так делает.
Итак, рекомендации Александра.
* Есть типовая структура, ее надо придерживаться: постановка задачи, метод, результаты, выводы, будущая работа.
* Цель публикации: идеи для широкого круга и детали результатов для тех, кто разбирается, поэтому детали часто уносят в Приложения (и там часто фигня, которую даже рецензенты не смотрят) .
* Название суперважно. Даже абстракт не читают.
* '''Очень важна первая картинка''', это visual abstract, и она должна быть недалеко от начала.
* Our contribution в конце абстракта – три фразы, для людей, на них смотрят, принимая решение – читать или нет.<br />
* Аффиляция автора – указание места работы или учебы, оно важно с учетом нынешней ситуации, поэтому используют псевдонимы – как выступленяи под белым флагом.
* В начале хороший маленький кусочек про теорию – мы подумали. Но не слишком длинный, много думать – вредно, а читать – скучно.
* Псевдокод, если речь идет про разработку или что-то похожее.
* Эксперименты – подтверждает, что все проверили, с бенчами сравнились и так далее.
Как создавать? Конечно, с помощью ИИ.
* Сначала – генерация идей. Здесь ИИ ускоряет процесс. Агенты ускоряют, но не делают сами. И в малой группе делаем прототип статьи.
* LLM – есть сервисы, что не пропустили. Так все работают, сначала – спроси LLM, потом уже люди смотреть будут.
* Работа с коллегами – прожарка с внутренними. Пусть прорецензируют.
* Выложить препринт на arXiv – застолбить место. Там тоже проблемы с санкциями, но есть способы. В принципе, на препринт можно выкладывать любую фигню, сгенерированную LLM, так реально делают. На него не ссылаются, кроме случаев известных авторов или институтов. Но он уже индексируется и попадает в обзоры LLM, так что есть вероятность, что про тебя узнают.<br />
* Дальше подаем на workshop – это малые сессии на больших конференциях. Там ниже требования, и там будет обратная связь.
* Дальше – дорабатываем и полноценно на конференцию.
Отказ – обновили и отправили. Получили отказ на большую статью – сделали на ее основе маленькую демо-статью на другую конфу, там приняли. И параллельно можно доработать и запустить полную на еще одну конфу. Надо следить, чтобы пересечений не было. Одна из статей у них крутилась три года на 6 конференциях и была принята.
Рецензия: о чем статья, сильные стороны и слабые в большом количестве. На большинстве конференций есть возможность один раз ответить рецензенту, убедить, что конфетка. И есть сеньор рецензент – он пишет итоговое решение.
Цикл публикации – 9 месяцев.
'''Сейчас никто не говорит про новизну'''. Полезности для сообщества – достаточно. Если старую идею оформили так, что на нее ссылаются – этого достаточно.
Репозиторий с кодом и звездочки – важно. Страница проекта и статьи – обязательно, можно сделать инструментами. И можно сделать публикацию на habr или где-еще, популярным языком изложить сложные идеи – это не мешает.
Разница между конференциями и журналами. У конференции понятные сроки, ограниченный объем публикации, и надо обязательно приехать. Зато можно продвигать статью, чтобы цитировали через постеры и общение. Презентация на конференции – постер. 1.5 часа идет сессия постеров: авторы стоят у своих постеров и общаются. Так 90-95% выступлений. Есть еще доклады на 5 минут, мини-сессия, но туда мало проходят. У некоторых конференций есть демо-треки, туда вообще почти всех берут. Короткое видео некоторые требуют, но их никто не смотрит.
В журналах – большой объем (хотя сейчас ограничивают до 7 страниц), но сроки рецензирования не ограничены, до 2 лет. Зато возможна переработка, и ездить никуда не нужно.
'''AIscientist'''. Идея была 5 лет назад, тогда не взлетело. Сейчас китайцы не стесняются использовать LLM, есть целая линейка инструментов. Есть DeepReviwer – и он точно лучше человека. Есть полный цикл: DeepScientist и CycleResearcher. Без человека КПД – низкое, супер-идей они не создают. Но человеку – помогают. В презентации – список инструментов, которые они используют. В том числе генерация кода – ИИ пишет лучше студента. А презентация – notebookLLM.
Как у них устроен процесс? Есть семинары для генерации идей. ИИ-суммаризатор обсуждения и набор экспериментов – из него идет бэклог. Через неделю – обсуждаем, повторяем цикл.
Что будет в будущем? Он думает, что будет площадка обмена snippet-идеями, через которую общаются ИИ-агенты, чтобы отслеживать пересечения с другими исследователями, и можно кооперироваться. Насколько я понимаю, сейчас ArXiv и другие площадки препринтов можно примерно так рассматривать и использовать, просто пока никто не делает – предпочитают вариться в собственном соку в знакомой среде.
'''Вопрос'''. Как понять, что LLM сделала хороший обзор? Ответ. Это как с поиском: вы доверяете Google, что он поиск правильно выдал? Надо смотреть, читать, проверять.
== Андрей Гетманов из ИТМО. Как мы разработали и внедрили систему проверки кода в научных статьях и дипломных работах ==
Рассказ о попытке с помощью ИИ решить проблемы защиты проектов и дипломных работ, которые студенты на халяву – когда есть красивый отчет, за которым нет ни кода ни экспериментов. На формальное требование «приложить код или исходные данные» студенты отвечают столь же формально – кладут в репозиторий что-нибудь, что может не соответствовать содержанию диплома или отчета. И они попробовали решить задачу с помощью LLM, которой передается отчет и код: она выделяет главные тезисы из текста и пробует найти им соответствие в коде, а также проверяет текст и код на соответствие набору критериев.
В целом работа понятная, но до «разработали и внедрили» тут еще далеко. Пока получено, что на тестовых примерах, в качестве которых используются накопленные в архиве работы, LLM дает какие-то разумные результаты. Но, наверное, совсем фигню отсекает. Детали – в презентации и выступлении.
А мне тут не понятно следующее. В теории отсекать халяву – задача научного руководителя. Похоже практика такова, что они это реально игнорируют, и никаких санкций за это не получают, раз явление носит массовый характер. А если так, то LLM – не поможет. Ну, напряжет студентов побольше поработать генератором, чтобы получить более правдоподобный фейк. Отмечу, что саму работу по прорыве ведут в отрыве от научных руководителей. Было бы, наверное, логично, если бы именно они первыми использовали такие проверки, и не на дипломе, а гораздо раньше, на проектах. И не с целью отсечь фейки, а с целью повысить качество самих студенческих проектов, дать рекомендации. Но нет, с преподавателями группа не взаимодействует, и нацелена именно на контроль – что подтверждает мою гипотезу про саботаж.
{{wl-publish: 2026-04-27 13:59:04 +0300 | MaksTsepkov }}
Основное впечатление было получено на обсуждениях в кулуарах конференций – они общие. '''За полгода сформировалась общая оценка, что разработка с копилотами существенно поднимает эффективность''', мидл с копилотом делает существенно больше, чем без него, работает примерно как раньше сеньор, а на сеньоре остается архитектура. Позицию джуна не обсуждали.
При этом '''эффективность команд разработки поднялась настолько, что узким местом становятся продакты''': если раньше один продакт мог работать с несколькими командами, а некоторые команды жили без продакта, то теперь ограничение по обработке бэклога на нем. Это не значит, что бэклог опустел, он по-прежнему длинный и повышение производительности разработки в большинстве компаний не означает сокращений, однако продакт делал определенную работу по каждой задаче, и он не справляется.
В целом ничего удивительного, над эффективностью разработки с помощью копилотов много работали, а над повышением производительности продакта – нет. У него, конечно, тоже есть помощь от ИИ – он может использовать чат, но в этом вместе эффективность меньше. Впрочем, думаю, что с этим тоже справятся. Отмечу, что полгода назад, на обсуждениях в кулуарах Highload и Teamlead такого общего мнения не было, были разные эксперименты, у одних – более успешные, у других – менее, и было достаточно много скепсиса наряду с энтузиазмом. Теперь скепсис ушел.
Правда, это среди руководителей разработки и активно интересующихся технологиями – на конференции ходят они. Что касается основной массы разработчиков, то ситуация, как с любыми новыми технологиями, как в свое время была с теми же вики-системами вместо ворд: энтузиастов 10-15%, остальных надо драйвить. И если в компании до 150 человек, то драйв передается просто за счет того, что люди друг друга знают и активные объединяются, специальной организации не требуется, и достаточно поддерживать процесс, и то когда их разработчиков 1500 и более, то уже надо специально организовывать пилотные зоны и демонстрировать в них эффективность другим. Но технологии принципиально не отличаются.
'''Произошедшие изменения меняют требования к разработчикам: они должны уметь работать с копилотом'''. Правда, в описание компетенции это пока не преобразовано, выступлений на эту тему не было. И на других конференциях я тоже не слышал конкретизации. Впрочем, это – достаточно общая вещь про soft skill компетенции, что такое «хорошая коммуникация» тоже раскрывают редко.
Если же говорить про выступления, то там – аналогично другим конференциям: практиками делятся, ИИ-агентов технологично встраивают в пайплайн разработки. Кстати, может, это я с опозданием заметил, но в обсуждении процесса разработки workflow поменялся на pipeline, такое прорастание devops-терминологии. И еще, забегая вперед – для технологичной встройки в пайплайн уже недостаточно описать процесс с помощью доски, требуется более детализированное описание с помощью n8n или аналогичных инструментов. Но это впечатления уже следующей конференции, SQAdays, подробности будут в отчете с нее.
Еще в терминологии звучит «кожаные мешки» про людей, при этом ИИ «жестянкой с болтами» не называют. И это такое «мы», из которого говорящий себя исключает, он говорит про других, не про себя. Ну, примерно как в обсуждении общественных тем употребляют «быдло». Так что я бы такой слэнг явно возвращал говорящему как оценку и пусть подумает.
Еще из общих впечатлений: на конференции было два выступления про научные публикации. И есть впечатление, что этот жанр окончательно стал разновидностью масс-медиа. Научная значимость публикации определяется исключительно появлением на нее ссылок, ни о какой научной новизне или других характеристиках речи не идет. Что практически размывает границы науки до полной неопределенности. В принципе, в этом нет особой проблемы, если рассматривать науку просто как сообщество. Но это – сообщество, которое претендует на общественную полезность и, на этом основании, финансирование от государства, а вот судить предлагает именно на основании публикаций. На мой взгляд, получается не очень хорошо. Впрочем, доклады были не о месте науки, они лишь давали практические советы: что изменилось в подходе к публикациям, и как их сделать, если тебе хочется или нужно играть в игру научной значимости.
Ну а теперь про выступления. Презентации уже выложены на сайте, записи будут для участников и купивших видео.
== Максим Цепков. IT-ландшафт будущего: как китайские tech-гиганты и культура меняют мир ==
[https://aiconf.ru/2026/abstracts/17449 Выступление на сайте конференции]
Мое выступление [[IT-ландшафт будущего: как китайские tech-гиганты и культура меняют мир (AIconf-2026)|IT-ландшафт будущего: как китайские tech-гиганты и культура меняют мир]] было посвящено осмыслению опыта моей осенней поездки по китайским технологическим компаниям: Baidu, Xiaomi, Little Red Book, SenseTime и другим, и последующем осмыслению темы.
Фокус выступления был именно на корпоративную культуру и практики разработки, а также отношение к ИИ, которое в Китае сильно отличается от нашего. Там в инфополе отсутствует тема замены человека на ИИ и связанных с этим страхах, и разработчики тоже думают не о том, как заменить человека, а о том, как ему помочь, повысить его производительность. И, отмечу, такие задачи решать гораздо проще, чем полную замену, что позитивно влияет на скорость прогресса в целом. И возмущения глупостью LLM тоже нет: недостаточную сообразительность воспринимают как естественное в период обучения, и полагают, что роль человека как раз в том, чтобы поскорее научить ИИ, чтобы он мог лучше помогал людям. В общем, ИИ – партнер, а не конкурент. Подробности – на слайдах презентации и в других моих статьях. И в моей новой книге: я надеялся успеть выпустить ее к конференции, но не успел, выйдет в мае. А еще можно смотреть вебинар [[Влияние технологий на изменение мирового порядка и глобальную конкуренцию]], там, правда, меньше ИТ-фокуса, зато больше раскрыта тема развития мира в целом ходе технологических революций.
== Дарья Шатько. Как мы внедрили LLM-судей в автоматизациях клиентского сервиса: подход, грабли, уроки ==
[https://aiconf.ru/2026/abstracts/id10704551 Выступление на сайте конференции]
Дарья – из Yandex Crowd Solutions – поддержка Яндекса: 80+ сервисов, 4.5 млн обращений, 2700 операторов. Задачи ИИ – ботик, помощь оператору, агенты. И надо оценивать качество работы ИИ, для этого создан ИИ-судья, который оценивает качество. Не всех ответов, а выборочно, и его оценки сопоставляются с оценками экспертов, на которую отправляется 3-5% оценок судьи. То есть такая постоянная система мониторинга и оценки качества, нацеленная на выявление проблемных мест для дальнейшего улучшения. В выступлении – рассказ о настройке ИИ-судьи. Я бы отметил, что это не сильно отличается от настройки организационной системы для качественной поддержки, просто она теперь состоит не только из людей, которых мы обучаем, но и из LLM-агентов, которых мы настраиваем.
Контекст формируем через поиск по документной базе и обогащение контекста. С помощью агентов добавляем информацию о клиенте и его заказах.
Чатбот – понятная история. Flow: кнопка «чат с поддержкой» → сообщение в свободной форме → классификатор интента → (ответ | кнопки | уточнение) → (LLM-рефраз по шаблону | ответ RAG | ответ агента) → Вопрос решен? → (завершение | оператор)
Как замерять качество? Есть классические метрики бота: CSAT удовлетворенность пользователя (очень полезная, в ней разные сценарии), AR доля решений ботом (80%), возвращаемость – повторные обращения по той же причине, ART – время решения проблемы пользователя. Метрики – понятные, но соотношение CSAT и AR может быть любым и надо погружаться внутрь.
Способ – посмотреть на Flow и оценивать шаги.
* Первое – классификация интентов. Там есть свои метрики для классификаторов. Но есть вопрос: откуда брать ground truth – что было на самом деле. Для этого LLM может постфактум посмотреть диалог и провести классфикацию – сравнить и начальной.
* LLM перефразировала ответ по шаблону: насколько здорово она это сделала, насколько хорошо сработал промпт. Смотрят расстояние Левенштейна – был ли перефраз вообще. А если сработал – то насколько хорошо: тон ответа, учет контекста диалога и галлюцинации.
* Поиск о RAG: что-то нашли, насколько поиск был релевантным: точность, релевантность и полнота индекса, по которому поиск. Полнота очень важна, какая-то информация может просто отсутствовать в индексе, и ее никогда не найдут.
* Проверка ответа: good-middle-bad.
Для агента – тоже ответ, как RAG. А еще адекватность использования инструментов по trace: правильность выбора, хорошая работа самого инструмента (быстро и правильно выдал ответ) и эффективность шагов – у агента могут быть циклы, стоимость и скорость. А еще количество эскалаций агентом на человека и качество плана.
Итого, как устроить оценку качества? Нужны диалоги, данные и контекст клиента, историю обращений, маршрут клиента в диалоге и диалог с оператором.
Критерии хорошо-плохо. И разметка – ее может делать эксперт, но интересно, чтобы ее делала LLM, возможно – другая. Почему проверка той же самой LLM работает, если ответить она не смогла? потому что даем больше контекста, у нас есть полный диалог, и мы не ограничены временем ответа. А еще нам надо лишь оценить ответ, а не решить задачу.
Судья может сравнивать ответы – это на этапе настройки, пилоты и эксперименты. А в проде – оценка по критериям, потому что там нет правильного ответа. Но если решал оператор, то его ответ можно рассматривать как целевой.
Структура промта – есть статьи, где уже приведены шаблоны. Там задача, критерии и рассуждения про шаги, которые можно сгенерить. И если есть потоки – можно альтернативно взвешивать. Фреймворки Ragas, DeepEval, Langfuse – там много заготовок, можно от них стартовать. И там же подходы по логированию и интерфейсы. Это дает quick start.
Как подключать в прод? Количественные метрики – смотрим на дашборд. Проверка на судью – не 100%, а какая-то доля. И не весь диалог, а по кусочкам. И 3-5% из потока на судей идут на экспертный контроль качества для проверки и донастройки самого судьи.
Улучшение промпта. Качество смотрим по отношению к экспертной разметке, и сравниваем. Промпт-инжиниринг для судьи – как для обычных промптов. SGR пробовлаи, не помогло, а DSPy как библиотека улучшений – помог.
Калибровка. Смотрим распределение судьи и экспертов. Например, может оказаться, что судья более строгий, чем эксперты. И можно корректировать оценку качества от судьи статистически. Только надо учитывать, что экспертная оценка не всегда чистая, есть разногласия. Замечу, что это прикольно: не исправить судью, а откорректировать его оценку – как нормировка для ЕГЭ, и лично я смысла тут не вижу, уш лучше коридор доп3устимого честно менять.
Перефраз – оптимизация по DSPy – смотрим оценки судьи. И калибровка – таблички работы и пояснения, как с этим работать.
Кейс. Агент в поддержке промокодов – ответ на вопрос «почему я не получил бонус»? Как проверить агента? Вычитывают агента, и дальше закладываем в типы ошибок, чтобы был мониторинг. Но если много вычиток, то 10 вариантов – это 10 оценок, это тяжело. Вместо этого группируют критерии в граф, и идут по нему, проблемы ловят, не доходя до конца. Более того, часть проверок можно сделать rule based без LLM, вплоть до 9 из 10 на правилах.
Самая частая проблема при настройке судьи: мы подсунули диалог судье, сверяем с экспертами, но не учитываем, что эксперты имеют гораздо больше доступа к контексту, чем дали судье – они никогда не сойдутся.
Судья – это тоже часть автоматизации. У него есть стоимость. Для полноты ответа судье тоже хорошо бы подкинуть контекст, качество поиска – ограничение для агента. Надо держать разумную оценку. Если судью построили – его тоже на дашборд, мониторим сходимость с экспертами, она может разъехаться в любой момент.
Монетизации в мониторинге нет, но в углубленной аналитике они это смотрят, в том числе ответы судей учитывают.
Обновление промпта для судьи. Хотелось бы автомата: мы смотрим на ручеек от экспертов, и как разъезжается – запускаем докрутку. Однако, изменения чаще всего из-за изменений в продукте, о которых эксперты знают, а LLM почему-то нет. То есть надо не промпт усовершенствовать, а контекст увеличивать, тут другой процесс.
== Виктория Костерина. Разметка против реальности: как фрод выявляет слабые места датасета ==
Система контроля работы курьеров. В процессе выполнения заказов курьеры делают множество фото, по ним ИИ контролирует соблюдение ими правил работы: опознание самого курьера, выполнение требований по ношению формы и так далее. В целом – понятный процесс: есть оценка ИИ и выборочные проверки людьми, следят за сходимостью метрик, а когда они начинают расползаться – значит в модели какой-то провал, надо его выявить и дообучить модель.
Люди – изобретательны, форму просто накидывают, подставляют фото вместо реального лица, делают крупное фото 3d-модели артефакта крупным планом и так далее. При этом часто это уже есть в датасете, просто надо сначала с помощью ручной разметки и ML найти такие фото, затем на них дообучить модель, которая классифицирует поток фото от курьеров.
== Дана Миндзаева из Cloud.ru. ИИ в enterprise: на что вы тратите миллионы ==
Cloud.ru предоставляет облака, в том числе – для хостинга ИИ-агентов, и они совместно с Высшей школой бизнеса провели исследование об использовании ИИ. Опросили 100+ специалистов, провели 30 глубинных интервью и 15 анализов кейсов внедрения. Я бы сказал, что часть результатов – очевидные, а другие – не обоснованы. Что очевидно: 96% организаций планируют расширять внедрение ИИ, при этом 2/3 проектов остаются на стадии пилота. На мой взгляд, это – логично.
Из этого делают вывод, что ИИ-агенты на пике ожиданий, хотя обоснованность такого вывода сомнительна: вполне может быть, что до пика еще далеко. А то, что 2/3 проектов по новой экспериментальной технологии не выходят из стадии пилота – вообще нормально. Потому что проект по новой технологии – это же исследовательская штука, он далеко не всегда завершается успехом. То, что любой проект должен быть успешен – дурацкая идея, хотя и распространенная в корпоративной и государственной среде, не только российской.
То, что компании тратят на эти проекты миллионы, цифрами не подтверждено. Повышение производительности – показано, хотя и оговорено, что «с измерением есть трудности». В презентации – диапазоны, 10-45%, а среднюю цифру в 30% я слушал во множестве источников. При этом получается срок окупаемости в 5-7 лет и это – основание для закрытия проектов. У меня тут понятный вопрос: а что, такой срок был не очевиден для старта проекта? Потому что если 30% производительности дают 5 лет окупаемости, то что, были какие-то основания предполагать многократный рост? Или не учли какие-то очевидные вложения? Или об этом вообще не думали на старте, кто-то просто осваивал бюджет исследований?
О низком качестве проектов как таковых, и чистой работе по освоению бюджета говорит и то, что в ходе проекта вскрывалось низкое качество или отсутствие процессов или отсутствие данных. Это, конечно, может быть не очевидно на входе, но это надо проверять сразу и обычно для этого достаточно 1-2 дней работы аналитика, в крайнем случае – недели. Вряд ли в обследовании были проекты, которые закрыли через неделю работы одного человека, обычно такую штуку проектом не называют. Отмечу, что среди многочисленных проблем с проектами внедрения ИИ низкое качество самих проектов упомянуто не было.
Способы увеличить шансы на успех в презентации были, но они – очевидные и без каких-либо метрик и кейсов, которые бы говорили, в какой доле проектов именно они применялись и как повлияли. Среди них прикольно смотрится «поддержка руководства без ожидания окупаемости» – понятно, что если руководство просто согласно лить деньги без ожидания результата, то проект будет вечно успешен. Равно как и проблемы тоже перечислены без какой-либо статистики, а их формулировки напоминают типичные оправдания, потому что большинство таких причины можно было проверить на старте.
== Панель от хайпа к прибыли – встройка ИИ в продукт ==
Спикеры обсуждали практическое применение ИИ и вайбкодинг. Я делал заметки, и дальше – некоторое обобщение без авторства. Я его делаю для себя, чтобы выделить главное, уложить в свою картину. И наверняка там много интерпретаций.
ИИ – разнообразен и часть из него – давно известное и успешное, приносящее деньги: рекомендательные системы, классификация, облегчение генерации текстов, например, при подаче объявлений в авито, и так далее. С ними – понятно, и надо прагматично мерить эффект, что рекомендации реально помогают пользователю, а не превращаются в навязчивую рекламу, от которой он идет на другой сайт.
Другие – новые, например, быстро создать прототип вайбкодингом, и с ними тоже достаточно понятно: мы сокращаем время и стоимость проверки гипотезы. И в этой области происходит качественный переход: такой прототип или MVP может создать человек без технических скилов, раньше была нужна помощь разработчика или инфраструктура. И это меняет рынок, вместо того, чтобы приспосабливаться к ограничениям промышленных CRM и платить подписку, люди смогут использовать небольшие собственные решения или дорабатывать чужие.
Впрочем, я бы это рассматривал просто как очередной такт по снижению точки входа: раньше и для создания сайта нужна была помощь разработчика, а теперь люди сами справляются. Ну а теперь они еще будут создавать простую CRM или таск-трекер для своих конкретных задач. Или даже собственную систему обработки заказов – на панели был пример.
Принципиальная разница в том, что ты не должен менять процессы под коробку, а можешь сделать решение под свои процессы. И даже когда привлекаешь разработку, а не делаешь сам, стоимость снижается: «нужна система управления заказами» теперь не 20 бэков и 10 фронтов, а 2-3 разработчика для руководства агентами. Кстати, аналогичный кейс рассказывали на курглом столе по вайбкодингу на Merge: три года назад некоторую систему пришлось заказывать студии разработки, они делали год и до конца оно не взлетело, а осенью 2025 аналогичную систему на новых технологиях один разработчик сделал за пару месяцев с помощью вайбкодинга. Правда, система была аналогичной, то есть было представление о требуемом решении, менялась технология – это сильно упрощает задачу.
То, что написано с помощью вайбкодинга, можно развивать и поддерживать. Тут нужны технические скилы, но не для того, чтобы что-то сделать руками, а чтобы грамотно поставить задачу на вайбкодинг – чтобы было покрытие тестами, мониторинг, логирование, разворачивание продукта и так далее. ИИ это умеет, но ему надо грамотно ставить задачу. Так что это получается и без прямого участия человека в конкретном проекте, может быть платформа-настройка. Именно поэтому cloud не просто GPU сдают в аренду, а делают AI-factor.
Отмечу, что это тренд этого года Андрей Карапатый в 2025 придумал термин «вайбкодинг», а теперь говорит про agentic engineering.
При этом понятно, что так создавать будут относительно небольшие продукты, увязывая их скриптами, встраивая Excel или боты для взаимодействия с человеком, помимо простых форм и так далее. Такой следующий этап микросервисов, когда они не только в бэке, но и на фронте получаются. Это тоже меняет рынок.
При этом с вендорскими продуктами с этой точки зрения далеко не превосходно, многие из них не имеют обвязки, позволяющей их подключить к современным средствам мониторинга или развертывания, надо ковырять для этого дырочки, и это – недешево. Так что свежий вайбкодинг может быть и лучше старого legacy. Более того, ИИ хорошо анализируют легаси, есть кейсы, когда анализ нашел «несущие швабры», которые люди могли бы и пропустить.
Стоимость ИИ-разработки – разная, зависит от того, разворачиваешь ли на своем железе или арендуешь его в облаке, или арендуешь платишь за токены. В целом это аналогично расчету для инфраструктуры, которая тоже может быть своя или в облаке и с разной оплатой, просто там появились дополнительные развилки и новый вид расхода – токены для арендуемых моделей. За год стоимость токена упала в 50 раз.
И это – не только на этапе разработки, важно сводить стоимость при эксплуатации. Если ты встроил LLM в CJM и он что-то делает для клиента – дает ли это экономический эффект или просто дополнительную статью расходов для тебя? И бывает, что делаешь пилот на Gemini, вдохновляешься, а на простой модели фигня получается.
Я тут отмечу, что ИИ на минималках тоже работает, на ArchDays был доклад при использовании ИИ как части облачного решения для сайтов интернет-магазинов, и там прод обеспечивают 2 арендованных full time GPU с простыми моделями, которые учат с помощью Qwen и других более сложных, арендуя под них свободные мощности GPU по необходимости.
При этом качество моделей постоянно повышается, успешный пилот на топовых моделях может через полгода стать реальностью на простых.
Ответственность при использовании ИИ – на человеке. Когда встраиваем в продукт – фильтр информации, цензура адекватности, контроль данных пользователей, защита от промпт-инъекций. Претензии-то будут к продукту. А когда используешь копилот, то ответственность на разработчике, мало ли что он тебе посоветовал. Когда с помощью ИИ пишешь письма или презентации – тоже самое. Это не значит, что нельзя использовать, наоборот, используешь, потому что эффективно, но проверяешь с его же помощью. При этом только ты понимаешь, насколько качественно нужно проверять, или достаточно посмотреть по диагонали – собственно, как с драфтом, который написал новичок.
ИИ усиливает сотрудника и в плохом и хорошем. Тут интересная модель, сотрудников при работе со смыслами можно представить как призмы: рассеивающая, фокусирующая и прямая. И вот '''усиление ИИ рассеивания смыслов сотрудником приводит к тому, что сотрудник становится не пригоден''', реально с некоторыми пришлось расстаться. Раньше это не так проявлялось. К разработчикам появились дополнительные требования по взаимодействию ИИ, включая ответственность. Поэтому конверсия найма уменьшилась.
По проектам – разработчики побежали быстрее, а как ускорить всех. Генеративную часть – дизайн, код – ускорилась, а согласование с бизнесом или безопасность – нет, и надо перестраивать процессы. И меняются ожидания каждой роли, включая использование ИИ. ИИ является акселератором, тупых делает тупее, а умных – умнее. Есть проекты, которые делают без аналитика – руководителя с ИИ достаточно, есть продукты без дизайнера, вопрос тестирования не решен, и непонятно, больше их будет или меньше. Есть проекты, где вместо 5 – 2, и есть большие, где вместо 5+5+5 сидит 1+1+1.
Изменения идут очень быстро, сильно меняется норма и какой она станет – неизвестно. Однако, ИИ – интересно, и это драйвит людей, тут плюс. Вообще есть три аспекта организации: принуждение (нормы, регламенты), поощрение (культура, интересные задачи) и поддержка (менторство). Нужны все три, два дают ленивых котов или выжженное поле.
Полтора года назад поставили практику: если кто-то уходит, не открываем вакансию, а пробуем заместить ИИ. И еще ИИ – обязательно для роста, есть 2 часа в пятницу на ИИ. При этом HR – передовики, они больше кандидатов отсматривают.
'''Что будет самым важным изменением в 3-6 месяцев?''' Это кажется короткий срок, но смотришь, что было осенью, и понимаешь, что изменения велики.
* В отдельных отраслях наступит похолодание и разочарование – вложенные средства не дают отдачи. Но где-то он будет показывать эффект: кодинг с помощью ИИ качественно меняет эффективность. И еще в каких-то увидим изменения.
* В России не очень хорошо в экономике, и это будет идти. Сокращать будут тех, кто рассеивает. Можно попробовать использовать ИИ для удержания своего табурета.
* Токены – еще подешевеют, подтянутся открытые модели к фронтирным. Все будет обвешено агентами для решения рабочих и личных задач.<br />
* Увидим рост в продуктах, где ИИ направят на сокращение пользовательского пути. От «хочу сайт» до «есть сайт». А хочется – чтобы научились считать профит.
В командах интересные изменения: появился контекст-инженер, его задача – взаимодействие с бизнесом, а дальше он заказывает в разработке отдельные ручки, а результат собирает сам. Я бы лично назвал эту позицию аналитиком, и я помню времена, когда были мечты о полном конструировании приложения аналитиком или даже бизнесом в каком-6нибудь дизайнере. Недавно на той же волне пришел low-code/no-code, а сейчас получается следующая волна.
== Александр Панов. Жизнь научной статьи по ИИ: от идеи до A* ==
Александр – из института искусственного интеллекта AIRI. В выступлении – рассказ о том, как сейчас устроено написание статей. У него перавя статья была в 2002 на школьную конференцию про реальный эксперимент, потом – во время учебы в Новосибирске (2009), а с 2016 он кандидат, и уровень журналов и конференций, на которых он выступает, все время повышается. Основной тезис: можно активно публиковаться, если поставить это своей задачей и научиться это делать.
При этом понимать, что публикации влияют на твою репутацию как ученого, и как именно. Тут Александр говорил, что будущее науки определяют люди, которые выбирают путь серьезного исследования, а не быстрой публикации. Может, это и так, но у меня из выступления сложилось впечатление, что репутация в научном мире сейчас ничем не отличается от журналистов или писателей: большинство смотрят на список публикаций, и не читает дальше названия, иногда заглядывают в аннотацию, а читать дальше – большая редкость. И, кстати, ИИ тоже так делает.
Итак, рекомендации Александра.
* Есть типовая структура, ее надо придерживаться: постановка задачи, метод, результаты, выводы, будущая работа.
* Цель публикации: идеи для широкого круга и детали результатов для тех, кто разбирается, поэтому детали часто уносят в Приложения (и там часто фигня, которую даже рецензенты не смотрят) .
* Название суперважно. Даже абстракт не читают.
* '''Очень важна первая картинка''', это visual abstract, и она должна быть недалеко от начала.
* Our contribution в конце абстракта – три фразы, для людей, на них смотрят, принимая решение – читать или нет.<br />
* Аффиляция автора – указание места работы или учебы, оно важно с учетом нынешней ситуации, поэтому используют псевдонимы – как выступленяи под белым флагом.
* В начале хороший маленький кусочек про теорию – мы подумали. Но не слишком длинный, много думать – вредно, а читать – скучно.
* Псевдокод, если речь идет про разработку или что-то похожее.
* Эксперименты – подтверждает, что все проверили, с бенчами сравнились и так далее.
Как создавать? Конечно, с помощью ИИ.
* Сначала – генерация идей. Здесь ИИ ускоряет процесс. Агенты ускоряют, но не делают сами. И в малой группе делаем прототип статьи.
* LLM – есть сервисы, что не пропустили. Так все работают, сначала – спроси LLM, потом уже люди смотреть будут.
* Работа с коллегами – прожарка с внутренними. Пусть прорецензируют.
* Выложить препринт на arXiv – застолбить место. Там тоже проблемы с санкциями, но есть способы. В принципе, на препринт можно выкладывать любую фигню, сгенерированную LLM, так реально делают. На него не ссылаются, кроме случаев известных авторов или институтов. Но он уже индексируется и попадает в обзоры LLM, так что есть вероятность, что про тебя узнают.<br />
* Дальше подаем на workshop – это малые сессии на больших конференциях. Там ниже требования, и там будет обратная связь.
* Дальше – дорабатываем и полноценно на конференцию.
Отказ – обновили и отправили. Получили отказ на большую статью – сделали на ее основе маленькую демо-статью на другую конфу, там приняли. И параллельно можно доработать и запустить полную на еще одну конфу. Надо следить, чтобы пересечений не было. Одна из статей у них крутилась три года на 6 конференциях и была принята.
Рецензия: о чем статья, сильные стороны и слабые в большом количестве. На большинстве конференций есть возможность один раз ответить рецензенту, убедить, что конфетка. И есть сеньор рецензент – он пишет итоговое решение.
Цикл публикации – 9 месяцев.
'''Сейчас никто не говорит про новизну'''. Полезности для сообщества – достаточно. Если старую идею оформили так, что на нее ссылаются – этого достаточно.
Репозиторий с кодом и звездочки – важно. Страница проекта и статьи – обязательно, можно сделать инструментами. И можно сделать публикацию на habr или где-еще, популярным языком изложить сложные идеи – это не мешает.
Разница между конференциями и журналами. У конференции понятные сроки, ограниченный объем публикации, и надо обязательно приехать. Зато можно продвигать статью, чтобы цитировали через постеры и общение. Презентация на конференции – постер. 1.5 часа идет сессия постеров: авторы стоят у своих постеров и общаются. Так 90-95% выступлений. Есть еще доклады на 5 минут, мини-сессия, но туда мало проходят. У некоторых конференций есть демо-треки, туда вообще почти всех берут. Короткое видео некоторые требуют, но их никто не смотрит.
В журналах – большой объем (хотя сейчас ограничивают до 7 страниц), но сроки рецензирования не ограничены, до 2 лет. Зато возможна переработка, и ездить никуда не нужно.
'''AIscientist'''. Идея была 5 лет назад, тогда не взлетело. Сейчас китайцы не стесняются использовать LLM, есть целая линейка инструментов. Есть DeepReviwer – и он точно лучше человека. Есть полный цикл: DeepScientist и CycleResearcher. Без человека КПД – низкое, супер-идей они не создают. Но человеку – помогают. В презентации – список инструментов, которые они используют. В том числе генерация кода – ИИ пишет лучше студента. А презентация – notebookLLM.
Как у них устроен процесс? Есть семинары для генерации идей. ИИ-суммаризатор обсуждения и набор экспериментов – из него идет бэклог. Через неделю – обсуждаем, повторяем цикл.
Что будет в будущем? Он думает, что будет площадка обмена snippet-идеями, через которую общаются ИИ-агенты, чтобы отслеживать пересечения с другими исследователями, и можно кооперироваться. Насколько я понимаю, сейчас ArXiv и другие площадки препринтов можно примерно так рассматривать и использовать, просто пока никто не делает – предпочитают вариться в собственном соку в знакомой среде.
'''Вопрос'''. Как понять, что LLM сделала хороший обзор? Ответ. Это как с поиском: вы доверяете Google, что он поиск правильно выдал? Надо смотреть, читать, проверять.
== Андрей Гетманов из ИТМО. Как мы разработали и внедрили систему проверки кода в научных статьях и дипломных работах ==
Рассказ о попытке с помощью ИИ решить проблемы защиты проектов и дипломных работ, которые студенты на халяву – когда есть красивый отчет, за которым нет ни кода ни экспериментов. На формальное требование «приложить код или исходные данные» студенты отвечают столь же формально – кладут в репозиторий что-нибудь, что может не соответствовать содержанию диплома или отчета. И они попробовали решить задачу с помощью LLM, которой передается отчет и код: она выделяет главные тезисы из текста и пробует найти им соответствие в коде, а также проверяет текст и код на соответствие набору критериев.
В целом работа понятная, но до «разработали и внедрили» тут еще далеко. Пока получено, что на тестовых примерах, в качестве которых используются накопленные в архиве работы, LLM дает какие-то разумные результаты. Но, наверное, совсем фигню отсекает. Детали – в презентации и выступлении.
А мне тут не понятно следующее. В теории отсекать халяву – задача научного руководителя. Похоже практика такова, что они это реально игнорируют, и никаких санкций за это не получают, раз явление носит массовый характер. А если так, то LLM – не поможет. Ну, напряжет студентов побольше поработать генератором, чтобы получить более правдоподобный фейк. Отмечу, что саму работу по прорыве ведут в отрыве от научных руководителей. Было бы, наверное, логично, если бы именно они первыми использовали такие проверки, и не на дипломе, а гораздо раньше, на проектах. И не с целью отсечь фейки, а с целью повысить качество самих студенческих проектов, дать рекомендации. Но нет, с преподавателями группа не взаимодействует, и нацелена именно на контроль – что подтверждает мою гипотезу про саботаж.
{{wl-publish: 2026-04-27 13:59:04 +0300 | MaksTsepkov }}
