CC BY
70
УДК 004.056.53
МОДУЛИ ИНФОРМАЦИОННО-ПОИСКОВОЙ СИСТЕМЫ «ИТ-СПЕЦИАЛИСТ»1
Е.С. Чиркин, Н.Л. Королева
Тамбовский государственный университет имени Г.Р. Державина Россия, г. Тамбов. e-mail: fmf@tsu.tmb.ru
В настоящей статье описаны модули информационно-поисковой системы «ИТ-специалист». Описана структура, раскрыты механизмы, позволяющие решить проблемы обучения и профессиональной подготовки ИТ-специалистов с учетом быстрого устаревания профессионально ориентированного контента в информационно-поисковой системе и недостаток квалификации лиц, выступающих в роли экспертов при его формировании и распространении.
Ключевые слова: информационно-поисковая система, структура и реализация.
Одна из острейших проблем профессионального образования в настоящее время -несоответствие структуры профессионального образования потребностям рынка труда: значительное число вузов практически утратило связь с рынком труда, 85 % выпускников школ продолжают обучение в вузах, более 2/3 обучающихся в образовательных организациях профессионального образования - студенты вузов. Вместе с тем сильно ощущается дефицит квалифицированных исполнителей, способных работать с современными технологиями, о чем свидетельствуют результаты опросов работодателей. Поэтому основным приоритетом Государственной программы «Развитие образования на 2013-2020 годы» является модернизация сферы образования в направлении большей открытости, больших возможностей для инициативы и активности самих получателей образовательных услуг, включая обучающихся, их семьи, работодателей и местные сообщества через вовлечение их как в управление образовательным процессом, так и непосредственно в образовательную деятельность [1]. Таким образом, в настоящее время особенно актуальными становятся общедоступные интернет-ресурсы для программ профессионального образования, включая специализированные порталы по направлениям подготовки, в формировании контента которых участвуют и
1 Работа выполнена при финансовой поддержке Российского фонда фундаментальных исследований (проект №12-07-00512).
обучающиеся, и потенциальные работодатели. В настоящей статье описаны структура и особенности реализации профессионально ориентированной on-line системы «ИТ-специалист».
В процессе программной реализации информационно-поисковой системы (ИПС) «ИТ-специалист» были использованы следующие методы и подходы:
1) автоматическая систематизация контента;
2) выделение областей интересов пользователей;
3) построение профессиональной карты интересов отдельно взятого пользователя;
4) защита пользователей и контента от несанкционированного доступа.
В статье мы рассмотрим особенности реализации вышеуказанных методов и подходов в процессе проектирования ИПС «ИТ-специалист».
Первоначально планировалось оформление информационно-поисковой системы в виде веб-сайта и размещение его в сети Интернет. В процессе разработки структура была изменена в пользу выделения ресурсоемких частей проекта в отдельные модули, размещенные на площадке (или площадках) с достаточной вычислительный и ресурсной емкостью, а веб-сайт, размещенный в сети Интернет, выполняет роль интерфейса и площадки для взаимодействия участников проекта (обучаемых, преподавателей, работодателей). Также, по принципу высоконагру-женных сервисов, архитектура была измене-
на в сторону создания запаса по горизонтальной масштабируемости проекта.
В обыкновенных задачах проблема недостаточных ресурсов решают путем увеличения мощности компьютера (добавления оперативной памяти, заменой центрального процессора на более производительный, увеличение дисковой емкости, замена носителей на более быстродействующие) - осуществляют «вертикальное» масштабирование. Однако существует определенный и легкодостижимый предел, после которого наращивать мощность компьютера становится невозможным (вопрос упирается либо в стоимость, либо в предел развития техники), поэтому при другом способе решения -«горизонтальном» масштабировании - система проектируется изначально как способная к распределению по фиксированному (или неограниченному) количеству компьютеров - либо для их совместной работы над проектом, либо для обслуживания отдельных его фрагментов. К особенностям второго подхода можно отнести два важных положения: а) не каждую решаемую на компьютере задачу возможно распараллелить; б) в архитектуру проекта изначально должна быть заложена возможность по ее масштабированию.
Исходя из этих позиций, ИПС «ИТ-специалист» была разделена следующие модули (см. рис. 1), размещение которых возможно на разных (частично зависимых) площадках:
- Веб-сайт - интернет-версия.
- Веб-сайт - локальная версия.
- Серверы с СУБД - главный и, возможно, ведомые (реплики).
- Модуль управления, модули систематизации контента, оценки научности, оценки актуальности, веб-паук и др. - каждый может быть размещен на отдельной вычислительной площадке, требуется только доступ к БД, а также все модули, кроме модуля управления, могут работать параллельно.
- Облачное хранилище - используется для синхронизации модулей и хранения резервных копий.
- Площадка для хранения резервных копий.
Рассмотрим более подробно каждый из модулей ИПС «ИТ-специалист».
Веб-сайт (интернет-версия) построен на основе системы управления контентом (CMS) WordPress, которая была выбрана за простоту архитектуры и возможность внесения усовершенствований путем написания собственных модулей (плагинов). В ИПС используются возможности стандартных плагинов WordPress по написанию и оформлению статей и публикаций, их оценке, мо-дерации, комментированию и прочие. Доступ к основной функциональности отделен штатными средствами CMS (механизмом приглашений), а также рядом административных ограничений. Каждый вновь зарегистрированный участник обязан пройти несложное анкетирование (анкета обслуживается специально разработанным плагином) и ряд тестов (также посредством специально разработанного плагина), подтверждающих заявленную им в анкете квалификацию. Также добавлены плагины работы с глоссарием и синхронизации с локальной версией веб-сайта. Интернет-версия веб-сайта после минимально необходимой настройки может быть размещена на любом походящем хостинге.
Веб-сайт (локальная версия) - представляет «оформление» основного назначения проекта, имеет упрощенный пользовательский интерфейс, служит для доступа к модулю управления. Функционал публикаций и база пользователей вторична по отношению к интернет-версии.
Модуль управления принимает задания через веб-интерфейс (локальный веб-сайт), не имеет собственного интерфейса, представляет собой набор скриптов, заданий для планировщика операционной системы (например, для cron) и прикладной интерфейс взаимодействия (API). Модуль управления предельно упрощен для увеличения надежности (быстродействие его так же достаточно высоко по сравнению со всеми остальными модулями проекта), это единственный модуль, который исполняется в единственном экземпляре - чья работа не может быть распараллелена, что и не требуется. Назначение - управляет очередью заданий (создает файлы-задания для исполнения прочими модулями) и их приоритетами. Проверяет окончание заданий, перезапускает их при необходимости, информирует локальный и
интернет-сайты (т.е. пользователей системы) о статусе исполнения заданий, степени их завершенности и результатах исполнения. Под заданиями в данном случае подразумеваются вызовы необходимых модулей ИПС
с соответствующими параметрами, передача результатов их работы другим модулям. При необходимости модуль управления рассылает административные уведомления посредством электронной почты и SMS.
Рис. 1. Модель информационно-поисковой системы «ИТ-специалист»
В качестве системы управления базой данных выбран MySQL как одна из самых известных, распространенных, проверенных и надежных СУБД. Используется движок на основе InnoDB - так как для распределенного проекта особенно важно поддержание целостности базы данных (фактически, логически распределенной вне зависимости от формы хранения) для недопущения несогласованного состояния отдельных функциональных модулей проекта, что достигается использованием транзакций, которые и предоставляет InnoDB. Немаловажно, что In-noDB использует индексы типа B+ tree, что учтено при добавлении в таблицы полей -суррогатных индексов.
Обычно в высоконагруженных проектах СУБД является узким местом, практически
не поддаваясь масштабированию. Для увеличения быстродействия системы часто либо переходят на другую СУБД (например, с поддержкой кластеризации), либо прибегают к алгоритмическим ухищрениям. В нашем проекте сервер БД MySQL развернут на высокопроизводительном компьютере в двух независимых экземплярах, между которыми настроена репликация. Это сделано с тремя целями: во-первых, отработка процедуры горизонтального масштабирования (при наличии одного главного MySQL-сервера и любого количества реплицируемых, запись (изменение данных) ведется на главный сервер, а запросы на чтение можно отправлять на любой реплицируемый (таким образом возможно значительно повысить быстродействие всей системы), а во-вторых, так как
ИПС является по своей сути ресурсоемким проектом, это сделано для испытаний пределов запасов производительности компьютера, дисков и оперативной памяти. В-третьих, репликация (разумеется, при размещении реплик на физически другом сервере) - своеобразная замена резервной копии, способной быстро заменить собой главный сервер в случае его сбоя.
Облачное хранилище используется как накопитель, постоянно доступный в сети Интернет (доступ осуществляется по протоколу WebDAV). Исходя из соображений безопасности и ограниченного свободного дискового пространства на хостинге с интернет-версией веб-сайта, а также следуя общей идеологии проекта - надежности и возможности самовосстановления, синхронизация не сделана через веб-интерфейс сайта, и сам хостинг не используется как накопитель. Модуль управления периодически (ведется разработка механизма подключения по уведомлению) проверяет поступление новых материалов, требующих их обработки, загружает их и формирует очередь заданий. По аналогичному принципу возвращаются статус и результат обработки. Вместо облачного хранилища может использоваться любой сервер, доступный по протоколу FTP (но при этом нет возможности использовать доступ по уведомлению -обмен производится только посредством регулярных проверок).
Резервное копирование осуществляется комплексом скриптов, часть из которых запускается по расписанию. Ввиду значительного объема хранимой информации (собственно вся информация проекта плюс поисковые индексы), выделено два сценария: сокращенный вариант - сохраняется только минимально необходимая информация и структура индексов, и полное сохранение всей информации в резервной копии, включая индексы. Сокращенный сценарий запускается ежедневно, сохраняет необходимый минимум данных на хранилище резервных копий, облачное хранилище и ряд удаленных носителей. Полный сценарий запускается вручную раз в две недели.
В настоящее время процедура сокращенного восстановления в ручном режиме интернет-версии веб-сайта занимает не-
сколько десятков минут (до часа), остального комплекса (полностью в автоматическом режиме) - около недели. При этом комплекс готов обслуживать (принимать задания) пользователей немедленно после восстановления работоспособности интернет-версии веб-сайта. Полный функционал ИПС будет доступен после восстановления и перестроения утерянных поисковых индексов. Полное восстановление в настоящее время занимает около суток, полное перестроение поисковых индексов - до недели непрерывной работы. Индексы перестраиваются последовательно, временно повышается приоритет индексов тех документов, которые необходимы для исполнения высокоприоритетных заданий, находящихся в текущей очереди. Очередь выполненных заданий модуля управления хранится в течение месяца, восстановление начинается с исполнения необходимых из них. Дополнительные скрипты по принудительному перезапуску проекта в режиме пересоздания индексов и проверки целостности способны в любой момент проверить и восстановить работоспособность проекта.
Модуль «веб-паук» - основной модуль сбора информации для поисковой системы. Представляет собой специальную программу, посещающую заданную веб-страницу и другие (по списку правил), на которые есть ссылка с нее; закачивает RSS-новости. Помимо этого модуль ведет учет частоты обновления ресурса для определения необходимости повторного захода. Может исполнять задания в автономном режиме - без соединения с базой данных ИПС.
Модуль извлечения текста - извлекает текст из всех необходимых документов различных форматов. В настоящее время поддерживаются форматы Microsoft Office (DOC, DOCX, RTF), HTML, MHT, OpenOf-fice.Org (ODT), текстовые документы в любой кодировке.
Модуль представляет собой программный комплекс в составе следующих компонентов:
1. Программа определения кодировки текста и преобразования текстового документа из любой кодировки в UTF-8. Используются статистические особенности текста и ряд эвристических приемов для
определения действительной кодировки текста и получения содержания документа в форме, пригодной для дальнейшей обработки.
2. Программа определения формата документа. Используются шаблоны и эвристические приемы для определения формата документа и последующего преобразования в текст с использованием текстового процессора OpenOffice.Org через его штатный API.
3. Программа преобразования в текст (оригинальный код, а также с использованием текстового процессора OpenOffice.Org (в перспективе - с использованием Microsoft Office)). Наблюдения показывают, что невозможно преобразовать подряд более 10-20 тысяч документов - видимо из-за утечек памяти в офисном пакете и в операционной системе происходят различные сбои. Поэтому офисный пакет запускается в изолированной среде - в VirtualBox. Программный комплекс отслеживает работоспособность виртуальной компьютерной системы и при необходимости перезапускает его. Помимо этого с хост-системы в автоматическом режиме забираются файлы для преобразования, преобразовываются и отдаются результаты работы.
База данных «программные продукты» содержит названия самых распространенных программных продуктов, имеющих отношение к обучению ИТ-специалистов и их последующей профессиональной деятельности. Каждая запись содержит: название компании-разработчика (или автора), полное и сокращенное название программного продукта, версия, дата выхода, имя конкретной версии (если есть), краткое описание. В работе ИПС данная база данных позволяет устанавливать точное название программного продукта по его контексту и хронологию упоминаемых фактов, и другие, не упоминаемые, но подразумеваемые факты любой публикации.
В базу данных «новости» помещаются новости (импорт из лент новостей RSS) из сферы информационных технологий с ряда доверенных с точки зрения экспертов ресурсов. В настоящее время используется для хронологической привязки - поиска первого упоминания какого-либо события, термина,
лица, программного продукта и т.п., и установления первоисточника.
База данных «термины» содержит термины из области информатики и защиты информации, а также термины, имеющие отношение к информатике, информатизации и телекоммуникациям из действующего законодательства, синонимы данных терминов (собственно синонимы, аббревиатуры, иноязычные эквиваленты), словарные статьи. Также для каждого термина присутствует дата его введения (первого упоминания), дата выхода из повсеместного употребления (для юридических документов -дата его прекращения действия или дата выхода документа, его заменяющего). Для объективности и возможности проверки и внесения исправлений, каждая характеристика термина снабжается названием документа (и, возможно, его URL), из которого она была взята.
Дополнительно к БД «термины» существует база данных противоположного назначения, содержащая жаргонные и сленговые термины, общеупотребительные слова, искаженные и ошибочные написания названий, аббревиатур, имен собственных, событий и явлений. Данная база данных позволяет ее использовать как «переводчик» сленга в правильную терминологию (для восстановления контекста в документе), а также как «черный список» в процедуре автоматизированного определения степени научности той или иной публикации.
База данных «источники» содержит: а) аннотированный каталог ссылок на документы, полезных для изучения каждым ИТ-специалистом (каждая статья в БД характеризуется, помимо выходных данных (автора, названия, ссылки, аннотации), разделом ИТ, а также экспертами проставляется указание (факт) научности статьи); б) автоматически пополняемый список публикаций. Каждая запись содержит максимально точные выходные данные соответствующей публикации; в) упрощенные по структуре и форме представления текстовые копии документов, помещенных в ИПС для индексирования. В дальнейшем эта информация используется для проверки достоверности ссылок из библиографии, индексирования содержания, проведения поиска, каталогизации и т.п.
Модуль оценки актуальности документа. ИПС оценивает актуальность (современность) каждого внесенного в нее источника посредством построения специальной хронологической карты - по датам упоминаемых терминов (по БД «термины»). Если это невозможно, производится анализ содержания на более глубоком уровне - по сопоставлениям фрагмента анализируемой статьи и словарной статьи распознается упоминание термина (т.е. когда последний явно не употребляется). Таким образом составляется оценка актуальности источника.
Дополнительно в его тексте распознаются даты (на русском и английском языках), а также на русском - относительные даты: например, пусть существует конструкция вида «<...> за полгода до анонса Windows 8 состоялась презентация <...>». Система проанализирует эту конструкцию следующим образом: 1. Фрагмент «за полгода до» - указание на арифметическое действие «минус 6 месяцев» для даты, вычисленной из последующей конструкции (алгоритм заложен в ИПС на этапе создания). 2. Фрагмент «Windows 8» будет преобразован в «Microsoft Windows 8», так как маловероятно, что речь идет о чем-то другом, чем данная операционная система (определяется по базе данных «программные продукты» и контексту) и вновь анализируемый фрагмент будет «анонса Microsoft Windows 8» (*). 3. Далее возможно два варианта: если ранее в базе данных новостей была в какой-то момент времени распознана фраза вида «состоялся анонс Windows 8», то за дату искомой фразы (*) будет взята дата публикации данной новости, если же подобного фрагмента ранее найдено не было, то за дату искомого фрагмента будет взята дата выхода Windows 8. И будет отнято 6 месяцев по предшествующей фразе.
Таким образом, будет достаточно точно определен временной интервал упоминаемого первоначального события и, следовательно, определена актуальность информации, изложенной в документе.
Модуль систематизации контента. Не-пересекающиеся основания для классификаций первоначально вручную создаются экспертами (путем оценки документов в БД «источники») по ряду признаков, в настоящее время это:
- предмет (учебная дисциплина);
- область (связь и телекоммуникации, защита информации, прикладная информатика, программное обеспечение, а также отношение к действующему законодательству и др.);
- проблемно-ориентированное основание. Условно каждая публикация при этом считается направленной на решение конкретной прикладной проблемы. Например, к факту «предупреждение антивируса об обнаруженной угрозе» будут относиться публикации: лабораторные работы по обучению с данным антивирусом; тренажер по работе с данным антивирусом; публикация об основных вредоносных угрозах - современных и исторический экскурс; общие сведения о вредоносных программах; рекомендации по предотвращению подобных угроз в будущем; рекомендации по ликвидации последствий; рекомендации по обновлению операционной системы, ее компонентов и установленного программного обеспечения. То есть, в целом, пользователь «с проблемой», при желании, изучивший данный пакет материала, получит не только исчерпывающий ответ, но и, в идеале, впоследствии будет способен справиться не только с такой же проблемой, но и всеми аналогичными.
Автоматизированная систематизация контента осуществляется, в основном, с помощью БД «термины». По тексту составляется карта используемых терминов. Каждое слово в контексте через словарные статьи «раскрывается», т.е. происходит отнесение слов и словосочетаний к тому или иному термину с различным весом (коэффициентом). Понижается коэффициент общеупотребительных слов и словосочетаний, выделяются вводные и связующие обороты и др. Потом отсекаются слова, не удовлетворяющие определенным границам, составляется список терминов, описывающих контент -множество слов, в сжатой форме описывающих содержание статьи. На основании знания предметных областей - по базе уже существующих ресурсов, проводится второй этап анализа - выделение онтологии предметной области. Строятся две онтологии: первая строится на основе размещения экспертами в той или иной классификации ре-
б5
сурсов из БД «статьи» - это позволяет достаточно точно классифицировать статью без привлечения эксперта, но предположив его выбор; вторая строится исходя из множества употребленных терминов, характерных для определенной области ИТ.
Модуль оценки научности текста. Степень научности текста определяется ИПС по совокупности следующих показателей:
1. По частоте употребления научных терминов (нетрудно заметить, что любая академическая статья, в том числе, узкоспециализированная, изобилует терминами из соответствующей области науки) [2].
2. Частотой употребления языковых конструкций (словосочетаний), характерных для научных статей. Для построения частотного словаря составлялось простое большинство русскоязычных оборотов по общедоступным академическим источникам - если любая пара (или больше) слов из одного предложения встречается более чем в трети всех текстов, ее можно считать характерной для научной речи; дополнительно понижался рейтинг для этих же словосочетаний, если они употреблялись более чем в 5 % всех доступных источников статей [2].
3. Текст не должен содержать выражений из словаря сленговых терминов.
4. Текст не должен содержать «эмоциональных» знаков препинания (в конце предложений). Например, таких, как «!», «?!», «???», символов-смайликов и их представлений в текстовом виде. Для уменьшения вероятности ошибки проводится распознавание контекста - например, символ «!» во многих языках имеет значение «логическое отрицание», а повсеместное употребление слова «Warning!!!» может означать текстовое выделение в книге для начинающего.
5. Орфографическая проверка должна показать незначительное количество ошибок (считается количество однотипных и разнотипных ошибок).
6. Существование источника (по БД «источники»). Например, некий недобросовестный студент в своей публикации может сослаться на статью, которой достоверно нет в упоминаемом источнике, так как на ее месте (на указанных страницах) на самом деле находится совсем другая публикация.
7. Для электронных изданий проводится поверхностный анализ содержания - на наличие заимствования: а) на точное заимствование - проверка на цитирование, либо плагиат, в зависимости от объема и оформления; б) на неточное заимствование - как проверка факта достоверности ссылки, например существует ли вообще пересечение ссылающегося текста и якобы источника.
8. Не оказывает влияния на оценку, но по запросу отображается читателю - наличие других публикаций, ссылающих на данный источник.
9. Не оказывает влияния на оценку, но по запросу отображается читателю - оценка покрытия источниками текста публикации (например, может оцениваться для оценки степени оригинальности публикации).
10. Проводится анализ на наличие заимствований из одного и того же документа, но размещенного в разных источниках (что выглядит как использование разных источников, но, фактически, таковым не является).
11. Проводится анализ на наличие само-плагиата (что характерно для научных публикаций).
12. Проводится анализ на наличие заимствований из источников, не являющихся объектом авторского права.
В ходе реализации были опробованы различные принципы организации данного «хранилища» (реляционная база данных MySQL, поисковый сервер Sphinx, хранение в различных префиксных и суффиксных деревьях в оперативной памяти и пр.). В конечном итоге наиболее эффективными оказались два решения - дерево (в оперативной памяти) и простая таблица базы данных. От первого из них пришлось отказаться по причине экспоненциального роста объема памяти, требуемого на накладные расходы для хранения префиксного дерева и сведений о документах, однако данный подход является самым быстродействующим. Например, для построенного дерева объемом около 48 Гб, хранящего в себе около 20000 документов (в среднем, по 10000 слов каждый), поиск по фрагменту длинной до 5000 слов занимает менее двух секунд (процессор 3,2 ГГц). Однако данный
подход ограничен количеством доступной оперативной памяти, переход к хранению фрагментов дерева на носителе полностью лишает данный способ преимуществ перед обычной реляционной базой данных из-за накладных расходов по перестроению дерева. Поэтому, в конечном итоге, для хранения поискового индекса была выбрана реляционная база данных.
Собственно, хранение осуществляется в нескольких логически эквивалентных таблицах, каждая из которых представляет из себя логическое «хранилище», деление осуществляется по источнику документа - Интернет, доверенные сайты, загруженный пользователями контент и др. Подобное деление также позволяет хранить многоверси-онный индекс - для осуществления возможности параллельного использования и разработки. Например, индекс с кодом («версией») № 0 является пословным по документу и используется практически во всех последующих версиях алгоритма. Слово «версия» в данном случае не имеет хронологического значения - это лишь число, отличающее один индекс от другого.
Всего в таблице получились следующие значимые поля:
- version - код (версия) индекса;
- hash - идентифицирует данное текстовое представление документа (MD5-хэш от текста);
- wordno - является стартовым номером слова в документе, с которого был построен данных индекс (что это - слово, шингл, пассаж или какая-то другая логическая единица индекса, определяется полем version);
- i0 - «основной» индекс;
- i9 - «полный» индекс или фрагмент, по которому строился «основной» индекс (зависит от version, хранимое значение сравнивается только с записями, имеющими одинаковый код версии (поле version));
- ii - поле - суррогатный индекс, получаемый сочетанием полей version и i0.
Выборка осуществляется по представлению, построенному по всем таблицам поискового индекса. Разбиение по отдельным таблицам было сделано для достижения двух целей:
1. Повышения быстродействия - начиная с некоторого объема индекса базы данных InnoDB происходит катастрофическое падение скорости перестроения данного индекса, эта величина близка к полутора объемам оперативной памяти, выделенной под сервер базы данных.
2. Физическое представление записи может различаться в разных таблицах.
Ниже приведены некоторые статистические параметры разработанной системы, эксплуатируемой в тестовом режиме. Конфигурация сервера базы данных: RAM - 40 Гб, CPU - Core i7 3820 3.4 ГГц, MySQL v5.5.30 64-bit, движок базы данных - InnoDB, innodb_buffer_pool_size = 20G.
1. Количество хранимых текстовых представлений русскоязычных документов: ~350000.
2. Объем хранимых текстовых представлений русскоязычных документов (в кодировке UTF-8): ~15 Гб.
3. Объем поискового индекса (суммарный объем таблиц и индексов в базе данных): ~250 Гб.
4. Средний размер документа: 7-12 тыс. слов.
5. Задержка между постановкой документа на проверку и началом обработки очереди: 0-60 сек.
6. Время исполнения ALTER TABLE над таблицей индекса: от 2 ч. до 1 нед.
7. Среднее время получения текстового представления документа (DOC, DOCX и аналогичные) из 15 тыс. слов: 3 сек.
8. Среднее время получения текстового представления документа (RSS, XML, HTML и аналогичные) из 15 тыс. слов (кодировка -неизвестна или неверно указана): 20 сек.
9. Среднее время добавления документа из 15 тыс. слов в поисковый индекс: 10 сек.
10. Среднее время поиска документа из 15 тыс. слов в базе документов: до 2 мин.
11. Среднее время подготовки полного отчета модулем оценки научности текста (имеет квадратичную зависимость от объема документа) для 1 документа: 2-30 мин.
Приведенная статистика позволяет сделать вывод о возможности последовательной ежедневной эксплуатации разработанной системы при ограниченном количестве пользователей (не более 1000 запросов на про-
верку в сутки), а также использование системы не более чем пятью экспертами для «глубокого» анализа текста посредством построения полного отчета модулем оценки научности текста.
Описанные выше модули в составе информационно-поисковой системы позволяют упростить решение следующих проблем обучения и профессиональной подготовки ИТ-специалистов: а) большой объем несистематизированной непроверенной информации, используемой в обучении; б) высокая скорость развития информационных технологий в совокупности с легкостью распространения информации в сети Интернет приводит к ложному впечатлению актуальности тех или иных данных, в действительности устаревших; в) систематизация контента осуществляется непрофессионалами и быстро устаревает; г) низкое качество публикаций, связанное не с содержанием, а с изложением - с использованием бытовой и просторечной лексики; д) высокая скорость распространения информации в сети Интернет с несоблюдением норм заимствования приводит к подмене или утере (намеренно или в результате небрежности) авторства текста.
Предложенная модель информационнопоисковой системы позволяет решить основные проблемы, лежащие перед обучаемым в процессе самостоятельного получения им профессиональных компетенций. С другой стороны, ИПС «ИТ-специалист» значительно облегчает труд преподавателей и экспертов, сокращая обработки поступающей информации, показав наличие в ней явных (в том числе, возможно, умышленных) ошибок и, самое главное, представить объективную оценку содержимому.
Список литературы
1. Развитие образования на 2013-2020 годы: государственная программа Российской Федерации [Электронный ресурс]. URL: http:// минобрнауки.рф/новости/2712
2. Зеленков Ю.Г., Сегалович И.В. Сравнительный анализ методов определения нечетких
дубликатов для WEB-документов // Труды 9-ой Всероссийской научной конференции «Электронные библиотеки: перспективные
методы и технологии, электронные коллекции» RCDL’2007: сб. работ участников конкурса. Переславль-Залесский, 2007. Т. 1. С. 166-174.
3. Чиркин Е.С., Королева Н.Л. Направления развития поиска и систематизации контента в профессиональном образовании в области систематизации контента // Вестник Тамбовского университета. Серия: Естественные и технические науки. Тамбов, 2012. Т. 17. Вып. 1. С. 206-208.
References
1. Razvitie obrazovanija na 2013-2020 gody: gosu-darstvennaja programma Rossijskoj Federacii [Elektronnyj resurs]. URL: http://minobrnauki.rf/ novosti/2712
2. Zelenkov Ju.G., Segalovich I.V. Sravnitel'nyj
analiz metodov opredelenija nechetkih dublika-tov dlja WEB-dokumentov // Trudy 9-oj Vseros-sijskoj nauchnoj konferencii «Elektronnye bib-lioteki: perspektivnye metody i tehnologii, elektronnye kollekcii» RCDL’2007: sb. rabot
uchastnikov konkursa. Pereslavl'-Zalesskij, 2007. T. 1. S. 166-174.
3. Chirkin E.S., Koroleva N.L. Napravlenija razvitija poiska i sistematizacii kontenta v profession-al'nom obrazovanii v oblasti sistematizacii kon-tenta // Vestnik Tambovskogo universiteta. Serija: Estestvennye i tehnicheskie nauki. Tambov, 2012. T. 17. Vyp. 1. S. 206-208.
THE MODULES OF INFORMATION RETRIEVAL SYSTEM «IT EXPERT»
E.S. Chirkin, N.L. Koroleva
Tambov State University named after G.R. Derzhavin Tambov, Russia. e-mail: fmf@tsu.tmb.ru
This article describes the modules of information retrieval system "IT Expert". Describes the structure and mechanisms to solve the problems of education and training IT professionals with the rapid obsolescence of professionally-oriented content in a retrieval system, and the lack of qualifications of individuals who act as experts at its formation and propagation.
Key words: information retrieval system design and implementation.
