Векторная БД и ретривер

Уже четвёртая статья. Начнём с векторки.

Векторная база данных — храню твои цифры.

Это хранилище для эмбеддингов. В отличии от реляционной базы данных, которая хранит табличные данные, и от нереляционной, которая хранит неструктурированные данные типа изображений и картинок, векторная база данных хранит массивы цифр, которые отражают семантику соответствующего чанка с текстом.

Сложновато, но смотри внимательно. Есть вектор для токена. По сути это столбец с цифрами фиксированной длины. Токен это часть слова, а в предложении слов 10. То есть векторное представление этого предложения — это соединение всех векторов токенов, для каждого из 10 слов, которые его формируют.

Задача векторной базы данных — хранить в одном месте все эти вектора токенов, которые соответствуют одному чанку.

— А семантика тут причём? Ну храним какие-то цифры, как вообще поиск работает, да?

Да.

Читай — у нас есть эмбеддер, он же не просто формирует вектор из каких-то цифр, случайных цифр. Он формирует их по одному принципу и эти цифры сохраняют, отражают семантику слова.

То есть цифры в векторе слова «рак» будут ближе к цифрам в векторе слова «болезнь», потом к ближе к вектору слова «животное» и далее к слову «мид». Далеко от слова «солнце», но рядом со словом «петушара».

И вот у нас векторная база данных, в ней есть чанк, который имеет свой общий вектор из цифр, отражающий слова, сформированный не случайным образом. Пока он там просто лежит, но чтобы раг заработал, нам нужен финальный механизм этого ансамбля — ретривер.

Ретривер — отвечает за слова.

«Возвращатель» — это не название нового фильма со Стетхемом, а адаптированный перевод названия инструмента, который осуществляет векторный поиск по векторной базе данных и возвращает подходящие чанки, которые попадут в контекстное окно ллмки.

То есть, в векторной базе данных хранятся вектора, которые отражают семантический смысл чанков. И вот тут как раз и раскрывается ключевая фишка рага, ведь когда пользователь пишет свой запрос, он тоже векторизуется.

Что получается?
Вектор запроса отправляется в векторную базу данных и по цифрам этого вектора происходит поиск. А именно, в каком чанке цифры наиболее близки к цифрам запроса пользователя?
Или.
Вектор какого чанка наиболее близок к вектору запроса? Наиболее близкие по векторам чанки с текстом забираются, возвращаются ретривером и подаются в контекстное окно ллмки. На их основе модель генерирует ответ.

Возвращаемся к началу.

Помнишь, в первой статье говорилось про «Оптический абонентский терминал Netlink C-data xpon fd511g-x port». Смотри, у нас есть чанк в векторной базе данных, описывающий работу именно этого терминала и содержащий ровно это название.

Если в запросе пользователя будет что-то вроде:
“Ллмка-ллмка, нейросеть. Здравствуйте. А можно как подклчся нэтлинк здата хпон эфд511Г?”

То векторный поиск сможет:

• 1. Корректно воспринять такой запрос.
• 2. Обработать, найти в векторной базе данных интересующий пользователя терминал с названием Netlink.
• 3. Найти именно тот чанк, где рассказывается как его подключать и первично настраивать.
• 4. Подать его в контекстное окно ллмки.

Модель на его основе грамотно ответит и доходчиво объяснит пользователю, как же подключается этот терминал.

Готово.
Мы ситуативно расширили эрудицию модели через раг и помогли решить вопрос пользователя. Вот так.

Архитектура классического RAG.

В теории существует множество архитектурных решений внутри самого рага. Большая часть из них нужна скорее на профильных ИИ-конференциях, чтобы постоять на сцене с умным лицом, чем для практического использования для высоконагруженных решений внутри корпорации.

Помимо классической архитектуры рага, описанной выше, широко применяется разве что графовый раг. Эффективность того или иного варианта надо определять после сбора, обработки и анализа метрик. Однако и классика может довольно эффективно выполнять задачи графового рага в проде, если корректно настроить его отдельные модули и гиперпараметры под свои задачи.

А это уже задача ИИ-инженера и его тимлида.