Разработка NLP-систем: пайплайны, модели и деплой

Разработка NLP-систем: где падает точность

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

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

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

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

Что даёт выстроенный конвейер обработки текста

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

Время ответа складывается из работы модели и постобработки. Задержку чаще даёт не она, а синхронные вызовы справочников и записи в учётную систему. Замерив каждый этап, мы убираем лишние ожидания: первый осмысленный ответ уходит за доли секунды, а тяжёлые проверки идут фоном.

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

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

Готовые модели и библиотеки экосистемы вроде Hugging Face закрывают базовый слой NLP-конвейера, поэтому время уходит не на обучение с нуля, а на разметку под ваш домен и разбор ошибок. Это и определяет, какая доля обращений реально закрывается без человека.

Варианты реализации: облако, свои мощности, гибрид

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

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

Схему не выбирают один раз и навсегда: при росте объёма запросов и накоплении разметки переход между вариантами — это плановая работа, а не переписывание системы с нуля.

Этапы внедрения: от аудита данных до развёртывания

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

1. Аудит данных. Разбираем источники: объём, доля неразмеченных записей, дубли, персональные данные. На выходе — пригодность каждого источника и список того, что чистим руками.
2. Схема решения. Определяем, где модель встаёт в контур: что закрываем правилами и словарями, что — обучением, какой формат входа и выхода нужен соседним системам. Схему согласуем до старта, чтобы не переделывать интеграцию.
3. Эталонная выборка. Собираем вручную размеченный набор, покрывающий редкие и спорные случаи, и фиксируем метрики по каждому классу, а не одну общую цифру. Это база сравнения для всех следующих версий.
4. Настройка и обучение. Готовим признаки и разметку, обучаем модель, подбираем пороги срабатывания под допустимую долю ложных. Каждая версия сохраняется вместе с параметрами и результатом на эталонной выборке.
5. Проверка на потоке. Запускаем в теневом режиме: модель отвечает, решение принимает текущий процесс. Сравниваем с эталоном, смотрим долю неуверенных ответов, задержку и поведение на редких классах.
6. Развёртывание. Переносим в рабочий контур с версионированием моделей, журналом запросов и откатом на предыдущую версию. Настраиваем контроль дрейфа: падение качества видно раньше, чем его заметит заказчик.
7. Передача. Документация, регламент переобучения и разбора ошибок, доступы — команда заказчика развивает решение дальше без нас.

Комплект поставки: конфигурации, схемы, регламенты

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

• Конфигурации сред: развёртывание, переменные окружения, лимиты ресурсов, доступы к внешним сервисам — с пояснением, какой параметр на что влияет и что будет, если его изменить.
• Схема обработки: путь запроса от приёма до ответа — где модель, где правила-фильтры, где кэш, какие точки логируются и как связать запись в логе с конкретным решением системы.
• Правила разметки: инструкция для аннотаторов, словарь спорных случаев, критерии согласия между разметчиками и порядок разрешения конфликтов в оценках.
• Документация по модели: состав признаков, происхождение обучающего набора, метрики качества по классам, известные границы применимости и типовые ошибки на живых данных.
• Регламент эксплуатации: что мониторим, пороги деградации качества, порядок отката на предыдущую версию, частота обновления словарей и правила переобучения.
• Схема оповещений: какие метрики собираются, где смотреть, при каких значениях дежурный получает сигнал и что делает первым шагом.
• Порядок передачи решения: доступы и роли, запуск системы с нуля на чистом окружении и инструкция для инженера заказчика, который войдёт в проект после нас.

Кейс: обработка обращений в службе поддержки

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

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

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

Чем отличается дообучение NLP-модели от обучения с нуля?

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

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

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

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

Технические сомнения: данные, разметка, нагрузка

Инженерные сомнения касаются не модели, а всего вокруг неё: хватит ли разметки, выдержит ли решение пиковую нагрузку, не утекут ли данные и кто отвечает за качество через полгода. Ниже — ответы на то, что чаще всего всплывает на технической приёмке.

Что будет при пиковой нагрузке?

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

Как обеспечивается конфиденциальность данных?

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

Кто отвечает за дрейф качества после запуска?

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

Обсудим задачу: что прислать для оценки

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

• Примеры данных — несколько сотен реальных обращений, писем или расшифровок в том виде, в каком они попадают в систему: с опечатками, смешением языков, вложениями и пустыми полями.
• Описание потока — откуда приходит текст, кто и что с ним делает дальше, какие системы получают результат: учёт заявок, внутренний портал, отчётность.
• Требования к качеству — какие ошибки недопустимы, а какие терпимы, нужна ли оценка уверенности и что система должна делать при низкой.
• Ограничения по контуру — где разрешено обрабатывать данные: внешнее облако, защищённый контур или полностью локальный запуск, и сколько их можно хранить.
• Объёмы и режим — сколько документов приходит в сутки, нужен ли ответ в реальном времени или достаточно обработки по расписанию.
• Критерии приёмки — на каком наборе примеров проверяем качество и какое расхождение с ожиданием считаем приемлемым для запуска.

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