AI-система пошуку експертів усередині компанії — Expertise Locator

Expertise locator: чому пошук експертів усередині компанії не працює

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

Корінь проблеми в тому, що карта компетенцій співробітників живе окремо від самої роботи. Її ведуть як анкету: хтось раз на рік заповнив поле «навички», хтось не заповнив.

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

Внутрішня база знань влаштована так само — документи розкладені за відділами, а не за задачами, і пошук по них знаходить формулювання, а не носія знання.

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

Expertise locator вирішує це інакше: пошук експертів усередині компанії будується не за анкетами, а за слідами реальної роботи. Система збирає, хто що робив, відповідав, писав і лагодив, і на запит звичайною мовою повертає конкретних людей з обґрунтуванням — чому саме вони.

Ключове тут не «розумний пошук», а зв'язок людини з темою та підтвердження, що цей досвід ще актуальний. Нижче розбираємо, як це закривається.

Що дає внутрішній пошук експертів: ефекти в цифрах

Ефект від впровадження пошуку експертів вважаємо не за кількістю запитів в інтерфейсі, а за чотирма метриками, які знімаємо до і після запуску.

Вони показують, чи йде робота навпомацки і скільки вирішується повторно — на цьому класі систем Expertise Locator і будується перевірка результату.

• Час до потрібної людини. Раніше питання «хто в нас це вже вирішував» ішло в кілька листувань і залежало від особистих знайомств — відповідь знаходилася за години, іноді за дні.

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

• Частка питань з відповіддю з першого разу. Значна частина звернень раніше поверталася формулою «запитайте в колеги із сусідньої команди». Після запуску більшість запитів закривається на першому кроці: система шукає за описом задачі, а не за точним іменем експерта.

• Охоплення компетенцій. З видачі перестають випадати вузькі фахівці, які не заявляли про себе в профілях і не сидять у формальних центрах компетенцій. Частка знайдених експертів із неочевидних підрозділів зростає — це основне джерело нових зв'язків усередині компанії.

• Зниження повторної роботи. Запит дедалі частіше звучить як «у кого є готове рішення», а не «як це зробити». Команди піднімають наявні напрацювання замість складання з нуля, і частка задач, зроблених заново, падає.

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

Варіанти expertise locator: вбудований пошук, асистент, граф зв'язків

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

Універсального варіанта немає — кожен по-своєму обмежений якістю вихідних даних, тому обирають під свій контур: скільки джерел доступно, наскільки вони розмічені та як часто змінюється склад команд.

Загальна вимога для всіх варіантів — регулярне оновлення індексу та успадкування прав доступу з джерела. Якщо картка експерта не підтягує актуальний склад проєктів і ролі, за кілька місяців вона розходиться з реальністю, і люди перестають довіряти системі.

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

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

Як ми впроваджуємо систему пошуку експертів: етапи робіт

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

Нижче — послідовність робіт із впровадження expertise locator, внутрішньої системи пошуку експертів, з контрольними точками на кожному кроці.

1. Аудит джерел даних. Розбираємо, де лежать відомості про навички: кадровий довідник, історії проєктів, бази знань, профілі в робочих чатах. Для кожного джерела фіксуємо повноту, частоту оновлення та права доступу.
2. Зведений довідник компетенцій. Приводимо назви ролей і технологій до єдиних формулювань — інакше те саме вміння приходить трьома рядками і пошук розвалюється на синоніми.
3. Налаштування пошуку. Збираємо гібридну схему: точний збіг за довідником плюс пошук за змістом в описах проєктів. Ранжування враховує свіжість підтвердження навички.
4. Перевірка релевантності. Формуємо еталонний набір запитів із заздалегідь відомими правильними відповідями та вимірюємо частку влучань у верх видачі. Поріг узгоджуємо до запуску.
5. Пілот і доналаштування. Запускаємо в одному підрозділі та дивимося, які запити не знаходять потрібну людину. Окремо перевіряємо права: хто бачить профіль співробітника, який перейшов до іншого відділу.
6. Передача рішення. Віддаємо документацію, регламент оновлення довідника, звіт за якістю видачі та навчаємо власника системи.

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

Склад постачання: налаштований пошук, політики доступу, регламенти

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

• Робочий контур пошуку — сервіс з індексуванням профілів співробітників, ранжуванням за релевантністю запиту та підсвічуванням збіглих навичок; розгортається у вашому середовищі.
• Схема даних — джерела (кадрова система, каталог навичок, трекери проєктів), правила зв'язування записів у єдиний профіль, обробка дублів і застарілих атрибутів.
• Політики доступу та модель видимості — що відкрито ролі, що приховано, які поля бачить лише власник профілю; журналювання запитів до персональних даних.
• Регламент оновлення профілів — тригери актуалізації, періодичність звірки з джерелами, відповідальні за якість записів і порядок розбору скарг на невірні дані.
• Документація рішення — архітектурна схема, опис логіки ранжування, інструкції адміністратора та пам'ятка співробітника: система не зав'язана на одну людину.
• Методика оцінювання якості — тестовий набір запитів, частка влучань у топ видачі, порядок зміни ваг і повторного калібрування після правок у даних.

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

Кейс: як пошук експертів скоротив час узгоджень

Компанія розподілена: продуктові команди в трьох часових поясах, частина виконавців заходить проєктно.

Знання про те, хто відповідає за платіжний шлюз або обмін довідниками із зовнішнім каталогом, жило в листуванні, описах задач і головах старожилів — запит «потрібна людина, яка вже це налаштовувала» перетворювався на ланцюжок із чотирьох-п'яти пересилань між командами.

Заміри до запуску: узгодження технічного рішення займало в середньому вісім робочих днів, пошук власника компетенції — від двох днів, а кожен третій запит потрапляв не в ту команду і повертався з уточненням.

Що змінили

Expertise Locator зібрали як шар поверх наявних джерел: каталогу проєктів, трекера задач, профілів співробітників та історії узгоджень.

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

Пошук іде за змістом запиту, а не за точним збігом слів: формулювання «міграція довідника постачальників» знаходить того, хто робив таке саме рішення під іншою назвою.

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

Результат

Узгодження рішення скоротилося з восьми днів до трьох, частка запитів, закритих з першого звернення до потрібної людини, зросла з 60 до 88%.

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

Чим відрізняється пошук за змістом від пошуку за ключовими словами?

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

Логіка пояснювана — видно, чому картка експерта піднялася у видачі, — але жорстко прив'язана до формулювань: у запиті «стримінг», у профілі «обробка потокових даних», збігу немає, і людина залишається незнайденою.

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

Зворотний бік: абревіатури, назви систем і точні ідентифікатори він плутає, а якість напряму залежить від повноти та однаковості карток.

Робочий варіант — гібридна видача, де смислова гілка відповідає за повноту, а ключові слова за точність на рідкісних термах; таку схему підтримують зрілі пошукові платформи, зокрема Elasticsearch.

Окрема частина роботи — дані та спостереження за якістю. Ключовому пошуку досить текстових полів і словника синонімів; смисловому потрібні єдиний довідник компетенцій, прив'язка експертів до проєктів і регулярна переіндексація при оновленні моделі.

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

Часті технічні питання про пошук експертів

Пошук експерта — це не пошук документа: система має повернути людину, яка вже вирішувала схожу задачу, і показати, на яких фактах ґрунтується висновок. Нижче — сумніви, які найчастіше виникають до старту, і як вони закриваються на рівні архітектури.

Дані розкидані по різних системах — як їх звести?

Підключаємо джерела через інтеграції: трекер задач, база знань, каталог компетенцій, кадровий контур. Далі — єдина модель компетенцій і словник синонімів: «постгрес», «PostgreSQL» і «реляційна база» зводяться до одного поняття. Індексація інкрементальна, за подіями зміни, тому повне перезбирання не потрібне.

Як вирішується питання конфіденційності?

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

Додатково — журнал запитів і маскування чутливих полів, щоб пошук не ставав обхідним каналом доступу.

Профілі доведеться заповнювати вручну?

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

Як підтримується актуальність бази знань?

Актуальність — метрика, а не побажання: стежимо за часткою профілів без свіжих підтверджень і за покриттям джерел. Застарілі зв'язки послаблюються автоматично, а розходження між джерелом та індексом показуються у звіті, щоб їх можна було розібрати, а не виявити в момент пошуку.

Обговоримо задачу: підберемо схему пошуку під ваш контур

Схему пошуку вибрати «на око» не можна: якість видачі expertise locator цілком залежить від того, які джерела даних у вас уже є і наскільки вони розмічені. Тому перед оцінкою проєкту нам потрібні вхідні дані по проєкту — від них залежать і архітектура, і обсяг робіт.

Від замовника достатньо:

• Перелік систем-джерел: каталог співробітників, профілі у внутрішніх системах, база знань, структура підрозділів — і спосіб доступу до кожного.
• Як експерта знаходять сьогодні: запит у загальний чат, лист керівнику, усне опитування — де втрачається час і чому відповідь приходить неповною.
• Які атрибути описують компетенцію: проєкти, технології, сертифікати, ролі — і хто відповідає за їхню актуальність.
• Розмежування доступу: хто бачить повний профіль, хто лише підтверджені компетенції, що закрито внутрішніми обмеженнями.
• Межі контуру: свої сервери або закритий сегмент, чи допустима обробка даних зовнішніми сервісами.
• Критерій приймання: яку частку запитів система закриває сама і з якою точністю влучає в потрібного фахівця.

У відповідь повернемо схему впровадження з етапами, оцінку проєкту за строками та складом команди, план робіт із точками контролю та ризиками за кожним джерелом. Окремо перелічимо, що доведеться доопрацювати в даних до старту — це знімає основні сюрпризи на етапі запуску.

Щоб обговорити задачу предметно, достатньо описати наявні джерела та те, як шукають експерта зараз — цього вистачить, щоб повернутися з оцінкою та планом.