В пятой главе было четыре вопроса и пять классов, которые они разводят: ассистент, RAG, text2SQL, workflow, агент. Разобраться постфактум этого хватает, но на встрече время идёт иначе: заказчик формулирует запрос один раз, и заход у вас тоже один. Чего пятая глава не дала — порядка. Какой вопрос задавать первым, какие можно не задавать вовсе, потому что предыдущий ответ их уже снял, и что говорить, когда заказчик спросит, почему выбран этот класс, а не соседний. Здесь есть и то, и другое: те же различия сложены в дерево, которое прогоняют молча, пока заказчик ещё говорит, и к каждому исходу приложен разбор, почему четыре остальных проиграли.
10.1 Дерево
Начните с того, кто отвечает за следующий шаг.
- Приходит запрос
- Результат читает человек — или система действует сама?
- Читает человек
- Действует система
Если результат читает человек, следующий вопрос — тот самый, на котором чаще всего путаются RAG и text2SQL, поэтому его нужно задать первым: ответ уже где-то записан, это число, которое ещё никто не посчитал, или готового ответа вообще нет — нужно что-то создать заново?
- Результат читает человек
- Ответ записан, это число для подсчёта, или его нужно создать с нуля?
- Записан → RAG
- Число из данных → text2SQL
- Нужно создать → ассистент
Если действует система, важен другой вопрос — меняется ли маршрут.
- Система действует сама
- Меняются ли шаги в зависимости от содержания запроса?
- Никогда — workflow
- Зависит от запроса — агент
Три вопроса, пять исходов. Ни один из них не спрашивает, какая модель внутри, как это называет вендор в презентации или со сколькими системами это связано, — это детали реализации, которые обсуждают после того, как класс определён, а не вместо этого. Дерево нарочно короткое: если для ответа нужен четвёртый вопрос, скорее всего, вы уже соскользнули с формы решения на обсуждение конкретного инструмента.
10.2 Что сказать про четыре отвергнутых
Назвать класс — это половина дела. Вторая половина начинается, когда заказчик спрашивает: «а почему не агент?» Отвечать нужно сразу и по каждому из четырёх, которые вы не выбрали. Именно по этому ответу и видно, разбираетесь ли вы в предмете или повторяете слово, прозвучавшее в начале встречи.
RAG. Про text2SQL здесь речи нет: ответ придумал тот, кто писал регламент, а не арифметика по строкам, — считать нечего, суммировать нечего, таблицы с этим ответом попросту не существует. Ассистент без шага поиска отвечает по памяти: спросите модель про срок гарантии, не подложив ей документ, и получите гладкий абзац без единой ссылки вместо честного «в моих данных этого нет». Агент здесь остаётся без работы: как только нужный абзац показан человеку, дело закончено, идти в другие системы не за чем. Workflow тоже не выйдет — вопросы каждый раз новые, закреплять в последовательность нечего.
Text2SQL. RAG искать нечего: цифры нет ни в одном файле, она рождается в момент агрегации, а до этого нигде не лежит. Ассистент опасен именно тем, что не промолчит: на «сколько мы отгрузили в прошлом квартале» он прикинет по обрывкам, которые видит, и назовёт своё число ровно тем же тоном, каким правильный запрос назвал бы настоящее. Агенту тут нечего выбирать — вопрос переводится в один запрос, запрос выполняется, маршрут на этом исчерпан. Workflow нечего закреплять: шаг всего один, и вся сложность в том, чтобы он выдержал любую формулировку вопроса.
Ассистент. С RAG путать не стоит: человеку нужен не найденный кусок текста, а черновик — то, чего до этого разговора не существовало нигде. Text2SQL подменяет результат: из таблицы выходит число, а нужен связный текст, и стоит записать задачу как отчётную, как исчезнет ровно то, ради чего её ставили. Агент здесь преждевременен: решает и отправляет по-прежнему человек, а забрать у него это право — отдельный проект с другими рисками, которого пока никто не заказывал. Workflow не получится по простой причине: повторяется здесь только оболочка задачи, а внутри каждый раз другой договор, другой адресат, другой повод писать.
Агент. Ассистент не вытянет объём: обращений столько или приходят они так часто, что прочитать каждое и решить руками физически невозможно. Workflow сломается на разнообразии: маршрут действительно зависит от содержания, и жёсткая последовательность на части случаев сработает верно, а на остальных уверенно ошибётся. RAG сузит задачу до неузнаваемости: поиск по дороге, скорее всего, будет, но продайте проект как поиск — и на выходе получится система, которая протягивает найденный абзац человеку, а этого человека в схеме и не было. Text2SQL останавливается на полпути: число здесь не результат, а повод что-то сделать, и выдать его и замолчать — значит бросить работу посередине.
Workflow. Агент здесь — переплата: шаги не меняются никогда, а система, которая заново выбирает маршрут на каждом запуске, добавляет задержку, стоимость и ещё один способ сломаться ради выбора, которого не было. Ассистент лишний: последовательность известна, запускать её безопасно, и просматривать каждый запуск глазами незачем. RAG и text2SQL отпадают вдвоём и по одной причине — оба заканчиваются ответом, а вопроса здесь никто не задавал. Результат — это то, что три вещи случились по порядку, и самый точный ответ такого результата не даёт.
10.3 Дерево на шести звонках
Отдел кадров хочет, чтобы новичок в первый день получал один и тот же комплект: анкету, инструктаж по охране труда и заявку на пропуск, а через неделю — напоминание про медосмотр. Система действует сама, и порядок не меняется от того, кого приняли — водителя или аналитика. Workflow.
Менеджер просит набросать письмо клиенту, который третий месяц не отвечает на счета. Читать и править письмо будет человек, но доставать нечего и считать нечего: текста, который подойдёт, пока не существует. Ассистент.
Продавец в зале спрашивает, обязан ли он принять назад вскрытую коробку. Ответ читает человек, и он уже записан — во внутреннем регламенте возвратов. Считать нечего, создавать нечего. RAG.
Управляющая компания хочет, чтобы заявки жильцов разбирались без диспетчера. Дальше система действует сама, и действие зависит от содержания заявки: протечка идёт в аварийную бригаду немедленно, вопрос по квитанции — в расчётный отдел, а спорный случай надо вернуть человеку. Один маршрут на все три не нарисовать. Агент.
Коммерческий директор спрашивает, у скольких клиентов долг перевалил за шестьдесят дней. Читает ответ человек, но в документах этого числа нет: оно появится, когда кто-то отфильтрует и посчитает строки в учётной системе. Text2SQL.
Руководитель филиала в одном разговоре спрашивает, что в положении о премировании сказано про испытательный срок и сколько филиал выплатил премий за прошлый квартал. Один человек, один тон, два разных проекта: положение — текст, лежащий в документе, значит RAG; сумма выплат — цифра, которую ещё никто не считал, значит text2SQL. Вот и развилка из 10.1 — ровно так часто, как предупреждала пятая глава.
Дерево даёт форму, а не приговор
Всё написанное выше отвечает на один вопрос: какую форму примет решение. Оно не отвечает, стоит ли его вообще делать. Безупречно классифицированный агент для процесса, который случается одиннадцать раз в год, или правильно спроектированный RAG по базе знаний, куда никто не заглядывает, — всё равно потраченный впустую квартал. Дерево не умеет об этом предупредить, и не должно: у него другая работа. Этот приговор выносят вопросы из второй главы, и задают их до дерева, а не вместо него.
Прогоните дерево, назовите класс, объясните, почему проиграли остальные четыре, — а потом вернитесь и проверьте, стоила ли задача вообще того, чтобы её решать. Правильный ответ на неправильный вопрос остаётся неправильным вопросом.