Небольшие модели для маскирования и классификации PII

Почему для PII не всегда нужна большая модель

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

Для таких задач сильный генератор часто просто не нужен. Когда система ищет ИИН, номер телефона, адрес, номер карты или ставит метку вроде "паспортные данные", она не создает новый текст. Она делает узкую работу: находит сущности и относит их к нужному классу.

На этом участке небольшие модели нередко выигрывают. Они дешевле, проще и обычно отвечают быстрее. Для онлайн-формы разница между 300 мс и 2 секундами заметна сразу. Для чата и колл-центра это еще важнее: паузы раздражают и оператора, и клиента.

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

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

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

Это особенно полезно там, где важна локальная обработка PII. Если команда держит этап маскирования ближе к данным, она снижает риск лишней передачи чувствительного текста и лучше контролирует журналирование, лимиты и правила хранения. Для части команд в Казахстане это обычное требование продакшена, а не дополнительная опция.

Какие задачи подходят небольшой модели

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

Обычно такой модели хватает, чтобы найти ФИО, телефон, email, ИИН, адрес и номер карты в сообщении или документе, заменить найденные фрагменты на маски вроде [NAME] или [CARD], присвоить метку сущности и отделить обычный текст от чувствительных кусков еще до записи в хранилище.

Такие задачи хорошо ложатся на небольшую модель, потому что правила понятны, а контекст часто короткий: чат с поддержкой, заявка, комментарий оператора, поле "примечание" в CRM. Если текст похож на поток однотипных сообщений, цена падает заметно, а точность часто оказывается вполне достаточной.

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

В банке это выглядит очень приземленно. Клиент пишет: "Меня зовут Алия Сарсенова, мой ИИН 990101300123, перезвоните на 8701..." Небольшая модель маскирует имя, ИИН и телефон, а заодно помечает запись как данные клиента. Но если в тексте встречается 16-значный номер без пояснений, модель может не понять, это карта, номер договора или внутренний идентификатор. Такой случай лучше не решать вслепую.

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

Как собрать честный тестовый набор

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

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

Не делайте выборку слишком "чистой". Если в тесте только аккуратные письма без опечаток, модель покажет результат выше реального. В рабочем потоке люди пишут "ИИН", "iin", "iin123...", слепляют номер телефона с именем, вставляют адрес в одну строку и смешивают русский с казахским. Все это должно попасть в тест.

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

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

Если вы работаете с данными из Казахстана, не ограничивайтесь русскими примерами. Добавьте казахские имена, адреса, формулировки из заявок и OCR после местных документов. Для локальной обработки PII это часто важнее, чем разница в пару пунктов на англоязычном бенчмарке.

Практическое правило простое: соберите 200-500 примеров, где около 80% похожи на обычный поток, а 20% состоят из неудобных случаев. Такой тест не льстит модели и помогает понять, за что вы платите на самом деле.

Как считать точность без красивых цифр

Одна средняя метрика почти всегда обманывает. Для маскирования и классификации PII она скрывает главный вопрос: какие именно сущности модель пропускает.

Смотрите recall по каждому типу PII отдельно. Если модель хорошо находит email и телефоны, но регулярно пропускает ИИН, номер карты или номер счета, общая цифра может выглядеть прилично, а риск для бизнеса останется высоким.

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

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

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

Поэтому считайте сущности поштучно. Для каждого типа PII фиксируйте true positive, false positive и false negative, а потом стройте precision и recall. Так сразу видно, где модель осторожничает, а где маскирует все подряд.

Цена и задержка должны стоять рядом с качеством. Иначе легко выбрать модель с лучшим recall и не заметить, что она в четыре раза дороже и отвечает на 800 мс дольше. Для потока из миллионов сообщений в месяц это уже серьезная разница.

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

Что сильнее всего влияет на цену

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

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

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

Вторая частая причина лишних затрат - повторные запросы. Один таймаут, одна ошибка валидации JSON, один лишний retry, и цена на документ почти удвоилась. Иногда пайплайн сам делает три прохода подряд: сначала ищет PII, потом проверяет ответ, потом повторяет вызов из-за спорного поля. На бумаге модель выглядит дешевой. В продакшене счет выходит совсем другим.

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

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

Это хорошо видно на простом банковском примере. Поток заявок идет через один LLM шлюз, и команда видит: разница между двумя небольшими моделями составляет считанные проценты по цене, а вот снижение эскалации с 25% до 8% режет месячный счет гораздо сильнее. Поэтому сравнение цены и точности лучше начинать не с прайса за токен, а со всей цепочки обработки одного документа.

Как провести сравнение по шагам

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

Опишите список сущностей до старта теста. Например: ИИН, номер карты, телефон, email, ФИО, адрес. Рядом запишите, что именно модель должна сделать с каждой сущностью: скрыть полностью, оставить последние 4 цифры, вернуть метку класса или сделать и то и другое.

Дальше держите одинаковые условия для всех моделей.

1. Соберите один тестовый набор. В нем должны быть короткие, длинные и шумные тексты: чат с клиентом, выписка, заявка, письмо, кусок OCR.
2. Дайте всем моделям один и тот же промпт и один формат ответа. Лучше простой JSON с полями для типа сущности, позиции и замаскированного значения.
3. Если модель ведет себя нестабильно, прогоните один и тот же набор минимум три раза. Потом посчитайте средний результат и разброс.
4. Разделите итоги на простые, спорные и провальные случаи. Простые показывают базовый уровень, спорные помогают понять границы правил, провальные сразу указывают на риск.
5. Считайте не только среднюю цену прогона, но и цену одной пропущенной ошибки.

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

Простой пример: модель A стоит 900 тенге на наборе и пропускает 12 сущностей, модель B стоит 1400 тенге и пропускает 4. Экономия на модели A равна 500 тенге, но вы получаете 8 дополнительных пропусков. Значит, каждый "сэкономленный" пропуск обходится примерно в 62,5 тенге. Для банка или клиники это обычно плохая сделка.

Если вы тестируете через единый шлюз, удобнее сохранить один и тот же код и формат запроса для всех моделей. В случае AI Router команде часто достаточно сменить base_url на api.airouter.kz и не трогать SDK, код и промпты. Это убирает лишний шум из сравнения и помогает честно сопоставить провайдеров и локально хостимые модели.

Простой сценарий для банка

Клиент пишет в чат поддержки: "Не проходит платеж, мой телефон 8 777 123 45 67, ИИН 990101300123, номер договора 45821". Банку не нужен самый сильный генератор, чтобы разобрать такое сообщение. Сначала системе надо убрать чувствительные данные, а уже потом понять тему обращения.

Первая небольшая модель делает маскирование PII до записи текста в логи, очереди и внутренние карточки обращения. Она заменяет телефон, ИИН и номер договора на метки вроде [PHONE], [IIN] и [CONTRACT]. Если модель работает аккуратно, сотрудник все еще видит смысл жалобы, но сырые данные не гуляют по сервисам и журналам.

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

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

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

Команда здесь смотрит не на красивые средние цифры, а на остаток ошибок на тысячу обращений. Если из 1000 сообщений модель пропустила 3 ИИН и неверно пометила 18 тем, это уже понятный разговор для риска, ИБ и владельца продукта. После этого можно решить, что дешевле: дообучить небольшую модель, поправить правила или расширить порог эскалации.

Где маленькие модели ошибаются чаще всего

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

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

С OCR все еще хуже. Скан заявления, фото анкеты или старый PDF после распознавания часто дают шумный текст: буквы похожи на цифры, строки едут, пробелы исчезают. Небольшая модель цепляется за сломанные шаблоны и пропускает ИИН, телефон, адрес или ФИО. А иногда, наоборот, маскирует случайный набор символов просто потому, что он похож на номер.

Проблем добавляет смесь языков и алфавитов. В одном сообщении легко встретить русский, казахский и латиницу: имя на кириллице, улицу на латинице, служебную пометку на казахском. На таких данных небольшие модели теряют точность быстрее, чем кажется по демо на чистом русском тексте. Они могут принять имя за название компании, не узнать адрес или оставить без маски кусок строки вроде "Abai 26, kv 14".

Еще одна частая ошибка выглядит почти комично, но в продакшене мешает сильно. После слова "мой" модель начинает маскировать слишком много. Фраза "мой врач сказал" или "мой тариф изменился" внезапно превращается в сплошные заглушки, хотя там нет PII. Обычно так бывает, когда модель переучилась на слишком простом правиле: после притяжательного слова часто идет личная информация. На живых данных это правило быстро ломается.

Падение качества заметно и в другом сценарии: один запрос пытается делать все сразу. Если вы просите модель найти PII, присвоить класс каждой сущности и еще сгенерировать ответ пользователю, небольшая модель начинает экономить на разметке. Текст ответа может выйти гладким, но метки станут грязными, а часть PII потеряется.

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

Быстрая проверка перед запуском

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

Сначала смотрят не на общую точность, а на recall по самым чувствительным типам данных. Если для банка или клиники критичны ИИН, телефоны, адреса и номера документов, проверьте именно их на редких и неприятных примерах: смешанный язык, лишние пробелы, ручной ввод оператора, текст из старой CRM. Одна пропущенная сущность здесь обычно дороже, чем несколько лишних срабатываний.

Потом считают деньги в простом виде. Не "сколько стоит тысяча токенов", а сколько стоит один день и один месяц при вашей реальной нагрузке. Возьмите обычный будний поток, добавьте запас на пики и посмотрите, укладывается ли маскирование PII в бюджет без сюрпризов. Часто небольшая модель выигрывает не тем, что она намного точнее, а тем, что ее можно держать включенной для всего потока, а не только для части запросов.

С задержкой та же логика. Для формы на сайте лишние 300-500 мс уже заметны. Для чата поддержки задержка быстро копится на каждом сообщении. Для оператора в контакт-центре даже одна дополнительная секунда раздражает сильнее, чем кажется на стенде. Проверяйте не среднее время ответа, а p95 на живом сценарии.

Перед запуском обычно хватает короткой проверки:

• на тестах нет просадки recall по критичным типам PII, особенно на редких примерах
• дневная и месячная стоимость понятна заранее, с запасом на пики
• задержка не ломает форму, чат или работу оператора
• логи не держат исходный PII дольше, чем это нужно для аудита и отладки
• команда знает, когда запрос надо отправить в более сильную модель

Последний пункт часто решает все. Нужны простые правила эскалации: низкая уверенность, длинный неструктурированный текст, спорная категория, смешение языков, конфликт между двумя проверками. Если вы используете AI Router, такие маршруты можно собрать через один совместимый с OpenAI API, а данные держать в контуре с аудит-логами, маскированием PII и ограничениями на уровне ключа, если этого требует политика компании.

Что делать дальше

Небольшие модели для маскирования и классификации PII лучше внедрять по одному потоку данных. Не расширяйте пилот сразу на чат, почту, заявки и документы. Возьмите один понятный источник, например обращения из веб-формы, и сравните 2-3 модели одного класса при одинаковом промпте.

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

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

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

Если команда уже работает с SDK, совместимыми с OpenAI, такие сравнения можно собрать без долгой переделки. В AI Router можно прогнать те же запросы через разных провайдеров или через open-weight модели на собственной GPU инфраструктуре, не меняя привычный код и промпты. Это особенно удобно, когда нужно быстро понять, дает ли дешевая модель ту же точность на вашем наборе или экономия исчезает из-за лишних повторов.

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

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