Расквартированная клубника и другие особенности машинного перевода: чтобы сделать еще один шаг в сторону автоматизированных кухонь, нужно научить технику понимать рецепты, написанные человеческим языком и в человеческой логике. Для этого их нужно трансформировать. Под катом текст-размышление над проблемой, который родился за чашкой с кофе в ходе обсуждения смежной темы.
Автоматизированные кухни. Необходимые этапы
Умные кухонные приборы облегчают процесс готовки, но человек все же делает большую часть работы: моет, режет и помещает в них продукты, перемешивает и т.д. А как хотелось бы просто сказать: «Горшочек, вари», и чтобы оно все само помылось, нарезалось, перемешалось, а пользователю осталось только дождаться звукового сигнала и идти трапезничать.
Сейчас автоматические кухни только появляются в промышленных масштабах, но до бытового уровня это дойдёт ещё очень нескоро. Для этого нужно решить несколько групп задач, и решения эти должны быть доступными.
Первая группа задач — дать кухне возможность действовать автономно от пользователя.
Эта задача, например, может решаться внедрением в кухню системы манипуляторов, конвейера;
Вторая группа задач — внедрить в кухню компьютерное зрение и систему датчиков для автоматического определения степени готовности блюда или его части.
Третья группа задач — интерфейс управления. Задача может быть реализована посредством приложения на смартфонах, а также голосовых помощников.
И, наконец, четвертая группа — задание кухне логики поведения. Как научить кухню готовить? Например, робота-повара обучает человек — профессиональный повар. Надев на руки датчики, он медленно показывает, как надо. Машина затем воспроизводит его действия, до мелочей, вплоть до подрагивания рук. Конечно, при обработке лишние движения должны быть убраны, но если программист что-то упустит, то робот-повар однажды остановится, чтобы почесать свой несуществующий нос.
К тому же, для того чтобы научить робота одному рецепту, движения нужно повторять несколько раз. Даже если научить робота отдельным движениям, которые он сможет потом комбинировать, то времени на такое обучение уйдет предельно много. Не говоря уже о строжайшем соответствии рецепту и, видимо, калиброванных ингредиентах: дать возможность роботу выковыривать глазки из картофелин — отдельная сложная инженерная задача. А еще после готовки все равно придется мыть плиту и посуду.
Рецепт — это код
Если вернуться к положению дел сейчас — т.е. учесть экономическую составляющую вопроса, трудности разработки, etc., становится понятно, что в обозримом будущем мы можем только научить умную бытовую технику читать рецепт и применять его. Для этого требуется преобразовать рецепт в код. Но классический программный Java или C здесь вряд ли подойдет — им можно описать рецепт, но если пользователь захочет внести в него какие-либо изменения, то ему придется или связываться с техподдержкой, или записываться на курсы программирования. К тому же, классический код слишком формальный. Например, если в ингредиентах написано «сушенные грибы», значит свежие в готовку не пойдут. Дополнительно усложняет задачу тот факт, что рецепты национальных кухонь представлены на разных естественных языках.
А хотелось бы дать возможность пользователю найти в Сети интересный ему рецепт, загрузить его, а робокухне — правильно интерпретировать его и применить. Задача-максимум — это возможность кухни самостоятельно, основываясь на кулинарных предпочтениях пользователя, искать и предлагать варианты. По-хорошему рецепты приготовления пищи должны не только включать в себя список сырых ингредиентов и способы приготовления пищи, но также и условия окружающей среды, в которой растут продукты. Блюдо относится к национальной кухне по многим критериям, в том числе специфическим способам готовки, применяемой посуде, инструментам и т.д. Трансформация всех этих данных в надлежащую цифровую форму или, скорее всего, ее интерпретация будет сложной задачей.
Итак, какие языки могут подходить для составления рецептов?
RDF
Существующие технологии формализованного представления знаний попадают в несколько групп структур.
К ним относятся подход Semantic Web с его технологиями OWL и RDF. Онлайн-коллекции взаимосвязанных наборов данных с использованием инструментов Semantic Web также известны как Linked Data. Недавно на Хабре появилась статья, посвященная этой концепции, потому не будем на ней заострять внимание. Многие проекты оцифровки построены вокруг идеи использования некоторой высшей онтологии, которая может быть расширена онтоинженерами в конкретной области знаний.
Рассмотрим случай использования и применения этих инструментов для оцифровки национальных кухонь. Основной идеей RDF является то, что Интернет отходит от хранения информации, воспринимаемой только человеком, становясь всемирной сетью взаимодействующих процессов. Как следует из названия, RDF является основой для выражения информации о ресурсах. В первую очередь — о веб-документах и различных организациях. Его формализм основан на идее статических классов и свойств. Возникает вопрос: насколько разумно рассматривать рецепт как сущность, а не как сложный процесс с аргументами, расчетом времени, входящими подпроцессами и т. д. Для рецепта этого будет явно недостаточно.
Schema.org
Вторым подходом можно считать инициативу Schema.org — совместная деятельность интернет-сообщества по созданию, поддержанию и продвижению схем для структурирования данных в Интернете. Эта инициатива направлена на предоставление стандартизированного словаря для общих метаданных опубликованных на веб-ресурсах. Веб-ресурсы, связанные с приготовлением пищи, могут использовать метаданные полей класса «Recipe», которые хранятся по ссылке. Ниже пример кода рецепта, предоставленного Google:
Словарь и формат, принятый Schema.org, в первую очередь ориентированы на представление метаданных высокого уровня в веб-документах. Однако правильно нормализованный семантический граф требует гораздо более явного представления понятий. Большинство строковых значений в полях Schema.org — это естественные тексты, требующие человеческой когнитивной интерпретации. Такой текст не может быть напрямую прочитан цифровыми системами без специальных инструментов обработки естественного языка, которые довольно часто подвержены ошибкам. В качестве иллюстрации подойдет машинный перевод Google к одному элементу строки из списка ингредиентов вышеприведенного примера рецепта:
‘fresh strawberries, quartered’
Перевод на русский язык дает совершенно неправильное смысловое значение:
'Свежая клубника, расквартированная'
с «quartered», используемым в смысле «жилья», как в «Наши войска были расквартированы в Бостоне», а не «Разрезанная на четыре части».
Отсутствие четко определенных ролей объектов и явной идентификации методов делает задачу машинного перевода рецепта намного сложнее.
Для нашей футуристической задачи для цифровых рецептов — сценария, в котором роботизированная машина могла бы следовать инструкции по приготовлению блюда, простая строка текста не может быть решением.
Рассмотрим типичное описание ингредиента:
‘8 Granny Smith apples — peeled, cored and sliced’
Совершенно очевидно, что эта текстовая строка содержит много классифицирующей информации: сырьевой ингредиент как класс, конкретный сорт яблок, количество в кусках, список методов, которые должны применяться к каждой части, чтобы нормально использовать ингредиент: удаление семечек, кожуры, разрезание объекта на части определенной формы.
Формализм Schema.org недостаточно выразителен для того, чтобы записать процесс приготовления в некий программный код. Чтобы правильно оцифровать рецепты для роботизированной кулинарии, нам нужно отделить описание ингредиента от логики
Третий подход — когнитивное моделирование рецепта
Традиционный способ составления рецепта – начать с компонентов и операций, которые необходимо выполнить. Этот порядок и стиль описания известны как императивный или процедурный. Декларативный или функциональный стиль описания логики процесса обычно начинается от вершины пирамиды исполнения, ожидаемого полезного результата, которого мы хотим достичь.
Рассмотрим следующее упрощенное представление классического русского рецепта грибного супа. Стрелки обозначают подпроцессы (иногда альтернативные), необходимые для родительского процесса.
Когнитивная интерпретация может поставить в тупик еще на моменте, когда мы попытаемся дать определение рецепта. Термин «рецепт» имеет несколько контекстуальных значений. Он может быть определен в общем смысле как способ получения желаемого результата. При употреблении в контексте приготовления пищи он обозначает набор инструкций по приготовлению кулинарного блюда. Таким образом, это понятие можно рассматривать как объект с определенными свойствами, такими как необходимые ингредиенты и время. В качестве альтернативы его можно рассматривать как технологический процесс, который имеет какие-то начальные данные, проходит серии этапов, которые должны быть выполнены, и приводит к определенным результатам. Рецепт также включает в себя время, которое необходимо затратить на выполнение шагов, и описание необходимой посуды.
С 2006 года в целях разработки оптимального формализма для выражения сложной семантики естественного языка был создан проект Knowdy, ориентированный на управление данными графов.
Проект Knowdy
Knowdy — это программный проект с открытым исходным кодом научно-исследовательской группы лингвистов в Санкт-Петербурге, занимающейся разработкой сверхбыстрой базы данных графов, которая позволяет прямо и эффективно работать с концептуальными графами, в обход любых промежуточных представлений, таких как таблицы SQL. Движок базы данных реализован на C и может использоваться как в качестве сетевой службы, так и в качестве автономной библиотеки для встроенной среды.
После нескольких лет исследований и разработок команда исследователей-разработчиков придумала специальный формат данных для Knowdy DB, называемый GSL (акроним General Semantics Language). GSL оптимизирован для компактного хранения концептуальных графов. Он используется для хранения данных, передачи сообщений и обмена информацией. Этот формат не чрезмерно многословный, как XML, и немного более компактный, чем JSON. Язык принимает некоторые особенности S-выражений Lisp, но с большой модификацией семантики, поскольку нужно иметь в виду, что графики — не списки. Скобочное описание в GSL имеет особое значение, позволяющее пользователям выражать не только многоуровневые группировки, но также операции CRUD внутри системы хранения базы данных.
В описании GSL процесс кодируется как функция первого класса, которая может быть названа или может быть анонимной, поддерживает наследование от базовой функции, имеет аргументы и подпроцессы, которые могут работать параллельно. Процессы ниже описывают некоторую логику все того же рецепта русского грибного супа.
{!proc prepare mushroom soup mix
[_gloss {ru подготовка заправки
грибного супа}]
Unknown macro: {is cooking by boiling}
(arg cut-mushrooms
{run prepare mushroom mix})
(arg cut-potatoes
{run prepare potato mix})
(arg cut-onions
{run prepare onion mix})
{run _put
[_gloss {ru Все ингредиенты выложить
в контейнер и перемешать.}]
{obj _all}
{into_loc container}}}
(proc prepare mushroom mix
[_gloss {ru подготовка
грибной заправки}]
(arg clean-mushrooms
{run clean mushrooms})
{run _cut
[_gloss {ru Нарезать грибы
мелкими кубиками.}]
{obj clean-mushrooms}
{form slice {size 1.5 {unit cm}}}})
В R4S используется третий подход. Он позволяет представить рецепт с нужной степенью формализма, описать как сущность, так и действие. Рецепт, записанный таким образом в базу данных, может быть быстро загружен и применен техникой. В приборах нашей разработки, где поддерживаются рецепты, они записываются в формате GSL. В планах — обучить нейросеть для записи рецептов народов мира, что упростит обмен рецептами и даст технологический задел для полноценных автоматизированных кухонь.
Мы часто сталкиваемся с, казалось бы, тривиальными задачами, воплощение которых не так-то просто. Какой, по вашему мнению, язык может быть использован для записи рецептов, с одной стороны доступных пользователям со всего мира, с другой — понимаемый и интерпретируемый машинами?
Автор: ready_for_sky_team