Один контракт для любого источника
Синхронизация по курсору, только изменения, и единая форма записи, которую индекс читает, не зная, из какой системы она пришла.

IIIContext
1С, Drive, почта и CRM входят в один индекс вместе с правами, которые в них уже заданы. Ничего не переносится, и каждый результат открывается в своей системе.
Context
Каждый документ приходит с правами своей системы, поэтому индекс отвечает человеку только тем, что ему открыто.
Синхронизация по курсору, только изменения, и единая форма записи, которую индекс читает, не зная, из какой системы она пришла.
Модель доступа источника читается при загрузке и становится проверкой на каждом запросе. Мы переводим правила и никогда не назначаем их сами.
БИН, ИИК и номера договоров требуют точного совпадения, и поиск только по смыслу их пропускает. Context ищет обоими способами и возвращает один список.
Номер находит свою запись, фраза находит смысл, и оба результата приходят одним списком.
PDF, Word, таблицы и письма читаются полностью и делятся на фрагменты. Пункт в середине договора находится так же, как его название.
Поиск должен понимать язык раньше модели: формы слов, варианты написания, смешанные фразы. Context работает с обоими языками на каждом шаге.
Русский и казахский в одном документе, и один контрагент, записанный тремя способами в четырех системах.
Люди спрашивают о том, что помнят наполовину. Нестрогий вопрос к точному индексу находит запись и две соседние.
Свой сервер, изолированный контур или дата-центр в Казахстане. Индекс и проверка прав работают там, где должны оставаться данные.
Тот же индекс и та же проверка, упакованные для дата-центра, который вы назовете. Ничто не покидает контур ради поиска.
Модель, которая отвечает, выбираете вы, и ключ к ней ваш. Хранение нулевое, обучение исключено, и оба правила держит шлюз при каждом вызове.
Фильтр работает внутри запроса. Документ, который нельзя открыть, не попадает в выборку, поэтому не просочится ни через выжимку, ни через ссылку, ни через счетчик.
Поиск начинается с набора, который человеку можно читать. Фильтровать результаты после означало бы уже прочитать то, что потом скрывается.
Никому не сообщают, что существует другой результат. Разница в самом поиске и в самом счетчике.
Каждая система уже решает, кому что открыто, и Context применяет это решение на выходе. На нашем корпусе: 197 из 208 файлов открыты hello@, 51 адресу клиента, 0 утечек за 16 запросов.
Файл, открытый одному человеку, находит этот человек. Файл, открытый по ссылке, находят все, у кого она есть. Ничего не назначается заново вручную.
Доступ, отозванный в источнике, гаснет здесь при следующей синхронизации. Проверка привязана к моменту запроса, поэтому вчерашним правам негде храниться.
По коннектору на источник, и каждый читает записи и права, которые в этой системе уже есть.
Drive и Gmail. Доступ к каждому файлу читается из источника, и именно это делает проверку прав настоящей.
Реализации, контрагенты и номенклатура через OData, изменения по версии данных. Те самые записи, по которым здесь ищут.
Сделки, контакты и задачи через REST, изменения приходят исходящими вебхуками.
Каждый вызов модели уходит через один шлюз. Он считает расходы, отказывает провайдеру, которому нельзя видеть эти данные, и держит нулевое хранение в одном месте.
Смените модель, которая отвечает, не трогая поиск. Собственная модель на своем сервере такой же полноправный вариант, и его требует изолированный контур.
Одна точка выхода для всех вызовов модели, с учетом токенов и расходов по каждому клиенту и каждому агенту.
Развертывание в Казахстане ограничивает, какой провайдер может обслужить запрос. Шлюз отказывает остальным, и никакая настройка этого не отменяет.
Context внедряют на реальном корпусе с реальными правами те инженеры, которые его построили. Расскажите, что у вас работает и где должны храниться данные.