Ров для корпоративного ИИ – это RAG + настройка вот почему

Ров для корпоративного ИИ объединение RAG и настройка - вот почему

Хайп вокруг LLM беспрецедентен, но оправдан. От искусственно-интеллектных изображений Папы Римского в наряде от Balenciaga до агентов технической поддержки без пульса, генеративный искусственный интеллект имеет потенциал изменить общество, как мы его знаем.

И во многом, LLM сделают инженеров данных еще более ценными – и это захватывающе!

Однако одно дело – показать своему боссу крутую демонстрацию инструмента обнаружения данных или генератора текста в SQL – и совсем другое – использовать его с собственными проприетарными данными компании, или даже более тревожным образом, с данными клиентов.

Слишком часто компании спешат создавать приложения искусственного интеллекта, имея мало предвидения о финансовых и организационных последствиях своих экспериментов. И это не их вина – вина лежит на руководителях и директорах, которые несут ответственность за “поторопись и иди” в менталитете вокруг этой (и большинства) новых технологий. (Помните NFT?)

• Метрики оценки для классификации за пределами точности
• Действительно ли глобальные переменные в Python глобальные?
• Совершенствование навыков в области заполнения данных повышение экспертизы в инжиниринге данных

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

По моему мнению, готовый к предприятию генеративный искусственный интеллект должен быть:

• Безопасным и конфиденциальным: Ваше приложение искусственного интеллекта должно гарантировать безопасность, конфиденциальность и соответствие, с должными средствами контроля доступа. Подумайте: SecOps для искусственного интеллекта.

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

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

Имея это в виду, настало время начать относиться к генеративному искусственному интеллекту серьезно. Но это не так просто…

Почему предприятий сложно достичь искусственного интеллекта?

Просто говоря, инфраструктура для масштабирования, обеспечения безопасности и работы с приложениями LLM пока не развита.

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

Возьмем GPT-4, например. В то время как GPT-4 превосходил GPT 3.5 в некоторых задачах (например, в сдаче экзамена SAT и AP по курсу “Аналитическая геометрия”), некоторые его результаты были наполнены галлюцинациями или не были достаточно представлены соответствующим контекстом для адекватного выполнения этих задач. Галлюцинации вызваны различными факторами – от плохих вложений до ограничений знаний, и часто влияют на качество результатов, генерируемых публично доступными или открытыми LLM, обученными на информации, полученной из интернета.

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

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

Два пути к готовности ИИ для предприятий: RAG и точная настройка

Когда дело доходит до приведения ИИ в состояние готовности для предприятий, самые важные части находятся в самом конце процесса разработки LLM: расширенное поколение с извлечением информации (RAG) и точная настройка.

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

Когда использовать RAG

Изображение от автора.

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

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

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

Изображение от автора.

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

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

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

Точная настройка, как и архитектуры RAG, требует создания эффективных конвейеров данных, которые обеспечивают доступность (помеченных!) предприятий к данным для процесса точной настройки. Не простая задача.

Почему RAG, вероятно, имеет смысл для вашей команды

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

Вот почему:

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

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

• RAG обеспечивает более надежные результаты: Простыми словами, RAG лучше работает с динамическими данными, генерируя детерминированные результаты из курированного набора актуальных данных. Поскольку точная настройка в большей степени работает, как чёрный ящик, сложно определить, как модель сгенерировала конкретные результаты, что снижает доверие и прозрачность. При точной настройке возможны искажения и неточности, так как вы полагаетесь на веса модели для кодирования деловой информации в утраточной форме.

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

Независимо от того, какой вы используете, ваше приложение ИИ будет требовать конвейеры, которые питают эти модели компанией данных через некоторое хранилище данных (будь то Snowflake, Databricks, автономная векторная база данных, такая как Pinecone или что-то другое). В конечном итоге, если генеративный ИИ используется для извлечения анализа и инсайтов из неструктурированных данных внутренних процессов, он будет работать в … барабанный бой … конвейере данных.

Для работы RAG вам нужна наблюдаемость данных

Изображение предоставлено Заком Уилсоном (LinkedIn).

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

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

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

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

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

Итак, какова де-факто-стек LLM?

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

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

Второй конкурент: хостинговые версии моделей, созданных сторонними разработчиками LLM, такими как OpenAI или Anthropic. В настоящее время, большинство команд получают доступ к генеративной ИИ через API с помощью этих стремительно развивающихся лидеров ИИ из-за удобства использования. Подключитесь к API OpenAI и воспользуйтесь передовой моделью за несколько минут? Мы уже зарегистрированы. Этот подход отлично работает «из коробки», если вам нужно, чтобы модель создавала код или решала известные, неспецифичные задачи на основе общедоступной информации. Если вы хотите включить собственную информацию в эти модели, вы можете использовать встроенную тонкую настройку или функции RAG, предоставляемые этими платформами.

И, наконец, третий конкурент: модернизированный стек данных. Snowflake и Databricks уже объявили, что они встраивают векторные базы данных в свои платформы, а также другие инструменты для интеграции данных, которые уже хранятся и обрабатываются на этих платформах, в LLM. Это имеет смысл для многих и позволяет командам данных, ответственных за ИИ-инициативы, использовать уже используемые инструменты. Зачем изобретать велосипед, когда у вас уже есть основы? Не говоря уже о возможности легкого соединения традиционных реляционных данных с векторными данными… Как и у двух других конкурентов, этот подход также имеет некоторые недостатки: Snowflake Cortex, Lakehouse AI и другие продукты MDS + AI находятся еще в зачаточном состоянии и требуют некоторого предварительного вложения для интеграции поиска векторов и обучения моделей в существующие рабочие процессы. Для более подробного рассмотрения этого подхода, я прекрасно вижу, что вы ознакомитесь со статьей Meltano pertinent piece о том, почему лучшим стеком LLM может быть тот, который находится прямо перед вами.

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

Будущее предприятий искусственного интеллекта в ваших процессах

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

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

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

Я готов к готовности предприятий в области искусственного интеллекта. А вы?