Dagster подходит для обновления корпуса бизнес-документов перед RAG, когда нужен конвейер с версиями, проверками и видимой историей запусков. Каждый этап описывается как актив: выгрузка файлов, очистка текста, нарезка, загрузка в индекс. При блокирующей проверке следующий этап стартует только после её успеха. Если документов мало и они меняются раз в квартал, хватит ручной загрузки с чек-листом.
Активы корпуса
Корпус для RAG в Dagster собирается цепочкой активов: исходные файлы, очищенный текст, фрагменты, индекс. Проверки стоят между активами и останавливают цепочку до того, как плохая версия попадёт в поиск.
Dagster описывает данные как активы: по документации, актив — это логическая единица данных вроде таблицы или набора данных. Для корпуса такая модель подходит почти буквально. Возьмём реестр внутренних регламентов: файлы лежат на общем диске, правят их несколько отделов, а чат-бот отвечает сотрудникам по последней редакции. Задачу обновления решает код: скрипт читает папку, считает контрольную сумму каждого файла, сверяет с прошлым запуском и собирает список изменений. Языковой модели в этой части конвейера нет, всю работу делает код.
Запуск настраивают двумя способами. Расписание (schedule) выбирают, когда документы меняются регулярно, например после еженедельной планёрки. Сенсор (sensor) реагирует на событие, скажем на появление нового файла в папке. Поиск и ответ со ссылкой на источник разобраны в статье про n8n RAG и обновление индекса, а общие принципы подготовки лежат в материале про версии, права и разбиение корпуса. Здесь разговор о том, как оркестратор держит эту подготовку под контролем.
Первый запуск делает полную загрузку, последующие обрабатывают только изменения. Для этого вместе с контрольными суммами сохраняют снимок списка файлов: по нему отличают удалённый документ от переименованного. Без снимка переименование выглядит как исчезновение одного регламента и появление другого, а старые фрагменты остаются в индексе и продолжают попадать в ответы. Такая мелочь чаще всего и создаёт ситуацию, когда бот цитирует отменённый приказ.
Версия и раздел
Разделы (partitions) в Dagster нужны для инкрементальной обработки: конвейер запускается только на нужном срезе данных. Корпус удобно резать по владельцу документа: бухгалтерия, закупки, склад. Правка одного регламента перезапускает один раздел, остальные остаются как были. Резать по месяцу изменения тоже можно, но владелец удобнее для проверки: у раздела есть человек, отвечающий за содержание.
| Событие в источнике | Что делает конвейер | Что сверяет человек |
|---|---|---|
| Появился новый файл | Читает текст, режет на фрагменты, пишет в новую версию индекса | Файл относится к нужному владельцу, права доступа указаны верно |
| Файл изменили | Сравнивает контрольную сумму и пересобирает фрагменты только этого документа | В ответах бота исчезла старая редакция |
| Файл удалили или заменили | Убирает фрагменты старой редакции из новой версии индекса | Удалённый регламент исчез из ответов |
| Файл пришёл сканом | Передаёт на распознавание, результат идёт в тот же актив | Текст после распознавания совпадает с оригиналом на выборке страниц |
Каждому фрагменту присваивают идентификатор документа, номер редакции и дату источника. Без этих полей откат и проверка превращаются в ручной поиск по папкам. Для сканов распознавание вынесено в отдельный шаг: подробности про такие файлы описаны в статье про Docling и документы перед RAG. Dagster отвечает за порядок и повторные запуски, а форматы разбирает специализированный инструмент.
Название раздела закрепляют в конфигурации: если выводить его из имени папки на лету, переименование каталога породит новый раздел и дубль фрагментов. Список разделов и их владельцев хранят рядом с кодом конвейера, чтобы при проверке сразу было видно, кому адресовать вопрос по спорному документу.
Проверки перед публикацией
Проверки в Dagster оформляют декоратором @asset_check: функция возвращает AssetCheckResult с признаком passed и уровнем важности. По умолчанию запуск после провала проверки родительского актива продолжается, и следующие активы всё равно строятся. Чтобы поставить заслон, параметр blocking выставляют в True: тогда зависимые активы ждут исправления. Для корпуса этот режим нужен прямо перед активом «индекс».
- Сравните число фрагментов с прошлой версией. Резкое падение значит, что часть папки осталась непрочитанной.
- Найдите пустые и обрезанные фрагменты, а также текст с побитой кодировкой.
- Убедитесь, что у каждого фрагмента заполнены документ, редакция и дата источника.
- Прогоните список контрольных вопросов с известными источниками: поиск должен вернуть нужный документ среди первых результатов.
- Передайте итог владельцу корпуса вместе со списком изменённых документов. Публикацию версии подтверждает человек.
Контрольные вопросы собирает владелец корпуса: он знает, какой документ должен найтись по какой формулировке. Список растёт после каждой жалобы пользователей. Пока он пуст, зелёная проверка гарантирует лишь целостность файлов, а полезность поиска остаётся непроверенной. При провале проверки конвейер останавливается на своём шаге, а владелец получает короткое сообщение: какой актив, какая проверка, сколько фрагментов затронуто. Исправление идёт в источнике, после чего запускают тот же раздел заново, и повторная сборка даёт тот же результат на тех же входных файлах.
Какие документы вашей компании чаще всего устаревают в базе знаний?
Откат версии
Откат версии индекса — свойство вашей схемы хранения, перекладывать его на оркестратор бессмысленно. Рабочий вариант строится так: индекс создаётся под именем версии, а поиск читает указатель на текущую версию. Новая версия собирается рядом со старой, проходит проверки, и после подтверждения человека указатель переключается. Если пользователи нашли ошибку, указатель возвращается к прежней версии одним действием, а проблемный документ разбирают без спешки.
- Предыдущая версия индекса, которую удаляют только после приёмки новой.
- Список изменённых документов каждого запуска.
- Номер запуска Dagster рядом с версией индекса: по нему жалобу связывают с конкретным обновлением.
- Запись о том, кто подтвердил переключение указателя.
Права на документы входят в ту же схему. Если у раздела есть ограничение доступа, его записывают в метаданные фрагмента, а проверяет его поиск при каждом запросе. Закрытые и открытые разделы в одной версии без метки смешивать нельзя.
Перед переключением указателя прогоните те же контрольные вопросы на обеих версиях и сравните ответы рядом. Расхождение в пользу новой версии подтверждает обновление, расхождение в пользу старой останавливает публикацию. Так решение о выпуске опирается на сравнение, а ощущение разработчика, что всё собралось, роли в нём играть перестаёт.
Видимость и владелец
Зависимости между активами показываются в интерфейсе Dagster графом, а метаданные материализации позволяют записать число документов, число фрагментов и номер версии. Этого хватает, чтобы ответить на вопрос, из чего собран индекс, по которому бот отвечал вчера. Сообщение об ошибке содержит название актива, номер запуска и ссылку на журнал, а тексты документов в него исключены. В журнале хранят идентификаторы документов и счётчики, но содержимое файлов оставляют там, где оно лежало: журнал читает больше людей, чем регламент.
У конвейера два владельца: технический следит за запусками, содержательный подтверждает версии. Если нужен проект целиком, посмотрите страницу про нейросети для работы с документами: состав работ и стоимость мы определяем после знакомства с вашим корпусом.
Руководителю достаточно короткой сводки по каждому обновлению: сколько документов добавлено, изменено и убрано, прошли ли проверки, какая версия сейчас читается поиском. Такая сводка собирается из метаданных запуска автоматически и отвечает на главный вопрос эксплуатации: можно ли верить базе знаний сегодня. Если ответ неясен, публикация версии откладывается до разбора причины. Свежесть базы знаний при этом остаётся вопросом владельца содержания, а работоспособность запусков остаётся вопросом технического владельца.
Возьмите один раздел корпуса, например регламенты одного отдела, и опишите его тремя активами: файлы, фрагменты, индекс. Добавьте одну блокирующую проверку и список контрольных вопросов. Остальные разделы подключайте после нескольких чистых обновлений подряд.