Pricing Engine — ML-alapú árajánlás

Hétfő reggel, 8:40. Dániel a szokásos ár-revíziós rutinját futtatja az árazási naptárban. A legtöbb nap rendben — aztán megáll október 15-nél. Csütörtök, 24 nappal az érkezés előtt. A javasolt ár: 132 EUR.

A zsigeri száma 118 lenne. Tavaly ilyenkor ez a csütörtök 114 EUR-on ment el, az idei árszint nagyjából 3-4%-kal magasabb — 114 × 1,035 ≈ 118. Kerek, kényelmes, védhető szám. A 132 ehhez képest +12%. „Nem túl agresszív ez?”

Két lehetősége van: elfogad vagy felülbírál. És mindkettő lehet hibás döntés. Ha vakon elfogad egy rossz ajánlást, a rendszer hibáját teszi a magáévá. Ha reflexből felülbírál egy jó ajánlást, pontosan azt a többletet dobja ki, amiért az ár-ajánló rendszert egyáltalán bevezette.

Ez a lecke erről a feszültségről szól: miből lesz egy ML-alapú (machine learning — gépi tanulás) árajánlás, hogyan olvasd, mikor fogadd el, és mikor bíráld felül. A 132 vs. 118 esetet a lecke végére teljesen szétszedjük — és Dániel döntését is látni fogod, az eredménnyel együtt.

A harmadik lépcső — a szabálytól a tanuló modellig

Az árazási módszertanban eddig két lépcsőt jártunk végig:

• 35. lecke — szabály-alapú: IF-THEN logika („ha 14 napon belül 85% felett a foglaltság → BAR +15%”). Átlátható és kontrollálható — de merev: kemény küszöbök (a 69% és a 71% között drasztikus ugrás), szegmens-vakság, és a szabálykészlet elavul, ha senki nem gondozza.
• 36. lecke — elastic demand: az árrugalmasság közgazdasági modellje. Már adat-vezérelt — kiszámolja a bevétel-maximális ár-pontot —, de a rugalmasság mérése a gyakorlatban nehéz: a változók összemosódnak (esemény + kampány + compset-mozgás egyszerre), és az érzékenység időben is változik.

Az ML-alapú árajánlás a harmadik lépcső. A döntő különbség: a modell nem egy előre felírt képletet alkalmaz, hanem a hotel historikus kimeneteiből tanul mintázatot — abból, hogy a múltban milyen jel-együttállások után milyen pickup és milyen realizált ár következett.

Ennek két következménye van, és mindkettő fontos.

1. A modell jel-kombinációkban gondolkodik, nem izolált jelekben. A „gyors pickup ÉS esemény a városban ÉS a compset még nem árazta be” együttállás más árat kíván, mint bármelyik jel önmagában. A szabály-alapú rendszerben ehhez minden kombinációra külön szabály kellene — kombinatorikus robbanás, pontosan az a „túl sok szabály” csapda, amelyet a 35. leckében láttál. Az elaszticitás-modellben ugyanez összemosódásként jelenik meg. Az ML-modell viszont éppen az együttállásokból tanul — nem-lineáris összefüggéseket is megfog (például azt, hogy az esemény-jel hatása másképp skálázódik magas és alacsony OTB mellett).

2. A válasz folytonos, nem lépcsős. Nincs 70%-os küszöb, amely alatt semmi nem történik, felette pedig +8%. A 69%-os és a 71%-os foglaltság közel azonos ajánlást ad — az ár-pálya sima.

És mit adsz fel cserébe? A közvetlen átláthatóságot. A 35. lecke szabályánál ránézésre látod, melyik szabály aktiválódott. Az ML-modellnél a „miért ennyi?” kérdésre nem elég egy sor a szabálytáblából. Ezért lesz a lecke egyik központi témája a magyarázhatóság — mert egy ajánlás, amelyet nem tudsz megindokolni, a gyakorlatban használhatatlan: sem Ádámnak nem tudod megvédeni, sem magadnak nem tudod eldönteni, bízhatsz-e benne.

Miből tanul a modell — az input-jelek

Az ML-szakzsargon a modell bemeneti jeleit feature-nek (jellemzőnek) hívja. Egy hotel-árazási modell tipikus feature-készlete pontosan azokból a jelekből áll, amelyeket a képzés korábbi leckéiben egyenként megtanultál olvasni:

Két megjegyzés a táblához.

Először: egy fejlett ár-ajánló modell további jeleket is használhat — időjárás-előrejelzést (city-hotelben mérsékelt, resort- és strand-üzletben erős jel), keresési és denial-adatokat a booking engine-ből (hányan kerestek és nem foglaltak — a 39. és 42. leckében láttad, miért arany ez), légi- és vasúti forgalmi adatokat. Az elv ugyanaz: minden jel, amely a keresletről korábban árulkodik, mint maga a foglalás, értékes feature.

Másodszor: a jelek nagy részét te magad is látod a Peaqplus árazási naptárában, az ajánlás mellett, soronként — a nap forecastját, foglaltságát és pickup-irányát, az eseményeket, az éjszaka aktiválódott riasztásokat, a versenytárs-átlagot (lenyitható részletekkel: melyik tartózkodásból jött ki egy versenytárs napi minimum-ára, és milyen alternatív ajánlatai vannak csatornánként). Ez nem véletlen: az ajánlás és a mögötte lévő jelek egy felületen élnek, hogy az ellenőrzés ne külön kutatómunka legyen. Erre épül Dániel rutinja is — mindjárt látni fogod.

Az output olvasása — javasolt ár, bizonytalanság, indoklás

Az ajánlás legláthatóbb része a javasolt BAR (Best Available Rate — legjobb elérhető ár): egy szám az adott napra, szobatípusra, árkategóriára. De egy érett ár-ajánló outputja ennél több, és RM-ként mindhárom rétegét olvasnod kell.

1. A javasolt ár. A modell szerint a bevétel-optimumhoz legközelebbi ár-pont — a 36. lecke bevétel-maximalizálási logikája, csak most nem egyetlen rugalmasság-számból, hanem a teljes jel-készletből számolva.

2. A bizonytalanság. A 36. leckében találkoztál a konfidencia fogalmával: egy érett rendszer az ajánlás mellé a bizonytalanságát is kifejezi — konfidencia-sáv („132 EUR, tartomány 126–140”) vagy a javaslat erősségének jelzése formájában. Így olvasd: szűk sáv = a múltban sok hasonló együttállás volt, és azok konzisztens kimenetre vezettek — az ajánlás erős. Széles sáv = kevés az analóg adat, vagy az analóg napok kimenete szórt — az ajánlás gyenge, és a te szakértői ítéleted súlya nagyobb. A bizonytalanság nem a modell hibája, hanem az őszintesége: 100%-os konfidencia nem létezik, és ami annak mutatja magát, abban ne bízz.

3. Az indoklás. A jó kérdés soha nem az, hogy mennyit javasol a modell, hanem hogy miért ennyit. És itt jön a klasszikus vád: „az ML fekete doboz — senki nem tudja, mi történik benne.” A válasz: az egyes belső súlyokat valóban nem látod, de az ajánlás dekomponálható a fő hajtóerőire — egy semleges bázis-árra és az egyes jelek hozzájárulására. „A compset −4%-ot mozgott, de a pickup 83%-kal gyorsabb a hasonló napokénál, és esemény-átfedés van” — ez már nem fekete doboz, hanem érvelés, amelyet meg tudsz ítélni. RM-ként ezt a dekompozíciót követeld meg: vagy a rendszer mutatja meg, vagy — ahogy Dániel csinálja — magad rakod össze öt perc alatt a naptár jeleiből. Ajánlás indoklás nélkül nem döntéstámogatás, hanem orákulum.

A 132 boncolása — a számpélda

Vissza október 15-höz. Szedjük szét az ajánlást úgy, ahogy egy magyarázható modell dekompozíciója mutatná.

A helyzet (T-24, azaz 24 nappal az érkezés előtt):

• Hotel Peaqplus City, 80 szoba. OTB: 46 szoba = 57,5%.
• A hasonló napok (őszi csütörtökök) átlaga ugyanennél a lead-time-nál: 45% — a nap +12,5 százalékponttal előrébb tart.
• Pickup az utolsó 7 napban: +11 szoba; a hasonló napok átlaga: +6 — 83%-kal gyorsabb.
• Compset-átlag: az utolsó héten −4%-ot mozdult lefelé.
• Esemény-naptár: október 14–16., háromnapos szakmai konferencia a városban, közepes méretű.

A dekompozíció — a semleges bázistól a 132-ig:

Figyeld meg a feszültséget a jelek között: a compset lefelé húz, a pickup és az esemény felfelé. Egy compset-követő reflex (44. lecke) itt árat csökkentene. A modell viszont azt tanulta a múltból, hogy amikor a saját pickup gyorsul ÉS esemény-átfedés van, a compset-mozgás követése bevételt hagy az asztalon — valószínűleg a versenytársak még nem árazták be a konferenciát, vagy más vendégkört céloznak. Ez az a jel-kombináció, amelyet sem a 35. lecke szabálya, sem Dániel horgonyzott reflexe nem fog meg.

És honnan jött Dániel 118-a? Tavalyi ár + inflációs korrekció. Vagyis a zsigeri szám egyetlen feature-ből dolgozik: a tavalyi árból. Nem látja az idei pickup-többletet, nem látja a konferenciát, nem látja az OTB-előretartást. A 44. leckében láttad az ARI-tanulságot: a horgonyzott reflex kompresszióban szisztematikusan alul-áraz — nem azért, mert az RM rossz, hanem mert a reflex definíció szerint a múlt átlagát ismétli, a modell pedig az aktuális együttállást olvassa.

Dániel ellenőrzési rutinja

Dániel nem fogadja el vakon a 132-t — de nem is bírálja felül reflexből. Öt percet szán az ellenőrzésre, és mindig ugyanazt az öt kérdést teszi fel:

1. Valós-e a pickup? Megnyitja a nap trend-grafikonját: a +11 szoba nem egyetlen csoport-foglalás torzítása-e. (Nem az — 9 különböző, 1-2 szobás foglalás.)
2. Valós-e a compset-jel? A versenytárs-átlag lenyitásával megnézi, melyik tartózkodásból jött az egyes versenytársak minimum-ára — a −4%-ot nem egyetlen kilógó, hosszú tartózkodásos akciós ajánlat húzza-e le. (Két versenytárs mozdult ténylegesen, a többi áll.)
3. Valós-e az esemény? A konferencia tényleg átfedi-e a dátumot, és mekkora. (Igen — a fő nap éppen 15-e.)
4. Mit mond a forecast? A várható zárás konzisztens-e az emeléssel. (90% felett — igen.)
5. Mit mondanak a szomszéd napok? A 48. lecke day-by-day szemlélete: a 132 nem lóghat ki indokolatlanul a szerda–péntek sávból, és ha a csütörtök kompressziós, a LOS-kérdést is fel kell tenni (42. lecke) — kell-e restrikció, vagy elég az ár. (A szerda 118-on, a péntek 125-ön áll — a csütörtöki csúcs az esemény miatt indokolt; restrikció nem kell, a konferencia-vendég eleve 2-3 éjszakás.)

Minden kérdésre konzisztens a válasz. Dániel elfogadja a 132-t.

Az eredmény — utólag

Mi történt volna a 118-cal? A modell a 132-es áron a hátralévő 24 napra ~28 további szoba foglalást várt. A konferencia-súlyos kereslet-mix viszonylag rugalmatlan — E ≈ −0,6, a 36. lecke logikájával: a 118 a 132-höz képest −10,6% ár, ami +6,4% keresletet hozna, azaz 28 helyett ~30 szobát.

A különbség: +156 EUR (+4,4%) a modell javára — egyetlen napon, egyetlen szobatípuson, egyetlen döntésen. A tény: a nap 74 szobán (92,5%) zárt, és az utolsó három hét foglalásai átlagosan 131 EUR-on érkeztek — a modell jól olvasta a kompressziót. A +156 EUR önmagában nem sok. De egy 80 szobás hotel évi 365 ár-döntésén ugyanez a néhány százalékos él az, amiből az ár-ajánló rendszer üzleti esete összeáll.

Az override-fegyelem — mikor bíráld felül, és mikor ne

Az override (felülbírálás — a javasolt ár kézi módosítása) nem bűn. A javaslat javaslat, nem parancs — az RM te vagy, nem a rendszer. De az override-nak fegyelme van, és ez a lecke talán legfontosabb gyakorlati üzenete.

Bíráld felül, ha olyan információd van, amely a modellben nincs. Ez az 51. lecke kerete: az ember ott ver gépet, ahol az adat még nem tart. Példák:

• Tudod, hogy a konferencia fő szálloda-blokkja a versenytársnál van lekötve — és most mondták le. A modell ezt legkorábban a pickupból látná, napokkal később.
• Egy 20 szobás tentative csoport-opció ül a dátumon, és a döntés e héten esedékes.
• Renoválás miatt 8 szoba kiesik — a tényleges kapacitás más, mint amit a modell lát.
• A sales-csapat éppen árajánlatot adott egy sorozat-üzletre pontosan erre az időszakra.

Ne bíráld felül, ha az egyetlen érved a zsigeri szám. „Nekem a 118 a kényelmes” — ez nem információ, hanem megszokás. A 44. lecke ARI-tanulsága kíméletlen volt ezzel kapcsolatban: a reflex-árazás szisztematikus, egy irányba mutató hibát termel — kompresszióban lefelé. Ha a modell és a reflexed eltér, és az ellenőrző rutin (a fenti öt kérdés) nem talál hibát a jelekben, akkor jó eséllyel a reflexed a hibás fél.

És a döntő elem: naplózz és értékelj. Minden ár-döntésnél rögzüljön, hogyan született — a Peaqplus árazásában minden mentett árnál eltárolódik, hogy az automatika állította-e be, a javaslatot fogadtad-e el, felülbíráltad-e, vagy tisztán kézi ár volt. Ez a hónap végi kiértékelés nyersanyaga: ki nyert — te vagy a gép? Vedd elő a felülbírált napokat, és nézd meg utólag a kimenetüket az elfogadott napokéval szemben:

• Ha az override-jaid szisztematikusan jobbak egy adott helyzet-típusban (például csoport-nehéz időszakokban) → a modell ott vak valamire; ez kalibrálási visszajelzés — jelezd.
• Ha szisztematikusan rosszabbak → a reflexed drágább, mint hitted; a következő hasonló napon ez legyen előtted.

A tanulás kétirányú: a modell a te override-jaidból is tanulhat, te a modell találati arányából. A 61. leckében (A/B testing) ezt a kiértékelést formalizáljuk kísérletté, a 64. leckében (Decisions és Revenue Track) pedig a döntés-nyomkövetés teljes rendszerét építjük fel.

Egy utolsó guardrail: a 35. lecke BAR-floor és BAR-ceiling elve az ML-rétegben is él. A modell javasolhat bármit — a 85 EUR-os padló (brand-védelem) és a 350 EUR-os plafon kemény határ marad, amelyet ajánlás nem léphet át.

Egy kézben — az ajánlás a nap kontextusában él

Végül a hely. Az ML-ajánlás nem külön riportban vagy exportban él, hanem a nap-szintű árazási felületen — abban a DCAL-rácsban (demand calendar: day-class × kategória × LOS), amelyet a 33-34. leckében felépítettünk, és amelyet a Peaqplusban a Pricing Map kezel. Ez tudatos: az árajánlást a nap kontextusában validálod (48. lecke), ahol egy nézetben van a javaslat, a forecast, a foglaltság, a versenytárs-átlag és a szomszéd napok — és ugyanott van a kezedben a LOS-eszköztár is (MLOS, CTA, CTD — 42. lecke), mert a kompressziós napra adott válasz gyakran ár és restrikció együtt.

A napi rutin a 35. leckéből ismerős, csak a javaslat lett okosabb mögötte: reggel átnézed a kiugró napokat, és az elfogadott ár a channel manageren keresztül negyedórán belül élesedik minden csatornán. Ha a hotel az automatikus árazást is engedélyezi, a rendszer a javasolt árakat magától alkalmazza — a kézzel zárt időszakok kivételével, ahol a kormány visszakerül hozzád. Az érett munkamegosztás: automata a csendes zónában, RM-figyelem a kiugró napokon — a gép skálázza azt, amire nem érdemes emberi percet költeni, te pedig oda teszed az idődet, ahol az ítélőképesség a szűk keresztmetszet.

A kirakós utolsó két darabja: az előző leckében (55. Smart Forecast Enhanced) a keresleti előrejelzést tettük rendbe — a forecast a keresleti képet adja, az ár-ajánló az ár-oldali választ; a kettő ugyanannak az éremnek a két oldala. A következő lecke (57. RM és adatminőség) pedig arról szól, ami mindkettő alatt van: a modell csak annyira jó, amennyire az adat, amelyből tanul. A 132-es ajánlás mögött ott a feltevés, hogy a pickup-adat pontos, az esemény-naptár karbantartott, a compset-ár friss. Ha ez nem áll, a legjobb modell is magabiztosan téved.

Kulcsüzenetek

• Az ML-alapú árajánlás a harmadik lépcső a szabály-alapú (35. lecke) és az elaszticitás-modell (36. lecke) után: sok jel együttes mintázatából tanul, historikus kimenetekkel kalibrálva — kombináció-érzékenységet és folytonos ár-pályát nyersz, a közvetlen átláthatóságot adod fel.
• Az input-jelek (feature-ök) ismerősek: OTB-pozíció, pickup-sebesség, lead-time, nap-típus, esemény-naptár, compset-árak, hasonló napok — a modell ereje nem új jelekben van, hanem az együttállásaik olvasásában.
• Az output három rétege: javasolt BAR + bizonytalanság (konfidencia) + indoklás. A „fekete doboz” vádra a válasz a dekompozíció: az ajánlás visszabontható egy semleges bázisra és a fő jelek hozzájárulására — a példában 112 + 13 + 9 + 8 − 6 − 4 = 132 EUR. Ezt RM-ként követeld meg.
• Override-fegyelem: felülbírálni akkor szabad, ha olyan információd van, amely a modellben nincs — a zsigeri szám önmagában nem érv, mert a horgonyzott reflex kompresszióban szisztematikusan alul-áraz (44. lecke). Minden döntés naplózva, havonta kiértékelve: ki nyert, te vagy a gép?
• Az ajánlás a nap-szintű felületen él (a 33-34. lecke DCAL-rácsa, a Peaqplusban a Pricing Map): ott validálod a nap kontextusában, a LOS-restrikciókkal egy kézben — automata a csendes napokon, RM-figyelem a kiugrókon, floor/ceiling védelem (85/350 EUR) mindenek felett.