Интересное. Чат — слепок публичной ленты

10 июля 2026

Ссылка
нажмите — покажем

Что там с 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

2.7K · 15:18

#agents #llm

85 · 15:18

Ссылка
нажмите — покажем

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

2.2K · 15:18

#agents #llm

93 · 15:19

Ссылка
нажмите — покажем

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

1.8K · 15:19

#llm #petproject

132 · 15:20

Ссылка
нажмите — покажем

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

#quant

Ссылка
нажмите — покажем

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

#rl #courses

Файл
upd_shortened Turbo-ML RL methods.pptx · 65.6 МБ · нажмите — покажем

Всем привет! Намедни меня позвали побыть говорящей головой на TurboML конференцию. Доклад был о том, как мы завариваем online-RL для alignment'а LLMок, какие сейчас есть модные подходы. Тайминг, к сожалению, не предполагал детального разбора всего вширь (благо разбирать есть чего), поэтому доклад скорее обзорный. Возможно, кому-нибудь будет интересно \ полезно. Запись с таймкодом: https://www.youtube.com/live/Srt5gLQliRA?si=qsa2uT3rcDtgS9uI&t=14167 Презу прилагаю

146 · 10:09

26 июля 2026

id 1107549329

#interview #statistics

119 · 16:50

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

2.6K · 16:50

27 июля 2026

id 1107549329

#llm #agents #petproject

146 · 11:56

Ссылка
нажмите — покажем

https://www.youtube.com/watch?v=rnDm57Py54A

158 · 11:56

28 июля 2026

id 1107549329

#interview #ab #statistics

136 · 23:04

Топ каверзных вопросов по статистике с собеседований. Часть 2 Продолжение разбора вопросов, вторая часть. Первая часть была здесь. Поехали! 🟡Дизайн готов, A/B тест запущен. Продакт волнуется и смотрит результаты каждый день, в один день пишет, что ключевая метрика статистически значимо упала, надо отключать. Что делаем? Тут спрятаны сразу две ловушки: 1. Проблема подглядывания. Нельзя смотреть результаты каждый день и принимать решения по первому стат значимому результату, если в дизайне теста изначально не было заложено последовательное тестирование. При таком принципе оценивания теста вероятность ложного прокраса в любую сторону стремительно растет. 2. Экстренная остановка. Важно не путать это с пунктом 1. Корректный критерий аварийной остановки закладывается заранее и обычно не завязан на пересчет p-value день в день, иначе он страдает от той же проблемы подглядывания. Обычно это простой практический порог: метрика упала на конкретное число процентов, выросло число ошибок, начались краши, возможно мы выкатили критический баг 😬. Если продакт увидел на платформе A/B статистически значимое падение без такого заранее согласованного порога, то это все еще подглядывание в результаты A/B. В хорошем ответе для собеседования нужно четко разделить два случая. Стоит подчеркнуть недопустимость подглядывания без специального дизайна, но обязательно сказать про возможность ранней остановки теста при критическом падении ключевых или заградительных метрик. 🟡Тест завершен, анализируем 5 ключевых метрик. Одна из них статистически значимо изменилась, p-value = 0.03. Выкатываем тест? Для внимательных читателей канала вопрос очевидный, это ловушка на множественное тестирование. Конечно, если мы тестируем 5 ключевых метрик, то вероятность совершить ложное открытие повышается, поэтому нужно использовать поправку на множественное тестирование или принимать решение только по одной ключевой метрике. Из поправок обычно достаточно назвать Бонферрони или Холма, а вот FDR я бы сильно

#softskills

Ссылка
нажмите — покажем

Я принес. Обучение и удержание Сегодня сразу два поста от титана оргпсихологии — Дмитрия Болдырева. Один про то, как строить обучение взрослых людей на работе так, чтобы оно действительно работало: https://t.me/dmiboldyrev/129 Второй про удержание ценного сотрудника: https://t.me/dmiboldyrev/130 Я хочу отметить, что данные посты представляют собой компактные, но по сути довольно емкие чеклисты и инструкции к действию. Для опытных руководителей — это скорее пошаговая напоминалочка ничего не забыть, а для неопытных — дорога, в которой на каждом шаге нужно погрузиться в тему, разобраться, приставить на свой конкретный контекст. И второе, на чтоо хочется обратить внимание — очень реалистичный (у Димы десятки лет обучения за плечами) взгляд на то, какое обучение действительно будет работать. Не для галочки, не как «бенефит от компании», не такое, на которое отправили на перевоспитание, а такое, чтобы и человек сам захотел научиться, и полученные знания перешли в навыки, приносящие пользу на работе. Внимание, спойлер: одна учебная сессия на 2-3 часа этого не дает, как надеются некоторые. А про удержание сотрудника — так это вообще сказка-песня. Оказывается, нельзя просто повысить зарплату, или похлопать по плечу, или наоборот поругать, и проблема рассосется. Человеки очень сложные, к ним нужен комплексный персональный подход, и особенно это касается тимлидов, которые управляют непосредственно исполнителями с мало прокачанными пипл-менеджерскими навыками. Мидл-менеджерам как будто бы тут попроще, ведь у них в подчинении другие руководители.

#ml

Ссылка
нажмите — покажем

Привет, друзья! Я очень часто и очень много слышу про SHAP, как про традиционный метод. С традиционностью спорить нельзя — это правда так — безумно сама его люблю. Однако классическая постановка (вот была коалиция, были и есть игроки-признаки) касается только табличного примера и очень плохо показывает, как и почему SHAP переносится на другие модальности и задачи — и какие ограничения это несёт. Что сделала: Вооружившись «загашником» (разговорное: место, куда откладывают что-либо про запас), я свела многое в Хабр-статью: улучшения SHAP от "было" до "стало", со ссылками на все либы и интуицией "что там навешано". В статье и напоминание: классическая формула и SHAP как задача взвешенного МНК, и три вопроса, которые-всех-волнуют и развивают метод. Из вопросов описаны 15 расширений, для каждого — зачем оно возникло, что поменяли и есть ли кодовая реализация. Можно сохранить как шпору и утащить себе список библиотек с SHAP: 1. shap — основная библиотека 2. kernelshap — KernelSHAP для R 3. GPUTreeShap — TreeSHAP на CUDA 4. Fast TreeSHAP — TreeSHAP быстрее на CPU 5. shapley-regression — несмещённый KernelSHAP 6. fastshap — реализация под PyTorch, TensorFlow 7. leverageshap — KernelSHAP с гарантией точности решения 8. sage-importance — глобальная важность 9. shapiq — взаимодействия высших порядков 10. shapr — условные значения Шепли 11. GenAISHAP — Token / Pixel / Video / AgentSHAP 12. mllm-shap — SGPA для аудио Статья на Хабре: https://habr.com/ru/articles/1067656/ Приятного чтения!

#llm #agents

Ссылка
нажмите — покажем

I just wrote an article about doing evaluations It complements what we studied in the course so I'm sure you'll find it useful https://alexeyondata.substack.com/p/how-to-do-evals-in-2026 Enjoy!

#softskills #career

Ссылка
нажмите — покажем

Я принес. Модель тройного долга от соавтора фреймворка SPACE Сегодня я принес вам пост, который в очередной раз подчеркивает, что нельзя просто «внедрить ИИ, и всё будет хорошо» https://t.me/badTechProject/2108 Оказывается нужно: - Работать над качеством. Тестирование и прочие контуры контроля, чтобы ломающая прод дичь (которую вы, может, даже и не прочтете в очередном пулреквесте на 10к строк кода) не дошла до деплоя. - Нормально описывать спеки/adr’ы своих технических решений. Теперь не прокатит «Моя работа код писать, а не доки. Кому надо — код почитают, там всё понятно». - Добросовестно формулировать не только что делать (привет менеджерам, которые приносят в задачу решение вместо проблемы), а и зачем это делать, что уже пробовали ранее, как и что исследовали (исследовали ведь? исследовали?!). В общем, выглядит так, что нужно подготовить такой рабочий контекст и культуру в команде, о которых уже раньше много лет говорилось, но это было в некотором роде бест-практисом, рекомендацией, но не обязательным вариантом. Поэтому раньше люди срезали многие эти уголки, а со временем станет нельзя.

2.6K · 13:29

Слепок открытой публичной ленты из поискового индекса ChatCrawler — «Google по публичному Telegram»; обновляется по мере обхода площадки. Время — UTC.