RAG или классификатор документов: что выбрать для входящих заявок и почему это не взаимозаменяемые подходы

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

Что именно нужно получить на выходе

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

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

Качество: разные метрики, разные ловушки

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

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

Данные и сопровождение

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

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

Цена и задержка

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

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

Практический выбор

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

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

Не забывайте о праве не отвечать

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

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

Вопросы по теме

Можно ли использовать RAG без генерации? Да. Поиск по фрагментам с источником часто полезнее рискованного готового ответа.

Что делать с обращениями вне известных классов? Добавить класс «не определено», направлять его человеку и регулярно смотреть, не появился ли новый устойчивый тип.

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