AI-система анализа питательной ценности продуктов

Оценка калорийности «на глаз» даёт разброс, из-за которого страдают рекомендации и отчётность. Мы разрабатываем AI-систему анализа питательной ценности под ключ: распознавание по фото, штрих-коду и этикетке, с понятными правилами ручных правок. Сокращаем долю ручной проверки и время обработки заказа вдвое.
Часто задаваемые вопросы

AI анализ питания: почему фото блюда даёт разброс в калориях

Калорийность считается по массе, а не по картинке: снимок даёт объём, цвет и текстуру, но не вес. Ошибка в оценке веса порции на глаз — обычно в пределах трети, а на соусах и масле доходит до двукратной, и она линейно переносится в итоговую цифру. Поэтому два одинаковых по фото блюда расходятся в расчёте в полтора-два раза.

Второй источник разброса — скрытые ингредиенты. Заправка, масло на сковороде, сахар в маринаде и панировка на фото не видны, а по вкладу они часто перекрывают основной продукт: порция овощного салата с двумя ложками соуса уходит из лёгкой категории в плотную. Распознавание продуктов по фото уверенно называет «огурец» или «курица», но не знает способа приготовления — а он меняет состав сильнее, чем сам продукт.

Третий слой — плотность. Одинаковый на вид объём риса и листовой зелени отличается по массе в разы, поэтому перевод «пиксели в граммы» без справочника плотностей даёт систематический сдвиг в одну сторону. Работает это так: сегментация отделяет компоненты друг от друга, калибровка по эталону в кадре задаёт масштаб, плотность и способ приготовления берутся из базы состава вроде USDA FoodData Central, а не угадываются моделью.

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

Эффект внедрения: скорость обработки и доля ручных правок

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

До настройки без правки проходило меньше половины записей: система путала близкие категории, неверно читала вес порции и раскладывала состав на компоненты не в том порядке. После приведения справочника к единому виду и калибровки порога уверенности доля карточек, проходящих насквозь, выросла до 85–90% — остальное уходит в очередь на разбор, а не в публикацию.

Время обработки карточки сократилось с нескольких минут ручного ввода до секунд: оператор подключается только к записям с низкой уверенностью. Пропускная способность растёт соответственно — тот же технолог за смену закрывает объём, на который раньше уходила неделя.

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

Справочник собирается из открытых источников вроде Open Food Facts и внутренних данных заказчика, поэтому новинки ассортимента распознаются без ручного заведения позиции. Человек остаётся там, где он действительно нужен: нестандартные рецептуры и состав, описанный маркетинговым языком.

Режимы распознавания: фото, штрих-код, ручной ввод и гибрид

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

Штрих-код и этикетка — самый воспроизводимый путь: код ведёт к карточке товара, где состав уже разобран на поля. Ограничение здесь не в распознавании, а в покрытии базы: без карточки или при изменённой рецептуре режим молча отдаёт устаревшие данные.

Вариант Когда подходит Ограничения
Фото блюда Еда без упаковки: кафе, домашняя кухня Нет эталона — расчёт по похожим блюдам, ошибка по массе порции
Штрих-код и этикетка Упакованные продукты с читаемым кодом Нужна карточка товара; состав на этикетке не всегда размечен под поля расчёта
Ручной ввод Составные блюда, заказ в ресторане Длинные формы обрываются — растёт доля неточных записей
Гибридный режим Неоднородный вход в одном приложении Дольше в разработке: слой согласования результатов и разрешения расхождений

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

Порядок работ: от аудита данных до передачи модели

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

  1. Аудит данных. Смотрим, что уже есть: справочники продуктов, таблицы состава, единицы измерения, дубли и пропуски. На выходе — карта данных с перечнем пробелов и решением, что добираем вручную, а что закрываем правилами.
  2. Схема расчёта состава. Фиксируем, как считаем пищевую ценность: база на порцию или на массу продукта, обработка неполных записей, кулинарные потери, допустимые отклонения между источниками.
  3. Подготовка набора данных. Приводим записи к единой базе, нормализуем наименования, размечаем эталонные примеры для обучения и последующей проверки.
  4. Настройка и обучение. Подбираем признаки и правила агрегации, калибруем на разметке, отдельно проверяем устойчивость к типовым ошибкам ввода и к продуктам со сложным составом.
  5. Проверка на контрольной выборке. Прогоняем позиции, которых модель не видела, и сверяем с ручным расчётом. Здесь важнее доля расхождений и их характер, чем средняя точность по всей выборке.
  6. Приёмка и передача системы. Отдаём схему расчёта, документацию, доступы и регламент обновления справочников, обучаем команду и оставляем инструкцию по разбору спорных случаев.

После передачи система остаётся управляемой: обновление справочников и переобучение идут по описанному регламенту, без обязательного участия нашей команды.

Артефакты проекта: схемы данных, политики доступа, регламенты

После сдачи у команды заказчика остаётся не отчёт о проделанной работе, а рабочий комплект документов, по которому систему можно развивать своими силами или передать другой команде без обратного проектирования. Ниже — что именно входит в этот комплект и зачем нужен каждый артефакт.

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

Такой комплект закрывает главный риск сопровождения AI-системы анализа питания: когда логика расчёта живёт только в коде и в голове автора. Изменения в справочник или политику доступа вносятся по документу — без повторного обследования системы и без остановки расчётов.

Кейс: как выросла точность анализа состава на потоке заказов

Клиент — розничная сеть с приложением, где покупатель сканирует упаковку и получает разбор состава по нутриентам. Часть этикеток не поддавалась автоматическому разбору: таблица питательной ценности свёрстана в две колонки, значения даны на порцию вместо 100 г, ингредиенты записаны синонимами и торговыми названиями.

До внедрения такие позиции вручную разбирал оператор: переносил цифры, пересчитывал порции, сопоставлял ингредиенты со справочником. На потоке это давало очередь, а пользователь вместо ответа видел, что состав не распознан, — и писал в поддержку.

Как устроили разбор

Анализ питания в приложении NutriLine разделили на два шага: распознавание текста этикетки и нормализация — приведение единиц к 100 г, сведение синонимов к справочнику, проверка суммы макронутриентов на сходимость. Если уверенность ниже порога или сумма расходится, позиция уходит оператору, а её разбор попадает в обучающую выборку.

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

Доля позиций, разобранных без оператора, выросла с 58% до 93% — вручную остались в основном мятые и засвеченные фото. Ошибки в калорийности и БЖУ на контрольной выборке сократились с одной карточки из двенадцати до одной из шестидесяти. Повторные обращения в поддержку по теме «неверный разбор» упали втрое: типовой спор вызывал пересчёт порции, теперь он закрыт на этапе нормализации.

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

Чем отличается оценка по фото от разбора состава по этикетке?

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

Таблица пищевой ценности — структурированный набор полей: калорийность, белки, жиры, углеводы, сахар, соль. Инженерная задача здесь — распознать текст при бликах и мелком шрифте, собрать строки в таблицу с корректной привязкой «показатель — значение — единица», привести к единой базе на 100 г и проверить сходимость. Ошибка получается локальной и проверяемой: видно, из какого фрагмента упаковки взято значение.

Точность методов имеет разную природу. У разбора этикетки она определяется полнотой полей и качеством распознавания текста; у оценки по фото — разбросом справочника и невидимыми компонентами: маслом на сковороде, соусом, заправкой, начинкой. Ширина коридора зависит от блюда: для яблока она узкая, для салата с заправкой — широкая.

Поэтому в AI-анализе питания мы не выбираем один метод. Сначала система ищет маркировку: если таблица пищевой ценности распознана, визуальная оценка не нужна. Если упаковки нет, включается оценка по фото с явным доверительным интервалом и возможностью поправить порцию или состав вручную.

На тестовом наборе считаем долю полей, извлечённых без правки, долю значений в допуске к эталону и калибровку интервалов — насколько заявленная погрешность совпадает с фактической. Так точность методов становится измеримой величиной, а не обещанием.

Сомнения по качеству данных: разбираем частые вопросы

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

Правило простое: значение либо подтверждено источником, либо помечено как оценка с диапазоном.

Что делать, если справочник неполный?

Мы сопоставляем записи по синонимам и торговым названиям и объединяем несколько источников, сохраняя происхождение каждого значения. Для позиции без подтверждённого состава считаем диапазон по близким продуктам и помечаем его как оценку. Пустое поле честнее выдуманного числа.

Как учитывается сезонный ассортимент?

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

Что с термообработкой и потерями?

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

Кто имеет права доступа к данным?

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

Обсудим задачу: покажем схему и вернёмся с оценкой

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

  • Выгрузка каталога: артикулы, наименования, категории, состав по ингредиентам, значения на 100 г и на 100 мл — в том виде, в котором они лежат в учётной системе.
  • Справочники входящих компонентов с единицами измерения и приведением к общей базе: сыпучие, жидкие, порционные позиции.
  • Правила расчёта, которыми пользуется ваш технолог: пересчёт на порцию, допустимые округления, региональные требования к маркировке.
  • 100–300 позиций с ручной разметкой — на них калибруем модель и видим расхождение ещё до запуска в контур.
  • Метрики приёмки: доля позиций с отклонением в пределах допуска, порог по критичным нутриентам и поля, где ошибка недопустима.
  • Доступ к источнику данных: реплика базы, файловая выгрузка или программный интерфейс — плюс контакт человека, отвечающего за справочники.
  • Ответ по ограничениям: где работает система, кто видит результат, нужна ли выгрузка в существующую отчётность.

В ответ вы получаете схему решения: как данные проходят от источника до ответа, где хранятся, как обновляются и что происходит при расхождении. К ней — план работ по этапам с точками проверки и оценкой трудозатрат.

Опишите задачу и пришлите то, что уже есть по перечисленному, — вернёмся со схемой и планом работ.

Направления AI-разработки

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1542
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1393
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1081
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1368
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    815
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1139