Există o tendință iminentă în digitalizarea mediului de lucru. Juxtapunerea dintre caracteristicile birourilor închiriate și nevoile adevărate ale utilizatorilor finali devine din ce în ce mai greu de justificat. Considerăm că valoarea angajaților este diminuată atunci când limitările spațiilor închiriate inhibă productivitatea, creativitatea și colaborarea percepută de către angajați. Prin urmare, obiectivul nostru principal este de a transforma mediul fizic de lucru într-un participant la activitățile zilnice de la birou.
Suntem pe ultima sută de metri înainte de a ne muta în noul sediu al Centrului de Inginerie Bosch din Cluj, o clădire emblematică gândită după standardele IWC (condiții inspiraționale de muncă) Bosch, iar echipa noastră a fost extrem de norocoasă să facă parte din procesul modelării acestui nou mediu, astfel încât să fie conform nevoilor și dorințelor noastre de la bun început. În contextul condițiilor IWC Bosch, am profitat de ocazie, și am dezvoltat o soluție care urmărește să ofere fiecărui utilizator funcționalitățile care să conecteze formele/culorile care inspiră gândirea creativă cu tehnologia de ultimă generație în automatizarea spațiului de birouri (personalizate după nevoile noastre). Claritatea are o frumusețe aparte atunci când vine după o perioadă de confuzie. Dorim să împărtășim procesul cu voi. Pentru ca ideile noastre să devină realitate, a fost necesară dezvoltarea unei baze infrastructurale puternice. Deși este uzual să se construiască atât cât trebuie pentru ca logica centrală de business să funcționeze, obiectivul pe care încercăm sa-l atingem elimină posibilitatea unor iterații mici de dezvoltare. Agentul de recomandare a birourilor are nevoie de un context de mediu unde poate opera, ceea ce ne-a determinat să construim un sistem de cartografiere interioară, care poate genera reprezentări multiple dintr-o sursă unică BIM (Building Information Model). Am investit mult în conceperea modului în care ar funcționa sistemul de feedback, din moment ce dinamismul emergent al mediului de la birou este dificil de capturat, în special ținând cont de constrângerile existente. Reducerea timpului de interacțiune a fost o constantă în euristica noastră de design pe parcursul dezvoltării proiectului. Această constrângere a adus propriile provocări ulterior, ceea ce a schimbat modul în care am conceput design-ul. Mai mult, după ce am extins gama de posibilități a sistemului inițial prin integrarea mai multor factori externi, am realizat că problema trebuie redefinită în termeni mai generici.
Produsul muncii noastre este MDK smart assistant core. Este un sistem construit de la zero, gândit să deservească modularitatea și siguranța. Arhitectura MDK este modelată de trei concepte fundamentale:
Având în vedere aceste concepte, am dezvoltat o fundație arhitecturală rezistentă, care este de asemenea extrem de eficientă în ceea ce privește viteza de dezvoltare. MDK este scris în Haskell, un limbaj de programare pur funcțional, de tip strongly-typed. După ce am petrecut mult timp în acest ecosistem, putem spune că anume acest subset de funcționalități Haskell fac ca MDK să fie ușor de înțeles, de extins și extrem de eficient când vorbim de cod concurent. Mulțumită STM (Software Transactional Memory - Memorie Tranzacțională de Software), putem evita multe condiții de cursă și deadlock-uri, ceea ce ușurează enorm de mult modificarea simultană a datelor. Aceste anomalii se pot manifesta, dar probabilitatea este mică. Trebuie să aducem în discuție și execuția non-strictă, ceea ce ne permite să obținem rezultate eficiente cu cod de nivel înalt. O funcționalitate de care suntem foarte mândri este compunerea automată de agenți, ceea ce acceptă un nou tip de intenție și încearcă să găsească o combinație potrivită între agenții deja existenți care, atunci când sunt secvențializați vor produce rezultatul dorit. Totul se întâmplă la nivel de tip folosind tipuri dependente, ceea ce este mult mai apropiat de programarea bazată pe constrângeri decât programarea logică în stil Prolog.
Vom simplifica unele concepte pentru a ne încadra în limitele acestui articol. Definim o intenție la nivel de tip, aceasta fiind identică cu semnătura de tip a funcției handler. Este un morfism ce transformă Entity a în Entity b. De exemplu, agentul meteorologic ia Entity PlaceEntity drept element de intrare și oferă ca rezultat Entity WeatherEntity. Funcția handler ce execută aceste operații este cuprinsă într-un tip de date Agent sau Dispozitiv. Resolver-ul central ce primește intenții generează un index ce asociază aceste semnături de tip cu modulele lor corespondente. Marele avantaj al acestei metode este documentarea implicită a codului - nu e nevoie de șiruri separate de notații pentru intențiile în sine - putem doar folosi tipurile. În cadrul acestui framework, sistemul de recomandare este implementat ca un alt agent ce exprimă starea internă a clădirii pentru a genera spații optime pentru o activitate. Cu aceasta ajungem la țesătura ce stă la baza acestui proiect - structura de date de tip graf. În culise, MDK este doar o colecție de operațiuni pe graful BIM, similar modului în care git poate fi gândit ca o colecție de operațiuni deasupra unei structuri de date pur funcționale. Aceeași reprezentare structurală a clădirii este folosită pentru navigare, control și logică. Subsetul de navigare al grafului de vizibilitate este o structură spațială imbricată cât de sumar posibil, fără a omite detaliile critice pentru orientare. Sistemul de decizie logică oferă context pentru graful de noduri. Acesta acceptă surse de date multiple, inclusiv starea clădirii în timp real. De exemplu, va ignora liftul dacă o evacuare de urgență este în desfășurare. Similar, va ignora scările dacă utilizatorul care solicită acest lucru este în scaun cu rotile. Folosim acest modul și pentru a experimenta cu simularea pietonală.
Modelele îmbogățite semantic sunt cruciale pentru dezvoltarea sistemelor inteligente ce au în centru oamenii. Pentru a promova acest atribut de calitate, am creat și un REPL ce ne permite să interacționăm ușor cu alte sisteme printr-un DSL customizat.
Agentul de recomandare este puțin neobișnuit în modul în care funcționează. Cabal, utilizat notoriu de Valve pentru a-și organiza dinamic forța de muncă conform unui model de dezvoltare distribuită, este o sursă de inspirație pentru noi. În timp ce ei preferă să mute fizic birourile lor pe roți, abordarea noastră este de a ne axa pe poziționarea angajaților. Acest lucru presupune ca fiecare birou să fie menținut curat după fiecare activitate, astfel ca noi să avem un mod standard de relocare ce implică fricțiune cât mai puțină. A doua sursă de inspirație vine din chimia informatică (cheminformatics) și din modul în care aceasta folosește machine learning în aplicațiile de descoperire a medicamentelor. De exemplu, fiind dată o bază de date cu compuși chimici și clasa lor asociată de bioactivitate (ex. nivel de toxicitate), putem prezice destul de bine scorul de bioactivitate pentru o structură chimică nouă. Această idee corespunde fidel problemei pe care ne propunem noi să o rezolvăm. Să presupunem că avem o echipă de angajați ce lucrează la un proiect. O implementare logică ar presupune amplasarea angajaților cât mai aproape unul de altul pentru a crea un mediu coeziv ce promovează comunicarea. Amplasarea lor reprezintă un subgraf atribuit, subsumat structurii globale de date menționate anterior. Fiecare membru al acestei echipe este un atom într-o moleculă, sau un graf al echipei. Clasa de bioactivitate a acestei echipe este dată de semnalul de feedback al fiecărui membru, care nu este obligatoriu. Un scor majoritar va determina cum evoluează această moleculă în viitor. Prin urmare, sistemul de recomandare generează trei opțiuni la invocare:
Din perspectivă business, sistemul este optimizat pentru utilizarea maximă de birouri. Simularea nocturnă menționată anterior folosește un scor de suprapunere (overlap score). Compania Robert Bosch are un sistem de măsurare a timpului la nivel de țară, care folosește 2 senzori principali pentru a înregistra timpii de pontare. Aceste evenimente sunt înregistrate la nivel de minut, care formează un set de date de calitate înaltă ce conține informații despre momentul în care angajații vin și pleacă. Această infrastructură este o precondiție obligatorie pentru a construi un astfel de sistem de recomandare, deoarece datele pe care le generează se potrivesc cu realitatea. De asemenea, prezicem care va fi opțiunea de birou aleasă de angajat. Aceste semnale euristice determină modul în care vor fi amplasate echipele, marcând birourile care vor face parte din granițele comune. Putem vizualiza problema și prin prisma teoriei jocurilor, unde fiecare actor (echipă) încearcă să maximizeze scorul propriu, iar soluția ține de găsirea echilibrului Nash. Semnalul de feedback este dat de un singur like/dislike din partea utilizatorului. Înțelegem că nu este suficient să surprindem particularitatea unei zile, dar scopul nostru este de a reduce timpul de interacțiune la minimum. Un formular de feedback detaliat este disponibil pe website-ul principal, dacă utilizatorul dorește să îl folosească. Chiar de la începutul proiectului, am conștientizat că utilizatorul poate ignora ecranul de feedback, deși este nevoie de doar trei secunde pentru a da un răspuns. Atâta timp cât multă lume interacționează cu interfața, semnalul de feedback este opțional. Este similar cu un vot democratic. Se spune că obținerea unei recompense este cheia dezvoltării unui nou obicei. Prin urmare, am implementat un agent care oferă informații de trafic în timp real pentru Cluj-Napoca. Astfel, încurajăm utilizatorul să ne ofere feedback arătându-i un pont util la finalul zilei:
Autobus nr. 35 -- 6 min. --> Stația Opera | Durata călătoriei: 12 min
Utilizatorii trebuie să specifice care sunt rutele lor preferate din timp în setările contului. Acest nivel de separare este o consecință directă a constrângerilor GDPR. Fiecare model de predicție poate fi anulat de utilizator, ceea ce ar regresa sistemul într-o stare implicită, cu comportament generic. Dezactivarea predicțiilor timpului de lucru poate duce tot la un scor de suprapunere brut (atâta timp cât alți angajați nu și-au retras datele), însă eficiența configurației de amplasare s-ar reduce semnificativ. Comportamentul default al agentului de trafic invocă un mesaj despre volumul de trafic, util în special pentru proprietarii de mașină. Când liftul se strică, acesta devine o scară. Aceasta a fost regula noastră de design de aur încă de la începutul proiectului. Orice funcționalitate are un sistem de siguranță fallback, iar totul se verifică în momentul compilării de către GHC (Glasgow Haskell Compiler). Există mult material pe care nu l-am abordat aici. Fiecare subsistem ar putea fi un articol. Sistemul de cartografiere internă și aplicarea markup, motorul NLU și graful de cunoștințe asociate, multitudinea de concepte Haskell care au redus complexitatea codului și multe altele. Toate aceste aspecte vor trebui să mai aștepte.
de Vasile Boris
de Ovidiu Mățan
