OBS

Многие уже задумываются о проектах с искусственным интеллектом, таких как помощник для клиентов, обработка документов, прогноз спроса. Кажется, что это новая сфера, но в финансах – это обычное вложение денег, которое должно окупиться, и оценивать его нужно так же, как покупку станка или наем сотрудника. Мы должны посчитать, сколько проект будет стоить и сколько он нам даст экономии или дополнительных доходов.

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

Почему цену нельзя взять из прайса

Кажется, что все просто: узнал цену одного обращения к ИИ-модели, умножил на ожидаемое число обращений, получил затраты. На практике цена одного обращения – величина непостоянная, и зависит она сразу от трех вещей: какую модель вы выбрали, сколько текста отправили и получили и по какой схеме платите.

Начнем с выбора ИИ-модели. Модели различаются по мощности и по цене: есть тяжелые и дорогие, есть легкие и дешевые. Разница в цене обращения между самой мощной и самой простой может достигать десятков раз. При этом для многих задач мощная модель не нужна, например, разобрать типовое обращение клиента или разложить документ по полям – вполне способна простая. Отсюда первый вывод: цена обращения зависит от конкретной задачи и конкретной модели.

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

Три схемы оплаты и главная ловушка

Схем оплаты сегодня три, и путать их опасно.

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

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

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

Третья схема: своя локальная модель, развернутая на собственных серверах. Здесь нет платы за обращение, но есть плата за оборудование и специалистов. По сути это выбор между двумя структурами затрат: своя модель требует высоких постоянных затрат и у нее почти нулевые переменные; внешний сервис, наоборот, – никаких вложений на старте, но плата за каждое использование. Чем выше доля постоянных затрат, тем сильнее результат зависит от объема. При малом объеме дешевле внешний сервис, при большом объеме или при длинном сроке проекта своя модель начинает выигрывать, потому что дорогая настройка распределяется на множество обращений. Прежде чем выбирать, стоит хотя бы примерно оценить ожидаемый объем использования: без этой цифры выбор превращается в спор о вкусах.

Почему иногда дешевая модель обходится дороже

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

Механика простая. Сначала платят за неудачную попытку. Потом сотрудник тратит время на проверку и переделку. Потом задачу все равно отдают мощной модели и платят второй раз. Суммарный счет выходит выше, чем если бы сразу взяли подходящий инструмент.

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

Четыре способа снизить затраты

Распределять задачи между моделями по сложности. Это самый действенный прием. Простые и массовые задачи отдавать дешевым моделям, сложные и редкие – передавать мощным. В современных инструментах такое распределение настраивается заранее, и именно оно дает основную экономию. Смысл в том, чтобы выбирать инструмент по достаточности, а не по мощности.

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

Следить за объемом пересылаемого текста. Сокращение лишнего контекста в каждом обращении снижает счет пропорционально и не требует менять ничего по существу.

Собирать статистику с первого дня. Нужно видеть, сколько обращений, какой модели и по какой задаче ушло и сколько это стоило. Без такого учета оптимизировать сложно, а с ним быстро становится видно, какие задачи съедают основную часть бюджета. Как правило, выясняется, что несколько типов запросов дают львиную долю расходов, и работать нужно именно с ними.

Порядок расчета

Соберем все в практическую последовательность.

- Определите классы задач и для каждого выберите модель по принципу достаточности.

- Посчитайте ожидаемое число обращений в месяц по каждому классу и умножьте на цену той модели, которая будет работать в эксплуатации.

- Добавьте запас на неудачные попытки и время сотрудников на проверку.

- Прибавьте постоянную часть: сопровождение, поддержание данных в порядке, присмотр специалиста.

- Если объем достаточно большой, проверьте альтернативу в виде локальной модели.

- Посчитайте, что будет при росте объема вдвое: при оплате по факту затраты вырастут пропорционально, и то, что окупалось при нынешнем объеме, при большем может перестать.

И последнее

ИИ – это самая быстро меняющаяся область из всех, где руководителю приходится считать деньги: цены падают, модели обновляются, схемы оплаты пересматриваются. Любой расчет здесь стоит перепроверять примерно раз в месяц.

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