AI-система оптимізації рецептур харчових продуктів

Чому оптимізація рецептур AI дає збій на пілоті

Оптимізація рецептур AI спотикається не на моделі, а на вхідних даних. Сертифікати на сировину, карти вхідного контролю, складські залишки й закупівельні умови лежать у різних системах, а в розрахунок іде усереднена картка інгредієнта з «типовим» складом.

Алгоритм знаходить дешеву комбінацію, але вже на першій партії жирність і вологість приходять іншими — рецептура потребує переробки.

Друга зона відмови — ручні таблиці технолога. Обмеження за складом, допустимі заміни та порядок введення живуть у файлах Excel з версіями «підсумок_фінал_2»: одне правило продубльовано в трьох книгах у різних значеннях, частина порогів тримається в голові провідного фахівця.

Поки це не зведено в єдиний набір правил, автоматизація відтворює приватний досвід, а не технологічний регламент.

З нормативними документами складніше. Вимоги до масових часток, кислотності, вмісту добавок і алергенів записані текстом, без поділу на жорсткі межі та цільові орієнтири.

Модель, яка вважає всі умови строгими, не знаходить рішення взагалі; модель, яка вважає їх м’якими, видає рецептуру, яку не пропустить перевірка.

Звідси провал щодо відтворюваності партії: сировина змінюється від поставки до поставки, і рецептура, оптимальна вчора, на нових сертифікатах дає інший вихід продукту.

Без перерахунку від фактичних значень і протоколу, за яким рішення повторюється, довести стійкість результату неможливо. Розбираємо, як це закривається: єдиний шар даних про сировину, формалізовані обмеження за складом і перерахунок рецептури на партію.

Вимірювані ефекти: що змінюється на виробництві

Після впровадження ми не питаємо «чи стало зручніше».

Рахуємо чотири числа по одній і тій самій лінії: частка рецептур, що пішли на повторний перегляд, час підбору складу під задані собівартість та органолептику, розкид ключових показників між партіями й частка відмов, які раніше закривалися переробкою партії.

Заміри знімаємо до старту й після — на тій самій сировині й тому самому обладнанні, інакше порівнювати нема чого.

Розкид скорочується не тому, що сировина стала рівнішою, а тому що модель працює з коридорами. Для кожної поставки задається допустимий діапазон за білком, жирністю та вологістю, і склад перераховується під фактичний аналіз партії, а не під середній по складу.

Звідси ж іде найболючіша відмова — рецептура, яка тримається в лабораторії й розсипається в масштабі, коли нестабільна сировина приходить хвилею.

Точність цих чисел тримається на планах експерименту: сумішеві моделі та поверхні відгуку рахуємо в JMP, тому внесок інгредієнта у втрати під час термообробки або в текстуру видно до прогону, а не після.

Технолог затверджує варіант і залишається власником рецептури — система пропонує розрахунок і межі, а не рішення.

Три підходи до побудови моделі та їхні обмеження

Рецептура — задача з обмеженнями: укластися в норми за складом, зберегти смак, текстуру й термін придатності. Детермінований розрахунок на балансових рівняннях і лінійній оптимізації дає відтворювану відповідь там, де склад і цільові показники формалізовані.

Але він не знає, як поводитиметься заміна партії сировини й чому в схожої рецептури погіршилася текстура.

Модель на історичних даних навчається на протоколах випробувань і випусків і ловить нелінійні зв’язки, які у формули не закласти. Плата — вимоги до обсягу й чистоти даних і відсутність гарантій щодо жорстких обмежень. Пошук по базі минулих рішень виручає, коли даних мало, але не виходить за межі вже випробуваного.

Варіанти та їхні обмеження

Режим вибирається за зрілістю даних: на тонкому архіві починають із пошуку за минулими рішеннями, за накопичених протоколів підключають модель, гібрид — цільовий стан. На пілоті обидва контури збираються на одних даних, і видно, який стійкий на вашій номенклатурі.

Етапи впровадження: від аудиту даних до передачі

Впровадження системи оптимізації рецептур іде етапами, і порядок тут не довільний: кожен наступний крок спирається на результат попереднього, і до його приймання ми далі не йдемо.

Так знімається типовий ризик, коли розрахунок готовий, а технологи не довіряють видачі й продовжують підбирати склад вручну.

1. Аудит даних. Розбираємо, що накопичено за сировиною, партіями та лабораторними аналізами, наскільки зіставні довідники. На виході — перелік прогалин, які закриваємо до старту.
2. Схема рішення. Фіксуємо, які показники входять у розрахунок і звідки береться кожен, що система повертає технологу: варіанти складу й очікувані характеристики.
3. Налаштування обмежень. Перекладаємо технологічні та нормативні рамки в машинні правила: допустимі частки компонентів, сумісність, сумарні межі за показниками, пріоритет жорстких рамок над м’якими.
4. Перевірка на історичних партіях. Проганяємо систему за минулими випусками й порівнюємо запропоноване з фактичним складом. Рахуємо частку рішень, що потрапили в допуски, розходження розбираємо окремо.
5. Навчання технологів. Показуємо, як читати видачу, змінювати рамки під нову сировину й віддавати зворотний зв’язок у систему, а не в листування.
6. Передача системи. Віддаємо конфігурацію обмежень, документацію, доступи й регламент оновлення даних. Далі команда працює самостійно.

На кожному кроці у вас залишається перевірюваний артефакт: перелік даних, схема розрахунку, набір правил, звіт за минулими партіями.

Конфігурації, схеми даних і регламенти перегляду

Рішення з оптимізації рецептур живе довше, ніж команда, яка його впроваджувала. Тому передаємо не лише працюючий сервіс, а й усе, що потрібно для самостійної експлуатації: налаштування моделі, обмеження за складом, точки інтеграції з обліковими системами. Нижче — комплект, який залишається у замовника.

• Конфігурація рішення. Склад вхідних ознак, допустимі діапазони за компонентами сировини, вагові коефіцієнти цільової функції та окремі профілі розрахунку під різні лінійки продуктів.
• Схема даних. Звідки приходять партії сировини, склади й результати лабораторних аналізів, як вони приводяться до єдиного вигляду і де зберігається історія версій.
• Правила доступу до рецептур. Ролі технолога, аналітика й керівника напряму, розподіл прав на читання, правку й затвердження, журнал дій за кожною формулою.
• Регламент перегляду. Періодичність, підстави (зміна постачальника, відхилення за якістю), хто ініціює, як фіксується рішення і як виконується повернення до попередньої версії.
• Технічна документація. Опис моделі, метрики якості на відкладеній вибірці, відомі обмеження та випадки, де обов’язкова перевірка технолога.
• Інструкції для технологів. Як читати рекомендації, що робити в разі конфлікту з нормативними вимогами, як передати зворотний зв’язок у модель.

Кожен пункт приймаємо разом із робочою групою замовника: до закриття проєкту у вас є не лише сервіс, а й документи, за якими його можна розвивати своїми силами.

Кейс: перегляд рецептур без зупинки лінії

До впровадження перегляд рецептури йшов як окремий проєкт: технолог збирав дані за партіями сировини, вручну перераховував співвідношення компонентів і надсилав пробні заміси в лабораторію.

Один цикл від задачі до затвердженої версії займав 18–25 робочих днів, а частину проб відбраковували за вологістю й органолептикою — частка відхилень сягала 12%.

Поки йшли проби, лінія випускала продукт за попередньою рецептурою, а склад накопичував запаси відразу під кілька версій складу.

Що змінили

Зібрали цифрову модель продукту: специфікації компонентів, допустимі коридори за складом і показниками, обмеження з Кодекс Аліментаріус і внутрішніх регламентів.

Підбір співвідношень рахується відразу за всіма партіями сировини, лабораторія перевіряє лише версії, що пройшли обмеження. Рецептура версіонується, тому відкат до попередньої версії — перемикання посилання, а не перерахунок із нуля.

Метрики до і після

Лінія за весь час впровадження не зупинялася: пробні заміси йшли в планові вікна, перехід на нову рецептуру — у звичайне переналагодження. Зниження переглядів дало побічний ефект: менше списань сировини під час зміни версій складу.

Як бути, якщо нормативні документи суперечать даним?

Розходження між технологічною картою та історією партій — не помилка вивантаження, а робоча ситуація. Документ описує дозволений коридор: масові частки, допустимі замінники, межі за показниками безпеки.

Історія партій показує, що реально відбувалося в цеху: сировина приходила з іншою вологістю, лінія тримала іншу температуру, партія йшла з відхиленням за в’язкістю.

Єдине джерело істини назавжди вибрати не можна: якщо сліпо довіряти документу, система пропонує рецептури, які не відтворюються на поточній сировині, а довіра лише до даних тиражує відхилення, що колись пройшли через недогляд.

Критерій вибору — клас розходження. Усередині коридору документа відхилення приймається як норма й ураховується під час підбору. Вихід за межу за показником безпеки блокує розрахунок повністю, як би часто такі партії не випускалися. Проміжні випадки йдуть у чергу на розбір технологу із зазначенням параметра й величини виходу.

Кожне рішення фіксується в журналі розходжень: параметр, величина, вибраний пріоритет, хто підтвердив. Це дає відтворюваність — спірну рецептуру можна підняти й пояснити, чому вона виглядає саме так.

Обмеження рішення та технічні сумніви

Модель оптимізації рецептур спирається на історію партій і лабораторних замірів, а не на фізику процесу. Її точність упирається в якість даних: якщо сировину зважували «на око», а відхилення записували постфактум, рекомендація спиратиметься на шум.

Перший етап — профілювання: знаходимо розриви, приводимо одиниці та вологість до єдиної бази, позначаємо партії з ручними правками й виводимо їх із навчання.

Частина факторів у модель не потрапляє в принципі — зміна постачальника, знос лінії, рішення оператора. Ми не ховаємо це за точністю до десятих: рішення показує чутливість рецепта до відхилень і видає діапазони, а не одне «ідеальне» значення. Пробне варіння в лабораторії залишається обов’язковим кроком — це закладено в процес.

Зону відповідальності проговорюємо до старту. До передачі ми відповідаємо за коректність даних, відтворюваність розрахунку й документацію за моделлю; після — за регламент роботи відповідає технологічна служба замовника. Межу фіксуємо письмово.

Хто відповідає за рецепт після впровадження?

Формулу затверджує технолог підприємства — модель не має права випускати партію. Ми відповідаємо за розрахунок і супровід, служба якості — за приймання; це прописано в регламенті.

Обговоримо задачу: що потрібно від вас на старті

Щоб повернутися з оцінкою та планом робіт, а не із загальними формулюваннями, потрібен компактний набір вхідних даних для оцінки. Нижче — те, що реально впливає на обсяг першої ітерації моделі оптимізації рецептур. Чогось може не бути в цифровому вигляді — скажіть, підкажемо, як зібрати мінімум.

• Поточні рецептури в структурованому вигляді — склад, дозування, допустимі коридори заміни компонентів; підійде вивантаження з облікової системи.
• Аналізи за сировиною та готовою продукцією — хоча б за показниками, які технолог контролює в кожній партії.
• Технологічні обмеження ділянки: порядок закладки, час обробки, температурні режими, обладнання, яке змінювати не можна.
• Що оптимізуємо — стабільність показника, вихід продукції, частку дорогих компонентів; мета визначає будову моделі.
• Критерії приймання — як ви визнаєте результат робочим: допуск за показником, частка рецептур, що пройшли перевірку технолога.
• Межі пілоту на одній лінії — одна номенклатурна група, одна ділянка, строк спостереження; розширюємо після того, як пілот зійдеться.
• Відповідальний технолог з вашого боку — той, хто підтверджує обмеження й приймає результат.

Цього достатньо, щоб порахувати трудовитрати й повернутися з планом робіт за етапами. Опишіть задачу — ділянку, продукти, що зараз не сходиться. Обговоримо задачу предметно: формат пілоту на одній лінії та порядок приймання.