Вектор смысла: новый квадрант. Навигация в пространстве векторного поиска

Есть задачи, которые легко сформулировать и трудно решить. «Найти похожее» – одна из них. Мы делаем это постоянно: ищем товар, напоминающий тот, что понравился; документ, связанный с текущим; песню, похожую на любимую. Мозг справляется мгновенно. Компьютер – нет.

Почему? Потому что мозг сравнивает значения, а компьютер видит только данные. Байты. Пиксели. Символы. Между «данными» и «смыслом» – пропасть. Эта глава – о том, как выглядит эта пропасть и почему её нельзя перепрыгнуть наивными методами.

1.1. Миллион фотографий

Представьте: вы строите интернет-магазин. Каталог – миллион товаров. У каждого товара – фотография, название, описание, характеристики. Классический поиск работает: пользователь вводит «красные кроссовки Nike», система находит товары, где в названии или описании есть эти слова. Всё понятно, всё работает. Технология отлажена десятилетиями, инструменты зрелые, задача решена.

А теперь пользователь загружает фотографию. Кроссовки, которые он увидел на улице. Или в соцсети. Или на ком-то в метро. Он не знает бренд, не знает модель, не может описать словами – у него есть только картинка и желание «хочу такие же». Или хотя бы похожие. Что делать?

Можно, конечно, попросить пользователя описать товар текстом. Но попробуйте сами: опишите словами конкретную пару обуви так, чтобы поисковая система нашла именно её среди миллиона других. «Белые кроссовки с синей полосой и толстой подошвой» – сколько результатов вернёт такой запрос? Сотни. Тысячи. И нужный товар может оказаться на двадцатой странице, потому что в его описании написано «спортивная обувь ivory с декоративным элементом navy». Та же пара, другие слова.

Это не экзотический сценарий. Google Lens, Pinterest, Taobao, ASOS – все они решают эту задачу. Загрузи картинку, получи похожие. Для пользователя это выглядит как магия: навёл камеру, нажал кнопку, получил результат. Для инженера – как проблема, у которой нет очевидного решения. Проблема, над которой бились десятилетиями и решили только в последние годы.

Потому что как сравнить две фотографии? Что значит «похожи»?

Одинаковые пиксели? Нет, конечно – тот же товар под другим углом будет иметь совершенно другие пиксели. Сдвиньте камеру на сантиметр, измените освещение, положите товар на другой фон – и попиксельно это будет совершенно другое изображение. Ноль совпадений. При этом для человека – очевидно тот же предмет.

Одинаковые цвета? Ближе, но красная куртка и красный автомобиль – это не «похожие товары». Красный закат и красный перец – тем более.

Одинаковая форма? Уже теплее, но как формализовать «форму»? Как объяснить компьютеру, что кроссовки – это кроссовки, независимо от того, сфотографированы они сбоку, сверху или под углом?

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

И фотографии – только начало. Та же проблема возникает везде, где нужно искать по смыслу, а не по точному совпадению. Везде, где пользователь знает что хочет, но не может это точно описать. Везде, где «похожее» важнее «точно такого же».

Возьмём документы. Юридическая фирма, архив на сотни тысяч договоров, накопленных за двадцать лет работы. Приходит новый контракт, нужно найти прецеденты – похожие договоры с похожими условиями, чтобы понять типичные формулировки, возможные риски, исторические решения. Поиск по ключевым словам? «Договор аренды» найдёт тысячи результатов, большинство нерелевантных. «Договор аренды нежилого помещения в Москве сроком на 5 лет с правом субаренды» – слишком специфично, можно пропустить релевантные документы, где формулировки чуть другие. «Помещение» в одном договоре, «площадь» в другом, «объект» в третьем – смысл тот же, слова разные. А ведь юристу нужны именно смысловые аналоги, не текстовые совпадения.

Возьмём службу поддержки. База знаний – десятки тысяч статей, инструкций, решений типичных проблем. Годы накопленного опыта, ответы на все возможные вопросы. Клиент пишет: «Приложение вылетает после обновления». Где искать ответ? По слову «вылетает»? Статья может называться «Проблемы совместимости версии 3.2 с iOS 17» – ни одного общего слова с запросом, но это именно то, что нужно. Или клиент напишет «приложение крашится», или «программа закрывается сама», или «не работает после апдейта» – всё это один и тот же вопрос, но для поиска по ключевым словам это четыре разных запроса с разными результатами.

Или рекомендации. Пользователь посмотрел фильм, понравилось. Что предложить дальше? Тот же жанр? Слишком грубо – «комедия» объединяет и лёгкие романтические истории, и чёрный юмор, и абсурдистские эксперименты. Фильм Уэса Андерсона и фильм Адама Сэндлера – оба комедии, но аудитории почти не пересекаются. Того же режиссёра? Может сработать, но ограничивает выбор и не всегда релевантно – режиссёр мог снять очень разные фильмы в разные периоды. С теми же актёрами? Ещё менее надёжно. Что-то с «похожим настроением», с похожей атмосферой, с похожим послевкусием? Отлично, только как измерить настроение? Как объяснить алгоритму, что «Амели» и «Королевство полной луны» – это похожий зрительский опыт, хотя один фильм французский, другой американский, разные жанры, разные годы, разные актёры?

Та же история с музыкой. Spotify и Apple Music каждый день решают эту задачу для сотен миллионов пользователей. Человек слушает песню и хочет «ещё что-нибудь такое». Тот же исполнитель – очевидно, но быстро закончится. Тот же жанр – слишком размыто, «рок» включает в себя тысячи непохожих направлений. Похожий темп, похожие инструменты, похожее настроение – всё это нужно как-то измерить и сравнить.

В науке – аналогично. Исследователь нашёл статью по своей теме и хочет найти связанные работы. Поиск по ключевым словам из заголовка? Пропустит статьи, где та же идея описана другими терминами. Поиск по авторам? Слишком узко. Поиск по цитированию? Ближе, но не учитывает недавние публикации, которые ещё не успели накопить цитаты. Нужен поиск по смыслу – «найди статьи, которые исследуют похожую проблему похожими методами».

Везде одна и та же структура: есть объект, есть коллекция, нужно найти в коллекции что-то «близкое» к объекту. Товар среди миллиона товаров. Документ среди сотен тысяч документов. Песня среди десятков миллионов треков. Статья среди бесконечного потока научных публикаций.

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

Форма – это то, что видит компьютер. Смысл – это то, что видит человек. Между ними – пропасть.

Человек справляется с этим легко. Мы смотрим на две фотографии и мгновенно понимаем: это похожие товары или разные. Мы читаем два документа и чувствуем: об одном они или о разном. Мы слушаем две песни и знаем: это похожая музыка или совершенно разная. Мы не можем объяснить алгоритм – мы не знаем, как именно наш мозг это делает, – но результат выдаём надёжно и быстро.

Компьютер так не может. Компьютер видит массив чисел – яркости пикселей, коды символов, частоты звуковых колебаний. Для него фотография – это таблица из миллионов ячеек, в каждой – три числа от 0 до 255, красный, зелёный, синий. Текст – последовательность кодов Unicode. Музыка – график колебаний давления воздуха. Никакого «смысла», никакого «значения», никакого «похоже на». Только числа.

И вот тут возникает вопрос, который определяет всю дальнейшую историю: можно ли научить машину сравнивать смыслы? Можно ли превратить «это про одно и то же» в вычислимую величину?

Почему очевидные методы не работают – об этом дальше.

1.2. Почему это сложно

Первый рефлекс программиста – попробовать очевидное. Нужно сравнить две картинки? Сравним пиксели. Нужно сравнить два текста? Посчитаем общие слова. Нужно найти дубликаты? Вычислим хэш. Эти методы интуитивно понятны, легко реализуемы, хорошо изучены. Они работают – для других задач. Для поиска по смыслу они бесполезны. И понять почему – значит понять саму природу проблемы.

Начнём с изображений и попиксельного сравнения.

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

На практике это не работает почти никогда.

Возьмите одну и ту же чашку кофе. Сфотографируйте её дважды – один раз чуть левее, другой раз чуть правее. Сдвиг на пять сантиметров. Для человека это очевидно одна и та же чашка, тот же кофе, та же сцена. Для попиксельного сравнения – два совершенно разных изображения. Каждый пиксель сдвинулся, каждый пиксель изменился. Там, где был край чашки, теперь фон. Там, где был фон, теперь чашка. Совпадений почти нет. Алгоритм скажет: это разные картинки, похожесть близка к нулю.

Теперь сфотографируйте ту же чашку при другом освещении. Утром и вечером. При лампе и при свече. Та же чашка, тот же ракурс, та же композиция – но цвета другие. Тени другие. Блики другие. Каждый пиксель изменил свои RGB-значения. Для алгоритма – снова разные картинки.

А теперь сфотографируйте две разные белые чашки на одинаковом белом фоне при одинаковом освещении. Пиксели будут очень похожи – много белого там и тут. Алгоритм скажет: почти одинаковые изображения. Хотя это совершенно разные предметы.

Попиксельное сравнение измеряет не то. Оно отвечает на вопрос «насколько совпадают числа в массивах», а не на вопрос «насколько похоже то, что изображено». Это разные вопросы с разными ответами.

Есть чуть более умные методы. Можно искать не точное совпадение пикселей, а похожие структуры. Можно сравнивать гистограммы цветов – сколько красного, сколько синего, сколько зелёного на картинке в целом. Не попиксельно, а статистически. Можно искать характерные точки – углы, края, контрастные переходы – и сравнивать их расположение. Такие алгоритмы десятилетиями использовались в компьютерном зрении. Они лучше справляются со сдвигами и поворотами. Могут найти тот же объект под другим углом, если угол не слишком отличается.

Но они всё равно сравнивают визуальные свойства, а не смысл. Красное яблоко и красный мяч будут «похожи» по цвету и даже по форме. Фотография кошки анфас и фотография той же кошки в профиль будут «разными» по характерным точкам – точки-то в других местах. А главное – эти методы не понимают, что на картинке. Они видят пиксели, статистику, закономерности. Не видят объекты, не видят сцены, не видят смысл.

Форма – не смысл. Пиксели – не значение. Этот путь никуда не ведёт.

Теперь текст. Кажется, с текстом проще – слова же несут смысл напрямую, в отличие от пикселей. Посчитаем общие слова, и дело в шляпе.

Метод называется «мешок слов» – bag of words. Берём текст, разбиваем на слова, считаем, сколько раз встречается каждое слово. Получаем что-то вроде рецепта: этот документ содержит три слова «договор», два слова «аренда», одно слово «помещение». Другой документ содержит пять слов «договор», одно слово «аренда», три слова «собственность». Сравниваем эти «рецепты» – чем больше совпадений, тем документы «ближе».

Проблема первая: синонимы – разные слова с одинаковым значением. «Автомобиль» и «машина» – одно и то же, но для мешка слов это разные слова. Документ про «автомобили» и документ про «машины» не найдут друг друга, хотя они об одном. «Быстрый», «скорый», «стремительный» – три разных слова, один смысл. «Врач», «доктор», «медик» – то же самое. Язык избыточен, у каждого понятия десятки способов выражения. Мешок слов этого не видит.

Вернёмся к интернет-магазину. Покупатель ищет «красное платье». В каталоге есть «алый сарафан» – именно то, что нужно, идеальное попадание. Но слова не совпадают. «Красное» – не «алый». «Платье» – не «сарафан». Для поиска по ключевым словам это промах. Товар не найден. Покупатель уходит, продажа не состоялась. А ведь достаточно было понять, что «алый» – это оттенок красного, а «сарафан» – это разновидность платья.

Проблема вторая: омонимы – одинаковые слова с разными значениями. «Банк» – это финансовое учреждение или берег реки? «Ключ» – это инструмент, источник воды или разгадка шифра? «Мир» – это планета, отсутствие войны или сообщество людей? «Лук» – овощ или оружие? Одно слово, разные значения. Мешок слов считает слово «банк» и не знает, какой банк имеется в виду. Для него это просто последовательность символов, б-а-н-к, без контекста, без значения. Документ о рыбалке на берегу реки окажется «похож» на документ о финансовых операциях, потому что в обоих есть слово «банк». Документ про стрельбу из лука – на кулинарный рецепт с луком.

Проблема третья: порядок слов. «Собака укусила человека» и «человек укусил собаку» – совершенно разные события, но одинаковые мешки слов. Те же слова, та же частота. Для алгоритма – идентичные документы. Мешок слов теряет структуру, теряет связи между словами, теряет грамматику. Остаётся только набор ингредиентов без рецепта.

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

Можно пойти дальше – использовать n-граммы, последовательности из нескольких слов подряд. «Банк реки» и «банк денег» станут разными n-граммами, и омонимы частично разрешатся. Но n-грамм комбинаторно много – каждая пара слов, каждая тройка, каждая четвёрка. Данные становятся разреженными, большинство n-грамм встречаются по одному разу, сравнивать становится сложно. И проблема синонимов всё равно остаётся – «берег реки» и «речной берег» будут разными n-граммами.

Текст – не просто набор слов. Слова – не просто символы. За словами стоит значение, и это значение нельзя вычислить простым подсчётом.

Остаются хэши. Хэш-функция берёт любые данные и превращает их в короткую строку фиксированной длины – «отпечаток пальца» данных. Одинаковые данные дают одинаковый хэш. Разные данные – с очень высокой вероятностью – разные хэши. Сравнить два хэша мгновенно: совпали или нет.

Хэши идеальны для поиска дубликатов. Точных дубликатов. Если нужно найти, есть ли в базе точно такой же файл – хэш справится. Быстро, надёжно, эффективно.

Но «похожее» – это не «точно такое же». Это принципиально другая задача. Измените в документе одну запятую – хэш изменится полностью, станет совершенно другой строкой, будто это другой документ. Измените в фотографии один пиксель – хэш станет другим. Пересохраните JPEG с чуть другим сжатием – хэш изменится, хотя картинка визуально неотличима. Для хэша нет понятия «почти совпадает» или «немного отличается». Есть только «да» и «нет», совпало или не совпало. Бинарно. Абсолютно.