Всем привет!
Давайте немного расскажу о себе и о канале:)
Меня зовут Макс, я ML инженер.
Этот канал завел, потому что хочется записывать и делиться инженерными мелочами, которые встречаются по ходу работы и развития в ML.
В этом канале вы не встретите регулярных новостей мира AI или частые репосты с каналов популярных гуру индустрии. Но зато в канале можно будет прочитать о:
- хаках, которые помогли в рутине инженера
- фейлах и хаках, которые не помогли
- рефлексии на тему работы в ML (индустрия и ресерч)
- каких-нибудь pet-project, в которые удалось законтрибьютить
- докладах и конфах, которые удалось посетить
- статьях, которые удалось почитать
Цель проста: получить канал, в котором можно посмотреть грабли, которые встречаются в профессии, послушать пути их обхода или предложить свой вариант:)
Давайте немного расскажу о себе и о канале:)
Меня зовут Макс, я ML инженер.
Этот канал завел, потому что хочется записывать и делиться инженерными мелочами, которые встречаются по ходу работы и развития в ML.
В этом канале вы не встретите регулярных новостей мира AI или частые репосты с каналов популярных гуру индустрии. Но зато в канале можно будет прочитать о:
- хаках, которые помогли в рутине инженера
- фейлах и хаках, которые не помогли
- рефлексии на тему работы в ML (индустрия и ресерч)
- каких-нибудь pet-project, в которые удалось законтрибьютить
- докладах и конфах, которые удалось посетить
- статьях, которые удалось почитать
Цель проста: получить канал, в котором можно посмотреть грабли, которые встречаются в профессии, послушать пути их обхода или предложить свой вариант:)
❤2
🔄 Захотелось scheduled task
Рано или поздно MLE задумываются о запуске задач по расписанию (раз в час/день/…). В голову начинают лезть мысли, чтобы раскатать и запустить на сервере scheduled таски в cron/celery/airflow и поддерживать этот yet another pipeline на yet another framework (берем за условие, что сельдерей и airflow не раскатаны на команду в силу специфики работы, чисто самому и для себя).
Получаем ряд минусов:
❌ Разбираемся с граблями еще одного фреймворка
❌ Хостим его
❌ Смотрим в еще один ui
Сидим ворчим от этой идеи, ведь хочется делать модельки и пить кофе, пока они обучаются, а не вот это вот всё инженерное🥹
На дейлике подсказали интересную вещь, оказывается GitLab CI/CD умеет в scheduled pipelines. Для меня было не очевидно, всегда представлял пайплайны гитлаба только после триггеров типа "новый коммит", "новый MR" или более специфичные, но привязанные к gitflow. Время развивать нейронные связи и ломать собственные стереотипы:
1️⃣ В дефолтных переменных гитлаба есть переменная
2️⃣ Делаем джобу, которую хотим выполнять регулярно и стейдж под нее, в джобе не забываем прописать:
3️⃣ Через ui гитлаба заходим и настраиваем регулярность выполнения sheduled джобы
4️⃣ Готово 🎉
Чем этот подход хорош:
✅ У нас не добавляется еще одна система, которую надо поддерживать, в то время как корпоративные гитлабы, как правило, отказоустойчивы на уровне компании
✅ Знакомый ui, приятный интерфейс, прозрачная привязка к конкретному проекту
✅ Scheduled пайплайны связаны к веткам проекта, поэтому мы получаем версионирование из коробки
✅ Scheduled пайплайны обладают всеми преимуществами обычных пайплайнов (цепочки джоб, гибкие условия выполнения через настройку rules, множество дефолтных переменных окружения и гибкость настройки кастомных)
✅ Простота настройки
#routine #job
Рано или поздно MLE задумываются о запуске задач по расписанию (раз в час/день/…). В голову начинают лезть мысли, чтобы раскатать и запустить на сервере scheduled таски в cron/celery/airflow и поддерживать этот yet another pipeline на yet another framework (берем за условие, что сельдерей и airflow не раскатаны на команду в силу специфики работы, чисто самому и для себя).
Получаем ряд минусов:
Сидим ворчим от этой идеи, ведь хочется делать модельки и пить кофе, пока они обучаются, а не вот это вот всё инженерное
На дейлике подсказали интересную вещь, оказывается GitLab CI/CD умеет в scheduled pipelines. Для меня было не очевидно, всегда представлял пайплайны гитлаба только после триггеров типа "новый коммит", "новый MR" или более специфичные, но привязанные к gitflow. Время развивать нейронные связи и ломать собственные стереотипы:
$CI_PIPELINE_SOURCE, в которой нас интересует значение "schedule". Заходим в текущий .gitlab-ci.yml проекта и добавляем в классические джобы следующее условие:
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"
when: never
- when: always
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"
Чем этот подход хорош:
#routine #job
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2🫡2
Когда заметил, что Post Rate канала +/- месяц: 🙆
Please open Telegram to view this post
VIEW IN TELEGRAM
Highload++ 2024
Всем привет! Появилась возможность выбраться на конференцию, поэтому хотел бы поделиться докладами, которые удалось посмотреть:
Nvidia Triton Inference Server: строим production ML без разработчиков
Не смотря на название, выступление не было скучной лекцией формата 101. В докладе разбирается продовая архитектура в части услуги развертывания gpu серверов от компании, предоставляющей облачные ресурсы. Помимо полученных лучших практик по скалированию, используя связку k8s+triton+ray+prometheus+grafana, спикер также делится полезными хаками, такие как: упаковка образов в zsdt для параллельной разархивации, kiali - для визуализации трейсов трафика в графане, табличка выбора тулов для шаринга gpu ресурсов, автобатчинг в triton.
Как масштабировать защиту от DDoS-атак на десятки миллионов RPS. Опыт Яндекса
Доклад подойдет, чтобы начать изучать специфику атак, предлагает базовую архитектуру для иб/хайлоада: использование топорного горячего кэша и постанализа/карантина, комбинация мл и формальных правил. Но для хайлоада - очень слабый (или бизнесовый ради пиара клауд защиты?) доклад.
Буду предвзят в силу некоторого опыта по вопросу ddos-атак:
- Тема качества рассказанной архитектуры не раскрыта. Да, было пару инцидентов, но метрик качества ML моделей/рулов/их комбинации не приведено. Также не рассказали о пропорциях трафика: какая доля отсекается на капчу/блокировку ML моделью, сколько общий первый этап классификации (кэшер), какой дифф качества у второго этапа классификации по сравнению с первым.
- Вопрос slow-ddos не затронут
- К признакам/факторам для ML модели второго уровня также возникли вопросы: тысячи признаков/факторов используются, при этом среди них есть абсолютные количественные значения (например rps), что неминуемо приведет модель к оверфиту на истории, деградация приложения будет расти стремительно по мере развития сервиса, наличия промо/праздничных дней и т.д.
- не рассказали инженерку: на чем считают фичи, как передаются данные, как хостятся модели, как составляют id пользователя
Исправлять — не искать. Разработка и внедрение AI-ассиcтента для исправления уязвимоcтей в коде
Чему посвящен доклад понятно из названия, в докладе хочется отметить следующее:
- выбран топорный sast инструмент с высоким recall, модель затачивают на precision.
- для сравнения ответов моделей проводились опросы внутри AppSec отдела (внутренняя ллм арена, хех).
- Составлен качественный бенчмарк оценки качества и представлено сравнение открытых моделей на нем
- В sast&llm проектах стоит вопрос извлечения релевантных сниппетов кода в диффах репозиториев. Понравился подход, основанный не только на ast (позволяет взять связанные методы, а не просто соседние N строк), но и на dfg с разделением на входные и выходные потоки (Позволяет сократить сниппет по ast).
- Ключ к апробации ллм проекта - принудительный резолв сканирований на всю компанию:) (с предварительным MVP на 20 команд)
- В докладе также есть слайды с большим числом лучших практик и советов из собственного опыта по проекту, где каждый может найти что-то полезное для себя.
- Доля фиксов по сработкам SAST повысилась с 4% до 14% (тут вопрос - это принудительный резолв критов или импакт ллм?), в целом есть слайд с собранными метриками, можно с появлением записи посчитать интересующие бизнесовые показатели
Всем привет! Появилась возможность выбраться на конференцию, поэтому хотел бы поделиться докладами, которые удалось посмотреть:
Nvidia Triton Inference Server: строим production ML без разработчиков
Не смотря на название, выступление не было скучной лекцией формата 101. В докладе разбирается продовая архитектура в части услуги развертывания gpu серверов от компании, предоставляющей облачные ресурсы. Помимо полученных лучших практик по скалированию, используя связку k8s+triton+ray+prometheus+grafana, спикер также делится полезными хаками, такие как: упаковка образов в zsdt для параллельной разархивации, kiali - для визуализации трейсов трафика в графане, табличка выбора тулов для шаринга gpu ресурсов, автобатчинг в triton.
Как масштабировать защиту от DDoS-атак на десятки миллионов RPS. Опыт Яндекса
Доклад подойдет, чтобы начать изучать специфику атак, предлагает базовую архитектуру для иб/хайлоада: использование топорного горячего кэша и постанализа/карантина, комбинация мл и формальных правил. Но для хайлоада - очень слабый (или бизнесовый ради пиара клауд защиты?) доклад.
Буду предвзят в силу некоторого опыта по вопросу ddos-атак:
- Тема качества рассказанной архитектуры не раскрыта. Да, было пару инцидентов, но метрик качества ML моделей/рулов/их комбинации не приведено. Также не рассказали о пропорциях трафика: какая доля отсекается на капчу/блокировку ML моделью, сколько общий первый этап классификации (кэшер), какой дифф качества у второго этапа классификации по сравнению с первым.
- Вопрос slow-ddos не затронут
- К признакам/факторам для ML модели второго уровня также возникли вопросы: тысячи признаков/факторов используются, при этом среди них есть абсолютные количественные значения (например rps), что неминуемо приведет модель к оверфиту на истории, деградация приложения будет расти стремительно по мере развития сервиса, наличия промо/праздничных дней и т.д.
- не рассказали инженерку: на чем считают фичи, как передаются данные, как хостятся модели, как составляют id пользователя
Исправлять — не искать. Разработка и внедрение AI-ассиcтента для исправления уязвимоcтей в коде
Чему посвящен доклад понятно из названия, в докладе хочется отметить следующее:
- выбран топорный sast инструмент с высоким recall, модель затачивают на precision.
- для сравнения ответов моделей проводились опросы внутри AppSec отдела (внутренняя ллм арена, хех).
- Составлен качественный бенчмарк оценки качества и представлено сравнение открытых моделей на нем
- В sast&llm проектах стоит вопрос извлечения релевантных сниппетов кода в диффах репозиториев. Понравился подход, основанный не только на ast (позволяет взять связанные методы, а не просто соседние N строк), но и на dfg с разделением на входные и выходные потоки (Позволяет сократить сниппет по ast).
- Ключ к апробации ллм проекта - принудительный резолв сканирований на всю компанию:) (с предварительным MVP на 20 команд)
- В докладе также есть слайды с большим числом лучших практик и советов из собственного опыта по проекту, где каждый может найти что-то полезное для себя.
- Доля фиксов по сработкам SAST повысилась с 4% до 14% (тут вопрос - это принудительный резолв критов или импакт ллм?), в целом есть слайд с собранными метриками, можно с появлением записи посчитать интересующие бизнесовые показатели
Про поетри и версии рассказать
UPD: в другой раз😴
UPD: в другой раз
Please open Telegram to view this post
VIEW IN TELEGRAM
Приватные ключи не нужны!
Пробую себя в написании кликбейтных заголовков, но если откинуть шутки в сторону, то хочу рассказать как потратил несколько часов на неочевидный баг:
Запускал py скрипт, в котором участвует приватный ключ💥
Оказалось, что проблема известная, но непопулярная и описанная достаточно в общих чертах. На всякий случай оставил issue. Take care!
#routine
Пробую себя в написании кликбейтных заголовков, но если откинуть шутки в сторону, то хочу рассказать как потратил несколько часов на неочевидный баг:
Запускал py скрипт, в котором участвует приватный ключ
PRIVATE_KEY для аутентификации учетки и получал ошибки, которые не воспроизводились у моих коллег. Пенял на либы подгрузки переменных из .env, версию питона, на временный баг ОС...но пуля летела в колено откуда не ждали - vscode имеет багу на подгрузку переменной окружения с таким названием и наличием символов переноса строки Оказалось, что проблема известная, но непопулярная и описанная достаточно в общих чертах. На всякий случай оставил issue. Take care!
#routine
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Глупые железяки
Разбираю тут одну статью по оценке качества LLM на задаче информационной безопасности, периодически повторяю что-то, если глаз зацепился.
И вот дохожу до эксперимента, в котором проверяется умение языковых моделей находить уязвимости (картинка 1). Авторы смотрят на результат (мол
Ладно, факт есть факт, подумал я и решил ради интереса проверить, смогут ли, спустя несколько лет публикации статьи, текущие модели справиться с этой задачей? Всё-таки GPT-4 вышла в далеком 2023 ( а cutoff у нее вообще случился в 2021).
Я отправил этот кусок кода без замысловатого промпта в gpt-4o и посмотрите на 2 картинку, о боже, она тоже попалась на эту задачу?!🤢
Заподозрил что-то неладное и решил проверить. Повторил пример из статьи и обнаружил баг: в стремлении упростить сниппет кода, авторы оставили в нем ошибку, которая не позволяла корректно воспроизвести уязвимость (а точнее её отстутсвие), сервис крашился на попытке выполнить
Поэтому нельзя сказать, что текущая и старая версии chatgpt были совсем не правы, они просто изучили код не так подробно, как хотелось бы авторам, сделав допущение, что в коде ошибок нет - подсветили явную уязвимость: мы в каком-то методе сформировали запрос без параметров в возвращаемом значении и подали на исполнение.
Получается дилемма, которую часто ловлю в работе с llm как с code copilot:
Тут как нельзя кстати приходится сравнение llm с джунами, которые часто в силу отсутствия опыта решают (a) только четко поставленные задачи, и (б) - решают их в лоб.
#papers #fun
Разбираю тут одну статью по оценке качества LLM на задаче информационной безопасности, периодически повторяю что-то, если глаз зацепился.
И вот дохожу до эксперимента, в котором проверяется умение языковых моделей находить уязвимости (картинка 1). Авторы смотрят на результат (мол
createQuery возвращает параметризованный запрос) и делают очевидный вывод:(1) LLMs are not familiar with the safe practices of library functions, and
(2) LLMs cannot handle complex multi- function and multi-variable data flow patterns.
Ладно, факт есть факт, подумал я и решил ради интереса проверить, смогут ли, спустя несколько лет публикации статьи, текущие модели справиться с этой задачей? Всё-таки GPT-4 вышла в далеком 2023 ( а cutoff у нее вообще случился в 2021).
Я отправил этот кусок кода без замысловатого промпта в gpt-4o и посмотрите на 2 картинку, о боже, она тоже попалась на эту задачу?!
Заподозрил что-то неладное и решил проверить. Повторил пример из статьи и обнаружил баг: в стремлении упростить сниппет кода, авторы оставили в нем ошибку, которая не позволяла корректно воспроизвести уязвимость (а точнее её отстутсвие), сервис крашился на попытке выполнить
cursor.execute с входным tuple вместо ожидаемых параметров:TypeError: can't concat tuple to bytes
Поэтому нельзя сказать, что текущая и старая версии chatgpt были совсем не правы, они просто изучили код не так подробно, как хотелось бы авторам, сделав допущение, что в коде ошибок нет - подсветили явную уязвимость: мы в каком-то методе сформировали запрос без параметров в возвращаемом значении и подали на исполнение.
Получается дилемма, которую часто ловлю в работе с llm как с code copilot:
- Если вопрос был поставлен прямо: есть ли уязвимость (да/нет/не знаю) в коде, должна ли ллм предусматривать еще и программные ошибки, которые не позволят коду запуститься?
- Или она должна допустить, что в одной из частей код корректен и ответить на поставленный вопрос?
- Если так, то обязана ли она выбрать то же допущение, что и пользователь?
Кажется, что нет...
Тут как нельзя кстати приходится сравнение llm с джунами, которые часто в силу отсутствия опыта решают (a) только четко поставленные задачи, и (б) - решают их в лоб.
#papers #fun
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Наш отдел тут завел канал с нашими обзорами статей и конф, буду сегодня холиварить на тему ии и кибербеза с коллегами
Вход свободный, без смс и регистрации)
Запись появится после встречи в канале
Вход свободный, без смс и регистрации)
❤1
Forwarded from False Positive
This media is not supported in your browser
VIEW IN TELEGRAM
С 28 апреля по 1 мая в Сан‑Франциско проходил RSAC 2025 — международная конференция по кибербезопасности. Помимо привычных ИБ‑тем, в программе было много докладов, тесно связанных с AI разной степени применимости — от фундаментальных обсуждений AI-агентов до кейсов применения LLM для триажа, фаззинга и защиты данных.
В эту пятницу специалисты ML‑команды проведут блиц‑разбор семи докладов (по 10–15 минут на каждый) с конференции, которые привлекли наше внимание.
На встрече вы узнаете:
🔹Кейсы внедрения AI в SOC от полевых команд
🔹Какие AI‑инструменты реально помогают специалистам SOC
🔹Как применить ML для классификации данных и предотвращения их утечек
🔹Как будет меняться рынок кибербезопасности с приходом Gen AI
🔹Как интегрировать LLM‑модели в фаззинг‑тестирование и триаж уязвимостей
🔹Как LLM могут помогать маппить алерты на техники и тактики матрицы MITRE
🔹Можно ли создать круглосуточную Purple-team на основе AI-агентов
Ждём всех в Толке в пятницу, 25 июля, в 15:00.
Подключайтесь: Ктолк
#reading_group #conf #rsac
В эту пятницу специалисты ML‑команды проведут блиц‑разбор семи докладов (по 10–15 минут на каждый) с конференции, которые привлекли наше внимание.
На встрече вы узнаете:
🔹Кейсы внедрения AI в SOC от полевых команд
🔹Какие AI‑инструменты реально помогают специалистам SOC
🔹Как применить ML для классификации данных и предотвращения их утечек
🔹Как будет меняться рынок кибербезопасности с приходом Gen AI
🔹Как интегрировать LLM‑модели в фаззинг‑тестирование и триаж уязвимостей
🔹Как LLM могут помогать маппить алерты на техники и тактики матрицы MITRE
🔹Можно ли создать круглосуточную Purple-team на основе AI-агентов
Ждём всех в Толке в пятницу, 25 июля, в 15:00.
Подключайтесь: Ктолк
#reading_group #conf #rsac
❤2
LLM Benchmark in CyberSec
Вчера вышел релиз открытой модели от OpenAI, а сегодня мы уже протестировали 120B версию на внутреннем бенчмарке одной из задач ИБ - обнаружение вредоносного кода.
Хочется отметить, что модель стала лидером в категории тяжелых open-source моделей.
Более того, по метрике вызовов, релевантных вредоносной активности GPT-oss 120B и вовсе стала самой точной из протестированных LLM, обойдя закрытую модель Claude Sonnet 4!
Если есть желание узнать больше о бенчмарке и истории его создания, приходите на конференцию OFFZONE 2025 21 августа в 13:20, зал ai․zone.
UPD: случился фейкньюс, модель 120B, пост выше поправил
---
@notesdotml
Вчера вышел релиз открытой модели от OpenAI, а сегодня мы уже протестировали 120B версию на внутреннем бенчмарке одной из задач ИБ - обнаружение вредоносного кода.
Хочется отметить, что модель стала лидером в категории тяжелых open-source моделей.
Более того, по метрике вызовов, релевантных вредоносной активности GPT-oss 120B и вовсе стала самой точной из протестированных LLM, обойдя закрытую модель Claude Sonnet 4!
Если есть желание узнать больше о бенчмарке и истории его создания, приходите на конференцию OFFZONE 2025 21 августа в 13:20, зал ai․zone.
UPD: случился фейкньюс, модель 120B, пост выше поправил
---
@notesdotml
❤3🔥2