Создание готового к производству генеративного ИИ: пять вещей, которые не следует делать

Введение

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

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

Не думайте, что результаты обучения на степень магистра права будут точными

Это может показаться очевидным, но я был удивлен, насколько ненадежным может быть вывод коммерческих LLM. При тестировании основных LLM (в частности, ChatGPT, Anthropic's Claude AI и Amazon Bedrock) на сложных финансовых наборах данных я заметил, что они могут генерировать ошибки или галлюцинации со скоростью одна на страницу. LLM виновны в частой генерации информации, котораязвукиправдоподобно, но ложно.

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

Хотяэффективное оперативное проектированиеможет смягчить некоторые из этих галлюцинаций, многие из которых возникают по изначально необъяснимым причинам (поэтому у каждого LLM есть рекомендация вручную просматривать свои выходные данные где-то в пользовательском интерфейсе и документации).

ОРС(Оптическое распознавание символов) — технология, которая преобразует изображения в машиночитаемый текст — также генерирует высокий уровень ошибок. Сложно разработать механизм для борьбы с неточностью OCR для каждой модели. Адаптивное обучение на основе ИИ для ошибок, отмеченных пользователем, может быть полезной стратегией, но требует огромного количества ручного вмешательства.

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

2. Не будьте самодовольны своими продюсерскими титрами

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

Банкротство из-за чрезмерной траты производственных кредитов может показаться городским мифом — конечно, нет зафиксированных случаев, когда производственные кредиты выходили из-под контроля — но лучше перестраховаться, чем потом сожалеть, не так ли?

Есть несколько способов максимально использовать потенциал ваших производственных титров:

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

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

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

3. Не забудьте протестировать пользовательский опыт (UE)

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

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

4. Не забывайте о важности обучающих данных

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

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

Немного не по теме, но в будущем, возможно, борьба с данными обучения не будет проблемой. Многообещающие достижения, такие какАвтоMLавтоматически очищать данные обучения и оценивать производительность модели, используя ряд методов, таких как метаобучение, байесовский вывод и поиск нейронной архитектуры. Для МСП с ограниченными ресурсами кодирования AutoML может стать многообещающей инновацией.

5. Не выбирайте неправильную стратегию моделирования масштаба

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

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

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

Краткое содержание

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

Работа с последними достижениями в области академического и промышленного машинного обучения поможет справиться с некоторыми типичными разочарованиями, поскольку конкурентная среда машинного обучения постоянно вытесняет новые инновации. Я организуюЛондонская встреча по машинному обучению(крупнейшее сообщество экспертов по искусственному интеллекту в Европе), представляющее собой бесплатное сообщество, где проводятся мероприятия, раскрывающие новейшие технические достижения в области машинного обучения.

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

Удачи!