Эксперимент: как отличить шум HTML от изменения документации

Вопрос эксперимента: как отличить raw HTML churn от meaningful documentation change на открытом URL? Raw churn — изменение байтов, которое не меняет извлечённый тезис или структуру ответа. Meaningful change — добавление, удаление или исправление содержания, сущности, ссылки, даты либо ограничения, способное изменить понимание читателя или извлечение ответа. Это исследовательское определение нужно зафиксировать до просмотра результатов.

Источники раздела:[2] Google Search Central

Пилот использует только публичные документы, например страницы Google Search Central и открытые страницы документации о краулерах. Для каждого URL запишите дату и время UTC, HTTP status, content type, final URL, размер ответа, hash сырого тела и сохранённый снимок. Не включайте закрытые клиентские страницы, cookies, токены, персональные данные или внутренние логи. Список URL и манифест должны быть опубликованы вместе с кодом нормализации.

Источники раздела:[1] Google Search Central

Получите HTML обычным HTTP-клиентом с честно обозначенным User-Agent и сохраните заголовки ответа отдельно. Проверьте robots.txt и условия использования источника; не обходите ограничения. Для повтора храните URL, команду или скрипт, дату, timezone, redirect chain и checksum. Снимок считается пригодным, если другой исследователь может скачать тот же публичный адрес и понять, какие входы породили diff.

Источники раздела:[3] OpenAI Developers

Сравните четыре слоя: raw bytes; HTML после удаления динамических timestamp, nonce, tracking-параметров и явно служебных узлов; извлечённый видимый текст с сохранением заголовков, списков и ссылок; структурированный набор сущностей, тезисов, дат и outbound URLs. Правила удаления должны быть детерминированными и версионироваться. Нельзя удалять всё незнакомое: нормализация, которая стирает реальное предложение, маскирует meaningful change.

Источники раздела:[2] Google Search Central

Этот материал не заявляет числового результата: пилотный результат — воспроизводимый способ получить кандидатов, а не подтверждённая доля изменений. Для каждого diff два оценщика присваивают label noise, meaningful или unclear и цитируют изменившийся фрагмент. Разногласия разрешаются третьим оценщиком или правилом, записанным заранее. Отдельно отмечайте изменения, которые видны только в raw bytes, и изменения, которые переживают все слои нормализации.

Источники раздела:[2] Google Search Central

Без повторного сбора нельзя оценить частоту churn или точность классификатора. Динамический рендеринг, A/B-тест, география, rate limit, CDN и персонализация могут дать разные снимки. Удаление timestamp может ошибочно убрать важную дату. Hash доказывает различие байтов, но не смысл. Даже meaningful documentation change не доказывает, что AI-поверхность обновила индекс или изменила цитирование.

Источники раздела:[3] OpenAI Developers

1) Скопируйте манифест публичных URL. 2) Запустите сборщик в двух заранее назначенных временных окнах UTC. 3) Проверьте status, redirect и checksum. 4) Примените зафиксированную версию нормализатора. 5) Получите diffs по четырём слоям. 6) Проведите независимую ручную разметку и сохраните решения. 7) Опубликуйте сырые снимки, нормализованные представления, код, версии зависимостей и журнал ошибок. Затем можно добавить контрольные страницы и оценить agreement, но числа появятся только после запуска.

Источники раздела:[2] Google Search Central

Разделите сборку на неизменяемые шаги. Collector получает ответ и манифест; parser извлекает заголовки, текст, ссылки и даты; normalizer создаёт версию с правилами; differ формирует кандидатов; reviewers присваивают label. Каждый шаг пишет версию инструмента, входной hash и время. Если один URL недоступен, не подменяйте его новым адресом без записи: пропуск должен остаться видимым. Повторный запуск с тем же манифестом должен быть идемпотентным и не плодить копии снимка.

Источники раздела:[2] Google Search Central[3] OpenAI Developers

До анализа реальных изменений создайте небольшой набор контрольных HTML-файлов. В один добавьте timestamp, nonce и tracking-параметр; в другой измените предложение, заголовок, ссылку и дату; третий сделайте с динамическим меню. Ожидаемый результат должен быть зафиксирован заранее: шум удаляется, смысловые изменения сохраняются. Проверяйте не только precision кандидатов, но и опасные пропуски. Любое изменение правила нормализации получает новую версию и повторный прогон контрольного набора.

Источники раздела:[2] Google Search Central

В публикации отделите четыре результата: байтовая разница, разница после нормализации, ручная метка и возможное влияние на читателя или retrieval. Последний пункт нельзя выводить автоматически из diff. Приводите изменившийся фрагмент, URL, timestamp и слой, на котором он обнаружен. Если оценщики не согласны, показывайте unclear, а не выбирайте удобный label. Такой формат делает эксперимент полезным для редакторов: он подсказывает, какую страницу прочитать и проверить, но не симулирует точность, которой у метода нет.

Источники раздела:[3] OpenAI Developers[4] Microsoft Learn

Минимальный пакет репликации содержит manifest, сырые ответы, нормализованный текст, diff по слоям, конфигурацию и журнал решений. Для каждого файла сохраните hash, время и версию схемы. Не заменяйте снимок пересохранённой страницей: это новый артефакт с новой цепочкой происхождения. Если публикация включает фрагмент документации, проверьте лицензию и объём цитирования. В отчёте перечислите недоступные URL, ошибки парсинга и ручные исправления. Тогда следующий исследователь увидит не только итоговую картинку, но и места, где метод мог ошибиться.

Источники раздела:[2] Google Search Central[3] OpenAI Developers