Ctrlk
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Время первичной индексации

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

Что известно о времени для УТ и ERP

Подтверждённых сопоставимых замеров полного первого запуска типовых УТ и ERP для CPU, локальной GPU и облачного API пока нет. Универсальную таблицу часов по одному числу объектов нельзя считать измерением или гарантией. Для конкретной выгрузки нужны её версия, объём кода, число чанков и настройки модели.

Режим эмбеддингов
Ориентир для планирования
Что проверить до большого запуска

Локальная модель на CPU

Многочасовое окно; точное число часов — по пробному прогону. Подтверждённой нормы для УТ/ERP нет

Модель и её размер, реально доступные CPU и RAM контейнера, отсутствие swap, локальный SSD

Локальная модель на GPU

Ускоряется вычисление эмбеддингов, но не обязательно весь запуск. Подтверждённого коэффициента ускорения для УТ/ERP нет

Модель действительно помещается в VRAM и использует GPU; загрузка на CPU и сброс слоёв в RAM меняют результат

Внешний API, например OpenRouter

Срок зависит от пропускной способности и лимитов провайдера; API не гарантирует завершение за ночь. Подтверждённой нормы для УТ/ERP нет

Модель и размерность, токены/мин, запросы/мин, задержка, 429, повторы, бюджет и стабильность соединения

light описывает состав образа, а не скорость эмбеддингов. Сервер с light может обращаться и к облаку, и к LM Studio на локальном компьютере. GPU в LM Studio и GPU внутри контейнера — разные способы исполнения; наличие видеокарты само по себе не подтверждает ни один из них.

Ранее приводившиеся диапазоны «2–6 / 10–20 / 20–60 часов на CPU» и «30–60 минут / 2–4 / 5–10 часов на GPU» не привязаны к воспроизводимым замерам. Использовать их как норму для своей УТ или ERP не следует.

Подтверждённый пример: ЗУП через OpenRouter

В отдельном прогоне 05.09.2026 первичное заполнение пустых индексов ЗУП завершилось за 3 ч 52 мин 10 с — по итоговому сообщению INDEXING COMPLETE. Это наблюдение одного корпуса, не норматив для УТ/ERP и не сравнение CPU с GPU.

Параметр
Зафиксировано в журнале

Начальное состояние

Коллекции metadata, code, help и forms пусты

Источники

12 106 файлов BSL, 11 215 единиц метаданных XML, 1 782 файла HTML справки

Эмбеддинги

OpenRouter, qwen/qwen3-embedding-8b, 4 096 измерений; локальная модель не использовалась

Параллелизм

8 workers разбора, 6 embedding workers, размер батча 64

Векторное хранилище

zvec, профиль fast_index, HNSW, fp16, mmap

Охват

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

Результат

INDEXING COMPLETE, total time: 3h 52m 10s

В итоговой строке стоит mode=incremental: это выбранный алгоритм, а не доказательство повторного запуска. В этом случае начальные коллекции были пусты, а исходники классифицированы как new. Версия другой конфигурации, характеристики оборудования и лимиты API могут существенно изменить время; полного сопоставимого протокола для УТ/ERP на CPU, GPU и API этот пример не заменяет.

Подтверждённый пример: только структурный разбор ЗУП

В отдельном прогоне 07.09.2026 разбор и запись структурного индекса той же выгрузки ЗУП (12 106 файлов BSL) заняли 6 мин 20 с: 232 931 символ, 1 728 817 вызовов, предупреждений Overlapping definition не было, INFO N/M file(s) done шла каждые 60 секунд. Это не полный первый запуск и не время векторных эмбеддингов: замерена дорожка, которая раньше могла два часа не печатать ни строки. Восьмикратная разница полного sub-index (часы против ~17 минут на stable) этим разбором не объясняется — сам парсер на этом корпусе укладывается в минуты.

Из чего складывается время

  • Чтение и хеширование исходников, определение формата и извлечение метаданных.

  • Разбор BSL, HTML и форм, разбиение текста на чанки.

  • Вычисление эмбеддингов — локально или через API.

  • Запись, полнотекстовая индексация и оптимизация векторного хранилища.

  • Структурный индекс, граф зависимостей, формы и XSD — согласно включённым дорожкам.

  • Проверка целостности и публикация готового поколения.

На каждом старте и каждом плановом тике сервер хеширует все исходники включённых дорожек, чтобы понять, изменилось ли что-нибудь; если ничего не изменилось, сборка не запускается. Этот проход упирается в чтение файлов. На Windows с Docker Desktop выгрузка, смонтированная с диска C: (-v C:/...:/app/code), читается через файловую систему 9p: на выгрузке ERP (26 тысяч модулей) такой проход занимает 15–20 минут против половины минуты для той же выгрузки внутри файловой системы WSL2 (ext4). Если выгрузка большая, держите её и том /app/chroma_db внутри WSL2 — например, выгружайте в \\wsl$\Ubuntu\home\<user>\erp и запускайте docker run из дистрибутива WSL с -v /home/<user>/erp:/app/code — или в именованном томе Docker.

Этапы могут перекрываться. Время ответа embedding API нельзя просто умножить на число файлов: файлы имеют разный размер, один файл даёт несколько чанков, запросы идут батчами и параллельно. Замер качества поиска на небольшом корпусе также не измеряет полный первый запуск УТ/ERP.

Как оценить оставшееся время на своей выгрузке

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

  2. Смотрите журнал своего контейнера:

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

  3. Найдите строки своей дорожки, а не чужой. Векторные дорожки пишут code progress, metadata progress или help progress: обработанные/всего файлы, число чанков, files/min, ETA и размер очереди. С образов от 02.10.2026 ETA … by size считается по объёму оставшихся файлов, а строка называет его: 869.0 of 1680.0 MiB left. Файлы кода обрабатываются от меньших к большим, поэтому оценка по числу файлов в хвосте фазы занижена в разы: там остаются самые крупные модули. Структурный проход этих строк не пишет — у него Sub-index pass: started и затем INFO N/M file(s) done примерно раз в минуту, даже когда ни один файл не залип. Warning still active past относится к конкретной единице, а не ко всему проходу. Начальный прогрев модели не показателен; сравните несколько последовательных интервалов на крупных и небольших файлах. Если INFO структурного прохода нет дольше минуты, монитор выключен (SUB_INDEX_PROGRESS_WARN_SEC=0) либо образ старше этой правки.

  4. Используйте ETA только как оценку остатка текущей дорожки, а не всего сервера. Для ручной оценки по двум отметкам:

    Считайте по объёму (MiB left), а не по числу файлов: оставшиеся файлы крупнее уже обработанных. На образах старше 02.10.2026 объёма в строке нет, и оценка по файлам в хвосте фазы кода занижена.

    Единицы времени должны совпадать. При нулевом приросте оценка не определена; это повод проверить очередь, провайдера, CPU, диск и ошибки, а не обещать время завершения. Не объединяйте отметки разных запусков или дорожек.

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

  6. После завершения сохраните Lane '…' completed in …, итоговую строку INDEXING COMPLETE / total time и результат stats. Живой контейнер, healthy или выполненная на 100% дорожка сами по себе не доказывают готовность всех индексов.

Как получить сопоставимый замер первичной индексации

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

Для каждого замера фиксируют:

  • УТ или ERP, точную версию, формат Designer XML/EDT и состав расширений;

  • число BSL/XML/HTML-файлов, объём исходников и итоговое число чанков по дорожкам;

  • тег и digest образа; доступные контейнеру CPU/RAM, диск и способ монтирования;

  • CPU/GPU и VRAM либо провайдера API; точную модель и размерность;

  • включённые дорожки, PARSE_WORKERS, EMBEDDING_CONCURRENCY, EMBED_BATCH_SIZE_API или EMBED_BATCH_SIZE_LOCAL;

  • отдельное время загрузки/прогрева модели, длительность каждой дорожки, оптимизации и всего запуска;

  • для API — фактические токены, стоимость, лимиты, число ошибок и повторов;

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

Первый холодный запуск, повторный запуск на пустой БД с прогретой моделью и инкрементальное обновление публикуются отдельно. До появления таких результатов конкретные часы для типовых УТ/ERP остаются непроверенными.

Перезапуск и сохранность прогресса

  • Постоянный том /app/chroma_db сохраняет данные при пересоздании контейнера. Обычный docker restart того же контейнера сам по себе не удаляет его файловый слой, но без тома удаление контейнера удалит и данные из этого слоя.

  • Наличие тома не означает сохранение каждого рассчитанного чанка: это зависит от механизма восстановления в установленной версии. В реализации с чекпоинтами только завершённых дорожек незавершённая дорожка строится заново даже при правильном -v.

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

  • Если stats().indexing.last_outcome стал degraded, а у коллекции write_health=failed и rebuild_required=true, инкрементальный тик больше не клонирует пустые поколения и не удаляет каталог <lane>.rebuild. Поиск по опубликованному поколению продолжает отвечать. Следующий обычный прогон, даже на неизменной выгрузке, восстанавливает дорожку из сохранённых в ней документов без разбора исходников и эмбеддингов; по времени это одно полное слияние дорожки. Если degraded остался и после него, лечение — reindex(force=true): из исходников пересобираются только повреждённые дорожки, здоровые (в том числе миллионы чанков code) переносятся. Если повреждённых дорожек нет, force=true по-прежнему начинает пустое поколение.

  • После полной пересборки граф зависимостей пишет XML в одну транзакцию (SUB_INDEX_BULK_LOAD=true). Если дорожка dependency_graph после force ползёт десятками файлов в час, это признак образа без этой правки либо выключенного bulk-load.

  • Не используйте RESET_DATABASE=true, удаление тома или docker compose down -v как обычный способ восстановления после прерывания. Сначала сохраните журнал и выясните причину.

  • Для плановой остановки дайте процессу время завершиться, например docker stop --time 120 1c_code_metadata_mcp. Это время ожидания, не гарантия завершения всей индексации; по истечении таймаута Docker может остановить процесс принудительно.

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

  • Даже при побатчном сохранении нельзя гарантировать нулевую повторную оплату каждого API-запроса: провайдер мог уже принять запрос, а процесс — не успеть получить ответ или зафиксировать его на диске. Повториться могут незавершённые запросы; при нескольких workers их может быть несколько.

Настройки модели и параллелизма: конфигурация. Команды запуска и монтирование: установка.

PreviousКонфигурация
NextGraph Metadata Search

Last updated