Gleb Mezhanskiy hat Jahre damit verbracht, Instruments zu entwickeln, um Unternehmensdaten sauber zu machen. Im März 2026 teilte der CEO von Datafold seinem Publikum mit, dass sich der Aufwand nie so ausgezahlt habe wie die Softwareüberwachung für Unternehmen wie Datadog. Seine Argumentation verändert nun die Definition von Qualität durch Datenführer bis in die zweite Hälfte des Jahres 2026 hinein.

Ein CEO eines Anbieters nennt die Branche eine Enttäuschung

Mezhanskiy legte den Fall in einem Beitrag vom 5. März mit dem Titel „Information Engineering im Jahr 2026: 12 Vorhersagen“ dar. Vorhersage elf argumentiert, dass Datenteams aufhören werden, der Datenqualität hinterherzujagen, weil KI-Agenten sich stattdessen um den Kontext kümmern. Er schrieb, dass jahrelange Investitionen und technische Anstrengungen nie zu einem bahnbrechenden Erfolg geführt hätten, der mit dem Aufstieg von Datadog im Bereich Software program-Überwachung vergleichbar sei. Seiner Aussage nach hat sich die Datenqualität von einem Einzelposten zu Jahreszielen zu etwas entwickelt, mit dem Groups nach besten Kräften umgehen.

Die Behauptung verdient einen Vorbehalt, bevor sie weiter verbreitet wird. Mezhanskiy leitet ein Unternehmen in einem überfüllten Umfeld, und seine Ansicht spiegelt die Sichtweise eines einzelnen Anbieters wider, nicht einen Branchenkonsens. Monte Carlo gab an, 236 Millionen US-Greenback eingeworben zu haben, während Bigeye eine Gesamtfinanzierung von 73,5 Millionen US-Greenback meldete. Datafold kündigte separat eine Serie A in Höhe von 20 Millionen US-Greenback an. Zusammen gaben die drei Unternehmen eine Finanzierung von mindestens 329,5 Millionen US-Greenback bekannt, die sich auf Qualität, Zuverlässigkeit und Beobachtbarkeit verteilte und nicht auf eine einzige Kategorie. Die Bezeichnung „Misserfolg“ hängt davon ab, welcher Maßstab verwendet wird, und Mezhanskiy wählte einen Maßstab, der seine Vorhersage begünstigt.

Warum Daten dem Software program-Playbook widerstehen

Mezhanskiys größte Stärke hat nichts mit Finanzierungsrunden zu tun. Er argumentiert, dass Daten schwieriger zu testen sind als Software program, weil sich die Grundwahrheit ständig verschiebt. Eine Anmeldung gelingt entweder oder nicht. Ein „aktiver Benutzer“ kann drei verschiedene Dinge bedeuten, je nachdem, ob Advertising and marketing, Produkt oder Finanzen danach fragen, und keine Checks auf Spaltenebene können Meinungsverschiedenheiten über Definitionen ausräumen. Fügen Sie einer verrauschten Pipeline weitere Warnungen hinzu, und der Wert jeder neuen Warnung sinkt schnell.

Der Vergleich hält als Spektrum besser als als harte Linie. Sicherheitsteams sind jeden Tag auf der Suche nach mehrdeutigen Signalen, und viele KI-gesteuerte Software program liefert Ergebnisse, die niemand mit Sicherheit überprüfen kann. Software program-Grundwahrheit ist nicht immer so sauber, wie Mezhanskiys Darstellung nahelegt. Was Daten auszeichnet, ist das Ausmaß der Mehrdeutigkeit: Ein einziges Lager kann Dutzende widersprüchlicher Definitionen für dasselbe Geschäftskonzept enthalten, und ein Softwareteam sieht sich selten am selben Nachmittag mit so vielen Abspaltungen konfrontiert.

Was KI-Agenten brauchen

Hier ist der Teil von Mezhanskiys Argumentation, der es wert ist, trotz der damit verbundenen Vorbehalte ernst genommen zu werden. Ein Agent, der aus einem Lager abruft, benötigt mehr als eine validierte Spalte. Es braucht eine Abstammung, die zeigt, woher eine Zahl stammt, die Transformationslogik dahinter, eine Dokumentation, die erklärt, warum eine Fallback-Tabelle existiert, und eine Ontologie, die Geschäftseinheiten wie Kunde, Bestellung und Produkt verbindet. Mezhanskiy nennt die Kombination einen Kontextgraphen, und Datafold verkauft nun einen solchen neben seinen herkömmlichen Qualitätstools.

Es lohnt sich direkt zu sagen: Mezhanskiy ist kein neutraler Erzähler. Sein Unternehmen profitiert, wenn Käufer ihre Ausgaben von der Qualitätsüberwachung auf die Kontextebene verlagern, die seine Vorhersage beschreibt, und der finanzielle Einsatz verschwindet nicht, nur weil das zugrunde liegende Argument vernünftig ist. Das Argument hat immer noch eine Grenze: Der Kontext hilft einem Agenten, eine Zahl richtig zu interpretieren, aber er verwandelt eine beschädigte, veraltete oder voreingenommene Zahl nicht in eine sichere Zahl. Die Abstammung teilt einem Agenten mit, woher die Daten stammen, und nicht, ob die Daten überhaupt Vertrauen verdient haben.

Wie risikobasierte Datenqualität in der Praxis aussieht

Der nützlichste Beweis in dieser Debatte ist keine Vorhersage. Es handelt sich um ein Muster, das sich bereits in der Artwork und Weise zeigt, wie Groups Datenverträge erstellen. Der von Bitol unter Apache 2.0 über die LF AI and Information Basis veröffentlichte Open Information Contract Customary definiert ein herstellerneutrales YAML-Format, das Schemata, Qualitätsregeln, Eigentumsverhältnisse, Supportkanäle und Servicelevel abdeckt. Groups verwenden den Customary, um zu formalisieren, was ein Datensatz verspricht, ohne sich an die Plattform eines Unternehmens zu binden.

Eine Handvoll Betriebsgewohnheiten trennen Groups davon, wie sie aus Verträgen Nutzen ziehen, von Groups, die Papierkram hinzufügen:

• Übertragen Sie die Verantwortung auf das Workforce, das einen Datensatz erstellt, und nicht auf das Workforce, das ihn drei Pipelines weiter unten verbraucht.
• Speichern Sie Verträge als Code in der Versionskontrolle und nicht als Folienstapel, den niemand mehr öffnet.
• Führen Sie Prüfungen im CI oder in der Pipeline selbst durch, damit ein Verstoß erkannt wird, bevor er ein Dashboard oder einen Agent erreicht.

Die Leitlinien von Monte Carlo fordern Kunden dazu auf, die Verträge schlank zu halten und sich auf Pipelines zu konzentrieren, die echtes Geschäftsgewicht tragen, und nicht auf jeden Tisch im Lager. Soda und Atlan unterstützen das gleiche Muster durch YAML-Dateien, Git-Workflows und Regeldurchsetzung und stellen ihre Instruments nicht als Anforderung dar: Beide betrachten die Automatisierung als eine Annehmlichkeit, die über einer Disziplin liegt, die ein Workforce mit einem Texteditor und einer CI-Pipeline ausführen könnte.

Der Gegenbeweis

Marktforscher unterstützen keinen Kollaps der Ausgaben für Datenqualität. Mordor Intelligence schätzt, dass der Markt für Datenqualitätstools von 3,27 Milliarden US-Greenback im Jahr 2026 auf 7,39 Milliarden US-Greenback im Jahr 2031 wachsen wird, was einer durchschnittlichen jährlichen Wachstumsrate von 17,7 Prozent entspricht. Behandeln Sie die Zahl als kommerzielle Schätzung und nicht als geprüfte Gesamtsumme. Verschiedene Forschungsunternehmen definieren die Kategorie unterschiedlich und stoßen auf nicht übereinstimmende Zahlen, was für einen derart fragmentierten Markt regular ist und mehr über inkonsistente Definitionen als über den zugrunde liegenden Pattern aussagt.

Die sicherere Lektüre lautet: Die Ausgaben steigen weiter, während die Definition von Qualität umfassender wird. Für diesen Artikel wurden keine Belege überprüft, die zeigen, dass sich die Budgets von der Qualitätsüberwachung hin zu Kontextdiagrammen verlagern. Die 2026 State of Information Engineering Survey von Joe Reis, die Ende 2025 über einen Zeitraum von zwei Wochen unter 1.101 Praktikern durchgeführt wurde, bringt eine einfache Aussage zum Ausdruck: Qualität ist bei niemandem auf der Sorgenliste gelandet. 34 Prozent der Befragten gaben an, dass die Datenqualität oder -zuverlässigkeit die Teamzeit stark belastet, und etwas mehr als zehn Prozent nannten sie den größten organisatorischen Engpass. Die Befragten sind vorwiegend in Nordamerika und Europa befragt und konzentrieren sich auf Nordamerika und Europa. Reis beschreibt die Prozentsätze als Richtwerte und nicht als endgültig. Trotz Vorbehalten deutet die Umfrage auf Groups hin, die durch Qualitätsarbeit überlastet sind, und nicht auf Groups, die sich davon abwenden.

Ein Framework zur Tiering-Datenqualität

Der praktische Schritt besteht nicht darin, sich zwischen Mezhanskiys Vorhersage und den Umfragedaten zu entscheiden. Es geht darum, damit aufzuhören, jeden Datensatz so zu behandeln, als ob er das gleiche Maß an Prüfung verdient. Ein vierstufiges Modell bietet Datenverantwortlichen einen Ausgangspunkt für die Entscheidung, wo strenge Verträge hingehören und wo eine einfachere Dokumentation sinnvoll ist.

Stufe 0 deckt Einnahmen und aufsichtsrechtlich kritische Daten ab: Abrechnungssysteme, Finanzberichts-Feeds und Compliance-Einreichungen. Jeder Datensatz erhält hier einen formellen Vertrag, automatisierte Prüfungen in CI, einen benannten Eigentümer und eine Bereitschaftsseite, wenn etwas fehlschlägt.

Stufe 1 deckt kunden- und produktkritische Daten ab: Dashboards, die Kunden direkt sehen, Kennzahlen, die Führungskräfte extern melden, und Funktionen des maschinellen Lernens, die kundenorientierte Vorhersagen liefern. Jeder Datensatz erhält weiterhin einen formellen Vertrag mit geplanten Überprüfungen und einer an den Eigentümer weitergeleiteten Warnung, allerdings ohne dass um 2 Uhr morgens irgendjemand angerufen wird

Stufe 2 deckt interne und betriebliche Daten ab: Advert-hoc-Berichte, interne Analysen und Experimentiertabellen. Eine einfache Dokumentation und eine erhaltene Abstammungslinie sind hier wichtiger als ein formeller Vertrag, da ein Fehler innerhalb eines Groups bleibt.

Stufe 3 deckt explorative Daten ab: einmalige Exporte, Scratch-Tabellen und Prototyp-Datensätze. Es gilt kein Vertrag, es gibt keine Qualitätsgarantie und jeder Datensatz trägt ein klares Etikett, auf dem dies steht.

Drei Fragen platzieren die meisten Datensätze richtig.

Würde eine falsche Nummer einen finanziellen Verlust, ein rechtliches Risiko oder ein Drawback bei der Einreichung der behördlichen Unterlagen auslösen?

Stufe 0. Wird der Datensatz einer kundenorientierten Oberfläche oder einer außerhalb des Unternehmens gemeldeten Metrik zugeführt?

Tier 1, es sei denn, das finanzielle oder regulatorische Risiko hat es bereits auf Tier 0 gebracht. Verlässt sich mehr als ein Workforce bei Entscheidungen auf den Datensatz, ohne dass externe oder regulatorische Interessen damit verbunden sind?

Stufe 2. Alles, was übrig bleibt, einschließlich einmaliger Exporte und Prototypen, wird standardmäßig auf Stufe 3 gesetzt.

Sobald ein Datensatz einen Vertrag erhält, benötigt das Dokument unabhängig vom Format sechs Felder:

• Schema und Datentypen für jedes Feld, das ein Verbraucher berühren könnte, mit Angabe von Nullable-Feldern und erwarteten Bereichen.
• Frische- und Verfügbarkeitsziele werden als Zahl und nicht als Beschreibung angegeben: innerhalb von vier Stunden aktualisiert, an 99,5 Prozent der Werktage verfügbar.
• Qualitätsschwellenwerte und die Prüfungen, die sie durchsetzen: Vollständigkeit, Eindeutigkeit und alle für den Datensatz spezifischen Geschäftsregeln.
• Ein benanntes Produzententeam, ein benanntes Verbraucherteam und ein Eskalationspfad für den Fall, dass die beiden nicht einverstanden sind.
• Ein Änderungsmanagementprozess, der beschreibt, wie Schemaänderungen angekündigt werden und wie lange Verbraucher Zeit haben, sich anzupassen.
• Ein namentlich genannter Supportkanal, bei dem ein Verbraucher ein Drawback meldet und eine Reaktionszeitzusage erhält.

Stellen Sie sich als anschauliches Beispiel ein Abonnementunternehmen vor, das seine monatlich wiederkehrende Umsatztabelle der Stufe 0 zuordnet. Die sechs Felder könnten lauten:

• Schema: customer_id (Zeichenfolge, nicht null), mrr_amount (dezimal, null oder größer), billing_period (Datum).
• Aktualität: Wird innerhalb von vier Stunden nach jedem Abrechnungslauf aktualisiert.
• Qualitätsprüfungen: Vollständigkeit bei 99,9 Prozent oder höher, Eindeutigkeit durchgesetzt für customer_id plus billing_period.
• Verantwortung: Das Billing Platform-Workforce erstellt die Tabelle, Finance Reporting nutzt sie und Streitigkeiten werden innerhalb von 15 Minuten an den Datentechniker auf Abruf weitergeleitet.
• Änderungsmanagement: Schemaänderungen werden zwei Wochen im Voraus im Kanal #data-contracts angekündigt.
• Assist: Ein benannter Posteingang verpflichtet zu einer Antwort innerhalb eines Werktages.

Ein Rubbeltisch, der eine einmalige Kohortenanalyse speist, benötigt nichts davon. Die Kosten für das Schreiben von sechs Feldern für jede Tabelle im Warehouse sind genau der Grund, warum die meisten Vertragsprogramme ins Stocken geraten, und es gibt Tiering, um die Kosten auf die Daten zu beschränken, wo sie sich amortisieren.

Datenverantwortliche, die dieses Modell verfolgen, sollten die Auswirkungen von Vorfällen, die Erkennungszeit, die Menge an Fehlalarmen und Vertragsverstöße nach Stufen im Auge behalten und nicht einen einzigen unternehmensweiten Qualitätsfaktor, der verbirgt, wo der tatsächliche Schaden entsteht. Ein Verstoß der Stufe 0 und ein Verstoß der Stufe 3 sind nicht dasselbe Ereignis, und ein Dashboard, das sie gleich behandelt, wird das Sign, das Führungskräfte am meisten brauchen, unterdrücken.

Wo die Tierung zusammenbricht

Zwei Fehlermodi treten quick sofort auf, wenn ein Workforce ein Stufenmodell übernimmt, und keiner betrifft das Framework selbst.

Das erste ist das Stufenkriechen. Jedes Workforce glaubt, dass seine Daten am wichtigsten sind, und ein Modell ohne Durchsetzungsmechanismen tendiert dazu, alles innerhalb eines Jahres als Tier 0 zu kennzeichnen. Die Lösung ist eher verfahrenstechnischer als technischer Natur: Leiten Sie Tier-0-Nominierungen über die Finanzabteilung, die Rechtsabteilung oder die Funktion weiter, die das regulatorische Risiko besitzt, und verlangen Sie einen angegebenen Dollarbetrag oder eine Compliance-Zertifizierung, bevor ein Datensatz das Label erhält.

Der zweite Fehlermodus knüpft direkt an Mezhanskiys Argumentation an. Eine Ebenenzuweisung bleibt im Kopf einer Particular person oder auf einer Wiki-Seite, es sei denn, jemand schreibt sie in Metadaten, die ein Agent oder eine Abfragemaschine lesen kann. Ein KI-Agent, der aus einem Lagerhaus greift, kann nicht erkennen, dass es sich bei einer Tabelle um einen Tier-3-Scratch-Datensatz handelt, es sei denn, die Zuweisung erfolgt mit der Tabelle selbst, über Tags, einen Katalogeintrag oder das Kontextdiagramm, das Mezhanskiys Unternehmen verkauft. Überspringen Sie den Tagging-Schritt, und ein Agent kann aus einer nicht überprüften Prototypentabelle eine Frage der Stufe 0 beantworten. Das Ergebnis verwandelt einen Datensatz mit geringem Einsatz in eine Entscheidung mit hohem Einsatz, und niemand bemerkt es, bis etwas kaputt geht.

Für die Ebenen ist außerdem ein Überprüfungsrhythmus erforderlich, da das Risikoprofil eines Datensatzes selten unverändert bleibt. Eine Kohortenanalyse, die für eine Vorstandssitzung erstellt wurde, kann sich innerhalb von zwei Quartalen in eine wiederkehrende Kennzahl verwandeln, die ein CFO extern zitiert. Zu diesem Zeitpunkt ist der Datensatz stillschweigend von Tier 3 auf Tier 1 übergegangen, ohne dass jemals ein Vertrag damit verbunden struggle. Eine vierteljährliche Re-Tiering-Überprüfung, die von demjenigen durchgeführt wird, der die Datenplattform betreibt, erkennt Abweichungen, bevor eine Metrik extern veröffentlicht wird.

Datenteams geben bei der Qualität nicht auf. Sie geben zu, dass die allgemeine Absicherung schon immer eine Fiktion struggle, und diese Fiktion wurde teurer, als KI-Agenten anfingen, in denselben Lagerhäusern zu arbeiten, die früher Menschen von Hand babysitteten. Starke Programme im Jahr 2026 werden schriftlich entscheiden, wo schlechte Daten echten Schaden anrichten, sich energisch behaupten und genügend Kontext hinterlassen, damit Menschen und Maschinen alles andere mit offenen Augen angehen können.

: Das Mitternachtsparadoxon

Stellen Sie sich das vor. Sie erstellen ein Modell zur Vorhersage des Strombedarfs oder der Taxiabholung. Sie geben ihm additionally ab Mitternacht Zeit (z. B. Minuten) ein. Sauber und einfach. Rechts?

Jetzt sieht Ihr Modell 23:59 (Minute 1439 des Tages) Und 00:01 (Minute 1 des Tages). Für Sie liegen sie zwei Minuten auseinander. Für Ihr Modell sind sie sehr weit voneinander entfernt. Das ist das Mitternachtsparadoxon. Und ja, Ihr Modell ist wahrscheinlich zeitblind.

Warum passiert das?

Weil die meisten Modelle des maschinellen Lernens Zahlen als gerade Linien und nicht als Kreise behandeln.

Lineare Regression, KNN, SVMs und sogar neuronale Netze behandeln Zahlen logisch, vorausgesetzt, höhere Zahlen sind „mehr“ als niedrigere. Sie wissen nicht, dass die Zeit vergeht. Mitternacht ist der Grenzfall, den sie nie verzeihen.

Wenn Sie Ihrem Modell schon einmal erfolglos stündliche Informationen hinzugefügt haben und sich später fragen, warum Ihr Modell mit Tagesgrenzen zu kämpfen hat, ist dies wahrscheinlich der Grund.

Das Versagen der Standardkodierung

Lassen Sie uns über die üblichen Vorgehensweisen sprechen. Sie haben wahrscheinlich mindestens eines davon verwendet.

Sie kodieren Stunden als Zahlen von 0 bis 23. Jetzt gibt es eine künstliche Klippe zwischen Stunde 23 und Stunde 0. Daher geht dieses Modell davon aus, dass Mitternacht der größte Sprung des Tages ist. Unterscheidet sich Mitternacht jedoch wirklich stärker von 23:00 Uhr als 22:00 Uhr von 21:00 Uhr?

Natürlich nicht. Aber Ihr Modell weiß das nicht.

Hier ist die Stundendarstellung im „linearen“ Modus.

# Generate knowledge
date_today = pd.to_datetime('right now').normalize()
datetime_24_hours = pd.date_range(begin=date_today, intervals=24, freq='h')
df = pd.DataFrame({'dt': datetime_24_hours})
df('hour') = df('dt').dt.hour	

# Calculate Sin and Cosine
df("hour_sin") = np.sin(2 * np.pi * df("hour") / 24)
df("hour_cos") = np.cos(2 * np.pi * df("hour") / 24)

# Plot the Hours in Linear mode
plt.determine(figsize=(15, 5))
plt.plot(df('hour'), (1)*24, linewidth=3)
plt.title('Hours in Linear Mode')
plt.xlabel('Hour')
plt.xticks(np.arange(0, 24, 1))
plt.ylabel('Worth')
plt.present()

Was wäre, wenn wir die Stunden im One-Sizzling-Verfahren kodieren würden? Vierundzwanzig Binärspalten. Downside gelöst, oder? Nun ja… teilweise. Sie haben die künstliche Lücke repariert, aber die Nähe verloren. 2 Uhr morgens ist nicht mehr näher an 3 Uhr morgens als an 22 Uhr.
Sie haben auch die Dimensionalität explodiert. Für Bäume ist das ärgerlich. Für lineare Modelle ist es wahrscheinlich ineffizient.

Kommen wir additionally zu einer praktikablen Various.

• Die Lösung: Trigonometrische Kartierung

Hier ist die Änderung der Denkweise:

Hören Sie auf, die Zeit als eine Linie zu betrachten. Betrachten Sie es als einen Kreis.

Ein 24-Stunden-Tag kehrt zu sich selbst zurück. Daher sollte auch Ihre Codierung eine Schleife bilden und im Kreis denken. Jede Stunde ist ein gleichmäßig verteilter Punkt auf einem Kreis. Um nun einen Punkt auf einem Kreis darzustellen, verwenden Sie nicht eine Zahl, sondern verwenden zwei Koordinaten: X Und j.

Hier kommen Sinus und Cosinus ins Spiel.

Die Geometrie dahinter

Jeder Winkel auf einem Kreis kann mithilfe von Sinus und Cosinus einem eindeutigen Punkt zugeordnet werden. Dadurch erhält Ihr Modell eine reibungslose, kontinuierliche Darstellung der Zeit.

plt.determine(figsize=(5, 5))
plt.scatter(df('hour_sin'), df('hour_cos'), linewidth=3)
plt.title('Hours in Cyclical Mode')
plt.xlabel('Hour')

Hier ist die mathematische Formel zur Berechnung der Zyklen für Stunden des Tages:

• Erste, 2 * π * hour / 24 rechnet jede Stunde in einen Winkel um. Mitternacht und 23 Uhr landen quick an derselben Place im Kreis.
• Dann Sinus Und Kosinus Projizieren Sie diesen Winkel in zwei Koordinaten.
• Diese beiden Werte zusammen definieren eindeutig die Stunde. Jetzt sind 23:00 und 00:00 Uhr im Characteristic-Bereich nahe beieinander. Genau das, was Sie schon immer wollten.

Die gleiche Idee funktioniert für Minuten, Wochentage oder Monate im Jahr.

Code

Lassen Sie uns mit diesem Datensatz experimentieren Energieprognose für Haushaltsgeräte (4). Wir werden versuchen, die Vorhersage mithilfe eines Random Forest Regressor-Modells (einem baumbasierten Modell) zu verbessern.

Candanedo, L. (2017). Energieprognose für Haushaltsgeräte (Datensatz). UCI-Repository für maschinelles Lernen. https://doi.org/10.24432/C5VC8G. Artistic Commons 4.0-Lizenz.

# Imports
from sklearn.ensemble import RandomForestRegressor
from sklearn.model_selection import train_test_split
from sklearn.metrics import root_mean_squared_error
from ucimlrepo import fetch_ucirepo 

Holen Sie sich Daten.

# fetch dataset 
appliances_energy_prediction = fetch_ucirepo(id=374) 
  
# knowledge (as pandas dataframes) 
X = appliances_energy_prediction.knowledge.options 
y = appliances_energy_prediction.knowledge.targets 
  
# To Pandas
df = pd.concat((X, y), axis=1)
df('date') = df('date').apply(lambda x: x(:10) + ' ' + x(11:))
df('date') = pd.to_datetime(df('date'))
df('month') = df('date').dt.month
df('day') = df('date').dt.day
df('hour') = df('date').dt.hour
df.head(3)

Lassen Sie uns schnell ein Modell mit dem erstellen linear Zeit zuerst, als unsere Vergleichsbasis.

# X and y
# X = df.drop(('Home equipment', 'rv1', 'rv2', 'date'), axis=1)
X = df(('hour', 'day', 'T1', 'RH_1', 'T_out', 'Press_mm_hg', 'RH_out', 'Windspeed', 'Visibility', 'Tdewpoint'))
y = df('Home equipment')

# Practice Take a look at Cut up
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

# Match the mannequin
lr = RandomForestRegressor().match(X_train, y_train)

# Rating
print(f'Rating: {lr.rating(X_train, y_train)}')

# Take a look at RMSE
y_pred = lr.predict(X_test)
rmse = root_mean_squared_error(y_test, y_pred)
print(f'RMSE: {rmse}')

Die Ergebnisse gibt es hier.

Rating: 0.9395797670166536
RMSE: 63.60964667197874

Als nächstes kodieren wir die zyklischen Zeitkomponenten (day Und hour) und trainieren Sie das Modell neu.

# Add cyclical hours sin and cosine
df('hour_sin') = np.sin(2 * np.pi * df('hour') / 24)
df('hour_cos') = np.cos(2 * np.pi * df('hour') / 24)
df('day_sin') = np.sin(2 * np.pi * df('day') / 31)
df('day_cos') = np.cos(2 * np.pi * df('day') / 31)

# X and y
X = df(('hour_sin', 'hour_cos', 'day_sin', 'day_cos','T1', 'RH_1', 'T_out', 'Press_mm_hg', 'RH_out', 'Windspeed', 'Visibility', 'Tdewpoint'))
y = df('Home equipment')

# Practice Take a look at Cut up
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

# Match the mannequin
lr_cycle = RandomForestRegressor().match(X_train, y_train)

# Rating
print(f'Rating: {lr_cycle.rating(X_train, y_train)}')

# Take a look at RMSE
y_pred = lr_cycle.predict(X_test)
rmse = root_mean_squared_error(y_test, y_pred)
print(f'RMSE: {rmse}')

Und die Ergebnisse. Wir sehen eine Verbesserung um 1 % beim Rating und 1 Punkt beim RMSE.

Rating: 0.9416365489096074
RMSE: 62.87008070927842

Ich bin sicher, das sieht nicht nach viel aus, aber bedenken Sie, dass dieses Spielzeugbeispiel ein einfaches, sofort einsatzbereites Modell ohne jegliche Datenverarbeitung oder -bereinigung verwendet. Wir sehen hauptsächlich den Effekt der Sinus- und Kosinustransformation.

Was hier wirklich passiert, ist, dass der Strombedarf im wirklichen Leben nicht um Mitternacht zurückgeht. Und jetzt erkennt Ihr Modell endlich diese Kontinuität.

Warum Sie sowohl Sinus als auch Cosinus benötigen

Erliegen Sie nicht der Versuchung, etwas zu verwenden nur Sinusda es sich genug anfühlt. Eine Spalte statt zwei. Sauberer, oder?

Leider bricht es die Symmetrie. Im 24-Stunden-Format können 6 Uhr morgens und 18 Uhr abends denselben Sinuswert erzeugen. Unterschiedliche Zeiten bei identischer Kodierung können schlecht sein, da das Modell nun die morgendliche Hauptverkehrszeit mit der abendlichen Hauptverkehrszeit verwechselt. Daher nicht very best, es sei denn, Sie mögen verwirrende Vorhersagen.

Die Verwendung von Sinus und Cosinus behebt dieses Downside. Zusammen verleihen sie jeder Stunde einen einzigartigen Fingerabdruck auf dem Kreis. Stellen Sie sich das wie Breiten- und Längengrad vor. Sie brauchen beides, um zu wissen, wo Sie sind.

Auswirkungen und Ergebnisse in der Praxis

Hilft das additionally tatsächlich Fashions? Ja. Vor allem bestimmte.

Distanzbasierte Modelle

KNN und SVMs sind stark auf Entfernungsberechnungen angewiesen. Die zyklische Kodierung verhindert vorgetäuschte „große Distanzen“ an Grenzen. Ihre Nachbarn werden tatsächlich wieder Nachbarn.

Neuronale Netze

Neuronale Netze lernen schneller mit glatten Merkmalsräumen. Durch die zyklische Kodierung werden scharfe Diskontinuitäten um Mitternacht entfernt. Das bedeutet normalerweise eine schnellere Konvergenz und eine bessere Stabilität.

Baumbasierte Modelle

Gradient Boosted Timber wie XGBoost oder LightGBM können diese Muster schließlich lernen. Die zyklische Kodierung verschafft ihnen einen Vorsprung. Wenn Ihnen Leistung und Interpretierbarkeit wichtig sind, lohnt es sich.

7. Wann sollten Sie es verwenden?

Stellen Sie sich immer die Frage: Wiederholt sich diese Funktion in einem Zyklus? Wenn ja, ziehen Sie eine zyklische Codierung in Betracht.

Gängige Beispiele sind:

• Stunde des Tages
• Wochentag
• Monat des Jahres
• Windrichtung (Grad)
• Wenn es eine Schleife gibt, können Sie versuchen, es wie eine Schleife zu kodieren.

Bevor Sie gehen

Zeit ist nicht nur eine Zahl. Es ist eine Koordinate auf einem Kreis.

Wenn Sie sie wie eine gerade Linie behandeln, kann Ihr Modell an Grenzen stoßen und es fällt Ihnen schwer, diese Variable als Zyklus zu verstehen, als etwas, das sich wiederholt und ein Muster aufweist.

Die zyklische Codierung mit Sinus und Cosinus behebt dieses Downside auf elegante Weise, indem die Nähe erhalten bleibt, Artefakte reduziert werden und Modelle schneller lernen.

Wenn Ihre Vorhersagen additionally das nächste Mal bei Tageswechseln seltsam aussehen, probieren Sie dieses neue Instrument aus, das Sie gelernt haben, und lassen Sie es Ihr Modell so erstrahlen, wie es sollte.

Wenn Ihnen dieser Inhalt gefallen hat, finden Sie mehr über meine Arbeit und meine Kontakte auf meiner Web site.

https://gustavorsantos.me

GitHub-Repository

Hier ist der gesamte Code dieser Übung.

https://github.com/gurezende/Time-Collection/tree/predominant/Sinepercent20Cosinepercent20Timepercent20Encode

Referenzen und weiterführende Literatur

(1. Codierungsstunden-Stack-Austausch): https://stats.stackexchange.com/questions/451295/encoding-symmetrical-feature-minutes-and-hours

(2. NumPy trigonometrische Funktionen): https://numpy.org/doc/steady/reference/routines.math.html

(3. Praktische Diskussion über zyklische Merkmale):
https://www.kaggle.com/code/avanwyk/encoding-symmetrical-features-for-deep-learning

(4. Energievorhersagedatensatz für Geräte) https://archive.ics.uci.edu/dataset/374/home equipment+power+prediction