Привет, я Александр Бондаренко, эксперт по комплаенсу и руководитель проектной группы в Далее. Еще до выхода «закона о защите русского языка» мы стали искать быстрый способ вычистить сайты от недопустимых заимствований и «латиницы».
В итоге создали алгоритм с многоступенчатым фильтром, OCR и LLM. Система находит в контенте только недопустимые слова и тут же предлагает русские аналоги. На выходе получаем результат в 20 раз быстрее, чем при адаптации текста вручную.
Рассказываю, как реализовано решение и чем кардинально отличается от скармливания страниц в ChatGPT или другие ИИ-боты.
Дисклеймер: В тексте используются профессиональные термины на английском языке. Статья носит информационный характер и адресована специалистам, а не физлицам-потребителям.
Требования 168-ФЗ как ТЗ к разработке системы
Чтобы автоматизировать проверку, нашим юристам и аналитикам пришлось перевести сухой язык закона в четкие техтребования. В тексте ФЗ №168 заложены 3 основных правила, которые определили логику работы алгоритма.
1. Идентификация недопустимых заимствований
Закон запрещает использовать иностранные слова, если у них есть общеупотребительные аналоги в русском языке. Под запрет попадает не только «латиница», но и транслитерации, написанные кириллицей.
Системе необходимо все найти и сопоставить с 4-мя словарями, утвержденными PAH: орфографическим, орфоэпическим, толковым и словарем иностранных слов. В итоге мы должны получить выборку из понятий, которых там нет.
2. Защита товарных знаков и брендинга
Закон гласит, что иностранные слова нужно либо заменить, либо пояснить на русском. Но есть исключения:
-
зарегистрированные товарные знаки;
-
фирменные наименования;
-
термины и характеристики, не имеющие аналогов на русском.
Алгоритму нужно задать жесткое правило: автоматически исключать из проверки любые сущности, которые входят в «белый список» компании и реестры Роспатента.
3. Контекстуальная замена без потери смысла
Замена иностранных слов «лоб в лоб» по обычному словарю может разрушить структуру предложений. Текст станет нечитаемым для пользователя и потеряет свою маркетинговую ценность.
Система должна подбирать аналоги с учетом контекста. Например, фразу «У нас лучший оффер на рынке» нельзя перевести как «У нас лучшее предложение работы на рынке», если компания продает товары. Наше решение обязано подбирать точные смысловые синонимы, согласуя их по роду, числу и падежу, чтобы финальный текст выглядел естественно.
Еще один важный момент — обновление словарей. Ведь по меньшей мере это обидно — искать аналог слова, которое вчера разрешили. Мы учли и этот аспект, добавив регулярные запросы к актуальной базе.
Принцип работы и реализация микросервиса с LLM
В феврале мы развернули пилот и назвали его Нормографом. Сервис построили по логике многоступенчатой фильтрации.
Большая часть слов вообще не отправляется в языковую модель. До обращения к LLM система самостоятельно отсеивает все случаи, которые можно определить алгоритмически. Это снижает стоимость обработки, ускоряет проверку и уменьшает вероятность ложных рекомендаций.
Функционал реализован как отдельный микросервис с простой архитектурой. Клиентская часть построена на HTML5, CSS3 и JavaScript. Серверная логика написана на PHP 8+ и взаимодействует с клиентом через JSON API. Для хранения данных используются PHP Sessions и файловый кеш.
Работа системы состоит из 5 этапов.
1. Извлечение текста
Сервис получает HTML страницы, удаляет разметку, JavaScript, CSS и другой технический код, после чего извлекает только текстовый контент. Текст разбивается на токены для дальнейшей обработки.
2. Первичная фильтрация
Система исключает все, что заведомо не требует проверки. После этого объем текста для анализа сокращается в несколько раз.
Не трогаем:
-
слова из нормативных словарей русского языка вместе со всеми словоформами;
-
слова из пользовательского белого списка;
-
зарегистрированные названия, бренды и другие исключения, которые компания может определить самостоятельно.
3. Поиск потенциально проблемных слов
На этом этапе формируется список слов, которые требуют дополнительной проверки. Данный набор становится предметом дальнейшего анализа.
В него попадают:
-
слова, отсутствующие в нормативных словарях;
-
слова из внутренней базы потенциальных англицизмов;
-
слова, написанные латиницей.
4. Проверка с помощью LLM
Только после всех предварительных фильтров подключается языковая модель. Она получает уже очищенный текст и решает задачи, которые сложно формализовать обычными правилами:
-
определяет, действительно ли слово является нежелательным заимствованием;
-
учитывает контекст употребления;
-
предлагает русские аналоги;
-
использует только варианты, соответствующие нормативным словарям, исключая замену одной «латиницы» или транслитерации на другую.
Модель анализирует не весь контент, а лишь небольшой фрагмент, где действительно требуется экспертная оценка.
5. Формирование отчета
Пользователь получает готовый список проблемных мест с рекомендациями по замене. Контент-менеджеру остается проверить предложенные варианты, выбрать подходящие формулировки и внести изменения на сайт.
В типовом подходе система лишь указывает на слова, отсутствующие в нормативных словарях. ИИ-модуль предлагает готовую корректную формулировку, сохраняя исходный смысл и учитывая контекст.
Следующим этапом развития сервиса могут стать:
-
замена собственного стеммера на библиотеку phpMorphy для более точной морфологической обработки;
-
подключение нескольких LLM, например YandexGPT, для дополнительной валидации результатов;
-
обучение собственной модели на размеченных данных;
-
API для интеграции с внешними сервисами и CMS;
-
расширение словарной базы и отраслевых глоссариев.
В качестве языковой модели для пилота взяли GigaChat API. Архитектура не привязана к конкретному провайдеру, поэтому при необходимости можно подключить другую LLM без изменения основной логики обработки.
Сайт — это не только текст: распознавание надписей на изображениях
В первой итерации Нормографа мы проверяли саму логику алгоритма на текстовом контенте. Позже добавили в конвейер OCR-модуль, чтобы искать латиницу и заимствования, которые скрываются в иллюстрациях.
Теперь сервис, как краулер, собирает изображения с каждой страницы сайта и отправляет их на распознавание. Извлеченный текст проходит тот же многоступенчатый фильтр, что и обычный контент: словари, белые списки, LLM-проверка контекста.
Для распознавания используем Yandex Cloud Vision. Он хорошо работает с кириллицей и латиницей вперемешку, а данные не покидают российскую инфраструктуру — для фармкомпаний и финтеха это не пожелание, а законодательное требование.
Чтобы снизить расходы на OCR, сделали несколько оптимизаций:
-
изображения кешируются по хешу — один и тот же баннер, повторяющийся на десятках страниц, распознается один раз;
-
иконки, пиктограммы и другие мелкие элементы отсеиваются до отправки по размеру и содержимому;
-
логотипы и зарегистрированные товарные знаки уходят в исключения — закон их не трогает, и алгоритм тоже не должен.
В отчете иллюстрацию со «стоп-словом» привязали к конкретному файлу и странице. Контент-менеджер видит URL картинки, распознанный фрагмент и рекомендацию. Ему не нужно пересматривать все баннеры сайта, чтобы понять, где именно проблема.
Что показало тестирование
На тестовых данных ручная проверка одной страницы занимала примерно час. Время зависело от объема контента, количества скрытых элементов и числа потенциальных заимствований. После внедрения сервиса полная адаптация 1 страницы занимает от 2 до 10 минут.
Да, алгоритм с LLM не исключает человека из процесса, но значительно ускоряет процесс и сокращает риски. На выходе получаем результат в 20 раз быстрее, чем при ручной адаптации текста.
Основная экономия достигнута за счет автоматического поиска проблемных слов и предварительной фильтрации текста.
Почему просто не использовать ChatGPT или другие ИИ-чаты
Главная ценность разработанного решения — гибкость. Его можно встроить в интерфейс админки, не заставляя менеджеров «бегать» по сервисам. Для корпоративных порталов фармы, финтеха и крупного e-com ручная адаптация сотен страниц выйдет намного дороже.
Но есть и другие причины, по которым ни ChatGPT, ни иные его аналоги не подходят для массовых проверок.
1. Непредсказуемость. Даже если задать языковой модели правила проверки, ее ответ останется вероятностным. При одинаковом запросе она может по-разному интерпретировать спорные случаи. Для нахождения запрещенных слов нужен точный результат, за который отвечает алгоритмическая проверка.
2. Лимиты. ИИ-чаты имеют ограничение на объем текста, который они могут обработать за раз. При попытке отправить в чат на анализ полный HTML-код страницы мы в 99% случаев получим ответ о превышении лимита и закрытии чата. Придется извлекать из страницы чистый текст, тратить время на его подготовку и/или отправлять по частям, что приведет к большим трудозатратам.
3. Экономика. Если рассмотреть платные API, то без предварительной фильтрации контента каждая страница потребует оплаты за обработку тысяч токенов. Модель будет анализировать и те слова, которые уже есть в нормативных словарях и заведомо не требуют проверки. При масштабировании на сотни и тысячи страниц затраты станут очень высокими.
4. Риск утечки конфиденциальных данных. Выгружая и сразу отправляя страницы из CMS в зарубежный чат, можно отдать ИИ непубличные и staging-страницы, внутренние документы, а иногда и формы с персональными данными. Для многих компаний это запрещено внутренними политиками, а если в контенте есть ПДн — это еще и трансграничная передача со всеми вопросами по 152-ФЗ.
5. Юридическая безответственность. Дисклеймер любой ИИ гласит: «ИИ может совершать ошибки. Проверяйте важную информацию». Пользователь не может взять скриншот ответа в качестве оправдания в суде или на комиссии ФАС.
6. Словарей как выгружаемого датасета нет. Нормативные словари РАН — это издания и веб-доступ, а не машиночитаемая база под свободной лицензией. Модели как GPT сами не понимают, какие заимствования уже стали нормой, а какие требуют замены.
Кроме того, ИИ не знает, какие слова исключать в рамках страницы. Речь про наш динамический список слов, специфичные термины и товарные знаки. Это приведет к ложным срабатываниям и созданию промта со списком, на написание которого также нужно время.
В случаях, когда дело касается сайтов-визиток из 10 страниц, конечно, более целесообразно обойтись подручными средствами. Для порталов ожидание и затяжная адаптация могут обернуться неприятным исходом в виде штрафов.
Когда ждать проверок сайтов регуляторами
С выхода закона 1 марта 2026 года общедоступных практик предписаний и разбирательств по цифровым площадкам еще нет. Но надо учитывать, что контроль за соблюдением требований 168-ФЗ осуществляют два ведомства.
-
Роспотребнадзор — нарушения, которые идут в связке с законом «О защите прав потребителей».
-
Федеральная антимонопольная служба — все, что касается использования иностранных слов в рекламе.
Скорее всего, в ближайшее время проверки будут проходить не по инициативе госорганов, а по факту поступления жалоб.
К 2027 году Правительство РФ намерено запустить информационную систему «Национальный словарный фонд». Как в случае с утвержденными РАН словарями в конце 2025 года и последующего принятия закона 168-ФЗ, новая система может стать отправной точкой к автоматизации процесса проверок и их массовым практикам.
Про комплаенс сайтов пишу в своем телеграм-канале https://t.me/soglasen_na_obrabotku, подписывайтесь, буду рад мнениям в комментариях.
Автор: AlexandrB09
