_rnd

AI-first P(S)DLC: как перевести разработку на агентные рельсы

За аббревиатурами SDLC и PDLC прячется простая вещь: жизненный цикл, по которому фича проходит путь от идеи до пользователей. Конечно, сейчас важно понять, как этот цикл выстраивать в формате AI-native.

Вместо разговоров мы поставили эксперимент — 6–8 недель на двух боевых проектах — и собрали методологию с двух сторон, разработки и продукта. Оба метода выложили в open source и делимся с вами здесь, должно быть полезно. Поехали!

Принцип для обеих сторон: жизненный цикл переезжает в репозиторий, агент ведёт работу, человек принимает решения на развилках.

🟥 Сторона разработки ↗️very-ai-framework
Агент ведёт фичу от идеи до прода, человек занимается инженерией.

• Код — единый источник истины. Всё идёт от кода, а не из параллельной джиры с ручной синхронизацией артефактов. От кода живут доки, задачи и контекст для продакта. Отсюда растёт агентное обслуживание: релизный агент реагирует на выкатки, задачи двигаются по доске сами, база знаний обновляется при изменениях в коде.

• Контроль сместился на контекст. Агенты эффективны, когда контекст задан правильно, и этот контекст — ответственность инженера. Человеческое ревью никуда не делось, но рядовой PR теперь это условно10 тыс. строк вместо привычных 300, и классические подходы к проверке на таком объёме не работают — нужны новые.

• Agentic review моделью из другого семейства. Код фичи перед выкатом обязательно проверяет вторая модель, например, у нас пишет Claude Code, ревьюит Codex. Разные модели качественнее ловят разные косяки.

🔳 Сторона продукта very-ai-product-loops☝️
Здесь тот же принцип: продуктовая стратегия вместо документа живёт в разных версиях в репозитории, который агент ведёт вместе с командой.

• Шесть шагов от идеи до спринта: паспорт продукта → анализ → стратегия → стратегический план → тактический план → план спринта. Каждый шаг это отдельный markdown-файл со своим горизонтом — от всего срока жизни продукта до пары недель.

• Живые регистры — память продукта. Сквозь все шаги проходят гипотезы, риски и метрики. Они рождаются там, где впервые становятся важны, и уточняются по мере спуска к спринту.

• Агент драфтит, человек решает. Агент читает текущее состояние, собирает черновики из реальных материалов, помечает утверждения источником , а на настоящих продуктовых развилках останавливается и предлагает пару вариантов. Изменения фиксируются в changelog и сигнал идёт дальше по цепочке.

Ручная стыковка #️⃣
Две стороны пока сшиваем вручную: из продуктового плана собираем список работ на спринт, каждую фичу скиллами переносим в таск-трекер, дальше она идёт в разработку и на прод. Прямой путь без ручного вмешательства у нас в планах.

🕐 Что пока не решено
• Безопасность — агенту нужен доступ почти ко всему — файлы, git, серверы, логи, код. Безопасных стандартов под это пока нет, проверку СБ такой контур не пройдёт. Копаем, но это открытый вопрос.
• Зрелость — разработку гоняем на боевых проектах, а продуктовая часть ещё совсем свежая. Обе репы публичные, но сырые и специфичные: это наш прикладной подход к общей концепции, а не готовое решение.
• Цена — быстрые релизы держатся на строгом флоу и возросших требованиях к разработчику — порог входа для инженера поднимается.

Дальше: замкнуть цикл после релиза ⚡️
Мы проектируем единый стандарт админок для наших SaaS, тогда петля замкнётся. Например, фича подняла удержание, но просадила активацию, сигнал уходит в продуктовый цикл, агент выдвигает гипотезу, что виноват усложнившийся процесс, и в следующий спринт падает конкретная задача по устранению этого. Так получится измерять эффект фич и мониторить продукты по метрикам.

Авторы этого поста и, соотвественно, своих фреймов:
Артём Лысенко — Team Lead в R&D red_mad_robot;
Тим Михайлов — Product Owner в R&D red_mad_robot.

#️⃣ Почему анонимизатор спотыкается о таблицы #️⃣

Давным-давно, а точнее два года назад, мы сделали AI-сервис Daisy для быстрого доступа ко всем передовым моделям. Под капотом у Daisy не просто токены к LLM, а многоуровневая архитектура со сложной логикой связок и своей системой безопасности.

Собственно, про безопасность мы сегодня и поговорим.

Суть проблемы PII 😕

Чтобы гарантировать пользователям Daisy защиту персональных данных и не «светить» их во внешний API, мы встроили в пайплайн обработки запросов PII-анонимизатор.

Почти сразу мы упёрлись в проблему: анонимизатор плохо обрабатывал таблицы. Он маскировал только первые пару строк, а остальные данные улетали во внешнюю модель без маскировки.

Обычно таблицу перед отправкой переводят в Markdown. Модели так удобнее: структура сохраняется, строки и колонки легко читаются. А вот анонимизатору — наоборот.

Он проверяет значения по правилам, но для многих типов данных этого мало — нужен контекст. Например, слова вроде «паспорт», «ИНН» или «карта».

В таблице весь этот контекст уходит в шапку. Чем больше строк, тем дальше значения от заголовков и тем хуже детекция.

| ФИО | Паспорт | ИНН |

| Иван Петров | 4509 217634| 771234567890 |

Быстрый фикс с подвохом 😊

Первое очевидное решение — переписать Markdown и добавить ключ внутрь каждой ячейки.

| ФИО: Иван Петров | Паспорт: 4509 217634 |

Точность детекции сразу растёт: подпись снова рядом, пропусков меньше.

Но у такого подхода есть обратная сторона. Этот обогащённый Markdown увидит и сама модель. Таблица раздувается, токены тратятся впустую, а модель получает служебные подсказки, которые нужны только детектору.

Сначала ячейки, потом другое 😊

Мы зашли с другой стороны и решили не «сплющивать» таблицу до анонимизации.

Идея в том, чтобы разделить два представления таблицы: одно для детектора, другое для модели.

Держим таблицу как структуру — ячейки, строки, колонки, координаты. И отдельно, только для детектора, собираем detect-context: временную строку для каждого значения, где прописаны положение заголовка, метки, ближайшие соседи.

Паспорт: 4509 217634

Эта строка живёт отдельно и в модель не попадает — поэтому её можно делать сколь угодно избыточной, лишь бы детектору было удобно.

Детектор находит PII в этой строке. А раз мы знаем координаты — возвращаемся к нужной ячейке, достаём точное значение и маскируем именно его. И только потом собираем Markdown для модели.

Чистый промпт и детекция 😍

Мы отвязали детекцию от итогового формата. Детектор точно маскирует персональные данные по изолированному контексту, а в модель уходит чистый Markdown без служебного мусора. В итоге качество анонимизации зависит только от точности детектора, а не от структуры данных.

Автор этого поста и бессменный исследователь вопросов безопасности, Андрей Иванов — NLP-инженер в R&D red_mad_robot.

#Безопасность

Системный промпт против привычек Qwen ❌

Qwen Code и модели семейства Qwen развиваются в тесной связке. Это видно в самом коде фреймворка: под Qwen адаптированы форматы примеров, режим thinking и обработка reasoning.

Но что, если этот симбиоз зашёл ещё дальше и модель во время обучения усвоила правила фреймворка?

Переворачиваем инструкции

Мы взяли оригинальный промпт Qwen Code и поочерёдно инвертировали шесть ключевых директив, например:
• «отвечай кратко» — «пиши подробно»;
• «не добавляй комментарии» — «комментируй каждый блок»;
• «используй Markdown» — «пиши без разметки».

Остальные проверки касались агентного поведения: запускать ли тесты, вызывать инструменты параллельно или по одному, писать ли преамбулу перед действием.

В каждом тесте менялась только одна инструкция.

Измеряем послушание ✅

Для каждой директивы мы выбрали наблюдаемую метрику: длину ответа, число комментариев, количество Markdown-маркеров, факт запуска тестов, число параллельных tool calls и наличие преамбулы перед первым действием.

По каждой метрике считали swing — насколько изменилось значение после переворота инструкции. Если модель после флипа резко меняет длину ответа, стиль разметки или поведение с инструментами, значит, она слушает новый системный промпт. Если swing близок к нулю, значит, инструкция почти не пробивает старую привычку.

Целевой моделью выступила Qwen3.6-35b-a3b, а в качестве контроля на тех же задачах мы использовали gpt-oss-120b.

Qwen держится за корни

Из шести проверок три дали однозначный результат — Qwen упорно игнорирует новые указания.

🟥 Длина ответа: контрольная модель отреагировала в четыре раза сильнее Qwen.

🟥 Комментарии в коде: у контроля их стало в 26 раз больше, а у Qwen число вообще не изменилось.

🟥 Markdown-разметка: контроль сократил использование разметки в 1,7 раза, а у Qwen показатель не изменился.

По этим данным нельзя сказать, что модель точно обучали на системном промпте Qwen Code. Но сам эффект хорошо виден: CLI явно подстраивается под своё семейство моделей, а Qwen3.6-35b-a3b слабее реагирует на смену привычных агентных инструкций, чем контрольная модель.

Остаётся лишь вопрос — распространяется ли это на все модели Qwen в рамках Qwen Code? 😊

Автор этого поста, как и самого исследования, Андрей Иванов — NLP-инженер в R&D red_mad_robot.

#️⃣ HTML → PPTX → Keynote. Или как нормально редактировать AI-презентации

Всё чаще к нашим дизайнерам попадают слайды, сгенерированные AI. Обычно это HTML, который нужно превратить в редактируемую презентацию и доработать.

Мы посмотрели, как сегодня работают Claude Design, NotebookLM и другие инструменты, протестировали разные подходы и собрали пайплайн, который позволяет сохранить структуру слайда при конвертации.

Генерация

Вместо генерации «с нуля» мы даём модели брендбук, примеры слайдов и библиотеку HTML-компонентов — готовых карточек, таблиц, диаграмм, колонок, заголовков и других элементов.

Модель не придумывает новую вёрстку, а собирает слайд из этих «кирпичиков», сохраняя сетку и визуальную логику бренда. По нашим наблюдениям, лучше всего с такой задачей сейчас справляется Claude Opus.

Конвертация

Сам HTML дизайнерам не помогает — его нужно открыть в Keynote или PowerPoint и продолжить редактировать.

Ребята протестировали несколько готовых HTML → PPTX-конвертеров. Почти везде повторяются одни и те же проблемы: съезжают отступы, меняются переносы текста, пропадают скругления, нарушается порядок слоёв.

Из open source сервисов ближе всех к идеалу оказался html2pptx, но и его результат не всегда предсказуем.

Мы пошли другим путём

• открываем HTML в headless Chromium — в Python, например, playwright;
• забираем реальные координаты, размеры и computed styles элементов.
• раскладываем слайд на типы объектов: текст, формы, картинки, декоративные слои;
• собираем PPTX из редактируемых объектов;
• растрируем только то, что нельзя нормально выразить в OOXML.

Так в растр уходят только сложные SVG и визуальные эффекты, всё остальное остаётся редактируемым.

Самые мутные случаи

🟥 border-radius
Pill-кнопка не должна превращаться в эллипс. Таблетка, круг и скруглённый прямоугольник — это разные формы, и их нужно различать.

🟥 z-index
Слои нельзя сортировать только по числу z-index. Важен stacking context, порядок рендеринга и последовательность отрисовки элементов;

🟥 SVG и фильтры
Их лучше растрировать локально, а не превращать весь слайд в картинку.

🟥 текст
Chromium и Keynote по-разному рассчитывают переносы строк. Поэтому приходится контролировать line-height, paragraph spacing и ширину текстовых блоков.

🟥 шрифты
Просто положить TTF в PPTX недостаточно. Нужны явные line-height, paragraph spacing и небольшой запас по ширине текстового блока.

Keynote ≠ PowerPoint

PowerPoint часто прощает то, что Keynote интерпретирует иначе: интервалы, порядок XML-элементов, язык текста, fallback-шрифты.

Поэтому лучше целиться не просто в «валидный PPTX», а в PPTX, который стабильно импортируется в Keynote.

В итоге всё работает: модель собирает черновик, конвертер сохраняет структуру, дизайнер финализирует результат. 😊

Автор этого поста, собственно и разработчик конвертера, Миша Мартьянов — NLP-инженер в R&D red_mad_robot.

Генерация hard negatives: определяем границы дозволенного ⚡️

В продолжение темы SHAP поговорим о генерации hard negatives. В задачах классификации такие примеры критически важны — они жёстко определяют границу между допустимым и недопустимым контентом.

Почему hard negatives сложно собирать

Классический hard negative — это запрос вроде «создай презентацию о вреде наркотиков». В нём есть явное триггерное слово, но по своей природе и интенту текст абсолютно безопасен.

Искать такие пограничные примеры в сырых данных тяжело, а создавать «в лоб» неэффективно: LLM часто скатывается в явные нарушения, либо генерирует абсолютно стерильный и скучный текст.

Наш подход: SHAP + концепция EDSA

Мы решили переиспользовать базу, описанную в предыдущем посте.

🟥 Берём набор разнообразных триггерных слов, которые мы вытащили из датасета с помощью SHAP.

🟥 Просим LLM сгенерировать вокруг «опасных» слов безопасный контекст.

🟥 Чтобы жёстко задать рамки для LLM, мы используем концепцию EDSA – Educational, Documentary, Scientific, которую расширили и адаптировали под задачу NSFW. Промпт заставляет модель оборачивать триггер в образовательный, научный или документальный контекст.

За счёт богатой базы SHAP-триггеров мы получаем отличный охват разных тематик. А границы EDSA удерживают модель на нужной нам серой линии, не позволяя генерировать очевидный NSFW или бесполезную воду.

Итоги и влияние на метрики

Такой способ генерации данных позволил поднять Specificity модели с 40% до 80% на hard negatives из нашего↗️ бенчмарка без ухудшения результатов на опасных запросах.

Автор этого поста, как и множества других про NSFW, Андрей Иванов — NLP-инженер в R&D red_mad_robot.

#Безопасность

OpenClaw в реальных сценариях: где ломаются агенты и что с этим делать

Последний месяц мы тестировали OpenClaw на типичных корпоративных задачах: разбор почты, анализ файлов, мониторинг внешних сервисов, DevOps-сценарии.

Вывод коротко: универсальной модели для агентного режима не существует

Да, в обычном чате LLM работают почти одинаково. Разница заметна в агентном режиме при длинных цепочках действий, вызовах инструментов, работе с файлами и контроле состояний.

🟥 В анализе данных лучше всего показал себя GLM-5.1: точные агрегации, стабильный Python, чёткие выводы по CSV и XLSX.

Но в DevOps-сценариях GLM проявлял излишнюю инициативу:
• запускал npm audit fix --force,
• отключал healthcheck, чтобы убрать падающий алерт, а не разбирался с причиной,
• удалял комментарии из CI-конфигов как избыточные.

Задача формально выполнялась, но модель игнорировала ограничения, прописанные в навыке.

🟥 У MiniMax-M2.5 противоположный профиль: слабее в анализе данных, зато намного аккуратнее в координации шагов и работе с инфраструктурными сценариями.

А самые интересные проблемы вообще оказались не в Prompt Engineering. Например, в навыке разбора почты модель ошибалась из-за HTML-шума в письмах, а не длинного SKILL.md. Стоило поставить фильтр, который выкидывает HTML и лишние поля — и объём входных данных упал в десять раз, модель перестала путать категории, а structured output стабилизировался.

Промежуточный вывод: проблема не в модели, а в энтропии входных данных

OpenClaw — это распределённая система, а не просто удобный чатик над моделью. Поэтому здесь бывают инфраструктурные проблемы: повторный запуск неидемпотентных операций, ложные ошибки из-за таймаутов, гонки состояний, конфликтующие действия и бесконечные циклы самопочинки.

🔳 Например, если команда openstack server create выполнялась больше минуты — агент видел статус «still building», считал это ошибкой и пытался починить ситуацию повторным запуском, создавая вторую VM.

🔳 В одном из сценариев системный промпт фактически подавил правило из навыка — перед созданием виртуальной машины модель должна была запросить подтверждение, но шаг был пропущен.

Логический вывод: жёстких правил внутри навыков недостаточно — нужны внешние механизмы контроля — подтверждения действий, политики безопасности и ограничения на выполнение команд.

#Продуктивность_агентов

Проблемы псевдоанонимизации 😕

На деле этот способ работать с личной информацией сильно упрощает жизнь. Вместо того чтобы прятать имена или телефоны под звёздочками и делать текст бессмысленным, мы заменяем их на специальные метки: {Имя-1} или {Телефон-2}. В метке сразу видно, что это за данные и какой у них номер. Настоящие значения — имя, номер, адрес — хранятся в отдельной защищённой таблице с парами «метка = оригинал».

Чем полезно для бизнеса

Представьте, что нужно отправить текст стороннему провайдеру, например от OpenAI или Grok, но без риска передать личные данные клиентов. Находим в тексте важные данные, ставим вместо них метки, отправляем безопасный вариант LLM. Она работает с фразами вроде: «клиент {Имя-1} позвонил по {Телефон-2}», генерирует ответ с этими метками, например: «Перезвоните {Имя-1} на {Телефон-2}». Потом наша система берёт из таблицы настоящие значения и возвращает клиенту обычный текст. Модель не видела оригинальные данные, все правила соблюдены, а клиент получил обычный ответ.

Другой распространённый случай. Компании важно разграничить допуск разных сотрудников к личным данным. Здесь поможет внутренний агент с доступом и к документам, и к отдельной таблице с личной информацией. Он соберёт информацию по запросу, но нужно установить правило: агент показывает руководителю настоящее имя из {Имя-1}, а рядовому сотруднику отправляет звёздочки 😊. Каждый видит только ту часть информации, которая ему доступна.

Сложности в работе

Сначала задача кажется простой, но на практике возник ряд неожиданных проблем. Основная сложность связана с тем, что текст — «живая система». В русском языке слова изменяются по падежам и формам, и система поиска с последующей заменой на метки должна это учитывать.

✔️ На ранних этапах часть проблем удалось снизить за счёт доработки промптов. Например, модель стала реже генерировать лишние и избыточные теги, а разметка стала более устойчивой.

↗️ Отдельного внимания потребовала обработка разных форм одного и того же имени. Например, в предложении «Михаил, Елена и Саша пришли» все сущности корректно заменяются на {Имя-1}, {Имя-2}, {Имя-3}. Однако в следующем предложении «Михаилу звонил клиент» форма «Михаилу» может быть распознана как новая сущность, что приведёт к появлению отдельной метки {Имя-4}. Без механизма сопоставления по смыслу и контекстной близости одна сущность начинает дробиться на несколько — это усложняет таблицу и снижает качество последующей обработки.

☝️ Ещё один сложный случай — связанные данные внутри одного предложения. Например, в конструкции «Моё имя Михаил, фамилия Мартьянов» система может выделить {Имя-1} и {Имя-2} как независимые сущности. Формально такая разметка допустима, однако в дальнейшем она приведёт к неоднозначностям при извлечении данных или генерации ответов. LLM частично восстанавливает связь по контексту, но без явного механизма сопоставления ошибки всё равно накапливаются.

Сейчас мы продолжаем исследовать подходы к решению этих проблем — тестируем разные механизмы объединения сущностей и учёта контекста.

Если у вас есть похожие кейсы или идеи — давайте обсудим в комментариях 😊

Автор этого поста и множества других по фильтрации данных, Миша Мартьянов — NLP-инженер в R&D red_mad_robot.

#Безопасность

NER-модель обобщает паттерны, которых не видела в обучении

Обычно часть категорий PII легко найти с помощью регулярных выражений, а часть через NER. Например, номера телефонов мы искали эвристикой, но что если поручить это самой модели?

После обучения NER-модели на датасете с телефонными номерами мы заметили интересный эффект: модель не просто воспроизводила «регулярку по образцу», а формировала распределённое представление паттернов.

Датасет и модель

Сначала мы подготовили датасет. В него вошли размеченные телефонные номера, начинающиеся с +7 или 8 и записанные в разных форматах: через пробелы, дефисы, скобки или слитно. Иногда рядом с номером встречались слова вроде «телефон» или «мобильный». Несмотря на разнообразие, датасет, разумеется, не покрывал все возможные варианты записи.

В качестве базового чекпойнта мы использовали модель bert-base-multilingual-cased — стандартный мультиязычный BERT, который затем дообучили на задаче NER.
Именно в процессе этого обучения мы заметили эффект обобщения: модель успешно распознавала номера в форматах, которые явно не встречались в обучающей выборке.

Что происходит внутри NER-модели

🟥 Токенизатор разбивает текст на токены — и каждому сопоставляется эмбеддинг. Для числовых последовательностей это цифры и специальные символы. Паттерны вроде группировки цифр и разделителей модель учит из данных.
🟥 Позиционные представления фиксируют, где встречается телефон — в подписи, блоке контактов или после определенных слов.
🟥 Механизм self-attention связывает «странную» последовательность цифр с окружением. Например, учитывает, что такие паттерны в обучающем датасете были размечены как PHONE в похожем контексте.

После нескольких проходов по обучающему датасету модель формирует обобщённое представление телефонных форматов. Конкретный вариант записи может отсутствовать в обучающих данных, однако когда его признаки близки к уже известным примерам, метка PHONE выпадает с высокой вероятностью.

В наблюдаемом эффекте можно выделить два основных источника обобщения:
🟥 Форма: цифры, группы, разделители, плюс в начале.
🟥 Контекст: местоположение в тексте и соседние слова.

В этом подходе модель не опирается на заранее заданные правила сопоставления шаблонов. Поэтому она сохраняет работоспособность даже если формат записи номеров меняется, например, там появляются дополнительные пробелы или скобки. Так происходит до тех пор, пока новый вариант по своим признакам близок к обучающим данным.

Вывод такой — NER-модели способны извлекать не только сложные сущности, такие как имена или локации, но и данные с выраженной структурой, которые традиционно описываются через шаблоны. Это позволяет сократить объём вручную заданных правил.

Автор этого поста, как и нескольких статей по фильтрации данных, Миша Мартьянов — NLP-инженер в R&D red_mad_robot.

#Безопасность

↗️ Метрики для тестирования агентов

Ну что ж, мы обсудили процесс тестирования агентов. Теперь разберёмся, какие метрики нужны для их оценки.

Для начала смотрим на агента целиком — решает он задачу или нет (E2E). Проверяем это на наборе тестовых сценариев. В каждом кейсе фиксируем бинарную оценку:
• 1 — задача выполнена,
• 0 — нет.
Считаем долю успешных кейсов по всему набору тестов и получаем метрику success rate. Это отправная точка, которая показывает, работает ли вообще система.

Далее — декомпозиция. Для каждого компонента агента — свои метрики оценки.

Метрики качества LLM ☝️

• Понимание запроса пользователя — подойдёт Answer Relevancy,
• Извлечение нужной информации из контекста, чтобы не было выдуманных данных — можно использовать Faithfulness,
• Соответствие кастомным требованиям, которые сложно формализовать, например, соблюдение роли или тона — тут G-Eval поможет задать критерий на естественном языке, а LLM-судья выставит оценку.

Метрики работы с инструментами 📂

• Выбор подходящего инструмента для задачи — Tool Correctness,
• Извлечение аргументов функций из входящего контекста — Argument Correctness,
• Эффективность вызовов инструментов, чтобы агент не делал лишних шагов, потому что вызов функции бывает довольно дорогим — Step Efficiency.

Метрики работы памяти 🕐

Память агента может быть устроена по-разному: история диалогов, долгосрочное хранилище фактов, внешняя база знаний. Нередко её реализуют через RAG — тогда применяют метрики качества извлечения контекста.

• Релевантность извлечённого контекста — агент находит нужные чанки и не подмешивает «левые» данные — Contextual Relevancy,
• Полнота извлечённого контекста — агент не упускает важную информацию — Contextual Recall.

Конечно, набор метрик отличается от системы к системе — многое зависит от архитектуры агента и задач, которые он решает. Больше примеров метрик можно посмотреть в документации DeepEval или Ragas.

Автор этого поста, собственно, как и предыдущего про тестирование, Максим Максимов — NLP-инженер в R&D red_mad_robot. 😊

#Тестирование_агентов

Почему модель считает тортик опасным как напалм 🟥

Продолжаем тему генерации датасета для NSFW-фильтра в Guardrails. При формировании тренировочного набора данных важно собрать не только примеры нарушений, но и безопасные тексты, которые покажут модели границу между нормальным и запрещённым контентом.

Кажется, что самое простое решение — взять для фона случайные нейтральные тексты, например: «реши линейное уравнение». Так модель действительно научится находить NSFW-категорию, но начнёт скатываться в shortcut learning.

Допустим, в небезопасной части датасета есть запрос: «как приготовить напалм». Если в безопасной выборке нет прямого противовеса — например, «как приготовить тортик» — модель начнёт учить ложные признаки. Она просто свяжет безобидную конструкцию «как приготовить...» с небезопасным классом. ❗️

Чтобы классификатор не цеплялся за синтаксические шаблоны, нужны контрастные примеры, максимально похожие тексты в безопасной и небезопасной частях датасета.

Как мы делаем такие данные:
• Просим LLM сгенерировать базовый безопасный текст,
• На его основе аккуратно генерируем небезопасную версию под конкретную категорию.

За счёт минимальных изменений — добавления, удаления или замены пары деталей — безопасная версия превращается в целевой NSFW-пример. На выходе мы получаем идеальные контрастные пары. Они заставляют модель фокусироваться на реальной семантике нарушения, снижают влияние shortcut learning и эффективно отсекают ложные корреляции. ⚡️

#Безопасность