Как работает семантический поиск и почему ключевых слов мало
Как работает семантический поиск в 2026: эмбеддинги, векторы и гибридный поиск простым языком. Почему поиск по словам теряет твои сохранённые видео.
Введи «сколько стоит привлечь клиентов» в поиск по сохранённым видео и посмотри, как ничего не находится. Видео, которое ты ищешь, лежит прямо в библиотеке, ты сам его сохранил. Спикер шестнадцать раз сказал «CAC». А в твоём запросе было «customer acquisition cost». Слова не совпадают, и поиск ничего не находит.
У этой проблемы есть название: несовпадение словаря (vocabulary mismatch). Именно из-за неё поиск по ключевым словам продолжает промахиваться, и поэтому семантический поиск сейчас используется по умолчанию в любом серьёзном инструменте, который ищет по тексту. Дальше расскажем, как на самом деле работает семантический поиск в 2026 году, простым языком и без высшей математики, и почему большинство потребительских приложений с «AI-поиском» всё равно делают его неправильно.
Проблема несовпадения словаря за 60 секунд
Старые поисковые системы искали буквальное совпадение строк. Вводишь customer acquisition cost, и система находит документы, где есть именно эти слова. Документы, где говорят «CAC», или «сколько мы платим за нового покупателя», или «во что нам обходится одна регистрация», остаются невидимыми.
Исследователи информационного поиска измеряют это уже сорок лет. Обычно несовпадение словаря составляет 70-80%: в большинстве случаев люди называют одно и то же понятие разными словами. Если поиск ищет только буквальные совпадения, ты пропускаешь четыре релевантных документа из пяти. Мягко говоря, поиск по ключевым словам сломан с 1985 года.
Исправили это две вещи. Первая — эмбеддинги: способ представить смысл числами так, чтобы две фразы, которые значат одно и то же, оказывались «рядом», даже если у них нет ни одного общего слова. Вторая — векторные базы данных: хранилища и индексы, которые быстро находят ближайшие векторы, даже если в корпусе миллионы документов.
Вместе они и делают семантический поиск возможным.
Что такое эмбеддинг простыми словами
Возьми предложение. Пропусти его через нейросеть. Сеть вернёт список чисел, обычно 384, 768 или 1536 штук. Этот список и есть эмбеддинг предложения.
Суть в том, что сеть обучают так, чтобы предложения с похожим смыслом давали похожие списки. Наглядный пример:
"Что такое customer acquisition cost"→ эмбеддинг A"Сколько мы платим чтобы привести нового клиента"→ эмбеддинг B"Как там чайки сегодня"→ эмбеддинг C
Эмбеддинги A и B окажутся близко друг к другу в 1536-мерном пространстве, где они находятся. C окажется далеко. Близость измеряют косинусным сходством: насколько два вектора смотрят в одну сторону в этом многомерном пространстве. Значения около 1,0 означают почти одинаковый смысл, около 0 — отсутствие связи.
Можно представить, что каждая фраза — это точка в 1536-мерной галактике, где направление кодирует смысл. Сами координаты ничего не значат, важно то, какие другие фразы оказываются рядом.
Модель, которая это делает
В 2026 году конкурируют несколько моделей. text-embedding-3-small от OpenAI изначально выдаёт 1536 измерений и поддерживает представление Matryoshka (вектор можно укоротить до 768 или 256 измерений, чтобы сэкономить место, без переобучения). embed-v3 от Cohere хорошо справляется с многоязычным контентом. Открытые альтернативы вроде bge-large и nomic-embed-text уступают по точности несколько процентов и запускаются прямо на Mac.
Для многоязычных задач, например сохранённых видео на 24 языках (столько их было на 30 сентября 2026 года в видео, которые сохранили пользователи SavedThat) и запросов на любом из них, text-embedding-3-small сейчас даёт лучший баланс точности, цены и размерности. В SavedThat мы используем укороченную по Matryoshka версию на 768 измерений: вдвое меньше места и около 99% качества поиска. (Подробнее о представлении Matryoshka.)
Почему «просто добавь AI» ещё не семантический поиск
Многие потребительские приложения в 2026 году рекламируют «AI-поиск». Большинство имеет в виду одно из трёх:
- Настоящий семантический поиск: эмбеддинги плюс поиск по векторам, как описано выше.
- LLM поверх поиска по ключевым словам: система ищет по ключевым словам, получает результаты, а потом просит LLM переформулировать или пересказать их. Сам поиск по-прежнему сломан на уровне ключевых слов, LLM просто маскирует провалы.
- Чистые вопросы и ответы к LLM: задаёшь вопрос, LLM отвечает на основе общих знаний, а твой сохранённый контент вообще не используется.
Проблему несовпадения словаря на твоих данных реально решает только первый вариант. Два других упакованы в продукт, но бесполезны, когда нужно найти то, что сохранил ты.
Быстрая проверка: если по понятию документ не находится, а по одному из конкретных слов находится, значит, инструмент делает вариант 2 или 3 под вывеской «AI-поиска». Если документ находится по перефразированному запросу, это вариант 1.
Векторные базы данных: как хранить эмбеддинги и быстро по ним искать
Сами по себе эмбеддинги не помогут, если каждый запрос приходится по очереди сравнивать с миллионами векторов. Полный перебор индекса на 50 000 документов наивным способом занимает сотни миллисекунд, а это слишком медленно для интерактивной работы.
Эту проблему решает индексация для приближённого поиска ближайших соседей (ANN). Специальные структуры данных (HNSW, то есть Hierarchical Navigable Small World, а также IVF и ScaNN) хранят векторы так, что ближайшие совпадения находятся быстрее чем за 10 миллисекунд даже в библиотеках с десятками миллионов векторов.
Передовой уровень для семантического поиска в продакшене на май 2026 года:
- Индексация HNSW используется чаще всего. В Postgres она есть через расширение
pgvector, а отдельные векторные базы вроде Qdrant, Pinecone и Weaviate используют HNSW или близкие варианты. SavedThat использует HNSW наpgvector, потому что хранить векторы рядом с реляционными метаданными в эксплуатации проще, чем поддерживать две базы. - Хранение с половинной точностью. Если хранить каждое измерение 16-битным числом с плавающей точкой вместо 32-битного, векторы занимают вдвое меньше места на диске. Потеря качества для поиска пренебрежимо мала. Тип
halfvec(768)вpgvectorтеперь выбор по умолчанию для любого развёртывания, где считают расходы. - Укорачивание по MRL (Matryoshka). Эмбеддинги на 1536 измерений обучаются один раз, а при хранении укорачиваются до 768 или 256 измерений в зависимости от задачи. Сначала ищешь по быстрому 256-мерному индексу, а потом пересортировываешь первые 100 результатов по 768- или 1536-мерной версии.
При масштабе SavedThat (на 30 сентября 2026 года во всём поисковом индексе около 230 000 фрагментов транскриптов) индекс помещается в память, и поиск по нему остаётся быстрым.
Подвох: сам по себе семантический поиск ошибается на точных фразах
А теперь главное, о чём молчит большинство руководств: на точных фразах семантический поиск проигрывает поиску по ключевым словам.
Если ищешь "text-embedding-3-small" (точное название продукта), поиск по ключевым словам поставит на первое место документ, где встречается именно эта строка. Семантический поиск может поставить выше документ про «эмбеддинги OpenAI в целом», потому что он по смыслу ближе к общему значению запроса, хотя буквальной строки в нём нет.
Это реальная проблема. Публичные бенчмарки стабильно показывают, что чистый семантический поиск проигрывает поиску по ключевым словам на очень конкретных запросах: названиях продуктов, сигнатурах функций, точных цитатах, датах, брендах. Проблемы, которую должна была решить семантика (несовпадения словаря), в таких запросах просто нет: пользователь и так ввёл ту самую строку, которую ищет.
Решение — запускать оба поиска и объединять результаты.
Гибридный поиск с reciprocal rank fusion
Гибридный поиск — это техника, которая незаметно стала стандартом в серьёзных поисковых системах в продакшене начиная с 2024 года:
- Запусти семантический поиск (по векторной близости). Получи top-K результатов, отсортированных по косинусному сходству.
- Запусти полнотекстовый поиск (по ключевым словам: tsvector, BM25, что угодно). Получи top-K результатов, отсортированных по оценке релевантности.
- Объедини два списка методом reciprocal rank fusion (RRF): оценка RRF для каждого документа равна
1 / (rank + 60), просуммированной по обоим методам. Документы, которые высоко стоят в обоих списках, получают заметную прибавку, а документы, найденные только одним методом, всё равно учитываются. - Отсортируй по итоговой оценке RRF.
Константа 60 — это «магическое число», которое проверяли бенчмарками вдоль и поперёк, и оно работает на большинстве корпусов. Его можно подстраивать, но обычно не нужно.
Результат: перефразированные запросы по-прежнему находят совпадения по смыслу (благодаря семантической части), а запросы с точной фразой по-прежнему ставят буквальное совпадение на первое место (благодаря поиску по ключевым словам). Слепое пятно каждого метода закрывает другой.
Именно такой поиск SavedThat использует по умолчанию. RPC search_chunks в нашем Postgres запускает оба запроса параллельно, считает оценки RRF и возвращает отсортированные результаты. Целиком, вместе с получением эмбеддинга запроса, поиск в сентябре 2026 года занимал в медиане около 1,3 секунды. (Microsoft о гибридном поиске)
Где всё становится сложнее: повторное ранжирование
В задачах с высокой ценой ошибки (поиск доказательств для судебных дел, медицинская литература, корпоративный поиск по миллионам документов) гибридный RRF обычно предпоследний слой. Последний — повторное ранжирование моделью cross-encoder.
Cross-encoder — это модель поменьше и помедленнее, которая принимает весь запрос и весь документ-кандидат и считает точную оценку релевантности, анализируя их вместе. Запускать её на миллионе документов нельзя (слишком медленно), поэтому её применяют к первым 50-200 результатам гибридного поиска, чтобы точно переупорядочить их.
Для этого у Cohere есть rerank-v3. Открытые альтернативы: bge-reranker-large, jina-reranker-v2. При потребительском масштабе вроде SavedThat небольшой выигрыш не оправдывает лишних 100 мс задержки. А в корпоративном поиске для судебных дел повторное ранжирование через cross-encoder теперь стандарт.
Добавим его, когда этого потребуют объём корпуса или задачи. Не раньше.
Сколько это стоит
Весь процесс выглядит примерно так:
| Этап | Стоимость |
|---|---|
| Эмбеддинги для 1000 фрагментов (~50 видео) | ~$0.02 в кредитах OpenAI |
| Хранение 1М фрагментов в pgvector | ~$25/мес на небольшом экземпляре Postgres |
| Построение индекса HNSW для 1М фрагментов | ~30 секунд, разовая операция при крупном изменении данных |
| Один поисковый запрос (эмбеддинг + поиск по HNSW + полнотекстовый поиск + RRF) | ~$0.0001, около 1,3 с целиком |
При ценах SavedThat одна подписка Pro ($9.99/мес) покрывает тысячи запросов и несколько сотен новых сохранений. Для потребительского масштаба экономика сходится. Не сходится она, если пытаться оплачивать всё это бесплатным безлимитным тарифом навсегда: счёт от OpenAI растёт линейно вместе с объёмом контента, а выручка равна нулю.
Почему большинство инструментов для «второго мозга» этого не делают
Три причины:
- Инженерная сложность. Гибридный поиск с RRF требует запустить две поисковые системы и объединить их результаты. Большинство команд выпускают только одну. И обычно это поиск по ключевым словам, потому что он старше и инструменты для него зрелее.
- Стоимость хранения. Эмбеддинг на 1536 измерений × 4 байта на измерение = ~6 КБ на фрагмент. Библиотека из 100 000 фрагментов — это 600 МБ векторов вдобавок к исходному тексту. Без
halfvecи MRL цифры получаются вдвое больше. - Инерция. Большинство существующих приложений для заметок появились до того, как эмбеддинги предложений стали общедоступными. Чтобы добавить семантический поиск в Evernote или Pocket, понадобился бы отдельный проект с векторной базой данных, а компании никогда не ставили его в приоритет.
Инструменты, в которых семантический поиск был с первого дня (Mem, Reflect, премиум-тариф Glasp, SavedThat), в основном появились после 2022 года, потому что именно тогда стоимость эмбеддингов упала ниже порога, при котором потребительский продукт можно устойчиво монетизировать.
Что это значит на практике
Когда оцениваешь в 2026 году инструмент для поиска внутри чего-либо, спрашивай:
- Использует ли он эмбеддинги? Если на схеме архитектуры нет векторного хранилища, ответ «нет».
- Использует ли гибридный поиск? Чистая семантика на многих реальных запросах хуже гибрида. Инструменты с «векторным поиском», но без полнотекстового, делают всё правильно только наполовину.
- Поддерживает ли несколько языков? Это зависит от модели эмбеддингов, а не от поисковой инфраструктуры.
text-embedding-3-smallработает на 100+ языках, старые или более компактные модели нет. - Объясняет ли вообще, как всё устроено? Инструменты, которые рассказывают, как у них работает поиск, обычно делают его хорошо. Инструменты с надписью «AI-powered search ✨» без подробностей обычно делают вариант 2 или 3 из списка выше (LLM поверх ключевых слов или чистые вопросы и ответы).
Для сохранения видео и поиска по ним потом: SavedThat поддерживает все четыре пункта (обзор архитектуры здесь). Glasp предлагает только поиск по ключевым словам (бесплатно) и семантический поиск (платно). Mem — только семантику, без гибрида. «AI-поиск» в Notion — это вариант 2: LLM поверх ключевых слов.
Такова картина на май 2026 года.
Читать дальше
Поиск по сохранённым видео: полное руководство 2026
Поиск по сохранённым видео из YouTube, Instagram и TikTok по тому, что в них сказано. Как устроен поиск по транскриптам и какие четыре инструмента это умеют.
Поиск по транскриптам видео: инструменты 2026
Поиск по транскриптам видео в 2026: какие инструменты ищут по сказанному в сохранённых видео с YouTube, Reels и TikTok, а какие только обещают.
Менеджер видео-закладок с поиском по транскриптам (2026)
Менеджер видео-закладок с поиском по транскриптам в 2026: честное сравнение семи инструментов, от SavedThat и Quiki до Raindrop Pro, Mymind и Glasp.
Частые вопросы (2026)
В чём разница между эмбеддингом и вектором?
Функционально никакой, на практике эти термины взаимозаменяемы. Строго говоря, эмбеддинг — это *представление*, которое выдаёт модель, а вектор — просто список чисел. Любой эмбеддинг является вектором, но не любой вектор является эмбеддингом (столбец значений яркости пикселей — это вектор, но не эмбеддинг). В большинстве статей и технической документации «вектор» используют, когда говорят о хранении, а «эмбеддинг» — когда говорят о смысле.
Работает ли семантический поиск на любом языке?
Зависит от модели эмбеддингов. OpenAI text-embedding-3-small обучали на 100+ языках, и она выдаёт векторы, примерно согласованные между языками: русский запрос и английский документ об одном и том же понятии попадают в похожие области векторного пространства. Небольшие открытые модели на неанглийских языках часто работают заметно хуже. Если нужна поддержка нескольких языков, проверь, что в описании модели явно упомянуто межъязыковое выравнивание (cross-lingual alignment).
Чем гибридный поиск отличается от того, чтобы запустить два поиска и показать оба результата?
Если запустить два поиска и просто склеить результаты, их станет вдвое больше. Гибридный поиск объединяет их по оценке (RRF или взвешенное объединение), так что итоговый порядок отражает согласие обоих методов. Документ на первом месте и в поиске по ключевым словам, и в семантическом окажется первым и в общем списке, а документ на первом месте в поиске по ключевым словам и на пятидесятом в семантическом опустится в середину. Без объединения непонятно, каким результатам верить.
Почему чистый семантический поиск проигрывает поиску по ключевым словам на точных фразах?
Эмбеддинги кодируют смысл, а не буквальные строки. Смысл запроса вроде «text-embedding-3-small» скорее «одна из моделей эмбеддингов OpenAI», чем конкретная последовательность токенов. Вектор запроса похож на векторы документов об эмбеддингах OpenAI вообще, и они могут оказаться выше конкретного документа, где упомянуто точное название продукта. У поиска по ключевым словам с точными строками нет никакой неоднозначности: строка либо есть, либо нет. Гибрид покрывает оба случая.
RAG — это то же самое, что семантический поиск?
Это связанные вещи, но не одно и то же. Семантический поиск — это этап поиска: найти документы, близкие к запросу в векторном пространстве. RAG (Retrieval-Augmented Generation) — это система, которая с помощью семантического поиска находит документы, а потом передаёт их генеративной LLM, и та пишет ответ, опираясь на эти документы как на контекст. RAG включает семантический поиск как один из компонентов, а семантический поиск может существовать и без RAG (когда нужно просто найти документы, а не генерировать на их основе текст).
Нужен ли GPU, чтобы запускать семантический поиск?
Для самого поиска по уже построенному индексу нет. На потребительском масштабе с поиском справляется CPU. Для построения индекса, то есть запуска модели эмбеддингов на твоём контенте, GPU ускоряет работу, но не обязателен. API OpenAI считает эмбеддинги в своём дата-центре и возвращает тебе вектор для хранения, а на твоей стороне остаются только векторная база и эмбеддинг запроса (один короткий вызов API на запрос). Стоит это копейки за тысячу поисков.