VTORNIK.Вечер #9: саммари выступлений

На прошлой неделе после летнего перерыва открыли второй сезон VTORNIK.Вечер - бесплатному оффлайн мероприятию о внедрении AI в организациях.
Из любопытного: второй сезон, как и первый, мы начали с выступления представителя Альфа-Банка; и еще в очередной раз подтвердили свое наблюдение и посмеялись вместе с постоянными участниками по поводу плохой погоды в день проведения митапа.

На мероприятии присутствовали руководители компаний и подразделений, тимлиды, AI-leaders, аналитики, ML-инженеры и разработчики. В программе традиционно было два доклада.

Сергей поделился практическим опытом запуска крупных AI-проектов — от идеи и защиты бюджета до продакшена и масштабирования на тысячи сотрудников и миллионы клиентов. За последние несколько лет команда запускала RAG-платформу, платформу интеллектуальной обработки документов, речевую аналитику и AI-инструменты для аналитиков. Главный вывод из этого опыта довольно парадоксален: сама технология оказывается далеко не самой сложной частью AI-проект.

1. Главная проблема AI-проектов — чаще всего не AI
Большинство технологий, которые сегодня внедряет крупный и средний бизнес, уже достаточно хорошо изучены. RAG, LLM, open-source модели, различные варианты архитектур — по ним есть статьи, готовые решения и опыт других компаний. Гораздо чаще проект ломается после того, как работающая технология встречается с реальным бизнес-процессом. Например:

• существующий процесс никто не хочет менять;
• инфраструктура вокруг AI-решения оказывается не готова;
• KPI сотрудников противоречат тому, что предлагает новый инструмент;
• непонятно, кто должен нести ответственность за ошибки модели;
• сотрудники продолжают работать привычным способом.

Особенно сложный вопрос — ответственность. Если сотрудник ошибается, организация умеет с этим работать. Если AI работает с качеством 95% и ошибается в оставшихся 5%, приходится заново определять, кто принимает этот риск на себя. Именно такие организационные изменения иногда оказываются сложнее разработки самой модели.
Практический вывод: перед запуском AI-проекта нужно проектировать не только модель, но и новый бизнес-процесс вокруг нее.

2. Начинайте не с заказчика, а с того, кто реально будет пользоваться результатом
Одна из самых частых ошибок — считать, что заказчик проекта и пользователь результата — один и тот же человек. Например, решение может заказать департамент качества, а пользоваться им должен колл-центр. При этом у колл-центра свои KPI и свой способ работы. В итоге команда делает хороший продукт, а конечный пользователь говорит: «Нам это не нужно». В Альфа-Банке поэтому действует правило: нельзя начинать проект без исследования работы реального получателя результата. В ходе такого исследования иногда выясняется, что:

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

Если для внедрения AI сначала необходимо год менять KPI подразделения, возможно, сам AI-проект пока вообще не стоит начинать. Лайфхак: прежде чем писать техническое задание, проведите несколько часов рядом с будущим пользователем и посмотрите, как он реально выполняет эту работу сегодня.

3. Для крупного проекта нужен спонсор, которому результат нужен лично
Парадокс корпоративного мира: иногда большой проект реализовать легче, чем маленький.
Крупная программа заметна руководству, получает приоритет у внутренних служб, вокруг нее проще собирать людей и ресурсы. Маленькая AI-инициатива может месяцами ходить по кругу между IT, безопасностью, HR, юристами и архитектурой.
Можно объединять несколько небольших AI-кейсов в одну значимую программу и искать спонсора уровня CEO-1, для которого ее результат связан с собственным KPI.
Проект, которым действительно заинтересованы несколько членов правления, зачастую проходит организационные барьеры гораздо быстрее.

4. Не каждый AI-проект обязан приносить деньги, но нужно честно понимать, зачем он существует
Еще одна распространенная ошибка — пытаться любой проект обосновать прямым финансовым ROI. На практике проект может быть: финансовым, инфраструктурным, регуляторным, социальным, репутационным. И это нормально. Если реальная ценность проекта — снижение риска или развитие социальной ответственности компании, не стоит искусственно придумывать финансовый эффект. Через год цифры придется защищать перед финансистами. Лучше честно сформулировать настоящую причину, по которой организации нужен проект, и защищать его именно через эту ценность.

5. Не спешите становиться первым пользователем новой инфраструктуры
Быть первым внутри большой организации дорого и болезненно: именно первый проект обнаруживает все проблемы новой среды, проходит первые проверки архитекторов, безопасности и аудита и фактически тестирует инфраструктуру за всех остальных. Отсюда практическое правило:если новую платформу обещают запустить в первом квартале, планируйте серьезный production-кейс скорее на третий. Пусть первые технические и организационные проблемы обнаружит кто-то другой. И еще до старта обязательно проверяйте весь технологический маршрут проекта, включая legacy-системы. Один незаметный компонент в цепочке, который больше никто не поддерживает, способен остановить проект с потенциальным эффектом в сотни миллионов рублей.

6. Не делайте PoC (Proof of Concept) технологии — делайте PoC бизнес-процесса
Если вы хотите понять, способен ли современный RAG технически отвечать на вопросы сотрудников, зачастую нет смысла три месяца доказывать сам факт работоспособности технологии. Такие решения уже реализованы десятками компаний. Гораздо важнее проверить другое: будут ли люди вообще пользоваться вашим решением? Для этого иногда даже не нужен настоящий AI. Можно сделать простой интерфейс, подставлять в него заранее подготовленные ответы и наблюдать: открывают ли сотрудники подсказки, доверяют ли им, используют ли их в работе, сокращается ли время выполнения задачи, вписывается ли инструмент в существующий workflow. То есть проверять нужно прежде всего PoC процесса, а не технологии.

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

• Поймать волну. Если руководство только что увидело сильный кейс конкурента или объявило новую стратегическую тему, окно возможностей может длиться всего несколько недель.
• Учитывать бюджетный цикл. В определенные периоды у подразделений появляются неиспользованные бюджеты и ресурсы, которые проще получить именно сейчас.
• Социализировать решение заранее. Не стоит впервые показывать спорную идею непосредственно на комитете. Лучше заранее встретиться с ключевыми ЛПР, собрать критику и встроить их замечания в проект. Тогда к заседанию они уже становятся в некотором смысле его соавторами.
• Знать актуальные правила игры. Сегодня компании может быть легче согласовать штат, завтра — вендора, послезавтра — получить ресурсы через соседнюю крупную программу. Эти правила постоянно меняются.

8. В начале проекта руководитель должен погружаться глубже, а не просто смотреть на статусы
Один из уроков Сергея — первые месяцы нового проекта требуют максимального личного вовлечения руководителя. Причина проста: команда может двигаться очень быстро, но не туда. Поэтому на старте важно убедиться, что бизнес, разработчики, архитекторы и другие участники одинаково представляют конечный результат.
При этом задача руководителя — не собирать зеленые и красные статусы в таблице. Он должен достаточно глубоко понимать архитектуру и методологию решения, чтобы на ранней стадии задавать неудобные вопросы. Исправить неверное архитектурное решение через полгода после выхода в production гораздо сложнее, чем заметить его в начале. Именно поэтому в Альфа-Банке появился обязательный этап System Design: ключевые специалисты должны подтвердить жизнеспособность архитектуры еще до начала разработки.

Главный вывод: AI-проект — это примерно на 30% технология и на 70% изменение процесса, ответственности, мотивации и способа работы людей.
Поэтому начинать стоит не с вопроса «какую модель использовать?», а с других вопросов: Кто реально будет пользоваться решением? Что изменится в его работе? Кто возьмет на себя риск ошибки AI? Не противоречат ли решению текущие KPI? Готова ли инфраструктура? Кто из руководителей заинтересован в результате лично?
И только после этого — выбирать технологии и писать код.

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

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

Основная идея доклада применима не только к науке: по мере того, как сами модели становятся мощнее и доступнее, конкурентным преимуществом становится не выбор конкретной LLM, а то, какую рабочую среду мы вокруг нее построили.

1. Хорошая модель сама по себе — еще не агент
Большие контекстные окна, новые модели и снижение стоимости inference уже перестают быть чем-то уникальным. Следующий уровень — обвязка вокруг модели: доступ к инструментам, работа с файлами и базами, сохранение контекста, память, циклы выполнения задачи, автоматические проверки, возможность возвращаться к предыдущим результатам. Именно совокупность этих элементов образует harness— рабочую среду, в которой AI может последовательно решать сложную задачу.
Поэтому выбирая AI-инструмент, все меньше смысла смотреть только на модель, важно смотреть на всю систему вокруг нее.

2. Чем быстрее обратная связь, тем лучше работают агенты
Почему агенты особенно быстро развиваются именно в программировании? Потому что там очень короткий feedback loop. Агент написал код — его можно сразу запустить, проверить тестами, измерить производительность, сравнить результат, исправить ошибку, попробовать еще раз. Цикл может повторяться сотни раз без участия человека. В физическом мире все сложнее. Если гипотеза связана, например, с биологическим экспериментом, недостаточно запустить еще одну вычислительную итерацию: образец нужно физически подготовить, провести эксперимент и дождаться результата. Отсюда важный принцип для любых агентных систем:
ищите задачи, где результат действия AI можно быстро и объективно проверить. Чем быстрее и дешевле feedback loop, тем выше потенциал автоматизации.

3. Оценивайте задачу по уровню неопределенности
Не все задачи одинаково хорошо подходят агентам. На одном конце шкалы находятся относительно детерминированные задачи: например, расчет A/B-теста. Правила известны, результат можно проверить. Дальше идут ML-задачи, где появляется больше вариантов решений. Еще дальше — диагностика, исследования и другие ситуации, где заранее неизвестно, какой путь окажется правильным. Чем ниже неопределенность, тем проще построить надежный harness. Но интересный эффект развития AI заключается в том, что именно рутинные и предсказуемые задачи будут автоматизироваться первыми. А людям все больше будут оставаться задачи с высокой неопределенностью — то есть, по сути, исследовательская работа.

4. Базовая архитектура хорошего харнеса: контекст + инструменты + проверки
Исследовательский harness можно представить как постоянный цикл: гипотеза → действие → результат → проверка → новая гипотеза. Чтобы такой цикл действительно работал, агенту необходимы три вещи:

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

Именно вокруг этих трех элементов строится рабочая агентная система.

5. Дайте агенту собственную библиотеку знаний
В исследовательском harness Максима агент имеет доступ к большой базе публикаций через RAG. Это позволяет ему в любой момент посмотреть:

• какие методы уже использовали другие исследователи;
• какие модели проверялись;
• какие метрики применялись;
• какие результаты уже получены;
• куда имеет смысл двигаться дальше.

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

6. Не позволяйте AI слишком быстро объявлять победу
У языковых моделей есть неприятная особенность: они любят соглашаться с пользователем и поддерживать красивую гипотезу. Для исследователя это особенно опасно. Получив интересный результат, агент может фактически сказать: «Похоже, мы сделали открытие». Но настоящий научный подход должен начинаться с противоположного вопроса: «Где мы могли ошибиться?». Поэтому в harness нужны Guard Rails — отдельные правила и механизмы проверки, например: перепроверить вычисления, сравнить результат с предыдущими исследованиями, проверить альтернативное объяснение, убедиться, что графики и таблицы построены корректно, запустить отдельного агента-рецензента. Таким образом, второй агент может специально пытаться опровергнуть вывод первого.

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

7. Храните не только результат, но и весь путь к нему
Для длинных агентных процессов критически важна трассируемость. Недостаточно сохранить итоговую цифру или вывод. Нужно иметь возможность восстановить: гипотеза → код → данные → конкретный запуск → результат. Это позволяет проверить вывод позже, понять источник ошибки, автоматически провести review, повторить эксперимент, использовать полученный результат в новых задачах.
Спикер использует для этого графовые связи и Obsidian: агент самостоятельно ставит перекрестные ссылки между связанными артефактами.
Главное правило — ни одна цифра или вывод не должны появляться в базе без связи с конкретным экспериментом и его источниками.

8. Хороший harness дает накопительный эффект
Самое интересное начинается не на первой гипотезе, а после десятков экспериментов. Представьте, что вы нашли работающую закономерность. Теперь вместо того, чтобы заново строить исследование, можно менять один элемент: другую модель, другой датасет, другую метрику, другой тип воздействия. Если весь pipeline автоматизирован, новая проверка превращается практически в изменение параметра. Именно так Максим обрабатывал замечания рецензентов научной публикации: добавить еще несколько моделей или проверить дополнительное условие можно было без перестройки всего исследования. Со временем появляется собственная база уже проверенных гипотез. RAG начинает работать не только по внешней литературе, но и по результатам предыдущей работы самого агента. Чем больше качественных экспериментов проведено, тем быстрее идут следующие.

9. Недетерминированность нужно учитывать архитектурно
Одна из ловушек работы с LLM — одинаковый запрос не гарантирует одинаковый ответ. Для исследования это критично: нельзя принимать случайную вариацию модели за реальный эффект. Поэтому для воспроизводимых экспериментов спикер использует температуру 0. Если температура выше, необходимы множественные прогоны и статистическая проверка результата. Есть и еще одна проблема — context poisoning: ошибочная информация, попавшая в контекст, может начать влиять на дальнейшие решения агента. Один из способов бороться с этим — фиксировать «индекс уверенности»: если одна гипотеза многократно подтверждается в разных условиях, ее можно постепенно переводить в разряд проверенного знания.

10. Human-in-the-loop никуда не исчезает
Даже очень развитый исследовательский агент пока не отменяет человека. Человек определяет направление, оценивает неожиданные результаты, замечает контекст и решает, куда двигаться дальше. При этом следующий этап развития уже просматривается: самоулучшающиеся исследовательские агенты, которые смогут анализировать собственные способы работы и перестраивать свой harness. Еще более интересная перспектива — соединение таких систем с физическим миром: микроскопами, лабораторным оборудованием, роботизированными установками. Тогда агент сможет не только анализировать существующие данные, но и самостоятельно выбирать следующий эксперимент.

Если свести весь опыт в три правила хорошего harness, получится очень практичная конструкция:
1. Структура. Агент должен видеть всю цепочку от гипотезы до результата.
2. Контекст. У него должен быть доступ и к актуальным внешним знаниям, и к истории собственной работы.
3. Верификация. Ни один красивый результат не должен автоматически становиться истиной.
По мере развития моделей именно качество такой «рабочей среды» становится все важнее. Хороший агент — это уже не просто LLM с хорошим промптом. Это система, которая умеет помнить, действовать, проверять себя, сохранять результаты и использовать накопленный опыт в следующем цикле.

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

Отдельная благодарность нашим партнерам ГК «Солар» за возможность проводить митапы в их красивом и гостеприимном офисе.

Если вы хотите провести образовательную программу в своей компании или получить консультацию наших экспертов, пожалуйста, пишите на info@vtornik.company.