ИИ не должен тратить время на переизобретение ETL

ИИ не должен тратить время на ETL

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

Но в процессе появилась тревожная тенденция: сообщество искусственного интеллекта, кажется, вновь изобретает перемещение данных (также известное как ELT). Независимо от того, называют ли они их коннекторами, экстракторами, интеграциями, загрузчиками документов или чем-то еще, люди пишут один и тот же код для извлечения данных из одних и тех же API, форматов документов и баз данных, а затем загружают их в векторные базы данных или индексы для своих LLM.

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

О многом было написано о проблемах, связанных с созданием надежных конвейеров извлечения, преобразования и загрузки (ETL), но давайте рассмотрим это в контексте искусственного интеллекта.

• 10 Необходимых подкастов по науке о данных, которые стоит послушать каждому энтузиасту
• Топ 18 идей проектов для практики Power BI в 2023 году
• Формирование интуиции по концепциям, лежащим в основе LLM-моделей, таких как ChatGPT — Часть 1 Нейронные сети, трансформеры, предварительное обучение и настройка

Зачем искусственному интеллекту нужно перемещение данных?

LLM, обученные на общедоступных данных, отлично работают, но знаете, что еще лучше? ИИ, который может отвечать на вопросы, специфичные для нас, наших компаний и наших пользователей. Мы бы все хотели, чтобы ChatGPT мог изучить всю вики-страницу нашей компании, прочитать все наши электронные письма, сообщения в Slack, записи и протоколы встреч, подключиться к нашей аналитической среде компании и использовать все эти источники при ответе на наши вопросы. Или, при интеграции ИИ в наш собственный продукт (например, с помощью Notion AI), мы бы хотели, чтобы модель ИИ нашего приложения знала всю информацию, которую у нас есть о пользователе при помощи помощи.

Перемещение данных является предпосылкой для всего этого.

Будь вы донастройка модели или использование Retrieval-Augmented Generation (RAG), вам нужно извлечь данные из мест, где они находятся, преобразовать их в формат, понятный вашей модели, а затем загрузить их в хранилище данных, к которому может обратиться ваше приложение ИИ для обслуживания вашего случая использования.

Диаграмма выше иллюстрирует, как это выглядит при использовании RAG, но можно представить, что даже если вы не используете RAG, основные шаги, скорее всего, не изменятся: вам нужно извлечь, преобразовать и загрузить, также известное как ETL, данные, чтобы создать ИИ-модели, которые знают непубличную информацию, специфичную для вас и вашего случая использования.

Почему перемещение данных сложно?

Построение базового функционального MVP для извлечения данных из API или базы данных обычно, хотя и не всегда, возможно в кратчайшие сроки (<1 неделя). На самом деле сложная часть заключается в том, чтобы сделать его готовым к использованию в производстве и поддерживать его в таком состоянии. Рассмотрим некоторые стандартные проблемы, которые приходят на ум при создании конвейеров извлечения.

Инкрементальное извлечение и управление состоянием

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

Обработка временных ошибок, задержки, возобновление при сбоях, заполнение воздушной щели

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

Выявление и проактивное исправление ошибок конфигурации

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

Аутентификация и управление секретами

API-интерфейсы могут быть как простыми, например, с использованием bearer-токенов, так и “творческими” реализациями сессионных токенов или одноразовой аутентификации через OAuth. Вам необходимо реализовать логику аутентификации, а также управлять секретами, которые могут обновляться каждый час, и, возможно, координировать обновление секретов между несколькими работниками.

Оптимизация скорости извлечения и загрузки, конкурентность и ограничения скорости

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

Адаптация к изменениям внешних API

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

Планирование, мониторинг, ведение журналов и наблюдаемость

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

Блокирование или хэширование данных

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

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

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

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

Итак, что должен делать инженер по искусственному интеллекту, чтобы перемещать данные здесь?

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

И даже если существующие платформы не поддерживают все, что вам нужно, вы всё равно должны иметь возможность подойти к этому наиболее близко с помощью переносимой и расширяемой инфраструктуры. Таким образом, вместо создания всего с нуля, вы можете достичь 90% цели с помощью готовых функций в платформе и заниматься разработкой и поддержкой только последних 10%. Самым распространенным примером являются интеграции с малым количеством пользователей: если платформа не имеет интеграции с API, которое вам нужно, хорошая платформа позволит вам легко написать код или даже использовать решение без кода для создания этой интеграции и все равно получить все полезные функции, предлагаемые платформой. Даже если вам нужна гибкость, чтобы просто импортировать коннектор в виде пакета Python и вызывать его по своему усмотрению из вашего кода, вы можете использовать одну из многих open-source инструментов для извлечения и загрузки данных, таких как Airbyte или Singer.

Чтобы быть ясным, перемещение данных полностью не решено. Есть ситуации, когда существующие решения действительно оказываются недостаточными, и вам приходится создавать новые решения. Однако это не относится к большинству пользователей AI-инженерии. Большинству людей не нужно снова и снова создавать одни и те же интеграции с Jira, Confluence, Slack, Notion, Gmail, Salesforce и т. д. Давайте просто использовать решения, которые уже прошли боевые испытания и стали доступными для всех, чтобы мы могли заниматься созданием ценности, которая на самом деле важна для наших пользователей.