Не совсем так, HR профильные, готовим так, чтобы понимали и метчили из контекста, а не сверялись 1 в 1 по заготовке. Скорее есть черный список, если сказал так, то точно не надо :)
Это скорее тема для отдельной большой статьи. Там несколько типовых задач для компании, оцениваем на сколько вообще понимает тематику, работает ли с кодом, какие подходы применяет, разобрался ли с function calling и подобное. Есть критерии для оценки по каждой задачи, проверяем типовые ошибки, стабильность вывода, способ реализации. При этом по тестовому часто сразу понятно, какая специализация и грейд у кандидата.
Мы готовим HR к скринингу, есть и примеры ответов с критериями, и погружаем в домен в целом. Часто сама просматриваю отклики и скрининги, достойные кандидаты не теряются 😊
Статья действительно про найм для специалистов, кто идет на подобные вакансии. И как показывает моя статистика - оптимальный возраст от 28 лет и старше, когда уже и диплом получен, и опыт работы есть в своей специализации (без AI).
Под своей LLM подразумевается дообучение открытой локальной большой языковой модели под наши нужды, чтобы она лучше понимала предметную область, русский язык и лучше следовала инструкциям.
Векторизация документов из базы: этот подход называется RAG (Retrieval Augmented Generation), он не обязательно подразумевает дообучение своей LLM. Об этом есть хорошие статьи, например, эта https://habr.com/ru/articles/779526/
На скриншоте №2 справа пример парсинга параметров в JSON из сообщения пользователя. Часто промпт выходит объемный и сложный, простые конструкции не охватывают частные случаи богатого и могучего русского языка.
Используем такой парсинг для тех решений, где LLM в итоге выгоднее, чем использование парсинга функциями или классический ML. Выигрываем по качеству и по времени реализации новых сценариев в тот же Ассистент, к примеру.
Проблема с нестабильностью действительно есть, часто даже через три месяца результат может быть другой. Мы отслеживаем обновления моделей и выход новых, фиксируем изменения, а за счет внутренней инфраструктуры поддерживаем актуальность во всех решениях.
Не совсем так, HR профильные, готовим так, чтобы понимали и метчили из контекста, а не сверялись 1 в 1 по заготовке. Скорее есть черный список, если сказал так, то точно не надо :)
я же написала, что просматриваю анкеты, как лидер по роли, а не HR. Часто срезаются вообще не по скринингу, а по резюме и кейсам в портфолио.
Это скорее тема для отдельной большой статьи. Там несколько типовых задач для компании, оцениваем на сколько вообще понимает тематику, работает ли с кодом, какие подходы применяет, разобрался ли с function calling и подобное.
Есть критерии для оценки по каждой задачи, проверяем типовые ошибки, стабильность вывода, способ реализации.
При этом по тестовому часто сразу понятно, какая специализация и грейд у кандидата.
Мы готовим HR к скринингу, есть и примеры ответов с критериями, и погружаем в домен в целом. Часто сама просматриваю отклики и скрининги, достойные кандидаты не теряются 😊
Еще рано просить опыт от 2-3 лет. Можете отправить мне сообщением ссылку на резюме?
Статья действительно про найм для специалистов, кто идет на подобные вакансии.
И как показывает моя статистика - оптимальный возраст от 28 лет и старше, когда уже и диплом получен, и опыт работы есть в своей специализации (без AI).
Под своей LLM подразумевается дообучение открытой локальной большой языковой модели под наши нужды, чтобы она лучше понимала предметную область, русский язык и лучше следовала инструкциям.
Векторизация документов из базы: этот подход называется RAG (Retrieval Augmented Generation), он не обязательно подразумевает дообучение своей LLM. Об этом есть хорошие статьи, например, эта https://habr.com/ru/articles/779526/
На скриншоте №2 справа пример парсинга параметров в JSON из сообщения пользователя. Часто промпт выходит объемный и сложный, простые конструкции не охватывают частные случаи богатого и могучего русского языка.
Используем такой парсинг для тех решений, где LLM в итоге выгоднее, чем использование парсинга функциями или классический ML. Выигрываем по качеству и по времени реализации новых сценариев в тот же Ассистент, к примеру.
Проблема с нестабильностью действительно есть, часто даже через три месяца результат может быть другой. Мы отслеживаем обновления моделей и выход новых, фиксируем изменения, а за счет внутренней инфраструктуры поддерживаем актуальность во всех решениях.
Спасибо за комментарий и ваш опыт.