Лондон и безопасность
По интернету ходят мемы о том, что в Лондоне надо ходить в кольчуге, чтобы защищаться от ножевых преступлений. Это спорный момент, ибо надо разделять две вещи:
1. Количество убийств/ранений ножами заметно упало за последние годы, это показывает разнообразная статистика. В 2003 началось падение, в 2019 был новый пик, теперь количество преступлений упало до уровня 2014 года, что хорошо.
2. Количество преступлений с острым оружием растёт. С одной стороны, она в каком-то смысле завышена - в эту категорию попадает даже срезание бирок с товаров в магазине, но нехилая доля - вооруженные ограбление.
Это является проблемой, но не так сильно влияет на повседневную жизни. Гораздо хуже распространение shoplifting и выхватывание телефонов из рук. Есть много разной статистики, обещают улучшение борьбы с этим, но факт остаётся фактом - шанс получить телефон обратно составляет лишь 1-2%. Видел цифры, что крадут 70-80к телефонов в год. В итоге люди стремаются с такого, ходят с привязанными телефонами и так далее.
Причём если кому-то удаётся задержать вора, есть шансы, что этот вор пожалуется в полицию на насилие, были случаи.
Несколько недель назад я увидел, как у мужика в трёх метрах от меня так выхватили телефон из рук. Велосипедист ещё издевательски посмотрел на него через плечо.
А вчера я сам попал в такую ситуацию. Шёл в Shoreditch Park, по дорожке на двух людей. Вокруг люди ходят. Вдруг дёрг - и велосипедист вырывает у меня телефон и уматывает с ним. Догнать, естественно, нереально. Пришлось бежать домой, чтобы всё заблокировать. Основное мучение - менять пароли, блокировать доступы и карты и так далее. Плюс в телефоне была дубайская симка.
Подал заявление в полицию - они за 1 час его закрыли, за отсутствием возможностей найти преступника.
Единственный плюс - телефоны обычно крадут не ради доступа к информации, а чтобы перевезти в другие страны и разобрать на запчасти.
#life
По интернету ходят мемы о том, что в Лондоне надо ходить в кольчуге, чтобы защищаться от ножевых преступлений. Это спорный момент, ибо надо разделять две вещи:
1. Количество убийств/ранений ножами заметно упало за последние годы, это показывает разнообразная статистика. В 2003 началось падение, в 2019 был новый пик, теперь количество преступлений упало до уровня 2014 года, что хорошо.
2. Количество преступлений с острым оружием растёт. С одной стороны, она в каком-то смысле завышена - в эту категорию попадает даже срезание бирок с товаров в магазине, но нехилая доля - вооруженные ограбление.
Это является проблемой, но не так сильно влияет на повседневную жизни. Гораздо хуже распространение shoplifting и выхватывание телефонов из рук. Есть много разной статистики, обещают улучшение борьбы с этим, но факт остаётся фактом - шанс получить телефон обратно составляет лишь 1-2%. Видел цифры, что крадут 70-80к телефонов в год. В итоге люди стремаются с такого, ходят с привязанными телефонами и так далее.
Причём если кому-то удаётся задержать вора, есть шансы, что этот вор пожалуется в полицию на насилие, были случаи.
Несколько недель назад я увидел, как у мужика в трёх метрах от меня так выхватили телефон из рук. Велосипедист ещё издевательски посмотрел на него через плечо.
А вчера я сам попал в такую ситуацию. Шёл в Shoreditch Park, по дорожке на двух людей. Вокруг люди ходят. Вдруг дёрг - и велосипедист вырывает у меня телефон и уматывает с ним. Догнать, естественно, нереально. Пришлось бежать домой, чтобы всё заблокировать. Основное мучение - менять пароли, блокировать доступы и карты и так далее. Плюс в телефоне была дубайская симка.
Подал заявление в полицию - они за 1 час его закрыли, за отсутствием возможностей найти преступника.
Единственный плюс - телефоны обычно крадут не ради доступа к информации, а чтобы перевезти в другие страны и разобрать на запчасти.
#life
😱15💔8🤣5💊1
Beyond Positional Bias: How DroPE Unlocks Zero-Shot Long Context in LLMs
Sakana DroPEd a new paper!
Кхм, в общем новая статья от Sakana.
Обычно для увеличения контекста в LLM используют разные трюки со скейлингом RoPE (YaRN, NTK и прочее). Они типа работают, но на задачах типа needle-in-a-haystack модели внезапно "не видят важную информацию глубоко в тексте.
И тут ресерчеры из Sakana придумали нечно интересное:
Позиционные эмбеддинги нужны, чтобы модель быстро обучалась, но именно они мешают zero-shot обобщению на длинные последовательности. Что если убрать их после претрейна и сделать короткую рекалибровку? Оказалось, что в результате модель начинает значительно лучше работать на длинном контексте
Причём это работает не только на маленьких моделях, но и на 1–7B параметров, с очень небольшим дополнительным бюджетом.
Звучит многообещающе.
Paper
Code
Project
Мои обзоры:
Personal blog
Medium
Linkedin
#paperreview
Sakana DroPEd a new paper!
Кхм, в общем новая статья от Sakana.
Обычно для увеличения контекста в LLM используют разные трюки со скейлингом RoPE (YaRN, NTK и прочее). Они типа работают, но на задачах типа needle-in-a-haystack модели внезапно "не видят важную информацию глубоко в тексте.
И тут ресерчеры из Sakana придумали нечно интересное:
Позиционные эмбеддинги нужны, чтобы модель быстро обучалась, но именно они мешают zero-shot обобщению на длинные последовательности. Что если убрать их после претрейна и сделать короткую рекалибровку? Оказалось, что в результате модель начинает значительно лучше работать на длинном контексте
Причём это работает не только на маленьких моделях, но и на 1–7B параметров, с очень небольшим дополнительным бюджетом.
Звучит многообещающе.
Paper
Code
Project
Мои обзоры:
Personal blog
Medium
#paperreview
🔥9👍2😁1
AI-adoption ускоряется на моих глазах
Пару дней назад я сидел, ждал пока Claude Code выполнит поставленную задачу и что-то задумался об AI-adoption.
Я стал использовать ChatGPT вскоре его появления, но в 2024 году это было скорее игрушкой. Иногда неплохо отвечало на вопросы, часто косячило. На работе практически не использовал, ибо в большинстве случаев было эффективнее делать вещи самому.
В 2025 году я по фану решил делать веб-игру. Это отдельная история, но если коротко, я вначале написал страниц 10 того, что хотелось бы иметь в игре, потом итеративно сделал приличный Design Document. На этом этапе Gemini Pro работало больше всего. Дальше я попросил Sonnet 3.7 написать код. На тот момент Claude Code я ещё не использовал, поэтому делал в браузере.
Модель выдала 50+ файлов, после получаса мелкий исправлений оно заработало. Вначале у меня было офигение и шок от того, что это сработало. Но довольно быстро увидел много проблем - кучи багов в интерфейсе, захардкоженные результаты вместо вычислений и много другого.
Когда я вышел на работу в BigTech летом 2025, мои коллеги говорили, что у нас есть внутренний AI-помощник, он может помочь искать информацию, но на большее рассчитывать не стоит. И не стоит ему полностью доверять - сильно галлюцинирует.
К осени 2025, внутренний ассистент постепенно стал более полезным и его можно было использовать для некоторых задач. Но и я, и большинство коллег предпочитали писать код сами.
Переломный момент, по моим ощущениям, наступил тогда, когда в компании выкатили Claude Code + Opus 4.5 в общий доступ. Люди стали пробовать... и им понравилось. Конечно, большой мотивацией делать это являлось то, что компания очень активно пушит использование AI-инструментов: и AI-driven impact, и просто их использование. Но всё равно заметно, что люди стали активно использовать Claude Code для рабочих задач. Плюс у нас есть много внутренних скилов, плагинов и прочего - они реально упрощают работу.
В этом году прям заметно, что больше кода генерится, больше всяких семинаров и ивентов про AI.
Последний пример: я всё никак не собрался попробовать OpenClaw, но вдруг увидел, что Oura Chief Medical Officer выложил репо для подключения Claw к данным Oura Ring. С помощью Claude Code я ща полчаса запустил это и попробовал. Любопытно (хотя не очень полезно), но меня вдруг осенила мысль, что если я опасаюсь проблем с безопасностью, я могу просто попросить Claude Code переписать код так, чтобы это был просто дашборд с аналитикой и прямое задавание вопросов Claude. До появления AI-ассистенов я бы даже и не подумал такое делать.
Значит ли это, что современные LLM могут всё? Далеко не так. Галлюцинаций всё ещё много, особенно при работе с внутренними ресурсами компании; анализ данных хорош, но генерация идей так себе; код пишут неплохо, но необходимо в деталях описывать что именно должно быть сделано. Прогресс продолжается и дальше будет удобнее, это не отрицаю. Но пока до автоматизации работы ещё очень далеко.
#datascience
Пару дней назад я сидел, ждал пока Claude Code выполнит поставленную задачу и что-то задумался об AI-adoption.
Я стал использовать ChatGPT вскоре его появления, но в 2024 году это было скорее игрушкой. Иногда неплохо отвечало на вопросы, часто косячило. На работе практически не использовал, ибо в большинстве случаев было эффективнее делать вещи самому.
В 2025 году я по фану решил делать веб-игру. Это отдельная история, но если коротко, я вначале написал страниц 10 того, что хотелось бы иметь в игре, потом итеративно сделал приличный Design Document. На этом этапе Gemini Pro работало больше всего. Дальше я попросил Sonnet 3.7 написать код. На тот момент Claude Code я ещё не использовал, поэтому делал в браузере.
Модель выдала 50+ файлов, после получаса мелкий исправлений оно заработало. Вначале у меня было офигение и шок от того, что это сработало. Но довольно быстро увидел много проблем - кучи багов в интерфейсе, захардкоженные результаты вместо вычислений и много другого.
Когда я вышел на работу в BigTech летом 2025, мои коллеги говорили, что у нас есть внутренний AI-помощник, он может помочь искать информацию, но на большее рассчитывать не стоит. И не стоит ему полностью доверять - сильно галлюцинирует.
К осени 2025, внутренний ассистент постепенно стал более полезным и его можно было использовать для некоторых задач. Но и я, и большинство коллег предпочитали писать код сами.
Переломный момент, по моим ощущениям, наступил тогда, когда в компании выкатили Claude Code + Opus 4.5 в общий доступ. Люди стали пробовать... и им понравилось. Конечно, большой мотивацией делать это являлось то, что компания очень активно пушит использование AI-инструментов: и AI-driven impact, и просто их использование. Но всё равно заметно, что люди стали активно использовать Claude Code для рабочих задач. Плюс у нас есть много внутренних скилов, плагинов и прочего - они реально упрощают работу.
В этом году прям заметно, что больше кода генерится, больше всяких семинаров и ивентов про AI.
Последний пример: я всё никак не собрался попробовать OpenClaw, но вдруг увидел, что Oura Chief Medical Officer выложил репо для подключения Claw к данным Oura Ring. С помощью Claude Code я ща полчаса запустил это и попробовал. Любопытно (хотя не очень полезно), но меня вдруг осенила мысль, что если я опасаюсь проблем с безопасностью, я могу просто попросить Claude Code переписать код так, чтобы это был просто дашборд с аналитикой и прямое задавание вопросов Claude. До появления AI-ассистенов я бы даже и не подумал такое делать.
Значит ли это, что современные LLM могут всё? Далеко не так. Галлюцинаций всё ещё много, особенно при работе с внутренними ресурсами компании; анализ данных хорош, но генерация идей так себе; код пишут неплохо, но необходимо в деталях описывать что именно должно быть сделано. Прогресс продолжается и дальше будет удобнее, это не отрицаю. Но пока до автоматизации работы ещё очень далеко.
#datascience
GitHub
GitHub - rickybloomfield/OuraClaw: Oura skill for OpenClaw
Oura skill for OpenClaw. Contribute to rickybloomfield/OuraClaw development by creating an account on GitHub.
👍14💊1
Oakley Meta HSTN. Часть 2.
Я уже писал, что мне выдали очки для dogfooding, но они не работали.
https://t.me/datastorieslanguages/586
Ну что ж, теперь я могу их использовать! Всего-то надо было подождать 4 недели и... замену :) Старые так и не получилось использовать, а вот новые заработали с первого раза.
На них прикольно делать фото и видео (особенно в Лондоне - не надо вытаскивать телефон и подвергать его опасности). Удивился, что через них можно даже можно музыку слушать. По идее его можно использовать с Meta AI в голосовом режиме для задавания вопросов. Другие функции особо не нужны.
Я уже писал, что мне выдали очки для dogfooding, но они не работали.
https://t.me/datastorieslanguages/586
Ну что ж, теперь я могу их использовать! Всего-то надо было подождать 4 недели и... замену :) Старые так и не получилось использовать, а вот новые заработали с первого раза.
На них прикольно делать фото и видео (особенно в Лондоне - не надо вытаскивать телефон и подвергать его опасности). Удивился, что через них можно даже можно музыку слушать. По идее его можно использовать с Meta AI в голосовом режиме для задавания вопросов. Другие функции особо не нужны.
Telegram
Data, Stories and Languages
Oakley Meta HSTN
Я уже писал, что в моей компании можно заниматься dogfooding. Всем желающим выдают headset Quest Pro при найме - он мне очень понравился.
В рамках dogfooding можно зарабатывать баллы - за выполнение заданий, репорт багов, участие в ивентах.…
Я уже писал, что в моей компании можно заниматься dogfooding. Всем желающим выдают headset Quest Pro при найме - он мне очень понравился.
В рамках dogfooding можно зарабатывать баллы - за выполнение заданий, репорт багов, участие в ивентах.…
❤2😁1
AI discourse: crafters vs builders — или вообще, про что сегодня software engineering?
В кулуарах, чатах и на форумах не утихают споры про AI-агентов, про их эффективность и про то, убьют ли они профессию.
У меня складывается ощущение, что во многом это спор двух лагерей.
• Crafters — те, для кого кодинг — это craft и часть identity. Им нравится сам процесс и написание красивого, качественного кода. Поэтому ai-coding (и его насаждение компаниями) вызывает обоснованный негатив: "я кодил всю жизнь, а теперь вместо меня агенты кодят — что дальше и как жить?"
• Builders — те, кто видит в коде инструмент. Если проблему можно решить быстрее и эффективнее — неважно, кто и как написал код. Главное — результат.
Я скорее ближе ко второй позиции. Старый тезис "code is liability" актуален ещё больше: чем меньше кода, тем меньше поддерживать. Главная работа SWE — решать проблемы, проектировать системы, коммуницировать и принимать решения. Код — это средство. Кстати, поэтому надо внимательнее ревьювить сгенеренный код и заставлять агентов писать по делу, без лишнего.
Но есть нюанс: AI не уменьшает работу — он делает её интенсивнее, как сказано тут. Раньше написание кода часто было "расслабляющим" процессом. Можно было погрузиться, часть решений принималась по ходу дела, мозг работал в привычном ритме. Иногда даже удавалось попасть в состояние потока.
Теперь большая часть времени уходит на: архитектурные решения, качественное планирование, анализ потенциальных проблем, ревью сгенерированного кода. А читать чужой (или агентский) код почти всегда тяжелее, чем писать свой. Operational fatigue меняется на decision fatigue.
Но есть и плюсы, например дешевая экспериментация:
Знакомый Staff Engineer привёл отличный пример: есть 2–3 варианта имплементации фичи, но непонятно, какой лучше. Сейчас можно не раздумывать над ними, а попросить агентов закодить их. Можно посмотреть на результаты, сравнить и выбрать понравившийся. Это значительно снижает стоимость экспериментов и расширяет пространство поиска решений.
Кажется, что мы теперь постепенно становимся архитекторами кода нежели его писателями. И это не всегда хорошо - люди выбирают профессию не только по тому какой impact ты принесешь компании, но и по тому, что им нравится это делать. При этом я хочу заметить, что AI не может заменить написание кода, особенно в нестандартных ситуациях.
И напоминаю, что компании типа Microsoft и Anthropic заявляют, что большую часть кода у них пишет AI... и их reliability сильно упала в последние месяцы.
Интересно, многие ли испытывают подобный кризис личности?
В кулуарах, чатах и на форумах не утихают споры про AI-агентов, про их эффективность и про то, убьют ли они профессию.
У меня складывается ощущение, что во многом это спор двух лагерей.
• Crafters — те, для кого кодинг — это craft и часть identity. Им нравится сам процесс и написание красивого, качественного кода. Поэтому ai-coding (и его насаждение компаниями) вызывает обоснованный негатив: "я кодил всю жизнь, а теперь вместо меня агенты кодят — что дальше и как жить?"
• Builders — те, кто видит в коде инструмент. Если проблему можно решить быстрее и эффективнее — неважно, кто и как написал код. Главное — результат.
Я скорее ближе ко второй позиции. Старый тезис "code is liability" актуален ещё больше: чем меньше кода, тем меньше поддерживать. Главная работа SWE — решать проблемы, проектировать системы, коммуницировать и принимать решения. Код — это средство. Кстати, поэтому надо внимательнее ревьювить сгенеренный код и заставлять агентов писать по делу, без лишнего.
Но есть нюанс: AI не уменьшает работу — он делает её интенсивнее, как сказано тут. Раньше написание кода часто было "расслабляющим" процессом. Можно было погрузиться, часть решений принималась по ходу дела, мозг работал в привычном ритме. Иногда даже удавалось попасть в состояние потока.
Теперь большая часть времени уходит на: архитектурные решения, качественное планирование, анализ потенциальных проблем, ревью сгенерированного кода. А читать чужой (или агентский) код почти всегда тяжелее, чем писать свой. Operational fatigue меняется на decision fatigue.
Но есть и плюсы, например дешевая экспериментация:
Знакомый Staff Engineer привёл отличный пример: есть 2–3 варианта имплементации фичи, но непонятно, какой лучше. Сейчас можно не раздумывать над ними, а попросить агентов закодить их. Можно посмотреть на результаты, сравнить и выбрать понравившийся. Это значительно снижает стоимость экспериментов и расширяет пространство поиска решений.
Кажется, что мы теперь постепенно становимся архитекторами кода нежели его писателями. И это не всегда хорошо - люди выбирают профессию не только по тому какой impact ты принесешь компании, но и по тому, что им нравится это делать. При этом я хочу заметить, что AI не может заменить написание кода, особенно в нестандартных ситуациях.
И напоминаю, что компании типа Microsoft и Anthropic заявляют, что большую часть кода у них пишет AI... и их reliability сильно упала в последние месяцы.
Интересно, многие ли испытывают подобный кризис личности?
Telegram
AI.Insaf
AI – это прогрев
Он должен был облегчить работу, но вместо этого делает её более интенсивной. В статье Harvard Business Review (от 9 февраля 2026г) как раз исследовали почему так получилось. Сотрудники берут больше задач (в том числе из-за взятия вне своего…
Он должен был облегчить работу, но вместо этого делает её более интенсивной. В статье Harvard Business Review (от 9 февраля 2026г) как раз исследовали почему так получилось. Сотрудники берут больше задач (в том числе из-за взятия вне своего…
👍13🔥7❤2
Bringing Code Review to Claude Code
https://claude.com/blog/code-review
https://code.claude.com/docs/en/code-review
Это типа team of agents анализирует PR и оставляет комментарии. По опыту инженеров в Anthropic, лишь 1% из них ошибочны.
Теперь у нас не только claude.md, но и REVIEW.md.
Пока только в research preview для Teams и Enterprise.
Средняя цена одного ревью - 15-25$. Готовы платить? 😁
#datascience #ai
https://claude.com/blog/code-review
https://code.claude.com/docs/en/code-review
Это типа team of agents анализирует PR и оставляет комментарии. По опыту инженеров в Anthropic, лишь 1% из них ошибочны.
Теперь у нас не только claude.md, но и REVIEW.md.
Пока только в research preview для Teams и Enterprise.
Средняя цена одного ревью - 15-25$. Готовы платить? 😁
#datascience #ai
😁15🥴3👍1🔥1
Collaborative Reinforcement Learning: Why HACRL Trains Models in Teams Instead of Isolation
Обычно при использовании RL для LLM каждая модель генерирует свои rollouts и учится сама на своём опыте.
Авторы HACRL предлагают другой подход: несколько разных моделей (разного размера, архитектуры и качества) обучаются вместе и делятся успешными траекториями рассуждений. Если одна модель нашла хороший способ решить задачу — другие могут учиться на этой траектории, даже если сами её не сгенерировали. Причём это происходит только во время обучения, а на инференсе модели остаются независимыми.
В результате reasoning работает лучше и требуется меньше rollouts для такого же или лучшего результата. Метрики выглядят не то чтобы прорывными, но идея весьма интересная
Возможно это большой шаг к тому, чтобы RL-обучение моделей стало экосистемой взаимодействующих моделей.
Paper
Project
Мои обзоры:
Personal blog
Medium
Linkedin
#paperreview
Обычно при использовании RL для LLM каждая модель генерирует свои rollouts и учится сама на своём опыте.
Авторы HACRL предлагают другой подход: несколько разных моделей (разного размера, архитектуры и качества) обучаются вместе и делятся успешными траекториями рассуждений. Если одна модель нашла хороший способ решить задачу — другие могут учиться на этой траектории, даже если сами её не сгенерировали. Причём это происходит только во время обучения, а на инференсе модели остаются независимыми.
В результате reasoning работает лучше и требуется меньше rollouts для такого же или лучшего результата. Метрики выглядят не то чтобы прорывными, но идея весьма интересная
Возможно это большой шаг к тому, чтобы RL-обучение моделей стало экосистемой взаимодействующих моделей.
Paper
Project
Мои обзоры:
Personal blog
Medium
#paperreview
👍3🔥1
What 81k people want from AI
https://www.anthropic.com/features/81k-interviews
Anthropic опубликовали новое исследование с красивыми визуализациями. В декабре я уже рассказывал про то, как они использовали Anthropic Interviewer, и новое исследование - пример его использования.
На этот раз, они опросили 80508 людей из 159 стран говорящих на 70 языках. Первая часть статьи - красивые цитаты людей о том, как им помогает AI.
То, для чего люди используют AI в целом не вызывает удивления: помощь в работе, развития навыков, экономия времени для более приятных дел, ускорение достижения результатов. При этом многие (аж 19%) недовольны AI в целом. Так сказать, люди бы хотели, чтобы AI мыл посуду и делал другие повседневные дела, а не замещал креатив.
Для кого-то AI работает как coping mechanism, кому-то позволяет учить что-то новое, кому-то даёт ранее недоступные возможности.
Людей волнуют проблемы надёжности и доверия к результатам, негативное влияние на экономику и на количество доступных рабочих мест, атрофия навыков от использования AI, галлюцинации и misinformation.
Любопытно, что люди в разных странах выражают разную степень оптимизма по отношению к AI: в Азии, Африке и Южной Америке больше оптимизма, в Америке и Европе больше пессимизма.
Очень интересное исследование, советую почитать.
https://www.anthropic.com/features/81k-interviews
Anthropic опубликовали новое исследование с красивыми визуализациями. В декабре я уже рассказывал про то, как они использовали Anthropic Interviewer, и новое исследование - пример его использования.
На этот раз, они опросили 80508 людей из 159 стран говорящих на 70 языках. Первая часть статьи - красивые цитаты людей о том, как им помогает AI.
То, для чего люди используют AI в целом не вызывает удивления: помощь в работе, развития навыков, экономия времени для более приятных дел, ускорение достижения результатов. При этом многие (аж 19%) недовольны AI в целом. Так сказать, люди бы хотели, чтобы AI мыл посуду и делал другие повседневные дела, а не замещал креатив.
Для кого-то AI работает как coping mechanism, кому-то позволяет учить что-то новое, кому-то даёт ранее недоступные возможности.
Людей волнуют проблемы надёжности и доверия к результатам, негативное влияние на экономику и на количество доступных рабочих мест, атрофия навыков от использования AI, галлюцинации и misinformation.
Любопытно, что люди в разных странах выражают разную степень оптимизма по отношению к AI: в Азии, Африке и Южной Америке больше оптимизма, в Америке и Европе больше пессимизма.
Очень интересное исследование, советую почитать.
👍3🔥2✍1❤1
Как я использую Claude Code в BigTech
Пятница, я решил порефлексировать на тему того, как использую AI (а именно Claude Code). У нас сейчас активно продвигают AI-инструменты, и я решил использовать эту возможность для улучшения своих навыков и продуктивности на работе. Использую только Opus на максималках. Совсем конкретику разглашать не могу из-за конфиденциальности, так что будет слегка поверхностно. Но на вопросы отвечать могу. С метриками всё сложно, но скорость работы реально выросла.
Сильно помогают дополнительные integrations / skills / plugins. Они помогают работать с разными инструментами, с внутренними тулами и много с чем другим.
Я использую Claude Code в терминале, но дополнительно использую VS Code. Почти всегда использую именно агентский режим.
Вначале о юзкейсах.
1. Работа с данными. В моём проекте мне надо собирать данные, использовать внутренние фреймворки, мониторить, фиксить проблемы.
Условный пример промпта (сильно упрощённый): вот есть пайплайн по сбору данных. напиши новый пайплайн, который добавляет к ним фичи из такой-то таблицы. Следуй структуре и стилю оригинального пайплайна
Из самого удобного, что сделал недавно, был подход типа:
вот у меня есть 3 пайплайна, запускаемых один за другим, напиши новые версии с такими-то изменениями. запускай их один за другим, мониторь исполнение, если падают - исправляй, сообщи когда будет готово.
2. Autoresearch
Недавно Karpathy выложил репо с autoresearch - итеративное автоматическое улучшение модели/тренировки для оптимизации метрик. Я сделал нечто такое же, но проще - запуск в полуручном режиме, табличка для трекинга экспериментов, докидывание моих идей в список итераций. Работало несколько дней, неплохо улучшило ml метрики.
Паттерн был примерно такой:
- вот есть пайплайн. поищи идеи, составь список. Исключи из него просто увеличение количества эпох - это сделаем в конце
- запусти 10 первых идей, когда тренировка закончится, занеси их в табличку, проанализируй и обнови список приоритетных новых идей
- повторяй
3. Дебаг падающих jobs. Раньше я много с этим страдал, теперь Claude Code решает их практически автономно - частично из-за улучшения skills, частично благодаря улучшениям самой модели.
4. Недавно у нас появилось нечто типа Claw. Я попробовал... и понял, что для многих кейсов мне и так хватает Claude Code + cron. Но для поиска свежей инфы на внутрених ресурсах - годно.
5. Уже не юзкейс: я активно использую subagents и swarms of agents - это и результаты улучшает, и в целом быстрее
6. Итеративное улучшение между сессиями - я бы сказал, что это ключевая штука, которая упрощает мне жизнь.
Все сессии логируются по дефолту в Claude Code. По итогу каждой сессии я запускаю внутренний инструмент, который собирает список "выученного" - что новое научилась делать модель (например, дебажить новый тип jobs), как я её поправлял, какие команды разрешал делать, какие баги были сделаны и как исправлены. Всё это добавляется в рабочую память модели. Это реально помогает.
7. О фейлах. Естественно, не всё работает идеально. Иногда модель применяет неправильный подход дебага, иногда использует некорректный синтаксис, иногда косячит в работе с внутренними инструментами.
Скажу честно: ещё полгода назад я писал 95% кода своими ручками, но с тех пор как нам на работе раздали Claude Code + Opus, доля написанного мной кода стала резко падать. Агенты реально упрощают жизнь. Но главное, что стоит помнить - любой закоммиченный код это моя ответственность. Нельзя сказать "это агент накосячил", так что надо внимательно ревьювить весь код.
Пятница, я решил порефлексировать на тему того, как использую AI (а именно Claude Code). У нас сейчас активно продвигают AI-инструменты, и я решил использовать эту возможность для улучшения своих навыков и продуктивности на работе. Использую только Opus на максималках. Совсем конкретику разглашать не могу из-за конфиденциальности, так что будет слегка поверхностно. Но на вопросы отвечать могу. С метриками всё сложно, но скорость работы реально выросла.
Сильно помогают дополнительные integrations / skills / plugins. Они помогают работать с разными инструментами, с внутренними тулами и много с чем другим.
Я использую Claude Code в терминале, но дополнительно использую VS Code. Почти всегда использую именно агентский режим.
Вначале о юзкейсах.
1. Работа с данными. В моём проекте мне надо собирать данные, использовать внутренние фреймворки, мониторить, фиксить проблемы.
Условный пример промпта (сильно упрощённый): вот есть пайплайн по сбору данных. напиши новый пайплайн, который добавляет к ним фичи из такой-то таблицы. Следуй структуре и стилю оригинального пайплайна
Из самого удобного, что сделал недавно, был подход типа:
вот у меня есть 3 пайплайна, запускаемых один за другим, напиши новые версии с такими-то изменениями. запускай их один за другим, мониторь исполнение, если падают - исправляй, сообщи когда будет готово.
2. Autoresearch
Недавно Karpathy выложил репо с autoresearch - итеративное автоматическое улучшение модели/тренировки для оптимизации метрик. Я сделал нечто такое же, но проще - запуск в полуручном режиме, табличка для трекинга экспериментов, докидывание моих идей в список итераций. Работало несколько дней, неплохо улучшило ml метрики.
Паттерн был примерно такой:
- вот есть пайплайн. поищи идеи, составь список. Исключи из него просто увеличение количества эпох - это сделаем в конце
- запусти 10 первых идей, когда тренировка закончится, занеси их в табличку, проанализируй и обнови список приоритетных новых идей
- повторяй
3. Дебаг падающих jobs. Раньше я много с этим страдал, теперь Claude Code решает их практически автономно - частично из-за улучшения skills, частично благодаря улучшениям самой модели.
4. Недавно у нас появилось нечто типа Claw. Я попробовал... и понял, что для многих кейсов мне и так хватает Claude Code + cron. Но для поиска свежей инфы на внутрених ресурсах - годно.
5. Уже не юзкейс: я активно использую subagents и swarms of agents - это и результаты улучшает, и в целом быстрее
6. Итеративное улучшение между сессиями - я бы сказал, что это ключевая штука, которая упрощает мне жизнь.
Все сессии логируются по дефолту в Claude Code. По итогу каждой сессии я запускаю внутренний инструмент, который собирает список "выученного" - что новое научилась делать модель (например, дебажить новый тип jobs), как я её поправлял, какие команды разрешал делать, какие баги были сделаны и как исправлены. Всё это добавляется в рабочую память модели. Это реально помогает.
7. О фейлах. Естественно, не всё работает идеально. Иногда модель применяет неправильный подход дебага, иногда использует некорректный синтаксис, иногда косячит в работе с внутренними инструментами.
Скажу честно: ещё полгода назад я писал 95% кода своими ручками, но с тех пор как нам на работе раздали Claude Code + Opus, доля написанного мной кода стала резко падать. Агенты реально упрощают жизнь. Но главное, что стоит помнить - любой закоммиченный код это моя ответственность. Нельзя сказать "это агент накосячил", так что надо внимательно ревьювить весь код.
👍11🔥7❤3💯3
Redesigning My Personal Website with Claude Code
https://andlukyane.com/blog/redesigning-my-personal-website
Недавно я задумался о том, что в последний раз я обновлял мой персональный сайт несколько лет назад, и решил обновить его.
Мой старый блогпост о том, как я создал сайт, до сих пор остаётся самым популярным, поэтому я хочу поделиться и своим новым подходом.
В первой итерации я подправил технические проблемы: добавил поиск, dark mode, обновил метаданные и прочее по мелочи.
На второй итерации я собрал список своих идей по улучшениям и попросил совета у Claude, ChatGPT, Gemini. Затем скомпилировал предложения и решил, что из них делать (было полно странных сгенерированных идей).
Обновил большую часть страниц, сделал ссылки на посты покрасивее, обновил работу тегов и много чего другого.
Изменения делал с помощью Claude Code, так что вторая итерация заняла всего 2-3 дня по паре часов вечером. Были косяки, но в целом получилось быстро и качественно.
Детали в блогпосте :)
https://andlukyane.com/blog/redesigning-my-personal-website
Недавно я задумался о том, что в последний раз я обновлял мой персональный сайт несколько лет назад, и решил обновить его.
Мой старый блогпост о том, как я создал сайт, до сих пор остаётся самым популярным, поэтому я хочу поделиться и своим новым подходом.
В первой итерации я подправил технические проблемы: добавил поиск, dark mode, обновил метаданные и прочее по мелочи.
На второй итерации я собрал список своих идей по улучшениям и попросил совета у Claude, ChatGPT, Gemini. Затем скомпилировал предложения и решил, что из них делать (было полно странных сгенерированных идей).
Обновил большую часть страниц, сделал ссылки на посты покрасивее, обновил работу тегов и много чего другого.
Изменения делал с помощью Claude Code, так что вторая итерация заняла всего 2-3 дня по паре часов вечером. Были косяки, но в целом получилось быстро и качественно.
Детали в блогпосте :)
artgor
Redesigning My Personal Website with Claude Code
A practical walkthrough of redesigning a Jekyll personal website — adding search, dark mode, structured data, and a full card-based redesign using Claude Code. What changed, what broke, and what it is like to iterate on a site with an AI coding assistant.
🔥5👍2
Чем только в бигтехе не занимаются. Кажется каждый пытается новый тул с использованием AI создать.
Из последнего, что видел - тул, генерящий такие карточки
Из последнего, что видел - тул, генерящий такие карточки
1🔥9🤮5💩3😭2😁1
Мой опыт tech review: часть 2
Я уже рассказывал про мой мой первый опыт tech review. Как я говорил - книгу должны были отменить, но издательство дало авторам ещё один шанс. Мне написали, что авторы переписали тексты, и попросили проревьювить снова.
На первый взгляд стало немного лучше - часть явного треша убрали, чуть улучшилась визуальная часть. Но стоило копнуть глубже, как карточный домик развалился.
- Полно предложений, обрывающихся на полуслове
- Куски промптов для генерации картинок типа "Picture three boxes lined up…"
- Дикая вариация стиля текста: от стиля классических учебников до фраз типа "really ‘get’ modern machine learning" или "random stuff”
- Всё ещё остались совершенно непонятные фразы типа "Dropout in neural networks? That’s a kind of Bayesian thinking."
- Есть график, который описан как "график с кластерами". Это line plot на 5 точках
- По другому графику делают умные выводы о рынке и эффективности признаков. На графике 4 точки
- Местами код противоречит сам себе
В итоге я написал ещё один гневный отзыв, книгу отменили и пообещали выплатить обещанную сумму за ревью.
Tech review второй книги - это совсем другой опыт, об этом расскажу отдельно.
#books #datascience #life
Я уже рассказывал про мой мой первый опыт tech review. Как я говорил - книгу должны были отменить, но издательство дало авторам ещё один шанс. Мне написали, что авторы переписали тексты, и попросили проревьювить снова.
На первый взгляд стало немного лучше - часть явного треша убрали, чуть улучшилась визуальная часть. Но стоило копнуть глубже, как карточный домик развалился.
- Полно предложений, обрывающихся на полуслове
- Куски промптов для генерации картинок типа "Picture three boxes lined up…"
- Дикая вариация стиля текста: от стиля классических учебников до фраз типа "really ‘get’ modern machine learning" или "random stuff”
- Всё ещё остались совершенно непонятные фразы типа "Dropout in neural networks? That’s a kind of Bayesian thinking."
- Есть график, который описан как "график с кластерами". Это line plot на 5 точках
- По другому графику делают умные выводы о рынке и эффективности признаков. На графике 4 точки
- Местами код противоречит сам себе
В итоге я написал ещё один гневный отзыв, книгу отменили и пообещали выплатить обещанную сумму за ревью.
Tech review второй книги - это совсем другой опыт, об этом расскажу отдельно.
#books #datascience #life
❤8🔥2🥴2🤣1
Ирония: skill для очистки кода от ai-slop сам полон текста с ai-slop
У нас на работе полно кастомных скилов для claude code, многие из них даже очень годные.
Но сегодня я наткнулся на skill, который предназначен для очистки кода от ai-slop - emoji, явное ai-форматирование, иногда явные ai-text обороты. Иронично
У нас на работе полно кастомных скилов для claude code, многие из них даже очень годные.
Но сегодня я наткнулся на skill, который предназначен для очистки кода от ai-slop - emoji, явное ai-форматирование, иногда явные ai-text обороты. Иронично
😁10❤6
Teaching Claude Code to teach itself: Part 1
Недавно обсуждали с коллегами, как сделать так, чтобы агенты в долгой перспективе переставали повторять одни и те же ошибки. Оказалось, что у меня есть несколько подходов, которые не все используют (и они реально работают). Попробую структурировать. Я в основном использую claude code, но подходы должны работать для любых агентных систем.
Я выделяю 3 "столпа":
- активное ручное и полуручное обучение агентов
- создание инструментов (skills и прочее) и автоматическое извлечение инсайтов
- сохранение и перенос знаний между окружениями
Cегодня поговорим о первом.
Самое базовое, и что делают все - во время сессии объяснять агенту, что он делает не так и как делать правильно. Увы, это работает лишь в конкретной сессии. Конечно, можно в каждой новой сессии просить агента смотреть в прошлые сессии для избежания ошибок, но это неэффективно и быстро сжигает токены.
Логично, что из этого возникает другая распространённая идея - вручную редактировать claude.md или memory.md (они похожи, но второй лучше подходит для фактов и информации, а не инструкций).
Увы, это работает не всегда - нередко встречал ситуацию, когда агент "забывал" посмотреть в инструкции. Решением проблемы является буквальное указание где и как искать информацию.
Конкретный пример этого: просил агента посчитать сколько долларов стоили сессии за последнюю неделю. Он корректно посчитал токены, но использовал какую-то неправильную стоимость. Я показал где у меня в инструкциях хранилась ссылка на стоимость - с тех пор он не повторял эту ошибку.
Если это делать регулярно, у агента формируется паттерн вначале искать в инструкциях, а потом уже в других местах.
Наконец, самое интересное и то, что мне помогает. Мы все нередко сталкивались с проблемой, что если попросить агента писать код/текст по подобию конкретного файла/документа, скорее всего он не сможет качественно повторить стиль.
Мне удалось частично это сделать.
Шаг 1: собрать ссылки на свой код/тексты, показать агенту и попросить извлечь из них свой стиль.
Шаг 2: попросить агента сгенерить код/текст с использованием своего стиля (и ужаснуться тому, что это совсем не получилось)
Шаг 3: въедливо переписать сгенеренный код/текст чтобы получилось так, как пишешь его обычно.
Шаг 4: попросить агента проанализировать сгенеренный код/текст и отредактированный, понять различия
По сути это маленький цикл обучения: генерация -> корректировка -> извлечение правил. После нескольких итераций качество резко растёт (не идеально, но ~80–90% достигается).
Вывод: при добавлении качественного фидбека и его повторения, агенты могут выработать устойчивые паттерны поведения, которые лучше выполняют повторяющиеся задачи.
LinkedIn post
#career #datascience #ai
Недавно обсуждали с коллегами, как сделать так, чтобы агенты в долгой перспективе переставали повторять одни и те же ошибки. Оказалось, что у меня есть несколько подходов, которые не все используют (и они реально работают). Попробую структурировать. Я в основном использую claude code, но подходы должны работать для любых агентных систем.
Я выделяю 3 "столпа":
- активное ручное и полуручное обучение агентов
- создание инструментов (skills и прочее) и автоматическое извлечение инсайтов
- сохранение и перенос знаний между окружениями
Cегодня поговорим о первом.
Самое базовое, и что делают все - во время сессии объяснять агенту, что он делает не так и как делать правильно. Увы, это работает лишь в конкретной сессии. Конечно, можно в каждой новой сессии просить агента смотреть в прошлые сессии для избежания ошибок, но это неэффективно и быстро сжигает токены.
Логично, что из этого возникает другая распространённая идея - вручную редактировать claude.md или memory.md (они похожи, но второй лучше подходит для фактов и информации, а не инструкций).
Увы, это работает не всегда - нередко встречал ситуацию, когда агент "забывал" посмотреть в инструкции. Решением проблемы является буквальное указание где и как искать информацию.
Конкретный пример этого: просил агента посчитать сколько долларов стоили сессии за последнюю неделю. Он корректно посчитал токены, но использовал какую-то неправильную стоимость. Я показал где у меня в инструкциях хранилась ссылка на стоимость - с тех пор он не повторял эту ошибку.
Если это делать регулярно, у агента формируется паттерн вначале искать в инструкциях, а потом уже в других местах.
Наконец, самое интересное и то, что мне помогает. Мы все нередко сталкивались с проблемой, что если попросить агента писать код/текст по подобию конкретного файла/документа, скорее всего он не сможет качественно повторить стиль.
Мне удалось частично это сделать.
Шаг 1: собрать ссылки на свой код/тексты, показать агенту и попросить извлечь из них свой стиль.
Шаг 2: попросить агента сгенерить код/текст с использованием своего стиля (и ужаснуться тому, что это совсем не получилось)
Шаг 3: въедливо переписать сгенеренный код/текст чтобы получилось так, как пишешь его обычно.
Шаг 4: попросить агента проанализировать сгенеренный код/текст и отредактированный, понять различия
По сути это маленький цикл обучения: генерация -> корректировка -> извлечение правил. После нескольких итераций качество резко растёт (не идеально, но ~80–90% достигается).
Вывод: при добавлении качественного фидбека и его повторения, агенты могут выработать устойчивые паттерны поведения, которые лучше выполняют повторяющиеся задачи.
LinkedIn post
#career #datascience #ai
LinkedIn
Teaching AI Agents to Learn from Experience | Andrey Lukyanenko posted on the topic | LinkedIn
𝗧𝗲𝗮𝗰𝗵𝗶𝗻𝗴 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝘁𝗼 𝘁𝗲𝗮𝗰𝗵 𝗶𝘁𝘀𝗲𝗹𝗳: 𝗣𝗮𝗿𝘁 𝟭
Several days ago, I got into a discussion on how to stop AI agents from making the same mistakes over and over. We were comparing notes, and I realized I've been doing several things that not everyone does - and…
Several days ago, I got into a discussion on how to stop AI agents from making the same mistakes over and over. We were comparing notes, and I realized I've been doing several things that not everyone does - and…
👍5🔥2💊2
Мой опыт tech review: часть 3
Я уже рассказывал про мой опыт технического ревью книги, явно сгенерированной AI. Сейчас я делаю подобное ревью для другой книги - про ML, DS, AI на питоне. Автором является один Kaggle Notebook Grandmaster (не я :)). Мне присылают главы по одной, недавно преодолели треть книги, хочу поделиться впечатлениями.
Ощущения у меня двоякие: с одной стороны, я своими глазами вижу насколько сложно писать хорошую книгу; с другой стороны, то ли у меня завышенные требования, то ли книга получается так себе.
Начну с хорошего: структура книги адекватная, в ней много полезного, есть годные примеры, многие главы построены хорошо.
Но косяков слишком уж много, даже для технического ревью.
Поскольку нигде не зафиксированы версии библиотек, часть кода просто не работает. Нередко бывают опечатки в коде, которые опять же приводят к его неработоспособности. Бывает так, что в рамках одной главы одни и те же примеры кода повторяются (для иллюстрации разных идей) и написаны в разном стиле.
Некоторые ошибки в коде вызывают просто удивление. Например, демонстрируется как можно установить конкретную версию библиотеки:
Полно несоответствий между текстом и кодом. Пример: в каждой главе есть мини-проекты для демонстрации нового материала. В тексте может быть написано, мол "есть разные варианты транфмормации признаков, вот они", а в следующем за этим коде ничего такого нет.
Но всё это в целом мелочи, гораздо хуже, что в книге полно фактических ошибок. Некоторые утверждения совершенно неправильны, некоторые спорны. Хочется привести ряд примеров:
Утверждается, что когда мы тренируем модель, мы минимизируем лосс. Вот только сказано, что лосс это bias ^ 2 + variance + irreductible error. Хотя это актуально только для регрессии.
"As model complexity increases... variance typically decreases" - хочется надеяться, что это лишь опечатка.
Хороший пример vague формулировок: "Ensemble methods reduce variance by averaging predictions across multiple models." В целом это верно, но основная польза блендинга заключается в том, что мы усредняем предсказания моделей, которые делают разные типы ошибок - тогда общая ошибка сглаживается.
"After we encode categorical features, Decision Trees can handle mixed data types." - ещё один пример интересного утверждения. Если мы закодировали категориальные признаки, то у нас больше нет mixed data types.
Один из любимых примеров подобных ошибок:
> Support Vector Machines (SVM) take a different approach. Instead of partitioning the feature space or constructing additive ensembles, SVM view learning as a geometric optimization problem. Rather than asking questions such as: “How should we split the data?”, “How should we combine weak learners?”, “How should we reduce residual errors?”, SVM ask a totally different question:
What is the most stable and robust boundary that separates the classes?
Утверждается, будто SVM совершенно по-другому решает задачу. Но это не другой тип задачи, а другой критерий разбиения данных. Впрочем, это может быть спорно.
И последний пример: "The points that lay closer to the boundary are called support vectors.". Это явная ошибка, ибо support vectors лежат на margin boundary, а не находятся близко к ней.
---
Впрочем, в нахождении таких ошибок есть и большой плюс для меня лично - это неплохо помогает вспомнить базовые вещи.
Если будет интерес, могу позже поделиться другими примерами косяков из этой книги :)
#books #datascience #life
Я уже рассказывал про мой опыт технического ревью книги, явно сгенерированной AI. Сейчас я делаю подобное ревью для другой книги - про ML, DS, AI на питоне. Автором является один Kaggle Notebook Grandmaster (не я :)). Мне присылают главы по одной, недавно преодолели треть книги, хочу поделиться впечатлениями.
Ощущения у меня двоякие: с одной стороны, я своими глазами вижу насколько сложно писать хорошую книгу; с другой стороны, то ли у меня завышенные требования, то ли книга получается так себе.
Начну с хорошего: структура книги адекватная, в ней много полезного, есть годные примеры, многие главы построены хорошо.
Но косяков слишком уж много, даже для технического ревью.
Поскольку нигде не зафиксированы версии библиотек, часть кода просто не работает. Нередко бывают опечатки в коде, которые опять же приводят к его неработоспособности. Бывает так, что в рамках одной главы одни и те же примеры кода повторяются (для иллюстрации разных идей) и написаны в разном стиле.
Некоторые ошибки в коде вызывают просто удивление. Например, демонстрируется как можно установить конкретную версию библиотеки:
pip install pandas==3.6.6. Всё бы хорошо, но такой версии pandas не существует.Полно несоответствий между текстом и кодом. Пример: в каждой главе есть мини-проекты для демонстрации нового материала. В тексте может быть написано, мол "есть разные варианты транфмормации признаков, вот они", а в следующем за этим коде ничего такого нет.
Но всё это в целом мелочи, гораздо хуже, что в книге полно фактических ошибок. Некоторые утверждения совершенно неправильны, некоторые спорны. Хочется привести ряд примеров:
Утверждается, что когда мы тренируем модель, мы минимизируем лосс. Вот только сказано, что лосс это bias ^ 2 + variance + irreductible error. Хотя это актуально только для регрессии.
"As model complexity increases... variance typically decreases" - хочется надеяться, что это лишь опечатка.
Хороший пример vague формулировок: "Ensemble methods reduce variance by averaging predictions across multiple models." В целом это верно, но основная польза блендинга заключается в том, что мы усредняем предсказания моделей, которые делают разные типы ошибок - тогда общая ошибка сглаживается.
"After we encode categorical features, Decision Trees can handle mixed data types." - ещё один пример интересного утверждения. Если мы закодировали категориальные признаки, то у нас больше нет mixed data types.
Один из любимых примеров подобных ошибок:
> Support Vector Machines (SVM) take a different approach. Instead of partitioning the feature space or constructing additive ensembles, SVM view learning as a geometric optimization problem. Rather than asking questions such as: “How should we split the data?”, “How should we combine weak learners?”, “How should we reduce residual errors?”, SVM ask a totally different question:
What is the most stable and robust boundary that separates the classes?
Утверждается, будто SVM совершенно по-другому решает задачу. Но это не другой тип задачи, а другой критерий разбиения данных. Впрочем, это может быть спорно.
И последний пример: "The points that lay closer to the boundary are called support vectors.". Это явная ошибка, ибо support vectors лежат на margin boundary, а не находятся близко к ней.
---
Впрочем, в нахождении таких ошибок есть и большой плюс для меня лично - это неплохо помогает вспомнить базовые вещи.
Если будет интерес, могу позже поделиться другими примерами косяков из этой книги :)
#books #datascience #life
Telegram
Data, Stories and Languages
Мой опыт tech review: часть 2
Я уже рассказывал про мой мой первый опыт tech review. Как я говорил - книгу должны были отменить, но издательство дало авторам ещё один шанс. Мне написали, что авторы переписали тексты, и попросили проревьювить снова.
На первый…
Я уже рассказывал про мой мой первый опыт tech review. Как я говорил - книгу должны были отменить, но издательство дало авторам ещё один шанс. Мне написали, что авторы переписали тексты, и попросили проревьювить снова.
На первый…
👍11🔥6😁3
Book Review: A Practical Guide to Reinforcement Learning from Human Feedback
Amazon
Author's LinkedIn page
Мне прислали ещё одну книжку на ревью, на этот раз про RLHF. Я считаю, что книжка годная:
- хорошее объяснение теории
- много говорится про разметку данных людьми, про оценку качества разметки и так далее. Вспомнилось как много лет назад я работал над медицинским чатботом и настрадался с разметкой
- хорошие визуализации
- прикольные примеры для практики, например, Mountain Car
- полно практических вещей, типа детального сравнения DPO и PPO
Подробности можно почитать в детальном обзоре:
Обзор в блоге
Обзор на medium
#books #datascience
Amazon
Author's LinkedIn page
Мне прислали ещё одну книжку на ревью, на этот раз про RLHF. Я считаю, что книжка годная:
- хорошее объяснение теории
- много говорится про разметку данных людьми, про оценку качества разметки и так далее. Вспомнилось как много лет назад я работал над медицинским чатботом и настрадался с разметкой
- хорошие визуализации
- прикольные примеры для практики, например, Mountain Car
- полно практических вещей, типа детального сравнения DPO и PPO
Подробности можно почитать в детальном обзоре:
Обзор в блоге
Обзор на medium
#books #datascience
👍4🔥2
Autoresearch with claude code
Я уже упоминал, что сделал на коленке autoresearch как у Карпатого и это работало. На прошлой неделе я попробовал это ещё раз.
Сетап:
- ~8млн семплов в датасете, 155 классов, сильный дисбаланс
- первую baseline модель я тренирую сам
- дальше я прошу claude code побрейнштормить: собрать идеи с внутренних обсуждений и кодовой базы, поискать снаружи, использовать несколько специальных skills для этого, поискать на каггле и так далее
- после этого мы планируем по 1-2 батча из 8 экспериментов
- клод их запускает и периодически мониторит. Если упали - фиксит и перезапускает (ну или не перезапускает, если пофиксить нельзя). Когда закончились - собирает метрики и записывает в spreadsheet
- когда все эксперименты в батче закончены, результаты анализируются и запускаются новые эксперименты. Обычно берем 1-2 самых успешных сетапа с прошлых запусков и работаем от них
- так мы проработали примерно 14 батчей. Почему остановился? Основные идеи закончились, прирост метрик стал меньше, последние батчи экспериментов улучшений не дали.
От финального результата я в шоке, если честно. Сам бы я вряд ли всё это попробовал.
Метрики в табличке - weighted f1, macro f1, count of classes with f1 > 0.5.
То есть получился не просто качественный рост взвешенного f1 - удалось сделать хорошую уверенность предсказаний модели на большинстве классов.
Естественно, рост оффлайн метрик не означает, что онлайн метрики вырастут на столько же, но корреляция обычно есть.
#datascience #ai
Я уже упоминал, что сделал на коленке autoresearch как у Карпатого и это работало. На прошлой неделе я попробовал это ещё раз.
Сетап:
- ~8млн семплов в датасете, 155 классов, сильный дисбаланс
- первую baseline модель я тренирую сам
- дальше я прошу claude code побрейнштормить: собрать идеи с внутренних обсуждений и кодовой базы, поискать снаружи, использовать несколько специальных skills для этого, поискать на каггле и так далее
- после этого мы планируем по 1-2 батча из 8 экспериментов
- клод их запускает и периодически мониторит. Если упали - фиксит и перезапускает (ну или не перезапускает, если пофиксить нельзя). Когда закончились - собирает метрики и записывает в spreadsheet
- когда все эксперименты в батче закончены, результаты анализируются и запускаются новые эксперименты. Обычно берем 1-2 самых успешных сетапа с прошлых запусков и работаем от них
- так мы проработали примерно 14 батчей. Почему остановился? Основные идеи закончились, прирост метрик стал меньше, последние батчи экспериментов улучшений не дали.
От финального результата я в шоке, если честно. Сам бы я вряд ли всё это попробовал.
Метрики в табличке - weighted f1, macro f1, count of classes with f1 > 0.5.
То есть получился не просто качественный рост взвешенного f1 - удалось сделать хорошую уверенность предсказаний модели на большинстве классов.
Естественно, рост оффлайн метрик не означает, что онлайн метрики вырастут на столько же, но корреляция обычно есть.
#datascience #ai
🔥13👍8❤3
Introducing Muse Spark: Scaling Towards Personal Superintelligence
Meta Superintelligence Labs выпустила первую модель: https://ai.meta.com/blog/introducing-muse-spark-msl/
По метрикам всё так хорошо, что аж странно. Уверяют, что по большинству бенчмарков бьют opus 4.6, gemini 3.1pro и gpt 5.4, только по кодингу немного хуже.
И странно то, что модели в доступе либо в приложении Meta AI, либо на сайте meta.ai.
Пока воспринимаю эту новость с неуверенностью и жду отзывов первых пользователей.
Meta Superintelligence Labs выпустила первую модель: https://ai.meta.com/blog/introducing-muse-spark-msl/
По метрикам всё так хорошо, что аж странно. Уверяют, что по большинству бенчмарков бьют opus 4.6, gemini 3.1pro и gpt 5.4, только по кодингу немного хуже.
И странно то, что модели в доступе либо в приложении Meta AI, либо на сайте meta.ai.
Пока воспринимаю эту новость с неуверенностью и жду отзывов первых пользователей.
👍5
Book Review: Unlocking Data with Generative AI and RAG, Second Edition
Amazon
Мне прислали ещё одну книжку на ревью, на этот раз про RAG. Я уже писал обзор на первую версию, это вторая.
Вторая книга ещё лучше первой
- автор использует и развивает один пример на протяжении всей книги - это очень удобно, жаль, что мало кто так делает.
- поскольку автор - CTO Ragas, он конечно уделяет этой библиотеке много внимания, но вполне заслуженно
- в одной из глав мы пытаемся "атаковать" RAG на стороне red team, потом защищаться на стороне blue team - прикольно
- хорошо описан Agentic RAG
Из мелких миносов - в начале книги описаны "популярные" LLM на октябрь 2025 года и их длина контекста. Некоторые из них даже на тот момент были не особо популярными
Подробности можно почитать в детальном обзоре:
Обзор в блоге
Обзор на Medium
#books #datascience
Amazon
Мне прислали ещё одну книжку на ревью, на этот раз про RAG. Я уже писал обзор на первую версию, это вторая.
Вторая книга ещё лучше первой
- автор использует и развивает один пример на протяжении всей книги - это очень удобно, жаль, что мало кто так делает.
- поскольку автор - CTO Ragas, он конечно уделяет этой библиотеке много внимания, но вполне заслуженно
- в одной из глав мы пытаемся "атаковать" RAG на стороне red team, потом защищаться на стороне blue team - прикольно
- хорошо описан Agentic RAG
Из мелких миносов - в начале книги описаны "популярные" LLM на октябрь 2025 года и их длина контекста. Некоторые из них даже на тот момент были не особо популярными
Подробности можно почитать в детальном обзоре:
Обзор в блоге
Обзор на Medium
#books #datascience
🔥4😁2💊2👍1