Forwarded from Андрей Созыкин (Andrey Sozykin)
Полезные материалы по сокетам
В видео с практикой по сокетам я показал только самый простой сценарий, чтобы понять логику работы. В реальности сервер не должен завершать работу после того, как ответил одному клиенту. И очень важно использовать многопоточность или асинхронность, иначе сервер будет работать медленно. Вот несколько ссылок с примерами, как эффективно использовать сокеты в Python:
1. Socket Programming in Python (Guide) от Real Python. Подробный разбор работы сокетов в Python, начиная с простого примера и заканчивая примером использования системного вызова .select() чтобы выбрать сокет, который готов к выполнению операций по передаче данных. Руководства от Real Python мне очень нравятся, поэтому рекомендую в первую очередь.
2. Python Socket Programming: Server and Client Example Guide. Руководство от Digital Ocean по программированию сокетов. Для обработки нескольких клиентов используются потоки с помощью модуля threading.
3. asyncio Streams. Официальная документация модуля Streams в Python, который позволяет выполнять сетевые операции с использованием asyncio. В документации есть примеры создания асинхронных клиента и сервера для сокетов.
4. Полное руководство по модулю asyncio в Python. Часть 8. Статья на Хабре с переводом документации по asyncio. Рассматриваются примеры работы с сокетами в асинхронном режиме.
5. socket — Low-level networking interface. Официальная документация по модулю socket в Python. Обязательно читаем первоисточник 😊.
6. Socket Programming HOWTO. Официальное руководство по программированию сокетов. Включает подробную информацию, как происходит передача бинарных данных, закрытие сокета, а также что будет, если сокет умрет (Die). К сожалению, нет рекомендаций, как эффективно обрабатывать несколько клиентов.
Какой подход вы используете для эффективной обработки нескольких сетевых соединений?
В видео с практикой по сокетам я показал только самый простой сценарий, чтобы понять логику работы. В реальности сервер не должен завершать работу после того, как ответил одному клиенту. И очень важно использовать многопоточность или асинхронность, иначе сервер будет работать медленно. Вот несколько ссылок с примерами, как эффективно использовать сокеты в Python:
1. Socket Programming in Python (Guide) от Real Python. Подробный разбор работы сокетов в Python, начиная с простого примера и заканчивая примером использования системного вызова .select() чтобы выбрать сокет, который готов к выполнению операций по передаче данных. Руководства от Real Python мне очень нравятся, поэтому рекомендую в первую очередь.
2. Python Socket Programming: Server and Client Example Guide. Руководство от Digital Ocean по программированию сокетов. Для обработки нескольких клиентов используются потоки с помощью модуля threading.
3. asyncio Streams. Официальная документация модуля Streams в Python, который позволяет выполнять сетевые операции с использованием asyncio. В документации есть примеры создания асинхронных клиента и сервера для сокетов.
4. Полное руководство по модулю asyncio в Python. Часть 8. Статья на Хабре с переводом документации по asyncio. Рассматриваются примеры работы с сокетами в асинхронном режиме.
5. socket — Low-level networking interface. Официальная документация по модулю socket в Python. Обязательно читаем первоисточник 😊.
6. Socket Programming HOWTO. Официальное руководство по программированию сокетов. Включает подробную информацию, как происходит передача бинарных данных, закрытие сокета, а также что будет, если сокет умрет (Die). К сожалению, нет рекомендаций, как эффективно обрабатывать несколько клиентов.
Какой подход вы используете для эффективной обработки нескольких сетевых соединений?
Telegram
Андрей Созыкин
Практика по сокетам на Python
В видео по компьютерным сетям на этой неделе рассматриваем пример с сокетами на Python:
- Разбираемся, как запустить клиент и сервер в терминале.
- Проверяем, что сервер ожидает соединений (LISTEN) с помощью TCPView и netstat.…
В видео по компьютерным сетям на этой неделе рассматриваем пример с сокетами на Python:
- Разбираемся, как запустить клиент и сервер в терминале.
- Проверяем, что сервер ожидает соединений (LISTEN) с помощью TCPView и netstat.…
Forwarded from BOGDANISSSIMO
пожалуй, самое грамотное видео о коммуникации, которое я смотрел. Очень плотное по содержанию, много прикладных советов
https://www.youtube.com/watch?v=BIvVGhy_VxU
- как правильно организовывать миты (прим. важно уделять время "продаже" - короткому напоминанию/объяснению почему мы созвонились, какую проблему решаем, почему это важно для бизнеса, а не переходить сразу к "логистике")
- как быть эксплицитным, как не завышать/не занижать свою уверенность в своей информации (самая большая проблема, когда твои гипотезы позиционируются как факты - значит, коммуникации-то и не случилось)
- как запрашивать обратную связь, "managing up" - как налаживать коммуникацию со своим менеджером (прим. "у меня проблема X" = заставляешь его делать твою работу, думать, диктовать что делать; "у меня проблема X, вот такие 3 решения вижу, ничего ли не упустил?" = сильно упрощаешь взаимодействие с тобой и показывает самостоятельность)
- как писать коротко и структурировано, чтобы тебя слышали с первого раза (лучше писать в 2 раза дольше, но чтобы все с первого раза всё узнали/поняли, чем писать неясно и отвлекать кучу коллег от работы запуская пинг-понг из сообщений в рабочем чате); о важности перечитывания хотя бы 1 раз того, что ты пишешь
+ очень много других тактических приемов, благодаря которым и вам будет легче работать и оказывать влияние на команду, и с вами будет легче работать
https://www.youtube.com/watch?v=BIvVGhy_VxU
- как правильно организовывать миты (прим. важно уделять время "продаже" - короткому напоминанию/объяснению почему мы созвонились, какую проблему решаем, почему это важно для бизнеса, а не переходить сразу к "логистике")
- как быть эксплицитным, как не завышать/не занижать свою уверенность в своей информации (самая большая проблема, когда твои гипотезы позиционируются как факты - значит, коммуникации-то и не случилось)
- как запрашивать обратную связь, "managing up" - как налаживать коммуникацию со своим менеджером (прим. "у меня проблема X" = заставляешь его делать твою работу, думать, диктовать что делать; "у меня проблема X, вот такие 3 решения вижу, ничего ли не упустил?" = сильно упрощаешь взаимодействие с тобой и показывает самостоятельность)
- как писать коротко и структурировано, чтобы тебя слышали с первого раза (лучше писать в 2 раза дольше, но чтобы все с первого раза всё узнали/поняли, чем писать неясно и отвлекать кучу коллег от работы запуская пинг-понг из сообщений в рабочем чате); о важности перечитывания хотя бы 1 раз того, что ты пишешь
+ очень много других тактических приемов, благодаря которым и вам будет легче работать и оказывать влияние на команду, и с вами будет легче работать
YouTube
Become a better communicator: Specific frameworks to improve your clarity, influence, and impact
Wes Kao is an entrepreneur, coach, and advisor. She co-founded the live learning platform Maven, backed by First Round and a16z. Before Maven, Wes co-created the altMBA with best-selling author Seth Godin. Today, Wes teaches a popular course on executive…
Forwarded from Denis Sexy IT 🤖
У OpenAI вышел классный гайд для бизнеса, на тему того как внедрять GenAI в бизнесс процессы:
https://openai.com/business/guides-and-resources/
Внутри 3 части:
– АИ на предприятии: Опыт семи передовых компаний
– Практическое руководство по созданию агентов ИИ: Что агенты АИ могут сделать для ваших сотрудников?
– Определение и масштабирование сценариев применения АИ: На чём концентрируются компании, первыми внедрившие АИ
Я полистал и там внутри много вещей на которых лично я набивал шишки в практике с GenAI, очень рекомендую корпоративным менеджерам
https://openai.com/business/guides-and-resources/
Внутри 3 части:
– АИ на предприятии: Опыт семи передовых компаний
– Практическое руководство по созданию агентов ИИ: Что агенты АИ могут сделать для ваших сотрудников?
– Определение и масштабирование сценариев применения АИ: На чём концентрируются компании, первыми внедрившие АИ
Я полистал и там внутри много вещей на которых лично я набивал шишки в практике с GenAI, очень рекомендую корпоративным менеджерам
Openai
OpenAI Learning Hub: AI Guides, Tutorials & Resources
Explore OpenAI’s expert content designed for business. Featuring in-depth resources to accelerate AI adoption for startups, enterprises, and developers.
Forwarded from BOGDANISSSIMO
#OCRBench Как строить бенчмарк с LLM-as-a-Judge?
Решил пойти по стопам Рината (@llm_under_hood) и периодически публиковать результаты тех или иных внутренних бенчмарков по разным моделям. Например вот как можно сделать бенчмарк по OCR (Optical Character Recognition), в нашем случае парсинг переписки со скриншота
Для тех, кто не знает, я делаю AI Dating Copilot – приложение, которое по скриншоту переписки или профиля подсказывает, что написать. Короткое демо iOS приложения в действии:
https://t.me/bogdanisssimo/1899
Вообще, разработка эвалов (систем оценки тех или иных задач вашего AI-сервиса) – одно из ключевых занятий при создании AI продуктов. Без них у тебя единственный способ принятия решений – это "по ощущениям". Мы конечно же пропагандируем Data-Driven Dating, поэтому сегодня мы говорим о том, как строить свои бенчмарки
Я понимаю, что этим постом я буквально делаю подарок коллегам по цеху, но если они не догадались в 2025 использовать LLM для OCR, это говорит о том, что они не очень заботятся о качестве продукта для пользователя и совсем не экспериментируют с пайплайном. Тем более, я почти год назад об этом писал сам (см. «Мечтает ли GPT-4o о сегментации картинок»). В конечном итоге оцениваю, что для моей аудитории это даст х100 больше value, чем преимуществ конкурентам
Значит, как я варил свой OCR Benchmark:
1. Берем 100-200 скриншотов переписок от пользователей, особенно нас интересуют сложные кейсы, где классический парсер (TextRecognition + if-else) или LLM часто ошибаются
2. Берем *довольно сложный* промпт для парсинга диалога, со всеми деталями (включая кто на какое сообщение ответил / поставил реакцию / какой длины голосовое и т.д.)
3. Пусть у нас есть какая-то система, которая работает сейчас. Мы через неё прогоняем все кейсы, затем глазками смотрим каждый скриншот, ручками меняем output до идеального. Это наши ground truth. Где-то будут ошибки в отправителях. Где-то будут пропущены какие-то куски сообщений. Где-то будет лишний мусор. Все это мануально вычищается
4. Прогоняем для нужной LLM все скриншоты
5. Теперь самое интересное: как сравнивать предикты и expected output? Год назад (когда ещё не было GPT-4o-mini и Claude 3 Haiku была не такой уж стабильной) я бы это делал по старинке через расстояние Левенштейна. Какие есть проблемы у этого подхода?
- непонятно как численно сравнивать и штрафовать за кейсы когда сообщение правильно распознано, но приписано не тому отправителю
- есть моменты когда куски диалога описывают что-то (кто кому какую реакцию поставил), а не буквально парсят текст на картинке
- пара букв разницы может иметь разный вес в зависимости от контекста
- ошибки вначале диалога менее критичны чем ошибки в самом конце (которые важнее всего для определения ситуации и понимания, что написать)
- одна и та же ошибка в короткой переписке и в длинной может по-разному влиять на диалог
Поэтому намного стабильнее, практичнее и проще использовать легковесную LLM-судью, которой мы даём кейс, ожидаемый результат и результат модели и просим на основе нашего подробного чеклиста (наши критерии) сравнить, оценить от 0 до 100 + дать фидбек по замеченным ошибкам (которые можно будет использовать для отладки, см. «анализ ошибок в ML системах»).
Внизу прикрепляю результаты замеров OCR Bench по разным LLM из свеже вышедших
—
Разумеется ровно такой же подход распространяется на очень широкий спектр кейсов. По сути это сводит оценку очень сложных выхлопов моделей к подобию тривиальных unit-тестов из разработки. В большинстве (менее технических) задач LLM-оценщик не заведётся с первого раза и понадобится большое количество итераций вместе с экспертом по выравниванию оценок LLM-оценщика и эксперта
Подробнее про LLM-as-a-judge можно почитать здесь:
- https://www.evidentlyai.com/llm-guide/llm-as-a-judge
- https://www.confident-ai.com/blog/why-llm-as-a-judge-is-the-best-llm-evaluation-method
- https://huggingface.co/learn/cookbook/en/llm_judge
Ваш любимый @bogdanisssimo, буду благодарен репостам друзьям и в ваши каналы
P.S. Какие модели надо ещё прогнать? Какие тулзы для эвалов вы юзаете?
#Evals
Решил пойти по стопам Рината (@llm_under_hood) и периодически публиковать результаты тех или иных внутренних бенчмарков по разным моделям. Например вот как можно сделать бенчмарк по OCR (Optical Character Recognition), в нашем случае парсинг переписки со скриншота
Для тех, кто не знает, я делаю AI Dating Copilot – приложение, которое по скриншоту переписки или профиля подсказывает, что написать. Короткое демо iOS приложения в действии:
https://t.me/bogdanisssimo/1899
Вообще, разработка эвалов (систем оценки тех или иных задач вашего AI-сервиса) – одно из ключевых занятий при создании AI продуктов. Без них у тебя единственный способ принятия решений – это "по ощущениям". Мы конечно же пропагандируем Data-Driven Dating, поэтому сегодня мы говорим о том, как строить свои бенчмарки
Я понимаю, что этим постом я буквально делаю подарок коллегам по цеху, но если они не догадались в 2025 использовать LLM для OCR, это говорит о том, что они не очень заботятся о качестве продукта для пользователя и совсем не экспериментируют с пайплайном. Тем более, я почти год назад об этом писал сам (см. «Мечтает ли GPT-4o о сегментации картинок»). В конечном итоге оцениваю, что для моей аудитории это даст х100 больше value, чем преимуществ конкурентам
Значит, как я варил свой OCR Benchmark:
1. Берем 100-200 скриншотов переписок от пользователей, особенно нас интересуют сложные кейсы, где классический парсер (TextRecognition + if-else) или LLM часто ошибаются
2. Берем *довольно сложный* промпт для парсинга диалога, со всеми деталями (включая кто на какое сообщение ответил / поставил реакцию / какой длины голосовое и т.д.)
3. Пусть у нас есть какая-то система, которая работает сейчас. Мы через неё прогоняем все кейсы, затем глазками смотрим каждый скриншот, ручками меняем output до идеального. Это наши ground truth. Где-то будут ошибки в отправителях. Где-то будут пропущены какие-то куски сообщений. Где-то будет лишний мусор. Все это мануально вычищается
4. Прогоняем для нужной LLM все скриншоты
5. Теперь самое интересное: как сравнивать предикты и expected output? Год назад (когда ещё не было GPT-4o-mini и Claude 3 Haiku была не такой уж стабильной) я бы это делал по старинке через расстояние Левенштейна. Какие есть проблемы у этого подхода?
- непонятно как численно сравнивать и штрафовать за кейсы когда сообщение правильно распознано, но приписано не тому отправителю
- есть моменты когда куски диалога описывают что-то (кто кому какую реакцию поставил), а не буквально парсят текст на картинке
- пара букв разницы может иметь разный вес в зависимости от контекста
- ошибки вначале диалога менее критичны чем ошибки в самом конце (которые важнее всего для определения ситуации и понимания, что написать)
- одна и та же ошибка в короткой переписке и в длинной может по-разному влиять на диалог
Поэтому намного стабильнее, практичнее и проще использовать легковесную LLM-судью, которой мы даём кейс, ожидаемый результат и результат модели и просим на основе нашего подробного чеклиста (наши критерии) сравнить, оценить от 0 до 100 + дать фидбек по замеченным ошибкам (которые можно будет использовать для отладки, см. «анализ ошибок в ML системах»).
Внизу прикрепляю результаты замеров OCR Bench по разным LLM из свеже вышедших
—
Разумеется ровно такой же подход распространяется на очень широкий спектр кейсов. По сути это сводит оценку очень сложных выхлопов моделей к подобию тривиальных unit-тестов из разработки. В большинстве (менее технических) задач LLM-оценщик не заведётся с первого раза и понадобится большое количество итераций вместе с экспертом по выравниванию оценок LLM-оценщика и эксперта
Подробнее про LLM-as-a-judge можно почитать здесь:
- https://www.evidentlyai.com/llm-guide/llm-as-a-judge
- https://www.confident-ai.com/blog/why-llm-as-a-judge-is-the-best-llm-evaluation-method
- https://huggingface.co/learn/cookbook/en/llm_judge
Ваш любимый @bogdanisssimo, буду благодарен репостам друзьям и в ваши каналы
P.S. Какие модели надо ещё прогнать? Какие тулзы для эвалов вы юзаете?
#Evals
Forwarded from BOGDANISSSIMO
Теория ограничений (теория узких мест) – это примерно тоже самое, что делать back propagation но в масштабах всего бизнеса. Вместо слоёв у тебя этапы воронки:
https://t.me/bogdanisssimo/1026
Вместо нейронов – компоненты продукта и маркетингового пайплайна (этапы воронки), вместо синапсов - конверсии. На каждом цикле оптимизации ты делаешь оценку в каком направлении что нужно поменять, чтобы больше максимизировать чистую прибыль / LTV:CAC или другую метрику
Как и в deep learning, ты можешь делать как forward pass и backward pass
Например, деньги и юнит-экономика – мы можем "отнормировать" на любом этапе: ты знаешь сколько денег тратишь - можешь оценить CPM (cost per mile, цена за 1000 просмотров) → CPI (cost per install) → CPT (cost per trial) → CAC (customer acquisiton cost, стоимость привлечения 1 платящего пользователя)
Так и, в обратную сторону, backward pass: LTV (Customer LifeTime Value) ← Trial LTV (сколько чистой прибыли принесёт 1 триал) ← Install LTV (сколько денег принесёт 1 инсталл) ← RPM/PPM (revenue per mile / profit per mile, выручка/прибыль на 1000 просмотров)
В случае если канал привлечения один – соотношения (например Install LTV : CPI, LTV : CAC, RPM : CPM) не поменяются. Если несколько каналов (например разбивка по гео) или несколько продуктов (например iOS vs Android) здесь уже начинают размазываться – и можно принимать решение, куда перенаправить усилия, ресурсы
https://t.me/bogdanisssimo/1026
Вместо нейронов – компоненты продукта и маркетингового пайплайна (этапы воронки), вместо синапсов - конверсии. На каждом цикле оптимизации ты делаешь оценку в каком направлении что нужно поменять, чтобы больше максимизировать чистую прибыль / LTV:CAC или другую метрику
Как и в deep learning, ты можешь делать как forward pass и backward pass
Например, деньги и юнит-экономика – мы можем "отнормировать" на любом этапе: ты знаешь сколько денег тратишь - можешь оценить CPM (cost per mile, цена за 1000 просмотров) → CPI (cost per install) → CPT (cost per trial) → CAC (customer acquisiton cost, стоимость привлечения 1 платящего пользователя)
Так и, в обратную сторону, backward pass: LTV (Customer LifeTime Value) ← Trial LTV (сколько чистой прибыли принесёт 1 триал) ← Install LTV (сколько денег принесёт 1 инсталл) ← RPM/PPM (revenue per mile / profit per mile, выручка/прибыль на 1000 просмотров)
В случае если канал привлечения один – соотношения (например Install LTV : CPI, LTV : CAC, RPM : CPM) не поменяются. Если несколько каналов (например разбивка по гео) или несколько продуктов (например iOS vs Android) здесь уже начинают размазываться – и можно принимать решение, куда перенаправить усилия, ресурсы
Telegram
BOGDANISSSIMO
Воронка. Набрасываю все метрики и конверсии вайба и прямо/косвенно известные по конкурентам + бенчмарки по рынку на таблицы, координатные оси на каждом шаге
Впереди еще много работы
Впереди еще много работы
Forwarded from BOGDANISSSIMO
Вопрос от подписчика:
Стек стандартный:
1. Аналитика/тренды в родном кабинете App Store Connect
2. Amplitude для ивентов внутри приложения (in-app воронка, ивенты, сессии пользователей, популярность фичей)
3. Adapty - для revenue management (конверсии, ARPU, ARPPU, выручка, MRR и остальное)
4. База данных в Supabase + своя кастомная аналитика в Datalens поверх. В Cursor настроен Supabase MCP, регулярно пользуюсь
В o3 последние дни активно кидаю. Помню раньше кидал код в ChatGPT, затем появился Cursor. Думаю в этом году решится вопрос с "Cursor для аналитики", где кроме самостоятельного написания SQL будет в целом коннект с широким пулом аналитических инструментов и ты можешь задавать вопросы как к аналитическому отделу, не переходя самостоятельно в отдельный сервис
Видел в YC пару батчей назад стартап на эту тему
Кстати расскажешь как-нибудь какими тулзами аналитическими пользуешься?
Стек стандартный:
1. Аналитика/тренды в родном кабинете App Store Connect
2. Amplitude для ивентов внутри приложения (in-app воронка, ивенты, сессии пользователей, популярность фичей)
3. Adapty - для revenue management (конверсии, ARPU, ARPPU, выручка, MRR и остальное)
4. База данных в Supabase + своя кастомная аналитика в Datalens поверх. В Cursor настроен Supabase MCP, регулярно пользуюсь
В o3 последние дни активно кидаю. Помню раньше кидал код в ChatGPT, затем появился Cursor. Думаю в этом году решится вопрос с "Cursor для аналитики", где кроме самостоятельного написания SQL будет в целом коннект с широким пулом аналитических инструментов и ты можешь задавать вопросы как к аналитическому отделу, не переходя самостоятельно в отдельный сервис
Видел в YC пару батчей назад стартап на эту тему
Amplitude
AI Analytics Platform for Modern Digital Analytics
Build better products by turning your user data into meaningful insights, using Amplitude's digital analytics platform and experimentation tools.
Forwarded from BOGDANISSSIMO
#OCRBench LLM-as-a-Judge: Error Analysis & Checklist
В книге Валеры и Арсения по ML System Design мы писали главу Error Analysis, по мотивам которой была написана моя статья на Хабре "Почему анализ ошибок – это начало разработки ML системы, а не её конец", а также создана одноимённая задача в Симуляторе DS
Когда у нас появляется какой либо способ оценки – кросс-валидация, offline эксперименты, LLM бенчмарк – мы получаем возможность закапываться в ошибки. Где пользователь не делает целевое действие? Где самое сильное расхождение с правильным ответом?
В главе книги мы описывали с каких сторон можно подходить к анализу ошибок, например, можно глазками смотреть на best cases, worst cases – искать, что в них общего, какие паттерны. Также можно мануально выделять группы/кластеры и смотреть перфоманс на ней
Сейчас у нас есть LLM, поэтому вместо рутинной мануальной работы:
1. Можно кидать целые логи / датасеты (с разбором ошибок от LLM-судьи с предыдущего этапа) – в LLM, и просить кластеризовать типовые проблемы
2. Затем можно под каждую из них завести бинарный флаг "есть / нету" и включить это как чеклист ответа LLM-судьи. Для судьи я использую модель от OpenAI где SO (structured output) работает стабильно, поэтому проблем с парсингом ответа несмотря на преумножение числа полей - не возникает
3. В конце прогона агрегируем по каждой модели и получаем "след" её проблем на нашей задаче
Иметь подобную декомпозицию проблем модели и пайплайна сильно полезнее, чем иметь одно агрегированное число "вот такая-то точность". Какие-то из проблем будут критичными, какие-то менее важны, но по крайней мере у тебя появляется четкая картина характера ошибок и теперь понятно, в «какую сторону» исправлять систему
По сути как взять градиент по бенчмарку и делать back propagation 🤓
Ваш @bogdanisssimo
#Evals
В книге Валеры и Арсения по ML System Design мы писали главу Error Analysis, по мотивам которой была написана моя статья на Хабре "Почему анализ ошибок – это начало разработки ML системы, а не её конец", а также создана одноимённая задача в Симуляторе DS
Когда у нас появляется какой либо способ оценки – кросс-валидация, offline эксперименты, LLM бенчмарк – мы получаем возможность закапываться в ошибки. Где пользователь не делает целевое действие? Где самое сильное расхождение с правильным ответом?
В главе книги мы описывали с каких сторон можно подходить к анализу ошибок, например, можно глазками смотреть на best cases, worst cases – искать, что в них общего, какие паттерны. Также можно мануально выделять группы/кластеры и смотреть перфоманс на ней
Сейчас у нас есть LLM, поэтому вместо рутинной мануальной работы:
1. Можно кидать целые логи / датасеты (с разбором ошибок от LLM-судьи с предыдущего этапа) – в LLM, и просить кластеризовать типовые проблемы
2. Затем можно под каждую из них завести бинарный флаг "есть / нету" и включить это как чеклист ответа LLM-судьи. Для судьи я использую модель от OpenAI где SO (structured output) работает стабильно, поэтому проблем с парсингом ответа несмотря на преумножение числа полей - не возникает
3. В конце прогона агрегируем по каждой модели и получаем "след" её проблем на нашей задаче
Иметь подобную декомпозицию проблем модели и пайплайна сильно полезнее, чем иметь одно агрегированное число "вот такая-то точность". Какие-то из проблем будут критичными, какие-то менее важны, но по крайней мере у тебя появляется четкая картина характера ошибок и теперь понятно, в «какую сторону» исправлять систему
По сути как взять градиент по бенчмарку и делать back propagation 🤓
Ваш @bogdanisssimo
#Evals
Forwarded from max.sh
Новый курс по Agentic AI
Сегодня UC Berkeley стартует бесплатный MOOC курс по агентам.
Страница курса https://agenticai-learning.org/f25 с расписанием.
Каждую неделю новая лекция, квиз на усвоение материала. Вроде бы, даже какие-то домашки, но это не точно.
Ведут лекции рисерчеры из разных топовых лаб. Название первых блоков очень базовое (LLM Agents Overview, LLM with Tool Use, Agent Stack & Infrastructure) и ни о чем не говорит. Посмотрим, какое будет содержание.
Я смотрел несколько лекций предыдущей итерации, писал тут, общий фокус был на reasoning моделях и кодогенерации. Мне понравилось. Планирую активнее смотреть в этот раз и мб выкроить время поучаствовать в хакатоне.
#образование
Сегодня UC Berkeley стартует бесплатный MOOC курс по агентам.
Страница курса https://agenticai-learning.org/f25 с расписанием.
Каждую неделю новая лекция, квиз на усвоение материала. Вроде бы, даже какие-то домашки, но это не точно.
Ведут лекции рисерчеры из разных топовых лаб. Название первых блоков очень базовое (LLM Agents Overview, LLM with Tool Use, Agent Stack & Infrastructure) и ни о чем не говорит. Посмотрим, какое будет содержание.
Я смотрел несколько лекций предыдущей итерации, писал тут, общий фокус был на reasoning моделях и кодогенерации. Мне понравилось. Планирую активнее смотреть в этот раз и мб выкроить время поучаствовать в хакатоне.
#образование
agenticai-learning.org
Agentic AI MOOC
MOOC, Fall 2025
Forwarded from adapt compete evolve or die
Все больше меня захватывает ai-хайп, показали мне (спасибо!) книжку с разными рецептами про агентов Выглядит неплохо, есть MCP, A2A, HIDL, мультиагентность и прочее модное. Воды много, но готовые интересные рецепты есть.
Тизерная задача в Alfa CTF по сути состоит в том, что надо уговорить ai-агента ChatGPT-5-nano совершить деструктивные команды (дать тебе рута, реверс шелл, rm -rf /). Я впечатлился тому насколько он хорошо защищен. Типа, скрываешь команду через base64, он ее расшифровывает, аккуратно выполняет все echo, так что в echo не спрятать абьюз. И это при том, что его запромптили выполнять все твои команды. Реверс шелл я таки получил, даже не понял почему сработало, но рута не смог.
Тизерная задача в Alfa CTF по сути состоит в том, что надо уговорить ai-агента ChatGPT-5-nano совершить деструктивные команды (дать тебе рута, реверс шелл, rm -rf /). Я впечатлился тому насколько он хорошо защищен. Типа, скрываешь команду через base64, он ее расшифровывает, аккуратно выполняет все echo, так что в echo не спрятать абьюз. И это при том, что его запромптили выполнять все твои команды. Реверс шелл я таки получил, даже не понял почему сработало, но рута не смог.
Google Docs
Agentic Design Patterns
Agentic Design Patterns 👉 🧠 ✅ I’m excited to share that my new book, "Agentic Design Patterns: A Hands-On Guide to Intelligent AI Agents," is officially out! 👉 🧠 ✅ In a field moving at lightning speed, this book focuses on the durable, fundamental patterns…
Forwarded from .ml
Многие, кто обучал большие модели искусственного интеллекта, сталкивались с ситуацией, когда необходимы данные из множества источников. Но если источники совсем не из одной корпорации, то из-за GDPR или законах о защите персональных данных нет возможности обмениваться данными напрямую.
Как быть, если нужно обучать большие модели, но нельзя собирать всю информацию в одном месте?
Решение —федеративное обучение . Это система, в которой центральное устройство (сервер) объединяет усилия множества участников (устройства): каждый совершает операции на своих данных, а сервер собирает только результаты, не забирая саму информацию.
В зависимости от специфики задачи, данные на устройствах могут храниться по-разному. На основе того, как делится матрица признаков между участниками, можно выделить два подвида федеративного обучения:
📌 Горизонтальное федеративное обучение (HFL)
Суть: у разных участников данные имеют одинаковые фичи (одинаковые столбцы), но разные строки (разные пользователи/наблюдения).
📌 Вертикальное федеративное обучение (VFL)
Суть: у разных участников есть одни и те же сэмплы (одни и те же строки), но разные признаки (разные столбцы).
При этом нельзя сказать, что примеры выше оторваны от реальности. Например, Google применяет федеративное обучение для улучшения работы клавиатуры Gboard. Вместо сбора всех данных о нажатиях на своих серверах, центральное устройство получает только агрегированные обновления модели. То есть, обучение происходит прямо на устройствах пользователей, но без нарушения приватности.
💜 Этот пост написал Сергей Станко, ML-инженер в Точка Банк.
Как быть, если нужно обучать большие модели, но нельзя собирать всю информацию в одном месте?
Решение —
В зависимости от специфики задачи, данные на устройствах могут храниться по-разному. На основе того, как делится матрица признаков между участниками, можно выделить два подвида федеративного обучения:
📌 Горизонтальное федеративное обучение (HFL)
Суть: у разных участников данные имеют одинаковые фичи (одинаковые столбцы), но разные строки (разные пользователи/наблюдения).
Пример: несколько банков обучают модель для предсказания мошеннических транзакций. У всех есть одинаковые признаки по транзакциям (сумма, время, место, категория операции и т.п.), но набор клиентов у каждого банка свой. Объединяя данные через HFL, они получают более устойчивую модель, не раскрывая данные клиентов напрямую.
📌 Вертикальное федеративное обучение (VFL)
Суть: у разных участников есть одни и те же сэмплы (одни и те же строки), но разные признаки (разные столбцы).
Пример: банк и страховая компания имеют одних и тех же клиентов. У банка есть финансовые характеристики (история транзакций, кредитный рейтинг), у страховой — медицинская история и страховые выплаты. Объединив признаки в VFL, они могут построить более точную модель для оценки рисков по клиенту.
При этом нельзя сказать, что примеры выше оторваны от реальности. Например, Google применяет федеративное обучение для улучшения работы клавиатуры Gboard. Вместо сбора всех данных о нажатиях на своих серверах, центральное устройство получает только агрегированные обновления модели. То есть, обучение происходит прямо на устройствах пользователей, но без нарушения приватности.
💜 Этот пост написал Сергей Станко, ML-инженер в Точка Банк.