Глава 2. Где LLM уместна, а где вы просто усложняете систему

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

LLM плохо подходит там, где задача уже хорошо решается детерминированным алгоритмом, SQL-запросом, регулярным выражением, правилами или обычной ML-моделью.

Да, это звучит скучно. Но сэкономленные деньги тоже звучат скучно, пока они ваши.

Хорошие задачи для LLM

LLM обычно уместна для:

• классификации естественно-языковых сообщений;
• извлечения структурированных данных из писем, документов, чатов;
• суммаризации длинных материалов;
• генерации черновиков писем, отчётов, описаний;
• переформулирования текста под стиль или аудиторию;
• question answering по базе знаний при наличии retrieval;
• помощи оператору, менеджеру, врачу, юристу или инженеру — но не полной замены ответственности;
• анализа неструктурированных жалоб, отзывов, тикетов;
• генерации кода или SQL в ограниченном и проверяемом контуре;
• работы с инструментами, если каждое действие проверяется и логируется.

Плохие задачи для LLM

LLM почти наверняка не нужна для:

• вычисления скидки;
• проверки формата email;
• выбора тарифа по фиксированным правилам;
• подсчёта суммы заказа;
• простого поиска точного совпадения;
• выполнения юридически значимого решения без человека;
• замены ACL/RBAC;
• хранения фактов;
• принятия финансовых решений без проверки;
• генерации ответа там, где пользователь ожидает точную запись из базы.

Если вы используете модель, чтобы заменить if, проблема не в модели.

Матрица решения

Перед внедрением LLM задайте пять вопросов:

1. Вход действительно неструктурирован?
2. Нужна ли языковая интерпретация?
3. Есть ли допустимый уровень ошибки?
4. Можно ли автоматически проверить результат?
5. Экономика сходится при реальном объёме запросов?

Если хотя бы на три вопроса ответ «нет», остановитесь. Вы не проявляете осторожность. Вы проявляете профессионализм.

Пример ненужной LLM

Задача: определить, просрочен ли счёт.

Плохое решение:

Попросить LLM посмотреть дату счёта и сказать, просрочен ли он.

Хорошее решение:

from datetime import date
 
is_overdue = invoice.due_date < date.today() and not invoice.paid_at

LLM может пригодиться рядом: объяснить пользователю человеческим языком, почему счёт просрочен и что делать дальше. Но сам факт просрочки должна считать обычная программа.

Пример уместной LLM

Задача: пользователь пишет в свободной форме:

Я вроде оплатил вчера, деньги ушли, но в личном кабинете всё равно висит долг. И ещё письмо пришло какое-то странное.

Здесь LLM может:

• определить категорию: billing / payment_status;
• извлечь признаки: «оплата вчера», «деньги списались», «долг отображается», «странное письмо»;
• предложить оператору следующий шаг;
• сформировать черновик ответа.

Но проверять факт оплаты должна не LLM, а платёжная система.

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

Чеклист главы

• Для задачи проверено: вход действительно неструктурирован или языковой.
• Детерминированное решение (правила, SQL, regexp, классический ML) рассмотрено и отвергнуто с причиной, записанной словами.
• Определён допустимый уровень ошибки и что происходит при ошибке.
• Результат можно проверить автоматически или дёшево вручную.
• Экономика посчитана на реальном объёме, а не на демо-нагрузке.
• Источник истины для фактов — не модель.

Практикум

Задача 2.1 — матрица решения на своём бэклоге. ⭑

Возьмите 10 реальных или типовых фич-кандидатов «добавим сюда AI» (например: автоответ в поддержке, проверка орфографии в форме, определение спама, рекомендация тарифа, поиск по базе знаний, генерация отчёта, валидация ИНН, сортировка заявок по срочности, перевод интерфейса, «умный» поиск по каталогу). Прогоните каждую через пять вопросов матрицы решения.

Критерии приёмки:

• По каждой фиче — ответы на все пять вопросов и вердикт: LLM / детерминированное решение / гибрид.
• Минимум три фичи получили вердикт «LLM не нужна» с конкретной заменой (какое правило, какой запрос).
• Для каждого «гибрида» указана граница: что делает модель, что делает код.

Подсказки:

1. Если вердикт «LLM» получили все десять — вы отвечали на вопросы формально. Валидация ИНН и рекомендация тарифа по анкете — не языковые задачи.
2. Самый частый правильный ответ в реальных системах — гибрид: модель интерпретирует, код решает.

Задача 2.2 — гибридный разбор обращения. ⭑⭑

Реализуйте обработчик сообщения из примера главы («я вроде оплатил, а долг висит»): модель извлекает категорию и признаки в структурированный объект, а решение «есть ли оплата на самом деле» принимает детерминированная функция-заглушка check_payment_status(user_id). Ответ пользователю собирается из результата проверки, а не из текста модели.

Критерии приёмки:

• Модель ни в одном месте не «утверждает» статус платежа — только интерпретирует жалобу.
• Если check_payment_status говорит «оплата есть», а модель извлекла «пользователь не платил», побеждает источник истины, и это покрыто тестом.
• Из кода очевидна граница: где кончается интерпретация и начинается бизнес-логика.

Подсказки:

1. Хороший тест на границу: замените LLM на функцию, возвращающую случайную категорию. Деньги пользователя от этого пострадать не должны.