Aceasta este o postare invitată de Oliver Frost, cercetător de date la ImmoScout24, în parteneriat cu Lukas Müller, AWS Solutions Architect.
În 2010, ImmoScout24 a lansat un indice de preț pentru imobilele rezidențiale din Germania: IMX. S-a bazat pe listări ImmoScout24. Pe lângă preț, listele conțin de obicei o mulțime de informații specifice, cum ar fi anul de construcție, dimensiunea parcelei sau numărul de camere. Aceste informații ne-au permis să construim un așa-numit indice hedonic al prețurilor, care ia în considerare caracteristicile particulare ale unei proprietăți imobiliare.
Când am lansat IMX, scopul nostru a fost să îl stabilim ca indice standard pentru prețurile imobiliare din Germania. Cu toate acestea, s-a chinuit să surprindă creșterea prețurilor pe piața imobiliară germană de la criza financiară din 2008. În plus, ca un indice bursier, era o cifră abstractă care nu poate fi interpretată direct. Prin urmare, IMX a fost greu de înțeles pentru neexperți.
La ImmoScout24, misiunea noastră este să luăm decizii complexe cu ușurință și am realizat că avem nevoie de un nou concept pentru a-l îndeplini. În loc de un alt indice, am decis să construim un raport de piață pe care toată lumea să-l poată înțelege cu ușurință: WohnBarometrul. Se bazează pe datele din listările noastre și ia în considerare proprietățile obiectului. Diferența cheie față de IMX este că WohnBarometrul arată prețurile de chirie și vânzare în euro pe metru pătrat pentru anumite tipuri de imobile rezidențiale de-a lungul timpului. Prin urmare, cifrele pot fi interpretate direct și permit clienților noștri să răspundă la întrebări precum „Plătesc prea multă chirie?” sau „Apartamentul pe care urmează să-l cumpăr are un preț rezonabil?” sau „Care oraș din regiunea mea este cel mai promițător pentru investiții?” În prezent, WohnBarometrul este raportat pentru Germania în ansamblu, cele mai mari șapte orașe și piețe locale alternative.
Următorul grafic prezintă un exemplu de WohnBarometru, cu prețurile de vânzare pentru Berlin și evoluția pe trimestru.
Această postare discută cum a folosit ImmoScout24 Amazon SageMaker pentru a crea modelul pentru WohnBarometru pentru a-l face relevant pentru clienții noștri. Se discută despre modelul de date de bază, reglarea hiperparametrului și configurația tehnică. Această postare arată, de asemenea, cum SageMaker a sprijinit un om de știință de date pentru a finaliza WohnBarometrul în decurs de 2 luni. A fost nevoie de o întreagă echipă 2 ani pentru a dezvolta prima versiune a IMX. O astfel de investiție nu era o opțiune pentru WohnBarometer.
Despre ImmoScout24
ImmoScout24 este principala platformă online pentru proprietăți imobiliare rezidențiale și comerciale din Germania. De peste 20 de ani, ImmoScout24 a revoluționat piața imobiliară și sprijină peste 20 de milioane de utilizatori în fiecare lună pe piața sa online sau în aplicația sa pentru a găsi noi locuințe sau spații comerciale. De aceea, 99% din grupul nostru de clienți țintă cunosc ImmoScout24. Cu soluțiile sale digitale, piața online coordonează și reunește cu succes proprietarii, agenții imobiliari, chiriașii și cumpărătorii. ImmoScout24 lucrează în vederea digitizării procesului de tranzacții imobiliare și, prin urmare, luarea deciziilor complexe cu ușurință. Din 2012, ImmoScout24 este activ și pe piața imobiliară din Austria, ajungând lunar la aproximativ 3 milioane de utilizatori.
De la on-premises la AWS Data Pipeline la SageMaker
În această secțiune, discutăm despre configurația anterioară și provocările acesteia și de ce am decis să folosim SageMaker pentru noul nostru model.
Configurația anterioară
Când prima versiune a IMX a fost publicată în 2010, cloud-ul era încă un mister pentru majoritatea companiilor, inclusiv pentru ImmoScout24. Domeniul învățării automate (ML) era la început și doar o mână de experți știau cum să codifice un model (de dragul ilustrației, prima lansare publică a Scikit-Learn a fost în februarie 2010). Nu este surprinzător faptul că dezvoltarea IMX a durat mai mult de 2 ani și a costat o sumă de șapte cifre.
În 2015, ImmoScout24 și-a început migrarea AWS și a reconstruit IMX pe infrastructura AWS. Cu datele din nostru Serviciul Amazon de stocare simplă (Amazon S3) data lake, atât preprocesarea datelor, cât și formarea modelului au fost acum efectuate Amazon EMR clustere orchestrate de Conductă de date AWS. În timp ce prima a fost o aplicație PySpark ETL, cea de-a doua a fost mai multe scripturi Python care foloseau pachete ML clasice (cum ar fi Scikit-Learn).
Probleme cu această configurare
Deși această configurație sa dovedit destul de stabilă, depanarea infrastructurii sau îmbunătățirea modelului nu a fost ușoară. O problemă cheie a modelului a fost complexitatea acestuia, deoarece unele componente și-au început viața de la sine: în cele din urmă, codul de detectare a valorii aberante a fost aproape de două ori mai lung decât codul modelului IMX de bază în sine.
Modelul de bază, de fapt, nu a fost un model, ci sute: un model per tip de imobil rezidențial și regiune, cu definiția variind de la un singur cartier dintr-un oraș mare la mai multe sate din zonele rurale. Am avut, de exemplu, un model de apartamente de vânzare în mijlocul Berlinului și un model de case de vânzare într-o suburbie a Münchenului. Deoarece configurarea antrenamentului pentru toate aceste modele a durat mult timp, am omis reglarea hiperparametrului, ceea ce a dus probabil la performanța scăzută a modelelor.
De ce ne-am hotărât pe SageMaker
Având în vedere aceste probleme și ambiția noastră de a avea un raport de piață cu beneficii practice, a trebuit să decidem între a rescrie părți mari din codul existent sau a începe de la zero. După cum puteți deduce din această postare, am optat pentru cea din urmă. Dar de ce SageMaker?
Majoritatea timpului petrecut pe IMX a mers în depanarea infrastructurii, nu în îmbunătățirea modelului. Pentru noul raport de piață, am vrut să inversăm acest lucru, cu accent pe performanța statistică a modelului. Ne-am dorit, de asemenea, să avem flexibilitatea de a înlocui rapid componentele individuale ale modelului, cum ar fi optimizarea hiperparametrilor. Ce se întâmplă dacă apare un nou algoritm de stimulare superior (gândiți-vă la modul în care XGBoost a ajuns pe scenă în 2014)? Desigur, vrem să-l adoptăm ca pe unul dintre primii!
În SageMaker, componentele majore ale fluxului de lucru ML clasic - preprocesare, antrenament, reglare hiperparametrică și inferență - sunt bine separate la nivel de API și, de asemenea, Consola de administrare AWS. Modificarea lor individuală nu este dificilă.
Noul model
În această secțiune, discutăm componentele noului model, inclusiv datele sale de intrare, algoritmul, reglarea hiperparametrului și configurația tehnică.
Date de intrare
WohnBarometrul se bazează pe o fereastră glisantă de 5 ani de listări ImmoScout24 cu proprietăți imobiliare rezidențiale situate în Germania. După ce eliminăm valorile aberante și înregistrările frauduloase, am rămas cu aproximativ 4 milioane de înregistrări care sunt împărțite în tren (60 %), validare (20 %) și date de testare (20 %). Relația dintre listări și obiecte nu este neapărat 1:1; pe parcursul a 5 ani, este probabil ca același obiect să fie introdus de mai multe ori (de mai multe persoane).
Folosim 13 atribute de listare, cum ar fi locația proprietății (coordonatele WGS84), tipul imobilului (casă sau apartament, vânzare sau închiriere), vârsta acesteia (ani), dimensiunea (metrul pătrat) sau starea sa (de exemplu , nou sau renovat). Având în vedere că fiecare listare vine de obicei cu zeci de atribute, se pune întrebarea: pe care să le includă în model? Pe de o parte, am folosit cunoștințele de domeniu; de exemplu, este bine cunoscut faptul că locația este un factor cheie și, în aproape toate piețele, proprietatea nouă este mai scumpă decât cele existente. Pe de altă parte, ne-am bazat pe experiențele noastre cu IMX și modele similare. Acolo am aflat că includerea a zeci de atribute nu îmbunătățește semnificativ modelul.
În funcție de tipul imobiliar al listării, variabila țintă a modelului nostru este fie chiria pe metru pătrat, fie prețul de vânzare pe metru pătrat (explicăm mai târziu de ce această alegere nu a fost ideală). Spre deosebire de IMX, WohnBarometrul este, prin urmare, un număr care poate fi interpretat direct și acționat de către clienții noștri.
Descrierea modelului
Când utilizați SageMaker, puteți alege dintre diferite strategii de implementare a algoritmului:
- Utilizați unul dintre algoritmii încorporați ai SageMaker. Există aproape 20 și acopera toate tipurile majore de probleme ML.
- Personalizați o imagine Docker prefabricată pe baza unui cadru ML standard (cum ar fi Scikit-Learn sau PyTorch).
- Creați-vă propriul algoritm și implementați-l ca imagine Docker.
Pentru WohnBarometer, ne-am dorit o soluție care să fie ușor de întreținut și să ne permită să ne concentrăm pe îmbunătățirea modelului în sine, nu a infrastructurii de bază. Prin urmare, ne-am decis asupra primei opțiuni: folosiți un algoritm complet gestionat, cu documentație adecvată și asistență rapidă, dacă este necesar. Apoi, trebuia să alegem algoritmul în sine. Din nou, decizia nu a fost dificilă: am optat pentru algoritmul XGBoost pentru că este unul dintre cei mai renumiți algoritmi ML pentru probleme de tip regresie și l-am folosit deja cu succes în mai multe proiecte.
Reglarea hiperparametrului
Majoritatea algoritmilor ML vin cu o multitudine de parametri de ajustat. Algoritmii de amplificare, de exemplu, au mulți parametri care specifică cum exact sunt construiți copacii: Au copacii maxim 20 sau 30 de frunze? Fiecare arbore se bazează pe toate rândurile și coloanele sau numai pe mostre? Cât de mult să tăiați copacii? Găsirea valorilor optime ale acelor parametri (măsurate printr-o metrică de evaluare la alegerea dvs.), așa-numita ajustare a hiperparametrului, este esențială pentru construirea unui model ML puternic.
O întrebare cheie în reglarea hiperparametrilor este ce parametri să reglați și cum să setați intervalele de căutare. S-ar putea să vă întrebați, de ce să nu verificați toate combinațiile posibile? Deși, în teorie, aceasta sună a o idee bună, ar avea ca rezultat un spațiu hiperparametric enorm cu mult prea multe puncte pentru a le evalua pe toate la un preț rezonabil. De aceea, practicienii ML selectează de obicei un număr mic de hiperparametri despre care se știe că au un impact puternic asupra performanței algoritmului ales.
După ce spațiul hiperparametru este definit, următoarea sarcină este să găsiți cea mai bună combinație de valori în el. Următoarele tehnici sunt utilizate în mod obișnuit:
- Căutare în grilă – Împărțiți spațiul într-o grilă discretă și apoi evaluați toate punctele din grilă cu validare încrucișată.
- Căutare aleatorie – Desenați aleatoriu combinații din spațiu. Cu această abordare, cel mai probabil veți rata cea mai bună combinație, dar ea servește ca un punct de referință bun.
- Optimizare bayesiană – Construiți un model probabilistic al funcției obiectiv și utilizați acest model pentru a genera noi combinații. Modelul este actualizat după fiecare combinație, ducând rapid la rezultate bune.
În ultimii ani, datorită puterii de calcul ieftine, optimizarea bayesiană a devenit standardul de aur în reglarea hiperparametrului și este setarea implicită în SageMaker.
Configurare tehnică
Ca și în cazul multor alte servicii AWS, puteți crea joburi SageMaker pe consolă, cu Interfața liniei de comandă AWS (AWS CLI) sau prin cod. Am ales a treia opțiune, SageMaker Python SDK pentru a fi mai precis, deoarece permite o configurare extrem de automatizată: WohnBarometer trăiește într-un proiect software Python care este executabil în linie de comandă. De exemplu, toți pașii conductei ML, cum ar fi preprocesarea sau antrenamentul modelului, pot fi declanșați prin comenzile Bash. Acele comenzi Bash, la rândul lor, sunt orchestrate cu o conductă Jenkins alimentată de AWS Fargate.
Să ne uităm la pașii și la infrastructura de bază:
- preprocesare – Preprocesarea se face cu biblioteca încorporată Scikit-Learn în SageMaker. Deoarece implică unirea cadrelor de date cu milioane de rânduri, avem nevoie aici de o mașină ml.m5.24xlarge, cea mai mare pe care o poți obține din familia ml.m. Alternativ, am fi putut folosi mai multe mașini mai mici cu un cadru distribuit precum Dask, dar am vrut să-l menținem cât mai simplu posibil.
- Pregătire – Folosim algoritmul implicit SageMaker XGBoost. Antrenamentul se face cu două aparate ml.m5.12xmari. De menționat că train.py nostru care conține codul antrenamentului modelului și reglarea hiperparametrului are mai puțin de 100 de rânduri.
- Reglarea hiperparametrului – Urmând principiul less is more, reglam doar 11 hiperparametri (de exemplu, numărul de runde de amplificare și rata de învățare), ceea ce ne oferă timp să le alegem cu atenție intervalele și să inspectăm modul în care interacționează între ei. Cu doar câțiva hiperparametri, fiecare job de antrenament rulează relativ rapid; în cazul nostru, lucrările durează între 10–20 de minute. Cu un număr maxim de 30 de locuri de muncă de formare și 2 locuri de muncă concomitente, timpul total de pregătire este de aproximativ 3 ore.
- deducție – SageMaker oferă mai multe opțiuni pentru a vă servi modelul. Folosim joburi de transformare în lot, deoarece avem nevoie doar de numerele WohnBarometer o dată pe trimestru. Nu am folosit un punct final pentru că ar fi inactiv de cele mai multe ori. Fiecare sarcină lot (aproximativ 6.8 milioane de rânduri) este deservită de o singură mașină ml.m5.4xlarge în mai puțin de 10 minute.
Putem depana cu ușurință acești pași pe consola SageMaker. Dacă, de exemplu, un job de formare durează mai mult decât era de așteptat, navigăm la Pregătire pagina, localizați jobul de formare în cauză și examinați Amazon CloudWatch metrici ale mașinilor de bază.
Următoarea diagramă de arhitectură arată infrastructura WohnBarometer:
Provocări și învățături
La început totul a decurs fără probleme: în câteva zile am configurat proiectul software și am antrenat o versiune în miniatură a modelului nostru în SageMaker. Am avut mari speranțe pentru prima rulare a setului de date complet și reglarea hiperparametrului în vigoare. Din păcate, rezultatele nu au fost satisfăcătoare. Am avut următoarele probleme cheie:
- Previziunile modelului erau prea mici, atât pentru obiectele de închiriere, cât și pentru vânzare. Pentru Berlin, de exemplu, prețurile de vânzare prevăzute pentru obiectele noastre de referință au fost cu aproximativ 50% sub prețurile pieței.
- Conform modelului, nu a existat o diferență semnificativă de preț între clădirile noi și cele existente. Adevărul este că clădirile noi sunt aproape întotdeauna semnificativ mai scumpe decât clădirile existente.
- Efectul locației asupra prețului nu a fost surprins corect. Știm, de exemplu, că apartamentele de vânzare în Frankfurt pe Main, sunt, în medie, mai scumpe decât în Berlin (deși Berlinul este în curs de recuperare); modelul nostru, însă, a prezis-o invers.
Care a fost problema și cum am rezolvat-o?
Eșantionarea caracteristicilor
La prima vedere, se pare că problemele nu sunt legate, dar într-adevăr sunt. În mod implicit, XGBoost construiește fiecare arbore cu un eșantion aleatoriu de caracteristici. Să presupunem că un model are 10 caracteristici F1, F2, … F10, atunci algoritmul ar putea folosi F1, F4, și F7 pentru un copac și F3, F4, și F8 pentru altul. În timp ce, în general, acest comportament previne în mod eficient supraadaptarea, poate fi problematic dacă numărul de caracteristici este mic și unele dintre ele au un efect mare asupra variabilei țintă. În acest caz, mulți copaci vor pierde caracteristicile cruciale.
Eșantionarea de către XGBoost a celor 13 caracteristici ale noastre a condus la mulți copaci care nu includ niciuna dintre caracteristicile esențiale - tipul imobiliar, locația și clădirile noi sau existente - și, în consecință, a cauzat aceste probleme. Din fericire, există un parametru pentru a controla eșantionarea: colsample_bytree
(de fapt, mai sunt doi parametri pentru a controla eșantionarea, dar nu i-am atins). Când ne-am verificat codul, am văzut asta colsample_bytree
a fost setat la 0.5, o valoare pe care am reportat-o din proiectele anterioare. De îndată ce l-am setat la valoarea implicită de 1, problemele precedente au dispărut.
Un model față de mai multe modele
Spre deosebire de IMX, modelul WohnBarometer este într-adevăr un singur model. Deși acest lucru minimizează efortul de întreținere, nu este ideal din punct de vedere statistic. Deoarece datele noastre de instruire conțin atât obiecte de vânzare, cât și de închiriere, diferența în variabila țintă este uriașă: variază de la sub 5 euro pentru unele apartamente închiriate până la mult peste 10,000 de euro pentru casele de vânzare în locații de primă clasă. Marea provocare pentru model este să înțeleagă că o eroare de 5 Euro este fantastică pentru obiectele de vânzare, dar dezastruoasă pentru obiectele închiriate.
În retrospectivă, știind cât de ușor este să întreținem mai multe modele în SageMaker, am fi construit cel puțin două modele: unul de închiriat și unul de vânzare obiecte. Acest lucru ar facilita surprinderea particularităților ambelor piețe. De exemplu, prețul apartamentelor neînchiriate de vânzare este de obicei cu 20–30% mai mare decât al apartamentelor închiriate de vânzare. Prin urmare, codificarea acestor informații ca variabilă dummy în modelul de vânzare are foarte mult sens; pentru modelul de închiriere, pe de altă parte, l-ai putea lăsa afară.
Concluzie
A îndeplinit WohnBarometrul obiectivul de a fi relevant pentru clienții noștri? Luând ca un indicator mediatizarea, răspunsul este un da clar: din noiembrie 2021, au fost publicate peste 700 de articole din ziare și reportaje TV sau radio despre WohnBarometru. Lista include ziare naționale precum Frankfurter Allgemeine Zeitung, Tagesspiegel și Handelsblatt și ziare locale care solicită adesea cifre WohnBarometer pentru regiunea lor. Pentru că oricum calculăm cifrele pentru toate regiunile Germaniei, suntem bucuroși să acceptăm astfel de solicitări. Cu vechiul IMX, acest nivel de granularitate nu era posibil.
WohnBarometrul depășește IMX-ul în ceea ce privește performanța statică, în special când vine vorba de costuri: IMX-ul a fost generat de un cluster EMR cu 10 noduri de activitate care rulează aproape o jumătate de zi. În schimb, toți pașii WohnBarometer durează mai puțin de 5 ore folosind mașini de dimensiuni medii. Acest lucru duce la economii de costuri de aproape 75%.
Datorită SageMaker, am reușit să aducem în producție un model complex ML cu un singur cercetător de date în mai puțin de 2 luni. Acest lucru este remarcabil. Cu 10 ani mai devreme, când ImmoScout24 a construit IMX, atingerea aceluiași reper a durat mai bine de 2 ani și a implicat o întreagă echipă.
Cum am putea fi atât de eficienți? SageMaker ne-a permis să ne concentrăm pe model în loc de infrastructură, iar SageMaker promovează o arhitectură de microservicii care este ușor de întreținut. Dacă am rămas blocați cu ceva, am putea apela la asistența AWS. În trecut, când una dintre conductele noastre de date IMX a eșuat, uneori petreceam zile întregi pentru a-l depana. De când am început să publicăm cifrele WohnBarometer în aprilie 2021, infrastructura SageMaker nu a eșuat o singură dată.
Pentru a afla mai multe despre WohnBarometru, consultați Barometrul Wohn și WohnBarometer: Angebotsmieten stiegen 2021 bundesweit wieder stärker an. Pentru a afla mai multe despre utilizarea bibliotecii SageMaker Scikit-Learn pentru preprocesare, consultați Preprocesează datele de intrare înainte de a face predicții utilizând conductele de inferență Amazon SageMaker și Scikit-learn. Vă rugăm să ne trimiteți feedback, fie cu privire la Forum AWS pentru Amazon SageMaker, sau prin contactele dvs. de asistență AWS.
Conținutul și opiniile din această postare sunt cele ale autorului terț, iar AWS nu este responsabilă pentru conținutul sau acuratețea acestei postări.
Despre Autori
Oliver Frost sa alăturat ImmoScout24 în 2017 ca analist de afaceri. Doi ani mai târziu, a devenit cercetător de date într-o echipă a cărei sarcină este să transforme datele ImmoScout24 în veritabile produse de date. Înainte de a construi modelul WohnBarometer, a condus proiecte mai mici SageMaker. Oliver deține mai multe certificate AWS, inclusiv specialitatea Machine Learning.
Lukas Müller este arhitect de soluții la AWS. Lucrează cu clienți din industriile sportului, media și divertismentului. El caută mereu modalități de a combina abilitarea tehnică cu abilitarea culturală și organizațională pentru a ajuta clienții să obțină valoare de afaceri cu tehnologiile cloud.
- Coinsmart. Cel mai bun schimb de Bitcoin și Crypto din Europa.
- Platoblockchain. Web3 Metaverse Intelligence. Cunoștințe amplificate. ACCES LIBER.
- CryptoHawk. Radar Altcoin. Încercare gratuită.
- Sursa: https://aws.amazon.com/blogs/machine-learning/predict-residential-real-estate-prices-at-immoscout24-with-amazon-sagemaker/
- "
- 000
- 100
- 11
- ani 20
- 2021
- Despre Noi
- Cont
- activ
- Algoritmul
- algoritmi
- TOATE
- deja
- Cu toate ca
- Amazon
- analist
- O alta
- api
- aplicaţia
- aplicație
- abordare
- Aprilie
- arhitectură
- în jurul
- bunuri
- Automata
- in medie
- AWS
- deveni
- Început
- fiind
- Benchmark
- Beneficiile
- CEL MAI BUN
- Cea mai mare
- stimularea
- construi
- Clădire
- construiește
- construit-in
- afaceri
- întreprinderi
- cumpăra
- apel
- Poate obține
- cauzată
- Certificatele
- contesta
- provocări
- Oraşe
- Oraș
- Cloud
- cod
- combinaţie
- combinaţii
- comercial
- complex
- Calcula
- concept
- condiție
- consideră
- Consoleze
- construcţie
- conține
- conţinut
- Control
- Nucleu
- Cheltuieli
- ar putea
- criză
- crucial
- clienţii care
- de date
- om de știință de date
- zi
- implementa
- Detectare
- dezvolta
- Dezvoltare
- FĂCUT
- diferit
- digital
- discuta
- distribuite
- Docher
- Nu
- domeniu
- cu ușurință
- efect
- eficient
- Punct final
- enorm
- Divertisment
- stabili
- bunuri
- Euro
- toată lumea
- tot
- exemplu
- de aşteptat
- Experiențe
- experți
- familie
- FAST
- DESCRIERE
- feedback-ul
- Figura
- financiar
- Criza financiară
- First
- Flexibilitate
- Concentra
- următor
- Cadru
- Îndeplini
- Complet
- funcţie
- General
- genera
- Germania
- ochire
- scop
- Aur
- bine
- Grilă
- grup
- Oaspete
- Vizitator Mesaj
- fericit
- având în
- ajutor
- aici
- Înalt
- extrem de
- deține
- casă
- case
- Cum
- Cum Pentru a
- HTTPS
- mare
- sute
- idee
- imagine
- Impactul
- îmbunătăţi
- include
- Inclusiv
- Crește
- index
- individ
- industrii
- informații
- Infrastructură
- investind
- investiţie
- implicat
- probleme de
- IT
- Loc de munca
- Locuri de munca
- alăturat
- Cheie
- cunoştinţe
- cunoscut
- mare
- conducere
- AFLAȚI
- învățat
- învăţare
- Led
- Nivel
- Bibliotecă
- Linie
- Listă
- listare
- înregistrări
- local
- locaţie
- Locații
- Lung
- cautati
- maşină
- masina de învățare
- Masini
- major
- Efectuarea
- administrare
- Piață
- Raport de piață
- piaţă
- pieţe
- Mass-media
- Metrici
- milion
- milioane
- Misiune
- ML
- model
- Modele
- luni
- cele mai multe
- național
- noua piaţă
- Presă
- noduri
- numere
- promoții
- on-line
- piața online
- Avize
- optimizare
- Opțiune
- Opţiuni
- comandă
- Altele
- Proprietarii
- Asociere
- Plătește
- oameni
- performanță
- platformă
- Punct de vedere
- posibil
- putere
- puternic
- Predictii
- preţ
- Problemă
- probleme
- proces
- producere
- Produse
- proiect
- Proiecte
- promițător
- proprietate
- public
- Editare
- Trimestru
- întrebare
- repede
- radio
- Imobiliare
- rezonabil
- relaţie
- eliberaţi
- Renumit
- Închiria
- raportează
- Rapoarte
- responsabil
- REZULTATE
- revizuiască
- Camere
- rotund
- runde
- Alerga
- funcţionare
- Rural
- Zone rurale
- sare
- Om de stiinta
- sdk
- Caută
- sens
- Servicii
- set
- instalare
- semnificativ
- asemănător
- simplu
- Mărimea
- mic
- So
- Software
- soluţii
- REZOLVAREA
- ceva
- Spaţiu
- spații
- petrece
- împărţi
- Sportul
- răspândire
- pătrat
- Etapă
- început
- statistic
- stoc
- bursa de valori
- depozitare
- strategii
- puternic
- Reușit
- superior
- a sustine
- Suportat
- Sprijină
- surpriză
- Ţintă
- echipă
- Tehnic
- tehnici de
- Tehnologii
- test
- terț
- Prin
- timp
- împreună
- atingeţi
- Pregătire
- Tranzacții
- Transforma
- tv
- înţelege
- us
- utilizare
- utilizatorii
- valoare
- Vizualizare
- Ce
- în
- de lucru
- fabrică
- valoare
- an
- ani