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

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

#llm #agents #code

Вышла хорошая статья «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

#llm #agents #code

Тарик Шихипар, один из 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

#dl #interview

Литкод для 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

Возможно, в комментарии еще накидают полезных ресурсов!
Кто знает, возможно такой формат адаптируют повсеместно, тогда будем гриндить новый тип литкода!

#llm #code

Я принес. Про поколения без стереотипов

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

Приношу вам сегодня два видео, где в разных форматах примерно одно и то же рассказывается:
— Стереотипов значительно больше, чем кажется.
— У всех всё примерно одинаково по сути.
— Возрастная психология + физиология формирования организма + контекст (а это не только был ли смартфон и интернет с детства или нет), в котором мы формировались = то, что надо рассматривать, а не вешать ярлыки, что зумеры нехочухи (кто помнит мультик про великого Нехочуху — ставьте 💯), миллениалы работают бесконечно до сердечного приступа и т. д.

Я неоднократно работал сам с миллениалами, которые вели себя как стереотипные зумеры, и с зумерами, которые вообще огромные молодцы и трудяги, с какой стороны ни посмотри.

Особенно важно не тонуть в этих стереотипах сейчас, когда у нас в командах всё больше поколений начинает смешиваться, финансы поют романсы (ну вы поняли по этой фразе — я миллениал), а гонка технологий всё быстрее с каждым днем. Надо уметь работать с каждым так, чтобы и пользы было много для дела, и в команде общая продуктивность высока, и люди чтобы могли долго работать без надрыва в таком режиме.

Видео тут:
1. https://www.youtube.com/watch?v=8QSEzexKN3Q
2. https://www.youtube.com/watch?v=NZrUh_Jna4Q

Завершить пост хочу цитатой: «Нынешняя молодежь привыкла к роскоши, она отличается дурными манерами, презирает авторитеты, не уважает старших, дети спорят со взрослыми, жадно глотают пищу, изводят учителей».

Это сказал Сократ примерно две с половиной тысячи лет назад.

#quant #books

Топ-5 книг для дизайна первой торговой стратегии

(не прибыльной, очевидно, но будет что показать в портфолио)

1. Ernest P. Chan - Algorithmic Trading: Winning Strategies and Their Rationale
📅 2013 | 📄 208 стр.

💡 Калман-фильтр всегда лучше скользящего окна для адаптивной оценки параметров - даёт оценку неопределённости и плавную адаптацию без резких скачков.

📝 Самая практичная книга для старта. Готовые стратегии mean-reversion и momentum с кодом. Cointegration, Kalman filter, Bollinger, cross-sectional MR.

2. Robert Carver - Advanced Futures Trading Strategies
📅 2023 | 📄 680 стр.

💡 «Не доверяй бэктесту с Sharpe > 2» - почти наверняка переобучение. Если издержки > 1/3 SR - стратегию нельзя торговать на этом инструменте.

📝 Полная система от нуля: выбор стратегии → sizing → risk overlay → execution. 7-шаговый фреймворк без переобучения. Лучшая книга по «как собрать всё вместе».

3. Igor Tulchinsky et al. - Finding Alphas: A Quantitative Approach to Building Trading Strategies
📅 2015 | 📄 245 стр.

💡 Робастная альфа показывает монотонное убывание доходности по квинтилям (Q1→Q5) - немонотонность = хрупкий сигнал, который быстро затухнет.

📝 Методология дизайна альфы от WorldQuant: идея → формализация → бэктест → оценка. 8-мерный фреймворк оценки. Учит думать об альфах, а не копировать формулы.

4. Marcos López de Prado - Advances in Financial Machine Learning
📅 2018 | 📄 432 стр.

💡 Meta-labeling разделяет НАПРАВЛЕНИЕ и РАЗМЕР ставки: первая модель - long/short, вторая (meta) - уверенность. Позволяет улучшить sizing не трогая модель направления.

📝 ML-пайплайн для финансов: triple barrier labeling, fractional differentiation, CPCV-валидация, HRP-портфели. Учит избегать фатальных ошибок (leakage, overfitting, неправильная CV).

5. Giuseppe Paleologo — Elements of Quantitative Investing
📅 2024 | 📄 519 стр.

💡 SE Sharpe Ratio ≈ 1/√T - чтобы отличить SR=0.5 от SR=0 на уровне 2σ, нужно ~16 лет данных. Большинство бэктестов слишком коротки.

📝 Теория за sizing и портфелем. Kelly criterion, Fundamental Law (IR=IC·√nT), spiked covariance, 5 подходов к робастной оптимизации. Объясняет, почему SR - это скилл, а не результат.

#редакция@overzeros

#agents #metrics

AI Evals: 9 принципов которые реально работают

Как говорил мой дед: "Доверяй но verify"! Не буду тут повторяться про то как важны Evals в AI разработке, перейду к сути - вот принципы, к которым я пришел на практике.

1. Сначала реальные проблемы, потом метрики

Не придумывай evals из головы (и уж тем более не проси AI их придумать). Выпусти первую версию, отдай эксперту на разметку, и пусть проверки (а главное их категории!) вырастут из реальных косяков. Исключение: если уже есть verified ground truth (пары вопрос-ответ от экспертов) - можно начать с evals сразу. Тем более размечать готовые трейсы (например из LangFuse) куда удобнее - там есть много важных деталей о ходе работы AI системы.

2. PASS/FAIL лучше чем грейды (1-5, 0..100%)

Бинарные чеки проще согласовать между людьми и между LLM и человеком. Люди и сами нестабильно используют шкалы, а с бинарными оценками дрифт минимальный. Согласование между людьми на бинарных оценках всегда выше. Хочется нюансов? Бинарный вердикт + текстовая критика. Судья пишет pass/fail И развернуто объясняет почему. Нужна гранулярность? Разбей на несколько бинарных чеков.

3. Эксперт - ключевая фигура. Сделай чтобы ему удобно

Доменный эксперт - человек, от которого зависит качество eval-ов. Надо сделать все чтобы ему было удобно и все шло быстро. Например, мы у себя нередко вайбкодим кастомные eval-аппы чтобы экспертам было удобно размечать: cлева исходный документ (например PDF), справа ответ системы и там же поле для аннотации. Или даже тиндер-стайл (мне за эту разработку такую премию дадут!): свайп вправо pass, влево fail, и надиктовать коммент голосом - почему бы и нет? Главное вытащить суть из эксперта и делать это регулярно.

4. Простой кастомный eval лучше готового фреймворка

Generic метрики (coherence, fluency, faithfulness) создают иллюзию контроля. Eval который ты понимаешь и можешь объяснить коллеге за 30 секунд - всегда лучше черного ящика. Привет, RAGAS)

5. Детерминированные проверки в приоритете

Код (regex, assertions, другие code-checks включая простые NLP чеки) - всегда первый выбор. LLM-as-a-judge - только там, где код не справляется. Это надежнее, дешевле, быстрее. LLM-judge оправдан для субъективных вещей: качество передачи контекста, тон, полнота ответа - то что кодом не проверишь.

6. LLM-judge калибруй по эксперту, а не наоборот

Порядок такой: сначала берешь несколько десятков пар, которые размечает эксперт, потом бьешь это на категории (AI в помощь), потом строишь разные скореры - часть кодом, часть LLM-as-a-judge (каждый отвечает четко PASS/FAIL и есть поле с обоснованием/критикой), потом надо снова согласовать выход LLM-as-a-judge с экспертом и править промпт пока согласованность не будет высокой.

7. Разделяй evals по блокам системы

Не один eval на всю систему (хотя и один лучше чем ничего).
Пример с RAG:
- Retrieval: recall, precision, MRR - находит ли система правильные документы?
- Generation ответа: правильно ли модель использует найденный контекст (кастомные скореры)?
Разделение дает четкий сигнал где ломается.
С агентами принцип тот же: eval-ишь отдельные tools изолированно + session-level pass/fail на итог. Но не проверяй конкретные шаги - агент часто находит путь, который ты не предвидел.

8. Синхронизируй версии промптов и evals

Промпт, код и evals легко рассинхронизируются - промпт поменялся, а evals проверяют старое поведение. Неважно как именно ты версионируешь (Git, платформа типа promtfoo или Langfuse, хоть excel) - главное чтобы была сквозная версия. А еще метрики дрифтуют, это нормально, не пытайся сохранить непрерывную линию метрик любой ценой.

9. Процесс важнее инструмента

Даже Google Sheets которыми реально пользуются эксперты лучше чем Promptfoo которым не пользуется никто. Ручной eval на 50 парах лучше чем крутой Eval Pipeline в CI. Не прокрастинируй выбором тулинга. Лучший eval-инструмент - тот, который используется. Тем более потом превратить эту табличку в автоматические проверки будет очень просто.

🔥 ➕ 🔁 @nobilix

#ml #dl #agents #courses

#ml #systemdesign #books

#softskills #career #books