Векторные базы данных: pgvector, Pinecone и Weaviate

Что такое векторная база данных

Векторная база данных — это хранилище, в котором данные представлены не только «как есть» (текст, картинка, товар), но и в виде числовых векторов — эмбеддингов. Такие векторы можно сравнивать между собой и быстро находить «похожие» объекты: не по совпадению слов, а по смыслу.

Проще говоря, векторная БД отвечает на вопросы вида: «покажи то, что максимально похоже на этот запрос/документ/изображение», и делает это эффективно даже на больших объёмах данных.

Чем отличается от обычной БД с LIKE и полнотекстовым поиском

Обычные методы поиска в SQL чаще всего опираются на совпадение символов и слов:

• LIKE ищет подстроки (удобно для точных фрагментов, но плохо понимает смысл).
• FTS (полнотекстовый поиск) учитывает формы слов и релевантность, но всё равно работает вокруг слов, а не значения.

Векторный поиск сравнивает эмбеддинги и находит близкие по «направлению» и «расстоянию» представления. Поэтому запрос «как вернуть товар» может находить документы, где нет этих слов, но описаны возврат и условия.

Типичные задачи для векторной БД

Чаще всего векторные базы используют для:

• семантического поиска по статьям, базам знаний, тикетам поддержки;
• поиска похожих товаров/картинок/документов («похоже на это»);
• дедупликации и поиска дубликатов по смыслу;
• RAG-сценариев: найти релевантные фрагменты, чтобы LLM отвечала на основе ваших данных.

Когда векторная БД не нужна

Если у вас маленький объём данных, достаточно точного поиска по атрибутам (фильтры, категории, даты) или важно строгое совпадение терминов (артикулы, номера договоров), то векторная БД может быть лишней.

Также она не заменяет обычную БД: транзакции, отчёты и сложные связи по-прежнему удобнее хранить и обрабатывать в реляционной модели.

Эмбеддинги: базовые понятия без математики

Эмбеддинг — это «упаковка смысла» объекта (фразы, изображения, аудио) в набор чисел, то есть вектор. Модель берёт исходные данные и превращает их в компактное представление, которое удобно сравнивать и искать.

Как эмбеддинги получаются из текста, картинок и аудио

Для текста модель читает предложение целиком и выдаёт один вектор на фразу/абзац (или на каждый фрагмент, если вы режете документ на куски). Для изображений работает похожий принцип: нейросеть смотрит на картинку и кодирует её содержание (объекты, стиль, композицию) в вектор.

Для аудио обычно сначала строят представление звучания (интонации, фонемы, тембр) и тоже превращают его в вектор; иногда аудио дополнительно транскрибируют в текст и считают текстовый эмбеддинг.

Почему «близкие» векторы означают «похожий смысл»

Модели обучают так, чтобы похожие по смыслу примеры оказывались рядом, а разные — далеко. Например, «как вернуть товар» будет ближе к «оформить возврат», чем к «поменять пароль».

Поэтому, когда вы ищете ближайшие векторы, вы фактически находите объекты с похожим смыслом, даже если слова не совпадают.

Размерность вектора: память и скорость

Размерность — это длина вектора (например, 384, 768, 1536). Чем она больше, тем точнее модель может «разложить» смысл по признакам, но тем больше памяти нужно хранить данные и тем тяжелее вычисления при поиске.

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

Нормализация и зачем она нужна

Нормализация — это приведение векторов к одинаковой длине (обычно к 1). Она важна, когда вы используете метрики, чувствительные к масштабу.

Например, для cosine similarity часто нормализуют векторы, чтобы сравнение отражало именно направление (смысл), а не «величину» вектора. Это делает результаты стабильнее и снижает число неожиданностей при смешанных данных.

Как работает поиск по похожести

Идея простая: каждый объект (текст, картинка, товар, документ) превращается в набор чисел — вектор. Дальше мы ищем не «точное совпадение слов», а ближайшие векторы: чем они ближе в выбранной метрике, тем более похожими считаются объекты.

kNN и ANN: точный и приближённый поиск

kNN (k-nearest neighbors) — точный поиск ближайших соседей. Он просматривает много кандидатов и гарантирует, что вы действительно нашли топ‑k самых близких. Минус: при больших объёмах данных это может быть медленно.

ANN (approximate nearest neighbors) — приближённый поиск. Он быстрее, потому что «умно» отбирает кандидатов и не перебирает всё. Цена скорости — иногда он пропускает часть идеальных соседей.

На практике почти все системы на больших коллекциях используют ANN: пользователю важнее получить ответ за десятки миллисекунд, чем математически идеальный топ‑k.

Метрики: чем измерять «близость»

Векторная БД должна понимать, как считать расстояние/сходство:

• Cosine similarity (косинусная) — сравнивает направление векторов. Часто подходит для текстовых эмбеддингов, где важнее «смысл», чем длина вектора.
• Euclidean (евклидова) — обычное расстояние в пространстве. Полезно, когда векторы не нормализованы и «масштаб» тоже несёт смысл.
• Dot product (скалярное произведение) — хорошо работает, когда модель обучалась под эту метрику (часто в рекомендациях). Может учитывать и направление, и длину.

Важно: метрику обычно выбирают не «по вкусу», а под конкретные эмбеддинги и задачу.

Индексы ANN: HNSW и IVF

Чтобы ANN был быстрым, строят индекс:

• HNSW — граф, по которому поиск «прыгает» к близким точкам. Часто даёт отличную точность при низкой задержке, но может потреблять больше памяти.
• IVF — делит пространство на «корзины/кластеры» и ищет только в некоторых из них. Обычно экономнее по памяти, но требует настройки количества кластеров и того, сколько кластеров просматривать.

Компромисс везде один: скорость vs качество.

Параметры качества: recall и latency

Ключевые ручки настройки:

• k — «сколько соседей вернуть» (например, top‑10). Чем больше k, тем больше работы на запрос.
• Сколько кандидатов просматривать (например, efSearch в HNSW или nprobe в IVF). Больше кандидатов → выше recall (доля найденных «правильных» соседей), но выше latency (задержка).

Хорошая настройка — это не максимальные значения, а стабильный баланс под ваш SLA и качество ответа в продукте.

Данные в векторной БД: векторы, метаданные и фильтры

Чтобы векторный поиск был полезным в продукте, одной «таблицы с векторами» недостаточно. Почти всегда запись в векторной базе состоит из трёх частей: вектор, метаданные и исходный объект (или ссылка на него).

Базовая схема: вектор + метаданные + объект

• Вектор (embedding) — числовое представление текста/картинки/профиля пользователя. По нему система ищет «похожие» элементы.
• Метаданные — структурированные поля, по которым удобно фильтровать: язык, категория, дата, права доступа, источник, автор, ID клиента и т. п.
• Исходный объект — сам текст, либо ключ/ID, либо ссылка на документ в другой системе (PostgreSQL, S3, CMS). На практике часто хранят только ID и краткий фрагмент, чтобы не дублировать большие данные.

Такой подход помогает разделить ответственность: векторная БД отвечает за поиск, а «источник правды» — за хранение полнотекстового контента и бизнес-логику.

Фильтрация по метаданным вместе с векторным поиском

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

Практическое правило: метаданные лучше делать как можно более предсказуемыми (типы, формат дат, нормализованные значения), иначе фильтры начнут «промахиваться» и усложнят отладку.

Гибридный поиск: BM25/FTS + векторы

В реальных задачах часто нужен гибридный поиск: классический текстовый (BM25/полнотекстовый поиск) хорошо ловит точные термины и редкие слова, а векторный — смысловые перефразирования.

Комбинация особенно полезна, когда в запросе есть артикулы, имена или точные формулировки, которые важно не «размыть» семантикой.

Обновления и удаления: почему это может быть нетривиально

Контент меняется: документ перезаписали, доступ отозвали, кусок текста удалили. Это означает, что нужно обновить или удалить соответствующие векторы.

Сложность в том, что один документ часто превращают в несколько фрагментов (chunks) — значит, придётся управлять множеством записей по одному исходному ID.

Хорошая практика — хранить в метаданных: document_id, chunk_id, версию, время индексации и признаки доступа. Тогда массовые удаления/переиндексация становятся управляемыми, а не ручной «охотой» за устаревшими векторами.

Основные сценарии использования

Векторная база данных особенно полезна там, где «точное совпадение» не работает: запрос сформулирован по‑разному, в тексте есть синонимы, опечатки или смысл выражен косвенно. Вместо поиска по ключевым словам система сравнивает эмбеддинги и находит ближайших соседей по смыслу.

Семантический поиск по документам и базе знаний

Самый частый сценарий: у вас есть инструкции, политики, тикеты, заметки, статьи — и нужно быстро находить релевантные фрагменты.

Практика: документы режут на небольшие куски (chunks), строят эмбеддинги и сохраняют вместе с метаданными (раздел, дата, продукт, язык). Тогда запрос «как восстановить доступ» найдёт ответ, даже если в тексте написано «сброс пароля».

Рекомендации: товары, контент, похожие кейсы

Векторный поиск помогает делать рекомендации без сложной ручной разметки. Вы можете сравнивать:

• товары по описанию и характеристикам (в том числе текстовым);
• статьи по теме и стилю;
• обращения в поддержку по «похожести ситуации».

Это удобно для блоков «Похожие товары», «Читайте также», «Похожие инциденты» — особенно когда каталог или база кейсов постоянно меняется.

Дедупликация и кластеризация похожих записей

Если данные приходят из разных источников, часто появляются дубликаты: один и тот же клиент, компания, документ или задача, но записаны по‑разному. Поиск ближайших соседей помогает находить кандидатов на дубль и объединять их.

Кластеризация по векторам полезна и для аналитики: выделить повторяющиеся темы в отзывах, сгруппировать запросы в поддержку, понять, какие проблемы «болят» чаще.

RAG для LLM: поиск контекста перед генерацией

RAG (Retrieval-Augmented Generation) — это когда перед ответом LLM вы сначала находите релевантные фрагменты в базе знаний, а затем просите модель ответить, опираясь на найденный контекст.

Плюсы: меньше галлюцинаций, проще обновлять знания (достаточно переиндексировать документы), можно ограничивать выдачу фильтрами по метаданным (например, «только актуальные политики» или «только для продукта X»).

Практический момент для команд в РФ: в RAG важны не только качество и задержки, но и контур данных (где крутятся модели и где хранятся векторы). Например, в TakProsto.AI такие сценарии можно быстрее собрать в формате «vibe-coding»: от чата — к рабочему веб-приложению с поиском по базе знаний, при этом код экспортируемый, а инфраструктура и модели развёрнуты на серверах в России.

pgvector: векторный поиск внутри PostgreSQL

pgvector — это расширение для PostgreSQL, которое добавляет тип данных vector и функции для поиска по похожести. Идея простая: вы храните эмбеддинги прямо в обычных таблицах, рядом с привычными полями (id, текст, даты, статусы), и выполняете запросы через SQL.

Как это выглядит в данных

Обычно схема напоминает классическую таблицу документов, только с дополнительной колонкой для вектора:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE docs (
  id bigserial PRIMARY KEY,
  title text,
  body text,
  embedding vector(1536),
  created_at timestamptz default now()
);

Дальше вы можете сортировать результаты по близости к запросному вектору и получать топ‑N совпадений. Важный плюс: метаданные и векторы живут вместе, поэтому фильтрация (например, по дате, языку, типу документа, правам доступа) делается обычным WHERE.

Сильные стороны pgvector

pgvector часто выбирают за прагматичность:

• Знакомый SQL и экосистема Postgres: миграции, бэкапы, репликация, мониторинг — всё как обычно.
• Транзакции и целостность данных: удобно, когда нужно атомарно обновлять и текст, и метаданные, и эмбеддинг.
• Единая база: меньше движущихся частей в архитектуре — полезно для быстрого старта и небольших команд.

Ограничения и нюансы

pgvector — не «магическая кнопка ускорения» для любого масштаба. На практике ограничения проявляются так:

• Масштабирование: если векторов становится очень много и запросов тоже, вы упрётесь в ресурсы одного кластера Postgres и в конкуренцию за CPU/IO с транзакционной нагрузкой.
• Индексы нужно осмысленно настраивать: выбор типа индекса и его параметры влияют на скорость и качество (точность) поиска.
• Нагрузка на Postgres: векторный поиск может мешать OLTP‑операциям, если всё крутится в одной базе без выделения ресурсов.

Когда pgvector подходит лучше всего

pgvector обычно выигрывает, когда нужен быстрый старт и простая эксплуатация: малые/средние проекты, пилоты RAG, внутренний поиск по базе знаний, приложения, где Postgres уже центральное хранилище, а объём векторов пока не измеряется сотнями миллионов.

Отдельный плюс для продуктовых команд: если ваш бэкенд и так на Postgres, то прототип семантического поиска можно поднять без отдельной платформы. В TakProsto.AI такой подход тоже часто оказывается самым быстрым, потому что типовой стек включает Go + PostgreSQL, и векторный слой можно «приземлить» рядом с остальными таблицами.

Pinecone: облачная векторная БД как сервис

Pinecone — это управляемая векторная база данных (vector database), которую вы используете как облачный сервис: без установки, настройки кластеров и постоянного «дежурства» по инфраструктуре. Вы создаёте индекс, загружаете эмбеддинги и метаданные, а дальше выполняете семантический поиск и поиск ближайших соседей через API.

Почему Pinecone часто выбирают «чтобы быстрее в продакшн»

Главная ценность — эксплуатация почти «из коробки». Pinecone берёт на себя типичные задачи, которые в self-hosted вариантах требуют времени и компетенций: масштабирование под нагрузку, управление ресурсами, обновления сервиса и стабильную доступность.

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

Что уточнить до выбора

Перед тем как «закрепиться» на Pinecone, полезно заранее проверить несколько пунктов:

• Регион и требования к данным: где физически обрабатываются и хранятся данные, подходит ли это под ваши комплаенс-правила.
• Ограничения по размерам и режимам: максимальные объёмы, лимиты запросов, поддерживаемые варианты фильтрации по метаданным.
• Стоимость по нагрузке: как тарифицируются хранение векторов, запросы, масштабирование при пиках. Важно оценить не только среднюю, но и пиковую активность.
• Операционные нюансы: мониторинг, SLA, бэкапы/восстановление, политики удаления данных.

Типичные кейсы

Pinecone особенно хорош, когда трафик непредсказуемый или быстро растёт: поддержка пользователей 24/7, поиск по базе знаний, рекомендации, RAG для поддержки клиентов. Если вы ожидаете резкие всплески запросов (например, маркетинговые кампании), управляемый сервис часто снижает риск «упасть» и ускоряет масштабирование без переделки архитектуры.

Weaviate: отдельная векторная платформа

Weaviate — это самостоятельная векторная платформа, которая запускается как отдельный сервер или кластер. Его часто выбирают, когда хочется отделить векторный поиск от основной транзакционной базы и при этом сохранить контроль над инфраструктурой. Разворачивать можно самостоятельно (например, в Kubernetes) или использовать облачные варианты Weaviate Cloud Service.

Модель данных: классы, схема и метаданные

В Weaviate данные организованы через классы (по сути — коллекции) и схему: вы заранее описываете, какие объекты храните и какие у них свойства. Помимо вектора, у каждого объекта есть метаданные (поля), по которым удобно фильтровать и строить более «бизнесовые» запросы: тип документа, язык, дата, источник, права доступа и т. п.

Важно, что метаданные — не просто «прицеп» к вектору: они участвуют в запросе наравне с похожестью, помогая отсекать нерелевантное ещё до ранжирования.

Поиск: векторы + фильтры и индексы

Типичный запрос в Weaviate — это поиск по похожести (nearest neighbors) с дополнительными фильтрами по метаданным. Например: «найди похожие фрагменты, но только из раздела “Договоры” и только за 2024 год». Платформа поддерживает разные варианты индексации для приближённого поиска ближайших соседей (ANN), что позволяет получать ответы быстро даже на больших объёмах.

Когда Weaviate особенно удобен

Weaviate хорош, когда нужен:

• контроль над развёртыванием (самостоятельный сервер/кластер, свои политики безопасности и сети);
• гибкая схема данных с богатой моделью объектов и метаданных;
• сочетание семантического поиска и строгих фильтров в одном запросе.

Если вам важно держать векторный слой как отдельный сервис с понятной структурой данных — Weaviate часто оказывается комфортным компромиссом между «всё внутри PostgreSQL» и полностью управляемым SaaS.

Как выбрать между pgvector, Pinecone и Weaviate

Выбор векторной БД обычно упирается не в «у кого лучше поиск», а в ваши ограничения: объём данных, нагрузку, требования к надёжности и то, кто будет всё это сопровождать.

1) Нагрузка и профиль данных

Если у вас умеренный объём эмбеддингов и запросов, а данные часто нужны вместе с привычными таблицами (пользователи, заказы, права), pgvector часто оказывается самым прямым путём: один PostgreSQL, один стек, одна модель доступа.

Если ожидаются высокие QPS и жёсткие требования по задержке, а векторный поиск — отдельный критичный сервис, проще смотреть в сторону Pinecone (как управляемого сервиса) или Weaviate (как отдельной платформы, которую можно держать у себя).

Также оцените частоту обновлений: при постоянных upsert/удалениях и «живом» каталоге важно, насколько удобно поддерживать индексы и пересборки, и какой SLA по деградациям во время обслуживания.

2) Операционные вопросы: кто будет «дежурить»

Pinecone снимает большую часть рутины: масштабирование, мониторинг, обновления. Вы платите деньгами, но экономите время команды.

pgvector — это ваши привычные бэкапы/репликации/миграции PostgreSQL, но ответственность за производительность векторных индексов и настройки остаётся на вас.

Weaviate требует дисциплины как у отдельного кластера: бэкапы, наблюдаемость, обновления, планирование ресурсов. Зато больше контроля над окружением.

3) Данные и безопасность

Если критична изоляция (регуляторика, чувствительные данные), часто выбирают pgvector (внутри существующего контура) или Weaviate on‑prem.

Для облачного сервиса (Pinecone) заранее проверьте: шифрование «на платформе», модель доступов, аудит, регионы, требования к ключам и журналированию.

Если у вас есть жёсткое требование «данные не покидают РФ», продумайте это заранее на уровне всей цепочки: где считаются эмбеддинги, где хранится индекс, где работает LLM. В российских контурах иногда удобнее стартовать с локальной инфраструктуры и/или платформ, которые изначально развёрнуты в РФ (в том числе TakProsto.AI, где используются локализованные и open-source LLM-модели и российские серверы).

4) Команда и стек

Есть сильная SQL‑экспертиза и уже живой PostgreSQL — pgvector обычно даёт минимум трения.

Нужно быстро запустить семантический поиск/RAG без отдельной SRE‑нагрузки — Pinecone часто самый быстрый старт.

Готовы держать отдельную платформу ради гибкости и контроля — смотрите на Weaviate.

Практика: сначала зафиксируйте целевые метрики (QPS, p95 latency, объём, SLA), а затем сделайте маленький POC на ваших данных — он быстрее выявит реальную стоимость и «узкие места», чем сравнение по описаниям.

Производительность, стоимость и типовые ошибки

Когда выбирают векторную БД, чаще всего спорят про «быстрее/точнее». Но на практике важнее другое: как система ведёт себя на ваших данных, при ваших фильтрах и при вашей нагрузке.

Скорость и качество поиска: измеряйте на своих данных

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

• возьмите 200–1000 реальных запросов пользователей;
• оцените качество (например, доля ответов, где нужный документ в top‑k);
• замерьте задержку p50/p95 при разных k и при включённых фильтрах.

Важно: фильтры по метаданным нередко «съедают» больше времени, чем сам поиск ближайших соседей.

Память и хранение: индексы и метаданные растут

Хранение — это не только сами векторы. Индекс приближённого поиска может занимать сопоставимый объём, а метаданные (тексты, идентификаторы, теги) иногда растут быстрее векторов.

Планируйте запас по памяти/диску и продумайте, где хранится «полный текст»: внутри БД или во внешнем хранилище с ссылкой.

Стоимость: не забудьте про «скрытые» статьи

Считайте бюджет по компонентам:

• хранение (векторы + индекс + метаданные);
• запросы (QPS, пиковые нагрузки, отдельные тарифы на операции);
• вычисления эмбеддингов (GPU/CPU, повторная индексация);
• сеть (пересылка больших батчей, межрегиональные вызовы).

Типичные ошибки, которые портят всё

1. Слишком большие чанки: модель «размывает» смысл, и top‑k становится менее точным.

2. Плохие фильтры: либо их нет (мусор в выдаче), либо они слишком узкие (почти нечего искать), либо фильтрация сделана так, что тормозит каждый запрос.

3. Неверная метрика похожести: разные эмбеддинги ожидают разные подходы (часто используют cosine similarity, но не всегда). Если метрика не соответствует модели, качество падает без очевидных причин.

4. Отсутствие мониторинга: без p95, процента пустых результатов и качества на контрольной выборке вы не заметите деградацию после обновления данных или модели.

Практический чек-лист внедрения

1) Подготовка данных: что вы индексируете

Сначала зафиксируйте «источник истины»: статьи базы знаний, тикеты, PDF, карточки товаров, переписки. Важно привести всё к одному формату текста и убрать шум: дубли, пустые страницы, служебные шапки/футеры, повторяющиеся навигационные блоки.

Дальше определите, какие метаданные понадобятся для фильтров: язык, продукт, версия документа, дата, доступ (роль), тип источника. Метаданные лучше продумать до загрузки — потом миграция бывает болезненной.

2) Разбиение на фрагменты (chunking)

Разбивайте документы на небольшие смысловые куски: абзацы, разделы, «вопрос–ответ». Слишком длинные фрагменты ухудшают точность, слишком короткие теряют контекст.

Часто помогает небольшое перекрытие между фрагментами (overlap), чтобы важная фраза не «резалась» пополам.

3) Эмбеддинги: единые правила

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

Нормализуйте текст одинаково для индексации и для запросов (регистр, пробелы, языковые особенности).

4) Загрузка в векторную БД

Шаги пайплайна: подготовка данных → разбиение на фрагменты → эмбеддинги → загрузка. Сразу храните связку: id фрагмента, текст, вектор, метаданные, ссылка на оригинал.

5) Минимальный пайплайн RAG в проде

Минимум состоит из трёх частей: индексирование (ingestion), retrieval (поиск top-k), сбор контекста (объединение найденных фрагментов и передача в LLM).

На этом этапе заранее решите: сколько фрагментов брать, как удалять дубликаты, что делать с конфликтующими источниками.

Если делаете это в прикладном продукте, удобно иметь «режим планирования» и быстрые откаты изменений пайплайна (настройки чанков, k, фильтров, промпта). В TakProsto.AI для таких итераций полезны snapshots и rollback: можно быстро проверить гипотезу и вернуться к стабильной версии без ручной возни с окружениями.

6) Контроль качества: до и после релиза

Начните с ручных примеров: 20–50 типовых запросов и «ожидаемые» документы. Затем добавьте метрики (например, доля запросов, где нужный источник попал в top‑k) и A/B для выдачи: сравнивайте разные настройки chunking, k, фильтры и модель эмбеддингов.

7) Логи и наблюдаемость

Логируйте: исходный запрос, применённые фильтры, top‑k результаты, расстояния/score, какие фрагменты ушли в контекст, а также клики/оценки пользователей. Эти данные быстро покажут, что ломается — индекс, фильтры, качество эмбеддингов или сбор контекста.

FAQ: частые вопросы о векторных БД

Нужно ли хранить исходный текст в векторной БД или отдельно?

Чаще всего — отдельно. Векторная БД хорошо хранит вектор + идентификатор + метаданные (например, doc_id, раздел, язык, даты, права доступа), а сам текст и «источник правды» остаются в вашем хранилище: PostgreSQL, S3/объектное хранилище, CMS, документооборот.

Хранить текст в векторной БД удобно для быстрого прототипа и простого RAG, но это может осложнить:

• контроль доступа (если он уже реализован в основной БД);
• обновления контента (дублирование данных);
• юридические требования к хранению и аудиту.

Практика: кладите в векторную БД короткий snippet (1–3 предложения) для превью, а полный текст подтягивайте по doc_id.

Как обновлять эмбеддинги при смене модели?

Смена модели почти всегда означает, что старые и новые векторы нельзя смешивать: у них разные «координаты смысла».

Делайте миграцию через версионирование:

• храните поле model_version в метаданных;
• создайте новую коллекцию/таблицу под новую модель;
• переиндексируйте данные батчами;
• переключите поиск на новую версию после контроля качества.

Если нужно обновляться без простоя — держите две версии параллельно и постепенно переводите трафик.

Сколько текста класть в один «чанк»?

Обычно лучше начинать с 300–800 токенов на чанк (или 1–3 абзаца) с небольшим overlap. Слишком маленькие чанки теряют контекст, слишком большие ухудшают точность и увеличивают стоимость.

Проверяйте на своих запросах: цель — чтобы один найденный чанк содержал достаточно информации для ответа без «склейки» из десятка фрагментов.

Можно ли обойтись без векторной БД (когда достаточно FTS/поиска)?

Да, если у вас:

• поиск по точным словам, артикулам, кодам, названиям;
• строгие фильтры и сортировки важнее «смысла»;
• небольшой набор документов и устраивает обычный полнотекстовый поиск (FTS).

Векторная база данных нужна, когда пользователи формулируют запросы по-разному, есть синонимы и «похожий смысл», а также когда вы строите RAG и хотите доставать релевантные фрагменты даже без совпадения ключевых слов.