Интересное что-то
624 subscribers
2.8K photos
255 videos
143 files
4.66K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
Сделал небольшое видео по вопросу который у меня часто спрашивают. На удивление много народу до сих пор не разобрались когда надо использовать OpenRouter а когда самохостить:)
Я не поднимаю тут вопрос про секьюрити из прошлого поста. Но про остальное достаточно подробно.
Forwarded from Coder Doesn’t Know
За последние несколько лет я провёл около сотни алгоритмических интервью в роли интервьюера.
Самое интересное, что проблемы не только в алгоритмах.

Вот мой топ-10 ❗️ самых частых ошибок, которые вижу снова и снова 👇

1. Кандидат не берёт на себя лидерство.
Мне часто приходится пушить: давай кодить, а что дальше, а какую идею выбираем, а давай теперь протестируем твой подход.
Кандидат должен вести процесс. Кандидат - звезда на собеседовании, не интервьюер ✍️

2. Не собирают требования.
Пример: shortest path - кандидат не уточнил про отрицательные числа, полез писать Dijkstra, а оказалось, что бывают данные с отрицательными числами, но Dijkstra не работает, если есть отрицательные числа. Как итог - алгоритм не работает.

3. Вспоминают про требования очень поздно.
Кандидаты часто вспоминают про constraints через 15–20 минут, когда алгоритм уже выбран или даже уже написана часть кода. Представь, если на работе начать делать задачу до того, как собрать требования - получится не то, что требует бизнес.

4. Прыгают между подходами.
Предложил идею → не договорил → перескочил → вернулся обратно. Без структуры. 😭

5. Пытаются придумать сразу “идеальное” решение.
Часто кандидат предлагает brute force решение и, до того как уточнить у интервьюера, начинает говорить, что это неэффективно и нужно предложить идею получше. Во-первых, это опять возвращает нас к сбору требований, а во-вторых, есть шанс, что самое эффективное решение не нужно для интервьюера и твоего подхода будет достаточно.

6. Думают молча.
Если нужно подумать - скажите это интервьюеру, который, конечно же, даст вам время чтобы подумать. Но когда кандидат читает задачу про себя, молча придумывает решение и молча пишет код - интервьюеру вообще непонятно, как вы мыслите и как вам помочь в процессе.
Решение простое: тренируйтесь решать задачи вслух.

7. Не вовлекают интервьюера.
Почти никто не спрашивает:
• То, что я сейчас объяснил понятно ли вам?
• Желаете ли чтобы я подумал над другим более оптимальным решением или этого достаточно?
Как и было сказано ранее: бывает, что brute force уже достаточно - но чтобы это узнать, нужно коммуницировать с интервьюером. Помните, интервьюер здесь, чтобы помочь вам, а не "потопить" вас.

8. Не следят за временем.
Бывает так, что кандидат рассуждает 30–40 минут так и не успев полностью написать решение.
Как ни крути, все сводится к тому есть ли решение или его нет.
Тайминг - ответственность кандидата.

9. Слишком много или слишком мало заметок 😄
Либо вообще ничего. Либо пишут всё подряд.
Оптимально будет написать ключевые пункты:
• approach 1: brute force: do this, do that, time, space.
• approach 2: binary search: do this, do that, time, space.

10. "Грязный" код.
Опечатки, портянка кода без разделения на методы, странные имена переменных типа: int number, string s. Это все мелочи, но они сильно бьют по impression.

🤪 TL;DR:
Алгоритмы - это только половина успеха.
Вторая половина - коммуникация, структура и контроль процесса.
Please open Telegram to view this post
VIEW IN TELEGRAM
Привет, товарищи-статистики!

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

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

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

Приобщиться к случайно высокому
Forwarded from balun.courses
💾Собрали roadmap по LeetCode из 100 задач для подготовки к алгоритмическим собеседованиям.

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

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


➡️Roadmap по LeetCode

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

📺 Как пройти алгоритмическое собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
Округлые кнопки увеличивают конверсию на 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
Please open Telegram to view this post
VIEW IN TELEGRAM
Шикарные новости от Антропик

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
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
Please open Telegram to view this post
VIEW IN TELEGRAM
👋 прочитал от Игоря Котенкова лонгрид про домашку от антропик Anthropic's Original Performance Take-Home

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

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

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

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

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

в общем, кайфовый материал 😎
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from max.sh
Андрей @asmekal описал свой опыт собеседований на ML роли за 25 год и скомпилировал мысли в один классный лонгрид:
https://asmekal.github.io/blog/posts/interviews-2025-ml-research-engineer-uk

Тут полезные советы, примеры вопросов и что вообще можно ждать в собесах от стартапов, биг теха и фронтир лаб. Рекомендую почитать, особенно тем, кому актуально!
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