Как Google создает интерфейс для построения сложных цепочек фильтрации документов (конвейерных запросов)

Термины и определения

BOOL OP (Булев оператор)

Логический оператор (например, AND, OR), используемый для объединения нескольких критериев в рамках одного этапа фильтрации или нескольких источников.

Discard (Исключить)

Тип операции фильтрации, который удаляет из набора документы, соответствующие указанным критериям.

E-discovery (Электронная обработка данных)

Процесс идентификации, сбора и предоставления информации, хранящейся в электронном виде (ESI), в ответ на запрос в рамках юридического дела или расследования.

Keep (Оставить)

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

NAMED (Именованный результат)

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

Pipeline (Конвейер / Конвейерный запрос)

В контексте патента — сохраненный именованный запрос или набор результатов, который может быть использован как источник данных (SOURCE) для последующих запросов.

Search-op (Оператор поиска)

Конкретный критерий фильтрации, применяемый к документам (например, from-account, file-type, created-before, contains).

SOURCE (Источник)

Начальный корпус документов, к которому применяется запрос (например, all data, account, pipeline, external).

TYPE (Тип операции)

Действие, выполняемое на этапе фильтрации (KEEP, DISCARD) или на этапе сохранения результата (NAMED).

Ключевые утверждения (Анализ Claims)

Патент фокусируется на методологии фильтрации и пользовательском интерфейсе, а не на алгоритмах поиска.

Claim 1 (Независимый пункт): Описывает компьютерный метод фильтрации корпуса документов, релевантных для судебного разбирательства (litigation).

1. Идентификация корпуса документов.
2. Генерация первого модифицируемого запроса (Q1).
3. Фильтрация корпуса в первый набор результатов (RS1).
4. Присвоение первого имени (Name 1) первому набору результатов RS1.
5. Генерация второго модифицируемого запроса (Q2).
6. Фильтрация RS1 с помощью Q2 для генерации второго набора результатов (RS2). Ключевой момент: это включает использование RS1 (указанного по имени Name 1) как источника документов для Q2.
7. Присвоение второго имени (Name 2) второму набору результатов RS2.
8. Маркировка (labeling) элементов RS2 именем Name 2. Маркировка позволяет представить Q1 и Q2 в ответ на выбор пользователя (например, клик по метке для аудита).
9. Определение изменения в Q1 или Q2.
10. Автоматическое обновление RS2 без дополнительного участия пользователя в ответ на это изменение.

Claim 6 (Независимый пункт): Описывает систему (инструмент/интерфейс) для представления истории фильтрации пользователю.

1. Система включает несколько областей отображения (display areas): для показа исходного корпуса документов, первого запроса (Q1), второго запроса (Q2) и именованного результирующего набора (RS2).
2. Каждый элемент результирующего набора маркируется меткой с именем набора, позволяющей показать Q1 и Q2 по выбору пользователя.
3. Наборы результатов включают ссылки на документы, которые хранятся на множестве клиентов (plurality of clients) — указание на распределенную файловую систему или облачное хранилище.
4. Система настроена на определение изменений в Q1 или Q2 и автоматическое обновление результирующего набора без участия пользователя.

Где и как применяется

Важно отметить: этот патент не описывает компоненты архитектуры публичного веб-поиска Google (CRAWLING, INDEXING, RANKING и т.д.). Он описывает технологию пользовательского интерфейса (UI) и связанную с ним логику обработки запросов в специализированных приложениях.

Область применения:

• Системы электронной обработки данных (E-discovery).
• Программное обеспечение для юридического анализа документов (Document Review Software).
• Внутренние инструменты управления данными или системы архивирования (например, Google Vault).

Как это работает в системе:

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

Входные данные:

• Исходный корпус документов (например, данные аккаунтов, импортированные данные).
• Параметры фильтрации, введенные пользователем через UI (ключевые слова, диапазоны дат, типы файлов).
• Идентификаторы существующих конвейерных запросов (Pipelines).

Выходные данные:

• Результирующий набор документов (Result Set), соответствующий всем критериям конвейера.
• Метки (Labels), присвоенные этим документам, содержащие информацию о том, какой запрос их обнаружил.

На что влияет

• Типы контента: Влияет на способность пользователей фильтровать любые типы электронных документов (электронная почта, текстовые документы, таблицы, презентации) в рамках той системы, где этот интерфейс реализован.
• Специфические запросы: Облегчает выполнение сложных, многоступенчатых запросов для анализа данных.

Патент не влияет на ранжирование сайтов в публичном веб-поиске Google.

Когда применяется

Алгоритм применяется в следующих условиях:

• Когда пользователь вручную создает новый запрос (Pipeline) для фильтрации набора документов.
• Когда пользователь использует существующий Pipeline как источник для нового запроса.
• Когда пользователь модифицирует существующий запрос. Это служит триггером для автоматического обновления всех зависимых запросов.

Пошаговый алгоритм

Процесс А: Создание базового конвейерного запроса

1. Выбор источника: Пользователь выбирает начальный набор документов. Это может быть all data, конкретный account (или несколько аккаунтов, объединенных через OR/AND), или external данные.
2. Установка критериев фильтрации (Этап 1): Пользователь добавляет первую колонку фильтра.
   1. Выбирается тип операции: KEEP (оставить соответствующие) или DISCARD (исключить соответствующие).
   2. Определяются критерии поиска (Search-op) и параметры (например, contains: fair).
   3. Если критериев несколько, они объединяются булевым оператором (AND или OR).
3. Установка дополнительных критериев (Этап N): Пользователь может добавить следующие колонки фильтрации. Каждая следующая колонка обрабатывает набор данных, полученный на предыдущем этапе.
4. Сохранение результата: Пользователь добавляет финальную колонку (Destination). Выбирается тип операции NAMED, и вводится имя для итогового набора результатов (например, "fair_use").

Процесс Б: Создание вложенного (зависимого) запроса

1. Выбор источника: Пользователь выбирает в качестве источника существующий pipeline, указав его имя (например, "fair_use").
2. Установка критериев фильтрации: Добавляются новые этапы фильтрации (KEEP/DISCARD), которые применяются к результатам исходного конвейера.
3. Сохранение результата: Результат сохраняется под новым именем (например, "video_fair_use").

Процесс В: Модификация и автоматическое обновление

1. Модификация запроса: Пользователь изменяет критерии в одном из существующих запросов (например, добавляет новый аккаунт в источники запроса "fair_use").
2. Определение зависимостей: Система определяет все другие запросы, которые используют измененный запрос в качестве источника (например, "video_fair_use").
3. Автоматическое обновление: Система автоматически пересчитывает результаты измененного запроса и всех зависимых запросов без дополнительного вмешательства пользователя.

Какие данные и как использует

Данные на входе

Патент описывает интерфейс, который может работать с различными типами данных документов и их метаданными. Он не упоминает факторы, используемые в веб-поиске (ссылки, поведение пользователей, PageRank и т.д.).

• Контентные факторы: Текст и содержимое документов. Используется оператором contains для поиска по ключевым словам или фразам.
• Технические факторы (Метаданные документов):
  • Тип файла (file-type).
  • Аккаунт-источник или владелец (from-account, account, userID).
• Временные факторы: Временные метки (created-before, created-after, created-on).
• Системные данные:
  • Существующие именованные запросы (pipeline).
  • Группы пользователей (group).

Какие метрики используются и как они считаются

Патент не использует метрики ранжирования (такие как Ranking Score, PageRank или Quality Score). Он описывает систему точной фильтрации, основанную на соответствии заданным критериям.

• Методы вычисления: Используется булева логика (AND, OR) для определения того, соответствует ли документ набору критериев.
• Операторы сравнения: Используются операторы точного соответствия, сравнения дат и поиска подстроки (contains).

1. Фокус на UI и E-discovery: Патент полностью посвящен дизайну пользовательского интерфейса и методологии построения сложных запросов, разработанных специально для систем управления данными и юридического анализа (E-discovery).
2. Конвейеризация запросов (Pipelining): Ключевая запатентованная концепция — это возможность создавать цепочки фильтров, где результат одного запроса (Pipeline) используется как источник для следующего. Это упрощает создание сложных логических конструкций для нетехнических пользователей.
3. Модифицируемость и автоматическое обновление: Система поддерживает динамическое изменение запросов и автоматическое обновление результатов во всей цепочке зависимостей, что критично для итеративного анализа данных.
4. Распределенные системы: Патент упоминает, что система работает с документами, хранящимися в распределенной среде (plurality of clients), что соответствует облачной архитектуре Google.
5. Отсутствие связи с SEO: Для SEO-специалистов этот патент не предоставляет абсолютно никакой практической ценности. Он не содержит информации об алгоритмах ранжирования веб-поиска Google, сигналах качества, E-E-A-T или любых других факторах, влияющих на продвижение сайтов.

ВАЖНО: Патент является инфраструктурным и описывает интерфейс специализированного программного обеспечения (E-discovery). Он не дает практических выводов для SEO.

Best practices (это мы делаем)

Не применимо к SEO. Патент не содержит рекомендаций по оптимизации сайтов.

Worst practices (это делать не надо)

Не применимо к SEO. Патент не описывает механизмы борьбы с SEO-манипуляциями.

Стратегическое значение

Стратегическое значение для SEO отсутствует. Патент демонстрирует подход Google к разработке интерфейсов для сложных задач анализа данных, но эти методы не связаны с работой публичного веб-поиска.

Практические примеры

Практических примеров для SEO нет. Ниже приведен пример использования интерфейса в соответствии с патентом для задачи E-discovery.

Сценарий: Юридический анализ документов по теме "Fair Use"

Шаг 1: Создание базового запроса "fair_use"

1. Источник: Выбрать аккаунты ключевых сотрудников (jsmith OR tjones).
2. Фильтр 1 (KEEP): Оставить документы, содержащие (contains: fair AND contains: use).
3. Фильтр 2 (DISCARD): Исключить документы, созданные до 2010 года (created-before: 2010).
4. Назначение: Сохранить результат как NAMED: "fair_use".

Шаг 2: Создание зависимого запроса "video_fair_use"

1. Источник: Выбрать существующий конвейер (pipeline: "fair_use").
2. Фильтр 1 (KEEP): Оставить документы, содержащие (contains: video).
3. Назначение: Сохранить результат как NAMED: "video_fair_use".

Шаг 3: Модификация и обновление

1. Юрист решает добавить еще одного сотрудника (ajohnson) в базовый запрос "fair_use".
2. Он модифицирует Источник в Шаге 1.
3. Система автоматически обновляет результаты запроса "fair_use" И запроса "video_fair_use".