Как работает семантический поиск в 2026 — эмбеддинги, векторы и гибридный retrieval плоским языком. Почему keyword-поиск продолжает терять твои сохранёнки, и что это чинит.
Набери «сколько стоит привлечь клиентов» в поиск по сохранёнкам и смотри как ничего не матчится. Видео которое ищешь — прямо в библиотеке, ты его сохранил. Спикер шестнадцать раз сказал «CAC». Твой запрос сказал «customer acquisition cost». Слова не совпадают. Матч проваливается.
У этого failure mode есть имя: vocabulary mismatch problem. Именно поэтому keyword search продолжает терять, и поэтому семантический поиск теперь default в каждом серьёзном инструменте который ищет что-то text-shaped. Дальше: как семантический поиск реально работает в 2026 — обычным языком, без степени по матану — и почему большинство consumer-приложений с «AI search» всё равно делают это неправильно.
Старые поисковые системы матчили литеральные строки. Печатаешь 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.)
Много consumer-приложений в 2026-м рекламируют «AI search». Большинство из них имеет в виду одно из трёх:
Только первый реально решает 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:
pgvector; standalone vector DB типа Qdrant, Pinecone и Weaviate используют HNSW или близкие варианты. SavedThat крутит HNSW на pgvector потому что держать векторы рядом с реляционной метадатой операционно проще чем мейнтейнить две базы.halfvec(768) в pgvector теперь default для любого деплоя который думает о costs.Для SavedThat-масштаба (сейчас ~120 сохранённых видео × ~50 чанков каждое = 6000 векторов), индекс помещается в RAM и lookup'ы — субмиллисекунда.
Теперь punchline которую большинство туториалов пропускают: семантический поиск проигрывает keyword-поиску на точных фразах.
Если ищешь "text-embedding-3-small" (точное название продукта), keyword-поиск возвращает документ упоминающий именно эту строку на ранге 1. Семантический поиск может ранкнуть выше документ который говорит про «OpenAI embeddings вообще» потому что он семантически ближе к среднему смыслу запроса, даже хотя литеральной строки нет.
Это реально. Публичные бенчмарки стабильно показывают что чистый семантический поиск проигрывает keyword'у на запросах с высокой specificity: названия продуктов, сигнатуры функций, точные цитаты, даты, бренды. То что семантика должна была починить (vocabulary mismatch) не существует для таких запросов, потому что юзер набрал ту литеральную строку которую хотел.
Фикс — запускать оба и мерджить результаты.
Гибридный retrieval — техника которая тихо стала default в серьёзных production-системах поиска с 2024-го:
1 / (rank + 60), просуммированный по двум методам. Документы которые хорошо появляются в обоих получают значимый буст; документы появляющиеся только в одном всё равно вкладываются.Константа 60 — magic number которое бенчмаркали до смерти и работает на большинстве корпусов. Можно тюнить, обычно не нужно.
Результат: перефразированные запросы всё ещё находят concept-матчи (через семантическую сторону), а exact-phrase запросы всё ещё ранкают литеральный матч на #1 (через keyword сторону). Слепое пятно каждого метода покрыто другим.
Это и есть то что SavedThat шипит как default поиск. RPC search_chunks в нашем Postgres запускает оба запроса параллельно, считает RRF-скоры и возвращает ранжированные хиты за ~80мс на нашем текущем размере корпуса. (Microsoft про hybrid search)
Для 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-подписка ($9.99/мес) покрывает тысячи запросов и несколько сотен новых сохранений. Экономика норм для consumer-масштаба; что не работает — попытка финансировать это free-forever-unlimited планом, потому что OpenAI-bill растёт линейно с контентом, а выручка капается в ноль.
Три причины:
halfvec и MRL — математика в два раза.Инструменты шипающие семантический поиск с первого дня — Mem, Reflect, premium-тариф Glasp, SavedThat — в основном пост-2022 билды потому что именно тогда стоимость эмбеддинга упала ниже порога где consumer-масштаб можно прайсить устойчиво.
Когда оцениваешь search-inside-X инструмент в 2026, спрашивай:
text-embedding-3-small работает на 100+ языков; старые или меньшие модели — нет.Для сохранения видео и поиска позже: SavedThat отгружает все четыре (архитектурный обзор тут). Glasp шипит keyword only (free) и семантику (платно). Mem шипит семантику только, без гибрида. «AI search» Notion — это пункт 2: LLM на keyword.
Такая лежанка в мае 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 в семантике падает в середину. Без мерджа непонятно каким результатам верить.
Эмбеддинги кодируют семантический смысл, а не литеральные строки. Запрос вроде «text-embedding-3-small» имеет смысл больше в «член семейства OpenAI embeddings» чем в литеральной последовательности токенов. Вектор запроса похож на векторы документов обсуждающих OpenAI-эмбеддинги в целом, которые могут ранкнуть выше конкретного документа упоминающего точное имя продукта. У keyword-поиска ноль неоднозначности на exact strings — они либо есть, либо нет. Гибрид покрывает оба режима.
Связано, но не одно. Семантический поиск — это retrieval-шаг — найти документы близкие к запросу в vector space. RAG (Retrieval-Augmented Generation) — это система которая использует семантический поиск чтобы достать документы, потом передаёт их генеративной LLM которая пишет ответ используя документы как контекст. RAG включает семантический поиск как один компонент; можно иметь семантический поиск без RAG (когда просто хочешь найти документы, а не генерировать поверх текст).
Для inference — поиска по построенному индексу — нет. CPU справляется с retrieval на consumer-масштабе. Для построения индекса — запуска embedding-модели на твоём контенте — GPU быстрый, но не обязательный. API OpenAI делает эмбеддинг в их датацентре, возвращая вектор тебе на хранение; на твоей стороне только vector-база и query-эмбеддинг (один короткий API-вызов на запрос). Цена — копейки за тысячу поисков.
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, ranked by what they actually do well. SavedThat, Glasp, Otter, Fireflies, Reduct, Trint, plus DIY Whisper.
The best AI video bookmark manager in 2026 depends on what you save. Honest comparison of SavedThat, Mymind, Raindrop, and Glasp — pricing, search, platforms.