Консалтинг по искусственному интеллекту: от выбора задачи до решения в вашем контуре

Четыре критерия отбора

• Частота. Операция повторяется каждый день или каждую неделю. Задача, которая случается дважды в год, не окупит даже простое решение.
• Цена ошибки. Если неверный ответ обходится дёшево и его ловит человек, ИИ годится. Если ошибка означает штраф, остановку линии или юридическое последствие, решение сначала работает как подсказка, а не как исполнитель.
• Данные. Есть ли история с правильными ответами: заявки с решениями, документы с проведёнными данными, прошлые обращения. Без образцов нечем проверить, что решение работает.
• Проверяемость. Можно заранее договориться, как выглядит «правильно», и сравнить результат с эталоном на отложенной выборке. Если «правильно» зависит от настроения руководителя, измерять нечего.

Что происходит с кандидатами

Часть идей отпадает на первом критерии: ИИ там не нужен, хватит правила в учётной системе или отчёта. Это нормальный результат. Часть упирается в данные: мы называем, что нужно собрать, и откладываем задачу. Остаётся одна-две, по которым хватает всего. Для них описываем пилот: что считаем успехом, на какой выборке, кто принимает.

Порядок работ после выбора подробно описан на странице «Внедрение ИИ», а как не потерять пилот на полпути, разобрано в статье «Почему ИИ-пилоты не доходят до продуктива».

Внешний программный интерфейс облачной модели (ChatGPT, GPT-4o и подобные) подходит, когда данные открытые или обезличенные, нагрузка небольшая, а скорость запуска важнее контроля. Для этого не нужен собственный сервер, и первую версию можно собрать быстро. Минусы: зависимость от условий и доступности внешнего поставщика, невозможность проверить, куда уходят данные, непредсказуемая стоимость при росте нагрузки.

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

Что мы делаем при выборе

1. Классифицируем данные задачи: что можно отправлять наружу, что нельзя ни при каких условиях.
2. Смотрим, есть ли у вас серверы и кто их обслуживает, нужна ли доверенная операционная система.
3. Собираем небольшую эталонную выборку и сравниваем кандидатов на ней. Победитель определяется по вашим примерам.
4. Записываем, при каких условиях вариант пересматривается: рост нагрузки, смена требований, новое семейство моделей.

Подробнее о развёртывании на своих серверах — на странице «Частные LLM в контуре» и в статье «Своя LLM или ChatGPT API».

• Что я получу в руки? Должен быть документ с составом, допущениями и вилкой, а не слайды с общими словами о трансформации.
• На чём проверены выводы? Хороший ответ — выборка ваших данных. Плохой — «в похожих компаниях это работает».
• Скажете ли вы «не надо»? Если консультант не называет задачи, где ИИ не нужен, его интерес не в вашем результате.
• Что будет, если я не продолжу с вами? Документ и материалы должны остаться у вас и быть понятными другому исполнителю.
• Как измерен успех? Метрика и порог названы до начала пилота, а не подобраны по итогам.

Мы не называем сроков окупаемости и эффекта до обследования: до разбора ваших данных любое число будет взято с потолка. Как считать эффект самостоятельно, описано в статье «Как посчитать ROI от внедрения ИИ».

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

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