Чому AI-вікі не знаходить відповідь у корпоративній базі знань
Співробітник формулює питання своїми словами — «як повернути клієнту оплату за скасоване замовлення», — а пошук у корпоративних документах шукає точні збіги.
У регламенті написано «повернення коштів при розірванні», спільних слів немає, і видача виходить або порожньою, або складається з формально збіглися, але нерелевантних сторінок. Людина гортає їх, не знаходить відповіді й іде в чат до того, хто «точно знає».
Друга причина — розрізнені джерела знань. Вікі, файлове сховище, система заявок, пошта, листування в месенджерах: у кожного своя структура, свій власник і своя модель прав доступу. Поки документи не зведені, пошук бачить лише один острів і мовчить про решту.
Якщо ж звести все в один індекс без урахування прав, співробітник отримає фрагмент документа, який йому читати не належить.
Третя причина — неточні відповіді нейромережі. AI-вікі добудовує формулювання за єдиним знайденим абзацом, не звіряючись із датою та статусом документа, і видає впевнений текст без посилання на першоджерело.
Перевірити його неможливо, а після другої-третьої такої відповіді інструментом перестають користуватися.
Підсумок передбачуваний: навантаження на експертів зростає, одні й ті самі питання задають заново, черга до носія знання не розсмоктується. Розбираємо, як це закривається — від єдиного шару доступу до джерел до відповіді з посиланням на конкретний документ.
Що змінюється після впровадження: швидкість, точність, охоплення
До впровадження шлях до відповіді виглядає так: співробітник відкриває пошук по базі, отримує список документів і читає п’ять-сім сторінок, щоб зібрати фрагменти в одне рішення.
Частина питань іде в профільні чати до експертів — ті відповідають з пам’яті, і версії відповідей поступово розходяться. Ми починаємо з вимірювання цієї вихідної точки за журналами звернень, а не з відчуттів.
Перший ефект — час до готової відповіді. Рахуємо від постановки питання до відповіді з посиланнями, окремо медіану та хвіст найдовших запитів: він показує, де базі бракує документів.
На практиці це хвилини замість десятків хвилин, і розрив зростає на питаннях, що вимагають звести три-чотири джерела.
Другий — частка відповідей із підтвердженим джерелом. Кожна відповідь іде з цитатою та посиланням на конкретний документ у Confluence, тому перевіряється за один перехід, а не на віру.
На тестовому наборі питань з еталонними відповідями ми рахуємо точність і розбираємо розходження: де відповідь неповна, де документ застарів, де запит потребує уточнення в автора.
Третій — охоплення. Дивимося, скільки підрозділів і співробітників повертаються в базу повторно, і як змінюється потік питань до експертів у профільних чатах. Для нових співробітників різниця принципова: не «спитати ні в кого», а знайти відповідь самостійно в перший робочий день.
Варіанти AI-вікі: зовнішній сервіс, контур замовника, гібрид
Спосіб розгортання визначає, де фізично лежать тексти документів і embeddings, хто відповідає за оновлення й скільки часу займе старт.
Для бази знань це не абстрактний вибір інфраструктури: від нього залежить, чи можна підключити внутрішні джерела і як забезпечується ізоляція конфіденційних даних.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Зовнішній сервіс для бази знань | Швидкий старт, документи не містять комерційної таємниці, потрібен доступ з будь-яких пристроїв | Дані розміщені поза периметром, частина внутрішніх джерел недоступна без вивантаження |
| Розгортання в контурі замовника | Суворі вимоги до ізоляції конфіденційних даних, є власні обчислювальні ресурси й адміністрування | Довша підготовка інфраструктури, оновлення та моніторинг — на боці замовника |
| Гібридна схема зберігання | Основний масив документів закритий, але потрібні зовнішні моделі та швидкі експерименти | Два контури, потрібне розмежування прав і узгодженість метаданих |
На практиці частіше обирають гібрид: конфіденційні дані залишаються всередині, а важкі операції з моделями виносяться назовні.
Ми описуємо обидва контури, схему потоків даних і точки, де можливий витік, — до початку робіт, щоб рішення відповідало вимогам безпеки, а не обходило їх.
Етапи робіт: від аудиту джерел до передачі в підтримку
Розробку вікі-платформи починають не з коду, а з інвентаризації того, що вже написано. Порядок робіт визначає, чи будуть відповіді спиратися на актуальні редакції, а розмежування доступу не розвалиться на першому ж запиті співробітника із суміжного відділу.
- Аудит джерел знань. Збираємо перелік: де лежать документи, які формати, де дублікати та застарілі редакції, які матеріали взагалі не мають власника.
- Схема зв’язків між системами. Вирішуємо, що підтягується із систем обліку напряму, а що залишається файлами, і за якими ознаками зіставляються співробітники, проєкти та підрозділи.
- Налаштування прав доступу. Групи успадковуємо з каталогу й розмежовуємо за розділами; перевіряємо, що відповідь не склеює фрагменти, які співробітнику бачити не належить.
- Складання та індексація. Документи ділимо на смислові фрагменти й задаємо правило цитування: кожна відповідь веде на конкретний документ та його редакцію.
- Приймання якості відповідей. Проганяємо реальні питання співробітників, рахуємо частку відповідей із правильним посиланням, розбираємо промахи й доучуємо систему на них.
- Передача в підтримку. Віддаємо регламент оновлення бази, карту власників розділів і правила контролю, щоб якість не деградувала після запуску.
Кожен етап закривається артефактом, який можна перевірити, — тому приймання йде за фактами, а не за відчуттями.
Склад постачання: конфігурації, схеми інтеграцій, регламенти
Усе, що описано в проєктній документації, залишається в контурі замовника — не в листуванні й не в пам’яті підрядника. Передаємо репозиторій конфігурацій, схем і регламентів, за яким ваша команда відтворює середовище з нуля, змінює модель або підключає нове джерело без нас.
Перевірка проста: інженер, який не брав участі в проєкті, за цими матеріалами розгортає стенд і пояснює, чому система відповіла саме так.
- Карта джерел знань — перелік систем, з яких збирається база: файлові сховища, вікі-простори, бази заявок, поштові архіви. За кожним джерелом указано власника, частоту оновлення та правила відбору, а також те, що свідомо виключено з індексу.
- Політики доступу та ролі — модель ролей, прив’язана до груп каталогу, і правила успадкування прав: співробітник отримує у відповіді рівно ті фрагменти, до яких має доступ у вихідній системі. Окремим пунктом — поведінка асистента, коли права в джерелі змінилися, а індекс ще не перезібрано.
- Схема інтеграцій — конектори, розклад синхронізації, обробка змін і видалень документів. Позначено точки відмови: де асистент відповідає за останньою узгодженою версією, а де чесно повідомляє про відсутність даних.
- Налаштування генерації відповідей — шаблони запитів до моделі, правила цитування фрагмента-джерела та поріг, нижче якого відповідь не видається взагалі.
- Інструкції для співробітників — пам’ятки на 1–2 екрани: як формулювати запит, як перевірити посилання на першоджерело, куди повідомити про неправильну відповідь. Плюс пам’ятка для власників контенту про те, як підтримувати документи придатними для пошуку.
- Метрики якості відповідей — частка відповідей із підтвердженим посиланням на джерело, частота звернень без знайдених даних, оцінка корисності від співробітників, час до відповіді. Дашборд із порогами, при виході за які потрібне втручання.
- Регламент експлуатації — порядок оновлення моделі та перезбирання індексу, реакція на інциденти, матриця відповідальних на боці замовника.
Приймання йде за цим самим переліком: кожен пункт перевіряємо на вашому стенді та вашими співробітниками, а не на демо-даних.
Кейс: база знань сервісної служби та час відповіді оператора
Сервісна служба з 40 операторів вела знання в Confluence: статті писалися під продукт, а не під формулювання клієнта. Пошук за назвою статті давав потрібне в 40% випадків, решта йшла в листування до старших інженерів.
Середній час підготовки відповіді оператором — 11 хвилин, а кожен четвертий клієнт повертався з тим самим питанням.
Що змінили
Ми розібрали потік звернень за квартал і переклали його в структуру бази: розмітка за симптомами замість продуктових розділів, права доступу за ролями та регіонами, обов’язковий зв’язок «звернення — стаття». Оператор бачить лише підтверджені статті, старший інженер — чернетки. Чернетка, яку двічі не підтвердили відповіддю, автоматично йде в архів, тому вітрина не заростає.
| Показник | До | Після |
|---|---|---|
| Час підготовки відповіді | 11 хвилин | 3 хвилини |
| Повторні звернення з тієї ж причини | 27% | 9% |
| Відповідь знайдено з першого запиту | 40% | 78% |
| Виведення оператора до самостійних відповідей | 6 тижнів | 3 тижні |
Окремий ефект — перестав зростати клас повторних звернень, де клієнт потрапляв до іншого оператора й починав пояснювати проблему заново: відповідь тепер збирається з однієї підтвердженої статті.
Розмітку та правила доступу ми передали команді підтримки — нові статті потрапляють на вітрину без участі розробки.
Чим відрізняється пошук за словами від відповіді за смислом
Пошук за точними словами працює за інвертованим індексом: документ розбирається на лексеми, і запит знаходить ті фрагменти, де трапляються ті самі слова.
Морфологія та стоп-слова згладжують частину розходжень, але синоніми й переформулювання залишаються поза бортом — «як оформити відпустку» та «порядок надання відпочинку» дають різні видачі за одного й того самого смислу.
Пошук за смислом запиту влаштований інакше: і запит, і кожен фрагмент бази знань перекладаються у векторне представлення, а близькість рахується за відстанню між ними, а не за збігом літер.
Формулювання «клієнт просить повернути гроші» знаходить регламент повернення, навіть якщо слова «гроші» в тексті немає. Синоніми при цьому підтягуються з тезауруса ISO 25964 і зі статистики реальних запитів співробітників.
Слабке місце смислового пошуку — він знаходить щось завжди, навіть коли правильної відповіді в базі немає.
Тому обидва механізми працюють у парі: точні збіги обов’язкові для артикулів, кодів помилок і абревіатур, де збіг має бути буквальним, смислова близькість добирає решту, а загальна видача проходить переранжування — нагору піднімаються фрагменти, релевантні і за смислом, і за термінами запиту.
Якість видачі в базі знань вимірюється не «схожістю», а тим, чи дійшов співробітник до відповіді.
Звідси дві жорсткі вимоги: посилання на джерело у відповіді — із зазначенням документа та розділу, щоб цитату можна було перевірити, і набір тестових пар «питання — правильний документ», на яких регулярно перевіряється, що пошук не розучився знаходити.
Без посилання смислова відповідь не відрізняється від впевненої вигадки; із нею це робочий інструмент, за логами якого видно, яких тем у базі бракує.
Обмеження та ризики: якість даних, доступи, навантаження
Платформа сама по собі не робить базу знань актуальною — якість відповіді обмежена якістю джерела. Якщо в індексі лежать три редакції одного регламенту, будь-яка видача буде впевненою й неправильною.
Частина обмежень закривається не моделлю, а правилами життєвого циклу документів і розмежуванням прав.
Нижче — чотири сумніви, які найчастіше порушують на пілотах, і як ми їх знімаємо.
Що буде із застарілими документами?
У кожного документа є власник, область дії та строк перегляду. Після закінчення строку він позначається як непідтверджений: залишається в базі для історії, але випадає з видачі й не цитується у відповідях.
Власник отримує нагадування, а частка документів із підтвердженим строком видна в окремому звіті — за нею видно, чи тримається база в актуальному стані.
Як вирішується конфлікт версій регламенту?
Версія — одиниця індексації, а не рядок тексту. Якщо чинних редакцій дві, система не вибирає мовчки: показує обидві з областю дії та датою затвердження. Пріоритет налаштовується за атрибутами документа — зазвичай виграє редакція з вужчою областю застосування, бо вона конкретніша.
Як розмежовується доступ?
Права успадковуються з корпоративного каталогу й перевіряються під час добору фрагментів, а не під час виведення відповіді. Відповідь не може переказати документ, недоступний користувачу, — інакше через цитати витікає зміст закритих розділів. Гостьові та тимчасові ролі працюють за тією ж схемою.
Що відбувається при піковому навантаженні?
Індексація нових документів і генерація відповідей ідуть через чергу з обмеженням паралельних задач, пошук за індексом залишається чутливим. Часті питання обслуговуються з кешу, користувач бачить статус замість таймауту. Ранковий пік звернень не валить сервіс для решти.
Обговоримо задачу: що надіслати для оцінки та плану робіт
Щоб повернутися з оцінкою, схемою рішення та планом етапів впровадження, достатньо короткого набору вступних. Чим конкретніші вихідні дані для оцінки, тим менше припущень у строках і тим раніше видно, яку частину бази знань доведеться готувати руками, а не просто переносити.
- Де знання лежать зараз: корпоративна вікі, файлові сховища, тікетниця, архіви листування — і що з цього вважається достовірним.
- Обсяг і структура: приблизна кількість сторінок і розділів, мови контенту, частка застарілих і дублювальних матеріалів.
- Зразки: 20–30 реальних сторінок, включно з погано розміченими, з таблицями та вкладеннями.
- Користувачі та ролі: скільки людей буде питати, які групи доступу є, хто власник розділів.
- Типові питання: 15–20 формулювань із підтримки та від колег — це майбутня перевірна вибірка.
- Обмеження: де дозволено зберігати дані, що вимагається щодо розмежування доступу та журналювання запитів.
- Точки стикування: месенджер, каталог співробітників, тікетниця — куди відповідь має потрапляти й звідки братися контент.
- Критерії приймання: частка відповідей із посиланням на джерело, швидкість відповіді, відсутність вигаданих посилань.
Із цього набору збираємо схему рішення — як контент потрапляє в пошук, як оновлюється при правках і як перевіряється перед публікацією — і розкладаємо порядок робіт за етапами з точкою приймання на кожному.
Обговорення задачі займає одну розмову: опишіть її та надішліть те, що вже є під рукою, відсутнє уточнимо по ходу.
