Когда (не) следует использовать Vector DB

Когда индексирование приносит больше вреда, чем пользы: как мы поняли, что для нашего варианта использования RAG требуется хранилище типа «ключ-значение», а не векторная база данных.

Делиться

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

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

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

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

Пример еды

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

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

Теперь остановитесь на секунду и задайте себе вопрос:

Где мне следует хранить эти векторные представления?

Источник: towardsdatascience.com