Четыре слова приносят на встречах больше всего вреда: ассистент, RAG, text2SQL, агент. Их употребляют как синонимы, как моду и как способ успокоить заказчика. Это разные ответы на разные вопросы — с разной стоимостью, разными требованиями к данным и разными способами не взлететь. Пятый класс, workflow, не путают ни с чем: его просто редко предлагают. А оказывается им изрядная часть того, что приносят на встречу под словом «агент». Он появляется в 5.4 и стоит одним из пяти исходов в вопросах, которыми глава заканчивается.
Ошибка здесь стоит не репутации, а месяцев. Разница между проектом, который сдают за шесть недель, и проектом, который тихо сворачивают через год, часто ровно в том, что команда построила поиск по документам для вопроса, ответ на который всегда лежал в базе.
Дальше — сами различия и вопросы, которые вытаскивают их на встрече.
5.1 Ассистенты
Ассистент делает что-то для человека, а человек решает, что с этим делать. Он ищет, пишет черновик, сравнивает, объясняет, вытаскивает главное. Он не действует.
Последняя фраза и есть определение. Не модель под капотом, не число подключённых систем, не то, как выглядит интерфейс. Если результат читает человек и он же решает, отправлять, подписывать, платить или удалять, — перед вами ассистент.
ChatGPT, Claude и помощники в духе Copilot, встроенные в редакторы и среды разработки, — всё это один и тот же класс, и это стоит проговаривать вслух. Когда заказчик говорит «мы уже пользуемся ChatGPT, нам нужно что-то посерьёзнее», он почти всегда имеет в виду тот же класс инструмента, но направленный на его собственные данные. Это следующая глава, а не другой уровень амбиций.
С этого класса стоит начинать почти всем, и именно его стесняются предлагать: звучит недостаточно амбициозно. При этом отдача здесь самая быстрая. Ассистент, который экономит юристу сорок минут на первом черновике, окупается задолго до того, как в компании договорятся, что вообще считать автономностью в регулируемом контуре.
Рабочий вопрос на встрече: кто читает результат до того, как что-то произойдёт? Если ответ «человек, всегда» — агента можно не искать.
5.2 RAG
RAG отвечает на вопросы, ответы на которые где-то записаны: в регламентах, договорах, инструкциях, обращениях, на страницах вики, в прошлых проектах.
Механика простая, и её полезно уметь нарисовать от руки:
- Приходит вопрос
- Система находит подходящие фрагменты
- Фрагменты попадают в запрос к модели
- Модель отвечает и ссылается на них
Ценность — в шаге поиска. Всё, что RAG «знает», ему передали в момент вопроса. Ничего не запомнилось.
Это важно не технически, а коммерчески. Раз ничего не заучивается, удаление документа из индекса убирает его из ответов сразу. Разграничение доступа, актуальность, исправления — всё это настройка, а не проект переобучения с отдельной строкой в смете. Когда заказчик говорит «и тогда модель выучит наши договоры», он описывает то, чего не происходит, и поправить это лучше сразу и мягко.
Ломается RAG буднично: документы противоречат друг другу, индекс никто не обновляет, а ответ формально подтверждён найденным фрагментом, который сам устарел два года назад.
5.3 Text2SQL
Text2SQL превращает вопрос на человеческом языке в запрос к базе. «Какая выручка по филиалам Северо-Запада за прошлый квартал в разрезе категорий» — это не вопрос к документам. Ни в одном тексте этого числа нет, пока его кто-нибудь не посчитает.
Путаница между ними — самая частая ошибка класса решения, и она дорогая в обе стороны. Построите поиск по документам для управленческого вопроса — получите систему, которая цитирует методику расчёта показателя вместо самого показателя. Построите text2SQL для вопроса про регламент — получите систему, которая не отвечает ни на что, чего нет в колонках.
Где text2SQL ломается, полезно знать до того, как вы его пообещали. Ему нужна схема, которую человек способен объяснить: осмысленные имена таблиц, описанные колонки и договорённость о том, что считать активным клиентом. На хранилище, которое росло само по себе, с шестью полями дат и без описаний, сгенерированный запрос будет уверенно неверным, а не явно сломанным.
Отдельный вопрос на discovery — есть ли витрины. Если аналитики компании считают выручку джойном на семь таблиц с оговорками, которые держат в голове, то и модель будет считать её как получится. Там, где витрины уже собраны и согласованы, text2SQL заводится быстро; там, где их нет, проект начинается не с модели, а с работы дата-инженеров, и сроки в коммерческом предложении должны это отражать. И у полученного числа нет предупреждающей наклейки: оно выглядит одинаково авторитетно и когда джойн был правильный, и когда нет. Любое внедрение, из которого числа уходят в отчётность, требует шага проверки и возможности увидеть сам запрос.
5.4 Агенты
Агент сам выбирает следующий шаг и действует в других системах. Смысл именно в выборе. Обращение, которое может потребовать CRM, биллинг, обе системы или ни одной — в зависимости от того, что написал клиент, — устроено по-агентски, потому что маршрут заранее не нарисовать.
- Пришло письмо
- Проверить CRM
- Создать задачу
- Отправить ответ
Нарисуйте эту цепочку заказчику и задайте один вопрос: каждое ли обращение проходит ровно эти шаги ровно в этом порядке? Если да — это workflow: дешевле, быстрее, тестируется и скучен ровно так, как и положено промышленной системе. Если маршрут действительно зависит от содержания обращения — агент оправдан.
Мультиагентные схемы — исследователь, автор, критик, координатор — это вариант, а не следующая ступень эволюции. Каждый дополнительный агент умножает стоимость, задержку и число способов сломаться. Бремя доказательства лежит на дополнительных агентах, а не на том, кто сомневается.
5.5 Когда агент не нужен
Эта глава зарабатывает вам доверие на встрече быстрее остальных. Десять случаев, где агент — усложнение без выгоды:
- Фиксированные шаги в фиксированном порядке. Счёт разобрать, проверить, разложить. Это workflow с триггером.
- Отчёт по расписанию. Три запроса утром в понедельник — это задание планировщика, а не тот, кто принимает решения.
- Один инструмент, один вызов. Если система только что-то находит, это tool calling внутри ассистента.
- Онбординг. Приветственное письмо и три задачи не меняются от сотрудника к сотруднику.
- Форма, которая могла остаться формой. Если поля известны, соберите их формой, а не диалогом.
- Поиск, переодетый в автономность. «Агент найдёт нужный документ» — это RAG с лишними шагами.
- Мультиагент там, где хватит одного. Пять специализированных агентов на ответ в поддержку — обычно поиск плюс один шаг формулирования.
- Действия, которые нельзя автоматизировать. Там, где каждое действие всё равно согласуют, автономность агента декоративна. Часто это «агенту не дадут таких прав», сказанное другими словами.
- Процессы, которые никто не описал. Если заказчик не может перечислить шаги, автоматизировать пока нечего. Сначала discovery.
- Объёмы, которые не окупают. Двадцать обращений в месяц редко возвращают стоимость мониторинга, который агенту нужен.
Ничто из этого не аргумент против агентов. Это аргументы за то, чтобы тратить деньги заказчика там, где они возвращаются.
Как определиться на встрече
Четыре вопроса в этом порядке классифицируют почти любой запрос ещё до разговора о технологиях:
- Действует человек или система? Человек — ассистент. Система — идём дальше.
- Ответ в документах или в базе? В документах — RAG. Числа и агрегаты — text2SQL.
- Шаги всегда одинаковые? Всегда — workflow. Зависит от запроса — агент.
- А заказчику вообще разрешат дать системе действовать? Если нет, вы проектируете ассистента, как бы его ни называли в презентации.