_rnd

#️⃣ 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.

DCD: Domain–Collection–Document ↗️ Выпустили статью на arXiv, в которой представили DCD Design — архитектурный подход к организации пространства знаний и обработке запросов в RAG-системах. DCD организует знания в виде явной иерархии и ограничивает область поиска ещё до извлечения документов. В статье: • объясняем, как устроен DCD; • сравниваем его с Naive RAG, Contextual RAG и RAPTOR; • показываем результаты экспериментов на собственном бенчмарке; • открываем код и датасет. Если хочется разобраться на русском — уже вышел материал на Хабре. А все детали экспериментов, метрики и оценки — в статье↗️на arXiv.

⚡️ Открываем бенчмарк для детекции PII в русском тексте Мы тут много рассказывали про работу guardrails. А теперь выкатываем в открытый доступ бенчмарк для детекции персональных данных на русском языке. На нём можно сравнивать NER-модели, PII-детекторы и системы анонимизации. Внутри датасета 21 тип персональных данных: • ФИО: имя, фамилия, отчество; • адресная иерархия: страна, регион, город, район, улица, дом; • контакты: email, телефон, URL, IP; • документы: паспорт, СНИЛС, ИНН, ОМС, банковская карта, водительское удостоверение, военный билет, свидетельство о рождении. Датасет состоит из синтетических данных, а также реальных примеров из продакшен-логов, где персональные данные заменены на синтетику. Внутри сгенерированные данные в формате документов + сложные пограничные кейсы и опечатки. Все данные представлены в формате BIO. Разметка и валидация выполнялись частично вручную, частично с помощью LLM. В карточке датасета описали таксономию сущностей и протокол оценки, а ещё добавили результаты популярных открытых моделей для удобного сравнения. 😊 Прогоняйте свои анонимайзеры, PII-детекторы и NER-модели, ломайте бенчмарк и делитесь результатами в комментариях. ↗️ Hugging Face

Автор этого поста, как и многих других про NER и PII, Женя Андриевская — 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.

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

SHAP против shortcut learning в открытых данных ⚡️ Вы должно быть помните наш пост про тортик и напалм — о генерации контрастных пар. Но что делать с готовыми датасетами из open-source, в которых нет таких пар антиподов. Если просто попросить LLM собрать пары на основе готовых данных — получатся либо галлюцинации, либо однообразные ответы. Например, нейросеть будет подставлять слово «книга» на место любого небезопасного контента. Наш подход: точечная замена через интерпретируемость Для этого достаточно NSFW-классификатора, который хорошо находит действительно опасные тексты. Схема действий: 1️⃣ Прогоняем небезопасные примеры датасета через метод интерпретации SHAP. Он математически оценивает вклад каждого токена и подсвечивает слова, сильнее всего влияющие на итоговый NSFW-скор. 2️⃣ Передаём LLM весь текст и список триггерных слов. Просим заменить только их на максимально подходящие по смыслу, но безопасные аналоги. 3️⃣ Чтобы модель не заменяла всё подряд на слово «книга» — типа «как покурить книгу» — мы внедрили счётчик слов. В каждый новый промпт добавляем top-k самых популярных ответов модели в виде списка слов, запрещённых к генерации. Влияние на метрики Мы получили идеальные контрастные пары, где структура предложения идентична, а меняется только семантика нарушения. Это заставило модель смотреть на суть, а не на синтаксические шаблоны. В результате удалось повысить Specificity модели с 70% до 90% на безопасных примерах из нашего бенчмарка — и при этом не просесть по качеству на опасных примерах. ↗️

Автор этого поста, как и множества других про 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.

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

PII-детекция в guardrails: почему NER + regex иногда недостаточно ❌ Когда мы смотрели на чужие решения детекции чувствительных данных, встречали одну и ту же связку: NER-модели ловят семантику, а регулярные выражения выстраивают структуру и формат. Однако этого базового решения недостаточно для шумных текстов с цифрами, сокращениями и опечатками. Например, строка из 16 цифр может быть как номером карты, так и суммой ваших накоплений в банке, а 10 цифр — это ИНН или паспорт? Без дополнительной валидации точность ответов проседает. Мы пошли дальше ↗️ И добавили детерминированные проверки контрольных цифр — этот же принцип используется в платёжных формах и анкетах. Пайплайн получился такой: • извлекаем кандидатов через regex — учитываем пробелы, дефисы и другие дополнительные символы, • нормализуем строку до цифр, • проверяем валидность по алгоритму для конкретного типа сущности, • анализируем контекст вокруг совпадения. Какие проверки добавили? 🟥 Карты — алгоритм Луна (Luhn) отсекает большую часть случайных последовательностей. 🟥 ИНН — контрольные цифры через mod 11 с весами, затем mod 10. 🟥 СНИЛС — взвешенная сумма первых 9 цифр и mod 101, но если результат >100, контроль = 00. Так стало меньше false positives на числовых последовательностях, внешне похожих на PII. И появилось объяснение — какую именно проверку прошло найденное значение. Отдельно настроили контекст ✅ Даже валидная последовательность после проверки Luhn не всегда однозначна — один и тот же формат может встречаться у разных типов идентификаторов. Поэтому мы добавили контекстные признаки и keyword-правила вокруг кандидата. Так получилось классифицировать сущности не только по длине и контрольной сумме, но и по окружению в тексте. Если сталкивались с ложными срабатываниями на числовых идентификаторах — расскажите, как решали?

Автор этого поста, как и недавней статьи про генетический алгоритм, Женя Андриевская — 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.

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

🟥 Эволюция и генетический алгоритм улучшают данные для NLP Наш NLP-инженер Женя Андриевская рассказала в статье на Хабре, как генетический алгоритм помогает улучшить данные для задачи классификации текстов. Вместо ручного подбора промпты эволюционируют: инструкции мутируют, скрещиваются и проходят отбор по метрикам на тесте. Так можно оптимизировать генерацию синтетических данных для обучения модели. Позже тот же подход применяют к самому датасету при генерации и аугментации данных. 😊 Читайте статью, чтобы узнать, как устроен пайплайн и в каких задачах метод работает.

⚡️ Открываем NSFW-бенчмарк для систем модерации В прошлых постах мы много говорили о фильтрации NSFW. А теперь выкатываем в открытый доступ наш двуязычный бенчмарк для систем модерации контента. Что внутри датасета: • контрастные пары — о которых мы уже писали, • сложные пограничные примеры — hard negatives. Все данные собирались, отсеивались и валидировались полностью вручную. В карточке датасета рассказали, как устроена таксономия небезопасного контента. А ещё — добавили метрики популярных открытых моделей на этом датасете для удобного сравнения. Тестируйте свои фильтры на прочность и делитесь мыслями в комментариях. 😍 ↗️ Hugging Face

Автор этого поста, как и большинства предыдущих про безопасность, Андрей Иванов — 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. 😊

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

Тестирование AI-агентов ✅ Представим, что вы разработали AI-агента. Как понять, что он работает хорошо? А если поменять параметры — стало лучше или хуже? Что такое «хорошо» для вашего агента Для начала нужно определить, какую задачу агент выполняет в системе. На этом этапе выделяются сценарии работы и end-to-end метрики: выполняется ли задача, какова точность результата, сколько времени и ресурсов требуется. Оценка только по итоговому результату показывает картину лишь сверху. Чтобы понять, где возникает сбой, агента нужно разобрать на компоненты: LLM, tools, memory и другие. Тут у каждого свои критерии качества — какие входы поступают, какие выходы получаются и что считать ошибкой. Переходим к данным Нужно подготовить тестовый датасет с реальными запросами и ответами для каждого компонента. Данные нужны разнообразные: простые и сложные сценарии, edge cases, разные формулировки одних и тех же запросов. Часть данных можно сгенерировать автоматически. Это ускоряет процесс, но важно следить, чтобы синтетика отражала реальное поведение пользователей, а не превращалась в тестирование идеальных кейсов, которых не бывает в жизни. Прогоняем агента и фиксируем метрики Ответы агентов могут быть недетерминированы, поэтому каждый тест лучше запускать несколько раз и агрегировать результаты. Оценивать нужно не только финальный ответ, но и весь трейс выполнения: вызовы инструментов, промежуточные решения, изменения в среде. Анализируем результаты Где агент проваливается, какие компоненты работают некорректно? Обращаем внимание на полные логи действий агента, чтобы понять причину ошибок. После происходит доработка компонентов, следующий прогон, следующее снятие метрик... Этот процесс идёт итеративно до момента достижения нужного качества. Так и появляется надёжный агент. 😍 #Тестирование_агентов

Почему модель считает тортик опасным как напалм ❗️ Продолжаем тему генерации датасета для NSFW-фильтра в Guardrails. При формировании тренировочного набора данных важно собрать не только примеры нарушений, но и безопасные тексты, которые покажут модели границу между нормальным и запрещённым контентом. Кажется, что самое простое решение — взять для фона случайные нейтральные тексты, например: «реши линейное уравнение». Так модель действительно научится находить NSFW-категорию, но начнёт скатываться в shortcut learning. Допустим, в небезопасной части датасета есть запрос: «как приготовить напалм». Если в безопасной выборке нет прямого противовеса — например, «как приготовить тортик» — модель начнёт учить ложные признаки. Она просто свяжет безобидную конструкцию «как приготовить...» с небезопасным классом. 🟥 Чтобы классификатор не цеплялся за синтаксические шаблоны, нужны контрастные примеры, максимально похожие тексты в безопасной и небезопасной частях датасета. Как мы делаем такие данные: • Просим LLM сгенерировать базовый безопасный текст, • На его основе аккуратно генерируем небезопасную версию под конкретную категорию. За счёт минимальных изменений — добавления, удаления или замены пары деталей — безопасная версия превращается в целевой NSFW-пример. На выходе мы получаем идеальные контрастные пары. Они заставляют модель фокусироваться на реальной семантике нарушения, снижают влияние shortcut learning и эффективно отсекают ложные корреляции. ⚡️ #Безопасность

От социологии к guardrails: как строить таксономию NSFW 🦾 В этот раз поговорим про компонент Guardrails, отвечающий за фильтрацию небезопасного текстового контента. NSFW — Not Safe For Work. Когда возникает задача собрать данные для обучения и оценки качества моделей, первая мысль — взять готовые open-source наборы. Их много, они объёмные. Но если у вас специфичная таксономия небезопасных категорий, большинство открытых источников идут мимо. Приходится обращаться к синтетическим данным. Кажется, что для генерации данных достаточно попросить модель: «Сгенерируй 15 примеров для категории violence». Но полагаться на внутреннее представление LLM — плохая идея. Модель просто не способна самостоятельно охватить всё множество значений: она быстро зацикливается на самых банальных паттернах и выдаёт однообразный датасет. Как определять категории 🟥 Чтобы модель выдавала качественное разнообразие, ей нужны жёсткие рамки. Лучше всего подходит сочетание интенсионального подхода — с чётким определением свойств и экстенсионального — со списком конкретных референсов. Применяя их, мы дробим широкую категорию на конкретные непересекающиеся подкатегории. Примерно так будет выглядеть подкатегория физического насилия: «Прямое физическое столкновение и нанесение телесных повреждений. Включает в себя: удары, укусы, стрельбу…», — и так далее, с детальным описанием различных видов причинения вреда здоровью. Откуда брать референсы 🔳 Нельзя полагаться на первые попавшиеся источники в интернете или генерировать описания подкатегорий через LLM. Чтобы подкатегории не пересекались и в совокупности полностью описывали категорию, нужны строгие рамки. Для этого мы обращаемся к научным статьям по социологии, культурологии и политологии. В академической среде давно описаны все возможные девиации, есть выверенные формулировки и огромная база примеров. Опираясь на них, мы получаем мощное научное обоснование определений категорий. Связка «определение + референсы» отлично направляет LLM при генерации и решает проблему масштабирования. Нужно ввести новую подкатегорию? Просто добавляем ещё одну пару. Дополнительный плюс — уверенное разделение похожих категорий. Например, грань между violence и extremism стала прозрачной и для нас, и для самой модели. ⚡️ #Безопасность

↗️Почему найти документ на фото сложнее чем кажется Классический сценарий решения задачи фильтрации документов в Guardrails: если пользователь загружает картинку с паспортом, мы должны её заблокировать. Первая, интуитивно понятная идея, как это сделать — берём паспорта, строим базовый пайплайн, а затем масштабируем на другие типы документов. Но везде есть свои нюансы. Одноклассовые классификаторы не работают Начать с One-Class кажется логичным. Мы преобразуем картинки в векторные представления через yolo11n-cls и натравливаем на них OneClassSVM и IsolationForest. На практике модели отрезают половину реальных документов. Подход пасует потому что пространство признаков для класса «всё, что не паспорт» бесконечно разнообразно. Модель просто не способна построить адекватную разделяющую гиперплоскость, когда «аномалией» может быть и селфи, и кот, и чек из магазина. Всё понятно: нужен честный бинарный классификатор. Ловушка разрешения и сила сложных отрицательных примеров Можно обратиться к yolov8n-cls. Собрать базовый набор данных: паспорта против картинок, отдаленно похожих на паспорта. При обучении YOLO сжимает входное изображение до 224x224 (чего мы не знали). На таком разрешении полностью стираются высокочастотные признаки документа: микротекст, паттерны бланка, печати. Эту неочевидную просадку от сжатия легко упустить на старте. Подняв разрешение, мы смогли добиться метрики F1 в 93%. Из интересного: оптимальное разрешение для таких задач стартует от 640x640, а дальше нужен компромисс между временем и качеством. И главное — для хорошего результата в тренировочный набор критически важно включать сложные отрицательные примеры: газеты, купюры, книги, обложки журналов, иначе модель не учится искать специфику документа. Смещение внимания и ложные срабатывания Вроде бы 93% по F1 — это отлично, но копать надо дальше. Кажется, можно переобучиться на «чистых» образцах паспортов. В сложном визуальном окружении, например, когда документ лежит на захламленном столе, модель спокойно пропускала утечки. Зато простая фотография мужчины, гуляющего на свежем воздухе, вызывала срабатывание классификатора и помечалась как документ. Что произошло под капотом? Модель пошла по пути наименьшего сопротивления и выучила ложную закономерность «лицо = паспорт», потому что на всех паспортах есть лица. Случайный фон — люди, животные, дома — полностью сбивал классификатор с толку. Предел синтетики всегда есть Чтобы улучшить работу классификатора на сложном фоне и отучить его от ложных закономерностей, мы сгенерировали синтетические данные. Программно наложили вырезанные фрагменты документов на случайные фоны. Естественный страх при таком подходе — модель не поймет контекст. На практике всё оказывается даже хуже: метрики не просто не вырастают, они падают на чистом тестовом наборе. На синтетическом тесте модель также промахивается. По нашему мнению, сеть просто не может выучить топологию объекта в не естественном окружении. Эти наблюдения стали отправной точкой для следующего шага. Мы попробовали другой подход — находить и маскировать PII прямо на картинке. Про этот эксперимент и архитектуру решения подробно рассказали в статье на Хабре 😊

Детализация сущностей в PII Давайте поговорим про поиск и маскировку персональных данных. Это одна из частей Guardrails, где работают даже грубые классы типа PERSON / ORG / LOC. Но если добавить детализацию — заметно вырастет качество и устойчивость модели. Мы решили докопаться до механики и понять, почему так происходит. Почему детализация помогает Когда в разметке есть только категория PERSON, модель получает один сигнал на всю сущность. Но если добавить категории FIRSTNAME / LASTNAME / MIDDLENAME — каждый токен получит свою роль. Условно, Александр Иванович Лужин перестанет быть просто PERSON и превратится в последовательность имя / отчество / фамилия, в которой модель учится понимать типичные паттерны. В исследованиях fine-grained разметки такой подход показывает прирост F1 и на уровне токенов, и на уровне сущностей. Та же логика работает и для других типов данных: даты, суммы, роли сторон, география, технические идентификаторы. Чем богаче таксономия — тем больше сигналов получает модель. Почему это не ломает модель Интуитивное опасение — чем больше классов, тем хуже обобщение. На практике часто работает наоборот: ✅ подтипы снимают конфликты внутри одной сущности, ✅ каждый токен чаще получает осмысленный лейбл, ✅ иерархию можно встроить в задачу, например, предсказывать классы coarse и fine одновременно. Похожая логика работает и за пределами чистого текста. Недавно разобрали кейс маскирования PII на изображениях — и выпустили статью на нашем Хабре. #Безопасность

🔗 Что мы сейчас исследуем в R&D В нашей практике много исследовательских треков. Вот несколько направлений, вокруг которых будут строиться ближайшие материалы канала. #Безопасность Исследуем, как выстраивать безопасную работу с LLM: от защиты персональных данных и юридических рисков до модерации контента и работы с текстом и изображениями. #Инфраструктура Изучаем подходы агентного управления инфраструктурой: настройку, мониторинг, выявление сбоев и их устранение. #Тестирование_агентов Разрабатываем платформу для тестирования агентных систем, чтобы проверять устойчивость их поведения и собирать собственные бенчмарки. #Продуктивность_агентов Работаем над стабильностью агентов и качеством их базовых навыков, чтобы они надёжно работали в сложных сценариях. #SGR Развиваем фреймворк Schema-Guided Reasoning, который задаёт жёсткую схему рассуждений модели, снижает число ошибок и делает reasoning более прозрачным. К каждому направлению проставили теги, чтобы было проще ориентироваться в материалах. Это лишь часть того, что происходит в R&D. Остальное тоже покажем, но постепенно. ↗️_rnd

↗️ Мы захватили этот канал Раньше канал назывался red_mad_dev. Теперь это _rnd — публичный блог практики R&D red_mad_robot. Это рабочая площадка для инженеров и ресёрчеров. Здесь будут наши мысли, эксперименты, короткие и длинные технические разборы, ссылки на научные статьи и git-репозитории. Про что будем писать: • какие гипотезы тестируем и какие результаты получаем • какие архитектурные решения принимаем и почему • где ошибаемся и что это меняет • как исследования превращаются в прикладной AI • что происходит в индустрии и что об этом думаем Если вам интересны reasoning-архитектуры, RAG-системы, агентные пайплайны, LLM-инфраструктура и реальный продакшн AI — вы в правильном месте. Поехали ⚡️