Свой семантический поиск в 2026: embeddings + векторная база с нуля

ПОЧЕМУ КЛЮЧЕВЫЕ СЛОВА УМЕРЛИ

Классический полнотекстовый поиск (тот самый BM25, что живёт в Postgres, Elasticsearch и Lucene) ищет пересечение токенов. Запрос «как ускорить холодный старт лямбды» не найдёт документ про «cold start в serverless», если там нет буквального слова «лямбда». Пользователь думает смыслами, индекс — строками. Разрыв.

Семантический поиск закрывает этот разрыв. Он превращает и запрос, и документы в векторы (embeddings) — точки в многомерном пространстве, где близость по смыслу означает близость в геометрии. «Собака» и «пёс» окажутся рядом, хотя не имеют ни одной общей буквы в нужной форме. Дальше остаётся найти ближайших соседей к вектору запроса. Всё.

Важно не впадать в фанатизм: BM25 всё ещё бьёт эмбеддинги на точных совпадениях — артикулы, коды ошибок, имена функций. Поэтому продакшн-стек 2026 почти всегда гибридный. Но фундамент — векторный, и именно его мы собираем.

ИЗ ЧЕГО СОСТОИТ СТЕК

Любой семантический поиск — это конвейер из четырёх звеньев:

1. Чанкинг — режем документы на куски разумного размера (обычно 200-500 токенов), потому что эмбеддинг всей статьи размывает смысл в «среднюю температуру».
2. Embeddings — модель превращает каждый чанк в вектор фиксированной длины (384, 768, 1024, 1536 измерений в зависимости от модели).
3. Векторная база — хранит векторы и умеет за миллисекунды находить ближайших соседей через приближённый поиск (ANN, чаще всего HNSW).
4. Реранкинг — опциональный, но мощный шаг: cross-encoder переоценивает топ-20 кандидатов и вытаскивает наверх реально релевантное.

Ошибка новичков — вкладываться только в звено 2, забивая на 1 и 4. На практике грамотный чанкинг и реранкер дают прирост качества больше, чем смена embedding-модели на «более топовую».

ВЫБОР EMBEDDING-МОДЕЛИ

В 2026 не обязательно платить за API. Открытые модели догнали проприетарные для большинства задач. Ориентир по качеству — лидерборд MTEB, но не гонитесь за первой строчкой: разница между топ-1 и топ-10 часто в пределах шума, а вот размерность вектора и скорость различаются в разы.

Практические соображения при выборе:

• Мультиязычность. Для русского берите модели с явной поддержкой (multilingual-e5, bge-m3 и подобные). Чисто английские на кириллице проседают.
• Размерность. 384 против 1024 — это в ~2.7 раза больше памяти и медленнее поиск. Для сотен тысяч документов 384-768 обычно достаточно.
• Matryoshka-эмбеддинги. Модели, где можно обрезать вектор до нужной длины без переобучения — удобно балансировать качество и цену.
• Инструкция-префиксы. Многие модели (семейство e5) требуют префиксов вроде query: и passage:. Забудете — качество молча упадёт.

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

СРАВНЕНИЕ ВЕКТОРНЫХ БАЗ

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

Практическое правило: начинайте с FAISS или Chroma для прототипа, переезжайте на Qdrant или pgvector в продакшн. Если у вас уже крутится Postgres — pgvector экономит целый сервис и упрощает бэкапы. Milvus и облачные managed-решения нужны, когда векторов реально миллионы и есть команда на поддержку.

СОБИРАЕМ ПОИСК: РАБОЧИЙ КОД

Минимальный, но честный пример на Python: локальная модель через sentence-transformers, хранение и поиск в Chroma. Никаких платных API, всё крутится на ноутбуке.

# pip install sentence-transformers chromadb
from sentence_transformers import SentenceTransformer
import chromadb

# 1. Модель. Мультиязычная, 384 измерения — быстрая и легкая
model = SentenceTransformer("intfloat/multilingual-e5-small")

def embed(texts, prefix):
    # e5 требует префиксы query:/passage: — иначе качество падает
    prepared = [f"{prefix}: {t}" for t in texts]
    return model.encode(prepared, normalize_embeddings=True).tolist()

# 2. База (persistent — переживёт перезапуск)
client = chromadb.PersistentClient(path="./vecdb")
col = client.get_or_create_collection(
    name="docs",
    metadata={"hnsw:space": "cosine"}  # косинусная близость
)

# 3. Индексация документов (чанки)
docs = [
    "Холодный старт в serverless возникает при инициализации нового контейнера.",
    "HNSW — граф-индекс для быстрого приближённого поиска соседей.",
    "BM25 ранжирует документы по частоте терминов и обратной частоте.",
]
col.add(
    ids=[f"d{i}" for i in range(len(docs))],
    embeddings=embed(docs, "passage"),
    documents=docs,
)

# 4. Поиск по смыслу
query = "как уменьшить задержку первого запроса в облачных функциях"
res = col.query(
    query_embeddings=embed([query], "query"),
    n_results=2,
)
for doc, dist in zip(res["documents"][0], res["distances"][0]):
    print(round(1 - dist, 3), doc)  # 1 - cos_distance = similarity

Запрос про «задержку первого запроса» найдёт документ про холодный старт, хотя дословных совпадений почти нет. Это и есть тот эффект, ради которого всё затевалось.

ГИБРИД И РЕРАНКИНГ: КАК ВЫЖАТЬ КАЧЕСТВО

Гибридный поиск

Комбинируйте BM25 (лексика) и векторный поиск (смысл). Простейший способ объединить результаты — Reciprocal Rank Fusion: каждый документ получает балл 1 / (k + rank) из каждого списка, баллы складываются. Никакого обучения, работает из коробки и стабильно поднимает метрики против чистой векторки.

Реранкинг

Векторный поиск быстрый, но грубый: он сравнивает уже сжатые представления. Cross-encoder (реранкер) берёт топ-20 кандидатов и оценивает каждую пару «запрос-документ» целиком, гораздо точнее. Схема:

1. Векторный поиск достаёт 20-50 кандидатов (быстро, дёшево).
2. Cross-encoder переоценивает их (медленнее, но кандидатов мало).
3. Отдаём пользователю топ-5 после переоценки.

По замерам сообщества связка «bi-encoder + реранкер» стабильно обгоняет одиночный эмбеддинг-поиск по релевантности, ценой десятков миллисекунд на переоценку. Для большинства продуктов это выгодный обмен.

ГРАБЛИ, НА КОТОРЫЕ НАСТУПАЮТ ВСЕ

• Разные модели на индекс и запрос. Векторы из разных моделей несравнимы. Индексировали одной — ищите той же.
• Забытая нормализация. Для косинусной близости векторы нужно нормализовать. Смешаете нормализованные и нет — метрика поедет.
• Чанки-гиганты. Эмбеддинг страницы текста усредняет смысл до бесполезности. Режьте на смысловые куски, добавляйте перекрытие (overlap) 10-15%.
• Игнор метаданных. Фильтр по дате/автору/языку до векторного поиска экономит время и режет мусор. Qdrant и pgvector это умеют нативно.
• Слепая вера в MTEB. Лидерборд — усреднение по чужим задачам. Соберите свой мини-набор из 30-50 реальных запросов и меряйте на нём.

Если собираете свой поисковый стек и хотите ловить свежие embedding-модели и релизы векторных баз раньше остальных — заглядывайте в Telegram-канал REDDYX AI — новые репозитории каждые 30-60 минут.