От Мяоцзин и Бобен

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

На базе алгоритма с открытым исходным кодом Pipcook мы запускаем imgcook — платформу для автоматической генерации кода из проектных документов (Sketch, Photoshop и т. д.).

Pipcook — это JavaScript-фреймворк, основанный на tfjs-node. Мы можем создавать конвейеры машинного обучения в Pipcook, а tfjs-node предоставляет алгоритмы и возможности обучения.

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

Фоновый анализ

Машинное обучение становится трендом в отрасли, и ИИ стал консенсусом в отношении будущего. Кай-Фу Ли также указал в «Будущем ИИ», что искусственный интеллект заменит почти 50% человеческой работы в течение 15 лет, особенно простые и повторяющиеся задачи. Более того, работу «белых воротничков» станет легче заменить, чем работу «синих воротничков», поскольку работа «синих воротничков» может потребовать прорывов в робототехнике и связанных с ней технологиях как в программном, так и в аппаратном обеспечении. Однако только технологические прорывы в программном обеспечении могут заменить белых воротничков. Будет ли заменена работа наших внешних «белых воротничков»? Когда и сколько будет заменено?

Оглядываясь назад на 2010 год, программное обеспечение затронуло почти все отрасли, что в последние годы привело к процветанию всей индустрии программного обеспечения. Но в 2019 году ИИ затронул саму индустрию программного обеспечения. Например, в поле DBA функция Question-to-SQL может автоматически генерировать операторы SQL, когда вы задаете вопросы в поле. Между тем, TabNine, инструмент анализа исходного кода на основе машинного обучения, помогает в генерации кода. Более того, в дизайнерской индустрии запущен интеллигентный конструктор «Любань». Что с фронтенд-разработкой?

Мы должны упомянуть знакомый вопрос: как автоматически генерировать код из проектного документа (Design2Code, называемый D2C). Комитет по внешнему интерфейсу Alibaba фокусируется на направлении разведки, и текущий этап заключается в повышении эффективности веб-разработки. Мы постараемся положить конец простой и повторяющейся работе, позволяя веб-разработчикам сосредоточиться на более сложной работе.

Анализ конкурентной продукции

В 2017 году внимание отрасли привлекла статья Pix2Code об преобразовании изображения в код. В нем описывается создание исходного кода непосредственно из изображения дизайна с помощью глубокого обучения. Впоследствии подобные идеи, основанные на этой идее, регулярно возникали в сообществе. Например, в 2018 году Microsoft AI Lab запустила Sketch2Code — инструмент с открытым исходным кодом для преобразования эскиза в код. В конце того же года Yotako привлекла внимание людей как платформа для перевода эскизов дизайна в код. Таким образом, машинное обучение официально привлекает разработчиков внешнего интерфейса.

Основываясь на анализе конкурирующих продуктов, мы можем получить следующие вдохновения:

1) В настоящее время возможность обнаружения объектов глубокого обучения в изображениях подходит для многократно используемой идентификации материала (идентификация модуля, идентификация базового компонента и идентификация бизнес-компонента) с большей степенью детализации.

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

3) Когда модель не может обеспечить ожидаемую точность, можно использовать жесткое правило проектной документации. С одной стороны, возможность ручного вмешательства может помочь пользователям получить желаемые результаты. С другой стороны, эти протоколы ручных правил также являются образцами высокого качества, которые можно использовать в качестве обучающих образцов для оптимизации точности распознавания модели.

Разрешение проблемы

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

Общая рабочая нагрузка веб-разработки в основном сосредоточена на просмотре кода, логическом коде и интеграции внешнего и внутреннего интерфейса. Далее мы разбиваем цели и анализируем их одну за другой.

Посмотреть код

При разработке кода представления код HTML и CSS обычно пишется на основе проектного документа. Как здесь повысить эффективность? Столкнувшись с повторяющейся работой по разработке представления пользовательского интерфейса, естественно подумать о таких решениях, как упаковка и повторное использование материалов, таких как компоненты и модули. На основе этого раствора осаждали различные библиотеки УИ. Существуют инкапсуляции даже более высокого уровня, которые являются платформами для визуального создания веб-сайтов. Однако повторно используемые материалы не могут охватывать все сценарии. Существует множество бизнес-сценариев, нуждающихся в персонализированных представлениях. Столкнувшись с самой проблемой, возможно ли напрямую генерировать надежный код HTML и CSS?

Подводя итог, мы сталкиваемся со следующими проблемами:

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

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

Однако, когда трудно использовать правила для решения некоторых проблем, мы можем использовать модели для решения проблем. Например, мы сталкиваемся с некоторыми случаями, когда нам нужно распознавать группы и циклы. Тем временем веб-разработчики часто используют существующие библиотеки пользовательского интерфейса для создания интерфейса пользовательского интерфейса, поэтому важно распознавать базовые компоненты в проектной документации. Для решения этих проблем мы используем Pipcook для создания конвейера обнаружения объектов для обучения наших моделей и достижения целей. Кроме того, требуется контекстно-семантическое распознавание элементов. Это также ключевая проблема, решаемая методом глубокого обучения. Например, если мы хотим распознать, что означает изображение в дизайн-проекте или почему в некоторых местах использовался какой-то корпус текстов, нам нужны модели классификации изображений и классификации текста, которые также строятся из Pipcook на основе tfjs-node.

Логический код

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

  • Привязка полей данных: это вполне осуществимо. Вы можете определить поле-кандидат на основе текста или изображения проектного документа. Но соотношение цены и качества невысокое, потому что это больше касается бизнес-логики, а не общей логики.
  • Динамический эффект. Входные данные этой части — проектный документ. Как правило, формы реализации динамического воздействия разнообразны. Некоторые из них представляют собой анимированные GIF-демонстрации, а некоторые представляют собой текстовое описание или даже устное. Генерация динамического кода больше подходит для визуальной генерации. Нет ссылки на прямую, интеллектуальную генерацию, учитывая, что соотношение вход-выход не является краткосрочной проблемой.
  • Бизнес-логика: эта часть разработки в основном основана на PRD и даже на логике менеджера по продукту. Если вы хотите сгенерировать эту часть логического кода разумно, входных данных слишком много. В частности, нам нужно посмотреть, какие проблемы может решить интеллектуализация в этой области.

Генерация логического кода

Идеальный план состоит в том, чтобы изучать исторические данные, как и другие области искусства, такие как поэзия, живопись и музыка. В соответствии с вводом PRD новый логический код может быть сгенерирован напрямую. Но может ли сгенерированный код работать напрямую без ошибок?

В настоящее время, хотя ИИ развивается быстрыми темпами, проблемы, которые он может решить, все еще ограничены. Необходимо определить проблемы как типы проблем, которые он решает хорошо. Обучение с подкреплением хорошо подходит для оптимизации стратегии, а глубокое обучение лучше подходит для компьютерного зрения, классификации и обнаружения объектов.

Для кода бизнес-логики первое, что приходит на ум, — это использовать LSTM (сеть с долговременной кратковременной памятью), которая с точки зрения NLP заключается в получении семантики функциональных блоков. Интеллектуальное напоминание о коде VS Code и TabNine используют эту стратегию.

Кроме того, мы обнаружили, что интеллект также может помочь определить местоположение (время) логических точек в представлении и угадать логическую семантику на основе представления.

Резюмируем преимущества интеллекта на данном этапе:

  • Анализ и угадывание семантики высокочастотных функциональных блоков (логических блоков) на основе исторического исходного кода. Таким образом, мы можем рекомендовать блоки кода при редактировании кода.
  • Мы можем догадаться о некоторых повторно используемых логических точках из проекта проекта. Например, чтобы привязать изображение или текстовые данные к просмотру, мы можем использовать классификацию НЛП или классификацию изображений для распознавания содержимого элементов.

Поэтому в текущем поколении бизнес-логики решаемые проблемы относительно ограничены. Особенно, когда появляются новые точки бизнес-логики с новой логической оркестровкой, все эти ссылки находятся в PRD или в сознании PD. Таким образом, текущие стратегии для схемы генерации бизнес-логики следующие:

  • Привязка полей. Используйте глубокое обучение для интеллектуального определения семантической классификации текста и изображений в черновике дизайна, особенно в текстовой части.
  • Многократно используемые точки бизнес-логики: интеллектуально идентифицируются на основе представлений. Он содержит небольшие логические точки (одна строка выражения или несколько строк кода, которых обычно недостаточно для инкапсуляции в компоненты), базовые компоненты и бизнес-компоненты.
  • Новая бизнес-логика, которую нельзя использовать повторно.Структурированный (визуализированный) набор требований PRD — сложная задача, и она все еще находится на стадии тестирования.

Резюме

Мы описали стратегии для интеллектуальной генерации HTML + CSS + части JS + части данных из приведенного выше анализа. Это основной процесс D2C (Design2Code). Из этой идеи мы разработали продукт imgcook. В последние годы, с развитием сторонних плагинов популярных инструментов проектирования (Sketch, PS, XD и т. д.), быстрое развитие глубокого обучения даже превосходит возможности человеческого распознавания. Это жизненно важный фон для рождения и непрерывного развития D2C.

Обнаружение объектов 2014–2019 гг.

Техническое решение

Основываясь на общем анализе упомянутой выше интеллектуальной разработки внешнего интерфейса, мы сделали обзор и архитектуру существующей интеллектуальной технологической системы D2C, которая в основном разделена на следующие три части:

  • Возможность распознавания: способность идентифицировать проектный документ. Это необходимо для интеллектуального анализа нескольких измерений информации из проектного документа, включая слои, базовые компоненты, бизнес-компоненты, макеты, семантику, поля данных и бизнес-логику. Если интеллектуальное распознавание не является точным, то для исправления ошибок используется вмешательство человека. С одной стороны, код высокой доступности создается за счет недорогого вмешательства. С другой стороны, искусственные поправки также можно использовать в качестве образцов для онлайн-обучения.
  • Возможность выражения: в основном вывод данных и доступ к инженерной части.
  • Используйте DSL для создания стандартного структурированного описания Schema2Code.
  • Выполните доступ к проекту через плагины IDE.
  • Разработка алгоритмов: для лучшей поддержки интеллектуализации, необходимой D2C, обслуживаются высокочастотные возможности, в основном включающие создание, обработку и услуги моделей данных.
  • Генерация сэмплов: в основном обрабатывайте семпловые данные каждого канала и генерируйте сэмплы.

Сводная информация об интеллектуальных возможностях интерфейса D2C

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

Уровень интеллектуальной идентификации

Во всем проекте D2C ядром является часть возможностей распознавания. Конкретное разложение этого слоя состоит в следующем. Последующая серия статей будет посвящена этим подразделенным слоям.

  • Слой идентификации материалов: для идентификации материалов на изображении посредством распознавания изображений, включая распознавание модулей, распознавание атомарных модулей, идентификацию базовых компонентов и идентификацию бизнес-компонентов.
  • Слой обработки слоев. В основном разделите слои в документе дизайна или изображении и объедините результаты распознавания предыдущего слоя, чтобы отсортировать метаинформацию слоя.
  • Слой повторной обработки: дальнейшая нормализация данных из предыдущих слоев.
  • Слой алгоритма макета: преобразование абсолютного положения в относительное положение макета и макет Flex.
  • Семантический уровень. Многомерные функции слоя используются для создания семантических выражений в сгенерированном коде.
  • Слой привязки полей: связывайте и сопоставляйте статические данные в слое с фактическими внутренними данными.
  • Уровень бизнес-логики: генерирует коды бизнес-логики посредством идентификации и выражения бизнес-логики.
  • Уровень механизма вывода. Наконец, выведите код, интеллектуально обработанный различными DSL каждого уровня.

Технологическое наслоение способности идентификации D2C

Технические трудности

Конечно, неполное распознавание и низкая точность распознавания всегда были главной темой D2C, а также нашим основным техническим моментом. Мы пытаемся проанализировать факторы, вызывающие эту проблему, с следующих точек зрения:

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

2) Отсутствие высококачественного набора данных. Возможности интеллектуального распознавания каждого слоя зависят от разных наборов данных. Сколько сценариев фронтенд-разработки могут охватывать наши образцы? Каково качество данных каждого сценария? Едины ли стандарты данных? Унифицирована ли обработка разработки признаков? Есть ли в образце неоднозначность? Как взаимосвязь? Это проблемы, с которыми мы сталкиваемся сейчас.

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

Определение проблемы

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

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

  • Шаг 1. Найдите как можно больше подходящих проектных документов. Перечислите виды изображений.
  • Шаг 2.Обоснованно суммируйте и классифицируйте типы изображений, так как это самый простой способ вызвать споры. Плохое определение и двусмысленность приведут к проблеме модели.
  • Шаг 3. Проанализируйте особенности каждого типа изображений — являются ли они типичными или нет и являются ли они основными характерными точками — поскольку они связаны со способностью последующих моделей к обобщению выводов.
  • Шаг 4. Доступен ли источник образца данных для каждого типа изображения, а если нет, то может ли он быть создан автоматически. Если выборка данных недоступна, модель не подходит. И вы можете заменить жесткие правила, чтобы увидеть эффект первым.

Таких проблем в проектах D2C много. Само определение проблемы должно быть очень точным и основанным на научных ссылках, что относительно сложно, поскольку нет прецедента для ссылок. Вы можете использовать известный опыт только для того, чтобы сначала попробовать его и исправить после того, как в пользовательских тестах возникнут проблемы. Это болевая точка, которая требует постоянной итерации и постоянного улучшения.

Образец качества

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

Мы используем стандартный формат данных Pipcook. Мы предоставляем единый инструмент оценки образцов для различных задач (классификация и обнаружение объектов) для оценки качества каждого набора данных. Для некоторых конкретных моделей может быть принята разработка признаков с лучшим эффектом (нормализация, усиление края и т. д.), и ожидается, что образцы схожих проблем также смогут распространяться и сравниваться в различных моделях в будущем, чтобы оценить точность. и эффективность различных моделей.

Модель

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

Мысли о процессе

Поскольку используется глубокая модель, более реалистичная проблема заключается в том, что модель не может идентифицировать данные, кроме признаков, изученных в обучающей выборке. И уровень точности не может быть на 100% удовлетворительным для пользователя. Помимо образцов, что мы можем сделать?

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

  • В начале мы можем достичь согласования петли вручную в конструкторском документе.
  • Основываясь на контекстной информации слоя, вы можете сделать некоторые суждения правил, чтобы определить, является ли он телом цикла.
  • Используя возможности слоя машинного обучения, вы можете попытаться оптимизировать правила.
  • Создайте несколько положительных и отрицательных образцов цикла, чтобы учиться с помощью модели глубокого обучения.

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

Бизнес-лендинг: 2019 Double 11

После почти двух лет оптимизации первая замкнутая разработка маркетингового модуля использует D2C. Это включает в себя создание модуля, генерацию кода представления, генерацию логического кода, написание дополнительного логического кода и отладку.

В сцене Double 11 он охватывает новые модули Tmall и Taobao, включая различные сценарии. Поддерживается 31 модуль. Около 79,34% кода генерируется D2C, включая автоматическое создание кода представления и некоторого логического кода. 98% простых модулей генерируются автоматически. Основными причинами ручного изменения кода являются новая бизнес-логика, анимация, ошибки распознавания привязки полей и ошибки распознавания циклов. Эти вопросы также нуждаются в постепенном улучшении.

Общая ситуация приземления

По состоянию на 09.11.2019 данные следующие:

  • Количество модулей составляет 12 681, и на этой неделе было добавлено около 540 модулей.
  • Количество пользователей составляет 4315 человек, и каждую неделю добавляется около 150 новых пользователей.
  • Количество команд: 24
  • Пользовательские DSL: 109

На данный момент доступны следующие сервисы:

Последующее планирование

  • Продолжайте снижать требования к проектным документам, в которых повышается точность интеллектуальной идентификации группировки и контура, а стоимость ручного вмешательства в проектный документ снижается.
  • Повышена точность идентификации компонентов. В настоящее время точность составляет всего 72%, а доступность бизнес-приложений низкая.
  • Возможности восстановления на уровне страницы и проекта улучшены в зависимости от точности возможностей сегментации страницы.
  • Улучшите восстановление на уровне страниц мини-приложений и программ для ПК, а также улучшите общее восстановление сложных форм, таблиц и диаграмм.
  • Улучшить возможность генерации кода из статических изображений, который можно использовать в производственной среде.
  • Продукты разработки алгоритмов совершенствуются, а каналы генерации образцов становятся более разнообразными.
  • Открытый источник.

В будущем мы надеемся, что в рамках проекта совместного создания внешнего интерфейса мы будем использовать коллективную силу, чтобы сделать решения интеллектуальных технологий внешнего интерфейса всеобъемлющими и размещать более конкурентоспособные образцы и модели, обеспечивая более высокую точность и большую доступность услуг. Мы надеемся сократить повторяющуюся и простую работу и помочь веб-разработчикам сосредоточиться на более сложной работе.

Связаться с нами

Оригинальный источник:



Интеллектуальное создание кода внешнего интерфейса из файлов дизайна: imgcook
Alibaba F(x) Team 26 февраля 2021 г. 173 Авторы: Мяоцзин и Бобен Являясь одним из четырех основных технических направлений… www.alibabacloud.com