NLU vs LLM: когда классификатор намерений лучше нейросети

Недавно ко мне обратился знакомый — технический директор логистической компании. Они два года назад внедрили чат-бота на классическом NLU-движке: интенты, сущности, сценарии. Бот работал неплохо, обрабатывал типовые вопросы — «где моя посылка», «когда доставка», «хочу изменить адрес». Но теперь руководство насмотрелось демок ChatGPT и требует «переделать всё на нейросеть, чтобы было умно».

Знакомый был в замешательстве. С одной стороны, текущий бот работает стабильно, метрики хорошие, пользователи довольны. С другой — LLM действительно впечатляет гибкостью. Но перестраивать всё с нуля? Это риск, это бюджет, это время. А главное — непонятно, станет ли лучше.

Мы проговорили пару часов, и я понял, что этот вопрос волнует многих. NLU или LLM? Интенты или промпты? Классика или хайп? Попробую разобраться без эмоций и маркетинговых лозунгов. Правильного ответа «на все случаи жизни» не существует — но есть понятные критерии выбора.

Для начала разберёмся в терминах

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

Классический NLU (Natural Language Understanding) — это подход, основанный на классификации. Вы заранее определяете набор «намерений» (intents), которые может выразить пользователь. «Хочу узнать статус заказа» — это один интент. «Хочу изменить адрес доставки» — другой. «Хочу отменить заказ» — третий. Для каждого интента вы собираете примеры фраз — как пользователи могут выразить это намерение. Система обучается на этих примерах и потом классифицирует новые фразы по известным категориям.

Помимо интентов, NLU извлекает сущности (entities) — конкретные данные из запроса. В фразе «Где мой заказ номер 12345» интент — это «узнать статус заказа», а сущность — номер заказа «12345». Это структурированные данные, с которыми потом работает логика бота.

Генеративные LLM (Large Language Models) — это совсем другая история. Модели вроде GPT-4, Claude или GigaChat не классифицируют, а генерируют. Вы даёте модели контекст (системный промпт, историю диалога, данные из базы знаний) и просите сгенерировать ответ. Модель не выбирает из заранее определённых вариантов — она создаёт ответ «с нуля», опираясь на своё обучение.

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

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

Как на самом деле работает NLU

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

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

Параллельно работает извлечение сущностей. Это может быть NER-модель (Named Entity Recognition), которая размечает токены как «начало сущности», «продолжение сущности», «не сущность». Или это могут быть регулярные выражения для типовых паттернов — дат, номеров телефонов, email-адресов.

Звучит неплохо? Есть и обратная сторона. NLU ограничен теми интентами, которые вы ему описали. Если пользователь спросит что-то, что не укладывается ни в один интент — система растеряется. Выдаст либо неправильный интент с низким confidence, либо сработает fallback «не понял вопрос».

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

Как работает LLM в контексте чат-ботов

LLM устроен принципиально иначе. Это огромная нейросеть (сотни миллиардов параметров), обученная на колоссальных объёмах текста. Модель «прочитала» интернет, книги, документацию — и научилась генерировать осмысленный текст, продолжая любой заданный контекст.

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

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

Но у LLM есть серьёзные ограничения, о которых восторженные посты в LinkedIn обычно умалчивают. Во-первых, стоимость. Каждый запрос к LLM стоит денег (или вычислительных ресурсов, если модель развёрнута локально). При большом потоке обращений это может быть существенно.

Во-вторых, задержка. LLM генерирует ответ последовательно, токен за токеном. Даже быстрые модели отвечают сотни миллисекунд, а то и секунды. Для голосового бота, где важна низкая latency, это критично.

В-третьих, непредсказуемость. LLM может выдать неожиданный ответ. Может «забыть» инструкции из промпта. Может галлюцинировать — выдумывать факты, которых нет в базе знаний. Это не баг, а особенность архитектуры. С ней можно бороться, но полностью устранить нельзя.

Наконец, контроль. С NLU вы точно знаете: вот 15 интентов, бот умеет только их. С LLM границы размыты. Модель может попытаться ответить на любой вопрос — даже на тот, на который отвечать не должна. Это создаёт риски: репутационные, юридические, коммерческие.

Сравнение по ключевым критериям

Разложим всё по полочкам. Сравним NLU и LLM по параметрам, которые обычно важны бизнесу.

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

Когда NLU — правильный выбор

Разберём конкретные ситуации, когда классический подход с интентами оправдан. Это не про «олдскул vs хайп», а про инженерную целесообразность.

Ограниченный и стабильный набор сценариев

Если ваш бот должен уметь делать 10-20 конкретных вещей — и не больше — NLU будет идеален. Классический пример: бот для записи на приём. Пользователь может записаться, отменить запись, перенести, узнать свободное время, спросить адрес. Это всё. Никаких философских бесед о смысле жизни не предполагается.

В такой ситуации NLU даёт 100% предсказуемость. Вы точно знаете, как бот среагирует на каждую фразу. Можете написать тесты, которые проверят каждый интент. Можете гарантировать SLA по качеству. С LLM такой определённости не будет — модель может интерпретировать запрос неожиданно.

Критичные по скорости приложения

Голосовые боты — классический случай. Когда человек говорит по телефону, паузы в секунду-полторы ощущаются как вечность. NLU отвечает за миллисекунды. LLM — за сотни миллисекунд в лучшем случае, а в реальности часто за секунды.

Да, можно оптимизировать: использовать streaming, кэшировать частые запросы, применять маленькие модели. Но даже при всех оптимизациях LLM будет медленнее классического NLU. Если latency критична — думайте в сторону NLU или гибридной архитектуры.

Высокие требования к точности на конкретных запросах

Представьте: пользователь пишет «Хочу отменить подписку». Это критически важное действие — если бот ошибётся и поймёт как «хочу оформить подписку», будет скандал. NLU на хорошо размеченных данных даст 98%+ точности на таких интентах. LLM тоже справится хорошо, но может иногда интерпретировать неправильно — особенно если формулировка нестандартная.

Когда ошибка стоит дорого — предпочитайте детерминированность. NLU с хорошим fallback («не уверен, переключаю на оператора») лучше, чем LLM, который уверенно делает неправильные выводы.

Ограниченный бюджет на inference

Если у вас миллион обращений в месяц, разница в стоимости ощутима. NLU-модель можно запустить на обычном сервере и забыть про неё — стоимость вычислений копеечная. LLM, даже при использовании дешёвых моделей вроде GPT-3.5-turbo, выльется в сотни и тысячи долларов в месяц.

Конечно, можно развернуть open-source LLM локально (Llama, Mistral). Но это требует GPU-серверов, которые тоже недёшевы. Если ваша экономика не позволяет тратить на inference — NLU экономически выгоднее.

Когда LLM — правильный выбор

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

Открытые вопросы и сложные формулировки

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

LLM справляется с такими формулировками естественно. Модель «понимает» контекст, выделяет несколько подвопросов, формирует связный ответ. NLU потребовал бы либо упрощения («спросите сначала про кредит, потом про страховку»), либо сложной логики разбора составных запросов.

Диалоги с контекстом

«— Сколько стоит доставка в Казань?
— Доставка в Казань стоит 500 рублей.
— А если до двери?
— ...»

Второй вопрос без контекста бессмыслен. «А если до двери?» — до двери чего? Куда? NLU придётся явно хранить состояние диалога, передавать сущности между репликами, писать логику «если спрашивают про доставку до двери, а контекст — Казань, то...». Это возможно, но муторно.

LLM работает с контекстом из коробки. Вы просто передаёте историю диалога, и модель сама понимает, что «до двери» относится к Казани из предыдущего вопроса. Никакой дополнительной логики писать не надо.

Работа с документами и базой знаний

RAG (Retrieval Augmented Generation) — это когда бот отвечает на вопросы по документам. Пользователь спрашивает что-то про ваш продукт, система находит релевантные куски документации и просит LLM сформировать ответ на основе этих данных.

С NLU такое не сделать. NLU может классифицировать вопрос («это про настройки», «это про биллинг»), но не может сгенерировать ответ по произвольному тексту. Для RAG нужна генерация, а генерация — это территория LLM.

Быстрый старт и эксперименты

Допустим, вы хотите протестировать гипотезу: «будет ли бот полезен нашим клиентам?» С NLU вам нужно: определить интенты, собрать примеры, разметить данные, обучить модель, написать сценарии. Это недели работы.

С LLM вы можете запустить MVP за день. Написали промпт, подключили к каналу — работает. Качество будет не идеальным, но достаточным для проверки гипотезы. Если гипотеза подтвердилась — можно инвестировать в оптимизацию. Если нет — не потратили месяц на разметку данных.

Гибридная архитектура: лучшее из двух миров

А вот что действительно интересно. В реальных проектах чаще всего работает не «или-или», а комбинация подходов. Гибридная архитектура позволяет взять лучшее от NLU и LLM, минимизировав недостатки каждого.

Паттерн 1: NLU для роутинга, LLM для генерации

Идея простая: NLU определяет, к какой теме относится запрос, а LLM генерирует ответ внутри этой темы. Например, NLU классифицирует: «это вопрос про возврат товара». Дальше управление передаётся LLM-модулю, который знает всё про возвраты и генерирует персонализированный ответ.

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

Паттерн 2: LLM для понимания, детерминированные действия

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

Пример: пользователь пишет «Перенеси мою запись с завтра на послезавтра, желательно после обеда». LLM парсит это в структуру: {action: «reschedule», current_date: «завтра», new_date: «послезавтра», preferred_time: «afternoon»}. Дальше код проверяет наличие слотов, бронирует, подтверждает. LLM не трогает CRM напрямую — только извлекает намерение.

Преимущества: гибкость понимания (любые формулировки) + надёжность действий (код не галлюцинирует). Если LLM неправильно распарсил — действие не выполнится, и можно переспросить. Это безопаснее, чем давать LLM полную автономию.

Паттерн 3: Fallback с эскалацией

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

Это хороший переходный вариант при миграции со старого бота. Вы сохраняете работающую логику для типовых сценариев, но добавляете «умный» обработчик для нестандартных случаев. Постепенно можете анализировать, какие запросы попадают в LLM-fallback, и либо добавлять интенты в NLU, либо расширять возможности LLM-модуля.

Миграция: как перейти со старого бота на новую архитектуру

Возвращаюсь к истории знакомого из начала статьи. Что делать, если у вас уже есть работающий NLU-бот, и хочется добавить «умности» от LLM? Или наоборот — был эксперимент на LLM, и нужно привести к продакшен-качеству?

Миграция с NLU на гибрид

Самый безопасный путь — не «переделывать всё», а добавлять LLM постепенно. Начните с fallback: все запросы, которые NLU не понял (низкий confidence), отправляйте в LLM. Смотрите метрики: помогает ли LLM закрыть эти кейсы? Не ломается ли что-то?

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

Важно: не удаляйте NLU-интенты сразу. Оставьте их как «страховку». Если LLM-модуль начнёт сбоить, можно быстро переключиться обратно. Постепенно, когда убедитесь в стабильности, можно упрощать архитектуру.

Миграция с LLM-прототипа к продакшену

Обратная ситуация: запустили бота на LLM, он работает, но дорого и иногда непредсказуемо. Что делать?

Анализируйте логи. Посмотрите, какие вопросы задают пользователи чаще всего. 80% запросов обычно укладываются в 20% сценариев. Эти топовые сценарии — кандидаты на NLU. Разметьте данные (у вас уже есть логи!), обучите классификатор, переключите типовые запросы на NLU.

LLM оставьте для длинного хвоста — редких и сложных запросов, где классификация не справляется. Так вы снизите расходы (типовые запросы идут через дешёвый NLU) и повысите предсказуемость (на частых сценариях — гарантированное качество).

Реальные кейсы: что выбирают компании

Теория — это хорошо, но как это работает в жизни? Вот как разные компании решают дилемму NLU vs LLM.

Кейс 1: Банк, служба поддержки

Крупный банк с миллионами клиентов. Чат-бот обрабатывает типовые вопросы: баланс, выписка, блокировка карты, курсы валют. Требования: высокая точность (нельзя перепутать «заблокировать» и «разблокировать»), низкие расходы (огромный поток), соответствие compliance.

Решение: классический NLU для всех типовых операций. Около 50 интентов, отличная точность, мгновенный отклик. LLM не используется — слишком рискованно в контексте финансовых операций. Fallback — на оператора.

Кейс 2: Онлайн-школа, продажа курсов

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

Решение: гибрид. NLU определяет тему (курс, оплата, техподдержка), LLM генерирует персонализированный ответ на основе информации о курсах и профиле студента. Критичные действия (оплата, возврат) — через NLU с подтверждением.

Кейс 3: IT-компания, внутренняя база знаний

Компания с сотнями сотрудников. Бот для ответов на внутренние вопросы: как оформить отпуск, где найти политику работы с конфиденциальными данными, как запросить доступ к системе. Документация разбросана по Confluence, SharePoint, регламентам.

Решение: чистый LLM + RAG. NLU не нужен, потому что вопросы слишком разнообразны для классификации. RAG находит релевантные документы, LLM формирует ответ со ссылками на источники. Если ответа нет в базе — честно говорит «не нашёл, обратитесь в HR».

Кейс 4: Голосовой бот для записи на приём

Сеть клиник. Голосовой бот принимает звонки и записывает на приём к врачам. Критична скорость отклика (голос!) и точность распознавания специальностей, дат, времени.

Решение: NLU для понимания намерений и извлечения сущностей. LLM вообще не используется — задержка неприемлема. ASR + NLU + детерминированная логика расписания. Работает надёжно и быстро.

Чек-лист: как выбрать подход для вашего проекта

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