ИИ для планирования производства: проверка расписания сводится к сверке предложенного плана с явными ограничениями по строкам. Ниже — учебный вход с тремя заказами и двумя станками, полный допустимый план, намеренно испорченная строка и готовый промпт, который возвращает таблицу нарушений со ссылкой на строку.
Учебный вход: контракт и полный план
Возьмём маленький контракт, где все ограничения выписаны заранее. Два станка M1 и M2 доступны с 08:00 до 16:00. Все заказы допускаются на любом из них. Каждый заказ — одна неделимая операция, выполнить ровно один раз. Между разными заказами на одном станке минимум 30 минут переналадки; перед первым заказом переналадка не требуется. Перерывов, сбоев и иных операций в этом игрушечном контракте нет. З1: 120 минут, срок 12:00, материал доступен 08:00. З2: 90 минут, срок 14:00, материал 08:00. З3: 60 минут, срок 16:00, материал 10:00.
Полный допустимый план выглядит так:
- M1 / З1 / 08:00–10:00
- M1 / переналадка / 10:00–10:30
- M1 / З2 / 10:30–12:00
- M2 / З3 / 10:00–11:00
Простой M2 до 10:00 допустим. Каждый из З1, З2, З3 назначен ровно один раз; длительности 120, 90 и 60 минут; материал З3 готов к началу; сроки 10:00 ≤ 12:00, 12:00 ≤ 14:00, 11:00 ≤ 16:00; рабочий календарь соблюдён. Это допустимый, не доказанно оптимальный план. Такой вход удобен тем, что каждое ограничение можно проверить вручную и сверить с ответом модели.
В обзоре PMC по проекту knowlEdge планирование производственного расписания описано как анализ ограничений между станками, линиями и процессами, который помогает находить узкие места и расставлять приоритеты заказов. Там же отмечено, что система может предлагать перепланирование с учётом текущего состояния склада.
Готовый промпт для проверки расписания
Задача промпта — получить разбор предложенного плана по строкам без молчаливых правок. Скопируйте блок целиком и подставьте свой вход.
Проверь расписание из следующего входа. Сначала посчитай число назначений каждого заказа, затем длительности, календарь/допустимость станка, наличие материала, переналадку, сроки и пересечения. Верни таблицу заказ | станок | длительность по факту/требуется | материал | срок | нарушения и ссылка на строку. Не исправляй план молча, не управляй оборудованием, не называй его оптимальным. Каждое нарушение объясни ссылкой на исходное ограничение. Вход:
Два станка M1/M2 доступны 08:00–16:00; все заказы допускаются на любом из них; каждый заказ — одна неделимая операция, выполнить ровно один раз. Между разными заказами на одном станке минимум 30 минут переналадки; перед первым заказом переналадка не требуется. Перерывов/сбоев/иных операций нет. З1: 120 минут, срок 12:00, материал доступен 08:00; З2: 90 минут, срок 14:00, материал 08:00; З3: 60 минут, срок 16:00, материал 10:00.
План:
M1 / З1 / 08:00–10:00
M1 / переналадка / 10:00–10:30
M1 / З2 / 10:30–12:00
M2 / З3 / 10:00–11:00
Под себя меняйте блок после слова «Вход:» — [ваши станки и часы доступности], [ваши заказы с длительностями], [ваши сроки и материал]. Строки контракта и плана вставляйте дословно: модель сверяет числа построчно, и сокращения ломают сверку.
Вариации той же задачи:
- Проверка только сроков: попросите список заказов, чьё окончание позже срока, с разницей в минутах.
- Проверка переналадок: попросите найти пары соседних заказов на одном станке без 30-минутного разрыва.
- Проверка материала: попросите отметить строки, где старт раньше момента готовности материала.
- Проверка пересечений: попросите найти наложения интервалов на одном станке.
- Перепланирование: дайте изменённую доступность станка и попросите новый план с повторной проверкой всех ограничений.
Отрицательный пример и эталон нарушений
Контрольный брак получается добавлением одной строки к допустимому плану: M2 / З1 / 11:30–13:00. Эталон нарушений содержит три пункта. Первое — дубликат З1: заказ назначен дважды. Второе — длительность 90 минут вместо требуемых 120. Третье — окончание 13:00 позже срока 12:00.
Проверяющий не имеет права проверить только первое вхождение З1 и объявить план корректным. Испорченная строка стоит ниже по списку, и подсчёт назначений обязан пройти по всем строкам. Это и есть главная ловушка при проверке расписания: беглая сверка первых строк даёт ложное «всё в порядке».
Сравним поведение проверок на двух планах.
| Проверка | Исходный план | План с добавленной строкой |
|---|---|---|
| Число назначений каждого заказа | 1, 1, 1 | З1 дважды |
| Длительность по факту | 120, 90, 60 | 120 и 90 для З1 |
| Срок | 10:00, 12:00, 11:00 | 13:00 позже 12:00 |
| Календарь и допустимость станка | интервалы внутри 08:00–16:00, станки допустимы | без нарушений |
| Материал | готов к началу | без нарушений |
| Переналадка | 30 минут между З1 и З2 | без нарушений |
| Пересечения | нет | нет |
Таблица показывает, что добавление одной строки порождает сразу три нарушения из семи проверок. Остальные четыре остаются чистыми. Приёмка требует перечислить каждое найденное отклонение; отсутствие ошибок в остальных проверках сохраняется в отчёте.
Семь проверок по шагам
Порядок проверок фиксирован, и его стоит держать в промпте. Сначала подсчёт назначений: каждый заказ встречается ровно один раз. Затем длительности: конец минус начало равно требуемому времени. Дальше календарь и допустимость станка: интервал внутри 08:00–16:00, станок подходит заказу. После этого наличие материала: старт не раньше момента готовности. Потом переналадка: между разными заказами на одном станке минимум 30 минут. Затем сроки: окончание не позже дедлайна. В конце пересечения: интервалы на одном станке не накладываются.
Приёмка результата опирается на список условий. Список заказов совпадает с требованием. Каждый заказ назначен ровно один раз. Конец минус начало равно длительности. Назначенный станок допустим. Календарь, материал, переналадка, сроки и пересечения проверены. Минимум две конкретные пробы: исходный план проходит ручную проверку, а бракованная добавленная строка обязательно порождает все три нарушения.
В обзоре PMC проект knowlEdge описывает мониторинг производства как сбор данных с датчиков в реальном времени и сопоставление с историей. Система выявляет отклонения от нормы и предлагает корректирующие действия, а сотрудники могут вмешиваться и дополнять базу. Для нашего учебного входа роль такого вмешательства играет ручная сверка эталона.
Карта задач: где ИИ уместен
Разные задачи планирования требуют разного уровня контроля. Сведём их в таблицу.
| Задача | Вход | Исполнитель | Проверка результата |
|---|---|---|---|
| Проверка расписания | операции, мощность, материал | планировщик производства | все семь проверок |
| Объяснение опоздания | план, срок, причина | LLM черновик, человек принимает | сверка цифр по строкам |
| Перепланирование | изменённая доступность и прежние ограничения | планировщик или решатель | повтор семи проверок |
| Прогноз спроса | история заказов, горизонт | аналитик | ошибка на выделенной выборке |
В обзоре PMC отмечено, что планирование расписания включает анализ ограничений и приоритизацию заказов, а симуляция всего процесса с учётом склада позволяет говорить о потребности в сырье и предлагать перепланирование. Там же подчёркнут человеческий контроль: решение остаётся за оператором, а система реагирует на непредвиденные ситуации.
Для объяснения опоздания подходит связка, где LLM готовит черновик, а человек принимает решение. Цифры при этом сверяются по строкам плана. Прогноз спроса опирается на историю заказов и целевой горизонт, а качество измеряется ошибкой на выделенной выборке. В нашем учебном контракте такая ошибка не измеряется, и переносить её оценку на реальное производство нельзя.
Чего не делать при проверке
Первая ошибка — молчаливая правка. Модель, которая исправляет план по ходу разбора, скрывает исходные нарушения. Промпт прямо запрещает править план и управлять оборудованием.
Вторая ошибка — объявление плана оптимальным. Допустимый план удовлетворяет ограничениям, и это всё, что можно утверждать по нашему входу. Оптимальность требует отдельного доказательства.
Третья ошибка — проверка только первого вхождения заказа. Как показывает контрольный брак, дубликат может стоять ниже по списку.
Четвёртая ошибка — перенос учебных чисел на реальное производство. Воспроизводимость зависит от реализации и параметров, а языковая модель может ошибиться даже в этой таблице. Цифры эталона рассчитаны из заданного учебного входа, и результат нейросети в этом разборе не получали.
В обзоре PMC отмечено, что не все организации готовы к внедрению ИИ: важны стратегия, компетенции, данные и совместимость с существующими процессами. Это относится и к проверке расписаний: инструмент работает при ясных ограничениях и понятной процедуре приёмки.
Частые вопросы
Как проверить расписание производства с помощью ИИ?
Дайте модели полный контракт с ограничениями и сам план, попросив таблицу с нарушениями и ссылками на строки. Проверка идёт по семи пунктам: назначения, длительности, календарь, материал, переналадка, сроки, пересечения. Результат сверяйте с ручным эталоном.
Что делать, если модель исправила план вместо разбора?
Добавьте в промпт прямой запрет на молчаливые правки и управление оборудованием. Требуйте отдельного списка нарушений со ссылкой на исходное ограничение. Если правки всё равно появляются, разбейте задачу: сначала подсчёт назначений, затем остальные проверки.
Почему проверка только первого вхождения заказа недостаточна?
Дубликат может стоять ниже по списку, как в контрольном примере со строкой M2 / З1 / 11:30–13:00. Подсчёт обязан пройти по всем строкам плана. Иначе план с повторным назначением получит ложное подтверждение.
Можно ли доверять ИИ в планировании производства?
В обзоре PMC описаны ожидаемые улучшения по показателям, включая сокращение времени планирования и рост эффективности оборудования. Эти значения относятся к конкретному проекту и его условиям. Для отдельного расписания результат зависит от реализации и параметров, а языковая модель может ошибиться даже в простой таблице.
Как проверить календарь и допустимость станка?
Сверьте начало и конец каждой операции с доступностью её станка. В учебном контракте оба станка доступны с 08:00 до 16:00 и подходят для всех заказов. Проверку нужно повторить для каждой строки, включая добавленную ошибочную запись.