![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
задопихание
Как backpropagation выводится из градиентного спуска:
https://babkin-cep.blogspot.com/2022/10/optimization-4-backpropagation-for-last.html
https://babkin-cep.blogspot.com/2022/10/optimization-5-backpropagation-further.html
https://babkin-cep.blogspot.com/2022/10/optimization-4-backpropagation-for-last.html
https://babkin-cep.blogspot.com/2022/10/optimization-5-backpropagation-further.html
What is the purpose of this neural network?
Re: What is the purpose of this neural network?
Re: What is the purpose of this neural network?
Откуда ты знаешь, что пофиг?
Вряд ли NN, специализирующаяся на распознавании картином, будет хорошо работать с текстами.
> Я пока играю с игрушечными примерами.
Какую проблему решают твои игрушечные примеры?
Re: What is the purpose of this neural network?
Смотря для какой цели и смотря как подключить.
> Какую проблему решают твои игрушечные примеры?
Никакой практической. Пока что только имитировать простую гладкую функцию. Мне интересно посмотреть на то, что там внутри происходит, в очень мелком масштабе.
Re: What is the purpose of this neural network?
У меня есть практическая задача: взять резюме кандидата, и извлечь из этого резюме ключевые слова, по которым можно искать работу для этого кандидата.
Думаешь neural network, в настройке которой ты упражнялся, поможет в решении этой задачи?
> только имитировать простую гладкую функцию
Для того, чтобы имитировать простую гладкую функцию - нет необходимости использовать neural network.
Re: What is the purpose of this neural network?
> Думаешь neural network, в настройке которой ты упражнялся, поможет в решении этой задачи?
Ну, во-первых, я пока упражняюсь еще не в настройке, а в построении механизма. Мне хочется понять, как оно работает. В реальности большинство data engineers используют механизмы как черный ящик, плохо понимая, как он внутри работает.
Во-вторых, твоя задача, наверное, хорошо решается более простым способом? От простого поиска по хэш-мапу до построения байесовой модели (которая по своей сути соответствует одному слою нейронов, по одному нейрону для каждого возможного результата). Для отдельных слов или для словосочетаний из двух-трех слов. Или ты пробовал и не решается? Ну, можем обсудить.
Для Байеса у меня, кстати, есть примеры на Перле: https://sourceforge.net/projects/exbayes/ . Циферки в именах файлов соответствуют номерам в серии постов в блоге, где они обсуждаются.
> Для того, чтобы имитировать простую гладкую функцию - нет необходимости использовать neural network.
Эта задача интересна тем, что она тривиальна. И если методы тренировки показывают странные эффекты (а они показывают) на такой тривиальной задаче, то они будут их показывать и на более сложных задачах. Эти эффекты общеизвестны, и на более сложных задачах их пытаются решать шаманизмом: "давайте возьмем другие случайные начальные значения", "давайте сдвинем диапазон случайных значений", "давайте возьмем больше нейронов", и т.д. Потому что там трудно проследить, что вызывает эти проблемы и какой именно получается подробный эффект от разных попыток решения. А на маленькой и тривиальной задаче все это видно хорошо. И мне интересно в этом поковыряться. Без кратковременной практической выгоды, просто так (ну а долговременно - кто знает, может когда-то пригодится).
Ну, а в следующем этапе у меня запланировано попробовать классическую простую задачу - распознавнаие цифер из набора рукописных образцов.
How to create a job search query from resume text?
Решается, но, пока, не очень хорошо.
Мы создаем и поддерживаем общий список skills (keywords).
Соответственно, несложно найти эти skills в тексте резюме.
Также, мы считаем частоту использования каждого skill.
В общем списке мы также считаем, насколько часто каждый skill используется при поиске работ и насколько часто используется в описании работ.
Чем больше соотношение "частота поиска"/"частота использования в работе" - тем более важный такой skill.
Можно взять один, два или три самых важных skills и использовать для поиска работ.
Это работает, но не идеально.
Например, вот это резюме:
https://www.postjobfree.com/resume/adsn0r/customer-service-clerk-new-city-ny
превращается в набор skills:
1) warehouse
2) sales
3) customer service
4) data entry
То есть можно автоматически получить такой job search:
warehouse sales
Но, хотелось бы, результат получше, что-нибудь вроде:
(manager or management) (warehouse or sales or quality or control or dairy or shop or frozen or osha)
Но как автоматически добиться подобного результата (job search query) - пока не совсем понятно.
Как ты думаешь, подходит ли NN для решения подобных задач?
Re: How to create a job search query from resume text?
Ваше нынешнее решение по соотношению частот - Байесово, только видимо независимо воссозданное из логических рассуждений. Я как-то вообще в таком ракурсе выбирания слов для поиска не думал.
Я думаю, что первое, как его можно улучшить - это использовать больше контекста, в как минимум двух смыслах:
1. Этот конкретный человек у тебя популярно написал что он хочет в разделе Objectives. Просто выделять этот раздел и считать слова из него более важными. Ну и можно искать предолжения с фразами типа "looking for". Аналогично, можно считать более недавние работы более важными.
2. Использовать не отдельные слова, а словосочетания. Например, data warehousing имеет очень другой смысл, чем просто warehousing и чем data entry. Если тебе не хочется индексировать все встречающиеся словосочетания, то можно начать с поиска более важных отдельных слов, а потом только их взять с соседними словами.
Третье, тоже связанное с контекстом - если ты ищешь по резюме, то надо искать слова не сами по себе важные, а важные в контексте резюме.
Про конкретно NN я не знаю. Использовать точно можно, но я не знаю, будет ли от них выгоды гораздо больше, чем от более простых методов. То, что NN умеет делать гораздо лучше простого Байеса - отличать случаи типа "А, но не Б, или Б, но не а" и противоположные. Плюс для всего нужен тренировочный материал, в котором вручную размечены правильные ответы.
Re: How to create a job search query from resume text?
Почему анализ частоты использования skills ты называешь "байесовой" моделью?
> 1. Этот конкретный человек у тебя популярно написал что он хочет в разделе Objectives. Просто выделять этот раздел и считать слова из него более важными.
Мне кажется, получится не очень хорошо. Давай рассмотрим на примере того же резюме:
"Management" и "managerial" - правильно. Но "develop" и "development" - неправильно.
Кроме того, упущены другие важные skills: "customer service", "deposits", "store", "sales", "quality control".
> искать предолжения с фразами типа "looking for"
Анализ использования looking for - показывает, что:
1) "looking for" указывает на важные skills лишь иногда.
2) "looking for" используется лишь в примерно 3% опубликованных резюме.
> 2. Использовать не отдельные слова, а словосочетания.
Это мы уже делаем: выделяем фразы из двух слов.
> надо искать слова не сами по себе важные, а важные в контексте резюме
Как определить какие слова - важные в контексте резюме?
Re: How to create a job search query from resume text?
Потому что частота - она же вероятность. В твоей байесовой модели используется событие - найм. Ты считаешь частоту встречания скилла у работников до найма, это твоя априорная вероятность, и частоту скилла у работ, то есть работников после найма, это твоя постериорная вероятность. Когда ты их делишь, ты получаешь условную вероятность найма с таким скиллом (ну, не сосем вероятность, а шанс, который имеет тот же смысл и эквивалентен вероятности для целей максиимзации), и отбираешь скиллы с наибольшей условной вероятностью, то есть дающие максимальную пользу в найме. Это аналогично тому, как в классических экспертных системах 80-х годов выбирался следующий вопрос чтобы задать клиенту - такой вопрос, который позволит извлечь максимум информации в имеющемся контексте.
Байесовую модель можно развернуть и дальше - получить рейтинг соответствия резюме к вакансии исходя из полного списка скиллов, перечисленных в обоих. Ну, соединять каждое резюме с каждой вакансией может быть утомительно, но можно сначала сделать поиск как у тебя есть для грубой фильтровки, а потом посчитать рейтинг для найденных вакансий и отсортировать результаты поиска по этому рейтингу.
> "Management" и "managerial" - правильно. Но "develop" и "development" - неправильно.
> Анализ использования looking for - показывает, что:
Эти советы надо использовать не тупо, а с умом. Я надеюсь, ты не ожидаешь, что я тебе тут за десять минут выкачу готовое решение во всех подробностях. Есть словосочетания, которые указывают на то, что рядом с ними выражаются желания кандидата. Например, "objective", "looking for", но не только они, а и прочие. Это не рецепт, а направление для дальнейшего изучения. Вот data engineers и занимаются всеми этими деталями, в частности поисками того, какие конкретно фразы дают какие добавления к смыслу.
Кстати, "develop" и "development" тут правильно, это часть "employee development", руководящего скилла. Это пример из той же области, что "data warehousing" - совсем не то же самое, что просто "warehousing".
> Как определить какие слова - важные в контексте резюме?
Один пример - те слова, которые выражают желание работника, цель его поиска работы. Другой пример - скиллзы в недавних работах гораздо более важны, чем скиллзы в работах десятилетней давности. Ну вот тебе в качестве очень простого примера, если есть человек, только что закончивший институт по инженерной специальности, но во время учебы работавший баристой, то ему будут интересны в первую очередь работы в инженерии, а не баристы.
У тебя, кстати, есть хорошая возможность набрать много тренировочных данных, если хранить историю резюме. Вот у тебя есть человек с неким резюме, ищет работу. Потом через какое-то время опа, он же закачивает новое резюме, в котором добавилась новая работа. Это твой сигнал, что человек с таким-то резюме хорошо подошел для вот такой работы.
Skills: frequency vs Bayesian probability
Да: частота использования скилла в резюме - кореллирует с вероятностью того, что работника наняли из-за этого скилла.
> и частоту скилла у работ, то есть работников после найма, это твоя постериорная вероятность.
Нет.
Частота употребления скилла в описании работы - коррелирует с востребованностью этого скилла на этой работе. А вовсе не с тем, сколько работников на этот скилл уже наняли.
> Когда ты их делишь, ты получаешь условную вероятность найма с таким скиллом
В данном случае, чтобы получить вероятность найма с таким скиллом, надо умножать эти две частоты использования, а не делить их друг на друга.
> Байесовую модель можно развернуть и дальше - получить рейтинг соответствия резюме к вакансии исходя из полного списка скиллов, перечисленных в обоих.
Да, примерно так можно считать match score.
Но это слабо похоже на байесовую модель.
Re: Skills: frequency vs Bayesian probability
Нет, умножать не надо. Чтобы понять байесову формулу, проще всего начать с рисования квадрата, который будет представлять всех кандидатов. Потом его поделить на две части: в одной части те, что нашли работу, в другой - что не нашли работу, и с площадью пропорциональной количеству. Потом каждую часть поделить на две части: у которых есть скилл, и у которых нет скилла.
Априорная вероятность встречания скилла среди всех кандидатов - это соотношение количеств: (есть скилл) / (все кандидаты)
Постериорная вероятность встречания скилла среди нашедших работы - это: ((есть скилл) И (нашел работу)) / (нашел работу)
Условная вероятность нахождения работы при наличии данного скилла - это: ((есть скилл) И (нашел работу)) / (есть скилл)
То есть, можно даже пропустить два деления и просто сразу делить количество встречания скилла среди работ на количество встречания скилла среди кандидатов.
Re: Skills: frequency vs Bayesian probability
Ты говоришь о том, насколько много resumes содержат рассматриваемый нами skill (HowManyResumesContainOurSkill).
Я же говорю о том, сколько раз рассматриваемый нами skill встречается в одной работе (HowManyTimesOurResumeContainsOurSkill).
Вероятность соответствия между резюме и работой:
- пропорциональна 1/HowManyResumesContainOurSkill
- пропорциональна log(HowManyTimesOurResumeContainsOurSkill + 1)
То есть формула вероятности:
log(HowManyTimesOurResumeContainsOurSkill + 1) / HowManyResumesContainOurSkill
> проще всего начать с рисования квадрата, который будет представлять всех кандидатов
Всех кандидатов на все работы?
Или всех кандидатов на одну работу?
Re: Skills: frequency vs Bayesian probability
В смысле, не в работе, а в резюме?
> Вероятность соответствия между резюме и работой:
> - пропорциональна 1/HowManyResumesContainOurSkill
> - пропорциональна log(HowManyTimesOurResumeContainsOurSkill + 1)
Так не получается, математически она не может быть одновременно пропорциональна обоим. Если ты каждому резюме приписываешь вес в log(HowManyTimesOurResumeContainsOurSkill + 1), то математически правильно будет смоделировать, что вероятность соответствия будет 1/(сумма_этих_весов).
Ну, не говоря уже про использование частоты встречания фразы как предсказателя ценности. Если кто-то поменял за год 5 работ и в каждой написал скилл, будет ли ему соответствие лучше, чем человеку, который написал этот скилл один раз в одной работе?
> Всех кандидатов на все работы? Или всех кандидатов на одну работу?
Хоть так, хоть так, смотря что хотеть мерять. Если ты ищешь среди всех работ, то для кандидатов на все работы.
Re: Skills: frequency vs Bayesian probability
> В смысле, не в работе, а в резюме?
Да, сколько раз skill встречается в резюме (а не в работе).
На самом деле, сколько раз skill встречается в работе - тоже желательно учитывать. И тоже по логарифмической шкале. Только, естественно, при подсчитывании match score - нужно будет поделить на сумму весов skills (умноженных на логарифм количества встречания этих skills.
А вот для резюме -- логарифмы количества использования skills в резюме - делить на общую сумму -- не обязательно. Потому, что мы ищем (и сортируем) работы для одного резюме. Поэтому делитель, во всех случаях, одинаковый. Поэтому сортировка не нарушается.
> Если кто-то поменял за год 5 работ и в каждой написал скилл, будет ли ему соответствие лучше
Мы же ищем наиболее подходящую работу для этого job-hopper. Поэтому учитывать нужно только пропорцию между skills в этом резюме.
Если бы мы для работы искали кандидатов - тогда нужно было бы делить resume matching skills score на общую skills score.
Re: Skills: frequency vs Bayesian probability
Re: Skills: frequency vs Bayesian probability
1) Даже если бы это было так (а это не так), это никак не отменяет того, что при поиске работ для job seeker, учитывать нужно только пропорцию между skills в этом резюме.
2) Обычно, люди часто меняют работу потому, что на интервью они выглядят лучше, чем в самой работе.
Re: Skills: frequency vs Bayesian probability
2) обычно люди часто меняют работу потому, что постепенно находят варианты с больше денег
Re: Skills: frequency vs Bayesian probability
> как мы уже обсудили, более недавние скиллы важнее давних
Да: недавние skills - важнее давних.
Поэтому при учете пропорции между skills в резюме - надо учитывать и давность тоже.
>> 2) Обычно, люди часто меняют работу потому, что на интервью они выглядят лучше, чем в самой работе.
> 2) обычно люди часто меняют работу потому, что постепенно находят варианты с больше денег
Варианты с "больше денег", для подавляющего большинства людей - не возникают часто.
Re: Skills: frequency vs Bayesian probability
Если цены на рыне труда растут, то как раз возникают часто. Каждый работодатель норовит спросить прошлую зарплату, и предложить чуть больше нее. Поэтому скажем вместо чем один раз поменять работу и повысить зарплату вдвое, окажется, что пришлось менять работу 3 раза и каждый раз добывать 30% (а то и 10 раз по 10%).
Re: Skills: frequency vs Bayesian probability
Re: Skills: frequency vs Bayesian probability
Re: Skills: frequency vs Bayesian probability
Re: Skills: frequency vs Bayesian probability
Re: Skills: frequency vs Bayesian probability
Ведь программист с опытом работы на текущем проекте, как правило, гораздо важнее/продуктивнее, чем программист, нанимаемый со стороны.
Re: Skills: frequency vs Bayesian probability
Re: Skills: frequency vs Bayesian probability
Получается, что причина, по которой переходящие с работы на работу зарабатывают больше -- заключается в том, что на новом месте -- нет других людей, согласных работать за меньшие деньги?
Re: Skills: frequency vs Bayesian probability
Квадрат Bayesian probability
Давай рассмотрим случай "всех кандидатов на одну работу" (как более простой).
Ты написал:Под "не нашли работу" ты имеешь ввиду, что "не нашли работу, на которую мы, сейчас, пытаемся найти кандидатов? Или "не нашли никакую работу"?
Re: Квадрат Bayesian probability
Re: Квадрат Bayesian probability
Re: Квадрат Bayesian probability
Re: Квадрат Bayesian probability
Это - неверное предположение.
Есть много работ, на которые никого нанять не могут. Или могут нанять, но потом хотя снова заменить на другого соискателя, потому что предыдущий не устраивает (или сбежал).
И есть много работ, которые нанимают вообще без публикации вакансии. Например, по знакомству. Или с помощью поиска в базах резюме.
Re: Квадрат Bayesian probability
Re: Квадрат Bayesian probability
"Objective" and "looking for"
Секция "Objective" - задумывалась для того, чтобы изложить желания кандидата.
Но большинство кандидатов просто хотят денег побольше, причем стесняются об этом написать.
Поэтому пишут всякую обобщенную фигню про то, как они хотели бы повысить свой уровень качества работы и не упоминают skills, которые помогают найти наиболее подходящую этим кандидатам работу.
> Это не рецепт, а направление для дальнейшего изучения.
Я этот "не рецепт" уже изучил. Выглядит довольно безнадежно.
Проще просто пытаться найти skills в тексте, а на заголовок "Objective" - не обращать внимания.
Также лучше не обращать внимание на "looking for".
Re: "Objective" and "looking for"
Вот кстати о географии, очеь бесит, когда единственный способ фильтрации - по зип-коду, и в радиус попадает какой-нибудь Нью-Йорк или Сиэттл, и потом этот мусор приходится вручную вычищать.
Search location and distance
Какую ты видишь альтернативу кругу поиска с определенным радиусом?
Рисовать карту с границами зоны поиска работ?
99% кандидатов подобным заморачиваться не станут, даже если им дать в руки такой инструмент.
Re: Search location and distance
Re: Search location and distance
Например, начать с одного zipcode и указания радиуса.
Потом выдать список всех попадающих в радиус зипкодов - и дать возможность удалить их из списка.
Ну а дальше - уже запомнить этот список и искать работы только в этих зипкодах.
Но это требует advanced user и более сложного кодирования.
Поэтому подобное мало кто делает.
Да и строгие ограничения по зипкоду - не всегда хорошо подходят.
Ведь ради какой-то работы ты вполне можешь согласиться ездить в ненавистный тобой downtown.
Например, потому, что очень много платят.
Или, потому, что работа очень интересная.
Или, потому, что туда нужно ездить только раз в месяц, а остальное время - работать из дома.
Разве эти варианты можно указать в стандартом фильтре при поиске работ?
Re: Search location and distance
Re: Search location and distance
Вероятно, поэтому интерфейс со списком зипкодов редко используется.
Хотя мне иногда пользователи перечисляют в каких зипкодах они ищут работу.
Но, в их случае, лучше использовать один зипкод (с радиусом), а не несколько.
Re: "Objective" and "looking for"
В objective тоже может оказаться что-то полезное, но смотреть надо не на то, что это objective, а на то, какие skills можно обнаружить в тексте.
> Там же могут содержаться уточнения про географию
Это как? "Исключить работы в NYC"?
Re: "Objective" and "looking for"
Ну да. Но там хотя бы есть вариант, что если есть ограничение по штату, то ставишь штат NJ - и готово, NYC исключен. А вот с Сиэттлом так просто не сделаешь, он в том же штате. Но это не только Сиэттл, есть еще городки на другой стороне залива. Они по прямой конечно рядом, но это по воде, а в реальности туда два часа ехать вокруг залива.
О, вот наверное как можно смоделировать заливы: у зипкодов, которые находятся рядом с естественными препятствиями, добавить атрибуты - имя препятствия и сторону от него, где зипкод находится. То есть, например, у Сиэттла это будет "Puget Sound, East", "Lake Washington, West". И потом при поиска делать агрегацию найденных препятствий, чтоб можно был пометить чекбоксы "исключить: Lake Washington, West; Puget Sound, West".
В-принципе, то же самое будет работать и с городами: "New York City, In", "New York City, Out". И ньюйоркцы смогут радостно ограничиться ньюйорком, а неньюйоркцы неньюйорком.
Re: "Objective" and "looking for"
New Jersey - слишком большой по размеру.
Лучше уж в NYC через мост ехать, чем ехать на другой конец New Jersey.
Я, обычно, выбираю zipcode миль на 7 западнее от исходного zipcode в NJ, и выставляю радиус поиска миль 10-15: и до NYC не достает, и в New Jersey не слишком далеко.
> есть еще городки на другой стороне залива.
Заливы - это вообще сложная ситуация.
Ведь через залив может ходить паром.
Или можно на своей лодке плыть или даже вертолете летать.
Иногда через залив идет мост. Или подземный туннель.
Все случаи - сложно учесть.
> у зипкодов, которые находятся рядом с естественными препятствиями, добавить атрибуты - имя препятствия и сторону от него, где зипкод находится.
Препятствия вполне могут быть преодолимыми для некоторых людей.
И, в любом случае, это существенно усложняет как код поиска, так и UI.
Re: "Objective" and "looking for"
Чекбокс, исключающий препятствия
Re: Чекбокс, исключающий препятствия
Re: Чекбокс, исключающий препятствия
Значит, такой checkbox нужно будет показывать только после того, как job seeker ввел свой зипкод (и оказалось, что на западе, поблизости от введенного зипкода, располагается Lake Washington.
Это несколько усложняет UI (и backend).
При большом объеме поисков в районе Lake Washington -- такой чекбокс может себя и оправдать. Но совсем необязательно.
Re: Чекбокс, исключающий препятствия
Ну естественно. Я ж даже рассказал выше: находим зикоды в радиусе, собираем их список препятствий, группируем их, и показываем чекбоксы для найденных препятствий и их сторон.
Re: Чекбокс, исключающий препятствия
Old skills
Да.
Поэтому, чем skills ниже в тексте резюме, тем меньший вес они имеют при нашем подсчете.
Антисигнал
Если бы человек хорошо подошел для новой работы, то он, вероятно, уже бы не публиковал новое резюме, верно?
Может быть, связь старой секции и новой секции -- это не сигнал, а антисигнал?
Re: Антисигнал
Re: Антисигнал
Обычно подобная практика есть у рекрутеров, которые получают свою компенсацию только после того, как кандидат проработает на новом месте 3 месяца.
Рекрутеры видят какие резюме с какими ключевыми словами привели к стабильному трудоустройству, а какие - нет.
Re: How to create a job search query from resume text?
Распознавание смысла делается примерно так: делается сеть, которая пытается предсказывать следующее слово. Она натренировывается. Потом с нее срезуют верхний слой нейронов, и используют выходы с предпоследнего слоя как индикаторы смысла.
Но я сам на анализ текста подробно никогда не смотрел, представляю только в общих словах. Могу еще сказать, что для анализа текста типовой топологией сети является LSTM, которая закольцовывает сигнал с выхода на вход.
Re: How to create a job search query from resume text?
Это слишком сложно для имплементации если конечная цель - найти наиболее подходящие работы для резюме.