Kérdezze meg egy operatív igazgatót, mennyi volt a kapacitáskihasználása múlt kedden, és általában két válasz egyikét kapja. Vagy azt, hogy „ezt majd össze kell szednem”, vagy egy számot, amely aztán ellentmond egy másik rendszerből származó másik számnak.
Ez nem jelentési probléma. Strukturális, és érdemes pontosan megérteni, miért.
Az adat létezik. Csak nem egyezik önmagával.
Egy közepes méretű működés jellemzően öt és tizenöt közötti rendszeren fut. Egy műszaktervező eszköz. Egy munkaidő-nyilvántartó rendszer. Valami az eszközökhöz vagy gépjárművekhez. Egy karbantartási napló. Néhány táblázat, amelyek csendben teherviselővé váltak. Egyre gyakrabban egy szkenner- vagy szenzoradat-forrás, amely olyan eseményeket generál, amelyeket még soha senki nem lekérdezett.
Ezek mindegyike önmagában rendben van. A gond akkor kezdődik, amikor egy olyan kérdésre próbál választ adni, amely kettő közülük metszi egymást.
Tegyük fel, tudni szeretné, egy adott műszakmintázat okoz-e túlfutást. A műszakok a műszaktervező rendszerben élnek. A túlfutások az operatív naplóban. Az összekapcsolásukhoz tudnia kell, hogy a 4471-es dolgozó az egyik rendszerben T-4471 a másikban, hogy az egyik helyi időt rögzít, a másik UTC-t, és hogy a „műszak vége” egy helyen a tervezett véget jelenti, a másikon a tényleges kilépést.
Ezt senki nem írta le. A havi jelentést készítő ember fejében él, aki kézzel csinálja, és másfél napig tart neki.
Ez a széttagolt operatív adatok valódi ára. Nem a tárolás, nem a licencek — hanem az, hogy minden rendszereken átívelő kérdéshez emberi fordítóra van szükség.
Miért nem elég a szokásos megoldás
Az ösztönös lépés egy adattárház építése: minden adatot egyetlen adatbázisba vezetni, ráállítani egy BI-eszközt, kész.
Ezt meg kell tennie. Csak éppen nem fejezi be a munkát — egy olyan okból, amely sok csapatot meglep.
Egy adattárház a tárolást egyesíti. Nem a jelentést egyesíti.
A csővezetékek megépítése után mind a tizenegy rendszer táblái egy helyen vannak — de még mindig tudnia kell, hogy az emp_id és a staff_ref ugyanaz a személy, hogy a duration_min egy forrásban kizárja a szüneteket, egy másikban tartalmazza őket, és hogy három különböző táblának van egy status nevű oszlopa három egymással semmilyen kapcsolatban nem álló értékkel.
Így csak áthelyezte a fordítási problémát, nem oldotta meg. Korábban egy emberben élt; most egy növekvő halom transzformációs logikában él, amelyet egyetlen mérnök ért. Amikor egy forrásrendszer megváltoztat egy mezőt, valami lejjebb csendben elromlik, és három héttel később veszi észre, amikor egy szám gyanúsan néz ki.
Mi is valójában a szemantikai réteg
A hiányzó darab egy olyan réteg, amely az adattal együtt jelentést is hordoz.
Konkrétan: egy dur_2 nevű oszlopot tartalmazó tábla helyett van egy definiált fogalma — a feladat időtartama —, amely tudja, hogy percben mérik, hogy kizárja a szüneteket, hogy ebből a két forrásból származik, így összeegyeztetve, és hogy egy feladathoz tartozik, amely egy személyhez és egy helyszínhez tartozik.
Amint ez létezik, egyszerre több dolog is egyszerűbbé válik.
A gyakorlatban
- Metrikánként egy definíció, a modellel együtt verziókövetve.
- A kapcsolatok és a granularitás egyszer deklarálva, nem minden lekérdezésben újra felfedezve.
- A természetes nyelvű kérdések ismert fogalmakra futnak, nem megtippelt oszlopokra.
A kérdésekhez már nincs szükség fordítóra. A „mutasd a feladatok időtartamát műszakmintázat szerint” anélkül oldódik fel, hogy bárkinek emlékeznie kellene, melyik rendszer mit tartalmaz.
A forrásváltozások már nem törnek el csendben semmit. A leképezés egy helyen van deklarálva, nem lekérdezésekbe szórva.
És — amit a legtöbben alábecsülnek — egy nyelvi modell valóban hasznossá válik. Ezen érdemes elidőzni, mert itt bukik el csendben sok „AI a működéshez” projekt.
Miért fontos ez minden beszélgetőalapú megoldáshoz
Ha egy nyelvi modellt nyers operatív táblákra irányít, magabiztosan fog rossz válaszokat adni. Nem azért, mert a modell rossz, hanem mert nincs módja megtudni, hogy a status = 3 azt jelenti, hogy „vezető által törölve”, vagy hogy egy tábla duplán számolja a sorokat egy elavult szinkronizálás miatt.
Nincs hozzáférése a jelentéshez, így tippel. Egy operatív kontextusban egy hitelesnek tűnő, de rossz szám rosszabb, mint egyáltalán nem kapni választ.
Adjon ugyanennek a modellnek egy szemantikai réteget, és a feladata teljesen megváltozik. Már nem kell kikövetkeztetnie, mit jelent egy oszlop — egy definiált fogalmat és annak kapcsolatait keresi ki. A „hány feladat futott túl tegnap” egy ismert túlfutás-definícióra épülő keresés lesz, nem improvizáció.
Ez a különbség egy chatbot, amely le tudja kérdezni az adatbázisát, és egy olyan rendszer között, amelyre rábízná egy műszakvezetőt a műszak közepén.
A sorrend, amely működik
Ha tizenegy rendszerről és egy havi táblázatról indul, a sorrend fontosabb, mint az eszközkészlet.
1. Először a kérdéseket válassza ki. Nem az, hogy „milyen adatunk van”, hanem az, hogy „mit kell folyamatosan tudnunk, és nem tudunk gyorsan megválaszolni?” Három vagy négy kérdés elegendő. Megmutatják, mely források fontosak valójában, és megakadályozzák, hogy egy szép adattárházat építsen, amelyet senki nem kérdez le.
2. Csak azokat a forrásokat vonja be, amelyekre ezekhez a kérdésekhez szükség van. Álljon ellen a teljesség csábításának. Egy csővezeték, amelyet nem használ, minden forrásváltozáskor karbantartási költséget jelent.
3. Definiálja a fogalmakat, mielőtt megépítené az irányítópultokat. Ezt a lépést mindenki kihagyja. Írásban megegyezni arról, mit jelent a feladat időtartama, osztályok között, nem csillogó, és néha viták forrása — és ez az, amitől minden utána következő dolog működik.
4. Tartsa automatikusan frissen. Egy adatállomány, amelyet valaki azért frissít, mert eszébe jut lefuttatni valamit, pontosan akkor lesz elavult, amikor a legfontosabb lenne.
5. Csak ezután tegyen rá felületet. Irányítópultok, természetesnyelvű lekérdezés, vagy mindkettő. Ezt tegye utolsóként. Egy felület nem definiált adat felett csak gyorsabban terjeszti a zavart.
Hol illik be az OptiControl
Ez az a réteg, amelynek az OptiControlt szántuk. Operatív rendszereket kapcsol egyetlen, ügyfelenkénti adatbázisba, tartalmazza azokat a definíciókat, amelyek jelentést adnak az adatnak, és ütemezett feladatokkal — nem manuális frissítésekkel — tartja frissen.
Minden más alatt van, amit csinálunk, és ez szándékos. Az optimalizálás csak annyira jó, mint a bemenetei — egy ütemezőmotor, amely inkonzisztens időtartam-adatot kap, magabiztos, jól alátámasztott, de rossz tervet fog adni. Az adatréteg helyes kialakítása nem az érdekes munka előkészítése. Ez az, ami az érdekes munkát lehetővé teszi.
Az Optimum Intelligence optimalizációs rendszereket épít a valós működéshez — földi kiszolgáláshoz, elosztáshoz és létesítménygazdálkodáshoz. Ha az Ön operatív adatai egymással nem egyező rendszerek között szóródnak, szívesen beszélünk.