Что такое оркестрация и зачем она в ИИ-проекте

Зачем это знать

• Понимать, за что подрядчик берёт деньги помимо обращений к модели
• Видеть, почему процесс из пяти проверяемых шагов надёжнее одного большого запроса
• Спрашивать, кто останавливает работу, когда шаг не прошёл, и как это видно в журнале

Что такое оркестрация простыми словами

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

Оркестрация — это тот самый пас в ИИ-системе. Модель хорошо разбирает текст и формулирует ответ. Она не решает, откуда взять договор, что делать при отказе внешнего сервиса и кому передать задачу, если уверенности мало.

Управляющий слой держит план целиком. Он знает шаги, порядок, условия перехода и точку, где процесс останавливается и зовёт человека.

Как это работает

Разбивка на шаги нужна ради проверяемости. Каждый шаг делает одно действие, у которого есть понятный признак успеха. Поле извлечено или нет, сумма сошлась или нет, контрагент найден в базе или не найден.

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

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

Ещё оркестратор решает, что именно попадёт в контекстное окно на каждом шаге. Один длинный запрос тащит с собой всё сразу и дорожает вместе с процессом. Пять коротких несут по одному куску данных.

И последнее: журнал. Записывается вход шага, решение и причина остановки. По журналу разбирают инцидент и считают, где процесс встаёт чаще всего.

Пример из практики

Компания разбирает входящие заявки на поставку. Письмо приходит в свободной форме, к нему приложен файл, номенклатура у каждого клиента названа по-своему.

Один запрос к модели с просьбой «разобрать заявку и завести заказ» работает на демонстрации и рассыпается на живом потоке. Причина простая: в одном действии смешаны разбор текста, поиск артикулов в базе, проверка остатков и запись в учётную систему. Когда результат неверен, непонятно, какой из четырёх шагов сломался.

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

Эффект замеряют так: доля заявок, прошедших без правок, и среднее время от письма до заказа. Берут поток за две недели до изменения и за две недели после, на одном и том же наборе клиентов. Оба показателя считаются по журналу оркестратора, вручную ничего сводить не нужно.

Что это даёт бизнесу

• Отказ перестаёт быть загадкой. Видно шаг, вход и причину остановки, поэтому доработка адресная и стоит дешевле общего «улучшим промпт».
• Автоматизация вводится частями. Сначала автоматически проходит самый простой маршрут, остальное остаётся у людей. Границу двигают по мере накопления статистики.
• Расходы становятся управляемыми. Каждый шаг несёт свой объём данных, и себестоимость операции считается по шагам, а не общей суммой в конце месяца.
• Человек остаётся в контуре по правилу, а не по настроению. Сумма, тип клиента, порог уверенности — условия передачи оператору записаны и проверяемы.

Когда без этого можно обойтись

Задача в один ход управляющего слоя не требует. Черновик письма, пересказ документа, ответ на вопрос по базе знаний — здесь достаточно хорошей инструкции для модели и человека, который читает результат.

Не нужна оркестрация и на малом потоке. Десяток заявок в неделю разбирает менеджер, а разработка маршрутов и журнала обойдётся дороже всей экономии. Порядок затрат на такой процесс удобно прикинуть калькулятором ручного процесса до начала работ.

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

Что важно проверить

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

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

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

Четвёртое: заранее договоритесь, по каким двум-трём показателям судят о результате и на каком объёме их считают. Готовность процесса к такому замеру проверяется чек-листом за один вечер.