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

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

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

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

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

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

#routine

Быть тревожником + IT’шником:
ловить бессонницы после релиза очередной sota на SWE-bench 🤬

OFFZONE - всё! ®️

Второй год подряд приезжаю на эту конфу и могу точно сказать, что она стоит потраченного времени (и возможно даже денег, но в этот раз прошел через постель доклад) 😄

Треки, связанные с AI/ML, плотно вошли мир кибербеза и им дают всё большие залы с каждым годом.

Также интересно наблюдать, как улучшился материал про GenAI на всех конференциях (не только кибербезных): докладчики сравнивают genAI vs людей vs тулы, создают эвалы/бенчмарки и делятся метриками, а в выступления без метрик сразу вгрызается зал на секции QA 📈

Как говорят на западе:
Reliability >> Capability

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

В 2024, потягивая пиво с Колей из ML команды бизона (aka незаменимый ведущий ai трека на offzone), я сказал, что было бы круто в следующий раз поделиться деталями проекта по анализу вредоносного кода, поэтому в двойне ценно, что год спустя у нашей команды получилось рассказать часть в паблик!

Отдельное спасибо всем, кто пришел послушать мой доклад, задавал вопросы или писал их в телеге! 🥰

Думаю, что запись скоро появится тут, а презу скину следующим сообщением:)

Читаем вместе. ИИ в AppSec: могут ли LLM работать с уязвимым кодом

[хабр-обзор] [папира]

Всем привет!

Решил расширить RG еще и на тексты Хабр, сделал разбор статьи LLMs Cannot Reliably Identify and Reason About Security Vulnerabilities (Yet?): A Comprehensive Evaluation, Framework, and Benchmarks. В качестве затравки — несколько тезисов из разбора:

➡️ Результаты бенчмарка — «фотография во времени», быстро устаревающая не только по списку оцененных моделей, но и по попаданию данных в cut-off более современных LLM. Бенчмаркам на безопасность кода критически не хватает подходов по автоматическому обновлению на подобие SWE-rebench.

➡️ Очень зашли гипотезы про согласованность рассуждений и ответов, проверка на «пропатченном» коде и эксперименты с аугментацией.

➡️ Так, например, даже сильные модели ломаются на стресс-аугментациях, таких как изменения в уязвимом коде названий методов/переменных или добавление неиспользуемого кода.

➡️ Наглядная секция про техники промптинга. Практический вывод: роль-ориентированные инструкции и пошаговый CoT заметно улучшают качество (особенно в zero-shot). Но при наличии few-shot инструкций импакт от CoT снижается. Это может помочь сэкономить контекста в некоторых задачах.

➡️ Ограничение длины контекста в реальных кейсах играет критическую роль, поскольку код, приводящий к уязвимости, может находиться не только в разных частях файла, но и в разных частях проекта. Тут стоит отойти от академических статей и посмотреть на инженерные подходы к отбору контекста разработчиками Cursor, Claude-code и прочих копайлотов для разработки.
__________________

Макс Митрофанов, ML-лид направления AppSec 🟥

Основные тезисы, вокруг которых строил работу в 2025-м

Поддерживая общую традицию, провожаю год размышлениями вокруг и около работы инженера по машинному обучению (разгон о t-shaped инженерах продуктовых команд).

Это всё добро копилось для отдельных постов, но я так и не смог порадовать вас их публикацией:)

Часть 1 (вы тут)
Часть 2

1️⃣ Меняется ландшафт задач ML-инженера

Что раньше находилось за гранью понимания стейкхолдеров?
*тут смежник помогал с тз, сбором данных и разметкой* -> чистка данных -> фиче-инжениринг -> обучение модели -> валидация -> написание обертки для прода -> *тут мы смотрим как смежник радуется, что эта магия работает*

Теперь же LLM-ки схлопывают первые 3 этапа нашей работы (не совру, если скажу, что 99% проектов решаются через context-engineering/RAG без файнтюна), а LLM-API настолько простое, что последний пункт тоже не требует специфики MLE.

Велик соблазн сократить всех мльщиков и просто научить остальное R&D работать с OpenAI-API, да? (Ладно, оставим бедолаг делать олдовый ML, иногда же мы хотим дешевый highload без кластера из GPU)

Прогноз на 2026 #1: ограничения ресурсов в проде будет дальше толкать спрос на small-LM модели из-за их низкого порога входа и острого дефицита железа (разное и одновременное: санкции, ограничение рынка предложения, ограничения production систем, тренд на self-hosted).

2️⃣ *смежник сам собрал данных и наинженерил промпты* -> валидация -> *смежник сам затащил в прод*

Да-да, внимательный читатель заметил в цепочке звено, которое требует определенного скилла. У людей, только сейчас получивших доступ к работе с моделями (пусть и большими языковыми), напрочь отсутствует привычка делать качественную валидацию, как правило проживая следующие стадии:
- Вайб-чекнуть на 2-5 кейсах, что модель умеет решать задачу и катить в прод
- Пытаться докидывать few-shot на каждый фолс
- Паниковать от галлюцинаций, когда меняется модель на LLM-бэкенде
- Стать заложником проекта, уточняя промпт и переходя с LLM-flow к агентам, так и не поняв природу галлюцинаций

Чтобы научиться в валидацию, рекомендую замечательную подборку постов от Рината про то, как за неделю привести в порядок типичный LLM проект.

Нужен ли обязательно MLE, чтобы строить валидацию? 2025 показал, что да, но лишь из-за привычки мерить качество у одних, и отсутствие этого навыка у других.

Прогноз на 2026 #2

: LLM фичи с автоматическим бенчмарком (без human-in-the-loop) станут таким же стандартом, как и unit-тестирование в разработке.

Прогноз на 2026 #3

: Как на собеседованиях, так и в работе умение погрузиться в домен продукта станет цениться значительно выше общих знаний теории по машинному обучению. Многие LLM фичи не требуют знаний о способах претрейна или особенностях архитектуры, но неумение грамотно оценить продуктовую ценность может вылиться в убытки для компании, которая сделала ставку на AI.

Основные тезисы, вокруг которых строил работу в 2025-м

Часть 1
Часть 2 (вы тут)

3️⃣ 0.9 * 0.9 * 0.9 * 0.9 * 0.9 = 0.6

О чем речь? О качестве современных агентов. LLM обладают некоторой стохастичностью ответа, могут иметь галлюцинации, поэтому математика агентских систем может быть удручающей: при качестве отдельного ответа 90% мы получаем на 5 итерациях агента с качеством 60% из-за того, что ошибка на одном из шагов повлияет на все последующие.

По этой причине каждому советую побороть желание сразу бежать делать агента и следовать следующей цепочке:
request -> flow -> agent

Прогноз на 2026 #4: Многие LLM-agent проекты схлопнутся, поскольку агенты на фронтир моделях не смогут адаптироваться под переезд на более дешевые/маленькие LLM (ограничение production, или требования заказчика/регулятора, или снижение бюджета). Развитие small-LM не успеет дойти до нужного качества в 4B моделях, приблизившись к нему только в 2027 году.

4️⃣ Притча о мальчике, который кричал "волки" "LLM"

R&D очень хочет построить агентов, а бизнес очень хочет рассказать об LLM-агентах клиентам/инвесторам (потому что кривая хайпа по гартнеру). Эта лихорадка приводит к тому, что многие проекты лоббируются и внедряются без должной проверки качества. Но с насыщением рынка у всех появятся LLM фичи. А раз есть у всех, то это не назвать конкурентным преимуществом. На чем вывозить дальше?

Прогноз на 2026 #5

: Рынок изменит риторику с вопроса "а может ли агент делать Х?" на вопрос "с каким качеством агент может Х?", само наличие LLM в продукте перестанет быть конкурентным преимуществом.

5️⃣ Как же мерить качество LLM фичей?

За этот год собрал коллекцию паттернов и антипаттернов оценки качества, которым хотел бы поделиться с вами:
1) Лабы жадно пылесосят интернет, поэтому ценность открытых бенчмарков сводится на нет ("Training on the test set is a new art form", - Андрей Карпати). Верьте регулярно обновляемым бенчмаркам (как SWE-rebench) или стройте свой закрытый (как LLM in business workloads). К слову, мы пошли по второму пути для оценки LLM в обнаружении вредоносного кода.
2) Не используйте LLM судей. Во-первых смотрите выше в посте п.3, во-вторых они предвзяты к длине и стилю текста, в-третьих деградируют при смене модели.
3) Следите за стабильностью ответа, делайте тесты на воспроизводимость с аугментацией входных даннх (подчерпнул из разбора статьи по LLM в анализе уязвимостей)
4) Тестируйте не только финальное решение, но и цепочку размышлений. Используйте SGR/SO для валидации качества промежуточных этапов размышления модели.

Прогноз на 2026 #6

: Крупные вендоры и независимые консалтинговые агентства начнут монетизировать оценку качества агентов в коммерческих рынках. Появятся закрытые бенчмарки, на которые станут опираться вендоры для продвижения своих AI-first продуктов

P.S. Всё, пошел резать салаты к новому году, всех обнял 🎄