Векторная база данных простыми словами: зачем ИИ хранилище смыслов
Поиск по документам в компании обычно работает так: вбиваешь слово из документа, надеешься, что помнишь его точно. «Командировочные» не найдут «расходы на поездки», «отпуск» не найдёт «регламент отдыха». Поиск по буквам тупой, он честно ищет то, что вы написали. Векторная база данных решает другую задачу: поиск по смыслу.
Как число становится смыслом
Возьмите фразу и прогоните через модель-кодировщик. На выходе набор чисел, вектор, скажем на тысячу позиций. Волшебство в том, что похожие по смыслу фразы дают близкие векторы, даже если ни одного общего слова в них нет. «Сколько дней отпуска за ненормированный график» и «Особый порядок предоставления отдыха» лягут рядом в этом числовом пространстве.
Векторная база это хранилище, которое умеет быстро находить ближайшие векторы. Ваши документы нарезаны на фрагменты, каждый превращён в вектор и сложен. Приходит вопрос, его тоже превращают в вектор, база отдаёт ближайшие по смыслу куски. Дальше модель читает эти куски и отвечает по ним. Это и есть RAG, его несущая конструкция, как RAG устроен целиком разобрано отдельно.
Что это даёт бизнесу
Первая история: поиск в базе знаний, который находит по смыслу. Сотрудник формулирует как умеет, система находит документ, в котором это написано другими словами. Вторая история: дедупликация и навигация. Близкие векторы показывают, что в базе лежат три версии одного регламента, а это уже аудит хранилища. Третья история: рекомендация «похожих обращений» в поддержке, когда новое письмо автоматически находит десяток похожих из прошлого.
Чего векторная база не делает: она не отвечает на вопросы и не рассуждает. Ответ пишет модель, база только подаёт материал. Если вам обещают «умную базу знаний» из одной векторной базы, уточните, где модель.
Из чего выбирают и на чём это работает
Известные имена: Milvus, Qdrant, Weaviate, pgvector как расширение PostgreSQL. Для компании среднего размера честный ответ: если данные уже живут в PostgreSQL, стартовать можно с pgvector, не заводя новую систему. Отдельная база оправдана при миллионах фрагментов и высокой нагрузке. Всё это работает и на вашем железе, без облака: какие локальные модели подходят для кодировщика и генерации, разобрано в статье о выборе моделей для своего железа.
Практический предел, о котором стоит знать: векторный поиск находит близкое по смыслу, но не точное совпадение. Для поиска точного кода договора или артикула нужен обычный индекс. Рабочие системы совмещают оба: сначала точный, потом смысловой.
Дальше по теме: как из векторной базы и модели собирается система ответов по корпоративным документам, описано в следующем материале рубрики, про корпоративную базу знаний.