Обзор модуляЧасть IV · ~12 ч · Сложность: (продвинутый) · Пререквизиты: Модуль 9, Модуль 19
До сих пор мы извлекали сигналы релевантности из самих документов и связей между ними: текст (Модуль 6), ссылочный граф (Модуль 7), числовые и категориальные признаки, на которых учится каскад ранжирования (Модуль 8). У всех этих сигналов общая слабость — их производит автор или владелец ресурса, а значит, их можно подделать: набить ключевые слова, накупить ссылок, нарисовать разметку. Этот модуль про принципиально иной класс сигнала, источник которого — не робот и не вебмастер, а сам пользователь, его взаимодействие с выдачей. Поведенческие сигналы (behavioral signals) — это агрегированная статистика того, что люди делали, увидев результаты: на что кликали, как долго оставались на странице, возвращались ли назад, переформулировали ли запрос.
В сквозном конвейере «обход → индекс → факторы → ранжирование → выдача → постобработка → измерение» поведенческие сигналы занимают особое, замкнутое положение. Они рождаются на стадии выдачи и измерения — в логах взаимодействия (interaction logs), которые система пишет на каждый показ и каждый клик. Затем они проходят оффлайн-обработку (снятие смещений, агрегацию, затухание) и возвращаются обратно в каскад ранжирования как одни из самых весомых факторов. Получается петля обратной связи: ранжирование формирует выдачу → выдача порождает поведение → поведение переучивает ранжирование. Управление этой петлёй (и её патологиями) — центральная инженерная тема модуля.
Главный тезис, который нужно усвоить: поведение — самый весомый и одновременно самый трудно-подделываемый сигнал релевантности. Весомый — потому что миллионы независимых пользователей коллективно «голосуют» за то, что реально решает их задачу, а не за то, что хорошо оптимизировано. Трудно-подделываемый — потому что для накрутки нужно сымитировать не одну строку HTML, а правдоподобное массовое человеческое поведение, распределённое во времени, по устройствам и сетям. Но «трудно» не значит «невозможно»: существует целая индустрия накрутки поведенческих факторов, и борьба с ней — отдельная большая тема (Модуль 16). А поскольку источник сигнала — данные о реальных людях, модуль неизбежно упирается в этику и приватность (Модуль 21).
Как читать по трекамВнимание. Это продвинутый модуль ((продвинутый)). Главы 11.2–11.4 опираются на вероятностные модели и оценку из Модуля 9 (обучение ранжированию) и Модуля 19 (оценка, A/B). Если понятия «смещение оценки» (bias), «латентная переменная», «оценка максимального правдоподобия» для вас новы — вернитесь к нему. Без этого клик-модели в главе 11.3 будут выглядеть набором формул.
- Студент — обязательны главы 11.2 (CTR, dwell-time, position bias — фундамент) и 11.3 (клик-модели cascade/DBN, вывод смещения позиции). Глава 11.1 — на уровне идей (откуда берутся данные). Глава 11.4 — концептуально (зачем затухание и окна), без деталей потоковой инженерии.
- Инженер — всё обязательно. Особое внимание: инженерные заметки об атрибуции кликов, дедупликации показов, потоковых счётчиках, временных окнах и near-realtime в главе 11.4; численная устойчивость EM-обучения DBN в 11.3.
- SEO — главы 11.2 (что на самом деле измеряют CTR и dwell-time, что такое «короткий клик» и «возврат») и обязательно SEO-врезки про опасность накрутки поведенческих в 11.2 и 11.3. Глава 11.1 — чтобы понимать, какие данные о пользователе вообще доступны системе.
- Смешанный — последовательно весь модуль; формальный вывод EM в DBN можно бегло просмотреть при первом проходе.
- 11.1. Источники поведенческих данных — логи поиска, веб-аналитика, браузерные/тулбарные данные; что в них есть и чего нет. (средний)
- 11.2. Метрики взаимодействия — CTR, dwell-time, долгие/короткие клики, потери (losses), position bias. (продвинутый)
- 11.3. Клик-модели и снятие смещения — cascade, DBN; оценка вероятности релевантности; агрегации по запросу/URL/хосту/владельцу. (продвинутый)
- 11.4. Near-realtime и временная динамика — потоковые счётчики, окна (90/365/730+ дней), затухание (decay). (продвинутый)
Цели обучения
После главы студент сможет:
- Перечислить основные источники поведенческих данных и объяснить, какой тип взаимодействия фиксирует каждый.
- Различать данные «внутри выдачи» (on-SERP) и «вне выдачи» (post-click, on-site) и понимать, почему вторые видны системе лишь частично.
- Описать анатомию записи лога показа и клика: ключевые поля и их роль для последующей атрибуции.
- Оценить полноту, надёжность и приватностные риски каждого источника.
- Связать доступность источника с этическими и правовыми ограничениями (Модуль 21).
Прежде чем считать метрики и строить клик-модели, надо понять физику данных: откуда они берутся, что в них надёжно, а что — артефакт сбора. Поведенческий сигнал хорош ровно настолько, насколько чисты логи под ним.
Главный источник — лог взаимодействия с выдачей
Сердце поведенческой аналитики — журнал событий поисковой сессии (search interaction log). Это не «таблица кликов», а поток событий двух базовых типов:
- Показ (impression / view) — система отрисовала пользователю выдачу. Фиксируется что показали: список результатов с их позициями, тип каждого блока (органика, обогащённый блок (rich result), реклама), и контекст запроса.
- Клик (click) — пользователь нажал на конкретный результат.
Анатомия типичной записи (поля обобщены, без привязки к конкретной платформе):Интуиция. Ключевая мысль: клик бессмыслен без показа. «1000 кликов» — это много или мало? Зависит от того, было показов 1100 или 1 000 000. Поэтому система всегда логирует оба события и связывает их общим идентификатором показа. Именно пара «показ + (не)клик на позиции i» — атом поведенческого сигнала, а не клик сам по себе.
Код: Выделить всё
Поле | Назначение
------------------+---------------------------------------------------------------------------------------
impression_id | уникальный идентификатор одного показа выдачи; склеивает показ с последующими кликами
query_normalized | нормализованная форма запроса (после обработки из Модуля 5) — ключ агрегации
results[] | упорядоченный список: (url, позиция, тип_блока) для каждого результата
clicks[] | события клика: (позиция, url, timestamp_клика)
ts_serp | момент отрисовки выдачи
session_id | идентификатор сессии (цепочка действий одного пользователя)
context | регион, тип устройства (десктоп/мобайл), язык интерфейса
Что система видит на выдаче и что — после кликаИнженерная заметка. Показ и клик приходят разными событиями, часто с разной задержкой и по разным каналам (показ — при рендере, клик — по факту нажатия). Их атрибуция (связывание по impression_id) — нетривиальная задача: события могут теряться, дублироваться (повторная отправка при флаки-сети), приходить из кэша или из «назад» в браузере. Без аккуратной дедупликации и джойна вся последующая статистика поедет.
Принципиально разделять два пространства наблюдения:
- On-SERP (внутри выдачи). Здесь система — хозяин: она знает позиции, типы блоков, порядок и сам факт клика по своей ссылке. Это самый чистый и полный сигнал.
- Post-click / on-site (после ухода на сайт). Как только пользователь покинул выдачу и оказался на чужом домене, прямое наблюдение обрывается. Система не видит, что человек делал на странице. Она может лишь косвенно заключить о результате — главным образом по тому, вернулся ли пользователь на выдачу и через сколько (об этом — dwell-time и «короткие клики» в главе 11.2).
Дополнительные источники (и их ограничения)Заблуждение. «Поисковик видит всё, что я делаю на любом сайте.» Нет — из самой выдачи система напрямую наблюдает только клики по своим ссылкам и возвраты. Что происходит внутри чужого сайта, ей напрямую не видно, если только сам сайт добровольно не делится данными через сторонние инструменты (см. ниже) или пользователь не использует браузер/тулбар того же владельца. Это разделение — не только техническое, но и приватностное.
Помимо лога собственной выдачи, поведенческий сигнал может обогащаться из других источников. У каждого — своя зона видимости и свои риски:
- Веб-аналитика (web analytics). Счётчики, которые владельцы сайтов добровольно ставят к себе на страницы. Дают post-click картину (глубину просмотра, время на сайте) — но только для тех сайтов, что подключили счётчик, и только для тех пользователей, что не заблокировали трекинг. Сигнал смещён по выборке (не все сайты участвуют) и приватностно нагружен.
- Браузерные / тулбарные данные (browser / toolbar telemetry). Если у владельца поисковой системы есть собственный браузер или расширение, оно может (с согласия пользователя) сообщать о посещениях вне выдачи. Это закрывает «слепую зону» post-click, но это самый чувствительный источник с точки зрения приватности и регулирования.
- Сигналы операционной системы / приложений — для мобильного контекста: переходы между приложениями, установки. Узкоприменимы и сильно зарегулированы.
Этическая и приватностная оговорка (мост к Модулю 21)Внимание. Чем шире зона видимости источника, тем выше приватностный и правовой риск. Лог собственной выдачи — относительно «свой» периметр. Тулбарная телеметрия о хождении по всему вебу — данные, требующие явного согласия, минимизации, анонимизации и срока хранения. Все эти ограничения подробно разбираются в Модуле 21 (этика и приватность); здесь важно усвоить: доступность источника определяется не только техникой, но и правом и этикой.
Поведенческие сигналы — это данные о реальных людях, часто связанные с чувствительными темами (здоровье, финансы, ориентация, политические взгляды — всё это видно из запросов и кликов). Поэтому корректная работа с ними подчиняется набору принципов, которые мы лишь обозначим здесь, а раскроем в Модуле 21:
- Минимизация — собирать только то, что нужно для качества, и не дольше, чем нужно (отсюда — временные окна в главе 11.4).
- Агрегация и анонимизация — для ранжирования нужна статистика по запросу/URL, а не профиль конкретного человека; сигнал должен агрегироваться так, чтобы единичный пользователь не идентифицировался (k-анонимность, отсечение хвостов с малым числом наблюдений).
- Согласие и прозрачность — особенно для браузерных/тулбарных данных.
- Право на удаление и ограничение срока хранения.
Частые заблужденияИнженерная заметка. Принцип агрегации удобно совпадает с инженерной необходимостью: одиночное наблюдение «один человек кликнул» статистически бесполезно (шум), а агрегат «из 10 000 показов по запросу q на URL u кликнули 38%» — и приватнее, и информативнее. Хорошая поведенческая система почти никогда не оперирует индивидом — только распределениями.
Заблуждение. «Поведенческий сигнал — это просто счётчик кликов.» Клик без показа не интерпретируется. Сигнал — это всегда отношение (кликнули из скольких показов) с учётом позиции и контекста. Сырой счётчик кликов вводит в заблуждение в пользу того, что и так стоит наверху.
Лаба / практикаЗаблуждение. «Раз есть веб-аналитика, post-click поведение известно полностью.» Веб-аналитика покрывает лишь подмножество сайтов и пользователей и приватностно ограничена; для ранжирования произвольной выдачи основной post-click сигнал — это всё-таки возвраты на выдачу, а не внутренняя аналитика чужих сайтов.
Дан фрагмент лога: 20 записей показов (каждая — список из 10 результатов с позициями и типами блоков) и отдельный поток из 35 событий кликов с impression_id и позицией. В потоке кликов намеренно есть: 3 дубликата (одинаковый клик отправлен дважды), 2 «осиротевших» клика (нет соответствующего показа), 1 клик по рекламному блоку.
Шаги: (1) сджойнить клики к показам по impression_id; (2) дедуплицировать клики (по impression_id + позиция + временное окно ~1 c); (3) отбросить осиротевшие клики и пометить клики по рекламе отдельно (они не должны попасть в органический CTR); (4) для каждой позиции 1–10 посчитать клики/показы.
Ожидаемый результат: таблица CTR по позициям с монотонным (примерно) убыванием; объяснение, как дубликаты и сироты исказили бы CTR без очистки. Язык — любой (Python/псевдокод). Время ~50 мин. Критерий «сделано»: CTR по позициям совпал с эталоном после очистки; явно показано, на сколько процентных пунктов «сырой» CTR позиции 1 отличался от очищенного.
Контрольные вопросы
- Почему клик нельзя интерпретировать в отрыве от показа? Приведите пример, где «много кликов» означает плохой результат.
- Что такое зона post-click и почему она для системы частично «слепая»?
- Перечислите три источника поведенческих данных и расположите их по возрастанию приватностного риска. Обоснуйте порядок.
- Какие поля записи показа необходимы, чтобы позже снять смещение позиции? (вперёд к 11.2–11.3)
- Почему агрегация одновременно решает инженерную и приватностную задачу?
- Чем опасны дубликаты и «осиротевшие» клики для последующей статистики?
- Какой источник закрывает «слепую зону» post-click и какой ценой?
Цели обучения
После главы студент сможет:
- Определить CTR и dwell-time и объяснить, какой аспект удовлетворённости измеряет каждый.
- Различать «долгий» и «короткий» клик и связать короткий клик с понятием pogo-sticking и неудовлетворённости.
- Сформулировать, что такое потеря (loss) на выдаче и почему «отсутствие клика» — тоже сигнал.
- Объяснить механизм смещения позиции (position bias) и почему сырой CTR нельзя использовать как меру релевантности.
- Оценить, почему попытка накрутить эти метрики опасна и обнаружима (SEO-врезка).
В главе 11.1 мы получили чистые пары «показ + (не)клик». Теперь превратим их в метрики удовлетворённости — и сразу столкнёмся с главным врагом всех поведенческих сигналов: смещением позиции.
CTR: кликабельность
CTR (Click-Through Rate) результата на позиции — доля показов, в которых по нему кликнули:
Код: Выделить всё
CTR(u, i) = клики(u на позиции i) / показы(u на позиции i)
Dwell-time: время на результатеИнтуиция. CTR — это «насколько заманчиво выглядит дверь». Dwell-time — «насколько хороша комната за ней». Хороший результат должен пройти оба теста.
Dwell-time — время между кликом на результат и возвратом пользователя на выдачу (или следующим действием). Это лучший доступный системе прокси удовлетворённости post-click: если человек ушёл на страницу и долго не возвращается, вероятно, он нашёл, что искал.
Долгие и короткие клики, pogo-stickingЗаблуждение. «Dwell-time — это время на сайте, которое поисковик точно знает.» Система обычно не видит, что происходит на чужом сайте (глава 11.1). Она оценивает dwell-time косвенно — по интервалу до возврата на выдачу или до следующего клика в той же сессии. Если возврата не было вовсе — это сильный позитивный сигнал (задача, скорее всего, решена), хотя точную длительность система и не знает.
Различают два качественно разных исхода клика:
- Долгий клик (long click) — большой dwell-time или отсутствие возврата. Сигнал: результат удовлетворил.
- Короткий клик (short click) — пользователь почти сразу вернулся на выдачу. Сигнал: результат не удовлетворил (не то, обманул заголовок, плохая страница).
Пример. Запрос «как перезагрузить роутер модели X». Пользователь кликает результат №1 (форум с водой) — возвращается через 4 секунды (короткий клик). Кликает №3 (чёткая инструкция) — не возвращается 3 минуты (долгий клик / last satisfied click). Вывод системы: №3 решает задачу лучше №1, хотя №1 стоял выше. Накопив тысячи таких сессий, система получит основание поднять №3.
Потери (losses): отсутствие клика — тоже сигналИнженерная заметка. Порог «короткий/долгий» не универсален и зависит от класса запроса. Для навигационного запроса (нашёл нужный сайт за 5 секунд) короткое время на странице — это успех, а не провал. Для информационного лонгрида 5 секунд — провал. Поэтому пороги калибруют по типу запроса и интенту (Модуль 5), а не задают глобальной константой.
Важнейший и часто упускаемый класс сигналов — потери (losses): ситуации, когда поведение указывает на неудачу выдачи в целом, а не отдельного результата:
- Показ без клика (abandonment) — пользователю показали 10 результатов, он не кликнул ни по одному. Либо ответ был прямо в выдаче (good abandonment — например, ответ в обогащённом блоке), либо выдача бесполезна (bad abandonment).
- Переформулировка (query reformulation) — пользователь не кликнул (или кликнул и вернулся) и переписал запрос. Сильный сигнал, что выдача не решила задачу.
- Уход без удовлетворения — короткий клик по последнему опробованному результату и конец сессии без признаков успеха.
Position bias: главный враг сырого CTRИнтуиция. Клики говорят, что сработало. Потери говорят, что не сработало. Система, которая учится только на кликах, оптимизирует «куда тыкают», а не «где находят ответ». Потери — это негативные примеры, без которых модель переоценивает кликбейт.
Теперь — центральная проблема главы. Смещение позиции (position bias): пользователи кликают по верхним результатам чаще просто потому, что они верхние, а не потому, что они релевантнее. Внимание убывает сверху вниз; до нижних результатов многие даже не доходят (особенно на мобайле).
Формально вводят вероятность осмотра (examination probability) позиции i — P(осмотр | i). Базовая гипотеза экзаменации:Заблуждение. «Высокий CTR = высокая релевантность.» Нет. Позиция 1 почти всегда имеет высокий CTR — даже если поставить туда заведомо средний результат, он соберёт много кликов за счёт позиции. Сырой CTR смешивает релевантность и позиционную фору. Использовать его как фактор «в лоб» — значит закрепить текущий порядок: верхнее кликают → верхнее считается хорошим → верхнее остаётся верхним. Это самоподтверждающаяся петля (feedback loop).
Код: Выделить всё
P(клик | u, i) = P(осмотр | i) · P(клик | u осмотрен) = examination(i) · attractiveness(u)
Пример (числовой). Пусть examination(1) = 1.0, examination(5) = 0.3. Результат A на позиции 1 имеет CTR 0.40; результат B на позиции 5 имеет CTR 0.18. Сырой CTR: A лучше (0.40 > 0.18). Но снимем позицию: attractiveness(A) = 0.40/1.0 = 0.40, attractiveness(B) = 0.18/0.30 = 0.60. После debiasing B привлекательнее A — его просто реже видели. Вот почему сырой CTR обманчив.
Сводная таблица сигналовИнженерная заметка. Самый чистый способ оценить examination(i) — рандомизация: иногда (на малой доле трафика) перемешивать результаты или менять их местами и смотреть, как меняется CTR при той же релевантности. Если переставить два результата и их CTR «поменялись по позициям» — значит, разница была позиционной, а не релевантной. Контролируемая рандомизация даёт несмещённую оценку, но стоит немного качества выдачи, поэтому её дозируют (связь с A/B и интерливингом, Модуль 19).
Код: Выделить всё
Сигнал | Что измеряет | Знак | Подвох
----------------------+----------------------------------+--------+-------------------------------------------------
CTR | привлекательность сниппета | + | смещён позицией; ловит кликбейт
Dwell-time | удовлетворённость post-click | + | оценивается косвенно; зависит от класса запроса
Короткий клик / pogo | неудовлетворённость | − | порог зависит от интента
Abandonment | провал выдачи ИЛИ ответ в SERP | ±/− | надо отличать good от bad
Переформулировка | провал выдачи | − | бывает и углублением задачи
Частые заблужденияSEO-врезка. Раз поведение влияет на ранжирование, возникает соблазн его накрутить — заказать «клики на свой результат с нужного запроса» и «долгое нахождение на странице». Это крайне опасная стратегия по трём причинам. (1) Обнаружимость. Естественное поведение — это шумное, разнообразное распределение по тысячам реальных пользователей, устройств, сетей, времён суток и моделей курсора. Накрутка порождает аномалии: всплески кликов с узкого пула устройств/подсетей, неестественно стабильный dwell-time, отсутствие «потерь» и переформулировок, корреляции, которых у органики не бывает. Антиспам-системы (Модуль 16) ищут именно эти аномалии. (2) Самоликвидация сигнала. Можно нагнать кликов, но нельзя заставить тысячи реальных людей не возвращаться с плохой страницы — короткие клики и pogo-sticking разоблачат накрутку и могут утопить результат ниже исходного. (3) Санкции. Доказанная накрутка поведенческих — основание для жёсткого понижения хоста, иногда катастрофического. Единственная устойчивая стратегия — делать страницу, которая честно даёт долгий клик: отвечает на интент сразу, без кликбейта.
Заблуждение. «CTR — лучший фактор релевантности, ведь это голос пользователя.» CTR — голос за дверь, а не за комнату. Без dwell-time и снятия позиции он награждает кликбейт и закрепляет текущий топ.
Заблуждение. «Если по выдаче не кликнули — она плохая.» Не обязательно: ответ мог быть прямо в выдаче (good abandonment). Отличать good от bad abandonment — отдельная нетривиальная задача.
Лаба / практикаЗаблуждение. «Достаточно поднять время на странице, и позиции вырастут.» Время на чужом сайте система напрямую не видит; она видит возвраты. А устойчиво «не возвращать» пользователя нельзя накруткой — только реальным качеством.
Дан лог по одному запросу q: для 6 результатов известны позиции, число показов, число кликов и средний dwell-time до возврата, а также доля сессий, закончившихся переформулировкой. Дополнительно дана таблица оценок examination(i) для позиций 1–6 (получена рандомизацией).
Шаги: (1) посчитать сырой CTR каждого результата и ранжировать по нему; (2) снять позицию — поделить CTR на examination(i) — и переранжировать по attractiveness; (3) разметить клики на «короткие/долгие» по порогу, зависящему от класса запроса (дан класс — информационный, порог 30 c); (4) для каждого результата вычислить «долю долгих кликов» и итоговый поведенческий балл attractiveness · доля_долгих; (5) сравнить три ранжирования (по сырому CTR / по attractiveness / по итоговому баллу) и объяснить, какой результат «всплыл» и почему.
Ожидаемый результат: три разных порядка; явно показан результат, который выигрывает по сырому CTR (за счёт позиции и кликбейта), но проигрывает по итоговому баллу из-за коротких кликов. Время ~70 мин. Критерий «сделано»: итоговый порядок совпал с эталоном; письменно объяснено, как position bias и короткие клики изменили ранжирование.
Контрольные вопросы
- Что измеряет CTR и почему его недостаточно? Что добавляет dwell-time?
- Чем долгий клик отличается от короткого и что такое pogo-sticking?
- Почему «показ без клика» — не всегда плохой сигнал? Как отличить good от bad abandonment?
- Сформулируйте гипотезу экзаменации. Как из неё следует, что сырой CTR смешивает релевантность и позицию?
- На позиции 2 (examination=0.7) результат имеет CTR 0.21; на позиции 1 (examination=1.0) — CTR 0.27. Какой привлекательнее после снятия позиции?
- Почему рандомизация даёт несмещённую оценку examination и чем за неё платят?
- Назовите три причины, по которым накрутка поведенческих факторов опасна. Какая из них делает накрутку принципиально неустойчивой?
- Почему порог «короткий/долгий клик» зависит от класса запроса? Приведите пример, где короткое время — успех.
Цели обучения
После главы студент сможет:
- Сформулировать каскадную модель кликов (cascade model) и вывести из неё распределение позиции клика.
- Объяснить ограничения cascade и мотивировать переход к динамической байесовской сети (DBN).
- Записать генеративную модель DBN с параметрами привлекательности и удовлетворённости и понять идею её обучения (EM).
- Извлечь из обученной клик-модели несмещённую оценку релевантности результата как фактор ранжирования.
- Спроектировать иерархию агрегаций сигнала: запрос → URL → хост → владелец, и понимать роль каждого уровня.
Глава 11.2 поставила задачу: отделить релевантность от позиции. Клик-модели (click models) — это вероятностные генеративные модели поведения пользователя, которые формализуют, как рождается клик, и позволяют оценить латентную релевантность из массы наблюдений. Идём от простой модели к более точной.
Каскадная модель (cascade model)
Простейшая модель с явным учётом позиции. Гипотеза: пользователь просматривает результаты строго сверху вниз, и на каждом решает — кликнуть или идти дальше; после первого клика просмотр прекращается (модель одного клика).
Введём для результата на позиции i параметр привлекательности a_i = P(клик | осмотрен). Тогда пользователь:
- осматривает позицию 1; кликает с вероятностью a_1;
- если не кликнул (1 − a_1), осматривает позицию 2; кликает с a_2;
- и так далее.
Код: Выделить всё
P(клик на i) = a_i · Π_{j<i} (1 − a_j)
Ограничения cascade очевидны: (1) ровно один клик за сессию — нереалистично (бывают ноль кликов и много кликов); (2) нет понятия удовлетворённости — модель не различает долгий и короткий клик; (3) не моделирует продолжение просмотра после клика и возврат. Чтобы лечить эти болезни, переходят к DBN.Интуиция. Каскад объясняет position bias механизмом: нижние позиции осматриваются, только если все верхние не «зацепили». examination(i) = Π_{j<i}(1 − a_j) — вероятность дойти до i — естественно убывает с позицией. Смещение здесь не постулируется таблицей, а выводится из привлекательностей верхних результатов.
Динамическая байесовская сеть (DBN)
DBN (Dynamic Bayesian Network) — более выразительная модель, разделяющая привлекательность (захотел кликнуть) и удовлетворённость (понравилось после клика). Это прямая формализация различия «долгий/короткий клик» из 11.2.
Для пары (запрос q, документ u) вводят два латентных параметра:
- a_u — привлекательность (attractiveness): P(клик | результат осмотрен). Отвечает за сниппет.
- s_u — удовлетворённость (satisfaction): P(пользователь удовлетворён | кликнул). Отвечает за качество страницы; прокси — долгий клик.
Код: Выделить всё
E_1 = 1 # первую позицию осматривают всегда
для позиции i:
если E_i = 1 (осмотрена):
клик C_i ~ Bernoulli(a_i) # кликнул, если привлекло
если C_i = 1:
удовлетворён S_i ~ Bernoulli(s_i)
если S_i = 1: STOP # ушёл удовлетворённым — каскад обрывается
переход к i+1 осматривается с вероятностью:
E_{i+1} = 1 с вер. γ·(1 − C_i·s_i) # если кликнул и удовлетворён — не продолжит
Ключевая ценность: s_u — это и есть несмещённая оценка релевантности, очищенная и от позиции (через осмотр E), и от кликбейта (привлекательный, но неудовлетворяющий результат имеет высокое a, но низкое s). Именно s_u (или комбинацию a_u/s_u) подают в каскад ранжирования как поведенческий фактор.Интуиция. DBN рассказывает связную историю: человек идёт вниз; на каждом видимом результате может кликнуть (по привлекательности a); кликнув, может удовлетвориться (по s); удовлетворившись — уходит (конец просмотра). Короткий клик = кликнул, но не удовлетворился (s мало) → продолжил смотреть → возможен следующий клик (это и есть pogo-sticking!). Длинный клик в конце = удовлетворился → стоп. Так модель естественно объясняет и потери, и pogo, и многократные клики.
Обучение клик-модели (EM, кратко)Пример. Кликбейтный заголовок: a = 0.7 (часто кликают), s = 0.2 (почти все возвращаются). Скромный заголовок над отличной страницей: a = 0.3, s = 0.85. По сырому CTR победит первый. По удовлетворённости s — уверенно второй. DBN извлекает именно s, и ранжирование «лечится» от кликбейта.
Параметры a_u, s_u латентны — мы не наблюдаем осмотр и удовлетворённость напрямую, только клики и возвраты. Их оценивают EM-алгоритмом (Expectation–Maximization): на E-шаге по текущим параметрам считают апостериорные вероятности скрытых событий (был ли осмотр, был ли удовлетворён) для каждой сессии; на M-шаге пересчитывают a_u, s_u, максимизируя правдоподобие наблюдённых кликов. Итерируют до сходимости.
Иерархия агрегаций: запрос → URL → хост → владелецИнженерная заметка. На вебе число пар (q, u) колоссально, наблюдений на большинство пар мало. Поэтому: (1) EM считают распределённо, по сессиям; (2) для пар с малым числом показов оценки a_u, s_u сглаживают к приору (байесовское сглаживание / псевдонаблюдения), иначе один случайный клик даст a=1.0; (3) пары с числом показов ниже порога вообще не используют как фактор — недостоверно и приватностно рискованно (см. агрегации ниже). Численно следят за вырождением (нулевые/единичные оценки) — отсюда сглаживание обязательно.
Поведение разрежено: для конкретной пары (запрос, URL) наблюдений часто слишком мало, чтобы оценка была надёжной. Решение — иерархическая агрегация: считать сигнал на нескольких уровнях детализации и комбинировать их (backoff/сглаживание от частного к общему).
Код: Выделить всё
Уровень | Ключ агрегации | Что улавливает | Риск
------------------------+------------------+-------------------------------------------------+---------------------------
Запрос→URL | (q_norm, url) | точный сигнал «этот результат на этот запрос» | очень разрежён
Запрос→хост | (q_norm, host) | «этот сайт хорош по такому запросу» | теряет специфику страницы
URL (по всем запросам) | url | общее качество страницы | смешивает интенты
Хост / владелец | host / owner | репутация ресурса в целом | грубо, но плотно
Уровень владельца (owner) заслуживает отдельного слова: разные хосты могут принадлежать одному владельцу (Модуль 7 — определение владения), и репутацию (как позитивную, так и негативную — например, история накрутки) разумно распространять на весь владельческий кластер. Это и сглаживает сигнал для новых хостов владельца, и затрудняет уход от санкций через смену домена.Интуиция. Backoff как у языковых моделей (Модуль 6): если по (q, url) данных мало — опираемся на (q, host); если и там мало — на общий уровень хоста/владельца. Чем выше уровень агрегации, тем плотнее данные, но грубее сигнал. Финальный фактор — взвешенная смесь уровней, где вес растёт с числом наблюдений на уровне.
Внимание. Агрегация — также приватностный предохранитель. Никогда не используют сигнал по паре с числом наблюдений ниже порога k: единичные наблюдения и шумны, и потенциально деанонимизируют пользователя (особенно на редких запросах). Порог отсечения хвоста — одновременно про достоверность и про приватность (Модуль 21).
Частые заблужденияSEO-врезка. DBN объясняет, почему накрутка кликов даёт так мало: модель оптимизирует не клик (a), а удовлетворённость (s), которую дают только долгие клики и отсутствие возвратов. Накрутчик легко поднимает a (нагнал кликов), но s падает (боты/мотивированные исполнители не имитируют реальную удовлетворённость и часто возвращаются) — итоговый сигнал может стать отрицательным. Плюс иерархия по владельцу означает: пойманную на накрутке историю переносят на все хосты владельца, а не на один URL. Накрутка масштабируется в минус.
Заблуждение. «Клик-модель просто считает CTR поумнее.» Нет: cascade и особенно DBN — это генеративные модели процесса просмотра с латентными переменными. Их выход — не сглаженный CTR, а оценка вероятности релевантности (s), очищенная от позиции и кликбейта.
Заблуждение. «Каскадная модель достаточно хороша.» Она ломается на нуле и множестве кликов и не различает долгий/короткий клик — то есть не отделяет привлекательность от удовлетворённости. Для ранжирования нужен именно этот развод, который даёт DBN.
Лаба / практикаЗаблуждение. «Сигнал надо считать как можно детальнее — по точной паре запрос-URL.» На точной паре данных почти всегда мало; без агрегации и сглажения оценка — шум. Иерархия уровней обязательна.
Дан синтетический генератор сессий с известными истинными a_u и s_u для 5 документов по одному запросу (истинные значения скрыты от обучения). Генератор симулирует поведение пользователя по правилам DBN.
Шаги: (1) сгенерировать 50 000 сессий; (2) реализовать упрощённый EM для оценки a_u, s_u (E-шаг: апостериорные вероятности осмотра/удовлетворённости; M-шаг: пересчёт параметров; сглаживание псевдонаблюдениями α=1); (3) сравнить восстановленные a,s с истинными; (4) показать, что ранжирование по s ближе к истинному порядку релевантности, чем ранжирование по сырому CTR; (5) дополнительно: уменьшить число сессий до 200 и продемонстрировать, как без сглаживания оценки вырождаются (a или s уходят в 0/1).
Ожидаемый результат: восстановленные s коррелируют с истинными (например, корреляция Спирмена > 0.9 на большом наборе); ранжирование по s совпадает с истинным, а по сырому CTR — нет (кликбейтный документ с высоким a, низким s уезжает вниз). Время ~120 мин. Критерий «сделано»: EM сходится, корреляция достигнута, продемонстрирован эффект сглаживания на малой выборке.
Контрольные вопросы
- Сформулируйте каскадную модель. Как из неё выводится examination(i)?
- Назовите три ограничения cascade и объясните, какое из них критично для различения кликбейта.
- Что означают параметры a_u и s_u в DBN? Какой из них — несмещённая оценка релевантности и почему?
- Как DBN объясняет pogo-sticking в терминах своих параметров?
- Почему параметры клик-модели латентны и при чём тут EM? Что делает E-шаг, что — M-шаг?
- Зачем сглаживать оценки и что произойдёт без сглаживания на паре с 3 показами?
- Опишите иерархию агрегаций. Зачем нужен уровень владельца и как он мешает уходу от санкций?
- Почему DBN делает накрутку кликов малоэффективной и даже вредной для накрутчика?
Цели обучения
После главы студент сможет:
- Различать оффлайн-, near-realtime- и realtime-обработку поведенческих сигналов и обосновать выбор для разных задач.
- Спроектировать потоковые счётчики показов/кликов на скользящих временных окнах.
- Объяснить, зачем нужны несколько окон (90/365/730+ дней) и какой запрос обслуживает каждое.
- Реализовать экспоненциальное затухание (time decay) и связать его постоянную с «полупериодом» сигнала.
- Оценить компромиссы свежесть–стабильность и инженерные ограничения потоковой агрегации.
Поведенческий сигнал не статичен: вкусы меняются, появляются новые страницы, всплывают сезонные и событийные запросы, устаревают старые ответы. Эта глава — про временную динамику: как считать сигнал так, чтобы он был одновременно свежим (реагировал на новое) и стабильным (не дрожал от шума), и как доставлять его в ранжирование с приемлемой задержкой.
Три режима по задержке
- Оффлайн (batch). Тяжёлые модели (EM для DBN из 11.3, иерархические агрегации) считают пакетно — раз в часы/сутки. Точно, но «вчерашним днём».
- Near-realtime (NRT). Потоковая обработка событий с задержкой от секунд до минут. Поддерживает «живые» счётчики и инкрементальные обновления.
- Realtime. Учёт сигнала прямо в момент запроса (например, в пределах сессии). Самый дорогой, применяется точечно.
Интуиция. Аналогия с термометрами: оффлайн — точный лабораторный замер раз в день; NRT — комнатный термометр, обновляющийся каждую минуту; realtime — рука на лбу прямо сейчас. Качественной системе нужны все три: оффлайн даёт точность, NRT — свежесть, realtime — реактивность на горячее.
Потоковые счётчики на скользящих окнахПример. Внезапное событие: запрос q резко набирает популярность, появляется свежая авторитетная страница. Оффлайн-сигнал её ещё «не знает» (она новая, статистики ноль). NRT-счётчики уже видят всплеск показов/кликов и могут временно поднять её, пока batch-модель не пересчитается. Без NRT система реагировала бы на новости с суточным лагом.
Базовый строительный блок — счётчики показов и кликов по ключам агрегации ((q,url), (q,host), url, host, owner из 11.3) на скользящем временном окне (sliding window). Концептуально для каждого ключа поддерживают пару (показы, клики) за окно, обновляя их по потоку событий и истекая старые.
Зачем несколько окон: 90 / 365 / 730+ днейИнженерная заметка. Хранить все события за 730 дней, чтобы вычесть истёкшие, — непозволительно дорого. Стандартный приём — дробление окна на бакеты (time buckets): храним посуточные (или почасовые) агрегаты (показы, клики) на ключ. Окно за 90 дней — сумма последних 90 суточных бакетов; «сдвиг окна» = добавить новый бакет, выкинуть старейший. Это O(числобакетов) памяти на ключ вместо O(числособытий). Для приближённых уникальных счётчиков (уникальные пользователи) применяют вероятностные структуры (HyperLogLog), а для частот — Count–Min Sketch; это экономит память ценой контролируемой ошибки.
Разные окна обслуживают разные потребности, поэтому считают сразу несколько:
Код: Выделить всё
Окно | Свойство | Для чего
----------------------+-----------------------------------------------------+--------------------------------------------------------
Короткое (~90 дней) | свежее, реактивное, но шумное и сезонно-смещённое | свежие страницы, тренды, быстрые сдвиги интента
Среднее (~365 дней) | сглаживает сезонность (полный год) | устойчивый сигнал, нивелирующий праздники/сезоны
Длинное (~730+ дней) | стабильное, плотное, медленно меняется | редкие запросы, долгосрочная репутация хоста/владельца
Интуиция. Короткое окно — «что популярно сейчас». Длинное — «что хорошо всегда». Для частого запроса с богатой статистикой можно опираться на свежее окно; для редкого запроса в коротком окне данных нет — приходится брать длинное. Финальный фактор часто — комбинация окон, где вес свежего окна растёт с плотностью данных в нём (та же логика backoff, что и с иерархией ключей в 11.3, но по оси времени).
Затухание (time decay)Внимание. Длинные окна конфликтуют с приватностным принципом минимизации хранения (Модуль 21): хранить поведение 2+ года надо обоснованно, в агрегированной/обезличенной форме, с политикой удаления. Длина окна — это не только инженерное, но и этико-правовое решение.
Жёсткие окна имеют грубый недостаток: событие 89-дневной давности учитывается полностью, а 91-дневной — выбрасывается целиком (обрыв на границе). Мягкая альтернатива — экспоненциальное затухание (exponential decay): вес наблюдения убывает с возрастом плавно.
Вес события возраста Δt (например, в днях):
Код: Выделить всё
w(Δt) = exp(−λ · Δt) = (1/2)^(Δt / T½)
Код: Выделить всё
score = Σ_событий exp(−λ · (now − t_события))
Интуиция. Half-life отвечает на вопрос «насколько быстро забываем». T½ = 7 дней — очень реактивный сигнал (для трендов); T½ = 180 дней — инерционный (для репутации). Это непрерывный аналог выбора длины окна: маленький half-life ≈ короткое окно, большой ≈ длинное.
Инженерная заметка. Затухающую сумму можно обновлять инкрементально, без перебора истории. Если хранить (score, t_last), то при новом событии в момент t_now:
Код: Выделить всё
score ← score · exp(−λ · (t_now − t_last)) + 1
t_last ← t_now
Компромисс свежесть ↔ стабильность
Это центральная дилемма всей главы. Малый half-life / короткое окно → сигнал свеж, но шумен и подвержен накрутке всплеском (нагнали кликов за день — фактор скакнул). Большой half-life / длинное окно → сигнал устойчив и трудно-накручиваем, но инертен (медленно признаёт реально улучшившуюся страницу).
Заблуждение. «Чем свежее сигнал, тем лучше.» Свежесть повышает реактивность, но и уязвимость к накрутке: короткое окно легче «залить» искусственным всплеском. Длинные окна и большие half-life — естественный антиспам-демпфер: чтобы сдвинуть двухлетний агрегат, нужно поддерживать аномалию долго, что и дорого, и заметно (Модуль 16). Выбор горизонта — это всегда баланс реактивности и устойчивости к манипуляции, а не «чем быстрее, тем лучше».
Частые заблужденияИнженерная заметка. Near-realtime контур обычно даёт поправку к стабильному оффлайн-сигналу, а не заменяет его: финальный фактор = надёжный длинный агрегат + ограниченная сверху NRT-поправка. Это сохраняет реактивность на горячее, но не даёт короткому шумному окну (или всплеску накрутки) полностью перевесить долгую историю.
Заблуждение. «Окно — это буфер всех событий за N дней.» Сырые события не хранят; держат посуточные бакеты-агрегаты или затухающие счётчики. Иначе память и приватность неуправляемы.
Заблуждение. «Затухание и окно — это одно и то же, выбор стилистический.» Окно обрывает вклад скачком на границе; затухание убирает его плавно и обновляется инкрементально за O(1). Это разные инструменты с разными свойствами; их часто комбинируют.
Лаба / практикаЗаблуждение. «Realtime всегда лучше batch.» Realtime дорог и шумен; тяжёлые клик-модели (DBN) считаются оффлайн. NRT/realtime — лишь свежий контур поверх точного оффлайн-сигнала.
Дан поток из ~200 000 событий показов/кликов за 800 дней по нескольким (q,url) ключам, включая: один ключ со стабильным CTR, один «новый» ключ, появившийся на 750-й день с резким всплеском, и один ключ с искусственным однодневным всплеском кликов (имитация накрутки).
Шаги: (1) построить посуточные бакеты (показы, клики); (2) вычислить CTR-фактор на окнах 90/365/730 дней для каждого ключа на каждый день; (3) реализовать затухающие счётчики с T½ = 14 и T½ = 180 дней (инкрементальное O(1) обновление); (4) построить графики «фактор во времени» для всех вариантов; (5) показать на графиках: новый ключ виден в окне-90 / T½=14 намного раньше, чем в окне-730 / T½=180; однодневный всплеск накрутки сильно дёргает короткий горизонт, но почти не двигает длинный.
Ожидаемый результат: визуальная и численная демонстрация компромисса свежесть↔стабильность; вывод, какой горизонт выбрать для трендового запроса, а какой — для устойчивой репутации; объяснение, почему длинный горизонт демпфирует накрутку. Время ~110 мин. Критерий «сделано»: графики воспроизводят ожидаемое поведение; письменно сформулирован выбор горизонта и его связь с устойчивостью к накрутке.
Контрольные вопросы
- Чем отличаются оффлайн-, near-realtime- и realtime-режимы? Какую задачу решает каждый?
- Почему сырые события не хранят, а держат суточные бакеты? Как из бакетов получить окно за 90 дней?
- Зачем считать сразу несколько окон (90/365/730+)? Какой запрос обслуживает каждое?
- Что такое период полураспада (half-life) и как он связан с постоянной λ? Чему соответствует малый и большой half-life?
- Запишите инкрементальное O(1)-обновление затухающего счётчика. В чём его преимущество над бакетами?
- Сформулируйте компромисс свежесть↔стабильность. Почему длинный горизонт устойчивее к накрутке?
- Почему NRT-контур делают поправкой к оффлайн-сигналу, а не заменой? Что это даёт против накрутки всплеском?
- Как длина окна связана с приватностным принципом минимизации хранения (Модуль 21)?
- Поведенческие сигналы — агрегированная статистика взаимодействия реальных пользователей с выдачей. Их источник — не робот и не вебмастер, а логи взаимодействия; это делает их самым весомым и самым трудно-подделываемым классом сигналов релевантности.
- Клик бессмыслен без показа. Атом сигнала — пара «показ + (не)клик на позиции i», а не сырой счётчик кликов. Система чисто видит on-SERP поведение и лишь косвенно (через возвраты) — post-click.
- CTR измеряет привлекательность сниппета (обещание), dwell-time — удовлетворённость post-click (выполнение). Долгий клик = успех, короткий клик / pogo-sticking = провал. Потери (abandonment, переформулировка) — негативные сигналы, без которых модель награждает кликбейт.
- Position bias — главный враг: верхнее кликают чаще из-за позиции. Сырой CTR смешивает релевантность и позиционную фору и закрепляет текущий топ. Гипотеза экзаменации клик = examination(i)·attractiveness(u) формализует развод этих эффектов; рандомизация даёт несмещённую оценку осмотра.
- Клик-модели оценивают латентную релевантность. Cascade выводит position bias из механизма «сверху вниз до первого клика», но не различает долгий/короткий клик. DBN разделяет привлекательность a и удовлетворённость s; именно s — несмещённая оценка релевантности, очищенная от позиции и кликбейта. Параметры латентны и оцениваются EM со сглаживанием.
- Иерархическая агрегация запрос→URL→хост→владелец лечит разрежённость (backoff к более общему уровню) и распространяет репутацию (в т.ч. негативную) на владельческий кластер. Отсечение хвостов с малым числом наблюдений — одновременно про достоверность и приватность.
- Временная динамика: оффлайн (точность) + near-realtime (свежесть) + realtime (реактивность). Несколько окон (90/365/730+) и экспоненциальное затухание (half-life) балансируют свежесть и стабильность; затухающий счётчик обновляется инкрементально за O(1).
- Главное про манипуляцию: накрутить можно a (клики), но не s (удовлетворённость) — реальных людей нельзя заставить не возвращаться с плохой страницы. Длинные горизонты демпфируют всплески, иерархия по владельцу мешает уходу от санкций, а аномалии накрутки обнаружимы (Модуль 16). Единственная устойчивая стратегия — честно зарабатывать долгий клик.
- Поведенческий сигнал (behavioral signal) — агрегированная статистика взаимодействия пользователей с выдачей, используемая как фактор ранжирования.
- Лог взаимодействия (interaction log) — поток событий показов и кликов поисковой сессии.
- Показ (impression) — событие отрисовки выдачи пользователю; контекст для интерпретации кликов.
- Атрибуция (attribution) — связывание событий клика с событием показа по общему идентификатору.
- On-SERP / post-click — поведение внутри выдачи (полностью видимо системе) / после ухода на сайт (видимо лишь косвенно).
- CTR (Click-Through Rate) — доля показов результата, завершившихся кликом по нему; мера привлекательности сниппета.
- Dwell-time — время от клика до возврата на выдачу; косвенный прокси удовлетворённости post-click.
- Долгий / короткий клик (long / short click) — клик с большим dwell-time (удовлетворил) / с быстрым возвратом (не удовлетворил).
- Pogo-sticking — паттерн быстрых возвратов и повторных кликов; явная неудовлетворённость верхними результатами.
- Потеря (loss) — поведение, указывающее на неудачу выдачи в целом: abandonment, переформулировка, уход без удовлетворения.
- Abandonment (показ без клика) — отсутствие кликов; бывает good (ответ в выдаче) и bad (бесполезная выдача).
- Position bias (смещение позиции) — завышение кликов по верхним результатам из-за их позиции, а не релевантности.
- Гипотеза экзаменации (examination hypothesis) — P(клик)=P(осмотр|позиция)·P(клик|осмотрен); разделяет позицию и привлекательность.
- Снятие смещения (debiasing) — отделение релевантности от позиционного эффекта в наблюдаемых кликах.
- Cascade model (каскадная модель) — клик-модель «осмотр сверху вниз до первого клика»; выводит position bias из привлекательностей.
- DBN (Dynamic Bayesian Network) — клик-модель, разделяющая привлекательность a и удовлетворённость s.
- Привлекательность (attractiveness) a — P(клик | осмотрен); зависит от сниппета.
- Удовлетворённость (satisfaction) s — P(удовлетворён | кликнул); несмещённая оценка релевантности.
- EM (Expectation–Maximization) — итеративный метод оценки латентных параметров клик-модели по наблюдённым кликам.
- Иерархическая агрегация (запрос→URL→хост→владелец) — счёт сигнала на нескольких уровнях детализации с backoff от частного к общему.
- Уровень владельца (owner) — агрегация по владельцу нескольких хостов; распространяет репутацию и мешает уходу от санкций сменой домена.
- Near-realtime (NRT) — потоковая обработка с задержкой секунды–минуты; свежий контур поверх оффлайн-сигнала.
- Скользящее окно (sliding window) — агрегат за последние N дней, реализуемый суточными бакетами.
- Time bucket (бакет) — посуточный/почасовой агрегат (показы, клики); единица хранения окон.
- Экспоненциальное затухание (exponential decay) — плавное убывание веса наблюдения с возрастом, w=exp(−λΔt).
- Период полураспада (half-life) T½ — время, за которое вклад наблюдения падает вдвое; T½=ln2/λ.
- Опирается на Модуль 9 (learning-to-rank) и Модуль 19 (оценка и эксперименты) — обучение ранжированию, оценка и смещения; поведенческие сигналы — мощные входы каскада, а debiasing — частный случай борьбы со смещением оценки.
- Опирается на Модуль 5 (понимание запроса) — классы/интенты запросов задают пороги «короткий/долгий клик» и нормализацию ключей агрегации.
- Продолжает Модуль 7 (ссылочный граф) — поведенческие сигналы — это куда перетёк ранжирующий вес после деградации легко-подделываемых ссылок; уровень «владельца» использует определение владения оттуда.
- Тесно связан с Модулём 16 (антиспам) — накрутка поведенческих факторов и её обнаружение по аномалиям; длинные горизонты и иерархия владельца — структурные демпферы манипуляции.
- Питает Модуль 19 (оценка и эксперименты / A/B) — рандомизация и интерливинг для несмещённой оценки осмотра; логи взаимодействия — общая инфраструктура.
- Обязательно дополняется Модулём 21 (этика и приватность) — минимизация, согласие, анонимизация, агрегация, сроки хранения и удаление; длина окна и порог отсечения хвостов — этико-правовые решения, а не только инженерные.
- Классические работы по клик-моделям веб-поиска (каскадная модель, модель зависимого клика, динамическая байесовская сеть): генеративные постановки и сравнение качества предсказания кликов.
- Литература по position bias и несмещённому обучению ранжированию (unbiased learning-to-rank): inverse propensity weighting, оценка propensity через рандомизацию и интервенции.
- Обзоры по интерпретации сигналов удовлетворённости (dwell-time, satisfied clicks, good/bad abandonment) и их связи с метриками качества.
- Работы по оценке latent-параметров методом EM и байесовскому сглаживанию разрежённых счётчиков.
- Инженерная литература по потоковой обработке: оконные агрегации, скетчи (HyperLogLog, Count–Min Sketch), экспоненциально-затухающие статистики.
- Обзоры по адверсариальному поведению в поиске (click fraud, накрутка поведенческих факторов) и методам его обнаружения.
- Материалы по приватности поисковых логов: анонимизация, k-анонимность, минимизация и сроки хранения (в связке с Модулем 21).
