В этой статье рассказывается о базовых техниках классификации, использующихся в архивном деле. На примере архива иллюстраций разбираются разные типы поисковых признаков, их применимость и ограничения.
УДК 639.3.043
По роду своей профессиональной деятельности мне регулярно приходится встречаться с разнообразными архивами. В архивах, где ожидалось, что пользователи могут и должны найти любой документ (например, архив проводок; такого рода архивами занимаются архивариусы), всё было куда ни шло. Однако, если дело касалось архива с нечетким поиском (например, крупный сайт или другой контентный проект; такими архивами обычно занимаются архивисты или библиотекари), все было иначе: разработчики таких архивов почти всегда недооценивали сложность стоящей задачи. Вместо полноценного архива, предназначенного, чтобы находить всё, что может понадобиться, почти всегда получается свалка (а часто и помойка), в которой можно найти только малую часть объектов, при этом необязательно самых ценных. При этом даже и эти свалки делались с необыкновенными муками и диким напряжением мозгового вещества — изобретался и изобретается давно сданный в архив велосипед.
Попытки исправить проблему через интерфейс (по каковой причине я с этими архивами и сталкиваюсь), встречаются с непреодолимыми трудностями — интерфейс помойки возможен, но он неизбежно получается помоечным. Лишенный соответствующей архивной инфраструктуры, вместо простого интерфейс получается упрощенным — и уж тем более недостаточно мощным («ура, мы вставим теги и всё наконец-то будет хорошо!»).
Удивляться тут, по-моему, нечему. Архив первого типа — база данных, архив второго — не просто база данных, а база данных с интегрированной поддержкой пользователя. Кроме того, есть еще и другой фактор. Появление компьютеров и, собственно, баз данных сделало совершенно неактуальной большую часть докомпьютерной архивной технологии. Вместе с ней кануло в небытие и уважение к архивному делу — многим, если не большинству, разработчикам просто не приходит в голову при разработке инфраструктуры своего архива поинтересоваться, как было устроено архивное дело в дремучую старину. Однако канула в небытие только внешняя сторона архивов; причины, по которым старые технологии вообще появились на свет, никуда не делись при переходе к компьютерам. Отсюда обманчивое убеждение в примитивности архивного дела — как в творческом плане («ну, это же просто!»), так и в плане трудоемкости.
Здесь я покажу, с какими проблемами сталкиваются пользователи сложных архивов. Я также опишу некоторые способы решения этих проблем. Не претендуя на исчерпывающую полноту изложения, полагаю, что даже простейшие решения могут сделать большинство архивов гораздо ценнее.
Важно: чтобы как-то ограничить объем, я порой сознательно (а порой бессознательно) упрощал некоторые понятия и подходы. Эта статья не может заменить учебник библиотечного дела.
Чтобы упростить дальнейшее изложение, полезно сразу дать расшифровку основных терминов. Кроме того, существует великое множество наглядных примеров, которые как нельзя лучше подходят в нашем случае — это коммерческие продавцы изображений. Архивы такого рода сравнительно сложны, хотя предметная область вполне понятна посторонним. Фотобанков множество; с их устройством очень рекомендую ознакомиться перед дальнейшим чтением. Рекомендую посмотреть два, находящихся на разных полюсах —Dreamstime (простой вариант, новая разработка) и Corbis Images (сложный вариант, ведущий свое начало в ещё докомпьютерные времена).
Объект (хранения)
То, что, собственно говоря, является содержанием архива. В нашем случае это цифровые изображения.
Метаинформация
Совокупность данных об объектах хранения, не являющаяся самим объектом. В случае фотобанка метаинформация должна содержать как минимум такие поля, как название изображения, размер, автор, цена — и, скорее всего, многое другое.
Поисковый признак / Дескриптор
Любое поле метаинформации, которое может быть использовано пользователем при поиске.
Рубрикатор
Перечень признаков объектов, представленный в линейной форме, как правило, с той или иной степенью иерархии. Рубрикаторами являются, например, оглавление в книге, статическая навигация по сайту или структура каталогов на жестком диске. Крупное достоинство рубрикатора — его можно показать пользователю, чтобы тот выбрал (а не вспоминал) подходящий ему элемент. Кроме того, архивные рубрикаторы можно напечатать на бумаге в виде структурированного справочника; когда-то это было очень ценно, но с появлением компьютеров и полнотекстового поиска нужда в архивных рубрикаторах заметно упала.
Пример рубрикатора на dreamstime.com:
Классификатор
То же, что и рубрикатор, но необязательно представляемый линейно. Например, таги (так же известные как теги, до появления вебдваноль известные как ключевые слова) являются классификатором. Рубрикатором их теоретически представить можно, отсортировав в столбик, но практически никогда это не служит ничему полезному. Классификатор может быть одномерным (те же одноуровневые ключевые слова), но, как правило, фасетный классификатор значительно полезнее.
Фасетный классификатор
Вариант классификации, в котором объект находится одновременно в нескольких классификаторах/рубрикаторах. Простейшим примером фасетного классификатора является любой клиент электронной почты: приходящие письма описываются независимыми классификаторами «от кого», «прочтено/не прочтено», «дата и время приема» и др. Принципиальная особенность фасетных классификаторов заключается в том, что отдельные классификаторы-фасеты никак не связаны друг с другом: ни по смыслу, ни по объему, ни по назначению. Именно это позволяет малым классификатором охватить большое число понятий и поисковых сценариев.
Вообще, термин «фасетный» здесь только запутывает понимание. Это — калька с английского facet, грань. Идея в том, что как в многограннике положение точки или региона может быть выражено через набор лучей, проходящих через три грани (в жизни чем граней больше, тем точнее), так и в массиве информации сокращение выбора может быть произведено через совокупность разных, не связанных между собою фильтров — граней архивной информации. Если бы вместо кальки употреблялось простое русское слово «грань», концепция, на мой взгляд, была бы гораздо более понятной.
Ниже представлены некоторые проблемы крупных контентных хранилищ, которые и не позволяют относиться к ним как к обычным базам данных.
По запросу «Happy» сейчас, когда я это пишу, на Dreamstime находится больше миллиона изображений. Популярные пользовательские запросы обычно в целом соответствуют наиболее популярным сюжетам, которые фотографируют создатели контента. В таких условиях неизбежно, что по всем самым популярным запросам количество результатов поиска будет гораздо большим, чем пользователи поиска будут готовы рассматривать. Фактически, это значит, что для каждого конкретного запроса, начиная примерно с двухсотого результата, качество результатов несущественно — туда все равно никто не будет смотреть. Это не значит, что эти результаты вовсе мусорные (по другим запросам они вполне могут оказаться сверху списка). Тем не менее, этот хвост — всего лишь накладные расходы на базу данных и файловое хранилище.
Можно ли как-то это улучшить? Есть два пути:
Оба подхода не противоречат друг другу; в целом, стоит использовать оба.
Уже на этом уровне становится видна первая лемма архивной деятельности: устройство классификатора зависит не столько от того, что хранится в архиве, сколько от того, что в этом архиве ищут.
Из этой леммы следует важный практический вывод — раз во время создания инфраструктуры архива еще неизвестно, что и как пользователи будут в нем искать, попытки лимитировать функциональность архива заранее более или менее обречены ухудшать архив.
При неизменном спросе (вопросы маркетинга я выношу за скобки) увеличения продаж фотоархива можно добиться только через увеличения числа удовлетворяемых запросов, а значит — приходится бороться за запросы редкие и специфичные. Сделать это невозможно, если о них не узнать. Соответственно, нет альтернативы введению активного мониторинга поисковых запросов. Такой мониторинг должен отслеживать как минимум два фактора:
Эти два пункта так же требуют как минимум двух путей развития:
Суммируя, инфраструктуре архива необходимо иметь возможность вести автоматическую статистику по просмотрам/выдачам для каждого объекта. Без такой статистики неизбежно низкое качество многих хранимых объектов, что приводит к снижению общего качества архива.
По запросу «Hapy» (т.е. Happy с пропущенной буквой) на Dreamstime сейчас находится больше двухсот изображений. Очевидно, что:
Обе проблемы с трудом могут быть решены алгоритмически — гораздо проще просто анализировать поисковые запросы и описания от фотографов в сравнении с результативностью поиска и поддерживать словарь синонимов (в самих запросах/описаниях опечатки можно либо исправлять автоматически, либо прогонять все запросы через тот же словарь терминов).
Как вопрос опечаток, так и отработка длинного хвоста в целом подтверждают, что большой архив не может быть эффективным без постоянной работы архивиста, регулярно анализирующего текущие запросы пользователей и результаты их запросов. Объекты с плохими показателями нужно вычищать, а запросы, которые архив покрывает плохо, надо выявлять в зародыше. К счастью, с появлением компьютеров это можно делать в полуавтоматическом режиме.
Как правило, ценность объектов хранения со временем меняется. Например, фотографии счастливых потребителей — хлеб фотобанков — мгновенно устаревают со сменой моды. Можно только предполагать, сколько постановочных фотографий «счастливых потребителей» списали западные архивы в начале и середине 90ых, вместе с концом эры диско. Таких тем довольно много, например, почти все предметы быта переживают медленный, но рестайлинг — некоторые, например сотовые телефоны, переживают его быстрее (попробуйте продать картинку телефона образца 2003ого года), некоторые медленно, но устаревают все. Это пример падения цены. Некоторые сюжеты, если тема остается популярной, а возможности сфотографировать сюжет уже нет, со временем только дорожают. По этой самой причине на крупных спортивных состязаниях так много фотографов — рекорд по прыжкам с шестом рано или поздно будет побит, но фотография предыдущего рекорда все равно останется ценной и будет продуцировать деньги вечно.
Кроме того, меняются и поисковые запросы. В редакционных фотоархивах, как правило, содержится куча фотографий малоизвестных политиков, музыкантов, актеров и пр. Если они станут более известны, их фотографии автоматически вырастут в цене (например, все фотографии полковника Путина выросли в цене, как только он был назначен президентом). В случае фотобанков вроде Dreamstime мало шансов, что соответствующую фотографию переиндексируют (см. ниже), но существенную часть времени архивистов в редакциях тратится именно на это.
К сожалению, эту работу нет никакой возможности сделать автоматически, здесь неизбежно требуется ручной анализ результатов наиболее частотных запросов.
Музыканты и политики интересны еще и в другом отношении — качество фотографий с ними, строго говоря, обусловлено не качеством самих фотографий, не наличием на фотографиях музполитиков, а прежде всего тем, адекватно ли размечены соответствующие фотографии. Объект хранения сам по себе часто не имеет никакой значимой поисковой информации о себе, она появляется только благодаря разметке. Нет разметки — ничего не появляется в результатах поиска.
Практическое следствие этого закона — качество архива опять определяется не только тем, что в нем хранится, сколько качеством работы архивиста. Это вторая причина, по которой любому сколько-нибудь крупному архиву требуется перманентная работа архивиста — никак не приходится ожидать от пользователей, что они все правильно и полно разметят (см. далее).
Это была одна половина проблемы — что пользователи ищут. Есть и вторая — непродуктивно ожидать, что разметка будет сама собой соответствовать тому, как они это делают. Про опечатки я уже писал, но есть еще два аспекта:
Неприятная особенность запросов такого типа заключается в том, что, хотя в среднем они не особо часты, они всегда продуцируют неудовлетворительные результаты, которые конечные пользователи не способны опознать как ненормальные и, соответственно, поменять тактику своих действий. Пользователям в таких случаях кажется, что они все делают правильно, а вот архив пустоват, хотя вполне может быть, что на самом деле в архиве есть все необходимое.
Уже из предыдущих пунктов видно, что поставляющие контент пользователи — не очень надежные генераторы классификации:
Если же финансовой мотивации нет, все совсем плохо: так, пользователи Flickr тоже заинтересованы в находимости своих фотографий, но средняя длина описания объектов там на порядок меньше, чем на Dreamstime.
Существуют относительно работоспособные способы борьбы с этой проблемой: пользователей можно учить, им можно показывать текущую конъюнктуру и статистику находимости материалов (с предложением подправить разметку слабо находимых объектов). Ничего особо сложного тут нет; на эту деятельность просто нужно заложиться при разработке архива. Всех проблем это не решит, но лучше так, чем никак.
Когда с появлением компьютеров стал возможен дешевый полнотекстовый поиск, архивное дело изменилось до неузнаваемости — исчезла необходимость вручную индексировать поисковые признаки и делать сложный интерфейс для доступа к ним. Полнотекстовый поиск, тем не менее, не всегда работает удовлетворительно.
Во-первых, вполне может оказаться, что поискового термина в документе нет, хотя документ именно о нем. В том же Dreamstime фотографии вообще не содержат слов, которые можно найти. Но даже если индексируются тесты, совершенно необязательно, что создатель текста использовал в нем правильные слова. Например, статья Паула Фиттса The information capacity of the human motor system in controlling the amplitude of movement, послужившая родоначальником т.н. Закона Фиттса, не содержит в себе поискового термина «Fitts Law», хотя именно этому поисковому запросу она глубоко релевантна.
Во-вторых, поиск невыгодно отличается от готового классификатора тем, что классификатор работает как меню (пользователь выбирает элемент, а не вспоминает, что ему нужно), а поиск — нет. Это лечится через последовательный поиск, когда пользователь находит сначала что-то относительно подходящее, а оттуда уже узнает нужный ему термин (т.е. пользователь сначала пытается найти, какой именно поисковый запрос ему нужен, а только потом, воспользовавшись этим термином, ищет нужные объекты). Это — очень важная часть интерфейса поиска и плох тот полнотекстовый поиск, интерфейс которого не помогает пользователю в этой активности.
Сравните карточку результата поиска на Dreamstime (ключевые слова мелко в нижнем правом углу)...
...с карточкой на Corbis (ключевые слова cнизу). Обратите внимание, что интерфейс позволяет прямо отсюда уточнить свой поисковый запрос по нескольким ключевым словам и запустить новый поиск:
В-третьих, полнотекстовый поиск без дополнительной работы не может отрабатывать омонимы («коса» и «коса», см. ниже).
Все это, разумеется, не значит, что полнотекстовый поиск плох. Это прекрасная штука, но даже и с ним для достижения наилучшего качества все равно приходится заниматься ручной индексацией — опять нужна ручная работа архивиста.
Помимо синонимов, в поиске приходится как-то бороться с омонимами, т.е. словами, который пишутся одинаково, но значат разное. Например, при запросе Moscow в Dreamstime в результаты попадает как Москва (которая в России), так и несколько Москв (которые в США), так и актер Дэвид Москоу (и, скорее всего, еще что-то постороннее, у меня не хватило терпения просмотреть несколько сот страниц поисковой выдачи).
К счастью, с омонимами не нужно бороться во всех случаях: если результатов поиска немного (т.е. запрос из длинного хвоста), пользователь разберется сам. Но в популярных запросах, продуцирующих большое количество результатов, бороться приходится. Помимо очевидного, т.е. уточнения текста поискового запроса (не всегда работает идеально, например запрос «Moscow Usa» находит на Dreamstime фотографии нашей Москвы, тем или иным образом связанные с Америкой), основными методами являются:
Опять-таки, оба этих варианта требуют и начального планирования и инфраструктуры, поддерживающей модификацию классификатора на ходу.
Из предыдущих параграфов видно, что хорошо действующий архив просто невозможно сделать; его можно только делать, в том смысле, что работа эта перманентная. Невозможно единократно построить классификатор, который будет хорошо работать все время.
Часть проблем поиска связана также и интерфейсом архива, безотносительно к его устройству. Интерфейсная составляющая порождает свои эффекты.
Существуют веские основания считать, что средний пользователь искать не умеет (например, языком поисковых запросов в Яндексе пользуется лишь незначительное количество посетителей). Отсюда следует, что интерфейс должен быть простым. Требуется определенная решительность, чтобы понять, что простой интерфейс не тождественен просто устроенному архиву. Например, синонимы в ключевых словах усложняют устройство архива, но, поскольку пользователи их не видят, интерфейс они не усложняют. В целом, механизм поиска может быть сколь угодно сложным, пока он проявляется только тогда, когда нужно — т.е. когда результатов оказывается слишком много (т.е. нужна дополнительная фильтрация) или когда подозрительно мало (велик шанс, что пользователь сделал некорректный запрос и ему нужно помочь).
В том же Corbis, к примеру, базовый интерфейс — всего лишь поле ввода и небольшое меню, которого часто вполне достаточно (результаты в меню различаются лицензиями, так что целевым пользователям важно делать этот выбор — даже наилучшая фотография не с той лицензией для них совершенно бесполезна):
Конечно, есть и расширенный поиск, нужный несколько реже:
Но и это не основной интерфейс. Еще больше интерфейса появляется на странице результата — проявляется часть фасетного классификатора:
Обратите внимание, что пользователь не обязан им пользоваться — если его удовлетворяют результаты запроса, классификатор ему не нужен. Однако, если что-то пошло не так, возможность уточнить запрос под рукой. Однако основной классификатор даже не тут, а в наборе ключевых слов, которые привязаны к самой фотографии (см. скриншот выше) — именно благодаря им пользователи могут узнать, какие именно ключевые слова им нужны. Более того, часть этого интерфейса пользователям даже не видна: ключевые слова «Moscow» (город в России) и «Moscow» (города в США) выглядят в интерфейсе одинаково, но в системе они разные (раньше это было видно и в интерфейсе, были видимы «Moscow, Russia» и «Moscow, USA»).
Именно такая проработка и делает поиск действенным — хотя интерфейс фактически не усложняется.
Из вышеперечисленного следует простой вывод — с ростом архива возникает необходимость все чаще и больше править систему поисковых признаков (расчищать ключевые слова, дорабатывать списки синонимов/омонимов/опечаток, дополнительно размечать малонаходимые объекты и т.п.). Соответственно, если не сделать более-менее быстрого и эффективного интерфейса для этой работы, ей будут в лучшем случае пренебрегать, что скажется на качестве архива для конечных пользователей.
Например, оказалось, что ключевое слово Москва стало слишком заезженным и применено к неоправданно большому числу фотографий, которые плохо находятся, т.е. висят в хвосте поисковой выдачи. Что делать?
Во-первых, необходимо сразу признать, что проблему не удастся решить, не поставив сначала ей диагноз. Соответственно, надо задать себе вопрос, как вообще такое может обнаружиться? Ответ не особо утешительный — если в системе не предусмотрено мониторинга частотности поисковых запросов, то никак. Кроме того, даже если такой мониторинг предусмотрен, как понять, что дескриптор «Москва» действительно применен к слишком многим словам из хвоста? Это значит, что нужны еще и (а) мониторинг малонаходимых объектов и (б) возможность построить срез малонаходимых фотографий по массовым ключевым словам. Без такой функциональности проблему даже не поставить.
Во-вторых, что делать, таки поставив проблему? Конкретно эта характеризуется тем, что фотографий, которые нужно переразмечать, очень много. Соответственно, если не будет быстрого административного интерфейса для таких операций, работа фактически не будет делаться вообще.
В третьих, самый печальный вопрос — кто будет делать эту работу, если в штатном расписании просто не предусмотрена соответствующая работа архивиста?
К сожалению, простого и приятного решения тут нет.
Из всего вышеизложенного видно, что архивное дело не совсем зря называется делом. Работы здесь много и не вся она является самоочевидной. Вера же в волшебный алгоритм, который решит все-все проблемы, оказывается на поверку несколько наивной («...как же, Яндекс-то все находит!» — так сколько всего он не находит и об этом мы не можем даже узнать!).
PS. Для заинтересовавшихся темой и желающих углубить свои знания — печалька и огорчение. На русском языке просто нет внятных современных учебников по библиотечному/архивному делу применительно к проблемам поиска (этот факт, собственно, и побудил меня написать этот текст).
Оригинал статьи: http://usethics.ru/blog/lib/archive_for_finding_stuff/
Хорошая статья. Во многом согласен с автором. Задачи по релевантному поиску всегда очень сложны в реализации и без ручного труда тут обойтись очень сложно, чтобы как то облегчить этот труд несколько дополнений к статье
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.
Технический директор в Nimax
Совершенно верна мысль, о том, что хорошо действующий архив просто невозможно сделать; его можно только делать. Это относится к любому сервису — не только архивного плана.
Тем не менее, автор статьи преувеличивает преемственность между старыми бумажными архивами и электронными. Общего между ними примерно столько же, сколько между гужевой повозкой и автомобилем: вроде бы и то, и другое передвигается, но под действием разных разных причин. А для создания быстрых и комфортных автомобилей не так уж и много пользы от изучения того, как ведут себя животные в упряжке.
У меня создалось впечатление, что автор статьи предпочитает ручную обработку информации любому другому способу. Да, раньше это был единственный вариант, который позволял вести архив. Однако современные технологии дают возможность распознавать образы и размечать информацию самостоятельно — пускай не идеально, но вполне сносно. Там, где алгоритм бессилен или необходимы инструменты защиты от логических ошибок при разметке пользователями, при злонамеренном искажении информации, на помощь приходит коллаборация. Пользователи архива — не столько авторы контента, сколько посетители, реально ищущие информацию — без проблем помогут с разметкой. Особенно если она подана в игровой форме, возвышает пользователя в сообществе или дает реальные скидки при доступе к данным. Краудсорсинг может творить чудеса, сводя к минимуму необходимость непосредственного участия в процессе совершенствования архива.
Многие проблемы, описанные в статье — синонимы, опечатки, морфология и лексические особенности разных языков — являются серьезной задачей. Однако современные алгоритмы довольно успешно справляются с ней. «Паршивые овцы» не являются сколько-нибудь серьезным препятствием при статистической проверке. Вес ключевых слов, добавленных объекту пользователем, который случайно или специально искажает информацию, стремится к нулю при накоплении на нем отрицательной статистики. Заметьте, такая статистика собирается и автоматически, основываясь на разметке того же материала другими пользователями.