---

Febbraio 2016

Volume 31 Numero 2

Il presente articolo è stato tradotto automaticamente.

Microsoft Azure - Azure Service Fabric, Q-Learning e Tris

Da Gesù Aguilar

Innovazioni di cloud computing sono ridurre gli ostacoli alla voce per l'elaborazione distribuita e applicazioni da tecnologie di nicchia richiedere infrastruttura specializzato e costoso per una merce offerta disponibile per qualsiasi progettista software developer o una soluzione di apprendimento automatico. In questo articolo verrà descritta l'implementazione di una tecnica che sfrutta le funzionalità di elaborazione e di archiviazione distribuite di Azure Service Fabric, l'iterazione successiva dell'offerta di Azure Platform-as-a-Service di apprendimento per rinforzo. Per illustrare l'impatto potenziale di questo approccio, verrà illustrato come è possibile utilizzare l'infrastruttura di servizi e spostare il modello di programmazione Reliable Actors per creare un back-end intelligente grado di stimare il successivo in un gioco del tris. Giochi di guerra, chiunque?

Immettere Q-Learning

Oggi abbiamo vedere soluzioni innovative basate sui dati, ad esempio consigli, faccia tutto il mondo il rilevamento di frodi e riconoscimento. Software engineering team utilizzano l'apprendimento supervisionato e tecniche per implementare tali soluzioni. Nonostante le funzionalità complete di questi approcci, vi sono casi in cui sono difficili da applicare.

Apprendimento per rinforzo è un metodo che gestisce gli scenari che è possibile rappresentare come una sequenza di stati e transizioni. A differenza di altri computer approcci di formazione, apprendimento per rinforzo non tenti di generalizzare modelli dal training di un modello da informazioni con etichettate (apprendimento supervisionato) o da dati senza etichettati (apprendimento non supervisionato). Al contrario, viene analizzato problemi che è possibile modellare come una sequenza di stati e transizioni.

Si supponga di che avere uno scenario che può essere rappresentato come una sequenza di stati che portano allo stato finale (noto come lo stato sull'assorbimento). Considerare un robot per prendere decisioni di evitare ostacoli o intelligenza artificiale (AI) in un gioco progettato per colpire un avversario. In molti casi, la sequenza di stati che portano a una determinata situazione è determina il passaggio successivo migliore per il carattere di robot/agente/AI.

Q-learning è una tecnica che utilizza un meccanismo di premio iterativa per trovare ottimale dei percorsi di transizione in un modello di macchina; lo stato di apprendimento per rinforzo funziona molto bene quando il numero di stati e delle relative transizioni è finito. In questo articolo, illustrerò come ho utilizzato Service Fabric per creare una soluzione di Q-learning end-to-end e Mostra come creare un back-end intelligente che come riprodurre gioco del tris "apprende". (Si noti che gli scenari di computer di stati definiti anche come processi decisionali Markov [multidimensionali]).

In primo luogo, alcune base la teoria su Q-learning. Prendere in considerazione gli Stati e transizioni rappresentate Figura 1. Ad esempio si desidera trovare, a qualsiasi stato, quale stato di un agente è necessario eseguire la transizione a successiva per raggiungere lo stato gold, riducendo al minimo il numero di transizioni. Un modo per gestire questo problema consiste nell'assegnare un valore di premio a ogni stato. Il premio suggerisce il valore della transizione a uno stato verso l'obiettivo: recupero di oro.

Figura 1 sequenza degli stati iniziali per lo stato di oro

Semplice, no? La sfida diventa come identificare il premio per ciascuno stato. L'algoritmo di apprendimento Q identifica premi in modo ricorsivo l'iterazione e l'assegnazione di premi a stati che portano allo stato sull'assorbimento (oro). L'algoritmo calcola premio di uno stato calcolando il valore di premio da uno stato successivo. Se uno stato include due premi, che è possibile che esista uno stato in più di un percorso, la priorità più alta. Lo sconto è un'importante effetto sul sistema. Calcolando il premio, l'algoritmo riduce il valore del premio per gli Stati che sono tutt'altro che l'oro e assegna un peso maggiore per gli stati più vicini per l'oro.

Un esempio di come l'algoritmo calcola il premio, esaminare il diagramma di stato in Figura 1. Come può notare, sono disponibili tre percorsi di oro:

1 -> 5 -> 4 -> C

1 -> 5 -> 3 -> 4 -> C

1 -> 5 -> 3 -> 2 -> 4 -> C

Dopo aver eseguito l'algoritmo utilizzando brute force transizione (scorrere tutti i possibili percorsi nel grafico), l'algoritmo calcola e assegna i premi per i percorsi validi. Premi vengono calcolati utilizzando il fattore di sconto di 0,9.

1(R=72) -> 5(R=81) -> 4(R=90) -> C (R = 100)

1(R=64) -> 5(R=72) -> 3(R=81) -> 4(R=90) -> G(R=100)

1(R=58) -> 5(R=64) -> 3(R=72) -> 2(R=81) -> 4(R=90) -> G(R=100)

Poiché alcuni stati dispongono di più di un premio, prevarrà il valore più alto. Figura 2 illustra l'assegnazione del premio finale.

Figura 2 finale premi

Con queste informazioni, un agente è possibile identificare il percorso ottimale per oro in uno stato con la transizione verso lo stato con la ricompensa maggiore. Ad esempio, se l'agente è in stato 5, ha la scelta di transizione per gli stati 3 o 4, e 4 diventa la scelta in quanto il premio è superiore.

Azure Service Fabric

Service Fabric, l'iterazione successiva dell'offerta di Azure Platform-as-a-Service, consente agli sviluppatori di creare applicazioni distribuite utilizzando due diversi modelli di programmazione principali: Reliable Actors e Reliable Services. Questi modelli di programmazione consentono di ottimizzare le risorse di infrastruttura di una piattaforma distribuita. La piattaforma gestisce le attività più difficili associate con la gestione e l'esecuzione di un'applicazione distribuita, il ripristino da errori, la distribuzione dei servizi per garantire l'utilizzo delle risorse efficiente, in sequenza gli aggiornamenti e controllo delle versioni in modalità affiancata, per citare alcuni.

Service Fabric offre un cluster, offrendo un livello superiore di astrazione da utilizzare, anziché doversi preoccupare dell'infrastruttura sottostante. Il codice viene eseguito sui nodi del cluster di Service Fabric ed è possibile ospitare il cluster a più nodi in un singolo computer a scopo di sviluppo o in più server (macchine fisiche o virtuali) per i carichi di lavoro. La piattaforma gestisce il ciclo di vita dei servizi e di attori e il ripristino da errori dell'infrastruttura.

Service Fabric introduce gli attori affidabili e servizi con la semantica di informazioni sullo stato. Questa funzionalità si traduce in un'esperienza di sviluppo completamente integrato in cui è possibile sviluppare applicazioni che rendono persistenti i dati in modo distribuito e pertanto a disponibilità elevata senza la necessità di includere un livello di archiviazione esterno (ad esempio, creare dipendenza da una risorsa di archiviazione esterna o la memorizzazione nella cache di livello) nell'architettura.

Mediante l'implementazione dell'algoritmo di apprendimento Q come servizio all'interno di Service Fabric, possono beneficiare con distributed computing e a bassa latenza funzionalità di archiviazione dello stato, che consente di eseguire l'algoritmo, mantenere i risultati ed espongono tutto come affidabile i punti di fine per i client di accedere. Tutte queste funzionalità si riuniscono in un'unica soluzione con una programmazione unificata e stack di gestione. Non è necessario aggiungere i componenti aggiuntivi all'architettura, ad esempio un'archiviazione esterna, cache o sistema di messaggistica. In breve, si dispone di una soluzione in cui il calcolo, dati e servizi si trovano all'interno della stessa piattaforma integrata. Che è una soluzione elegante nel mio libro!

Attori Q-Learning e affidabili

Il modello actor semplifica la progettazione di applicazioni altamente simultanee. Nel modello attore, gli attori sono l'unità fondamentale di elaborazione. Un attore rappresenta un limite di funzionalità e stato. Può essere considerato di un attore come un'entità di oggetti che risiedono in un sistema distribuito. Service Fabric gestisce il ciclo di vita dell'attore. In caso di errore, Service Fabric nuovamente crea un'istanza dell'attore in un nodo integro automaticamente. Ad esempio, se si arresta un attore con stato per il nodo (interazione utente macchina virtuale) è in esecuzione in caso di errore o un qualsiasi motivo, l'attore è ripristinata automaticamente in un altro computer con il relativo stato (dati) intatto.

Service Fabric gestisce inoltre l'accesso a un'istanza di un attore. La piattaforma garantisce che in qualsiasi momento, solo un metodo su un determinato attore è in esecuzione contemporaneamente. Se sono presenti due chiamate simultanee a quello stesso attore, Service Fabric verrà una coda e consentire altri passare. L'implicazione è che all'interno di un attore il codice non deve preoccuparsi di condizioni di competizione, blocchi o sincronizzazione.

Come descritto in precedenza, l'algoritmo di apprendimento Q scorre stati con l'obiettivo della ricerca sull'assorbimento stati e con premi. Una volta che l'algoritmo identifica uno stato sull'assorbimento con un premio, viene calcolato premi per tutti gli stati di determinare lo stato sull'assorbimento.

Utilizzando il modello, è possibile modellare questa funzionalità come un attore che rappresenta uno stato nel contesto dell'algoritmo di apprendimento Q (è possibile fasi nel grafico generale). In questa implementazione, il tipo di attore che rappresenta questi stati è QState. Una volta che si verifica una transizione a un attore QState contenente un premio, l'attore QState creerà un'altra istanza dell'attore di un tipo diverso (QTrainedState) per ognuno degli attori QState il percorso. Attori QTrainedState mantenere il valore massimo premio e un elenco di stati successivi che producono il premio. L'elenco contiene i token di stato (che identifica in modo univoco un stato nel grafico) degli stati successivi.

In Figura 3, illustrano la logica dell'algoritmo utilizza gli attori, per uno scenario molto semplice in cui uno stato con token stato 3 è stato sull'assorbimento, contiene un premio pari a 100 e ha un solo percorso con due stati precedenti (token stato 1 e 2). Ogni cerchio rappresenta un'istanza di un attore, QStates in blu e QTrainedStates in arancione. Una volta che il processo di transizione raggiunge QState con token stato 3, l'attore QState creerà due QTrainedStates, uno per ogni QStates precedente. Dell'attore QTrainedState che rappresenta il token di stato 2, la transizione suggerita (per un premio di 90) è allo stato 3 token e dell'attore QTrainedState che rappresenta il token di stato 1, la transizione suggerita (per un premio di 81) è in stato 2 token.

Figura 3 determinazione e la conservazione premia

È possibile che più stati restituirà i benefici ottenuti dalla stessa, pertanto l'attore QTrainedState mantiene una raccolta di token di stato come stati degli elementi figlio.

Il codice seguente viene illustrata l'implementazione delle interfacce per gli attori QState e QTrainedState, denominato IQState e IQTrainedState. QStates hanno due comportamenti: processo in fase di transizione per altri QStates e avvio la transizione quando è presente alcuna transizione precedente:

public interface IQState : IActor
{
  Task StartTrainingAsync(int initialTransitionValue);
  Task TransitionAsync(int? previousStateToken, int transitionValue);
}
public interface IQTrainedState:IActor
{
 .Task AddChildQTrainedStateAsync(int stateToken, double reward);
 .Task<List<int>> GetChildrenQTrainedStatesAsync();
}

Si noti che l'implementazione di IQTrainedState copre il metodo GetChildrenQTrainedStatesAsync. Questo metodo è come l'attore QTrainedState esporrà i dati di training contenente gli Stati con il valore più alto di premio per qualsiasi stato del sistema. Si noti che tutti gli attori nell'infrastruttura del servizio devono implementare un'interfaccia derivata da IActor.

QState attore

Dopo aver definito le interfacce, è possibile spostare l'implementazione degli attori. Inizierò con l'attore QState e il metodo TransitionAsync, che è il fulcro dell'algoritmo e in cui risiede la maggior parte del lavoro. TransitionAsync effettua la transizione a un altro stato creando una nuova istanza di un attore QState e chiamare nuovamente il metodo stesso.

Ci si potrebbe chiedere se chiamando il metodo in modo ricorsivo è necessario evitare l'overhead della chiamata del metodo in un'altra istanza dell'attore. Una chiamata al metodo ricorsiva è un'operazione a elevato utilizzo di calcolo in un singolo nodo. Al contrario, creando un altro attore, si sta assumendo advantange delle funzionalità di Service Fabric, consentendo la piattaforma di distribuire l'elaborazione tra le risorse di elaborazione orizzontale.

Per gestire l'assegnazione di un premio, procederà alla registrazione di un promemoria. I promemoria vengono introdotti nel modello di programmazione attore nuovi costrutti che consentono di pianificare il lavoro asincrono senza bloccare l'esecuzione di un metodo.

I promemoria sono disponibili solo per gli attori con stato. Per gli attori con e senza stati, la piattaforma fornisce i timer che consentono di modelli analoghi. Una considerazione importante è che quando viene utilizzato l'attore, il processo di garbage collection è posticipato; Tuttavia, la piattaforma non considera i callback del timer di utilizzo. Se il garbage collector viene avviato, il timer verrà arrestato. Gli attori sarà sottoposto a garbage collection durante l'esecuzione di un metodo. Per garantire l'esecuzione periodica, utilizzare i promemoria. Ulteriori informazioni sono reperibili in bit.ly/1RmzKfr.

L'obiettivo, è in relazione all'algoritmo, per eseguire l'assegnazione di premio senza bloccare il processo di transizione. In genere, è sufficiente la pianificazione di un elemento di lavoro nel pool di thread a un callback; Tuttavia, nel modello di programmazione attore, questo approccio non è una buona idea, si perderanno i vantaggi della concorrenza della piattaforma.

La piattaforma garantisce che solo un metodo viene eseguito in qualsiasi momento. Questa funzionalità consente di scrivere il codice senza considerare la concorrenza; vale a dire, senza doversi preoccupare thread-safe. Come può immaginare, vi è un compromesso: È necessario evitare la creazione di attività o thread per eseguire il wrapping di operazioni all'interno dei metodi degli attori. I promemoria consentono di implementare scenari di elaborazione in background con le garanzie di concorrenza della piattaforma, come illustrato nella Figura 4.

Figura 4 TransitionAsync nella classe QState

public abstract class QState : StatefulActor, IQState, IRemindable
{
  // ...
  public Task TransitionAsync(int? previousStateToken, int transitionValue)
  {
    var rwd = GetReward(previousStateToken, transitionValue);
    var stateToken = transitionValue;
    if (previousStateToken != null)
        stateToken = int.Parse(previousStateToken.Value + stateToken.ToString());
    var ts = new List<Task>();
    if (rwd == null || !rwd.IsAbsorbent)
      ts.AddRange(GetTransitions(stateToken).Select(p =>
        ActorProxy.Create<IQState>(ActorId.NewId(),
        "fabric:/QLearningServiceFab").TransitionAsync(stateToken, p)));
    if (rwd != null)
      ts.Add(RegisterReminderAsync("SetReward",
        Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(rwd))
        , TimeSpan.FromMilliseconds(0)
        , TimeSpan.FromMilliseconds(-1), ActorReminderAttributes.Readonly));
      return Task.WhenAll(ts);
  }
  // ...
}

Si noti che l'impostazione dueTime su TimeSpan.FromMilliseconds(0)) indica un'esecuzione immediata.

Per completare l'implementazione di IQState, il codice seguente implementa il metodo StartTransitionAsync, in cui è utilizzato un promemoria per evitare una chiamata di blocco a esecuzione prolungata:

public Task StartTrainingAsync(int initialTransitionValue)
  {
    return RegisterReminderAsync("StartTransition",
      Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(new { TransitionValue =
      initialTransitionValue })), TimeSpan.FromMilliseconds(0),
      TimeSpan.FromMilliseconds(-1),
      ActorReminderAttributes.Readonly);
  }

Per completare l'implementazione della classe QState, verrà descritta l'implementazione del SetRewardAsync e i metodi ReceiveReminderAsync, Figura 5. Il metodo SetReward crea o aggiorna un attore con stato (l'implementazione di IQTrainedState). Per individuare l'attore nelle chiamate successive, utilizzare il token di stato come l'id dell'attore, gli attori sono indirizzabili.

Figura 5 il SetRewardAsync e i metodi ReceiveReminderAsync

public Task SetRewardAsync(int stateToken, double stateReward, double discount)
  {
    var t = new List<Task>();
    var reward = stateReward;
    foreach (var pastState in GetRewardingQStates(stateToken))
    {
      t.Add(ActorProxy
        .Create<IQTrainedState>(new ActorId(pastState.StateToken),
          "fabric:/QLearningServiceFab")
        .AddChildQTrainedStateAsync(pastState.NextStateToken, reward));
      reward = reward * discount;
    }
    return Task.WhenAll(t);
  }
public async Task ReceiveReminderAsync(string reminderName,
  byte[] context, TimeSpan dueTime, TimeSpan period)
  {
    await UnregisterReminderAsync(GetReminder(reminderName));
    var state = JsonConvert.DeserializeObject<JObject>(
      Encoding.UTF8.GetString(context));
    if (reminderName == "SetReward")
    {
      await SetRewardAsync(state["StateToken"].ToObject<int>(),
        state["Value"].ToObject<double>(),
        state["Discount"].ToObject<double>());
    }
    if (reminderName == "StartTransition")
    {
      await TransitionAsync(null, state["TransitionValue"].ToObject<int>());
    }
  }

QTrainedState attore

Il secondo attore nella soluzione è QTrainedState. I dati di attore QTrainedState devono essere durevoli, pertanto ho implementato attore come un attore con stato.

In Service Fabric si implementa un attore con stato derivando la classe da StatefulActor o le classi di base StatefulActor < T > e implementa un'interfaccia derivata da IActor. T è un tipo di riferimento e il tipo dell'istanza dello stato, che deve essere serializzabile. Quando si chiama un metodo di una classe derivata da StatefulActor < T >, la piattaforma Carica lo stato dal provider di stato e una volta completata la chiamata, la piattaforma viene salvato automaticamente. Nel caso di QTrainedState, modellato lo stato (dati durevoli) utilizzando la classe seguente:

[DataContract]
public class QTrainedStateState
{
  [DataMember]
  public double MaximumReward { get; set; }
  [DataMember]
  public HashSet<int> ChildrenQTrainedStates { get; set; }
}

Figura 6 viene illustrata l'implementazione completa della classe QTrainedState, che implementa due metodi dell'interfaccia IQTrainedState.

Figura 6 classe QTrainedState

public class QTrainedState : StatefulActor<QTrainedStateState>, IQTrainedState
{
  protected async override Task OnActivateAsync()
  {
    this.State =
      await ActorService.StateProvider.LoadStateAsync<QTrainedStateState>(
      Id, "qts") ??
      new QTrainedStateState() { ChildrenQTrainedStates = new HashSet<int>() };
    await base.OnActivateAsync();
  }
  protected async override Task OnDeactivateAsync()
  {
    await ActorService.StateProvider.SaveStateAsync(Id, "qts", State);
    await base.OnDeactivateAsync();
  }
  [Readonly]
  public  Task AddChildQTrainedStateAsync(int stateToken, double reward)
  {
    if (reward < State.MaximumReward)
    {
      return Task.FromResult(true);
    }
    if (Math.Abs(reward - State.MaximumReward) < 0.10)
    {
      State.ChildrenQTrainedStates.Add(stateToken);
      return Task.FromResult(true);
    }
      State.MaximumReward = reward;
      State.ChildrenQTrainedStates.Clear();
      State.ChildrenQTrainedStates.Add(stateToken);
      return Task.FromResult(true);
  }
  [Readonly]
  public Task<List<int>> GetChildrenQTrainedStatesAsync()
  {
    return Task.FromResult(State.ChildrenQTrainedStates.ToList());
  }
}

Esponendo gli attori

A questo punto, la soluzione contiene tutti gli strumenti necessari per avviare il processo di training e rendere persistenti i dati. Ma non ancora trattato come client di interazione con gli attori. In generale, questa interazione è costituito da avviare il processo di training e sulle query dei dati persistenti. Ognuna di queste interazioni correla perfettamente con un'operazione API, e un'implementazione RESTful facilita l'integrazione con i client.

Oltre a disporre di due modelli di programmazione, Service Fabric è una piattaforma di gestione processo e l'orchestrazione completa. L'errore ripristino e gestione delle risorse disponibile per gli attori e i servizi è disponibile anche per altri processi. Ad esempio, è possibile eseguire processi ASP.NET 5 o Node. js, gestiti da Service Fabric e sfruttano queste funzionalità senza ulteriori interventi. Quindi, posso semplicemente utilizzare un'applicazione API Web ASP.NET 5 standard e creare un controller di API che espone la funzionalità dell'attore pertinenti, come illustrato nella Figura 7.

Figura 7 il Controller API

[Route("api/[controller]")]
public class QTrainerController : Controller
{
  [HttpGet()]
  [Route("[action]/{startTrans:int}")]
  public  async Task<IActionResult>  Start(int startTrans)
  {
    var actor = ActorProxy.Create<IQState>(ActorId.NewId(),
      "fabric:/QLearningServiceFab/");
    await actor.StartTrainingAsync(startTrans);
    return Ok(startTrans); 
  }
  [HttpGet()]
  [Route("[action]/{stateToken}")]
  public async Task<int> NextValue(int stateToken)
  {
    var actor = ActorProxy.Create<IQTrainedState>(new ActorId(stateToken),
      "fabric:/QLearningServiceFab");
    var qs = await actor.GetChildrenQTrainedStatesAsync();
    return qs.Count == 0 ? 0 : qs[new Random().Next(0, qs.Count)];
  }
}

E gioco del tris?

Rimane ora è necessario utilizzare la soluzione con uno scenario concreto. A tale scopo, si utilizzerà un semplice gioco: gioco del tris.

L'obiettivo è per il training di un set di QTrainedStates che è possibile eseguire query per stimare il passaggio successivo in un gioco del tris. È possibile considerare è che la macchina è funge da entrambi i lettori e formazione tra i diversi risultati.

Tornando all'implementazione, si noti che QState è una classe astratta. L'idea è per incapsulare le caratteristiche principali dell'algoritmo e inserire la logica dello scenario specifico in una classe derivata. Uno scenario definisce tre parti dell'algoritmo: come (criterio) si verifica la transizione tra Stati; gli Stati sono sull'assorbimento e hanno un premio iniziale; e gli Stati dell'algoritmo assegnerà un premio con uno sconto. Per ognuna di queste parti, la classe QState dispone di un metodo in cui è possibile implementare questa semantica per risolvere uno scenario specifico. Questi metodi sono GetTransitions, GetReward e GetRewardingQStates.

Pertanto, la domanda da porsi: Come è possibile modellare un gioco del tris come una sequenza di stati e transizioni?

Prendere in considerazione il gioco rappresentato Figura 8, in cui ogni cella è assegnato un numero. È possibile considerare ogni turno come una transizione da uno stato a altro in cui il valore di transizione è la cella in cui Windows Media player effettua un gioco. Ogni token di stato è quindi una combinazione dell'attiva precedenti (celle) e il valore di transizione. Ad esempio, in Figura 8, una transizione da 1 a 14, quindi ad 142 e così via, modella i passaggi necessari per il gioco in cui il giocatore che riprodotto il primo attivare wins. E in questo caso, tutti gli Stati che portano a 14273 (stato confermato e sull'assorbimento) devono essere assegnati un premio: 1 e 142.

Figura 8, lo Scenario di gioco del tris

Tornando al Q-learning, è necessario fornire sono tutti finali (sull'assorbimento) gli stati, ognuno con un premio iniziale. Per gioco del tris, tre tipi di stati produrrà un premio: un successo, un valore equivalente o un blocco (fare riferimento a un punto quando l'avversario sta per essere vince, pertanto è necessario utilizzare una alla volta per bloccare gli). Un successo e parità sono sull'assorbimento, vale a dire la partita finisce; un blocco, non è tuttavia e continua il gioco. Figura 9 viene illustrata l'implementazione del metodo GetReward per il gioco del tris.

Figura 9 il metodo GetReward

internal override IReward GetReward(int? previousStateToken, int transitionValue)
{
  var game = new TicTacToeGame(previousStateToken,transitionValue);
  IReward rwd = null;
  if (game.IsBlock)
  {
    rwd = new TicTacToeReward() { Discount = .5, Value = 95, IsAbsorbent = false,
      StateToken = game.StateToken};
  }
  if (game.IsWin)
  {
    rwd = new TicTacToeReward() { Discount = .9, Value = 100, IsAbsorbent = true,
      StateToken = game.StateToken };
  }
  if (game.IsTie)
  {
    rwd = new TicTacToeReward() { Discount = .9, Value = 50, IsAbsorbent = true,
      StateToken = game.StateToken };
  }
  return rwd;
}

Successivamente, dopo uno stato viene identificato con un premio, è necessario fornire all'algoritmo con gli Stati che ha lo stato con un premio iniziale può essere assegnato un premio scontato. Per gli scenari di Windows o un blocco, sono elencati tutti gli stati precedenti (riproduzione) di Windows Media player vincente o di blocco. Per valori equivalenti, è necessario assegnare a tutti gli stati (riproduzione) di entrambi i lettori un premio:

internal override IEnumerable<IPastState> GetRewardingQStates(int stateToken)
{
  var game = new TicTacToeGame(stateToken);
  if (game.IsTie)           
    return game.GetAllStateSequence();           
  return game.GetLastPlayersStateSequence();
}

Infine, è necessario implementare i criteri che determinano come l'algoritmo scorrerà gli stati di transizione. Per il gioco, si implementerà un criterio di transizione in cui vengono esaminate tutte le possibili combinazioni:

internal override IEnumerable<int> GetTransitions(int stateToken)
{
  var game = new TicTacToeGame(stateToken);
  return game.GetPossiblePlays();
}

Riproduzione su computer

A questo punto, è possibile pubblicare la soluzione e avviare la formazione dall'API REST chiamante e fornendo le transizioni iniziale: da 1 a 9.

Una volta al termine della formazione, è possibile utilizzare l'API per creare un'applicazione che è possibile semplicemente passare un token di stato e ricevere il valore consigliato. Il codice sorgente per questo articolo contiene un'applicazione di piattaforma UWP che utilizza il back-end. Figura 10 Mostra il gioco.

Figura 10 A gioco del tris

Avvolgendo

Utilizzando Service Fabric e Q-learning, è stato possibile creare un framework end-to-end che si basa su una piattaforma distribuita per calcolare e mantenere i dati. Per illustrare questo approccio, il gioco del tris ho utilizzato per creare un back-end che possa imparare a utilizzare il gioco e a tale scopo, un livello accettabile solo che indica quando si verifica un successo, un valore equivalente o un blocco e consentendo la macchina di informazioni per l'esecuzione del gioco.

---

Jesus Aguilarè un architetto di cloud senior presso Microsoft nel team di sviluppo e di evangelizzazione tecnica in cui si collabora con aziende a questo punto, sono nati nel cloud e consente di realizzare esperienze accattivanti su vasta scala. Sua passione per la progettazione del software e di progettazione della soluzione, e si rileverà la sua attenzione utilizzando termini quali "Analisi predittiva," "Scalabilità", "Concorrenza", "Modelli di progettazione" e "< scegliere qualsiasi lettera > servizio app di Azure." È possibile seguirlo su Twitter: @giventocode ed estrarre il suo blog all'indirizzo giventocode.com.

Grazie ai seguenti esperti tecnici Microsoft per la revisione di questo articolo: Rob Bagby, Mike Lanzetta e Matthew Snider
Ezio Alboni sono un Senior Architetto di cloud per Microsoft. In questo ruolo, Rob funziona con gli ISV influenti, consentendo loro di implementare il proprio software in Azure. Prima di questo ruolo, Rob ha lavorato come consulente compilazione loosely coupled, gestibili e scalabili, sistemi.

Mike Lanzetta è uno sviluppatore del team Catalyst Partner Microsoft, con particolare attenzione nei sistemi di programmazione, Big Data e Machine Learning. Egli ha una MS in CSE dall'università di Washington ed è stato nel settore oltre 20 anni società compreso neo-imprese e Amazon e Microsoft.

Matt Snider parte di Microsoft nel 2008, lavorando a una piccola parte di .NET. Dopo aver spedito .NET 4, ha aggiunto il team di Service Fabric come primo tecniche PM, lavorando tutte le aree di funzionalità diverso ed è stato con il team da allora. Questi giorni si occupa principalmente in Gestione Cluster di risorse (Orchestrator), le raccolte Reliable Collections e le parti di Failover/replica dello stack. Quando si lavora non in sistemi distribuiti, ama beer ed escursioni, alla musica.