Получение расширенного поколения (RAG) в поиске ИИ Azure

Статья
04/22/2024

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

Решение о том, какая система получения информации используется, имеет решающее значение, так как определяет входные данные для LLM. Система получения сведений должна предоставлять следующее:

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

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

Примечание.

Новые понятия copilot и RAG? Просмотрите векторный поиск и состояние получения искусства для приложений сгенерируемым искусственным интеллектом.

Подходы к RAG с помощью поиска ИИ Azure

Корпорация Майкрософт имеет несколько встроенных реализаций для использования службы "Поиск ИИ Azure" в решении RAG.

Azure AI Studio использует векторный индекс и расширение извлечения.
Azure OpenAI Studio использует индекс поиска с векторами или без нее.
Машинное обучение Azure используйте индекс поиска в качестве векторного хранилища в потоке запроса.

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

Оставшаяся часть этой статьи описывает, как поиск ИИ Azure вписывается в пользовательское решение RAG.

Настраиваемый шаблон RAG для поиска ИИ Azure

Общие сведения о шаблоне выглядят следующим образом:

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

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

RAG-шаблоны, включающие поиск ИИ Azure, содержат элементы, указанные на следующем рисунке.

UX приложения (веб-приложение) для взаимодействия с пользователем
Сервер приложений или оркестратор (уровень интеграции и координации)
Поиск ИИ Azure (система получения сведений)
Azure OpenAI (LLM для создания искусственного интеллекта)

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

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

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

LLM получает исходный запрос, а также результаты из поиска ИИ Azure. LLM анализирует результаты и формирует ответ. Если LLM является ChatGPT, взаимодействие с пользователем может быть обратной и обратной беседой. Если вы используете Davinci, запрос может быть полностью составным ответом. Решение Azure, скорее всего, использует Azure OpenAI, но от этой конкретной службы нет жесткой зависимости.

Поиск по искусственному интеллекту Azure не обеспечивает встроенную интеграцию LLM для потоков запросов или сохранения чата, поэтому необходимо написать код, который обрабатывает оркестрацию и состояние. Вы можете просмотреть демонстрационный источник (Azure-Samples/azure-search-openai-demo) для схемы полного решения. Мы также рекомендуем Azure AI Studio или Azure OpenAI Studio создавать решения поиска azure на основе RAG, которые интегрируются с LLM.

Содержимое, доступные для поиска в Azure AI

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

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

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

Content type	Индексировано как	Функции
text	токены, неуправляемый текст	Индексаторы могут извлекать обычный текст из других ресурсов Azure, таких как служба хранилища Azure и Cosmos DB. Вы также можете отправить любое содержимое JSON в индекс. Чтобы изменить текст в полете, используйте анализаторы и нормализаторы для добавления лексической обработки во время индексирования. Сопоставления синонимов полезны, если исходные документы отсутствуют терминологии, которые могут использоваться в запросе.
text	векторы ¹	Текст можно фрагментировать и векторизировать во внешнем виде, а затем индексировать в виде векторных полей в индексе.
Изображение	токены, неуправляемый текст ²	Навыки для OCR и анализа изображений могут обрабатывать изображения для распознавания текста или характеристик изображения. Сведения об изображении преобразуются в доступный для поиска текст и добавляются в индекс. Навыки имеют требование индексатора.
Изображение	векторы ¹	Изображения можно векторировать во внешнем виде для математического представления содержимого изображения, а затем индексировать в виде векторных полей в индексе. Вы можете использовать модель открытый код, например OpenAI C пакет интерфейса пользователя для векторизации текста и изображений в одном пространстве внедрения.

¹ Общедоступная функция поддержки векторов требует вызова других библиотек или моделей для блокирования и векторизации данных. Однако интегрированная векторизация (предварительная версия) внедряет эти действия. Примеры кода, демонстрирующие оба подхода, см . в репозитории azure-search-vectors.

²Навыки — это встроенная поддержка обогащения ИИ. Для OCR и анализа изображений конвейер индексирования выполняет внутренний вызов API визуального распознавания Azure. Эти навыки передают извлеченный образ в Azure AI для обработки и получают выходные данные в виде текста, индексированного поиском ИИ Azure.

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

Получение содержимого в поиске ИИ Azure

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

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

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

В поиске ИИ Azure нет типа запроса , даже семантического или векторного поиска, который создает новые ответы. Только LLM предоставляет генерированный ИИ. Ниже приведены возможности в поиске ИИ Azure, которые используются для формирования запросов:

Функция запроса	Характер использования	Причины использования
Простой или полный синтаксис Lucene	Выполнение запроса по тексту и числового содержимого невектора	Полнотекстовый поиск лучше всего подходит для точных совпадений, а не аналогичных совпадений. Запросы полнотекстового поиска ранжируются с помощью алгоритма BM25 и поддерживают настройку релевантности с помощью профилей оценки. Он также поддерживает фильтры и аспекты.
Фильтры и аспекты	Применяется только к полям текста или числовых (невекторов). Уменьшает область поверхности поиска на основе критериев включения или исключения.	Добавляет точность в запросы.
Семантическое ранжирование	Повторно ранжирует результирующий набор BM25 с помощью семантических моделей. Создает короткие подпись и ответы, полезные в качестве входных данных LLM.	Проще, чем профили оценки и в зависимости от содержимого, более надежный метод настройки релевантности.
Векторный поиск	Выполнение запроса по полям вектора для поиска сходства, где строка запроса является одним или несколькими векторами.	Векторы могут представлять все типы содержимого на любом языке.
Гибридный поиск	Объединяет все описанные выше методы запроса. Векторные и невекторные запросы выполняются параллельно и возвращаются в едином результирующем наборе.	Наиболее значительными преимуществами точности и отзыва являются гибридные запросы.

Структура ответа запроса

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

Поля, определяющие, какие части индекса включены в ответ.
Строки, представляющие совпадение из индекса.

Поля отображаются в результатах поиска, когда атрибут является "извлекаемым". Определение поля в схеме индекса имеет атрибуты и определяет, используется ли поле в ответе. Возвращаются только поля с полным текстом или векторным запросом. По умолчанию возвращаются все поля, которые можно получить, но можно использовать "select" для указания подмножества. Кроме "извлекаемого", нет ограничений на поле. Поля могут иметь любую длину или тип. Что касается длины, в поиске ИИ Azure нет максимального ограничения длины поля, но есть ограничения на размер запроса API.

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

Ранжирование по релевантности

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

Релевантность применяется к поиску ключевое слово (невектору) и гибридным запросам (по полям невектора). В службе "Поиск ИИ Azure" нет настройки релевантности для запросов поиска сходства и векторов. Ранжирование BM25 — это алгоритм ранжирования для полнотекстового поиска.

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

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

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

Пример кода запроса поиска ИИ Azure для сценариев RAG

Следующий код копируется из файла retrievethenread.py с демонстрационного сайта. Он создает content для LLM из результатов гибридного поиска запросов. Вы можете написать более простой запрос, но этот пример включает векторный поиск и ключевое слово поиск с семантической повторной настройкой и орфографическим проверка. В демонстрационной версии этот запрос используется для получения начального содержимого.

# Use semantic ranker if requested and if retrieval mode is text or hybrid (vectors + text)
if overrides.get("semantic_ranker") and has_text:
    r = await self.search_client.search(query_text,
                                  filter=filter,
                                  query_type=QueryType.SEMANTIC,
                                  query_language="en-us",
                                  query_speller="lexicon",
                                  semantic_configuration_name="default",
                                  top=top,
                                  query_caption="extractive|highlight-false" if use_semantic_captions else None,
                                  vector=query_vector,
                                  top_k=50 if query_vector else None,
                                  vector_fields="embedding" if query_vector else None)
else:
    r = await self.search_client.search(query_text,
                                  filter=filter,
                                  top=top,
                                  vector=query_vector,
                                  top_k=50 if query_vector else None,
                                  vector_fields="embedding" if query_vector else None)
if use_semantic_captions:
    results = [doc[self.sourcepage_field] + ": " + nonewlines(" . ".join([c.text for c in doc['@search.captions']])) async for doc in r]
else:
    results = [doc[self.sourcepage_field] + ": " + nonewlines(doc[self.content_field]) async for doc in r]
content = "\n".join(results)

Код интеграции и LLM

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

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

Следующий блок ячейки в записной книжке chat-read-retrieve.ipynb отображает вызовы поиска в контексте сеанса чата:

# Execute this cell multiple times updating user_input to accumulate chat history
user_input = "Does my plan cover annual eye exams?"

# Exclude category, to simulate scenarios where there's a set of docs you can't see
exclude_category = None

if len(history) > 0:
    completion = openai.Completion.create(
        engine=AZURE_OPENAI_GPT_DEPLOYMENT,
        prompt=summary_prompt_template.format(summary="\n".join(history), question=user_input),
        temperature=0.7,
        max_tokens=32,
        stop=["\n"])
    search = completion.choices[0].text
else:
    search = user_input

# Alternatively simply use search_client.search(q, top=3) if not using semantic ranking
print("Searching:", search)
print("-------------------")
filter = "category ne '{}'".format(exclude_category.replace("'", "''")) if exclude_category else None
r = search_client.search(search, 
                         filter=filter,
                         query_type=QueryType.SEMANTIC, 
                         query_language="en-us", 
                         query_speller="lexicon", 
                         semantic_configuration_name="default", 
                         top=3)
results = [doc[KB_FIELDS_SOURCEPAGE] + ": " + doc[KB_FIELDS_CONTENT].replace("\n", "").replace("\r", "") for doc in r]
content = "\n".join(results)

prompt = prompt_prefix.format(sources=content) + prompt_history + user_input + turn_suffix

completion = openai.Completion.create(
    engine=AZURE_OPENAI_CHATGPT_DEPLOYMENT, 
    prompt=prompt, 
    temperature=0.7, 
    max_tokens=1024,
    stop=["<|im_end|>", "<|im_start|>"])

prompt_history += user_input + turn_suffix + completion.choices[0].text + "\n<|im_end|>" + turn_prefix
history.append("user: " + user_input)
history.append("assistant: " + completion.choices[0].text)

print("\n-------------------\n".join(history))
print("\n-------------------\nPrompt:\n" + prompt)

Как приступить к работе

Используйте Azure AI Studio для создания индекса поиска.
Используйте Azure OpenAI Studio и "принесите собственные данные", чтобы экспериментировать с запросами на существующий индекс поиска на детской площадке. Этот шаг помогает решить, какую модель следует использовать, и показывает, насколько хорошо работает существующий индекс в сценарии RAG.
Акселератор решения "Чат с данными", созданный командой поиска ИИ Azure, помогает создать собственное пользовательское решение RAG.
Шаблоны приложений корпоративного чата развертывают ресурсы Azure, код и примеры данных приземления с помощью вымышленных документов плана работоспособности для Contoso и Northwind. Это комплексное решение дает вам рабочее приложение чата не более 15 минут. Код для этих шаблонов — это демонстрация azure-search-openai-demo , представленная в нескольких презентациях. Следующие ссылки предоставляют версии, относящиеся к языку:
- .NET
- Python
- JavaScript
- Java

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