Это был RAG с использованием векторного поиска. О них сегодня пост.
RAG (Retrieval Augmented Generation, генерация с дополненной выборкой) — подход когда LLM дает ответ не только своими внутренними знаниями, а еще использует внешнюю корпоративную информацию. Например, корпоративную бизнес-википедию, базу знаний...
1️⃣Дается большой набор документации, которая делится на куски-чанки.
2️⃣ На выходе получаются вектора, они же эмбеддинги — из себя представляют массив с большим набором чисел [0.1, 0.003 ...]. Все они заносятся в векторную БД.
3️⃣ Когда пользователь делает запрос, то движок тоже преобразовывает его в вектор, а затем по специальным алгоритмам ищет в БД ближайший вектор.
Происходит семантический поиск — по смыслу запроса, а не по ключевым словам. Никаких LIKE(), как в SQL.
4️⃣ Наиболее релевантные фрагменты среди миллионов документов добавляются к исходному запросу, обогащая его контекст.
5️⃣ И в конце, LLM генерирует ответ, отталкиваясь от исходного запроса пользователя и найденного в документах контекста. Так, векторая БД повышает точность ответа и снижает галлюцинации LLM.
Таким образом: векторная БД в RAG нужна для быстрого поиска знаний. LLM нужна для генерации понятного ответа.
Математическое представление смысла того или иного объекта: текст, картинка, аудио, документа. Поиск идет по смыслу, а не по ключевым словам.
🤩 Кошка спит на кресле
[0.10, -0.09, 0,56, -0.11, 0.89, ...]
Каждое число — координата в многомерном пространстве признаков, сформированном ML-моделью.
Близкие по смыслу вектора:
✔️ домашняя кошка
[0.11, -0.05, 0.50, -0.15, 0.84, ...] — все числа расположены рядом с теми, которые получились у "Кошка, спит на кресле"!
❌ самолет Boeing
[0.95, 0.67, -0.33, 0.82, 0,02, ...] — все числа слишком далеко от тех, которые указаны в "Кошка спит на кресле". Смысл уже другой.
Это пример для демонстрации сути вектора. В реальном мире семантические связы намного обширнее. Например, кресла тоже в самолете есть, как и люди путешествующие с животными. Поэтому в реальности используются большие, длинные числа. Векторная БД/движок производит ближайший поиск к точке в многомерном пространстве. Обычная база хранит данные, а векторная — смысл данных.
Многие СУБД имеют векторные движки. Но векторная СУБД кардинально отличается. Там нет SQL-запросов и нет поиска key-value. Векторный поиск — это поиск по смыслу, поиск сходства (Similarity Search), поиск ближайшего соседа (Nearest Neighbor Search).
🔤 Почему обычные СУБД хуже?
На небольших векторах это хорошее решение. Но если у нас десятки и сотни миллионов векторов, это медленный перебор записей, большие задержки, слабая масштабируемость, отсутствие специализированных индексов. В то время как в векторных БД есть ANN-индексы (Approximate Nearest Neighbors, приблизительный поиск ближайших соседей), позволяющие производить поиск за миллисекунды среди миллионов векторов.
🔤 Какие базы данных использовать?
Из специализированных векторных СУБД: Qdrant, Milvus. Касательно движков, есть pgvector (PostgreSQL) и OpenSearch (форк Elasticsearch). Yandex DB тоже обладает крепкими характеристиками для осуществления векторного поиска.
Понравился пост? Подписывайся, чтобы не пропустить следующий.
Артем Лещев