УДК 639.3.043

По роду своей профессиональной деятельности мне регулярно приходится встречаться с разнообразными архивами. В архивах, где ожидалось, что пользователи могут и должны найти любой документ (например, архив проводок; такого рода архивами занимаются архивариусы), всё было куда ни шло. Однако, если дело касалось архива с нечетким поиском (например, крупный сайт или другой контентный проект; такими архивами обычно занимаются архивисты или библиотекари), все было иначе: разработчики таких архивов почти всегда недооценивали сложность стоящей задачи. Вместо полноценного архива, предназначенного, чтобы находить всё, что может понадобиться, почти всегда получается свалка (а часто и помойка), в которой можно найти только малую часть объектов, при этом необязательно самых ценных. При этом даже и эти свалки делались с необыкновенными муками и диким напряжением мозгового вещества — изобретался и изобретается давно сданный в архив велосипед.

Попытки исправить проблему через интерфейс (по каковой причине я с этими архивами и сталкиваюсь), встречаются с непреодолимыми трудностями — интерфейс помойки возможен, но он неизбежно получается помоечным. Лишенный соответствующей архивной инфраструктуры, вместо простого интерфейс получается упрощенным — и уж тем более недостаточно мощным («ура, мы вставим теги и всё наконец-то будет хорошо!»).

Удивляться тут, по-моему, нечему. Архив первого типа — база данных, архив второго — не просто база данных, а база данных с интегрированной поддержкой пользователя. Кроме того, есть еще и другой фактор. Появление компьютеров и, собственно, баз данных сделало совершенно неактуальной большую часть докомпьютерной архивной технологии. Вместе с ней кануло в небытие и уважение к архивному делу — многим, если не большинству, разработчикам просто не приходит в голову при разработке инфраструктуры своего архива поинтересоваться, как было устроено архивное дело в дремучую старину. Однако канула в небытие только внешняя сторона архивов; причины, по которым старые технологии вообще появились на свет, никуда не делись при переходе к компьютерам. Отсюда обманчивое убеждение в примитивности архивного дела — как в творческом плане («ну, это же просто!»), так и в плане трудоемкости.

Здесь я покажу, с какими проблемами сталкиваются пользователи сложных архивов. Я также опишу некоторые способы решения этих проблем. Не претендуя на исчерпывающую полноту изложения, полагаю, что даже простейшие решения могут сделать большинство архивов гораздо ценнее.

Важно: чтобы как-то ограничить объем, я порой сознательно (а порой бессознательно) упрощал некоторые понятия и подходы. Эта статья не может заменить учебник библиотечного дела.

Для начала...

Чтобы упростить дальнейшее изложение, полезно сразу дать расшифровку основных терминов. Кроме того, существует великое множество наглядных примеров, которые как нельзя лучше подходят в нашем случае — это коммерческие продавцы изображений. Архивы такого рода сравнительно сложны, хотя предметная область вполне понятна посторонним. Фотобанков множество; с их устройством очень рекомендую ознакомиться перед дальнейшим чтением. Рекомендую посмотреть два, находящихся на разных полюсах —Dreamstime (простой вариант, новая разработка) и Corbis Images (сложный вариант, ведущий свое начало в ещё докомпьютерные времена).

Объект (хранения)

То, что, собственно говоря, является содержанием архива. В нашем случае это цифровые изображения.

Метаинформация

Совокупность данных об объектах хранения, не являющаяся самим объектом. В случае фотобанка метаинформация должна содержать как минимум такие поля, как название изображения, размер, автор, цена — и, скорее всего, многое другое.

Поисковый признак / Дескриптор

Любое поле метаинформации, которое может быть использовано пользователем при поиске.

Рубрикатор

Перечень признаков объектов, представленный в линейной форме, как правило, с той или иной степенью иерархии. Рубрикаторами являются, например, оглавление в книге, статическая навигация по сайту или структура каталогов на жестком диске. Крупное достоинство рубрикатора — его можно показать пользователю, чтобы тот выбрал (а не вспоминал) подходящий ему элемент. Кроме того, архивные рубрикаторы можно напечатать на бумаге в виде структурированного справочника; когда-то это было очень ценно, но с появлением компьютеров и полнотекстового поиска нужда в архивных рубрикаторах заметно упала.

Пример рубрикатора на dreamstime.com:

Классификатор

То же, что и рубрикатор, но необязательно представляемый линейно. Например, таги (так же известные как теги, до появления вебдваноль известные как ключевые слова) являются классификатором. Рубрикатором их теоретически представить можно, отсортировав в столбик, но практически никогда это не служит ничему полезному. Классификатор может быть одномерным (те же одноуровневые ключевые слова), но, как правило, фасетный классификатор значительно полезнее.

Фасетный классификатор

Вариант классификации, в котором объект находится одновременно в нескольких классификаторах/рубрикаторах. Простейшим примером фасетного классификатора является любой клиент электронной почты: приходящие письма описываются независимыми классификаторами «от кого», «прочтено/не прочтено», «дата и время приема» и др. Принципиальная особенность фасетных классификаторов заключается в том, что отдельные классификаторы-фасеты никак не связаны друг с другом: ни по смыслу, ни по объему, ни по назначению. Именно это позволяет малым классификатором охватить большое число понятий и поисковых сценариев.

Вообще, термин «фасетный» здесь только запутывает понимание. Это — калька с английского facet, грань. Идея в том, что как в многограннике положение точки или региона может быть выражено через набор лучей, проходящих через три грани (в жизни чем граней больше, тем точнее), так и в массиве информации сокращение выбора может быть произведено через совокупность разных, не связанных между собою фильтров — граней архивной информации. Если бы вместо кальки употреблялось простое русское слово «грань», концепция, на мой взгляд, была бы гораздо более понятной.

Эффекты и аффекты

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

Много найденного

По запросу «Happy» сейчас, когда я это пишу, на Dreamstime находится больше миллиона изображений. Популярные пользовательские запросы обычно в целом соответствуют наиболее популярным сюжетам, которые фотографируют создатели контента. В таких условиях неизбежно, что по всем самым популярным запросам количество результатов поиска будет гораздо большим, чем пользователи поиска будут готовы рассматривать. Фактически, это значит, что для каждого конкретного запроса, начиная примерно с двухсотого результата, качество результатов несущественно — туда все равно никто не будет смотреть. Это не значит, что эти результаты вовсе мусорные (по другим запросам они вполне могут оказаться сверху списка). Тем не менее, этот хвост — всего лишь накладные расходы на базу данных и файловое хранилище.

Можно ли как-то это улучшить? Есть два пути:

• Можно рассматривать такие запросы как начало других, более сложных запросов — и предлагать пользователям уточнить запрос на основе ранее введенного. Например, система знает, что среди уже найденных фотографий есть другие ключевые слова, при этом частотность их известна. Система может предложить пользователю список самых частотных слов в уже сделанной выборке; если пользователь воспользуется этим списком, количество фотографий, которые он просмотрит за сессию, вырастет — это хорошо и для фотографов (вырастет вероятность покупки) и для пользователей (им придется сканировать взглядом меньше фотографий). Например, по запросу «Happy» система может спросить пользователя, что ему нужно: фотографии с живыми людьми или фотографии, на которых счастье выражено метафорически.
• Можно автоматически отслеживать неудачные фотографии (найденные, но не купленные) и рассматривать их как плохие: либо выкидывать их из базы, либо — еще лучше — предлагать автору их разметить более подробно (формально правильнее вместо «разметить» писать «переиндексировать», но у этого слова появились четкое IT-понимание, поэтому здесь его использовать не хочу). В этом случае вырастает шанс, что изображение хотя бы будет появляться в редких запросах.

Оба подхода не противоречат друг другу; в целом, стоит использовать оба.

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

Из этой леммы следует важный практический вывод — раз во время создания инфраструктуры архива еще неизвестно, что и как пользователи будут в нем искать, попытки лимитировать функциональность архива заранее более или менее обречены ухудшать архив.

Длинный хвост

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

• Все или почти все запросы пользователей должны удовлетворяться, т.е. пользователи должны что-то находить и покупать. Это можно определить, проанализировав статистику запросов в разрезе продаж. Все запросы, по которым не было заметных продаж, являются проблемными.
• Пользователи должны иметь хоть какой-то выбор изображений для основных запросов (например, можно постановить, что на 90% запросов архив предъявляет более 5 релевантных изображений).

Эти два пункта так же требуют как минимум двух путей развития:

• Нужно отсеивать и отдельно отрабатывать некорректные запросы (см. ниже).
• Желательно дать фотографам понять, что ищут — и не находят — пользователи, чтобы фотографы могли не тратить время на съемки счастливых потребителей, которых уже много, а снимали то, чего в архиве мало. Легко делается автоматически составлением очищенного от опечаток списка запросов с указанием частотности (интересно, что зачастую фотографам ничего не придется снимать, достаточно будет просто переиндексировать уже сделанные фотографии). С другой стороны, просто-то это просто, но на Dreamstime ничего подобного сейчас нет (Corbis, ориентирующийся, прежде всего, на редакционные архивы, может об этом не очень беспокоиться — эту работу за него уже сделали фоторедакторы оригинальных банков, давая задания фотографам).

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

Катенок и другие мифические животные

По запросу «Hapy» (т.е. Happy с пропущенной буквой) на Dreamstime сейчас находится больше двухсот изображений. Очевидно, что:

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

Обе проблемы с трудом могут быть решены алгоритмически — гораздо проще просто анализировать поисковые запросы и описания от фотографов в сравнении с результативностью поиска и поддерживать словарь синонимов (в самих запросах/описаниях опечатки можно либо исправлять автоматически, либо прогонять все запросы через тот же словарь терминов).

Как вопрос опечаток, так и отработка длинного хвоста в целом подтверждают, что большой архив не может быть эффективным без постоянной работы архивиста, регулярно анализирующего текущие запросы пользователей и результаты их запросов. Объекты с плохими показателями нужно вычищать, а запросы, которые архив покрывает плохо, надо выявлять в зародыше. К счастью, с появлением компьютеров это можно делать в полуавтоматическом режиме.

Счастливый потребитель тогда и сейчас

Как правило, ценность объектов хранения со временем меняется. Например, фотографии счастливых потребителей — хлеб фотобанков — мгновенно устаревают со сменой моды. Можно только предполагать, сколько постановочных фотографий «счастливых потребителей» списали западные архивы в начале и середине 90ых, вместе с концом эры диско. Таких тем довольно много, например, почти все предметы быта переживают медленный, но рестайлинг — некоторые, например сотовые телефоны, переживают его быстрее (попробуйте продать картинку телефона образца 2003ого года), некоторые медленно, но устаревают все. Это пример падения цены. Некоторые сюжеты, если тема остается популярной, а возможности сфотографировать сюжет уже нет, со временем только дорожают. По этой самой причине на крупных спортивных состязаниях так много фотографов — рекорд по прыжкам с шестом рано или поздно будет побит, но фотография предыдущего рекорда все равно останется ценной и будет продуцировать деньги вечно.

Кроме того, меняются и поисковые запросы. В редакционных фотоархивах, как правило, содержится куча фотографий малоизвестных политиков, музыкантов, актеров и пр. Если они станут более известны, их фотографии автоматически вырастут в цене (например, все фотографии полковника Путина выросли в цене, как только он был назначен президентом). В случае фотобанков вроде Dreamstime мало шансов, что соответствующую фотографию переиндексируют (см. ниже), но существенную часть времени архивистов в редакциях тратится именно на это.

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

Ненаходимость звезды, помидор ≠ томат

Музыканты и политики интересны еще и в другом отношении — качество фотографий с ними, строго говоря, обусловлено не качеством самих фотографий, не наличием на фотографиях музполитиков, а прежде всего тем, адекватно ли размечены соответствующие фотографии. Объект хранения сам по себе часто не имеет никакой значимой поисковой информации о себе, она появляется только благодаря разметке. Нет разметки — ничего не появляется в результатах поиска.

Практическое следствие этого закона — качество архива опять определяется не только тем, что в нем хранится, сколько качеством работы архивиста. Это вторая причина, по которой любому сколько-нибудь крупному архиву требуется перманентная работа архивиста — никак не приходится ожидать от пользователей, что они все правильно и полно разметят (см. далее).

Это была одна половина проблемы — что пользователи ищут. Есть и вторая — непродуктивно ожидать, что разметка будет сама собой соответствовать тому, как они это делают. Про опечатки я уже писал, но есть еще два аспекта:

• Синонимы без дополнительной работы над архивом ненаходимы. Технически, может доходить до смешного, например, на Dreamstime запросы в множественном числе находят другой набор изображений, чем запросы в единственном числе (просто потому, что у них «s» в конце). Но даже если проигнорировать такие различия, остаются собственно синонимы (томат — помидор). Понятно, что многое можно алгоритмизировать, но многое и нельзя — архивисту придется время от времени отслеживать запросы с подозрительно малым количеством результатов и вручную пополнять словарь синонимов.
• Кроме того, некоторые понятия невозможно классифицировать одним единственным образом. Так, тот же помидор большинство людей будут искать в разделе Овощи, но ботаники — в разделе фруктов, а выглядят помидоры как ягоды. Опять-таки, единственный способ опознать такие случаи — смотреть статистику сессий, в которых использовался и текстовый поиск, и классификатор.

Неприятная особенность запросов такого типа заключается в том, что, хотя в среднем они не особо часты, они всегда продуцируют неудовлетворительные результаты, которые конечные пользователи не способны опознать как ненормальные и, соответственно, поменять тактику своих действий. Пользователям в таких случаях кажется, что они все делают правильно, а вот архив пустоват, хотя вполне может быть, что на самом деле в архиве есть все необходимое.

User Generated Content

Уже из предыдущих пунктов видно, что поставляющие контент пользователи — не очень надежные генераторы классификации:

• Они не знают, что именно потребители ищут: как конкретной терминологии, так и конъюнктуры.
• Странно рассчитывать, что они, помимо своей компетенции в создании контента, будут еще компетентны в его разметке. Фотографы с Dreamstime, даже будучи финансово заинтересованы в находимости своих работ (не найдут — не купят), не демонстрируют стабильно высокого качества индексации своих работ (например, примерно треть материалов на 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 фотографии нашей Москвы, тем или иным образом связанные с Америкой), основными методами являются:

• Фасетный классификатор. Например, если бы на Dreamstime существовала фасета География, достаточно было бы выбрать Россию, чтобы скрыть и Дэвида Москоу и Москоу из Айдахо. Наоборот, ценитель штата Айдахо мог бы изъять большинство результатов — лично ему ненужных — выбрав в классификаторе США.
• Вручную разделенные поисковые признаки. Если перестроить классификатор так, чтобы ключевого слова «Москва» не было, а были «Москва (Россия)», «Москва (США, Айдахо)» и др., пользователю на таких запросах можно задавать вопрос, какую, собственно, Москву он имеет в виду. В случаях, когда пользователи не умеют искать, этот вариант позволяет сделать наилучший интерфейс.

Опять-таки, оба этих варианта требуют и начального планирования и инфраструктуры, поддерживающей модификацию классификатора на ходу.

Вечная работа

Из предыдущих параграфов видно, что хорошо действующий архив просто невозможно сделать; его можно только делать, в том смысле, что работа эта перманентная. Невозможно единократно построить классификатор, который будет хорошо работать все время.

Вопросы интерфейсознания

Часть проблем поиска связана также и интерфейсом архива, безотносительно к его устройству. Интерфейсная составляющая порождает свои эффекты.

Сделайте попроще, пожалуйста

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

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

Конечно, есть и расширенный поиск, нужный несколько реже:

Но и это не основной интерфейс. Еще больше интерфейса появляется на странице результата — проявляется часть фасетного классификатора:

Обратите внимание, что пользователь не обязан им пользоваться — если его удовлетворяют результаты запроса, классификатор ему не нужен. Однако, если что-то пошло не так, возможность уточнить запрос под рукой. Однако основной классификатор даже не тут, а в наборе ключевых слов, которые привязаны к самой фотографии (см. скриншот выше) — именно благодаря им пользователи могут узнать, какие именно ключевые слова им нужны. Более того, часть этого интерфейса пользователям даже не видна: ключевые слова «Moscow» (город в России) и «Moscow» (города в США) выглядят в интерфейсе одинаково, но в системе они разные (раньше это было видно и в интерфейсе, были видимы «Moscow, Russia» и «Moscow, USA»).

Именно такая проработка и делает поиск действенным — хотя интерфейс фактически не усложняется.

Сделайте поэффективнее, пожалуйста

Из вышеперечисленного следует простой вывод — с ростом архива возникает необходимость все чаще и больше править систему поисковых признаков (расчищать ключевые слова, дорабатывать списки синонимов/омонимов/опечаток, дополнительно размечать малонаходимые объекты и т.п.). Соответственно, если не сделать более-менее быстрого и эффективного интерфейса для этой работы, ей будут в лучшем случае пренебрегать, что скажется на качестве архива для конечных пользователей.

Например, оказалось, что ключевое слово Москва стало слишком заезженным и применено к неоправданно большому числу фотографий, которые плохо находятся, т.е. висят в хвосте поисковой выдачи. Что делать?

Во-первых, необходимо сразу признать, что проблему не удастся решить, не поставив сначала ей диагноз. Соответственно, надо задать себе вопрос, как вообще такое может обнаружиться? Ответ не особо утешительный — если в системе не предусмотрено мониторинга частотности поисковых запросов, то никак. Кроме того, даже если такой мониторинг предусмотрен, как понять, что дескриптор «Москва» действительно применен к слишком многим словам из хвоста? Это значит, что нужны еще и (а) мониторинг малонаходимых объектов и (б) возможность построить срез малонаходимых фотографий по массовым ключевым словам. Без такой функциональности проблему даже не поставить.

Во-вторых, что делать, таки поставив проблему? Конкретно эта характеризуется тем, что фотографий, которые нужно переразмечать, очень много. Соответственно, если не будет быстрого административного интерфейса для таких операций, работа фактически не будет делаться вообще.

В третьих, самый печальный вопрос — кто будет делать эту работу, если в штатном расписании просто не предусмотрена соответствующая работа архивиста?

К сожалению, простого и приятного решения тут нет.

Заключение

Из всего вышеизложенного видно, что архивное дело не совсем зря называется делом. Работы здесь много и не вся она является самоочевидной. Вера же в волшебный алгоритм, который решит все-все проблемы, оказывается на поверку несколько наивной («...как же, Яндекс-то все находит!» — так сколько всего он не находит и об этом мы не можем даже узнать!).

PS. Для заинтересовавшихся темой и желающих углубить свои знания — печалька и огорчение. На русском языке просто нет внятных современных учебников по библиотечному/архивному делу применительно к проблемам поиска (этот факт, собственно, и побудил меня написать этот текст).

Оригинал статьи: http://usethics.ru/blog/lib/archive_for_finding_stuff/

Артур Кротов
Технический директор в Nimax

Совершенно верна мысль, о том, что хорошо действующий архив просто невозможно сделать; его можно только делать. Это относится к любому сервису — не только архивного плана.

Тем не менее, автор статьи преувеличивает преемственность между старыми бумажными архивами и электронными. Общего между ними примерно столько же, сколько между гужевой повозкой и автомобилем: вроде бы и то, и другое передвигается, но под действием разных разных причин. А для создания быстрых и комфортных автомобилей не так уж и много пользы от изучения того, как ведут себя животные в упряжке.

У меня создалось впечатление, что автор статьи предпочитает ручную обработку информации любому другому способу. Да, раньше это был единственный вариант, который позволял вести архив. Однако современные технологии дают возможность распознавать образы и размечать информацию самостоятельно — пускай не идеально, но вполне сносно. Там, где алгоритм бессилен или необходимы инструменты защиты от логических ошибок при разметке пользователями, при злонамеренном искажении информации, на помощь приходит коллаборация. Пользователи архива — не столько авторы контента, сколько посетители, реально ищущие информацию — без проблем помогут с разметкой. Особенно если она подана в игровой форме, возвышает пользователя в сообществе или дает реальные скидки при доступе к данным. Краудсорсинг может творить чудеса, сводя к минимуму необходимость непосредственного участия в процессе совершенствования архива.

Многие проблемы, описанные в статье — синонимы, опечатки, морфология и лексические особенности разных языков — являются серьезной задачей. Однако современные алгоритмы довольно успешно справляются с ней. «Паршивые овцы» не являются сколько-нибудь серьезным препятствием при статистической проверке. Вес ключевых слов, добавленных объекту пользователем, который случайно или специально искажает информацию, стремится к нулю при накоплении на нем отрицательной статистики. Заметьте, такая статистика собирается и автоматически, основываясь на разметке того же материала другими пользователями.