TGViewer
Channel Public Channel
Интересное что-то

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

@youknowds

Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Subscribers
624
Photos
2.8K
Videos
255
Links
4.7K

Showing posts older than #11868 · Back to latest

Older Posts 19 shown
Post #11867 206

Forwarded from max.sh

Литкод для numpy

В тему к посту выше

Недавно один подписчик пришел за советом. Как готовиться к кодинг раунду, где спрашивают задачки с фокусом на знания фреймфорков с функционалом numpy. Cуть задачи реализовать обозначенную логику через операции над тензорами. Без циклов и явных обращений к каждом элементу, а путем работы с векторами.

Формально, это конечно же никакой ни литкод. Но из-за того что задачи часто могут звучать далекими от жизни, можно сказать, что элемент литкода присутствует. Как правило, решение будет состоять из того, чтобы написать наивное решение с циклами, увидеть какой-то паттерн и найти как это можно свести к существующим операциям над тензорами (слайсы, бродкастинг, паддинг, cumsum, маскирование и так далее).

Пример подобной задачи:
Given a binary array mask and a value fill_value, return an array of the same length where each contiguous run of 1s is replaced by its 0-based run id (from left to right), and each 0 is replaced by fill_value.

mask = [0, 0, 1, 1, 0, 0, 1, 1, 1, 0, 1, 0, 1, 1, 1, 1, 0, 1, 0]
fill_value = -1

# output
[-1, -1, 0, 0, -1, -1, 1, 1, 1, -1, 2, -1, 3, 3, 3, 3, -1, 4, -1]


Или чуть более сложная версия (с точки зрения векторных операций):
Given a binary array mask, return an array of the same length where each contiguous run of 1s is replaced by its run length, and each 0 stays 0.

mask = [0, 1, 1, 0, 1, 1, 1, 0, 1]

# output
[0, 2, 2, 0, 3, 3, 3, 0, 1]


Такие секции не очень частое явление. Их можно увидеть в стартапах, организованных выходцами из больших лаб, где компании ориентированы на обучение своих моделей. Из того что я слышал, таким подходом пытаются заменить классический литкод про алгоритмы и структуры данных – чем-то более похожим, что делают ML инженеры. Подписчик вытянул подобные вопросы в 2 из 5 процессов с стартапами SF based.

Похоже ли это на ML инженерию в жизни? Частично. Когда-то я и в сам возился с сложными процессингом батчей и без эффективных операций над матрицами все работало крайне медленно; хорошее решение заняло часы (еще до агентской эпохи), много принтов и тестов, чтобы убедиться в правильности. Но в рамках интервью, пока что звучит как какое-то задротство. Классический ML Coding / ML Debugging, который хотя бы про известные кусочки мл архитектур, выглядит более разумно.

Остается важный вопрос. А как готовиться к такого рода задачам? Я не нашел одного хорошего ответа, как прокачивать свои навыки в такой нишевой теме, но вот несколько ссылок и советов:

1. Комфортно чувствовать себя при работе с ключевыми операциями над тензорами. Порешать упражнения из популярного репозитория тут
2. Более структурированный курс с набором упражнений на codechef
3. Платформы-тренажеры с вопросами в стиле интервью: tensorgym, tensortonic, deep-ML

Возможно, в комментарии еще накидают полезных ресурсов!
Кто знает, возможно такой формат адаптируют повсеместно, тогда будем гриндить новый тип литкода!
Post #11866 166
#dl #interview
Post #11865 233

Forwarded from AI for Devs

Тарик Шихипар, один из core-инженеров Claude Code, опубликовал гайд по skills — как их пишут внутри Anthropic, какие типы скиллов прижились и что отличает рабочий skill от бесполезного.

У них сейчас сотни skills в активном использовании.

Основные тейки:

— Самый ценный раздел в любом skill — gotchas. Типичные ошибки, на которые Claude натыкается при работе с вашим кодом. Обновляйте по мере накопления граничных случаев.

— Не загоняйте Claude в жёсткие рамки. Skills переиспользуются в разных контекстах, слишком жёсткие инструкции ломают адаптивность. Давайте информацию, но оставляйте пространство.

— Не пишите очевидное. Claude и так много знает про код. Фокусируйтесь на том, что выводит его за рамки дефолтного поведения. Пример из Anthropic: skill frontend-design учит Claude избегать Inter и фиолетовых градиентов.

— Поле description — в первую очередь для модели. Claude сканирует описания при старте сессии, чтобы понять, какой skill вызвать. Пишите его как условие триггера.


Сам гайд мы уже перевели на русский язык — сохраняйте и делитесь с коллегами: https://habr.com/ru/articles/1011524/

@ai_for_devs
Post #11864 183
#llm #agents #code
Post #11863 206

Forwarded from AI for Devs

Вышла хорошая статья «8 Levels of Agentic Engineering» — автор постарался разделить на логичные уровни то, как разработчики эволюционируют в работе с кодинг-агентами. Первые пять уровней (tab complete, Agent IDE, context engineering, compounding, MCP/skills) многие уже так или иначе прошли. Что дальше?

Уровень 6 — harness engineering. Суть: дать агенту окружение, в котором от будет достаточно самостоятельным. Команда OpenAI Codex, например, подключила к рантайму агента Chrome DevTools и observability — и агент сам воспроизводит баг, пишет фикс, валидирует через UI, открывает PR и мёржит. Человек подключается только по запросу.

Уровень 7 — background agents. Когда harness настроен, агент может работать, пока вы спите. Популярная точка входа — Ralph loop: автономный цикл, где агент раз за разом запускает CLI, пока все пункты задачи не закрыты, каждая итерация — свежий инстанс с чистым контекстом. Важный на этом уровне совет, к которому я тоже пришел опытным путём: используйте разные модели под разные задачи. Opus на реализацию, Gemini на ресёрч, Codex на ревью. Одна модель (особенно в одной сессии) не должна и писать и ревьювить код.

Уровень 8 — агентные команды без центрального оркестратора. Anthropic 16 агентами написала C-компилятор, Cursor сотнями агентов строил браузер с нуля. Но по сути сейчас ни у кого это в полной мере не работает.

В интересное время живём!

@ai_for_devs
Post #11862 167
#llm #agents #code
Post #11861 200

Forwarded from max.sh

Андрей @asmekal описал свой опыт собеседований на ML роли за 25 год и скомпилировал мысли в один классный лонгрид:
https://asmekal.github.io/blog/posts/interviews-2025-ml-research-engineer-uk

Тут полезные советы, примеры вопросов и что вообще можно ждать в собесах от стартапов, биг теха и фронтир лаб. Рекомендую почитать, особенно тем, кому актуально!
Post #11859 205

Forwarded from Тоже Паша Техник

👋 прочитал от Игоря Котенкова лонгрид про домашку от антропик Anthropic's Original Performance Take-Home

читал в 3 захода. очень интересно, но мои джипитишные мозги уже тяжеловато заставить шестеренкам крутить 😎

вот сам лонгрид

в целом вся задачка, это показательный кейс про то, как вообще рождается перформанс. вот в этом посте я разбрал лекци от яндекса, где тоже рассказывали про насущную проблему memory/compute bound вычисленй в обучени LLM.

в целом лонгрд имеет отличную структуру повествования. сначала у тебя есть наивная реализация. потом ты понимаешь:
• можно векторно обрабатывать сразу пачку объектов
• не надо бессмысленно гонять одни и те же данные между DRAM и scratchpad
• мало просто ускорить математику — нужно еще плотно упаковать инструкции, чтобы больше утилизировать доступных мощностей

ну и наверное для меня самая полезная мысль, как для инженера: ботлнек почти никогда не живет только в алгоритме. важно думать о том, как именно двигаются данные и как железо переваривает нструкции.

в общем, кайфовый материал 😎
Post #11857 173

Forwarded from Заскуль питона (Аналитика данных)

Claude врёт. И жрёт токены.

Я нашёл способ это пофиксить. Уже прошло несколько недель, как я начал экспериментировать с ним. От фронтенда до написания архитектуры, но сейчас расскажу про одну киллер-фичу, которая вам точно понравится.

Я уже не раз упоминал про NotebookLM и его шикарным дип-ресерчем и поиском, по которому можно учиться, но пост не о том, как пользоваться функционалом внутри и заполнять конспекты.

У Claude, как и у любой модели есть проблемы:

1. Наличие галлюцинаций. Claude этому подвержен, но в меньшей степени, как мне показалось.

2. Додумывание того, что не знает. Любая LLM сейчас это по сути вероятностные модели, которые определяют следующие слова (если можно упростить), есть вероятность того, что занесет не в то русло. В очередной раз для составления конспектов мне пихали нерелевантную инфу, например, для сравнения средний с помощью Mann-Whitney, что является уже неправильным и нужно опираться на более надежные источники или понимать предметную область.

3. Большое количество токенов на поиск информации. После того, как я слез с Codex, понял, что токены нужно тратить с умом, особенно, в контексте Claude, а еще лучше, когда он у тебя за 20 баксов. Поэтому сейчас отдаю 100 🚘

А что если попытаться убить двух зайцев сразу? Меньше додумывать и тратить меньше токенов? Как будто сложно, не правда ли?

💸 Есть решение связать по MCP Claude с NotebookLM.

Один человек написал (кстати, с помощью Claude) самописный MCP, лежит в открытом доступе. Можете ради интереса развернуть такой же, либо сделать все по инструкции, предварительно принимая все риски и вуаля, MCP готов. Ставится очень просто.
Если вы в РФ, нужно прокинуть прокси на использование в настройки, чтобы Claude обращался напрямую.

А дальше остается дело за малым: прописать инструкцию в агента или вынести отдельный скилл, чтобы Claude общался по источникам и забирал нужную инфу, если этого не нашел, то переключался в формат ресерча. С Pro версией можно вообще создать несколько ноутбуков и загрузить до 300 источников, каждый из которых может содержать до 500к слов. Более подробно сравнение контекстных окон с другими модельками можно посмотреть тут.

Что получаем?

1. Ресерч становится быстрее и качественнее
2. Claude ест меньше токенов
3. Меньше ошибок
4. Можно быстрее построить базу знаний (например, для того же Obsidian)

И все, пользуемся. За наводку спасибо @strangethemrgrench. Уверен, что еще можно найти полезных тулзов, которые упрощают жизнь при использовании агентов.

Если тема зашла, ставьте 🐳, продолжу и дальше искать интересные темы, которые упростят разработку. Кстати, на сайте будут скоро большие изменения, не переключайтесь!

@zasql_python
Post #11856 150
#llm #petproject
Post #11854 166

Forwarded from Заметки LLM-энтузиаста

Шикарные новости от Антропик

Opus 4.6 и Sonnet 4.6: контекст 1M токенов теперь в general availability 🧠

Anthropic перевела поддержку контекстного окна до 1 миллиона токенов в статус GA для Opus 4.6 и Sonnet 4.6. Без доплат и бета-флагов.

Правда с моим Max планом при создании новой сессии все еще пишет, что 1M для Sonnet 4.6 - с доплатой, а 1M для Opus 4.6 - без доплаты (см. скриншот)

Что изменилось:
▫️ Единая цена на весь контекст — никакого множителя за длину. Запрос на 900K токенов тарифицируется по той же ставке, что и на 9K
▫️ Полные rate limits на любом размере контекста
▫️ Лимит медиафайлов вырос в 6 раз — до 600 изображений или страниц PDF за один запрос (было 100)
▫️ Бета-заголовок для запросов свыше 200K больше не нужен — всё работает автоматически
▫️ Для пользователей Claude Code на планах Max, Team и Enterprise: 1M контекст для Opus 4.6 включён по умолчанию, => меньше принудительных операций /compact (кстати, возможно, и в claude.ai в связи с этим станет меньше проблем с потерей контекста)

Цены на API:
▫️ Opus 4.6 — $5 / $25 за 1M токенов (input/output)
▫️ Sonnet 4.6 — $3 / $15 за 1M токенов
(если у вас в текущей сессии claude code команда /model по Sonnet 4.6 показывает другие цены - просто откройте новую сессию)

Результаты MRCR v2 (8-needle) —относительное падение точности при росте контекста с 256K до 1M токенов: 📊 (см. скриншот)

① Opus 4.6 — с 91.9% до 78.3% (−15 п.п.) 🟠
② Sonnet 4.6 — с 90.6% до 65.1% (−28 п.п.) 🟢
③ GPT-5.4 — с 79.3% до 36.6% (−54 п.п.) ⚫️
④ Gemini 3.1 Pro — с 59.1% до 25.9% (−56 п.п.) ⚪️

Opus 4.6 теряет около 15 п.п. точности при увеличении контекста в 4 раза — против 54 п.п. у GPT-5.4.

Данные по Gemini воспроизведены независимо через Context Arena; результат OpenAI усреднён по диапазону 128K–256K.
Модель Opus 4.6 1M доступна на Claude Platform (что в РФ наиболее актуально), Amazon Bedrock, Google Cloud Vertex AI и Microsoft Foundry.

В общем, для себя я решил, что продолжаю пользоваться Opus 4.6, теперь уже с 1M контекстным окном.
У нас осталось еще 2 проекта в рамках курса. Напишу по результатам, заметим ли какие-то сдвиги в положительную или отрицательную сторону.

🔗 Официальный анонс · X (Twitter)

@llm_notes @MAX

#claude #anthropic #llm #longcontext #benchmark
Post #11852 164

Forwarded from Статистика и R в науке и аналитике

Округлые кнопки увеличивают конверсию на 55% (или нет 🤓)

В 2024 году в Journal of Consumer Research вышло исследование, что более скругленные кнопки на сайтах увеличивают конверсию в клик. В одном из тестов конверсия выросла с 7.2% до 11.2% – рост на 55%, с p-value 0.037 🚀
Аргументация авторов: округлые углы приятнее глазу, ассоциируются с безопасностью и меньшей жесткостью. Звучит как легкий способ поднять метрики без регистрации и смс)

Ну как, вы уже пошли проверять форму кнопок в своём продукте?

Но не торопимся скруглять кнопки – Рон Кохави (босс A/B тестов, автор книги "Trustworthy Online Controlled Experiments") с коллегами попытался воспроизвести эти результаты на реальном трафике. И вот что показали масштабные A/B тесты в 4 разных компаниях:

🟡SeaWorld Orlando – 2.9 млн пользователей, эффект +0.16%, p-value=0.20, незначимо
🟡Obs (норвежский ритейл) – 1.8 млн пользователей, эффект 0.73, p-value=0.09, незначимо
🟡Obs-BYGG (норвежский ритейл) – 2.2 млн пользователей, эффект +0.3%, p-value=0.29, незначимо
🟡Metro Russia – 7.4 млн пользователей, эффект -0.07%, p-value=0.83, незначимо. Пример скругленных и квадратных кнопок прикреплен к посту.

Каждая репликация была в тысячи раз масштабнее оригинала, но ни одна не подтвердила такую ракету роста.
В эксперименте от Metro Russia было еще интересное о правильном выборе ключевой метрики, подробнее можно почитать в посте Андрея Андреева (Head of eMerchandising). Коротко: разница между бинарной метрикой (добавил в корзину – да/нет) и счетчиком (количество добавлений) увеличивает нужный размер выборки в 8 раз – для счетчика выборка нужна больше. Вместо 1 млн пользователей вам нужно 8 млн и крутить тест 16 недель. Но в любом случае отсутствие эффекта было показано как на бинарной метрике, так и на счетчике.

А почему в исходном исследовании был показан рост на +55%?

Это классическое проклятие победителя (winner's curse) – когда публикуют только значимые результаты, причем самые успешные, с завышением истинной оценки эффекта. Часто в A/B тестировании можно обнаружить эффект больше, чем реально существующий (как посчитать реальный эффект рассказывал Сергей Матросов на прошлом матемаркетинге).
В оригинальном тесте было всего по ~450 человек на группу. На такой маленькой выборке рост конверсии по случайным причинам может превратиться в статистически значимый результат. Кохави применил метод Small Telescopes – суть в том, что если эффект, обнаруженный на малой выборке, действительно существует, то на миллионах пользователях мы его тем более обнаружим. Однако реального эффекта обнаружено не было, мощность оригинального исследования была недостаточной и есть серьезные основания думать, что рост конверсии на 55% был получен по случайным причинам.

Круто, а есть еще подобное?

История с круглыми кнопками это часть большого проекта: Кохави с коллегами запустили проект Trustworthy A/B Patterns – независимую проверку популярных UX-паттернов, которые считаются рабочими. Эксперты работают бесплатно, помогают компаниям правильно спроектировать и провести эксперименты, а взамен получают право публиковать результаты (тут самое сложное согласовать это со своим PR-отделом 🤓).
В очереди на проверку – открытие ссылок в новой вкладке, анализ размера поля купона, подчеркивание ссылок и не только, буду писать здесь о новых интересных результатах.

А вам больше нравятся круглые или квадратные кнопки?

#analytics #AB_tests
Post #11850 170

Forwarded from balun.courses

💾Собрали roadmap по LeetCode из 100 задач для подготовки к алгоритмическим собеседованиям.

Внутри:
– 43 easy и 57 medium задач
– последовательность тем, чтобы идти от базы к более сложным паттернам
– только те типы задач, которые регулярно встречаются на интервью

Темы в роадмапе:
• два указателя
• матрицы
• хеш-таблицы
• префиксные суммы
• битовые операции
• бинарный поиск
• сортировки
• интервалы
• связные списки
• деревья
• стеки и очереди
• sliding window
• backtracking
• графы
• динамическое программирование


➡️Roadmap по LeetCode

А если хочется понять, как в целом выстраивать подготовку, посмотри запись открытого урока:

📺 Как пройти алгоритмическое собеседование
Post #11849 140
#algo #interview
Post #11848 177

Forwarded from Не AБы какие тесты

Привет, товарищи-статистики!

Во-первых, с Международным Днем солидарности женщин в борьбе за женские права и эмансипацию, 8 марта: твердо убежlён, что в России курс на домострой аки "традиционные ценности", который от которого так и несёт средневековыми нравами, переломится, и люди будут видеть в друг в друге не "баб" и "мужиков", а субъектов.

Во-вторых, вот вам тонус на предстоящую неделю: мой разбор критерия последовательного тестирования SRM (Sample Ratio Mismatch, - есть ли перекос от ожидаемого сплита групп), который предложил Виктор Харламов (Math for Impact), см. его презентацию в комментариях, где уж больно интересные темы поднимаются а-ля процессы Бесселя, гёльдеровость и пр.

Попробую, огрубив ряд моментов, погрузить в логику критерия и ряд приведенных понятий, надеюсь, не слишком погрешил против истины.

Приобщиться к случайно высокому
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →