Согласованность Milvus: почему новый документ ещё не находится

Подтверждённая вставка и доступный поиску документ являются разными наблюдениями в Milvus. До перестроения индекса или обвинения embedding-процесса проверьте выбранную согласованность и границы клиентской сессии, через которую документ должен увидеть потребитель.

Назвать контракт видимости

Руководство согласованности Milvus описывает strong, bounded, session и eventual. Эти режимы определяют видимость чтения, а не качество эмбеддингов. Сохраните реальный выбор в проверочном запросе либо настройке коллекции. Отсутствие нового документа может соответствовать контракту чтения и не означает автоматически провал вставки. Поздний успешный поиск также не объясняет прежнее состояние без записанных времени, клиента и конфигурации, использованных при обеих проверках.

Разделить этапы индексации

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

Намеренно использовать два клиента

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

Граница	Наблюдение
Подтверждение записи	Операция принята по своему контракту
Чтение той же сессии	Видимость внутри этой сессии
Поиск другого клиента	Видимость для реального потребителя

Проверить коллекцию и арендатора

Руководство multi-tenancy различает способы организации данных. Читатель способен обращаться к другой коллекции или применять tenant-фильтр, исключающий новую точку. До обвинения consistency проверьте эти условия. Также сохраните ревизию: найденная старая версия не подтверждает видимость последнего обновления. Видимости и релевантности нужны разные контроли. Используйте проверку известной записи рядом с поисковым набором приложения, чтобы эти вопросы можно было различить по результатам.

Не менять опыт во время ожидания

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

Сделать вывод пригодным для исправления

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

Связанные материалы: Локальный RAG-сервер: какие компоненты размещать рядом с GPU; Память векторной базы: как выбрать RAM и диск для поиска.