От совпадения слов к пониманию смысла запроса: как эволюционировали поисковики и AI‑чаты

Кто помнит поисковики начала двухтысячных, наверняка помнит, что результаты выдачи иногда имели мало общего с самим запросом. Системы слабо учитывали порядок слов, синонимы, предлоги и отрицания, поэтому пользователям приходилось упрощать формулировки, добавлять уточнения и пробовать запрос в нескольких вариантах.

Чат‑боты того времени тоже были совсем не похожи на современные AI‑чаты. Они находили во фразе знакомое ключевое слово и выбирали одну из заранее подготовленных реплик, а любое отклонение от предусмотренного сценария быстро заводило диалог в тупик.

Сегодня поисковые системы распознают сущности, учитывают контекст, геопозицию и смысловые связи между словами, а также способны формировать ответы на основе нескольких источников. AI‑чаты понимают разные формулировки одного намерения, работают с текстом, изображениями и голосом, используют веб‑поиск и могут учитывать контекст предыдущих разговоров.

Чтобы поисковые системы и AI‑чаты научились отвечать так, как они отвечают сегодня, потребовался долгий путь. Именно об этой эволюции и пойдет речь в статье.

Часть I. Как поисковые системы учились понимать запросы

1990-е: поисковик видел слова, а не смысл

Основа классической поисковой системы — индекс. Краулер обходил сайты, считывал текст и записывал, на каких страницах встречается каждое слово. Получался огромный каталог интернета. Когда пользователь вводил запрос, поисковик не перечитывал все сайты заново, а обращался к этому индексу и быстро находил подходящие страницы.

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

Для представления текста применялся подход Bag of Words, то есть способ представить документ в числовом виде: система фиксирует, какие слова в нем встречаются и сколько раз, но не учитывает их порядок и связи между ними. Поэтому предложения «Иван быстрее Сергея» и «Сергей быстрее Ивана» получают одинаковый набор слов, хотя сообщают противоположные факты. Дополнительная проблема возникала со стоп‑словами: частые служебные слова могли исключаться из обработки, хотя именно не, без, до или после иногда полностью меняют смысл запроса.

Ниже — намеренно упрощенный пример. Он показывает, как два разных запроса могут получить одинаковое представление, если на этапе обработки удалить отрицания как стоп‑слова.

import re
from collections import Counter


STOP_WORDS = {
    "в", "на", "у", "не", "без", "с", "и", "но"
}


def legacy_bow(text: str) -> Counter[str]:
    tokens = re.findall(r"[а-яё]+", text.lower())

    return Counter(
        token
        for token in tokens
        if token not in STOP_WORDS
    )


query_a = "парковка в центре Петербурга у порта"
query_b = "парковка в центре Петербурга, но не у порта"

print(legacy_bow(query_a))
print(legacy_bow(query_b))

assert legacy_bow(query_a) == legacy_bow(query_b)

Сам по себе Bag of Words лишь превращает документ в набор числовых признаков, но не определяет, какие слова важнее и какую страницу нужно поставить выше. Для решения этой задачи применялись методы взвешивания и ранжирования — в частности, TF‑IDF и BM25.

TF‑IDF и BM25: не все слова одинаково важны

В простейшем варианте Bag of Words учитывает только количество употреблений каждого слова. При этом сама по себе частота слова далеко не всегда отражает его смысловую ценность. Общеупотребительные термины встречаются почти в каждом документе, тогда как тему статьи задают редкие, специфические слова.

Метод TF‑IDF (TF — частота слова в документе; IDF — редкость слова во всем интернете) присваивает больший вес словам, которые часто встречаются в конкретном документе, но редко — во всей коллекции. Например, в запросе ошибка Docker 0x80070005 код ошибки ^[1] и слово Docker лучше отличают нужные страницы от остальных, чем общее слово ошибка.

Позже широкое распространение получил BM25 — вероятностный метод ранжирования, который также учитывает длину документа и эффект насыщения. Первые повторения ^[2] нужного слова заметно повышают оценку страницы, но каждое следующее влияет все меньше. Поэтому документ, где термин повторен двадцать раз, не считается автоматически в двадцать раз полезнее документа, где он встречается один раз.

TF‑IDF и BM25 оставались лексическими методами: они оценивали совпадение слов, но не понимали синонимы, отрицания и перефразированные мысли. Зато поисковик уже не просто считал найденные термины, а определял, насколько каждое совпадение важно для конкретного запроса.

1998 год: Google учится оценивать авторитет страницы

По мере роста веба одного совпадения терминов стало недостаточно. Тысячи страниц могли содержать нужные слова, но далеко не все были одинаково полезными.

В работе Сергея Брина и Ларри Пейджа о раннем Google структура гиперссылок стала отдельным сигналом при ранжировании. Алгоритм PageRank оценивал значимость страницы по входящим ссылкам, учитывая вес страницы‑источника и количество размещенных на ней исходящих ссылок. Поэтому ссылка с уже высоко оцененной страницы влияла на PageRank сильнее, чем ссылка с малоизвестного сайта.

PageRank не решал задачу понимания естественного языка. Он отвечал на другой вопрос: какие из уже найденных документов с большей вероятностью заслуживают доверия и высокой позиции. С появлением PageRank проявилось важное разграничение: matching определяет, о чем документ, ranking — насколько высоко его показать.

Начало 2000-х: поиск начинает прощать ошибки

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

Если раньше запрос с ошибкой мог почти ничего не найти, пока человек не перепечатает его правильно, то позже поисковик уже понимал, что рестаран — это, скорее всего, ресторан, а запросы купить холодильник и покупка холодильника относятся к одной теме.

Для русского языка особенно важны морфологический анализ и лемматизация — приведение словоформ к начальной форме. Дополнительные словари и статистика помогали связывать однокоренные и близкие по смыслу слова. Поэтому купить, покупаю, покупка и купленный уже не обязательно воспринимались как четыре совершенно независимых сигнала.

Да, до полноценного понимания контекста было еще далеко: поиск по‑прежнему опирался на слова, словари и правила. Но пользователю по крайней мере уже не приходилось угадывать единственную верную формулировку запроса.

Упрощенно предварительную обработку запроса можно представить так:

def preprocess_query(query: str) -> list[str]: 
    query = fix_spelling(query) # "рестаран" → "ресторан" 
    tokens = tokenize(query) # разбить запрос на слова 
    lemmas = lemmatize(tokens) # привести словоформы к начальной форме 
    terms = expand_synonyms(lemmas) # добавить близкие по смыслу слова 
    return terms

Это Python псевдокод. Он показывает один из возможных вариантов предварительной обработки запроса: исправление опечаток, разбиение текста на токены, приведение слов к начальной форме и расширение запроса синонимами перед обращением к поисковому индексу.

В итоге, поисковик начал работать не только с тем, что пользователь буквально написал, но и с вероятной нормализованной версией его запроса.

2009 год: MatrixNet и переход к learning‑to‑rank

К концу 2000-х поисковые системы учитывали уже десятки и сотни сигналов: совпадение текста запроса со страницей, ссылочные показатели, свежесть материала, регион пользователя, качество документа и другие параметры. Но оставался вопрос: как правильно объединить их и определить, какие страницы нужно показать выше.

В 2009 году Яндекс внедрил MatrixNet — собственный метод машинного обучения ^[3] для построения формулы ранжирования. Вместо того чтобы вручную задавать вес каждого фактора, систему обучали на большом количестве примеров: для запросов заранее оценивали, насколько хорошо разные страницы на них отвечают. На основании этих данных модель училась рассчитывать итоговую оценку документа.

Упрощенно принцип learning‑to‑rank можно представить так:

features = {
    "text_relevance": text_relevance(query, document),
    # насколько текст страницы соответствует запросу

    "link_score": link_score(document),
    # оценка страницы по входящим ссылкам

    "freshness": freshness_score(document),
    # актуальность материала

    "region_match": region_match(query, document),
    # соответствие страницы региону пользователя или запроса

    "page_quality": page_quality_score(document),
    # общая оценка качества страницы
}

ranking_score = ranking_model.predict(features)
# итоговая оценка, по которой документ размещается в выдаче

Для каждого документа формируется набор признаков, модель рассчитывает итоговый ranking_score, а затем страницы сортируются по полученным оценкам.

MatrixNet позволял учитывать большое количество факторов и их сочетаний при построении формулы ранжирования. Это был важный этап развития поиска: порядок выдачи начал определяться не только правилами, заданными разработчиками, но и закономерностями, которые модель находила в обучающих данных.

2012 год: Knowledge Graph — от строк к сущностям

Лексический поиск плохо справляется с неоднозначностью. Taj Mahal может означать мавзолей, музыканта, казино или ресторан. Последовательность символов одна, сущности разные.

В 2012 году Google представил Knowledge Graph — граф реальных объектов и связей между ними. В нем хранятся не только названия, но и типы сущностей, атрибуты и отношения: человек родился в городе, актер снимался в фильме, произведение создано автором.

Поисковый pipeline получил новые операции:

строка запроса
      ↓
поиск упоминаний сущностей
      ↓
entity linking и disambiguation
      ↓
выбор нужного объекта
      ↓
поиск документов и фактов об объекте

Если пользователь пишет ягуар скорость, система должна определить, интересует его животное или автомобиль. Для этого учитываются соседние слова, популярные интерпретации и контекст сессии.

Knowledge Graph не заменил обычный поиск по страницам. Его главная задача заключалась в том, чтобы помочь поисковику определить, о каком конкретном объекте идет речь, и связать его с известными фактами и другими объектами. Благодаря этому по запросу Taj Mahal Google мог различить мавзолей, музыканта и казино, а затем показать подходящие результаты и структурированную карточку выбранной сущности.

2015 год: RankBrain связывает формулировки с понятиями

Не все запросы однотипны, некоторые встречаются довольно редко. А бывает и такое, что пользователь может не знать профессионального термина и описать понятие обычными словами: как называется боязнь замкнутых пространств.

В 2015 году Google внедрил RankBrain — первую систему глубокого обучения, развернутую непосредственно в Search. Она помогала связывать слова запроса с концептами и использовать это соответствие при ранжировании.

Вместо требования точного совпадения:

запрос: боязнь замкнутых пространств
страница: клаустрофобия
лексическое пересечение: низкое

система могла учитывать семантическую близость:

semantic_similarity(
    "боязнь замкнутых пространств",
    "клаустрофобия"
) → высокая

RankBrain не понимал текст в человеческом смысле — он лишь сопоставлял запросы с концептами и был один из компонентов ранжирования, особенно полезный для редких и непривычных формулировок.

2016–2017 годы: «Палех» и «Королёв» в Яндексе

В 2016 году Яндекс запустил поисковое обновление «Палех». Алгоритм был ориентирован в том числе на long‑tail‑запросы.

Для «Палеха» использовалась модель типа DSSM (Deep Structured Semantic Model) — нейросеть, которая превращала запрос пользователя и заголовок страницы в числовые векторы. Если тексты были близки по смыслу, похожими получались и их векторы. Благодаря этому поисковик мог находить подходящие страницы даже без точного совпадения слов.

Предположим, человек вводит:

фильм, в котором мужчина несколько лет живет в аэропорту

Заголовок релевантной страницы может выглядеть так:

Терминал — фильм Стивена Спилберга

У обычного лексического поиска здесь почти нет одинаковых слов. Нейросетевая модель сравнивала уже не только слова, но и числовые представления смысла запроса и заголовка:

query_vector = encoder.encode(query)
title_vector = encoder.encode(document_title)

score = dot_product(query_vector, title_vector)

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

По современной терминологии, это схема раздельного кодирования — bi‑encoder, или dual encoder: запрос и заголовок страницы преобразуются в векторы независимо, а их смысловая близость оценивается с помощью скалярного произведения. В «Палехе» такой подход применялся главным образом к запросу и заголовку. В «Королёве» его расширили на полный текст страницы, а вектор документа стали рассчитывать заранее и хранить в поисковом индексе. Благодаря этому нейросетевое сравнение можно было применять к гораздо большему числу документов без чрезмерного увеличения времени ответа.

2018 год: Neural Matching и fuzzy concepts

Похожее направление развивал Google. В 2018 году компания внедрила Neural Matching. Компания описывала его как систему, которая сопоставляет запрос и страницу целиком и помогает понимать «размытые» представления понятий, а не только одинаковые ключевые слова.

Например:

почему экран телефона сам нажимает кнопки

и:

устранение фантомных касаний сенсорного дисплея

лексически похожи слабо, но описывают одну проблему.

На этом этапе нейросетевые модели стали играть заметную роль не только в ранжировании уже отобранных документов, но и в retrieval — расширении множества кандидатов, потенциально отвечающих намерению пользователя.

2019 год: BERT начинает учитывать связи между словами

BERT — модель обработки текста на основе архитектуры Transformer. Такая архитектура позволяет анализировать фразу целиком и определять, какие слова связаны между собой. BERT учитывает контекст слова с обеих сторон, поэтому ключ в выражениях ключ от двери и ключ к задаче получает разные числовые представления.

В 2019 году Google начал применять BERT в поиске, чтобы точнее ранжировать результаты и выбирать фрагменты для коротких ответов над основной выдачей. Одним из показательных примеров стал запрос:

2019 brazil traveler to usa need a visa

До BERT поиск мог показать информацию об американцах, направляющихся в Бразилию. После внедрения модели система лучше учла отношение, заданное предлогом to, и распознала обратное направление: гражданин Бразилии едет в США.

Но здесь важен не только предлог to, а общий смысл, который складывается из отношений между частями запроса:

путешественник ── страна отправления ── Бразилия
путешественник ── направление поездки ── США

Главное преимущество BERT заключалось в том, что модель учитывала не только наличие отдельных слов, но и их роль в конкретной фразе. Это позволило Google точнее обрабатывать длинные разговорные запросы, особенно когда смысл зависел от предлогов, порядка слов или отрицания. BERT не устранил ошибки полностью, но стал одним из наиболее заметных улучшений понимания поисковых запросов на тот момент.

Как контекстная модель дополняет обычный поиск

RERANK_LIMIT = 100

# Этап 1: быстрый лексический поиск отбирает кандидатов
candidates = lexical_search(
    query,
    index,
    limit=1000,
)

shortlist = candidates[:RERANK_LIMIT]

# Этап 2: контекстная модель уточняет оценку документов
for document in shortlist:
    context_score = context_model.score(
        query,
        document.relevant_fragment,
    )

    document.final_score = combine_scores(
        lexical_score=document.lexical_score,
        context_score=context_score,
        other_signals=document.other_signals,
    )

results = sorted(
    shortlist,
    key=lambda document: document.final_score,
    reverse=True,
)

Сначала быстрый лексический поиск отбирает ограниченный набор потенциально подходящих страниц. Затем контекстная модель совместно анализирует запрос и фрагмент каждого документа, после чего ее оценка объединяется с другими сигналами ранжирования и результаты сортируются заново.

2020 год: YATI в поиске Яндекса

В 2020 году Яндекс внедрил YATI — Yet Another Transformer with Improvements. Модель была специально обучена для поискового ранжирования: она сравнивала запрос с наиболее важными фрагментами страницы и оценивала, действительно ли в них содержится подходящий ответ, а не просто похожие слова.

Главная сложность заключалась в том, чтобы использовать такую тяжелую модель в реальном поиске. Яндекс должен обрабатывать десятки тысяч запросов в секунду и выдавать результаты без заметной задержки, а большой трансформер требует значительных вычислительных ресурсов. Кроме того, страницу нельзя целиком передавать модели при каждом запросе: документ может быть слишком длинным, а потенциальных результатов — очень много. Поэтому YATI запускали на графических ускорителях, уменьшали вычислительную сложность модели и разделяли обработку запроса и документов на несколько этапов.

Упрощенно процесс выглядел так:

Быстрые алгоритмы отбирают потенциально подходящие страницы.
Нейросеть точнее сравнивает запрос с важными фрагментами отобранных страниц.
Итоговый порядок формируется с учетом оценки YATI и других факторов: качества страницы, свежести, региона и других сигналов.

Такая многоступенчатая схема позволила применять сложную нейросеть не ко всему поисковому индексу, а только к ограниченному числу уже отобранных страниц. Благодаря этому Яндекс смог повысить точность ранжирования, не замедлив поиск до неприемлемого уровня. По оценке компании, внедрение YATI стало самым значительным улучшением ранжирования со времен MatrixNet.

2021 год: MUM связывает сложные запросы, языки и форматы

В 2021 году Google представил MUM — Multitask Unified Model. Она была обучена одновременно на 75 языках и могла работать не только с текстом, но и с изображениями. Главная задача MUM заключалась в том, чтобы лучше обрабатывать сложные вопросы, для ответа на которые пользователю обычно приходилось вводить несколько отдельных запросов.

Google приводил такой пример:

Я уже поднимался на гору Маунт‑Адамс и хочу подняться на Фудзи следующей осенью. Что мне нужно изменить в подготовке?

Чтобы обработать такой сложный запрос, MUM должна была выделить внутри него несколько связанных тем: различия между горами, сезон, погоду, маршруты, экипировку и физическую подготовку. После этого поисковая система могла отдельно найти материалы по каждому направлению и показать в выдаче страницы и тематические блоки, которые вместе помогали ответить на вопрос пользователя.

MUM обучалась на 75 языках и могла сопоставлять одинаковые понятия, даже если на разных языках они назывались по‑разному. Например, сведения о Фудзи из японских материалов помогали модели точнее определить связанные с восхождением темы, а затем подобрать подходящие результаты для запроса, заданного на другом языке.

Первым практическим применением MUM стал поиск информации о вакцинах. Google передал модели официальные названия препаратов, а она обнаружила более 800 вариантов их названий и написания на 50 языках. После проверки эти соответствия добавили в обработку запросов, поэтому поиск мог понимать, что разные технические, торговые и местные названия обозначают одну и ту же вакцину.

MUM также задумывалась как мультимодальная модель: она могла сопоставлять текст и изображения. Например, пользователь мог сфотографировать поврежденную деталь велосипеда и дополнить изображение вопросом о том, как ее отремонтировать. Поисковая система должна была учитывать и сам объект на фотографии, и текстовое уточнение.

При этом MUM не заменила BERT, RankBrain и другие компоненты Google Search. В 2021 году ее внедряли постепенно и использовали для отдельных задач, а не как единую модель, управляющую всей поисковой выдачей.

2024 год: «Нейро» формирует ответ на основе найденных источников

В 2024 году Яндекс запустил «Нейро» — сервис, объединивший обычный веб‑поиск и языковую модель YandexGPT 3. Поисковая часть отбирает актуальные источники, после чего языковая модель анализирует их и формирует связный ответ со ссылками. Система также поддерживает follow‑up‑вопросы и мультимодальные запросы.

Упрощенно процесс выглядит так:

текстовый запрос или изображение с вопросом
                    ↓
поиск подходящих страниц в интернете
                    ↓
выбор полезных фрагментов из найденных материалов
                    ↓
анализ информации с помощью YandexGPT
                    ↓
формирование краткого связного ответа
                    ↓
добавление ссылок на использованные источники

2025 год: AI Mode разбивает сложный вопрос на несколько поисков

В 2025 году Google начал разворачивать AI Mode. Один из его ключевых механизмов — query fan‑out: система разбивает сложный вопрос на несколько связанных подтем, параллельно выполняет по ним отдельные поиски, а затем объединяет найденную информацию в один ответ.

Например, для запроса:

Какой ноутбук до 1500 евро подойдет для Kotlin-разработки, работы с Docker и редкого запуска локальных языковых моделей?

система может выделить несколько направлений:

процессор и объем оперативной памяти для Docker
совместимость с нужной операционной системой
производительность NPU или GPU
автономность
актуальные цены
качество системы охлаждения

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

AI Mode также получил поиск по изображениям. Модель анализирует не только фотографию целиком, но и отдельные объекты, их форму, цвет и материал, после чего запускает несколько связанных запросов. Например, по снимку книжной полки система может распознать отдельные книги, найти информацию о каждой из них и предложить похожие произведения.

2026 год: личный контекст и живой диалог с поиском

В 2026 году Google сосредоточился не только на точности выдачи, но и на контексте конкретного пользователя. В режиме AI Mode появилась функция Personal Intelligence — персонализация поиска на основе данных из подключенных сервисов Google. С разрешения пользователя система может учитывать информацию из Gmail и Google Photos вместе с материалами из интернета. Например, при планировании поездки она может найти в почте даты и место бронирования, а по фотографиям определить интересы пользователя и предложить более подходящий маршрут. Подключение работает добровольно, и его можно отключить в настройках. На старте функция была доступна в тестовом режиме для отдельных подписчиков в США.

Еще одним направлением стал Search Live — режим живого общения с поиском. В приложении Google пользователь нажимает кнопку Live, задает вопрос голосом, получает аудиоответ со ссылками и может сразу задать уточняющий вопрос. Система сохраняет контекст текущей беседы, поэтому каждую следующую реплику не нужно формулировать с нуля.

Если включить камеру, Search Live анализирует то, что находится перед пользователем, и связывает изображение с заданным вопросом. Например, можно показать детали стеллажа и спросить, куда установить конкретное крепление, или навести камеру на растение и уточнить, почему у него желтеют листья. Поиск распознает объекты в кадре, учитывает голосовое пояснение и подбирает подходящую информацию из интернета. В марте 2026 года Search Live стал доступен во всех языках и регионах, где работает AI Mode.

Сегодня поиск все больше напоминает AI‑чат, но, несмотря на всю его эволюцию ^[4], ядром по‑прежнему остается поисковая система. Сначала она анализирует запрос, обращается к индексу, находит подходящие страницы и определяет их порядок в выдаче. Все остальное — от исправления опечаток до распознавания смысла и контекста, поиска по изображениям и формирования готового ответа — работает уже поверх этой основы.

Но поиск — это только половина истории. Параллельно развивались диалоговые интерфейсы, у которых была другая задача: не просто найти страницы, а поддержать полноценный разговор с человеком.

О том, как чат‑боты прошли путь от жестких заранее написанных сценариев до современных языковых моделей с голосовым вводом и памятью ^[5] диалога, читайте во второй части: «Часть II. Как AI‑чаты учились понимать пользователя» — она выйдет уже совсем скоро.