Интересное что-то

Топ каверзных вопросов по статистике с собеседований. Часть 1 Сегодня разберем самые интересные, на мой взгляд, вопросы и типичные ловушки. В изначальной версии получилось довольно много, поэтому мне посоветовали разделить пост на два. Правильные ответы спрятала под спойлером, попробуйте сначала ответить сами. Здесь не будет вопросов "что такое p-value" или "что такое доверительный интервал". Хотя они могут встретиться на HR-скринингах, на техническом интервью обычно вопросы поинтереснее. Отмечайте, сколько из этих вопросов вам уже попадалось 👇 Поехали! 🟡От чего зависит размер выборки? Иногда могут спросить формулу MDE, что в числителе, а что в знаменателе. Можно назвать сразу все 4 параметра: MDE (минимально детектируемый эффект), дисперсия, уровень значимости и мощность. Обычно уровень значимости и мощность фиксированы, размер выборки в основном зависит от дисперсии и MDE. Для непрерывных метрик, таких как ARPPU, характерна высокая дисперсия из-за длинного хвоста, что увеличивает время проведения тестов. Для непрерывных метрик дисперсия и среднее это независимые параметры. Бонусный вопрос: как считается дисперсия для конверсионных метрик? Для биномиального распределения дисперсия напрямую зависит от значения среднего по формуле `p(1−p)`. 🟡Что такое ошибка первого и второго рода и какая из них хуже на практике? Как связаны ошибка первого рода и уровень значимости? Ошибка первого рода — ложноположительный результат (нашли эффект, которого нет), ошибка второго рода — ложноотрицательный результат, не обнаружили реальный эффект (тут моя любимая картинка-мнемоническое правило). Какая ошибка хуже зависит от конкретного кейса, нельзя дать универсальный ответ. В медицинской диагностике ложноположительный результат почти всегда более безопасен, чем ложноотрицательный, лучше перепровериться, чем пропустить болезнь. В A/B тестировании по-разному, не заметить положительный эффект фичи может быть хуже чем раскатить нейтральную, а может и наоборот, нейтральные фичи усложняют поддержку, кодовую базу, а влияние на метрики не имеют. Уровень значимости - верхняя граница вероятности ошибки первого рода. Подробнее про это и связь их между собой здесь. 🟡Приготовили дизайн A/B, но тест идет долго, например больше месяца, продакт просит ускорить его. Что делать? Есть ряд способов ускорения A/B, например через снижение дисперсии: CUPED и стратификация. Кроме этого, можно использовать последовательное тестирование, но с этим есть нюансы, планирую разобрать это в одном из следующих постов. Еще один способ - рассмотреть вариант с прокси-метриками. В крайнем случае можно увеличить MDE, сократив выборку и ускорив тест, но продакта нужно предупредить, что мелкие изменения теперь не засечем. На тему ускорения A/B можно делать не один пост, здесь будет только нужная информация для старта. Вторая часть с вопросами выйдет завтра, накидайте лайков, если формат понравился ❤️ Пишите в комментарии вопросы, с которыми сталкивались! #analytics #собес_PA

#interview #statistics

#rl #courses

Max Dama on Automated Trading Недавно видел в Реддите дискуссию о том, кто из quant-инфлюенсеров - Christina Qi или Giuseppe Paleologo (Gappy) - прав. Дискуссия предсказуемо пришла к тому, что ни Кристина, ни Гаппи не обладают необходимой квалификацией! Я не настолько радикален - все-таки Кристина несколько лет была CEO своего хедж-фонда, а сейчас СЕО компании DataBento, которая продает данные для трейдинга. Гаппи же сейчас Global Head of Quant Research в Balyasny. Так что что-то об индустрии они знают! Если же вы хотите реально что-то понять, то советую читать Max Dama on Automated Trading. Это текст меньше, чем на 60 страниц, который написан настолько хорошо, что я жалею, что его написал не я! Max Dama написал его, когда был студентом, а сейчас он партнер в Headlands! http://isomorphisms.sdf.org/maxdama.pdf https://www.reddit.com/r/quant/comments/1k4nivo/what_are_your_thoughts_on_the_christina_qi_vs/ #хеджфонды Подписаться на канал https://t.me/rybasharp

#quant

Голосовой ввод и visul explainer – чтобы структурировать мысли Я давно использую visual explainer не только для презентаций. Один из полезных сценариев - структурировать свои мысли: выделить основные блоки, связи между ними и места, где чего-то не хватает. Недавно мне нужно было подготовить стратегию дальнейшего движения нашего продукта. В целом понимание, что и зачем делать, уже было, но не складывалась картинка, как это презентовать. Здесь хорошо сработала связка голосового ввода в Handy и скилла visual explainer. Я просто начал надиктовывать свои мысли: что думаю, почему это важно, какие части связаны между собой. Если где-то было понимание, как я хочу это видеть, тут же надиктовывал: вот это сгруппировать с этим, это вынести отдельно, здесь показать связь. В этом как раз плюс голосового ввода: обычно, когда пишешь, так или иначе пытаешься писать связно. А тут просто говоришь, как думаешь, и можно даже перескакивать между идеями. Получившийся текст я отдал агенту с visual explainer и попросил структурировать. Конечно, он не сделал готовый результат с первого раза. Не было истории, где агент взял все мои мысли, правильно структурировал их и сразу выдал готовую презентацию. Но когда я посмотрел на первую визуализацию, стало намного понятнее, что не так: этот блок должен быть иначе, эта связь потерялась, вот здесь нужно сгруппировать по-другому. Где-то агент действительно попал, но главное - появился конкретный вариант, который уже можно править. По сути, это решило проблему белого листа: когда перед тобой есть первая версия, проще понять, как должно быть на самом деле. Итоговый воркфлоу такой: надиктовываем поток мыслей, просим структурировать, от получившегося результата отталкиваемся и правим до нормальной презентации за несколько итераций. Уже делал так несколько раз - попробуйте. #ai #devfm

#llm #petproject

Создаем свои скиллы (часть 4) Что касается создания своих скиллов – тут я обычно беру skill-creator от Anthropic. Очень мощная штука: проводит по всему флоу создания, задаёт уточняющие вопросы и помогает написать евалы – чтобы при доработке скилла сразу видеть, что старые сценарии не сломались. Скиллов общего назначения сейчас супер много, и, как по мне, имеет смысл находить что-то популярное и местами подточить под себя. Сам я пишу скиллы под около-рутинные задачи – там, где хочу передать агенту экспертизу. Например, на работе периодически нужно делать релиз-ноты – и в продукте, и на информационных площадках. Процесс довольно топорный: 1. Достать из таск-трекера то, что вошло в релиз 2. Методом пристального взгляда отфильтровать то, что важно пользователям 3. Сформулировать всё на пользовательском языке, перевести на английский 4. Найти в кодовой базе json, который отвечает за релиз-ноты, и дописать нужное – то же самое для английского ... N. Закоммитить, запушить N+1. Взять эти релиз-ноты, расписать подробнее по шаблону и разложить по площадкам Руками это задача на час минимум. Топорно с агентом – минут пятнадцать. Со скиллом – три минуты. Или, например, скилл для постов: проверить грамматику, поставить нужный тег и опубликовать из Obsidian, применив телеграммное форматирование (вручную это очень заморочно). Аналогично есть скилл для моего таск-менеджера TickTick. Надиктовал задачу – а он уже знает, в какое место её положить, какую дату поставить, какие теги навесить. Очень удобно. Ещё пара моментов: – Скиллы стоит делать от сценариев. Обычно сначала просто решаешь задачу через агента, а потом понимаешь, что это можно обернуть в скилл – Не жди, что заработает с первого раза – особенно на сложных скиллах. Это инкрементальный процесс: нашёл, где не работает – подточил, написал евал – и так из раза в раз – skill.md не резиновый. Общая рекомендация Anthropic – не больше 5000 токенов, но и это кажется дофигамба. Держим skill.md маленьким, остальное выносим в references – Не пиши в скилле общеизвестное. Как понять, что лишнее? Только опытным путём: есть сомнения – удаляешь кусок информации и смотришь, как работает. Опять же, skill-creator при прогоне евалов сам подсказывает, что можно улучшить #devfm #ai

#agents #llm

Где брать скиллы (часть 3) С тем, как устроены скиллы, разобрались, даже в движении. А где их брать? Мне нравится простой каталог skills.sh. Удобно, что можно отсортировать по популярности или посмотреть, что сейчас набирает обороты – можно позалипать, вдохновиться. Из тех, чем сам пользуюсь: frontend-design – уже про него рассказывал. Лучший способ получить адекватный дизайн, когда дизайнера рядом нет. brainstorming – запускаешь перед началом работы над задачей, и агент начинает задавать уточняющие вопросы. После 5–6 вопросов требования становятся заметно полнее. На практике брейншторм почти всегда поднимает что-то, о чём не подумал или отложил на потом. pptx – скилл от антропика для работы с презентациями. Два режима: с нуля (чтобы было не вырви глаз) или создать по существующему шаблону – очень удобно. У ребят есть аналогичные скиллы и для pdf, docx, xlsx – тоже стоит присмотреться. playwright-skill – никогда написание тестов не было таким простым и бесплатным. Если необходимость unit-тестов для агента ещё под вопросом, то полноценные e2e – мастхев, и плейрайт-скилл сильно облегчает задачу. Делитесь, какими скиллами пользуетесь – интересно собрать подборку. #devfm #ai

#agents #llm

Что там с MCP Когда придумали MCP – это было чудо чудесное. Агент общается с любым внешним сервисом через единый протокол, и тебе не нужно писать обвязку под каждую интеграцию. MCP-серверы стали городить как не в себя. Потом начали вылезать технические нюансы. Описания тулов жрут контекст – подключил несколько серверов, и половина окна занята ещё до первого запроса. Ещё одна проблема, которую я часто вижу на практике. Владелец сервиса, который пишет свой MCP, просто повторяет в нём свой API. В итоге появляются десятки тулов, между которыми агент путается. И вот вышло новое видео от Anthropic – про текущее состояние MCP и планы дальше. MCP – это про коммуникацию с внешними сервисами, и в этой области он реально полезен. А проблема забитого контекста – это не про протокол, а про клиента. Решается с помощью progressive disclosure: нужные тулы подгружаются на лету, по аналогии со скиллами. Ближайшие планы: – Stateless transport – чтобы MCP-сервера можно было хостить как обычный stateless REST. Сейчас streamable HTTP плохо масштабируется – Server discovery – клиент автоматически находит MCP-сервер сайта по well-known URL. Заходит браузер или агент на сайт – и сразу видит, есть ли у него MCP – Skills over MCP – сервер сможет отдавать не только тулы, но и инструкции с доменными знаниями. То есть сервер сам учит агента, как им пользоваться – TypeScript и Python SDK – с учётом набитых шишек ребята будут активно переделывать SDK В общем MCP никуда не исчезают, а продолжают развиваться в своей нише. #ai

#agents #llm

Все ли так классно со скиллами – часть 2 В моём окружении скиллы едут и бибикают – периодически слышу: теперь ни рулы, ни MCP не нужны, скиллы всё заменят. Давайте разбираться. Skills vs rules/agents.md Идея звучит соблазнительно: все командные правила кладём в скиллы, агент сам подтянет нужный. На эту тему ребята из Vercel недавно выпустили статью. У них была задача дать ai-агентам актуальную документацию по собственному API. Сравнили два подхода – скиллы и agents.md. Получилось любопытно. Скилл периодически не срабатывал. Что ожидаемо – обещание "агент сам подтянет скилл, когда нужно" оказалось зыбкой почвой. Если же в промпте прямо написать "используй скилл" – срабатывает чаще, но появляется сайд-эффект: агент якорится на документации из скилла и перестаёт смотреть контекст проекта. С agents.md такой истории не случилось. По сути, убирается точка принятия решения – информация всегда в контексте, и гадать "а надо ли сходить за докой" не приходится. А чтобы контекст не переполнялся, в agents.md кладут не всю доку, а сжатый индекс – указатель, где смотреть по какой функциональности. Вывод: скиллы хорошо работают под конкретные сценарии – скилл по проведению ревью, скилл миграции. А для пассивных знаний о проекте лучше подходят rules/agents.md. Skills + CLI vs MCP Следующий заход, который я слышу всё чаще: давайте выкинем MCP, обернём походы во внешние сервисы в cli-утилиты, а в скилл положим инструкцию, как дергать cli. Идея – блеск. Ну по крайней мере на первый взгляд. Во многом разделяю позицию автора статьи – делать так не стоит. MCP – это по сути абстракция над API. LLM не нужно знать, как устроен сервис: достаточно вызвать service.do_x(), а MCP-сервер делает всё остальное. Коннектор между моделью и сервисом, где все шероховатости спрятаны. А когда ту же задачу пытаются переложить на скиллы, начинаются нюансы: – К скиллу нужно ещё доставить cli-утилиту. А если в окружении нет консоли – всё, приехали – Обновление непрозрачное: не до конца понятно, как раскатывать обновления скиллов – Аутентификация – туман войны, как параноидально управлять токенами изнутри скилла – до конца неясно – Скиллы обещают экономить контекст, но это не всегда так. Нужен тебе буквально один вызов, а в контекст улетает весь SKILL.md – Поддержка скиллов у агентов вроде есть, но у каждого свои нюансы. Универсальности, на которую хотелось бы рассчитывать, нет Итого: скиллы – не замена MCP, а другой инструмент под другие задачи. А что имеет смысл попробовать – skill over MCP. MCP остаётся слоем соединения с сервисом, а Skill добавляется поверх как слой знаний о том, как этим MCP правильно пользоваться. В следующем посте посмотрим, что сейчас происходит с MCP. #ai

Скиллы в агентах – часть 1: база Скиллы для агентов продолжают набирать популярность. Поэтому хочется пройтись по этой теме. Первая часть – база. Скилл – это модульная инструкция для агента, которая подгружается в контекст по необходимости. По сути – ещё один способ заставить агента работать так, как вам надо. Но с парой важных отличий. Модульность Скилл – это обычная папка. Внутри обязательный SKILL.md – основная инструкция, которую читает агент: что делает скилл, когда его применять и как именно действовать. Рядом можно положить что угодно: референсы, примеры, вспомогательные скрипты, которые агент вызывает по ходу работы.

my-skill/ ├── SKILL.md ├── references/ │ └── examples.md └── scripts/ └── helper.py

В SKILL.md обязателен фронтматтер с двумя полями – name и description. Progressive disclosure В отличие от правил (rules) или agents.md, которые грузятся в начале каждой сессии, тело скилла в контекст не попадает. Изначально там только name и description из фронтматтера – буквально пара строк. Агент сам решает, нужен ли скилл под текущую задачу, и только тогда подтягивает содержимое. Думаю, именно поэтому скиллы набирают такую популярность. В проектах, которые я видел, бывает куча рулов, которые грузятся по умолчанию, и контекст забит ещё до того, как ты начал работать. С MCP та же история (хотя с этим пытаются бороться – писал тут). Добавил несколько MCP-серверов, и добрая часть контекстного окна уходит под описания тулов, которые в этой сессии даже не пригодятся. Всё это осложняется тем, что обычный пользователь агентов не сразу поймёт, в чём у него проблема, будет страдать и не понимать, почему агент тупит на ровном месте. Скиллы этой боли лишены. Можно иметь десятки скиллов – и практически нулевую нагрузку на контекст, пока они реально не понадобятся. А значит, в агента можно паковать большое количество экспертизы: как у вас устроены миграции, как правильно собрать релиз, как команда делает код-ревью. Чтобы лучше разобраться, как работают скиллы – подготовил визуализацию. В следующем посте посмотрим, а так ли всё хорошо с этими вашими скиллами. #devfm #ai

#agents #llm

Я принес. Простой, самый базовый совет, как выглядеть крутым менеджером Есть у меня знакомый опытный менеджер, который через прикол выдал чистую правду. Звучит гротескно, но жиза 🙂 https://t.me/badTechProject/2043 Я бы еще добавил умение отвечать на такие вопросы: 1. В чем РЕАЛЬНАЯ цель проекта? Официальную-то мы все знаем, а вот на самом деле у кого что отвалится, кому надо выслужиться, премию получить или по-пацански выглядеть – это надо понимать. 2. Кто за что отвечает и кто наделен полномочиями? Чтобы не играть в игру «горячая картошка» на проекте с кучей команд и исполнителей. И чтобы понимать кому и куда эскалировать, и кому про что отчитываться. 3. Какие мы уже видим риски? Сюрприз, но если на старте проекта, где все вроде бы уже кивнули и сказали «изян, сделаем», явно спросить, кто какие риски уже видит прямо сейчас, то откроется портал в ад много всего интересного. 4. Что будет, если не успеем в срок? Да, очень круто успевать в срок, но давайте честно, всякое бывает. Поэтому надо заранее понимать, где можно в срок не успеть, но его сдвинуть, и всем будет неприятно, но приемлемо. А, где наоборот, срыв срока - это капец беда, нет денег, потеря репутации, запоротый запуск анонсированного проекта. Вот там надо будет думать не о том, чтобы куда-то срок подвинуть, а как накостылить вовремя оптимизировать работу.

#softskills #career

6️⃣0️⃣0️⃣ Коллеги, всем спасибо за 600! Расскажите откуда вы вообще на канале? И наверно как вы заметили я вообще не успеваю вычитывать посты и собирать крутую информацию в крутые теги, поэтому накидайте пожалуйста крутых ссылочек с вашими ботами, которые собирают дайджесты из новых постов в каналах - я попробую придумать что-нибудь покруче!