База знаний агропоставщика для ИИ: как обновлять документы и не путать версии

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

RAG помогает находить материалы и передавать их языковой модели перед формированием ответа. В исходной работе Patrick Lewis и соавторов этот подход объединяет параметрическую модель и внешний индекс фрагментов Wikipedia. Это исследование подтверждает полезность архитектуры на определённых задачах, а не правильность любой корпоративной базы знаний. Retrieval-Augmented Generation, версия 4.

Для агропоставщика управление версиями начинается раньше генерации: с решения, какие документы допустимо показывать конкретному пользователю на конкретную дату. Ниже — проект такого процесса и локальная проверка его правил. Реальная модель, векторный поиск и корпоративное внедрение в этом примере не запускались.

Дата загрузки не равна периоду действия

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

Поэтому вопрос «какой файл самый новый» слишком узкий. Система должна знать:

• какую позицию, партию или модификацию описывает документ;
• когда начинается и заканчивается его действие;
• кто утвердил редакцию и для какой задачи;
• есть ли отзыв, конфликт или запрет на выдачу;
• кому разрешено читать документ.

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

Реестр, из которого можно восстановить ответ

Предлагаемая структура реестра отделяет логический документ от его редакций и фрагментов.

Конец интервала удобно считать исключённым: редакция действует с 1 сентября до начала 1 октября; следующая — с 1 октября. В рабочей системе дополнительно фиксируют точность времени и часовой пояс. Для ответа о прошлой дате нужен отдельный разрешённый сценарий исторической проверки. Пользователь должен видеть, что получил историческую редакцию.

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

Обновление — это несколько согласованных операций

Показать данные текстом

Шаг	Что проверяется
Утверждённая версия	ID, версия, hash; период и область
Кандидат индекса	Фрагменты и ссылки; испытание до активации
Допуск к контексту	Дата, статус, права; регион; конфликт — запрос
Ответ и цитаты	Источник и смысл отдельно; нет источника — отказ
Изменение или отзыв	Новая редакция отдельно; архив не равен выдаче
Блокировка и кэш	Отозванное не выдаётся; права проверяются снова
Повторная проверка	История, будущее, конфликт; критичные факты — эксперт

Ссылка на документ не доказывает правильность вывода. В тесте проверяются два независимых результата.

Показать картинку

Проект жизненного цикла документа и проверки ответа

Практический маршрут можно построить так:

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

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

В Qdrant удаление точек доступно как по ID, так и по фильтру. Удаление только вектора отличается от удаления всей точки: оставшиеся данные могут сохраняться. Это конкретный механизм работы хранилища, а не готовый регламент смены документов. Официальная документация Points.

Перед удалением нужно точно определить редакцию: фильтр только по логическому document_id может затронуть и новую версию. После операции проверяют не ответ «команда принята», а отсутствие старых допустимых фрагментов и поведение контрольных вопросов.

Права проверяются до передачи контекста модели

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

Qdrant поддерживает фильтры по payload; условия must работают совместно как логическое AND. Это позволяет выразить часть правил по метаданным. Однако фильтр базы данных не удостоверяет личность пользователя и не определяет роли компании. Эти решения принимает приложение на основе своей системы доступа. Официальная документация Filtering.

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

Кэш может вернуть отменённое знание

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

Дополнительная защита — заново проверить допустимость источников перед выдачей кэшированного ответа. Это полезно при срочном отзыве документа, когда обычная смена поколения ещё не завершилась. В распределённом сервисе необходимо испытать распространение блокировки между экземплярами и поведение запросов, уже находящихся в обработке.

История диалога и сохранённые ответы — тоже места, откуда может вернуться старое условие. Нельзя подставлять их как проверенный текущий факт. Для ответа на новый вопрос о действующих условиях следует повторно установить применимость источника.

Исполненный локальный пример: 18 вопросов

Учебный комплект содержит девять искусственных документов, реестр, 18 вопросов с вручную заданными эталонами и собственный проверяющий скрипт. В документах только условные коды FAKE_: нет дозировок, реальных цен или инструкций продукции.

Для повторения выполняют python3 build_fixtures.py, затем python3 check_versions.py. Проверка читает файлы и их hash, применяет правила даты, статуса, региона, роли и исключения. Вопрос уже размечен точным fact_key; распознавание естественного языка здесь не проверяется.

Все 18 ожиданий совпали с результатами исполнения. В 18 случаях набор источников соответствовал эталону, а проверка значения ответа дала 17 совпадений: последний ответ намеренно испорчен. Для отказов совпадение означает ожидаемое отсутствие значения.

Это не «точность RAG 94%» и не измерение галлюцинаций модели. Здесь проверены правила допуска и точные искусственные факты. Полный отчёт позволяет проверить каждый вопрос отдельно. Производственный поиск, качество извлечения таблиц, embeddings и генерацию предстоит испытывать на своём разрешённом корпусе.

Источник и ответ оцениваются отдельно

Наличие ссылки отвечает только на первый вопрос: куда можно перейти для проверки. Затем нужно установить, действительно ли источник поддерживает сформулированное утверждение и действует ли он для этой ситуации.

В исследовании ALCE авторы отдельно оценивают корректность ответа и качество цитирования. Для цитат рассматриваются полнота поддержки утверждений и наличие нерелевантных ссылок. Такая постановка полезна для собственной приёмки; опубликованные результаты на исследовательских наборах нельзя переносить на спецификации агропоставщика. Gao и соавторы, ALCE, разделы 3.2–3.3.

Предлагаемый лист приёмки должен содержать две независимые отметки: «выбрана допустимая редакция» и «вывод подтверждается её содержанием». Если модель расширила совместимость, потеряла ограничение или объединила противоречащие условия, ссылка не исправляет ошибку. Критичные утверждения проверяет ответственный специалист.

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

Когда отказ полезнее ответа

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

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