Классификация текстов нейросетью: отзывы и заявки

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

Что можно классифицировать

Список задач, которые на самом деле одна и та же задача.

Обращения в поддержку — по теме, чтобы направить в нужный отдел.

Отзывы — по тональности и по предмету жалобы.

Заявки и лиды — по типу и приоритету.

Письма — по срочности и адресату.

Документы — по типу: счёт, договор, акт, письмо.

Сообщения — на предмет того, требуют ли они ответа человека.

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

Как описать категории

Здесь сосредоточено почти всё качество, и здесь же самая частая причина ошибок.

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

Каждая описана одним предложением. Не название, а объяснение: что сюда попадает. «Доставка — вопросы о сроках, статусе и месте нахождения заказа, включая жалобы на опоздание».

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

К каждой категории дан пример. Один реальный текст. Примеры действуют сильнее описаний.

Есть категория «не определено». О ней отдельно ниже — это самый недооценённый элемент схемы.

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

Почему нужна категория «не определено»

Пункт, который чаще всего пропускают, и зря.

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

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

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

Какую модель брать

Хорошая новость: почти любую.

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

В каталоге на 1 сентября 2026 года восемь позиций тарифицируются по нулевой ставке после платного пополнения, и несколько из них прямо заявлены как компактные модели для классификации и извлечения. Это ровно тот случай, когда начинать надо снизу и подниматься только при доказанной нехватке — что доступно по нулевой ставке.

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

Как получить ответ, пригодный для кода

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

Просите строгую структуру. Поле с категорией, поле с уверенностью, поле с обоснованием — по вкусу. Механику разбирали в материале как получить строгий JSON.

Задайте перечисление. Список допустимых значений вместо свободного текста снимает целый класс расхождений вроде «Доставка», «доставка» и «вопрос о доставке».

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

Не просите объяснений, если они не нужны. Обоснование — это выходные токены, которые вы оплачиваете. Полезно на этапе отладки, лишнее в проде.

Как измерить точность

Без этого шага любые улучшения — гадание.

1. Разметьте вручную двести реальных примеров. Не придуманных. Разметку делает человек, знающий предметную область.
2. Прогоните через модель. Тот же промпт, что в проде.
3. Посчитайте долю совпадений. Это ваша базовая точность.
4. Разберите несовпадения по категориям. Обычно выясняется, что ошибки сконцентрированы в одной-двух парах похожих категорий.
5. Правьте описания, а не модель. Восемь из десяти ошибок лечатся уточнением границы между двумя категориями.

Двести примеров — минимум, при котором видно разницу между версиями промпта. На двадцати вы будете смотреть на шум.

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

Сколько это стоит

Классификация — редкий случай, когда счёт приятно удивляет.

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

Отсюда два вывода:

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

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

Как перевести это в месячную сумму — в разборе стоимости миллиона токенов в рублях.

Где схема ломается

Четыре типовые проблемы.

Категории пересекаются. Текст честно подходит к двум. Лечится переописанием границ или разрешением нескольких меток.

Классов слишком много. Двадцать категорий — почти гарантированные промахи. Лечится двухуровневой схемой.

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

Категории изменились, промпт нет. Бизнес добавил новый тип заявок, описания остались прежние. Стоит завести привычку сверять список раз в квартал.

Что делать с результатом дальше

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

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

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

Автоответ. Здесь автоматизация уже рискованная: неверная категория превращается в неуместный ответ клиенту от вашего имени. Порог по уверенности и категория «не определено» становятся обязательными.

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

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

Чего мы не утверждаем

Не сравниваем модели по точности. Своих замеров мы не делали; мерить надо на своих данных.

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

Цифры каталога — на дату. Восемь позиций с нулевой ставкой — состояние на 1 сентября 2026 года.

Что держать в голове

Классификация — самая простая точка входа в API: короткий ответ, конечный список, автоматическая проверка. Дорогая модель здесь почти не даёт преимущества.

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

Как мы проверяем факты и что храним из запросов — на странице о проекте и в llms.txt. Проверить свою выборку на нулевой ставке: keydealer.ru/login.