Классификатор услуг на LLM вырос с 73% до 94%, но цепочка из трёх нод всё равно даёт 75%

Любая команда, которая запускала LLM в прод, знакома с этим разочарованием. На тестовом наборе модель выдаёт 98%, а на реальных данных выходит 73%. Автор разбора на Habr считает, что на проде редко удаётся получить качество всей системы выше 90%. Поэтому ориентироваться стоит именно на эту цифру. Некоторые проекты из-за высокой цены ошибки просто не сойдутся.

Задача: 50 классов и один справочник

Пример взят из реальной работы. По названию услуги нужно выбрать код для 402-й формы. Классификация плоская, 50 классов, каждый вид услуги соответствует ровно одному коду. Например, «842 — Разработка и установка программного обеспечения» или «7123 — Грузовые перевозки автомобильным транспортом». Задача выглядит простой, но на ней видно, как ведёт себя одна нода.

Первый инстинкт — дописывать в промпт исключения. Так промпт раздувается, и появляются три проблемы. Во-первых, модель может «потерять» часть длинного контекста: информация во входе есть, а в ответе её нет. Во-вторых, если в одном промпте десятки разных задач (скажем, извлечение 50 атрибутов, и для суммы уже целый абзац правил), часть правил выпадает. В-третьих, возникает аналог переобучения: вы подгоняете промпт под один и тот же бенчмарк, и он выучивает примеры вместо общего правила. Остановились на 8 примерах и получили 81%.

Что реально подняло качество ноды

Наивное разделение справочника пополам автор отвергает. Получатся два кандидата, и понадобится третий шаг, чтобы выбрать один код. Это новое место для ошибок.

Помог разбор логов и разговор с бизнесом. Выяснилось, что в одном документе может быть несколько услуг. Предыдущая нода записывала их одной строкой, и LLM выбирала один код, а остальные услуги терялись. Исправление такое: извлекать услуги списком, подавать каждую отдельно с нужным контекстом документа и собирать результат с кодом для каждой. Качество выросло до 89%. Проблема сидела в постановке задачи, а не в модели.

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

Цепочки: качество перемножается

Главная мысль второй половины статьи: у цепочки вызовов итоговое качество равно произведению качества шагов. Пример из контакт-центра. Переписывание вопроса работает на 95%, RAG-поиск по базе знаний на 80%, финальный ответ на 99%. Итого 0,95 × 0,80 × 0,99 = 75%. Расчёт честен только на одном фиксированном датасете: нельзя мерить каждое звено на своём наборе и потом перемножать.

Соблазн понятен: добавить оркестрацию со стоп-листом проблемных вопросов. Она действительно отсекает часть случаев, и RAG на оставшихся работает лучше, допустим на 89%. Но сам оркестратор тоже ошибается, скажем в 5% случаев. Итог: 95% × 95% × 89% × 99% ≈ 79,5%. Прирост есть, но небольшой, а система стала сложнее. Идеальной она не стала: к цепочке добавился ещё один шаг со своей ошибкой.

Что делать на практике

• Измеряйте качество на реалистичных данных, а не только на внутреннем бенчмарке. Разрыв 98% и 73% — типичный сценарий.
• Прежде чем усложнять промпт, смотрите логи и разговаривайте с бизнесом. Часть «ошибок модели» окажется ошибками постановки задачи или предыдущего шага.
• Дробите задачу по смыслу (одна услуга — один вызов), а не механически.
• Считайте цепочку заранее: три шага по 90% дают около 73%.
• Если цена ошибки высока, закладывайте человека в контур. 100% от LLM-системы ждать не стоит.

Ограничения

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