ML System Design: прогноз производства по отчетам и LLM-фичи

Базовый слой строится на истории добычи, руднике, регионе, компании, capacity, макро- и рыночных признаках. Для MVP достаточно бустинга или регуляризованной линейной модели с time-based validation.

Сначала нужен честный табличный baseline без LLM. Единица прогноза - рудник и квартал. В признаки входят история добычи, лаги и rolling statistics, регион, оператор/владелец, тип рудника, capacity, сезонность, цены на металл и публичные макро- или отраслевые сигналы.

Модель можно начать с CatBoost/LightGBM или регуляризованной линейной модели. Split должен идти по времени и по рудникам аккуратно: нельзя случайно смешивать будущие кварталы в train. Такой baseline задает нижнюю границу качества и показывает, где текстовые события действительно добавляют сигнал.

История описывает старый режим работы рудника. Инвестиции, расширение capacity или смена технологии меняют data-generating process, поэтому лаги добычи больше не достаточны.

Исторический baseline хорошо работает, пока будущее похоже на прошлое. Инвестиции, запуск новой линии, смена технологии добычи или maintenance shutdown меняют режим процесса. Модель, которая видит только лаги добычи, регион и сезонность, продолжит экстраполировать старую динамику.

Нужны event features: дата объявления, ожидаемый ramp-up, изменение capacity, planned production, delay risk и confidence источника. Такие события лучше хранить как состояние рудника во времени, чтобы модель видела, с какого квартала новый режим должен влиять на target.

Нужны не пересказы, а структурные события: production guidance, maintenance, outages, capacity expansion, grade, ore quality, delays и даты влияния на кварталы.

Из PDF стоит извлекать факты, которые меняют будущий ряд: production guidance, planned maintenance, shutdowns, expansion projects, grade/ore quality, recovery rate, capex milestones, delays, accidents и management commentary с привязкой к руднику и периоду.

Фича должна быть структурной: тип события, рудник, дата публикации, affected quarters, direction, magnitude, source span и confidence. Свободный summary отчета хуже, потому что его сложно валидировать и использовать в табличной модели. Для контроля качества нужны ссылки на страницу/фрагмент документа и правила на невозможные значения.

LLM лучше использовать как extractor структурированных признаков из отчетов: планы роста/падения, guidance, capex, запуск/остановка активов, риски. Финальный прогноз может делать бустинг или другая табличная модель.

Сильная архитектура разделяет извлечение информации и прогноз. LLM читает отчет, таблицы или графики и превращает их в структурированные признаки: плановый рост производства, горизонт плана, confidence, наличие guidance, события по конкретному активу, задержки, capex, regulatory risks.

Затем эти признаки попадают в табличную модель вместе с историей добычи, ценами, сезонностью, регионом, типом актива и макро-факторами. Это сохраняет интерпретируемость и позволяет валидировать ML-модель на historical backtesting.

Важно не просить LLM "сделать прогноз" без контроля. Лучше задать схему вывода, требовать цитаты/страницы источника, отдельное поле missing/unknown и не использовать знания модели вне данного документа.

Хранится версионированный state по руднику: текущий план по кварталам, источник, дата публикации, confidence и история изменений. Новый документ делает patch, а не перезаписывает все вслепую.

Состояние удобно хранить как temporal feature state по руднику. В нем есть production plan по кварталам, capacity, grade, ключевые события, source document, extraction timestamp, publication date и confidence. Важно различать дату события, дату публикации и дату, когда система узнала факт.

Новый отчет не должен просто перетирать state. Extractor возвращает patch: какие поля подтверждены, какие изменились, какие устарели и какие требуют review. Это дает воспроизводимость backtest: для каждого исторического прогноза можно восстановить, какие документы были доступны на тот момент.

Годовой рост может начаться только после запуска проекта или ремонта. Равномерное распределение завысит ранние кварталы и занизит кварталы после ramp-up.

Годовой guidance - агрегат, а модель прогнозирует кварталы. Если рост связан с запуском линии в четвертом квартале, равномерный коэффициент уже в первом квартале создаст ложный сигнал. Модель увидит повышение там, где operationally оно еще невозможно.

Лучше хранить не только annual delta, но и timing assumptions: start quarter, ramp-up curve, confidence, dependency on milestones и delay risk. Если timing неизвестен, признак должен отражать неопределенность, например несколько сценариев или распределение по кварталам, а не один уверенный коэффициент.

Надежнее извлекать event stream и обновлять JSON-state: событие, объект, период влияния, величина, источник и confidence. Summary слишком трудно валидировать.

Для прогноза полезнее не текстовый summary, а структурная лента событий. Каждое событие содержит рудник, тип события, дату публикации, affected period, направление влияния, magnitude, confidence и ссылку на источник. Затем deterministic слой обновляет JSON-state рудника.

Такой дизайн разделяет обязанности. LLM отвечает за извлечение кандидатов из текста, rules/schema validator проверяет формат и допустимые значения, feature pipeline превращает state в табличные признаки. Это упрощает аудит, backtest и ручную проверку спорных событий.

LLM могла видеть будущие отчеты или новости на pretraining. Тогда при backtest она достает знание не из переданного документа, а из параметров модели.

В классическом backtest мы ограничиваем модель информацией, доступной на дату прогноза. У LLM появляется дополнительный канал: pretraining мог включать будущие отчеты, новости, статьи или агрегированные датасеты. Даже если prompt содержит только старый документ, модель может восстановить будущий факт из параметрической памяти.

Снижение риска: использовать модели/снэпшоты с известной датой обучения, требовать citations/source spans, запрещать ответы без опоры на документ, сравнивать с extractive baseline и делать ablation, где LLM получает только документные фрагменты после retrieval. Метрика backtest должна отдельно учитывать leakage risk.

Нужно требовать evidence: ссылка на страницу/таблицу/цитату, confidence, тип извлечения, missing/unknown вместо догадки и human review для спорных признаков.

Контроль начинается с формата вывода. LLM должна возвращать не только значение признака, но и evidence: page id, fragment id, цитату, единицы измерения, период, confidence и reason. Если evidence нет, значение должно быть null/unknown.

Дальше нужна валидация: schema validation, range checks, consistency checks между таблицами и текстом, сравнение с предыдущими отчетами, ручная разметка golden set и метрики extraction quality. Для числовых признаков полезны exact match или tolerance-based метрики, для категориальных — accuracy/F1.

В production стоит логировать source snippets и отдельно мониторить долю unknown, частоту конфликтов и drift форматов отчетов. Для high-impact признаков нужен human-in-the-loop.

Лучше вернуть структурированный объект: annual_guidance=+20%, timing=second_half, q1/q2 evidence missing, assumption_needed=true, confidence ниже. Не надо молча делить на 4.

Если отчет дает годовой рост и говорит, что он начнется во втором полугодии, LLM не должна автоматически распределять +20% равномерно по кварталам. Это уже предположение, а не извлечение.

Правильный output: зафиксировать годовой guidance, период действия, timing hint, evidence, а для квартальных значений вернуть либо null, либо диапазон/сценарий с явным флагом assumption. Например: q1_growth=unknown, q2_growth=unknown, h2_growth_positive=true, annual_growth=20%.

Дальше бизнес-логика или downstream model может решить, как использовать это: отдельная categorical feature "growth concentrated in H2", сценарные фичи, prior distribution или ручная проверка. Главное — не смешивать факт из документа и синтетическое распределение.

Нужны entity resolution по руднику/компании, event deduplication, приоритет источников, temporal ordering и хранение conflicting evidence.

Multi-document слой сначала нормализует сущности: рудник, компания, оператор, регион и период. Затем события дедуплицируются по типу, объекту и временному окну. Если источники расходятся, state должен хранить конфликт, а не молча выбирать последнее значение.

Приоритет источников можно задать правилами: audited annual report выше новости, свежий quarterly update выше старого guidance, но sudden outage из news может быть быстрее официального отчета. Для модели важны не только итоговые поля, но и признаки качества: число источников, recency, confidence и наличие противоречий.

Сравнение остается полезным, если явно ограничить evidence path, добавить leakage flags и сравнивать не LLM “как oracle”, а extractive pipeline с проверяемыми источниками.

Backtest нельзя трактовать как честную оценку будущего, если LLM могла видеть future facts. Но его можно использовать для сравнения controlled variants: один и тот же document set, одинаковый retrieval cutoff, одинаковые schema validators и одинаковая табличная модель.

Отдельно нужно считать leakage-sensitive slices: события после cutoff, документы с поздней публикацией, редкие крупные изменения. Если LLM-фичи дают слишком резкий прирост именно на таких срезах, результат требует ручной проверки. Production-критерий - не только RMSE/MAPE, но и auditability: можно ли показать, из какого доступного источника появилась фича.