Rule-based или LLM-агенты: где заканчивается if-else

Rule-based движок обрабатывает 10 000 обращений на одном ядре с латентностью в единицы миллисекунд и стоит ноль за вызов. LLM-агент на GPT-4-класса модели тратит на то же обращение секунды, сотни-тысячи токенов и деньги за каждый запрос — но справляется с формулировками, которых вы не предусмотрели. Выбор между ними — не вопрос моды, а вопрос того, сколько стоит ошибка и сколько стоит вызов.

Что стоит за терминами

Rule-based система — это набор явных правил вида условие → действие. Дерево решений, движок продукционных правил, конечный автомат, регулярные выражения, каскад if-else. Всё поведение задано разработчиком заранее и воспроизводимо: одинаковый вход всегда даёт одинаковый выход.

LLM-агент — это большая языковая модель, которая получает задачу на естественном языке, сама решает, какие шаги предпринять, и вызывает внешние функции¹ (поиск, вычисления, обращения к API), пока не сочтёт задачу выполненной. Поведение не прописано жёстко: модель интерпретирует инструкцию и контекст.

¹ Function calling / tool use

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

Три оси сравнения, которые решают всё

Спор «правила против агента» сводится к трём измеримым характеристикам: предсказуемость, стоимость вызова и способность обрабатывать неизвестные входы. Всё остальное — производные.

Правила отказывают там, где вы их не написали. Агент отвечает там, где вы его не спрашивали. Первое — тихий провал, второе — громкий, и это разные типы риска.

Когда выбирать правила

Rule-based выигрывает не потому что «проще», а потому что дешевле и предсказуемее в задачах с ограниченным пространством входов.

• Регуляторика и деньги. Расчёт скидки, начисление бонусов, проверка лимита по кредиту. Ошибка стоит денег, а решение обязано быть объяснимым для аудита.
• Высокая частота, низкая маржа на вызов. Миллион событий в час — платить за токены каждого нереально.
• Жёсткие SLA по латентности. Антифрод в момент оплаты, маршрутизация в реальном времени.
• Узкое, стабильное пространство входов. Валидация формата email, разбор фиксированного протокола, статусная машина заказа.

Если вы можете перечислить все ветки на бумаге за разумное время — вам не нужен LLM.

Когда выбирать LLM-агента

Агент оправдан там, где вход неструктурирован, вариативность высока, а формализовать все случаи заранее дороже, чем терпеть вероятностные ошибки.

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

Цена вопроса: за гибкость вы платите непредсказуемостью и деньгами за каждый вызов. Агент, который в 2% случаев уверенно выдаёт неверный ответ, в задаче про деньги неприемлем, а в черновике письма — терпим.

Гибрид как норма, а не компромисс

На практике продакшн-системы редко чисто rule-based или чисто агентные. Побеждает разделение ролей: правила держат каркас, LLM закрывает вариативность.

1. Правила на входе — фильтр и роутинг. Дешёвые детерминированные проверки отсекают явные случаи и решают, дошло ли вообще до модели.
2. LLM в середине — интерпретация неоднозначного. Модель разбирает то, что правила не смогли классифицировать.
3. Правила на выходе — валидация ответа модели. Проверка схемы, границ значений, запрещённых действий. Агент предлагает — детерминированный слой утверждает.

Ключевая идея: любое действие с необратимыми последствиями — списание денег, отправка клиенту, удаление данных — проходит через детерминированный guardrail², а не остаётся на усмотрение модели.

² Guardrail

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

Минимальный пример гибридной обёртки

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

def handle(request):
    # 1. Детерминированный роутинг
    if request.type in KNOWN_TYPES:
        return rule_engine.process(request)   # быстро, бесплатно

    # 2. Неоднозначный вход отдаём агенту
    result = llm_agent.run(
        task=request.text,
        tools=[search_db, get_order],
    )

    # 3. Guardrail на выходе
    if not schema.validate(result):
        return escalate_to_human(request)
    if result.action in IRREVERSIBLE:
        return require_confirmation(result)
    return result

Обратите внимание: LLM здесь не «главный», а один из исполнителей внутри контролируемого пайплайна. Это снижает и стоимость (модель зовётся не всегда), и риск (её вывод не исполняется вслепую).

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

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

И держите в голове операционную стоимость: rule-based требует людей, которые пишут и поддерживают правила; агент требует людей, которые следят за качеством ответов, версиями модели и дрейфом³ поведения после обновления. Ни один из подходов не бесплатен в эксплуатации.

³ Дрейф поведения

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

Итог простой. Правила — это то, что вы уже знаете и хотите гарантировать. Агент — это то, чего вы заранее не знаете и готовы принять с погрешностью. Хорошая система знает, какая из этих двух ситуаций перед ней в каждый конкретный момент.