Как ограничить размер пакета при индексации в LlamaIndex VectorStoreIndex

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

Готовый шаблон Python

from llama_index.core import Document, VectorStoreIndex

docs = [
    Document(text="Политика R7: возврат 14 дней.", id_="R7"),
    Document(text="FAQ D9: доставка по будням.", id_="D9"),
]
# Для стандартных embeddings требуется настроенный провайдер/ключ.
index = VectorStoreIndex.from_documents(
    docs, insert_batch_size=32, show_progress=True)
retriever = index.as_retriever(similarity_top_k=2)
print([(n.node.node_id, n.score) for n in retriever.retrieve("срок возврата")])

Код ниже в статье предназначен для тестовых источников без персональных сведений. Вызовы SDK не выполнялись в данном окружении с реальной моделью; синтаксис Python проверен отдельно. Не переносите вывод демонстрационного эксперимента на любой корпус и любого провайдера без повторной проверки.

Пример входа и ожидаемого результата

Вход: политика R7 о 14 днях и нерелевантный D9 о доставке. Ожидается наличие фрагмента R7 среди извлечённых узлов. Не рассчитывайте, что node_id совпадёт с ID документа: индекс может разбить Document на новые узлы. Для честного сравнения памяти загрузите один и тот же корпус при разных размерах пакета и зафиксируйте peak RSS отдельно.

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

Диагностика и границы решения

Параметр batch size влияет на то, сколько узлов обрабатывается за раз при построении индекса, но не решает проблему некачественного разбиения текста. Если условие и исключение отделились в разных узлах, увеличение пакета не вернёт их в общий контекст. Не называйте in-memory индекс постоянным: после завершения процесса требуется сохранение или внешний store. При удалённом vector database слишком большие пакеты могут вызвать ограничения сервиса, а слишком маленькие — увеличить число обращений. Оптимум зависит от размерности модели, сети и объёма метаданных, поэтому не приводите универсальное значение памяти в гигабайтах. Ключи провайдера задают на сервере; демонстрационный код не содержит секретов. Для точной проверки изменения batch size сравните одинаковые документы, модель, разбиение и параметры поиска. Если качество поиска изменилось, сначала проверьте, не потерялись ли записи при ошибках индексации, а не объясняйте это самим размером пакета.

Дополнительный проверочный сценарий

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

Критерии проверки