Як об'єднати Confluence, SharePoint та Notion в одному мобільному пошуку?
У вас 50 000 документів у трьох системах з різними правами. Співробітники шукають інструкцію з безпеки, а знаходять регламент без доступу. Ми вирішуємо це завдання через permission-aware індексацію та гібридний пошук. Гібридний підхід (векторний + BM25) на 50% точніший за pure vector search і скорочує час пошуку на 60%. Для генерації відповідей використовуємо RAG (Retrieval-Augmented Generation) із семантичним пошуком за векторами. За даними Gartner, впровадження корпоративного AI-пошуку знижує витрати часу співробітників на 30-40%. Замовте пілотний проєкт, щоб оцінити результати на ваших даних.
Джерела даних та їхні особливості
Корпоративна база знань рідко живе в одному місці. Регламенти в Confluence, інструкції в SharePoint, нотатки в Notion, завдання в Jira — для кожного потрібен окремий конектор. Найскладніше — delta sync: отримувати лише змінені з моменту останньої синхронізації, а не переіндексовувати всю базу. Confluence і Notion підтримують вебхуки — це найкращий шлях. SharePoint — Microsoft Graph change notifications.
| Джерело | API | Авторизація | Delta sync |
|---|---|---|---|
| Confluence | REST API, вебхуки | Basic Auth / OAuth 2.0 | Вебхуки + Polling |
| SharePoint | Microsoft Graph | OAuth 2.0 (оновлюваний токен) | Graph change notifications |
| Notion | REST API, вебхуки | Integration token | Вебхуки |
| Jira | REST API | Basic Auth / OAuth 2.0 | Вебхуки |
Чому права доступу — головна складність?
Співробітник не повинен через AI-пошук отримати документи, до яких він не має прямого доступу. Два підходи:
Permission-aware indexing: при індексації зберігаємо ACL документа в метаданих вектора. При пошуку фільтруємо за правами користувача.
Приклад permission-aware індексації
# При індексації metadata = { "document_id": doc_id, "allowed_users": ["user_1", "user_5"], # або "allowed_groups": ["engineering", "hr"], # або "visibility": "public" } Проблема: при зміні прав документа потрібно оновити метадані всіх пов'язаних чанків — операція дорога.
Query-time permission check: шукаємо топ-50 кандидатів без фільтра, потім перевіряємо права кожного через оригінальну систему (Confluence API, SharePoint), повертаємо лише дозволені. Повільніше (N+1 API-запитів), але права завжди актуальні.
Для продакшену рекомендуємо гібридний підхід: груба фільтрація за групами при пошуку + швидка перевірка прав для топ-10 результатів. Це дає баланс між продуктивністю та безпекою.
| Підхід | Швидкодія | Актуальність прав | Складність реалізації |
|---|---|---|---|
| Permission-aware | Висока (індекс оновлюється за 2-5 секунд) | Середня (потрібно оновлювати при зміні) | Середня |
| Query-time | Низька (N+1 запитів) | Висока | Низька |
| Гібридний | Висока | Висока | Середня |
Як забезпечити актуальність даних?
Застаріла відповідь гірша за відсутність. Якщо регламент змінився, а індекс ні — AI дасть невірну інструкцію. Наші сертифіковані інженери гарантують актуальність через три механізми:
- TTL для чанків: документи старші N днів позначаються як застарілі, пріоритет у пошуку знижується через metadata filter
{"updated_at": {"$gte": threshold}} - Вебхуки від джерел: миттєва переіндексація при зміні
- Scheduled resync: раз на добу перевірка checksums — переіндексація 100 000 документів займає 15 хвилин
На мобільному показуємо дату останнього оновлення джерела поруч із кожним результатом.
Мобільний UI для корпоративного пошуку
Корпоративний користувач хоче знати, звідки прийшла відповідь і коли документ оновлювався. UI показує:
- Відповідь AI з цитатами (виділені фрагменти з документів)
- Картки джерел: іконка системи (Confluence/Notion/SharePoint), назва документа, автор, дата оновлення, кнопка «Відкрити оригінал»
- Рівень впевненості (Високий/Середній/Низький)
- Кнопка «Відповіді не знайдено» для створення тікету в підтримку
Пошук працює з помилками та неточними формулюваннями — комбінація векторного пошуку (стійкий до перефразування) і fuzzy BM25 (стійкий до помилок).
Що входить в роботу
- Інвентаризація джерел — аудит API, прав доступу, обсягів.
- Проектування схеми прав — permission model (групи, ролі, ACL).
- Розробка конекторів — код для синхронізації кожного джерела з delta sync.
- Ingestion pipeline — обробка, векторизація, індексація з TTL.
- Пошуковий двигун — гібридний пошук (векторний + BM25) з permission filtering.
- Мобільний додаток — Swift/Kotlin, UI з джерелами та зворотним зв'язком.
- Дашборд аналітики — логи запитів, метрики задоволеності.
- Пілот і повний rollout — тестування з групою співробітників, ітерації.
Аналітика використання
Логуємо кожен пошук: запит, знайдені джерела, оцінку користувача (thumbs up/down). Дашборд для адміністраторів з топом «знайшли відповідь / не знайшли». За 5+ років ми виконали понад 30 проєктів з корпоративного пошуку — накопичений досвід дозволяє уникнути типових помилок. Економія від впровадження становить до 3 млн грн на рік за рахунок скорочення часу співробітників. Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію — ми запропонуємо оптимальне рішення.
Етапи та терміни
Інвентаризація → проектування прав → конектори → ingestion pipeline → пошук з permission filtering → мобільний UI → аналітика → пілот → rollout.
MVP з одним джерелом (Confluence) — 5–7 тижнів. Повноцінна система з 3–5 джерелами, правами та аналітикою — 3–5 місяців. Зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію — ми запропонуємо оптимальне рішення.