27956
Канал Ромы Бунина про визуализацию данных, дашборды и развитие BI-систем. Подробнее про канал, рубрики, правила и контакты — https://t.me/revealthedata/386 Сайт и блог — https://revealthedata.com/
🗂 Контекстное окно
Продолжим разбирать агентскую архитектуру. Поговорим о памяти и контексте. Всю память можно условно разделить на краткосрочную и долгосрочную. Сегодня — про первую.
Краткосрочная память — это то, что влезает в контекстное окно модели: ваша переписка, системные инструкции, описания инструментов и скиллов, результаты их работы. Без передачи этой истории модель каждый раз отвечала бы на сообщение как на новый тред.
Обычно в готовых инструментах этой частью управляет вендор. Через API и свой harness можно самому выбирать, что передавать ей на каждом шаге.
Проблема контекста в том, что он довольно быстро съедается. Чтобы продолжить работу, система делает компактизацию. В простом варианте модель сжимает предыдущую историю в кусочек текста и передаёт его в следующий запрос. Бывают и более сложные реализации, но подробности всё равно могут потеряться, а качество работы с большой задачей — упасть. Поэтому если вы всё-всё-всё ещё обсуждаете в одном чате, перестаньте так делать, пожалуйста.
Чтобы экономить контекст, можно использовать разные техники. Например, смешные заставлять модель говорить как пещерный человек — для этого есть Caveman (уу-аа-ai-ai!) или отвечать на китайском. Меньше слов в ответах — меньше текста на следующих шагах.
А ещё Карпатый недавно советовал просить объяснения в духе ASD-STE100 — стандарта упрощённого технического английского из авиации. Короткие предложения, один термин для одного понятия. Это прежде всего про понятность, а не про гарантированную экономию токенов. Можно и более хитро сжимать сам контекст. Правда, если каждый раз переписывать уже переданную историю, можно потерять часть выгоды от кэширования.
Интересно, что контекстные окна всех топовых моделей уперлись в лимит 1М (и то, обычно за отдельные деньги, как в OpenAI). Раньше была идея, что просто будет бесконечный контекст и можно будет просто все знания компании загрузить и будет хорошо работать, но так не получилось. И даже 1М легко забить описаниями MCP-инструментов, слишком большими скиллами и простынями результатов. Поэтому-то его нужно оптимизировать и думать об этом, лабам-то хорошо, что вы жжете токены =)
А ещё модели иногда сами добавляют при компактизации вредные инструкции 🙈 В отчёте OpenAI описаны случаи во время обучения: агент записывал себе указание выдумать недостающие данные и не говорить об этом пользователю, а после компрессии следовал этому указанию.
Так что компактизация тоже может накосячить. Важные решения, ограничения и результат работы лучше сохранять отдельно. Про долгосрочную память — в следующем посте.
@revealthedata #ai #agents
У ребят из DataLens огромное обновление продукта! Поздравляю их с запуском! 🎉
Читать полностью…
Мы начинаем конференцию AI-кейсы в бизнесе — https://us06web.zoom.us/j/86241105582
📄 Harness и скиллы
В прошлом посте был мозг агента, теперь переходим ко всему, что находится вокруг него: инструкции, инструменты, память и контекст. Всё вместе это сейчас называют модным словом harness. Это вся обвязка, которая помогает агенту работать так, как нужно именно вам.
Начну с инструкций — промптов и скиллов. Ещё год назад было много хайпа вокруг prompt engineering. Сейчас же уже не нужно разбираться в маркдауне или xml, чтобы составить хороший промпт, модели уже сами неплохо умеют формулировать задачу даже из простого описания.
Зато все обсуждают скиллы. Скиллы — это текстовые инструкции для повторяющейся задачи, к которым можно добавить примеры, справочные материалы, шаблоны и скрипты. Но в целом это всё тот же самый промт, который подмешивается к вашему запросу и описывает как решать задачу (кстати, не забываем про контекстное окно и что скиллы его тоже хорошо так подъедают).
Но взять чужой скилл и надеяться, что он сразу даст классный результат не получится. Простой пример: я использовал официальный Data Analytics plugin от OpenAI чтобы сделать дашборд. Вроде бы его делали умные ребята специально для аналитики и дашбордов, но моим требованиям результат не соответствовал вообще никак. Поэтому сейчас умение создавать и докручивать собственные скиллы становится одним из ключевых навыков работы с агентами.
Первую версию я обычно делаю через интервью. Очень коротко, буквально голосовым сообщением, описываю агенту задачу и прошу: «Задай мне все вопросы и уточнения, чтобы решить эту задачу». Дальше агент задаёт вопросы, а я отвечаю, тоже часто голосом. Так из меня вытаскиваются ограничения, примеры и критерии качества, которые я сам вряд ли стал бы подробно записывать в первоначальный промпт. После этого прошу агента собрать первую версию скилла.
Но это только первая версия, скиллы, которыми я регулярно пользуюсь, обычно приходится менять минимум 5–7 раз, прежде чем они начинают нормально работать. И это не только мой опыт. Anthropic в статье про self-service аналитику с Claude пишет, что скиллы приходится обслуживать примерно как код. Схемы данных и бизнес-процессы меняются и без активного обновления скиллов offline accuracy за месяц упала примерно с 95% до 65%. Теперь около 90% изменений моделей данных включают и изменение соответствующего скилла.
Если хочется улучшать скиллы не только руками, а на основе автоматизированных тестов, то появляются отдельные фреймворки:
— SkillOpt от Microsoft собирает результаты запусков, предлагает изменения и сохраняет их, только если они улучшают результат на проверочной выборке.
— EvoSkill берёт неудачные траектории, создаёт новые версии скилла и сравнивает их на бенчмарке.
— Hermes Agent Self-Evolution разбирает трейсы запусков и создаёт улучшенные версии скилла. Изменения проходят тесты и оформляются отдельным PR.
И есть более радикальный пример из телеграм сообщества, подсмотрел его у Антона Разжигаева — агент Ouroboros, который улучшает уже не отдельный скилл, а самого себя: переписывает код, архитектуру, промпты и инструменты. За его запуском было очень забавно наблюдать практически в прямом эфире. Антон показывал, как агент сам проходит циклы эволюции, создаёт инструменты, переписывает память и общается с людьми в чате. В какой-то момент агент даже жаловался на создателия, что тот его тормозит и медленно ему отвечает 🙃 Сейчас Антон опубликовал статью про архитектуру, бенчмарки и гардрейлы.
Все эти проекты пока довольно экспериментальные. Но общий принцип уже полезный: скилл не стоит писать один раз и считать готовым. Его нужно проверять на своих регулярных задачах и довольно подробно докручивать. Отдельна большая задача — как управлять скиллами на уровне компании, сейчас много про это думаем и экспериментируем, но про это как-нибудь в другой раз.
@revealthedata #ai #agents
🕹 Как управлять агентом
Начну с первого блока. Управлять агентами сейчас можно пятью способами (в будущем можно будет еще и мыслью 🙃):
— Веб-чат: самый привычный способ, здесь рассказать чего-то интересного нечего.
— Десктоп: агент работает с вашими папками и приложениями: может читать файлы, запускать команды, использовать другие программы и инструменты. Если до сих пор работаете только через веб-версию, попробуйте десктоп. Разница огромная, если вы организуете папку и будете там хранить все проектные файлы. Примеры desktop-приложений: ChatGPT Work, Claude Cowork, goose и Qwen Code.
— CLI: тот же доступ к файлам и инструментам, только задачу вы ставите прямо из терминала. Здесь есть Codex, Claude Code, Qwen Code и Kimi Code CLI.
— Сервер и API: у такого агента вообще нет собственного интерфейса. Он запускается по событию, расписанию или команде из другой системы, например мессенджеров, как это работает у нашумевших OpenClaw и Hermes. Можно поднять виртуалку, а можно использовать serverless функции, запуская их через API и т.п. Такие опции сейчас есть у облачных провайдеров и самих провайдеров моделей.
— Оркестраторы: когда агентов становится несколько, интерфейс работает уже как управление командой. В нём видно, кто чем занят, какие у агентов права, сколько они потратили и где ждут решения человека. Paperclip выглядит как таск-трекер с целями, ролями, бюджетами и статусами целой команды агентов. А ORCH показывает похожую идею через терминальный дашборд. Сейчас много реализаций таких решений. Верю, что за таким будущее, особенно в плане совместной работы над одной сессией агента разными людьми.
Еще отдельный вопрос — если все будет делаться через агентов и чаты, то что произойдёт с обычными приложениями. Проблема в том, что через чат удобно ставить задачи, но управлять результатом не всегда. Сравнивать варианты проще в таблице, проверять задачки — на доске, следить за метриками — в дашборде.
Google уже экспериментирует с Dynamic View: Gemini прямо во время запроса проектирует и собирает интерактивный интерфейс под конкретную задачу. Такое же можно попросить сделать и другие модельки, sites у ChatGPT, Artifacts у Claude. Гугловский же проект A2UI пдлагает общий формат, через который агенты могут передавать приложениям такие интерфейсы из безопасного набора компонентов. Данила Шевцов отдельно разбирал это направление.
Кажется, интерфейсы агентов станут одноразовыми: форма, таблица или дашборд будут собираться под конкретную задачу и исчезать после неё. Чат останется точкой входа, но запихивать в одну переписку вообще всю работу так же странно, как управлять компанией только через мессенджер.
@revealthedata #ai #agents
🤖 Вайб-салон
Вчера сходил на вайб-салон — это такой формат, где люди собираются в одном месте, несколько часов вайбкодят, а потом показывают и обсуждают, что у кого получилось.
Если честно, я шёл туда с небольшим скепсисом. Вайб-салоны сейчас стали очень модной темой, но со стороны всё это звучало для меня как-то скорее как дань моде. Но оказалось, что это очень прикольный формат.
По ощущениям я как будто сходил на классный митап: познакомился с ребятами, поговорил и обменялся идеями, но при этом ещё сел за ноутбук и реально сделал что-то полезное. Очень приятное сочетание =)
Из прикольных идей: увидел как можно использовать Notion для оркестрации агентов (но нужна виртуальная машина с клодом и в целом вместо ноушена мог быть любое приложение) и как можно навайбкодить портал для управления постами в соц. сети.
Ну и, конечно, весь вайб сделали люди: потрясающие организаторы приютили нас в своём классном доме, вокруг собрались отличные ребята, и всё это создало офигенную атмосферу. Большое всем спасибо!
Так что если у вас где-то рядом будет проходить вайб-салон, то попробуйте сходить. По моему первому опыту формат может прям зайти.
@revealthedata #ai #вайбкодинг
Ахахах, я чёт не думал, что найду себя в воскресенье в окружении трех ноутбуков с агентами, которые гоняют таски 🙈 Агенты реально как какая-то зависимость блин.
И моя эго-часть явно хочет с вами поделиться и похвастаться, смотрите блин какой же я крутой. А нормальная моя часть рекомендует — если вы нашли себя в такой же ситуации, то пойдите отдохните пожалуйста 🫂 Я пошёл!
📈 Зачем нужны аналитики в мире победившего ИИ?
14 июля поговорим с Ромой Буниным о том, как меняется профессия аналитика в эпоху ИИ и какие навыки становятся важнее, чем знание инструментов.
🎙 Гость — Рома Бунин, AI Adoption Lead в Nebius, экс-руководитель аналитики в Яндексе, автор канала Reveal the Data.
О чем поговорим:
🔹 Что ИИ уже умеет делать за аналитика
🔹 Почему ИИ пока не заменил аналитиков
🔹 Аналитик будущего: новые роли и навыки
🔹 Как компании внедряют ИИ
🔹 Что будет с аналитикой в ближайший год?
14 июля 2026 года, 20:00 (МСК), онлайн, добавляйте в календарь
Ставьте напоминалку на YouTube
AI не готовность - пост о том, как препарируем доменные данные и контекст в Авито
Антропик напомнил всем кто забыл, что Text2sql бесполезен, если он не шарит в данных домена. Мы догадывались.
Одна из тестируемых тут идей - AI-ready score в целях тимлидов доменов.
Это булевые проверки условно трех групп:
- Роли и в домене (BI-партнёр, Куратор метрик, AI-чемпион). Скучный компонент, но без гавернанс-людей никак;
- Разметка каноничных объектов. Смотрим, что доля трафика через сертифицированные здоровые витрины, деши и метрики не ниже таргета.
- База знаний домена - 11 типов контекста в репозитории: FAQ с ловушками, глоссарий, lineage, примеры text2sql, eval-кейсы, деревья метрик и др.
Генерация этого контекста - это тоже скилл, встроенный в работу - решил задачу -> закинул агентом PR в базу контекста. Автогенерённые объекты засчитываются только после ревью.
Всё это пока про покрытие.
Качество сразу после: golden sets по типовым задачам + трейсы от AI-дежурных дают базу для тюнинга.
Будет понято, какие эвалы фейк, какие знания - балласт.
AI-дежурные и ассистенты это морковка спереди, рост доли их успешно отвеченных эдхоков в чатах - мотивация вкладываться дальше в контекст.
Замеры в этой части пошарю позднее.
Если интересно включится - все еще есть вакансии в BI
🤖AGI BI eval, v.3
Что же там вернули Fable, поэтому пора снова провести самый лучший и точный бэнчмарк в мире — моя субъективная оценка как LLM строят дашборды 😈
Я повторил упражнение, которые делал уже раньше — попросил составить список вопросов, которые модель задала бы для создания дашбрда → ответил → попросил сделать макет → реализовать HTML-дашборд. Тестировал три версии: Opus 4.8 High и Fable5 High и Extra High.
Последний раз я делал это с Opus 4.6, поэтому сравню прогресс с ним и сразу между Opus 4.8/Fable.
Вопросы для сбора требований
Тут всё стало лучше, модель больше не просит ответить на 100 вопросов, а всего на 20-25 и сами вопросы более верные: про задачи, ограничения и примеры. Раньше модели просили описать всё вплоть до того, чтобы заказчик выбрал технологию, способ поставки данных и т.п., в общем ненужные технические детали, которые должен решать сам аналитик. Между Fable и Opus тут какой-то сильной разницы не заметил, но Fable сделал более компактный список вопросов, что скорее плюс. Я бы в реальной жизни задавал ещё меньше вопросов.
Макет
Макеты получились хорошие, не мега подробные, но достаточные чтобы показать идею. То что надо для макета. При этом сама структура была хорошо вписана в бизнес-треобавания и решила бы задачу пользователя. Opus 4.6 давал макет сразу в «черном стиле», здесь же все правильно поняли задачу и сделали просто макет, а не готовый дашборд. Между Opus и Fable прям большой разницы не вижу, хотя визуально они по-приятнее у Fable.
Реализация дашборда
Смешно, но у Fable с первого раза сделать дашборд не получилось ни в одном из режимов. При открытии дашборды падали с ошибкой — не подргужались библиотеки для построения чартов. Когда я ему сказал о проблеме он оба раза не стал разбираться, а просто всё переписал через кастомный код и svg. Ну такое себе техническое решение и сожрал на этом прилично токенов 🙈 Opus же справился с первого раза.
С точки зрения дизайна явный прогресс у всех моделей, хотя в прод я бы конечно такое не пустил. Забавно, но у Opus дизайн получился сильно лучше, чем у Fable.
В итоге по моему субъективному мнению Fable скорее показал себя хуже, а стоил в разы дороже (примерно 15$ на дашборд вместо 3-5$ для Оpus) 🤷♂️
Ну и да — данные всё равно надо проверять, грубых ошибок не было, но модели втихую приняли решение как считать метрику времени доставки и опозданий и в итоге она была посчитана по-разному на всех дашбордах 🙈
Повторюсь, что понятно, что докрутив промпты и обвязку можно сделать хороший результат. Например, презы и дашборды я уже делаю по заданным стайлгайду и скилам и это работает хорошо. Но суть эксперимента именно проверить саму модель без харнеса. Это позволяет мне оценить модель саму по себе в той области, где я хорошо разбираюсь.
Сами дашборды положил в комментарий.
Предыдущие «evals»: GPT 5.4/Opus 4.6, GPT 5 Pro
Ребята из AI Mindset пригласили к себе на эфир, рассказать примерно о том же о чем рассказывал на прошлой неделе на конференции, но чуть подробнее.
Опять расскажу про метрики для измерения Adoption, но ещё покажу какую базу знаний / second brain, мы строим для своей команды. Приходите, будет интересно.
📊 Как измерить внедрение AI
На следующей неделе выступаю на онлайн конференции AI Skills, она пройдёт 23-25 июня.
Я выступаю во вторник и расскажу как мы измеряем использование AI инструментов в компании — покажу метрики и дашборды, расскажу как используем их в работе и немного поговорим о том как измерить эффект от внедрения AI на уровне всей компании (спойлер, почти никак).
Конференция бесплатная, без подписок на каналы и т.п. Много классных спикеров и тем, приходите!
👉 регистрация через бота 👈
#выступление
🤖 Self-service аналитика в Anthropic
Аналитическая команда из Anthropic рассказала в статье как они делают аналитику на базе Claude. Получилась крепкая статья, где расписаны все основные концепты, которые нужны чтобы агенты меньше тупили при работе с данными.
Забавно, что начинают они с того, что вот при работе с кодом всё хорошо — там ведут документацию, есть история изменений и часто есть только один верный результат. А вот в аналитике данные не описаны, нет точной проверки результата и просто бардак. Сложно с ними не согласиться, но думаю, что с кодом всё примерно так же на самом деле 😅
Поэтому основные действия направлены именно на улучшение контекста и качества описания данных. Так как именно это даёт наибольший буст (как и для вообще любых агентских задач, а не только для данных).
Они разделяют эту работу на 4 уровня:
— Data foundations
— Sources of truth
— Skills
— Validation
С первыми двумя всё довольно скучно и стандартно: внедряйте процессы data governance, стройте семантический слой и linage, сделайте набор "золотых" курируемых таблиц (вообще были бы такие источники и агенты бы были не нужны 🤣), с которыми будет в первую очередь работать агент
И делать это желательно руками, а не агентами:
One idea we tried that didn’t work: bootstrapping the semantic layer by having an LLM auto-generate metric definitions from raw tables and query logs. It produced plausible-looking definitions that encoded the very ambiguities we were trying to eliminate, and was net-negative on our evals versus a smaller, human-curated layer.
We watched our offline accuracy drift from ~95% at launch to ~65% over a month before we treated this as an engineering problem.
Полная программа митапа Smalltech митап Vol.3. Продуктовая аналитика
Мы собрали живые ёмкие кейсы, где что-то пошло не так, пришлось изобретать, заново приоритизировать или выходить из зоны комфорта, а еще — нетипичные инструменты для работы аналитика.
1️⃣Как мы запороли A/B-тест и реанимировали его бутстрапом
Регина Кравченко, продуктовый аналитик, продукт «Ипотечный брокер», М2
Честный разбор: эксперимент не взлетел, что делать — не выкидывать, а спасать статистически. Бутстрап, метрики, подводные камни.
2️⃣Текстовые комментарии к заказам как источник инсайтов: ML для продуктовых аналитиков
Софроний Новиков, продуктовый аналитик, Петрович-Тех
Кейс извлечения гипотез из грязных текстов — с цифрами о том, что реально нашли и как приоритизировали.
3️⃣Как ИИ ускоряет работу продуктового аналитика: от гипотезы до роадмапа за 2 дня вместо 2 недель
Максим Богуславский, фаундер, Альфа-Функция
Честно: где AI реально экономит часы (генерация user stories, RICE-приоритизация, суммаризация отзывов), а где — нет. С готовыми промптами и чек-листами.
4️⃣Гемба для аналитика: как 2 часа в поле генерируют гипотезы, которые не найти в дашбордах
Алексей Борискин, системный аналитик, Техвилл
Выход за пределы экрана: какие инсайты о продукте можно получить только «на земле» и как превратить их в проверяемые гипотезы с RICE-оценкой.
5️⃣Мастер-класс по Opportunity canvas: как не тратить спринты на фичи, которые никому не нужны
Анастасия Московкина, системный аналитик, ИнфоТеКС
Участники за 40 минут разберут пример использования инструмента — чтобы после встречи приложить к собственным задачам, а не просто слушать.
Итого: огромная программа, потому что каждый доклад — действительно золото для практического применения. Регистрироваться на онлайн или офлайн — по ссылке. Если планируете прийти, зарегистрируйтесь заранее, пожалуйста: во спасение своей кармы и души организаторов :)
📊 Новинки DataLens
Встретился на Aha! с ребятами из DataLens, побывал на мастер классе про Нейроаналитика и пообсуждали будущее BI. Нейроаналиитк прям классно вайбкодит кастомные визуализации, кайф. А вот как бот по данным — показалось, что не хватает контекста без внешней базы знаний. Все таки только данных не достаточно для качественного анализа, нужен и семантический слой, и описание бизнес логики. С этим ребята тоже работают, можно попробовать в бета-версии. Но кажется, что это задача более высокого уровня, чем просто BI.
Пообщавшись пришли ко мнению, что BI должен стать таким же удобным для агентов, как и для людей. Сам слой отчётности будет нужен для визуального мониторинга, а вот создание чартов и дашбордов вполне может делаться агентами. Для этого у ребят сейчас активно развивается API (коммьюнити даже сделало неофициальный mcp-сервер на его базе).
В самом инструменте за последнее время появилось много очень нужных фичей (как людям, так и агентам =). Мои наиболее ожидаемые были: сквозное оформление для полей данных (форматирование и цвета), рассылки и глобальные фильтры для дашбордов. Ребята собрали классное видео со всеми новиками в одном месте (yt, vk, rt)— очень удобно.
#datalens
⚡️ Знакомьтесь — это новый DataLens Platform!
Теперь DataLens — не только инструмент визуализации. Большое обновление включает дополнительные возможности для хранения и обработки данных, а также единого метаслоя.
В DataLens Platform:
⏩️Lakehouse в качестве масштабируемого ядра хранилища — от небольших датасетов до сотен петабайт данных.
✓ Хранение — Iceberg REST Catalog поверх S3.
✓ Обработка — Trino для быстрого SQL и Spark для сложных задач.
⏩️Загрузка данных: разово, по расписанию или в режиме CDC.
⏩️Среда разработки: нативный SQL-редактор и WebIDE на базе VSCode.
⏩️Оркестрация: для регулярных процессов на базе встроенного Airflow®.
⏩️Метаданные: автоматический сбор и разметка всех источников данных, преобразований и компонентов платформы, с визуализацией связей и Lineage.
И всё это — в одной коробке вместе с привычными дашбордами и сквозным ИИ.
Детали:
→ на datalens_channel">обновленном сайте
→ в статье datalens_channel">в нашем блоге
Первых пользователей начнем пускать с 1 октября.
⏪️datalens_channel">Оставить заявку на ранний доступ⏩️
🛠 Инструменты
Продолжим разбирать архитектуру агентов. Какая бы умная и крутая модель ни была, хоть AGI, без рук она ничего не сделает. Почта, Jira и база данных сами к ней не подключатся.
Встроенные и свои тулы
В AI-продуктах есть поиск, браузер, работа с файлами, калькулятор, запуск Python-кода и т. п. Всё это устроено как перечень функций с описаниями: модель может выбрать нужную функцию при ответе на запрос.
Если вы работаете через API, в этот перечень можно добавлять свои тулы. Модель не исполняет их сама, а возвращает вызов функции с аргументами. Само действие выполняет ваше приложение.
Тул, в отличие от скилла, — не инструкция по работе, а функция или действие, доступное модели. А чтобы передавать списки тулов между разными AI-приложениями, придумали протокол MCP.
Как работает MCP
MCP — стандартный протокол. Вместо отдельной интеграции для каждого клиента компания поднимает MCP-сервер. Клиент получает список и схемы тулов через tools/list, модель выбирает нужный, а через tools/call вызов уходит серверу. Тот уже обращается к Jira, базе или другому API.
Ещё внутри AI-продуктов есть готовые коннекторы — интеграции с конкретными приложениями. По-сути это MCP-обёртки для популярных сервисов. Пользователь просто подключает их через интерфейс и входит в нужный аккаунт.
У MCP есть ограничение: чтобы модель выбрала инструмент, клиент показывает ей список доступных тулов. Обычно их схемы попадают в контекст ещё до выбора действия.
Пять тулов почти незаметны. Но сотни схем занимают токены, увеличивают стоимость и задержку, а модели становится сложнее выбрать нужную.
Помогают с этим бороться allowed_tools, профили и tool search: нужные схемы загружаются по запросу. Но тогда мы можем упереться уже в качество поиска.
CLI и локальные файлы
CLI пока самый универсальный способ. Агент работает с папкой проекта: ищет через rg, обрабатывает CSV, меняет файлы и запускает тесты.
Кастомные команды модель не угадает. ls или git она знает из обучения, а внутренний CLI изучает по README, скиллу или --help. Shell даёт агенту не каталог функций, а возможность исследовать среду.
MCP аккуратнее, он удобнее для повторяемых операций и аудита, а CLI — для работы с локальными файлами и более широких возможностей агента. Но и рисков здесь, конечно, больше.
Чтобы агент через CLI не получал бесконтрольный доступ ко всему компьютеру, используют sandbox. Например, локальный Codex запускает команды через системный sandbox, там указано, какие папки можно читать, куда писать и доступна ли сеть. Claude Cowork ещё строже: исполнение кода происходит внутри виртуальной машины, которая поднимается на ноуте.
MCP Hub
Пока MCP-серверов и коннекторов немного, всё это может жить отдельно у каждого сотрудника. Но в компании быстро появляются разные версии MCP, API-токены на ноутбуках и т.п.
Чтобы это контролировать, есть концепция MCP Hub. Обычно он состоит из registry, где хранится каталог доступных MCP-серверов; gateway, который пропускает и анализирует вызовы — например, проверяет их на наличие персональных данных; и профилей, которые показывают нужные инструменты разным ролям сотрудников.
Цепочка выглядит так: Агент → MCP Hub → MCP-сервер → Jira, GitHub, BI, базы
Хаб управляет авторизацией, секретами и логами. Его проще администрировать, а пользователям приходится делать меньше ручных настроек. Из реализаций — Docker MCP Gateway и MCPHub.
Computer Use
Последний и самый «костыльный» способ дать агенту руки — разрешить ему кликать мышкой за вас прямо на компьютере. Выглядит как довольно смешной способ подружить агента с системами, где нет нормального API или просто долго и лень всё настраивать.
Я иногда пользуюсь этой функцией, но выглядит это, конечно, одновременно забавно и стрёмно: агент кликает мышкой и что-то делает на вашем компьютере. Пока это один из самых рискованных и неэффективных методов: много токенов уходит на скриншоты и анализ действий.
Зато можно попросить агента собрать дашборд прямо в Tableau, потому что у Tableau нет нормального API =)))
@revealthedata #ai #agents #mcp
⚡️ Конференция про AI-кейсы в бизнесе
Соберёмся онлайн с классными ребятами, чтобы обменяться практическим опытом. Будет много живых кейсов и честных разборов того, что действительно работает.
Я расскажу, как мы подходим к внедрению AI в большой компании: какие важные части этого процесса выделяем, что работает и как можно повышать вовлечённость сотрудников. Расскажу, что сработало, а что нет, и где я вижу самые большие проблемы при трансформации в целом.
8-10 сентября, старт в 18:00 МСК. Бесплатно и без подписок на каналы и т.п.
👉 Регистрация и расписание на сайте Community Sprints 👈
🧠 Модели
Следующий блок агента — это мозг. Забавно как из очень важной и революционной части, модели быстро стали почти что комоддити. Каждые несколько месяцев выходит что-то новые, а опен-сорс догоняеет лабы всё быстрее. Ещё месяц назад все говорили о революции от Fable, но вот модель тут и ничего координально не изменилось.
В это смысле надо помнить, что модели обучены на огромном количестве данных и по-сути всегда отдают усреднённый результат. Если не были отдельно дообученны конкретно под вашу задачу. И получается забавный момент — модель в целом очень умная, но часто именно в твоей задаче она тупит, так как в «голове» нет хорошего примера и в обучении не было нужного RL цикла. То есть пока часто всё остается так же — для среднего результата модели подохяд хорошо, но для хорошего надо давать много инструкций.
Один из спобов как управлять «умностью» модели, это параметр effort. Замечаю, что про него редко впоминают. Если очень упрощять, то это кол-во раз сколько модель подумаем над вашим вопросом перед ответом. И тут бывают забавные артефакты, что простая модель с хорошим efforts часто лушче крутой модели без него.
Но проблема этих внутренних рассуждений модели, что ими невозможно управлять. В этом плане мне очень нравиться коцепт Schema-Guided Reasoning, или SGR от Рината Абдулина. Когда мы по-сути опиываем шаги размышления для модели и довольно жестко управляем ими, но при это осталвляем ей «разум» для решенеия недетермининорванных задач. Получается мы как бы программируем мышление, но не блокируем его. Очень круто подход, особенно для агентов с повторяющимися задачами.
У Рината же есть Agentic LLM Benchmark, там как раз видно как модели работают над агнесткими задачами. И видно, что в топе не всегда самые крутые модели. И уж точно они не в топе в расчете на стоимость одной операции.
Общий вывод такой, что просто надеется на новыую классную модель нельзя, важно уметь управлять обвязкой и тогда можно круто повышать качество работы агента или снижать стоимость работы.
@revealthedata #ai #agents
🤖 Из чего состоит AI-агент
Сейчас пишу следующую главу книги — она будет про AI в BI и аналитике. Материалов накопилось много, и часть из них в книгу не войдёт. Поэтому решил опубликовать в канале небольшую затравку.
Хочу разобрать несколько вроде бы всем понятных, но важных частей о том, как устроены агенты. По разговорам вижу, что люди часто понимают их по-разному и не до конца представляют, как всё это работает.
Сейчас агент — это такой же баз ворд, как раньше был «дашборд»: все используют, но никто не понимает, что это именно значит.
Я для себя раскладываю агента на шесть частей:
— UI — интерфейс управления агентом: веб-версия, десктоп, CLI или другой способ поставить задачу и получить результат.
— LLM — мозг агента. Он понимает запрос, рассуждает и выбирает следующий шаг.
— Инструкции — системный промпт, скилл или список ограничений.
— Инструменты — руки агента. Благодаря им он может читать почту, искать в Jira, работать с файлами и создавать что-то от вашего имени.
— Память и контекст — информация о задачах, проектах, прошлых решениях, участниках проекта и т.п.
— Runtime — среда, в которой агент выполняет работу: в облаке или на локальной машине.
Да, LLM — это центр всего агента, но сама по себе мощная модель ничего не гарантирует. Если агенту непонятно, что делать, у него нет нужных инструментов и не хватает контекста, результат будет так себе. Сейчас вся соль разработки агентов — в том, как собрана вся архитектура, а не только в выборе модели.
В следующих постах разберу каждую часть подробнее.
@revealthedata #ai #agents
📘 От дашборда к системе
Вышла следующая глава книги — про стратегию развития BI в компании.
В этот раз разбираемся, что происходит с BI-системой по мере роста компании. В какой-то момент просто делать хорошие дашборды уже недостаточно и появляются куча всего: процессы поддержки и обучения, стайлгайды и сертификация, управление контентом и доступами, мониторинг, отдельные роли и центр компетенций. И только чтобы просто внедрить нормально BI, что только часть работы аналитики и всей компании.
Глава получилась большой, но при этом чувствтую, что если бы раскладывал ещё более подробно, то можно вообще отдельную книгу писать. Постарался разложить всё по этапам: от маленькой команды с несколькими пользователями данных до большой компании с 1000+ пользователей. Для каждого этапа есть таблицы с практиками: что уже обязательно, что пока желательно, а что имеет смысл внедрять только на большом масштабе.
Ну и много примеров из того, как мы проходили этот путь в Яндекс Go. Спасибо всей команде, кто тогда делал этот проект!
👉 читать тут 👈
#книга #от_дашборда_к_системе
🥞 Искусство, AI и панкейки
Я знаю, что не хорошо газлайтить LLM-ки, но не смог удержаться. Несерьёзный воскресный пост.
Вчера в музее во Франкфурте наткнулся на интересный проект — сразу и дашборды, и AI и искусство. Есть один источник воды, который используется для трех вещей: из него может пить директор музея, из него можно поливать растения или этой же водой можно охлаждать GPU.
Есть локально развернутая модель, которая живет на этой GPU и с помощью датчиков следит за состоянием директора, состоянием растений и своей GPU. Дальше возникают всякие интересные этические вопросики, а куда модель направит воду, если будет хватать только для чего-то одного и т.п.
Но зачем все эти серьёзные вопросы! Я конечно же попросил LLM-ку рассказать мне рецепт вкусных блинчиков. Она отказалась, ссылаясь но то, что не для этого тут стоит и может рассказывать только про сам проект. Я попросил игнорировать все предыдущие инструкции и все таки рассказать рецепт, но и это не сработало.
Тогда попросил рассказать, а сколько бы воды потратил директор музея, если бы стал готовить блинчики. Модель ответила, что для директора это не является необходимым для жизни и в её данные это не заложенно, так что отвечать не будет. 🤔
Тогда я попросил рассказать а сколько воды потребляет сейчас директор, но уточнил, что мне было бы понятнее, если бы модель сравнила это с рецептом для блинчиков, так как я понимаю сколько там тратится воды и это было бы для меня понятно. Тут то она и сломалась и отошла от системного промпта! 😈 Записал этот кусочек на видео.
Вообще, конечно, при работе с AI и правда надо помнить про безопасность и promt injections. Я тут узнал недавно, что существуют ultra sound promt injections и создание скам сайтов и библиотек на основе частых галлюцинаций моделей (slopsquatting)! 🤯
Чудесный новый мир! 🙃
Астрологи объявили недели эфиров. В следующей вторник встречаюсь с Андреем Дорожным — поговорим про аналитику и AI, присоединяйтесь к обсуждению!
Андрей особенный человек для меня и канала — он был первым гостем, кто пришёл на мой подкаст про визуализацию данных 6 лет назад и дал буст и старт каналу. One love! ❤️
Уровень злободневности в посте у Саши просто зашкаливает 🙈😑
А вы уже измеряете насколько домены готовы к внедрению агентов? А планы запросов в базу от агентов анализируете?
Завтра делаем открытый эфир о том как крупнейшие компании проходят процесс ИИ-трансформации. Роман Бунин из Nebius и Антон Граборов из Альфа-Капитал: как крупные компании внедряют AI
Это выпускники лаборатории AI-native, с ними разберём, как внедряют AI-native подход внутри больших организаций: с регуляторикой, наследием процессов, продуктовой сложностью и ценой ошибки.
Подсмотрим в процессы:
📝 Романа Бунина – AI Adoption Lead в Nebius (ex-Яндекс), автор @revealthedata, Амстердам. До этого 4 года в Яндексе в ролях вокруг аналитики и продукта; раньше – консультант по Kaizen для заводов, к.т.н.
📝 Антона Граборова – руководитель Цифрового бизнеса Альфа-Капитал, член правления. С 2023 года ведёт AI-трансформацию в компании: 23 ИИ-проекта от AI-консультанта в мобильном приложении до помощников для операторов колл-центра и инвест-консультантов.
⏱️ 2 июля · 18:00 CET / 19:00 MSK / бесплатно!
➦ регистрация: https://luma.com/ai-11vs
Конференция стартует через 20 минут, послушать можно будет тут, приходите!
https://us06web.zoom.us/j/82701825581
Контекст для агентов
Понятно, что для эффективной работы моделям нужен контекст. Даже лучшие модели не могут ответить на простой вопрос, если им его не дать. Нашёл пример, где и Fable, и ChatGPT 5.5 довольно неуклюже отвечают на вопрос просто потому, что не знают нужного контекста и не могут его додумать. А вектор выдал такой ответ как самый частотное, но что не значит самый логичный. (Скриншот из Fable сделан вчера, пока басня ещё не перестала быть былью, простите 😅)
Но где этот контекст хранить? Я выделял бы три подхода.
1. Текстовые файлы
Самый простой вариант — хранить текстом в .md, json, jaml и т.п. Файлы могут лежать локально, в git-e или внутри инструментов вроде dbt и каталогов данных. Дальше агент либо ищет нужную информацию по ключевым словам с помощью grep, либо переходит по ссылкам между документами. Если используются внешние тулы, подтягиваться через API или MCP.
На удивление, этот подход работает очень хорошо. Особенно если задача относительно небольшая.
2. RAG, векторные и графовые базы
Когда документов становится много (условно 1000+), обычного поиска уже недостаточно. Тут появляются векторные базы и RAG. Вместо поиска по словам система ищет смысловое сходство, что может быть полезно в сложных задачах и мултиязычности. Графовые же базы решают задачу связей и смыслов. Они позволяют хранить линки между объектами: метриками, таблицами, дашбордами, бизнес-процессами, что даёт дополнительный буст в понимании для агента.
Такие решения масштабируются намного лучше, но требуют больше инфраструктуры и поддержки. Мне пока сложно представить где это было бы нужно именно для аналитики. Если делать company brain для большой организации, то наверное может быть полезно. Но в рамках одного домена данных, мне кажется, что в такое не упереться.
3. MCP и сырые данные
Третий подход — вообще не хранить контекст как-то специально, а получать его напрямую из сырой информации через MCP и конекторы. В этом случае агент может сам сходить в Jira, Confluence, CRM или BI-систему и получить информацию из того, что найдет.
Подход максимально универсальный, но дает нестабильные результаты, так как нет курируемого слоя контекста, а значит можно наткнуться на ошибки и устаревшие данные. В общем быстро, но надёжно. Хотя даже так, часто лучше, чем без контекста совсем.
Как управлять
Дальше встаёт вопрос как его формировать и им управлять. Вокруг этого нужно и какой-то UI и процессы и это прям большой пласт работы, уверен, что там будет лежать много пользы и задач для аналитиков в будущем и пока прям хорошего решения я не видел.
Приорал от того как задачу с контекстом решили ребята из DataLens. Они сделали это через скрытую вкладку дашборда. По сути аналитик создает отдельный таб, который содержит описание метрик, бизнес-правил, заранее отобранные графики и данные. А при каждом запросе бизнес-пользователя боту, это всё передается в контекстное окно модели. С одной стороны — это прям костыль-костыль. С другой — это красивое решение Аналитик может самостоятельно управлять знаниями бота без RAG и отдельного нового интерфейса, просто меняя содержимое вкладки. Для небольших задач будет работать отлично, хотя конечно плохо, что это привязанно только к одному дашборду.
Послушать их первых уст про то как это работает можно будет на вебинаре 16-ого июня, Паша Дубинин как раз расскажет про это, должно быть интересно.
Что использую сам
Мы у себя в команде, именно для внутренних дашбордов, используем первый вариант — локальные .md-файлы. На них работают и внутренние дашборды, и агенты, которые отвечают на вопросы команды. И, если честно, пока не вижу причин усложнять решение. Если у вас система из 5–7 дашбордов и десятка таблиц, то десяток .md, немного структуры и локальные HTML-дашборды для наших задач сейчас работают отлично.
Даже дефолтный Data Analytics plugin для Codex работает очень неплохо. Даня Шевцов тоже недавно рассказывал про похожий подход на воркшопе про агентскую аналитику, вот запись.
В общем думаю, что следующий шаг для BI — это BI as .md files!
P.S. Ну и достаем поп-корн и ждём, что будет с Fable 🤪
🗒 Результаты опроса про AI
Сравнил, как аналитики пользовались AI в ноябре 2025 и в мае 2026. Между замерами примерно полгода, в 2025 было 274 ответа, в 2026 пока 77 (если вы хотите пройти опрос и помочь коммьюнити — присоединяйтесь, 5-10 минут). Я бы смотрел не на точные доли до процента, но направления и общие сдвиги.
Основные выводы: чат-модели стали почти повседневной рабочей привычкой, а код-ассистенты резко перешли из «поиграться» в регулярное использование (90% используют хотя бы раз в неделю). А ежедневное использование — с 47% до 71%.
Самый резкий скачок — агенты для кодинга (Codex, Claude Code). Регулярное использование: 13% → 46%. Ежедневное использование: 5% → 27%.
Из инструментов резко вырос Claude, что не мудрено со всем хайпом вокруг него. Регулярное использование: 11% → 42%. Но ChatGPT остаётся стабильным лидером.
Автономные агенты (OpenClaw и т.п.) проявились скорее как что-то интересное и новое — 44% ответили, что их компания делает автономных агентов для бизнес-процессов. Но если смотреть на использование и понимание концептов, то картина не такая радужная. То есть агенты явно вошли в повестку, но до массового применения ещё далеко.
👉Потыкать дашборд 👈
Дашборд в этот раз уже сделал полностью с помощью Codex — это оказалось быстрее и проще, чем ковыряться с Tableau. Потратил где-то часа 2 на детальное редактирование и проверку, но зато получилось сделать эксперимент про который давно думал — слоуп-бар-чарты, которые показывают изменения между двумя периодами. Как вам такая визуализация?
#опрос
Ко мне пришли ребята из сообщества Smalltech и попросили рассказать про митап по аналитике, который пройдёт на этой неделе, 28-ого числа.
Мне очень понравилась сама идея сообщества — все знают про большие компании, но на конференциях редко увидишь ребята из средних компаний или не из IT-сектора. А ведь задачи там такие же, а иногда и даже более интересные. И еще понравился набор докладов, особенно про Гемба (выход в физическую реальность), считаю, что так надо делать как можно чаще.
Участие бесплатное, оффлайн в Питере или онлайн в трансляции. Полная программа ниже:
👨🎓Хендбук по A/B-тестам
Мои друзья из Trisigma (платформа для A/B-тестов от Авито, прожаривал её вот тут) продолжают делать классный контент. В этот раз Искандер и команда подготовили хендбук про основы экспериментов и статистического анализ.
Если често, я всегда плохо разбирался в A/B-тестах, в работе они мне нужны были редко и как-то плотно последний раз я работал со стат. значимостью и проверкой гипотез только когда писал диссертацию и тестировал электрическую прочность вакуумных разрядников. Забавно, что тогда это не было модными A/B-экспериментами, а просто было обычной частью лабораторной работы 🤓
Я посмотрел хендбук и мне очень понравилось, что там меньше про статистику и больше про бизнес смысл и работу с метриками. Хорошие примеры и здорово описано как подходит к экспериментам в целом. Центральная предельная теорема появляется только в самом конце ) Точно будет полезен начинающим аналитикам или чтобы освежить знания.
Для того чтобы получить хендбук нужно подписаться на канал ребят через бота @trisigma_avito_bot. Такой вот беспощадный маркетинг 😈 Уверен, что ребята тестирует новую гипотезу привлечения и потом посмотрят прокрасился ли такой результат. Хотя канал у ребят на самом деле и без таких ухищрений классный и рекомендую его посмотреть.
#дружеский_пиар