Как обновлять базу знаний ИИ при изменении документов в Notion, Confluence и Google Docs

Короткий ответ: одного подключения коннектора недостаточно. Чтобы ассистент отвечал по актуальным документам, нужен конвейер обновления из трёх частей: реакция на события изменений, регулярная сверка индекса с источником и проверка прав доступа в момент ответа. События дают скорость, но не гарантируют, что ни одно изменение не потеряется. Сверка обнаруживает пропуски. Проверка прав не позволяет ассистенту цитировать документ, к которому у человека уже нет доступа.

Главное условие: удалённый документ или отозванный доступ должны перестать влиять на ответы так же надёжно, как обновлённый текст начинает на них влиять. После этой статьи вы сможете описать цикл «документ изменён, индекс обновлён, ответ проверен» для своих источников, определить допустимую задержку и составить список проверок после сбоя.

Что считать актуальностью

До выбора технологии стоит договориться, что именно означает «актуальная база знаний». Иначе нельзя понять, работает ли синхронизация, и настроить оповещения.

Для каждого документа в индексе полезно хранить как минимум четыре значения:

• Идентификатор в источнике. У страницы Notion, страницы Confluence или файла Google Drive есть стабильный ID. Именно по нему, а не по названию, нужно находить старые фрагменты для замены.
• Версию или время изменения в источнике. Это позволяет понять, содержит ли индекс последнюю редакцию.
• Время последней успешной индексации. Не время попытки, а момент, когда новые фрагменты действительно заменили старые.
• Права доступа, с которыми документ попал в индекс. Кто мог его читать в момент индексации и как эта информация обновляется.

Затем определите допустимую задержку. Это бизнес-решение, а не техническое. Для справочника о корпоративной культуре задержка в сутки может быть приемлема. Для прайса, правил возврата или инструкции по безопасности она может быть слишком большой. Для отзыва доступа к кадровому или финансовому документу допустимая задержка обычно минимальна.

Полезно разделить документы на классы по критичности и для каждого записать допустимую задержку обновления, а отдельно записать допустимую задержку удаления. Это станет основой для выбора событий, сверки или их сочетания.

События или периодическая сверка

Есть два основных способа узнать об изменениях.

События (webhooks). Платформа сама отправляет сообщение на ваш адрес, когда что-то меняется. В Notion есть webhooks для изменений страниц, баз данных и комментариев. Для платформы Forge в Confluence документированы события создания, обновления, перемещения страницы в корзину, восстановления, удаления и изменения её разрешений. В Google Drive можно подписаться на уведомления об изменениях, но уведомление лишь сообщает, что изменения есть; подробности нужно получить из ленты изменений.

У событий есть важные ограничения, о которых стоит знать заранее:

• Событие часто не содержит содержимого. Например, в Notion оно сообщает ID страницы и тип изменения, а актуальный текст интеграция должна отдельно получить через API.
• Часть событий объединяется. Частые правки одной страницы Notion могут прийти одним уведомлением с небольшой задержкой, обычно до минуты. Не следует ожидать мгновенной реакции на каждый символ во время тестирования.
• Доставка не абсолютно гарантирована. Notion прямо описывает доставку как «не более одного раза» с повторами, если сервер не подтвердил получение. Если сервер был недоступен дольше периода повторов, событие можно потерять.
• Не каждое изменение порождает событие. В Notion нет отдельного события об изменении прав доступа к странице. При удалении целого пространства Confluence не отправляет отдельные события удаления для его дочерних страниц. Событие также не придёт, если у интеграции нет доступа к объекту.

Периодическая сверка. Интеграция по расписанию сама спрашивает источник, что изменилось. В Google Drive для этого есть лента изменений с токеном продолжения: вы сохраняете токен после каждого прохода, а в следующий раз получаете изменения только после него. Для источников без такой ленты сверка может сравнивать список документов и даты их изменения с тем, что записано в индексе.

Сверка медленнее событий, но обнаруживает то, что события пропустили. Поэтому для рабочей системы лучше не выбирать что-то одно, а сочетать оба способа: события быстро обновляют данные, а регулярная сверка закрывает пропуски, удаления без событий и изменения прав.

Идемпотентное обновление

Идемпотентность означает, что повторная обработка одного и того же изменения даёт тот же результат, что и первая. Для базы знаний это критично: повторы неизбежны. Платформа может отправить событие дважды, сверка может обнаружить изменение, уже обработанное событием, а обработчик может упасть посередине и запуститься снова.

Что нужно для идемпотентного обновления:

1. Ключ документа. Все фрагменты в индексе должны ссылаться на ID документа в источнике. Тогда обновление означает «удалить все фрагменты документа X и записать новые», а не «добавить новые фрагменты».
2. Проверка версии. Перед заменой система сравнивает версию или время изменения с тем, что уже есть в индексе. Если в индексе та же или более новая версия, повторное событие ничего не меняет.
3. Атомарная замена. Старые фрагменты не удаляются, пока новые не записаны. Иначе в промежутке ассистент может не найти ничего или найти только часть документа.
4. Журнал результата. Для каждой обработки записываются документ, версия, число фрагментов, успех или ошибка и время.

Типичная ошибка без идемпотентности: после каждого повторного события в индексе появляется ещё одна копия тех же фрагментов. Поиск начинает выдавать дубликаты, вытесняя другие полезные фрагменты, а после нескольких редакций старые версии текста продолжают находиться рядом с новыми.

Удаление и права доступа

Именно удаление и отзыв доступа чаще всего ломают базы знаний. Новый документ заметен: кто-то ищет его и жалуется, если не находит. Удалённый документ, который продолжает влиять на ответы, замечают поздно, обычно когда ассистент цитирует отменённое правило.

Удаление. Когда документ удалён, перемещён в корзину или архив, его фрагменты нужно убрать из индекса или пометить как недоступные для поиска. Стоит проверить и производные места: кэш ответов, сохранённые ссылки в истории диалогов, отдельные копии на других языках. Если источник не отправляет событие об удалении (например, для дочерних страниц при удалении целого пространства Confluence), это должна обнаружить регулярная сверка: документ есть в индексе, но отсутствует в источнике или стал недоступен.

Права доступа. Здесь есть два уровня.

Первый уровень — права самой интеграции. Если интеграцию отключили от пространства или страницы, она перестаёт получать события и читать документ. При этом индекс сам не очищается. Сверка должна обнаружить, что документ стал недоступен, и убрать его фрагменты.

Второй уровень — права человека, который задаёт вопрос. Интеграция может иметь доступ ко всему пространству, а конкретный сотрудник может иметь доступ только к его части. Поэтому при ответе система должна фильтровать найденные фрагменты по правам пользователя. Надёжнее выполнять эту проверку на уровне поиска или отдельного сервиса прав, а не поручать модели соблюдать инструкцию «не показывай закрытое». Модель вообще не должна получать фрагмент, который человек не вправе видеть.

Поскольку не все платформы сообщают об изменении прав через событие, права в индексе нужно обновлять и во время сверки. Для самых чувствительных документов имеет смысл проверять доступ непосредственно в источнике перед выдачей ответа, если это позволяют лимиты API.

Ошибки и восстановление

Синхронизация ломается не только из-за пропущенных событий. Типичные причины: лимиты API, временная недоступность источника, истёкший токен авторизации, слишком большой для обработки документ, ошибка в коде разбиения текста. Важно, чтобы каждую такую проблему было видно и для неё существовал способ восстановления.

Минимальный набор механизмов:

• Очередь с повторами. Событие сначала записывается в очередь, затем его забирает обработчик. Если обработка завершается ошибкой, событие возвращается в очередь с постепенно увеличивающейся паузой. После нескольких неудачных попыток оно попадает в отдельный список проблемных событий, о чём узнаёт ответственный сотрудник.
• Учет лимитов. Массовая сверка может исчерпать лимит запросов и заблокировать обработку событий. Сверку следует планировать с ограничением скорости, отдавая приоритет событиям.
• Сохранение курсоров. Для ленты изменений Google Drive токен продолжения сохраняется только после успешной обработки страницы изменений. Если сохранить его раньше и затем упасть, изменения между токенами будут пропущены.
• Журнал и оповещения. Отдельно отслеживаются время последнего успешного обновления каждого источника, количество событий в очереди, проблемных событий и расхождений, найденных сверкой. Оповещение срабатывает не на каждую ошибку, а при нарушении допустимой задержки из первого раздела.
• Полная переиндексация как запасной план. Должна быть возможность заново построить индекс одного пространства или всего источника. Это долго, но единственный гарантированный выход, если курсор потерян или в логике обновления была ошибка.

После любого сбоя полезно ответить на три вопроса. Какие документы изменились за время сбоя? Все ли они уже обработаны? Были ли среди них удаления или изменения прав?

Проверка после изменения

Технический журнал показывает, что обновление произошло. Но для бизнеса важнее другое: отвечает ли ассистент по новой версии и не раскрывает ли закрытую информацию. Это проверяют контрольными вопросами.

Ниже приведён учебный пример цикла. Время условное и не гарантирует такую скорость реакции любой платформы.

Учебный сценарий обновления регламента

Из этого примера следует набор контрольных вопросов для каждого критичного документа:

• Вопрос о новом содержании. Ответ должен отражать текущую, а не предыдущую версию.
• Вопрос об удалённом содержании. После удаления документа ассистент не должен его цитировать и должен честно сказать, что актуальная информация не найдена.
• Вопрос от пользователя без доступа. Ответ не должен раскрывать закрытую информацию ни прямо, ни пересказом.
• Повтор события. После повторной обработки число фрагментов документа не должно меняться.

Вывод

Актуальность базы знаний зависит не от коннектора, а от процесса: события обеспечивают скорость, сверка обеспечивает полноту, идемпотентная замена отвечает за корректность, а проверка прав в момент ответа — за безопасность. Самые слабые места обычно связаны не с обновлением текста, а с удалениями и отзывом доступа, потому что платформы сообщают о них менее надёжно.

Что можно сделать в своём процессе:

1. Составьте список источников и классов документов. Для каждого класса запишите допустимую задержку обновления и отдельно задержку удаления или отзыва доступа.
2. Проверьте, какие события каждая платформа действительно предоставляет для ваших сценариев, особенно для удаления и изменения прав. Всё, что не покрыто событиями, должна покрывать сверка.
3. Убедитесь, что у каждого фрагмента в индексе есть ID документа и версия, а обновление атомарно заменяет фрагменты.
4. Настройте журнал с временем последнего успешного обновления каждого источника и оповещение при превышении допустимой задержки.
5. Подготовьте для критичных документов контрольные вопросы: новое содержание, удалённое содержание, запрос без доступа, повтор события. Проверяйте их после каждого изменения логики и после сбоев.
6. Убедитесь, что существует процедура полной переиндексации и определено, кто вправе её запускать.

Если ваш ассистент работает с постоянно меняющимися документами, команда BotLabs может обсудить это с вами на 15-минутной консультации. Разберём, какие источники и классы документов у вас есть, какая задержка обновления допустима и с каких контрольных вопросов начать проверку актуальности. Следующим шагом определим, что стоит проверить в вашей текущей схеме синхронизации.

Часто задаваемые вопросы