Ассистент, а не агент: как спроектировать предсказуемую LLM-систему

Введение: почему «агентный» подход может навредить вашему проекту

В последние годы рынок LLM-систем переживает настоящий бум: от простых чат-ботов до сложных мультиагентных архитектур. Однако, как показывает практика, стремление сделать каждую модель «агентом», способным самостоятельно принимать решения, часто оборачивается непредсказуемостью и потерей контроля. В недавней статье на Habr (источник: Ассистент, а не агент: как спроектировать предсказуемую LLM-систему) подробно разбирается, почему во многих коммерческих и промышленных сценариях стоит отдавать предпочтение ассистентам — системам с чётко заданными рамками поведения, а не автономным агентам.

Проблема агентов в том, что они часто пытаются «угадать» намерение пользователя, выполнять действия без явного подтверждения или менять план на ходу. Это может быть полезно в исследовательских проектах, но критично в production-среде, где нужна воспроизводимость и предсказуемость. Авторы статьи утверждают: грамотно спроектированный ассистент, который работает в строго определённом контексте, даёт более стабильные результаты и проще в отладке.

Чем отличается ассистент от агента: ключевые критерии

Чтобы разобраться в различиях, рассмотрим основные характеристики:

В статье подчёркивается, что для большинства бизнес-задач (например, обработка заказов, ответы на типовые вопросы, генерация отчётов) ассистентный подход оказывается более надёжным. Агенты же оправданы только в случаях, когда система должна адаптироваться к неизвестным заранее сценариям.

Как спроектировать предсказуемую LLM-систему: пошаговый гайд

Шаг 1. Определите границы ответственности

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

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

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

Шаг 2. Используйте строгую схему вывода (Structured Output)

Чтобы избежать неформатированных ответов, применяйте механизмы принудительной генерации в заданном формате. Например, используйте response_format в API OpenAI или json_mode в других моделях. Это гарантирует, что выходные данные будут парситься без ошибок.

Пример запроса с JSON-схемой:

{
  "type": "object",
  "properties": {
    "answer": {"type": "string"},
    "confidence": {"type": "number", "minimum": 0, "maximum": 1},
    "suggestions": {"type": "array", "items": {"type": "string"}}
  },
  "required": ["answer", "confidence"]
}

Шаг 3. Внедрите систему подтверждений (Confirmation Gates)

Для критически важных действий (например, списание средств, отправка email) обязательно добавляйте шаг подтверждения. Ассистент не должен выполнять действие сразу — сначала он должен запросить разрешение у пользователя. Это снижает риск ошибок и повышает доверие.

Шаг 4. Ограничьте количество шагов в диалоге

Чтобы избежать «ухода в бесконечный диалог», задайте максимальное количество итераций (например, не более 5 обменов). После этого система должна либо завершить разговор, либо передать его человеку. Это особенно важно для ассистентов в чатах, где пользователь может начать задавать нерелевантные вопросы.

Шаг 5. Добавьте мониторинг и логирование

Даже самая предсказуемая система может дать сбой. В статье рекомендуется логировать каждый запрос и ответ, а также метрики: время ответа, уверенность модели, количество отказов. Эти данные помогут быстро выявить аномалии и доработать промпты.

Практический пример: ассистент для обработки заказов

Рассмотрим гипотетический кейс: компания внедряет LLM-ассистента для обработки заказов в интернет-магазине. Если бы это был агент, он мог бы:
- Самостоятельно изменять статус заказа;
- Отменять заказы без подтверждения;
- Предлагать скидки, не предусмотренные правилами.

Вместо этого разработчики спроектировали ассистента с жёстким сценарием:
1. Ассистент принимает запрос (например, «Изменить адрес доставки»).
2. Проверяет, есть ли у пользователя активный заказ.
3. Если да — запрашивает новый адрес и подтверждение.
4. После подтверждения генерирует команду для системы (например, POST-запрос к API).

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

Когда агент всё-таки нужен?

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

Однако для production-систем, где важна стабильность, рекомендуется начинать с ассистента и добавлять агентные элементы только при необходимости.

Выводы

Главный урок из статьи: не стоит гнаться за модным словом «агент». Для большинства бизнес-задач предсказуемый ассистент с чёткими границами работает эффективнее и безопаснее. Проектируя LLM-систему, определяйте её поведение на уровне правил, а не на уровне «самообучения». Это сэкономит время на отладку и повысит доверие пользователей.

Если вы хотите глубже изучить, как интегрировать такие ассистенты в свои бизнес-процессы, обратите внимание на платформу ASI Biont, которая поддерживает подключение к различным сервисам через API — подробнее на asibiont.com/courses. Там вы найдёте примеры архитектур и готовые шаблоны для быстрого старта.