ШІ-теги для вакансій замість нескінченного гортання

Від фільтрів до семантичних міток

Тут привертає увагу не саме слово ШІ, а вдала постановка задачі: звичайні фільтри не давали змоги знайти дуже специфічну роботу без тривалого перегляду стрічки. В оригінальному дописі автора в обговоренні спільноти цей кейс описано вкрай практично: інструмент з'явився під час пошуку роботи та автоматично тегував оголошення.

На момент опублікованого допису проєкт уже працював із вакансіями, а згодом автор вирішив поширити його на довільні формати даних, відкрити вихідний код і розвивати окремий сервіс із додатковими функціями. Точної календарної дати у вихідних даних немає, тому це не реліз із зафіксованою версією, а ранній інженерний кейс.

Технічна цінність полягає не в генерації тексту, а в перетворенні неструктурованого оголошення на набір ознак, придатних для пошуку. Я б поділив таку систему на приймання даних, нормалізацію полів, призначення міток і пошуковий шар; інакше підтримка нових форматів швидко перетвориться на набір винятків. Для вакансій особливо важливо не змішувати посаду, навички, рівень, формат роботи та інші критерії в одну непрозору оцінку.

Першою перевіркою мала б бути не краса інтерфейсу, а якість рідкісних запитів, заради яких проєкт і виник. Далі потрібні аналіз помилок тегування, видалення дублікатів і зрозуміле пояснення, чому конкретне оголошення потрапило до вибірки. Інакше ШІ лише замінить ручне гортання ручною перевіркою результатів.

Що насправді змінюється

Головний ефект тут цілком реальний: користувач формулює вузький намір, а система зводить різнорідні оголошення до зіставних міток. Це корисніше за черговий фільтр за ключовим словом, якщо потрібну ознаку описують різними формулюваннями.

Втім, розширення на будь-які дані різко підвищує складність. У вакансій є відносно зрозумілі сутності, а інший формат потребуватиме нової схеми міток, правил нормалізації та власної оцінки якості. Універсальність легко стає обіцянкою, що ламається на першому нестандартному документі.

Відкритий код може зробити якість видимою: можна обговорювати схему міток, граничні випадки та поведінку на рідкісних даних. Але сам по собі він не вирішує проблем доступу до оголошень, змін форматів і мовного дрейфу. Саме за цим варто стежити, а не за кількістю підтримуваних джерел.

Цей проєкт виглядає не як магія навколо моделі, а як спроба прибрати конкретну рутину. Переможе не найрозумніша модель, а система, що стабільно перетворює брудний вхід на зрозумілі мітки.

Ми також розглядали, як вимірювати надійність LLM у завданнях контролю якості за допомогою IRT-метрик. Це напряму стосується перевірки точності тегів, які ШІ присвоює вакансіям.