Следующим узким местом в развитии ИИ станет не сама модель, а система вывода.

Корпоративные системы искусственного интеллекта вступают в фазу, когда проектирование процесса вывода имеет такое же важное значение, как и сами возможности модели.

Делиться

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

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

Я видел это столько раз, что считаю необходимым об этом написать.

Тонкая настройка полезна, но ею злоупотребляют.

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

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

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

Сама модель так и не была изменена. И это довольно распространенное явление.

Что происходит во время вывода?

Долгое время вывод модели представлял собой лишь этап её использования. Все важные решения принимались на этапе обучения. Сейчас ситуация меняется.

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

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

Проблема распределения ресурсов

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

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

Эти системы гораздо сложнее, чем кажется на первый взгляд.

Если заглянуть внутрь современной системы искусственного интеллекта, то обычно это не просто одна модель, отвечающая на вопросы. Часто она включает в себя этап поиска, этап ранжирования, возможно, этап проверки и этап обобщения; несколько этапов, выполняемых одновременно для получения конечного результата. Речь идёт не только о возможностях базовой модели, но и о том, как все эти элементы взаимодействуют, чтобы получить результат.

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

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

Проблемы с памятью становятся всё более актуальными.

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

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

Еда на вынос

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

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

Шафик Ур Рахаман Посмотреть все от Шафик Ур Рахаман

Источник: towardsdatascience.com