Чтобы продолжить наш путь к применимому генеративному ИИ, я хотел бы обсудить некоторые проблемы применения векторных баз данных. Эти вопросы плохо обсуждаются, не говоря уже о том, чтобы найти широко принятые решения. Векторные базы данных — это настолько новая концепция, что осознание этих проблем приведет к более разумному проектированию системы.
Оглавление
· Почему векторные базы данных
· Различные типы векторных баз данных
· Проблемы применения векторных баз данных
∘ Векторные базы данных неразвиты
∘ Знание профессии -Выкл»
∘ Тесная связь с моделями встраивания
· Вывод
· Ссылки
Почему база данных векторов
Людям, знакомым с расширенной генерацией повторных попыток (RAG), назначение векторной базы данных легко понять. Как описано в статье[1], большой текстовый файл необходимо разделить на фрагменты, чтобы LLM могла найти наиболее релевантную информацию. Фрагменты необходимо хранить в векторном хранилище. Затем, отвечая на запросы, RAG будет использовать функцию сходства векторов и KNN, чтобы выбрать фрагменты, наиболее соответствующие запросу.
В случае RAG содержимым фрагмента является текст, а способ представления значения фрагмента — использование вектора — многомерного пространства данных. А функция сходства будет использоваться для выбора наиболее подходящих фрагментов. В большинстве систем используемой функцией подобия является функция косинусного подобия. Люди выбирают функцию косинусного подобия, потому что она не чувствительна к масштабу векторов. Он проверяет только угол между двумя векторами. Ближайшие векторы имеют очень малые углы. Оценка косинуса будет близка к 1. В противном случае угол, образуемый несвязанными векторами, будет диагональным, а оценка косинуса будет близка к 0.
А полезная нагрузка базы данных векторов — это пары «ключ-значение», где вектор является ключом, а содержимое фрагмента — значением для приложений RAG. На самом деле содержимое векторной базы данных не обязательно должно представлять собой фрагменты текста, это могут быть изображения, видео, аудио или что-то еще, что вам нужно, и вы можете создать вектор, чтобы передать его значение.
Представьте, что мы создаем небольшое векторное хранилище, и время отклика не является проблемой; мы можем просто использовать любую базу данных SQL или No-SQL для хранения пар ключ-значение. Нам нужно всего лишь итеративно запустить функцию сходства косинусов через хранилище векторов, чтобы увидеть, какой из них имеет наивысший балл.
Если это так, то нам не нужно использовать векторную базу данных. Мы можем сэкономить время для чего-то более важного. Но размер данных в большинстве проектов гораздо больше, а время отклика должно находиться в пределах определенного SLA. В этом сценарии нам необходимо использовать сложную базу данных векторов, чтобы получить оптимальную скорость.
Готовая к использованию векторная база данных предприятия предлагает гораздо больше, чем просто оптимальную скорость. Я это точно знаю. Давайте пока просто.
Различные типы векторных баз данных
Область баз данных Vector действительно довольно насыщена. Существует два типа векторных баз данных:
- Базы данных SQL, базы данных No-SQL и системы полнотекстового поиска расширяют свои функции для поддержки хранения векторных данных и поиска по сходству. Например, Cassandra заявила о поддержке векторной базы данных [2]; Elastic Search также догоняет [3]
- Специально разработанные коммерческие базы данных Vector с открытым исходным кодом. Ведущими продуктами являются:
У этих двух типов векторных баз данных есть свои плюсы и минусы. Хотя векторно-расширенный SQL, базы данных No-SQL и системы полнотекстового поиска могут поддерживать векторный поиск, их производительность и функциональность не так хороши, как у чисто векторных баз данных. Более того, традиционные базы данных не предназначены для обработки неструктурных типов данных, таких как изображения, аудио и видео. Они не очень хорошо масштабируются.
В дальнейшем обсуждении этой статьи мы будем рассматривать только наиболее типичные векторные базы данных.
Проблемы применения векторной базы данных
Векторные базы данных еще незрелы
В отличие от традиционных баз данных, чистые векторные базы данных предлагают комплексные векторные операции и более высокую производительность; однако они не так готовы к использованию на предприятиях, как эти очень зрелые решения. Говоря о некоторых проблемах, почти все векторные базы данных поддерживают только фильтрацию метаданных в дополнение к векторным операциям. Они не поддерживают сложные запросы, такие как SQL, и не интегрируются с другими системами. Вам необходимо независимо проверить их контроль доступа, планы устойчивости, контроль транзакций, изоляцию ACID и даже поддержку CRUD. Неосведомленность об этих ограничениях может вызвать очень дорогостоящие проблемы в реальном бизнесе.
Я заметил, что у Pinecone есть несколько вариантов резервного копирования индекса. Я верю, что катастрофы, подобные описанным выше, можно исправить, если люди знают о рисках и планируют заранее. Вот цель этой статьи.
Знание компромиссов
У инженеров, знакомых с любой традиционной базой данных, может сложиться впечатление, что база данных похожа на автомобиль, который может приземлиться и поехать без особых настроек. Даже если база данных требует некоторой настройки, чаще всего за это отвечает администратор базы данных. Однако векторная база данных не такая. Есть несколько серьезных решений, которые необходимо принять на этапе проектирования базы данных, а не на этапе обслуживания.
Секрет высокой эффективности векторной базы данных заключается в том, что она использует сложные структуры данных и алгоритмы для ускорения запроса. Процесс построения структуры данных называется индексированием. Во время индексации разработчикам приходится идти на первый компромисс: хотим ли мы сделать уклон в сторону более быстрой индексации или лучшей скорости выполнения запросов? Тогда им нужно определиться со вторым вопросом: как сбалансировать точность и скорость?
Например, индекс IMI компании Pinecone (Inverted Multi-Index, вариант ANN) создает накладные расходы на хранение и требует больших вычислительных ресурсов. Он в первую очередь предназначен для статических или полустатических наборов данных и может вызывать затруднения, если векторы часто добавляются, изменяются или удаляются. Milvus использует индексы, называемые «Квантование продукта» и «Иерархический навигационный малый мир» (HNSW), которые представляют собой приблизительные методы, в которых точность поиска сочетается с эффективностью. Более того, его индексация требует настройки различных параметров. Неправильная настройка параметров может повлиять на качество результатов поиска или привести к снижению эффективности.
HNSW — очень популярная технология индексирования, поскольку она обеспечивает очень высокую производительность запросов. Недостаток заключается в том, что он требует предварительного построения графа всех узлов вектора. Для крупной векторной базы данных, содержащей около 1 миллиарда векторов, на завершение первоначальной индексации может уйти целый день или даже больше.
Чтобы получить хорошее представление о том, как компромиссы влияют на производительность, и принять обоснованное решение о выборе правильного алгоритма, полезно зайти на сайт ANN Benchmarks [6]. Это один из графиков в тестах:
Вывод из графика: более высокая точность приводит к быстрому падению производительности; более высокие размеры вызывают более медленную скорость. Для приложений, которые отчаянно стремятся к высокой точности, это действительно болезненный момент принятия решения.
Будьте экономны
Предположим, мы создаем приложение RAG со скромными 10 миллионами страниц, каждая страница содержит 3000 символов или 800 токенов и будет обрабатываться как блок. Таким образом, у нас есть 10 миллионов вложений. В качестве модели внедрения мы выбрали модель внедрения OpenAI text-embedding-ada-002, а вектор внедрения будет иметь 1536 измерений. Игнорировать все метаданные; каждый фрагмент будет занимать 1536 x 4 + 3000 = 9,144 КБ. Общий объем хранилища составляет 91 ГБ.
Мы используем четыре стручка Pinecone P1.x8. База данных векторов будет стоить около 3300 долларов в месяц. Также существует единовременная стоимость создания внедрения в размере 3300 долларов США и дополнительные 3300 долларов США при каждом изменении модели внедрения. Если приложение получает много запросов в месяц, возникнут дополнительные периодические расходы на услугу внедрения запросов и генерацию ответов.
Обратите внимание, что это относительно небольшой набор данных, и настройки времени выполнения неэффективны. При таких настройках пропускная способность базы данных составляет всего 30 запросов в секунду. Инициализация 10 миллионов векторов на такой скорости занимает 4 дня. Если нас не устроит такая скорость, нам понадобится больше реплик. Стоимость будет намного выше, чем в этом расчете. Предприятия с более крупными корпорациями могут рассчитывать на то, что заплатят за приложение RAG в 10–100 раз больше.
Тесная связь с моделями внедрения
Все векторные базы данных ориентированы на эффективное хранение и извлечение векторизованных вложений. Ни один из них не предлагает решения для управления процессом внедрения, например, процессом генерации векторов. Как описано в архитектуре RAG, внедрение моделей требуется в двух процессах:
- индексирование или заполнение базы данных векторов парами ключ-значение полезной нагрузки или внедрение вектора и фрагмента
- запрос или создание внедрения для запроса, который будет использоваться в поиске по сходству.
В обоих процессах модель внедрения должна быть одинаковой. На протяжении всего жизненного цикла базы данных векторов все векторы внедрения должны создаваться с использованием одной и той же модели. Модели не только производят одинаковое количество измерений, но они должны быть точно одной и той же моделью.
В этом случае нам необходимо исследовать устойчивость моделей встраивания. Всего три недели назад топ-моделью в тесте MTEB была E5-large-v2, а text-embedding-ada-002 занимала 7-е место. С тех пор семейства моделей BGE и GTE превзошли E5-large-v2. Некогда передовой E5-large-v2 занимает лишь 5-е место, а text-embedding-ada-002 опустился на 13-е.
LLM — невероятно быстро развивающаяся область. Очень смело можно делать ставку на то, что модель не потребует обновлений в течение всего жизненного цикла системы векторной базы данных. Если мы дополнительно проверим вкладку «Рейтинг поиска» в таблице лидеров MTEB:
Заметим, что рейтинг варьируется от задачи к задаче. Для задачи FIQA2018 ведущей моделью является text-search-davinci-001, которая имеет низкий общий рейтинг — всего 61-е место. OpenAI объявила, что его место займет text-embedding-ada-002. Эта разница в производительности, связанная с задачами, показывает необходимость построения метрик производительности, связанных с проектом, и точно настроенных моделей внедрения [4, 5].
Проблема в том, что данные придется переиндексировать при каждом изменении модели. Как обсуждалось ранее, переиндексация — это трудоемкий, дорогостоящий и нарушающий работу процесса процесс.
Постоянно развивающиеся модели внедрения и точно настраиваемые модели ставят разработчиков перед дилеммой: как мы можем поддерживать модели, не слишком сильно нарушая данные? Если вы обновляете свой LLM путем тонкой настройки, обновления модели или даже увеличения размерности, вам необходимо повторно индексировать и снова оплатить полную стоимость.
Заключение
По сравнению с традиционными чисто программными системами системы машинного обучения всегда сложнее разрабатывать и поддерживать. Проблема применения векторных баз данных не является чем-то особенным. Лично я считаю, что сегодняшним векторным базам данных еще есть куда совершенствоваться. Но здесь я бы предложил практикам решать эти проблемы с помощью инженерных стратегий.
Прежде всего, нам необходимо провести больше исследований по техническим вариантам. Это включает в себя сравнение большего количества продуктов и проведение большего количества экспериментов для подтверждения широкого спектра функциональных и нефункциональных решений. Это означает, что после впечатляющей презентации MVP нам нужно немного подождать, прежде чем запускать крупный проект.
Во-вторых, общение. Успешный проект ML требует участия всех заинтересованных сторон. Однако машинное обучение до сих пор не является широко известной концепцией в большинстве компаний. Поэтому обязательно общайтесь со всеми разными сторонами. Например, нам нужно подробно обсудить это с владельцами продукта, чтобы найти правильный баланс между точностью и задержкой, и нам нужно сотрудничать с командой технического обслуживания, чтобы знать, как настроить гарантию стабильности продукта.
И последнее, но не менее важное: нам необходимо разработать стратегию управления моделями внедрения. Нам необходимо вести учет моделей и их сопоставление с векторными данными. Нам также нужна стратегия обновления базы данных при изменении моделей.
Эта статья ни в коем случае не пытается отговорить людей от применения векторных баз данных. Вместо этого я бы посоветовал инженерам машинного обучения ознакомиться с этой новой технологией, включая ее красоту и сложность.
