_rnd

⚡️ PII Guard: невошедшее

Недавно мы поделились в статье, как строили систему маскировки данных, умеющую подставлять настоящие данные обратно в ответ модели. Наше решение основано на детерминированных правилах в сочетании с работой NER-модели. Однако это был не единственный подход, который мы протестировали.

Рассказываем в этом посте о ещё трёх перспективных идеях, так и не попавших в релиз.

↗️ Якоря вместо словаря синонимов

Правила упирались в жёсткий словарь ключевых слов: «мое вадительское удастоверение 4111-1111-1111-1111» уходило в карту — опечаток и синонимов в словаре нет, а цифры проходят Луна.

Поэтому мы поставили в конец пайплайна после правил слой на rubert-tiny. Вокруг предположительно личных данных вырезали окно в 80 символов, считали эмбеддинг и сравнивали его по косинусной близости с эталонными фразами каждого типа документа. Сам слой включался только там, где не сработали ни регулярки, ни леммы.

Что получилось: на сложных случаях с опечатками и синонимами, где старые правила пасовали полностью, качество выросло с нуля до 60–80%. Baseline при этом не просел. Новый тип документа добавлялся за несколько эталонных фраз вместо недель на сбор датасета и дообучение.

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

↗️ Две модели вместо одной

Имена и адреса модель определяет по смыслу фразы, номера документов — по словам вокруг числа. Мы попробовали развести эти навыки: первая модель для семантических сущностей, вторая только для контекста вокруг числовых последовательностей.

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

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

↗️ Все цифры за одним токеном

Сами цифры документов сигнала не несут: номера меняются от документа к документу, устойчивого образца в них нет. Поэтому все числовые последовательности в обучающих данных мы заменили служебным токеном [NUM] — модель видит «Паспорт серия: [NUM] номер: [NUM]» и физически не может опереться на цифры.

Что получилось: от документов остаётся один контекст, а разнобой в записи номеров исчезает под общим токеном. Концептуально это честнее, ведь при расширении на новые типы модель с меньшей вероятностью прицепится к самим цифрам.

Почему не взяли в релиз: обфускация, ради которой всё и затевалось, подход и подвела. На примерах вида «Банковская карта 4111чч1111жж1111жж1111» обычное обучение покрыло около 80%, а [NUM] — всего 30%. Разделители дробят число на несколько токенов, и модель размечает только первый. По средней метрике варианты почти сошлись (F1 96 против 95).

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

😍 Как получить доступ ко всем LLM через единый API

Мы запустили red_mad_router — единую точку доступа к большим языковым моделям.

В новой статье мы рассказываем, как мы собрали нашу платформу, благодаря которой пользователи могут получить доступ к более чем 100 моделям.

В материале поделились:

📍 как устроена архитектура системы;
📍 как мы работаем с данными и безопасностью;
📍 какие особенности есть у роутера, которые отличают его от других подобных платформ.

🔗 Читайте статью — она уже на нашем сайте.

😍 Пакман и разработка: выбираем агентов при помощи DDQN

При построении MAS перед разработчиком рано или поздно встаёт вопрос — как эффективнее всего подобрать агента для конкретной задачи и найти их нужное количество. Как правило, выбор большинства останавливается на роутере-агенте на базе LLM. Но что, если у этого подхода есть альтернативы?

Кирилл Мозолев, автор новой статьи, решает эту задачу при помощи алгоритма DDQN. Рассказываем про эксперименты и получившиеся результаты и сравниваем наш метод с другими подходами.

А ещё мы разместили наше решение в открытой библиотеке на GitHub — можете опробовать его уже прямо сейчас.

↗️ Читайте новый материал на нашем сайте.

#️⃣ Как LLM работать с замаскированными данными?

Маскировка персональных данных — совершенно обычная практика для компаний, работающих с LLM. Однако требования к системам маскировки изменились, а сами они стали более совершенными: теперь они должны и скрывать данные, и возвращать их в ответ модели.

В новой статье рассказываем:

📍 как мы совместили детерминированные правила и NER-модель для псевдоанонимизации данных;
📍 как научились корректно возвращать скрытые данные;
📍 какие результаты показывает наша система в сравнении с другими решениями.

🔗 Читайте статью полностью на нашем сайте, а код инструмента смотрите на GitHub.

😊 Расследуем инциденты при помощи Telegram-бота

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

В новой статье поделились, как мы собрали такого бота при помощи агента, который сам ходит в логи и метрики и приносит корневую причину. Рассказали подробно об устройстве архитектуры и показали принципы работы инфра-бота на демо-инциденте.

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

#️⃣ Как AI-агенты поменяли разработку

Делимся новой статьёй — в ней наш CTO по AI Влад Шевченко рассказывает, как перестраивается SDLC в эпоху AI-агентов.

В материале разберёмся:

🟥какие трансформации переживают классические Agile-команды и почему происходит переход к T-Shape микрокомандам;
🟥чем инженерная зона ответственности при разработке агента отличается от исследовательской;
🟥как оптимально составить исследовательский контур.

📎 Читайте статью на нашем сайте, чтобы разобраться, как выстроить процессы вокруг AI-агентов в своей команде.

Материал подготовлен совместно с Selectel по следам доклада на конференции МLечный путь.

✅ AI-дашборд для HR

Можно ли автоматизировать работу HR — и сделать это этично и безопасно? Мы доказали, что да.

Делимся в статье нашим новым кейсом с HR-дашбордом. В материале подробно описываем, как соединили для его работы:
• AI-транскрибацию;
• локальные LLM;
• и AI-агентов.

А ещё — рассказываем об экспериментах, которые привели к его созданию, и о результатах его использования.

↗️ Читайте кейс на нашем сайте redmadrobot.ai

Кстати, сайт с элементами AI-native — умным поиском, системой навигации и AI-глоссарием, который подсказывает определения терминов — а недавно он выиграл Red Dot Design Award. Приходите на сайт читать наши материалы. 😍

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.

⚡️ Как оценивать агентский harness

Одной LLM недостаточно, чтобы понять качество AI-агента. На итоговый результат влияет агентский harness — как он управляет инструментами, памятью, сообщениями, восстановлением после ошибок.

Чтобы разобраться в этой теме, мы провели ряд экспериментов. И выкатили в open source Harness Bench — открытый фреймворк для сравнения связок «модель + harness».

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

↗️ Читайте статью
↗️ Тестируйте бенч

Автор и статьи, и бенчмарка, Андрей Иванов — 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.

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.

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