Поиск и обнаружение контента в стриминге

TL;DR

Строка поиска на стриминговом сервисе выполняет две разные работы – помогает найти тайтл, который зритель уже знает по названию, и помогает зрителю, который знает лишь, чего ему хочется, – и система, настроенная под одну, проваливает другую. Классический поиск по словам сопоставляет введённые слова со словами в вашем каталоге через инвертированный индекс и функцию ранжирования BM25, а пригодным к жизни его делают терпимость к опечаткам (чтобы «strm» всё равно нашёл «Storm») и autocomplete (чтобы печатать почти не пришлось); более новый семантический поиск сопоставляет смысл через числовые отпечатки – embeddings, – поэтому «добрая комедия про офис» находит нужный сериал, даже если этих слов нет ни в одном описании. Сильнейший стриминговый поиск в 2026 – гибридный: он запускает оба, сливает два ранжированных списка и ре-ранжирует верх – и относится к поиску, который ничего не нашёл, не как к тупику, а как к передаче рекомендациям. Ошибётесь – и зрители, пришедшие в приложение намеренно, уходят ни с чем; сделаете правильно – и поиск становится самым быстрым путём от интента к воспроизведению.

Почему это важно

Поиск – единственная поверхность discovery, которую зритель выбирает сам. Рекомендации и ряды главного экрана действуют на людей пассивно – и, как доказывает открывающая статья блока, именно discovery определяет удержание, – но когда кто-то открывает строку поиска, у него есть конкретный интент, и провалить его здесь – самый дорогой промах во всём продукте, потому что человек хотел что-то посмотреть, а вы не связали его с этим. Эта статья – для основателя, продакт-менеджера или стримингового CTO, которому нужно решить, сколько технологий поиска строить, когда хватает совпадения по словам, когда семантический поиск окупает свою цену и как поиск и рекомендации должны передавать запрос друг другу. Вы не будете писать функцию ранжирования руками, но вам нужно задать поведение, выбрать между «строить» и «купить» и понимать, почему строка, которая делает только точное совпадение, тихо теряет зрителей каждый день. Поиск стоит прямо ниже по течению от пайплайна метаданных из прошлой статьи – он находит лишь то, что описывают ваши метаданные, – поэтому две темы суть половины одной истории про discovery.

Две работы одной строки поиска

Начнём с различия, которое определяет всё остальное, потому что большинство команд строят под одну работу и забывают про другую. Когда зритель пользуется поиском, он делает одно из двух принципиально разных дел.

Первое – known-item поиск: зритель уже точно знает, чего хочет, и использует поиск как короткий путь к этому. Он печатает «Inception», потому что хочет именно Inception. Здесь работа – это скорость и снисходительность: довести до нужного тайтла за минимум нажатий и не наказывать за опечатку. Это простая работа, и её хотя бы пытается делать любая строка поиска.

Второе – exploratory поиск: у зрителя нет конкретного тайтла на уме; у него есть интент, настроение или расплывчатое описание, и он использует поиск, чтобы обнаружить что-то подходящее. Он печатает «добрая комедия про офис» или «фильмы как Inception», потому что хочет тип вещи, а не известную вещь. Это сложная работа, та, что пересекается с рекомендациями, и та, что отличает строку поиска от движка discovery. Различие между поиском известного и исследованием, чтобы понять, чего ты хочешь, – давнее в информационном поиске (Marchionini, 2006).

Эта рамка важна потому, что две работы нагружают разную машинерию. Known-item поиск вознаграждает точное и почти точное совпадение – зритель ввёл название, так сопоставь название. Exploratory поиск вознаграждает совпадение по смыслу – зритель описал ощущение, и ни один тайтл в каталоге буквально не содержит слов «добрая комедия». Система, построенная только под первую работу, прекрасно отвечает на «Inception» и встречает «что-нибудь жизнеутверждающее на дождливое воскресенье» пустым экраном. Держите обе работы в голове, пока мы идём по технологии, потому что весь аргумент за современный поиск в том, что обе нужно обслуживать из одной строки.

Нажмите, чтобы увеличить

Как на самом деле работает поиск по словам: инвертированный индекс и BM25

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

Базовая структура данных – инвертированный индекс, и простейшая аналогия – указатель в конце учебника. Вместо «тайтл A содержит такие-то слова, тайтл B содержит такие-то» движок переворачивает это и хранит для каждого слова список тайтлов, которые его содержат: «слово ограбление встречается в тайтлах 12, 88 и 405». Когда зритель печатает ограбление, движок не читает каждый тайтл каталога; он прыгает прямо к записи ограбление и достаёт короткий список тайтлов, заведомо его содержащих. Именно это делает поиск мгновенным даже по каталогу в сотни тысяч тайтлов: работа сделана заранее, при индексировании каталога, а не в момент запроса.

Найти совпавшие тайтлы – лишь половина дела. Вторая половина – ранжировать их, решить, какое совпадение идёт наверх, – и функция, делавшая это в большинстве боевых систем поиска целое десятилетие, называется BM25 («BM» – от Best Matching, «лучшее совпадение»). BM25 выросла из десятилетий академических исследований информационного поиска и полностью описана её авторами (Robertson & Zaragoza, 2009). Формула вам не нужна, но три её идеи стоит понять, потому что они объясняют поведение поиска, которое вы видите ежедневно.

Первое: редкие слова весят больше. Если зритель ищет «the matrix», слово the встречается почти в каждом тайтле и почти ничего не говорит, а matrix редкое и очень информативное. BM25 автоматически понижает вес частых слов и повышает вес редких – это идея «обратной частоты документа» (inverse document frequency), наблюдение, что ценность слова обратна числу документов, в которых оно есть. Второе: повторение даёт убывающую отдачу. Тайтл, чьё описание упоминает ограбление пять раз, релевантнее того, что упоминает его раз, но не в пять раз; BM25 даёт оценке насытиться. Третье: длина нормируется, так что длинный синопсис не обходит короткий просто за счёт большего числа слов. Под два последних поведения BM25 даёт две ручки настройки – по соглашению k1 и b – а обычные значения по умолчанию (k1 около 1,2–2,0 и b = 0,75) и поставляются в распространённых движках поиска (Robertson & Zaragoza, 2009).

Для покупателя это важно потому, что BM25 не экзотика и не дорого – это встроенный дефолт в open-source движках поиска, которые у большинства команд уже есть: Apache Lucene и построенные на нём Elasticsearch и OpenSearch переключили ранжирование по умолчанию на BM25 около 2016 года. Иначе говоря, грамотный поиск по словам с хорошим ранжированием почти бесплатен; инженерные усилия уходят на всё вокруг него, и об этом – следующие разделы.

Терпимость к опечаткам: почему «strm» обязан найти «Storm»

У точного совпадения по словам есть неумолимый изъян: люди опечатываются, особенно на устройствах, где работают стриминги. Зритель, тыкающий в клавиатуру телефона или клюющий буквы пультом, промахнётся, а строка, которая совпадает только с идеальным написанием, вернёт пусто на «strm», хотя очевидно имелось в виду «Storm». Лекарство – терпимость к опечаткам: совпадение со словами, близкими по написанию, а не только идентичными.

Мера «близости» – edit distance (расстояние редактирования): число однобуквенных изменений, нужных, чтобы превратить одно слово в другое. Классический вариант, расстояние Левенштейна, считает три вида правки – вставку буквы, удаление буквы и замену одной буквы другой (Левенштейн, 1966). Так «strm» → «storm» – одна правка (вставить o), расстояние 1. Уточнение под названием расстояние Дамерау-Левенштейна добавляет четвёртую операцию, транспозицию – перестановку двух соседних букв, – потому что самая частая ошибка набора именно она: «teh» вместо «the», «micheal» вместо «michael» (Damerau, 1964). Считать транспозицию одной правкой, а не двумя – вот почему этот вариант стал стандартом проверки орфографии, и именно это расстояние использует ведущий хостируемый сервис поиска, по умолчанию допуская до двух опечаток в слове (Algolia, 2026).

Практическая отдача велика, а цена мала: терпимость к опечаткам – встроенная функция любого серьёзного движка и хостируемого сервиса поиска, а не то, что строят с нуля. Продуктовое решение – насколько терпимым быть. Слишком строго – теряете промахнувшегося зрителя; слишком вольно – «star» начинает совпадать с «scar», «stir» и «tsar», хороня нужный тайтл. Большинство платформ привязывают терпимость к длине слова – больше правок на длинных, меньше на коротких – и ставят точные совпадения выше близких, чтобы идеальное написание всегда побеждало.

Вторая половина проблемы набора – заставить зрителя печатать меньше, через autocomplete – поиск-по-мере-ввода, где подсказки появляются после первых символов. Зритель, печатающий «inc», видит Inception до конца слова и выбирает его. Autocomplete не роскошь; на телевизоре, где каждый символ – медленное путешествие по экранной клавиатуре, это разница между пригодным поиском и брошенным – об этом отдельный раздел ниже.

Стена, в которую упирается поиск по словам: он сопоставляет слова, не смысл

Поиск по словам, как бы хорошо ни был настроен и терпим к опечаткам, упирается в потолок, который сам пробить не может: он сопоставляет слова, не смысл. BM25 – это, в техническом выражении, «мешок слов» (bag of words): он смотрит, какие слова запроса встречаются в каких тайтлах и как часто, и ничего – на то, что эти слова значат (Robertson & Zaragoza, 2009). Это идеально для known-item работы и проваливает exploratory.

Сделаем провал конкретным. Зритель печатает «добрая комедия про офис». Ни один тайтл в каталоге не содержит буквальной фразы «добрая» в синопсисе. Поиск по словам послушно ищет слова добрая, комедия, про, офис, находит разрозненные частичные совпадения и ставит документалку о технике безопасности на заводе выше ситкома про офисный коллектив, который зритель и хотел, – потому что в документалке случайно были про и офис. Интент зрителя был ясен любому человеку; он был невидим для системы, которая лишь считает слова. Та же стена блокирует «фильмы как Inception» (ни один тайтл не содержит слова «Inception», кроме самого Inception), «тот сериал с драконами» и любой запрос по настроению, теме или вайбу, который печатает реальный зритель.

Это и есть разрыв, который семантический поиск был создан закрыть, и это самое важное обновление стримингового discovery за последние годы. Чтобы перейти стену, нужен поиск, понимающий, что добрый и тёплый – соседи, что комедия про офис и офисный ситком – одна идея, а зритель, которому понравился Inception, тянется к заумному и выносящему мозг, а не к буквальной строке «Inception».

Семантический поиск: совпадение по смыслу через embeddings

Технология, сопоставляющая смысл, а не слова, – семантический поиск, и держится она на одной мощной идее под названием embedding. Embedding – это список чисел, координата, представляющая смысл куска текста или видео как точку в пространстве. Фокус в том, что вещи с похожим смыслом оказываются рядом. «Добрый», «тёплый», «жизнеутверждающий» приземляются недалеко друг от друга; «комедия про офис» и «офисный ситком» – рядом; жёсткий криминальный триллер – далеко от всех них. Смысл становится геометрией, а «найди мне похожее» – «найди мне ближайшие точки».

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

Как строится карта – как модель превращает текст или видео в эти координаты-смыслы – это работа машинного обучения, относящаяся к другому разделу; внутренности модели, embedding-модели и их обучение разобраны в разделе AI for Video Engineering про векторный поиск и embeddings, а здесь мы остаёмся на продуктовом слое. Стриминговой команде нужно знать поведение: embeddings позволяют поиску и рекомендациям работать со смыслом, а это ровно то топливо, которое нужно exploratory-работе.

Есть одна инженерная реальность, которую стоит унести, потому что она диктует стоимость. Находить ближайшие точки на карте из сотен тысяч тайтлов для каждого запроса, измеряя расстояние до каждой точки, – слишком медленно вживую. Поэтому семантический поиск использует approximate nearest neighbor – приближённый поиск ближайших соседей, ANN, – который находит почти ближайшие точки гораздо быстрее, готовый изредка промахнуться мимо истинно ближайшей. Доминирующий метод, графовая структура под названием HNSW (Hierarchical Navigable Small World), строит слоистую карту, дающую запросу быстро прыгнуть в нужный район вместо проверки каждого тайтла, разменивая щепотку точности на примерно логарифмическую скорость поиска (Malkov & Yashunin, 2018). Вывод для покупателя: семантический поиск не бесплатен, как BM25, – ему нужны embeddings, посчитанные для каждого тайтла, и специализированный индекс, чтобы их обслуживать, – но стоимость хорошо понятна, а строительные блоки зрелы.

Нажмите, чтобы увеличить

Гибридный поиск: запусти оба, потом слей

Если поиск по словам решает known-item, а семантический – exploratory, очевидный ход – запустить оба и объединить. Это гибридный поиск, и это лучшая практика 2026 для любого каталога, который серьёзно относится к discovery.

Зачем нужны оба, а не только новый, – потому что каждый проваливается там, где другой успешен. Поиск по словам непобедим на точных совпадениях: зритель, печатающий точное название, точное имя актёра или редкое имя собственное, хочет именно буквальное совпадение, и BM25 его даёт. Семантический поиск непобедим на смысле – перефразы, настроения, «что-то как X» – но может недооценить точное совпадение редкого термина, иногда ставя тематически похожий тайтл выше точного, который ввёл зритель. Запустите только поиск по словам – провалите каждый запрос по настроению; только семантический – иногда промахнётесь мимо точного названия. Hybrid запускает их параллельно и берёт оба верно.

Загвоздка – в объединении двух списков, потому что они оценивают по несовместимым шкалам: BM25 даёт одно число, vector-похожесть – другое, и просто сложить нельзя. Стандартное решение элегантно: игнорировать сырые оценки и объединять по рангу. Метод под названием Reciprocal Rank Fusion (RRF) делает ровно это – тайтл, высоко стоящий в любом из списков или умеренно высоко в обоих, всплывает наверх объединённого, без жонглирования шкалами (Cormack, Clarke & Büttcher, 2009). RRF – то, что крупные платформы поиска используют под капотом для гибридного поиска.

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

Таблица 1. Какой подход побеждает для какого типа запроса. Поиск по словам владеет точными названиями, именами и совпадением с опечатками; семантический владеет настроением, перефразами и «что-то как X»; hybrid запускает оба и сливает результаты, обслуживая known-item и exploratory работы из одной строки. Колонка «лучше для?» – hybrid в каждой строке, и это аргумент за него.

Проблема телевизора: когда набор – враг

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

ТВ-интерфейс – то, что дизайнеры зовут 10-футовым UI: зритель сидит примерно в десяти футах и управляет направленным пультом, а не клавиатурой или тачскрином (термин и его ограничения – стандарт в гайдах по дизайну платформ, напр. Amazon Fire TV). Ввод текста означает навигацию по экранной клавиатуре по букве – вправо, вправо, вправо, вниз, выбор – ради одного символа, что медленно и раздражает достаточно, чтобы длинные запросы просто не набирались. Зритель, который с удовольствием набрал бы «добрая комедия про офис» на телефоне, наберёт «ком» на пульте, сдастся и пойдёт листать. Цена плохого ввода текста платится брошенными поисками.

Два дизайнерских ответа следуют прямо отсюда. Первый – агрессивный autocomplete: показывайте вероятные тайтлы после одного-двух символов, чтобы зритель перестал печатать и выбрал. На ТВ autocomplete – не приятная мелочь, а основной способ ввода. Второй – голосовой поиск: дайте зрителю произнести запрос в пульт или в подключённого ассистента вместо набора, что гайды по дизайну платформ считают предпочтительной заменой экранному вводу (Amazon Fire TV; Android TV). Голос переворачивает слабость телевизора в силу – произнести «добрая комедия про офис» легко, а значит, голосовой поиск непропорционально рождает длинные, естественные, exploratory-запросы, на которые семантический поиск и создан отвечать. Две технологии усиливают друг друга: голос делает зрителей готовыми выразить настоящий интент, а семантический поиск превращает этот интент в нужные тайтлы. Платформа, выпустившая голосовой поиск поверх keyword-only бэкенда, ловит богатые запросы и затем не может на них ответить.

Нажмите, чтобы увеличить

Когда поиск ничего не нашёл: передача рекомендациям

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

Зрелый discovery относится к нулевому результату не как к тупику, а как к передаче рекомендациям. Если точный запрос провалился, система откатывается: предлагает ближайшие семантические совпадения («такого нет, но вот похожее»), смежные жанры или персональные ряды зрителя, чтобы путь продолжился, а не оборвался. Это шов, где встречаются поиск и рекомендации, – и он работает в обе стороны. Успешный поиск – сильный сигнал интента, который может питать дата-пайплайн персонализации («этот зритель только что искал фильмы про ограбление»), а неудачный – сигнал рекомендателю вступить. Поиск берёт known-item работу, рекомендации берут открытую, и передача между ними делает весь слой discovery как будто без краёв.

Стоит держать масштаб двух поверхностей в перспективе. На большом каталоге гораздо больше просмотров рождают рекомендации, чем поиск, – Netflix сообщал, что его система рекомендаций влияет примерно на 80% просмотренных часов (Gomez-Uribe & Hunt, 2015). Поиск – меньший канал по объёму, но самый интентный: зритель, который ищет, прямо говорит вам, чего хочет. Потерять его на пустом экране – более дорогой провал, чем посредственный ряд рекомендаций, потому что интент был явным, а вы всё равно промахнулись.

Нажмите, чтобы увеличить

Discovery за пределами вашего приложения: поисковики и ассистенты

Большая доля «поиска» ваших тайтлов вообще не касается вашей строки поиска. Кто-то вводит название фильма в Google или спрашивает ИИ-ассистента «где посмотреть тот сериал с драконами» – и появляется результат, в идеале указывающий на вашу платформу. Это discovery вне платформы, и работает оно на тех же метаданных, выставленных в машиночитаемой форме.

Механизм – структурированные данные: словарь Schema.org, встроенный в ваши веб-страницы, чтобы поисковик читал ваш каталог, не угадывая. Разметка страницы просмотра типом VideoObject (как минимум имя, миниатюра и дата загрузки плюс ссылка на контент) даёт ей право на video rich results в поиске Google (Google Search Central, 2026; Schema.org, 2026). Смежная разметка SearchAction внутри типа WebSite исторически давала строку поиска прямо в результатах Google; Google убрал эту конкретную функцию в конце 2024-го, но разметка сохраняет ценность по мере того, как поисковики и ИИ-ассистенты всё чаще действуют как агенты над структурированными данными каталога (Google Search Central, 2026). Связь с этой статьёй прямая: те же descriptive-метаданные, что питают ваш внутренний семантический поиск, – сырьё, которое внешний движок читает, чтобы прислать вам интентного искателя. Постройте поиск хорошо внутри – и большая часть нужного для discovery вне платформы уже у вас в руках, что и есть аргумент «метаданные как общее топливо» из статьи про метаданные.

Разобранный пример: скрытая цена пустого экрана поиска

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

Допустим, строка делает только точное совпадение по словам – без терпимости к опечаткам, без семантики. Кусают два режима отказа. Первый – опечатки: на сенсорных и пультовых клавиатурах заметная доля запросов несёт хотя бы одну ошибку набора; примем консервативные 8%, то есть 500 000 × 0,08 = 40 000 поисков в месяц проваливаются чисто потому, что «strm» не совпал со «Storm». Второй – запросы по интенту: примем, что 15% поисков основаны на настроении или похожести («добрая комедия», «фильмы как…»), что поиск по словам обслужить не может, – 500 000 × 0,15 = 75 000 новых проваленных поисков. Игнорируя пересечение для грубой цифры, получаем порядка 115 000 нулевых поисков в месяц, zero-result rate (доля поисков, вернувших пусто) около 23%. Почти каждый четвёртый поиск – пустой экран.

Теперь привяжем поведение к этому пустому экрану. Если хотя бы 40% этих нулевых поисков завершают сессию – правдоподобный abandonment rate (доля отказов), ведь у зрителя, который искал и не нашёл, мало причин остаться, – это 115 000 × 0,40 = 46 000 сессий в месяц, начавшихся с явного интента и закончившихся ничем. Лекарство стоит куда меньше потери: терпимость к опечаткам – встроенная функция, семантический поиск – известное и зрелое дополнение, а передача нуля рекомендациям – продуктовая обвязка, не исследование. Арифметика и есть причина, почему качество поиска – рычаг удержания, а не пункт полировки: каждый пункт, сбитый с zero-result rate, – интентные зрители, которых вы удержали.

Частая ошибка: выпустить поиск с точным совпадением и счесть готовым

Самая частая ошибка поиска в стриминге – самая дешёвая в совершении и самая тихая в провале: выпустить строку, которая делает точное совпадение по словам, увидеть, как она верно отвечает «Inception» на демо, и счесть готовой. Кажется, что работает, потому что демонстрирующий печатает названия, которые умеет писать. Реальные зрители опечатываются, ищут по настроению и описывают, а не называют, – и строка тихо возвращает пустые экраны четверти из них. Лекарство – относиться к терпимости к опечаткам и передаче нуля как к требованиям запуска, а не к улучшениям.

Вторая, противоположная ошибка – пере-исправиться в semantic-only поиск, полагая, что новая технология заменяет старую. Не заменяет. Vector-only поиск может промахнуться мимо точного названия или редкого имени собственного, ставя «тематически похожий» тайтл выше точного, который ввёл зритель, – known-item работа деградирует. Правильная форма – hybrid: слова для точного, semantic для смысла, слитые.

Третья ошибка специфична для телевизора: строить богатый голосовой или естественно-языковой ввод поверх keyword-only бэкенда. Голос приглашает зрителей произносить длинные exploratory-запросы – «что-нибудь смешное и короткое на вечер», – а keyword-бэкенд ответить не может, так что платформа собирает ровно те запросы, которые меньше всего способна обслужить. Выпускаете голос – выпускайте и семантический поиск, который делает голос стоящим. У каждой ошибки один корень: к поиску относятся как к галочке, а не как к самой интентной поверхности discovery, которой вы владеете.

Где здесь Фора Софт

Стриминговый поиск – это проблема масштаба раньше, чем функция: каталог в десятки или сотни тысяч тайтлов, запрашиваемый с телефона, веба и управляемого пультом телевизора, с ожиданием отклика меньше секунды на каждом. За 250+ выпущенных проектов для 400+ клиентов с 2005 года в видеостриминге, OTT/Internet TV, e-learning и видеонаблюдении мы раз за разом строим полный стек поиска – слой по словам с терпимостью к опечаткам для known-item, семантический/vector-слой для интента и настроения, слияние и ре-ранжирование, что их объединяют, голос и autocomplete под 10-футовый интерфейс и передачу нуля, которая превращает проваленный поиск в рекомендацию, а не в тупик. Наш подход scalability-first и vendor-neutral: мы стартуем от размера каталога, объёма запросов и набора устройств, решаем, где хватит хостируемого сервиса поиска, а где окупится свой гибридный индекс, и вшиваем поиск в те же метаданные и системы рекомендаций, чтобы discovery вёл себя как один продукт на каждом экране.

Ключевые выводы

• Строка поиска делает две работы: найти известный тайтл и исследовать ради типа вещи.
• Поиск по словам (инвертированный индекс + BM25) берёт точные названия; опечатки и autocomplete делают его пригодным.
• Поиск по словам сопоставляет слова, не смысл – он проваливает запросы по настроению и «что-то как X».
• Семантический поиск сопоставляет смысл через embeddings и ANN-индексы (HNSW).
• Hybrid запускает оба и сливает списки (RRF), затем ре-ранжирует – лучшая практика 2026.
• На ТВ набор – враг: опирайтесь на голос и autocomplete и никогда не делайте ноль тупиком.

Что читать дальше

• Метаданные: топливо для discovery
• Рекомендательные системы для видео
• Персонализированный мерчандайзинг: ряды, обложки, порядок