Вопрос или проблема
Я работаю с набором данных Yahoo! Webscope ydata-frontpage-todaymodule-clicks-v1_0 (в частности, с журналами кликов за первые десять дней мая 2009 года). Описание набора данных гласит, что каждый пользователь и статья имеют 6 признаков, пронумерованных от 1 до 6. Признак №1 является постоянной (всегда 1), а признаки №2-6 построены с помощью анализа совместного выбора. Формат данных — пары feature_id:feature_value.
Однако я обнаружил случаи, когда у статьи есть признак с feature_id = 7. Вот пример строки, где это происходит:
1241196300 109522 0 |user 2:0.008078 3:0.005109 4:0.000172 5:0.007422 6:0.979220 1:1.000000 |109523 2:0.316894 3:0.000023 4:0.210890 5:0.198013 6:0.274180 1:1.000000 |109498 2:0.306008 3:0.000450 4:0.077048 5:0.230439 6:0.386055 1:1.000000 |109509 2:0.306008 3:0.000450 4:0.077048 5:0.230439 6:0.386055 1:1.000000 |109508 2:0.264355 3:0.000012 4:0.037393 5:0.420649 6:0.277591 1:1.000000 |109473 2:0.295442 3:0.000014 4:0.135191 5:0.292304 6:0.277050 1:1.000000 |109524 2:0.274868 3:0.000032 4:0.046639 5:0.362209 6:0.316252 1:1.000000 |109527 2:0.375829 3:0.000025 4:0.033041 5:0.349637 6:0.241468 1:1.000000 |109520 2:0.016328 3:0.953419 4:0.000538 5:0.008263 6:0.021452 1:1.000000 |109503 2:0.306008 3:0.000450 4:0.077048 5:0.230439 6:0.386055 1:1.000000 |109510 2:0.287909 3:0.000025 4:0.008983 5:0.511333 6:0.191751 1:1.000000 |109526 2:0.432433 3:0.000002 4:0.069055 5:0.351774 6:0.146736 1:1.000000 |109495 2:0.313277 3:0.000125 4:0.018413 5:0.410555 6:0.257630 1:1.000000 |109506 2:0.264355 3:0.000012 4:0.037393 5:0.420649 6:0.277591 1:1.000000 |109512 2:0.297322 3:0.000025 4:0.034951 5:0.413566 6:0.254137 1:1.000000 |109511 2:0.381149 3:0.000129 4:0.060038 5:0.269129 6:0.289554 1:1.000000 |109514 2:0.297750 3:0.000013 4:0.011603 5:0.512182 6:0.178452 1:1.000000 |109528 7:1.000000 |109522 2:0.214605 3:0.000037 4:0.410493 5:0.097704 6:0.277162 1:1.000000 |109515 2:0.281649 3:0.000173 4:0.195994 5:0.151003 6:0.371182 1:1.000000 |109525 2:0.306008 3:0.000450 4:0.077048 5:0.230439 6:0.386055 1:1.000000 |109513 2:0.211406 3:0.000036 4:0.002773 5:0.569886 6:0.215900 1:1.000000
В частности, статья с article_id=109528 имеет признак 7:1.000000, что не ожидается. Кто-нибудь еще сталкивался с этой проблемой в этом наборе данных? Есть ли какие-либо идеи, почему может возникнуть это несоответствие и как его можно обработать при разборе данных? Это указывает на потенциально более широкую проблему в наборе данных?
Я не знаю этот набор данных, и, я думаю, что не многие его знают, так как он, кажется, не в свободном доступе. Но если мы сыграем в Шерлока Холмса, я дам вам свое предположение, которое может быть совершенно неправильным 🙂
7: находится между признаком 1 и 2 (так ли это всегда?), так что это может быть ошибкой (от оцифровки?). Более того, значение имеет тот же формат, что и признак 1, а 1 и 7 могли бы выглядеть одинаково для оцифровки.
Вы говорили, что значение признака 1 всегда 1, но действительно ли это выглядит как 1.000000 | 109xxx, не так ли? И все эти 109xxx, кажется, уникальны, как ID? (хорошо, я еще раз прочитал ваш вопрос, и вы упомянули, что это ID статьи).
7: связано с 109522, есть ли у вас “1:1.000000 |109522” где-то в остальной части вашего набора данных? Также, каков формат первой строки, которая отличается от остальных строк? Я замечаю, что на этой строке 109522 появляется, и что после “user” отсутствует 1: признак. Может быть, отсутствующий 1: это тот самый 7:, найденный несколькими строками ниже?
Так что моя догадка заключается в том, что 7 – это на самом деле 1, и если так, то у нас есть 2 признака 1 рядом друг с другом, так что, возможно, первый не имеет значения для 5 признаков и должен быть проигнорирован.
Другой вариант: просто игнорировать “7:”, если их немного.
PS: Я также связался бы с компанией или человеком, откуда этот набор данных, чтобы получить объяснение.
.
Ответ или решение
Теория:
Работа с большими данными, особенно когда речь идет о специализированных наборах, таких как Yahoo! Webscope, может представлять определенные вызовы. Наличие неожиданных или необъяснимых значений в данных зачастую связано с ошибками во время сбора, хранения или обработки данных. В данном случае, появление признака с идентификатором feature_id = 7 в наборе данных, где он не должен присутствовать, заслуживает особого внимания и тщательного анализа.
Пример:
В вашем примере видно, что для статьи с article_id=109528 появляется признак 7:1.000000. Согласно описанию, каждый пользователь и статья в данных имеют только шесть признаков, а первый из них всегда равен единице. Это можно интерпретировать как потенциальную ошибку, связанную с автоматической обработкой текста (OCR) или неправильным парсингом данных. Варианты могут включать:
- Неверное считывание: "7" может быть ошибочно интерпретировано вместо "1" из-за похожести графических элементов, что иногда бывает в OCR-системах.
- Ошибки в исходных данных: Возможно, признак 7 был добавлен ошибочно на первом этапе обработки данных, и превышает первоначально объявленный числовой диапазон признаков.
Применение:
-
Проверка дубликатов: Проверьте, появляется ли подобный случай в других частях набора данных. Если feature_id = 7 встречается многократно, возможно, стоит провести более глубокий анализ определенных участков данных.
-
Сравнительный анализ: Проведите сравнительный анализ строк с feature_id = 7 и без него, возможно, это поможет выявить закономерности или контексты, при которых возникает эта ошибка.
-
Игнорировать или исправлять: Временно можно игнорировать строки с feature_id = 7, если они несущественны по количеству. Если такие строки существенны, то возможно, стоит заменить "7" на "1", но такой подход требует тщательной валидации, чтобы не исказить данные.
-
Обратная связь с источником: Обсудите выявленную аномалию с лицами или организациями, ответственными за предоставление набора данных. Они могут предложить готовое решение или объяснение.
Таким образом, ключевой подход заключается в критическом анализе данных, сравнительном анализе и, по необходимости, подключении сторонних экспертиз для устранения ошибок или переоценки данных.