Обзор модуляЧасть V · ~10 ч · Сложность: (средний) · Пререквизиты: Модуль 5, Модуль 12
До сих пор мы строили ранжирование так, будто релевантность документа запросу — свойство пары (q, d) и больше ничего. На практике это упрощение. Один и тот же запрос «доставка пиццы», «налоговая декларация» или «погода» означает разное для пользователя в разных городах, странах и языковых контурах; запрос «футбол» в сезон местного дерби и в межсезонье ждёт разного; а у двух разных людей, набравших «ягуар», в голове может быть кошка, автомобиль или операционная система. Релевантность на самом деле — свойство тройки (q, d, u, c): запроса, документа, пользователя u и контекста c (место, время, язык, устройство, история сессии). Этот модуль — о том, как поисковая система учитывает это, оставаясь при этом полезной, предсказуемой и не нарушающей приватность.
В сквозном конвейере «обход → индекс → факторы → ранжирование → выдача → постобработка → измерение» локализация и персонализация — это дополнительные источники признаков и переранжирующие сигналы, которые подмешиваются в каскад (Модуль 12) и в постранжирование. Гео- и языковые признаки уточняют, какие документы вообще являются кандидатами и как их скорить; персональные признаки уточняют порядок внутри уже релевантного множества. Понимание запроса из Модуля 5 здесь становится контекстно-зависимым: интент P(intent | q) превращается в P(intent | q, u, c).
После модуля студент будет понимать: как документ и запрос привязываются к региону и как считается гео-релевантность; чем языковой контур отличается от странового и как они влияют на отбор и ранжирование; как устроена персонализация по истории, профилю и сессии, и почему она резко повышает риск переобучения и непредсказуемости; и где проходят инженерные, продуктовые и этические границы персонализации — приватность и эффект «пузыря фильтров».
Как читать по трекамВнимание. Это средний по сложности модуль ((средний)), но глава 18.3 (персонализация) — продвинутая ((продвинутый)): там появляются проблемы редких данных, обратной связи (feedback loop), холодного старта и отделения персонального сигнала от общего. Если контекстное ранжирование ново — закрепите гео-контур (18.1–18.2) прежде, чем браться за персонализацию.
- Студент — обязательны 18.1 (модель гео-привязки документа и запроса, гео-релевантность как фактор) и 18.3 (что персонализируется, источники сигналов, риски переобучения и feedback loop). Глава 18.2 — на уровне идей (язык ≠ страна, контуры). Глава 18.4 — обязательна концептуально (приватность, пузырь фильтров): это связка с этикой (Модуль 21).
- Инженер — всё обязательно. Особое внимание: инженерные заметки о хранении гео-индекса и геокодировании, о пайплайне признаков сессии в реальном времени, о холодном старте и о приватных техниках (агрегация, дифференциальная приватность, on-device). Важна архитектурная развязка «общий скор → персональный переранжер».
- SEO — главы 18.1 (региональное продвижение, привязка бизнеса к локации, локальная выдача) и 18.2 (мультиязычность, разметка языковых/региональных версий, аналог hreflang). Из 18.3–18.4 — как персонализация искажает наблюдаемые позиции и почему «своя» выдача не равна выдаче пользователя. SEO-врезки разбросаны по всему модулю.
- Смешанный — последовательно весь модуль; формальные модели гео-затухания и разложения скора в 18.3 можно бегло просмотреть при первом проходе и вернуться позже.
- 18.1. Региональная привязка документа и запроса; гео-релевантность — как документ и запрос получают регион, что такое локальный/гео-чувствительный запрос, гео-затухание и гео-фактор в каскаде. (средний)
- 18.2. Языковые и страновые контуры ранжирования — язык ≠ страна, отбор по контуру, мультиязычные документы, аналог hreflang, межъязыковой поиск. (средний)
- 18.3. Персонализация: история запросов, профиль, контекст сессии — три горизонта персонализации, источники признаков, архитектура переранжирования, переобучение и feedback loop, холодный старт. (продвинутый)
- 18.4. Границы персонализации: приватность и «пузырь фильтров» — когда персонализация вредит, приватные техники, разнообразие против эха, прозрачность и контроль пользователя. (средний)
Цели обучения
После главы студент сможет:
- Объяснить, почему релевантность многих запросов зависит от местоположения и чем гео-чувствительный запрос отличается от гео-нейтрального.
- Описать, как документ получает региональную привязку (контент, контакты, домен, ссылочное и поведенческое окружение) и как — запрос (явный регион, геолокация устройства, история).
- Формализовать гео-релевантность как функцию расстояния/принадлежности и встроить гео-фактор в каскад ранжирования (Модуль 12).
- Различать глобальную, страновую и локальную (city-level) гранулярность гео-сигнала.
- Оценить влияние гео-привязки на отбор кандидатов и на стратегию локального SEO.
Зачем поиску география
Часть запросов имеет смысл только относительно места. «Аптека рядом», «эвакуатор», «суши» подразумевают здесь и сейчас; «загранпаспорт» или «детский сад» — административно привязаны к региону пользователя; «погода» или «пробки» бессмысленны без локации. Это гео-чувствительные (geo-sensitive, locally biased) запросы. Другая часть — «теорема Пифагора», «рецепт безе», «кто написал „Войну и мир“» — от места не зависит (гео-нейтральные). Между ними — широкий серый слой запросов с локальным интентом по умолчанию: «ресторан» почти всегда «ресторан рядом», но «ресторан на Марсе» — нет.
Задача распадается на три части: (1) привязать документ к региону(ам), к которым он относится; (2) привязать запрос к региону, относительно которого его оценивать; (3) посчитать гео-релевантность пары и подмешать её в скоринг и отбор.Интуиция. Гео-сигнал — это ещё одна ось релевантности. Текстовая релевантность отвечает «о том ли это документ»; гео-релевантность — «для моего ли это места». Идеальный по тексту документ о ремонте обуви в другом городе для запроса «ремонт обуви» почти бесполезен — как идеальная статья на языке, которого пользователь не знает (это уже 18.2).
Как документ получает регион
У документа нет «поля регион» — его приходится выводить из множества слабых сигналов:
Код: Выделить всё
Источник сигнала | Что даёт | Надёжность
--------------------------+------------------------------------------------------------------+------------------------------------------------------
Контент и контакты | адрес, телефон с кодом города, упоминания топонимов, индекс | высокая, если структурно (микроразметка организации)
Доменная зона | .ru, .de, .fr → страна; геодомены | средняя (страна, не город)
Язык контента | сужает множество стран | слабая (язык ≠ страна, 18.2)
Хостинг/IP сервера | страна размещения | очень слабая (CDN, облака размывают)
Ссылочное окружение | на кого ссылаются и кто ссылается, их регионы | средняя, косвенная
Поведение | из каких регионов кликают и удовлетворяются | сильная, но накопительная
Явные сигналы вебмастера | региональная привязка в инструментах для вебмастеров, разметка | высокая, но декларативная
Как запрос получает регионИнженерная заметка. Гео-привязка документа хранится как набор (geo_id, weight, confidence), где geo_id — узел гео-онтологии (район ⊂ город ⊂ регион ⊂ страна), weight — сила связи, confidence — уверенность извлечения. Для бизнес-объектов отдельно ведётся геокод (широта/долгота) точки. Извлечение топонимов из текста — отдельная задача (toponym resolution / geoparsing) с классической неоднозначностью: «Москва» — город, река, несколько населённых пунктов; разрешается по контексту и популярности.
Запрос привязывается к региону по убыванию явности:
- Явный топоним в запросе — «пиццерия Казань», «нотариус Тверская». Регион выделяется при понимании запроса (Модуль 5) и обычно перекрывает остальные сигналы.
- Заданный пользователем регион — выбранный в интерфейсе город/страна.
- Геолокация устройства — GPS/Wi-Fi/сотовые (точная) или по IP (грубая, на уровне города/региона).
- История и профиль — обычный регион пользователя как приор (это уже мостик к 18.3).
- Дефолт страны/языкового контура — последний рубеж.
Ещё система должна оценить степень локальности интента — P(local | q): вероятность, что запросу нужен локальный ответ. Для «суши» она высока, для «фотосинтез» близка к нулю. Эту вероятность учат на поведении (кликают ли пользователи разных регионов по разным документам на один запрос — признак локальности) и на лингвистике запроса.Заблуждение. «Регион запроса — это просто страна по IP.» IP даёт грубую и часто неверную привязку (мобильные сети, VPN, корпоративные шлюзы маршрутизируют через другой город). Поэтому IP — лишь один сигнал среди многих и почти никогда не единственный. Явный топоним и заданный регион сильнее.
Гео-релевантность как функция
Когда есть регион запроса g_q (или точка p_q) и гео-профиль документа, гео-релевантность считается как затухание с расстоянием/несоответствием. Несколько рабочих форм:
- Точка–точка (для бизнесов с геокодом): geo(d, q) = exp(−dist(p_d, p_q) / τ), где dist — расстояние (метрическое или по времени в пути), τ — масштаб затухания (характерный радиус интереса). Близко → ≈1, далеко → →0.
- Принадлежность региону: geo(d, q) = match(g_q, region_profile(d)) — насколько регион запроса покрывается гео-профилем документа (тот же город → 1, та же страна другой город → частично, другая страна → 0 для локального интента).
- Смешанная: для запросов «вокруг меня» — расстояние; для административных («МФЦ») — принадлежность.
Гео-фактор в каскадеПример. Запрос «кофе» от точки p_q. Кофейня A в 200 м: dist=0.2 км, при τ=1 км → geo≈exp(−0.2)=0.82. Кофейня B в 5 км: geo≈exp(−5)=0.0067. Даже если B чуть лучше по отзывам, гео-фактор почти обнуляет её для запроса с локальным интентом. Для запроса «лучшая кофейня в городе» интент шире — τ берётся больше, и B возвращается в игру.
Гео-сигнал входит в систему на двух уровнях (см. Модуль 12):
- Отбор кандидатов (L0/L1). Для сильно локальных запросов индекс сужают географически: берут только документы с подходящим гео-профилем (гео-индекс по сетке/гео-хэшу). Это и точность, и экономия — не скорить пол-страны для запроса «парикмахерская рядом».
- Ранжирование (L2/L3). Гео-релевантность — один из признаков LTR-модели наряду с текстовыми и поведенческими. Её вес модель выучивает сама, и он тем больше, чем выше P(local | q).
Код: Выделить всё
score(d | q, c) = f_LTR( text_features(d,q),
link_features(d),
behavior_features(d,q),
geo(d, q, c), # гео-релевантность
P_local(q), # модулятор веса гео
... )
Инженерная заметка. Геопоиск кандидатов реализуют через гео-индексы: геохэш (geohash), сетки S2/H3, R-деревья. Запрос «в радиусе R от точки» превращается в выборку по ячейкам, покрывающим круг, с последующим точным отсевом по расстоянию. Это переносит дорогую гео-фильтрацию на дешёвую стадию отбора, а точное затухание считается уже на немногих кандидатах.
SEO-врезка (региональное продвижение). Чтобы попадать в локальную выдачу: (1) дайте системе чёткую гео-привязку — структурированный адрес и телефон (микроразметка организации), карточку бизнеса в профильных сервисах, согласованные NAP-данные (Name–Address–Phone) по всему вебу; (2) для нескольких филиалов — отдельные посадочные страницы по городам/районам с уникальным локальным контентом, а не один список адресов; (3) помните, что у локальной выдачи свой набор факторов (близость, отзывы, полнота карточки) поверх обычных; (4) геопривязка по .домену-зоне и хостингу слаба — не полагайтесь на неё, давайте явные структурные сигналы.
Частые заблужденияВнимание. Гранулярность сигнала должна совпадать с гранулярностью интента. Привязка документа к стране бесполезна для запроса «аптека рядом» (нужен район), а попытка приписать глобальному справочному документу один город — вредна (он не локальный, и сужение по гео его несправедливо отсечёт). Гео-нейтральные документы нельзя загонять в гео-фильтр.
Заблуждение. «Если добавить в текст название города много раз, документ станет локальным для этого города.» Текстовое упоминание — слабый и легко спамящийся сигнал. Сильную привязку дают структурные данные (адрес, геокод, карточка) и поведение пользователей региона. Переспам топонимами ловится антиспамом (Модуль 16).
Лаба / практикаЗаблуждение. «Гео-релевантность — отдельный финальный фильтр после ранжирования.» Чаще это и стадия отбора (сужение индекса), и признак внутри LTR, чей вес зависит от локальности запроса. Жёсткий пост-фильтр опасен: обнулит полезные нелокальные результаты для запросов со смешанным интентом.
Дано: 8 документов-бизнесов с координатами, рейтингом (0–5) и текстовой релевантностью к запросу «кофе» (0–1); точка пользователя p_q; две категории τ (кофейня τ=1 км, гипермаркет τ=15 км). (1) Посчитайте geo(d,q)=exp(−dist/τ) для подходящего τ. (2) Соберите итоговый скор как 0.5·text + 0.2·rating/5 + 0.3·geo и отсортируйте. (3) Повторите для P_local низкой («лучший кофе в стране»): обнулите гео-вес и пересортируйте. Сравните топы. Время ~45 мин. Критерий «сделано»: при высоком P_local близкие бизнесы поднялись над далёкими-но-лучшими; при низком — порядок определяется текстом и рейтингом; объяснено влияние τ и P_local.
Контрольные вопросы
- Чем гео-чувствительный запрос отличается от гео-нейтрального? Приведите по два примера и один пограничный.
- Перечислите источники гео-привязки документа и расположите их по надёжности. Почему IP сервера слаб?
- Что такое гео-профиль документа и почему одной точки недостаточно?
- Запишите две формы гео-релевантности (точка–точка и принадлежность) и объясните роль τ.
- На каких стадиях каскада участвует гео-сигнал и чем отличается его роль на отборе и на ранжировании?
- Что такое P(local | q) и как её оценивают по поведению?
- Почему жёсткий гео-пост-фильтр опаснее, чем гео-признак в LTR?
- Сформулируйте для SEO три действия, повышающих локальную видимость, и одно бесполезное.
Цели обучения
После главы студент сможет:
- Разделять язык, страну и регион как независимые оси и объяснить, почему их смешение — частая ошибка.
- Описать языковой/страновой контур (locale) и его роль в отборе и ранжировании.
- Обрабатывать мультиязычные и многорегиональные документы и связи между их версиями (аналог hreflang).
- Объяснить идею межъязыкового поиска (cross-lingual retrieval) и когда он нужен.
- Сформулировать правила мультиязычного SEO без дублирования и каннибализации.
Язык, страна, регион — три разные оси
Их постоянно путают, а это независимые измерения:
- Язык (language) — на каком языке написан/нужен контент: ru, en, de.
- Страна/регион (country/region) — для какой юрисдикции/рынка контент: цены, законы, доставка, локальные реалии.
- Гео (geo) — физическое место (глава 18.1).
Контур / локаль (locale) — рабочая комбинация (язык, регион), например ru-RU, de-CH, es-MX. Поиск ведётся в рамках контура: он задаёт язык интерфейса и подсказок, приоритетный язык контента, страновой набор реалий и дефолты форматов (даты, валюта).Интуиция. Эти оси пересекаются, но не совпадают. Швейцарец читает по-немецки, по-французски или по-итальянски — один регион, три языка. Испанский нужен и в Испании, и в Мексике, и в Аргентине — один язык, разные страны (разные цены, реалии, даже лексика). Англоязычный эмигрант в другой стране хочет интерфейс на родном языке, но локальные результаты по месту жительства. Сводить всё к «стране по IP» — значит выдать ему чужой язык.
Определение языка запроса и пользователя
- Язык запроса определяется по символам/словам (для коротких запросов ненадёжно: «table» — англ. или фр.?), по языку интерфейса, по истории. Двуязычные пользователи смешивают языки даже в одном запросе.
- Предпочтения пользователя — заявленные языки (часто упорядоченный список: «немецкий, затем английский») плюс выученные из поведения.
- Страновой контур — заданный пользователем регион или дефолт по сигналам (глава 18.1), но независимо от языка.
Контур в отборе и ранжированииЗаблуждение. «Определять язык запроса по стране пользователя.» Нет: язык — отдельный сигнал. Пользователь в одной стране может искать на другом языке (эмигранты, билингвы, профессиональная терминология на английском). Контур — это пара осей, а не одна.
Языково-страновой контур работает похоже на гео-фактор, но мягче:
- Отбор. Документы не на языке(ах) пользователя обычно понижаются или отсекаются — но не всегда жёстко: для нишевых/научных запросов англоязычный результат полезен, даже если контур русский. Поэтому язык — чаще сильный признак, чем жёсткий фильтр.
- Ранжирование. Совпадение языка документа и предпочтений пользователя, совпадение странового контура (релевантна ли версия именно этому рынку) — признаки LTR. Их вес зависит от запроса: для «купить X» страновой контур критичен (цены, доставка), для «история Рима» — нет.
Код: Выделить всё
locale_match(d, u) = w_lang · lang_fit(lang(d), prefs(u))
+ w_country · country_fit(region(d), region(u))
Мультиязычные и многорегиональные документыПример. Пользователь de-CH (немецкий, Швейцария), запрос «Versicherung» (страховка). Документы: (A) немецкая версия для Германии — язык совпал, страна нет (цены/законы DE); (B) немецкая версия для Швейцарии — совпало всё; (C) французская для Швейцарии — страна совпала, язык нет. Порядок при коммерческом интенте: B ≻ A ≻ C (страна важнее для покупки), но для пользователя, чей второй язык французский, C может обойти A.
Сайт часто существует в нескольких языковых/страновых версиях одного контента: example.com/de/, example.com/fr/, example.com/en-us/, example.com/en-gb/. Для системы это вызов: версии — не дубли (их нельзя схлопывать каноникализацией, Модуль 3), но и не независимы (это один контент на разных языках/для разных рынков).
Решение — механизм объявления альтернатив (аналог hreflang): каждая версия декларирует свои (язык, регион) и ссылается на все остальные версии-альтернативы. Это даёт системе три вещи: (1) понять, что это семья версий одного контента; (2) для пользователя контура X показать именно версию X, а не случайную; (3) не считать версии дублями и не наказывать за «дублирующийся контент».
Код: Выделить всё
<альтернатива lang="de" region="DE" url="…/de-de/">
<альтернатива lang="de" region="CH" url="…/de-ch/">
<альтернатива lang="fr" region="CH" url="…/fr-ch/">
<альтернатива lang="en" url="…/en/"> # язык без региона
<альтернатива default url="…/en/"> # запасной вариант
Инженерная заметка. Декларации альтернатив должны быть взаимными и согласованными: если A ссылается на B как на французскую версию, B обязана ссылаться обратно. Односторонние или конфликтующие объявления игнорируются как ненадёжные. Система всё равно проверяет декларации поведением и контентом — заявленный язык, не совпадающий с фактическим, обнуляет доверие к разметке.
Межъязыковой поискSEO-врезка (мультиязычность). (1) Каждой языковой/страновой версии — свой стабильный URL и взаимная разметка альтернатив со всеми остальными версиями плюс x-default-аналог для непокрытых контуров. (2) Не подменяйте язык по IP без возможности переключиться — это ломает индексирование и раздражает пользователя. (3) Переводите контент по-настоящему, а не только интерфейс: «тонкие» автопереводы — кандидат на понижение. (4) Не путайте мультиязычность с дублированием: правильно связанные версии не каннибализируют друг друга; несвязанные — конкурируют за один контур и размывают сигналы.
Иногда нужное знание есть только на другом языке (узкая тема, документация, наука). Межъязыковой поиск (cross-lingual retrieval) позволяет по запросу на одном языке находить документы на другом: запрос переводится (или, в нейропоиске, запрос и документ кодируются в общее многоязычное пространство эмбеддингов, где близость не зависит от языка — связь с Модулем 10). Результат при показе может сопровождаться переводом. Это включают осознанно — для большинства навигационных и коммерческих запросов чужой язык не нужен.
Частые заблужденияЗаблуждение. «Документ на чужом языке всегда нерелевантен.» Для нишевых информационных запросов авторитетный источник на английском может быть лучшим ответом, чем слабый на родном языке. Поэтому язык — взвешиваемый признак, а не абсолютный запрет; его вес зависит от запроса и от доступности контента на языке пользователя.
Заблуждение. «Язык и страна — одно и то же, достаточно одной настройки.» Это две независимые оси. de-DE, de-CH, de-AT — один язык, три рынка; es-ES и es-MX — один язык, разные реалии. Контур всегда пара.
Лаба / практикаЗаблуждение. «Перевод страницы создаёт дубль, и его понизят.» Корректно связанные через альтернативы переводы — не дубли, а версии. Понижают за необъявленные копии и за машинный перевод без ценности, а не за честную локализацию.
Дано: контент в 4 версиях с заявленными (lang, region): de-DE, de-CH, fr-CH, en (+ x-default=en); таблица взаимных деклараций альтернатив (с одной намеренно односторонней). Три пользователя: de-CH, fr-CH, it-IT. (1) Постройте граф альтернатив, найдите несогласованную связь и отметьте её как недоверенную. (2) Для каждого пользователя выберите версию по правилам (точное совпадение контура → совпадение языка → x-default). (3) Объясните выбор для it-IT (нет ни языка, ни региона). Время ~40 мин. Критерий «сделано»: для de-CH/fr-CH выбраны точные версии, для it-IT — x-default, односторонняя связь помечена недоверенной с объяснением последствий.
Контрольные вопросы
- Назовите три независимые оси и приведите пример, где язык и страна расходятся.
- Что такое контур (locale) и из чего он состоит? Почему страну нельзя выводить из языка?
- Как язык участвует в отборе и ранжировании? Почему он чаще признак, а не жёсткий фильтр?
- Чем мультиязычные версии отличаются от дублей и почему их нельзя схлопывать?
- Что декларирует механизм альтернатив (аналог hreflang) и почему связи должны быть взаимными?
- Что такое межъязыковой поиск и как его реализуют в нейропоиске?
- Для SEO: как связать языковые версии, чтобы не было каннибализации? Что делает подмена языка по IP?
Цели обучения
После главы студент сможет:
- Различать три горизонта персонализации: профиль (долгосрочный), история (среднесрочный), сессия (краткосрочный) — и их источники сигналов.
- Спроектировать архитектуру «общий скор → персональный переранжер» и объяснить, почему персонализацию обычно делают как переранжирование, а не как замену базового ранжирования.
- Оценить риски: разреженность данных, холодный старт, переобучение под пользователя и контур обратной связи (feedback loop).
- Формализовать разложение скора на общий и персональный компоненты и роль доверия к персональному сигналу.
- Измерить эффект персонализации корректно (онлайн/офлайн, с учётом смещения предъявления).
Что вообще персонализируется и насколько
Персонализация — это сдвиг ранжирования под конкретного пользователя на основе того, что система о нём знает. Но не всё стоит персонализировать. Полезность сильно зависит от типа запроса:
- Навигационные («сайт банка X») — персонализация почти бесполезна и опасна: ответ один для всех.
- Однозначные информационные («температура кипения воды») — персонализация лишняя.
- Неоднозначные («ягуар», «питон», «ласка») — персонализация ценна: история помогает разрешить интент (программист → язык, зоолог → животное).
- Повторные/возвратные («та статья, что я читал», повторный поиск) — персонализация очень ценна.
- С предпочтениями (рецепты, музыка, шопинг) — персонализация уместна (диета, бренд, ценовой сегмент).
Три горизонта: профиль, история, сессияИнтуиция. Персонализация — не «переписать выдачу под человека», а разрешить остаточную неопределённость, которую общий сигнал снять не смог. Если общий интент ясен (навигация), персонализировать нечего. Чем шире P(intent | q), тем больше пользы от P(intent | q, u).
Код: Выделить всё
Горизонт | Окно | Сигналы | Что разрешает
-------------------------+----------------------------------+-----------------------------------------------------------------------------------+-----------------------------------------------------------
Профиль (долгосрочный) | месяцы/годы | устойчивые интересы, язык, регион, демография (агрегированно), категории кликов | стабильные предпочтения (тематика, язык, ценовой сегмент)
История (среднесрочный) | дни/недели | прошлые запросы и клики по темам, повторные визиты | тематический приор, возврат к ранее найденному
Сессия (краткосрочный) | минуты, текущая серия запросов | предыдущие запросы и клики в этой сессии, отказы, переформулировки | сиюминутный интент, дизамбигуация по контексту
Пример (сессионная дизамбигуация). Серия запросов в одной сессии: «питон установка» → «питон pip ошибка» → «питон». На третьем, коротком и неоднозначном запросе сессия уже однозначно говорит: интент — язык программирования, не змея. Система поднимает технические результаты, хотя сам запрос «питон» неоднозначен. Это и есть P(intent | q, c_session).
Архитектура: общий скор → персональный переранжерИнженерная заметка. Сессионные признаки должны вычисляться в реальном времени в пределах запроса: предыдущие запросы/клики сессии агрегируются в компактный контекст-вектор (темы, сущности, кликнутые домены) и подаются в переранжер. Бюджет — единицы миллисекунд, поэтому контекст держат в горячем хранилище сессии, а не пересчитывают из сырого лога.
Персонализацию почти никогда не вшивают в базовое ранжирование. Типовая развязка:
Код: Выделить всё
1. Базовый каскад (Модуль 12) выдаёт топ-N кандидатов
с ОБЩИМ скором score_base(d | q) — одинаковым для всех.
2. Персональный переранжер берёт эти N и пересортирует их,
добавляя персональные признаки:
score_pers(d | q, u, c) = score_base(d|q)
+ β(q,u) · Δ_pers(d | q, u, c)
где Δ_pers — персональный сдвиг, β — доверие к персонализации.
- Дёшево и безопасно. Переставить 50–100 кандидатов дёшево; персональный отбор из миллиардов — нет.
- Не теряем общерелевантное. Базовый каскад гарантирует, что в топ-N попали объективно релевантные документы; персонализация лишь меняет их порядок, не выдумывая своих.
- Управляемость. β(q, u) — единая «ручка силы»: на навигационных запросах β→0 (персонализацию глушим), на неоднозначных с богатой историей β выше.
Персональный сдвиг и довериеВнимание. β должна зависеть и от запроса, и от уверенности в пользователе. Сильная персонализация при бедных данных о пользователе или на запросе с ясным общим интентом — прямой путь к ухудшению выдачи. По умолчанию персонализация должна быть консервативной: лучше недо-персонализировать, чем выдать пользователю не то.
Δ_pers собирается из совпадений документа с профилем/историей/сессией: тематическое сходство с интересами, совпадение языка/региона предпочтений (связь с 18.1–18.2), кликал ли пользователь раньше этот домен, был ли документ уже посещён. Доверие β растёт с объёмом и свежестью данных о пользователе и падает с однозначностью запроса:
Код: Выделить всё
β(q, u) = g( 1 − P_navigational(q), # чем неоднозначнее — тем выше
data_richness(u), # чем больше истории — тем выше
freshness(u) ) # свежие сигналы важнее
Три большие проблемы персонализацииЗаблуждение. «Персонализация = заменить общий скор на персональный.» Нет. Персональный сигнал почти всегда аддитивная поправка к общему, с ограниченным влиянием. Заменять опасно: бедные/шумные персональные данные разрушат объективно хорошую общую выдачу.
(1) Разреженность и холодный старт. О новом пользователе (или в режиме инкогнито) система почти ничего не знает — персонализировать нечем. Решения: опираться на контурные дефолты (гео, язык — главы 18.1–18.2), на сессию (она есть всегда), на сегментные приоры (поведение похожих когорт), пока не накопится личная история. Холодный старт документа — зеркальная проблема: новый документ не имеет персональной обратной связи.
(2) Переобучение под пользователя (over-personalization). Если давить слишком сильно, система запирает пользователя в его прошлом: показывает только то, что он уже кликал, и перестаёт показывать новое и альтернативное. Это и продуктовая, и этическая проблема — прямой мост к «пузырю фильтров» (глава 18.4).
(3) Контур обратной связи (feedback loop). Самая коварная. Система персонализирует → пользователь кликает по поднятому → этот клик становится сигналом «ему это нравится» → система поднимает ещё сильнее. Возникает самоподтверждающаяся петля: модель учится на данных, которые сама же и сгенерировала. Без коррекции это сужает выдачу и закрепляет случайные ранние предпочтения как «истину».
Интуиция (feedback loop). Пользователь кликает по тому, что показали, а не по тому, что объективно лучшее. Если показали персонализированно, клик подтверждает персонализацию — даже если непоказанная альтернатива была бы лучше. Сигнал смещён предъявлением (presentation/position bias, Модуль 11), и наивное обучение на нём усиливает само себя.
Как измерять эффект персонализацииИнженерная заметка. Петлю разрывают: (1) исследованием (exploration) — иногда показывать не-персонализированные/новые результаты, чтобы собрать несмещённый сигнал; (2) коррекцией смещения предъявления при обучении (inverse-propensity weighting, контрфактическая оценка — связь с Модулем 11); (3) затуханием старых сигналов, чтобы прошлое не закреплялось навечно; (4) удержанием базового общего скора как якоря (архитектура переранжирования выше), не давая персонализации полностью оторваться от объективной релевантности.
Измерять трудно именно из-за смещения и петли:
- Онлайн A/B (Модуль 19) — золотой стандарт, но метрики надо брать на уровне сессии/долгого периода (удовлетворённость, доля успешных сессий, возвраты), а не сиюминутный CTR: персонализация легко «накручивает» клик, ухудшая исход.
- Офлайн на логах — только с коррекцией смещения предъявления (контрфактические оценки), иначе измеряем собственную петлю.
- Held-out пользователи / интерливинг — сравнение персонализированной и неперсонализированной выдачи на тех же пользователях устойчивее, чем сравнение между группами.
Заблуждение. «Рост CTR доказывает пользу персонализации.» CTR смещён предъявлением и петлёй: подняв то, что человек и так кликает, легко получить +CTR при нулевой или отрицательной пользе. Доказательство — улучшение исхода сессии/удержания, измеренное с коррекцией смещения.
Частые заблужденияSEO-врезка. Из-за персонализации «ваша» выдача не равна выдаче пользователя. Проверять позиции «как я вижу» бессмысленно: ваша история и регион искажают её. Используйте обезличенный/региональный замер, агрегированные данные о видимости из инструментов вебмастера, и понимайте, что для возвратных пользователей бренд, который они уже посещали, поднимается — то есть удержание аудитории влияет на видимость не только через прямой трафик.
Заблуждение. «Чем больше персонализации, тем лучше выдача.** Сверх меры персонализация переобучается, запирает в пузыре и портит навигационные/однозначные запросы. Польза немонотонна по силе β; оптимум — консервативный и зависящий от запроса.
Лаба / практикаЗаблуждение. «Персонализация заменяет общее ранжирование.» Она его переранжирует поверх общего скора в пределах топ-N, как аддитивная поправка с ограниченным доверием β, а не как самостоятельный источник кандидатов.
Дано: топ-10 кандидатов на неоднозначный запрос «питон» с score_base и тематической меткой (tech / animal); профиль пользователя interest=tech (0.8); сессия из двух предыдущих tech-запросов. (1) Постройте Δ_pers(d) как сходство темы документа с интересами/сессией. (2) Соберите score_pers = score_base + β·Δ_pers для трёх β (0, 0.3, 1.0) и сравните топы. (3) Смоделируйте один шаг feedback loop: пользователь кликает по поднятому tech-документу, увеличьте его персональный вес и пересортируйте. Опишите, как это сужает выдачу за 3 итерации. (4) Предложите механизм исследования, разрывающий петлю. Время ~60 мин. Критерий «сделано»: показан рост tech в топе с ростом β; продемонстрировано схлопывание разнообразия в петле; предложен и обоснован механизм exploration + якорь базового скора.
Контрольные вопросы
- Для каких типов запросов персонализация полезна, а для каких вредна? Почему она «разрешает остаточную неопределённость»?
- Опишите три горизонта персонализации и их сигналы. Почему сессия — самый сильный и безопасный?
- Почему персонализацию делают как переранжирование топ-N, а не как персональный отбор из индекса? Назовите три причины.
- Запишите разложение score_pers и объясните роль β(q,u). От чего она зависит?
- Что такое холодный старт пользователя и документа? Как с ним бороться?
- Объясните контур обратной связи на конкретном примере. Какими четырьмя приёмами его разрывают?
- Почему рост CTR не доказывает пользу персонализации? Как мерить правильно?
- Что такое over-personalization и как он связан с «пузырём фильтров»?
Цели обучения
После главы студент сможет:
- Сформулировать, где персонализация перестаёт помогать и начинает вредить пользователю и обществу.
- Объяснить эффект «пузыря фильтров» (filter bubble) и эхо-камеры и их механику через feedback loop (18.3).
- Перечислить приватные техники персонализации: агрегация, минимизация, on-device, дифференциальная приватность.
- Спроектировать механизмы прозрачности и контроля пользователя над персонализацией.
- Связать ограничения персонализации с этикой поиска (Модуль 21).
Две границы: приватность и искажение картины мира
Персонализация требует данных о человеке и меняет то, что он видит. Отсюда две принципиально разные группы рисков:
- Приватность. Чтобы персонализировать, надо собирать, хранить и обрабатывать историю запросов, кликов, мест — чувствительные данные, по которым реконструируется личность, здоровье, убеждения, перемещения.
- Искажение информационной картины (пузырь фильтров). Подстраиваясь под пользователя, система может перестать показывать то, что расширяет кругозор, оспаривает взгляды или просто отличается от прошлого — особенно опасно для спорных, политических, медицинских тем.
Пузырь фильтров и эхо-камераИнтуиция. Полезная персонализация снимает шум (показать кофейню рядом, язык программирования вместо змеи). Вредная — фильтрует содержание (показывать только согласные с тобой мнения, прятать альтернативы). Граница между «удобно» и «манипулятивно» проходит по тому, лишает ли персонализация пользователя выбора, который он бы сделал, зная о нём.
Пузырь фильтров (filter bubble) — состояние, когда персонализация (и поведенческое ранжирование, Модуль 11) систематически прячет от пользователя информацию, не совпадающую с его прошлым поведением и взглядами. Эхо-камера (echo chamber) — усиление этого эффекта обратной связью: пользователь видит и кликает согласное → система показывает ещё больше согласного → взгляд закрепляется.
Механика — прямой результат feedback loop из 18.3: без коррекции персонализация монотонно сужает разнообразие. Особенно вредно на запросах с общественной значимостью (новости, политика, здоровье), где доступ к разным точкам зрения — общественное благо, а не вопрос удобства.
Когда персонализацию надо ослаблять или выключатьВнимание. Степень эффекта — предмет научного спора: исследования показывают, что для большинства информационных запросов выдача разных людей пересекается куда сильнее, чем гласит сильная версия гипотезы, и что собственный выбор источников человеком влияет больше, чем алгоритм. Но направление риска бесспорно: непроверяемая персонализация без диверсификации сужает кругозор. Поэтому это инженерная задача, а не только философская.
Не все запросы равны. Разумная политика:
- Глушить β на навигационных и однозначных запросах (нечего разрешать).
- Ограничивать на запросах общественной значимости (новости, политика, здоровье): гарантировать разнообразие источников и точек зрения поверх персонализации — связь с диверсификацией (Модуль 15).
- Усиливать на явно «вкусовых» запросах (рецепты, развлечения, шопинг), где персональные предпочтения и есть интент.
- Всегда оставлять базовый общий скор как якорь (архитектура 18.3), чтобы выдача не отрывалась от объективной релевантности.
Приватные техники персонализацииЗаблуждение. «Раз пузырь фильтров вреден, персонализацию надо отключить вовсе.** Это другая крайность. Сессионная дизамбигуация, гео, язык — полезны и почти безвредны. Проблема не в персонализации как таковой, а в её бесконтрольном применении к содержательным/спорным темам без диверсификации и прозрачности.
Персонализировать, минимизируя риск приватности:
Код: Выделить всё
Техника | Идея | Цена
-----------------------------------------------------+-----------------------------------------------------------------------------------------------+----------------------------------
Минимизация данных | хранить только нужное, агрегированно, недолго | меньше сигнала
Агрегация/когорты | персонализировать по *группе* похожих, не по индивиду | грубее
On-device | хранить и применять профиль на устройстве пользователя; сервер видит лишь результат | сложнее, слабее серверной модели
Дифференциальная приватность (differential privacy) | добавлять калиброванный шум, чтобы по выходу нельзя было восстановить вклад одного человека | потеря точности на шум
Сессионность вместо профиля | использовать только текущую сессию, забывать после | нет долгосрочного приора
Анонимизация/псевдонимизация | разорвать связь сигналов с личностью | риск реидентификации
Инженерная заметка. Дифференциальная приватность даёт формальную гарантию: распределение выхода почти не меняется от наличия/отсутствия данных одного пользователя (параметр ε задаёт силу). Применяется при обучении моделей и сборе агрегированной статистики, а не к выдаче одного запроса. On-device персонализация (профиль и переранжер на клиенте) радикально снижает риск, но ограничена ресурсами устройства и сложнее в отладке.
Прозрачность и контроль пользователяВнимание. Режим «инкогнито»/без входа должен реально означать отсутствие долгосрочной персонализации, а не её видимость. Сессионная персонализация в нём допустима (она эфемерна), но профиль и история — нет. Несоответствие декларации и поведения — нарушение доверия и часто закона.
Этическая и во многих юрисдикциях правовая норма: пользователь должен знать о персонализации и управлять ею.
- Прозрачность. Объяснимость («показано, потому что вы недавно искали X»); пометка персонализированных блоков.
- Контроль. Переключатель персонализации; просмотр/удаление истории; режим без персонализации; управление категориями интересов.
- Дефолты. Консервативная персонализация по умолчанию; явное согласие на сбор чувствительных данных (правовое требование во многих юрисдикциях — связь с Модулем 21).
Частые заблужденияSEO-врезка. Персонализация и приватные режимы означают: (1) нет единой «объективной» выдачи — позиция зависит от пользователя, региона, истории; замеряйте обезличенно и агрегированно; (2) удержание и возвратность аудитории влияют на видимость у этих пользователей — то есть ценность бренда и лояльности конвертируется в видимость; (3) в режимах без персонализации (инкогнито, новые пользователи) работают контурные дефолты — гео и язык остаются главными управляемыми сигналами.
Заблуждение. «Пузырь фильтров — это просто паранойя, выдача у всех почти одинаковая.» Эмпирически сильная версия гипотезы переоценена, но направление риска реально: без диверсификации и коррекции петли персонализация монотонно сужает разнообразие, и на спорных темах это вредно. Отрицать риск так же неверно, как преувеличивать.
Лаба / практикаЗаблуждение. «Анонимизация = приватность.» Деанонимизация по совокупности признаков (история запросов — почти отпечаток личности) хорошо известна. Реальные гарантии дают минимизация, дифференциальная приватность и on-device, а не переименование идентификатора.
Дано: набор из 10 запросов с метками «навигационный / однозначный / вкусовой / общественно значимый» и профиль пользователя со склонностью к одной точке зрения. (1) Для каждого запроса назначьте политику персонализации (β высокий/низкий/ноль) и обоснуйте. (2) Для общественно значимого запроса спроектируйте механизм гарантии разнообразия точек зрения поверх персонализации (используйте идеи диверсификации из Модуля 15). (3) Опишите минимальный набор данных, который вам достаточно хранить, и предложите для него приватную технику (агрегация / on-device / DP / только сессия) с обоснованием цены. (4) Спроектируйте UI прозрачности и контроля (что показать и чем управлять). Время ~55 мин. Критерий «сделано»: политики согласованы с типами запросов; для спорной темы предусмотрена диверсификация; выбор приватной техники обоснован через trade-off; перечислены конкретные элементы прозрачности и контроля.
Контрольные вопросы
- Назовите две принципиально разные группы рисков персонализации и приведите пример каждой.
- Что такое пузырь фильтров и эхо-камера? Как они связаны с feedback loop из 18.3?
- На каких типах запросов персонализацию ослабляют или глушат и почему?
- Перечислите приватные техники персонализации и их цену. Чем on-device лучше серверной модели по приватности?
- Что гарантирует дифференциальная приватность и к чему она применяется (и к чему нет)?
- Почему анонимизация не равна приватности? Что такое реидентификация?
- Какие механизмы прозрачности и контроля должны быть у пользователя? Что должен реально означать режим инкогнито?
- Как связать ослабление персонализации на спорных темах с диверсификацией выдачи (Модуль 15)?
- Релевантность контекстна. На практике это свойство не пары (q, d), а тройки (q, d, u, c): запроса, документа, пользователя и контекста (место, время, язык, сессия). Локализация и персонализация — механизмы учёта u и c.
- Гео-релевантность — отдельная ось наряду с текстовой. Документ получает гео-профиль из множества сигналов (контент/адрес, домен, поведение, разметка), запрос — регион по убыванию явности (топоним → заданный регион → геолокация → история). Гео-релевантность — затухание с расстоянием/несоответствием, масштаб τ категориен; гео входит и в отбор (гео-индекс), и в LTR с весом, зависящим от P(local | q).
- Язык, страна и гео — три независимые оси. Контур (locale) — пара (язык, регион). Язык — чаще признак, чем жёсткий фильтр. Мультиязычные версии — не дубли: их связывают механизмом альтернатив (аналог hreflang) для выбора нужной версии и защиты от мнимого дублирования; межъязыковой поиск находит ответы на других языках через общее многоязычное пространство.
- Персонализация разрешает остаточную неопределённость, а не переписывает выдачу. Полезна на неоднозначных/возвратных/вкусовых запросах, вредна на навигационных и однозначных. Три горизонта — профиль, история, сессия; сессия — самый сильный и безопасный сигнал.
- Архитектурно персонализация — это переранжирование топ-N поверх общего скора как аддитивная поправка score_base + β·Δ_pers с управляемым доверием β(q,u), а не персональный отбор из индекса и не замена базового ранжирования. Базовый скор служит якорем.
- Три большие проблемы: разреженность/холодный старт, переобучение под пользователя и контур обратной связи (feedback loop). Петлю разрывают исследованием, коррекцией смещения предъявления, затуханием сигналов и удержанием базового якоря. CTR обманчив — мерить надо исход сессии с коррекцией смещения.
- Границы персонализации — приватность и пузырь фильтров. Приватность защищают минимизацией, агрегацией, on-device и дифференциальной приватностью. Сужение кругозора (особенно на спорных темах) ограничивают диверсификацией поверх персонализации (Модуль 15), прозрачностью и пользовательским контролем.
- Главное: локализация и персонализация мощны, но немонотонны по силе — оптимум консервативен и зависит от запроса; их нельзя оценивать по локальным метрикам (CTR), а только по полезности сессии и с учётом приватности и общественных эффектов (Модуль 21).
- Контекстная релевантность — релевантность как функция тройки (q, d, u, c): запрос, документ, пользователь, контекст.
- Гео-чувствительный (locally biased) запрос — запрос, ответ на который зависит от местоположения; гео-нейтральный — не зависит.
- P(local | q) — вероятность, что запросу нужен локальный ответ; модулятор веса гео-фактора.
- Гео-профиль документа — набор (geo_id, weight, confidence) региональных привязок документа; для бизнеса — ещё геокод (координаты).
- Геокодирование / разрешение топонимов (geocoding / toponym resolution) — сопоставление адреса/названия места координатам и узлу гео-онтологии с разрешением неоднозначности.
- Гео-затухание — убывание гео-релевантности с расстоянием/несоответствием, например exp(−dist/τ); τ — категорийный масштаб.
- Гео-индекс (geohash, S2/H3, R-дерево) — структура для быстрой выборки документов в географической области на стадии отбора.
- NAP-данные (Name–Address–Phone) — согласованные имя/адрес/телефон бизнеса по вебу как сигнал локальной привязки.
- Язык / страна / гео — три независимые оси контекста; их смешение — частая ошибка.
- Контур / локаль (locale) — рабочая пара (язык, регион), например de-CH.
- lang_fit / country_fit — компоненты соответствия документа языковым и страновым предпочтениям пользователя.
- Механизм альтернатив (аналог hreflang) — взаимные декларации языковых/страновых версий одного контента для выбора нужной версии и защиты от мнимого дублирования; x-default — запасная версия.
- Межъязыковой поиск (cross-lingual retrieval) — поиск документов на одном языке по запросу на другом, через перевод или общее многоязычное эмбеддинг-пространство.
- Персонализация — сдвиг ранжирования под пользователя для разрешения остаточной неопределённости интента.
- Горизонты персонализации — профиль (долгосрочный), история (среднесрочный), сессия (краткосрочный).
- Сессионная дизамбигуация — разрешение интента текущего запроса по предыдущим запросам/кликам той же сессии.
- Персональный переранжер — стадия, пересортирующая топ-N общего ранжирования по персональным признакам.
- score_pers = score_base + β·Δ_pers — разложение скора на общий компонент и персональную поправку; β(q,u) — доверие к персонализации.
- Холодный старт (cold start) — отсутствие данных о новом пользователе или новом документе для персонализации.
- Переобучение под пользователя (over-personalization) — чрезмерная персонализация, запирающая пользователя в его прошлом.
- Контур обратной связи (feedback loop) — самоусиление: система персонализирует → пользователь кликает по показанному → сигнал подтверждает персонализацию.
- Исследование (exploration) — намеренный показ не-персонализированных/новых результатов для сбора несмещённого сигнала и разрыва петли.
- Пузырь фильтров (filter bubble) — систематическое сокрытие от пользователя информации, не совпадающей с его прошлым поведением/взглядами.
- Эхо-камера (echo chamber) — усиление пузыря обратной связью: согласное закрепляется.
- Дифференциальная приватность (differential privacy) — формальная гарантия, что выход почти не зависит от данных одного пользователя; сила задаётся ε.
- On-device персонализация — хранение и применение профиля на устройстве пользователя без передачи на сервер.
- Реидентификация (re-identification) — восстановление личности по совокупности «обезличенных» признаков.
- Опирается на Модуль 5 (понимание запроса) — гео- и языковая привязка запроса, оценка P(local|q) и интента — продолжение классификации запросов; контекст превращает P(intent|q) в P(intent|q,u,c).
- Опирается на Модуль 12 (каскад ранжирования) — гео-, языковые и персональные сигналы входят как признаки LTR и как стадии отбора/переранжирования; overfetch и развязка «общий скор → персональный переранжер» — каскадные решения.
- Связан с Модулем 10 (нейропоиск) — общее многоязычное эмбеддинг-пространство для межъязыкового поиска; тематическое сходство для Δ_pers.
- Связан с Модулем 11 (поведенческие сигналы) — персонализация и feedback loop наследуют смещение предъявления/позиции; коррекция (inverse-propensity, контрфактика) общая.
- Связан с Модулем 3 (каноникализация) — мультиязычные версии нельзя схлопывать как дубли; механизм альтернатив дополняет каноникализацию.
- Связан с Модулем 15 (диверсификация) — диверсификация поверх персонализации — главный инструмент против пузыря фильтров.
- Связан с Модулем 19 (оценка и эксперименты) — эффект персонализации мерят на уровне сессии с коррекцией смещения, не по CTR.
- Перетекает в Модуль 16 (антиспам) — переспам топонимами и фальшивые гео/языковые сигналы — манипуляции, нейтрализуемые антиспамом.
- Перетекает в Модуль 21 (этика) — приватность, согласие, прозрачность, пузырь фильтров и общественная значимость — этический контур всего модуля.
- Классические и обзорные работы по геопоиску и локальной релевантности (geoparsing, toponym resolution, гео-индексы — geohash, S2, H3).
- Литература по многоязычному и межъязыковому информационному поиску (cross-lingual / multilingual IR, многоязычные эмбеддинги).
- Работы по персонализации поиска и контекстному ранжированию (сессионный контекст, дизамбигуация по истории).
- Литература по смещениям обратной связи и контрфактическому обучению ранжированию (presentation/position bias, inverse-propensity weighting, off-policy evaluation).
- Исследования эффекта «пузыря фильтров» и эхо-камер (включая критические эмпирические работы, оспаривающие сильную версию гипотезы).
- Материалы по приватности данных: дифференциальная приватность (определение через ε, федеративное обучение, on-device), минимизация и реидентификация.
- Обзоры по оценке персонализированного поиска (интерливинг, held-out пользователи, метрики уровня сессии).
