Реализация AI-поиска по базе знаний компании в мобильном приложении
Корпоративный мобильный инструмент с AI-поиском — это другой класс задач по сравнению с пользовательским чат-ботом. Тысячи сотрудников, конфиденциальные данные, роли и права доступа, документы из разных систем (Confluence, SharePoint, Notion, Jira), актуальность контента. Здесь недостаточно просто «подключить RAG».
Источники данных и их особенности
Корпоративная база знаний редко живёт в одном месте:
- Confluence — статьи, регламенты, техническая документация. REST API, вебхуки об изменениях
- SharePoint / OneDrive — Word, Excel, PDF-документы. Microsoft Graph API
- Notion — заметки, проекты, базы данных. Notion API
- Jira / Linear — тикеты, комментарии, описания задач
- Внутренние Wiki — часто legacy, с нестандартными API
Для каждого источника нужен отдельный коннектор: авторизация, получение документов, отслеживание изменений (delta sync), удаление устаревших векторов.
Самое сложное — delta sync. Нельзя переиндексировать все 50 тысяч документов каждую ночь. Нужно получать только изменённые с момента последней синхронизации. Confluence и Notion поддерживают вебхуки — это предпочтительный путь. SharePoint — Microsoft Graph change notifications.
Права доступа: самая трудная часть
Сотрудник не должен через AI-поиск получить доступ к документам, которые ему недоступны напрямую. Это юридически и технически критично.
Два подхода:
Permission-aware indexing. При индексации сохраняем ACL (Access Control List) документа в метаданных вектора. При поиске фильтруем по правам текущего пользователя.
# При индексации
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 результатов.
Мобильный UI для корпоративного поиска
Корпоративный пользователь в первую очередь хочет понять, откуда пришёл ответ, и когда документ обновлялся. UI должен это показывать:
- Ответ AI с цитатами (выделенные фрагменты из документов)
- Карточки источников: иконка системы (Confluence/Notion/SharePoint), название документа, автор, дата обновления, кнопка «Открыть оригинал»
- Скор уверенности (не число, а «Высокая/Средняя/Низкая» релевантность)
- Кнопка «Ответа не нашёл» для создания тикета в поддержку
Поиск должен работать с опечатками и неточными формулировками — это достигается комбинацией векторного поиска (устойчив к перефразированию) и fuzzy BM25 (устойчив к опечаткам).
Актуальность контента: TTL и переиндексация
Устаревший ответ хуже отсутствия ответа. Если регламент изменился, а индекс не обновился — AI даст неверную инструкцию. Механизмы:
-
TTL для чанков: документы старше N дней помечаются как устаревшие, приоритет в поиске снижается через metadata filter
{"updated_at": {"$gte": threshold}} - Вебхуки от источников: мгновенная переиндексация при изменении
- Scheduled resync: раз в сутки проверка checksums для выявления изменений без вебхуков
На мобильном — показываем дату последнего обновления источника рядом с каждым результатом.
Аналитика использования
Корпоративный инструмент требует аналитики: какие вопросы задают, на какие нет ответов, какие документы самые используемые. Это помогает редакторам базы знаний заполнять пробелы.
Логируем каждый поиск: запрос, найденные источники, оценку пользователя (thumbs up/down). Дашборд для администраторов с топом «нашли ответ / не нашли».
Этапы и сроки
Инвентаризация источников данных и их API → проектирование схемы прав доступа → разработка коннекторов и delta sync → ingestion pipeline → поиск с permission filtering → мобильный UI → аналитика → пилот с группой сотрудников → полный rollout.
MVP с одним источником (например, только Confluence), базовым поиском и мобильным приложением — 5–7 недель. Полноценная система с 3–5 источниками, правами доступа и аналитикой — 3–5 месяцев.