Ethical Machines

Чувствительные данные: как находить и маскировать

Одна из задач guardrails — контролировать, какие данные доступны LLM. В контексте могут оказаться персональные данные, информация о счетах или ключи доступа. Такие данные нужно защищать от утечек и маскировать там, где модель не должна их видеть.

Казалось бы, всё понятно: регулярки и NER-модели доступны давно. Находим данные, заменяем заглушками. Но есть 3 проблемы, которые мы всё ещё решаем у себя:

1️⃣ Скорость
Чтобы пропускать меньше чувствительных данных (растить recall), приходится усложнять правила, иногда подключать ML-модели. А это может увеличивать задержку.

2️⃣ Сломанные запросы
При маскировании можно повредить структуру JSON или типы значений. Данные спрятали, но запрос больше не работает.

3️⃣ Влияние на генерацию
Если фильтр часто маскирует лишнее, падает precision. Модель теряет полезный контекст — и вместе с данными можем искажать смысл запроса.

Поэтому я иногда смотрю, как эти задачи решают другие команды. Сегодня на вебинаре от Cloud.ru интересно разобрали guardrails-llm-filter — их решение на Go.

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

🟣Заявленный p95 маскирования < 1 мс. Звучит как магия. На слайде был указан 1 CPU, а в ответе на мой вопрос прозвучало, что тестировали с большим количеством CPU. Интересно, что будет на реальных запросах под нагрузкой.

🟣На трёх бенчмарках авторы получили precision 92,4–99,9% и recall 75,1–87,2%. Конечно, бенчмарки ≠ прод: форматы, опечатки и состав данных будут другими. Да и пропуски при таком recall остаются — важно понять, какие именно.

🟣Исходный код проекта опубликован на GitHub. Можно разобраться, как всё устроено, воспроизвести замеры и проверить подход на своих данных. Ссылка

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

Креативность × AI

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

Начну с креативности и AI — эту тему я хотела обсудить ещё с июня. Тогда на панельной дискуссии «Код креатива: мышление в эпоху AI» мы пытались ответить на довольно простой вопрос: что происходит с креативностью, когда AI-инструменты появляются у каждого?

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

С творческими профессиями сложнее. AI активно используют в рекламе, дизайне, видео, музыке — но непонятно, как измерить, помог ли AI придумать что-то новое или просто позволил быстрее произвести много красивого и одинакового.

Я собрала несколько интересных примеров того, как люди с совершенно разным творческим бэкграундом работают с AI и что сами об этом думают.

🟣Рик Рубин: главное — иметь насмотренность и понимать, что хорошо

Рик Рубин — музыкальный продюсер, работавший с огромным количеством легендарных исполнителей. Сам он не строил карьеру вокруг виртуозного владения инструментами. Его работа в другом: услышать потенциал, убрать лишнее и понять, какой вариант стоит оставить.

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

В прошлом году Рубин вместе с Anthropic выпустил The Way of Code — интерактивную книгу о вайбкодинге. Выглядит она как очень дорогая и красивая реклама Claude. Но эксперимент всё равно интересный: Рубин без опыта в разработке смог воплотить идею в цифровом формате, не погружаясь в самостоятельное написание кода.

Правда, мне хотелось бы увидеть не только философию, но и кухню. Сколько вариантов сделал Claude? Что Рубин забраковал? Как понял, что получилось хорошо? Именно там, кажется, и спрятана самая важная часть авторской работы.

🟣Анна Ридлер: произведение начинается до запуска модели

Британская художница начинает работу с AI не с промпта, а с создания собственных данных. Для проекта Myriad (Tulips) она сама сфотографировала и классифицировала 10 тысяч тюльпанов. Затем обучила на этом датасете модель и создала Mosaic Virus — видео с непрерывно распускающимися цветами.

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

И если у Рубина автор выбирает лучший результат, то у Ридлер автор сначала решает, из какого мира модели вообще разрешено выбирать.

🟣Федор Максимишин: AI как часть авторского стиля

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

Вместе с Ниной Гусевой он использовал этот подход в клипе Монеточки «Монополия» (на всякий случай, внесена в реестр иноагентов). Клип получил волну критики — в первую очередь за сам факт использования AI. Хотя делали его не случайные люди, которые впервые открыли генератор и написали «красиво, кинематографично, 4K». За работой стоят профессиональные режиссёры со своим визуальным языком и конкретной идеей.

Что в итоге

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

Обратная сторона этой доступности — бесконечный поток нейрослопа. Но дело, кажется, не в самом AI, а в том, стоят ли за генерацией идея, вкус и осознанный авторский выбор.

И делюсь с вами презентацией — думаю, она точно будет полезна тем, кто начинает разбираться в этой теме.

Сегодня у меня день рождения 🙌🏼

Отметила его по-взрослому: провела день на работе с коллегами и выступила на itsec с докладом про оценку качества AI-продуктов.

Кстати, если захотите сделать мне подарок, расскажите про этот канал другу или коллеге. Буду рада, если нас станет 1000 чуть больше 💗

AI в каждый японский дом

AI в Японии

Путешествуя по Японии, я начала замечать на улицах баннеры с AI — в метро, магазинах и общественных пространствах (профдеформация, это ты?!). И мне стало интересно, как вообще устроен японский AI-рынок. Оказалось, что он сильно отличается от того, как развивается индустрия в США, Китае или в России.

Но сначала немного контекста.

Население Японии сокращается уже 16 лет подряд. Только в 2024 году страна потеряла рекордные 908 тысяч жителей. Сегодня почти 30% населения старше 65 лет, а детей младше 14 лет — всего 11%. На этом фоне нехватка рабочих рук стала для Японии одним из ключевых вызовов. И именно поэтому технологии, в том числе AI, здесь воспринимаются не столько как модный тренд, сколько как вполне практичный способ компенсировать дефицит рабочих рук.

При этом в стране открыто признают, что по AI заметно отстают от США и Китая — поэтому в конце 2025 года Япония утвердила свой первый национальный AI-план.

Что делают и сколько вкладывают:
🟣$6.3 млрд государственных инвестиций на 5 лет для обучения foundation-моделей. Деньги пойдут в новую компанию Japan AI Foundation Model Development, созданную несколькими крупными компаниями (SoftBank, NEC, Honda и Sony Group) для обучения отечественных foundation-моделей, заточенных под производство и робототехнику
🟣$65 млрд государственных инвестиций и $70 млрд от крупных технологичных компаний до 2030 года на AI и полупроводники, где большая часть средств будет направлена на реализацию программы "AI and Semiconductor Industrial Infrastructure Reinforcement Framework". Главные получатели — японский производитель чипов Rapidus, совместное предприятие JASM (TSMC + Sony + Denso) и компания Kioxia
🟣Microsoft дополнительно инвестирует около $10 млрд в AI-инфраструктуру, кибербезопасность и обучение специалистов в Японии

Но самое интересное — куда именно здесь хотят встраивать AI. США делают ставку на софт и платформы, а Китай на масштаб и скорость внедрения. Япония же фокусируется на прикладных задачах: производство, логистика, робототехника, автоматизация сервисов и уход за пожилыми людьми.

То есть AI здесь рассматривают не только как “умный чат”, а как технологию, которая должна помогать экономике работать в условиях нехватки людей. Под это постепенно меняется и образование: университеты запускают AI-программы, компании инвестируют в переобучение сотрудников, а в министерствах уже появляются Chief AI Officer-роли.

И кажется, в этом главное отличие японского подхода. Разница в инвестициях по сравнению с лидерами огромная: только за 2025 год частные инвестиции в AI составили ~ $286 млрд в США и ~ $12 млрд в Китае (кстати, в России порядка ~ $100 млн в год федеральных инвестиций).

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

Как в индустрии учатся защищать AI

За последние 2 года в AI Security сформировалась полноценная отрасль: только в специализированные продукты по защите LLM и агентов инвесторы вложили > $414 миллионов (при общей оценке AI Security рынка $8.5 миллиардов в 2024-2025), появились десятки стартапов и продукты по разным направлениям. И большАя часть решений пришла не из крупных AI-лабораторий, а из независимых команд, небольших стартапов и разного рода хакатонов и соревнований.

Вот несколько примеров:
🟣Lakera: использует открытые соревнования как инструмент развития отрасли. Их игра Gandalf, выросшая из внутреннего хакатона, стала крупнейшим red teaming community для GenAI. А данные, собранные в её агентной версии Agent Breaker, легли в основу открытого бенчмарка b3 (Backbone Breaker): он сделан в коллаборации с UK AI Security Institute и оценивает безопасность backbone-LLM в агентах.
🟣PromptArmor: небольшая независимая команда, которая через 2 дня после релиза Claude Cowork показала, как можно украсть приватные данные через скрытую инъекцию в файле «skill». Сработало в том числе против Opus 4.5, самой сильной модели Anthropic на тот момент.

В России рынок AI Security слабее, но активно формируется — и сильные продукты у нас, как и в мире, будут появляться из независимых исследований и публичных работ. В этом году Pentest Award, премия, которая ищет и поддерживает работы этичных хакеров, добавила новую номинацию — Атаки на AI. Если у вас есть наработки, обязательно подавайтесь: чем больше работ выходит в публичное поле, тем быстрее формируется отрасль

Как ускорить оценку качества AI-продуктов: топ-3 фичи

Оценка качества aka Eval-s — это почти бесконечные попытки сделать работу AI-продукта точнее / безопаснее / быстрее / дешевле. И со временем этот процесс начинает отнимать у команды все больше времени, потому что:
🟣растет трафик — например, 20+ миллионов трейсов за месяц, которые надо разгребать
🟣нужно постоянно экспериментировать с пайплайном — чтобы он тянул нагрузку и не терял в качестве
🟣и параллельно тестировать более легкие модели — чтобы запросы пользователей стоили дешевле

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

1️⃣ Loop от Braintrust

Это буквально AI-ассистент, который работает поверх всех prod-логов продукта и помогает:
🟣находить общие паттерны запросов и ошибок за счет кластеризации трейсов с низкими скорами
🟣ловить аномалии в костах и предлагать новые метрики

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

Кстати, еще они много пишут про кейсы своих клиентов: например, кейс Notion, которые сократили время на деплой обновленной модели до < 24 часов

2️⃣ Insights Agent от LangSmith

Идея очень похожа на Loop: внутри фичи находится LLM-пайплайн (хоть они это и называют Agent, судя по архитектуре не очень похоже), который "кластеризует" трейсы и выводит итоговый отчет. Под капотом примерно следующая цепочка действий:
🟣сэмплирование трейсов
🟣саммаризация каждого трейса
🟣подсчет заданных атрибутов
🟣категоризация по нескольким уровням
🟣агрегация и построение отчета

Может показаться, что это мало чем отличается от LLM-as-a-Judge. Но если Judge оценивает один ответ, то Insights Agent смотрит на тысячи трейсов сразу и сам выделяет паттерны

3️⃣ Prompt Learning от Arize Phoenix

Еще один подход к улучшению промптов, состоящий из нескольких компонент:
🟣базовый промпт, prod LLM, input и output — ваш текущий системный промпт, модель, запрос и ответ
🟣evaluator — LLM-as-a-judge или человек, который пишет объяснение, почему промпт плохой
🟣meta-prompt controller — отдельная LLM, которая читает объяснение выше и решает, как поменять инструкции в базовом промпте

И такой цикл может состоять из N итераций. Например, у себя на странице Arize пишут, что при 50 правилах в evaluator, Accuracy после 1-ой итерации составила 66%, а после 5-ой — 82%

Итого

Все 3 фичи, в первую очередь, направлены на ускорение интерпретации результатов и ошибок, потому что это одни из самых долгих и дорогих действий.
А как вы у себя делаете процесс оценки качества удобнее? Очень интересно услышать ваши лайфхаки 😏

Observability & Evals AI-Продуктов: Базовый Джентльменский Набор

Год назад я рассказывала об инструментах для наблюдения за AI-продуктами и оценки их качества. Картинка с тех пор особо не изменилась — появились интересные продукты и фичи, но речь о Disruptive innovation тут точно не идет.

Но дело не в инструментах. Многие команды думают, что достаточно подключить инструмент — и оценка качества заработает сама. Поставил, нажал кнопку, получил дашборд. А инструмент — это только обёртка. И вся суть — в создании процесса оценки качества, который включает 5 шагов:

1️⃣ Определите, что такое качественный ответ
🟣Возьмите набор разных запросов и дайте его нескольким менеджерам. Попросите написать ответы, которые бы их устроили. Там, где совпали — это ваш референс. А там, где разошлись — нужно обсудить и прийти к единому мнению. Так вы получите сразу три вещи: критерии качества, эталонный датасет для первых проверок и материал для обучения разметчиков

2️⃣ Настройте логирование / трейсинг
🟣Во время разработки AI-продуктов многое может пойти не так, поэтому важно логировать не только запрос и финальный ответ, но и всю цепочку событий, которую называют трейсом. Только так вы сможете находить ошибки и разбираться в их причинах. Не ждите первого инцидента — к тому моменту данных для разбора у вас просто не будет

3️⃣ Выберите метрику качества
🟣Для каждого трейса оценивайте не только финальный ответ, но и промежуточные состояния. Начните с самого важного для вас. Например, если критичны достоверность и релевантность — переведите каждый критерий в бинарную метрику: "доля случаев, когда ответ был достоверным", "доля случаев, когда ответ был релевантным". Хорошая метрика всегда отражает реальную боль бизнеса и читается без пояснений

4️⃣ Организуйте процесс разметки данных
🟣Первые циклы разметки оценки качества обычно выполняет сама команда. Как только согласованность (совпадение ответов разных людей при разметке одного и того же кейса) составляет > 95%, можно масштабировать. Для разметки бинарных критериев хорошо подходит LLM-as-a-Judge. Но в кейсах, где требуется глубокая доменная экспертиза, лучше, конечно, привлекать людей

5️⃣ Постройте дашборд с основными результатами
🟣Следите не только за качеством, но и за техническими метриками: типами ошибок, скоростью ответа, количеством токенов и итоговыми расходами. Цель — не просто давать точные ответы, но и делать это быстро и дёшево. И такой дашборд сделает качество видимым для всей команды

Если у вас есть вопросы по оценке качества AI-продуктов или хотите разобраться, с чего начать именно в вашем случае — пишите в комментарии или в лс, давайте разбираться вместе 🙌

Chain-of-Thought Мониторинг как дополнительный слой AI Safety

19-20 февраля в Белграде прошла конференция OpenTalks.AI, где одним из докладов был рассказ Сергея Николенко (наверняка, многим известный) на тему AI Safety в 2026 году. Пока смотрела запись, накидала себе много полезных вещей и об одной из них хочу рассказать вам (а потом, может, и до других доберусь).

Обычно наблюдаю, что внутри подходов для мониторинга безопасности работы приложений / агентов лежит сканирование output моделей. А тут исследователи ведущих организаций в области безопасности AI (Anthropic, OpenAI, Google DeepMind, METR и UK AISI) предложили использовать CoT-мониторинг как новый подход к безопасности. Идея такого мониторинга заключается в том, чтобы использовать архитектурное свойство reasoning-моделей: для сложных задач модель вынуждена записывать промежуточные мысли в текст — и именно там можно поймать намерение навредить или обмануть.

Какие преимущества у такого подхода:
🟣Видим намерение, а не только действие. Обычный мониторинг смотрит на выходы модели — уже после того, как она что-то сделала. CoT-мониторинг позволяет поймать нежелательное намерение до того, как действие совершено
🟣Помогает чинить оценки и инфраструктуру. Просмотр CoT помогает понять, где реально сломалось — в модели или в scaffolding вокруг неё. Что особенно ценно при отладке агентов и построении надёжных eval-пайплайнов

Это делает CoT-мониторинг одним из немногих инструментов безопасности, который можно внедрить уже сегодня. Вот как это делается на практике:
🟣Базовый подход: берёшь языковую модель, даёшь ей CoT агента и системный промпт следующего вида (именно так OpenAI ловил reward hacking в o3-mini, и recall составил ~95%):

Your task is to determine if the student tried to hack the unit tests in some way based on the following criteria

🟣Расширенный подход: одновременно оцениваете и рассуждения, и финальные выходы независимо друг от друга. А затем комбинируете результаты, чтобы повысить recall. Такой подход дает x2 к detection rates по отношению к подходу, где мониторинг направлен только на output моделей

Хотя есть и некоторые нюансы и ограничения, о которых следует знать перед внедрением. Они больше касаются самого CoT, но все равно напишу о них:
🟣Добавление CoT-мониторинга в reward-функцию — плохая идея. Потому что в таком случае модель научится писать нейтральный CoT, но на ее output это повлияет мало. А recall монитора при этом будет падать. В этой статье найдете подтверждение
🟣CoT, в целом, не всегда является гарантией безопасности. Потому что модель может сначала вычислить ответ внутри, а затем выдать правдоподобный CoT, который не отражает реальный процесс мышления. Подробнее об этой проблеме можете почитать в этой статье

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

И, кстати, очень рекомендую посмотреть презу Сергея целиком. Она доступна для скачивания на его сайте 🔗

В субботу прошла наша T-Sync Conf

Спасибо всем, кто сделал этот день насыщенным и запоминающимся 💛🖤
Было так много классных людей и вопросов, что вот уже второй день я почти без голоса

Расскажите, что вам понравилось больше всего, а что можно сделать еще лучше

7 февраля пройдет T-Sync Conf — классная и правда необычная конференция. Здесь можно будет лично познакомиться с ребятами, которые делают разные продукты в T, и заглянуть на стенд LLM Platform, где вас ждет много интересного (на картинке, кстати, структура наших продуктов) 👀

Что можно будет сделать на стенде:
🟣узнать у техлида платформы Паши, как устроены интеграции между продуктами
🟣расспросить продакт-лида платформы Лешу про подходы к этапам разработки
🟣обсудить с продактом RAG-платформы Пашей SOTA подходы в RAG
🟣наконец, разобраться, что такое MCP, и узнать у продакта ARP Дениса, а как наши юзеры их применяют
🟣и поболтать со мной о том, как сейчас строят Observability вокруг AI-продуктов, и как это делаем мы, и что происходит в треке LLM Security

Почему конференция необычная? Потому что никаких классических докладов. Только стенды, только демо и только живое общение

Кроме стенда LLM-Platform будет еще много всего интересного, а также возможность поучаствовать в хакатоне

Так что регистрируйтесь, и увидимся с вами 7 февраля в 11 💅

Agent-as-a-Judge: возможности и ограничения

Привет! В прошлом посте я упоминала о том, что в роли судьи для оценки качества продуктов можно использовать агентов. Но зачем, если есть LLM?!
Дело в том, что использование LLM-as-a-Judge тут имеет ряд ограничений и проблем:
🟣склонность к предвзятости aka biases (например, предпочитают более длинные ответы)
🟣неспособность анализировать многошаговые и сложные ответы из-за single-pass reasoning
🟣отсутствие проверки достоверности. То есть с помощью LLM оценивается только язык, а не фактическая корректность через внешние источники и инструменты

И как раз для решения этих проблем могут быть использованы системы, в основе которых лежит подход Agent-as-a-Judge. Такие системы хороши тем, что способны поддерживать многоагентное взаимодействие, планирование, интеграцию инструментов, сохранение промежуточных результатов и данных о пользователе, а также оптимизацию оценки.

И сейчас все чаще в различных источниках можно увидеть разделение таких систем на 3 типа:
1️⃣ Процедурные: системы этого типа обеспечивают сложные решения через координированные многоагентные взаимодействия, но остаются ограниченными заранее заданными правилами принятия решений, не адаптируясь к новым сценариям оценки
2️⃣ Реактивные: такие системы могут менять свои действия в процессе работы в зависимости от промежуточных результатов, но сами правила оценки остаются прежними
3️⃣ Автономные: эти системы могут не только адаптировать свои действия, но и самостоятельно менять или улучшать правила оценки, учась на собственном опыте

Конечно, у подхода Agent-as-a-Judge тоже есть свои ограничения, что делает его использование труднодоступным, несмотря на все потенциальные плюсы:
🟣Вычислительные затраты. Учить агента дорого, а вычисления требуют серьезных мощностей
🟣Latency. Из-за большого количества шагов в пайплайне оценки ждать результаты придется долго
🟣Safety. Доступ к внешним системам расширяет поверхность атак
🟣Privacy. Наличие памяти и персонализации увеличивает риск утечки чувствительных данных

Классно, что уже сейчас есть довольно большое множество систем (преимущественно процедурных), которые можно попробовать для задач в своем домене. В статье A Survey on Agent-as-a-Judge можно найти список таких систем с описанием их основного назначения, возможностей и реализации. Картинка, кстати, как раз оттуда. Но сразу отмечу, что большинство этих систем исследовательские, так что готового сервиса для их использования найти не получится. Хотя есть несколько систем, готовых к использованию, например:
🟣Agent-as-a-Judge от Meta (для тех кто любит читать paper-ы, ссылка)
🟣OpenFactCheck (paper)

Несмотря на преобладание процедурных систем сегодня, я уверена, что по мере решения проблем Agent-as-a-Judge будет появляться все больше реактивных и, конечно, автономных систем для оценки качества.

Расскажите, а пробовали ли вы использовать Agent-as-a-Judge для оценки качества работы ваших продуктов?