{"id":89110,"date":"2020-07-18T19:42:10","date_gmt":"2020-07-18T17:42:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/obshhij-obzor-arhitektury-servisa-dlya-oczenki-vneshnosti-na-osnove-nejronnyh-setej"},"modified":"2020-07-18T19:42:10","modified_gmt":"2020-07-18T17:42:10","slug":"obshhij-obzor-arhitektury-servisa-dlya-oczenki-vneshnosti-na-osnove-nejronnyh-setej","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/obshhij-obzor-arhitektury-servisa-dlya-oczenki-vneshnosti-na-osnove-nejronnyh-setej","title":{"rendered":"Generel oversigt over arkitekturen af tjenesten til vurdering af udseendet baseret p\u00e5 neurale netv\u00e6rk","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Generel<\/p>\n

Introduktion<\/h2>\n

<\/p>\n

Hej!<\/p>\n

<\/p>\n

I denne artikel vil jeg dele erfaringer med at opbygge en mikrotjenestearkitektur til et projekt, der bruger neurale netv\u00e6rk.<\/p>\n

<\/p>\n

Lad os tale om kravene til arkitekturen, se p\u00e5 forskellige strukturelle diagrammer, gennemg\u00e5 hver af komponenterne i den f\u00e6rdige arkitektur, samt vurdere de tekniske metrikker for l\u00f8sningen.<\/p>\n

<\/p>\n

God l\u00e6selyst!<\/p>\n

<\/a><\/noindex><\/p>\n

Et par ord om opgaven og dens l\u00f8sning<\/h2>\n

<\/p>\n

Hovedid\u00e9en er at vurdere en persons tiltr\u00e6kningskraft baseret p\u00e5 billeder p\u00e5 en skala fra 1 til 10.<\/p>\n

<\/p>\n

I denne artikel vil vi ikke komme ind p\u00e5 hverken de anvendte neurale netv\u00e6rk eller dataforberedelse og tr\u00e6ning. Men i en af de kommende publikationer vil vi bestemt vende tilbage til en dybere gennemgang af vurderingspipelines.<\/p>\n

<\/p>\n

Lige nu vil vi overordnet gennemg\u00e5 vurderingspipelinen og fokusere p\u00e5 samspillet mellem mikrotjenesterne i konteksten af projektets samlede arkitektur.\u00a0<\/p>\n

<\/p>\n

N\u00e5r man arbejder med vurderingspipelinen for tiltr\u00e6kningskraft, blev opgaven opdelt i f\u00f8lgende komponenter:<\/p>\n

<\/p>\n

    \n
  1. Ansigtsgenkendelse p\u00e5 billeder<\/li>\n
  2. Vurdering af hvert ansigt<\/li>\n
  3. Rendering af resultatet<\/li>\n<\/ol>\n

    <\/p>\n

    Det f\u00f8rste l\u00f8ses med en fortr\u00e6net MTCNN<\/a><\/noindex>. Til det andet blev en konvolutionel neurale netv\u00e6rk tr\u00e6net i PyTorch, hvor ResNet34<\/a><\/noindex> blev brugt som backbone med fokus p\u00e5 \"kvalitet \/ hastighed ved inference p\u00e5 CPU\".<\/p>\n

    \n\"Generel<\/p>\n

    Funktionsdiagram for vurderingspipelinens struktur<\/i><\/p>\n

    <\/p>\n

    Analyse af kravene til projektarkitekturen<\/h2>\n

    <\/p>\n

    I livscyklussen ML<\/a><\/noindex> er faserne med at arbejde p\u00e5 arkitekturen og automatisering af implementeringen af modellen ofte de mest tid- og ressourcekr\u00e6vende.<\/p>\n

    \n\"Generel<\/p>\n

    Livscyklussen for ML-projekter<\/i><\/p>\n

    <\/p>\n

    Dette projekt er ingen undtagelse \u2013 der blev taget beslutning om at pakke vurderingspipelinen ind i en online service, hvilket kr\u00e6vede dybdeg\u00e5ende forst\u00e5else af arkitekturen. De grundl\u00e6ggende krav blev fastlagt:<\/p>\n

    <\/p>\n

      \n
    1. Et centralt logopbevaringssystem \u2013 alle tjenester skal skrive logfiler til \u00e9t sted, og disse skal v\u00e6re nemme at analysere.<\/li>\n
    2. Mulighed for horisontal skalering af vurderingstjenesten \u2014 som den mest sandsynlige flaskehals.<\/li>\n
    3. Der skal tildeles det samme antal CPU-ressourcer til vurderingen af hvert billede \u2014 for at undg\u00e5 udsving i tidsfordelingen for inference.<\/li>\n
    4. Hurtig (gen)implementering af b\u00e5de specifikke tjenester og stakken som helhed.<\/li>\n
    5. Mulighed for, om n\u00f8dvendigt, at anvende f\u00e6lles objekter i forskellige tjenester.<\/li>\n<\/ol>\n

      <\/p>\n

      Arkitektur<\/h2>\n

      <\/p>\n

      Efter analysen af krav blev det klart, at mikrotjenestearkitekturen passer n\u00e6sten perfekt.<\/p>\n

      <\/p>\n

      For at slippe for un\u00f8dige hovedpiner blev Telegram API valgt som frontend.<\/p>\n

      <\/p>\n

      Lad os f\u00f8rst se p\u00e5 den strukturelle diagram over den f\u00e6rdige arkitektur, derefter g\u00e5r vi videre til beskrivelsen af hver komponent og formaliserer processen for succesfuld billedbehandling.<\/p>\n

      \n\"Generel<\/p>\n

      Strukturelt diagram over den f\u00e6rdige arkitektur<\/i><\/p>\n

      <\/p>\n

      Lad os tale mere om hver komponent i diagrammet og definere deres Single Responsibility i vurderingsprocessen af billedet.<\/p>\n

      <\/p>\n

      Mikrotjeneste \u00abattrai-telegram-bot\u00bb<\/h3>\n

      <\/p>\n

      Denne mikrotjeneste inkapslerer al interaktion med Telegram API. Vi kan fremh\u00e6ve to hovedscenarier \u2013 arbejde med brugerens billede og arbejde med resultatet fra vurderingspipen. Lad os gennemg\u00e5 begge scenarier i al almindelighed.<\/p>\n

      <\/p>\n

      N\u00e5r et brugerbesked med billede modtages:<\/p>\n

      <\/p>\n

        \n
      1. Der udf\u00f8res en filtrering best\u00e5ende af f\u00f8lgende tjek:\n