litceysel.ru
добавить свой файл
  1 ... 2 3 4 5

2.1 Основные части системы


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

Исходя из этих требований, было решено реализовывать систему на языке С#, на базе web сервера IIS. Работа системы осуществляется на удаленном сервере, с ОС Windows 2003 server.

Система изначально была поделена на несколько частей. В данном пункте будут описаны основные из них.


  1. Работа с почтой.

В компании есть общий ящик, на который приходят письма от соискателей. Предполагается, что каждой вакансии будет сопоставлен свой код, который будет указываться в поле “Subject” письма. Если код не указан – письмо считается спамом, и игнорируется. В зависимости от кода, конкретные резюме приходят к конкретному сотруднику отдела по работе с персоналом – каждый сотрудник отдела по работе с персоналом отвечает за некоторое число конкретных отделов. Обычно резюме присылается в качестве присоединенных файлов. Каждое письмо разбирается, а присоединенный файл складывается в соответствующую директорию, с которой начинает работу следующая часть системы.

2. Doc Converter.

Основная часть резюме присылается в приложенном файле письма формате doc, rtf, или txt. Для корректной работы непосредственно с резюме необходимо перевести резюме в текстовый вид.

После этого начинает работу основная часть системы: Resume parser.

3.Resume parser.

Данная часть отвечает за непосредственно разбор текстового файла, и выделение конкретных полей. На входе данная часть системы получает текстовый файл, на выходе передает структуру – Data Set - c разобранными полями, которые в последствии отображаются на asp странице.


Рис 3. Принципы взаимосвязи основных частей системы.



2.2 Описание реализации частей.


2.2.1 Исследование проблем

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



  • Doc Converter


Основной формат присылаемых резюме – это документы Microsoft Office, и основная проблема при реализации данной части, в том, что Microsoft Word – хотя и повсеместно распространен, является коммерческим продуктом, а формат документов doc и rtf являются закрытыми, и их формат изменяется от версии к версии.

Естественно, что работать и пытаться извлечь какую-нибуть информацию из них напрямую, без преобразования в другой формат является нетривиальной задачей. Поэтому решено было рассмотреть несколько вариантов формата, в который можно было бы перевести документы Microsoft Word. Это форматы XML (который так же может быть использован для последующего хранения разобранного резюме), html или plain text.

Под OS Linux существуют open source программы, например “catdoc”[15], которые отображает Word файлы в текстовый вид, но, к сожалению, они далеко не всегда корректно делают это, и, весьма вероятно, что с появлением новой версии Microsoft Word, новая версия документов doc и rtf не будет корректно открываться им. По этим же причинам пропала возможность использовать офисные продукты с открытым исходным кодом, поддерживающие файлы Microsoft Office, такие как Star Office [16] или Open Office[17].

Из-за этого было решено использовать инструментарий самого Microsoft Word, который может гарантировать, что от версии к версии переход будет происходить без проблем и гладко. С самого начала было понятно, что этот вариант не очень хорош из-за больших затрат времени: даже просто открытие Microsoft Word занимает достаточно длительное время. С другой стороны, если один раз запустить Word, а после этого проводить манипуляции над файлами затраченное время будет меньше. Так же DocConverter можно выделить в резидентно выполняющийся на сервере процесс, который раз в 10 минут будет проверять наличие файлов в определенной директории, и сохранять их в txt. Тем самым проблема скорости, применительно к данному решению отходит на второй план.


Так же были исследованы варианты преобразования doc и rtf с помощью Microsoft Office в различные типы документов, которые возможно потом облегчили разбор резюме, и способствовали более “красивому” хранению разобранного текста, описанные выше.

Первым из типов, которые были исследованы, был формат xml.

К плюсам данного типа можно отнести то, что не только Microsoft Word, но еще и, например, Microsoft Excel умеет генерировать xml, хотя резюме в формате xls встречаются редко, но всё-таки такие случаи известны.

Файл, в формате xml, который генерирует Microsoft Office из своих стандартных форматов очень громоздок, например фраза, известная каждому программисту, “hello world” (11 байт), в формате doс, преобразованная в xml занимает 3.5 kb, и содержит много абсолютно не нужной для данной проблемы информации о версиях, шрифтах, о человеке, на которого зарегистрирован Microsoft Office и пр.




Рис 4 . Часть XML файла сгенерированного Microsoft Word’ом из doc файла содержащего фразу “Hello World!”


Было предположение, что формат является более-менее универсальным – например, что сам текст (с разметкой и прочей дополнительной информацией) в doc, rtf, xls и пр. размечается примерно одинаковыми тегами, и что не составит труда его разобрать и “вытянуть”, возможно потеряв дополнительную, не нужную для исходных целей информацию, зато сохранив структуру (таблицы, расположение и пр.) – но оно, к сожалению, не соответствует действительности.

После детального рассмотрения данного типа файлов было решено отказаться от использования xml созданных Microsoft Office на базе doc, rtf и пр.

По этим же причинам (громоздкости и трудности разбора), плюс неуниверсальность, в отличие от xml, было решено отказаться от формата html.

Принятый же вариант - сохранять документы в формате plain-text.


Еще один вариант решения данной проблемы, который позднее был принят в качестве основного - “сохранять как” любой документ (как текстовый, так и в формате doc, rtf, html, и любые другие, которые на данный момент поддерживает установленный на сервере Microsoft Office) в формат txt с кодировкой Unicode. В этой кодировке и происходит вся работа системы.

Microsoft Word запускается в “невидимом” для пользователя режиме [18], после этого запускается метод “Save As”, и файл сохраняется на сервере в формате text-only. После этого данный документ закрывается.

К сожалению, хотя данный способ представления документов, созданных Microsoft Office в формат text-only более-менее универсальный, но он так же далек от идеального. Например, при переводе подобным образом резюме, оформленного в виде таблицы, нельзя гарантировать, что порядок, в котором расположена информация будет такой же, какой хотел составитель данного резюме.

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

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


  • Resume parser

      • Разбор ФИО кандидата

Основной частью системы является сам разборщик – Resume parser. На вход он получает путь до файла на сервере, на выходе выдает разобранные поля, которые корректно отображается на asp странице.

Заказчиком было высказано пожелание, которым можно заменить все требования – разбор должен быть максимально точным, возможно в ущерб времени. Под таким лозунгом и началось исследование проблемы.

В рамках работы над Resume Parser’ом было исследовано большое число различных резюме, и сделан вывод, что нет единого стандарта написания резюме, они очень отличаются как по структуре так и по содержанию. Исходя из этого, было решено рассматривать резюме как произвольный текст, в котором, с большой долей вероятности, присутствуют как минимум ФИО кандидата и контакты, хотя, как не странно, были встречены резюме, в которых последние отсутствовали.


Для разбора текста решено было использовать популярное и удобное средство для работы с текстом - регулярные выражения – наиболее удобный и легко адаптируемый инструментарий для работы с произвольными текстами. К счастью, в языке С# есть встроенные регулярные выражения, ничем существенно не отличающихся, например от классических, используемых в языке Perl.

Первыми полями, несомненно, самыми тяжелыми для разбора, стали поля “Фамилия”, “Имя” и “Отчество”.

Перед началом реализации исследовались два подхода:


  1. Лингвистический.

При данном подходе исследовались лингвистические особенности написания имен, фамилий и отчеств.



  1. Наблюдательный

Он появился только из изучения особенностей построения резюме, их закономерностей (как “Правильных”[19] так и не очень) взятых с различных сайтов о работе.


В первом случае были рассмотрены языковые особенности фамилий и имен, и, после прочтения нескольких статей, подобных ([20]) ( а так же изучения найденного словаря фамилий [21]) стало понятно, что для того, чтобы создать работающую систему на основе только данного метода, пришлось бы создавать очень сложную систему отслеживающую и работающую с окончаниями, суффиксами, падежами и пр. Но из-за разнообразия имен и фамилий, и требования возможности с именами не только в именительном, но еще и родительном падежах, при реализации такой системы время ее работы было бы очень велико. И даже после этого всё равно бы остались вопросы по поводу качества разбора. Так же не удалось найти формальных “правил” (признаков), по которым формируются данные поля.

Была предпринята попытка сделать некоторую вероятностную оценку – после работы система искала бы наиболее вероятное сочетание, максимально похожее на ФИО (например, если слово оканчивается на “ов”, “ова”, “ин”,”ина” то + 1 балл к “вероятности что это фамилия”) и т.д. Но и в этом случае о точности разбора при таком подходе не могло быть и речи.


Были рассмотрены продукты, позволяющие работать с произвольными текстами “AOT”[22] и “RCO”[23], но, к сожалению, то, что можно бы было использовать для реализации системы, в этих программах не было.

Помимо неудач были найдены очевидные правила, по которым достаточно большую часть слов в резюме можно было бы “отбросить” как не являющиеся данными искомыми полями.


  1. Имена, фамилии, отчества пишутся с большой буквы.

  2. Отчества оканчиваются на “вич” или “вна” в зависимости от пола.

  3. В русском языке есть несколько вариантов порядка написания фамилий, имен и отчеств:

        • Фамилия Имя Отчество (Иванов Иван Иванович)

        • Имя Отчество Фамилия (Иван Иванович Иванов)

        • Фамилия Имя (Иванов Иван)

        • Имя Фамилия (Иван Иванов)

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

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


Во втором подходе было рассмотрено более 150 различных резюме (не только претендентов на должности в сфере IT), и установлены такие, весьма очевидные, но, тем не менее, очень полезные факты:

  • Фамилии, имена, отчества располагаются в первых строчках резюме (Обычно в первой четверти).

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

  • При написании фамилии, имени, отчества (особенно в англоязычных резюме) зачастую отчество либо совсем не пишут, либо пишут инициалом (например, Иван И. Иванов)
  • Фамилия, имя, отчество разрывается либо пробелами, либо “Enter’ом”, либо словами “Фамилия”, “Имя”, “Отчество”(периодически это случалось из-за того, что данные показывались в таблице, и после воздействия Doc Converter’a они путались местами)


  • Остальные поля

Для разбора остальных полей применялись технологии, описанные выше.

2.2.2 Описание конечной реализации частей системы

1) Работа с почтой

Письма собираются с сервера. Осуществляется проверка, если нет прикрепленного файла, или нет кода вакансии, письмо помечается как “спам”. Тело остальных писем игнорируется. Система cохраняет прикрепленный файлы в директорию.

2) Doc Converter

Если Microsoft Word еще не запущен, то Doc converter вызывает Microsoft Word с флагом “invisible”, что позволяет не показывать пользователю, что он запустился. После этого искомый файл открывается, и методом “Save As” сохраняется в текстовый файл в кодировке Unicode.

Doc файл так же сохраняется во временную директорию, для того чтобы позже оригинал резюме поместить в базу данных, на случай сбоев в системе. Путь до обоих файлов передается основной части данной системы, называемой “Resume Parser”.


3) Resume Parser

Вначале были изучены особенности фамилий, имен, и отчеств. Пользуясь только морфологическими особенностями фамилий и имен качество разбора получалось неприемлемое.

Чуть лучше дела обстояли с отчествами, но, к сожалению, отчества в резюме указываются далеко не всегда.

После неудачной попытки реализации данного подхода, было решено составить “словарь имен”.

Основными проблемами данного подхода было данный словарь найти или составить, решить, как он будет храниться и добиться максимального быстродействия при максимально большом словаре.

Первая проблема была решена при помощи [24] – пожалуй, самого полного словаря имен. Последние утверждение нигде не проверялась, кроме субъективных ощущений. Так же была найдена версия сайта с английскими именами [25].

Словарь признан достаточно полным для решения данной задачи –в нем содержится русских имен женских более 12500, мужских более 15000. В английской версии, женских - более 40000, мужских, чуть меньше.


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

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

После этого было решено создать файлы исходя из первоначальных букв имени, чтобы уменьшить поиск. Данный подход дал небольшой, но всё равно недостаточный выигрыш во времени.

В конченом счете было решено поместить все имена в базу данных, в которой было два поля: Имя и пол (0 или 1).Это позволило еще сократить время поиска, но всё равно не дало приемлемого быстродействия. Стоит заметить, что пол не всегда “берется” в зависимости имени, по причинам описанным ниже.

Тогда и была найдена особенность, о которой уже упоминалось, фамилии, имена, отчества – это два или три слова, идущих подряд, написанных с большой буквы (возможно разделенные словами “фамилия”, “имя”, “отчество”, пробелами или переводами строки).

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

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

Если имя найдено, начинается поиск фамилии и отчества.

В русском языке есть небольшое количество случаев, как могут располагаться Фамилия, имя, отчество относительно друг друга.

Рассмотрим данные варианты на примере.

1)Иванов Иван Иванович

2) Иван Иванович Иванов

3) Иван И. Иванов

4) Иван Иванов

5) Иванов Иван

Отчество, если есть всегда располагается после имени, и оканчивается на “вич”, “вна”(“ich”,”vna”), Либо возможна ситуация, когда отчество представляется только одной буквой.


В зависимости от расположения имени и отчества (или, если его нет, то исходя из имени и количества слов в данном сочетании) в данном словосочетании единственным образом находится фамилия. Исходя из найденного имени, делается вывод о поле кандидата.

Если не найдено ни одного поля, то начинается проверка, не написанными фамилия, имя, отчество в родительном падеже.

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

Разбор Фамилии Имени Отчества кандидата, написанных в родительном падеже

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

Поэтому было решено разрабатывать систему перевода самостоятельно.

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

Именно поэтому, в случае, если указано полное отчество кандидата, определение пола происходит исходя именно из отчества. В ином случае, определение пола происходит исходя из флага “пол” в базе данных имен.

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


  1. Работа с таблицей с именами в родительном падеже (имена переводятся родительный падеж один раз, и каждое имя из таблицы имен в именительном падеже соответствует единственному имени в родительном)

  2. “На лету” преобразовывать слово из резюме, которое рассматривается как имя к именительному падежу, и после этого проводить сравнение c базой данных имен в именительном падеже.

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


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

Для начала опишем некоторые правила, которыми руководствовались при переводе имен русского языка из именительного падежа в родительный и назад.

Данные правила являются “выжимкой” из [26, 27, 28]. К сожалению, все правила автоматизировать не удалось – исключения есть везде, но их единицы, так что к критичной потери качества разбора данные исключения не приведут.

М
ужские имена.

Стоит выделить особые случаи, исходя из которых и будет производится описание. Нас будет интересовать последняя буква – гласная или согласная. В случае если последняя буква согласная, за исключением букв “й” и “ь”, то в конце просто добавляется буква “a” (например Ивана, Петра и т.п.).

В случае если имя заканчивается на “й” или “ь” (например Савелий или Самуэль) последняя буква заменяется на “я” ( например Савелия, Самуэля и т.п).

Когда имя оканчивается на гласную, кроме “а” или “я”, имя не склоняется, а остается таким как есть в именительном падеже (например Отто, Луи, Леонардо и т.п). Стоит заметить, что мужских имен оканчивающихся на гласные буквы достаточно мало.

В случае, когда имя оканчивается на “я”, последняя буква заменяется на “и” (например “Ильи”).

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



Женские имена

В отличие от мужских имен, основная часть женских имен заканчивается на гласные буквы, в большей своей части на “а” или “я”, а те имена, которые оканчиваются на остальные буквы, не склоняются.

В случае, когда женское имя окончатся на “я” или “а”, начинают работать правила, описанные для мужских имен, оканчивающихся на эту букву.


После того как ФИО обнаружено, в случае, если оно написано в родительном падеже, в поле “Имя” происходит вставка имени в именительном падеже, соответствующего найденному имени в родительном.

Тем самым экономится время – не надо преобразовывать найденное имя назад в именительный падеж – всё делается одним запросом в базу данных.

В случае, если присутствует отчество, окончание “ича” заменяется на “ич”, либо “вны” на “вна”, в зависимости от пола кандидата.

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

Преобразование фамилий из родительного падежа в именительный

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


  • Не склоняются женские фамилии оканчивающиеся на согласную, либо мягкий знак.

  • Не склоняются фамилии на -а, -я с предшествующим гласным -и (сонеты Эредия, стихи Гарсия, рассказы Гулиа)

  • Не склоняются русские фамилии, представляющие собой застывшие формы родительного падежа единственного числа с окончаниями: -ово, -аго, -яго (Дурново, Сухово, Живаго, Шамбинаго, Дебяго, Хитрово) и множественного числа с окончаниями: -их, -ых (Крученых, Островских, Польских, Долгих, Седых)

  • Не склоняются украинские по происхождению фамилии на ударное и безударное -ко (Головко, Ляшко, Франко, Янко, юбилей Шевченко, деятельность Макаренко, произведения Короленко).

Исходя из этих правил, не склоняются следующие фамилии:


Женские: оканчивающиеся на согласную, и оканчивающиеся на “ия”, “иа”, “ово”, “аго”,”яго”, “их”, “ых”, “ко”

Мужские: оканчивающиеся на ия”, “иа”, “ово”, “аго”,”яго”, “их”, “ых”, “ко”.

Однако это еще есть например, китайские фамилии, такие как “Ли”, которые не склоняются, и есть еще фамилии которые однозначно не переводятся из родительного падежа в родительный, если не знать ударение. Примером такой женской фамилии в родительном падеже служит фамилия “БочковОй” или “БОчковой”. В первом случае, в именительном падеже фамилия будет “Бочковая”, во втором же ”Бочкова”. Тот же самый эффект наблюдается при переводе из родительного падежа мужских фамилий, например фамилии в родительном падеже “Старинского” может соответствовать две, “СтаринскИй”, либо “СтаринскОй”. Именно по этому на этапе перевода фамилии в именительный падеж возникает бОльшая часть ошибок, но, к счастью процент указания в резюме ФИО в родительном падеже достаточно небольшой, именно поэтому было решено отказаться от склонения в именительный падеж фамилий из родительного падежа, в случае если возможна ошибка. При этом HR менеджеру выдается предупреждение, о том, что возможно фамилия не была переведена в именительный падеж, после чего HR менеджер проверяет, и в случае надобности руками изменяет на ту, которая кажется ему более правильной.

Перевод в именительный падеж мужских фамилий производится по следующему принципу


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

  • Если фамилия в родительном падеже оканчивается на “а”, то последняя буква просто отбрасывается.
  • Если фамилия в родительном падеже оканчивается на “я” то смотрится предпоследняя буква. Если это гласная, то последняя буква заменятся на “й”, если же согласная, то на мягкий знак.


  • Остальные случаи признаются потенциально ошибочными, после чего выбрасывается предупреждение.

Перевод в именительный падеж женских фамилий производится по следующему принципу

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

  • Если фамилия оканчивается на “кой” в родительном падеже, “кой” заменяется на “кая”, если же остальные буквы стоят перед “ой”, оно заменяется на “а”

  • Остальные случаи признаются потенциально ошибочными, после чего выбрасывается предупреждение.

При тестировании данной части системы, оказалось, что “сомнительных” фамилий (информация бралась из списка реальных пользователей сервера mephisto.ccfit.nsu.ru) не более 5% (из более 400 человек). Основную часть погрешности “дают” мужские имена оканчивающиеся на “ий”.


Поиск контактов

Так же основными полями для разбора являются контакты. Для конторы, специализирующиеся на IT не важен адрес, гораздо более важен телефон/icq/email и пр, именно поэтому именно они выделены в основные поля, а адрес выделен в второстепенные.

Естественно, что e-mail разобрать достаточно легко –“@” и “[at]” просто так используются мало, но были некоторые нюансы, которые “всплыли” при тестировании этой части системы, например то, что хост может состоять только из цифр (например, http://911.ru) [29].

Хотя первоначально было решено по максимуму отказаться от слов, характеризующих конкретную информацию (имеется в виду конструкции типа “тел. 222-22-22 ” или “ICQ 1111111”), в случае ICQ UIN (и остальных messenger’ов) это было сделать достаточно проблематично из-за их разнообразия и разнообразия UIN.


Так же, надо отметить, что при разборе e-mail’ов учитывается еще тот факт, что e-mail может быть идентификатором пользователя в MSN, поэтому так же система проверяет, что e-mail не является MSN идентификатором.

Более сложно было производить поиск телефонов.

Изначально понятно, что искать стоит как минимум два типа телефонов – мобильные и городские. Так же следовало учитывать, что телефоны могут быть не только Новосибирские, а еще и Бердские, Искитимские, г. Обь, и больших близлежащих городов. Для того чтобы преодолеть данную проблему, было принято решение посмотреть на номера телефонов, которые могут быть. Изначально было решено не привязываться к скобкам (указание кода города), “-”,”.”,“ ”и прочим знакам разделяющим цифры в номерах телефона, а попытаться найти закономерности исходя из количества цифр.


  1. Городские телефоны “маленьких” городов – 5 цифр

  2. Городские телефоны г. Новосибирска – 7 цифр

  3. “Городские номера” мобильных телефонов г. Новосибирска – 7 цифр.

  4. Городские телефоны маленьких городов с “неполным” кодом номера (с учетом 8-ки вначале 9 цифр)

  5. Полные номера телефонов 10 или 11 цифр (в зависимости, указывают ли 8 или 7 вначале)

При просмотре резюме выяснилось, числа, встречающихся в резюме обычно это:

    • Дата рождения (8 символов)

    • Месяц/год начала работы (6 символов)

    • Год-год работы на “старом” месте - 4 или 8 символов.

Естественно, что были исключения из правил, но они, по сути, подтверждали правило.

Тем самым было решено что телефон, это от пяти до одиннадцати (но не шесть и не восемь) цифр идущих подряд, разделенных символами ” ”, “-”, “.”, “(”, ”)”, “+”.

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

Изначально была идея узнать префиксы мобильных операторов, но решено было этого не делать (так как операторы постоянно чего-то меняют) да и заказчику было не важно четкое отделение мобильных номеров от городских – если мобильный телефон определился как городской или наоборот ошибкой это не считается. Фактически есть телефон № 1 и телефон № 2).


Именно поэтому и здесь было решено привязаться к словам “cell” , “mobile”, “моб.”, “мобильный”.


Разбор второстепенных полей

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

Поиск домашнего адреса осуществляется как поиск по присутствующим там словам “адрес” ”место проживания” “место жительства” “address” “home address”. Для того чтобы не была еще раз выбрана электронная почта, проверяется, что в данной строке (или если она пустая то в следующей) не присутствовал знак @ или [at].

Если этого нет, производится дополнительная проверка на “адресность” данной строки – в строке, должно быть одно из нескольких строк – “ул”, “пл”, “р-н”, “пос”, “м-н”, “пер”, “пр.”, их несокращенные эквиваленты, и переводы на английский язык.

В случае, если этих сочетаний нет, адрес не определится.

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

Полностью, корректно адрес обрабатывается в среднем в 69% случаях.

Поиск “Образование” осуществляется по трем категориям слов -  

“университет”, “институт”, “академия” “училище”, “колледж”

“факультет”

“специальность”.

Стоит заметить, что в “образовании” может быть не одно учебное заведение, именно поэтому поиск осуществляется по всему тексту резюме, даже если уже что-то было найдено.

В случае если в 3 соседних строках (или менее) находятся 2 слова из разных групп, весь блок считается “Образованием”.

Полностью корректно “Образование” обрабатывается в среднем в 73% случаев.

Поиск “Навыков в программировании” был начат в данной (первой) версии системы, была сделана базовая часть, остальная часть будет реализована в следующей версии .

Навыки в программировании – набор полей (технологий, языков программирования, средств разработки и пр, для краткости далее будем называть их “навыками” которые описаны в резюме.


Обычно они описаны совершенно неструктурированно и в разных частях резюме.

В данной части реализован исключительно поиск упоминания некоторых “навыков” в резюме. В следующей версии будет попытка создать какую-то, хотя бы приблизительную оценку качеством владения тем или иным “навыком”.

Из конфигурационного файла с навыками последовательно выбираются “навыки” и просто ищутся в соответствующей строке.

Если “навык” найден, считается, что кандидат хотя бы о нем знает, и помечается, что кандидат этим “навыком” владеет.

Полностью корректно “навыки” в зависимости от количества навыков обрабатывается в среднем в 75-90% случаев.



<< предыдущая страница   следующая страница >>