notes.ml

Глупые железяки

Разбираю тут одну статью по оценке качества 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

Приватные ключи не нужны!

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

Запускал py скрипт, в котором участвует приватный ключ PRIVATE_KEY для аутентификации учетки и получал ошибки, которые не воспроизводились у моих коллег. Пенял на либы подгрузки переменных из .env, версию питона, на временный баг ОС...но пуля летела в колено откуда не ждали - vscode имеет багу на подгрузку переменной окружения с таким названием и наличием символов переноса строки 💥

Оказалось, что проблема известная, но непопулярная и описанная достаточно в общих чертах. На всякий случай оставил issue. Take care!

#routine

Про поетри и версии рассказать

UPD: в другой раз😴

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% (тут вопрос - это принудительный резолв критов или импакт ллм?), в целом есть слайд с собранными метриками, можно с появлением записи посчитать интересующие бизнесовые показатели

notes.ml pinned a photo

пов: ai трек на кибербез конфе😅

#fun

Когда заметил, что Post Rate канала +/- месяц: 🙆

При настройке ci/cd переживаешь:
- отрицание
- гнев
- торг <— вы здесь
- депрессия
- принятие

#fun

🔄 Захотелось scheduled task

Рано или поздно MLE задумываются о запуске задач по расписанию (раз в час/день/…). В голову начинают лезть мысли, чтобы раскатать и запустить на сервере scheduled таски в cron/celery/airflow и поддерживать этот yet another pipeline на yet another framework (берем за условие, что сельдерей и airflow не раскатаны на команду в силу специфики работы, чисто самому и для себя).

Получаем ряд минусов:
❌ Разбираемся с граблями еще одного фреймворка
❌ Хостим его
❌ Смотрим в еще один ui

Сидим ворчим от этой идеи, ведь хочется делать модельки и пить кофе, пока они обучаются, а не вот это вот всё инженерное 🥹

На дейлике подсказали интересную вещь, оказывается GitLab CI/CD умеет в scheduled pipelines. Для меня было не очевидно, всегда представлял пайплайны гитлаба только после триггеров типа "новый коммит", "новый MR" или более специфичные, но привязанные к gitflow. Время развивать нейронные связи и ломать собственные стереотипы:

1️⃣ В дефолтных переменных гитлаба есть переменная $CI_PIPELINE_SOURCE, в которой нас интересует значение "schedule". Заходим в текущий .gitlab-ci.yml проекта и добавляем в классические джобы следующее условие:


rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - when: always

2️⃣ Делаем джобу, которую хотим выполнять регулярно и стейдж под нее, в джобе не забываем прописать:

rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"


3️⃣ Через ui гитлаба заходим и настраиваем регулярность выполнения sheduled джобы
4️⃣ Готово 🎉

Чем этот подход хорош:
✅ У нас не добавляется еще одна система, которую надо поддерживать, в то время как корпоративные гитлабы, как правило, отказоустойчивы на уровне компании
✅ Знакомый ui, приятный интерфейс, прозрачная привязка к конкретному проекту
✅ Scheduled пайплайны связаны к веткам проекта, поэтому мы получаем версионирование из коробки
✅ Scheduled пайплайны обладают всеми преимуществами обычных пайплайнов (цепочки джоб, гибкие условия выполнения через настройку rules, множество дефолтных переменных окружения и гибкость настройки кастомных)
✅ Простота настройки

#routine #job

Всем привет!
Давайте немного расскажу о себе и о канале:)
Меня зовут Макс, я ML инженер.

Этот канал завел, потому что хочется записывать и делиться инженерными мелочами, которые встречаются по ходу работы и развития в ML.
В этом канале вы не встретите регулярных новостей мира AI или частые репосты с каналов популярных гуру индустрии. Но зато в канале можно будет прочитать о:
- хаках, которые помогли в рутине инженера
- фейлах и хаках, которые не помогли
- рефлексии на тему работы в ML (индустрия и ресерч)
- каких-нибудь pet-project, в которые удалось законтрибьютить
- докладах и конфах, которые удалось посетить
- статьях, которые удалось почитать

Цель проста: получить канал, в котором можно посмотреть грабли, которые встречаются в профессии, послушать пути их обхода или предложить свой вариант:)

Channel created