Масштабировать ИИ-решение можно в трёх направлениях: на больший объём того же процесса, на смежные процессы и на другие подразделения. Это три разные задачи с разными рисками, и попытка двигаться во всех направлениях сразу — основная причина, по которой успешный пилот не превращается в работающую систему. Правильная последовательность — сначала объём, потом смежные процессы, и только затем другие подразделения.
Почему направления нельзя смешивать
Пилот доказал, что решение работает на конкретном сочетании трёх вещей: этот процесс, эти данные, эти люди. Каждое направление масштабирования меняет одну из них, и вместе с ней — набор рисков.
Когда меняют всё сразу, диагностировать проблему становится невозможно: качество упало, но непонятно, из-за объёма, из-за других документов или из-за того, что новое подразделение работает по другим правилам. Проект превращается в поиск причин вместо развития.
Отсюда правило: за один шаг меняется одна переменная.
Направление 1: рост объёма
Тот же процесс, те же данные, больше обращений. Самый простой и предсказуемый шаг, но и здесь ломаются вещи, незаметные на пилоте.
Расходы растут пропорционально. У ИИ-решения переменная стоимость, и то, что было терпимо на десятой части потока, на полном объёме становится основной статьёй. Считать это нужно было до пилота — методика в статье «Сколько стоит эксплуатация ИИ-решения».
Появляются редкие случаи. Сценарий, встречающийся в одном проценте обращений, на пилоте мог не встретиться ни разу. На полном объёме он приходит регулярно, и часто именно на нём решение ошибается.
Меняется профиль нагрузки. Пиковые часы, очереди, ограничения поставщика на число обращений в минуту — то, чего не было видно при малом потоке.
Проверка перестаёт справляться. Если на пилоте человек проверял каждый результат, на полном объёме это физически невозможно. Нужно решить, что проверяется сплошь, а что выборочно, — и это решение о допустимом риске, а не техническая настройка.
Признак готовности к росту объёма: качество на пилоте устойчиво, расходы посчитаны на полном потоке, определён порядок проверки при масштабе.
Направление 2: смежные процессы
Тот же отдел, те же люди, другая задача. Кажется лёгким шагом — команда уже умеет работать с решением. Ломается здесь обычно другое.
Данные другие. Смежный процесс опирается на другие документы, и их состояние может отличаться радикально. Успех на первом корпусе ничего не говорит о втором: проверку готовности данных придётся проводить заново — см. «Готовность данных к внедрению ИИ».
Цена ошибки другая. Первый процесс выбирался в том числе за низкую цену ошибки. Смежный может оказаться существенно рискованнее, и конструкция, работавшая раньше, окажется недостаточной.
Критерий правильности другой. Эталонные ответы нужно готовить заново, и снова силами эксперта.
Соблазн здесь — «расширить существующее решение, там же почти то же самое». Практика показывает, что расширение универсального решения обходится дороже отдельной настройки под второй процесс, потому что попытка обслужить два разных сценария одной конфигурацией ухудшает оба.
Направление 3: другие подразделения
Тот же процесс, другие люди, часто — другие правила. Самое сложное направление, и трудности здесь не технические.
У подразделения свои правила. Филиал работает иначе, у региона своя специфика, у отдела сложились негласные исключения. Корпус, верный для одного подразделения, для другого содержит ошибки.
Нет своего владельца процесса. Это главная причина неудач при тиражировании. Решение приходит «сверху» как готовое, у него нет внутреннего заказчика, и повторяется классический сценарий: система работает, ею не пользуются. Роль владельца — в статье «Кто ведёт ИИ-проект внутри компании».
Опыт не передаётся автоматически. Команда, прошедшая пилот, знает про решение массу неписаных вещей. Новое подразделение начинает с нуля и наступает на те же грабли.
Сопротивление выше. В пилотном подразделении люди участвовали в создании. В остальных получают готовое — и воспринимают его как навязанное.
Практический вывод: тиражирование в другое подразделение — это не копирование, а новое внедрение с сокращённым циклом. Обязательны свой владелец, своя проверка данных и своя приёмка.
Что меняется в каждом направлении
| Направление | Что меняется | Основной риск | Что проверить заново |
|---|---|---|---|
| Объём | Количество обращений | Расходы, редкие случаи | Стоимость на полном потоке, порядок проверки |
| Смежный процесс | Задача и данные | Другое состояние документов | Готовность данных, критерий приёмки |
| Другое подразделение | Люди и правила | Нет владельца, свои исключения | Владелец, локальные правила, регламент |
Когда масштабировать рано
Признаки, при которых расширение приведёт к тиражированию проблем:
- качество на пилоте не измерено, а оценивается впечатлением;
- не посчитаны расходы на полном объёме;
- решением не пользуются даже в пилотном подразделении;
- нет регулярного контроля качества — значит, ухудшение обнаружится не сразу;
- сопровождение не организовано — при росте числа установок это становится критично.
Последний пункт заслуживает отдельного внимания. Одно решение без сопровождения деградирует медленно и заметно только владельцу. Пять решений без сопровождения деградируют одновременно и обнаруживаются по жалобам — см. «Сопровождение ИИ-решений».
Признаки готовности
Масштабировать имеет смысл, когда одновременно верно следующее: качество измерено на реальном потоке и устойчиво; расходы посчитаны и приемлемы при росте; решением реально пользуются, а не обходят; есть человек, отвечающий за поддержку; зафиксирован эффект «до/после», подтверждающий пользу.
Последнее важно не только для отчёта. Масштабирование требует ресурсов, а получить их без подтверждённого эффекта первого шага обычно не удаётся — см. «Как обосновать внедрение ИИ перед руководством».
Частые вопросы
С чего начинать масштабирование ИИ-решения?
С роста объёма в том же процессе — это самое предсказуемое направление, где меняется только количество обращений. Смежные процессы идут вторым шагом, тиражирование в другие подразделения — третьим, потому что там добавляются чужие правила и отсутствие своего владельца. Движение сразу по всем направлениям делает невозможной диагностику: непонятно, что именно перестало работать.
Можно ли расширить существующее решение на соседнюю задачу?
Технически да, практически это часто дороже, чем настроить отдельное решение. Смежный процесс опирается на другие документы, имеет другую цену ошибки и другой критерий правильности, а попытка обслужить два сценария одной конфигурацией обычно ухудшает оба. Общими остаются инфраструктура и опыт команды, а не сама настройка.
Почему решение, успешное в одном отделе, не приживается в другом?
Чаще всего потому, что в новом подразделении нет своего владельца процесса: решение приходит как готовое и навязанное, менять регламент некому, а сотрудники не участвовали в его создании. Вторая причина — локальные правила: то, что верно для одного отдела или филиала, в другом содержит исключения, не учтённые в корпусе. Тиражирование — это новое внедрение по сокращённому циклу, а не копирование.
Что происходит с расходами при масштабировании?
Растут пропорционально объёму обращений, поскольку каждое обращение к модели оплачивается. Это принципиальное отличие от обычного ПО, где рост нагрузки почти не меняет стоимости. Перед увеличением потока расходы нужно пересчитать на целевой объём и при необходимости оптимизировать — сократить передаваемый контекст, направить простые запросы на дешёвую модель, кэшировать повторяющееся.
Нужно ли заново проверять качество при переносе на другой процесс?
Обязательно, включая подготовку новых эталонных ответов силами эксперта. Достижимое качество определяется состоянием конкретного корпуса документов, а не самим решением, поэтому результат на первом процессе ничего не говорит о втором. Пропуск этой проверки при расширении — та же ошибка, что и пропуск её в первом проекте, только совершённая с большей уверенностью.
Что дальше
Перед масштабированием стоит убедиться, что эффект первого шага измерен, — «Как измерить эффект от внедрения ИИ». Что делать, если при росте объёма качество упало, — «Что делать, если ИИ-решение не работает». Чем масштабирование отличается от пересмотра самого процесса — «ИИ-трансформация или автоматизация». Полная картина — в опорной статье «Внедрение ИИ в бизнес».
Развитие работающего решения на новые процессы и подразделения — часть работ по разработке и внедрению ИИ; оценить кандидатов на расширение можно через аудит процессов.