RAG-агент — это тот же поиск по базе знаний, но с правом сделать несколько шагов: переформулировать вопрос и поискать ещё раз, заглянуть в учётную систему за текущими данными, задать уточняющий вопрос, передать дело человеку. Обычный RAG делает один шаг: нашёл подходящие куски документов, отдал модели, получил ответ.
Разница нужна не всем. Каждый лишний шаг — это лишние секунды ожидания и лишние деньги за обращение, поэтому агентные шаги имеет смысл включать точечно, а не везде.
Суть: один шаг против нескольких #
Обычная схема линейная и жёстко заданная: вопрос — поиск — найденные фрагменты — модель — ответ. Маршрут один, и если поиск принёс не то, ответ будет построен на «не том». Модель при этом не знает, что ей дали неподходящий документ, и отвечает так же уверенно, как если бы дали нужный.
У агента вместо маршрута набор инструментов: поиск по базе, запрос в учётную систему, уточняющий вопрос сотруднику, передача человеку. После каждого шага он смотрит на результат и решает, чего не хватает. Решение «что делать дальше» принимает модель, а не заранее написанный сценарий — в этом и смысл слова «агент».
Сама идея подхода разобрана в статье что такое RAG, а устройство по частям — в статье про RAG-систему. Здесь речь только про разницу между «один поиск» и «несколько шагов».
Вопрос возникает потому, что агентов сейчас активно продают, и со стороны кажется, будто это следующая версия, которую надо брать всем. Это не так. Агент — не улучшенный RAG, а другой режим работы: медленнее, дороже за ответ, труднее в отладке. Выигрыш он даёт на вполне определённых вопросах. Дальше — на каких.
Разбор: где одного поиска не хватает #
Вопрос составной #
«Можно ли вернуть товар, купленный в рассрочку, после трёх месяцев?»
Для поиска это одна фраза. По сути вопросов три, и ответы лежат в разных документах:
- правила возврата — какой срок и для какой категории товара;
- договор рассрочки — что происходит с оставшимися платежами при возврате;
- регламент по технически сложным товарам — считаются ли три месяца гарантийным случаем.
Один поиск вытащит фрагменты, похожие на фразу целиком. Скорее всего, это будут правила возврата: слово «вернуть» встречается там чаще всего. Модель получит один документ из трёх и ответит наполовину — а наполовину верный ответ хуже отказа, потому что сотрудник передаст его заказчику как позицию компании.
Агент разбирает вопрос на части: ищет про срок возврата, отдельно про рассрочку, отдельно про категорию товара. Потом складывает найденное и отвечает. Или сообщает, что в договоре рассрочки такой случай не описан, — и это тоже рабочий ответ, с ним можно идти к юристу.
Признак составного вопроса простой: в нём два-три условия сразу. «После трёх месяцев», «в рассрочку», «со скидкой», «для юрлица», «по второму договору».
Ответ зависит от текущих данных #
В документах написано правило, а не значение. «Отгрузка возможна при наличии остатка на складе и неотрицательном балансе заказчика» — это правило. Отвечать им на вопрос «можно ли отгрузить 200 упаковок в Казань на этой неделе» бессмысленно: ответ зависит от остатка, баланса и очереди отгрузок, то есть от того, что лежит в учётной системе прямо сейчас.
Улучшать здесь поиск бесполезно — нужных чисел в базе знаний нет и быть не должно. Нужен второй шаг: запрос в систему. Агент читает правило, понимает, какие данные ему нужны, запрашивает их и собирает ответ из правила и факта.
Это самый частый повод завести агента в корпоративной базе знаний: статус заказа, остаток, баланс, срок действия договора, этап согласования. Какие данные реально удаётся достать из учётной системы и что из этого стоит работы, разобрано в статье про ИИ в 1С.
Вопрос задан не теми словами #
Сотрудник пишет: «Мне не пришла премия за октябрь». В документах — «Порядок начисления стимулирующих выплат». Общих слов нет ни одного.
Часть разрыва закрывает поиск по смыслу: он находит документ по близости значения, а не по совпадению слов. Как это работает, разобрано в статье про векторную базу и семантический поиск. Но у него есть предел. Внутренняя терминология компании — «форма 7», «реестр Р-2», «служебка по М-11» — живёт только в её документах, и привычная сотруднику формулировка может не иметь с ней ничего общего.
Агент добавляет сюда один простой приём: смотрит на слабый результат и пробует снова, другими словами. Увидел в первой выдаче слово «стимулирующие» — ищет по нему. Наткнулся на название формы — ищет по названию. Человек в незнакомом справочнике поступает так же: по подсказкам из первой попытки. У обычного RAG попытка одна.
Два шага, которые забывают считать шагами #
Кроме поиска у агента есть ещё два действия, и оба дешёвые.
Уточняющий вопрос. «Сколько у меня осталось дней отпуска» — на это нельзя ответить, не зная, о каком отпуске речь и за какой период. Агент спрашивает вместо того, чтобы отвечать средним по компании.
Передача человеку. Когда ответа в документах нет, правильный ход — не пятая попытка поиска, а передать вопрос живому сотруднику вместе с историей разговора. Это общая логика для любого ассистента, не только агентного.
Оба шага выглядят как признание бессилия, а на практике именно они держат доверие к ассистенту. Ассистент, который переспрашивает и честно сдаётся, используется дальше. Тот, который всегда отвечает, перестаёт использоваться после первого случая, когда ответ оказался выдумкой.
Как это устроено у нас #
Поиск гибридный — по смыслу и по словам одновременно. Это не агентность, это устройство базы, и оно снимает часть случаев «не теми словами» ещё до того, как понадобятся лишние шаги. Дешёвый поиск лучше дорогого агента там, где он справляется.
Модель выбирается цепочкой: GigaChat, YandexGPT, зарубежная через ProxyAPI, модель внутри сети компании. Если одна не ответила, запрос идёт дальше. Для многошаговой работы это важнее, чем для одношаговой: цепочка из четырёх шагов рвётся целиком, если модель не ответила на третьем.
Перед выдачей ответ проверяется. Выдуманная ссылка правится, а не выбрасывает весь ответ. У каждого ответа есть ссылка на документ-источник — сотрудник видит, откуда он взялся, и может проверить сам.
Чего нет в документах, ассистент не придумывает, а передаёт человеку. Это правило не отключается ни в одном режиме.
Данные из учётных систем — на внедрении: 1С, Битрикс24, Диадок. На пилоте мы обычно остаёмся в документах. Сначала надо убедиться, что база отвечает на вопросы отдела, и только потом подключать системы: если документы не в порядке, доступ к данным ничего не спасёт.
Серверы в России, персональные данные обезличиваются до отправки в модель. Чем больше шагов, тем больше раз текст уходит в модель, так что это не формальность.
Строки «агент» в прайсе у нас нет. Число шагов — часть настройки сценария: часть тем закрывается одним поиском, часть требует обращения в систему. Что именно к чему относится, видно по списку вопросов отдела, который мы собираем на аудите. Сама услуга описана на странице корпоративной базы знаний.
Сколько стоит и от чего зависит #
Цены на 23 октября 2026 года.
| Что | Стоимость | Срок |
|---|---|---|
| Аудит: карта документов, с какого отдела начать, оценка | Бесплатно | 30 минут |
| Пилот: один отдел, до 300 документов, проверка на 40 вопросах | от 150 000 ₽ | 3–4 недели |
| Внедрение: несколько отделов, права доступа, автообновление, 1С, Битрикс24, Диадок | от 500 000 ₽ | 6–10 недель |
| Сопровождение после запуска | от 40 000 ₽ в месяц | — |
| Платформа по подписке, если проект велик | от 7 000 ₽ в месяц плюс настройка от 15 000 ₽ | запуск 3–10 дней |
Отдельной цены у агентных шагов нет — они входят в работу по внедрению. Но у них есть цена в эксплуатации, и про неё честно.
Время. Ответ в один поиск складывается за секунды. Цепочка из трёх-четырёх шагов занимает примерно во столько же раз больше: сотрудник ждёт, пока агент сходит в базу, переформулирует вопрос, запросит данные и соберёт ответ. На вопросе «где лежит регламент по командировкам» такая задержка раздражает, а выгоды не даёт.
Деньги. Работа моделей оплачивается по объёму текста, и каждый шаг тащит с собой свой контекст: вопрос, найденное на прошлых шагах, результат запроса. Три шага — это не три коротких обращения, а три всё более длинных. В пересчёте на обращение разница заметная.
Отсюда практическое правило: агентные шаги включают на темах, где одного поиска заведомо мало — составные вопросы, вопросы про текущие данные, разрыв в терминологии. Остальное остаётся на обычном поиске. Если все вопросы отдела звучат как «какой срок согласования счёта», агент не нужен: он даст те же ответы медленнее и дороже.
Где это не работает #
Данных нет или они устарели. Если остатки ведутся в таблице, которую обновляют руками раз в неделю, агент будет уверенно отвечать по позавчерашним числам. Здесь проблема не в ассистенте, и решать её надо не им.
Нет доступа к системе. Старая конфигурация, из которой нельзя получить данные запросом, — обычное дело. Тогда остаются документы, то есть обычный поиск без агентных шагов.
Права доступа. Ассистент, который ходит по учётным системам, должен видеть ровно то, что видит сам сотрудник. Иначе он становится удобным способом узнать чужую зарплату или условия чужого договора. Это настраивается на внедрении и занимает время — на пилоте одного отдела такой задачи обычно нет.
Запись данных. Читать безопасно, писать — нет. Создать заявку, изменить заказ, провести документ: ошибка здесь стоит дороже, чем неудачный ответ, и такие действия мы оставляем с подтверждением человеком. Что ИИ-агенты вообще берут на себя, а чего им доверять рано, разобрано в статье про ИИ-агентов для бизнеса.
Долгие цепочки. Чем больше шагов, тем больше мест, где агент уходит в сторону, и тем труднее понять, почему ответ получился странным. Поэтому число шагов ограничивается, а не оставляется на усмотрение модели.
Противоречия в документах. Если в двух регламентах разные сроки, агент найдёт оба и не выберет правильный — за него это делает человек. Никакая многошаговость не заменяет порядок в документах.
Точность в процентах. Мы её не обещаем, и обещаний от других советуем проверять вопросом «на каком наборе вопросов измеряли». В пилоте проверка идёт на сорока вопросах отдела, составленных до начала работы, и результат по ним видно.
Частые вопросы #
Чем RAG-агент отличается от обычного RAG? #
Числом шагов и тем, кто выбирает следующий. Обычный RAG идёт по одному заранее заданному маршруту: поиск, модель, ответ. Агент после каждого шага решает, чего не хватает, и может поискать ещё раз другими словами, запросить данные из учётной системы, переспросить сотрудника или передать вопрос человеку.
Нам нужен агент или хватит обычного поиска? #
Посмотрите на список реальных вопросов сотрудников. Если это «где лежит инструкция» и «какой порядок согласования» — хватит поиска. Если там регулярно встречаются вопросы с двумя-тремя условиями или вопросы про текущие остатки, статусы и балансы — одного шага мало. Такой список составляется на бесплатном аудите, он же показывает, с какого отдела начинать.
Агент будет сам менять данные в 1С? #
По умолчанию нет. Чтение данных и запись — разные по риску вещи: неудачный ответ можно поправить словами, проведённый документ — нет. Действия, которые меняют данные, делаются только с подтверждением человеком.
Насколько агент медленнее? #
Примерно во столько раз, сколько шагов он делает: каждый шаг — это отдельное обращение к модели со своим ожиданием. Поэтому многошаговый режим включают на отдельных темах, а не на всех вопросах подряд. На простых вопросах это был бы проигрыш и во времени, и в деньгах.
Можно начать с обычного поиска, а шаги добавить потом? #
Так и правильнее. Сначала база, по которой ассистент отвечает сотрудникам одного отдела, потом — подключение учётных систем и многошаговые сценарии на тех темах, где без них видно, что ответов не хватает. Обратный порядок обычно означает, что сложность добавили до того, как разобрались с документами.
Как понять, что агент работает хорошо? #
По доле вопросов, закрытых без человека, и по тому, читают ли сотрудники ссылки на источники. Если ссылки открывают и не возвращаются с жалобой — ответы совпадают с документами. Если доля ответов без человека не растёт, дело почти всегда в документах, а не в числе шагов: агент умеет искать лучше, но не умеет находить то, чего не написано.
