Универсальный Bloom: Apply ⏱ 8 мин мультиагентность

Метрдотель разруливает заказы: Routing

🧊 Won't Have 💧 Could Have ☀️ Should Have 🔥 Must Have
☀️ Should Have
Простой приём оркестрации, который чаще всего и режет счёт за AI. Не основа основ, но почти всегда окупается первым.

🤔 Зачем это читать

В прошлой теме ты выстроил конвейер цехов — шаг за шагом, с контролёром на стыке. Хорошо для задач, которые всегда идут по одной дорожке. Но вот сцена с работы, которая бьёт по кошельку каждый день. У вас один бот в поддержке. Ему прилетает и «во сколько вы работаете?», и «у меня списали деньги дважды, верните или я иду в суд». И на оба вопроса он отвечает одинаково: гоняет один и тот же дорогой движок, одну и ту же тяжёлую модель.

Что в итоге? На вопросе про режим работы — ответ, который стоил как консультация юриста, ради фразы «с 9 до 21». А на жалобе с угрозой суда — бодрое «спасибо за обращение, мы ценим ваше мнение», после которого клиент пишет отзыв на одну звезду. Один инструмент пытается тянуть всё: на простом палит деньги, на сложном лажает. Знакомо?

Беда не в том, что модель плохая. Беда в том, что её не на ту задачу поставили. Простому вопросу не нужен дорогой эксперт — хватит готового ответа из FAQ (частые вопросы, готовая база ответов). А жалоба с юридическим риском вообще не должна решаться ботом, её надо отдать человеку. Кто-то на входе должен посмотреть на заказ и решить, куда его направить. На кухне эту работу делает метрдотель у раздачи. В AI-системе — приём, который называется маршрутизация (routing).

После этой темы ты сможешь разложить входящий поток на ветки и для каждой выбрать свою станцию: простое — на дешёвую, сложное — на дорогую, рискованное — на человека. Это самый окупаемый приём из всей бригады агентов: чаще всего именно он, а не «модель помощнее», заметно режет счёт за AI (нередко в разы) и при этом поднимает качество. Научишься его видеть — перестанешь платить за консультацию юриста там, где хватило бы таблички на двери.

Задержись на 10 секунд. Вспомни любую очередь, где всех гонят в одно окно — простой вопрос «уточнить адрес» и сложный «оспорить начисление» стоят в одной и той же ленте к одному и тому же оператору. Бесит, правда? И простой ждёт зря, и сложному не хватает внимания. Подержи это раздражение в голове — сегодняшняя тема ровно про то, как этого не делать.

🛎 Метрдотель смотрит на заказ и решает, куда его кинуть

Представь хорошую кухню в час пик. Заказы сыплются, и они разные: кто-то просит просто кофе, кто-то — сложное горячее, кому-то нужен торт со свечками к юбилею, а за пятым столом гость нашёл волос в супе и зовёт разбираться. Если всё это валить в один цех, начнётся хаос: кофе застрянет за тортом, а скандал будет ждать, пока повар дожарит стейк.

Поэтому на раздаче стоит метрдотель (он же экспедитор — тот, кто разводит заказы по станциям). Его работа — не готовить. Его работа — за секунду глянуть на заказ и решить, на какую станцию его кинуть: кофе — на барную, горячее — на гриль, торт — в кондитерский цех, а скандал с волосом в супе — вообще не на кухню, а к управляющему, потому что это уже не про еду.

Вот это и есть маршрутизация (routing) — по-русски «дорожная развилка для заказа». В AI-системе на входе стоит не повар, а отдельный маленький шаг — классификатор (classifier), то есть «сортировщик». Он не отвечает на запрос. Он только смотрит на входящий запрос и навешивает ярлык: «это простое», «это сложное», «это жалоба». А дальше по ярлыку запрос едет на свою ветку — к своей станции.

Один заказ → метрдотель → нужная станция
📥
Входящий заказ
🛎
Метрдотель
смотрит и вешает ярлык — куда
Простое
быстрая дешёвая станция / готовый ответ
🔥
Сложное
к шефу — дорогая сильная модель
🙋
Спорное
не на кухню — к человеку
Метрдотель сам не готовит — он только сортирует. Вся экономия и всё качество рождаются тут, на развилке.

Заметь главное: метрдотель сам ничего не готовит. Он маленький, быстрый и дешёвый — глянул, навесил ярлык, отправил дальше. Вся тяжёлая работа происходит на станциях, и каждая станция заточена под свой тип заказа. В этом вся суть: вместо одного универсала, который умеет всё посредственно и дорого, — развилка и несколько узких специалистов.

💸 Почему это режет счёт, а не раздувает

Тут законный вопрос владельца: «погоди, ты добавил лишний шаг на входе — это же ещё одна работа, ещё одни деньги. Где экономия?» Справедливо, давай по-деловому.

Смотри, что было без маршрутизации: каждый запрос — и «во сколько открываетесь», и «оспорить начисление» — шёл на одну дорогую модель. Дорогую вызывали сто раз из ста. А теперь представь реальный поток поддержки: грубо, восемь запросов из десяти — это простые повторяющиеся вопросы, на которые есть готовый ответ. И только два — действительно сложные, где нужна тяжёлая модель.

С маршрутизацией восемь простых уходят на дешёвую станцию (готовый ответ из базы или маленькая быстрая модель), и только два сложных — к дорогому «шефу». Дорогую модель вызывают не сто раз, а двадцать. Метрдотель на входе стоит копейки — он же не готовит, он только сортирует. Вот тебе и арифметика: лишний дешёвый шаг на входе экономит кучу дорогих шагов на выходе. Это и есть routing-ROI — окупаемость маршрутизации (ROI — отдача от вложений, то есть сколько денег приём возвращает на каждый вложенный рубль).

И это не только про деньги. Качество тоже растёт. Помнишь принцип «начни с самого простого» из темы про лестницу сложности? Здесь он работает дважды. Простому вопросу не нужен дорогой эксперт — готовый выверенный ответ из базы и точнее, и быстрее, чем модель, которая каждый раз сочиняет заново. А сложному вопросу наконец достаётся вся мощь дорогой модели, не размазанная на тысячу «спасибо за обращение». Каждый получает свою станцию — и каждому на ней лучше.

🚪 Третья ветка, без которой всё ломается: к человеку

Самая важная ветка — не «простое» и не «сложное». Это ветка «это вообще не для бота». Жалоба с угрозой суда. Просьба об отмене крупного платежа. Что-то про здоровье или безопасность. Любой запрос, где цена ошибки высокая, а тон — эмоциональный.

Метрдотель в хорошем ресторане не пытается сам уладить скандал с волосом в супе — он зовёт управляющего. Не потому что он глупый, а потому что это его работа: распознать, что заказ — не про еду, и передать туда, где с ним справятся. Передачу запроса от агента к человеку (или к другой ветке) в нашем мире называют handoff (хэндофф) — буквально «передать дальше», как когда официант передаёт заказ на кухню вместе с запиской о том, что к чему.

Это прямое продолжение того, что ты уже видел: в теме про исполнителя и критика мы развели две роли, чтобы один проверял другого. Routing — следующий шаг той же идеи: не одна роль на всё, а правильная роль под каждый запрос. И самая правильная роль для горящей жалобы — это не агент, а живой человек. Хороший маршрутизатор знает свои пределы и не стесняется сказать «это не ко мне».

🧠 Метрдотель — это умная модель или просто табличка с правилами?

А вот теперь — ключевой вопрос, ради которого стоило всё это читать. Кто играет роль метрдотеля? Есть два варианта, и выбрать неправильный — частая и дорогая ошибка.

Вариант первый: простое правило (по-программистски — «if», «если…»). Если в запросе есть слово «суд», «верните деньги», «жалоба» — сразу к человеку. Если запрос точно совпал с вопросом из FAQ — отдать готовый ответ. Никакого AI, просто список условий. Дёшево, мгновенно, предсказуемо, легко проверить глазами.

Вариант второй: маленькая модель-классификатор. Когда запросы приходят живым языком и их не разложить по словам-маячкам («у меня тут такая ситуация, я заказывал на прошлой неделе, и вот…»), нужен кто-то, кто поймёт смысл, а не просто поищет слова. Тогда метрдотелем ставят отдельную модель — обычно дешёвую и быструю, её дело только сортировать, не отвечать.

И вот здесь — главный нерв темы, который мы дальше разберём в AI-чутье: не ставь дорогого AI-метрдотеля туда, где хватит таблички с правилами. Если поток сортируется по трём очевидным словам — простое правило сделает это бесплатно и надёжнее. Тащить нейросеть, чтобы она «решала», есть ли в тексте слово «суд», — это переплата на ровном месте: дорогой инструмент сел на работу, которую бесплатно делает строчка-условие.

Ниже — вся механика на псевдокоде. Это не настоящий код, а логика на человеческом языке (можешь пролистать, если картинка и так сложилась).

Псевдокод (на пальцах) · метрдотель сортирует входящий запрос # это НЕ настоящий код, а логика на человеческом языке
запрос = «то, что прислал клиент»

# ШАГ 1 — метрдотель вешает ярлык (НЕ отвечает, только сортирует)
ярлык = метрдотель смотрит на запрос → «простое» / «сложное» / «к человеку»
# метрдотель — это либо простое правило (if со словами-маячками),
# либо маленькая дешёвая модель, если смысл словами не поймать

# ШАГ 2 — развилка: по ярлыку едем на свою станцию
если ярлык = «простое» → готовый ответ из базы / дешёвая быстрая модель
если ярлык = «сложное» → дорогая сильная модель (шеф)
если ярлык = «к человеку» → передать живому оператору (handoff)
# → каждый запрос попал на станцию под себя: дёшево там, где можно, дорого там, где надо

Две вещи на вынос. Первое: метрдотель — отдельный лёгкий шаг, он только вешает ярлык, а не готовит. Второе: ветка «к человеку» — не признак слабости системы, а признак зрелой. Хуже всего, когда такой ветки нет вообще и бот пытается «решить» жалобу с угрозой суда сам.

🎮 Встань за метрдотеля

Час пик в поддержке. Прилетают запросы — твоя задача навесить на каждый правильный ярлык и отправить на нужную станцию. Веток четыре: FAQ (готовый ответ — дёшево), эксперт (дорогая модель — для реально сложного), человек (высокая цена ошибки или эмоции — не для бота), отказ (это вообще не наша задача — вежливо отклонить). Прежде чем жать кнопку, спроси себя: «сложность тут настоящая — или дорого просто потому, что текст длинный? и не пахнет ли это судом, деньгами, здоровьем?». Сначала прикинь, потом жми и сверяйся. Это тренировка того самого чутья, на котором держится вся экономия.

📖 Ключевые понятия

Маршрутизация (routing)
Приём оркестрации (дирижирования агентами): на входе стоит шаг, который смотрит на запрос и направляет его на нужную ветку-станцию. Простое — на дешёвую, сложное — на дорогую, рискованное — на человека. Метрдотель у раздачи кидает заказ на нужный цех.
Классификатор (classifier)
Сам метрдотель: лёгкий шаг, который не отвечает на запрос, а только вешает на него ярлык — «к какой ветке». Может быть простым правилом («если есть слово „суд" → к человеку») или маленькой дешёвой моделью, когда смысл не поймать по словам.
Handoff (передача)
Буквально «передать дальше»: передача запроса другому исполнителю — другой ветке или живому человеку, вместе с контекстом. Как официант передаёт заказ на кухню с запиской. Ветка handoff к человеку — обязательная страховка для всего, где цена ошибки высока.
Routing-ROI
Окупаемость маршрутизации: дешёвый сортировщик на входе экономит кучу дорогих вызовов на выходе. Восемь простых запросов уходят на дешёвую станцию, и только сложные — на дорогую. Чаще всего именно routing, а не «модель помощнее», режет счёт за AI.

🛡️ Частые заблуждения

«Маршрутизатор — это лишний шаг, он только добавляет задержку и стоимость»

Да, ты добавил шаг — но добавил дешёвый шаг, чтобы убрать дорогие. Тут интуиция и подводит: она считает количество шагов, а считать надо стоимость шагов. Метрдотель сортирует, а не готовит, поэтому стоит копейки — а каждый простой запрос, который он увёл с дорогой станции на дешёвую, это сэкономленный дорогой вызов. И с задержкой так же: лишние полсекунды на сортировку с лихвой отбиваются тем, что простой ответ из базы возвращается мгновенно, не дожидаясь раздумий тяжёлой модели.

«Раз это про AI, метрдотелем должна быть умная модель»

Не обязательно, и часто это перебор. Если запросы сортируются по двум-трём очевидным словам («суд», «вернуть деньги», «сбросить пароль») — хватит простого правила («если…»): оно бесплатное, мгновенное и предсказуемое. Модель-классификатор нужна только там, где смысл не поймать по словам, а надо понять, о чём вообще речь. Тащить нейросеть на работу, которую делает табличка, — палить деньги. Дорогой инструмент не там, где он нужен, — это и есть незрелое решение.

«Хороший маршрутизатор должен уметь обработать любой запрос сам»

Как раз нет. Лучший метрдотель знает свои пределы и не лезет улаживать скандал с угрозой суда — он зовёт человека (handoff). Ветка «это не для бота» — не дыра в системе, а признак зрелости. Хуже всего, когда такой ветки нет: тогда бот пытается «решить» жалобу сам, и вы получаете отзыв на одну звезду и потерянного клиента вместо вовремя переданного тикета.

🧠 AI-чутьё (AI Judgment)

Дешёвое — на дешёвое, дорогое — на дорогое; и не зови AI туда, где хватит правила

Вот рамка, которую стоит унести из этой темы и прикладывать к любому AI-предложению. Маршрутизация окупается по одной простой причине: не все запросы одинаково дорого решать, и грех тратить дорогой инструмент на дешёвую задачу. Дешёвую модель — на простое и массовое, дорогую — только на действительно сложное, человека — на рискованное. Это и есть routing-ROI, и чаще всего именно он, а не «давайте модель помощнее», даёт самую быструю и осязаемую экономию.

Но у этой же медали есть вторая сторона, и она важнее. Сам метрдотель тоже не должен быть дороже, чем надо. Если поток сортируется по трём очевидным словам — поставь простое правило, а не нейросеть. Звучит банально, но именно здесь чаще всего и перетрачивают: ставят умную модель-классификатор туда, где хватило бы строчки «если в тексте есть „суд" → к человеку». Получается метрдотель в смокинге, который весь день проверяет, открыта ли дверь.

Поэтому к любому предложению «давайте сделаем умного AI-диспетчера» прикладывай два вопроса. Первый: «а можно ли тут отсортировать простым правилом, без модели?» — если да, модель не нужна. Второй: «есть ли ветка к человеку для дорогих ошибок?» — если нет, систему опасно пускать в бой. Тот, кто задаёт эти два вопроса, экономит компании больше, чем тот, кто внедряет AI в каждую щель.

🎯 Практика

Одно задание на пять минут — оно превращает «метрдотель разруливает заказы» в твою рабочую схему под конкретный участок.

  1. Возьми любой реальный поток обращений со своей работы — поддержка, заявки, входящие письма, заказы. Выпиши 5 - 7 типичных запросов, которые туда прилетают, от самого простого до самого тяжёлого.
  2. Раскидай их по четырём веткам: FAQ (есть готовый ответ), эксперт (нужна сильная модель или сложная логика), человек (высокая цена ошибки, деньги, эмоции, юридический риск), отказ (это не ваша задача). Прикинь грубо: какая доля потока — это простое FAQ? Часто там и прячется главная экономия.
  3. Теперь по каждой ветке-сортировке реши: хватит простого правила или нужна модель? Если запрос узнаётся по двум-трём словам — пиши правило. Если только по смыслу — отметь «нужен классификатор». И обязательно проверь: у тебя есть ветка к человеку для горящих случаев? Если нет — это первое, что надо добавить.

Помнишь бота из начала, который и про режим работы, и про угрозу суда отвечал одинаково? Теперь у тебя есть схема, как его починить: метрдотель на входе, FAQ для простого, эксперт для сложного и обязательная ветка к человеку для горящего. Один и тот же поток — но каждый запрос наконец попадает на свою станцию.

🔗 Что дальше

Следующая тема: 8.4 — Бригада параллельно: Parallelization (Sectioning/Voting). Маршрутизация отправляет один заказ на одну станцию. А что, если большой заказ можно разделить на независимые части и готовить их одновременно — или, наоборот, отдать одну задачу нескольким поварам, чтобы они «проголосовали» за лучший вариант? Это следующий приём бригады — распараллеливание.

Связанные темы: