Получение сведений

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

Этот материал входит в цикл статей. Ознакомьтесь с введением.

Поиск индекса

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

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

• Алгоритм векторного поиска — алгоритм , используемый для поиска относительных совпадений. Поиск по искусственному интеллекту Azure имеет параметр алгоритма подбора, который сканирует весь векторный пробел, называемый исчерпывающим KNN, и более высокопроизводительным вариантом алгоритма, который выполняет приблизительный поиск ближайшего соседа (ANN) под названием Иерархический навигационно-малый мир (HNSW).
• Метрика . Эта конфигурация — это метрика сходства, используемая для вычисления близкости алгоритмом. Параметры в поиске ИИ Azure : косинус, dotProduct и Euclidean. Если вы используете модели внедрения Azure OpenAI, выберите cosine.
• efConstruction — параметр, используемый во время построения индекса иерархического навигационного индекса (HNSW), который задает количество ближайших соседей, подключенных к вектору во время индексирования. Большее значение efConstruction приводит к повышению качества индекса, чем меньшее число. Компромисс заключается в том, что большее значение требует больше времени, хранилища и вычислений. efConstruction должен быть выше для большого количества блоков и ниже для низкого количества блоков. Для определения оптимального значения требуется экспериментирование с данными и ожидаемыми запросами.
• efSearch — параметр, используемый во время запроса для задания количества ближайших соседей (то есть аналогичных блоков), используемых во время поиска.
• m — число двунаправленных ссылок. Диапазон составляет от 4 до 10, а более низкие числа возвращают меньше шума в результатах.

В службе поиска ИИ Azure конфигурации векторов инкапсулируются в vectorSearch конфигурации. При настройке векторных столбцов вы ссылаетесь на соответствующую конфигурацию для этого векторного столбца и задаете количество измерений. Атрибут измерений векторного столбца представляет количество измерений, созданных выбранной моделью внедрения. Например, оптимизированная text-embedding-3-small для хранения модель создает 1536 измерений.

Условия поиска

При выполнении запросов из оркестратора запросов в хранилище поиска можно рассмотреть множество вариантов. Вам нужно определить следующее:

• Какой тип поиска вы собираетесь выполнить: вектор или ключевое слово или гибридное
• Запрос к одному или нескольким столбцам
• Выполняется ли вы вручную несколько запросов, например запрос ключевого слова и векторный поиск
• Необходимо ли разбить запрос на вложенные запросы
• Следует ли использовать фильтрацию в запросах

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

Типы поиска

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

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

Поиск векторов соответствует сходству между векторизованным запросом (запросом) и полями векторов.

embedding = embedding_model.generate_embedding(
    chunk=str(pre_process.preprocess(query))
)

vector = RawVectorQuery(
    k=retrieve_num_of_documents,
    fields="contentVector",
    vector=embedding,
)

results = client.search(
    search_text=None,
    vector_queries=[vector],
    top=retrieve_num_of_documents,
    select=["title", "content", "summary"],
)

Пример кода выполняет векторный поиск по полю contentVector . Обратите внимание, что код, встраивающий запрос, сначала обрабатывает запрос. Этот препроцесс должен быть тем же кодом, который предварительно обрабатывает блоки перед внедрением. Модель внедрения должна быть той же моделью внедрения, что и внедренные блоки.

Полнотекстовый поиск

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

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

formatted_search_results = []

results = client.search(
    search_text=query,
    top=retrieve_num_of_documents,
    select=["title", "content", "summary"],
)

formatted_search_results = format_results(results)

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

Гибридный поиск

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

 embedding = embedding_model.generate_embedding(
    chunk=str(pre_process.preprocess(query))
)
vector1 = RawVectorQuery(
    k=retrieve_num_of_documents,
    fields="contentVector",
    vector=embedding,
)
vector2 = RawVectorQuery(
    k=retrieve_num_of_documents,
    fields="questionVector",
    vector=embedding,
)

results = client.search(
    search_text=query,
    vector_queries=[vector1, vector2],
    top=retrieve_num_of_documents,
    select=["title", "content", "summary"],
)

Пример кода выполняет полнотекстовый поиск по заголовку, содержимому и полям сводки и вектору поиска по полям contentVector и questionVector. Платформа поиска ИИ Azure выполняет все запросы параллельно, повторно выполняет результаты и возвращает первые retrieve_num_of_documents документы.

Вручную несколько

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

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

Несколько вложенных запросов

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

Рекомендуется определить, требует ли запрос несколько поисковых запросов перед выполнением любых поисковых запросов. Если вы считаете, что требуется несколько вложенных запросов, можно выполнить вручную несколько запросов для всех запросов. Используйте большую языковую модель, чтобы определить, требуются ли несколько вложенных запросов. Следующий запрос берется из репозитория GitHub GitHub RAG Experiment Accelerator, который используется для классификации запроса как простого или сложного, с сложным требованием нескольких запросов:

Consider the given question to analyze and determine if it falls into one of these categories:
1. Simple, factual question
  a. The question is asking for a straightforward fact or piece of information
  b. The answer could likely be found stated directly in a single passage of a relevant document
  c. Breaking the question down further is unlikely to be beneficial
  Examples: "What year did World War 2 end?", "What is the capital of France?, "What is the features of productX?"
2. Complex, multi-part question
  a. The question has multiple distinct components or is asking for information about several related topics
  b. Different parts of the question would likely need to be answered by separate passages or documents
  c. Breaking the question down into sub-questions for each component would allow for better results
  d. The question is open-ended and likely to have a complex or nuanced answer
  e. Answering it may require synthesizing information from multiple sources
  f. The question may not have a single definitive answer and could warrant analysis from multiple angles
  Examples: "What were the key causes, major battles, and outcomes of the American Revolutionary War?", "How do electric cars work and how do they compare to gas-powered vehicles?"

Based on this rubric, does the given question fall under category 1 (simple) or category 2 (complex)? The output should be in strict JSON format. Ensure that the generated JSON is 100 percent structurally correct, with proper nesting, comma placement, and quotation marks. There should not be any comma after last element in the JSON.

Example output:
{
  "category": "simple"
}

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

Your task is to take a question as input and generate maximum 3 sub-questions that cover all aspects of the original question. The output should be in strict JSON format, with the sub-questions contained in an array.
Here are the requirements:
1. Analyze the original question and identify the key aspects or components.
2. Generate sub-questions that address each aspect of the original question.
3. Ensure that the sub-questions collectively cover the entire scope of the original question.
4. Format the output as a JSON object with a single key "questions" that contains an array of the generated sub-questions.
5. Each sub-question should be a string within the "questions" array.
6. The JSON output should be valid and strictly formatted.
7. Ensure that the generated JSON is 100 percent structurally correct, with proper nesting, comma placement, and quotation marks. The JSON should be formatted with proper indentation for readability.
8. There should not be any comma after last element in the array.

Example input question:
What are the main causes of deforestation, and how can it be mitigated?

Example output:
{
  "questions": [
    "What are the primary human activities that contribute to deforestation?",
    "How does agriculture play a role in deforestation?",
    "What is the impact of logging and timber harvesting on deforestation?",
    "How do urbanization and infrastructure development contribute to deforestation?",
    "What are the environmental consequences of deforestation?",
    "What are some effective strategies for reducing deforestation?",
    "How can reforestation and afforestation help mitigate the effects of deforestation?",
    "What role can governments and policies play in preventing deforestation?",
    "How can individuals and communities contribute to reducing deforestation?"
  ]
}

Передача изображений в запросах

Некоторые многомодальные модели, такие как GPT-4V и GPT-4o, могут интерпретировать изображения. Если вы используете эти модели, вы можете выбрать, следует ли избегать фрагментирования изображений и передавать изображение как часть запроса в многомодальную модель. Следует поэкспериментировать, чтобы определить, как этот подход выполняется по сравнению с блокированием изображений и без передачи дополнительного контекста. Кроме того, следует сравнить разницу в затратах между подходами и проанализировать затраты.

Фильтрация

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

Повторная настройка

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

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

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

Повторное выполнение крупной языковой модели

Ниже приведен пример запроса крупной языковой модели из акселератора экспериментов RAG, который повторно выполняет результаты.

A list of documents is shown below. Each document has a number next to it along with a summary of the document. A question is also provided.
Respond with the numbers of the documents you should consult to answer the question, in order of relevance, as well as the relevance score as json string based on json format as shown in the schema section. The relevance score is a number from 1–10 based on how relevant you think the document is to the question. The relevance score can be repetitive. Don't output any additional text or explanation or metadata apart from json string. Just output the json string and strip rest every other text. Strictly remove any last comma from the nested json elements if it's present.
Don't include any documents that are not relevant to the question. There should exactly be one documents element.
Example format:
Document 1:
content of document 1
Document 2:
content of document 2
Document 3:
content of document 3
Document 4:
content of document 4
Document 5:
content of document 5
Document 6:
content of document 6
Question: user defined question

schema:
{
    "documents": {
        "document_1": "Relevance",
        "document_2": "Relevance"
    }
}

Перекрестное изменение кодирования

В следующем примере из репозитория GitHub RAG Experiment Accelerator используется CrossEncoder, предоставляемый Hugging Face для загрузки модели Роберты. Затем он выполняет итерацию по каждому блоку и использует модель для вычисления сходства, давая им значение. Мы сортируем результаты и возвращаем верхний N.

from sentence_transformers import CrossEncoder
...

model_name = 'cross-encoder/stsb-roberta-base'
model = CrossEncoder(model_name)

cross_scores_ques = model.predict(
    [[user_prompt, item] for item in documents],
    apply_softmax=True,
    convert_to_numpy=True,
)

top_indices_ques = cross_scores_ques.argsort()[-k:][::-1]
sub_context = []
for idx in list(top_indices_ques):
    sub_context.append(documents[idx])

Семантическое ранжирование

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

Руководство по поиску

При реализации решения поиска рассмотрите следующее общее руководство.

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

Оценка поиска

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

• Запрос — пример запроса
• Контекст — коллекция всех текстов в тестовых документах, которые обращаются к образцу запроса

Ниже приведены три хорошо установленных метода оценки извлечения, которые можно использовать для оценки решения поиска:

• Точность на K — процент правильно определенных соответствующих элементов из общих результатов поиска. Эта метрика фокусируется на точности результатов поиска.
• Отзыв на K - Отзыв на K измеряет процент соответствующих элементов в верхней K из общего количества возможных относительных элементов. Эта метрика фокусируется на охвате результатов поиска.
• Средний обратный ранг (MRR) - MRR измеряет среднее значение взаимных рядов первого соответствующего ответа в результатах поиска. Эта метрика фокусируется на том, где первый соответствующий результат возникает в результатах поиска.

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

Следующие шаги

Связанные ресурсы

• Краткое руководство. Чат с моделями Azure OpenAI с помощью собственных данных
• Гибридный поиск с помощью векторов и полнотекстового текста в поиске ИИ Azure