Validera simuleringen för maskinlärning

Träningsmotorn Bonsai använder förstärkt inlärning (RL) för att strukturera maskinlärning för hjärnan. Simuleringar stöder förstärkt inlärning med data och en interaktiv miljö för iterativ träning. Men alla simuleringar är inte kompatibla med maskinutbildning. Det är viktigt att verifiera beredskapen för simuleringen för att kunna träna en hjärna med Bonsai.

Viktigt

Stegen nedan representerar de grundläggande metodtipsen för simuleringsverifiering. Slutligen kräver utvecklingen av en omfattande, domänrelevell valideringsprocess situationsspecifika experiment och jämförelser med verkliga data. Målet med en valideringsplan bör vara att identifiera och åtgärda kritiska luckor mellan din simulerade miljö och den verkliga miljö där hjärnan ska distribueras.

Innan du börjar

  • Se till att du kan interagera med simuleringen programmatiskt. Du kan använda val av programmeringsspråk.
  • Se till att har Bonsai stöd för din simuleringsplattform (eller språk).

Steg 1: Verifiera din step-funktion

För att stödja förstärkt inlärning måste simulatorn svara på iterativa informationsändringar. För att hantera iterativa ändringar måste simuleringen innehålla en stegfunktion. Stegfunktionen accepterar indatavariabler (åtgärd) och returnerar utdatavärden (tillstånd) såvida inte ett terminaltillstånd inträffar.

  • Indatavariabler representerar åtgärder som vidtas av Bonsai hjärnan under den föregående iterationen.
  • Utdatavariabler ger resultatinformation som hjärnan kommer att använda under den aktuella iterationen.

Tänk dig till exempel en apiary HVAC-simulering som styr temperaturen genom att manipulera utfiskande reglage. Antalet och positionen för öppna öppningar är indatavariablerna. Apiaryens interna temperatur är utdatatillståndet. För att kunna arbeta med maskinlärning måste simuleringen tillåta iterativa ändringar av positionen och antalet öppna öppningar och returnera den nya temperaturen vid varje iteration.

Så här verifierar du din stegfunktion:

  1. Bekräfta att uppsättningen förväntade indatakontrollåtgärder matchar, eller är en supermängd av, den uppsättning åtgärder som din hjärna tränar med.
  2. Bekräfta att din stegfunktion är deterministisk. Med andra ord har alla möjliga indata ett motsvarande utdatatillstånd eller terminalvillkor.
  3. Bekräfta att informationen om utdatatillståndet använder rätt enheter. Om hjärnan till exempel förväntar sig temperatur i Celsius bekräftar du att simuleringen inte skickar temperaturinformation iRankvins.

Steg 2: Verifiera terminalvillkoren och återställningsfunktionen

En viktig del av iterativ simulering är att veta när processen ska stoppas och återställas. Terminaltillstånd låter simuleringen veta när hjärnan har nått en punkt där återställning inte längre är möjlig. Temperaturen i ett apiary har till exempel nått en punkt där bin har avlidit.

När ett terminaltillstånd inträffar bör din återställningsfunktion återställa miljön i simuleringen till det förväntade starttillståndet så att hjärnan kan försöka igen.

Så här kontrollerar du terminalvillkoren och återställningsfunktionen:

  1. Bekräfta att terminalvillkoren faktiskt kan uppstå som en del av simuleringens utdata. Om din apiary-simulering till exempel har angetts i en miljö där miljön är liten och simuleringen bara avslutas när temperaturen sjunker under fryspunkten avslutas den aldrig.
  2. Bekräfta att din återställningsfunktion exponeras för användarna så att den kan anropas av Bonsai plattformen.
  3. Kontrollera att du hanterar gränsfall på rätt sätt. Om det till exempel är möjligt att temperaturer ändras med mer än 1 grad i en iteration kontrollerar du om det finns värden som är större än ett brytvärde i stället för likhet.

Steg 3: Verifiera dina konfigurationsvariabler

Simulatorn bör ha stöd för initiering av miljövariabler så Bonsai att hjärnan kan träna mot en mängd olika scenarier. Till exempel bör en apiary HVAC-simulering ha stöd för alla rimliga starttemperaturer.

Så här verifierar du dina konfigurationsvariabler:

  1. Bekräfta att uppsättningen tillgängliga konfigurationsvariabler omfattar all relevant information om starttillståndet.
  2. Bekräfta att konfigurationsvariablerna kan anges av din återställningsfunktion.
  3. Bekräfta enheterna mellan simuleringen och hjärnan eller konverteras på rätt sätt.

Steg 4: Utforma ett bastestprotokoll

Ett bastestprotokoll upprättar ett enkelt (bas) fall och kör simuleringsstegen i en loop för det fallet ett fördefinierat antal iterationer. Använd genererade utdata för närmare analys för att bekräfta att simulatorn fungerar som förväntat.

Ditt grundläggande testprotokoll är beroende av två mått:

  • Kontrollfrekvens (CF): hur ofta hjärnan vidtar åtgärder för att kontrollera den simulerade miljön som ett mått på händelser per mått, vilket vanligtvis anges i Hertz (Hz). Måttet för kontrollfönstret bör återspegla det verkliga måttet (tid, avstånd) som du förväntar dig att den tränade hjärnan ska använda när du utvärderar och vidta åtgärder för att kontrollera den verkliga miljön.
  • Simuleringstid (ST): hur lång tid det tar att simulera det önskade kontrollfönstret i realtid. St för en viss iteration varierar beroende på simuleringens komplexitet.

För att fastställa en lämplig kontrollfrekvens kan du beräkna antalet kontrollhändelser som hjärnan ska hantera i en meningsfull enhet av kontrollmåttet. Tidsbaserade kontrollsystem beräknar vanligtvis CF i händelser per sekund medan avståndsbaserade kontrollsystem vanligtvis beräknar CF i händelser per mätare.

Anta till exempel att du vill att apiary HVAC-hjärnan ska utvärdera apiary-tillståndet och vidta åtgärder var 100:e timme när den distribueras. För att effektivt efterlikna produktionsmiljön bör varje tränings iteration simulera ett 100 ms-fönster med en kontrollåtgärd per iteration.

1 händelse var 100 ms → 1händelse100 / ms

1 000 ms per sekund → (1händelse100 / ms) × (1 000 ms1 / sekund) → målfrekvensen är 10 kontrollhändelser per sekund

Per definition:

1 Hz = 1 händelse per sekund

För att bekräfta att simuleringen replikerar miljön på rätt sätt bör därför bastestprotokollet använda en kontrollfrekvens på 10 Hz.

Anteckning

Det är vanligt att definiera kontrollfrekvensen för Hertz, men det krävs inte. I slutändan behöver du avgöra hur många kontrollhändelser du vill ha för ett visst mått. När du vet hur ofta kontrollhändelserna ska inträffa kan du fastställa resten av testvariablerna.

När du har beräknat kontrollfrekvensen kan du använda följande steg för att utforma ett allmänt basprotokoll som du kan anpassa efter simuleringens specifika funktioner:

  1. Kör simuleringen med en standardkonfiguration för att generera en typisk loggfil.
  2. Baserat på CF och loggfilen fastställer du det maximala antalet iterationer som du vill tillåta för träningsavsnitt.
  3. Kontrollera att du kan beräkna och logga följande information för varje iteration av testet:
    1. Alla utdata tillstånd som tillhandahålls av simulatorn.
    2. Det faktiska CF-värdet som uppnås av simuleringen.
    3. ST-värdet för iterationen.
  4. Analysera relationen mellan indata och utdata för loggfilen för att identifiera ett enkelt konfigurationsscenario (test).
  5. Definiera minst ett fast testscenario. Välj en lämplig startkonfiguration och fastställ förväntade kontrollåtgärder (principsvar) för varje iteration av testscenariot.
  6. Definiera minst ett scenario för slumpmässig testning. För en godtycklig startkonfiguration skriver du testkod som slumpmässigt väljer en av de tillgängliga kontrollåtgärderna för varje iteration av testscenariot.
  7. Skriv testkod för att anropa stegfunktionen med önskade indata (fasta eller slumpmässiga) för varje iteration och upprepa processen tills den når ett terminalvillkor eller det maximala antalet iterationer som du fastställde tidigare.

Steg 5: Kör ett bastestprotokoll

Simuleringsvalidering är en iterativ process. Du bör förvänta dig att köra testprotokollet flera gånger med olika startkonfigurationer och köra om protokollet när du gör justeringar i simuleringen.

Tips

För bästa resultat bör du ha flera konfigurationer definierade för dina fasta och slumpmässiga principer.

För varje testkörning:

  1. Ange simulatorn med det ursprungliga tillståndet för testscenariot.
  2. Kör simuleringen med olika indata för det fasta testscenariot.
  3. Kör simuleringen med olika indata i scenariot för slumpmässig testning.
  4. Kör simuleringen för ett stort antal iterationer så att en återställning kan ske.
  5. Kör simuleringen och tvinga fram en återställning vid en slumpmässig punkt.
  6. Kör simuleringen med en inledande konfiguration som tvingar fram en återställning.

Steg 6: Analysera resultatet av testet

Det finns inget rätt sätt att analysera resultatet av ett simuleringstest. Vissa metodtips anges nedan, men du bör också förlita dig på din kreativitet och ämnesexpertis för att utvärdera simuleringens beteende. Genom att rita ut dina resultat som indata kontra utdata blir det enklare att analysera simulatorbeteendet och kommunicera resultaten till andra.

Utvärdera tillförlitlighet

Tillförlitligheten för simuleringen relaterar direkt till relationen mellan indata och utdata (åtgärdstillstånd) i basprotokollet. Om du kör samma scenario med en fast kontrollprincip och en princip för slumpmässig kontroll blir det enklare att fastställa tillförlitligheten:

  • Den fasta principen bör resultera i ett välförstått resultat.
  • Den slumpmässiga principen genererar oväntade villkor i simulatorn.

Den fasta principen hjälper dig att verifiera ett bra beteende medan den slumpmässiga principen hjälper dig att identifiera gränsfall där simuleringen är långsam, fastnar eller träffar på andra problem.

I till exempel apiary HVAC-simuleringen bör öppningen av en vak sänka temperaturen i api-aryen. Om temperaturen ökar i stället indikerar det att simuleringen är buggig.

Utvärdera flexibilitet

Flexibiliteten i simuleringen relaterar direkt till hur väl den hanterar olika konfigurationer. Granska loggarna för dina fasta och slumpmässiga kontrollprinciper. För var och en av startkonfigurationerna ska du avgöra om motsvarande ändringar i den simulerade miljön är meningsfulla.

Om du till exempel ändrar storlek och antal av beter sig i api-aryen bör det ha en motsvarande ändring i hur snabbt eller långsamt temperaturen ändras när öppningarna öppnas.

Utvärdera återställning

En viktig del av maskinlärning är möjligheten att återställa träningsmiljön när det behövs. Kontrollera testloggarna för alla platser där ett terminaltillstånd inträffade och miljöåterställningen. Observera simulatortillståndet, de resulterande åtgärderna när återställningen inträffade och om beteendet är logiskt i den kontexten.

Viktigt

Om du ser ett falskt positivt eller falskt negativt terminaltillstånd indikerar det att simuleringen är buggig.

Återställdes till exempel apiary HVAC när den interna temperaturen nådde en punkt där alla anläggningar i miljön skulle bli utsvugna och fördrugna? Var den nya interna temperaturen efter återställningen meningsfull som en starttemperatur?

Utvärdera den simulerade kontrollfrekvensen

Om du planerar att distribuera din hjärna på maskinvara i stället för att installera den som programvara ska den simulerade kontrollfrekvensen vara lika med, eller en faktor för, den verkliga kontrollfrekvens som du förväntar dig att se i produktion. På så sätt kan ditt steg loopa så många gånger som behövs för att hålla simuleringen CF i linje med den förväntade maskinvaran CF.

Om maskinvaran för hjärnan till exempel har en CF på 100 Hz måste simuleringen tillåta indata vid var 10:e ms av den verkliga simuleringen.

1 Hz = 1 händelse per sekund → 100 Hz = 100 händelser per sekund

1 000 ms per sekund → 1 000ms100 / händelser = 10 ms per händelse

Simuleringskontroller på 1 ms, 2 ms och 5 ms fungerar också. I varje fall kan simulatorn loopa genom stegfunktionen ytterligare gånger för att uppnå önskad kontrollfrekvens.

Simulerat kontrollfönster Nödvändiga loopar Simulerad CF
1 ms 10 1 000 Hz
2 ms 5 500 Hz
5 ms 2 200 Hz

Utvärdera simuleringstiden

Beräkna det genomsnittliga ST-värdet för alla iterationer för alla testkörningar. För att kunna arbeta tillförlitligt med maskinlärning Bonsaioch måste den genomsnittliga st för simuleringen vara ≤ 20 sekunder.

Om din genomsnittliga st är över tröskelvärdet som stöds betraktas det som en långsam simulator och kan inte ge hjärnan en realistisk modell för träning.

Nästa steg

När du har verifierat simulatorn kan du prova att köra den lokalt mot en grundläggande indelningsfil för att börja integrera med Bonsai.