Comments 55
Как-то не очень понятно, как именно векторная база позволяет упрощать анализ изображений или медиа и так далее. Сама база ж не умеет работать с содержимым непосредственно данных.
Как я понял, она заточена под оптимизацию тегов и других метаданных, которые позволяют создавать сложные связи между данными.
Все остальное это уже варианты использования, так?
Соседей позволяет искать быстро. Это их киллер фича. Т.е не строгие совпадения
Тут ещё стоит добавить, что сами вектора могут позволять делать операции над ними. Соответственно вы можете сделать какие-то преобразования над "смыслами" и потом в базе искать что-то близкое к цели.
Условный пример (работает для некоторых видов эмбеддингов): если из вектора для слова "король" вычесть вектор для слова "мужчина" и прибавить вектор для слова "женщина", то вы получите вектор, близкий к вектору для слова "королева".
... вот только поиск соседей (похожих) далеко не самая частая задача для базы данных.
Спасибо за список бесплатных баз данных. Все хочу их попробовать.
Статья явно написана не человеком. Привет, Тьюринг!
Так а чем собственно такой "вектор" от строки в таблице отличается?
Зарплатой разработчика?
Типичный вектор - это массив из 500 чисел float32
Вектор эмбеддинга - это, на низком уровне, координаты точки в n-мерном пространстве, полученные в результате обработки нейросетью каких-либо данных. А на высоком уровне эмбеддинг - это самый что ни на есть "смысл" данных в представлении этой нейросети.
Полезность векторной базы лежит в её способности быстро находить "расстояния" между разными векторами, вытягивать близкие к определённому векторы, высчитывать схожесть по отдельным признакам, и так далее.
Оттуда и термин "векторные базы данных". Потому что классические реляционные базы не обладают нужным функционалом. В SQL нельзя сделать SELECT точек, ближайших к массиву из 2048 координат.
апример, в векторной базе данных можно предварительно рассчитать кластеры, такие как "животные" и "фрукты". При запросе базы данных на "Котенка" поиск начинается с ближайших животных, избегая расчетов расстояний между фруктами и объектами, не относящимися к животным.
в SQL можно сделать то же самое... В смысле предварительно.
А вообще все эти сравнения с SQL ради хайпа. Помню сколько его было лет 15 назад с No-SQL базами.... Но никуда требования знать SQL не делось )))
правильно. никуда не делись. no-sql заняли свое почетное место
Мне помню один товарищ рассказывал, что все эти новомодные fts штуки типа эластика нахер не нужны, и он всё тоже самое делает на оракле и plsql. Правда разобраться в этом мог только он(и то не факт), писалось два года, по скорости иногда было всего в 20 раз медленне чем Solar, а так да, не нужны эти ваши fts системы, и no-sql, и графовые бд. Только гениальные программисты и миллионы на ФОТ нужны. Их же всегда в достатке, да?
Векторные базы - отдельный узкоспециализированный тип. Универсальные базы они не заменяют и на это не претендуют.
На первый взгляд смотря как хранить, но остается преобразованиель "сущность"-"вектор" и обратно.
В SQL нельзя сделать SELECT точек, ближайших к массиву из 2048 координат.
А технически, как этот поиск осуществляется в векторной базе данныз?
Давольно просто: находится модуль вектора и угол между вектором и осями. и дальше вы можете сравнивать модули и углы. либо просто вычитать одни векторы из других, ища минимальную разность
Типа вот так, да?
Типа вот так, но только типичные размерности не 2, а 128-256-512 и выше (т.е. PostGIS сразу мимо), и время поиска должно быть лучше, чем фулл-скан.
Т.е. если взять постгрес и прикрутить ему в качестве индексного движка один из ANN-методов, то он тоже станет вполне себе неплохой векторной базой (а по сравнению с некоторыми - даже отличной векторной базой). Но у постгреса такого индексного движка нет, а у векторных баз есть.
Но у постгреса такого индексного движка нет
SP-GIST
SP-GIST вообще не об этом. Попытаться можно, но итоговая производительность будет очень грустной для реальных задач. Индустрия сдвинулась в сторону ANN (approximate nearest neighbor) не от хорошей жизни, а от того, что точные методы слишком медленные.
Вот pgvector по ссылке выше уже ближе, HNSW работает довольно хорошо.
ParadeDB - это Postgres с 2 векторными плагинами для работы со dense & sparse векторами прямо из SQL
Индексы тоже есть
в pgvector есть HNSW
SELECT * FROM items ORDER BY embedding <-> '[3,1,2]' LIMIT 5;https://github.com/pgvector/pgvector?tab=readme-ov-file#hnsw
Спасибо за публикацию. Векторные бд интересны для обратного реверса мышления, чтобы попробовать мыслить (например планировать) векторами. Как указано в эпилоге статьи, так удобно находить выбросы например.
Пока я встречал только кибернетические модели мышления у Бейтсона.
Если столкнетесь с моделями векторного мышления, буду рад если поделитесь.
Что ещё за векторное мышление? Расскажите подробнее пожалуйста. Речь о человеках, или о чём?
Речь о человеках. Кручу идею, что можно мыслить представляя не причинно-следственные связи, а векторы. Это должно быть удобно при планировании, т.к. можно представлять вектор изменения объектов во времени.
В статье хорошая идея, что качество объекта тоже можно представлять вектором, поэтому добавив параметр об изменениях качеств во времени можно реализовать эту идею.
Кажется, что с таким подходом можно более быстро и экономно думать.
Не очень понял, как в статью попала библиотека Faiss. Если говорить о библиотеках для быстрого поиска похожих векторов, то их нынче вагон, но к базам данных это никакого отношения не имеет.
Балансировка точности и скорости является ключевым аспектом при использовании векторных баз данных, которые предоставляют приближенные результаты.
Есть данные, какова приближённая точность результатов? Какова вероятность, что человека с фамилией "Кошкин" модель запихнёт в раздел "животные"?
Это вопрос к модели, которая вычисляет векторы-эмбединги. Векторному поиску всё равно к чему близость считать. Но в целом, эмбединги сильно зависят от контекста. На коротком контексте могут быть ошибки. Одно слово "кошкин" даст совершенно непредсказуемый вектор. А вот фраза "фамилия: Кошкин" - здесь уже любая современная модель даст вполне сносный результат и точно к животным это близко не будет.
вполне сносный результат
Есть конкретные цифры? Реляционные БД во всех случаях дают точность близкую к 100%. С векторными базами пока непонятно как работать. Кроме как в областях, связанных с самими моделями, я им применения пока не вижу.
Реляционные БД во всех случаях дают точность близкую к 100%.
Это в теории, а что в итоге будет на стороне пользователя - никому не ведома, кроме тех кто сам продукт делает.
Там же между самой базой и пользователем будет куча прокладок со своей логикой, которые сперва запрос исковеркают, а потом ответ сформируют.
Так что, если сравнивать точность ПРОДУКТА В ЦЕЛОМ, то хз что там получится.
Векторный приближенный поиск - это совершенно отдельное направление поиска данных. Чаще всего его используют как замену полнотекстового поиска. Или как рекомендацию похожего (например товаров). Но приближенный поиск абсолютно не годится для замены формальных фильтров по значению.
Например, если задача - фильтровать по фамилии - то СУБД с реляционной моделью будет идеальным решением. А вот если мы храним резюме и надо обеспечить поиск по навыкам - ситуация иная. Допустим имеем три резюме. У одного запись "программирую на Java, знаю Spring Framework". У второго "Использую в работе NodeJS, React, Anglular". У третьего - "разрабатываю приложения для браузера". А запрос получили "веб-разработка". Эмбединг этого запроса на основании статистического контекста модели типа GPT3.5, скорее всего, вытащит близкие вектора второго и третьего резюме. При этом, для обычного полнотекстового поиска, в этих фразах нет общих ключевых слов. Ну и общий подход при подобном поиске, что если мы потеряли какие-то конкретные записи - это не проблема в общей массе.
Векторые СУБД следует отделять от моделей эмбедингов. Как и то, является ли векторная БД точной или приближенной. Например, pgvector реализует два типа векторных индексов - точный, но медленный VFFlat и приближенный, но очень быстрый HNSW. При этом, в момент создания индекса мы сами можем решить на сколько HNSW-индекс должен быть точным и на сколько быстрым. Для этого у него есть параметры m и ef_construction (определяют топологию).
Касаемо цифр по точности, есть бенчмарки именно по векторным инструментам - https://ann-benchmarks.com/index.html . По точности см. Recall. Чем выше требуется recall, тем, соответственно, медленнее будет приближенный векторный поиск. В части же чистой производительности, см. другие бенчмарки.
Ну а по точности моделей текстовых эмбедингов - это совершенно отдельный разговор, который к СУБД отношения не имеет. Например https://huggingface.co/blog/mteb . Однако общий результат, действительно, складывается из качества эмбедингов и контекста + качество приближенного векторного поиска.
Я видимо слишком стар, потому что первое, что пришло мне на ум после прочтения названия и вступительной части статьи — СисОп Мицгол и его Гипертекстовый векторный ФидоНет.
Прощайте, базы данных, да здравствуют векторные базы данных
Ну, тут чел погорячился.
Тот факт что для хранения embedings лучше подходят векторные базы не имеет никакого отношения к общему понятию баз данных.
Векторная база данных против реляционной базы данных
И уж не стоит трогать реляционные базы.
Каждому типу данных своя база.
А почему бы не перевести Jeopardy как «Своя игра»?
Это тоже будет найдено, если исходная обучающая выборка модели включала не только виды кошек, но и игры. Причём найдено будет, если вектор-запрос будет ближе к кластеру игр. Но как по мне в этом сразу кроется и слабость такого представления данных. Получается, что оно "вылавливает" абсолютно все ассоциации, которые были в исходном наборе данных. Т е это всë ещё методы "грубой силы", всё равно что прямой перебор путей в графе или фул-скан таблицы в базе. Потому то обучение таких моделей требует такую уйму ресурсов и времени. В то время как человек ассоциацию "схватывает" моментально, достаточно один раз рассказать ему, что есть такая игра, у которой название такое же, как у большой кошки...
Не пробовали перевести ANN? Почему не классический kNN? Разница есть, и она важная. Как минимум написать о её существовании следовало.
Approximate Nearest Neighbor - приближенный ближайший сосед!
Т. Е. продуктовые требования к таким бд свои особенные, не факт что всем подойдут
Очень интересно, но ничего не понятно.
Реляционная база на примере животных как раз будет иметь справочник типов, где будут записи "животное" и "фрукт". Таким образом запрос отработает тоже быстро. А если векторная сама их определила и положила рядом, то как найти связь, когда мне нужно найти "кто из животных живёт у меня дома?" Т.е. придется писать больше условий как и в sql.
Может быть пример некорректен и это действительно работает быстрее с изображениями и видео в которых я не силен.
Как отлаживать качество данных, если я не знаю в какие и 1000 измерений положили мои 10 строк?
HNSW не собственный алгоритм qdrant, он появился до него, открыт и можно посмотреть тут: https://arxiv.org/abs/1603.09320
Какое-то время использовал собственную реализацию, затем появился qdrant, и перешел на них, т.к. продукт действительно удобный и рабочий. А главное, отличные разработчики, которые не забивают на проблемы и доступны для прямого общения.
Faiss не очень удобен в использовании, к тому же есть большое недоверие к разрабам фейсбука, которые постоянно умудряются делать на кроссплатформенных языках решения жестко привязанные к одной платформе.
Есть ли векторные базы, в которых можно быстро удалить 1 вектор и не пере-вычислять все индексы ?
Прощайте, базы данных, да здравствуют векторные базы данных