Поделиться через


Проектирование данных на основе рабочих нагрузок ИИ в Azure

Для приложений искусственного интеллекта подход к проектированию данных хорошо спроектированной платформы должен соответствовать нефункциональным требованиям, таким как операбельность, стоимость и безопасность, и придерживаться основных принципов основных принципов платформы Azure Well-Architected Framework. Он также должен учитывать функциональные требования, такие как прием данных, подготовка и проверка.

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

Модели генерированного искусственного интеллекта предварительно созданы или предварительно обучены, что позволяет немедленно использовать их без внесения изменений. Однако нестандартные модели часто не соответствуют определенным требованиям к рабочей нагрузке. Для решения этой проблемы модели дополняются данными, зависящими от контекста, чтобы повысить их производительность. Например, модель GPT можно использовать в различных вариантах использования. К этим приложениям относятся получение сведений из документов, предоставление поддержки ИТ-службы технической поддержки и сводка сложных сведений. Чтобы использовать базовые модели для удовлетворения конкретных потребностей, важно понимать эти аспекты.

Внимание

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

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

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

Рекомендации

Ниже приведена сводка рекомендаций, приведенных в этой статье.

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

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

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

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

Обслуживание индекса

Типы данных

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

  • Исходные данные — это существующие данные в рабочей среде. Эти данные можно структурировать, например данные в базах данных или частично структурированные, например JSON-файлы. Она также может быть неструктурирована, например документы, изображения и звуковые файлы.

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

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

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

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

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

Индексирование

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

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

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

Специализированная технология индексов

Рассмотрите возможность внешних данных приземления в индекс поиска. Используйте этот подход вместо запроса непосредственно из исходной системы.

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

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

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

По умолчанию или настраиваемый индекс

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

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

Структура схемы

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

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

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

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

Примечание.

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

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

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

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

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

Возможности индекса

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

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

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

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

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

Эффективное выполнение запросов

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

Типичные типы поисковых запросов:

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

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

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

  • Гибридный поиск объединяет различные типы поиска, такие как векторный поиск, полнотекстовый поиск и семантический ранжирование, чтобы повысить релевантность результатов поиска.

Чтобы повысить производительность модели, объедините типы поиска.

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

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

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

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

Подготовка данных

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

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

Повторное преобразование тома данных

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

Ниже приведены некоторые общие соображения.

  • Устранение данных. Сохраняйте только то, что важно для функциональных возможностей продукта, отменяя ненужные сведения. Ниже приведено несколько типичных примеров.

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

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

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

      Этот тип предварительной обработки также необходим для внедрения, что позволяет сравнивать слова на основе их контекста и важности. Однако одна проблема возникает из конфиденциальности регистра слов. Контекст имеет значение, и могут быть нюансы, такие как семантические различия между прилагательным "гражданским" и соответствующим существительным "(Honda) Civic".

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

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

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

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

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

Преобразование типов данных

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

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

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

Фрагментирование и внедрение

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

Существует множество методов реализации фрагментирования. Дополнительные сведения см. в разделе "Методы блокирования".

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

Обслуживание индекса

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

Критерии обслуживания

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

  • Удаление данных. Удаление данных сложно, так как необходимо проанализировать доступные и отсутствующие данные, чтобы определить, что не имеет значения. Чтобы исключить устаревшее содержимое из индекса, рассмотрите возможность использования метаданных, которые не позволяют поисковым системам индексировать определенные страницы или содержимое. Кроме того, при выборе параметров хранения выберите технологию, которая поддерживает удаление эффективно. Например, хранилище BLOB-объектов поддерживает обратимое удаление. Если вы используете поиск ИИ и загрузку документов из хранилища, хранилище BLOB-объектов может обнаруживать удаленные документы и удалять соответствующие записи. Этот подход не является идеальным, но это необходимо, если переиндексирование является дорогостоящим из-за большого размера индекса.

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

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

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

Стратегия развертывания

Стратегия развертывания. Существует две основные стратегии обновления индекса.

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

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

Совет

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

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

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

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

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

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

Операции с свежестью

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

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

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

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