Comments 8
Так как в посгресе лежат уже просто векторы определённой размерности, то, как мне кажется, никто не помешает в них добавить ещё пару измерений. Например, если мы ищем похожие товары в интернет-магазине, то, наверно, можно попробовать добавить в вектора такие числа как "длина", "ширина", "цвет", и т. д.
Просто добавить числа не получится, их тоже надо как-то кодировать. Например, нужно понимать должны ли мы учитывать близость чисел друг к другу. Когда мы говорим о длине или ширине, то логично считать 99 более близким и похожим на 100, чем число 1. Но если это будут, например, номера категорий товара, то близость их номеров скорее всего не будет говорить о схожести.
Ещё при добавлении других признаков надо не забывать приводить фичи к одной размерности. Если у одной фичи диапазон значений от -10000 до 10000, а у другой от 0 до 1, то первая будет сильнее влиять на рассчет расстояния, чем вторая.
Понятно, что зависимость от API чужого сервиса — это плохо, поэтому можно попробовать сделать свою систему для получения embeddings. Я нагуглил пару способов, как это сделать на языке Go, но глубоко в эту сторону не копал.
Как альтернатива, использовать word2vec. Вроде для Go тоже завезли https://pkg.go.dev/code.sajari.com/word2vec
Было бы интересно сравнить результаты pgvector с решениями вроде FAISS и Qdrant. Дают ли они какое-то преимущество или наоброт проигрывают постгре.
Подобное достаточно просто реализовалось на N-gram лет 20 назад (поиск дубликатов в CRM). Можно даже на реляционных таблицах. Строка, переведенная в N-gram-ы по сути тот же вектор.
https://blog.arbinada.com/ru/category/00020.html
Зависимости от API как и от стоимости за OpenAI можно избежать, если использовать для генерации векторов одну из предобученных бесплатных моделей, например эту https://huggingface.co/cointegrated/rubert-tiny2. Основная проблема здесь в другом. Точность оценки сходства сильно снижается когда тексты существенно отличаются по количеству токенов. Так что от игрушечного примера до реального проекта этот кейс еще пилить и пилить. А так да, классная подмога FTSу
Это круто, конечно, что программисты научили поиск понимать, что "котик гонится за мышкой" и "кошка охотится на грызуна" это близкие понятия. Но что делать пользователю, который хочет найти именно "котик гонится за мышкой"? К сожалению, современные интеллектуальные поисковые системы этого не позволяют - не найдя "котика", они с чувством выполненного долга выдают пользователю "кошек" и "котят". А если и "кошек" не найдется - то есть "катет" и "Ниссан Кашкай", это же семантически близко, верно?
Кашкай гонится за Жуком
Это уже не проблема программистов, а проблема бизнес анализа/архитектора/дизайнера. Как пользователь, я хочу контролировать возможность поиска точных значений или "приближенных", значит мне нужно дать возможность управлять этим. К примеру поиск в гугле пользуется двойными кавычками.
Очевидно, в этой ситуации можно пользоваться аналогичным способом и это не изменит логики и не усложнит разработку.
Но что делать пользователю, который хочет найти именно "котик гонится за мышкой"?
Можно использовать специальные возмоности в поисковике, чтобы он нашел именно котика, почти все системы позволяют искать именно то, что хочет пользователь, но пользователю придется освоить нужные инструменты
Пишем поиск семантически похожих текстов (или товаров) за полчаса на Go и Postgres (pgVector)