Векторный поиск как новый способ думать о данных
Векторный поиск как новый способ думать о данных Недавно послушал выпуск Podlodka Podcast #445 — «Почему текстовый поиск устарел» с Андреем Васнецовым (сооснователь Qdrant), и честно — получил удовольствие. Подкаст длинный — почти полтора часа — но при этом лёгкий, без сложных фо
22-10-2025 09:04 (МСК)
Векторный поиск как новый способ думать о данных Недавно послушал выпуск Podlodka Podcast #445 — «Почему текстовый поиск устарел» с Андреем Васнецовым (сооснователь Qdrant), и честно — получил удовольствие. Подкаст длинный — почти полтора часа — но при этом лёгкий, без сложных формул и академичных выкладок. Андрей говорит о сложном просто, так что его можно слушать и за клавиатурой, и за уборкой квартиры — суть дойдёт в любом случае. Вот несколько идей, которые особенно запомнились: 🔹 Векторные базы — это не базы данных, а поисковые движки. Они ближе к Elasticsearch, чем к PostgreSQL. Им не нужна транзакционность — им нужны масштабируемость, отказоустойчивость и скорость поиска в памяти. Важно понимать границы применимости, как в примере про векторный поиск в PSQL, что похоже на попытку скрестить ужа и ежа, и для многих продакшн-задач не работает и скорее всего не будет работать. 🔹 Главный компромисс — не «скорость или точность», а «скорость И точность И память». Меня поразили цифры: средний вектор — 6 КБ. Умножьте на миллионы записей — и получаются гигабайты, которые для скорости должны быть в оперативной памяти. Решение? Бинарная квантизация, сжимающая векторы в 32 раза — и при этом теряющая всего около 5% точности (что, честно, поражает). Кстати, не путайте это с квантизацией самих моделей (как в LM Studio, про что будет у меня отдельное видео) — это разные вещи, хоть и объединённые общей логикой: «сжимаем, чтобы уместиться в реальный мир». 🔹 Интерфейс поиска придётся пересматривать. Андрей привёл отличную аналогию: в TikTok нет строки поиска — система учится на свайпах, паузах, повторных просмотрах. Это неявный фидбек, который гораздо естественнее для векторного пространства, чем текстовый запрос. Возможно, будущее поиска — в агентах, которые сами формируют запросы, или в интерфейсах, где пользователь даже не замечает, что «ищет». 🔹 RAG — главный use case, но не единственный. Крутой пример: обнаружение аномалий на кофейной плантации через сравнение векторов зёрен. Вместо обучения новой модели на каждый вид брака (пересушенные зёрна, плесень), можно один раз обучить модель на векторы «похожести». Новый тип брака? Просто добавьте его вектор в базу, и для анализируемого экземпляра будет искаться схожий класс. Элегантно, эффективно и без переобучения. Кстати, похожие задачи освящены в базовых курсах по машинному обучению, например, при анализе семян пшеницы, Часто оказывается, что простая кластеризация (вроде k-means) эффективнее бустинга, потому что цель — не классифицировать по известным меткам, а находить «похожее» или «непохожее». Интересно было услышать взгляд на эмбеднниги, RAG и векторный поиск не как исследователя, а как инженера, строящего систему в продакшене. Мой вердикт: Рекомендую прослушать всем, кто работает с данными, поиском или ML. Если вы используете RAG или просто хотите понять, зачем векторные БД выделились в отдельный класс систем — этот выпуск для вас. 🎧 Послушать / посмотреть https://www.youtube.com/watch?v=BOWq8JI-XNg ➡️ А вам что показалось самым интересным? Сталкивались ли вы с векторным поиском на практике? #ITИнсайты