Ez Oliver Frost, az ImmoScout24 adattudósának vendégbejegyzése Lukas Müllerrel, az AWS Solutions Architectjével együttműködve.
A 2010, ImmoScout24 kiadott egy árindexet a németországi lakóingatlanokra: az IMX. Az ImmoScout24 listákon alapult. Az ár mellett a listák általában sok konkrét információt tartalmaznak, mint például az építési év, a telek mérete vagy a szobák száma. Ez az információ lehetővé tette számunkra egy úgynevezett hedonikus árindex felépítését, amely figyelembe veszi az ingatlan sajátosságait.
Amikor kiadtuk az IMX-et, az volt a célunk, hogy ez legyen a németországi ingatlanárak standard indexe. A 2008-as pénzügyi válság óta azonban nehezen tudta megragadni a német ingatlanpiaci áremelkedést. Ráadásul a tőzsdeindexhez hasonlóan egy absztrakt, közvetlenül nem értelmezhető adat volt. Az IMX ezért nehezen érthető volt a nem szakértők számára.
Az ImmoScout24-nél az a küldetésünk, hogy egyszerűvé tegyük az összetett döntéseket, és rájöttünk, hogy ennek megvalósításához új koncepcióra van szükségünk. Egy másik index helyett úgy döntöttünk, hogy egy mindenki számára könnyen érthető piaci jelentést készítünk: a WohnBarometert. Adatainkon alapul, és figyelembe veszi az objektum tulajdonságait. A legfontosabb különbség az IMX-hez képest az, hogy a WohnBarometer euróban és négyzetméterenként mutatja a bérleti és eladási árakat adott lakóingatlantípusokra az idő függvényében. A számadatok tehát közvetlenül értelmezhetők, és lehetővé teszik ügyfeleink számára, hogy válaszoljanak olyan kérdésekre, mint például: „Túl sok bérleti díjat fizetek?” vagy „Elfogadható áron van a lakás, amit vásárolni készülök?” vagy „A régiómban melyik város a legígéretesebb befektetés szempontjából?” Jelenleg a WohnBarometer Németország egészére, a hét legnagyobb városra és váltakozó helyi piacokra vonatkozik.
A következő grafikon egy példát mutat a WohnBarometerre, a berlini eladási árakkal és a negyedéves fejlődéssel.
Ez a bejegyzés azt tárgyalja, hogyan használta az ImmoScout24-et Amazon SageMaker a WohnBarometer modelljének elkészítéséhez, hogy ügyfeleink számára releváns legyen. Megtárgyalja az alapul szolgáló adatmodellt, a hiperparaméterek hangolását és a műszaki beállításokat. Ez a bejegyzés azt is bemutatja, hogy a SageMaker hogyan támogatott egy adatkutatót a WohnBarometer 2 hónapon belüli elvégzésében. Egy egész csapatnak 2 évbe telt az IMX első verziójának kifejlesztése. A WohnBarometer számára nem volt lehetőség ilyen befektetésre.
Az ImmoScout24-ről
Az ImmoScout24 a lakó- és kereskedelmi ingatlanok vezető online platformja Németországban. Az ImmoScout20 több mint 24 éve forradalmasítja az ingatlanpiacot, és havonta több mint 20 millió felhasználót támogat online piacterén vagy alkalmazásában, hogy új otthonokat vagy kereskedelmi helyiségeket találjanak. Éppen ezért a cél ügyfélcsoportunk 99%-a ismeri az ImmoScout24-et. Digitális megoldásaival az online piactér sikeresen koordinálja és hozza össze a tulajdonosokat, ingatlanosokat, bérlőket és vásárlókat. Az ImmoScout24 azon a célon dolgozik, hogy digitalizálja az ingatlantranzakciók folyamatát, és ezáltal megkönnyítse a bonyolult döntéseket. 2012 óta az ImmoScout24 az osztrák ingatlanpiacon is aktív, havonta mintegy 3 millió felhasználót ér el.
A helyszínitől az AWS Data Pipeline-on át a SageMaker-ig
Ebben a részben az előző beállítást és annak kihívásait tárgyaljuk, valamint azt, hogy miért döntöttünk úgy, hogy a SageMaker alkalmazást használjuk új modellünkhöz.
Az előző beállítás
Amikor 2010-ben megjelent az IMX első verziója, a felhő még mindig rejtély volt a legtöbb vállalkozás számára, beleértve az ImmoScout24-et is. A gépi tanulás (ML) területe gyerekcipőben járt, és csak egy maroknyi szakértő tudta, hogyan kell modellt kódolni (az illusztráció kedvéért a Scikit-Learn első nyilvános kiadása 2010 februárjában volt). Nem meglepő, hogy az IMX fejlesztése több mint 2 évig tartott, és hét számjegyű összegbe került.
2015-ben az ImmoScout24 megkezdte az AWS-migrációt, és átépítette az IMX-et az AWS infrastruktúrára. A mi adatainkkal Amazon egyszerű tárolási szolgáltatás (Amazon S3) Data Lake-en, az adatok előfeldolgozása és a modell betanítása is megtörtént Amazon EMR által hangszerelt klaszterek AWS Data Pipeline. Míg az előbbi PySpark ETL-alkalmazás volt, az utóbbi több Python-szkript volt, amelyek klasszikus ML-csomagokat használnak (például Scikit-Learn).
Problémák ezzel a beállítással
Bár ez a beállítás meglehetősen stabilnak bizonyult, az infrastruktúra hibaelhárítása vagy a modell javítása nem volt egyszerű. A modell fő problémája a komplexitás volt, mivel egyes komponensek önálló életet kezdtek: a kiugró értékek észlelésének kódja végül majdnem kétszer olyan hosszú volt, mint magának az IMX alapmodellnek a kódja.
Az alapmodell valójában nem egy modell volt, hanem több száz: egy modell lakóingatlan-típusonként és régiónként, a meghatározás pedig a nagyváros egyetlen negyedétől a vidéki területeken található több faluig terjed. Volt például egy modellünk Berlin közepén eladó lakásokhoz és egy München külvárosában eladó házakhoz. Mivel ezeknek a modelleknek a betanítása sok időt vett igénybe, elhagytuk a hiperparaméter-hangolást, ami valószínűleg a modellek alulteljesítéséhez vezetett.
Miért döntöttünk a SageMaker mellett
Tekintettel ezekre a kérdésekre és arra a törekvésünkre, hogy gyakorlati előnyökkel járó piaci jelentést készítsünk, döntenünk kellett, hogy a meglévő kód nagy részét átírjuk, vagy a nulláról kezdjük. Amint ebből a bejegyzésből arra következtethetünk, mi az utóbbi mellett döntöttünk. De miért a SageMaker?
Az IMX-re fordított időnk nagy részét az infrastruktúra hibaelhárítására fordítottuk, nem a modell fejlesztésére. Az új piaci jelentéshez ezt meg akartuk fordítani, a modell statisztikai teljesítményére helyezve a hangsúlyt. Azt is szerettük volna, hogy rugalmasan lehessen gyorsan cserélni a modell egyes komponenseit, például a hiperparaméterek optimalizálását. Mi van, ha megjelenik egy új, kiváló teljesítménynövelő algoritmus (gondoljunk csak arra, hogyan lépett színpadra az XGBoost 2014-ben)? Természetesen az elsők között szeretnénk örökbe fogadni!
A SageMakerben a klasszikus ML munkafolyamat fő összetevői – előfeldolgozás, betanítás, hiperparaméter-hangolás és következtetés – szépen el vannak különítve API-szinten és a AWS felügyeleti konzol. Egyenként módosítani őket nem nehéz.
Az új modell
Ebben a részben az új modell összetevőit tárgyaljuk, beleértve a bemeneti adatokat, az algoritmust, a hiperparaméterek hangolását és a műszaki beállításokat.
Beviteli adat
A WohnBarometer a Németországban található lakóingatlanok ImmoScout5 24 éves listáinak tolóablakon alapul. Miután eltávolítottuk a kiugró értékeket és a csalárd adatlapokat, körülbelül 4 millió adat maradt hátra, amelyek vonatra (60%), érvényesítésre (20%) és tesztadatokra (20%) vannak felosztva. A listák és az objektumok közötti kapcsolat nem feltétlenül 1:1; 5 év során valószínű, hogy ugyanazt az objektumot többször is beszúrják (több ember).
13 listázási attribútumot használunk, mint például az ingatlan elhelyezkedése (WGS84 koordináták), az ingatlan típusa (ház vagy lakás, eladás vagy bérlet), életkora (év), mérete (négyzetméter) vagy állapota (pl. , új vagy felújított). Tekintettel arra, hogy minden listához általában tucatnyi attribútum tartozik, felmerül a kérdés: melyiket kell belefoglalni a modellbe? Egyrészt a domain tudást használtuk; Például köztudott, hogy az elhelyezkedés kulcstényező, és szinte minden piacon az új ingatlanok drágábbak, mint a meglévők. Másrészt az IMX és hasonló modellekkel kapcsolatos tapasztalatainkra hagyatkoztunk. Ott megtudtuk, hogy több tucat attribútum felvétele nem javítja jelentősen a modellt.
A kiírás ingatlantípusától függően modellünk célváltozója vagy a négyzetméter bérleti díj, vagy az eladási négyzetméterár (később elmagyarázzuk, miért nem volt ez a választás ideális). Az IMX-től eltérően a WohnBarometer tehát egy olyan szám, amelyet ügyfeleink közvetlenül értelmezhetnek és befolyásolhatnak.
A modell leírása
A SageMaker használatakor különböző stratégiák közül választhat az algoritmus megvalósításához:
- Használja a SageMaker egyik beépített algoritmusát. Csaknem 20 van, és lefedik az összes főbb ML problématípust.
- Szabványos ML keretrendszer (például Scikit-Learn vagy PyTorch) alapján szabjon testre egy előre elkészített Docker-képet.
- Készítse el saját algoritmusát, és helyezze üzembe Docker-képként.
A WohnBarometer esetében olyan megoldást szerettünk volna, amely könnyen karbantartható, és lehetővé teszi, hogy magának a modellnek a fejlesztésére összpontosítsunk, ne az alapul szolgáló infrastruktúrára. Ezért az első lehetőség mellett döntöttünk: használjunk egy teljesen felügyelt algoritmust megfelelő dokumentációval és szükség esetén gyors támogatással. Ezután magát az algoritmust kellett kiválasztanunk. A döntés ismét nem volt nehéz: az XGBoost algoritmust választottuk, mert ez az egyik legismertebb ML algoritmus a regressziós típusú problémák megoldására, és már több projektben is sikeresen alkalmaztuk.
Hiperparaméter hangolás
A legtöbb ML algoritmus számtalan módosítandó paraméterrel rendelkezik. A boosting algoritmusok például számos paramétert tartalmaznak, amelyek meghatározzák a fák pontos felépítését: A fáknak legfeljebb 20 vagy 30 levele van? Minden fa az összes soron és oszlopon alapul, vagy csak mintákon? Milyen erősen kell metszeni a fákat? Ezen paraméterek optimális értékének megtalálása (amelyet az Ön által választott kiértékelési metrika mér), az úgynevezett hiperparaméter-hangolás kritikus fontosságú egy hatékony ML-modell felépítéséhez.
A hiperparaméter-hangolás kulcskérdése az, hogy mely paramétereket hangoljuk, és hogyan állítsuk be a keresési tartományokat. Felmerülhet a kérdés, miért nem ellenőrzi az összes lehetséges kombinációt? Bár elméletben ez jó ötletnek hangzik, óriási hiperparaméter-teret eredményezne, túl sok ponttal ahhoz, hogy mindezt ésszerű áron értékeljük. Ez az oka annak, hogy az ML gyakorlói jellemzően kis számú hiperparamétert választanak ki, amelyekről ismert, hogy erősen befolyásolják a választott algoritmus teljesítményét.
A hiperparamétertér meghatározása után a következő feladat a legjobb értékkombináció megtalálása benne. Általában a következő technikákat alkalmazzák:
- Rács keresés – Oszd fel a teret egy diszkrét rácsra, majd értékeld ki a rács összes pontját keresztellenőrzéssel.
- Véletlenszerű keresés – Véletlenszerűen rajzoljon kombinációkat a térből. Ezzel a megközelítéssel nagy valószínűséggel hiányozni fog a legjobb kombináció, de ez jó viszonyítási alapként szolgál.
- Bayesi optimalizálás – Készítse el a célfüggvény valószínűségi modelljét, és használja ezt a modellt új kombinációk létrehozásához. A modell minden egyes kombináció után frissül, ami gyorsan jó eredményekhez vezet.
Az elmúlt években az olcsó számítási teljesítménynek köszönhetően a Bayes-féle optimalizálás aranystandard lett a hiperparaméter-hangolásban, és ez az alapértelmezett beállítás a SageMakerben.
Műszaki beállítás
Sok más AWS-szolgáltatáshoz hasonlóan SageMaker-feladatokat hozhat létre a konzolon, a AWS parancssori interfész (AWS CLI), vagy kódon keresztül. A harmadik lehetőséget választottuk, pontosabban a SageMaker Python SDK-t, mert ez nagymértékben automatizált beállítást tesz lehetővé: a WohnBarometer egy Python szoftverprojektben él, amely parancssori futtatható. Például az ML folyamat összes lépése, mint például az előfeldolgozás vagy a modell betanítás, elindítható Bash parancsokkal. Ezeket a Bash parancsokat viszont egy Jenkins-csővezeték hajtja végre AWS Fargate.
Nézzük a lépéseket és a mögöttes infrastruktúrát:
- Előfeldolgozás – Az előfeldolgozás a SageMaker beépített Scikit-Learn könyvtárával történik. Mivel ez magában foglalja a több millió sorból álló adatkeretek összekapcsolását, itt egy ml.m5.24xnagy gépre van szükségünk, amely a legnagyobb, amit az ml.m családban kaphat. Alternatív megoldásként több kisebb gépet is használhattunk volna olyan elosztott keretrendszerrel, mint a Dask, de a lehető legegyszerűbben akartuk tartani.
- Képzések – Az alapértelmezett SageMaker XGBoost algoritmust használjuk. Az edzés két ml.m5.12xnagy géppel történik. Érdemes megemlíteni, hogy a modellképzés kódját és a hiperparaméter-hangolást tartalmazó train.py-nk kevesebb mint 100 sorból áll.
- Hiperparaméter hangolás – A kevesebb több elvét követve csak 11 hiperparamétert hangolunk (például a boosting körök számát és a tanulási sebességet), ami időt ad arra, hogy gondosan megválasszuk a tartományukat, és megvizsgáljuk, hogyan hatnak egymásra. Mindössze néhány hiperparaméterrel minden képzési feladat viszonylag gyorsan fut; esetünkben a munkák 10-20 percet vesznek igénybe. Maximum 30 képzési feladat és 2 párhuzamos munkakör esetén a teljes képzési idő körülbelül 3 óra.
- Következtetés – A SageMaker többféle lehetőséget kínál a modell kiszolgálására. Kötegelt transzformációs feladatokat használunk, mert a WohnBarometer számokra csak negyedévente van szükségünk. Nem használtunk végpontot, mert az legtöbbször tétlen volt. Minden kötegelt feladatot (körülbelül 6.8 millió sor) egyetlen ml.m5.4xnagy gép szolgál ki, kevesebb mint 10 perc alatt.
Ezeket a lépéseket könnyen hibakereshetjük a SageMaker konzolon. Ha például egy betanítási munka a vártnál tovább tart, a következőre navigálunk Képzések oldalon, keresse meg a kérdéses képzési munkát, és tekintse át amazonfelhőóra az alapul szolgáló gépek mérőszámai.
A következő architektúra diagram a WohnBarometer infrastruktúráját mutatja be:
Kihívások és tanulságok
Kezdetben minden gördülékenyen ment: néhány napon belül beállítottuk a szoftverprojektet, és betanítottuk modellünk miniatűr változatát a SageMakerben. Nagy reményeket fűztünk a teljes adatkészlet első futtatásához és a hiperparaméter-hangoláshoz. Sajnos az eredmények nem voltak kielégítőek. A következő kulcsfontosságú problémáink voltak:
- A modell előrejelzései túl alacsonyak voltak, mind a bérelhető, mind az eladó objektumok esetében. Berlin esetében például a referenciaobjektumainkra előre jelzett eladási árak nagyjából 50%-kal voltak a piaci árak alatt.
- A modell szerint az új és a meglévő épületek között nem volt jelentős árkülönbség. Az igazság az, hogy az új épületek szinte mindig lényegesen drágábbak, mint a meglévő épületek.
- A hely árra gyakorolt hatását nem rögzítették megfelelően. Tudjuk például, hogy Frankfurt am Mainban az eladó lakások átlagosan drágábbak, mint Berlinben (bár Berlin felzárkózik); modellünk azonban fordítva jósolta meg.
Mi volt a probléma és hogyan oldottuk meg?
Mintavétel a jellemzőkből
Első pillantásra úgy tűnik, hogy a problémák nem kapcsolódnak egymáshoz, de valójában igen. Alapértelmezés szerint az XGBoost minden fát a szolgáltatások véletlenszerű mintájával épít fel. Tegyük fel, hogy egy modellnek 10 F funkciója van1, F2, … F10, akkor az algoritmus használhatja az F-et1, F4és F7 egy fára, és F3, F4és F8 másnak. Míg általában ez a viselkedés hatékonyan akadályozza meg a túlillesztést, problémát okozhat, ha a jellemzők száma kicsi, és némelyikük nagy hatással van a célváltozóra. Ebben az esetben sok fáról hiányoznak a döntő jellemzők.
Az XGBoost által a 13 jellemzőnkből mintavételezése sok fához vezetett, beleértve a kulcsfontosságú jellemzők egyikét sem – ingatlan típusa, elhelyezkedése, valamint új vagy meglévő épületek –, és ennek következtében okozta ezeket a problémákat. Szerencsére van egy paraméter a mintavétel szabályozására: colsample_bytree
(sőt, van még két paraméter a mintavétel szabályozására, de ezekhez nem nyúltunk). Amikor ellenőriztük a kódunkat, ezt láttuk colsample_bytree
0.5-re volt állítva, ez az érték a korábbi projektekből vett át. Amint az alapértelmezett 1-es értékre állítottuk, a korábbi problémák eltűntek.
Egy modell vs. több modell
Az IMX-szel ellentétben a WohnBarometer modell valójában csak egy modell. Bár ez minimálisra csökkenti a karbantartási erőfeszítést, statisztikai szempontból nem ideális. Mivel képzési adataink eladási és bérbeadási objektumokat is tartalmaznak, a célváltozó szórása óriási: egyes bérlakások esetében 5 euró alatti értéktől az első osztályú helyen eladó házaknál jóval 10,000 5 euró felettiig terjed. A modell nagy kihívása annak megértése, hogy az XNUMX eurós hiba fantasztikus az eladási tárgyaknál, de katasztrofális a bérelt tárgyaknál.
Utólag visszagondolva, tudva, milyen egyszerű több modellt karbantartani a SageMakerben, legalább két modellt építettünk volna: egyet bérelhető, egyet pedig eladásra. Ez megkönnyítené mindkét piac sajátosságainak megragadását. Például az eladó béreletlen lakások ára jellemzően 20-30%-kal magasabb, mint az eladó bérlakásoké. Ezért az információ álváltozóként való kódolása az eladási modellben nagyon logikus; a bérleti modellnél viszont elhagyhatnád.
Következtetés
Megértette a WohnBarometer azt a célt, hogy releváns legyen ügyfeleink számára? A médiavisszhangot tekintve egyértelmű igen a válasz: 2021 novemberéig több mint 700 újságcikk, valamint tévé- vagy rádióriport jelent meg a WohnBarometerről. A listán olyan országos újságok szerepelnek, mint a Frankfurter Allgemeine Zeitung, a Tagesspiegel és a Handelsblatt, valamint olyan helyi újságok, amelyek gyakran kérnek WohnBarometer-adatokat a régiójukra vonatkozóan. Mivel egyébként is Németország összes régiójára számítjuk ki a számokat, örömmel fogadjuk az ilyen kéréseket. A régi IMX-szel ilyen szintű részletesség nem volt lehetséges.
A WohnBarometer statikus teljesítményt tekintve felülmúlja az IMX-et, különösen ami a költségeket illeti: az IMX-et egy 10 feladatcsomópontból álló EMR-klaszter hozta létre, amely majdnem fél napig fut. Ezzel szemben a WohnBarometer minden lépése kevesebb, mint 5 órát vesz igénybe közepes méretű gépeken. Ez közel 75%-os költségmegtakarítást eredményez.
A SageMakernek köszönhetően kevesebb mint 2 hónap alatt egy komplex ML-modellt tudtunk gyártásba hozni egyetlen adattudóssal. Ez figyelemre méltó. 10 évvel korábban, amikor az ImmoScout24 megépítette az IMX-et, ugyanezen mérföldkő elérése több mint 2 évig tartott, és egy egész csapat bevonásával.
Hogyan lehetünk ilyen hatékonyak? A SageMaker lehetővé tette számunkra, hogy az infrastruktúra helyett a modellre összpontosítsunk, a SageMaker pedig egy könnyen karbantartható mikroszolgáltatási architektúrát hirdet. Ha elakadnánk valamiben, hívhatjuk az AWS támogatását. A múltban, amikor az egyik IMX adatfolyamunk meghibásodott, néha napokat töltöttünk a hibakereséssel. Amióta 2021 áprilisában elkezdtük közzétenni a WohnBarometer adatait, a SageMaker infrastruktúra egyetlen alkalommal sem hibázott.
Ha többet szeretne megtudni a WohnBarometerről, nézze meg WohnBarométer és a WohnBarometer: Angebotsmieten stiegen 2021 bundesweit wieder stärker an. Ha többet szeretne megtudni a SageMaker Scikit-Learn könyvtár előfeldolgozáshoz való használatáról, lásd: Előfeldolgozza a bemeneti adatokat, mielőtt előrejelzéseket készítene az Amazon SageMaker következtetési csővezetékek és a Scikit-learn segítségével. Kérjük, küldjön visszajelzést, akár a AWS fórum az Amazon SageMaker számára, vagy az AWS ügyfélszolgálati kapcsolattartóin keresztül.
A bejegyzés tartalma és véleménye a harmadik fél szerzője, és az AWS nem vállal felelősséget a bejegyzés tartalmáért vagy pontosságáért.
A szerzőkről
Oliver Frost 24-ben csatlakozott az ImmoScout2017-hez üzleti elemzőként. Két évvel később adattudós lett egy csapatban, amelynek feladata az ImmoScout24 adatok valódi adattermékekké alakítása. A WohnBarometer modell megépítése előtt kisebb SageMaker projekteket futtatott. Oliver számos AWS-tanúsítvánnyal rendelkezik, beleértve a Machine Learning Specialty-t.
Lukas Müller az AWS megoldási építésze. Ügyfelekkel dolgozik a sport-, a média- és a szórakoztatóiparban. Folyamatosan keresi a módját, hogyan ötvözze a technikai lehetőségeket a kulturális és szervezeti lehetőségekkel, hogy segítse ügyfeleit üzleti érték elérésében felhőtechnológiákkal.
- Coinsmart. Európa legjobb Bitcoin- és kriptográfiai tőzsdéje.
- Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. SZABAD HOZZÁFÉRÉS.
- CryptoHawk. Altcoin radar. Ingyenes próbaverzió.
- Forrás: https://aws.amazon.com/blogs/machine-learning/predict-residential-real-estate-prices-at-immoscout24-with-amazon-sagemaker/
- "
- 000
- 100
- 11
- 20 év
- 2021
- Rólunk
- Fiók
- aktív
- algoritmus
- algoritmusok
- Minden termék
- már
- Bár
- amazon
- elemző
- Másik
- api
- app
- Alkalmazás
- megközelítés
- április
- építészet
- körül
- cikkek
- Automatizált
- átlagos
- AWS
- válik
- Kezdet
- hogy
- benchmark
- Előnyök
- BEST
- Legnagyobb
- fellendítése
- épít
- Épület
- épít
- beépített
- üzleti
- vállalkozások
- megvesz
- hívás
- Kaphat
- okozott
- tanúsítványok
- kihívás
- kihívások
- városok
- Város
- felhő
- kód
- kombináció
- kombinációk
- kereskedelmi
- bonyolult
- Kiszámít
- koncepció
- feltétel
- úgy véli,
- Konzol
- építés
- tartalmaz
- tartalom
- ellenőrzés
- Mag
- kiadások
- tudott
- válság
- kritikus
- Ügyfelek
- dátum
- adattudós
- nap
- telepíteni
- Érzékelés
- Fejleszt
- Fejlesztés
- DID
- különböző
- digitális
- megvitatni
- megosztott
- Dokkmunkás
- Nem
- domain
- könnyen
- hatás
- hatékony
- Endpoint
- hatalmas
- Szórakozás
- létrehozni
- birtok
- Euro
- mindenki
- minden
- példa
- várható
- Tapasztalatok
- szakértők
- család
- GYORS
- Jellemzők
- Visszacsatolás
- Ábra
- pénzügyi
- pénzügyi válság
- vezetéknév
- Rugalmasság
- Összpontosít
- következő
- Keretrendszer
- eleget tesz
- Tele
- funkció
- általános
- generál
- Németország
- Pillantás
- cél
- Arany
- jó
- Rács
- Csoport
- Vendég
- Vendég bejegyzés
- boldog
- tekintettel
- segít
- itt
- Magas
- nagyon
- tart
- Ház
- házak
- Hogyan
- How To
- HTTPS
- hatalmas
- Több száz
- ötlet
- kép
- Hatás
- javul
- tartalmaz
- Beleértve
- Növelje
- index
- egyéni
- iparágak
- információ
- Infrastruktúra
- befektetés
- beruházás
- részt
- kérdések
- IT
- Munka
- Állások
- csatlakozott
- Kulcs
- tudás
- ismert
- nagy
- vezető
- TANUL
- tanult
- tanulás
- Led
- szint
- könyvtár
- vonal
- Lista
- felsorolás
- listák
- helyi
- elhelyezkedés
- helyszínek
- Hosszú
- keres
- gép
- gépi tanulás
- gép
- fontos
- Gyártás
- vezetés
- piacára
- Piaci jelentés
- piactér
- piacok
- Média
- Metrics
- millió
- Több millió
- Küldetés
- ML
- modell
- modellek
- hónap
- a legtöbb
- nemzeti
- New Market
- Újság
- csomópontok
- számok
- Ajánlatok
- online
- online piactér
- Vélemények
- optimalizálás
- opció
- Opciók
- érdekében
- Más
- tulajdonosok
- Létrehozása
- Fizet
- Emberek (People)
- teljesítmény
- emelvény
- Nézőpont
- lehetséges
- hatalom
- erős
- Tippek
- ár
- Probléma
- problémák
- folyamat
- Termelés
- Termékek
- program
- projektek
- biztató
- ingatlan
- nyilvános
- Kiadás
- Negyed
- kérdés
- gyorsan
- rádió
- ingatlan
- ésszerű
- kapcsolat
- engedje
- Híres
- Bérlés
- jelentést
- Jelentések
- felelős
- Eredmények
- Kritika
- Szobák
- körül
- fordulóban
- futás
- futás
- Vidéki
- Vidéki területek
- eladás
- Tudós
- sdk
- Keresés
- értelemben
- Szolgáltatások
- készlet
- beállítás
- jelentős
- hasonló
- Egyszerű
- Méret
- kicsi
- So
- szoftver
- Megoldások
- SOLVE
- valami
- Hely
- terek
- költ
- osztott
- Sport
- terjedése
- négyzet
- Színpad
- kezdődött
- statisztikai
- készlet
- részvénypiac
- tárolás
- stratégiák
- erős
- sikeresen
- felettes
- támogatás
- Támogatott
- Támogatja
- meglepetés
- cél
- csapat
- Műszaki
- technikák
- Technologies
- teszt
- harmadik fél
- Keresztül
- idő
- együtt
- érintse
- Képzések
- Tranzakciók
- Átalakítás
- tv
- megért
- us
- használ
- Felhasználók
- érték
- Megnézem
- Mit
- belül
- dolgozó
- művek
- érdemes
- év
- év