Что происходит между запросом пользователя и ответом AI-агента
Пользователь печатает «где мой заказ» и через три секунды читает ответ. Между этими точками — конвейер из десятка шагов: нормализация, планирование, поиск по базе знаний, вызовы инструментов, валидация. Понимание этого конвейера отличает агента, который работает в проде, от демо, которое работает на записи.
Агентный интерфейс обманчиво прост: строка ввода, три секунды ожидания, готовый ответ. На самом деле между вопросом и ответом агент успевает построить план, найти документы, сходить в пару сервисов и проверить сам себя. Каждый шаг этого конвейера — точка, где система может потерять качество, деньги или пользовательское доверие. Разберём полный цикл по шагам на примере агентной поддержки: пользователь спрашивает о статусе заказа, и агент обязан ответить точно, без галлюцинаций.
Нумеруем шаги в порядке выполнения — на практике некоторые идут параллельно, но для разбора удобна линейная картина. Обратите внимание: модель принимает решения лишь на части шагов. Половину конвейера составляет обычный инженерный код, и это осознанный выбор, а не недоработка.
01Нормализация запроса. Сырой текст приводится к рабочему виду: исправляются очевидные опечатки, разворачиваются сокращения, из «а где мой заказ №4712??» остаётся «статус заказа 4712». Это делает не модель, а обычный код — дешевле, быстрее и предсказуемее.
02Классификация намерения. Малая модель или регэксп определяет тип запроса: статус заказа, возврат, консультация. От класса зависит, какие инструменты доступны агенту и какой системный промпт используется. Ошибка классификации здесь потом аукнется на каждом следующем шаге.
03Планирование. Агент строит план: нужен номер заказа, значит — сначала поиск клиента, затем обращение к сервису заказов, затем сверка сроков доставки. На этом шаге модель решает, что делать, ещё не видя данных, и от качества плана зависит всё остальное.
04Поиск по базе знаний. Параллельно с планом работает ретривал: запрос превращается в лексемы и векторы, BM25 и семантический поиск отбирают кандидатов, реранкер оставляет лучшие. Детали и метрики этого шага мы разбирали в кейсе о переписывании ретривала .
05Сборка контекста. Результаты поиска, данные из инструментов, история диалога и системный промпт складываются в единое окно. Здесь живёт главное искусство агентной инженерии: уложиться в контекст, не выбросив важного и не притащив лишнего.
06Первый вызов модели. Модель читает контекст и решает: ответить сразу или запросить инструмент. В нашем примере — вызвать get_order(4712) . Формат вызова задан JSON-схемой, и валидация строга по схеме: что не влезло в схему, то не вызов, а ошибка формата.
07Вызов инструментов. Инфраструктура исполняет запрос к сервису заказов. Каждый вызов обёрнут в таймаут, ретраи и логирование: инструменты падают чаще, чем модели, и падают менее предсказуемо.
08Второй проход модели. Модель получает результат инструмента и либо продолжает план — запросить сроки доставки, сверить склад, — либо переходит к ответу. Средний агентный диалог — это три-пять таких циклов, и каждый стоит токенов и миллисекунд.
09Валидация. Ответ проверяется до показа: у всех ли утверждений есть источник в контексте, нет ли обещаний, которых агент не вправе давать, — компенсаций, юридических оценок, — не утекли ли внутренние детали. Проверку делят правила и вторая модель-критик.
10Генерация финального ответа. Тон задаётся промптом, формат — шаблоном: статус, срок, что делать дальше. Ответ стримится пользователю, пока валидационные правила уже отработали в фоне.
11Телеметрия. Каждый шаг конвейера пишет метрики: задержку по шагам, стоимость в токенах, долю циклов с инструментами, долю отказов валидации. Без телеметрии агент — чёрный ящик, который деградирует незаметно.
Весь цикл на простом запросе укладывается в две-три секунды, из которых модель «думает» меньше половины времени. Остальное — поиск, инструменты и транспорт. Практический вывод: оптимизировать стоит сначала конвейер, а не промпт. Сокращение ретривала на четыреста миллисекунд пользователь заметит, а вот переписывание системного промпта — почти никогда.
Стоимость конвейера считают в трёх валютах: времени, деньгах и риске. Время сконцентрировано в ретривале и вызовах инструментов — модель отвечает за десятые доли секунды, а внешние системы за сотые доли минут. Деньги размазаны по вызовам модели: каждый цикл «инструмент — модель» повторно отправляет накопленный контекст, и к третьему циклу счётчик токенов растёт квадратично. Риск накапливается в двух местах — в ретривале, который может не найти нужное, и в валидации, которая может пропустить плохое.
Отсюда практическое правило дизайна конвейера: дешёвые шаги — вперёд, дорогие — за фильтрами. Классификация почти бесплатна и отсекает треть запросов от тяжёлого пути. Кэш ответов на повторяющиеся вопросы экономит больше, чем любая оптимизация промптов. А ограничение глубины циклов «инструмент — модель» спасает и от бесконечных диалогов агента с самим собой, и от внезапных счетов.
Первое место стабильно держит ретривал: агент формально всё сделал верно, но нужный документ в контекст не попал — и модель честно выдумала ответ на пустоте. Пользователь видит уверенный текст, не подозревая, что под ним ничего нет. Второе место — инструменты: таймауты, изменения контрактов, рассинхронизация между сервисами. Третье — дрейф формулировок: промпт, стабильный на пятистах примерах, ведёт себя иначе на пятистах тысячах, и это обнаруживается только телеметрией.
Выбор модели под каждый шаг — отдельная дисциплина. Классификацию и валидацию тянет компактная модель, планирование требует более крупной, а служебные шаги можно вообще увести на локальный инференс и сократить счёт за токены вдвое. О раскладке по размерам и ценах мы писали в материале о локальных языковых моделях .
Именно поэтому агентные системы проектируют как распределённые: с таймаутами на каждом шаге, с идемпотентными инструментами, с наблюдаемостью на уровне всего конвейера, а не только модели. Продукт, в котором агент «просто вызывает GPT», не переживёт первый месяц реального трафика. Продукт, в котором конвейер спроектирован честно, переживёт и смену модели, и рост в десять раз — заменой одного шага, а не переписыванием всего.
