Как работает семантический поиск (и почему keyword не справляется)
Как работает семантический поиск в 2026 — эмбеддинги, векторы и гибридный retrieval плоским языком. Почему keyword-поиск продолжает терять твои сохранёнки, и что это чинит.
Набери «сколько стоит привлечь клиентов» в поиск по сохранёнкам и смотри как ничего не матчится. Видео которое ищешь — прямо в библиотеке, ты его сохранил. Спикер шестнадцать раз сказал «CAC». Твой запрос сказал «customer acquisition cost». Слова не совпадают. Матч проваливается.
У этого failure mode есть имя: vocabulary mismatch problem. Именно поэтому keyword search продолжает терять, и поэтому семантический поиск теперь default в каждом серьёзном инструменте который ищет что-то text-shaped. Дальше: как семантический поиск реально работает в 2026 — обычным языком, без степени по матану — и почему большинство consumer-приложений с «AI search» всё равно делают это неправильно.
Vocabulary mismatch problem за 60 секунд
Старые поисковые системы матчили литеральные строки. Печатаешь customer acquisition cost, система находит документы где эти точные слова. Документы где говорят «CAC», или «сколько мы платим за привлечение нового покупателя», или «сколько у нас на сигнап» — остаются невидимыми.
В research'е по information retrieval это меряли сорок лет. Типичный vocabulary mismatch где-то 70-80%: люди используют разные слова для одного и того же концепта в большинстве случаев. Если поиск матчит только литеральные строки — пропускаешь четыре из пяти релевантных документов. Это вежливо сказать «keyword search сломан с 1985-го».
Две вещи это починили. Первая — эмбеддинги: способ представить смысл числами, так что две фразы означающие одно — оказываются «близко», даже если у них нет общих слов. Вторая — векторные базы данных: хранилища и индексы способные быстро находить ближайшие векторы, даже если корпус — миллионы документов.
Вместе — это то что делает «семантический поиск» возможным.
Что такое эмбеддинг, плоским языком
Возьми предложение. Прогони через нейросеть. Сеть возвращает список чисел — обычно 384, 768 или 1536. Этот список — это эмбеддинг предложения.
Фишка в том что сеть тренируется так что предложения с похожим смыслом дают похожие списки. Буквальный пример:
"Что такое customer acquisition cost"→ эмбеддинг A"Сколько мы платим чтобы привести нового клиента"→ эмбеддинг B"Как там чайки сегодня"→ эмбеддинг C
Эмбеддинги A и B будут близко в 1536-мерном пространстве в котором живут. C будет далеко. Близость меряется через cosine similarity — насколько два вектора выровнены в этом высокоразмерном пространстве. Числа около 1.0 — почти одинаковый смысл; около 0 — несвязанные.
Можно думать об этом как о плотинге каждой фразы как точки в 1536-мерной галактике где направление кодирует смысл. Сами координаты бессмысленны — важно какие другие фразы приземляются рядом.
Модель которая это делает
В 2026-м несколько моделей конкурентны. text-embedding-3-small от OpenAI отгружает 1536 размерностей нативно и поддерживает Matryoshka representation (можно усечь до 768 или 256 для экономии хранения без переобучения). embed-v3 от Cohere конкурентен на мультиязычном контенте. Open-source альтернативы типа bge-large и nomic-embed-text отстают на несколько процентов точности и крутятся на Mac'е.
Для мультиязычных нагрузок — типа сохранёнок на 30 языках с запросами на любом — text-embedding-3-small сейчас лучший баланс точности, цены и размерности. В SavedThat мы используем 768-мерное Matryoshka-усечение: половина хранения, ~99% качества поиска. (Подробнее про Matryoshka representation.)
Почему «просто используй AI» не равно семантическому поиску
Много consumer-приложений в 2026-м рекламируют «AI search». Большинство из них имеет в виду одно из трёх:
- Настоящий семантический поиск — эмбеддинги + vector retrieval, как описано выше.
- LLM-поверх-keyword-поиска — система делает keyword-поиск, получает результаты, потом просит LLM перефразировать или резюмировать. Retrieval всё равно keyword-сломан; LLM просто закрашивает провалы.
- Чистый LLM Q&A — задаёшь вопрос, LLM отвечает из своего общего обучения, твой сохранённый контент вообще не консультируется.
Только первый реально решает vocabulary mismatch на твоих данных. Остальные два — продуктизированы но бесполезны для поиска того что ты сохранил.
Быстрый диагностический тест: если ты ищешь концепт и не находишь документ, но находишь по одному из конкретных слов — инструмент делает #2 или #3 завёрнутые в «AI search». Если документ находится по перефразированному запросу — это #1.
Векторные базы данных: хранение и быстрый поиск эмбеддингов
Эмбеддинги сами по себе не помогают если нужно сравнивать каждый запрос с миллионами векторов по очереди. Полный поиск по 50 000-документному индексу наивным способом — сотни миллисекунд, слишком медленно для интерактивного использования.
Чинит это approximate nearest neighbour (ANN) индексация. Специализированные структуры данных — HNSW (Hierarchical Navigable Small World), IVF, ScaNN — хранят векторы так что ближайшие матчи находятся менее чем за 10 миллисекунд даже на библиотеках с десятками миллионов векторов.
Текущий state of the art (май 2026) для production semantic search:
- HNSW-индексация — самая часто деплоящаяся. У Postgres есть через расширение
pgvector; standalone vector DB типа Qdrant, Pinecone и Weaviate используют HNSW или близкие варианты. SavedThat крутит HNSW наpgvectorпотому что держать векторы рядом с реляционной метадатой операционно проще чем мейнтейнить две базы. - Half-precision хранение. С 16-битными float'ами на размерность вместо 32-битных векторы занимают пол-диска. Потеря качества — пренебрежимая для retrieval. Тип
halfvec(768)вpgvectorтеперь default для любого деплоя который думает о costs. - MRL (Matryoshka) усечение. Тренируется-один-раз 1536-мерных эмбеддингов усекается на хранении до 768 или 256 размерностей в зависимости от use case. Ищешь сначала по быстрому 256-мерному индексу, ре-ранкуешь топ-100 против 768-мерной или 1536-мерной версии.
Для SavedThat-масштаба (сейчас ~120 сохранённых видео × ~50 чанков каждое = 6000 векторов), индекс помещается в RAM и lookup'ы — субмиллисекунда.
Подвох: семантический поиск один сам ошибается на exact phrases
Теперь punchline которую большинство туториалов пропускают: семантический поиск проигрывает keyword-поиску на точных фразах.
Если ищешь "text-embedding-3-small" (точное название продукта), keyword-поиск возвращает документ упоминающий именно эту строку на ранге 1. Семантический поиск может ранкнуть выше документ который говорит про «OpenAI embeddings вообще» потому что он семантически ближе к среднему смыслу запроса, даже хотя литеральной строки нет.
Это реально. Публичные бенчмарки стабильно показывают что чистый семантический поиск проигрывает keyword'у на запросах с высокой specificity: названия продуктов, сигнатуры функций, точные цитаты, даты, бренды. То что семантика должна была починить (vocabulary mismatch) не существует для таких запросов, потому что юзер набрал ту литеральную строку которую хотел.
Фикс — запускать оба и мерджить результаты.
Гибридный retrieval с reciprocal rank fusion
Гибридный retrieval — техника которая тихо стала default в серьёзных production-системах поиска с 2024-го:
- Запусти семантический поиск (vector similarity). Получи top-K результатов ранжированных по cosine.
- Запусти full-text поиск (keyword, tsvector, BM25, что угодно). Получи top-K ранжированных по relevance score.
- Слей два списка через reciprocal rank fusion (RRF): RRF-скор каждого документа это
1 / (rank + 60), просуммированный по двум методам. Документы которые хорошо появляются в обоих получают значимый буст; документы появляющиеся только в одном всё равно вкладываются. - Сортируй по объединённому RRF-скору.
Константа 60 — magic number которое бенчмаркали до смерти и работает на большинстве корпусов. Можно тюнить, обычно не нужно.
Результат: перефразированные запросы всё ещё находят concept-матчи (через семантическую сторону), а exact-phrase запросы всё ещё ранкают литеральный матч на #1 (через keyword сторону). Слепое пятно каждого метода покрыто другим.
Это и есть то что SavedThat шипит как default поиск. RPC search_chunks в нашем Postgres запускает оба запроса параллельно, считает RRF-скоры и возвращает ранжированные хиты за ~80мс на нашем текущем размере корпуса. (Microsoft про hybrid search)
Где это становится сложнее: re-ranking
Для high-stakes use cases — legal discovery, медицинская литература, enterprise-поиск по миллионам документов — гибридный RRF обычно предпоследний слой. Последний — re-ranking через cross-encoder модель.
Cross-encoder — это меньшая, медленная модель которая берёт полный запрос и полный кандидат-документ и считает плотный relevance score аттендя по обоим совместно. Нельзя запускать на миллионе документов (слишком медленно); запускаешь на топ-50–200 результатах из гибридного retrieval'а чтобы переупорядочить точно.
Cohere отгружает rerank-v3 для этого. Open-source альтернативы: bge-reranker-large, jina-reranker-v2. Для consumer-масштаба типа SavedThat marginal gain не оправдывает 100мс latency hit. Для enterprise legal-discovery поиска cross-encoder re-ranking теперь стандарт.
Добавим когда корпус или use case потребует. Не раньше.
Картина цен
Весь пайплайн примерно такой:
| Стадия | Стоимость |
|---|---|
| Эмбеддинг 1000 чанков (~50 видео) | ~$0.02 в OpenAI-кредитах |
| Хранение 1М чанков в pgvector | ~$25/мес на маленьком Postgres-инстансе |
| Сборка HNSW-индекса для 1М чанков | ~30 секунд, разовая операция при major data change |
| Один поисковый запрос (embed + HNSW lookup + FTS + RRF) | ~$0.0001 + 80мс |
На прайсе SavedThat одна Pro-подписка ($6.99/мес) покрывает тысячи запросов и несколько сотен новых сохранений. Экономика норм для consumer-масштаба; что не работает — попытка финансировать это free-forever-unlimited планом, потому что OpenAI-bill растёт линейно с контентом, а выручка капается в ноль.
Почему большинство «второй мозг» инструментов этого не шипят
Три причины:
- Инженерная сложность. Гибридный retrieval с RRF требует запустить две retrieval-системы и слить. Большинство команд шипят одну. Эта одна обычно keyword потому что она старше и стек зрелее.
- Стоимость хранения. Эмбеддинги на 1536 размерности × 4 байта/размерность = ~6КБ на чанк. Библиотека из 100 000 чанков — 600МБ vector-хранения поверх оригинального текста. Без
halfvecи MRL — математика в два раза. - Инерция. Большинство существующих заметочных инструментов шипились до того как sentence-эмбеддинги стали commodity. Доделывать semantic search в Evernote или Pocket потребовало бы vector-database проекта который орг никогда не приоритизировал.
Инструменты шипающие семантический поиск с первого дня — Mem, Reflect, premium-тариф Glasp, SavedThat — в основном пост-2022 билды потому что именно тогда стоимость эмбеддинга упала ниже порога где consumer-масштаб можно прайсить устойчиво.
Что это означает практически
Когда оцениваешь search-inside-X инструмент в 2026, спрашивай:
- Эмбеддит? Если архитектурная диаграмма не включает vector-store — ответ нет.
- Запускает гибридный retrieval? Чистая семантика хуже гибрида для многих реальных запросов. Инструменты шипящие «vector search» но не full-text — делают это наполовину правильно.
- Поддерживает мультиязык? Это функция embedding-модели, а не инфры поиска.
text-embedding-3-smallработает на 100+ языков; старые или меньшие модели — нет. - Раскрывает математику вообще? Инструменты которые объясняют свой retrieval обычно делают его хорошо. Инструменты говорящие «AI-powered search ✨» без специфики обычно делают пункт 2 или 3 из выше (LLM-поверх-keyword или чистый Q&A).
Для сохранения видео и поиска позже: SavedThat отгружает все четыре (архитектурный обзор тут). Glasp шипит keyword only (free) и семантику (платно). Mem шипит семантику только, без гибрида. «AI search» Notion — это пункт 2: LLM на keyword.
Такая лежанка в мае 2026.
Keep reading
Search inside saved videos: the complete 2026 guide
Search inside saved videos by what was actually said — across YouTube, Instagram, and TikTok. How transcript search works in 2026, and four tools that do it.
The 7 best video transcript search tools in 2026
The 7 best video transcript search tools in 2026, ranked by what they actually do well. SavedThat, Glasp, Otter, Fireflies, Reduct, Trint, plus DIY Whisper.
Best AI video bookmark manager in 2026: 4 tools compared
The best AI video bookmark manager in 2026 depends on what you save. Honest comparison of SavedThat, Mymind, Raindrop, and Glasp — pricing, search, platforms.
Frequently asked questions (2026)
В чём разница между эмбеддингом и вектором?
Функционально — никакой, на практике термины используются взаимозаменяемо. Строго: эмбеддинг — это *представление* которое выдаёт модель, а вектор — это просто список чисел. Каждый эмбеддинг это вектор; не каждый вектор это эмбеддинг (колонка интенсивностей пикселей — вектор, но не эмбеддинг). Большинство статей и инженерных доков используют «вектор» как storage-термин и «эмбеддинг» как концептуальный.
Семантический поиск работает на любом языке?
Зависит от embedding-модели. OpenAI text-embedding-3-small тренировали на 100+ языков и выдаёт векторы примерно выровненные между ними — русский запрос и английский документ про один концепт приземляются в похожих регионах vector space. Меньшие open-source модели часто заметно деградируют на не-английском. Если мультиязык — требование, проверь что model card явно упоминает cross-lingual alignment.
Чем гибридный поиск отличается от запуска двух поисков и показа обоих?
Запуск двух поисков и конкатенация результатов просто даёт в два раза больше результатов. Гибридный поиск мерджит их по скору (RRF или weighted fusion) так что финальное ранжирование отражает согласие обоих методов. Документ на ранге 1 в keyword и ранге 1 в семантике в итоге на ранге 1 общем; документ на ранге 1 в keyword но 50 в семантике падает в середину. Без мерджа непонятно каким результатам верить.
Почему чистый семантический поиск проигрывает keyword'у на точных фразах?
Эмбеддинги кодируют семантический смысл, а не литеральные строки. Запрос вроде «text-embedding-3-small» имеет смысл больше в «член семейства OpenAI embeddings» чем в литеральной последовательности токенов. Вектор запроса похож на векторы документов обсуждающих OpenAI-эмбеддинги в целом, которые могут ранкнуть выше конкретного документа упоминающего точное имя продукта. У keyword-поиска ноль неоднозначности на exact strings — они либо есть, либо нет. Гибрид покрывает оба режима.
RAG — это то же что семантический поиск?
Связано, но не одно. Семантический поиск — это retrieval-шаг — найти документы близкие к запросу в vector space. RAG (Retrieval-Augmented Generation) — это система которая использует семантический поиск чтобы достать документы, потом передаёт их генеративной LLM которая пишет ответ используя документы как контекст. RAG включает семантический поиск как один компонент; можно иметь семантический поиск без RAG (когда просто хочешь найти документы, а не генерировать поверх текст).
Нужен GPU чтобы крутить семантический поиск?
Для inference — поиска по построенному индексу — нет. CPU справляется с retrieval на consumer-масштабе. Для построения индекса — запуска embedding-модели на твоём контенте — GPU быстрый, но не обязательный. API OpenAI делает эмбеддинг в их датацентре, возвращая вектор тебе на хранение; на твоей стороне только vector-база и query-эмбеддинг (один короткий API-вызов на запрос). Цена — копейки за тысячу поисков.