От пилота к продукту: разрыв, который ломает ИИ-проекты
Языковая модель отлично работает в демо - и разваливается в реальном использовании. Разбираю, где находится разрыв и как его преодолеть.
В 2023 году многие компании запустили пилоты с языковыми моделями. Это легко сделать: берёшь API, пишешь несколько промптов, получаешь впечатляющие результаты на тестовых примерах. Презентация проходит хорошо. Решение о расширении пилота принято.
А потом что-то идёт не так.
Я вижу этот сценарий повторяющимся. Называю разрыв между пилотом и продуктом самой недооценённой проблемой ИИ-проектов прямо сейчас.
Почему пилот выглядит лучше, чем он есть
Пилот тестируется на примерах, которые подобраны или хотя бы просмотрены командой. Это создаёт иллюзию, что модель работает хорошо на "реальных" данных. Но реальные данные в продакшене разнообразнее, грязнее и содержат краевые случаи, которые никто не думал проверять.
Второй фактор - пилот обычно не имеет требований к latency, масштабируемости, логированию, мониторингу и обработке ошибок. Всё это появляется при переходе в продакшен и требует значительной работы.
Третий фактор - в пилоте нет операционной нагрузки. Никто не ждёт ответа за 2 секунды, никто не запрашивает систему тысячу раз в день.
Что конкретно ломается при переходе в продакшен
Первое - качество на реальных запросах. Пользователи задают вопросы иначе, чем предполагала команда разработки. Формулировки другие, контекст другой, язык другой. Модель начинает делать ошибки, которых не было в тестировании.
Второе - стоимость. API языковых моделей стоит денег. Пилот на 100 тестовых запросах не даёт представления о реальных затратах при тысячах запросов в день.
Третье - надёжность. Что происходит, когда API недоступен? Что происходит, когда ответ приходит с задержкой? Что происходит, когда модель возвращает ответ в неожиданном формате?
Четвёртое - безопасность и контроль. Что происходит, если пользователь задаёт вопрос за пределами предполагаемого сценария? Может ли он получить информацию, которую не должен получать?
Как сократить разрыв
Первое правило - тестировать на реальных данных с реальным разнообразием как можно раньше. Не на подготовленных примерах, а на том, что реально поступает от пользователей.
Второе правило - определить метрику качества до запуска пилота. Не "выглядит ли ответ хорошо", а конкретное измеримое определение приемлемого результата.
Третье правило - заложить в архитектуру возможность мониторинга. Каждый запрос к модели и каждый ответ должны логироваться в форме, позволяющей анализировать качество и выявлять деградацию.
Четвёртое правило - планировать человеческий надзор на переходном периоде. Полная автоматизация - это не первый шаг. Первый шаг - помочь человеку делать работу быстрее. Второй шаг - убрать человека из петли там, где качество и надёжность подтверждены.
Разрыв между пилотом и продуктом реален и преодолим. Но его нужно планировать, а не обнаруживать в процессе.