Содержание
Коротко
Один запрос к большой языковой модели кажется дешевле цепочки из пяти или десяти. Но для поддержки и внутренних баз знаний важна не цена отдельного вызова LLM, а цена решённого обращения: с уточнениями пользователя, потерянным временем и подключением специалиста.
Автор разбирает пример, в котором агент ИИ делает несколько самостоятельных шагов поиска и всё же оказывается выгоднее простого RAG. RAG — это подход, при котором модель получает найденные фрагменты базы знаний перед подготовкой ответа.
Что произошло
Простой ассистент обычно работает по прямой схеме: превращает вопрос в векторное представление, ищет подходящие фрагменты и просит LLM составить ответ. Такой путь хорош, когда решение лежит в одном документе. Но сложный вопрос часто требует сопоставить заметки о версии, инструкцию по переносу настроек и точный текст ошибки.
Если первый ответ оказался неполным, работу начинает делать человек: уточняет запрос, переформулирует симптом и снова ждёт результат. После нескольких неудачных попыток обращение попадает оператору. Формально каждый вызов модели был недорогим, но задача всё это время оставалась открытой.
В описанном проекте агент действует иначе. Он сам выбирает следующий способ поиска: сначала ищет по смыслу, затем проверяет точный термин, открывает найденный фрагмент документа и только потом формирует ответ со ссылками. Вызовов LLM становится больше, зато пользователю не приходится направлять поиск своими уточнениями.
Почему это важно
Автор предлагает считать полную стоимость закрытого вопроса. В неё входят токены, время пользователя, доля обращений к оператору и время специалиста. При таком подсчёте дополнительные обращения модели могут быть оправданы, если агент заметно реже передаёт задачу человеку.
Показательный сценарий связан с ошибкой после обновления продукта. Обычный ассистент несколько раз предлагает проверить общие настройки почты и лишь после уточнений находит переименованное поле. Агент сначала замечает связь с заметками релиза, открывает их, ищет новое имя поля и находит инструкцию по обновлению соответствий.
Это не означает, что многошаговый поиск нужно включать всегда. На вопрос вроде «какой порт использует сервис» прямой ответ будет быстрее и дешевле. Агент приносит пользу там, где ответ собирается из нескольких источников или требует проверить несколько правдоподобных причин.
На практике
Для подобной системы важен не только набор инструментов поиска, но и ограничения. Агенту нужно вовремя завершать бесплодные попытки, сохранять исходный вопрос и не раздувать контекст результатами каждого шага. В материале автор отказался от постоянного сжатия истории моделью: оно добавляло расходы и иногда выбрасывало важные детали.
Вместо этого используется скользящее окно: системная инструкция и последние сообщения остаются, а старые результаты поиска удаляются после достижения лимита. Сжатие истории остаётся резервным механизмом с ограничением на число применений. Это грубее, но предсказуемее для реальной поддержки.
- Разделите точный поиск и поиск по смыслу: код ошибки и название поля удобнее искать по строке, а общую проблему — по семантической близости.
- Назначайте разные классы моделей для лёгких шагов, итогового ответа и построения векторных представлений.
- Записывайте по каждому обращению число вызовов, токены, результаты инструментов, время до ответа и передачу оператору.
- Проверяйте отдельно простые, сложные и неопределённые вопросы: один режим не обязан быть лучшим для всех случаев.
- Оценивайте качество по доле решённых с первого ответа обращений, а не по числу вызовов модели.
Итог
Агент ИИ не отменяет простые RAG-ассистенты. Для коротких справочных запросов дополнительное рассуждение только увеличит задержку и расход токенов. Также он не спасёт пустую или устаревшую базу знаний: несколько попыток поиска не создадут отсутствующую информацию.
Но в поддержке, где пользователи приходят с составными симптомами, цена одного ответа — плохая метрика. Если система самостоятельно находит причину, инструкцию и подтверждающие документы, она экономит не только токены, но и время пользователей с операторами. Сравнивать такие решения стоит по стоимости закрытого обращения и по фактической доле решённых задач.