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

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

На приведенной ниже диаграмме показана упрощенная схема архитектуры компонентов RAG:

Глядя на диаграмму выше, она имеет следующие компоненты:

  1. Компонент Внедрение преобразует весь необработанный текст во Внедрение (векторное представление текста).
  2. Механизм хранения и извлечения векторов, который хранит всю информацию о векторах и обеспечивает быстрый поиск.
  3. Пользователь отправляет запрос через интерфейс чата. Запрос преобразуется во вложения тем же компонентом встраивания.
  4. Вложения ищутся через векторный движок. Векторный механизм извлекает соответствующий контекст (фрагменты, которые потенциально могут иметь ответ) и отправляет запрос и контекст в LLM.
  5. LLM считывает контекст запроса и дает точный ответ.

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

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

ПРИМЕЧАНИЕ. Поскольку сложно охватить все инструменты для каждого из компонентов, инструменты выбираются на основе популярности при реализации RAG на AWS.

Еще одно примечание по оценке затрат:

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

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

Встраиваемый компонент

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

  • BERT(базовый без регистра): первая модель встраивания, выбранная для сравнения, — это BERT(базовый без регистра). Эту модель можно развернуть непосредственно из SageMaker Jumpstart. Известно, что он хорошо работает при создании контекстного встраивания. Размер этих моделей составляет около ~ 500 МБ. Следовательно, запустить такую ​​модель на Amazon SageMaker легко можно на ml.p2.2xlarge. Также доступно множество доработанных вариантов для многоязычных вариантов использования, а также с точки зрения размера параметра. Его можно хорошо использовать в тех случаях, когда требуется многоязычная поддержка и когда командам нужна большая гибкость при выборе моделей.

  • GPT-J: самый популярный вариант, упоминаемый во многих блогах на основе RAG на AWS. Опять же, его также можно разместить на SageMaker одним щелчком мыши в SageMaker JumpStart. Это довольно большая модель, поэтому она требует более мощных вычислений, но обеспечивает действительно высокое качество встраивания. На самом деле, это одна из самых эффективных моделей встраивания по их результатам оценки.

  • Преобразователи предложений Hugging Face: еще одно очень популярное средство встраивания предложений, предоставляемое библиотекой Hugging Face, которую можно развернуть через SageMaker JumpStart. Один из самых маленьких, но очень мощных вариантов в предложении. Из-за небольшого размера его запуск на SageMaker Endpoint может быть довольно дешевым и обеспечивает хорошее качество встраивания. Помимо этого, существует множество доработанных версий, доступных даже для конкретных доменных данных.

ПРИМЕЧАНИЕ. Эта модель также может работать на AWS Lambda, что может значительно снизить затраты. Причина, по которой это отображается как конечная точка в SageMaker, заключается в обеспечении паритета архитектуры, когда любой из компонентов может быть заменен без каких-либо изменений в конструкции.

  • Amazon Bedrock (Внедрение текста Amazon Titan): Следующий вариант — использовать модель Внедрение текста Amazon Titan через Amazon Bedrock, предварительная версия которой все еще находится на стадии предварительной версии. Но поскольку Amazon Bedrock не имеет серверов, было бы довольно просто использовать эту модель в решении RAG без операционных издержек. Информация о ценах пока недоступна, но будет доступна, когда услуга станет общедоступной.

Подводя итог, вот как все варианты складываются друг с другом.

Следующим компонентом в архитектуре RAG является хранилище векторов, давайте посмотрим, какие у нас есть варианты.

Магазин векторов

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

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

  • Amazon OpenSearch: Amazon OpenSearch — это распределенный, управляемый сообществом, лицензированный Apache 2.0, полностью открытый поисковый и аналитический набор, используемый для хранения и извлечения вложений. Основанный на поисковой библиотеке Apache Lucene, он поддерживает ряд возможностей поиска и аналитики, таких как поиск k-ближайших соседей (KNN), который идеально подходит для векторного поиска. Вы можете быстро настроить его через boto3 APIs или консоль AWS. Он может очень хорошо масштабироваться с помощью хранилища и вычислений с помощью сегментирования и выделенных мастер-узлов. Для его настройки необходимы общие знания Python.

  • Amazon RDS(PostgreSQL) с использованием pgvector: Еще один многообещающий вариант — использование Amazon RDS(PostgreSQL) с расширением pgvector с открытым исходным кодом. Просто настройте кластер RDS и установите pgvector. Поскольку установка pgvector выполняется вручную, существуют некоторые операционные накладные расходы, связанные с поддержанием расширения в актуальном состоянии, а в некоторых случаях также с его настройкой. Кроме того, для запуска этого решения потребуется понимание SQL и Python. Таким образом, совокупная стоимость владения будет немного выше, чем в предыдущем варианте. Он использует L2, косинус и внутренний продукт в качестве некоторых методов для поиска подходящего вложения.

  • FAISS: самая популярная альтернатива для хранения векторов, не относящаяся к AWS. Его открытый исходный код обеспечивает молниеносное извлечение. Он использует множество подходов с квантованием произведения, HNSW и IF. Он может очень хорошо масштабироваться даже с поддержкой графического процессора для сверхбыстрой производительности. Но поскольку это ручная установка, общая стоимость владения довольно высока. Как разработчик, вам необходимо настроить весь кластер для FAISS, обновить его, исправить, защитить и настроить в соответствии с вашими требованиями. Вы можете запустить его на EC2, Amazon ECS, Amazon EKS или любом другом предложении для постоянных вычислений на AWS.

Специальное упоминание: Amazon Kendra — магазин для встраивания и вектора в одном сервисе.

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

Amazon Kendra: полностью управляемый сервис, предоставляющий готовые возможности семантического поиска документов и отрывков. Нет необходимости иметь дело с встраиванием слов, фрагментацией документов, векторным хранилищем и т. д. Amazon Kendra предоставляет Retrieve API, разработанный для варианта использования RAG. Он также поставляется с готовыми коннекторами для популярных источников данных, таких как Amazon Simple Storage Service (Amazon S3), SharePoint, Confluence и веб-сайтов, и поддерживает распространенные форматы документов, такие как HTML, Word, PowerPoint, PDF. , Excel и текстовые файлы. Поскольку это бессерверный опыт, заменяющий два компонента одновременно, совокупная стоимость владения может быть довольно низкой.

И в завершение этого раздела, вот краткое изложение всех вариантов, которые мы обсуждали:

Помимо вышеперечисленного, некоторые почетные упоминания, которые не были включены в сравнение баз данных Vector, — это Weaviate, Pinecone и chroma, которые также получили хорошее признание в сообществе разработчиков.

Далее идет последний компонент RAG, LLM. Давайте рассмотрим выбор LLM на AWS

Большая языковая модель

Это пространство развивается очень быстро, поэтому я бы выбрал те, которые довольно популярны в эталонных реализациях на основе RAG на AWS.

ПРИМЕЧАНИЕ. Доступ к некоторым из сторонних моделей, упомянутых ниже, вполне можно получить через их собственные API, но их использование через AWS имеет то преимущество, что эти модели размещаются внутри самого AWS, что повышает безопасность и сетевое состояние.

Jurassic-2 через SageMaker Jumpstart: первый вариант — Jurassic-2 от AI21Labs. Он также доступен через SageMaker JumpStart. Вы можете развернуть модель на SageMaker Endpoint за считанные минуты из SageMaker Studio или через SageMaker API. Помните, что опыт разработчиков не является бессерверным. Стоимость состоит из цены модели поставщика и цены экземпляра SageMaker. Его самым большим преимуществом является то, что он многоязычный и был признан одним из самых эффективных LLM в Стандфордском тесте HELM, поэтому вы можете рассчитывать на высокое качество результатов.

Falcon через SageMaker JumpStart: другой очень популярной альтернативой является использование модели Falcon. Это самый эффективный LLM с открытым исходным кодом в таблице лидеров Hugging Face на момент написания этого блога. Благодаря открытому исходному коду цена программного обеспечения становится равной нулю, что делает его действительно привлекательным выбором для AWS. Вам нужно платить только за стоимость экземпляра. Он идеально подходит для вопросов и ответов и расширенного извлечения информации. Имейте в виду, что длина контекста составляет около 2 КБ, что может быть мало для некоторых вариантов использования.

Специальное упоминание: Amazon Bedrock — выберите LLM по вашему выбору

Amazon Bedrock: Amazon Bedrock — самое уникальное предложение в этом списке. Это полностью бессерверный опыт, в котором один API-интерфейс Bedrock можно использовать для вызова моделей из Amazon Titan, Jurassic2 от AI21Labs, Claude от Anthropic и моделей Stable Difusion от Stability.ai. Bedrock позволяет вам выбрать модель, которая лучше всего подходит для вашего случая использования. Он обрабатывает всю инфраструктуру и масштабирование за кулисами. Из-за того простого факта, что он бессерверный, есть очень веские основания для того, чтобы совокупная стоимость владения была довольно низкой.

И в завершение этого раздела, вот краткое изложение всех вариантов, обсуждаемых в этом разделе:

Заключение

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

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