VTORNIK.Вечер #10: саммари выступлений
Рубрика: мероприятия
Время чтения: 6 мин
Степень использования AI в создании этого материала: 90% работы по созданию данного материала сделал ИИ.
Мы считаем важным открыто информировать о том, в какой степени ИИ использовался в написании материала, поскольку только такой подход способен создавать доверие между нами и читателем.
Мы считаем важным открыто информировать о том, в какой степени ИИ использовался в написании материала, поскольку только такой подход способен создавать доверие между нами и читателем.
На прошлой неделе провели юбилейный 10-ый VTORNIK.Вечер — бесплатное оффлайн мероприятие о внедрении AI в организациях. На мероприятии присутствовали руководители компаний и подразделений, тимлиды, AI-leaders, аналитики, ML-инженеры и разработчики. В программе традиционно было два доклада.
С первым докладом — “Как следить за вашими AI-решениями и понимать их? Практические кейсы по AI Observability” — выступил Артем Каледин, AI Stream Lead, Sber2B. Более 8 лет в Data Science и AI / руководит командами более 4 лет; делал проекты в банках, телекоме, такси и стартапах. Сейчас строит ИИ решения для развития бизнеса и внутреннюю LLM-платформу.
Презентацию Артёма можно найти в комментариях к посту в нашем телеграм-канале.
Артём рассказал о том, почему привычных инструментов мониторинга уже недостаточно для систем на базе LLM и AI-агентов — и что именно нужно наблюдать, чтобы такие решения оставались управляемыми в продакшне.
Главная проблема в том, что технически исправная AI-система не обязательно работает хорошо. Сервер может вернуть 200 OK, модель — сформировать ответ, а пользователь при этом получить нерелевантный результат, галлюцинацию или просто не дождаться начала генерации. Поэтому в AI-системах наблюдаемость постепенно смещается от контроля инфраструктуры к пониманию всего пути запроса: что система получила, какие решения приняла, какие инструменты вызвала, сколько это стоило и чем закончилось.
Почему классического мониторинга недостаточно
В обычных веб-сервисах многое можно понять по стандартным показателям: latency, throughput, error rate, загрузке CPU, GPU и RAM. Структурированные логи позволяют связать запрос с конкретной версией сервиса или модели и найти техническую причину сбоя. В классическом ML к этому добавляются качество данных, Data Drift, качество модели и деградация ее показателей со временем. Однако и здесь система в основном работает с достаточно четко определяемыми входными и выходными данными.
С LLM ситуация меняется. Модели работают со свободным естественным языком, где одну и ту же мысль можно выразить множеством способов, а единственного математически правильного ответа часто вообще не существует. Поэтому традиционных метрик качества уже недостаточно. LLM Observability в презентации определяется как комплексный мониторинг и анализ LLM-приложения на всех этапах — от трассировки цепочек промптов до оценки качества ответов уже в production.
Что нужно видеть внутри LLM-системы
Минимально полезная трассировка должна позволять восстановить весь путь запроса. Что именно спросил пользователь? Какие документы вернула векторная база? Что вошло в итоговый промпт? Что ответила модель? Это важно, потому что ошибка часто находится не там, где кажется. Плохой ответ может быть связан не с самой моделью, а с поиском, составом контекста, системной инструкцией или промежуточным сервисом.
При этом наблюдаемость должна объединять как минимум две группы показателей. Первая — производительность и стоимость: количество токенов в prompt и completion, TTFT — время до первого токена, общую задержку и throughput. Вторая — качество и безопасность: насколько ответ опирается на переданный контекст, отвечает ли он на вопрос пользователя, нет ли в нем токсичности или предвзятости.
Для проверки качества в production может использоваться LLM-as-a-Judge: другая модель оценивает ответы основной модели по заданной шкале.
С агентами все становится еще сложнее. Для обычного LLM-вызова цепочка относительно проста: есть prompt, ответ, токены и задержка. У агента появляется полный цикл поведения: планирование, несколько обращений к LLM, вызовы инструментов, память и реальные действия во внешних системах. Поэтому объектом наблюдения становится уже не отдельный ответ, а вся траектория выполнения задачи. Такую траекторию важно видеть как граф. Агент может двигаться линейно, возвращаться на предыдущие шаги, вызывать подагентов или запускать инструменты параллельно. Простого списка вызовов в этом случае недостаточно. При этом полезно фиксировать не только время выполнения операций, но и их смысл: какие данные получил агент, какой шаг выбрал и к какому результату это привело. Для этого используются семантические spans.
Отдельная задача — экономика. Стоимость нужно считать не только на уровне отдельного вызова модели, но и по каждому шагу, агенту и пользовательской задаче целиком.
Кейс 1. Документ найден, но модель его «не видит»
Один из примеров — классическая проблема Lost in the Middle.
Векторный поиск отработал правильно: нужный документ действительно попал в prompt. Но если в контексте слишком много документов, модель может хорошо использовать информацию в начале и конце и проигнорировать фрагмент из середины. В кейсе в prompt было передано 15 документов, а нужное правило находилось на седьмой позиции. При этом модель утверждала, что нужной информации в предоставленных документах нет. Трассировка позволяет увидеть, что поиск сработал корректно, а проблема появилась уже на этапе использования контекста.
Решение — не просто «дать модели больше данных», а подобрать оптимальный объем контекста: использовать reranking, уменьшать top_k, убирать дубли и нерелевантный текст через context compression. После этого изменение нужно проверить A/B-тестом — не только по качеству ответа, но и по расходу токенов и стоимости.
Практический вывод: документ, попавший в prompt, еще не означает, что модель действительно использовала его в ответе.
Кейс 2. Несколько запросов могут стоить очень дорого
Другой пример — неконтролируемый рост расходов.
Пользователь повторно отправляет один и тот же большой файл после таймаута. Количество запросов может оставаться относительно небольшим, но токены в минуту, стоимость в час и размер каждого запроса резко растут. Observability позволяет пройти от финансового алерта до конкретного пользователя или API-ключа, увидеть повторяющиеся крупные запросы и обнаружить, что лимит установлен только на число запросов, но не на токены или бюджет. В результате причиной оказывается агрессивный retry, который многократно умножает стоимость большого prompt. Решение — лимиты по токенам и бюджету, ограничение числа повторов, backoff и защита от дублей.
Практический вывод: мало запросов не означает низкую стоимость. В LLM-системах критически важен размер каждого вызова.
Кейс 3. Новый prompt может тихо ухудшить продукт
Еще одна типичная ситуация — после изменения системной инструкции инфраструктура продолжает работать штатно, но ответы становятся хуже.
Например, инструкция «отвечай кратко» приводит к тому, что модель начинает пропускать важные детали в сложных запросах. Падение видно не по HTTP-ошибкам, а по метрике Answer Relevance. Чтобы найти причину, нужно связать момент ухудшения с релизом prompt, сравнить версии через prompt diff и посмотреть качество по разным сегментам запросов. Если новая версия действительно ухудшает результат, ее откатывают, неудачные запросы сохраняют в регрессионный датасет, а следующую версию проверяют на этих кейсах еще до релиза.
Практический вывод: промпт — такой же компонент системы, как код или модель, и его изменения требуют версионирования и регрессионного тестирования.
Кейс 4. Агент работает долго не потому, что модель медленная
В мультиагентной системе классификатор и исполнитель могут начать бесконечно передавать друг другу одну и ту же задачу. Для пользователя это выглядит как долгая загрузка или таймаут. При этом внутри растет количество шагов, вызовов и расход токенов. Трассировка показывает внутренний «пинг-понг»: задача почти не меняется, новых фактов не появляется, но в системе нет условия выхода из цикла. Решение — ограничить число передач задачи, время и бюджет одного запуска. Если новые данные перестали появляться, система должна либо уточнить запрос, либо передать его человеку.
Практический вывод: большая latency в агентной системе может быть вызвана не медленной моделью, а неудачной логикой маршрутизации.
Кейс 5. API работает, но пользователь все равно уходит
Еще одна скрытая проблема — деградация провайдера модели. Ошибок может не быть вообще, но время до первого токена увеличивается, например, с 0,2 до 8 секунд. Пользователь воспринимает это как зависание приложения и закрывает его.
Поэтому важно отдельно мониторить TTFT, а при устойчивом превышении порога переключать критичные запросы на резервного провайдера. После восстановления основной инфраструктуры трафик возвращается постепенно с контролем TTFT, отмен запросов, качества и стоимости.
Практический вывод: техническая доступность API еще не означает приемлемого пользовательского опыта.
Наблюдаемость должна доходить до бизнес-результата. Кейс ассистента продавца. Такой агент может анализировать каталог продуктов, актуальные условия и данные CRM, а затем предлагать решение и черновик письма клиенту. Но оценивать его работу только по правильности текста недостаточно.
Здесь предлагается смотреть сразу на три уровня:
Это важный переход: observability — это уже не только поиск технических ошибок, но и попытка связать работу AI с реальной пользой.
До релиза — тесты, после релиза — трассировка. Для контроля AI-агента предлагается сочетать несколько уровней.
Golden Dataset хранит эталонные сценарии, ожидаемые результаты и обязательные правила.
Promptfoo используется для тестов в CI/CD: проверки регрессий, формата и ограничений. Для более мягких критериев можно подключать LLM-as-a-Judge.
Langfuse дает трассировку уже работающей системы: какие инструменты использовались, что ответили микросервисы, где возникли ошибки, какова задержка и сколько токенов было потрачено.
При этом Артём отдельно подчеркивает: жесткие бизнес-правила лучше проверять кодом, а оценку LLM использовать как дополнительный сигнал, а не как единственный механизм контроля.
Иногда проблема агента — не в логике, а в отсутствии нужного инструмента. Один из показательных кейсов — обработка кредитной заявки тремя агентами: аналитиком, рисковиком и супервизором. Аналитик формирует отчет, рисковик находит пропущенный судебный риск и возвращает документ на доработку. Но у аналитика нет инструмента, позволяющего получить нужные данные. Поэтому он просто меняет формулировку и снова отправляет практически тот же отчет. В результате два агента зацикливаются, стоимость растет, а супервизор так и не получает решенный спор. Через три минуты и около $50 расходов запрос завершается таймаутом 504.
Обычный APM показывает только длинный POST, но не объясняет, что произошло внутри системы. Семантические spans позволяют увидеть реальную причину: агенту буквально нечем получить недостающую информацию. Решение — дать ему проверенный источник данных или передавать такую проверку человеку, а также добавить эскалацию и ограничения по числу итераций, времени и бюджету.
Практический вывод: бесконечный цикл иногда возникает не из-за «плохого reasoning», а из-за того, что система требует от агента действие, для которого у него нет данных или инструмента.
Наблюдать нужно не только агента, но и все его окружение
По мере усложнения систем одного мониторинга модели становится недостаточно.
Один пользовательский запрос может запустить несколько LLM-вызовов, поиск в vector DB, обращения к бизнес-БД, внешние API, выполнение кода, запись в память, отправку уведомлений и human-in-the-loop.
Поэтому для одного запуска стоит считать число шагов и вызовов инструментов, общие токены, latency, стоимость, количество retry и неудачных действий.
Зрелая AI-инфраструктура должна связывать все эти действия единым распределенным trace, управлять объемом сохраняемых данных через sampling и retention, маскировать чувствительную информацию, вести аудит действий, ограничивать нагрузку и ресурсы. Важен и model routing: простые задачи можно направлять на более дешевые модели, сложные — на более мощные. Для критичных действий должен оставаться механизм human-in-the-loop.
Инфраструктурные метрики и качество AI нельзя рассматривать отдельно
При масштабировании AI-систем необходимо соединять два уровня наблюдаемости. С одной стороны — инфраструктура: vRAM, NVLink, KV-cache, состояние серверов и реальная нагрузка. С другой — пользовательские метрики вроде TTFT. Например, переполненный KV-cache может резко увеличить время до первого токена. Поэтому TTFT из Langfuse имеет смысл сопоставлять с инфраструктурными метриками vLLM в Grafana или Prometheus. Есть и еще один компромисс: дополнительные guardrails сами увеличивают задержку, потому что синхронная проверка добавляет новый шаг в критический путь. Поэтому тяжелую оценку ответов имеет смысл по возможности выполнять асинхронно, например через Langfuse и Ragas.
Главный тезис выступления можно сформулировать просто: выпускать LLM в production без полноценной наблюдаемости — значит создавать систему, которую невозможно нормально объяснять и контролировать. В LLM и особенно агентных системах недостаточно считать ошибки сервера или количество токенов. Нужно одновременно видеть производительность, стоимость, качество и безопасность; отслеживать планы, вызовы инструментов, циклы и память; версионировать промпты, скиллы и MCP; учитывать особенности выбранной модели и инфраструктуры. И, пожалуй, самое важное: считать нужно не только деньги, но и качество. Экономный AI-сервис, который регулярно галлюцинирует или нарушает бизнес-правила, нельзя считать хорошо работающим.
Главная проблема в том, что технически исправная AI-система не обязательно работает хорошо. Сервер может вернуть 200 OK, модель — сформировать ответ, а пользователь при этом получить нерелевантный результат, галлюцинацию или просто не дождаться начала генерации. Поэтому в AI-системах наблюдаемость постепенно смещается от контроля инфраструктуры к пониманию всего пути запроса: что система получила, какие решения приняла, какие инструменты вызвала, сколько это стоило и чем закончилось.
Почему классического мониторинга недостаточно
В обычных веб-сервисах многое можно понять по стандартным показателям: latency, throughput, error rate, загрузке CPU, GPU и RAM. Структурированные логи позволяют связать запрос с конкретной версией сервиса или модели и найти техническую причину сбоя. В классическом ML к этому добавляются качество данных, Data Drift, качество модели и деградация ее показателей со временем. Однако и здесь система в основном работает с достаточно четко определяемыми входными и выходными данными.
С LLM ситуация меняется. Модели работают со свободным естественным языком, где одну и ту же мысль можно выразить множеством способов, а единственного математически правильного ответа часто вообще не существует. Поэтому традиционных метрик качества уже недостаточно. LLM Observability в презентации определяется как комплексный мониторинг и анализ LLM-приложения на всех этапах — от трассировки цепочек промптов до оценки качества ответов уже в production.
Что нужно видеть внутри LLM-системы
Минимально полезная трассировка должна позволять восстановить весь путь запроса. Что именно спросил пользователь? Какие документы вернула векторная база? Что вошло в итоговый промпт? Что ответила модель? Это важно, потому что ошибка часто находится не там, где кажется. Плохой ответ может быть связан не с самой моделью, а с поиском, составом контекста, системной инструкцией или промежуточным сервисом.
При этом наблюдаемость должна объединять как минимум две группы показателей. Первая — производительность и стоимость: количество токенов в prompt и completion, TTFT — время до первого токена, общую задержку и throughput. Вторая — качество и безопасность: насколько ответ опирается на переданный контекст, отвечает ли он на вопрос пользователя, нет ли в нем токсичности или предвзятости.
Для проверки качества в production может использоваться LLM-as-a-Judge: другая модель оценивает ответы основной модели по заданной шкале.
С агентами все становится еще сложнее. Для обычного LLM-вызова цепочка относительно проста: есть prompt, ответ, токены и задержка. У агента появляется полный цикл поведения: планирование, несколько обращений к LLM, вызовы инструментов, память и реальные действия во внешних системах. Поэтому объектом наблюдения становится уже не отдельный ответ, а вся траектория выполнения задачи. Такую траекторию важно видеть как граф. Агент может двигаться линейно, возвращаться на предыдущие шаги, вызывать подагентов или запускать инструменты параллельно. Простого списка вызовов в этом случае недостаточно. При этом полезно фиксировать не только время выполнения операций, но и их смысл: какие данные получил агент, какой шаг выбрал и к какому результату это привело. Для этого используются семантические spans.
Отдельная задача — экономика. Стоимость нужно считать не только на уровне отдельного вызова модели, но и по каждому шагу, агенту и пользовательской задаче целиком.
Кейс 1. Документ найден, но модель его «не видит»
Один из примеров — классическая проблема Lost in the Middle.
Векторный поиск отработал правильно: нужный документ действительно попал в prompt. Но если в контексте слишком много документов, модель может хорошо использовать информацию в начале и конце и проигнорировать фрагмент из середины. В кейсе в prompt было передано 15 документов, а нужное правило находилось на седьмой позиции. При этом модель утверждала, что нужной информации в предоставленных документах нет. Трассировка позволяет увидеть, что поиск сработал корректно, а проблема появилась уже на этапе использования контекста.
Решение — не просто «дать модели больше данных», а подобрать оптимальный объем контекста: использовать reranking, уменьшать top_k, убирать дубли и нерелевантный текст через context compression. После этого изменение нужно проверить A/B-тестом — не только по качеству ответа, но и по расходу токенов и стоимости.
Практический вывод: документ, попавший в prompt, еще не означает, что модель действительно использовала его в ответе.
Кейс 2. Несколько запросов могут стоить очень дорого
Другой пример — неконтролируемый рост расходов.
Пользователь повторно отправляет один и тот же большой файл после таймаута. Количество запросов может оставаться относительно небольшим, но токены в минуту, стоимость в час и размер каждого запроса резко растут. Observability позволяет пройти от финансового алерта до конкретного пользователя или API-ключа, увидеть повторяющиеся крупные запросы и обнаружить, что лимит установлен только на число запросов, но не на токены или бюджет. В результате причиной оказывается агрессивный retry, который многократно умножает стоимость большого prompt. Решение — лимиты по токенам и бюджету, ограничение числа повторов, backoff и защита от дублей.
Практический вывод: мало запросов не означает низкую стоимость. В LLM-системах критически важен размер каждого вызова.
Кейс 3. Новый prompt может тихо ухудшить продукт
Еще одна типичная ситуация — после изменения системной инструкции инфраструктура продолжает работать штатно, но ответы становятся хуже.
Например, инструкция «отвечай кратко» приводит к тому, что модель начинает пропускать важные детали в сложных запросах. Падение видно не по HTTP-ошибкам, а по метрике Answer Relevance. Чтобы найти причину, нужно связать момент ухудшения с релизом prompt, сравнить версии через prompt diff и посмотреть качество по разным сегментам запросов. Если новая версия действительно ухудшает результат, ее откатывают, неудачные запросы сохраняют в регрессионный датасет, а следующую версию проверяют на этих кейсах еще до релиза.
Практический вывод: промпт — такой же компонент системы, как код или модель, и его изменения требуют версионирования и регрессионного тестирования.
Кейс 4. Агент работает долго не потому, что модель медленная
В мультиагентной системе классификатор и исполнитель могут начать бесконечно передавать друг другу одну и ту же задачу. Для пользователя это выглядит как долгая загрузка или таймаут. При этом внутри растет количество шагов, вызовов и расход токенов. Трассировка показывает внутренний «пинг-понг»: задача почти не меняется, новых фактов не появляется, но в системе нет условия выхода из цикла. Решение — ограничить число передач задачи, время и бюджет одного запуска. Если новые данные перестали появляться, система должна либо уточнить запрос, либо передать его человеку.
Практический вывод: большая latency в агентной системе может быть вызвана не медленной моделью, а неудачной логикой маршрутизации.
Кейс 5. API работает, но пользователь все равно уходит
Еще одна скрытая проблема — деградация провайдера модели. Ошибок может не быть вообще, но время до первого токена увеличивается, например, с 0,2 до 8 секунд. Пользователь воспринимает это как зависание приложения и закрывает его.
Поэтому важно отдельно мониторить TTFT, а при устойчивом превышении порога переключать критичные запросы на резервного провайдера. После восстановления основной инфраструктуры трафик возвращается постепенно с контролем TTFT, отмен запросов, качества и стоимости.
Практический вывод: техническая доступность API еще не означает приемлемого пользовательского опыта.
Наблюдаемость должна доходить до бизнес-результата. Кейс ассистента продавца. Такой агент может анализировать каталог продуктов, актуальные условия и данные CRM, а затем предлагать решение и черновик письма клиенту. Но оценивать его работу только по правильности текста недостаточно.
Здесь предлагается смотреть сразу на три уровня:
- качество ответа — учтены ли требования клиента, подтверждены ли функции, ограничения и цены актуальными источниками;
- процесс — какие документы и данные CRM использовал агент, какие сервисы вызвал, где возникли сбои и сколько стоило выполнение;
- результат — воспользовался ли продавец рекомендацией, что исправил в письме и сколько времени сэкономил.
Это важный переход: observability — это уже не только поиск технических ошибок, но и попытка связать работу AI с реальной пользой.
До релиза — тесты, после релиза — трассировка. Для контроля AI-агента предлагается сочетать несколько уровней.
Golden Dataset хранит эталонные сценарии, ожидаемые результаты и обязательные правила.
Promptfoo используется для тестов в CI/CD: проверки регрессий, формата и ограничений. Для более мягких критериев можно подключать LLM-as-a-Judge.
Langfuse дает трассировку уже работающей системы: какие инструменты использовались, что ответили микросервисы, где возникли ошибки, какова задержка и сколько токенов было потрачено.
При этом Артём отдельно подчеркивает: жесткие бизнес-правила лучше проверять кодом, а оценку LLM использовать как дополнительный сигнал, а не как единственный механизм контроля.
Иногда проблема агента — не в логике, а в отсутствии нужного инструмента. Один из показательных кейсов — обработка кредитной заявки тремя агентами: аналитиком, рисковиком и супервизором. Аналитик формирует отчет, рисковик находит пропущенный судебный риск и возвращает документ на доработку. Но у аналитика нет инструмента, позволяющего получить нужные данные. Поэтому он просто меняет формулировку и снова отправляет практически тот же отчет. В результате два агента зацикливаются, стоимость растет, а супервизор так и не получает решенный спор. Через три минуты и около $50 расходов запрос завершается таймаутом 504.
Обычный APM показывает только длинный POST, но не объясняет, что произошло внутри системы. Семантические spans позволяют увидеть реальную причину: агенту буквально нечем получить недостающую информацию. Решение — дать ему проверенный источник данных или передавать такую проверку человеку, а также добавить эскалацию и ограничения по числу итераций, времени и бюджету.
Практический вывод: бесконечный цикл иногда возникает не из-за «плохого reasoning», а из-за того, что система требует от агента действие, для которого у него нет данных или инструмента.
Наблюдать нужно не только агента, но и все его окружение
По мере усложнения систем одного мониторинга модели становится недостаточно.
Один пользовательский запрос может запустить несколько LLM-вызовов, поиск в vector DB, обращения к бизнес-БД, внешние API, выполнение кода, запись в память, отправку уведомлений и human-in-the-loop.
Поэтому для одного запуска стоит считать число шагов и вызовов инструментов, общие токены, latency, стоимость, количество retry и неудачных действий.
Зрелая AI-инфраструктура должна связывать все эти действия единым распределенным trace, управлять объемом сохраняемых данных через sampling и retention, маскировать чувствительную информацию, вести аудит действий, ограничивать нагрузку и ресурсы. Важен и model routing: простые задачи можно направлять на более дешевые модели, сложные — на более мощные. Для критичных действий должен оставаться механизм human-in-the-loop.
Инфраструктурные метрики и качество AI нельзя рассматривать отдельно
При масштабировании AI-систем необходимо соединять два уровня наблюдаемости. С одной стороны — инфраструктура: vRAM, NVLink, KV-cache, состояние серверов и реальная нагрузка. С другой — пользовательские метрики вроде TTFT. Например, переполненный KV-cache может резко увеличить время до первого токена. Поэтому TTFT из Langfuse имеет смысл сопоставлять с инфраструктурными метриками vLLM в Grafana или Prometheus. Есть и еще один компромисс: дополнительные guardrails сами увеличивают задержку, потому что синхронная проверка добавляет новый шаг в критический путь. Поэтому тяжелую оценку ответов имеет смысл по возможности выполнять асинхронно, например через Langfuse и Ragas.
Главный тезис выступления можно сформулировать просто: выпускать LLM в production без полноценной наблюдаемости — значит создавать систему, которую невозможно нормально объяснять и контролировать. В LLM и особенно агентных системах недостаточно считать ошибки сервера или количество токенов. Нужно одновременно видеть производительность, стоимость, качество и безопасность; отслеживать планы, вызовы инструментов, циклы и память; версионировать промпты, скиллы и MCP; учитывать особенности выбранной модели и инфраструктуры. И, пожалуй, самое важное: считать нужно не только деньги, но и качество. Экономный AI-сервис, который регулярно галлюцинирует или нарушает бизнес-правила, нельзя считать хорошо работающим.
Вторым спикером VTORNIK.Вечер с темой “Не угадывать будущее: как управлять в эпоху AI и что стоит сделать уже вчера с позиции консерватора-скептика” был Александр Шепард
Заместитель технического директора - ЦТК, Солар. В прошлом: CTO, Т-Банк; Руководитель разработки, Robocash Group; Руководитель разработки в Ozon Fintech и VK.
Презентацию можно найти в комментариях к посту в нашем телеграм-канале.
Заместитель технического директора - ЦТК, Солар. В прошлом: CTO, Т-Банк; Руководитель разработки, Robocash Group; Руководитель разработки в Ozon Fintech и VK.
Презентацию можно найти в комментариях к посту в нашем телеграм-канале.
Александр предложил посмотреть на AI не через очередной прогноз о том, «что именно изменится через несколько лет», а через более практичный вопрос: насколько быстро организация сможет перестроиться, если сегодняшние предположения окажутся неверными.
История технологий уже много раз показывала, насколько плохо мы умеем оценивать последствия больших изменений в момент, когда они только начинаются. Интернет, облачные технологии, смартфоны, киберугрозы, пандемия, ChatGPT — задним числом легко выстроить логичную цепочку событий. Но непосредственно во время этих изменений оценки были гораздо менее однозначными. В своем выступлении Александр приводил примеры того, как в разные годы интернет считали нишевой историей, домашние компьютеры — переоцененным трендом, а саму сеть сравнивали чуть ли не с объединением филателистов.
Поэтому главный вопрос сегодня — не в том, какая из двух крайностей окажется правильной: «AI — это очередной хайп» или «AI изменит абсолютно всё». Ошибка обеих позиций в одном: каждая пытается превратить неопределенность в определенный прогноз. Реальность, скорее всего, окажется сложнее: что-то изменится очень сильно, что-то почти не изменится, а часть изменений пойдет совсем не по тому сценарию, который мы сегодня предполагаем. Ошибиться можно как минимум в трех вещах — в скорости, масштабе и направлении изменений.
Не готовиться к одному будущему
Традиционная логика стратегии выглядит так: понять, что произойдет, построить прогноз и подготовить под него компанию. Проблема возникает, если прогноз оказывается неправильным. Можно обучить сотрудников нужным навыкам, перестроить процессы, купить инструменты — а затем обнаружить, что развитие технологии пошло в другом направлении. Александр предлагает заменить эту модель циклом:
гипотеза → эксперимент → обратная связь → адаптация.
То есть не пытаться единожды выбрать «правильное будущее», а создавать организацию, способную постоянно проверять предположения и быстро корректировать курс. И тогда готовить компанию нужно не к конкретному сценарию, а к способности меняться. Насколько быстро можно изменить продукт? Перепроектировать процесс? Переучить сотрудников? Заменить технологический стек или инструмент? И, что особенно важно, насколько быстро руководство способно признать, что предыдущая ставка оказалась ошибочной?
Адаптивность становится конкурентным преимуществом
конкурентоспособность = точность прогноза × скорость адаптации
Хороший прогноз при медленной реакции может оказаться бесполезным. Даже плохой прогноз при высокой способности быстро перестроиться оставляет организации шанс. Поэтому качество стратегии стоит оценивать не только по тому, насколько хорошо компания угадала будущее, но и по тому, как быстро она способна изменить стратегию, обнаружив ошибку.
Вторая часть этой логики — снижение стоимости ошибки. Чем дешевле организации обходится проверка гипотезы, тем больше предположений она может протестировать и тем меньше риск слишком долго инвестировать в неверное направление. У любой системы есть две «смерти». Для рассказа об изменениях Александр использовал образ жизненного цикла системы. Система — это способ получать определенный результат. Но со временем ее эффективность падает. Иногда ее можно «подлатать» или модернизировать, временно продлив срок жизни.
При этом есть две принципиально разные точки: физическая смерть — система окончательно перестает выполнять свою функцию. Но раньше нее может наступить моральная смерть: система технически продолжает работать, однако ее эффективность уже опустилась ниже необходимого уровня. Именно здесь инновации особенно важны. Они позволяют либо модернизировать существующую систему, либо сдвинуть момент ее морального устаревания. Между необходимостью изменений и окончательной потерей эффективности возникает своеобразное «окно решений». Чем больше организация, тем сложнее воспользоваться этим окном: вместе с масштабом растут инерция и сопротивление изменениям.
Ускорить один участок — не значит ускорить всю систему. Эта идея хорошо проявляется и в практических экспериментах с AI. В одном из кейсов команда пыталась применить RAG и LLM для работы с корпоративными знаниями. Однако качество ответов упиралось не столько в модель, сколько в состояние самой базы знаний: данные в Confluence и связанных системах были фрагментированы и плохо структурированы. В другом случае AI использовали для ускорения создания автотестов. Локально задача действительно могла выполняться быстрее, но это не привело к ожидаемому снижению количества ошибок в production, поскольку существенная часть проблем возникала на уровне архитектуры. Общий принцип здесь гораздо шире AI: ускорение отдельного этапа процесса еще не означает ускорения всей системы. Если ограничение находится в другом месте, локальная автоматизация просто сделает одно звено быстрее, не изменив итоговый результат.
Поэтому перед автоматизацией важно понять, какую системную проблему компания вообще пытается решить и какой результат должен измениться.
Люди: изменения начинаются с руководителей
Первый слой подготовки организации — люди. Основная мысль Александра здесь довольно жесткая: людей невозможно просто заставить измениться. Поэтому изменения начинаются с руководителей и их собственного поведения.
Управлять трансформацией необходимо как отдельным процессом — например, используя такие модели изменений, как ADKAR. При этом требования к HR постепенно становятся более «инженерными»: недостаточно просто проводить коммуникации и обучение, требуется системно сопровождать изменение поведения и компетенций.
Процессы: сначала измеримость, потом ускорение
Вторая область — процессы. Минимальный порог здесь — наличие стандартов и измеримости. Нельзя улучшать процесс, если невозможно понять его текущее состояние и измерить эффект изменений. Александр отдельно говорит о демократизации инструментов: данные и инструменты анализа должны быть доступны не узкому кругу специалистов, а тем, кто непосредственно принимает решения. При этом встречи не должны подменять процессы. Автоматизация и ускорение также должны иметь измеримый эффект, иначе легко создать много локальной активности без заметного результата для системы в целом. Еще одна сложность — выравнивание целей разных участников процесса.
В выступлении эта логика дополнялась практическими примерами высвобождения ресурсов: отменой неэффективных активностей и очисткой накопившихся бэклогов. Смысл не столько в самой «чистке», сколько в том, что ресурс для экспериментов редко появляется сам — его приходится освобождать внутри существующей системы.
Технологии: сначала понять устройство системы
Третий слой — технологии. Здесь Александр предлагает учитывать закон Конвея: архитектура создаваемых систем во многом отражает структуру взаимодействия внутри самой организации. Кроме того, данные существующих систем влияют на дизайн процессов, поэтому способность принимать решения на основе данных становится одним из условий адаптивности. В технологическом контуре также появляется новая задача — работа с non-human identity, поскольку участниками процессов становятся уже не только люди, но и автоматизированные системы и AI-агенты. И наконец, технологии должны не просто создавать новые возможности, но и высвобождать ресурсы, которые можно направлять на дальнейшие изменения.
Экспериментировать чаще — значит дешевле ошибаться
Вместо большого плана трансформации Александр предлагает двигаться через зрелость практик. В презентации для этого используется Kanban Maturity Model: определить необходимый уровень зрелости, посмотреть на карту практик, сформировать план развития и выбрать конкретные гипотезы и точки их применения.
Ключевая мысль при этом — экспериментировать чаще, чтобы снижать стоимость ошибок. В той же логике в выступлении прозвучала идея фальсифицируемости гипотез: эксперимент должен быть сформулирован так, чтобы заранее было понятно, какой результат докажет, что предположение оказалось неверным. Это особенно важно для AI-проектов. Если заранее не определены метрики успеха, бюджет и условия остановки, эксперимент легко превращается в проект, который продолжает существовать просто потому, что в него уже вложили время и деньги.
Поэтому полезный AI-эксперимент должен отвечать на несколько простых вопросов: какую проблему мы проверяем, какой эффект считаем успехом, сколько готовы потратить на проверку и при каком результате прекращаем эксперимент.
Главная идея выступления Александра — не пытаться угадать единственно правильный сценарий развития AI. И скептицизм, и безусловная вера в технологию становятся проблемой, когда превращаются в жесткий прогноз. В условиях высокой неопределенности организации полезнее развивать способность быстро замечать изменения, дешево проверять гипотезы и столь же быстро отказываться от решений, которые не дают результата. Для этого недостаточно просто внедрять новые AI-инструменты. Нужно одновременно работать с людьми, процессами и технологиями, искать реальные ограничения всей системы, а не оптимизировать отдельные ее участки. Именно поэтому, пожалуй, самый практичный вопрос для руководителя сегодня звучит не «что AI сделает с нашей компанией через пять лет?», а: «Насколько быстро мы сможем перестроиться, если то, во что мы сейчас верим, окажется неправильным?» Это хорошо совпадает и с финальной формулой самой презентации: скептицизм — как драйвер, консерватизм — как фундамент.
История технологий уже много раз показывала, насколько плохо мы умеем оценивать последствия больших изменений в момент, когда они только начинаются. Интернет, облачные технологии, смартфоны, киберугрозы, пандемия, ChatGPT — задним числом легко выстроить логичную цепочку событий. Но непосредственно во время этих изменений оценки были гораздо менее однозначными. В своем выступлении Александр приводил примеры того, как в разные годы интернет считали нишевой историей, домашние компьютеры — переоцененным трендом, а саму сеть сравнивали чуть ли не с объединением филателистов.
Поэтому главный вопрос сегодня — не в том, какая из двух крайностей окажется правильной: «AI — это очередной хайп» или «AI изменит абсолютно всё». Ошибка обеих позиций в одном: каждая пытается превратить неопределенность в определенный прогноз. Реальность, скорее всего, окажется сложнее: что-то изменится очень сильно, что-то почти не изменится, а часть изменений пойдет совсем не по тому сценарию, который мы сегодня предполагаем. Ошибиться можно как минимум в трех вещах — в скорости, масштабе и направлении изменений.
Не готовиться к одному будущему
Традиционная логика стратегии выглядит так: понять, что произойдет, построить прогноз и подготовить под него компанию. Проблема возникает, если прогноз оказывается неправильным. Можно обучить сотрудников нужным навыкам, перестроить процессы, купить инструменты — а затем обнаружить, что развитие технологии пошло в другом направлении. Александр предлагает заменить эту модель циклом:
гипотеза → эксперимент → обратная связь → адаптация.
То есть не пытаться единожды выбрать «правильное будущее», а создавать организацию, способную постоянно проверять предположения и быстро корректировать курс. И тогда готовить компанию нужно не к конкретному сценарию, а к способности меняться. Насколько быстро можно изменить продукт? Перепроектировать процесс? Переучить сотрудников? Заменить технологический стек или инструмент? И, что особенно важно, насколько быстро руководство способно признать, что предыдущая ставка оказалась ошибочной?
Адаптивность становится конкурентным преимуществом
конкурентоспособность = точность прогноза × скорость адаптации
Хороший прогноз при медленной реакции может оказаться бесполезным. Даже плохой прогноз при высокой способности быстро перестроиться оставляет организации шанс. Поэтому качество стратегии стоит оценивать не только по тому, насколько хорошо компания угадала будущее, но и по тому, как быстро она способна изменить стратегию, обнаружив ошибку.
Вторая часть этой логики — снижение стоимости ошибки. Чем дешевле организации обходится проверка гипотезы, тем больше предположений она может протестировать и тем меньше риск слишком долго инвестировать в неверное направление. У любой системы есть две «смерти». Для рассказа об изменениях Александр использовал образ жизненного цикла системы. Система — это способ получать определенный результат. Но со временем ее эффективность падает. Иногда ее можно «подлатать» или модернизировать, временно продлив срок жизни.
При этом есть две принципиально разные точки: физическая смерть — система окончательно перестает выполнять свою функцию. Но раньше нее может наступить моральная смерть: система технически продолжает работать, однако ее эффективность уже опустилась ниже необходимого уровня. Именно здесь инновации особенно важны. Они позволяют либо модернизировать существующую систему, либо сдвинуть момент ее морального устаревания. Между необходимостью изменений и окончательной потерей эффективности возникает своеобразное «окно решений». Чем больше организация, тем сложнее воспользоваться этим окном: вместе с масштабом растут инерция и сопротивление изменениям.
Ускорить один участок — не значит ускорить всю систему. Эта идея хорошо проявляется и в практических экспериментах с AI. В одном из кейсов команда пыталась применить RAG и LLM для работы с корпоративными знаниями. Однако качество ответов упиралось не столько в модель, сколько в состояние самой базы знаний: данные в Confluence и связанных системах были фрагментированы и плохо структурированы. В другом случае AI использовали для ускорения создания автотестов. Локально задача действительно могла выполняться быстрее, но это не привело к ожидаемому снижению количества ошибок в production, поскольку существенная часть проблем возникала на уровне архитектуры. Общий принцип здесь гораздо шире AI: ускорение отдельного этапа процесса еще не означает ускорения всей системы. Если ограничение находится в другом месте, локальная автоматизация просто сделает одно звено быстрее, не изменив итоговый результат.
Поэтому перед автоматизацией важно понять, какую системную проблему компания вообще пытается решить и какой результат должен измениться.
Люди: изменения начинаются с руководителей
Первый слой подготовки организации — люди. Основная мысль Александра здесь довольно жесткая: людей невозможно просто заставить измениться. Поэтому изменения начинаются с руководителей и их собственного поведения.
Управлять трансформацией необходимо как отдельным процессом — например, используя такие модели изменений, как ADKAR. При этом требования к HR постепенно становятся более «инженерными»: недостаточно просто проводить коммуникации и обучение, требуется системно сопровождать изменение поведения и компетенций.
Процессы: сначала измеримость, потом ускорение
Вторая область — процессы. Минимальный порог здесь — наличие стандартов и измеримости. Нельзя улучшать процесс, если невозможно понять его текущее состояние и измерить эффект изменений. Александр отдельно говорит о демократизации инструментов: данные и инструменты анализа должны быть доступны не узкому кругу специалистов, а тем, кто непосредственно принимает решения. При этом встречи не должны подменять процессы. Автоматизация и ускорение также должны иметь измеримый эффект, иначе легко создать много локальной активности без заметного результата для системы в целом. Еще одна сложность — выравнивание целей разных участников процесса.
В выступлении эта логика дополнялась практическими примерами высвобождения ресурсов: отменой неэффективных активностей и очисткой накопившихся бэклогов. Смысл не столько в самой «чистке», сколько в том, что ресурс для экспериментов редко появляется сам — его приходится освобождать внутри существующей системы.
Технологии: сначала понять устройство системы
Третий слой — технологии. Здесь Александр предлагает учитывать закон Конвея: архитектура создаваемых систем во многом отражает структуру взаимодействия внутри самой организации. Кроме того, данные существующих систем влияют на дизайн процессов, поэтому способность принимать решения на основе данных становится одним из условий адаптивности. В технологическом контуре также появляется новая задача — работа с non-human identity, поскольку участниками процессов становятся уже не только люди, но и автоматизированные системы и AI-агенты. И наконец, технологии должны не просто создавать новые возможности, но и высвобождать ресурсы, которые можно направлять на дальнейшие изменения.
Экспериментировать чаще — значит дешевле ошибаться
Вместо большого плана трансформации Александр предлагает двигаться через зрелость практик. В презентации для этого используется Kanban Maturity Model: определить необходимый уровень зрелости, посмотреть на карту практик, сформировать план развития и выбрать конкретные гипотезы и точки их применения.
Ключевая мысль при этом — экспериментировать чаще, чтобы снижать стоимость ошибок. В той же логике в выступлении прозвучала идея фальсифицируемости гипотез: эксперимент должен быть сформулирован так, чтобы заранее было понятно, какой результат докажет, что предположение оказалось неверным. Это особенно важно для AI-проектов. Если заранее не определены метрики успеха, бюджет и условия остановки, эксперимент легко превращается в проект, который продолжает существовать просто потому, что в него уже вложили время и деньги.
Поэтому полезный AI-эксперимент должен отвечать на несколько простых вопросов: какую проблему мы проверяем, какой эффект считаем успехом, сколько готовы потратить на проверку и при каком результате прекращаем эксперимент.
Главная идея выступления Александра — не пытаться угадать единственно правильный сценарий развития AI. И скептицизм, и безусловная вера в технологию становятся проблемой, когда превращаются в жесткий прогноз. В условиях высокой неопределенности организации полезнее развивать способность быстро замечать изменения, дешево проверять гипотезы и столь же быстро отказываться от решений, которые не дают результата. Для этого недостаточно просто внедрять новые AI-инструменты. Нужно одновременно работать с людьми, процессами и технологиями, искать реальные ограничения всей системы, а не оптимизировать отдельные ее участки. Именно поэтому, пожалуй, самый практичный вопрос для руководителя сегодня звучит не «что AI сделает с нашей компанией через пять лет?», а: «Насколько быстро мы сможем перестроиться, если то, во что мы сейчас верим, окажется неправильным?» Это хорошо совпадает и с финальной формулой самой презентации: скептицизм — как драйвер, консерватизм — как фундамент.
Наши ивенты дают хорошую возможность пообщаться и обменяться опытом внедрения ИИ, будем рады видеть вас на следующем оффлайн митапе в 20 октября. Следите за анонсами в нашем телеграм-канале.
Отдельная благодарность нашим партнерам ГК «Солар» за возможность проводить митапы в их красивом и гостеприимном офисе.
Если вы хотите провести образовательную программу в своей компании или получить консультацию наших экспертов, пожалуйста, пишите на info@vtornik.company.
Отдельная благодарность нашим партнерам ГК «Солар» за возможность проводить митапы в их красивом и гостеприимном офисе.
Если вы хотите провести образовательную программу в своей компании или получить консультацию наших экспертов, пожалуйста, пишите на info@vtornik.company.
Другие материалы нашего блога