Standaryzacja wykrywania obiektów na makietach

Wiele świetnych pomysłów powstaje na kartce papieru lub tablicy. Dlaczego? Rysowanie odręczne wciąż jest najbardziej naturalnym, intuicyjnym i efektywnym sposobem porządkowania abstrakcyjnych lub wizualnych myśli. Ludzie, mimo starań, by dostosować się do cyfrowego świata, często lepiej radzą sobie w sytuacjach analogowych.

Mając na uwadze tę obserwację, postanowiliśmy skupić się na konkretnym przypadku użycia: automatycznym generowaniu kodu gotowego do wdrożenia na podstawie odręcznie narysowanych makiet. Na tym etapie wierzymy, że cyfrowy proof of concept, który powstaje zaraz po spotkaniu z udziałowcami, nie jest już odległym marzeniem.

Jak wyjaśniliśmy w poprzednim artykule, chcemy wykorzystywać sztuczną inteligencję (AI) i uczenie maszynowe (ML) w różnych obszarach naszej platformy. Wiemy jednak, że przynajmniej na razie ML nie rozwiąże każdego problemu. Nasze API wizyjne jest częścią większego ekosystemu i odpowiada jedynie za wykrywanie ramek ograniczających. Te surowe ramki trzeba następnie przekształcić w reprezentację języka opisu interfejsu użytkownika (UIDL). Potem generatory kodu oraz niektóre zastrzeżone warstwy podejmowania decyzji mogą przejąć zadanie i wygenerować kod.

Zrzut ekranu i makieta Stackoverflow.com

Potrzeba danych#

Na papierze problem wydaje się data scientistowi bardzo prosty: mamy obrazy lub skany makiet z adnotacjami wskazującymi, gdzie znajdują się elementy takie jak obrazy, przyciski i teksty. Brzmi łatwo, więc po prostu wyszukajmy w Internecie jakieś obrazy, a później je opiszemy.

Kilka makiet znalezionych w Internecie

Na początek postanowiliśmy zebrać bezpłatne dane z Internetu. Pozwoliło nam to z grubsza zrozumieć charakter danych, z którymi mieliśmy pracować, ale uświadomiło nam też, że to źródło nie zapewni wystarczającej liczby obrazów do trenowania modelu uczenia maszynowego. Potem natknęliśmy się na kolejny problem: nikt nie stosował tych samych konwencji przy rysowaniu makiet... Co więcej, w dalszej części procesu zbierania danych dowiedzieliśmy się, że w każdej organizacji często obowiązują konkretne wytyczne.

Aby rozwiązać te pierwsze problemy, postanowiliśmy opracować własne wytyczne i sami zaczęliśmy rysować makiety. Gdy każdy członek zespołu dołożył swoją cegiełkę, postanowiliśmy zebrać dane metodą „friendsourcingu” i poprosiliśmy wszystkich naszych (wspaniałych!) znajomych, by również narysowali dla nas makiety. Zdecydowanie nie jest to strategia, którą da się skutecznie stosować na dużą skalę, bo liczba znajomych jest ograniczona, ale dzięki niej uzyskaliśmy pierwszą spójną kolekcję ręcznie rysowanych makiet.

Obowiązujące u nas wytyczne dotyczące rysowania makiet

Mieliśmy X, ale wciąż potrzebowaliśmy Y#

Najprostsza intuicja dotycząca uczenia maszynowego jest taka, że komputer sam uczy się funkcji, która na podstawie dużej liczby przykładów przewiduje Y na podstawie X. W tamtym momencie mieliśmy już kilkaset obrazów, czyli mieliśmy X. Wiedzieliśmy, że to wystarczy do sprawdzenia koncepcji, więc przeszliśmy do kolejnego kroku: dodania adnotacji, aby uzyskać Y.

Zaczęliśmy ręcznie opisywać każdą narysowaną makietę, zaznaczając położenie obrazów, przycisków i tekstów. Nie trzeba dodawać, że nie było to najprzyjemniejsze zadanie w ramach tej inicjatywy, ale nic nie przychodzi za darmo, więc zacisnęliśmy zęby i zabraliśmy się do pracy.

W naszym przypadku był to dość długi proces. Zaczęło się od kilku przypadkowych prac nad chatbotami i interfejsami konwersacyjnymi. W 2015 roku większość z nas pracowała jeszcze w dziale JavaScript w Evozon. Te prace nigdy nie trafiły do produkcji, ale wszyscy pozostaliśmy pełni entuzjazmu: otworzyły przed nami wiele nowych perspektyw dotyczących tworzenia nowych doświadczeń użytkownika. Dobra wiadomość jest taka, że pomogło to wszystkim członkom zespołu w pełni docenić prawdziwą wartość czystych i uporządkowanych danych — zasobu niezwykle rzadkiego, który stanowi wąskie gardło większości projektów z zakresu data science.

Potrzeba spójnych danych#

Gdy mieliśmy już X i Y, mogliśmy wreszcie przejść do przyjemniejszej części: trenowania modelu. Zajęło to znacznie mniej czasu niż zebranie danych, a wniosek był oczywiście taki, że potrzebujemy ich więcej!

Mimo to udało nam się stworzyć dowód słuszności koncepcji i bardzo dobrą podstawę do dalszych ulepszeń. Dokładność modelu na naszym zbiorze testowym wyniosła 55%, co oznacza, że poprawnie wykrył 55% elementów.

Oprócz niewielkiej liczby punktów danych, właśnie wtedy zdaliśmy sobie sprawę, że czeka nas nowe wyzwanie: w adnotacjach było wiele nakładających się oznaczeń. Niektóre adnotacje były niejednoznaczne nawet dla człowieka:

• Czy to obraz, czy przycisk?
• Czy to nagłówek, czy akapit?
• Czy to pole tekstowe, czy przycisk?

W niektórych przypadkach, takich jak nagłówki i akapity, o decyzji mogła pomóc główna struktura makiety. W wielu innych przypadkach nie dało się jednak rozróżnić tych elementów. A skoro tak, modelu nie można było poprawnie wytrenować.

Makieta przesłana przez użytkownika po lewej, obok makiety z naszego zbioru treningowego po prawej

Potrzeba bardziej rygorystycznych wytycznych#

Jak w przypadku wielu problemów inżynieryjnych, najtrudniej jest wypracować solidny punkt wyjścia, który można później udoskonalać. Uczenie maszynowe nie jest wyjątkiem. W naszym przypadku solidny punkt wyjścia oznaczał wprowadzenie restrykcyjnych ograniczeń dotyczących tego, co model może wykrywać oraz w jaki sposób może rozpoznawać intencje użytkownika. Chociaż w przyszłości planujemy rozszerzyć możliwości modelu, zarówno pod względem różnorodności elementów, jak i swobody ich rysowania, na razie ograniczymy się do następujących konwencji (wiele z nich zainspirował język Markdown):

• Nagłówek: ponieważ można go pomylić z akapitem, proponujemy poprzedzać go znakiem hashtagu
• Pole tekstowe: ponieważ można je pomylić z przyciskiem, proponujemy używać wyłącznie pustego pola tekstowego
• Link: ujmiemy go w nawiasy kwadratowe
• Etykiety: będą rozpoznawane jako takie tylko wtedy, gdy są powiązane z polem wejściowym
• Akapit: jeśli tekst nie jest etykietą, nagłówkiem ani linkiem, jest akapitem
• Obraz: może mieć wyłącznie kształt prostokąta lub okręgu z krzyżykiem w środku

Nasze przyszłe wytyczne dotyczące rysowania makiet

To była trudna decyzja, ale jesteśmy przekonani, że wprowadzone przez nas ograniczenia przyniosą ważne korzyści, które przeważą nad takimi niedogodnościami jak:

• Czy to pole tekstowe, czy przycisk?
• Czy to obraz, czy przycisk?
• Zadbaj o jednoznaczną adnotację

Podsumowanie#

Na razie nasze API do analizy obrazu nadal działa zgodnie ze starymi wytycznymi, ale wkrótce, w kolejnej wersji, zaczniemy stosować nowe. Jak zawsze chcemy przypomnieć, że to wciąż praca w toku i daleko jej do doskonałości. Chętnie poznamy jednak wszelkie opinie i pomysły na to, jak ulepszyć nasze API do analizy obrazu. Napisz do nas na Twitterze i obserwuj nas, aby nie przegapić kolejnych aktualizacji.