У нас есть внутренняя платформа подбора ИТ-специалистов. Вакансии приходят от заказчиков, и по каждой платформа находит в базе резюме, близкие к её тексту по смыслу, даже если слова в них другие. Внутри обычный векторный поиск на эмбеддингах.У любого такого поиска есть врождённая болезнь. Он находит похожие тексты, а рекрутёру нужны подходящие люди. Резюме сильного программиста совпадает с вакансией архитектора почти по всем ключевым словам, но это другая роль, и кандидат не подходит. Рекрутёр видит такое за несколько секунд. Поиск не видит вовсе. У такого резюме высокая косинусная близость к тексту вакансии, и поиск выводит его в верх поисковой выдачи.Этим летом мы переделали ранжирование кандидатов. Теперь место кандидата в поисковой выдаче зависит от ответа на вопрос, который рекрутёр и так задаёт себе про каждого. «Показал бы я этого кандидата клиенту?» На этот вопрос отвечает языковая модель (LLM). Она встроена в платформу как судья, перечитывает найденные поиском резюме, и каждый вердикт обязана доказывать дословными цитатами из них.Доля действительно подходящих кандидатов в первой десятке поисковой выдачи выросла с 43,7 до 66,3 процента. Замерено на эталонном наборе, который мы заморозили до начала работ. Как устроен замер, расскажу ниже.Кроме прироста точности эта переделка дала четыре истории, где проверка на эталонном наборе перечеркнула то, что казалось очевидным. Тендер на роль судьи, который мы устроили между четырьмя LLM, выигрывала недорогая и быстрая из них, пока мы не проверили, настоящие ли цитаты из резюме она приводит. Экономия на глубине рассуждений прошла все проверки качества и провалилась на проверке цитат. Перебор 1330 вариантов взвешивания оценок судьи доказал, что веса не нужны. А RRF, стандартный приём слияния семантического и полнотекстового поиска, первую же проверку на эталонном наборе провалил, он ухудшил и полноту, и точность. Обо всём по порядку. Читать дальше