AI-аналіз харчування: чому фото страви дає розкид у калоріях
Калорійність рахується за масою, а не за картинкою: знімок дає об'єм, колір і текстуру, але не вагу. Похибка в оцінці ваги порції на око — зазвичай у межах третини, а на соусах і олії сягає дворазової, і вона лінійно переноситься в підсумкову цифру. Тому дві однакові за фото страви розходяться в розрахунку в півтора-два рази.
Друге джерело розкиду — приховані інгредієнти. Заправка, олія на пательні, цукор у маринаді та панірування на фото не видні, а за внеском вони часто перевищують основний продукт: порція овочевого салату з двома ложками соусу переходить з легкої категорії до щільної.
Розпізнавання продуктів за фото впевнено називає «огірок» або «курка», але не знає способу приготування — а він змінює склад сильніше, ніж сам продукт.
Третій шар — щільність. Однаковий на вигляд об'єм рису й листової зелені відрізняється за масою в рази, тому переведення «пікселі в грами» без довідника щільностей дає систематичний зсув в один бік.
Працює це так: сегментація відокремлює компоненти один від одного, калібрування за еталоном у кадрі задає масштаб, щільність і спосіб приготування беруться з бази складу на кшталт USDA FoodData Central, а не вгадуються моделлю.
Підсумок чесного розрахунку складу страви — не одне число, а діапазон із позначкою, що саме його розширило. Нижче розбираємо, як із цього збирається передбачувана система аналізу харчової цінності: де потрібне уточнювальне запитання користувачу, а де достатньо автоматики.
Ефект впровадження: швидкість обробки та частка ручних правок
Ефект вимірюємо не за відчуттями, а прогоном по архіву карток: беремо вибірку, за якою технолог уже підтвердив склад і харчову цінність, і порівнюємо з тим, що видає система.
Дві ключові метрики — частка карток, що пішли в публікацію без правки оператора, і час обробки однієї картки.
До налаштування без правки проходило менше половини записів: система плутала близькі категорії, неправильно читала вагу порції та розкладала склад на компоненти не в тому порядку.
Після приведення довідника до єдиного вигляду й калібрування порогу впевненості частка карток, що проходять наскрізь, зросла до 85–90% — решта потрапляє в чергу на розбір, а не в публікацію.
Час обробки картки скоротився з кількох хвилин ручного введення до секунд: оператор долучається лише до записів із низькою впевненістю. Пропускна здатність зростає відповідно — той самий технолог за зміну закриває обсяг, на який раніше витрачався тиждень.
Окремий ефект — єдиний довідник складу. Раніше той самий інгредієнт існував у базі в десятках написань, частина карток втрачала одиниці вимірювання, а сума компонентів не збігалася із заявленою вагою.
Нормалізація довідника й перевірка збіжності на рівні запису прибирають цей клас помилок цілком: розбіжність виявляється до публікації, а не редактором після.
Довідник збирається з відкритих джерел на кшталт Open Food Facts і внутрішніх даних замовника, тому новинки асортименту розпізнаються без ручного заведення позиції. Людина залишається там, де вона справді потрібна: нестандартні рецептури та склад, описаний маркетинговою мовою.
Режими розпізнавання: фото, штрих-код, ручне введення й гібрид
Жоден режим розпізнавання не дає однакової точності — різниця в тому, що потрапляє на вхід. Пакований продукт зі штрих-кодом, тарілка в кафе й домашній суп потребують різних джерел даних: якщо змішати їх в одному розрахунку, розбіжність за калорійністю сягає дворазової.
Штрих-код і етикетка — найвідтворюваніший шлях: код веде до картки товару, де склад уже розібрано на поля. Обмеження тут не в розпізнаванні, а в покритті бази: без картки або за зміненої рецептури режим мовчки віддає застарілі дані.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Фото страви | Їжа без упаковки: кафе, домашня кухня | Немає еталона — розрахунок за схожими стравами, похибка за масою порції |
| Штрих-код і етикетка | Паковані продукти з читабельним кодом | Потрібна картка товару; склад на етикетці не завжди розмічено під поля розрахунку |
| Ручне введення | Складені страви, замовлення в ресторані | Довгі форми обриваються — зростає частка неточних записів |
| Гібридний режим | Неоднорідний вхід в одному застосунку | Довше в розробці: шар узгодження результатів і вирішення розбіжностей |
Гібридний режим закриває розриви покриття: фото дає первинну оцінку, штрих-код її уточнює, ручне введення працює там, де автоматика не впевнена. Кожен запис зберігає джерело й рівень впевненості — за низького значення він іде на підтвердження, а не в тиху помилку.
Порядок робіт: від аудиту даних до передачі моделі
Роботу ведемо етапами, і кожен закривається перевірюваним артефактом — звітом, схемою або тестом.
Так результат не тримається на одній людині: будь-яку цифру в системі можна простежити від вихідного запису до підсумкового значення, а розбіжність розбирається на конкретному кроці, а не на готовому звіті.
- Аудит даних. Дивимося, що вже є: довідники продуктів, таблиці складу, одиниці вимірювання, дублі й пропуски. На виході — карта даних із переліком прогалин і рішенням, що добираємо вручну, а що закриваємо правилами.
- Схема розрахунку складу. Фіксуємо, як рахуємо харчову цінність: база на порцію чи на масу продукту, обробка неповних записів, кулінарні втрати, допустимі відхилення між джерелами.
- Підготовка набору даних. Приводимо записи до єдиної бази, нормалізуємо найменування, розмічаємо еталонні приклади для навчання й подальшої перевірки.
- Налаштування й навчання. Підбираємо ознаки та правила агрегації, калібруємо на розмітці, окремо перевіряємо стійкість до типових помилок введення й до продуктів зі складним складом.
- Перевірка на контрольній вибірці. Прогоняємо позиції, яких модель не бачила, і звіряємо з ручним розрахунком. Тут важливіша частка розбіжностей та їхній характер, ніж середня точність по всій вибірці.
- Приймання й передача системи. Віддаємо схему розрахунку, документацію, доступи й регламент оновлення довідників, навчаємо команду й залишаємо інструкцію з розбору спірних випадків.
Після передачі система залишається керованою: оновлення довідників і перенавчання відбуваються за описаним регламентом, без обов'язкової участі нашої команди.
Артефакти проєкту: схеми даних, політики доступу, регламенти
Після здачі в команди замовника залишається не звіт про виконану роботу, а робочий комплект документів, за яким систему можна розвивати власними силами або передати іншій команді без зворотного проєктування. Нижче — що саме входить до цього комплекту й навіщо потрібен кожен артефакт.
- Схеми потоків даних — звідки надходить склад продукту, як нормалізуються одиниці та розмір порції, у якому вигляді результат іде у ваші системи.
- Модель даних і контракти обміну — поля, типи, обов'язковість, поведінка за неповного опису продукту.
- Політики доступу — ролі аналітика, технолога, адміністратора: хто бачить дані, хто змінює пороги розрахунку, хто затверджує довідник.
- Правила ведення довідника — джерела, обробка пропусків і викидів, версіонування записів.
- Регламент оновлення довідника — періодичність, хто затверджує, порядок відкату версії в разі падіння метрик якості.
- Документація системи — логіка розрахунку, відомі обмеження, метрики якості, інструкції для підтримки.
- Журнал змін і матриця відповідальності — що і ким змінювалося, до кого йти із запитанням щодо конкретного блоку.
Такий комплект закриває головний ризик супроводу AI-системи аналізу харчування: коли логіка розрахунку живе лише в коді та в голові автора. Зміни до довідника або політики доступу вносяться за документом — без повторного обстеження системи й без зупинки розрахунків.
Кейс: як зросла точність аналізу складу на потоці замовлень
Клієнт — роздрібна мережа із застосунком, де покупець сканує упаковку й отримує розбір складу за нутрієнтами.
Частина етикеток не піддавалася автоматичному розбору: таблиця харчової цінності зверстана у дві колонки, значення подано на порцію замість 100 г, інгредієнти записано синонімами й торговими назвами.
До впровадження такі позиції вручну розбирав оператор: переносив цифри, перераховував порції, зіставляв інгредієнти з довідником. На потоці це давало чергу, а користувач замість відповіді бачив, що склад не розпізнано, — і писав у підтримку.
Як організували розбір
Аналіз харчування в застосунку NutriLine розділили на два кроки: розпізнавання тексту етикетки й нормалізація — приведення одиниць до 100 г, зведення синонімів до довідника, перевірка суми макронутрієнтів на збіжність.
Якщо впевненість нижче порогу або сума розходиться, позиція йде оператору, а її розбір потрапляє в навчальну вибірку.
Метрики до й після
Частка позицій, розібраних без оператора, зросла з 58% до 93% — вручну залишилися переважно зім'яті та засвічені фото. Помилки в калорійності та БЖВ на контрольній вибірці скоротилися з однієї картки з дванадцяти до однієї із шістдесяти.
Повторні звернення в підтримку на тему «неправильний розбір» упали втричі: типовий спір викликав перерахунок порції, тепер він закритий на етапі нормалізації.
Щоб точність не відкотилася, складні етикетки складаються в регрес-набір, а раз на тиждень інженери вручну перевіряють випадкову вибірку розборів. Нові формати упаковки йдуть на донавчання тим самим циклом.
Чим відрізняється оцінка за фото від розбору складу за етикеткою?
За фото модель відновлює склад опосередковано: спочатку розпізнає продукт або страву, потім підбирає типове значення з довідника й оцінює порцію за геометрією знімка. Похибка накопичується на кожному з трьох кроків, тому результат — завжди діапазон, а не точне число. За етикеткою ми читаємо те, що виробник уже виміряв і зобов'язаний зазначити.
Таблиця харчової цінності — структурований набір полів: калорійність, білки, жири, вуглеводи, цукор, сіль.
Інженерне завдання тут — розпізнати текст за відблисків і дрібного шрифту, зібрати рядки в таблицю з коректною прив'язкою «показник — значення — одиниця», привести до єдиної бази на 100 г і перевірити збіжність. Похибка виходить локальною й перевірюваною: видно, з якого фрагмента упаковки взято значення.
Точність методів має різну природу. У розбору етикетки вона визначається повнотою полів і якістю розпізнавання тексту; в оцінки за фото — розкидом довідника й невидимими компонентами: олією на пательні, соусом, заправкою, начинкою. Ширина коридору залежить від страви: для яблука вона вузька, для салату із заправкою — широка.
Тому в AI-аналізі харчування ми не вибираємо один метод. Спочатку система шукає маркування: якщо таблицю харчової цінності розпізнано, візуальна оцінка не потрібна.
Якщо упаковки немає, вмикається оцінка за фото з явним довірчим інтервалом і можливістю виправити порцію або склад вручну.
На тестовому наборі рахуємо частку полів, витягнутих без правки, частку значень у допуску до еталона й калібрування інтервалів — наскільки заявлена похибка збігається з фактичною. Так точність методів стає вимірюваною величиною, а не обіцянкою.
Сумніви щодо якості даних: розбираємо часті запитання
AI-аналіз харчування впирається не в модель, а в довідник складу й правила перерахунку. Якщо джерело неповне або запис застарів, система видає правдоподібну, але неправильну цифру — це гірше за явну помилку. Розбираємо сумніви, які найчастіше порушують під час оцінювання.
Правило просте: значення або підтверджено джерелом, або позначено як оцінка з діапазоном.
Що робити, якщо довідник неповний?
Ми зіставляємо записи за синонімами й торговими назвами та об'єднуємо кілька джерел, зберігаючи походження кожного значення. Для позиції без підтвердженого складу рахуємо діапазон за близькими продуктами й позначаємо його як оцінку. Порожнє поле чесніше за вигадане число.
Як враховується сезонний асортимент?
Склад партії залежить від сезону, регіону й виробника, тому записи довідника версіонуються з датою дії, а розрахунок прив'язується до конкретної партії. Під час оновлення джерела зачеплені записи перераховуються, і видно, які показники змінилися.
Що з термообробкою та втратами?
Для кожного способу приготування задаються коефіцієнти збереження нутрієнтів з урахуванням режиму й часу. Розрахунок ведеться за вагою до й після обробки, втрати показуються окремим рядком — у звіті видно, звідки різниця між сирим і готовим продуктом.
Хто має права доступу до даних?
Доступ розмежовується за ролями: окремо на набір даних, окремо на поля й вивантаження. Звернення до довідника журналюються, вивантаження віддається без зайвих полів — рецептури й комерційні дані не виходять за межі погодженого контуру.
Обговоримо задачу: покажемо схему й повернемося з оцінкою
Щоб стартувати без розгону, нам потрібна не тека документів на сотню сторінок, а робоча вижимка щодо даних і правил предметної області. Нижче — що зазвичай запитуємо на вході, і що віддаємо назад до першого рядка коду.
- Вивантаження каталогу: артикули, найменування, категорії, склад за інгредієнтами, значення на 100 г і на 100 мл — у тому вигляді, у якому вони лежать в обліковій системі.
- Довідники вхідних компонентів з одиницями вимірювання та приведенням до спільної бази: сипкі, рідкі, порційні позиції.
- Правила розрахунку, якими користується ваш технолог: перерахунок на порцію, допустимі округлення, регіональні вимоги до маркування.
- 100–300 позицій із ручною розміткою — на них калібруємо модель і бачимо розбіжність ще до запуску в контур.
- Метрики приймання: частка позицій з відхиленням у межах допуску, поріг за критичними нутрієнтами й поля, де помилка неприпустима.
- Доступ до джерела даних: репліка бази, файлове вивантаження або програмний інтерфейс — плюс контакт людини, відповідальної за довідники.
- Відповідь щодо обмежень: де працює система, хто бачить результат, чи потрібне вивантаження в наявну звітність.
У відповідь ви отримуєте схему рішення: як дані проходять від джерела до відповіді, де зберігаються, як оновлюються і що відбувається в разі розбіжності. До неї — план робіт за етапами з точками перевірки та оцінкою трудовитрат.
Опишіть задачу й надішліть те, що вже є з переліченого, — повернемося зі схемою та планом робіт.
