RTD: Ссылки и репосты

Как написать стратегию аналитики и зачем она нужна? Ура, я наконец-то закончил эту статью! Писал ее долго, потому что хотел сделать по-настоящему крутой гайд, в который вложил много сил. И теперь с радостью делюсь с вами. Эта статья для тех, кто недавно стал тимлидом или хедом аналитики и чувствует, что пора выйти из режима «просто делаем задачи» и начать думать системно. Перед тем, как ее опубликовать, я искал подобные материалы и не нашел ничего достойного на русском языке. Есть пересказы Gartner, есть руководства от вендоров уровня «нужно делать data-driven», есть какие-то корпоративные посты. Поэтому статья - попытка закрыть реальный пробел. В ней вы найдете практическое руководство: как вывести стратегию аналитики из бизнес-целей, честно оценить зрелость команды, пройти три фазы развития и собрать дорожную карту. Это выжимка из моего опыта, с конкретными шагами. Приятного чтения. #опыт

Microsoft сделал язык Flint для создания графиков и визуализаций через AI-агентов Поддерживает 46 типов диаграмм и рендеринг в Vega-Lite, ECharts и Chart.js. Код открыт. Есть MCP. https://microsoft.github.io/flint-chart/

http://openai.com/index/how-agents-are-transforming-work/

Я спарсил все скилы с гитхаба, кластеризировал и прогнал по эвалам. Результаты: - 1 из 3 скилов делает задачу хуже, чем без скила - звездочки вообще не показатель - чем хуже модель, тем полезнее скилы

🏁 Аналитика без аналитика: как Anthropic дошёл до 95% Многим начинающим аналитикам рано или поздно на уровне целей и ориентиров продают историю о self-service аналитике – чтобы продакт сам получал ответы на свои вопросы через аналитические инструменты Раньше это в основном было в контексте дэшбордов – сделать их и научить продактов ими пользоваться. Год-два назад на конференциях начали рассказывать про мечту о text-to-SQL, которая в большинстве случаев не работает Недавно Anthropic выложил разбор, как они эту мечту наконец собрали: заявляют, что 95% бизнес-запросов к данным закрываются через Claude, без аналитика. Точность – тоже около 95%. Конечно, им же не надо договариваться с СБ Начнём с фундамента. Почему селф-сервис аналитика валилась все эти годы? Ты спрашиваешь, сколько у нас активных – а active users в компании определены сотней способов. Для маркетинга одно, для продукта другое, для биллинга третье. Модель не угадывает, какой нужен именно тебе, и уверенно выдаёт красивое неправильное число Что Anthropic сделал, чтобы это вылечить: • Skills, обычные папки с markdown-файлами, подняли точность с 21% до 95%+. Не дообучение, а текстом записанный контекст: вот таблицы, вот их гранулярность, вот подводные камни • Закинуть боту тысячи прошлых SQL-запросов почти не двинуло точность – меньше 1%. Гора кода без контекста бесполезна • Без поддержки точность за месяц сползла с 95% до 65%. Определения и схемы протухают быстрее, чем кажется • Отдельный агент каждые пару часов сканит рабочие чаты, ловит сообщения в духе тут цифра неверная, сам пишет однострочный фикс в доку и открывает PR И вот главная мысль в статье. В коде ИИ силён, потому что под рукой тесты и компилятор – есть на что опереться. А в аналитике часто один правильный ответ и ноль способов доказать, что он правильный – плюс куча контекста, который часто не описывается Поэтому, словами самих Anthropic, точность аналитики – это проблема контекста и проверки, а не генерации кода Недавно я писал, что ИИ не заберёт у нас работу – и это ровно тот случай. Агент закрывает 95% вопросов, но только поверх горы работы, которую кто-то сделал руками: описал метрики, навёл порядок в данных, прописал все грабли, выстроил валидацию Профессия не умирает, она переезжает – с написания SQL на упаковку своего контекста в инструменты. Сам запрос за тебя напишет агент. А вот объяснить ему, что такое активный юзер именно у вас, пока придётся самим А у вас в компании уже были попытки построить своих агентов для ответов на вопросы? @tagir_analyzes

Microsoft опенсорснули проект SkillOpt для оптимизации способностей агентов Это фреймворк, который фоново улучшает вашего агента через изменение markdown файлов со скиллами. Это похоже на классический learning loop, но в текстовом пространстве. То есть агент выполняет задачи с текущей версией условного skill.md (это аналог прямого прохода), система легирует все, что тот делает, отмечает ошибки и успешные ответы, а затем на основе этого предлагает небольшие правки в skill (это уже backward pass). Новая версия md принимается только после прохождения верификации на отдельном сете задач (его можно задать самостоятельно или взять готовый). Как и в реальном обучении, тут предусмотрено подобие learning rate: чтобы сразу случайно сильно не испортить файл правками, они могут быть только небольшими и должны соответствовать определенным правилам. Так что попробовать инструмент можно довольно безопасно, даже если боитесь за свои md-шки. Приросты можно посмотреть в большой таблице наверху. Как видите, абсолютно во всех комбинациях моделей и бенчмарков они положительные и заметные, а в Codex и Claude Code на GPT-5.5 средний gain указан вообще как +21.8 и +18.6 соответственно (!). Статья, код, овервью и инструкции по использованию – все здесь: https://microsoft.github.io/SkillOpt/

☕️ Агентная аналитика для продактов. Материалы воркшопа Провёл воркшоп у Podlodka ProductCrew — «Агентная аналитика для продактов». Запись уже выложена. Главный тезис: аналитику можно делать на любой модели, не важно какая она. Главное - контекст, который вы ей даёте. Чтобы продемострировать это сделал два публичных репо на одних и тех же данных вымышленного фитнес-приложения: — fitflow-bare — голая БД, никакого контекста. — fitflow-rich — то же самое + PRODUCT_CONTEXT.md, data dictionary, 7 скиллов в .claude/skills/. На вебинаре прогнал два кейса в обоих репо: 1. Onboarding funnel — где люди отваливаются и почему. На bare-репо агент честно посчитал воронку и выдал гипотезы из учебника. На rich — увидел, что drop-off на шаге «выбор целей» связан с конкретной персоной, и предложил продуктовое действие. 2. NPS-фидбэк за квартал — темы, динамика, связь с поведением. На bare получились generic-кластеры «UI/Pricing/Performance». На rich — фитнес-специфичные темы (мотивация, расписание, сложность) и джойн с retention. Паттерн повторился на двух типах данных — структурированных событиях и тексте. Можно попробовать 1. Форкнуть оба репо и задать им одни и те же два вопроса — почувствовать разницу за 30 минут. 2. Подменить данные на свои, переписать PRODUCT_CONTEXT под свой продукт — это 4–8 часов. 3. Взять один реальный кейс из работы (research, фидбэк, RCA) и пройти один цикл. Всё бесплатное, всё в открытых репо, а ещё есть сайт воркшопа #events #agentic #analytics

Мы видим AI везде, кроме статистики Сегодня обсуждали парадокс, который, имхо, объясняет 90% разочарований от AI. Солоу, нобелевский лауерат по экономике, как-то заметил: Мы видим компьютеры повсюду, только не в показателях производительности Компании массово покупали компьютеры, но производительность не росла. Звучит знакомо? Собственно, тот же парадокс сейчас: Goldman Sachs пишет, что на макроуровне пока нет значимой связи между внедрением AI и производительностью. До 95% AI пилотов не проходят cost-benefit. CEO покупают подписки, но ROI не видно. J-Curve theory объясняет почему. Когда приходит новая GPT (general-purpose technology) - электричество, компьютеры, AI - мы входим в фазу инвестиций, в которой производительность ПАДАЕТ. Не потому что технология не работает, а потому что: 1) Нужно переучиваться, нужно менять процессы, это вызывает трение. Мы начинаем покупать всем Claude — затраты растут. Тратим время на обучение — output временно падает. В отчётности это выглядит как убыток, потому что реорганизация, переобучение — это всё учитывается как операционные затраты, а не как инвестиции. Причем это не только про бухучет, лучшие умы и значительные ресурсы перенаправляются на создание новой инфраструктуры и процессов. 2) Лаг между adoption и результатом. С электричеством было ~40 лет. С компьютерами ~25. Фабрики сначала просто воткнули электромоторы вместо паровых — ноль эффекта. Просто замена инструмента без перестройки процессов не дает почти ничего - и это имхо именно то, что происходит со многими сейчас. Рост тогда пришёл когда полностью перепроектировали фабрику, поняли что можно подвести электричество к каждому рабочему месту и тп. 3) Может быть, производительность и растёт — но измеряемая производительность падает. Ты лично пишешь код в 3 раза быстрее, но на уровне компании это пока не видно. Цепочка от кода до клиента длинная, и AI пока ускорил только один кусок. Как сказал недавно один участник курса: "Мы построили фабрику софтверную, но теперь нам нужны заказы". Очень напоминает Цель-2 Голдратта Вот что меня зацепило: из-за этого разрыва могут быть поспешные выводы о том, что технология не работает. И это бьёт сильнее по большим компаниям — чем больше людей и процессов, тем меньше рост индивидуальной производительности влияет на общий результат. Устранение узкого места в одном месте не решает проблему в другом. Прям теория ограничений. А у маленьких команд — наоборот. Один человек с Claude Code может заменить целый отдел — и это сразу видно в выручке, а не через 20 лет. У нас 5 человек делают то, на что обычно нужно 12-15. Не потому что мы гении — потому что нам меньше перестраивать. Имхо, хороший майндсет, который стоит держать в голове: - Если ваш CEO говорит «попробовали AI, не работает» — покажите ему J-Curve. Скорее всего, вы в investment phase и выводы преждевременные - Если вы маленькая команда — у вас преимущество. Пока корпорации пытаются «масштабировать AI adoption», вы просто работаете быстрее На эту тему очень понравился, кстати, ресурс jobsdata.ai (скриншот в аттаче) — чувак собирает все релевантные статьи и исследования на тему влияния AI на рынок труда, плюс есть чатбот, которому можно задать вопросы по своей индустрии.

Чем конкретнее задача от заказчика — тем выше шанс, что вы сделаете работу в стол. ————— Да это бред! Метрики понятны, срезы указаны, даже цель ясна — отслеживать активность пользователей. Всё по SMART. Бери и делай, что время терять? Да, только через неделю на демо: «не то хотели», «а где ещё вот это», «руководство просило другое». Почему так происходит? Потому что заказчик проделал за вас самую важную работу — прошёл путь от боли до решения сам, и отдал вам только последний шаг. Вы получили готовый ответ, не зная вопроса. ————— Как быстро раскопать, что нужно на самом деле? Спросите: И что дальше? П: Нужен DAU/MAU по подпискам. А: Окей. Вы открываете дашборд, Stickiness 30%. Что делаете? П: Ну... смотрю, не просели ли платные после первых двух недель. А: Почему именно платные? Почему две недели? П: В прошлый раз запускали платную подписку — пользователи пробовали и пропадали. Мы на это кучу денег потратили. А: А почему запускаете снова? П: Руководство считает, что проблема была не в идее, а в исполнении. Сейчас масштабируем. А: Тогда DAU/MAU вам не поможет. Давайте покажем жизненный цикл платного клиента и конверсию по этапам — так будет видно, где именно теряем. ————— Четыре вопроса — и задача превратилась в инструмент, который реально закроет проблему, а не поведёт по неправильному пути. Не отдавайте аналитическую функцию и продумывание вашей задачи заказчикам, иначе доработки неизбежны. Ваша работа начинается не с «возьму в спринт», а с поиска вопроса, на который заказчик на самом деле ищет ответ. ————— ↓ Как за хотелками заказчика найти настоящую задачу — в статье: https://think-visualize.ru/principles-of-good-data-product-requirements

How to. ClickHouse Projections Простой способ ускорить самые популярные метрики и разрезы дэша - проекции. Проекции физически хранят предпосчитанные метрики на диске, за ними не надо следить: они считаются автоматически при обновлении таблички или какой-то партиции, и позволяют вам прилично снизить нагрузку на железо.

exp-tools.ru

Дописал большую статью, которую пытался дописать последние 2 недели 🍺 В ней рассуждения на тему того, как изменится продуктовая разработка после появления инструментов типа Claude Code/Codex и похожих. Просто рассуждать - скучно, поэтому я провел эксперимент по созданию продукта с нуля, немного позалезал внутрь claude code, обвесил телеметрией и замерил - но не все собранное пока переварил, потому что все ожидаемо оказалось не просто, но на эту тему точно буду писать дальше. Следующий заход будет про стоимость фичеразработинга и вообще экономику AI-assisted кодинга 🤖💸 В безумно интересное время живем, оторваться просто невозможно Приятного чтения, буду рад лайкам на хабре и тут 🤗 https://habr.com/ru/articles/1006912/

https://evidence.dev/

Самая сложная часть в AI-продуктах — последняя миля. Разрыв между демкой и боевым решением не просто большой, он катастрофический. И большинство людей, которые не делают такие продукты руками, этого вообще не понимают. Карпаты в интервью Дваркешу хорошо это сформулировал: «march of nines». Демка работает в 90% случаев — это первая девятка. Потом нужна вторая (99%), третья (99.9%), четвёртая. Каждая следующая девятка — тот же объём работы в лучшем случае, что и предыдущая, а скорее всего усилия будут экспоненциально расти. Но Карпаты говорит про селф-драйвинг, где, если утрировать, метрика бинарная: машина доехала или нет. В консьюмерских AI-продуктах всё хуже. Модель может ответить на 70%, на 30%, может уверенно соврать — и пользователь не отличит одно от другого. Весь UX приходится строить вокруг факта, что система врёт с покерфейсом, и тебе надо как-то дать человеку понять, когда ей верить, а когда нет. Ни на одной демке этой проблемы не существует. По сути, в AI-продуктах работает принцип Парето курильщика: 20% усилий дают 80% вау-эффекта, а 80% усилий — 80% продакшн-эффекта. На этом месте ломаются ожидания всех, кто видел только демку. Куда уходят эти 80% усилий? Эдж-кейсы, где модель галлюцинирует, молчит или ломает даунстрим-системы. Лэтенси, которое на реальных запросах в разы больше, чем на подготовленных. Стоимость инференса, которая при масштабе убивает юнит-экономику. Гардрейлы, контент-фильтрация, детекция персональных данных — каждый слой отдельный проект со своими эдж-кейсами. Эвалы — это вообще отдельная история. Платформа, методология, аналитика, квалифицированная и неквалифицированная разметка, LLM as judge — целая инфраструктура с кучей процессов и людей, чтобы понимать, работает ли то, что ты выкатил. И ни один из этих слоёв не нужен на стадии демки. Когда кто-то говорит «мы за неделю собрали AI-продукт», я всегда уточняю: демку или продакшн? Демку за неделю соберёт стажёр с кредитами у провайдера LLM. Продакшн — это месяцы, если не годы, работы команды, где 90% времени уходит на то, что никогда не покажешь на презе.

Ку-ку! 9 месяцев c последнего поста, да уж... У меня было время для того, чтобы родилась статья🫃А, стоп, это я опять перестал ходить в зал😁 Расходились мы на том, что я обещал написать продолжение статьи по созданию дата-продуктов — макро-повествование. Это про то, в каком порядке графики расположить, да ведь? Когда я начинал писать, то тоже так думал. Но всё это выросло в 2 большие статьи, одну из которых публикую сейчас. На самом деле хорошее макро делается в 4 этапа: проектируем аналитический сценарий и то, как пользователь идёт по нему. Было у вас такое, что вы собрали требования, вроде глубоко погрузились. А дальше пытаетесь сделать макет, или делаете сразу дашборд и... непонятно, как собрать что-то полезное и цельное из этого, при этом не перегрузив пользователя. Сам я пришёл к этому интуитивно в течение нескольких лет боли и страданий. В статье попытался раскрыть и формализовать, как это сделать классно и потратить как можно меньше времени на это. Что происходит между требованиями и первым графиком, и почему именно здесь решается будет ваш инструмент жить или пылиться и утонете вы в правках и костылях или нет? Читайте на сайте: https://think-visualize.ru/principles-of-good-data-product-macro-narrative/

Как вы знаете, в Авито есть старая добрая традиция - публично выкладывать матрицы компетенций для основных профессий. Не будем и мы исключением, актуальная версия матрицы BI аналитики теперь в открытом доступе на Github Почему мы вообще регулярно меняем матрицу компетенций? Есть два мотива: 1) Операционный Какие критические замечания есть по итогам калибровок? Каждая калибровка выявляет слабые места текущей матрицы и мы ее понемного отшлифовываем 2) Стратегический Матрица должна создавать виденье: А какими должны быть специалисты в нашей функции через 2-3 года? Как мы будем нанимать и за что поощрять? Как отличим хорошего биайщика от плохого? И если матрица начинает сильно расходиться с стратегическим виденьем, ей требуется уже более глобальная пересборка. Филосовские мысли в качестве заключения. Сейчас весь мир в целом и наша профессия в частности меняется очень быстро,и где-то в заметках уже лежат мысли-вопросы вида: А как нам оценивать биайщиков в будущем? А как повлияют LLM-агенты? Как вообще изменится BI и будет ли он нужен? Готовых ответов у нас нет. Но когда появятся, будьте уверены мы сохраним традицию и поделимся своей версией) На картинке - диаграмма-радар заполненной матрицы у одного из биайщиков Авито. Куда мы без визуализации= )

https://openai.com/index/inside-our-in-house-data-agent/

Dash Dash - это самообучающийся data-агент, который опирается на шесть уровней контекста и непрерывно улучшает качество ответов по мере использования. Он решает ключевые проблемы сырых LLM при генерации SQL: отсутствие бизнес-контекста, нехватку tribal knowledge и неспособность учиться на прошлых ошибках, из-за чего запросы часто оказываются некорректными или вводящими в заблуждение. Dash достигает этого за счёт интеграции нескольких слоёв контекста и уникального самообучающегося цикла. Система сохраняет как курируемые Knowledge, так и автоматически выявленные Learnings из предыдущих взаимодействий, что позволяет со временем генерировать более точный и контекстно-осмысленный SQL. @five_minutes_of_data