Dan Petrovic проанализировал функции внутреннего поиска Chrome и обнаружил информацию, связанную с тем, как он обрабатывает, интерпретирует и анализирует страницы сайта.
Алгоритм DocumentChunker
Данный алгоритм разбивает страницу на «значимые отрывки», которые затем могут быть использованы для LLM. В частности, есть параметр "max_words_per_aggregate_passage", который ограничивает отрывки всего 30 абзацами (~200 слов каждый).
Алгоритм обхода дерева
Системы также обрабатывают содержимое по мере его продвижения вниз по дереву документа и в значительной степени полагаются на семантическую структуру HTML. Это означает, что хорошо отформатированный контент (заголовки, маркеры, списки, пары ключ-значение) легче обрабатывается системой.
Ограничения на объем данных
Также есть параметр "max_passages_per_page", который равен 30. Это означает, что Chrome может извлечь только до 30 различных отрывков на одной странице, независимо от того, насколько длинным является контент. Каждый пассаж закладывается в виде 1540-мерного вектора.
Динамический контент
Также есть «passage_extraction_delay», который позволяет странице полностью загрузиться до начала извлечения отрывка. Это дает немного больше свободы для рендеринга динамического содержимого до того, как произойдет извлечение.
Embedding Engine
Как только отрывки извлечены, они перемещаются через службы встраивания Chrome. Используя встраиваемые модели Google, отрывки преобразуются в 1540-мерное векторное пространство. Именно так движок интерпретирует смысл отрывков.
Контроль качества
Затем система обрабатывает вложения с помощью различных уровней проверки качества. Это включает в себя «search_score_threshold», который измеряет, является ли встраивание достаточно релевантным для фактических выходных данных.
Поиск по истории Chrome
Система также учитывает историю поиска пользователя. Система может преобразовывать предыдущие поисковые запросы, выполненные пользователем, во встраивания. Это дает ему еще один путь к формированию сильного ответа.
Классификация намерений
Модели Chrome также имеют «классификатор намерений», который определяет, как они формируют ответ. В зависимости от интента запросов, будет определено, как именно система будет реагировать. В статье Dan Petrovic упоминает, что навигационный запрос может отдавать приоритет точным совпадениям страниц, а исследовательский запрос может инициировать получение информации из нескольких источников.
Описание процесса от Dan Petrovic
Встраивания хранятся для каждого посещения в embeddings_blob внутри базы данных History.
Процесс фрагментации и встраивания Passage в Chrome
Механика прохода: Chrome разбивает страницы на логические «отрывки». Параметры определяются в history_embeddings_features.h, в том числе:
- max_passages_per_page = 30
- passage_extraction_max_words_per_aggregate_passage = 200
Это означает, что:
- Chrome ограничивает количество встроенных элементов до 30 на страницу (соответствует массивам (30, 1540), которые вы видели).
- Он группирует текст страницы в части примерно по 200 слов каждая.
Встраивание потока генерации
Служба HistoryEmbeddingsService обрабатывает конвейер:
- Когда страница завершает загрузку, Chrome извлекает отрывки и вызывает ComputeAndStorePassageEmbeddings(url_id, visit_id, visit_time, отрывки).
- Если необходимы внедрения, он вызывает embedder_->ComputePassagesEmbeddings(priority, passages, callback).
- После вычисления векторы сохраняются в объекте UrlData и фиксируются в базе данных через vector_database. SaveTo(sql_database).
- Почему ваши данные выглядят так (30, 1540) означает полностраничное вложение: 30 отрывков × вектором 1540-dim каждый.
- Более мелкие фигуры (например, 1 или 3 блока) встречаются на более коротких страницах с небольшим количеством текста.
- Очень большие и очень маленькие значения float16 являются артефактами квантования/сжатия.
***
Больше интересных новостей и полезных инструментов на нашем телеграм-канале https://t.me/siteanalyzer