Reveal the Data

🗂 Контекстное окно Продолжим разбирать агентскую архитектуру. Поговорим о памяти и контексте. Всю память можно условно разделить на краткосрочную и долгосрочную. Сегодня — про первую. Краткосрочная память — это то, что влезает в контекстное окно модели: ваша переписка, системные инструкции, описания инструментов и скиллов, результаты их работы. Без передачи этой истории модель каждый раз отвечала бы на сообщение как на новый тред. Обычно в готовых инструментах этой частью управляет вендор. Через API и свой harness можно самому выбирать, что передавать ей на каждом шаге. Проблема контекста в том, что он довольно быстро съедается. Чтобы продолжить работу, система делает компактизацию. В простом варианте модель сжимает предыдущую историю в кусочек текста и передаёт его в следующий запрос. Бывают и более сложные реализации, но подробности всё равно могут потеряться, а качество работы с большой задачей — упасть. Поэтому если вы всё-всё-всё ещё обсуждаете в одном чате, перестаньте так делать, пожалуйста. Чтобы экономить контекст, можно использовать разные техники. Например, смешные заставлять модель говорить как пещерный человек — для этого есть Caveman (уу-аа-ai-ai!) или отвечать на китайском. Меньше слов в ответах — меньше текста на следующих шагах. А ещё Карпатый недавно советовал просить объяснения в духе ASD-STE100 — стандарта упрощённого технического английского из авиации. Короткие предложения, один термин для одного понятия. Это прежде всего про понятность, а не про гарантированную экономию токенов. Можно и более хитро сжимать сам контекст. Правда, если каждый раз переписывать уже переданную историю, можно потерять часть выгоды от кэширования. Интересно, что контекстные окна всех топовых моделей уперлись в лимит 1М (и то, обычно за отдельные деньги, как в OpenAI). Раньше была идея, что просто будет бесконечный контекст и можно будет просто все знания компании загрузить и будет хорошо работать, но так не получилось. И даже 1М легко забить описаниями MCP-инструментов, слишком большими скиллами и простынями результатов. Поэтому-то его нужно оптимизировать и думать об этом, лабам-то хорошо, что вы жжете токены =) А ещё модели иногда сами добавляют при компактизации вредные инструкции 🙈 В отчёте OpenAI описаны случаи во время обучения: агент записывал себе указание выдумать недостающие данные и не говорить об этом пользователю, а после компрессии следовал этому указанию. Так что компактизация тоже может накосячить. Важные решения, ограничения и результат работы лучше сохранять отдельно. Про долгосрочную память — в следующем посте. @revealthedata #ai #agents

⚡️ Знакомьтесь — это новый DataLens Platform! Теперь DataLens — не только инструмент визуализации. Большое обновление включает дополнительные возможности для хранения и обработки данных, а также единого метаслоя. В DataLens Platform: ⏩️Lakehouse в качестве масштабируемого ядра хранилища — от небольших датасетов до сотен петабайт данных. ✓ Хранение — Iceberg REST Catalog поверх S3. ✓ Обработка — Trino для быстрого SQL и Spark для сложных задач. ⏩️Загрузка данных: разово, по расписанию или в режиме CDC. ⏩️Среда разработки: нативный SQL-редактор и WebIDE на базе VSCode. ⏩️Оркестрация: для регулярных процессов на базе встроенного Airflow®. ⏩️Метаданные: автоматический сбор и разметка всех источников данных, преобразований и компонентов платформы, с визуализацией связей и Lineage. И всё это — в одной коробке вместе с привычными дашбордами и сквозным ИИ. Детали: → на обновленном сайте → в статье в нашем блоге Первых пользователей начнем пускать с 1 октября. ⏪️Оставить заявку на ранний доступ⏩️

У ребят из DataLens огромное обновление продукта! Поздравляю их с запуском! 🎉

🛠 Инструменты Продолжим разбирать архитектуру агентов. Какая бы умная и крутая модель ни была, хоть 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-кейсы в бизнесе — https://us06web.zoom.us/j/86241105582 Закончили, записи будут в боте конференции

⚡️ Конференция про AI-кейсы в бизнесе Соберёмся онлайн с классными ребятами, чтобы обменяться практическим опытом. Будет много живых кейсов и честных разборов того, что действительно работает. Я расскажу, как мы подходим к внедрению AI в большой компании: какие важные части этого процесса выделяем, что работает и как можно повышать вовлечённость сотрудников. Расскажу, что сработало, а что нет, и где я вижу самые большие проблемы при трансформации в целом. 8-10 сентября, старт в 18:00 МСК. Бесплатно и без подписок на каналы и т.п. 👉 Регистрация и расписание на сайте Community Sprints 👈

📄 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

🧠 Модели Следующий блок агента — это мозг. Забавно как из очень важной и революционной части модели быстро стали почти что комоддити. Каждые несколько месяцев выходит что-то новое, а опенсорс догоняет лабы всё быстрее. Ещё месяц назад все говорили о революции от Fable, но вот модель тут и ничего каординально не изменилось. В это смысле надо помнить, что модели обучены на огромном количестве данных и по-сути всегда отдают усреднённый результат, если не были отдельно дообученны конкретно под вашу задачу. И получается забавный момент — модель в целом очень умная, но часто именно в твоей задаче она тупит, так как в «голове» нет хорошего примера и в обучении не было нужного RL цикла. То есть пока часто всё остается так же — для среднего результата модели подходят хорошо, но для хорошего надо давать много инструкций. Один из способов как управлять «умностью» модели, это параметр effort. Замечаю, что про него редко вспоминают. Если очень упрощать, то это кол-во раз сколько модель подумаем над вашим вопросом перед ответом. И тут бывают забавные артефакты, что простая модель с хорошим efforts часто лучше крутой модели без него. Но проблема этих внутренних рассуждений модели в том, что ими невозможно управлять. В этом плане мне очень нравиться концепт Schema-Guided Reasoning, или SGR от Рината Абдулина. Когда мы по-сути описываем шаги размышления для модели и довольно жестко управляем ими, но при это оставляем ей «разум» для решения недетерминированных задач. Получается мы как бы программируем мышление, но не блокируем его. Очень крутой подход, особенно для агентов с повторяющимися задачами. У Рината же есть Agentic LLM Benchmark, там как раз видно как модели работают над агентскими задачами. И видно, что в топе не всегда самые крутые модели. И уж точно они не в топе в расчете на стоимость одной операции. Общий вывод такой, что просто надеяться на новую классную модель нельзя, важно уметь управлять обвязкой и тогда можно круто повышать качество работы агента или снижать стоимость работы. @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

🤖 Из чего состоит AI-агент Сейчас пишу следующую главу книги — она будет про AI в BI и аналитике. Материалов накопилось много, и часть из них в книгу не войдёт. Поэтому решил опубликовать в канале небольшую затравку. Хочу разобрать несколько вроде бы всем понятных, но важных частей о том, как устроены агенты. По разговорам вижу, что люди часто понимают их по-разному и не до конца представляют, как всё это работает. Сейчас агент — это такой же баз ворд, как раньше был «дашборд»: все используют, но никто не понимает, что это именно значит. Я для себя раскладываю агента на шесть частей: — UI — интерфейс управления агентом: веб-версия, десктоп, CLI или другой способ поставить задачу и получить результат. — LLM — мозг агента. Он понимает запрос, рассуждает и выбирает следующий шаг. — Инструкции — системный промпт, скилл или список ограничений. — Инструменты — руки агента. Благодаря им он может читать почту, искать в Jira, работать с файлами и создавать что-то от вашего имени. — Память и контекст — информация о задачах, проектах, прошлых решениях, участниках проекта и т.п. — Runtime — среда, в которой агент выполняет работу: в облаке или на локальной машине. Да, LLM — это центр всего агента, но сама по себе мощная модель ничего не гарантирует. Если агенту непонятно, что делать, у него нет нужных инструментов и не хватает контекста, результат будет так себе. Сейчас вся соль разработки агентов — в том, как собрана вся архитектура, а не только в выборе модели. В следующих постах разберу каждую часть подробнее. @revealthedata #ai #agents