Как стать автором
Обновить

Векторные базы данных: простым языком про устройство и принцип работы

Уровень сложностиПростой
Время на прочтение11 мин
Количество просмотров11K
Всего голосов 30: ↑29 и ↓1+35
Комментарии13

Комментарии 13

Сейчас рассматриваю OpenSearch (форк ElasticSearch), видел там в документации раздел по работе с векторами слов. Это оно самое, о чем речь в статье?

ИМХО смысла использовать OpenSearch нет, кроме как вместе с AWS OpenSearch. Во всем остальном Elastic лучше.

Эластик не дает доступ (403) к загрузкам из РФ, плюс лицензию изменил на негнушную. Я уважаю волю правообладателя, тем более если есть выбор. Поэтому смотрю в сторону полностью гнушного opensearch. В любом случае я предпочитаю более свободный софт. Да, это не технический вопрос, но всё же.

В OpenSearch и ElasticSearch используются различные реализации векторного индекса и разные схемы ранжирования при гибридном поиске. Год назад у ElasticSearch было ограничение на размер векторов не более 1500. Сейчас, вроде, уже 4096. То есть, Amazon была проворнее в разработке.

Если размещать приложения на AWS, то OpenSearch однозначно. В остальных случаях есть о чём думать.

Спасибо за интересную статью!

В одном из проектов для поиска по огромной базе FAQ сделал такую систему:

Для эмбеддингов использую Ada от OpenAi. Сначала «индексация» - векторизирую все вопросы и складываю в Qdrant;

Затем при по поиске - векторизирую вопрос пользователя и ищу 10 ближайших векторов, по которым нахожу ответы.

Вопрос, что будет работать также хорошо как Ada, но на моем сервере?

Как эффективно работает удаление вектора из базы? Нужна ли переиндексация ?

Это зависит от конкретной базы данных и от выбранного типа индекса, лучше уточнять в документации или смотреть исходники. Например, для weaviate и индекса HNSW используются tombstones https://github.com/weaviate/weaviate/blob/main/adapters/repos/db/vector/hnsw/delete.go и позднее очищаются https://github.com/weaviate/weaviate/blob/b59527994a85d35664bec7eb5acc8fa628318a86/adapters/repos/db/vector/hnsw/delete.go#L116-L167

Рад, что понравилось! Очепятку исправил)

pgvector упомянули, но как-то не развили. А тренд сейчас такой, что любая традиционная СУБД скоро будет иметь векторный индекс с приближенным поиском. Именно для того, чтобы команде разработчиков не надо было изучать новые сторонние инструменты. Собственно, PostgreSQL, Clickhouse, MariaDB, Cassandra уже их имеют. И во всех случаях - доступ к ним через язык SQL. В некоторых случаях, типа Snowflake Cortex, есть даже доступ к языковым моделям прямо через SQL.

+ https://superlinked.com/vector-db-comparison/

Допустим, в источнике написано, что событие произошло:
- в 1897 году
- в одна тысяча восемьсот девяносто седьмом году
- в конце 19 века.

А теперь приходит пользователь с вопросом:
"ищу событие наступившее за несколько лет до наступления XX века."
Как там векторы отработают?


Зарегистрируйтесь на Хабре, чтобы оставить комментарий