Так получилось, что мы с нашей командой разработки вместе с линейкой совместных с фирмой 1С типовых конфигураций занимаемся развитием и внедрением нескольких перспективных продуктов и направлений. В их числе:
-
Сервис мониторинга производительности для высоконагруженных систем на базе 1С,
-
Сценарный обработчик конфигурации, который мы используем для быстрой и качественной сборки релиза всей линейки отраслевых решений.
Наш новый проект – технология распознавания блюд и самообслуживания гостей на предприятиях питания, об истории разработки и пилотного внедрения которой я хотел бы рассказать.
Цель проекта и бизнес-контекст
Вначале была идея – максимально ускорить процесс обслуживания гостя в столовой. Гость набирает поднос, проходит через раздачу, берет все, что хочет, и дальше его нужно как можно быстрее обслужить. Мы занимаемся общепитом и комплексной автоматизацией более 20 лет и часто получаем такие запросы. Значительная часть нашего бизнеса – операторы кейтеринга и индустриального питания: столовые на заводах, в геологоразведке, нефтедобыче и других отраслях. Основная задача там – успеть обслужить всех гостей за обеденный перерыв, и эта необходимость нередко прямо прописана в контракте с операторами питания.
Первый подход: RFID-посуда
В самом начале мы экспериментировали с посудой с RFID-метками. Сделали даже несколько экземпляров сами – приклеивали метки эпоксидкой. Эту посуду до сих пор используем в офисе. На раздаче возле кассира устанавливался объемный сканер RFID-меток, который, когда поднос оказывался на нем, считывал массив меток и определял, что нужно добавить в чек.
Подобные системы распространены, например, в Юго-Восточной Азии, но в России оказалось сложно купить такую посуду. На AliExpress можно заказать партию из 200 штук, но обеспечить постоянную ротацию посуды с необходимыми сертификатами оказалось невозможно, поэтому пилот пришлось свернуть. Кроме того, технология оказалась дорогой во внедрении: на каждую точку порционирования требовалось отдельное рабочее место, где повар отмечал бы, что именно он кладет в метку.
Переход к компьютерному зрению
Мы начали искать другое решение и решили попробовать распознавание на нейросетях и машинное зрение. Вначале сомневались, что такой подход обеспечит нужную стабильность распознавания для потокового обслуживания.
Использование нейросетей и машинного зрения началось с идеи сделать систему помощником кассира. Из дополнительного оборудования требовалась только камера, установленная сверху над раздачей, в дополнение к POS-терминалу, на котором работает кассир. Система должна была помогать формировать чек.
Для этого мы разработали нейросети и технологию распознавания, добились первых результатов и сделали систему работоспособной. Однако оказалось, что бизнесу в таком виде решение неинтересно: платить за него не готовы, потому что ускорение незначительное, а местами система даже мешает. Опытный кассир набирает чек быстрее, чем тратит время на корректировки. После этого мы решили разработать собственный полноценный терминал – аппаратно-программный комплекс, а не только программную часть.
Разработка собственного терминала
Помимо программных и архитектурных задач нам пришлось решить множество дополнительных вопросов.
Разработать новое оборудование в изначально софтовой компании оказалось непросто. У нас много тиражных решений, отлаженные годами процессы разработки, тестирования и доставки релизов, но с оборудованием мы столкнулись впервые.
Пришлось самостоятельно собрать прототип такого устройства. Мы закупили комплектующие, собрали конструкцию из элементов для систем шкафов и мебели в офисе.
Для тестирования закупили муляжи блюд – вначале приносили еду из столовой, но это оказалось неудобно: блюда быстро портились и стоили денег. Муляжи, как в кафе на витринах, позволили проводить тесты полноценно.
После этого мы начали искать заказчика для пилотного проекта. Желающих установить готовую технологию было много, но тех, кто готов был пройти весь путь внедрения и доработки вместе с нами, оказалось немного. Одного из ключевых заказчиков нам удалось убедить, и мы вместе с ним начали пилот. И с этим проектом мы выиграли «1С:Проект года-24».
Юридические и организационные аспекты
Казалось бы, нет ничего сложного в том, чтобы заключить договор, но на практике все оказалось не так просто. Нужно было оформить отношения с контрактным сборщиком, чтобы выстроить их в правильные юридические рамки, а также согласовать условия с заказчиком пилотного проекта на разработку и внедрение. Это сильно отличалось от стандартных лицензионных договоров и типовых франчайзинговых услуг, поэтому пришлось тщательно продумать, как все правильно оформить.
Архитектурные и технические решения
На раннем этапе мы использовали распространенные сверточные модели нейросетей, которые оказались очень требовательными к ресурсам. Мы даже рассматривали вариант архитектуры терминала с полноценной видеокартой, что требовало дополнительного места, системы охлаждения и существенно повышало стоимость. Поскольку мы изначально планировали тиражировать решение на рынок, нужно было сделать предложение доступным по цене.
Мы начали модифицировать стандартные модели, вырезая из них отдельные блоки, но вскоре поняли, что это не приведет к успеху, и перешли к исследованию альтернативных архитектур. В результате получили значительный прирост производительности. Нам удалось обойтись без видеокарты, а вместо двух машин – одной на Windows и второй на Linux – мы оставили только одну, работающую под Windows.
Локальная работа и UX
Также изначально мы планировали, чтобы распознавание выполнялось локально. Это было принципиально важно. Обращение к облаку с мощным сервером, с одной стороны, дает преимущества, но с другой – требует постоянного стабильного интернета.
Многие наши заказчики – это удаленные объекты недропользования и ведомственные учреждения, где интернет может отсутствовать или быть строго ограничен. Отправлять туда фотографии с раздачи, не зная, что именно попадет в кадр, невозможно. Поэтому мы добились того, чтобы система полностью работала локально.
Кроме того, выбор альтернативных нейросетей и снижение требований к аппаратным ресурсам сделали систему значительно более отзывчивой. Для гостя, стоящего у терминала, любая задержка воспринимается как «тормознутость», поэтому нам было важно обеспечить максимально комфортный пользовательский опыт.
Многомодульная архитектура распознавания
Еще один важный архитектурный момент – обойтись одной моделью нейросети для всех задач сразу у нас не получилось. Мы и не ставили такой цели, главное было, чтобы система стабильно работала.
В итоге, чтобы выполнить все функциональные требования и обеспечить нужную скорость, мы используем несколько нейросетей, каждая из которых отвечает за свою задачу и работает в определенный момент времени. Общая связка реализована на Python.
Отдельные нейросети используются для обнаружения подноса в кадре, основного распознавания на обученной модели, дообучения системы в онлайн-режиме и распознавания динамических данных, а также для распознавания QR-кодов.
Автоматическое обнаружение подноса
Обнаружение подноса в кадре стало одной из дополнительных задач, возникших в процессе разработки. Постоянно нагружать систему распознаванием видеопотока с высоким разрешением оказалось неэффективно – это сильно расходовало ресурсы.
Мы рассматривали вариант, при котором гость сам нажимает на экран, чтобы запустить распознавание. Даже сделали интерфейс с надписью большими буквами: «Нажмите на экран для старта распознавания». Но на практике это не дало хорошего результата – гости, особенно впервые, долго смотрели на экран и не понимали, что делать. Кроме того, если система позиционируется как полностью автоматическая и ускоряющая обслуживание, ее запуск по нажатию на экран выглядел нелогично.
В итоге мы реализовали автоматическое обнаружение подноса в кадре. При этом возникла еще одна особенность, связанная с компоновкой терминала: во время касания экрана рука гостя оказывается между камерой и подносом, частично закрывая обзор. После серии экспериментов мы решили использовать отдельную, более дешевую камеру с низким разрешением и выделенную нейросеть специально для задачи обнаружения подноса.
Борьба с помехами в кадре
Теперь подробнее про руки в поле зрения камеры. Нам важно, чтобы процесс распознавания не начинался, пока в зоне подноса остается рука или руки. Иногда в кадр попадают и другие части тела – некоторые любопытные гости наклоняются, чтобы посмотреть, как работает система, и тогда вместо блюд камера видит лица.
Любые посторонние объекты могут закрыть блюдо или его часть, что делает распознавание невозможным или неточным. Такое происходит как случайно – когда гость ставит поднос и поправляет что-то на нем, – так и намеренно, например, когда кто-то решает проверить, можно ли «обмануть» систему. Почти всегда первый вопрос, который нам задают при демонстрации: «А если я котлету рукой прикрою – система ее найдет?» Конечно, нет – ведь анализируется изображение.
Поэтому мы предусмотрели механизм, который не запускает распознавание, пока не достигнуты благоприятные условия. А рука над котлетой – это очевидно неблагоприятное условие.
Исключение посторонних предметов
Есть еще одна интересная подзадача. На поднос в столовой часто кладут посторонние предметы, которые не должны попадать в чек: кошельки, телефоны, документы, банковские карты, ключи. Чтобы система не пыталась их распознавать, мы обучили ее на специальные «минус-классы» – нейросеть игнорирует эти объекты.
С банковскими картами возникла отдельная история. Мы заметили, что лучше заранее установить табличку в начале раздачи с предупреждением: «Внимание! Не кладите банковские карты – ведется съемка подносов». Люди часто оставляют карту номером вверх, а потом, увидев запись, начинают спрашивать, куда ушел номер их карты. Поэтому такую табличку мы считаем обязательной.
Распознавание QR-кодов и порционирование соусов
Следующая подзадача потребовала разработки отдельного блока и нейросети – считывания и распознавания QR-кодов камерой, которая изначально для этого не предназначена, в отличие от специализированных сканеров.
Зачем это понадобилось? Терминалы оснащены стандартным 2D-сканером (на фото я его обвел) – он нужен для продажи товаров, подпадающих под систему «Честный знак». Например, молочную продукцию нужно дополнительно сканировать перед продажей.
Однако в нашем пилоте возникла особенность – раздача соусов. В столовой стояли общие емкости с майонезом, горчицей, кетчупом и другими соусами, из которых гости накладывали себе порцию ложкой. Для системы распознавания это стало проблемой: сметана могла утонуть в супе, переставала быть видимой и не попадала в чек, или могла растечься по горячему блюду, меняя его цвет и фактуру, и нейросеть переставала понимать, что перед ней.
После нескольких встреч с заказчиком мы договорились немного изменить бизнес-процесс: начали фасовать соусы в небольшие пластиковые контейнеры. Мы добавили из BackOffice возможность печати QR-кодов, которые система распознает как конкретную позицию. Кроме того, на этикетку стали выводить дату фасовки.
В итоге процесс стал чище и гигиеничнее, а гости получили дополнительное удобство – теперь можно проверить дату фасовки и срок годности соуса прямо на упаковке.
Сложности стандартизации и человеческого фактора
Иногда блюда на тарелке расположены так, что частично или полностью закрывают друг друга. Обычно это происходит на раздаче, когда повар порционирует и выкладывает еду. Здесь мы подходим к теме стандартизации обслуживания и дисциплины персонала – важному условию корректной работы системы.
Это отдельный большой вопрос, не столько технический, сколько организационный. У нас есть подробный документ со сводом правил и требований, который мы обсуждаем с заказчиком до начала внедрения и регулярно используем потом – при разборе случаев, когда система что-то не распознала.
На предприятиях, особенно удаленных, со сложной логистикой и сменными поварами, поддерживать единый внешний вид блюд непросто. Некоторые заказчики ожидали, что систему можно просто установить – и она «сама догадается». На деле без соблюдения стандартов этого не происходит.
Поэтому ключевое значение имеет качественная коммуникация с командой заказчика и готовность вносить изменения в процессы и стандарты обслуживания. Технологии работают эффективно только при соблюдении правил выкладки и оформления блюд. На практике же у персонала это получалось не всегда, и порой возникали конфликты с производственными сотрудниками.
Динамическое дообучение нейросети
После очередного конфликта с поварами, которые утверждали, что не могут соблюдать требуемый внешний вид блюд – потому что привезли не те продукты, меню внезапно изменили, ингредиенты закончились или что-то подморозилось и пришлось заменить, – мы разработали и внедрили систему динамического дообучения блюд.
Теперь перед началом раздачи можно показать системе новый вид блюда на примере двух-трех чеков, вручную выбрав соответствующее название из меню и указав: «Да, это именно это блюдо, просто сейчас оно выглядит иначе». Система научилась динамически дообучаться и после этого продолжала корректно распознавать обновленное меню.
После добавления этой функции мы смогли запускать объекты буквально «с нуля» – без предварительного сбора датасета и разметки. Достаточно приехать, установить систему, показать несколько чеков – и она уже готова к работе. По сути, это позволило сократить время запуска технологии до одного дня.
Проблемы фрода и корректировки чеков
Бывают и более неприятные ситуации, когда гость осознанно закрывает одно блюдо другим – обычно более дорогое прикрывает чем-то подешевле. Например, стейк – хлебом. После этого он может сказать: «Я оплатил все, что система распознала, какие вопросы?»
Иногда гости при корректировке чека удаляют верно распознанные позиции или заменяют более дорогие блюда на дешевые.
Мы действительно даем пользователю возможность откорректировать чек перед оплатой. Поэтому на этапе внедрения обсуждаем с заказчиками, что некоторый процент фрода неизбежен – как и при использовании касс самообслуживания в розничной торговле. Всегда найдется тот, кто «утащит что-то в карман». Главное, чтобы общий результат оставался положительным.
Со своей стороны мы обеспечиваем технические меры: сбор и анализ статистики подобных инцидентов, их отображение в интерфейсе заказчика, а также общую систему управления, в которой могут работать и наша команда, и сотрудники клиента.
Централизованная система управления (СУМЗ)
Здесь мы подходим к одной из важнейших частей нашей системы – общей центральной управляющей части, которую мы разработали на 1С:Предприятии на нашей собственной технологии. Назвали ее СУМЗ – система управления машинным зрением.
Она размещается на наших серверах и находится в постоянной связи со всеми терминалами, входящими в систему машинного зрения. СУМЗ собирает всю статистику и позволяет централизованно управлять процессом. На схеме показаны основные компоненты системы и взаимосвязи между ними.
Функциональные модули СУМЗ
Опишу основные задачи этой части системы и кратко покажу, как СУМЗ выглядит отдельно по блокам. Сильно перегружать изображениями из 1С не буду, покажу только основное и самое интересное. Итак, что мы реализовали в СУМЗ на 1С:
Есть отдельный АРМ для управления данными на терминалах и составом датасета. В нем можно анализировать состав изображений блюд в датасете, регулировать их использование, формировать датасеты, отправлять их на обучение и получать результаты обучения.
Инструмент для автоматизации процесса разметки датасета. Полностью от ручной разметки мы пока не отказались, но с помощью СУМЗ сделали этот процесс максимально удобным и менее трудоемким для человека. Раньше, до переноса функционала в СУМЗ, мы использовали внешние инструменты (например, LabelMe).
Также реализован отдельный блок для просмотра всех чеков продаж и логов действий пользователей – важный инструмент, позволяющий видеть, когда и кто удалял или изменял позиции в чеке. Это помогает при разборе инцидентов и позволяет объективно предъявлять претензии гостям при необходимости.
В системе есть отчет по использованию терминалов: видно, какие терминалы, в какие даты и время работали или простаивали. Это помогает задавать обоснованные вопросы сотрудникам на раздаче – почему не используют терминал и не проводят через него гостей.
Из каждой строки чека можно перейти в режим подробного анализа блюда, чтобы понять, почему оно было распознано именно так. Система показывает, на какие предыдущие изображения она ориентировалась и почему выбрала тот или иной вариант. Здесь также видно, как сработала основная обученная модель и онлайновая модель, и какой результат в итоге был принят системой.
Отчетность и мониторинг
Отдельным важным блоком в СУМЗ являются отчеты по статистике распознавания и возможность их рассылки. В них можно увидеть за любой выбранный период, какая выручка прошла через терминалы самообслуживания, сколько было чеков, сколько блюд распознано, сколько из них распознано верно и каков процент точности. Также отображается, сколько блюд находится в обученной нейросети, что позволяет отслеживать динамику внедрения системы самообслуживания в общий процесс.
В системе реализованы уровни доступа. В СУМЗ находятся все наши проекты и заказчики, но каждый из них видит только свои терминалы, статистику по ним, использует изображения своих блюд и управляет только собственным оборудованием.
Прозрачность и объяснение решений
Также важный блок – анализ и поиск причин некачественного распознавания.
После его добавления система стала гораздо более прозрачной и научилась «оправдываться» перед пользователем в случае неверного распознавания. Раньше на вопрос, почему система решила, что это именно то блюдо, ответить было нечего. Перечень и критерии факторов, по которым сверточные нейросети определяют принадлежность изображения к тому или иному классу, человеку сложно интерпретировать, поэтому объяснить результат было сложно.
Теперь с помощью отчета система сама показывает, на основании каких признаков и сходства с какими предыдущими изображениями она сделала выбор. Обычно, когда пользователи видят эти данные, они соглашаются с результатом и переходят к корректировке датасета, потому что становится очевидно: либо ранее была ошибка при разметке, либо блюдо изменилось настолько, что стало похоже на другое, которое система и определила.
Все изменения датасетов и управляющие воздействия также можно выполнять через СУМЗ. Таким образом, формируется система замкнутого цикла.
Тепловая карта распознавания
Далее – тепловая карта системы распознавания. С ее помощью можно в режиме онлайн наблюдать, как система работает на каждом терминале и с каким качеством распознаются блюда.
На карте слева отображается список блюд, сверху – терминалы и даты. Зеленый цвет означает, что все хорошо: распознавание стабильное и качественное. Желтый и особенно красный сигнализируют о проблемах – в таких случаях нужно разбираться, почему система дает сбои. Возможно, блюдо сегодня выглядит иначе, чем обычно, или произошли другие отклонения. В таких ситуациях требуется подключиться и внести корректировки.
Проблемы аппаратной реализации
И все же, несмотря на все сложности с архитектурной и программной частью, больше всего трудностей и коллизий у нас возникло именно с аппаратной частью – с самой железкой. Я уже говорил, что спроектировать и создать устройство внутри софтовой компании оказалось непросто. Этот процесс был долгим, сложным и полным неожиданных проблем.
С первыми двумя тестовыми терминалами постоянно что-то происходило: они перегревались, почти плавились, давали неравномерную подсветку из-за особенностей освещения, камера провисала и отваливалась. Когда устройства доставляли в районы Крайнего Севера, где проходили первые пилоты, они нередко разбивались при транспортировке.
На одном из прототипов, где для охлаждения камеры с мощными серво-приводами оставили вентиляционное отверстие, в него забивалась мошкара – а на севере ее особенно много. В итоге нейросети действительно буквально приходилось отличать мух от котлет, как в поговорке.
Текущие результаты внедрения
Тем не менее, все удалось довести до рабочего состояния. Сейчас у нас четыре работающих терминала у двух заказчиков. Среднее время распознавания и обслуживания одного гостя – не более 20 секунд.
Надо отметить, что система в итоге распознает блюда лучше человека. Мы неоднократно убеждались в этом на сравнительных тестах: сажали несколько человек, давали им названия блюд и картинки, а затем показывали новые варианты. Почти всегда люди справлялись хуже, а система по своим внутренним критериям выбирала более точный вариант. В этом отношении она действительно оказалась совершеннее нас.
Из важных результатов – мы научились динамически обучать нейросети буквально за 3–4 чека и запускать новые объекты на технологии за один-два дня. Вся следующая серия терминалов, которая сейчас находится в производстве, уже распродана заранее.
25:55 (в презентации видео нет) На видео показано, как система работает на реальном объекте – в столовой нефтегазовой отрасли на севере. Гость набирает блюда на поднос, ставит его на терминал, система распознает, предлагает откорректировать или подтвердить, выбирается тип оплаты, и происходит оплата. Обычно используется корпоративная карта питания, но можно оплатить и банковской. Все обслуживание занимает не более 20 секунд на человека.
Планы на будущее
В планах самое главное – масштабировать технологию на новые объекты и проекты.
У нас много идей для дальнейшего развития как в части функциональности, так и в применении новейших достижений нейросетевых технологий. Планируется и развитие интерфейсов – как СУМЗ, так и самого терминала.
Отдельно стоит отметить, что мы уже научились хорошо обобщать данные. Если раньше при запуске нового пилота систему приходилось обучать заново – с полноценной разметкой всех блюд, – то теперь практически любой проект можно стартовать «из коробки»: достаточно показать системе несколько блюд в режиме динамического обучения. Тем не менее, в области обобщения данных остаются направления для улучшений.
Мы также развиваем технологию централизованного онлайн-обучения. Например, если на объекте есть общая столовая с пятью терминалами, то обучение можно проводить только на одном – не нужно обходить все терминалы в начале смены. Обновления распространяются автоматически, хотя процесс не проходит через общий сервер. Эта технология по принципу похожа на РИБ в 1С, и мы активно ее совершенствуем.
Кроме того, у заказчиков появляются новые идеи, как использовать собранную статистику не только для формирования чеков, но и для оценки качества работы производственного персонала и эффективности управления объектами.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT.
Вступайте в нашу телеграмм-группу Инфостарт