Neuronale Netze im Trading: Akteur–Direktor–Kritiker
Einführung
Reinforcement Learning (RL) bleibt eines der vielversprechendsten und sich am schnellsten entwickelnden Felder des modernen maschinellen Lernens. Seine Einzigartigkeit liegt in der Fähigkeit eines Agenten, durch Interaktion mit seiner Umgebung zu lernen und optimale Verhaltensstrategien auf der Grundlage gesammelter Erfahrungen zu entwickeln. Besonders erfolgreich war die Integration mit tiefen neuronalen Netzen, üblicherweise als Deep Reinforcement Learning (Deep RL) bezeichnet, was zu bedeutenden Fortschritten bei autonomen Systemen für Robotik, Spiele, industrielle Prozesssteuerung und Finanzmärkte geführt hat.
Finanzumgebungen sind durch hohe Stochastizität, ständige Veränderungen und erhebliches Risiko gekennzeichnet, was sie zu einem idealen Testgelände für Deep RL-Methoden macht. In solchen Umgebungen muss sich ein Agent schnell an Schwankungen bei Preisen, Handelsvolumina und Marktvolatilität anpassen, während er Entscheidungen unter Unsicherheit trifft. Der praktische Einsatz von RL in Handelsstrategien, insbesondere im Hochfrequenzhandel und im Portfoliomanagement, steht jedoch vor mehreren Herausforderungen. Eines der bedeutendsten Probleme ist die geringe Sample-Effizienz, was bedeutet, dass nicht informative Aktionen und fehlerhafte Strategien außergewöhnlich hohe Kosten verursachen.
In klassischen modellfreien RL-Algorithmen, bei denen kein explizites Modell der Umgebung verwendet wird, erhält der Agent Informationen ausschließlich aus der beobachteten Erfahrung. Er lernt durch Versuch und Irrtum: Er führt Aktionen aus, erhält Belohnungen und aktualisiert seine Schätzungen. Ein großer Teil dieser Interaktionen ist jedoch nur schwach informativ. Auf den Finanzmärkten bedeutet dies erhebliche Transaktionskosten, Kapitalverluste und einen langen Weg zu einer robusten Strategie. Folglich bleiben die Verbesserung der Sample-Effizienz und die Beschleunigung der Lernkonvergenz kritische Ziele.
Eine der robustesten und am weitesten verbreiteten Architekturen ist das Framework von Akteur–Kritiker, das zwei Modelle kombiniert:
- Akteur – lernt die Policy,
- Kritiker – bewertet Aktionen durch die Wertfunktion.
In Finanzanwendungen wird die Architektur von Akteur–Kritiker häufig verwendet, um Agenten zu entwickeln, die in der Lage sind, kurzfristige Renditen vorherzusagen und gleichzeitig langfristige Risiken zu steuern. Zum Beispiel lernt der Kritiker bei Aufgaben zur Portfolio-Neugewichtung, erwartete Renditen zu schätzen, während der Akteur Asset-Gewichtungen auswählt, die den Portfoliowert maximieren. Diese fortschrittliche Architektur hat jedoch auch ihre Grenzen. Während der frühen Phasen des Trainings können die Schätzungen des Kritikers sehr ungenau sein, was dazu führt, dass der Akteur irreführende Signale erhält. Infolgedessen erkundet der Agent möglicherweise wiederholt Bereiche des Aktionsraums, die wahrscheinlich unrentabel sind.
Um diese Einschränkung anzugehen, führt der Artikel Akteur-Direktor-Kritiker: A Novel Deep Reinforcement Learning Framework ein neues Framework ein: Akteur–Direktor–Kritiker (Actor–Director–Critic, ADC). Zusätzlich zum Akteur und Kritiker enthält die Architektur eine dritte Komponente – den Direktor. Seine Rolle besteht darin, als Klassifikator zu fungieren, der in der Lage ist, qualitativ gute Aktionen von schlechten Aktionen zu unterscheiden, noch bevor der Kritiker gelernt hat, zuverlässige Bewertungen abzugeben. Im Gegensatz zum Kritiker führt der Direktor eher eine Klassifizierungs- als eine Bewertungsfunktion aus. Er bestimmt, ob eine bestimmte Aktion zum Training der Policy verwendet werden sollte oder ob sie von Natur aus von geringer Qualität ist und von weiterer Betrachtung ausgeschlossen werden sollte.
Die Einführung des Direktors bietet mehrere Vorteile. Erstens ist Selektivität in den frühen Phasen des Trainings von entscheidender Bedeutung, in denen ineffektive Aktionen nach Möglichkeit vermieden werden sollten. Zweitens kann in Umgebungen mit hohen Transaktionskosten und Marktvolatilität jede erfolglose Aktion für den Agent teuer sein. Unter solchen Bedingungen dient der Direktor als anfänglicher Leitmechanismus für den Akteur, der es ihm ermöglicht, sich auf potenziell effektive Aktionen zu konzentrieren. Dieser Ansatz reduziert die Explorationsentropie und beschleunigt die Bildung produktiver Strategien.
Der Direktor wird anhand von zwei empirischen Datenteilmengen trainiert: eine enthält hochprofitable Zustands-Aktions-Belohnungs-Tupel und eine andere enthält leistungsschwache Beispiele. Nach dem Training führt der Direktor eine binäre Klassifizierung neu generierter Aktionen durch, filtert potenziell ineffektive Entscheidungen heraus und verstärkt dadurch die vom Kritiker bereitgestellten Signale. Der Einfluss des Direktors wird durch einen Zerfallskoeffizienten gesteuert: Anfangs übt er einen erheblichen Einfluss auf den Akteur aus, aber mit zunehmender Genauigkeit des Kritikers nimmt das Gewicht des Direktors allmählich ab. Dieser Mechanismus bewahrt während der gesamten Optimierung sowohl Flexibilität als auch Stabilität.
Zusätzlich zu den strukturellen Verbesserungen, die durch die Architektur von ADC eingeführt wurden, befassen sich die Autoren mit einem weiteren grundlegenden Problem: Überschätzungsverzerrung. Beim RL tritt eine Überschätzung auf, wenn überhöhte Wertschätzungen als Lernziele verwendet werden, was zu übertriebenen Belohnungserwartungen und instabilem Training führt. Die Hauptursachen für die Überschätzung sind:
- Maximierungsfehler, der aus der Tendenz entsteht, überschätzte Wertfunktionsausgaben auszuwählen;
- Bootstrapping-Fehler, bei denen vorhergesagte zukünftige Belohnungen verwendet werden, um Schätzungen des aktuellen Zustands zu aktualisieren.
Einer der bekanntesten Ansätze zur Minderung der Überschätzung ist der Algorithmus Twin Delayed Deep Deterministic Policy Gradient (TD3). TD3 verwendet zwei unabhängige Funktionen Q und nutzt das Minimum ihrer Schätzungen für Aktualisierungen. Dennoch bleibt die Methode anfällig für Instabilität, da ihre Zielnetzwerke verzögert aktualisiert werden und ihre Schätzungen immer noch verrauscht sein können.
Das Framework ADC schlägt eine Modifikation dieses Ansatzes vor. Jeder Funktion Q sind zwei Zielnetzwerke zugeordnet, die abwechselnd in unterschiedlichen Intervallen aktualisiert werden. Bei der Berechnung des Zielwerts verwendet das Framework die durchschnittliche Schätzung, die von den beiden Zielmodellen erzeugt wird. Dieser Ansatz reduziert die Schätzvarianz, minimiert die Überschätzungsverzerrung und verbessert die Trainingsstabilität. Solche Verbesserungen sind besonders wichtig bei Finanzanwendungen, bei denen sich Fehler in der Funktion Q direkt in Kapitalverlusten niederschlagen können.
Durch die Kombination der Architektur Akteur–Direktor–Kritiker mit einem verbesserten dualen Schätzmechanismus bildet ADC ein leistungsfähiges, adaptives und robustes Framework. Seine Anwendung auf den algorithmischen Handel, Vermögensverwaltung und automatisiertes Hedging hat das Potenzial, die Handelsperformance signifikant zu verbessern, das Training des Agenten zu beschleunigen und Risiken durch intelligente Aktionsauswahl von den frühesten Lernphasen an zu reduzieren.
Der ADC-Algorithmus
Über eine breite Palette von Aufgaben des RL hinweg hat sich die Akteur–Kritiker-Architektur als zuverlässige und effektive Lösung etabliert. Ihre Eleganz, Klarheit und Fähigkeit, qualitativ hochwertige Policies zu erstellen, haben sie zu einer Grundlage für nachfolgende Entwicklungen im RL gemacht. Da Umgebungen jedoch zunehmend komplexer geworden sind, insbesondere solche, die kontinuierliche Aktionsräume des Agenten und spärliches Feedback beinhalten, sind leistungsfähigere und flexiblere architektonische Lösungen notwendig geworden. Das Framework Akteur–Direktor–Kritiker (ADC) entstand als Reaktion auf diese Herausforderungen und integriert Prinzipien der strategischen Planung, heuristischen Führung und tiefen Aktionsbewertung.
Die Architektur basiert auf drei miteinander verbundenen Komponenten: Akteur, Kritiker und Direktor. Zusammen bilden sie ein koordiniertes System, in dem jede Komponente die anderen verstärkt, was Bedingungen für ein schnelleres und stabileres Lernen des Agenten schafft.
Der Kritiker dient als analytischer Kern des Systems. Seine Hauptaufgabe besteht darin, den langfristigen Nutzen der Aktionen des Agenten zu bewerten, indem die Wertfunktion Q(s, a) approximiert wird, die den erwarteten kumulativen Ertrag unter der aktuellen Policy darstellt. Der Kritiker wird durch die Minimierung des Fehlers zwischen vorhergesagten und Zielwerten trainiert:

wobei:
- r ist die Belohnung, die der Agent von der Umgebung für seine letzte Aktion erhält;
- γ ∈ [0,1) der Diskontfaktor ist;
- s' und a' bezeichnen den nachfolgenden Zustand beziehungsweise die nachfolgende Aktion.
Sich jedoch ausschließlich auf die Schätzungen des Kritikers zu verlassen, insbesondere in den frühen Phasen des Trainings, kann riskant sein, da seine Vorhersagen oft instabil sind. Um diese Unsicherheit auszugleichen und den Agenten zu sinnvollen Entscheidungen zu führen, führt die Architektur den Direktor ein, der als eine Art Mentor-Komponente fungiert. Der Direktor agiert als binärer Klassifikator, der potenziell vorteilhafte Aktionen von unerwünschten unterscheidet. Der Direktor wird anhand von vorab gekennzeichneten Datensätzen profitabler Aktionen ah und unprofitabler Aktionen al gemäß der folgenden Zielfunktion trainiert:
![]()
wobei die Funktion D(s, a) die Wahrscheinlichkeit schätzt, dass die Aktion a im Zustand s angemessen ist. Auf diese Weise filtert der Direktor Aktionen und leitet den Lernprozess des Akteurs, insbesondere in den Anfangsphasen, wenn die Schätzungen des Kritikers möglicherweise noch nicht zuverlässig sind.
Der Akteur wiederum repräsentiert die Policy des Agenten. Er ist als parametrisierte Funktion μθ(s) implementiert, die nach der Analyse des aktuellen Zustands s eine Aktion a ausgibt, die unter der aktuellen Policy als optimal erachtet wird. Im Framework ADC wird der Akteur nicht nur durch Feedback des Kritikers, sondern auch mit Unterstützung des Direktors trainiert. Dies ermöglicht ein sichereres Voranschreiten zu optimalen Strategien. Die Zielfunktion des Akteurs kombiniert diese beiden Informationsquellen:
![]()
Infolgedessen sucht der Akteur nach Aktionen, die sowohl vom Direktor unterstützt werden als auch vom Kritiker einen hohen Erwartungswert zugewiesen bekommen.
Um die Trainingsstabilität zu verbessern und die Überschätzungsverzerrung zu verringern, verwendet das Framework ADC einen verbesserten Dual-Schätzungsmechanismus. Es werden zwei unabhängige Kritiker beibehalten, von denen jeder von zwei Zielnetzwerken mit eingefrorenen Parametern begleitet wird. Während des Trainings von Kritiker wird der Zielwert als durchschnittliche Vorhersage der entsprechenden Zielnetzwerke für das nächste Zustands-Aktions-Paar berechnet, was zur Stabilisierung des Lernprozesses beiträgt. Während des Trainings des Akteurs wird die Mindestschätzung der beiden Kritiker verwendet, was eine Überbewertung von Aktionen verhindert und die Entwicklung einer konservativeren, aber zuverlässigeren Policy fördert.
Die Zielmodelle der Kritiker werden abwechselnd aktualisiert, indem die Parameter ihrer entsprechenden trainierbaren Modelle in vordefinierten Intervallen kopiert werden. Dieser Ansatz fördert die langfristige Trainingsstabilität und verhindert abrupte Schwankungen der Zielwerte.
Es ist auch wichtig zu beachten, dass die Parameter des Kritikers bei jeder Trainingsiteration optimiert werden. Im Gegensatz dazu werden Policy-Aktualisierungen für den Akteur verzögert durchgeführt, was für zusätzliche Trainingsstabilität sorgt. Dieser Mechanismus der verzögerten Aktualisierung gibt dem Kritiker ausreichend Zeit, die aktuelle Policy genau zu bewerten und zuverlässigere Orientierungen für deren Anpassung zu bieten.
Darüber hinaus werden stochastische Glättungstechniken eingesetzt, um die Verhaltensvielfalt und Robustheit des Agenten zu verbessern, einschließlich:
- Hinzufügen von gaußschem Rauschen zu den Aktionen des Agenten:
![]()
- Hinzufügen von begrenztem Rauschen zu Zielaktionen:
![]()
Die endgültige Parameteroptimierungsfunktion für den Akteur integriert Signale sowohl vom Kritiker als auch vom Direktor:
![]()
Das Framework von Akteur-Direktor-Kritiker eröffnet neue Wege für die Entwicklung intelligenter Agenten, die nicht nur aus Erfahrung lernen, sondern auch Anleitung auf eine Weise nutzen können, die dem menschlichen Lernen ähnelt.
Die Visualisierung des Frameworks Akteur-Direktor-Kritiker durch die Autoren wird unten dargestellt.

Implementierung in MQL5
Nachdem wir die theoretischen Aspekte des Frameworks von Akteur-Direktor-Kritiker betrachtet haben, gehen wir nun zum praktischen Teil dieses Artikels über, in dem wir unsere Interpretation der Implementierung der vorgeschlagenen Methoden unter Verwendung von MQL5 präsentieren.
Wie Sie vielleicht bemerkt haben, erfordert das hier behandelte Framework nicht die Einführung völlig neuer Module als separate Objekte. Dieser Aspekt unterscheidet diese Arbeit maßgeblich von früheren Ansätzen. In dieser Implementierung konzentrieren wir uns darauf, die Architektur der zu trainierenden Modelle aus zuvor entwickelten Modulen zu konstruieren sowie den Trainingsprozess in Übereinstimmung mit der vorgeschlagenen Methodik zu gestalten.
Architektur der zu trainierenden Modelle
Beim Beginn der Konstruktion der Architektur der zu trainierenden Modelle ist zu beachten, dass das von den Autoren vorgeschlagene Framework ADC auf eine breite Palette architektonischer Designs anwendbar ist. Im ursprünglichen Beitrag werden experimentelle Ergebnisse unter Verwendung einer Erweiterung des Frameworks TD3 präsentiert. In unserer Arbeit gehen wir jedoch weiter und wenden die vorgeschlagenen Ideen auf eine komplexere architektonische Lösung an – HiSSD, die in einer früheren Studie vorgestellt wurde. Darüber hinaus beschränken wir uns nicht darauf, einfach zwei neue Modelle (den Kritiker und den Direktor) hinzuzufügen, sondern führen auch Modifikationen an zuvor entwickelten Komponenten ein.
Wie zuvor wird die Architektur aller trainierbaren Modelle innerhalb der Methode CreateDescriptions definiert. In den Parametern dieser Methode fügen wir zwei dynamische Arrays hinzu, um die Architekturen der neu eingeführten Modelle zu speichern.
bool CreateDescriptions(CArrayObj *&encoder, CArrayObj *&task, CArrayObj *&actor, CArrayObj *&probability, CArrayObj *&director, CArrayObj *&critic ) { //--- CLayerDescription *descr; //--- if(!encoder) { encoder = new CArrayObj(); if(!encoder) return false; } if(!task) { task = new CArrayObj(); if(!task) return false; } if(!actor) { actor = new CArrayObj(); if(!actor) return false; } if(!probability) { probability = new CArrayObj(); if(!probability) return false; } if(!director) { director = new CArrayObj(); if(!director) return false; } if(!critic) { critic = new CArrayObj(); if(!critic) return false; }
Im Hauptteil der Methode werden die empfangenen Zeiger überprüft und gegebenenfalls neue Instanzen von dynamischen Array-Objekten erstellt. Dies verhindert kritische Fehler beim anschließenden Zugriff auf diese Arrays.
Das erste Modell, das wir beschreiben, ist der übergeordnete Planer, der teilweise als Encoder des Umgebungszustands fungiert.
Zur Erinnerung: Dieses Modell erhält als Eingabe einen Tensor, der den Umgebungszustand beschreibt. Es generiert eine Matrix allgemeiner Skills im latenten Zustand des Modells und sagt zukünftige Umgebungszustände über einen gegebenen Planungshorizont voraus. Wichtig ist, dass nur die Repräsentation allgemeiner Skills für die Vorhersage zukünftiger Zustände verwendet wird. Dies ermutigt das Modell, einen hochgradig informativen latenten Skill-Tensor zu konstruieren.
Die erste Schicht bleibt eine vollständig verbundene Schicht mit einer Größe, die ausreicht, um den vollständigen Eingabezustandstensor der Umgebung zu kodieren.
//--- Encoder encoder.Clear(); //--- Input layer if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronBaseOCL; int prev_count = descr.count = (HistoryBars * BarDescr); descr.activation = None; descr.optimization = ADAM; if(!encoder.Add(descr)) { delete descr; return false; }
Das Modell erhält rohe, unverarbeitete Daten direkt vom MetaTrader 5-Terminal. Dies kann Sequenzen von Kursnotierungen sowie technische Indikatordaten umfassen, die von einfachen gleitenden Durchschnitten bis hin zu komplexen Oszillatoren reichen.
Obwohl diese Daten sehr wertvoll sind, sind sie von äußerst heterogener Natur. Ihre Bereiche, statistischen Verteilungen und Rauscheigenschaften können sich erheblich unterscheiden. Ohne geeignete Vorverarbeitung führt eine solche Heterogenität zu einer erheblichen Verschlechterung der Leistungsfähigkeit beim Modelltraining. Daher besteht der nächste Schritt darin, die Daten in einen vergleichbaren Darstellungsraum zu bringen, typischerweise unter Verwendung von Batch-Normalisierung, was dazu beiträgt, das Ungleichgewicht der Werteverteilung abzumildern.
In dieser Implementierung verfolgen wir jedoch einen anderen Ansatz. Um die Robustheit und die Generalisierungsfähigkeit des Modells zu verbessern, erweitern wir diese Stufe durch die Einführung von kontrolliertem Rauschen in die normalisierten Daten. Dies wirkt als eine Form der Regularisierung, verhindert Overfitting und verbessert die Anpassungsfähigkeit bei realen Marktturbulenzen.
//--- layer 1 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronBatchNormWithNoise; descr.count = prev_count; descr.batch = 1e4; descr.activation = None; descr.optimization = ADAM; if(!encoder.Add(descr)) { delete descr; return false; }
Erst nach diesem Schritt verwenden wir ein universelles Modul zur Skill-Generierung, dessen Zweck es ist, einen Tensor informativer allgemeiner Skills für jeden Agenten zu konstruieren. Dieser Tensor stellt eine kondensierte Abstraktion von Schlüsselmerkmalen dar, die in der Lage sind, das Verhalten und die Ziele des Agenten im aktuellen Marktumfeld zu charakterisieren. In hochvolatilen und unvorhersehbaren Finanzumgebungen erhöht eine solche Abstraktion die Robustheit der Strategie, indem sie die Empfindlichkeit gegenüber kurzfristigem Rauschen und Ausreißern verringert.
Es ist wichtig zu verstehen, dass dieser Skill-Tensor später als Teil der Eingabedaten für die Policy-Generierung der Agenten verwendet wird. Dessen Vorhandensein verbessert die Selektionsfähigkeit des Modells erheblich und ermöglicht es ihm, präziser zwischen potenziell profitablen und unprofitablen Aktionen zu unterscheiden. Auf diese Weise interpretieren wir die Daten im Hinblick auf Aufgaben und Kompetenzen neu. Wir bewegen uns weg von der klassischen Formulierung Zustand → Aktion hin zu einem interpretierbaren Übergang: Kontext → Skill → Aktion.
//--- layer 2 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronSkillsEncoder; descr.count = HistoryBars; { int temp[] = {BarDescr, NSkills, 4}; // Variables, Common Skills, Heads if(ArrayCopy(descr.windows, temp) < (int)temp.Size()) return false; } descr.window = 8; descr.step = 1; descr.window_out = 32; prev_count = descr.windows[0]; int prev_out = descr.windows[1]; descr.batch = 1e4; descr.optimization = ADAM; descr.activation = None; if(!encoder.Add(descr)) { delete descr; return false; }
Um die Aktionen des Agenten unter Berücksichtigung der Dynamik der Veränderungen im allgemeinen Skill-Tensor weiter zu verbessern, führen wir einen rekurrenten LSTM-Block ein. Diese Komponente spielt eine Schlüsselrolle bei der Erfassung der zeitlichen Struktur der beobachteten Marktdaten. Finanzmärkte weisen, wie allgemein bekannt ist, eine starke Abhängigkeit von vergangenen Zuständen auf, und ein erheblicher Teil der Marktlogik ist in zeitlichen Mustern eingebettet.
Genau hier wird LSTM (Long Short-Term Memory) zu einem unverzichtbaren Werkzeug. Sein interner Speichermechanismus ermöglicht es ihm, Informationen über wichtige Marktübergänge und strukturelle Muster beizubehalten und zu aktualisieren, ohne den Kontext bei langfristigen Abhängigkeiten zu verlieren. Infolgedessen lernt das Modell nicht nur, aktuelle Marktbedingungen zu erkennen, sondern auch potenzielle Umkehrungen oder Fortsetzungen auf der Grundlage der komplexen Struktur historischer Beobachtungen zu antizipieren.
Die Platzierung des LSTM-Blocks nach der Schicht zur Skill-Generierung ist eine bewusste architektonische Entscheidung. Zunächst extrahiert das Modell eine abstrakte Darstellung des aktuellen Zustands und der Agentenziele in Form eines Skill-Tensors. Anschließend verfolgt das LSTM die Entwicklung dieser Skills im Zeitverlauf. Dies ermöglicht es dem Agenten, nicht nur eine statische Momentaufnahme des Marktes wahrzunehmen, sondern auch die Dynamik seines strategischen Profils – zum Beispiel, wie sich dominante Trends entwickeln, wie sich Unterstützungs- und Widerstandsniveaus bilden und wie sich die Volatilität im Zeitverlauf verhält.
//--- layer 3 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronLSTMOCL; descr.count = prev_out; // Common Skkills descr.layers = prev_count; // Variables descr.batch = 1e4; descr.activation = None; descr.optimization = ADAM; if(!encoder.Add(descr)) { delete descr; return false; }
Als Nächstes fügen wir sequenziell zwei Faltungsschichten hinzu, von denen jede eine spezifische Rolle bei der Verarbeitung der mehrdimensionalen Zeitreihen spielt, die von den vorherigen Schichten empfangen wurden. Diese Faltungsschichten fungieren als eine Form von MLP mit unabhängigen Prognoseköpfen, die für die autonome Analyse und Vorhersage der Entwicklung einzelner Komponenten komplexer Marktsequenzen über einen festgelegten Prognosehorizont konzipiert sind.
//--- layer 4 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronConvOCL; descr.count = 1; descr.window = prev_out; descr.step = prev_out; prev_out=descr.window_out = 4*NForecast; descr.layers = prev_count; descr.activation = SoftPlus; if(!encoder.Add(descr)) { delete descr; return false; } //--- layer 5 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronConvOCL; descr.count = 1; descr.window = prev_out; descr.step = prev_out; prev_out=descr.window_out = NForecast; descr.layers = prev_count; descr.activation = TANH; if(!encoder.Add(descr)) { delete descr; return false; }
Die vorhergesagten univariaten Sequenzen werden dann in eine vollständige mehrdimensionale Zeitreihenrepräsentation transponiert.
//--- layer 6 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronTransposeOCL; descr.count = prev_count; descr.window = prev_out; descr.activation = None; if(!encoder.Add(descr)) { delete descr; return false; }
Wichtig ist, dass wir nach dieser gesamten Kaskade von Merkmalstransformationen die vorhergesagten Werte mithilfe der inversen Normalisierung auf die ursprüngliche Datenskala und -verteilung zurücksetzen. Dieser Schritt ist notwendig, um sicherzustellen, dass die Modellausgaben in einem Handelskontext aussagekräftig und interpretierbar bleiben.
Die inverse Normalisierung bewahrt die Verbindung zwischen der „Modellwelt“ und dem realen Marktraum, in dem jeder Wert eine präzise quantitative Interpretation hat.
//--- layer 7 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronRevInDenormOCL; descr.count = prev_count*prev_out; descr.layers = 1; descr.activation = None; if(!encoder.Add(descr)) { delete descr; return false; }
Es sollte betont werden, dass die latente Repräsentation, die durch den allgemeinen Skill-Generierungsblock erzeugt wird, nicht das Endergebnis der Pipeline ist. Vielmehr dient sie als wertvolle Zwischenabstraktion, die mehrfach in verschiedenen Komponenten des Frameworks Akteur–Direktor–Kritiker wiederverwendet wird. Aus diesem Grund speichern wir die rekurrente Repräsentation von LSTM in einer lokalen Variable, um ihre Verfügbarkeit für nachfolgende Operationen sicherzustellen.
//--- Latent CLayerDescription *latent = encoder.At(LatentLayer); if(!latent) return false;
Als Nächstes beschreiben wir die Architektur des niederstufigen Controllers. Dieses Modul analysiert denselben Umgebungszustand und erzeugt einen Tensor spezifischer Skills. Daher können wir die ersten beiden Schichten des vorherigen Modells – Eingabeverarbeitung und Normalisierung – ohne Modifikation wiederverwenden.
//--- Task task.Clear(); //--- Input layer if(!task.Add(encoder.At(0))) { return false; } //--- layer 1 if(!task.Add(encoder.At(1))) { return false; }
Der Controller fungiert dann als niedrigstufiges Modul, das für die Konstruktion eines Tensors aufgabenspezifischer Skills verantwortlich ist. Im Gegensatz zu dem zuvor beschriebenen allgemeinen Skill-Generierungsmodul, das in einem strategischen Kontext arbeitet, agiert der Controller auf einer taktischen Ebene und analysiert den aktuellen Umgebungszustand.
Der Controller reagiert nicht bloß auf die Umgebung; er interpretiert aktiv die komplexe Marktstruktur und extrahiert das, was als kurzfristige „Intuition“ des Agenten beschrieben werden kann. Basierend auf dieser Analyse erzeugt er einen Tensor aufgabenspezifischer Skills, der unmittelbare Präferenzen und die Handlungen widerspiegelt, die der Agent in einer gegebenen Situation ausführen sollte.
Schließlich werden drei Informationsströme zusammengeführt:
- die latente Repräsentation allgemeiner (übergeordneter) Skills;
- der Tensor aufgabenspezifischer (niedrigstufiger) Skills;
- die normalisierte Repräsentation des aktuellen Umgebungszustands.
Der resultierende kombinierte Tensor dient als Grundlage für die Generierung der Aktionsmatrix des Agenten. Diese Struktur bietet eine starke Modellanpassungsfähigkeit: Strategische Ziele werden mit taktischen Realitäten in Einklang gebracht. Verhaltensmuster werden flexibler und bleiben dennoch konsistent mit der gesamten Handels-Policy.
Es ist wichtig zu betonen, dass der Controller nicht bloß ein prädiktives Aktionsmodul ist, sondern vielmehr eine semantische Brücke zwischen übergeordneten Absichten und dem konkreten Marktkontext. Er ermöglicht es dem Agenten, sich an kontinuierlich ändernde Marktbedingungen anzupassen und gleichzeitig die strategische Ausrichtung seines Verhaltens beizubehalten.
//--- layer 2 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronHiSSDLowLevelControler; descr.count = HistoryBars; { int temp[] = {latent.layers, // Variables NSkills, // Task Skills latent.count, // Common Skills NActions, // Action Space 4}; // Heads if(ArrayCopy(descr.windows, temp) < (int)temp.Size()) return false; } descr.window = 8; descr.step = 1; descr.window_out = 32; prev_count = descr.windows[0]; prev_out = descr.windows[3]; descr.batch = 1e4; descr.optimization = ADAM; descr.activation = SIGMOID; if(!task.Add(descr)) { delete descr; return false; }
Als Nächstes fahren wir mit der Architektur des übergeordneten Modells Akteur fort, das für die Erstellung der endgültigen Handelsentscheidung verantwortlich ist. Seine Aufgabe ist es, die vom Controller in der vorherigen Stufe vorgeschlagene Aktionsmatrix zu interpretieren. Mit anderen Worten fungiert der Akteur als die endgültige Entscheidungsinstanz, die auf der Grundlage einer Reihe alternativer taktischer Szenarien bestimmt, welches spezifische Verhalten im aktuellen Marktumfeld ausgeführt wird.
Die Architektur des Akteurs wurde vollständig aus unserer früheren Arbeit übernommen. Wir haben uns bewusst dazu entschieden, den aus der Matrix alternativer Strategien generierten Aktionen kein Rauschen hinzuzufügen. Im Gegensatz zu vielen Problemen des RLs, bei denen die Rauschinjektion die Exploration und Diversität fördert, kann an den Finanzmärkten selbst eine minimale Verzerrung der endgültigen Aktion zu katastrophalen Folgen führen. Eine leichte Abweichung bei der Positionsgrößenbestimmung, eine geringfügige Verschiebung der Handelsebenen oder, noch schlimmer, eine Fehlinterpretation der Marktdynamik können zu erheblichen Verlusten und folglich zu einer Verringerung der Systemzuverlässigkeit führen.
Wir haben lediglich eine geringfügige Anpassung am Wahrscheinlichkeitsprognosemodell für die gerichtete Marktbewegung vorgenommen, die sich auf die Verlagerung des latenten Zustands des Umgebungs-Encoders vom allgemeinen Modul zur Fertigkeitsgenerierung zum rekurrenten Block bezieht. Diese kleine, aber wichtige Modifikation zielt darauf ab, die Fähigkeit des Modells zu verbessern, zeitliche Abhängigkeiten zu erfassen und sich dynamisch an veränderte Marktbedingungen anzupassen.
Da das Ziel dieses Abschnitts darin besteht, die Darstellung prägnant zu halten, bieten wir hier keine vollständige und detaillierte Beschreibung dieser Architekturen. Interessierte Leser können sich jedoch für vollständige Implementierungsdetails an die Anhänge wenden.
Fast alle der oben beschriebenen Modelle bilden eine hierarchische Struktur des Akteurs innerhalb des Frameworks Akteur–Direktor–Kritiker. Die nächste Schlüsselkomponente ist der Direktor, ein spezialisiertes Modell, dessen Hauptaufgabe es ist, die vom Akteur generierten Aktionen in profitable und unprofitable zu klassifizieren.
Die Rolle des Direktors ist kaum zu überschätzen: Er fungiert als strategischer Qualitätsfilter, der potenziell verlustbringende Entscheidungen verwirft, bevor sie ausgeführt werden und zu finanziellem Schaden führen. In hochvolatilen Finanzmärkten, in denen jeder Fehler kostspielig ist, wird ein solcher früher Bewertungsmechanismus besonders kritisch.
Ein besonderes Merkmal des vorgeschlagenen Ansatzes ist, dass der Direktor Aktionen nicht nur klassifiziert, sondern auch zusätzliche überwachte Lernsignale generiert. Dies beschleunigt den Anpassungsprozess des Akteurs, da es der Policy ermöglicht, das Feedback des Direktors zu integrieren, ohne dass eine wiederholte Ansammlung negativer Erfahrungen erforderlich ist. Dieser Mechanismus ist besonders effektiv in Umgebungen, in denen die Fehlerkosten hoch und die Lernzeiten begrenzt sind.
In traditionellen Implementierungen erhält der Direktor als Eingabe den Tensor des Umgebungszustands, der direkt die Beobachtungen des Agents widerspiegelt. In unserer Implementierung operiert der Direktor jedoch auf einer allgemeinen Skill-Matrix – einer informativen latenten Repräsentation, die vom Skill-Generierungsmodul am Ausgang des LSTM-Blocks erzeugt wird, welcher darauf vortrainiert wurde, Verhaltensmuster aus multivariaten Zeitreihen zu extrahieren. Diese Repräsentation berücksichtigt bereits die Umgebungsdynamik, filtert irrelevante Signale heraus und konzentriert sich auf die aussagekräftigsten Aspekte des aktuellen Kontextes. Infolgedessen operiert der Direktor in einem komprimierten und stabileren Merkmalsraum, was die Klassifizierungsgenauigkeit, die Entscheidungsstabilität und die Echtzeitanpassungsfähigkeit unter Live-Marktbedingungen erheblich verbessert.
Im Hauptinformationsstrom erhält der Direktor den Aktionstensor des Agenten als Eingabe, der unmittelbar normalisiert wird.
//--- Director director.Clear(); //--- Input layer if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronBaseOCL; descr.count = NActions; descr.activation = None; descr.optimization = ADAM; if(!director.Add(descr)) { delete descr; return false; } //--- layer 1 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronBatchNormOCL; descr.count = NActions; descr.batch = 1e4; descr.activation = None; descr.optimization = ADAM; if(!director.Add(descr)) { delete descr; return false; }
Die direkte Analyse der vom Akteur vorgeschlagenen Aktionen im Kontext der aktuellen Marktbedingungen – kodiert in der allgemeinen Skill-Matrix – erfolgt mithilfe eines Kreuzaufmerksamkeits-Moduls. Hier findet eine semantische Angleichung zwischen dem statt, was der Agent zu tun beabsichtigt, und dem, was durch die aktuelle Marktdynamik tatsächlich gerechtfertigt ist.
Der Kreuzaufmerksamkeits-Mechanismus ermöglicht es dem Direktor, Beziehungen zwischen Komponenten des Aktionstensors und Merkmalen der allgemeinen Skill-Matrix zu identifizieren. Dies ist besonders wichtig in hochvolatilen Märkten, in denen einfache lineare Abhängigkeiten nicht mehr gelten. Die Kreuzaufmerksamkeit ermöglicht es dem Modell effektiv, sich auf diejenigen Aspekte des Verhaltens des Akteurs zu konzentrieren, die in einer gegebenen Situation am kritischsten sind.
//--- layer 2 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronCrossDMHAttention; { int temp[] = {3, // Inputs window latent.count // Cross window }; if(ArrayCopy(descr.windows, temp) < (int)temp.Size()) return false; } { int temp[] = {NActions/3, // Inputs units latent.layers // Cross units }; if(ArrayCopy(descr.units, temp) < (int)temp.Size()) return false; } descr.step = 4; // Heads descr.window_out = 32; descr.batch = 1e4; descr.activation = None; descr.optimization = ADAM; if(!director.Add(descr)) { delete descr; return false; }
Die Ausgabe des Kreuzaufmerksamkeits-Moduls ist eine semantisch angereicherte Repräsentation der Aktion des Akteurs, die bereits an den aktuellen Marktkontext angepasst ist. Diese Repräsentation spiegelt nicht nur die Absicht des Agents wider, sondern auch deren Angemessenheit unter den aktuellen Bedingungen, wobei alle entdeckten Muster und Interaktionen zwischen Aktionen und allgemeinen Skills berücksichtigt werden.
Diese kontextangereicherte Repräsentation bildet die Grundlage für die letzte Verarbeitungsstufe – die Klassifizierung der Aktion im Hinblick auf ihre potenzielle Rentabilität.
Das Klassifizierungsverfahren wird mithilfe einer Sequenz von drei vollständig verbundenen neuronalen Schichten implementiert, die jeweils mit einer eigenen Aktivierungsfunktion ausgestattet sind, um die notwendige Nichtlinearität in die Datentransformation einzuführen. Diese Kaskade ermöglicht es dem Modell, komplexe Entscheidungsgrenzen flexibel zu approximieren, wodurch eine genauere Trennung zwischen profitablen und unprofitablen Aktionen erzielt wird.
In der letzten Schicht wird eine Sigmoid-Aktivierungsfunktion verwendet, wodurch die Ausgabe des Modells als probabilistische Schätzung der Klassenzugehörigkeit interpretiert werden kann. Somit erzeugt das Modell nicht nur eine binäre Entscheidung, sondern liefert auch ein Konfidenzmaß für seine Klassifizierung.
//--- layer 3 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronBaseOCL; descr.count = LatentCount; descr.batch = 1e4; descr.activation = TANH; descr.optimization = ADAM; if(!director.Add(descr)) { delete descr; return false; } //--- layer 4 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronBaseOCL; descr.count = LatentCount; descr.activation = SoftPlus; descr.batch = 1e4; descr.optimization = ADAM; if(!director.Add(descr)) { delete descr; return false; } //--- layer 5 if(!(descr = new CLayerDescription())) return false; descr.type = defNeuronBaseOCL; prev_count = descr.count = 1; descr.activation = SIGMOID; descr.batch = 1e4; descr.optimization = ADAM; if(!director.Add(descr)) { delete descr; return false; }
Es ist anzumerken, dass das Modell von Kritiker in dieser Implementierung ein ähnliches architektonisches Design aufweist. Wie im Fall des Direktors wird ein Kreuzaufmerksamkeits-Modul verwendet, das es dem Kritiker ermöglicht, die vom Akteur vorgeschlagenen Aktionen mit dem aktuellen Umgebungskontext abzugleichen, der durch die allgemeine Skill-Matrix repräsentiert wird. Dies führt zu einer genaueren Bewertung der Aktionsergebnisse, wobei die komplexen Abhängigkeiten zwischen dem Verhalten des Agenten und der latenten Marktdynamik berücksichtigt werden.
Es gibt jedoch einen grundlegenden Unterschied in der letzten Stufe der Architektur von Kritiker. Im Gegensatz zum Direktor, der eine Sigmoid-Funktion zur probabilistischen Interpretation verwendet, enthält die Ausgabeschicht des Kritikers keine Aktivierungsfunktion. Diese Designentscheidung ist durch die Art der Zielvariablen motiviert – den erwarteten kumulativen Ertrag –, die einen weiten und effektiv unbegrenzten Bereich umfassen kann.
Mit anderen Worten, der Kritiker gibt eine skalare Schätzung des Nutzens der vorgeschlagenen Aktion im aktuellen Kontext aus, ausgedrückt in Einheiten des erwarteten Ertrags. Die Anwendung einer begrenzten Aktivierungsfunktion würde diese Größe durch das Abschneiden potenziell wichtiger Abweichungen verfälschen. Daher wird der Endwert direkt erzeugt, was es dem Modell ermöglicht, erlernte Erwartungen der Umgebung frei darzustellen.
Dies ist jedoch nur eine geringfügige architektonische Anpassung. Aus diesem Grund verzichten wir in diesem Artikel auf eine detaillierte Diskussion der Architektur von Kritiker. Eine vollständige architektonische Beschreibung aller Modelle ist im Anhang enthalten und steht für eine selbstständige Vertiefung zur Verfügung.
Leider haben wir nach dieser detaillierten Untersuchung der architektonischen Designentscheidungen den Umfang dieses Artikels im Wesentlichen ausgeschöpft. Wir machen hier eine kurze Pause, und im nächsten Artikel werden wir den Trainingsprozess der Modelle diskutieren und die Wirksamkeit der vorgeschlagenen Lösung anhand realer historischer Daten bewerten.
Schlussfolgerung
In dieser Arbeit haben wir das neue Framework Akteur–Direktor–Kritiker vorgestellt, das für die Lösung von Problemen mittels Deep Learning und neuronalen Netzen entwickelt wurde. Einer der wichtigsten Beiträge dieses Frameworks ist die Einführung des Direktor-Modells, das die Aktionen des Akteurs im Kontext des aktuellen Umgebungszustands klassifiziert und so die Effizienz und Stabilität des Trainingsprozesses erheblich verbessert.
Im praktischen Teil des Artikels haben wir das architektonische Design der trainierbaren Modelle, die die Grundlage des Frameworks Akteur–Direktor–Kritiker bilden, detailliert untersucht. Wir haben die Prinzipien hinter der Verwendung verschiedener Module beschrieben und wichtige Designentscheidungen hervorgehoben, die jeder Komponente des Systems zugrunde liegen.
Im nächsten Artikel werden wir uns auf den Trainingsprozess dieser Modelle konzentrieren und ihre Handelsperformance anhand historischer Marktdaten bewerten.
Referenzen
In diesem Artikel verwendete Programme
| # | Name | Typ | Beschreibung |
|---|---|---|---|
| 1 | Research.mq5 | Expert Advisor | Expert Advisor für die Datenerfassung |
| 2 | ResearchRealORL.mq5 | Expert Advisor | Expert Advisor für die Datenerfassung mit der Methode Real-ORL |
| 3 | Study.mq5 | Expert Advisor | Expert Advisor für das Offline-Modelltraining |
| 4 | StudyOnline.mq5 | Expert Advisor | Expert Advisor für das Online-Modelltraining |
| 4 | Test.mq5 | Expert Advisor | Expert Advisor für die Modelltests |
| 5 | Trajectory.mqh | Klassenbibliothek | Struktur der Beschreibung des Systemzustands und der Modellarchitektur |
| 6 | NeuroNet.mqh | Klassenbibliothek | Eine Bibliothek von Klassen zur Erstellung eines neuronalen Netzes |
| 7 | NeuroNet.cl | Codebibliothek | OpenCL-Programmcode |
Übersetzt aus dem Russischen von MetaQuotes Ltd.
Originalartikel: https://www.mql5.com/ru/articles/17796
Warnung: Alle Rechte sind von MetaQuotes Ltd. vorbehalten. Kopieren oder Vervielfältigen untersagt.
Dieser Artikel wurde von einem Nutzer der Website verfasst und gibt dessen persönliche Meinung wieder. MetaQuotes Ltd übernimmt keine Verantwortung für die Richtigkeit der dargestellten Informationen oder für Folgen, die sich aus der Anwendung der beschriebenen Lösungen, Strategien oder Empfehlungen ergeben.
Marktsimulation: Erste Schritte mit SQL in MQL5 (IV)
Extremaloptimierung (EO)
Von den Grundlagen zur Mittelstufe: Umgang von Mausereignissen
Neuronale Netze im Trading: Skill-Hierarchie für das Verhalten adaptiver Agenten (letzter Teil)
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.