Transcription
Всем привет, с вами очередной выпуск подкаста Подлодка. И сегодня мы будем говорить про очень интересную и увлекательную тему под названием векторные базы. Казалось бы, что кто-то, кто уже в теме, подумает, что о, снова выпуски про AI, но нет, мы будем обсуждать векторные базы в целом как сущность. Вот и сегодня у нас в гостях Андрей Воснецов. Это CTO и ко-фаундер Квадранта. Андрей, привет.
Привет. Спасибо, что позвали.
Да, и соведущим сегодня будет невероятный, прекрасный Егор Толстой. Егор, привет.
Да, я привет. Я очень, очень, очень скучал по выпускам про базы данных. У нас был какой-то невероятно крутой выпуск про базы, я не знаю, лет пять назад с Коле Головым. А где мы вообще поговорили про в там про разные виды баз данных, их свойства и прочее. И с тех пор, по-моему, из таких плюс-минус рядом лежащих выпусков нас только про SQL был, наверное, и про SQL Lite. По-моему, у нас было два разных отдельных или только про SQL, неважно. Короче, привет.
Да, и для начала хотелось бы, Андрей, э, спросить немножко контекста. Опять же, я, когда готовился, я успел там посмотреть и интервью у Осетинской и разное там другое, но расскажи, почему ты вообще эксперт по векторным базы данных, векторному поиску и так далее.
Почему я эксперт? Ну, это немножко, конечно, странно про себя такое рассказывать, но ладно, наверное, стоит начать с того, что, а, практически всю свою карьеру я в той или иной степени взаимодействовал с поиском, да. Э, то есть моя первая стажировка была в Mail.ru, Там, где ээ я занимался таким очень низкоуровневым бэкэндом поиском L.ruру, то есть такой webscale поиск. Потом я перешёл работать ближе к элю, но всё равно этот LL был в той или иной степени связан с поиском всячески реранжирование, всячески ну тогда ещё это был обычный поиск, да, потом это постепенно трансформировалось в векторный поиск. И, наверное, когда у тебя есть такой золотой молоток, то любая проблема кажется гвоздём. И каждую проблему хочется решать с помощью поиска. Наверное, в таком э контексте я докатился до состояния изобретения своего поискового движка. Наверное, так будет правильно объяснить, почему кто-то считает меня экспертом.
Давай тогда для начала, кто ещё не в контексте, как раз поговорим вообще, что такое векторная база данных, что такое векторный поиск и так далее.
А я вообще вопрос закину ещё более простой. Давайте, может быть, что вообще такое вектор в этом контексте?
Что такое вектор? Да, ну, то есть это, да, хороший вопрос. Ээ на него можно отвечать ну с разной степенью детализации. Мы, наверное, подразумеваем, что наша аудитория - это разработчики, которые знают более-менее, что такое ээ нейросети, да. Ээ начнём начнём где-то с этой части. В общем, вектор это такое замечательное представление какого-либо объекта в виде набора цифр. что это этот набор цифр отличается таким замечательным свойством, что если э два набора цифр, два вектора близко друг к другу в каком-то пространстве, там, допустим, вклидовом пространстве или чуть более ээ близком к практике косинусном пространстве, то это означает, что исходные объекты, которые ээ были конвертированы в векторы, они тоже в каком-то смысле близкие. И это свойство, оно возникает не само собой, оно возникает, потому что нейросети обучались таким образом, чтобы это свойство воспроизводить. Вот это такое довольно техническое объяснение, но я надеюсь, что кто-нибудь поймёт.
Смотри, ты рассказывал и сравнивал вот вектор и то, как это всё работает с тем, как работают цвета в RGB. Хотел тут уточнить. То есть в RGB, если мы понимаем, что у нас есть вот эти как бы три оси координат, назовём это так, и мы понимаем, как, э, численно это везде расставить. То есть у нас есть какой-то фрейм понятный. А вот как мне понять, вот все там эти примеры, что вот есть кот, есть кошка и так далее, есть там блин, есть сковородка для блинов и вот это вот всё. А как мне понять, вот какая размерность будет у вектора, какие там будут числа? То есть вот если у меня вообще ничего нет вот с нуля, как мне как мне это создать и осознать вот как что-то такое смысловое?
Э, размерность вектора - это, скажем так, гиперпараметр, который можно выбрать произвольным образом, да? То есть он он выбирается не от задачи, от того, сколько у нас есть времени ждать, пока обучится модель, сколько у нас есть времени ээ да ждать, пока произойдёт поиск. Вот это вот это то, на что влияет размерность вектора. И обычно, чем она больше, тем лучше при этом качество, тем больше информации мы можем затолкать в этот вектор. Если обратить внимание на типичный размер векторов, они все обычной степени двойки. И это не случайно, это такая оптимизация. Вот все очень, я надеюсь, программисты любят, когда все числа являются степенями двойки, потому что тогда они очень красиво ложатся в память. Ну, с точки зрения, э, пользователя, размерность, она как бы мало на что влияет, кроме, э, собственно качества и скорости.
А если если копать дальше, да, то есть как как понять, какие цифры туда засовывать, то мы, грубо говоря, не знаем, какие, э, это процесс не аналитический, это процесс обучения нейросети. То есть нейросеть ээ сама как чёрный ящик какие-то цифры подбирает через процесс обучения, но мы сами руками расставить это, скорее всего, не можем, да? То есть мы можем придумывать какие-то признаки. Э даже если мы придумаем признаки, мы не знаем, насколько они важны относительно друг друга, например, да? То есть это, э, непрактично. Это, скорее всего, не будет работать так хорошо, как, э, работало бы, если бы мы обучили модель. То есть, условно говоря, вот мы даём модели некий фиксированный размер вектора и говорим ей: "Упакуй сюда как можно больше разной информации таким образом, чтобы, э, минимизировать ошибку обучающей выборки. Обучающая выборка состоит в основном из ну это называется триплета, но условно говоря, давайте скажем, что это пары, пары объектов. И нейросеть видит пары объектов. И какие-то пары помечены, что они должны быть похожи. Какие-то пары объектов помечены тем, что они должны быть не похожи в результате. И нейросеть пытается так подобрать цифры, чтобы похожие объекты оказались близко, а разные объекты оказались далеко друг от друга.
Но векторный поиск, он же появился ещё до появления нейросетей.
Ну сложно, наверное, так сказать, что конкретно первым появилось. Ну да, вектор можно составить и без нейросетей. То есть RGB, например, это такой, э, ну, хороший пример, э, вектора, да, который мы руками можем собрать. Мы также можем собрать вектор из признаков, да. Вот, например, мы, э, описываем какого-нибудь человека, например, и в качестве признаков мы там напишем его рост, напишем его вес, напишем, сколько у него оценка в вузе по математике. Это будет всё наборы признаков, которые тоже можно засунуть в вектор какой-то условный, правильно? Но этот вектор, он очень навряд ли будет хорошо соответствовать вот этому качеству, что близкие вектора будут генерировать похожих друг на друга людей. Просто потому, что нам очень сложно так отмасштабировать эти признаки. чтобы векторное пространство было хорошо организовано, да? То есть это, в принципе, можно сделать. И, например, поиск ближайших соседей как алгоритм, вот он может работать просто на вручную подобранных признаках. Просто это не настолько впечатляюще, как ээ нейросеть может. И в целом, если как раз вот возвращаться к векторным базам, почему в итоге они вообще появились и чем вот поиск по вектору в этой базе отличается там от текстового поиска и так далее. Давайте так скажем, что векторный поиск как такая массовая технология, он появился примерно в тот момент, когда начали появляться открытые, доступные модели, которые могут генерировать это вектора. А до этого момента векторный поиск, конечно же, тоже существовал, но он существовал как такой очень эксклюзивный продукт для больших корпораций, которые могут себе позволить. И в первую очередь большие корпорации могли себе позволить именно обучение таких нейросетей, которые генерируют хорошие вектора. То есть например Google мог себе позволить, это Facebook мог себе позволить, э, какой-нибудь стартап на 150 человек уже не мог. У него не либо не было экспертизы, ли либо не было достаточно данных. Ээ и вообще это довольно такой рисковый процесс. можно много всего сделать неправильно в процессе обучения и потратить кучу времени и не добиться практически никакого результата. То есть это такой нетривиальный процесс, который сложно формализовать, который требует много экспериментов. Вот. Но как только появились, э, общедоступные бесплатные модели, э которые любой человек мог скачать и начать использовать хотя бы для General Purpose задач, типа поиска похожих текстов, векторный поиск сразу стал намного более доступен. И встал вопрос: а как, собственно, хранить эти вектора? где их, э, а, содержать, как, как по ним быстро искать, как сделать, чтобы это было удобно. А опять же на этапе больших корпораций, на этапе Фейсбука и Гугла эти задачи они они были окрашены немного в другой аспект, да? То есть, э, удобство было на втором плане, на первом плане было масштабирование. И практически весь ресч, вот академические статьи, они были направлены на то, как сделать так, чтобы векторный поиск там масштабировался до миллиардов триллионов векторов на десятках и сотнях машин в огромных кластерах. То есть это как бы была проблема номер один для векторного поиска тогда, потому что основной потребитель векторного поиска был корпорацией, который, которым нужно был именно такой масштаб. А с появлением общедоступных ээ нейросетей этот масштаб начал понижаться. Ну то есть это уже не только не только Гуглу надо было, но и какому-нибудь условному eкоммерц магазину. им это стало доступно. И встал вопрос такого удобства, можно сказать, как и где и и с помощью каких инструментов с этим всем нужно взаимодействовать.
Да, тут как раз хотелось бы понять как вообще работают векторные базы, то есть как одновременно хранить кучу векторов и при этом быстро их искать. Тут, наверное, надо сказать нашу стандартную catchфз, что векторные базы - это на самом деле не база данных, потому что, да, это такой маркетинговый термин, который прижился просто потому что, наверное, его выговаривать легче. Эн как-то ассоциируется проще, в памяти остаётся. Но, по-хорошему, векторные базы данных практически все, которые именно специализируются на векторах - это поисковые движки, да? То есть их архитектура, она больше похожа на поисковый движок типа эластика, нежели на э такую типичную базу данных, как постгроз. А этом много причин. В первую очередь, э, основное - это то, что вектора - это не какая-то новая информация, которую нельзя ни откуда больше получить. Вектора - это всегда трансформация какого-то исходного объекта, какого-то исходного текста, какого-то исходного набора данных, который мы условно называем source of truth, а и который, э, всегда можно трансформировать ещё раз и получить вот эти самые вектора. А,
то есть сейчас, извини, то есть это ты говоришь не данные, а функция, по сути, трансформация и кэш какой-то результатов этой функции.
Да, да, какой-то кэш, кэш результат функции - это то, что мы называем векторами, то, что мы кладём в векторную базу данных, которые на самом деле поисковый движок. Наверное, я всё-таки буду использовать термин векторная база данных, просто потому что его легче произносить на русском языке. Но нужно как бы иметь иметь в виду, что там достаточно большая архитектурная разница между классическими базами данных и тем, что делают векторные базы данных. И про это мы можем, кстати, отдельно поговорить. Это довольно интересная тема, как по мне, техническая. Мы любим. Так вот, имея эти трансформированные данные, а нужно учитывать несколько вещей. Во-первых, они могут меняться. В любой момент может выйти какая-нибудь новая версия модели, и мы захотим выкинуть старые вектора и построить новые вектора, которые будут там в каком-то виде лучше, больше, точнее, эффективнее там. Who knows what? И второе, что вектора сами по себе - это довольно дорогая вещь. То есть они зачастую намного больше, чем исходные данные. То есть, если текст там 50 слов - это условно 100 байт, то средний размер вектора с текущими самыми, а, популярными моделями - это 6 Кб на один вектор. Э довольно много. То есть, если представлять себе какую-нибудь типичную таблицу в базе данных на миллион строк, таблица на миллион строк - это мало по современным стандартам это любой фаритир ээ в любом клауде может миллион строк в таблице держать. Но как только миллион строк умножается на 6 Кб, у нас внезапно оказывается 6 Гб данных, которые при этом должны быть как-то быстро, э, доступны, то есть они не могут лежать на очень медленном диске. Лучше всего, если они будут лежать в памяти. То есть это такая очень дорогая вещь с точки зрения машин, которую если положить рядом с source ofсом, она просто перевесит это и затмит с собой оригинальные данные, оригинальный casйс. То есть то, что база данных раньше делала очень быстро, э, и просто, просто за счёт того, что там было не очень много данных, с векторами становится, ну, намного тяжелее. А поэтому для векторов э хорошо бы иметь что-то отдельное, что изолировано от основного ворклоуда, что можно в любой момент перестроить, что можно в любой момент как-то переключить с одного инстанса на другой. Это как бы такая good good practice. Это справедливо. В принципе, не только для векторов, это для текстов и текстовых индексов тоже справедливо, но, возможно, в меньшей степени. Просто за счёт того, что текстовые индексы проще и дешевле с точки зрения машины. А вектора тяжелее.
А условно завекторированный, назовём это, понимаешь, нет такого слова. а-а, текст и то же самое векторное представление картинки, по весу это будет одно и то же или это будет может быть в разы отличаться?
Угу. Ну, это, на самом деле, полностью зависит от модели, которую мы используем. Ээ, есть модели, которые генерируют большие вектора для текстов, есть модели, которые генерируют маленькие вектора для э картинок. То есть это как бы всё всё всё кастомизируемо. Из интересного, релевантного, наверное, стоит отметить, что есть такие модели, которые универсальные для картинок и для текстов. То есть это такой мультимодальные модели, они так называются. А и весь прикол в том, что они обучались, то есть и их обучающие данные состоят одновременно из картинок и из текстов. И эти картинки и тексты, они сопоставлены между собой. Ну то есть, э, простой, ну, точнее, даже не простой, а самые популярный, самый известный кейс - это, а, модель называется cliли, и она обучена на датасете, который называется Lion. Датаasсет Lion - это что такое? Это, э, скравленный интернет, в котором, э, каждая найденная картинка, если она проассоциировано с неким заголовком, с неким альттекстом, это такой обучающий пример, что как только вот в любом в любом сайте в интернете вы нашли картинку, у неё есть подпись, то вот это пара таких позитивных позитивный пример, то какой текст должен соответствовать какой картинке. И таких картинок в интернете, ну, несложно догадаться, очень много. Сам датасет, по-моему, самый большой его вариант с составляет 5 млрд пар текст картинок. И вот такой датасет используется для обучения мультимодальной модели, которая и текст, и картинки превращает в вектора, которые находятся в одном пространстве. То есть мы можем сравнивать то, насколько текст близок к картинке и насколько картинка близка к тексту, соответственно. То есть мы можем искать картинки по текстовому описанию и наоборот текст по карти картинковому описанию, если так можно выразиться.
А можно какой-то тоже вот житейский пример, как картинка кодируется в вектор. То есть, если с текстом я, например, понял, опять же, вот есть эта аналогия про RGB, с картинкой, как будто бы чуть сложнее. Там тоже используется кодирование как раз вот альтекста, описания. или какие-то более хитрые штуки.
На самом деле, э я бы сказал, что с картинкой происходит даже проще, чем с текстом, потому что картинка - это такой, ну, более-менее непрерывный сигнал, да? То есть каждый пиксель картинки - это, условно говоря, число, а, даже там три числа, да? А, и эти три числа, их понятно как подать на вход нейросети. То есть есть такие свёрточные нейросети, которые могут преобразовать по сути любое изображение в какое-то внутреннее представление нейросетей, дальше его обработать и превратить в вектор. То есть на самом деле для картинок это проще. Картинки как бы, наверное, даже раньше начали обрабатываться нейросетями, чем тексты. Вот для текстов сложнее. Тексты сначала преобразуются в токены. Токенам соответствуют некое некие базовые вектора, э, обученные каким-то специальным особым способом. И затем эти базовые вектора, да, там через, ну, современная архитектура - это трансформеры, через трансформеры преобразуется вектор. Вот. Но если мы говорим о клипе, да, вот этой модели, которая мультимодальная, то она не использует заголовок картинки как вход. Она использует именно саму картинку. И в этом её прелесть, что мы можем взять любую картинку и эту любую картинку превратить в вектор.
А как всё-таки получается, что вектор полученный, я не знаю, из я не знаю, картинка собаки. Вот как получается, что вектор картинки собаки лежит близко с вектором слово Давай даже усложним словосочетание сутулая. Вот.
Да, да, давай. Так, вот вот у нас есть 5 млрд, э, картинок из интернета. А очень большая вероятность, что кто-то, э, что-то похожее, э, в интернете выложил, да? То есть он выложил фотографию собаки и написал: "Это моя псина". Вот, э, это как бы является положительным примером, да? То есть мы говорим нейросети, что если ты встречаешь вот такую картинку и такое слово, они должны быть вместе. Дальше встаёт вопрос: "А, а где отрицательные примеры?" Ну, то есть у нас же нету, э, каких-то там специально размеченных картинок и ээ слов, которые вот точно не должны быть похожи. И тут, на самом деле, целая целая область исследования, как достать отрицательный пример. Самый простой, самый такой интуитивно понятный, это мы просто берём случайную картинку и случайный текст и говорим: "Вот это не похоже", скорее всего. Ну, то есть там есть маленькая вероятность, что они будут похожи, но это на уровне шума, да? То есть 99.9%, 9%, что это будет вообще не связанные между собой картинки тексты. И вот мы говорим нейросети, вот у тебя есть положительные примеры, вот у тебя есть отрицательные примеры. Пожалуйста, поменяй веса внутри себя таким образом, чтобы вектор, который мы получили из текста, он был чуть-чуть ближе к собаке, да, к картинке собаки и чуть-чуть дальше от всего остального, что мы называем негативными примерами. И мы так делаем, э, много миллионов миллиардов раз. Если у нас там датасет 5 млрд и мы делаем несколько эпох, то да, это очень долгая долгий процесс. Он занимает там дни, недели на большом количестве железа, но в итоге мы получаем такое векторное представление, которое вот это наше свойство как-то отражает.
А что делать с примерами? Ну, наверняка из 5 млрд есть где-то картинка какого-нибудь вокзала, где подписано место, где пахнет псиной. Вот это вроде и не негативный пример, и не позитивный.
Нет, это, да, это как бы шум. Ну, то есть в каждом датасете есть какой-то уровень э плохих примеров некачественных. И тут возникает такой момент, что модель она как бы не может запомнить всё вообще. У неё ограниченная ёмкость, правильно? Поэтому она должна выбирать между тем, чтобы как бы вывести какие-то общие принципы. и запомнить какие-то конкретные примеры. Если мы сделаем всё хорошо, если мы настроим процесс обучения таким образом, чтобы он игнорировал такие аутлайеры и фокусировался больше на общих принципах, то наша нейросеть будет работать хорошо. Это не гарантирует стопроцентное качество, конечно, но такое допущение, что среди 5 млрдов если даже у нас будет, скажем, 10% шума, 10% плохих разметок, то это не очень сильно повлияет на итоговое качество. Тут, наверное, хотелось бы немножко вот, да, ещё вернуться на уровень обычных смертных и понять, а чем не устраивал просто поиск, почему, э, нужен был векторный поиск.
Ну, на самом деле, много очень примеров. И тот пример, который мы только что ээ обсудили, это как бы один из них. То есть как обычным поиском искать картинку по тексту. Это на самом деле, да, самый интересный кейс. Может быть, он сейчас не самый популярный, потому что все ударились в LMAG и прочее. Но это очень такой показательный пример того, что можно сделать с векторным поиском и что практически никак нельзя сделать с обычным. Э то есть ну есть есть много других примеров. Если мы говорим об обычном текстом поиске, то, как правило, он работает хорошо, когда у нас есть большие документы с большим количеством слов и короткий запрос. Это такой лучший bestкей сценарию для текстового поиска. Большой документ хорош, потому что в нём много слов и увеличивается вероятность, э, правильно сформулировать свою мысль, да? То есть, э, нам обязательно использовать именно тот синоним, который используется в документе, чтобы он совпал. А короткий запрос хорош тем, что просто если он будет большой, то это слишком дорого для обычного текстового поиска. Он превращается в полный перебор и, ну, как правило, он не не настолько эффективен. То есть можно провести эксперимент, попробовать вставить в текстовый поисковый запрос, там 150 слов и сравнить, насколько он станет медленнее из-за этого. И медленнее он становится практически линейно. Вот поэтому это там ещё одно ограничение текстового поиска. Поиск на разных языках это тоже, э, интересный пример, да. То есть вот мы, у нас есть один пример, что мы обучили соответствие картинок и текста между собой, но никто нас не останавливает от того, чтобы обучить соответствие текстов на разных языках, одному вектору, например. И тогда становится уже неважно на на каком языке документ и запрос. Если нейросеть всё преобразует в такое универсальное векторное пространство для смысла, а не языка, то тогда поиск будет работать без перевода. Э поиск будет работать, ну, практически из коробки.
А вот тот пример, который ты называл, где хорошо работает обычный поиск, там векторный работает плохо или тоже хорошо? Просто по-другому?
Безусловно, есть сценарии, где традиционный текстовый поиск работает лучше, чем векторный. Например, когда мы хотим найти какие-то документы с артиклями или с какими-то цифровыми идентификаторами, которые не несут в себе смысла, да? То есть надо понимать, что вектор - это ограниченная по объёму информации сущность, правильно? То есть мы не можем в фиксированного размера вектор засунуть в бесконечность разных слов, да, он всех их не сможет запомнить. А и тем более он не сможет их запомнить, если это какой-то уникальный токен, который даже, может быть, не встречался в обучающей выборке, когда мы обучали нашу модель. Поэтому такие примеры их, скорее всего, векторный поиск не найдёт вообще. Если у нас там артикль или какой-нибудь UU ID, например. По этой причине, кстати говоря, а очень плохо работает идея построить поиск по логам на векторном поиске. То есть, если у вас есть какой-нибудь сервис и вы выгружаете логи, ээ то там, скорее всего, только обычный текстовый поиск вам поможет, а векторный поиск будет очень плох. Затем есть какие-то, а, ну, специальные области. как бы домены знаний, ээ, которые очень, э, богаты на какие-то специфичные для себя термины, скажем, медицина, а, или какой-нибудь, э, химия, да, то есть вот эти все названия веществ, которые, э, в обычном, в обычной жизни редко встречаются, имеют смысл только для специалистов. Скорее всего, в таких случаях модель, обученная на общем корпусе текстов, будет работать довольно плохо, да? То есть нужно либо обучать специализированную модель на конкретном, на конкретной области знаний, либо использовать стандартный текстовый поиск. Но как бы хорошая новость в том, что никто не запрещает делать и то, и то одновременно. И это как бы, наверное, сейчас такой дефолтный подход к поиску. Нужно делать и и векторный поиск, и обычный текстовый поиск, а потом совмещать результат.
А при этом векторный поиск он же, ну, получается, ему энное количество лет, то есть с обычным поиском всё понятно, он уже модернизировался десятилетиями. Да, вот как ты считаешь, эээ если просто там смотреть на какую-то кривую развитие, то в векторных базах, векторных поисках и как это уже всё довольно хорошо оптимизировано или ещё там непочатый край для развития улучшений и так далее.
А, ну я бы сказал,
Что основной источник оптимизации для векторного поиска является компромисс, как ни странно, да? То есть, ээ, на самом деле сама операция сравнения векторов — это очень тривиальная штука, да? То есть, э, в большинстве сценариев это используется dot production, э, как он по-русски называется? Скалярное произведение векторов. Вот скалярное произведение векторов — это то, что оптимизировалось в компьютерах там, начиная с 1950 года. Самое примитивное, что вообще может быть, а-а, самое часто используемое. И из-за этого оптимизировать конкретно Dot Production, ну, довольно сложно.
А с другой стороны, а когда мы имеем дело с векторами довольно большой размерности, то нам, может быть, не всегда нужна абсолютная точность этого скалярного произведения. Может быть, нам даже не всегда нужна абсолютная точность самого поиска, да? То есть, э, найдём мы, э, вектор, который абсолютно самый близкий к нашему среди миллиарда векторов, или мы найдём вектор, который отличается там на одну на одно значение там после запятой трёх нулей, да?
>> А что это значит на практике? Как мне ээ понять, что мне вот дали сейчас ровно то, что я искал? и потратили на это огромное количество ресурсов или как раз дали неточное произведение скалярное и показали мне что-то около. Я это вообще пойму сам на человеческом уровне?
>> Скорее всего, нет. Скорее всего, нет. Потому что, а, в принципе, когда есть датасет, который, э, имеет миллионы, э, похожих картинок, э, там, например, или похожих текстов, э отличия такого такого рода они несравнимо несравнимо меньше, чем а отличия, которые дают между собой разные модели, ээ, которые, собственно, вектора производят, да? То есть, э, разница есть, но она проявляется, скорее всего, только на бенчмарках. То есть человек сам, смотря на результат, скорее всего, не поймёт разницу. Но посчитать чисто механически мы его можем. На самом деле на достаточно больших объёмах, даже на бенчмарках довольно проблематично посчитать точность, потому что, ну, чтобы считать точность, нужно, на самом деле, сделать поиск сначала перебором, да, а потом с помощью, э, векторной базы, да, условно скажем, назовём это так. Аа и только тогда сравнить результат. Но вот этот поиск полным перебором, он настолько медленный, что для того, чтобы на набрать какую-то достаточно большую выборку примеров, нужно там день потратить, просто потому что этот поиск настолько медленный, настолько большом объёме данных.
>> А как вообще ищется вот этот компромисс между скоростью и точностью? А как ну я понимаю, что есть какие-то опять же, наверное, тестирования. Э, но в какой момент и каким образом понимается, что вот такой уровень точности уже как раз заметен человеческому глазу, и он уже не удовлетворён результатами векторного поиска.
>> На самом деле, самое главное для нас, как для тех, кто строит векторные базы данных — это, э, сам факт возможности такого компромисса, потому что это, ну, нетривиальное решение, которое, например, в текстовом поиске, по-моему, никто не делает. В текстовом поиске всегда результат абсолютно идентичный, да? То есть он всегда абсолютно точный. Сам факт этого компромисса позволяет нам построить такой индекс, да, специализированный на вектора, который, э, допускает саму возможность неточного результата, не абсолютно гарантированно стопроцентного результата. И уже внутри этого индекса там есть свои параметры, которые можно по-всячески подстраивать, крутить, ээ, подтюнивать, чтобы в каждом конкретном приложении этот компромисс, эээ, пользователь сам для себя мог выбрать, да? То есть мы предпочитаем это решение про э точность против скорости переложить на пользователя, потому что мы, в общем-то говоря, не знаем, кому какую какая точность приемлема. Например, если мы там делаем какую-нибудь биометрию, то там точность намного важнее, чем в поиске смешных картинок в интернете. Вот. Э, но сам факт такой возможности и сам факт, э, существования индекса, который позволяет делать, выдавать не абсолютно точный результат, он как бы позволяет, ээ, в общем-то, сделать интерфейсы даже, которые тоже подразумевают, что точность будет не всегда стопроцентная.
>> А есть какие-то компромиссы, которые вот вы решили за пользователя и всё? и уже никак иначе, там, не знаю, хранение данных, где оно будет, ээ, ещё какие-то истории.
>> Ну, на самом деле, наша философия такого он сорса, она скорее подразумевает, э, открытие для пользователя всех возможных конфигураций, да, которые можно всячески настраивать. Э, с одной стороны, это хорошо, если пользователь знает, что он делает. С другой стороны, конечно, на грабли наступить довольно просто. Просто сделать такую такую настройку, такую конфигурацию, которая, ну, будет просто не жизнне способна. Это как бы уже такой дизайн decisionн того, какой продукт мы делаем. То ли мы делаем Cloud Native, который как бы предполагается, что будет использоваться в основном или только в в клауде только как коммерческий продукт или мы делаем open source toolso, которая доступна, условно говоря, для всех. И как они, как пользователи захачат как они будут извращаться с применением этой толзы. Это уже как бы их ответственность, если они что-то сломают, они сломают это у себя, а а не в клауде. Вот. Но у нас у нас довольно много всего открыто прямо для пользователя. Это как бы с одной стороны проблема, с другой стороны бонус.
>> А у всех так? Понятно, что сейчас огромное количество инструментов. Как бы в чём вообще >> различия между ними, особенно с учётом вот этойной моды на вектора?
>> Нет, естественно, у всех по-разному. Кто-то строит векторный поиск с прицелом на то, что он обязательно должен быть как такой cloud продукт. А и на самом деле, если ты строишь его как cloud продукт, то с точки зрения cloud он будет намного более, э, легко вписываться в инфраструктуру. Аэ можно там менять внутренние форматы, можно обновлять внутренние версии. Если это не портит интерфейс для пользователя, то он это, скорее всего, даже и не заметит, и у него нету способа это контролировать. А если мы строим open source продукт, то тут совсем другая история. Мы не можем контролировать, что пользователь там у себя сделает. Мы можем только допускать, что вот он хотя бы следует инструкциям по обновлению версий. И всё. Существуют, конечно, и версии посередине, существуют версии, которые были cloud продуктом и стали открытыми. Существует наоборот, как мы, например, сначала open source, потом переезжаем в cloud, э, и там начинаем накатывать всяческие ограничения сверху сорса. Там историй как бы очень много разных. Сложно сложно придумать. Наверное, самое интересное — это поговорить про разделение storage compute. Это такая популярная тема в базах данных и в поисковых движках. А основная идея заключается в том, что вот у нас есть Amazon S3. Amazon S3 очень дешёвое хранилище. Да, у него там может быть скорость не такая быстрая, но как бы если если скорость не является приоритетом номер один, то почему бы и нет, да? Почему бы не выгрузить всё, всё в S3 э вспомнить э процессоры, да, условно, машины для вычислений уже как бы независимо от хранилища? Вот, то есть есть есть решения, которые именно на это архитектурное решение опираются как на основополагающие, строят свой векторный поиск, исходя из этого. Это как бы история не про нас, то есть у нас у нас другой подход, но как бы это тоже валидное архитектурное решение, которое закрывает какую-то нишу.
>> В чате задавали вопрос про то, что уже появляются какие-то векторные фичи в классических базы данных типа постгреса. кликхауса и так далее.
>> Ну, я бы не сказал, что кликхаус — это классическая база данных, но, допустим, >> о'кей. Вот вообще с учётом вот таких вот трендов, каким образом это повлияет на именно вот отдельные целиком направленные на векторный поиск инструментах, >> да?
>> Ну, как мы уже, наверное, в начале поговорили, э вектор, э, и векторный поиск — это не тот workклод, который хорошо сочетается с классическими базами данных, которые любят транзакционность, и с классическими базами данных, которые любят персистентность всего. Это такой, э, архитектурный паттерн, да, который нам многие слышали. AC, то есть это то, то то, на чём строятся вот эти классические базы данных, типа Постгрос. Аэ, этот подход он несёт в себе как преимущество, да, так и фундаментальные ограничения. Очень сложно э сделать реплику для постгороса, да, то есть там оно оно не будет полностью как бы идентично. Потому что всегда нужно, чтобы была какая-нибудь главная реплика, остальные бы её слушали. Очень сложно, например, делать джойны таблицы, если эти таблицы находятся на разных машинах. А эти все ограничения, они как бы имеют смысл, если ты работаешь с данными, которым нужна транзакционность. Векторам транзакционность не нужна. Это вообще не source of tr. Аэ для векторов намного важнее, чтобы, а, вот этот сторедж, который мы используем, он мог, например, легко масштабироваться, потому что бактора большие, они редко влазят на отдельную машину. Мы хотим построить распределённый кластер. Мы хотим сделать так, чтобы этот кластер работал, даже если какие-то машины в нём упадут. То есть, ээ, соответственно, F tolerance нам нужен. И нам нужно eventual consistency, да? То есть нам нам нам не обязательно, чтобы наш апдейт применялся сразу гарантированно на все узлы. мы можем пережить, если что-то обновилось там на одной ноде раньше, чем на другой, например. И за счёт этого для векторных для векторных поисковых движков, да, э, сильно расширяется возможность их применения. Конечно, если мы говорим про тоткейс, когда а мы не упираемся в ресурсы вообще, если мы говорим про тот ззкейс, когда там всё очень хорошо влезает на одну машину, а влезает даже до тех пор, пока мы можем там держать две копии. Если мы хотим там перейти с одной модели на другую, нам нужно две копии в какой-то момент иметь. Если это всё влезает на одну машину и мы не упираемся в производительность, то, конечно, можно использовать вообще любой инструмент. Но если мы говорим про какой-то более-менее большой масштаб, то я думаю, что тут не только для векторов, но и для текстового поиска э обычной традиционные базы данных не подойдут. То есть, отвечая на другой вопрос из чата, вряд ли когда-то векторные базы сольются с классическими базами данных и всегда будут неким таким отдельным классом систем.
>> Ну, всегда будет место для, э, векторных баз данных, построенных по принципу поисковых движков, а не традиционных SQL баз, да? То есть какие-то юзкейсы, естественно, закроют такие гибриды, такие там плагины для постгроза это закроют. Естественно, это будет. Но как бы при этом всегда будут существовать э те сценарии, те э масштабы, на которых э специализированное решение просто, ну, необходимо. А как вообще понять, что вот я, например, что-то разрабатываю и вот ощущаю, что мне очень сильно нужна векторная база данных, векторный поиск. Какие есть вообще вот самые яркие кейсы практического применения?
>> Сейчас с появлением CH GPT, с появлением LLM доступных всем самый частый кейс применения векторного поиска — это так называемый рак. Retrieval Augmented generation. Суть суть в том, что, ну, все знают, что языковые модели галлюцинируют. Все знают, что языковые модели не обладают доступом там к последней информации, э, какой-то приватной информации, на которых они не обучались. Э, поэтому им надо расширять контекст информации, которая релевантна текущей задаче. И такой самый straightйтфорвард, способ расширения контекста для [музыка] текущей задачи — это сделать поисковый запрос, найти релевантные документы и их засунуть прямо вот в промпт, который в который в котором мы, собственно, и спрашиваем наш вопрос. Это такой рак версия ээ 1.0, да, который появился, ну, наверное, уже 2 года назад. Это сейчас, наверное, 80% всех юзкейсов, которые, ну, например, мы видим на нашей платформе. С одной стороны, это, конечно, грустно, потому что, ну, хотелось бы больше интересных всяких разных применений, хотелось бы больше чего-то, ну, нестандартного, но как бы практика показывает, что вот сейчас это нужно всем больше всего. Можно сказать, конечно, что векторный поиск не уникален в этом случае, да? То есть мы могли бы даже и обычным поиском воспользоваться, чтобы сделать то же самое, но а здесь вопрос возникает, а насколько качественно обычный поиск может это сделать в том случае, если мы именно работаем с маленькими документами. А работаем мы с маленькими документами, даже не потому, что они у нас сами по себе маленькие, а потому, что мы их разбиваем на маленькие чанки, на маленькие фрагменты, чтобы не засорять контекст и звуковых моделей всяким нерелевантным барахлом, кото за которое нам придётся платить, если если мы его туда добавим. А если вот смотри, если брать и так фокусироваться на кейсе с раго, есть ли какие-то конкретные, э, не знаю, фичи векторных баз, которые именно вот для кейса рага помогают их заточить или там не фичи, а, я не знаю, требования к ним? То есть вот что делает именно конкретный векторный поисковый движок классным конкретно для рага?
>> А, ну есть некоторые функции, которые скорее утилитарные, да? То есть, например, э, ну, из практики становится известно, что много, э, сценариев использования урага, они завязаны на множество независимых как бы подмножеств документов, да? То есть это то, что мы называем mittency. То есть, условно говоря, есть какой-нибудь коллекция или, э, веб-сайт, который хранит документы. Но каждая организация, зарегистрированная на этом сайте, она имеет доступ только к своему подмножеству документов, да? То есть условный Notion, да? Вот, но - это хороший пример. У каждой организации есть свои свои какие-то workркпейсы, а, и нужно производить поиск только по ним. При этом как бы масштаб может быть совершенно разный. Есть организации, которые там создали две странички и всё. Есть организации, которые там на 1.000 человек и миллионы документов. Вот, э, это всё нужно как-то эффективно, э, складировать, да? То есть мы не можем просто создавать отдельный инстанс на каждого такого пользователя, потому что это просто будет очень дорого. Нам нужно как-то их эффективно хранить вместе, желательно там в одной коллекции, в одной таблице, не переплачивать за глобальный поиск, который, в принципе, никогда никому не будет нужен. Ещё раз нужно, да, отметить, что для того, чтобы построить векторный индекс, нужно потратить очень много ресурсов. А, и чем больше документов у нас есть, тем больше этот индекс ну тем дороже строить индекс и при этом нелинейно, да? То есть, э если мы добавляем там 1.000 документов, это не то же самое, что, ну, что два раза по 500 добавить, это дороже. Вот. Но с multicдом, э, если мы можем, э-э, каким-то образом совместить всех пользователей в одной коллекции и при этом выключить глобальный индекс и строить только маленькое подмножество для каждого независимое, это очень большая оптимизация, э, которая сильно снижает потребность в ресурсах. Вот это один пример. Другой пример, который мне очень нравится, он более такой ресерчерский, что ли. Он ещё не имплементирован, по-моему, нигде, но эксперименты показывают, что он довольно хороший. Это так называемый relevance feedback. Для тех, кто не знает, поясню. Ээ, relevance feedback, ээ, — это очень старая тема в комьюнити, э, связанном с информационным поиском. А он известен буквально с 1965 года. Это первая первая статья, которую я нашёл. Она там вот ей уже 70 и больше лет. То есть эта тема далеко не новая, но, как ни странно, она не популярна до сих пор. Она слабо применяется. Её очень сложно применить. Почему? А потому что она завязана на э действие человека как агента в этой системе. Что это вообще такое? Relevance Feedback — это такая техника, которая позволяет, ну или предполагает, что мы будем модифицировать поисковый запрос. на основе фидбэка пользователя, исходя из результатов первого запроса. То есть, условно говоря, пользователь делает первый запрос в системы, получает какой-то результат, говорит, что из этого ему нравится, что из этого ему не нравится, и система выполняет второй раз поиск, основываясь каким-то образом на этом полученном новом знании. И второй результат поиска предполагается быть более более качественным, более точным. Вот. И это всё, конечно, очень хорошо в теории, но пользователи такие э своеобразные, что они, ну, практически никогда не оставляют свой фидбэк. Это очень сложно заставить пользователя, э, куда-то дополнительно нажать, если это, ну, конкретно для них не нужно. Ээ, если кто-то помнит, то в первых версиях Гугла, например, даже были такие кнопки палец вверх, палец вниз на результаты поиска. Вот. Никто на них не нажимал. Это было очень шумно, неполезно, поэтому они в результате все ушли и убрались. А, то есть вот на протяжении последних 70 лет заставить пользователя как-то оставить свой фидбэк было, ну, практически невозможно. Сейчас с появлением LM эта проблема кажется, что решается просто за счёт того, что заставить ЛМ что-то делать намного проще, чем заставить пользователя, да? То есть мы можем спросить у модели, нравится ли ей там результат, какой результат ей нравится больше. Она может это выразить там даже в каких-то числах. То есть не обязательно её спрашивать текста. можно из неё извлечь информацию там на более низком уровне, но это всё равно будет полезная информация, которая мо может быть использована для вот этого второго второй итерации поиска, э, которая, по идее, должна улучшить результат. Векторный поиск для этого подходит как нельзя лучше, потому что векторный поиск может работать не с абсолютными значениями, да? То есть ограничение вот этого вот первого, первой итерации шестидесятипятилетней давности заключалась в том, что пользователь должен сказать однозначно, какой документ релевантный, какой документ нерелевантный его запросу. И, ну, как несложно понять, в большинстве случаев первый результат ничто не было релевантным, да? То есть не было никакой градации. И эту градацию, э, даже если бы мы могли её извлечь из пользователя, применить для поиска по ключевым словам достаточно сложно. Векторами, тем не менее, это довольно просто, потому что сами вектора представляют собой не бинарные значения, да, а какие-то взвешенные взвешенные скоры. И поэтому применить такой подход к векторам, ну, это интуитивно понятная задача, по крайней мере, для тех, кто работает с векторами. Мы приходим к ситуацию, где у нас есть старая, очень известная, но редко применяемая технология, которая становится возможной только благодаря тому, что у нас появляются языковые модели, у нас появляются агенты, которые, в принципе, могут себе позволить этой технологией пользоваться. И эта технология — это что-то, что на самом деле требует такого, ну, скажем, если не фундаментального, то достаточно глубокого изменения в том, как мы исполняем поисковый запрос, да? То есть у нас перестаёт существовать единственный вектор как запрос, а у нас появляется запрос плюс его некий контекст, который, э, ну, в который нужно записать фидбк э пользователя или там языковой модели. И исполнение вот этого вот второго запроса, это что-то, что требует изменения в поисковом движке, начиная от его интерфейса и заканчивая э тем, как, собственно, этот запрос исполняется очень глубоко там в кишках, в хранилище данных. Вот. Это то, что, наверное, только векторные базы данных могут имплементировать, потому что они как бы владеют своим собственным кодом, да. Они, э, есть команды, которые условно говоря, имеют полномочия менять код вот на всём на всём протяжении стека, начиная от API и заканчивая тем, где вектора хранятся. Насколько я знаю, текстовые движки, и им довольно сложно это сделать, потому что, ну, например, Elastic Search, это же проект, который состоит из двух частей. Есть собственный ластик и есть Люсенen. Это отдельная библиотека, которая, ну, наверное, пересекается с командой ластика, но тем не менее это независимый проект, чтобы протолкнуть такое изменение, которое дойдёт от API до, э, внутренних ээ кишков. Да, условно говоря, стойдж - это нужно там довольно нетривиальное взаимодействие провернуть между командами разных проектов. Вот. А для векторных базы данных — это то, что мы можем сделать за условно квартал.
>> Кстати, у меня такой вопрос для отлиса тех, кто захочет дальше попробовать закопаться в кишочке векторных баз поподробнее. Понятное дело, что ковадрант есть, эээ, на гитхабе, исходники можно посмотреть, но если может быть какой-то какая-то реализация покомпактнее, попроще, поменьше, вот с исходников который проще всего начать понимать, как векторные базы работают, или ты рекомендуешь сразу к вам идти?
>> Ну, в самом деле, ээ, наверное, я не рекомендую сразу к нам идти.
>> Ну, там раст, понятное дело. Ну нет, раст — это не самая большая проблема. Самая большая проблема в нашем случае, что мы довольно сильно декомпозировали индекс таким образом, что, ну, мы добавили туда несколько уровней абстракции, и понимать эти уровни абстракции без контекста движка в целом довольно тяжело. Аа с другой стороны, классические имплементации вот этого векторного индекса, кстати говоря, он называется HNSW. Ну, тот, который мы используем, э, они довольно академичные, да? То есть они тоже заточены на бенчмарки, они заточены на то, чтобы вот там каждый байт сптимизировать. Поэтому читать этот код, особенно на C++, довольно сложно. Вот. Так что я бы, наверное, нашёл какую-нибудь, может быть, не самую каноничную имплементацию, но имплементацию алгоритма, э, и начал бы с неё. Есть множество библиотек, которые просто реализуют этот самый векторный индекс даже на расте, который не зависит от поискового движка.
>> Вы используете алгоритм иерархического навигационного маленького мира. Да, на русском это звучит ужасно.
>> Ну зато понятно. Да.
>> Да. Ну наш алгоритм, он, естественно, прошёл несколько этапов эволюции. Мы добавили в него возможность сделать фильтрацию. Мы добавили в него опять же вот эти вот абстракции, что он не зависит, например, от той функции сравнения векторов, которую мы применяем, да? То есть в нашем случае он довольно сильно переработан. Угу.
>> Вот. Но основные принципы, да, там сохранены, >> да, это метод приближённого поиска ближайших соседей на основе графов. А, и тут сразу вспоминается вопрос из чата: а чем векторные базы отличаются от графовых баз?
>> Да, как бы всем отличаются. Ну, ну тут, ээ, если, если, ээ, зацепиться, да, за то, что векторный индекс представляет собой граф, то этот граф чисто внутренняя структура данных. Э графовые базы данных, они сделаны для того, чтобы хранить графы пользователя, да? То есть пользователь задаёт какие-то графы, э, и эти графы там мы их раскладываем уже на какие-то внутренние структуры. Векторные базы данных не хранят граф как таковой. Они используют граф как такой промежуточный формат, чтобы просто удобнее было искать вектора. А так-то с точки зрения интерфейса нету практически ничего общего между векторными базами. Да.
>> А с точки зрения решаемых задач это скорее конкуренты или просто вот общее внутреннее представление и всё?
>> А, ну, есть такое, скажем так, такая мода или хайп в сре среди э некоторых людей, которые занимаются вот этой задачей построения рага, что нужно добавлять туда э ну какие-то графовые сущности, э, там, антологии, как-то строить связи из документы. Если честно, я просто в это не верю. У меня такая прививка от всего, что связано с графами, она с универа у меня пошла. Я я просто не верю в антологии. Я не верю ни в какой сенtic web. Э для меня это как бы страшные слова. Я может быть не прав, да? То есть как бы я допускаю, что есть какой-токейс, которым для которому это полезно, но сам я такого никогда не видел. Хотелось бы ещё спросить про практическое применение. Есть ли что-то вне языковых моделей, рагов, где это классно подходит?
>> Ну, самая такая интересный интересная задачка, которая лично мне нравится больше всего, связанная с векторным поиском, это, э, нахождение аномалий. У нас даже такой кейсстади есть. Ну, но расскажу, расскажу вкратце. В общем, есть кофейная плантация. Кофейная плантация заинтересована в том, чтобы понимать, насколько хороший у неё урожай кофейных зёрен. Э, и для того, чтобы это делать, у них есть такой специальный аппарат, который выглядит как большой ээ ящик с подсветкой и с камерой, которая смотрит внутрь него. куда закидываются, значит, горсть кофейных зёрен. И задача этого ящика посчитать, что среди вот этой горсти это хорошие зёрна, а что какие-то разного рода аномалии. Ну, то есть, например, там может быть пересушено или плесень или вместо зерна там вообще таракан какой-то лежит. Вот, то есть есть набор разного рода аномалий, да, которые, ну, мы можем их начать классифицировать, но, в общем говоря, они не ограничены каким-то конкретным списком, да? То есть там может может быть реально что угодно, веточка там какая-нибудь, мы заранее не предскажем. И классически эта задача решаются, ну, естественно, сбором какого-то обучающего датасета. Там посидели, э, разметчики, там пару недель набрали 10.000 примеров. Вот они, э, там разметили, это хорошая, это веточка, это таракан, это плесень, это пересушенное. Там там 50 разных классов аномалий. обучили э- модель, и она работает, даёт там хорошее качество, там 98%, например. Для этого достаточно, чтобы условно оценить, как на каком поле урожай лучше, на каком хуже. Но что делать, если у нас появились какие-то новые аномалии, которых раньше не было, да? Там завёлся какой-то новый жук, который, которого раньше не наблюдалось, да? То есть он какими-то новыми способами портит нам жизнь. А в случае классических моделей, как бы традиционный путь — это посадить разметчиков ещё раз. Они должны ещё раз ээ разметить вот эти новые аномалии. Модель должна снова обучиться. И мы должны, ну, по сути, повторить этот процесс. Может быть чуть проще, конечно, потому что мне надо
всё размечать, но, в общем, нам нужно пройти этот путь. В случае векторного поиска мы можем сделать примерно то же самое, только вместо того, чтобы обучить вот эту специализированную модель, э, которая отличает аномалии, мы можем обучить некой некую модель, которая генерирует вектор похожести. Мы его даже можем обучить на тех же самых аномалиях, которые мы уже разметили, но только вместо того, чтобы предсказывать класс, эта модель будет находить ближайший класс из тех, который у нас сохранён в базу данных. Таким образом, когда следующий раз что-то новое появится, нам не нужно ничего переобучать. Мы просто добавляем, аэ, вот эту новый пример нового жука в базу данных, и она автоматически начинает его распознавать, как только он появляется. Вот это такой прикольный пример, как как векторный поиск работает не связано с текстом.
>> Очень классный пример. >> Прикольно. Какая самая большая боль при работе с векторными базами? Ну, основная боль, естественно, приходит от того, что вектора дороги, они занимают много места, они занимают много ресурсов, и как бы это та цена, которую приходится платить за то, чтобы получить хороший качественный поиск. Естественно, как бы все наши усилия, там половина команды направлены на то, чтобы эту цену понизить, да. Мы придумываем разные трюки, как э использовать там память более эффективно, как там, например, квантизовать Виктора, чтобы они занимали там не 32 байта, а 16 или вообще 1 бит. Это как бы процесс, который построен на компромиссах.
>> А можно вот какой-то самый неожиданный трюк, который вы делали и вот который ты можешь вспомнить? Самые неожиданные, наверное, это бинарная квантизация, которая, ну, она, в принципе, довольно тривиальная, как концепт. Неожиданно в ней то, что она работает, да? То есть, э, условно говоря, что мы делаем? У нас есть вектор. Вектор - это какое-то flot point число. Обычно 32 бита на на элемент. И мы просто берём и говорим: "Если это число больше нуля - это один. Если меньше нуля, то это ноль". И сжимаем таким образом вектор в 32 раза. кажется, ну, то есть обычно программисту или там scienтисту кажется, что мы потеряем при этом практически всю точность вообще. Ну, потому что слишком большая компрессия. А оказывается, что для больших векторов, например, тех векторов, которые генерируют модели от Open AI, потери не настолько большие, как нам исходно казалось. Они там, ну, в районе 5%. Пятипроцентная потеря точности при сжатии в 32 раза - это довольно хорошо. Это неожиданный результат. Когда мы это померили, мы как бы подумали сначала, конечно, что мы там что-то, ну, что-то не так в нашем коде, что-то не так в нашем бенчмарке. Этого, по идее, не должно было произойти. А вот произошло. Самое замечательное, что этот компромисс, его можно, в принципе, компенсировать. Не в моменте, когда ты создаёшь индекс, его можно компенсировать в моменте, когда ты выполняешь запрос, да? То есть, условно говоря, можно, э, запросить чуть больше результатов и этот большой топ результатов перескорить настоящими хорошими векторами, да, и таким образом потратить чуть-чуть больше времени в момент выполнения запроса, но там компенсировать ту потерю точности, которая получилась из-за компрессии. Это как будто бы что-то из физики, где вот это сину X при малых значениях равен X. И вот это вот всё.
>> Но это не работает для всех моделей. Вот это тоже интересный результат, что для каких-то моделей, которые может быть даже больше по размерности, э этот трюк не срабатывает. Ну там есть когда уже начали больше про это смотреть, там есть разные объяснения, что там распределение этих величин, оно не совсем нормальное. Ну, в общем, там это открыло, на самом деле, целое целое направление исследований, которые вот сейчас, наверное, это самый эффективный способ сделать векторный поиск дешевле. Это квантизация, причём бинарная квантизация.
Ну то есть ты вот в своё время сел и у тебя из там твоего подпроекта вот случилось вот то, что случилось там собственная компания openсоourсный движок, который используется крайне много где. Ты примерно понимаешь, что вообще дальше может со всей этой темой произойти в будущем? И и с твоим именно продуктом, и вообще со всей сферой векторных баз, она скорее затухнет, потому что станет неким там, ну, просто вот все привыкнут к тому, что это есть, поймут сфера применимости и всё. Или наоборот это ещё будет больше развиваться?
Прямо сейчас мне кажется, что, конечно, ничего не затухнет. Конечно, э станет каким-то, ну, стандартом, да? То есть точно так же, как мы сейчас привыкли к обычному поиску практически везде. Мне кажется, векторный поиск тоже будет, ну, практически везде, потому что это просто такой конвениенс, да? То есть, э, если если ваш поиск не векторный, ну тогда вы сильно теряйте результат. Вот. Ну, по крайней мере, в тех областях, где векторный поиск имеет смысл, да? То есть я не говорю там про логи, я не говорю там про какие-то ещё, э, текстовые представления, которые не имеют семантики, например, да, их мы оставляем за скобками.
Моя такая более глобальное видение того, что произойдёт с векторным поиском, это то, что, вообще говоря, сейчас векторный поиск он воспринимается как такой более умный обычный поиск. То есть с точки зрения практики, там, с точки зрения разработчиков. Но на самом деле у векторного поиска как такового есть пересечение, да, с текстовым поиском, но функции, которые можно с ним делать, они, вообще говоря, не одинаковые, да? То есть, э, есть функции, которые могу хорошо работают в текстовом поиске и вообще не работают в векторном, например, э для текстового поиска очень просто оценить, сколько результатов совпало с запросом. Да, мы просто можем посчитать. Все видели в Гугле такую строчку, что типа найдено 5 млрд результатов, да? То есть для векторного поиска это просто не имеет смысла. Э потому что в векторном поиске каждый документ похож на каждый запрос в какой-то степени. Мы не можем там порогом это а отсечь простым способом. С другой стороны, например, для векторного представления такая штука, как отрицательный пост, да, то есть перевёрнутый наоборот, вместо самых похожих мы ищем самые непохожие. Это что-то естественное. Это этого можно добиться просто там умножив вектор на -1. Э условно для текстого поиска это невыполнимая задача. у него нету та так такого представления данных, которое позволяло бы это сделать. А для векторного поиска это тривиально, и это можно там для тех же самых поисков аномалий применить. Например, для векторного поиска интересна такая задача, да, даже сказать точно не для векторного поиска, а именно для векторного представления данных существуют другие задачи, которые тоже интересны. Вот, например, что делать, если у нас есть какая-нибудь коллекция документов и для неё мы вообще не знаем, что там, да, но мы хотим понять, как-то исследовать эту коллекцию документов и, э, какую-то полезную информацию из неё извлечь, да? Ну, то есть самое наивное - это как бы построить кластера, например, для такой такой коллекции. кластера довольно тривиально строятся с помощью векторного представления. То есть, например, у нас есть как бы даже специальная, э, API функция, да, в нашем в нашем движке, которая генерирует матрицу попарных расстояний. Это то, что а напрямую можно передавать в алгоритмы кластеризации, чтобы уже построить красивую картинку, да? То есть мы не делаем как бы сами алгоритмы, мы их не имплементируем просто потому, что их очень много разных, но мы подготавливаем для них данные таким образом, чтобы сами сами алгоритмы уже не тратили много ресурсов на стороне пользователя на то, чтобы нарисовать хорошие кластера. А и там можно углубляться дальше, дальше, дальше. Для векторного представления нужны свои специализированные интерфейсы, которые несовместимы подчастую с традиционным поиском, да? То есть для традиционного поиска кластера мы не сможем построить. Для традиционного поиска мы не сможем сделать diversity такой selection, когда каждый объект максимально не похож на каждый другой и так далее.
А как в таком ключе перенастроить свою парадигму мышления? Просто мне кажется, что ещё удерживает от понимания и распространения векторных баз, векторного поиска, то, что условно мы привыкли понимать, как работает привычный поиск, как работают привычные данные. И поэтому вот все разговоры про векторное представление вот в каком-то непонятном виде понятных нам вещей, оно вот стекается в эти житейские примеры, потому что всем хочется как-то это наложить на собственную парадигму мышления. Вот что с этим можно сделать, на твой взгляд?
А, ну, мне кажется, что виноваты в этом скорее интерфейсы, которые обучили, э-э, там несколько поколений пользователей, что поиск выглядит вот так. Поиск выглядит как такая строка ввода, которую нужно записать э свои ключевые слова, нажать на на кнопочку, и он найдёт результаты. Да, это в лучшем случае. В худшем случае будет ещё такая ужасная панель сбоку, где 10.000 тысяч разных чекбоксов помогут там выбрать подходящие туфли э на магазине одежды, например, да? То есть интерфейсы, которые построены таким образом - это интерфейсы, построенные для текстового поиска. И попытка натянуть на существующие интерфейсы векторный поиск - это, э, ну, такой, ну, подход для бедных, да, что называется, да? То есть мы, у нас есть что-то, мы хотим, чтобы это что-то было лучше. Вот мы туда добавляем векторный поиск. А на самом деле кажется, по крайней мере мне, что векторному поиску могут быть доступны и другие формы интерфейса, да? То есть мой любимый пример - это, конечно же, TikTok, что в ТикТоке мы вообще ничего не ищем. Мы просто либо свайпаем быстро, либо свайпаем медленно. И это уже достаточный сигнал, чтобы там через, э, там сколько-то, 10 свайпов нам показать такой смешной ролик про кота, чтобы мы там застряли на на весь вечер, да, условно, свайп этих котов. А вот вот это такой интерфейс, который позволяет взаимодействовать с векторным поиском. А какие ещё примеры? Ну, тут сложно, да? То есть я на предполагаю, что что-то может быть похожее на э такой путь исследования, но как бы построить сам интерфейс, ну это это сложная задача, но мне кажется, она будет решена в тот тот или иной момент. Э а от нас зависит только то, насколько удобный API мы будем предоставлять, чтобы этот интерфейс смог в него встроиться.
То есть я правильно услышал, что помимо ТикТока сейчас даже вот ты описать как-то пример интерфейса, который подходил бы для векторного поиска, не можешь?
>> Ну это сложная задача, да. Я могу его представить, я могу что-то попробовать сам там сделать на коленке, но как бы я не специалист по интерфейсу. Скорее всего, это будет плохо. Скорее всего, это никому не понравится. То есть на самом деле, наверное, э-э направление сейчас идёт в том, чтобы скрыть как бы как можно больше от пользователя, что поиск вообще существует, да? То есть с одной стороны это вот TikTok, с другой стороны, наверное, это агенты, которые сами напишут поисковый запрос, э которые сами там поговорят с поисковым движком, сделают там несколько итераций, несколько попыток, и только потом пользователю покажут результат. Это, наверное, такой второй второй второе направление действий, которое более-менее понятно.
>> А давай я, наверное, задам после последний вопрос наш классический. Помимо того, что куда можно посмотреть вход, что ты ещё посоветуешь людям, которые хотят поглубже в область вкатиться? Может быть, есть какие-нибудь книги? Может быть, есть какие-нибудь прямо такие must have статьи или бумаги, которые надо прочитать? Короче, есть вот что-то такое, куда вот нам надо прямо направить наших слушателей.
>> Ну, это зависит от того, что именно вы хотите. Если вы хотите начать применять векторный поиск, >> то, наверное, я бы сказал, что надо начать с экспериментов. Ну, то есть нужно попробовать э самому сделать что-нибудь по туториалам. И, ну, по крайней мере, для меня это работает лучше всего, да, нужно придумать сначала задачу, а потом эту задачу пробовать решить. А если мы говорим про именно внутренности самих векторных баз данных, то, ну, это сложная задача. Ээ, наверное, тут полезно всё, что связано с обычными базами данных. Ну, то есть, например, когда мы нанимаем людей, то для нас важно, чтобы человек понимал, как, например, работает ядро Линукса, э, на низком уровне, там как работает, э, ну, инструкции процессора, да, например, SIMD оптимизации, там как работает ГПУ важно. То есть очень низкоуровневые вещи мы обычно хотим э обсуждать на таких интервью.
То есть, грубо говоря, вот у меня как раз параллельно с подготовкой к этому выпуску была такая задачка, и я подумал вот, а вдруг здесь бы это было как раз применимо. У меня есть большое количество, ну, как бы в одной сфере не особо структурированных экселей с разными данными.
>> Угу.
>> Это прямо огромные массивные эксели. И, а, мне необходимо взять и придумать, каким образом можно найти какие-то закономерности между этими экселями, где их там друг с другом пересекать. При этом мне их читать э просто глазами и делать это эту работу самому не хочется. И казалось бы, можно действительно построить ээ какой-то вектор ээ на основе всего этого. Вот если вот мы берём вот просто такую задачку, мне каким образом вот ту-дулиistст, чтобы пройти по вот этому вот пути векторного посвящения?
>> Ну, надо ответить на первый вопрос такой: а есть ли вообще в в этом Экселе какая-то семантическая составляющая или это просто таблица с цифрами? Если это просто таблица с цифрами, то навряд ли есть такая готовая модель -э для получения векторов, которые вот с этими данными будет хорошо работать.
>> Ну там есть заголовки колонок, как минимум.
>> Вот вот заголовки колонок- это уже лучше. Это то, по крайней мере, с чем >> векторный поиск может в каком-то виде справиться, да? То есть вот нужно идентифицировать ту часть, которая содержит в себе семантическую информацию. Если такая есть, ну вот можно её использовать, да, там дальше возникает вполне себе инженерная задача, как её извлечь из Экселя. Они же наверняка ещё в разных форматах там каких-нибудь.
>> Угу.
>> А возникает инженерная задача, как её извлечь, как её сложить в векторную базу данных, как потом соотнести результат поиска с исходным документом. Как это визуализировать? Ну это это вполне себе задача, которая под силу программисту. То есть для этого не нужно быть никаким machine learningм, для этого не нужно быть там PhD. Это задача, которая вот за последние несколько лет спустилась с уровня ресрча до уровня обычного программиста, который вот этим раньше не занимался. Нужно просто на там освоить как бы некое представление, что не всё может быть эффективно конвертировано в вектор, да? То есть таблица с числами навряд ли, да? Там, например, ээ как-то я слышал такую идею: "А что, если мы вот шахматную партию запишем как вектор?" Вот не будет это работать, если у вас нет специализированных моделей под шахматой, если есть текст. Если есть какие-то картинки, опять же, не любые картинки, да, там картинки с белым шумом, навряд ли будут подходить картинки, на которых что-то нарисовано из реальной жизни, вот это уже другое дело, да, то есть нужно как бы учитывать семантическую составляющую.
>> Супер, спасибо. Да, попробую и вдруг получится. Класс, да, Андрей, спасибо тебе огромное за то, что пришёл. Мы сегодня, мне кажется, очень классно всё всего коснулись, обсудили и главные нюансы, что векторная база на самом деле не база, а векторный поиск. Как это всё работает с житейскими примерами, с тем, где это применимо, чем это отличается от обычного поиска, какие проблемы, боли и будущее у всего. Напоследок, как обычно, хотелось бы спросить Егор, что ты любишь больше, чем записывать выпуски про новые базы данных?
>> А больше этого мне нравится только самому придумывать вопрос для тебя. Но так как ты задал мне его первым, больше этого мне нравится, когда вы, дорогие друзья, не только смотрите наши новые выпуски, но и пересматриваете старые. Потому что помимо тех, что я вам проспойлер проспойлерил в начале, я очень рекомендую послушать ещё один а выпуск про поиск, где мы в основном говорили про движок сфинкс, но затронули и другие тоже. То, что старый выпуск тоже очень клёвый. Вот. На самом деле мне нравится, когда вы слушаете наш подкаст, подписываетесь вообще где только угодно на него, рекомендуете его своим друзьям, коллегам, мамам, папам, братьям, детям, а детям ещё насильно включаете в машине, когда вы с ними путешествуете. Аа когда вы вступаете в наш Telegram-канал и накидываете вопросов к следующим выпускам, вот это мне нравится больше всего.
>> Да, не забывайте ещё ставить пять звёзд в Айтюнсе. Опять же вопросы, как вы видели к этому выпуску, были взяты частично из чата по предвадительному посту, так что да, не забывайте вступать. Спасибо ещё раз, Андрей, что пришёл к нам и так всё классно ответил. Услышимся через неделю. Всё, всем пока.
>> Всем спасибо. Всем пока.
>> Спасибо, что пригласили. Пока. M.