6 критических проблем при организации векторного поиска

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

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

1. Поиск векторов ≠ база данных векторов

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

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

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

Будьте очень осторожны с домашним «векторным поиском инфра». Не так уж и сложно загрузить современную библиотеку векторного поиска и начать путь к интересному прототипу по методу «приблизительно-ближайший сосед». Однако продолжение этого пути — это путь к случайному переизобретению собственной базы данных. Вероятно, это выбор, который вы хотите сделать сознательно.

2. Инкрементная индексация векторов

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

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

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

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

3. Задержка данных как для векторов, так и для метаданных.

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

Через какое время после «создания» вектора вам нужно, чтобы он был доступен для поиска в вашем индексе? Если это произойдет в ближайшее время, векторная задержка станет основным моментом проектирования этих систем.

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

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

4. Фильтрация метаданных

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

Покажите мне все рестораны, которые мне могут понравиться (векторный поиск), которые расположены в радиусе 10 миль и имеют цены от низких до средних (фильтр метаданных).

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

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

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

5. Язык запросов метаданных

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

С точки зрения базы данных, и поскольку это блог Rockset, вы, вероятно, можете ожидать, к чему я клоню. SQL — это стандартный отраслевой способ выражения подобных утверждений. «Фильтры метаданных» на векторном языке — это просто «предложение WHERE » для традиционной базы данных. Его преимущество заключается в том, что его относительно легко переносить между различными системами.

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

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

6. Управление жизненным циклом векторов

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

Ваша команда ML (или, может быть, OpenAI) выпускает новую версию своей модели внедрения. У вас есть гигантская база данных, заполненная старыми векторами, которые теперь необходимо обновить. Что теперь? Где вы собираетесь запустить это большое задание пакетного машинного обучения? Как вы собираетесь хранить промежуточные результаты? Как вы собираетесь переходить на новую версию? Как вы планируете сделать это так, чтобы не повлиять на вашу производственную нагрузку?

Задавайте трудные вопросы

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

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