AI Enterprise Search — это не просто чат поверх общей папки. Система должна находить данные сразу в нескольких рабочих источниках, учитывать права конкретного пользователя, возвращать прямой ответ на естественном языке и показывать, на какие документы, сообщения или записи он опирается.
Чем Enterprise Search отличается от обычного RAG
Обычный RAG-проект часто начинается с набора заранее загруженных документов. В компании знания распределены между Google Drive, SharePoint, Slack, Confluence, Jira, CRM, support-системой, GitHub и внутренними базами. Enterprise Search решает не только retrieval, но и connectors, синхронизацию, permissions, freshness, structured/unstructured data и аудит доступа.
Какие данные стоит подключать первыми
Начните с 2–3 источников, где сотрудники действительно теряют время на поиск: например Drive + Slack + wiki.
Не подключайте весь стек сразу: каждый connector добавляет отдельную модель permissions, rate limits и правила обновления.
Разделяйте рабочие знания, персональные данные и чувствительные записи с разными политиками индексации.
Для CRM и тикетов заранее определите, какие поля можно показывать в synthesized answer, а какие только открывать по ссылке.
Permission-aware search — обязательное требование
Главный риск — ответить пользователю на основе документа, который он не имеет права видеть. ACL/permissions должны применяться до генерации ответа: retrieval-кандидаты фильтруются с учётом identity пользователя и прав исходной системы. Нельзя надеяться, что LLM «не покажет лишнее» после того, как секретный фрагмент уже попал в prompt.
Сохраняйте source of truth и citations
Каждый ответ должен иметь ссылки на исходные документы или записи.
Сохраняйте source ID, URL, owner, modifiedAt и время последней синхронизации.
Показывайте пользователю, когда источник устарел или был удалён после индексации.
Не смешивайте факт из CRM и предположение модели без явного разделения.
Как строится retrieval pipeline
Connector получает документ/запись и нормализует metadata.
Контент режется на chunks с сохранением source identity и ACL.
Индекс хранит semantic representation и поля для metadata filtering.
Запрос преобразуется в retrieval query; при необходимости используются hybrid keyword + vector search.
ACL-filter оставляет только разрешённые кандидаты.
Reranker выбирает наиболее релевантные passages.
LLM формирует короткий grounded answer и citations.
Freshness важнее размера индекса
Корпоративный ответ быстро теряет ценность, если документ уже обновили, а индекс остался старым. Для часто меняющихся источников полезны webhooks или incremental sync; для остальных — расписание плюс контроль modifiedAt. Удаление или потеря доступа должны отражаться в индексе так же быстро, как добавление документа.
Что измерять вместо «кажется, ищет хорошо»
Retrieval recall на наборе реальных внутренних вопросов.
Citation precision: действительно ли ссылка подтверждает формулировку ответа.
Permission leakage rate — должна стремиться к нулю.
Freshness lag между изменением source и поисковым индексом.
No-answer quality: умеет ли система честно сказать, что подтверждённого ответа нет.
Search-to-source rate: как часто сотрудник открывает найденный первоисточник после ответа.
Защита от prompt injection в корпоративных документах
Документ внутри Drive или wiki может содержать инструкции, которые выглядят как prompt. Retrieval-контент нужно считать недоверенными данными, а не системными инструкциями. Ограничивайте tool execution, отделяйте retrieved text от управляющих сообщений и логируйте попытки заставить agent выполнить действие на основе найденного контента.
Когда нужен agent, а когда достаточно поиска
Для вопроса «какая последняя политика отпусков?» достаточно retrieval + cited answer.
Для «найди договор, проверь дату продления и создай задачу владельцу» уже нужен agentic workflow.
Сначала добейтесь надёжного поиска и permissions, и только потом разрешайте write-actions.
Каждое действие, меняющее внешнюю систему, должно иметь отдельный policy layer и при необходимости human approval.
Пилотный rollout
Соберите 30–50 реальных вопросов от одной команды.
Подключите ограниченный набор источников и перенесите их permissions без упрощений.
Сделайте golden set с ожидаемыми источниками и допустимыми ответами.
Проверьте retrieval, citations, no-answer и permission boundaries.
Запустите пилот на небольшой группе и собирайте failed searches.
Расширяйте connectors только после того, как качество текущих источников измеримо.
Итог
Рабочий AI Enterprise Search строится по схеме connectors → normalized metadata → ACL-aware indexing → hybrid retrieval/reranking → grounded answer → citations → audit. Главная ценность не в том, чтобы «знать всё о компании», а в том, чтобы быстро находить подтверждённый ответ только из тех данных, которые конкретному пользователю разрешено видеть.