Когда для задачи не нужен LLM — и что взять вместо

TL;DR. Значительная часть задач, которые приносят под вывеской «нужен ИИ», решается без языковой модели — быстрее, дешевле и с воспроизводимым результатом. Признак такой задачи: ответ выбирается из закрытого списка, шум в данных орфографический, а не смысловой, и решение нужно уметь объяснить. Языковая модель здесь не улучшает результат, зато добавляет стоимость инференса, задержку и разброс между запусками.

Три признака задачи, где LLM лишний

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

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

Результат нужно объяснить. Если по итогу кто-то спросит «почему система решила так», ответ «модель посчитала» не годится. Особенно там, где решение влияет на деньги или на человека.

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

Чем это решается

Нормализация плюс нечёткое сравнение. В проекте с классификацией должностей 300 входных строк после нормализации схлопнулись в 78 канонических форм — то есть большая часть работы свелась к точным совпадениям ещё до всякого сравнения. Остаток сопоставлялся взвешенной метрикой похожести строк со справочником. Обработка всего датасета — меньше 0,2 секунды на обычном процессоре, без GPU и без единого внешнего вызова.

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

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

Что вы отдаёте, взяв модель без нужды

• Воспроизводимость. Один и тот же вход даёт разные ответы между запусками. На демонстрации это незаметно, а в проде — расхождение отчётов и потерянное доверие.
• Объяснимость. Правило можно прочитать. Вес можно поправить. Решение модели можно только принять или не принять.
• Стоимость и задержка. Инференс стоит денег на каждом вызове или требует своей видеокарты. Ноль целых две десятых секунды на CPU против сетевого вызова к внешнему API — разница, которую чувствует пользователь.
• Контур данных. Внешнее API означает, что данные ушли наружу. Для кадровых выгрузок и договоров это отдельный разговор, которого можно было избежать.
• Точные идентификаторы. Артикулы, номера моделей, коды ошибок семантическому поиску даются плохо: VF-3YT и VF-3YR для эмбеддинга почти неразличимы. Там, где нужно точное совпадение строки, лексический поиск и фильтры работают лучше плотных векторов.

Где языковая модель действительно нужна

Обратная сторона, без которой список выше выглядел бы отрицанием.

• Открытое множество ответов. Объяснить, что именно в формулировке пункта договора создаёт риск, — ответ нельзя выбрать из списка, его нужно сформулировать.
• Смысловая неоднозначность. Вопрос «как охлаждается шпиндель» должен найти абзац про систему охлаждения, даже если слова «охлаждение» в нём нет. Это ровно то, чего лексический поиск не умеет.
• Работа с длинным неструктурированным текстом. Сжать часовой разговор до сути, вытащить из письма намерение, превратить свободное описание в структуру.
• Гибкость важнее предсказуемости. Задачи, где правила пришлось бы переписывать каждую неделю под новые формулировки.

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

Короткий тест перед началом

Четыре вопроса, которые стоит задать до выбора инструмента:

1. Можно ли перечислить все допустимые ответы? Если да — вероятно, модель не нужна.
2. В чём природа шума — опечатки и сокращения или разные способы выразить одну мысль? Первое лечится нормализацией.
3. Что произойдёт, если система ответит по-разному на один и тот же вход дважды? Если это проблема — арифметику и решения нужно забирать в код.
4. Сколько будет стоить каждый вызов при вашем реальном объёме? Иногда ответ закрывает вопрос сам.

Разметочная выборка, кстати, тоже аргумент. В проекте с должностями обучаемую модель отклонили по арифметике: размеченных строк было 50 при 56 классах — обучение почти гарантированно переобучилось бы и потеряло редкие классы. Это стоило одного вечера подсчётов и сэкономило недели работы в неверную сторону.

Как мы это делали

• Классификатор должностей: 1С-выгрузки в справочник — нормализация, нечёткое сопоставление, калибровка уверенности. 277 записей из 300 приняты автоматически, 23 ушли на проверку человеку. Без LLM, эмбеддингов и внешних API. Код открыт.
• Автораспределение обращений: mini-CRM для операторов — веса компетентности и лимит нагрузки вместо модели. Код открыт.
• AI-анализ договоров — пример разделения труда: сверка с шаблоном детерминированная, разметка риска модельная.

Если не уверены, нужна ли под вашу задачу модель, — обсудим за 30 минут. Ответ «не нужна» тоже бывает результатом.