![[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
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
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
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: Чекбокс, исключающий препятствия
Re: Чекбокс, исключающий препятствия
Re: Чекбокс, исключающий препятствия
Old skills
Да.
Поэтому, чем skills ниже в тексте резюме, тем меньший вес они имеют при нашем подсчете.
Антисигнал
Если бы человек хорошо подошел для новой работы, то он, вероятно, уже бы не публиковал новое резюме, верно?
Может быть, связь старой секции и новой секции -- это не сигнал, а антисигнал?
Re: Антисигнал
Re: Антисигнал
Обычно подобная практика есть у рекрутеров, которые получают свою компенсацию только после того, как кандидат проработает на новом месте 3 месяца.
Рекрутеры видят какие резюме с какими ключевыми словами привели к стабильному трудоустройству, а какие - нет.