un approccio per la generazione di scenari di test in sistemi ... · distribuito: loki. in ne,...

Facoltà di IngegneriaCorso di Studi in Ingegneria Informatica

tesi di laurea specialistica

Un approccio per la generazione di scenari di test in sistemi distribuiti basato su Reinforcement Learning.

Anno Accademico 2010/2011

relatoreCh.mo prof. Domenico Cotroneo

correlatoreIng. Roberto Natella

candidatoFrancesco Fuccimatr. 885/000528

Indice

Ringraziamenti 2

Introduzione 4

1 Concetti fondamentali e motivazioni 6

1.1 Contesto del problema . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Un caso di studio sulla tolleranza ai guasti di concorrenza . . . 9

1.2.1 Guasti di concorrenza . . . . . . . . . . . . . . . . . . 9

1.2.2 Il middleware CARDAMOM . . . . . . . . . . . . . . . 10

1.2.3 L’applicazione FDPS . . . . . . . . . . . . . . . . . . . 11

1.2.4 Un esempio d’inizione . . . . . . . . . . . . . . . . . . 12

1.3 Fault injection nei sistemi distribuiti . . . . . . . . . . . . . . 13

1.3.1 Loki . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4 Un approccio ”intelligente” . . . . . . . . . . . . . . . . . . . . 16

1.5 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Reinforcement Learning 21

2.1 Processi di decisione sequenziale . . . . . . . . . . . . . . . . . 21

2.1.1 Markov Decision Process . . . . . . . . . . . . . . . . . 23

2.1.2 Semi Markov Decision Process . . . . . . . . . . . . . . 26

2.1.3 Partially Observable Markov Decision Process . . . . . 27

i

Indice

2.2 Concetti di base . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.2.1 Il modello Agente-Ambiente . . . . . . . . . . . . . . . 30

2.2.2 Stima dell’ottimalita delle politiche . . . . . . . . . . . 32

2.2.3 Exploration vs Exploitation . . . . . . . . . . . . . . . 35

2.3 Algoritmi fondamentali . . . . . . . . . . . . . . . . . . . . . . 37

2.3.1 Approccio incrementale . . . . . . . . . . . . . . . . . . 38

2.3.2 Programmazione Dinamica . . . . . . . . . . . . . . . . 38

2.3.3 Metodi Monte Carlo . . . . . . . . . . . . . . . . . . . 42

2.3.4 Metodi TD . . . . . . . . . . . . . . . . . . . . . . . . 46

2.4 Algoritmi avanzati . . . . . . . . . . . . . . . . . . . . . . . . 50

2.4.1 Tracce di eleggibilita . . . . . . . . . . . . . . . . . . . 50

2.4.2 Tracce di rimpiazzo . . . . . . . . . . . . . . . . . . . . 55

2.5 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3 Architettura proposta 60

3.1 Panoramica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.2 Schema a blocchi . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.3 Uno sguardo nel dettaglio . . . . . . . . . . . . . . . . . . . . 69

3.4 Struttura di un esperimento . . . . . . . . . . . . . . . . . . . 72

3.5 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

4 Risultati sperimentali 75

4.1 Definizione degli esperimenti . . . . . . . . . . . . . . . . . . . 76

4.1.1 Singola Coda . . . . . . . . . . . . . . . . . . . . . . . 76

4.1.2 Coda Multipla . . . . . . . . . . . . . . . . . . . . . . . 77

4.2 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.2.1 Velocita di convergenza . . . . . . . . . . . . . . . . . . 79

4.2.2 Reward accumulata . . . . . . . . . . . . . . . . . . . . 88

4.3 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Conclusioni e sviluppi futuri 95

A Tabelle 96

A.1 Esperimento 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

A.2 Esperimento 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

ii

Indice

Bibliografia 109

iii

Elenco delle figure

1.1 Un modello semplificato dell’applicazione FDPS. . . . . . . . . 11

1.2 Un esempio di iniezione di un guasto di concorrenza. . . . . . 13

2.1 Un modo intuitivo di vedere l’evoluzione di un processo di

decisione sequenziale. . . . . . . . . . . . . . . . . . . . . . . . 22

2.2 Esempio di un modello MDP. . . . . . . . . . . . . . . . . . . 25

2.3 Modello d’interazione nel caso POMDP. . . . . . . . . . . . . 28

2.4 Interazione Agente-Ambiente . . . . . . . . . . . . . . . . . . . 30

2.5 Processo di Generalized Policy Iteration. . . . . . . . . . . . . 43

2.6 Co-convergenza, value function e politica. . . . . . . . . . . . . 44

2.7 Schema a blocchi per l’algoritmo Actor-Critic. . . . . . . . . . 49

2.8 Effetti delle tracce di eleggibilita e delle tracce di rimpiazzo

nell’apprendimento . . . . . . . . . . . . . . . . . . . . . . . . 53

2.9 Un esempio di confronto tra tracce di eleggibilita e tracce di

rimpiazzo, al variare di λ, in un processo di predizione random-

walk a 19 passi. . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.1 Schema a blocchi del sistema . . . . . . . . . . . . . . . . . . . 63

3.2 Modelli di code implementati nel sistema . . . . . . . . . . . . 65

3.3 Il sottosistema Brain (Cervello) . . . . . . . . . . . . . . . . . 67

3.4 Una vista dinamica del sistema sviluppato . . . . . . . . . . . 70

iv

Elenco delle figure

3.5 La struttura di un esperimento . . . . . . . . . . . . . . . . . 73

4.1 Struttura dell’esperimento con coda singola . . . . . . . . . . . 77

4.2 Struttura dell’esperimento con coda multipla . . . . . . . . . . 78

4.3 Numero dei passi impiegati al primo episodio, nel caso di coda

singola al variare del learning rate. . . . . . . . . . . . . . . . 81


singola al variare di λ. . . . . . . . . . . . . . . . . . . . . . . 81

4.5 Numero dei passi impiegati all’ultimo episodio, nel caso di

coda singola al variare del learning rate. . . . . . . . . . . . . 87


coda singola al variare di λ. . . . . . . . . . . . . . . . . . . . 87


multipla al variare del learning rate. . . . . . . . . . . . . . . . 89


multipla al variare di λ. . . . . . . . . . . . . . . . . . . . . . 90


coda multipla al variare del learning rate. . . . . . . . . . . . . 91

4.10 Numero dei passi all’ultimo episodio, nel caso di coda multipla

al variare di λ. . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.11 Reward accumulata alla fine del primo episodio al variare di

learning rate, nel caso dell’esperimento con coda singola. . . . 93


λ, nel caso dell’esperimento con coda singola. . . . . . . . . . . 93


learning rate, nel caso dell’esperimento con coda multipla. . . 94

4.14 Reward accumulata alla fine del primo episodio, al variare di

λ, nel caso dell’esperimento con coda mutlipla. . . . . . . . . . 94

v

Alla mia famiglia

Ringraziamenti

”Amo molto parlare di niente. E l’unico argomento di cui so

tutto. (O.Wilde)”

Sono giorni ormai che mi trovo a scrivere di notte, e tra una pausa e

un’altra pensavo a come avrei potuto sintetizzare questi ultimi anni. Cre-

do che comunque sia importante mettere un punto alla fine del tragitto di

una parte di un percorso; piu che del proprio percorso di studi, del proprio

percorso di vita. Sono partito dalla rilettura della sezione dei ringraziamen-

ti della mia tesi triennale, per ricordare come mi trovavo due anni fa. Era

arida, un po scarna; pero ricordo nitidamente quel mio entusiasmo e quella

mia ”ingenuita” . Da allora molto e cambiato, io sono cambiato, quello che

mi sta intorno e cambiato. Nonostante tutto, sono contento di come sono

andate le cose. E facile parlare alla fine, ma ”tra la partenza ed il traguardo

in mezzo c’e tutto il resto ed il e ”resto” che ti fa cambiare, o almeno fa uscire

quello che sei in realta. Chi direttamente o indirettamente mi e stato vicino,

fa parte di questo momento. Sono molte le persone che mi sono state vicine

e che voglio ringraziare. Voglio ringraziare mio fratello Luca, che e stato

sempre presente, nonostante i suoi metodi ”poco ortodossi” e Valentina che

lo ”sopporta”. Poi volevo ringraziare Mario per le centinaia di ore spese a

confrontarci su tutto, e per esserci sempre fatti spalla a vicenda. Poi volevo

ringraziare lo ”zio” Delio per le innumerevoli giornate spese a ricercare, con-

2

Ringraziamenti

frontarci e consigliarci per essere ”costantemente in evoluzione”, e Valeria

che ci ha trasmesso sempre ”energia positiva” in tutto quello che facevamo.

Volevo ringraziare Marco per tutte le discussioni e i consigli riguardo molti

problemi che ci siamo trovati ad affrontare e Laura che molte volte le ha

sopportate. Volevo ringraziare Biagio, di cui ho apprezzato i consigli in mol-

te occasioni; Anna, Antonio, Federica, Pamela, Paola, Stella, Simona, Nino,

Michela, Marialuisa e Alessia per le tantissime belle serate spese assieme;

Gianluca e Vincenzo per le ”serate a pazzo”. Caterina e Donatella che non

vedo da molto tempo, di cui ho apprezzato sempre il grande affetto che han-

no mostrato nei miei confronti.

Un ringraziamento particolare va a Roberto che mi ha sopportato pazien-

temente (forse anche troppo), le sue continue critiche mi hanno aiutato a

maturare e strutturare tutto questo lavoro e i costanti ”brain-storming” so-

no stati fondamentali sia per ricercare nuove soluzioni, sia ”per capire cosa

succedeva”.

Volevo infine ringraziare il Prof. Cotroneo che ci ha seguito e spronato co-

stantemente in tutto questo periodo di lavoro.

Caserta, lı 01/07/2011

3

Introduzione

I sistemi software per applicazione critiche richiedono in molti casi di rispet-

tare dei requisiti stringenti in termini di affidabilita. Per questo motivo ab-

biamo bisogno di meccanismi e algoritmi di Fault Tolerance che incrementino

l’affidabilita del sistema, e tecniche di validazione per garantire che tale affi-

dabilita sia stata conseguita. Una delle principali tecniche per la validazione

di meccanismi di Fault Tolerance e la Software Fault Injection, ovvero l’in-

troduzione di guasti software (bug) all’interno di un componente del sistema

per analizzarne l’impatto sugli altri componenti e nel sistema complessivo.

Questa tecnica ha grossa rilevanza dato che i guasti software rappresenta-

no una significativa causa di fallimento. L’analisi effettuata attraverso SFI si

basa fortemente sul concetto di workload, ossia il carico di lavoro del sistema,

che influisce sul modo in cui i guasti si manifestano e propagano nel sistema.

Tuttavia progettare un workload non e semplice per sistemi complessi, perche

essi presentano un elevato numero di stati di funzionamento, che sono diversi

tra loro. Inoltre, e difficoltoso controllare tali sistemi poiche la relazione tra

ingressi e stato e complessa ed ignota, ed inoltre e non-deterministica a causa

di fattori aleatori e per la presenza di componenti di terze parti. Molti studi

sulla SFI, che si sono succeduti nel corso del tempo, hanno mostrato che essa

e una tecnica particolarmente efficace per la validazione dei meccanismi di

Fault Tolerance. In molti studi e stato evidenziato come una grande parte

dei guasti software non siano facilmente riproducibili e dipendano fortemente

4

Introduzione

dallo stato in cui si trova il sistema oggetto dell’analisi. Sono stati proposti

dei metodi per emulare questo tipo di guasti, che necessitano di meccanismi

efficaci per il controllo dello stato di un sistema. Il problema del controllo

dello stato in se e non banale a causa della grossa quantita di variabili interne

al sistema, che ne influenzano la dinamica.

Questo lavoro di tesisi colloca esattamente in tale contesto, e ha i seguenti

obiettivi:

• Proporre e valutare un approccio, basato su reinforcement learning, per

l’iniezione dei guasti in sistemi software complessi.

• Proporre l’architettura di un sistema che permetta di compiere un’ana-

lisi degli algoritmi in maniera semplice ed efficace e che sia (i) facilmente

integrabile in un sistema complesso, (ii) facilmente estendibile.

• Effettuare un’analisi esplorativa degli algoritmi, per valutare l’applica-

bilita dell’approccio in casi significativi, in prospettiva di una integra-

zione futura.

Roadmap

In questo lavoro verranno dapprima illustrate le caratteristiche dei guasti

software, focalizzando particolarmente l’attenzione sui guasti di concorrenza

e sull’iniezione di guasti in sistemi distribuiti, facendo infine qualche riflessio-

ne sulle motivazioni che ci hanno spinto ad adottare questo tipo di approccio

(Capitolo 1). Successivamente tratteremo i modelli e concetti fondamentali

del Reinforcement Learning (Capitolo 2). Nel Capitolo 3 illustreremo l’ar-

chitettura proposta basata su un Agente che controlla un sistema simulato,

pensato sia per la fase sperimentale, sia per essere facilmente integrabile su

un sistema reale. Nel Capitolo 4 verrano mostrati i risultati sperimentali

ottenuti da un’analisi esplorativa dei principali algoritmi di Reinforcement

Learning.

5

CAPITOLO 1

Concetti fondamentali e motivazioni

”Occorre fornire tutte le informazioni per aiutare gli altri a

giudicare il valore del vostro contributo, non si possono dar solo

quelle che orientino in un determinato modo. (R.Feynman)”

In questo capitolo, discuteremo riguardo le motivazioni per cui si e propo-

sto l’approccio oggetto della tesi. Prima di tutto verranno illustrati alcuni

concetti fondamentali, riferendoci per linee generali ai processi di validazio-

ne dei meccanismi di fault tolerance. Descriveremo, poi, un caso di studio,

che consiste in un’applicazione distribuita per la gestione dei piani di volo,

nell’ambito del controllo del traffico aereo, mettendo in evidenza una meto-

dologia per iniettare guasti di concorrenza. Successivamente, daremo uno

sguardo piu approfondito ad un tool proposto per la validazione un sistema

distribuito: Loki. Infine, faremo alcune considerazioni su come migliorare gli

strumenti di fault injection per permettere il raggiungimento di uno stato,

allo scopo di iniettare un faultload.

6

1. Concetti fondamentali e motivazioni

1.1 Contesto del problema

I moderni sistemi software crescono costantemente in complessita, questo

aumento di complessita comporta un aumento dei guasti software che rap-

presenta un motivo significativo di fallimenti del sistema stesso. Lo scopo

che si vuole raggiungere e quello di ottenere che la probabilita che il sistema

non fallisca per un determinato periodo di tempo, noto come mission time,

sia la piu alta possibile. Trattare i guasti software in generale e un’opera-

zione complessa, uno dei problemi principali, infatti, e la riproducibilita del

fallimento, che e appunto l’abilita di indentificare il pattern di attivazione

del guasto.

Possiamo fare una classificazione dei guasti, in base alla riproducibilita del-

l’attivazione:

• Bohrbugs: in cui l’attivazione e riproducibile. Sono rilevati e rimossi

tipicamente nella fase di testing.

• Mandelbugs: in cui l’attivazione dei guasti non e sistematicamen-

te riproducibile e tipicamente portano a manifestazioni di fallimenti

transienti. Le condizioni di attivazione per questo tipo di guasti di-

pendono tipicamente da una complessa combinazione di input da parte

dell’utente, dallo stato interno e dall’ambiente esterno.

Una cosa importante da evidenziare e che le condizioni di attivazione dei

Mandelbugs si verificano nella fase operazionale del sistema ,che possono

essere molto complicate da riprodurre. Proprio per questa ragione, le attivita

di testing si sono rivelate non adeguate per fronteggiare questo tipo di guasti.

Poiche e praticamente intrattabile evitare che si verifichino Mandelbugs, i

sistemi critici adottano meccanismi di fault tolerance. Un meccanismo di

fault tolerance consiste in un insieme di procedure che permettono al sistema

di continuare ad operare anche in presenza di guasti.

I fallimenti dovuti a Mandelbugs possono essere mascherati tramite:

• ridondanza spaziale: ad esempio usando replicazione di componenti

software.

• ridondanza temporale: ad esempio riprovando un’azione ad un

successivo istante di tempo.

7


I meccanismi di tolleranza ai guasti devono essere validati prima della fase di

accettazione. Un modo molto utile per validare i sistemi software e quello di

usare una tecnica nota come SFI (Software Fault Injection). La fault injec-

tion consiste nel modificare il sistema software, al fine di causare fallimenti.

Lo scopo e quello di verificare che i meccanismi di tolleranza ai guasti del

sistema funzionino come ci si aspetta.

8


1.2 Un caso di studio sulla tolleranza ai gua-

sti di concorrenza

In questa sezione, descriveremo brevemente un caso di studio che ha costituito

la base su cui si e sviluppato l’approccio oggetto della tesi. Prima di fare

cio parleremo dei guasti di concorrenza, analizzando FDPS, un’applicazione

basata sul midlleware CARDAMOM, in questo contesto faremo un esempio

di iniezione di un guasto di concorrenza.

1.2.1 Guasti di concorrenza

In questa sezione analizzeremo brevemente i guasti di concorrenza, in questo

contesto tratteremo le idee che sono alla base dell’approccio proposto e le cui

linee generali sono spiegate nell’ultima sezione. Precedentemente, abbiamo

visto che i Mandelbugs sono una categoria di guasti, in cui le condizioni di

attivazione sono difficilmente riporducibili. Esistono studi che mostrano che i

Mandelbugs si verificano nella fase operativa della vita del sistema software.

E stato mostrato, inoltre, che le tecniche di G-SWFIT (General Software

Fault Injection Technique) non sono adatte ad emulare questo tipo di guasti.

I guasti di concorrenza sono una particolare categoria di guasti che si ma-

nifestano in sistemi in cui vengono gestite risorse condivise. Piu processi o

thread si sincronizzano per accedere ad una risorsa, il guasto consiste nel-

l’errata sincronizzazione dei processi o dei threads (per esempio mancanza

di una sezione critica). Le manifestazioni dei guasti che prendiamo come

riferimento sono due:

• race condition: la correttezza dell’esecuzione dipende dalla velocita

di esecuzione relativa dei processi/thread.

• deadlock: e una situazione in cui due (o piu) processi (o threads)

si bloccano a vicenda aspettando indefinitamente che uno esegua un’a-

zione, ad esempio il rilascio di un lock.

Studi fatti su analisi di dati prelevati da sistemi reali hanno mostrato che i

guasti di violazione di atomicita ricoprono il 49% dei casi, nel 66% dei casi

c’e solo una variabile condivisa, nel 90% dei casi ci sono al piu due variabili

9


coinvolte. Il modello dei guasti e costituito da due thread che accedono ad

una variabile condivisa, senza acquisire il lock che serve a proteggerla.

L’approccio che vogliamo analizzare [NC10] per l’emulazione di questo tipo

di guasti consiste di due fasi:

• fase di fault injection: in questa fase vengono collezionate informa-

zioni riguardo le sezioni critiche e gli accessi in memoria a tali sezioni

e poi vengono rimossi le operazioni di lock prima e dopo una coppia di

sezioni critiche in conflitto.

• fase di trigger injection: in cui viene sottomessa una sequenza di in-

put per guidare il sistema in un certo stato obiettivo, vengono schedulati

due threads in modo che ci sia interferenza negli accessi in memoria.

1.2.2 Il middleware CARDAMOM

CARDAMOM e una piattaforma middleware che fornisce risorse per confi-

gurare, distribuire ed eseguire quasi in real-time, applicazioni distribuite e

fault-tolerant. E basato su CORBA, e si affida a diversi componenti off-the

shelfs. Inoltre, la piattaforma include un’implementazione del DDS (Data Di-

stribution Service) dello standard OMG per comunicazioni del tipo publish-

subscribe. Lo scopo del DDS e quello di permettere la condivisione dei dati

tra piu processi distribuiti su diversi nodi, senza che ci si preoccupi della

modalita tramite la quale sono distribuiti.

CARDAMOM ha due servizi che sono stati utilizzati per sviluppare il caso

di studio sotto analisi:

• Fault Tolerance: fornisce ridondanza che viene effettuata tramite re-

plicazione di oggetti CORBA. Quando viene rilevato un guasto nella

replica primaria, il servizio Fault Tolerance elegge una nuova replica

primaria da un insieme di oggetti. La replicazione viene gestita con

uno stile warm passive, ovvero dopo la modifica dello stato della repli-

ca primario, lo stato viene memorizzato e passato agli altri membri del

gruppo di oggetti.

• Load Balancing: permette la distribuzione del flusso di esecuzione

delle richieste tra piu membri del gruppo di oggetti. Una richiesta

10


Figura 1.1: Un modello semplificato dell’applicazione FDPS.

viene smistata tra i vari server, seguendo una politica definita dall’u-

tente. La logica con cui vengono smistate le richieste e completamente

trasparente al client.

1.2.3 L’applicazione FDPS

L’applicazione FDPS, consiste in un sistema sviluppato in C++ basato sul

middleware CARDAMOM, che abbiamo brevemente descritto nel paragra-

fo precedente. FDPS e un’applicazione che fa parte di un sistema per il

controllo del traffico aereo, ed e stata pensata per la gestione dei piani di

volo. Un piano di volo, in questo contesto, e una struttura dati che contie-

ne informazioni riguardo un volo; l’obiettivo dell’applicazione e mantenere

costantemente aggiornato questo piano di volo. Uno schema semplificato di

FDPS e osservabile nella figura 1.1.

Dal punto di vista progettuale, FDPS e composto da:

11


• un componente Facade che viene replicato dal servizio FT di CARDA-

MOM.

• da un insieme di processi PS gestiti dal servizio LB.

Il Facade ha il compito di interfacciare l’applicazione con i sistemi esterni e

di gestire lo stato dei piani di volo. Quando riceve una richiesta del piano

di volo, congela il piano di volo e lo codifica in una struttura dati gestita

internamente dall’applicazione. Successivamente invia una richiesta a dei

processi che si occupano di servire la richiesta, questi processi sono stati

chiamati Processing Server. Per ogni piano di volo puo essere servita solo

una richiesta alla volta.

Il processing server:

• riceve il piano di volo e le tracce radar dal DDS,

• serve la richiesta fatta dal Facade (che puo essere di diversi tipi),

• ripubblica la struttura sul DDS.

• risponde al Facade, il quale sblocca il piano di volo

Se vengono inviate piu richieste allo stesso processing server, vengono ese-

guite una alla volta. In particolare il Facade si occupa dell’accondamento

delle richieste concorrenti e di effettuare il checkpointing delle tabelle che

rappresentano i piani di volo.

1.2.4 Un esempio d’inizione

Adesso mostriamo un esempio di applicazione dello schema d’iniezione pro-

posto a pagina 10 ad una esecuzione nel sistema FDPS, ci concentriamo sulla

fase di trigger injection per poter fare delle osservazioni utili al nostro sco-

po. Supponiamo di aver superato la fase di iniezione, adesso le variabili sono

sprotette.

Nella figura 1.2 e possibile osservare una esecuzione dell’applicazione. In

particolare, quando il sistema si trova nello stato 1:1:0, viene generata una

richiesta di tipo update (CRQ UPDATE). Il Facade risponde eseguendo la

12


Figura 1.2: Un esempio di iniezione di un guasto di concorrenza.

sezione critica facendo un accesso in memoria alla variabile a′′. Per forza-

re una specifica schedulazione del thread al fine di attivare il guasto, viene

bloccato il thread che compie l’accesso a′′. In seguito, viene mandata una

richiesta di tipo CR DELETE, che porta il sistema a compiere un accesso

in memoria a′ che e in conflitto con l’accesso a′′. Quando il thread viene

sbloccato compie l’accesso in memoria a′′ e quindi attiva il guasto che porta

alla manifestazione di una race condition. A questo punto, la domanda che

potremmo porci e se sia possibile trovare un metodo sistematico per raggiun-

gere uno stato, per poi effettuare l’iniezione. Nell’ultima sezione di questo

capitolo ci occuperemo di questo problema.

1.3 Fault injection nei sistemi distribuiti

Un fault-injector per sistemi distribuiti deve tener traccia dello stato globale

del sistema su cui e in esecuzione. E noto, comunque, che non e possibile in

pratica tener traccia dello stato globale di un sistema distribuito, operando

un’intrusivita minima. Una possibile soluzione a questo problema e di sincro-

nizzare l’esecuzione di tutti i componenti del sistema ad ogni cambiamento

di stato del sistema e determinare se e il caso di iniettare i guasti. Questo

tipo di soluzione pero, non e applicabile nella pratica a causa dell’eccessiva

13


intrusivita. Un’altra soluzione e di far mantenere al fault-injector una sin-

cronizzazione lasca con il sistema, ad esempio tramite l’invio di notifiche ad

ogni cambiamento di stato, e iniettare cosı i guasti nel componente basandosi

sulle informazioni che ha il componente dello stato globale del sistema.

Anche questa soluzione non sembra soddisfacente, perche potrebbe esserci

inconsistenze tra le viste che hanno i vari componenti dello stato globale, a

causa dei tempi di ritardo dei messaggi che viaggiano nella rete.

Adesso analizziamo un tool per la validazione di applicazioni in sistemi

distribuiti: Loki [Cha98], [Cha+04].

1.3.1 Loki

Loki e un fault-injector per sistemi distribuiti. Mantiene una vista parziale

dello stato del sistema che e costruita a partire dal sistema e dagli obiettivi

della campagna di fault injection, permette di eseguire del codice sviluppato

in un formato proprietario per stabilire gli obiettivi del test.

I punti che analizzeremo in Loki sono tre:

• vista parziale dello stato globale

• nodo

• processo di valutazione di un sistema

Vista parziale dello stato globale: Il concetto di stato e fondamen-

tale in Loki. Si puo assumere che, ad un desiderato livello di astrazione,

l’esecuzione di un componente del sistema distribuito in esame puo essere

specificato come una macchina a stati finiti, in cui le transizioni tra gli sta-

ti avvengono in seguito a eventi locali al componente. In altri termini, ad

un generico istante di tempo, un componente si trova in uno stato locale

particolare, e le sue transizioni verso un nuovo stato avvengono solo quando

avviene e rilevato un evento. Il nuovo stato e calcolato usando una funzione

di transizione, che e determinata in maniera univoca a partire dal vecchio

stato e dall’evento. Lo stato globale del sistema e un vettore, in cui ogni

termine rappresenta lo stato locale di un componente. Loki mantiene solo

la parte dello stato globale che e utile ai fini della fault-injection. Questa

14


parte e detta per l’appunto, vista parziale dello stato globale e dipende sia

dal sistema che stiamo studiando sia dai guasti che devono essere iniettati.

Nodo: Loki divide il sistema distribuito in esame in componenti di base,

da ognuno di questi vengono raccolte informazioni di stato e in ognuno di

questi vengono iniettati guasti. Ognuno di questi componenti di base del

sistema distribuito, insieme con il Loki runtime allegato, e chiamato nodo. Il

Loki runtime e codice Loki che viene eseguito all’interno del sistema distri-

buito e manitiene la vista parziale dello stato globale.

Inoltre, esegue iniezione di guasti quando il sistema transita verso gli stati

desiderati e colleziona informazioni riguardanti cambiamento di stati, e le

iniezioni dei guasti.

Processo di valutazione di un sistema Dopo aver specificato delle cam-

pagne di test, viene effettuata la valutazione del sistema.

I processi nella fase di valutazione sono tre:

• fase di runtime.

• fase di analisi.

• fase di stima.

La fase di runtime e la fase durante la quale vengono compiute le iniezio-

ni dei guasti mentre l’esperimento e in esecuzione. Questa fase implica (i)

l’esecuzione del sistema distribuito, (ii) l’iniezione dei guasti all’interno del

sistema in istanti di tempo appropriati, (iii) collezione e registrazione delle

osservazioni. Per fare cio, la fase di runtime utilizza il Loki runtime. Durante

l’esecuzione di un esperimento, il Loki runtime interagisce con il sistema in

esame usando un probe che e dipendente appunto dal sistema. Il probe e

definito dal progettista del sistema. Il probe serve a notificare al Loki run-

time del nodo, gli eventi locali che avvengono nel componente del nodo. Le

iniezioni sono comunque compiute dai probe. Le specifiche della macchina a

stati sono usate per mantenere la vista parziale dello stato globale, e le spe-

cifiche dei guasti sono usate per l’attivazione dei guasti durante le iniezioni.

La macchina a stati tiene traccia dello stato locale del componente usando

15


sia le specifiche che sono date della macchina a stati, sia le notifiche fatte al

probe.

La fase di analisi e la fase in cui si rileva se le iniezioni sono state fatte nello

stato desiderato. Questa analisi puo essere fatta on-line o off-line. I risultati

delle iniezioni errate sono ignorate, e solo le iniezioni di guasti corrette sono

usate nella stima delle misure. In particolare, la fase di controllo dopo la fase

di run-time porta a piazzare le singole timeline di ogni macchina a stati, su

un’unica timeline globale. Successivamente, vengono usate le specifiche dei

guasti per determinare se ogni guasto e stato iniettato nello stato giusto.

Loki usa un algoritmo di sincronizzazione del clock off-line per calibrare i

clock su piu macchine sulle quali opera l’iniettore, dopo questa stima tutte le

timeline locali vengono messe su un’unica timeline globale. Si prende come

riferimento il clock di una macchina, l’offset e il drift rate (tasso di deriva)

dei clock delle altre macchine vengono stimati a partire da questo riferimen-

to. Questi offset e questi drift rate sono usati per posizionare tutti gli istanti

d’interesse in un’unica timeline. La fase di stima e la fase in cui l’utente ot-

tiene misure per accertare la dependability e la performance dell’applicazione

distribuita. Loki contiene un linguaggio flessibile che permette di specificare

misure di performance e dependability.

1.4 Un approccio ”intelligente”

Come abbiamo visto nella precedente sezione, Loki ha i seguenti punti di

forza:

• Vista parziale dello stato globale, si collezionano e si analizzano solo

le informazioni strettamente necessarie a ricostruire lo stato con cui

effettuare il test.

• Possibilita di ricavare parametri sintetici per la valutazione della de-

pendability e delle performance del sistema distribuito in esame.

• Minima intrusivita nel sistema, utilizzando un’analisi off-line dell’ese-

cuzione per determinare la correttezza dell’esperimento.

Nonostante questi punti di forza, Loki presenta i seguenti svantaggi:

16


• La specifica della macchina a stati viene fatta da un operatore che mo-

della il sistema. L’approccio di valutazione e statico, la macchina a

stati deve essere specificata sistema per sistema. Quindi il progettista

e l’unico responsabile della definizione della macchina a stati, e il mo-

dello rappresenta quello che sa Loki del sistema, e come se fosse un

intermediario tra il sistema reale e la logica di controllo di Loki.

• Per ogni sistema deve essere programmato un probe diverso.

• Non fornisce un approccio per guidare il sistema in uno specificato stato

obiettivo, bensı permette solo di analizzare passivamente l’esecuzione

del sistema.

Una cosa che possiamo osservare e che analogamente a quello che abbiamo

visto per il problema dei guasti di concorrenza, si ripresenta il problema

della raggiungibilita di uno stato obiettivo. Quindi quello che ci proponiamo

di fare ora, e di ragionare su questo punto cioe di capire come possiamo

effettivamente approcciare a questo problema.

Una prima idea e quella di formulare un problema di ottimizzazione, in cui:

• le variabili sono i ritardi che possiamo introdurre nei singoli processi.

• la funzione obiettivo dovrebbe stimare il costo per il raggiungimento

dello stato e dipendere dai ritardi.

• i vincoli dovrebbero imporre che il ritardo massimo accumulabile da

ogni processo non superi una certa soglia.

Sarebbe intrattabile formulare da un punto di vista analitico questo tipo di

problema, se non altro perche la dinamica del sistema dipende dal sistema

stesso. Potremmo pensare di formulare il problema in maniera diversa. Se

osserviamo il modello, possiamo intuire che una funzione che potrebbe ri-

sultare utile per la definizione del problema e quella che misura quanto sia

positivo trovarsi in uno stato. Siccome il nostro problema e incentrato sul

raggiungimento e sul mantenimento di uno stato in un sistema distribuito,

deduciamo che questa funzione dovrebbe avere un il valore piu alto di tutti

nello stato obiettivo. Ma anche in questo caso non sappiamo come definire

17


questa funzione analiticamente.

L’idea oggetto di tutte le seguenti e se possa essere progettato un agente che

(i) sia in grado di manipolare le richieste che vengono inviate ai processi e

(ii) possa aggiungere tempi di ritardo (che sono i nostri due gradi di liberta)

in modo da raggiungere e mantenere lo stato.

La prima riflessione riguarda la scelta della tipologia di apprendimento.

Per esempio se supponessimo di utilizzare un approccio supervisionato, il

problema principale in cui ci imbatteremmo e quello di costruire una corri-

spondenza dalle situazioni che si presentano, ad azioni che mimano le azioni

corrette da compiere [SB98]. Inoltre, dovrebbe essere in grado di generalizzare

cioe adattarsi a nuove situazioni. Un sistema di apprendimento supervisio-

nato non puo imparare a controllare, perche segue le istruzioni che riceve,

piuttosto che criticarle. In altri termini, invece di far in modo che il siste-

ma che sta controllando si comporti in un determinato modo, prova a fare

in modo che egli stesso si comporti come gli e stato dettato implicitamente

dal sistema. Per questo motivo, la scelta cade su una metodologia di ap-

prendimento nota come reinforcement learning, i cui dettagli li analizzeremo

successivamente. Nel seguito faremo una breve sintesi di alcuni casi in cui

il reinforcement learning e stato applicato in domini complessi ed ha dato

risultati soddisfacenti.

I successi del reinforcement learning: Il reinforcement learning e stato

applicato con successo in numerosi campi:

• robotica.

• controllo autonomo di elicotteri.

• economia.

• giochi.

• settore militare.

Uno dei lavori che ha destato molto interesse nella comunita scientifica e

un lavoro ad opera di G.Tesauro [Tes02], in cui ha proposto un giocatore

18


di backgammon che utilizza un approccio ibrido per l’apprendimento. L’al-

goritmo TD-gammon da lui proposto e basato sull’unione di un algoritmo

TD e una rete neurale MLP. La particolarita e che l’apprendimento avviene

aggiornando con l’errore TD il peso del livello di uscita.

Il giocatore usa una logica di apprendimento self-teaching, non esiste un

istruttore che mostra all’agente come comportarsi. Questo giocatore dopo

diversi episodi ha mostrato un grado di bravura talmente alto da essere equi-

parabile a esperti del gioco.

Un altro caso significativo riguarda il volo autonomo di elicotteri [NJ00] stu-

diato da Andrew Ng, in cui ha proposto un algoritmo policy-search (PEGA-

SUS) basato su simulazione. Altri casi di studio significativi, sono in campo

militare per lo sviluppo di robot autonomi in grado di orientarsi in campo di

battaglia.

In tutte queste applicazioni, anche se il contesto e diverso, lo scopo e sempre

lo stesso cioe il raggiungimento di uno o piu stati obiettivo.

1.5 Conclusioni

In questo capitolo abbiamo richiamato i concetti fondamentali di dependa-

bility, focalizzando l’attenzione sui meccanismi di fault-tolerance. In parti-

colare, abbiamo classificato i guasti in base alla riproducibilita (Bohrbugs e

Mandelbugs), ponendo particolare enfasi sul problema della riproducibilita.

Infatti, abbiamo detto che il problema della riproducibilita di un Mandel-

bug e non banale, poiche l’attivazione del guasto dipende da una complessa

sequenza di input da parte dell’utente, dallo stato interno e dall’ambiente

esterno. Successivamente, abbiamo definito i meccanismi di fault-tolerance,

e abbiamo parlato di una tecnica per la validazione dei sistemi fault-tolerant

nota come Software Fault Injection. In seguito abbiamo parlato dei guasti

di concorrenza, motivando la scelta di un modello di guasti sulla base di

dati sperimentali. In particolare, le manifestazioni dei guasti che abbiamo

preso come riferimento sono (i) race condition, (ii) deadlock e abbiamo de-

finito un modello dei guasti costituito da due thread che accedono ad una

variabile condivisa, i quali non acquisiscono il lock che serve a proteggerla.

L’approccio all’iniezione che abbiamo preso come riferimento e costituito da

19


due fasi (i) fase di fault injection, (ii) fase di trigger injection. Poi, abbiamo

descritto brevemente il middleware CARDAMOM, mettendo in evidenza i

servizi Fault Tolerance e Load Balancing. Successivamente, abbiamo ana-

lizzato l’applicazione FDPS, enfatizzando la trattazione sia dell’architettura

del sistema, sia dei meccanismi di fault tolerance all’interno della stessa. In

questo contesto, abbiamo analizzato un esempio di iniezione di un guasto

di concorrenza al fine di osservare che, per emulare il comportamento di un

Mandelbug, abbiamo bisogno che l’inezione avvenga in uno stato specifico. In

questo contesto, abbiamo osservato che uno dei problemi principali dell’iniet-

tore e quello di guidare il sistema in uno stato obiettivo, dove fare l’iniezione.

Successivamente abbiamo parlato di Loki un tool per la validazione di un si-

stema distribuito, descrivendone l’architettura, ed enfatizzando i vantaggi e

gli svantaggi di un tale tipo d’approccio. Infine, nell’ultima sezione abbiamo

osservato che anche un fault injector per sistemi distribuiti ha il problema

del raggiungimento di uno stato target per l’iniezione. Proprio a questo rife-

rimento, abbiamo fatto delle riflessioni e motivato l’uso di un Agente che usa

una modilita di apprendimento di reinforcement learning. Nell’ultimo para-

grafo abbiamo descritto brevemente i casi di successo che abbiamo reputato

piu significativi.

20

CAPITOLO 2

Reinforcement Learning

Ci sono cose che l’intelligenza e capace di cercare, ma che da

sola non trovera mai.(H.Bergson)

In questo capitolo analizzeremo i modelli per descrivere processi di de-

cisione sequenziale e i relativi metodi di risoluzione basati su reinforcement

learning. In prima istanza, specificheremo che cos’ e un processo di decisione

sequenziale e i principali modelli di decisione, successivamente analizzeremo

il problema fondamentale del reinforcement learning definendo le funzioni e

i principali algoritmi che sono stati sviluppati per risolverlo.

2.1 Processi di decisione sequenziale

Un processo di decisione sequenziale e un processo che evolve in quanti di

tempo discreti e definito su due insiemi:

• un insieme S che rappresenta l’insieme degli stati in cui si puo trovare

il processo,

• un insieme A che descrive lo spazio delle azioni che possono essere

compiute all’interno del processo

21

2. Reinforcement Learning

Figura 2.1: Un modo intuitivo di vedere l’evoluzione di un processo di decisione

sequenziale.

Inoltre, su questi due insiemi, e definita una funzione R detta funzione di

reward (ricompensa), la quale e associata ad un decisore ma non fa parte

del decisore stesso. Il processo in se consiste in una successione di decisioni,

che vengono prese ad ogni istante di valutazione t = 1, 2, ..., T , l’intervallo di

tempo tra un istante di decisione ed un altro e detto epoca. Ad ogni epoca

viene compiuta una decisione, come risposta a questa decisione vengono re-

stituiti sia un valore che rappresenta il guadagno istantaneo del decisore, sia

lo stato in cui il sistema e transitato. Questo procedimento e mostrato in

modo molto intuitivo nella figura 2.1.

Gli insiemi S ed A possono essere discreti o continui.

Diremo che il processo di decisione e a :

• orizzonte finito (finite horizon): se T 6=∞. Indicheremo questo tipo

di situazione con FH.

• orizzonte infinito (infinite horizon): se T =∞. Indicheremo questo

tipo di situazione con IH.

Ora ci preoccuperemo solamente di specificare modelli, funzioni e metodi, al

fine di trovare strategie (che poi formalizzeremo meglio) ottime o subottime,

che ci permetteranno di raggiungere a partire da uno stato un altro stato,

detto appunto stato obiettivo.

22


2.1.1 Markov Decision Process

Un Markov Decision Process [Mar94] e definito tramire la 5-pla (S,A, pt(·|s, a), γ, rt(s, a))

dove

• S e lo spazio degli stati;

• A e lo spazio delle azioni;

• pt(·|s, a) e la funzione probabilita di transizione;

• γ ∈ [0, 1]1 e il fattore di sconto (discount factor);

• rt(s, a) e la funzione di reward.

Il modello MDP e associato ad un decisore, che ha l’opportunita d’influenzare

il comportamento del sistema stocastico che evolve nel tempo. Il suo obietti-

vo e scegliere una sequenza di azioni che portano il sistema a comportarsi in

maniera ottima rispetto a criteri di prestazioni prestabiliti. Questa sequenza

d’azioni e detta politica, successivamente nel capitolo formalizzeremo meglio

questo concetto. Poiche il sistema e in evoluzione, il decisore a priori non

puo prevedere lo stato futuro, ma per le ipotesi che abbiamo fatto e in grado

di rilevare lo stato del sistema. Risolvere un modello MDP, significa trovare

una politica ottima 2

Il processo e detto Markoviano se la probabilita di transitare dallo stato s

allo stato s′ dipende unicamente dallo stato corrente e non dalla storia del

processo, meno formalmente il fatto di arrivare in un nuovo stato s′ dipende

solo dallo stato corrente e non da come ci si e arrivati in tale stato.

Per completare l’introduzione ai modelli MDP, dobbiamo parlare piu in det-

taglio sia della funzione di reward, sia della funzione di probabilita di tran-

sizione. Secondo il modello MDP, dopo aver scelto l’azione a ∈ A(s) nello

stato s all’epoca di decisione t,

1. il decisore riceve una reward (ricompensa) rt(s, a) e

1ha senso considerare γ = 1 se il processo e FH.2L’esistenza e l’unicita della soluzione e garantita ad esempio se lo spazio degli stati

e finito. Piu in generale, non e detto che la soluzione esista e ammesso che esista non e

detto che sia unica.

23


2. lo stato del sistema nella prossima epoca di decisione e determinato

dalla distribuzione di probabilita pt(·|s, a).

Se la funzione rt(s, a) e positiva allora puo essere vista come un guadagno,

viceversa se e negativa puo essere vista come un costo. Dal punto di vista

del modello e opportuno specificare come viene accumulata la reward duran-

te un periodo. In realta, quello di cui abbiamo bisogno, e che il valore della

funzione rt(s, a) o il valore atteso sia conosciuto prima di scegliere un’azione.

Inoltre, questo valore non deve dipendere da azioni future, cioe da quello che

il decisore fara in futuro.

Quando la reward dipende dallo stato del sistema alla successiva epoca di

decisione, denotiamo con rt(s, a, j) il valore al tempo t della reward ricevuta

quando lo stato del sistema all’epoca di decisione t e s, e stata scelta l’azione

a ∈ A(s) e il sistema occupa lo stato j all’epoca di decisione t+ 1. Pertanto,

non e detto che un istante di decisione coincida con l’istante in cui arriva al

decisore una nuova reward. Infatti, ad ogni istante di decisione, il decisore

sulla base delle reward accumulate nei vari stati tra l’istante di decisione

corrente t e l’istante di decisione futuro t + 1, calcola il valore atteso condi-

zionato rispetto alla probabilita di transizione per stimare quale sara il suo

guadagno medio futuro:

rt(s, a) =∑j∈S

rt(s, a, j)pt(j|s, a)

Dove la funzione non negativa pt(j|s, a) denota la probabilita che il sistema

e nello stato j ∈ S all’istante t, quando il decisore sceglie l’azione a ∈ A(s)

all’istante t. Siccome la funzione p e una funzione di probabilita essa sara

una funzione non negativa e: ∑j∈S

pt(j|s, a) = 1

Formalizzeremo meglio in seguito come risolvere il problema di trovare una

politica ottima da un punto di vista analitico sia per il caso FH, sia per il

caso IH quando utilizzeremo questo modello nel contesto del reinforcement

learning. Per il momento, ci limitiamo a fornire un esempio di MDP, per

fare qualche considerazione piu intuitiva che teorica sui modelli MDP. Come

24


Figura 2.2: Esempio di un modello MDP.

possiamo osservare nella figura 2.2, ci sono due stati s1 e s2. Nello stato s1

ci sono due azioni possibili a1,1 e a1,2, mentre nello stato s2 c’e solo un’azione

possibile a2,1. Nelle parentesi graffe il primo termine rappresenta la reward

immediata che riceve il decisore, mentre il secondo termine rappresenta con

quale probabilita il sistema transitera nel nuovo stato. Quindi ad esempio, se

viene scelta l’azione a1,1, il processo transitera dallo stato s1 allo stato s2 con

probabilita 0.5, passando al decisore una reward di 5 unita, o rimarra nello

stato s1 con una probabilita di 0.5, passando al decisore una reward di 5 unita.

In caso contrario, se viene scelta l’azione a1,2 allora il processo transitera nello

stato s2 con probabilita 1, dando al decisore una reward di 10 unita. Se ci

troviamo nello stato s2, invece, il processo rimarra sempre in s2 solo che

ricevera sempre una reward negativa pari a -1. Per esempio supponiamo

che il decisore faccia scelte di tipo greedy, al primo istante di decisione sara

compiuta l’azione a1,2, per ricevere immediatamente una reward di 10 unita.

Ma una scelta di questo tipo, nel lungo periodo, non porta a buoni risultati.

Infatti, siccome il decisore dopo l’azione a1,2 passa nello stato s2 e per come

e fatto il modello e ”costretto” a rimanere in tale stato e ad ogni istante di

decisione successivo, la reward che ha accumulato il decisore decrescera di 1

unita. Quindi dopo 10 istanti di decisione, il decisore vanifichera lo ”sforzo”

che ha fatto per passare nello stato s2. Gia questo esempio molto semplice, ci

suggerisce che non e un problema semplice scegliere una sequenza di azioni,

25


perche un’azione apparentemente comoda nel momento di decisione, puo non

rivelarsi utile nel futuro.

Infine, possiamo menzionare per completezza, anche MDP continui, in cui

l’istante di decisione non e piu a prefissati istanti discreti, l’istante di scelta

successivo t1 puo trovarsi in qualsiasi punto dell’asse dei tempi a partire da

un prefissato istante t0. Il tempo speso in uno stato dal processo puo essere

descritto da una variabile aleatoria esponenziale.

2.1.2 Semi Markov Decision Process

I processi semi Markoviani, generalizzano processi Markovani continui, hanno

il vantaggio che il tempo speso in un determinato stato possa essere descritto

da un generico tipo di distribuzione.

Piu formalmente, i passi compiuti da un SMDP (Semi Markov Decision

Process) sono, supponendo che il sistema si trovi nello stato s ∈ S:

• l’agente sceglie un’azione a ∈ A(s)

• la prossima epoca di decisione avviene nell’istante t o dopo t stesso.

La probabilita di trovarsi nell’epoca di decisione successiva nello stato

j e descritta dalla funzione Q(t, j|s, a). Di solito questa funzione si

scompone in due contributi. Il primo e dovuto alla funzione F (t|s, a)

che denota la probabilita che il prossimo istante di decisione sia t dato

il fatto che abbiamo scelto l’azione a ∈ A(s) nello stato s. Il secondo

contributo e dovuto alla funzione p(j|t, s, a) che denota la probabilita

che il sistema permanga nello stato j dato un certo tempo t stato s e

azione a.

In tutti i modelli analizzati finora, abbiamo implicitamente supposto che lo

stato del sistema fosse totalmente osservabile, nel senso che non solo cono-

sciamo il modello del sistema stesso, ma che inoltre riusciamo a misurare

con certezza lo stato in cui si trova il sistema stesso. Nel prossimo paragrafo

rimuoveremo quest’ultima ipotesi.

26


2.1.3 Partially Observable Markov Decision Process

I modelli POMDP [Cas94] sono basati sulla caratteristica che lo stato non

e completamente osservabile. Assumiamo ancora che il sistema si comporti

nello stesso modo di un MDP; quindi ci sono stati azioni, reward e probabi-

lita di transizione che sono basate sulla coppia stato-azione corrente. Inoltre,

e aggiunto un insieme di osservazioni Z, in questo modo ogni osservazione

viene prodotta dopo che e avvenuta la transizione da uno stato ad un altro e

il decisore puo compiere l’azione che reputa dal suo punto di vista migliore.

L’osservazione prodotta e correlata con la transizione di stato, pero chiara-

mente non ci permette di descrive lo stato completamente, data la parziale

osservabilita del sistema. Denotiamo con Ot la variabile aleatoria associata

all’osservazione compiuta all’istante di decisione t. Oltre un insieme di os-

servazioni, introduciamo una funzione di osservazione, O : A × S → Π(Z).

Questa funzione associa l’azione all’istante t − 1 e lo stato al tempo t, una

distribuzione sull’insieme delle osservazioni.

Pertanto, definiamo Pr{Ot = z|St = s, At−1 = a} = o(a, s, z).

Inoltre, possiamo ancora definire una funzione di reward e una funzione di

probabilita di transizione tra stati, che denotiamo con T .

Quindi riassumendo, un modello POMDP e definito formalmente dalla 6-

pla Γ ≡ (S,A, Z,R, T,O). La struttura di un sistema modellata usando una

POMDP e la seguente 2.3. Analogamente ai modelli MDP, l’obiettivo in que-

sto tipo di modelli e quello di trovare una politica ottima. Poiche abbiamo

accesso esclusivamente alle osservazioni del sistema, possiamo definire una

politica POMDP come una corrispondenza tra l’ultima osservazione fatta

sul sistema, ad un’azione π : Z → A. Comunque, un tipo di politica del

genere non e adeguato in molti casi reali. Un approccio leggermente migliore

di politica deterministica basata sull’ultima osservazione, e quello di definire

la politica, π : Z → Π(A), come una corrispondenza dalle osservazioni a

distribuzioni su azioni. Questo tipologia di politica e detta probabilistica ed

e piu generale, in quanto contiene anche il caso deterministico. La politica

ottima per un modello POMDP e in generale non necessariamente Markovia-

na, nel senso che l’azione successiva non dipende esclusivamente dallo stato,

ma anche dalla storia passata. Affinche la politica sia ottima, essa deve

27


Figura 2.3: Modello d’interazione nel caso POMDP.

essere in grado di ricordare l’intera storia del processo. Chiaramen-

te, questo tipo di ragionamento non e strettamente applicabile in pratica,

pero possiamo immaginare che gli eventi che sono accaduti molto indietro

nel tempo non abbiano un impatto apprezzabile nel presente. Per ovviare a

questa evidente intrattabilita, possiamo derivare dei parametri sintetici che

descrivono con una certa precisione il processo. Questi parametri sono detti

stati d’informazione (information states) o stati di credenza (belief states).

A differenza della storia completa del processo la dimensione dello stato d’in-

formazione e fissa. La peculiarita di questo parametro e che rappresenta una

statistica sufficiente per la storia, il che vuol dire che possiamo trovare la

politica ottima basandoci su questo parametro, piuttosto che sulla storia del

processo. Uno stato di credenza, b, e una distribuzione di probabilita definita

sull’insieme degli stati, Π(S), b(s) rappresenta la probabilita di occupare lo

stato s. Definiamo, inoltre, B = Π(S) come lo spazio di tutte le distribu-

zioni di probabilita definibili sullo spazio degli stati S. Un singolo stato di

credenza puo catturare gli aspetti rilevanti della storia passata del processo,

e per di piu puo essere aggiornato in maniera semplice usando la regola di

28


Bayes. Inoltre, analogamente a quello che vedremo in seguito, si puo definire

una funzione su questa struttura3, detta funzione di valutazione dello stato

(value function) V (b), che descrive numericamente quanto sia positivo per

l’agente trovarsi in un determinato stato di credenza b.

Nel caso POMDP ci sono due importanti considerazioni da fare:

• si dimostra che la funzione V (b) nel caso che il processo sia FH e una

funzione costante lineare a tratti e convessa (PWLC), combinazioni di

funzioni PWLC sono ancora PWLC.

• si dimostra che la funzione V (b) nel caso IH converge nel senso della

norma alla funzione di valutazione ottima V ∗(b). In altri termini, pos-

siamo trovare una funzione Vk(b) che approssima bene quanto vogliamo

la funzione V ∗(b).

Nel prossimo paragrafo ci accingeremo a descrivere i concetti di base del

reinforcement learning, in cui definiremo metodi ed algoritmi per risolvere

i modelli che abbiamo visto in questi paragrafi in forma esatta e in forma

approssimata.

3tratteremo questo aspetto con maggiore dettaglio nel caso di MDP

29


Agent

Environment

actionatst

rewardrt

rt+1st+1

state

Figura 2.4: Interazione Agente-Ambiente

2.2 Concetti di base

In questa sezione affronteremo i concetti di base per affrontare lo studio

degli algoritmi, al fine di risolvere problemi di reinforcement learning [AM96],

[SB98].

2.2.1 Il modello Agente-Ambiente

Il problema del reinforcement learning consiste nell’apprendere tramite inte-

razione. L’ente che compie le decisioni e l’Agente mentre tutto quello che si

trova al di fuori di esso e con cui puo interagire e detto Ambiente. L’Ambiente

puo essere a sua volta reale o simulato , nel primo caso l’Agente impara inte-

ragendo direttamente con il sistema target, nel secondo caso l’Agente impara

interagendo con un modello che simula il funzionamento del sistema target.

L’evoluzione del sistema Agente-Ambiente avviene ad intervalli di tempo di-

screti t = 0, 1, 2, ... ; in ogni quanto di tempo l’Agente riceve informazioni di

stato da parte dell’Ambiente che indichiamo con st ∈ S e in base a queste

informazioni decide l’azione at ∈ A(st) da compiere. Ora al passo successivo

l’Agente riceve una ricompensa rt+1 ∈ R e il nuovo stato st+1, come si puo

evincere dalla figura 2.4.

Una politica π : S → A e una funzione che associa stati ad azioni. Una

politica puo essere di due tipi:

30


• deterministica : restituisce l’azione che deve essere compiuta nello

stato s. Assume la forma π(s).

• stocastica: restituisce la probabilita di compiere l’azione a sapendo di

essere nello stato s, viene denotata con π(s, a).

I metodi per fare reinforcement learning (da ora RL) specificano come l’A-

gente cambia la propria politica partendo dall’esperienza che esso acquisisce

nell’Ambiente. Non abbiamo ancora ben specificato quali sono gli obiettivi

dell’apprendimento in scenari di tipo RL, per fare cio approfondiamo l’anali-

si della funzione di ricompensa (a cui faremo riferimento come funzione

di reward). In pratica la funzione di reward e un guadagno/costo che si

vuole massimizzare/minimizzare nel lungo periodo, infatti la reward viene

calcolata all’esterno dell’Agente, e puo essere pensata come un premio o una

punizione che l’Agente riceve quando induce un cambiamento di stato del-

l’Ambiente con un’azione.

I problemi che ci troveremo ad affrontare fino alla fine del capitolo sono

essenzialmente due:

• Non conosciamo le probabilita di transizione.

• L’apprendimento e oneroso da un punto di vista computazionale.

Possiamo notare comunque che ci sono casi in cui anche conoscendo perfet-

tamente il sistema, il processo di reinforcement learning e oneroso.

Ritornando a qual e l’obiettivo dell’apprendimento, esso puo essere espresso

in termini di reward. Tutti gli algoritmi agiscono per massimizzare il gua-

dagno atteso cioe tutto il guadagno che l’Agente di aspetta di ricevere nel

lungo periodo. Nel caso in cui il nostro processo sia FH allora il guadagno

atteso a partire dall’istante t ≤ T sara:

Rt = rt+1 + rt+2 + ...+ rT

Per quello che riguarda i processi di apprendimento essi sono divisi in due

categorie:

• episodici: in cui l’apprendimento viene fatto per episodi, cioe in sot-

tointervalli di tempo finito in cui il tempo di evoluzione del sistema

31


viene diviso, inoltre, viene definito uno stato terminale in cui l’episodio

si deve concludere.

• continui: in cui non c’e un proprio istante di fine apprendimento.

Nel caso di processi di apprendimento continui, poiche T =∞, a meno che la

successione dei reward sia limitata (cosa alquanto rara), il guadagno atteso

sara infinito e quindi il processo non convergera.

Quindi ora e evidente l’utilita del fattore di sconto (discount factor) γ che

abbiamo introdotto nei vari modelli. Essendo 0 ≤ γ ≤ 1, possiamo definire

il guadagno atteso come

Rtγ =+∞∑k=0

γkrt+k+1

Osserviamo che per quanto detto precendentemente le condizioni γ = 1 e

T =∞ non si possono verificare contemporaneamente.

Ora possiamo anche dare una definizione intuitiva di γ, possiamo pensare

infatti che il fattore di sconto rappresenta quanto l’agente da importanza a

quello che guadagnera nel futuro. Infatti se T = ∞ e γ = 0 allora l’agente

e sostanzialmente ”miope”, nel senso che si preoccupa di massimizzare il

suo guadagno nell’immediato, nel caso invece che T = ∞ e γ → 1 allora

l’Agente ”guardera lontano”, cioe si preoccupera non solo di guadagnare

nell’immediato, ma anche nel futuro. Come si puo intuire, questo tipo di

procedimento e piu oneroso dal punto di vista computazionale.

Nel prossimo paragrafo ci occuperemo di definire funzioni definite sullo spazio

degli stati e delle azioni, per poter delineare dei metodi di risoluzione del

problema.

2.2.2 Stima dell’ottimalita delle politiche

Adesso che abbiamo definito il problema possiamo parlare delle funzioni che

sono utilizzate per trovare la politica ottima.

I metodi di reinfocement learning sono basati sulla stima di due funzioni:

• V (s) detta value function o anche V-function, che indica quanto

beneficio porta all’agente trovarsi nello stato s (funzione di valutazione

dello stato).

32


• Q(s, a) detta action-value function o anche Q-function, che indi-

ca quanto beneficio porta all’agente compiere l’azione a nello stato s

(funzione di valutazione di un’azione compiuta in uno stato).

Nella pratica V (s) e Q(s, a) sono funzioni che dipendono anche dalla politi-

ca. Infatti, fissata una politica π, il valore V π(s) indica il guadagno atteso

partendo dallo stato s e seguendo la politica π.

V π(s) = Eπ{Rt|st = s} = Eπ{+∞∑k=0

γkrt+k+1|st = s}

La funzione V π(s) e detta state-value function per la politica π.

Analogamente, fissata una politica π, possiamo definire il valore di Qπ(s, a),

ovvero del valore associato a compiere l’azione a, nello stato s, seguendo la

politica π come:

Qπ(s, a) = Eπ{Rt|st = s, at = a} = Eπ{+∞∑k=0

γkrt+k+1|st = s, at = a}

La funzione Qπ(s, a) e detta action-value function per la politica π.

Una proprieta importante di queste funzioni e che soddisfano particolari

relazioni ricorsive. Invero, per qualsiasi politica π e stato s vale la seguente4:

V π(s) =∑a

π(s, a)∑s′∈S

P as,s′ [R

as,s′ + γV π(s′)]

Ora ci restano da analizzare i criteri di ottimalita delle funzioni. Il nostro

obiettivo e quello di trovare una politica π∗ che, assumendo come stato di

partenza lo stato s, ci dia un guadagno atteso massimo. In linea di principio,

non e detto che la politica ottima sia unica (questo vale per MDP con spazio

degli stati finito).

Queste funzioni hanno la proprieta di definire un ordinamento parziale tra le

politiche, cioe:

π ≥ π′ ⇐⇒ V π(s) ≥ V π′(s)

La politica ottima π∗ sara tale che ∀s ∈ S:

V π∗(s) ≥ V π(s) ∀π ∈ Π

4diamo la definizione solo per la V-function, per la Q-function le considerazioni sono

equivalenti

33


Quindi la V-function ottima sara:

V π∗(s) = maxπ∈ΠVπ(s) ∀s ∈ S

Analogamente, la Q-function ottima sara:

Qπ∗(s, a) = maxπ∈ΠQπ(s, a) ∀s ∈ S ∀a ∈ A(s)

Inoltre le funzioni V π∗(s) e Qπ∗(s, a) sono legate tra loro, infatti:

Qπ∗(s, a) = Eπ{rt+1 + γV π∗(st+1)|st = s, at = a}

V π∗(s) = maxa∈A(s)Qπ∗(s, a)

Queste equazioni sono le equazioni di ottimalita di Bellman.

Il problema del reinforcement learning si traduce pertanto nell’apprendere

dall’esperienza le espressioni di V π∗(s) e di Qπ∗(s, a). Ovviamente questo vale

nel caso in cui si conosca la funzione che descrive la probabilita di transizione,

cioe in altri termini quando e nota la dinamica del sistema. Una volta che

conosciamo le funzioni estremanti allora e relativamente semplice ricavare la

politica ottima.

Infatti:

π∗ = argmaxa∈A(s)

∑s′∈S

P as,s′V

π∗(s)

Per ogni azione ci saranno uno o piu azioni che soddisferanno la condizione

di ottimalita di Bellman. Un risultato da evidenziare e il seguente: qualsiasi

politica che e greedy rispetto alla V-function ottima e una politica ottima.

In altri termini:

π∗ greedy rispetto a V π∗(s) =⇒ π∗ ottima nel lungo termine

Nel caso di Qπ∗(s, a) non serve neanche fare un passo all’indietro per valutare

la funzione nello stato s’, basta unicamente trovare a ∈ A(s) che la massi-

mizzi.

In molti casi concreti pero le funzioni ottime sono difficili da trovare, ci si deve

accontentare di approssimazioni. Quanto migliore e l’approssimazione, tanto

migliore sara la politica derivante. Nel prossimo paragrafo faremo qualche

commento su come comportarsi nel caso in cui la dinamica del sistema non

e pienamente conosciuta.

34


2.2.3 Exploration vs Exploitation

Spesso accade che, anche con una buona rappresentazione dello stato e un

numero sufficiente di episodi di apprendimento, l’Agente raggiunge soluzio-

ni subottime, poiche non ha ricercato nello spazio degli stati con sufficiente

profondita. D’altro canto, se sono stati usati troppi step di esplorazione non

si riesce a trovare comunque una buona politica.

Uno dei principali problemi a cui dobbiamo far fronte e ricavare, in assenza

di un modello, la funzione delle probabilita di transizione, espressa in forma

numerica.

In realta quando l’agente non conosce il modello deve bilanciare due opera-

zioni:

• exploration: consiste nell’esplorazione dello spazio degli stati nel caso

in cui sia gia stata trovata un’azione ”buona”.

• exploitation: consiste nella valorizzazione dell’azione scelta dall’agen-

te in un determinato stato, in altri termini l’agente passando per quello

stato scegliera con probabilita alta quell’azione.

Dalla definizione che abbiamo dato, si evince che le due operazioni si con-

trastano a vicenda. Infatti, aumentare il numero di volte che si preferisce

esplorare, a partire da uno stato s, piuttosto che intraprendere una strada

gia fatta, implica un minor numero di volte in cui l’agente scegliera la stessa

azione a nello stato s. Tutto quello che diremo in seguito, e orientato a tro-

vare il giusto compromesso tra le due operazioni, al fine di fornire soluzioni

adeguadatamente accurate, senza avere tempi di esecuzione non praticabili.

Supponiamo ora di avere delle ottenuto delle stime per le nostre funzioni, in

particolare consideriamo Qt(s, a). La domanda a cui vogliamo rispondere e

se effettivamente conviene sempre seguire un procedimento di tipo greedy,

ovvero scegliere per ogni s ∈ S:

a∗ = argmaxaQ∗(s, a)

La risposta a questa domanda e negativa, nel senso che bisogna permettere

all’agente di esplorare anche altre zone dello spazio degli stati.

35


Le strategie di scelta delle azioni che vengono maggiormente usate nella

pratica sono due:

ε-greedy: rinunciamo al fatto che in tutta l’evoluzione del sistema l’agen-

te agisca in maniera greedy, pertanto ci sara una piccola probabilita ε che

l’agente scelga un’altra azione, che viene scelta seguendo una distribuzione

uniforme; a prescindere dal valore greedy.

Soft-Max: il problema di una strategia di scelta ε-greedy e che le azioni

che vengono scelte con probabilita ε, sono tutte equiprobabili. In altri ter-

mini, si ha la stessa probabilita di scegliere la migliore azione (dopo quella

greedy) e la peggiore di tutte. Pertanto, in numerosi casi, si preferisce usare

una distribuzione che tenga conto anche dei valori assunti dalle azioni. Tale

distribuzione deve essere in grado di dare maggiore importanza ad azioni che

abbiano un valore alto e meno importanza ad azioni che abbiano un valore

basso.

La distribuzione piu utilizzata e quella di Gibbs:

p(s, a, τ) =eQt(s,a)/τ∑nb=1 e

Qt(s,b)/τ

n e il numero di azioni e τ e un parametro non negativo detto temperatura.

Se τ → 0 siamo alle basse temperature . In questo caso, la distribuzione

tendera a discriminare molto di piu azioni con valori bassi rispetto a quelle

con valori alti. Viceversa, nel caso in cui τ → +∞ allora siamo alle alte

temperature e la distribuzione tende a non discriminare i valori delle azioni

tra di loro, praticamente la distribuzione diventa quasi uniforme. Quella di

Gibbs non e l’unica distribuzione utilizzabile, si possono costruire distribu-

zioni che manifestano il comportamento richiesto.

Nella prossima sezione affronteremo gli algoritmi fondamentali di reinforce-

ment learning, che sono alla base degli approcci avanzati, in cui vi sono gli

algoritmi che sono stati utilizzati nel progetto dell’agente, che analizzeremo

meglio nel prossimo capitolo.

36


2.3 Algoritmi fondamentali

Gli algoritmi del reinforcement learning, possono essere appartenere ad una

di queste due classi:

• model free: nel caso in cui l’algoritmo sia in grado di far apprendere

all’agente le VF (value functions), senza aver bisogno di ricostruire il

modello del sistema.

• model based: nel caso in cui l’algoritmo fa apprendere all’agente il

modello e sulla base di questa conoscenza l’agente modifica i valori delle

VF.

Gli algoritmi, che descriveremo in questa sezione fanno riferimento a tre

metodi, ognuno dei quali ha i propri punti di forza e debolezza.

I metodi a cui facciamo riferimento sono:

• Programmazione dinamica: E ben definito dal punto di vista ma-

tematico, ma necessita di un modello ed accurato, cosa che abbiamo

detto non sempre possibile.

• Monte Carlo: Non necessitano di un modello e sono concettualmen-

te semplici, il problema e che non sono utilizzabili in caso di calcoli

incrementali passo-passo, tutto viene calcolato ogni fine episodio.

• TD (Temporal Difference): Non hanno bisogno di un modello e sono

incrementali, l’unico inconveniente e che sono difficili da analizzare.

Prima di addentrarci nell’analisi dei vari tipi di algoritmi, occorre analizzare

in breve dal punto di vista concettuale con che logica vengono fatti gli aggior-

namenti. Infatti, ogni algoritmo ha una differente regola di aggiornamento e

pertanto e opportuno capire in dettaglio i parametri di una generica regola

di aggiornamento. Nell’ultima sezione vedremo come i metodi di cui sopra

possono essere combinati, per ereditare le migliori caratteristiche di ognuno.

37


2.3.1 Approccio incrementale

La modalita di aggiornamento di tutti gli algoritmi che descriveremo e la

seguente:

NuovaStima← VecchiaStima + DimensionePasso[Target− VecchiaStima]

• Il valore [Target - VecchiaStima] indica l’errore compiuto nella stima.

• Il valore [DimensionePasso] indica quanto pesa ad ogni passo l’errore.

In processi stazionari ha senso il fatto che man mano che il sistema Agente-

Ambiente evolve, l’errore conti sempre meno. Quindi avremo che α = 1k

dove α e il passo e k il numero di volte che viene scelta l’azione a nel corso

dell’evoluzione temporale.

Nei casi non stazionari, cioe quando il comportamento del sistema cambia

nel corso del tempo e quindi non e detto che si raggiunga un valore a regi-

me, conviene selezionare un passo α costante in modo tale che venga data la

stessa importanza ad ogni stima nel corso dell’apprendimento.

Nella prossima sezione ci occuperemo di descrivere gli algoritmi fondamen-

tali che sono alla base degli approcci avanzati che analizzeremo nell’ultima

sezione.

2.3.2 Programmazione Dinamica

Con il termine programmazione dinamica (da ora in poi DP) facciamo

riferimento ad un insieme di tecniche e conseguentemente di algoritmi, che

possono essere usati per calcolare politiche ottime, previa conoscenza del mo-

dello dell’ambiente (formulato ad esempio come MDP).

Gli algoritmi DP classici non sono molto utilizzati nella pratica, ma costitui-

scono le fondamenta di tutti gli algoritmi avanzati di reinforcement learning.

Infatti, tutti i metodi che analizzeremo, sono dei tentativi di ottenere lo

stesso effetto della DP, solo con un minor numero di calcoli e assumendo la

mancanza di un modello.

In questo paragrafo assumiamo di conoscere il nostro modello, nella fattispe-

cie e una MDP con spazio degli stati e delle azioni finito. Si dimostra infatti,

sotto queste ipotesi, che i metodi DP convergono all’ottimo. In mancanza di

38


queste ipotesi la convergenza di tali metodi e possibile sono in casi rari.

L’idea fondamentale della programmazione dinamica, come anche del rein-

forcement learning in generale, e l’uso dei valori degli stati e delle azioni, per

cercare buone politiche.

Valutazione di una politica: Ora consideriamo come calcolare la fun-

zione V π(s) data una politica π e uno stato di partenza s.

Questo problema e noto anche come problema di predizione o anche policy

evaluation5. Nel caso in cui la dinamica del sistema e completamente cono-

sciuta, si tratta di risolvere un sistema di equazioni lineare di |S| equazioni

in |S| incognite (|S| e la cardinalita dello spazio degli stati).

In generale, si preferisce utilizzare metodi iterativi :

Vk+1(s) =∑a∈A(s)

π(s, a)∑s′∈S

P as,s′ [R

as,s′ + γVk(s

′)]

Questo viene fatto ∀s ∈ S.

Sotto le ipotesi che abbiamo fatto, si puo osservare che l’operatore V e una

contrazione in uno spazio di Banach. Questo ci garantisce esistenza e unicita

in virtu del teorema delle contrazioni, e il metodo di cui sopra e proprio un

metodo di punto fisso pertanto per k →∞ Vk converge all’ottimo.

Quindi l’algoritmo di valutazione di una politica, consiste nell’applicare un

metodo iterativo alla risoluzione dell’equazione di ottimalita di Bellman. Sic-

come la convergenza ci e garantita solo per k → ∞, dobbiamo acconten-

tarci di avere buone approssimazioni imponendo una condizione d’arresto

|Vk+1(s)− Vk(s)| < η con η sufficientemente piccolo.

Miglioramento di una politica: Abbiamo visto come calcolare la V π

data una π fissata perche ci e utile per ricercare politiche migliori.

Supponiamo, infatti, di fissare uno stato s. Vogliamo capire in che condizioni

conviene scegliere a 6= π(s). E opportuno osservare che la politica che stiamo

considerando e deterministica, considerazioni analoghe possono essere fatte

nel caso in cui la politica sia stocastica.

Un modo per rispondere a questa domanda e calcolare il valore di eseguire

5da qui in poi faremo riferimento agli algoritmi mediante la dicitura anglosassone.

39


l’azione a nello stato s:

Qπ(s, a) =∑s′∈S

P as,s′ [R

as,s′ + γV (s′)]

In effetti, se Qπ(s, a) e maggiore di V π(s), converra eseguire ogni volta che

incontriamo lo stato s, l’azione a. Il viceversa accade nel caso opposto.

Questo risultato e un caso particolare di uno piu generale noto come teorema

del miglioramento di una politica6.

Se π e π′ sono una generica coppia di politiche, tali che ∀s ∈ S:

Qπ(s, π′(s)) ≥ V π(s)

Allora la politica π′ sara migliore o al piu equivalente a π.

In formule:

Qπ(s, π′(s)) ≥ V π(s) ∀s ∈ S =⇒ V π′(s) ≥ V π(s)∀s ∈ S

Da questo teorema deriva la considerazione che se scegliamo in ogni stato

l’azione che ci sembra la migliore, ovvero quella che massimizza Qπ(s, a),

otterremo la migliore politica derivabile dalla conoscenza di Qπ(s, a).

La nuova politica π′ sara calcolata nel modo seguente:

π′(s) = argmaxaQπ(s, a) = argmaxa

∑s′∈S

P as,s′ [R

as,s′ + γV π(s)]

Quello che abbiamo fatto e di trovare una politica che sia greedy rispetto al

valore calcolato. Questa procedura e detta policy improvement.

Nel caso in cui π ≡ π′ =⇒ V π = V π′ =⇒ V soddisfa l’equazione di ottimalita

di Bellman.

Come detto in precedenza, criteri analoghi possono essere utilizzati in caso

di politica stocastica.

Policy Iteration: A questo punto possiamo osservare che se combiniamo

entrambi i metodi esposti precedentemente, possiamo ottenere un algoritmo

in cui:

6questo risultato e alla base per dimostrare la convergenza di tutti i metodi che

studieremo, noi in molti casi non forniremo dimostrazioni.

40


• V converge verso il suo valore ottimo V ∗.

• π → π∗

Infatti, supponiamo di partire da una politica fissata π. Possiamo, quindi

prima valutare la politica e poi farne il miglioramento. Quello che risultera

da questo processo e aver ottenuto una politica migliore di quella di parten-

za. Se ripetiamo questo processo fino al raggiungimento del valore ottimo

otteniamo il cosidetto algoritmo policy iteration.

Quello che facciamo e:

• fissare una politica di partenza π0

• eseguire:

π0E→ V π0 I→ π1

E→ V π1 I→ π2E→ V π2 I→ ...

I→ π∗E→ V π∗

Dove E denota il passo di valutazione (policy evaluation) e I denota il passo

di miglioramento (policy improvement).

Value Iteration: Uno svantaggio dell’algoritmo policy iteration e che in

ogni passo dobbiamo valutare una politica. Questo comporta un procedi-

mento iterativo di cui non conosciamo a priori il tempo di convergenza, che

dipendera fra l’altro da come e stata scelta la politica di partenza.

Un modo per ovviare a questo inconveniente e troncare la valutazione dellla

politica ad un certo passo. Questa operazione non modifica la garanzia di

convergenza al valore ottimo. Un caso particolare in cui si blocca la valu-

tazione della politca ad un backup7 per stato (detto anche sweep) da vita

all’algoritmo value iteration. Per completezza possiamo scrivere l’equazione

che descrive quello che fa l’algoritmo:

Vk+1(s) = maxaE{rt+1 + γVk(st+1)|st = s, at = a} =

= maxa∑s′∈S

P as,s′ [R

as,s′ + γVk(st+1)]

7per backup intendiamo il procedimento di valutazione di V o Q in uno stato precedente

a quello dato

41


Questo ovviamente e fatto ∀s ∈ S. Un altro modo di vedere quest’equazione

e come una trasformazione dell’equazione di ottimalita di Bellman in una

regola di aggiornamento.

L’algoritmo termina quando il valore di Vk+1 differisce da Vk di una quantita

sufficientemente piccola in uno sweep. Value iteration combina, quindi, uno

sweep di policy evaluation e uno sweep di policy imporvement. Chiaramente

possiamo anche pensare di aumentare il numero di sweep, questo ci assicura

una convergenza piu veloce, ma un onere di calcolo maggiore.

Generalized Policy Iteration: Gli algoritmi che abbiamo descritto in

questi ultimi paragrafi si basano essenzialmente su due processi che avvengo-

no in parallelo: policy evaluation e policy improvement. L’esecuzione ripetu-

ta di questi due processi fa convergere il processo generale verso la soluzione

ottima, come e riportato nella figura 2.5.

L’idea di far interagire questi due processi va sotto il nome di Generalized

Policy Iteration. La cosa importante e che possiamo far in modo che i due

processi agiscano sulla stessa risorsa e non su due risorse diverse cioe su

(π, V ).

In questo caso i due processi sono sia in competizione che in cooperazione.

Scegliere una politica che sia greedy rispetto alla funzione rende, in generale,

la funzione V inconsistente rispetto alla politica π. Viceversa, la politica π

tipicamente e non greedy rispetto alla funzione V π. Nonostante questi pro-

blemi, il processo nel lungo periodo converge al valore ottimo di V e di π

come e espresso sinteticamente nella figura 2.6. L’ultima cosa che vogliamo

mettere in evidenza e una speciale proprieta dei metodi DP. Tutti gli aggior-

namenti delle stime in uno stato sono basati sulle stime degli aggiornamenti

fatte nei suoi successori. Questa proprieta e nota come bootstraping.

2.3.3 Metodi Monte Carlo

Le tipologie di apprendimento che possono essere fatte sono di due tipi:

• esperienza simulata

• esperienza sul sistema reale

42


V

evaluation

improvement

V V

greedy(V)

*V*

Figura 2.5: Processo di Generalized Policy Iteration.

In generale e complesso avere a priori la distribuzione dei campioni generati

da un sistema, pero si possono generare campioni che sono in linea con tale

distribuzione, per fare apprendimento. I metodi Monte Carlo sono modi per

risolvere i problemi calcolando la media dei guadagni per stato fatti in un

episodio. Per questo motivo, i metodi MC sono metodi di apprendimento

episodici. Una cosa che i metodi MC hanno in comune con i metodi DP e

su come interagiscono con le funzioni per valutare il valore degli stati e delle

azioni per ottenere l’ottimalita.

Monte Carlo Policy Evaluation: Ora vogliamo usare i metodi Monte

Carlo per apprendere la V-function data una certa politica che fissiamo a

priori.

In particolare, supponiamo di voler stimare V π(s) dato un insieme di episodi

ottenuti seguendo la politica π. Ogni volta che transitiamo per lo stato s

durante un episodio, diremo che abbiamo visitato lo stato s.

43


startingV

V = V

= gree d y (V )

V**

Figura 2.6: Co-convergenza, value function e politica.

A questo punto dividiamo gli algoritmo MC in due tipi a seconda del metodo

di visita:

• every-visit MC: la stima di V π(s) viene fatta come la media dei

guadagni provenienti da tutte le visite di s in un insieme di episodi.

• first-visit MC: si effettua la media solo dei guadagni provenienti

dalla prima visita di s.

Entrambi i metodi all’aumentare del numero dei campioni convergono a

V π(s). Nel caso del metodo first-visit questa proprieta di convergenza e

diretta conseguenza della legge dei grandi numeri. Una caratteristica impor-

tante dei metodi MC e che le stime per ogni stato sono indipendenti. In altri

termini, la stima che facciamo della V o della Q in uno stato, non risulta

costruita da stime in altri stati come accadeva nei metodi DP. Per questo

motivo diciamo che i metodi MC non godono della proprieta di fare boo-

tstrap.

Un altro vantaggio e che il costo computazionale di stimare il valore di un

singolo stato e indipendente dal numero degli stati8

Stima MC per i valori delle azioni: Se non disponiamo di un modello,

e piu utile stimare i valori delle azioni piuttosto che il valore degli stati.

8per esempio e utile se voglio calcolare il valore solo per un sottoinsieme di stati piuttosto

che per tutto l’insieme.

44


Uno degli obiettivi principali dei metodi MC e quello di calcolare Q∗. Nel

caso di valutazione dei valori delle azioni, le considerazioni sui tipi di metodi

MC sono equivalenti. L’unica cosa da aggiungere e che ci sono anche le

azioni da considerare. Per evitare problemi e confrontare alternative abbiamo

bisogno di stimare il valore di tutte le azioni in uno stato, non solo quella

che prediligiamo.

Un modo semplice per assicurare questa cosa e che l’azione al primo passo

possa essere scelta con una certa probabilita non nulla. Questo ci garantisce

che ogni azione verra scelta in un gran numero di episodi. Questa assunzione

non e utile in casi piu generali, quando abbiamo un contatto diretto con il

sistema reale. Alternativamente, si puo pensare di considerare solo politiche

che sono stocastiche, e quindi avere una probabilita non nulla di scegliere

tutte le azioni. Prima di procedere e parlare di un metodo di controllo di

tipo MC facciamo un’ulteriore distinzione tra gli algoritmi:

• on-policy: l’agente apprende modificando la politica che sta seguen-

do.

• off-policy: l’agente apprende modificando un’altra politica, diversa

dalla politica che sta seguendo.

Controllo di tipo Monte Carlo: Anche per i metodi di tipo Mon-

te Carlo possiamo utilizzare un approccio di tipo GPI (Generalized Policy

Iteration). Per la fase di policy evaluation, possiamo seguire un metodo di

valutazione indicato nel paragrafo precedente.

Facciamo per il momento due ipotesi:

• c’e una probabilita non nulla di scegliere ogni azione nello stato iniziale.

• numero infinito d’iterazioni.

Il policy improvement e fatto rendendo la corrente politica greedy rispetto

alla Qπ(s, a) calcolata nel passo precedente:

π(s) = argmaxaQπ(s, a)

Questo viene fatto ∀s ∈ S. La politica πk+1(s) calcolata al passo k viene

calcolata da πk(s) in questo modo. Quando la politica diventa stabile nel

45


senso che πk+1(s) ≡ πk(s) ∀s ∈ S, allora significa che abbiamo trovato la

politica ottima e la corrispondente Q∗.

Per ogni azione a ∈ A(s):

Qπk(s, πk+1(s)) = Qπk(s, argmaxaQπk(s, a)) = maxaQ

πk(s, a) ≥ Qπk(s, a)

Per concludere ci limiteremo a rimuovere la seconda ipotesi. Per fare cio

possiamo operare in due modi:

1. Porre delle condizioni di arresto nella policy evaluation di Qπk(s, a),

che in genere richiede molti passi.

2. Dopo ogni episodio, sulla base del guadagno, viene fatto un passo di

policy evaluation9e uno di policy improvement.

Nella prossima sezione ci occuperemo dei metodi di apprendimento tempo-

ral difference, che sono alla base degli approcci che utilizzeremo nella fase

sperimentale.

2.3.4 Metodi TD

Tutto quello che abbiamo descritto finora era per introdurre i metodi tem-

poral difference.

I metodi TD:

• ereditano dai metodi Monte Carlo l’idea d’imparare direttamente dal-

l’esperienza accumulata interagendo con il sistema, senza la dinamica

del sistema stesso.

• ereditano dai metodi DP l’idea di aggiornare la stima delle funzio-

ni in uno stato a partire dalle stime fatte in altri stati (cioe fanno il

bootstrap).

9nel senso che non attendiamo che si facciano tutti i passi del metodo fino ad ottenere

la convergenza.

46


Partiamo con l’analizzare come viene valutatata la politica, cioe il problema

di predizione. Per il problema di controllo, ovvero quello di trovare la poli-

tica ottima, anche TD usa varianti del metodo piu generale GPI. Le princi-

pali differenze tra i metodi TD, DP e Monte Carlo risiedono nella logica di

risoluzione del problema di predizione.

Il problema di predizione TD: Abbiamo visto che i metodi Monte

Carlo, nonostante abbiano una regola di aggiornamento che permette l’ap-

prendimento tramite esperienza, devono aspettare la fine dell’episodio per

compiere gli aggiornamenti. Nel caso dei metodi TD, invece, l’approccio e

completamente incrementale ovvero l’apprendimento viene fatto ad ogni pas-

so temporale. Il metodo TD piu semplice e noto come TD(0) in cui la regola

di aggiornamento e:

V (st)← V (st) + α[rt+1 + γV (st+1)− V (st)]

A differenza dei metodi MC che hanno come obiettivo dell’aggiornamento

Rt, il metodo TD(0) ha come obiettivo rt+1 + γVt+1(st+1).

TD(0) combina le stime di DP e di Monte Carlo :

1. campiona il valore atteso di Rt come nei metodi Monte Carlo.

2. usa una stima di V calcolata all’istante t piuttosto che V π come nei

metodi DP.

A questo punto possiamo analizzare i vantaggi che hanno i metodi TD rispet-

to ai metodi Monte Carlo e DP. Il vantaggio piu evidente rispetto ai metodi

DP e che non richiedono un modello dell’ambiente. Il vantaggio rispetto ai

metodi Monte Carlo sta proprio nel fatto che i metodi Monte Carlo sono epi-

sodici e i metodi TD sono ”passo-passo”. Questo in linea di principio rende

l’apprendimento piu veloce. Inoltre, si dimostra che TD(0) converge verso la

soluzione ottima.

Ora analizziamo tre metodi che usano metodi di predizione TD per il pro-

blema di controllo:

• SARSA

47


• Q-learning

• Actor-Critic

SARSA: In questo tipo di controllo useremo il pattern della Generalized

Policy Iteration, solo che adesso utilizziamo i metodi TD per la parte di valu-

tazione. Ancora una volta dobbiamo trovare un compromesso tra exploration

ed exploitation. Adesso analizziamo un metodo di controllo TD on-policy.

Il primo passo e imparare una funzione di valutazione delle azioni piuttosto

che una funzione di valutazione dello stato. In questo caso infatti, dob-

biamo stimare Qπ(s, a) per ogni stato ed ogni azione che puo essere fatta

a partire da quello stato. Non consideriamo piu transizioni stato-stato ma

consideriamo transizioni tra coppia stato-azione a coppia stato-azione. Dal

punto di vista della convergenza considerare una rappresentazione o l’altra ,

non altera i risultati di convergenza. Quindi, applicando TD(0), la regola di

aggiornamento diventa:

Q(st, at)← Q(st, at) + α[rt+1 + γQ(st+1, at+1)−Q(st, at)]

Questo aggiornamento viene fatto dopo ogni transizione per uno stato non

terminale st. Se st+1 e terminale, allora Q(st+1, at+1) e posta uguale a zero.

Questa regola di aggiornamento usa tutti e cinque gli elementi della quintupla

(st, at, rt+1, st+1, at+1) per questo motivo e chiamato SARSA (State-Action-

Reward-State-Action). A questo punto possiamo rendere la politica π greedy

rispetto a Qπ e ripetere la valutazione della nuova politica, tramite il metodo

appena trattato.

La convergenza dell’algoritmo SARSA dipende dalla natura della dipendenza

della politica rispetto a Q.

Q-learning: Questo algoritmo (Watkins) ha una logica di controllo off-

policy, nella sua forma piu semplice la regola di aggiornamento e definita nel

modo seguente:

Q(st, at)← Q(st, at) + α[rt+1 + γmaxaQ(st+1, a)−Q(st, at)]

In questo caso, la funzione di valore delle azioni, Q, approssima direttamente

Q∗, la politica ottima risultera indipendente dalla politica che e stata seguita

48


Policy

TDerror

Environment

ValueFunction

reward

state action

Actor

Critic

Figura 2.7: Schema a blocchi per l’algoritmo Actor-Critic.

durante il processo di apprendimento. L’unico impatto che ha la politica e

quello di determinare quali coppie stato-azione verranno visitate e quindi ag-

giornate. Quello che viene richiesto al fine di avere una corretta convergenza

e che tutte le coppie stato-azione continuino ad essere aggiornate.

Sono state fornite comunque dimostrazioni di convergenza di Q-learning.

Metodi Actor-Critic: Questi metodi hanno la caratteristica di separa-

re la struttura di memoria per rendere indipendenti la politica, dalla value

function. Il blocco della politica e noto come attore, perche sceglie le azioni,

il blocco della value function stimata e noto come critico, nel senso che ef-

fettua una critica sulle azioni compiute dalla politica che si sta seguendo. Da

cio s’intuisce che l’apprendimento e di tipo on-policy, infatti il critico impara

e critica l’operato della politica. In questo schema il critico prende la forma

di un errore di differenza temporale (TD error), nella figura 2.7 e riportato

lo schema a blocchi che descrive il funzionamento dell’algoritmo. I segnali in

uscita al critico sono riportati in ingresso sia all’attore che al critico stesso.

49


Tipicamente, il critico e una funzione di valuzione dello stato. Dopo ogni

selezione di un’azione, il critico valuta il nuovo stato per determinare se le

cose sono andate meglio o peggio di come si aspettava.

Questa valutazione e l’errore TD:

δt = rt+1 + γV (st+1)− V (st)

dove V e la value function corrente implementata dal critico. Questo errore

puo essere utilizzato per valutare l’azione appena selezionata, l’azione at

fatta nello stato st. Se l’errore e positivo, fa pensare al critico che l’azione at

deve essere rafforzata, mentre nel caso opposto indebolita. Supponiamo di

considerare una distribuzione di tipo Gibbs:

πt(s, a) =ep(s,a)∑nb=1 e

p(s,b)

La funzione p(s, a) esprime la preferenza dell’attore di selezionare l’azione a

nello stato s. La forza o la debolezza nello scegliere un’azione e modulata

usando la seguente relazione:

p(st, at)← p(st, at) + βδ

dove β e un altro parametro di selezione del passo.

Un’altra regola di aggiornamento spesso utilizzata nelle implementazioni e la

seguente:

p(st, at)← p(st, at) + βδ(1− πt(st, at))

2.4 Algoritmi avanzati

In questa sezione descriveremo due importanti meccanismi di reinforcement

learning. Si tratta di miglioramenti fatti agli algoritmi che sono basati su

TD.

2.4.1 Tracce di eleggibilita

Le tracce di eleggibilita (elegibility traces) sono uno dei meccanismi di

base del reinforcement learning.

50


Possiamo analizzare il significato delle tracce di eleggibilita da due punti di

vista:

• teorico: possono essere visti come ponti che interconnettono metodi

TD a metodi Monte Carlo. Quando ai metodi TD vengono aggiunte

le tracce di eleggibilita, vengono prodotti una famiglia di metodi che

coprono un spettro che ha ad un estremo metodi Monte Carlo e all’altro

metodi TD.

• meccanicistico: da questo punto di vista una traccia di eleggibilita

e una struttura che memorizza un evento, come ad esempio la visita

di uno stato o la decisione di compiere un’azione. La traccia marca i

parametri di memoria associati all’evento come eleggibili per modifche

dei parametri di apprendimento. Quando c’e un errore TD, solo agli

stati o alle azioni elette vengono assegnati colpe per l’errore.

Quindi le tracce di elegibilita aiutano a colmare il gap tra gli eventi e le

informazioni ricevute per l’apprendimento.

Il punto di vista teorico viene detto anche forward view, mentre quello

meccanicistico viene detto anche backward view.

Predizione TD a n-passi: I metodi di predizione TD in n-passi sono

metodi in cui non viene fatto solo un passo di backup, ma n-passi. L’obietti-

vo dell’aggiornamento e il guadagno atteso dopo gli n-passi, esso viene fatto

a partire da stime della V-function nei successori dello stato s e analizzato in

un particolare istante di tempo. Da un punto di vista formale se consideria-

mo una sequenza stato-reward st, rt+1, st+1, rt+2, ..., rT , sT , l’aggiornamento

in questo tipo di metodi avviene in questo modo:

Rnt = rt+1 + γrt+2 + γ2rt+2 + ...+ γn−1rt+n + γnVt(st+n)

Il termine di errore ∆Vt(st) che viene aggiunto alla funzione Vt(st) e:

∆Vt(st) = α[Rnt − Vt(st)]

A questo punto possiamo anche definire semplicemente le regole di aggiorna-

mento:

51


• aggiornamento on-line: in cui al passo t + 1, per ogni s ∈ S viene

applicato il segunete aggiornamento Vt+1(s) = Vt(s) + ∆Vt(s)

• aggiornamento off-line: in cui l’aggiornamento viene fatto solo alla

fine degli n-passi (alla fine dell’episodio) e quindi per ogni s ∈ S

V (s)← V (s) +T−1∑t=0

∆Vt(s)

Il fatto di aver complicato la regola di aggiornamento ha effetto sull’errore

compiuto nel caso peggiore:

ηn = maxs|Eπ{Rnt |st = s} − V π(s)| ≤ γnmaxs|V (s)− V π(s)|

Osserviamo che a parita di errore desiderato, nel caso in cui il fattore di

sconto γ sia maggiore abbiamo bisogno di un maggiore numero di passi.

I metodi di predizione n-passi non utilizzati in pratica a causa dell’elevato

costo computazionale, ma sono la base per l’analisi delle tracce di eleggibilita.

TD(λ) Forward view: Il metodo TD(λ) puo essere pensato come un

modo particolare di fare una media di piu esecuzioni di un approccio n-passi,

con n variabile. Infatti, in questo caso si fa una media combinando i backup

semplici calcolati con un processo a n-passi. Questa media, contiene tutti i

backup fatti su n-passi, ognuno pesato e proporzionale a λn−1. Quest’ultimo

viene moltiplicato per (1−λ) per far in modo che la somma su tutti gli n sia

pari ad 1.

Pertanto, il guadagno conterra anche un contributo dovuto a λ:

Rλt = (1− λ)

∞∑n=1

λn−1R(n)t

Analogamente all’algoritmo a n-passi possiamo nell’ algoritmo TD(λ) forward

view l’errore viene aggiornato nel modo seguente:

∆Vt(st) = α[Rλt − Vt(st)]

52


times of state visits

accumulating trace

replacing trace

Figura 2.8: Effetti delle tracce di eleggibilita e delle tracce di rimpiazzo

nell’apprendimento

TD(λ) Backward view: L’algoritmo TD(λ) con forward view e non

causale, questo significa che e solo utile teoricamente ma non puo essere

applicato nella pratica. Infatti, nel caso precedente abbiamo visto che la

valutazione fatta in un istante dipendeva, sostanzialmente, dalle valutazioni

fatte in altri instanti, successivi in ordine cronologico.

Nella formulazione backward view di TD(λ), viene introdotta una variabile

in memoria, che rappresenta appunto la traccia di eleggibilita.

Dato uno stato s e un istante t, la traccia di eleggibilita e rapprensentata

come un numero reale positivo et(s).

E utile definire et(s) nel seguente modo:

et(s) =

{γλet−1(s) se s 6= st

γλet−1(s) + 1 se s = st

Questa definizione vale ∀s ∈ S. In questa formula ci sono due parametri: γ

che indica un tasso di sconto, mentre λ e noto come parametro di decadimento

della traccia.

Questo tipo di traccia e detta accumulante perche accumula le visite di ogni

stato e poi decade gradualmente a seconda del tempo trascorso da quando

lo stato s e stato visitato per l’ultima volta, questo fenomeno e riportato

nella figura 2.8. Pertanto, ad ogni istante di tempo, le tracce di eleggibilita

memorizzano un valore che sara piu alto per gli stati recentemente visitati e

piu basso per quelli che non vengono visitati da molto tempo. Nella figura

53


2.8 e riportata anche un altro tipo di traccia detto traccia di rimpiazzo

(replacing traces), questo tipo di traccia verra analizzata piu nel dettaglio

in seguito.

In questo caso l’errore con il quale viene aggiornata la funzione Vt(st) e:

∆Vt(st) = αδtet(s)

dove δt e l’errore introdotto nelle precedenti sezioni.

Quindi l’algoritmo stima all’istante t+ 1, guardando indietro nel tempo cioe

guardando all’istante t, in base ad un indicatore del tempo di visita dello sta-

to s in esame che per l’appunto e memorizzato nella traccia di eleggibilita.

Nel prossimo paragrafo analizziamo le varianti degli algoritmi introdotti nella

precedente sezione, muniti questa volta di traccia di eleggilita. Ci occupe-

remo, brevemente, di Sarsa(λ) e Q(λ), tralasceremo Actor-Critic(λ) perche

sfrutta idee simili a Sarsa(λ).

Sarsa(λ): L’idea in Sarsa(λ) e quella di applicare il metodo di predizione

TD(λ) alle coppie stato-azione, piuttosto che agli stati. Chiaramente adesso

la traccia di eleggibilita non dovra tenere conto solo dello stato, ma anche

delle azioni.

Quindi in questo caso la regola sara:

Qt+1(s, a) = Qt(s, a) + αδtet(s, a)

Questo aggiornamento viene fatto per ogni stato e per ogni azione.

Inoltre

δt = rt+1 + γQt(st+1, at+1)−Qt(st, at)

e

et(s, a) =

{γλet−1(s, a) + 1 se s = st e a = at

γλet−1(s, a) altrimenti

L’algoritmo Sarsa(λ) eredita le principali caratteristiche della sua versione

one-step.

Q(λ): L’uso delle tracce di elegibilita nel caso di Q-learning e piu de-

licato. L’algoritmo Q-learning e un algoritmo off-policy, infatti viene fatto

54


l’apprendimento della politica greedy mentre tipicamente viene seguita un’al-

tra politica che e piu che altro esplorativa.

Abbiamo due varianti principali dell’algoritmo Q(λ):

• variante di Watkins.

• variante di Peng.

L’idea della variante di Watkins e quella di non guardardare indietro fino

alla fine dell’episodio, ma solo fino alla prima azione esplorativa. Se voles-

simo essere piu precisi guarda alla prima azione dopo la prima esplorazione

fatta nell’episodio corrente. Tralasciamo i dettagli riguardo le variabili usate

dall’algoritmo, poiche sono simili a quelli gia visti per Sarsa(λ). Sfortunata-

mente questo approccio fa perdere la maggior parte dei vantaggi delle tracce

di eleggibilita. Infatti, se le azioni esplorative sono frequenti, allora verranno

fatti dei backup di al piu un paio di passi. La variante di Peng cerca di

ovviare a questo problema. In questo caso non c’ e distinzione tra le azioni

esplorative e quelle greedy. Ogni componente del backup viene fatta su molti

passi e alla fine di tutti gli step viene compiuta un’azione di massimizzazio-

ne. Questo algoritmo, in realta e un ibrido tra algoritmo on-policy ed uno

off-policy.

2.4.2 Tracce di rimpiazzo

Le tracce di rimpiazzo (replacing traces) sono usate per far in modo che il

valore della traccia di eleggibilita non superi 1. In altri termini, le tracce

di rimpiazzo ottimizzano il lavoro che fanno le tracce di eleggibilita, come e

stato gia osservato nella figura 2.8. Da un punto di vista formale, una traccia

di rimpiazzo per uno stato discreto s e definito da:

et(s) =

{γλet−1(s) se s 6= st

1 se s = st

Ci sono molti modi per generalizzare l’uso del rimpiazzo nelle tracce di eleggi-

bilita per l’uso nei metodi di controllo. Un approccio raccomandato e quello

55


0.2

0.3

0.4

0.5

0 0.2 0.4 0.6 0.8 1

accumulatingtraces

replacingtraces

RMS errorat best

Figura 2.9: Un esempio di confronto tra tracce di eleggibilita e tracce di

rimpiazzo, al variare di λ, in un processo di predizione random-walk a 19 passi.

dovuto a Sutton e Singh:

et(s, a) =

1 se s = st e a = at

0 se s = st e a 6= at

γλet−1(s, a) se s 6= st

L’uso delle tracce di rimpiazzo in molti casi puo incrementare in maniera

significativa il tasso di apprendimento, la figura 2.9 mostra proprio questo

fenomeno in un caso di analisi dell’errore di un processo di predizione al

variare di λ. In particolare, si puo osservare che il valore quadratico medio,

avendo scelto la dimensione del passo di aggiornamento α in maniera ottima,

per λ maggiore di un certo valore (che nel caso specifico e 0.6) e minore nel

caso di utilizzo della traccia di rimpiazzo al posto della semplice traccia di

eleggibilita.

2.5 Conclusioni

In questo capitolo abbiamo fornito una panoramica principali degli approcci

per fare reinforcement learning. Abbiamo iniziato con il descrivere in maniera

56


generale i processi di decisione decisione sequenziale e ne abbiamo specifica-

to i principali tipi, distinguendoli in base alle proprieta della probabilita di

transizione e in base all’osservabilita del sistema. Successivamente, abbiamo

analizzato il problema generale del reinforcement learning, evidenziando in

prima istanza il modello Agente-Ambiente. In ipotesi di completa osserva-

bilita dell’Ambiente, l’Agente riceve lo stato e la reward al tempo t e decide

la successiva azione di compiere at+1 che portera il sistema nello stato st+1.

Per modellare il problema da un punto di vista analitico, si sono introdotte

la funzione V che rappresenta quanto e positivo, da parte dell’agente, per

il raggiungimento dello stato target trovarsi nello stato, e la funzione Q che

rappresenta quanto e positivo, da parte dell’agente, scegliere l’azione a se

l’Ambiente si trova nello stato s. Dopo aver formalizzato il problema da un

punto di vista analitico, abbiamo constatato che l’obiettivo del reinforcement

learning e quello di trovare una o piu politiche ottime. Uno dei principali

obiettivi dei metodi di reinforcement learning e quello di trovare il giusto

compromesso tra ”exploration” ed ”exploitation”, cioe tra l’esplorazione dello

spazio degli stati, nonostante l’Agente conosca gia come si comportano le

azioni in molti casi, e dare la giusta ”importanza” a queste azioni. In questo

contesto abbiamo introdotto due metodologie di esplorazione. La prima e la

modalita ε-greedy in cui in uno stato viene scelta un’azione diversa da quella

ottima con probabilita ε, tutte le azioni possibili sono equiprobabili, questo

vuol dire che la migliore azione dopo quella ottima e la peggiore azione in

assoluto possono essere scelte con la stessa probabilita. Per superare le limi-

tazioni di questo approccio abbiamo introdotto la seconda modalita di scelta

detta Soft-Max. Quest’ultimo metodo ha il vantaggio rispetto alla modalita

ε-greedy di fare una gerarchia delle azioni in modo da scegliere con una proba-

bilita piu alta l’azione migliore dopo quella ottima e con probabilita piu bassa

la peggiore azione in assoluto. Successivamente, abbiamo parlato da un punto

di vista generale degli algoritmi di reinforcement distinguendoli dal punto di

vista della costruzione del modello dell’Ambiente in model-free e model-based

e dal punto di vista della modalita di apprendimento in on-policy e off-policy.

Abbiamo parlato degli approcci basilari del reinforcement learning. Il primo

approccio e la Programmazione Dinamica in cui lo svantaggio e che l’Agente

deve conoscere il modello, abbiamo visto che i metodi di programmazione di-

57


namica godono della proprieta di fare bootstrap (cioe di stimare il valore di V

in uno stato a partire dal valore di V in altri stati). Abbiamo parlato di come

trovare il valore V π di una politica π (policy-evaluation) e di come migliorare

una politica π, sapendo V π (policy-improvement). Inoltre, abbiamo parlato

degli algoritmi policy-iteration e value-iteration e abbiamo detto che sono

una combinazione di policy-evaluation e policy-improvement e che godono

della proprieti. convergere sia al valore ottimo di V π∗ , sia alla politica ottima

π∗. Abbiamo parlato anche del pattern piu generale GPI (Generalized Policy

Iteration) che consiste in un miglioramento dell’approccio di policy-iteration.

Poi abbiamo parlato della seconda classe di metodi fondamentale, noti co-

me metodi Monte Carlo. Questi metodi non necessitano di una conoscenza

del modello e sono episodici. L’apprendimento avviene tramite algoritmi che

acquisicono in ingresso sequenze di campioni che sono in accordo ad una va-

riabile aleatoria che in generale non puo essere conosciuta in maniera facile.

Le stime dei valori degli stati sono fatte effettuando una media dei guadagni

ricevuti in ogni episodio. Abbiamo osservato in primo luogo che ogni esecu-

zione di un metodo Monte Carlo e indipendente dalle altre, in altri termini

non fanno il bootstrap. In secondo luogo, i metodi Monte Carlo sfruttano il

concetto di visita di uno stato, cioe la stima del valore di uno stato viene fatta

effettuando la media solo dei guadagni provenienti dalla prima visita (first-

visit), o dei guadagni provenienti da tutte le visite dello stato (every-visit).

Abbiamo introdotto successivamente un importante classe di metodi noti co-

me metodi Temporal Difference che ereditano le principali caratteristiche sia

dei metodi Monte Carlo (acquisizione dell’esperienza), sia dei metodi di Pro-

grammazione Dinamica (fanno boostrap). La caratteristica fondamentale dei

metodi TD e quella di essere incrementale: adesso i guadagni non vengono

piu acquisiti alla fine dell’episodio, ma vengono acquisiti ad ogni passo di

apprendimento. Poi abbiamo analizzato piu in dettaglio gli algoritmi TD(0),

SARSA e Q-learning. Infine, abbiamo parlato degli approcci avanzati con

l’introduzione delle tracce di eleggibilita e tracce di rimpiazzo. Per quello che

riguarda le tracce di eleggibilita le abbiamo descritte sia da un punto di vista

teorico forward-view, sia da un punto di vista pratico backward-view. Le trac-

ce di eleggibilita sono dei numeri che vengono aggiornati per tenere traccia

delle visite di uno stato, al fine di incrementare la capacita di apprendimento

58


dell’Agente. I metodi TD muniti di traccia di eleggibilita, possono essere

visti come una famiglia di metodi che hanno ad un estremo il metodo TD ad

un passo e ad un altro estremo un metodo Monte Carlo. Abbiamo descritto

gli algoritmi fondamentali TD con traccia di eleggibilita (SARSA(λ), Q(λ),

ActorCritic(λ)). Infine nell’ultima parte abbiamo parlato piu in dettaglio

delle tracce di rimpiazzo, che vengono usate nella pratica per incrementare

ulteriormente la capacita di apprendimento dell’Agente.

59

CAPITOLO 3

Architettura proposta

In questo capitolo, analizziamo l’architettura proposta per generare un wor-

kload che serva a pilotare il sistema in uno stato, una volta raggiunto lo

stato si puo iniettare un faultload per effettuare fault injection. Nel primo

paragrafo faremo una panoramica del sistema descrivendo la struttura ed

i tool utilizzati per l’implementazione. Successivamente, daremo una vista

statica del sistema, descrivendolo poi blocco per blocco. Poi, vedremo come

si comporta il sistema dinamicamente, per fare cio analizzeremo lo scenario

di un esperimento. Infine, vedremo come e stato strutturato un esperimento

dal punto di vista dell’implementazione.

3.1 Panoramica

Il sistema e stato progettato per effettuare reinforcement learning on-line,

per fare cio si sono dovute modificare delle classi all’interno del toolbox RL,

in modo da adattarle al fine di poter effettuare apprendimento online.

E costituito da tre sottosistemi:

• Agente.

60

3. Architettura proposta

• Gestore delle richieste.

• Ambiente.

Il sottosistema Agente, che contiene le classi e le interfacce costituenti l’agen-

te, si occupa di gestire l’apprendimento di una politica in base all’algoritmo

scelto e d’interfacciarsi agli altri sottosistemi per il controllo.

Il sottosistema Gestore delle richieste si occupa di generare il workload che

arrivera al sistema sotto analisi.

Il sottosistema Ambiente si occupa di fornire un ambiente in cui puo essere

iniettato un carico puo essere costituito da uno o piu code, ogni coda ha il

proprio tempo di servizio.

Il sistema e stato implementato in C++, di seguito riportiamo i dettagli

tecnici, riguardo all’ambiente :

• Sistema operativo: Linux Fedora 13, con kernel 2.6.11− 1.1369.

• Compilatore: g++ 4.0.0.

• Librerie esterne: Boost 1.46.1 , RL Toolbox 2.0.0 , Asio 1.48.1.

Tutti i sottosistemi sono implementati come processi che comunicano tra di

loro, la comunicazione avviene tramite scambio di messaggi sulla rete.

I tre sottosistemi si coordinano per:

• permettere all’agente di apprendere.

• permettere lo scambio delle informazioni tra i processi tramite messag-

gi.

• permettere all’agente l’esecuzione di azioni e sincronizzare i processi.

Librerie esterne: Ora analizziamo brevemente le caratteristiche fonda-

mentali dei tool utilizzati per implementare il sistema.

• Boost: e un pacchetto di librerie C++ che supportano molteplici fun-

zionalita, in particolare e stato utilizzato il pacchetto Random per la

generazione di numeri casuali [Boo].

61


• Asio: e una libreria cross-platform C++ sviluppata per la rete e per

la programmazione dell’I/O a basso livello, usata per fornire agli svi-

luppatori un modello asincrono consistente e versatile. In particolare,

Asio e una libreria portabile, scalabile ed efficace [Asi].

• RL Toolbox: e una libreria C++ applicabile per problemi di reinfor-

cement learning. E stata progettata per essere estendibile a seconda

delle esigenze del programmatore, al fine di concentrarsi sul processo

di controllo che vuole risolvere piuttosto che sull’algoritmo. Il toolbox

contiene tutti i principali algoritmi dei reinforcement learning, come ad

esempio quelli che sono stati utilizzati (T (λ), Q(λ), ActorCritic(λ))

[Neu05].

62


3.2 Schema a blocchi

In questa sezione, presenteremo lo schema a blocchi del sistema, analizzando

nel dettaglio le varie parti che lo costituiscono.

Figura 3.1: Schema a blocchi del sistema

63


Gestore richieste: Il gestore delle richieste e il processo che si occupa

dell’invio delle richieste. E in grado di ricevere comandi dall’Agente. Le

richieste vengono inviate con il seguente criterio, ad ogni step di simulazione

il gestore decide dopo quanto tempo ci dovra essere l’invio della richiesta

successiva. Il processo e Server per l’Agente e Client per l’Ambiente.

Le classi principali di questo sottosistema sono le seguenti:

• CRequestManager: e la classe che incapsula i metodi di send e

receive, per astrarre i meccanismi di scambio dei messaggi.

• CTimedRequest: e la classe che contiente le strutture per memo-

rizzare dopo quanto tempo e stato effettuato l’invio della richiesta all’i-

stante di simulazione t e per memorizzare l’intervallo tra una richiesta

e un’altra all’istante di simulazione t+ 1.

La classe CTimedRequest, contiene istanze della classe CRequestManager, in

modo da poter inviare i messaggi in maniera trasparente ai livelli sottostanti

a tutti i sottosistemi.

I messaggi che vengono inviati dall’agente sono:

• reset: Messaggio usato per riportare le strutture ad uno stato prede-

finito. Questo messaggio blocca anche il timer responsabile dell’invio

del messaggio.

• restart: Messaggio usato per effettuare il restart del timer.

• time: messaggio per modificare il tempo d’invio del successivo mes-

saggio. Il messaggio e strutturato per contenere anche il valore che

rappresenta di quanto sara ritardato o anticipato il prossimo invio.

• kill: Messaggio che serve ad ”uccidere” il processo in cui risiede il

gestore. E usato per terminare un esperimento.

Sistema: Questo processo contiene degli oggetti per simulare reti di code.

Al momento abbiamo implementato la singola coda, e una coda multipla

che usa una disciplina di schedulazione di tipo round-robin, come e possible

osservare nella figura 3.2. Nell’implementazione attuale il tempo di servizio

64


di ogni coda e di tipo esponenziale, in cui si puo passare in ingresso il tasso

di servizio λ. Si puo modificare, in maniera semplice il codice di una coda

per usare altri tipi di distribuzioni. Le classi principali di questo sottosistema

sono le seguenti:

• CQueueManager: e la classe che implementa metodi per simulare

il comportamento di una coda.

• CMQueueManager: e la classe che implementa metodi per simulare

il comportamento di un parallelo di code, in cui all’atto dell’arrivo di

un messaggio il messaggio viene schedulato con una disciplina di tipo

round robin.

Figura 3.2: Modelli di code implementati nel sistema

I messaggi che il sistema di simulazione delle code invia al sottosistema Agente

e essenzialmente un messaggio d’informazioni riguardo lo stato delle code,

nella fattispecie e il numero di richieste pendenti ma possono essere aggiunti

anche scenari piu complessi.

Agente: Come abbiamo detto precedentemente, l’Agente controlla il si-

stema per il raggiungimento dello stato obiettivo.

Il sottosistema Agente e il responsabile:

65


• Dell’apprendimento di una o piu politiche da seguire per pilotare il

sistema1

• Del mantenimento di strutture date consistenti, che sono state protette

al fine di permettere un aggiornamento concorrente.

• Dell’interfacciamento con gli altri sottosistemi per effettuare un’azione,

la rappresentazione dell’azione e slegata dalla sua implementazione nel

sistema stesso.

• Della gestione delle richieste di aggiornamento di stato, l’Agente e in-

capsulato in un server che e il responsabile dei aggiornare le strutture

che contengono lo stato e di portare tutti sottosistemi ad uno stato

consistente per effettuare l’apprendimento.

Cervello (Brain): Il cervello costituisce il centro dell’apprendimento del

sistema. E implementato come un ”wrapper” , che e accoppiato in maniera

lasca con le classi:

• che gestiscono l’apprendimento.

• che implementano gli algoritmi.

• che gestiscono il mantenimento dello stato.

Le classi fondamentali di questo sottosistema sono le seguenti:

• CBrain: funge da ”collante” tra le classe, il Server s’interfaccia a

questa classe per compiere uno step di apprendimento.

• CBrainAgent: e la classe responsabile della gestione dell’apprendi-

mento, decide ad ogni step quale sara la prossima azione da compiere

e s’interfaccia al sottosistema System Facade, richiamando metodi di

tale classe per compiere azioni sul gestore delle richieste e il sistema.

1da notare che, in linea generale, l’apprendimento di una politica puo essere slegato

dalla politica che il sistema segue durante l’esperimento.

66


Figura 3.3: Il sottosistema Brain (Cervello)

67


Questa scelta, come si puo vedere nella figura 3.3 e motivata dal fatto che il

sistema non debba essere legato ad uno specifico toolbox o ad una specifica

interfaccia, ma possa essere facilmente modificato per essere ”trapiantato”

in scenari piu complessi.

System Info (Strutture di stato): Il sottosistema System Info gestisce

le strutture che memorizzano lo stato rilevato dall’agente, a seguito degli invii

di informazioni di stato, da parte del sistema sotto analisi.

In particolare:

• Sincronizza l’accesso alle strutture dati condivise dai i vari sottosistemi,

che rappresentano per l’appunto lo stato.

• A seguito di richieste di aggiornamento, vengono anche aggiornate

informazioni statistiche.

Le strutture di stato sono accedute in mutua esclusione per permettere il

mantenimento di uno stato consistente. Ogni aggiornamento di stato viene

fatto in maniera atomica.

System Facade: Il sottosistema System Facade si occupa di astrarre

le operazioni. In questo modo, l’Agente richiama metodi della classe che

rappresenta il sottosistema, per compiere operazioni sia verso il gestore delle

richieste, sia verso il sistema sotto analisi. Le operazioni sono realizzate

tramite messaggi che vengono invati ad entrambi i sottosistemi.

Queste funzionalita sono realizzate nella classe CSystemFacade. I principali

metodi che possono essere richiamati su questa classe sono:

• Metodo per la modifica del successivo istante d’invio del messaggio,

questo messaggio e diretto al gestore delle richieste.

• Metodo per aggiungere ritardi, verso i simulatori del tempo di servizio.

• Metodo per richiedere il reset delle strutture e i restart dei timer.

• Metodo per richiedere l’uccisione dei processi.

68


In questo modo, come gia abbiamo detto in precedenza si e riusciti a mante-

nere separati l’astrazione dell’azione, dalla sua implementazione2.

Update Manager (Gestore degli aggiornamenti) : Questo sottosiste-

ma si occupa ricevere le richieste e avviare il sistema di apprendimento, e

implementato come un Server dove ci possono essere piu sessioni che agi-

scono sullo stesso insieme di strutture dati. In primo luogo, dopo una fase

iniziale di sincronizzazione con gli altri processi, inizializza le strutture dati

sia l’apprendimento, per il mantenimento dello stato, le classi che rappresen-

tano le politiche, le azioni e gli algoritmi di reinforcement learning.

Ogni sessione puo essere utilizzata per mantenere lo stato di ogni sottosistema

che invia il proprio stato interno. Questo sottosistema si occupa di coordi-

nare tutte le attivita sia dal punto di vista dell’invio delle azioni agli altri

sottosistemi, sia dal punto di vista della ricezione dello stato dall’Ambiente.

3.3 Uno sguardo nel dettaglio

In questa sezione, analizzeremo il sistema da un punto di vista dinamico. Ab-

biamo visto, nel capitolo precedente, che i processi di apprendimento possono

essere sia episodici sia continui. Nella fase sperimentale abbiamo preferito

usare un approccio episodico, questo ci e servito a valutare i vari algoritmi

di cui abbiamo valutato l’ ”efficacia” al variare dei parametri in ingresso,

di questo discuteremo in maggiore dettaglio in seguito. Ora quello che ci

resta da fare e vedere come interagiscono tra di loro, i vari sottosistemi, allo

scorrere del tempo di simulazione. Come si puo evincere dalla figura 3.4, i

tre sottosistemi evolvono in parallelo, la simulazione avviene per quanti di

tempo, dove ogni quanto puo essere specificato nel sistema.

In particolare, come e possibile osservare dalla figura 3.4, in ogni episodio:

1. Dopo che i tre sottosistemi sono stati avviati c’e una fase di sincroniz-

zazione iniziale, in cui i tre sottosistemi si sincronizzano per iniziare

l’episodio.

2di fatto abbiamo fornito un’implementazione, ma tale implementazione si puo

estendere anche ad altri tipi di sistema.

69


Figura 3.4: Una vista dinamica del sistema sviluppato

70


2. Dopo la fase di sincronizzazione, il gestore delle richieste avvia la ge-

nerazione delle richieste e all’atto della ricezione delle richieste, che

avviene dopo un tempo aleatorio ε, l’Ambiente aggiorna il proprio stato.

3. Dopo un certo numero di step (precedentemente impostato), l’Ambien-

te invia informazioni inerenti il proprio stato all’agente.

4. Dopo un certo tempo di trasmissione aleatorio η, l’agente aggiorna le

strutture che rappresentano lo stato dell’ambiente e calcola iterativa-

mente una media su finestra mobile che e impostata al valore del nu-

mero di passi tra un passo di apprendimento ed un altro, inoltre viene

calcolata anche la varianza e vengono aggiornate anche le informazio-

ni riguardo i ritardi che sono stati immessi nell’Ambiente, per fare in

modo da non superare una certa soglia massima.

5. Dopo un certo multiplo del numero di invii dell’Ambiente (che di de-

fault e stato impostato a 3 pero puo essere opportunamente cambiato),

l’Agente invoca i metodi del sottosistema Cervello per effettuare uno

step nell’apprendimento.

6. Dopo lo step di apprendimento vengono memorizzate informazioni sot-

toforma di tuple, che cambiano a seconda dell’algoritmo scelto (Q(λ),

SARSA(λ), ActorCritic(λ)) e l’Agente decide che azioni compiere dal

suo set di azioni.

7. Una volta scelta l’azione l’Agente richiede al System Facade di compiere

un’operazione di aggiornamento dei nel sottosistema di Gestione delle

richieste e nel sottosistema Ambiente.

8. All’atto della ricezione, da parte di entrambi i sottosistemi, ogni sotto-

sistema aggiorna le proprie strutture interne.

Il tempo δ e l’intervallo di tempo dalla ricezione del messaggio, all’invio delle

azioni da compiere ad entrambi i sottosistemi. Dalla trattazione che abbiamo

fatto, possiamo notare che il numero di step dopo cui viene inviato lo stato,

e diverso dal numero di step in cui viene fatto apprendimento.

71


3.4 Struttura di un esperimento

Nella precedente sezione abbiamo detto che seguiamo un approccio di ap-

prendimento di tipo episodico, anche se e possibile trattare in una seconda

fase, dopo una fase di apprendimento iniziale, il problema con un approccio

di tipo continuo. In questa sezione analizziamo nel dettaglio un esperimento.

Un esperimento e costituito da un numero di episodi, che a sua volta e co-

stituito da un numero di step. La cosa importante da sottolineare, in questa

prima analisi, e che ogni episodio ha un numero massimo di step, che posso-

no anche non essere raggiunti perche l’Agente ha appreso prima del numero

massimo di passi che gli sono stati concessi.

Una parte fondamentale di tutto il sistema e quella del logging. Il sistema

utilizza delle strutture di logging fornite da RL Toolbox, e altre inserite ad

hoc:

• CAgentLogger: che memorizza le informazioni di logging dell’a-

gente in forma human-readble, cioe in un formato che e comprensibile

all’utente.

• CEpisodeMatlabOutput: che memorizza le strutture in un formato

che e facilmente importabile in Matlab.

• CExperimentInfo: contiene tutte le informazioni inerenti l’esperi-

mento, che vengono inizializzate all’atto di ogni inizio esperimento.

I test sono stati automatizzati tramite gli script launch.sh e launch test.sh:

il primo script permette di lanciare l’esperimento, il secondo si occupa di

avviare i tre sottosistemi e di mettersi in attesa fino alla fine dell’esecuzione

dei processi,come possiamo osservare dalla figura 3.5.

72


Figura 3.5: La struttura di un esperimento

73


3.5 Conclusioni

In questo capitolo abbiamo descritto il sistema proposto per il test. Abbiamo

osservato che e suddiviso in tre parti: (i) Agente, (ii) Generatore di Richie-

ste, (iii) Ambiente. Abbiamo evidenziato che l’Agente segue uno schema di

apprendimento episodico, che puo essere facilmente esteso per includere an-

che il caso continuo. L’Agente riceve periodicamente lo stato dall’Ambiente,

aggiorna le proprie strutture interne per tener traccia dell’evoluzione del si-

stema e effettua passi di apprendimento per imparare una politica seguendo

un certo algoritmo che viene fornito in input. Abbiamo dato sia una vi-

sta statica del sistema, sia una vista dinamica, descrivendo passo per passo

evolve l’intero sistema. Nell’ultimo paragrafo abbiamo descritto in breve la

struttura di un esperimento, questo ci servira per descrivere come e stata

fatta la campagna sperimentale.

74

CAPITOLO 4

Risultati sperimentali

La verita e una cosa troppo complicata perche permetta qual-

cosa di differente dalle approssimazioni. (J. Von Neumann)

In questo capitolo, verra illustrata un’analisi esplorativa dell’approccio. Gli

obiettivi di quest’analisi si possono schematizzare nei due punti seguenti:

1. Valutare come si comportano gli algoritmi al variare dei parametri della

traccia di eleggibilita e del learning rate,

2. Valutare la bonta dell’approccio in casi di studio che sono significativi,

in vista di una integrazione su un sistema reale.

Una cosa da evidenziare e che il nostro studio e basato su simulazioni del

reale comportamento di un sistema di code. Non ci sono studi a nostra co-

noscenza riguardo l’applicazione di metodi basati su reinforcement learning,

questo motiva l’analisi esplorativa. Il modello d’interazione Agente-Ambiente

prevede che i due sottosistemi che interagiscono tra di loro siano separati. A

differenza dell’approccio di RL Toolbox, il nostro approccio mira a separare

nettamente i due sottosistemi. Una seconda cosa da evidenziare e il problema

del tempo, la nostra variabile tempo e in realta un tempo simulato. Quindi, i

75

4. Risultati sperimentali

Parametro Numero passi

Slice d’apprendimento 3

Slice d’aggiornamento strutture 1

Tabella 4.1: Numero di passi dei parametri principali riguardo il tempo.

risultati di convergenza, devono essere pensati nell’ordine dei passi, piuttosto

che nell’ordine di una misura di tempo. I parametri principali riguardanti il

tempo sono descritti nella tabella 4.1. Infine, l’ultima considerazione da fare

e sullo stato obiettivo. In questa campagna sperimentale ci siamo preoccu-

pati di considerare l’impatto degli algoritmi al variare dei parametri per un

prefissato stato obiettivo.

4.1 Definizione degli esperimenti

In questo paragrafo descriveremo gli esperimenti che sono stati effettuati sul

sistema dai noi proposto.

4.1.1 Singola Coda

Overview - In questo esperimento abbiamo analizzato la capacita dell’A-

gente di controllare lo stato di una singola coda. Questo esperimento rappre-

senta il caso piu semplice che possiamo immaginare. Il valore del tempo di

servizio in questo caso e stato posto pari a 1.5 req/step. Il caso analizzato e

mostrato nella figura 4.1. La configurazione delle azioni sono mostrate nella

tabella 4.2.

Reward - La funzione di reward R che abbiamo usato in questo caso

assume la seguente forma generale:

R(k, w1, w2, w3, ε1, ε2, ε3) =

(w1

ε1 + (S∗ − Sk)2+

w2

ε2 + σ+

w3

ε3 + η

)Il valore σ e la deviazione standard calcolata iterativamente su una fine-

stra temporale di dimensione prefissata (nel nostro caso e il numero di step

76


Figura 4.1: Struttura dell’esperimento con coda singola

d’apprendimento). Il valore η rappresenta il tempo di sleep accumulato fino

a quel momento. La funzione di reward e stata pensata in questo modo al

fine di raggiungere l’obiettivo per il quale quanto piu e alto il valore di sleep

tanto piu ”puniamo” l’Agente. I valori degli altri parametri sono brevemente

riassunti nella tabella 4.3.

4.1.2 Coda Multipla

Overview - In questo caso analizziamo come l’Agente riesce a controllare

la convergenza allo stato obiettivo di un parallelo di code, in cui le richieste

sono schedulate con una politica round robin.

Il caso specifico che abbiamo analizzato e quello composto da un numero di

code N = 3. Le code sono simmetriche, cioe i tempi di servizio di tutte e

tre le code sono uguali tra di loro. I parametri di questo esperimento sono

mostrati nella tabella 4.4, lo schema del caso analizzato e mostrato nella

figura 4.2. Le impostastioni delle azioni sono mostrate nella tabella 4.5.

Reward - La funzione di reward R che abbiamo usato in questo caso

assume la seguente forma generale:

R(k, w1, w2, w3, ε1, ε2, ε3) =N∑m=1

(w1

ε1 + (S∗m − Sk,m)2+

w2

ε2 + σm+

w3

ε3 + ηm

)

77


Figura 4.2: Struttura dell’esperimento con coda multipla

Il vettore σ e il vettore delle deviazioni standard calcolate iterativamente su

una finestra temporale di dimensione prefissata (nel nostro caso e il numero

di step d’apprendimento). Il vettore η rappresenta il vettore dei tempi dei

ritardi accumulati fino a quel momento. Analogamente a quello che abbiamo

visto nel caso precendente, quanto piu e basso il valore di questo contributo

( all’aumentare del tempo di ritardo accumulato) tanto piu ”puniamo” il

nostro Agente. I valori degli altri parametri sono brevemente riassunti nella

tabella 4.3.

4.2 Risultati

In questa sezione riportiamo i risultati che abbiamo ottenuto al variare del

learning rate e del valore della traccia di eleggibilita λ. Ora daremo dei risul-

tati sintetici per ogni esperimento, nei successivi paragrafi analizzeremo piu

in dettaglio i risultati ottenuti per ogni singola metrica al variare del learning

rate e del parametro λ. Nel caso dell’esperimento su coda singola, e possibile

osservare dalla tabella 4.6 che l’algoritmo che in media riesce a convergere

nel minor numero di passi al primo episodio e l’algoritmo SARSA(λ), Q(λ)

e quello che presenta una variabilita minore. Tali differenze sono comunque

78


minime e non abbastanza significative da dire che la scelta dell’algoritmo in-

fluisce molto sulle prestazioni. Vogliamo fare ulteriori osservazioni riguardo

le misure ottenute rispetto alla terza metrica. Infatti, come si puo osser-

vare σ > µ. Una spiegazione ragionevole a questo fenomeno e nella scelta

delle azioni che potrebbe portare gli algoritmi ad assumere valori di reward

oscillanti, essendo tutti gli elementi della tabella maggiori di 0.

Nel caso dell’esperimento su coda multipla, e possibile osservare dalla

tabella 4.7 che, analogamente a quello che accadeva nel caso precedente l’al-

goritmo che in media riesce a convergere nel minor numero di passi al primo

episodio e l’algoritmo SARSA(λ), in questo caso presenta anche i migliori

risultati in termini di variabilita. L’analisi rispetto alla seconda metrica, e

praticamente analoga alla precedente. Per quello che riguarda la terza metri-

ca, AC(λ) ha le prestazioni migliori in termini di media, quindi ha il ”guada-

gno” piu alto di tutti, mentre Q(λ) ha le prestazioni peggiori sia in termini di

variabilita che in termini di media. SARSA(λ) ha le migliori prestazioni in

termini di variabilita. Come nel primo esperimento, la variabilita piu bassa

la presenta l’algoritmo AC(λ). In questo paragrafo, vogliamo concentrarci

sull’analisi di tre punti, usando un approccio di tipo comparativo:

• sensibilta degli algoritmi nei vari casi.

• prestazioni dei vari algoritmi al variare delle metriche

• eventuali casi di non convergenza per alcuni valori.

4.2.1 Velocita di convergenza

In questa sezione, ci soffermeremo nell’analisi delle prime due metriche che

abbiamo visto nel paragrafo precendente cioe (i) ”Numero di passi al primo

episodio”, (ii) ”Numero di passi all’ultimo episodio”, che analizzeremo nei

due esperimenti oggetto della nostra discussione.

Esperimento 1- Seguendo le linee guida dell’introduzione a questo para-

grafo possiamo dividere l’analisi in:

79


• sensibilita: Nella figura 4.3 possiamo osservare che nel caso della pri-

ma metrica, al variare del learning rate, tutti e tre gli algoritmi presen-

tano una simile sensibilita. Questo non accade nel secondo caso, come

si puo osservare nella figura 4.4. Infatti, in questo caso a presentare la

sensibilita minore rispetto a λ e l’algoritmo SARSA(λ), mentre l’algo-

ritmo che risente di piu dell’effetto di λ e AC(λ). Nel caso della seconda

metrica, possiamo osservare dalla figura 4.5 che l’algoritmo che presen-

ta maggiore sensibilita rispetto al parametro learning rate e AC(λ),

mentre i restanti presentano caratteristiche di sensibilita simili. Invece

nel caso di figura 4.6 e l’algoritmo SARSA(λ) a presentare una sensi-

bilita maggiore rispetto a λ, mentre gli altri algoritmi si comportano

in maniera simile.

• prestazioni: Sebbene ci siano differenze tra le prestazioni dei vari

algoritmi, la scelta di un algoritmo piuttosto che un altro non impatta

in maniera significativa sulle prestazioni.

• problemi di convergenza: Dalle figure 4.3 e 4.5 si evincono problemi

di convergenza per valori del learning rate pari ad 1.0 in cui la Q-

function tende a non convergere.

.

80


Figura 4.3: Numero dei passi impiegati al primo episodio, nel caso di coda singola

al variare del learning rate.

Figura 4.4: Numero dei passi impiegati al primo episodio, nel caso di coda singola

al variare di λ.

81


Alg

orit

mo

Val

ore

rita

rdo(

step

)

Ser

ver

1R

ichie

sta

pro

ssim

a

Q(λ

),SARSA

(λ)

0,1

0,1

0,05

0,05

00

−0,

05−

0,05

−0,

1−

0,1

AC

(λ)

−0,

05−

0,05

0,05

0,05

Tabe

lla

4.2:

Tabe

lla

che

con

tien

ei

valo

ridel

leazi

on

in

ell’

espe

rim

ento

coda

sin

gola

.

82


Parametro Significato Valore impostato

w1 Peso del primo contributo 10

w2 Peso del secondo contributo 1

w3 Peso del terzo contributo 1

ε1 Fattore numerico del primo contributo 1

ε2 Fattore numerico del secondo contributo 1

ε3 Fattore numerico del terzo contributo 1

Tabella 4.3: Parametri della funzione di reward.

Tempo medio di servizio Distribuzione

(req/step)

Coda 1 2.0 Exp

Coda 2 2.0 Exp

Coda 3 2.0 Exp

Tabella 4.4: Parametri dell’esperimento tre code in parallelo con disciplina di

schedulazione round robin.

83


Alg

orit

mo

Val

ore

rita

rdo(

step

)

Ser

ver

1Ser

ver2

Ser

ver

3R

ichie

sta

pro

ssim

a

Q(λ

),SARSA

(λ)

−0,

5−

0,5

−0,

5−

0,5

00

0−

0,5

0,5

0,5

0,5

−0,

5

−0,

5−

0,5

−0,

50

00

00

0,5

0,5

0,5

0

−0,

5−

0,5

−0,

50,

5

00

00,

5

0,5

0,5

0,5

0,5

AC

(λ)

−0,

5−

0,5

−0,

5−

0,5

0,5

0,5

0,5

0,5

Tabe

lla

4.5:

Tabe

lla

che

con

tien

ei

valo

ridel

leazi

on

in

ell’

espe

rim

ento

coda

mu

ltip

la.

84


Met

rica

Alg

orit

mo

(µ∓σ

)

Q(λ

)SARSA

(λ)

AC

(λ)

Num

ero

di

pas

si46,5

0∓

3,07

45,8

5∓

3,16

48,4

4∓

3,73

impie

gati

alpri

mo

epis

odio

Num

ero

di

pas

si27,1

8∓

0,81

28,1

9∓

1,08

29,4

3∓

0,81

impie

gati

all’ult

imo

epis

odio

Rew

ard

accu

mula

taal

la3,

70∓

5,17

4,04∓

5,30

3,98∓

5,27

fine

del

pri

mo

epis

odio

Tabe

lla

4.6:

Ris

ult

ati

sin

teti

cidel

laca

mpa

gna

sper

imen

tale

rigu

ard

on

elca

soco

da

sin

gola

.

85


Met

rica

Alg

orit

mo

(µ∓σ

)

Q(λ

)SARSA

(λ)

AC

(λ)

Num

ero

di

pas

si22

7,97∓

91,8

619

4,69∓

53,5

730

4,18∓

109,

08

impie

gati

alpri

mo

epis

odio

Num

ero

di

pas

si78,1

2∓

22,7

978,0

6∓

23,6

676,2

6∓

20,3

0

impie

gati

all’ult

imo

epis

odio

Rew

ard

accu

mula

taal

lafine

31,7

2∓

4,08

32,1

1∓

2,83

33,0

5∓

3,81

del

pri

mo

epis

odio

Tabe

lla

4.7:

Ris

ult

ati

sin

teti

cidel

laca

mpa

gna

sper

imen

tale

rigu

ard

on

elca

soco

da

mu

ltip

la.

86


Figura 4.5: Numero dei passi impiegati all’ultimo episodio, nel caso di coda

singola al variare del learning rate.


singola al variare di λ.

87


Esperimento 2 - In questo paragrafo facciamo un’analisi sintetica del

secondo esperimento:

• sensibilita: Nella figura 4.7 possiamo osservare che nel caso della

prima metrica, al variare del learning rate, l’algoritmo che presenta

una maggiore sensibilita e Q(λ) . Nel caso in figura 4.8, l’algoritmo

SARSA(λ) presenta la sensibilita minore al variare di λ, mentre i re-

stanti presentano una sensibilita simile rispetto a λ. Nel caso della

seconda metrica, possiamo osservare che dalla figura 4.9, tutti e tre

gli algoritmi presentano caratteristiche di grossa sensibilita. Invece nel

caso di figura 4.6 possiamo osservare che anche rispetto a λ accade

questo fenomeno in cui c’e un’apprezzabile sensibilita per tutti e tre gli

algoritmi.

• prestazioni: Per quello che riguarda il numero di passi al primo epi-

sodio, come si evince dalle figure 4.7 e 4.8, possiamo constatare che

l’algoritmo SARSA(λ) presenta prestazioni migliori degli altri due al-

goritmi nella maggior parte dei punti dell’asse del learning rate e di

λ. Per quello che riguarda il numero di passi all’ultimo episodio, dalla

figura 4.9 si evince che rispetto al learning rate non c’e un algoritmo

migliore degli altri. Invece, come mostrato in figura 4.10, rispetto a λ

continua a comportarsi meglio SARSA(λ) rispetto a tutti gli altri.

• problemi di convergenza: Analogamente a prima si presentano pro-

blemi di convergenza al variare del learning rate per un learning rate

pari ad 1.0, la funzione Q tende a non convergere.

4.2.2 Reward accumulata

In questa sezione, ci soffermeremo nell’analisi della reward accumulata dal-

l’Agente al variare degli algoritmi alla fine del primo episodio.

Esperimento 1 - Di seguito riportiamo brevi considerazioni riguardo

il primo esprimento rispetto alla metrica ”Reward accumulata alla fine del

primo episodio”.

88


Figura 4.7: Numero dei passi impiegati al primo episodio, nel caso di coda

multipla al variare del learning rate.

• sensibilita: Rispetto a questa metrica, come si puo osservare dalla

figura 4.11, tutti gli algoritmi che abbiamo preso come riferimento ma-

nifestano una apprezzabile sensibilita rispetto al parametro di learning

rate. Da questo punto di vista, gli algoritmi si comportano in maniera

simile.

• prestazioni: Gli algoritmi presentano prestazioni simili al variare

di entrambi i parametri, non c’e un significativo miglioramento nel

utilizzare un algoritmo piuttosto che un altro.

• problemi di convergenza: Dalle figure 4.11 si evincono problemi di

convergenza per valori del learning rate pari ad 1.0 in cui la Q-function

tende a non convergere.

89


Figura 4.8: Numero dei passi impiegati al primo episodio, nel caso di coda

multipla al variare di λ.

Esperimento 2 - Di seguito riportiamo brevi considerazioni riguardo il

secondo esperimento rispetto alla metrica ”Reward accumulata alla fine del

primo episodio”.

• sensibilita: Rispetto a questa metrica, come si puo osservare dalle

figure 4.13 e 4.14, si puo osservare che l’algoritmo che manifesta la

sensibilita piu bassa e AC(λ).

• prestazioni: Dalle figure 4.13 e 4.14 si evince che l’algoritmo AC(λ)

manifesta il comportamento migliore, in termini di reward accumulata.

• problemi di convergenza: Dalla figura 4.11 si evincono un problemi

di convergenza per valori del learning rate pari a 0.9 e 1.0 in cui la

Q-function tende a non convergere.

90



multipla al variare del learning rate.

4.3 Conclusioni

In questo capitolo, abbiamo analizzato i risultati sperimentali ottenuti da

una analisi sperimentale esplorativa. Abbiamo evidenziato la necessita di

un’analisi esplorativa al fine di valutare la fattibilita dell’approccio, e ricava-

re dei primi risultati per valutare l’applicabilita dell’approccio in domini di

complessita maggiore. In particolare abbiamo descritto sia la struttura degli

esperimenti, sia la funzione di reward scelta a seconda dei casi. Il primo

esperimento aveva l’obiettivo di valutare l’approccio nel controllo dello stato

di una singola coda con un tempo di servizio esponenziale. Il secondo espe-

rimento aveva, invece, l’obiettivo di valutare l’approccio nel controllo dello

stato di un parallelo di code, in cui i server sono simmetrici, e i tempi di servi-

zio sono esponenziali(le richieste in tale scenario venivano schedulate secondo

una politica round robin). Per l’analisi dei risultati abbiamo definito due ti-

pologie di metriche: (i) velocita di convergenza, (ii) reward accumulata. Per

entrambe le tipologie di metriche (velocita di convergenza e reward accumu-

lata), nell’esperimento con singola coda gli algoritmi presentano prestazioni e

91


Figura 4.10: Numero dei passi all’ultimo episodio, nel caso di coda multipla al

variare di λ.

sensibilita simile. Le misure hanno mostrato che, per questo particolare caso,

scegliere un algoritmo piuttosto che un altro non impatta significativamente

sulle prestazioni. Nel secondo esperimento, invece, le misure hanno mostrato

che dal punto di vista della velocita di convergenza l’algoritmo SARSA(λ) si

e mostrato il migliore, sia in termini di sensibilita che di prestazioni. Invece,

dal punto di vista della reward accumulata l’algoritmo AC(λ) ha mostrato il

comportamento migliore sia dal punto di vista della sensibilita, sia dal punto

di vista delle prestazioni.

92


Figura 4.11: Reward accumulata alla fine del primo episodio al variare di

learning rate, nel caso dell’esperimento con coda singola.

Figura 4.12: Reward accumulata alla fine del primo episodio al variare di λ, nel

caso dell’esperimento con coda singola.

93


Figura 4.13: Reward accumulata alla fine del primo episodio al variare di

learning rate, nel caso dell’esperimento con coda multipla.

Figura 4.14: Reward accumulata alla fine del primo episodio, al variare di λ,

nel caso dell’esperimento con coda mutlipla.

94

Conclusioni e sviluppi futuri

In questo lavoro di tesi e stato proposto un approccio basato su Reinfor-

cement Learning, per l’iniezione dei guasti in sistemi software complessi.

In particolare, abbiamo focalizzato la nostra attenzione sul problema della

raggiungibilita e del mantenimento di uno stato di un sistema software com-

plesso. Per valutare l’applicabilita di tale di approccio sono stati utilizzati

algoritmi di reinforcement learning su un sistema sviluppato per la sperimen-

tazione, che costituira la base di partenza per gli sviluppi futuri.

L’analisi sperimentale fatta ha mostrato che:

• L’approccio proposto permette di controllare, in maniera automatizza-

ta, un sistema software complesso in modo che possa raggiungere uno

stato desiderato.

• L’analisi sperimentale ha evidenziato che gli algoritmi basati su Reinfor-

cement Learning che sono stati considerati sono in grado di raggiungere

l’obiettivo, e che in sistemi piu complessi la scelta dell’algoritmo puo

influire sulle prestazioni, in particolare sulla velocita di convergenza.

Per quello che riguarda gli sviluppi futuri i nostri obiettivi saranno:

• Integrazione dell’approccio in un sistema reale,

• utilizzo di un approccio Bayesiano per stimare probabilisticamente lo

stato corrente nel caso d’incertezza nelle osservazioni.

95

APPENDICE A

Tabelle

96

A. Tabelle

A.1 Esperimento 1

Learning RateAlgoritmo (µ∓ σ)

Q(λ) SARSA(λ) AC(λ)

0.0 46.73∓ 4.03 45.70∓ 3.40 48.27∓ 4.03

0.1 46.45∓ 3.11 44.40∓ 4.03 48.00∓ 2.72

0.2 47.36∓ 2.20 45.90∓ 3.21 49.00∓ 3.35

0.3 47.00∓ 4.15 45.50∓ 3.75 49.91∓ 3.21

0.4 46.00∓ 1.61 46.20∓ 2.86 48.18∓ 3.79

0.5 46.45∓ 3.33 44.70∓ 2.36 46.18∓ 2.99

0.6 46.36∓ 2.46 46.60∓ 3.66 49.18∓ 2.44

0.7 47.55∓ 2.70 45.90∓ 3.67 48.09∓ 4.11

0.8 46.64∓ 2.66 46.67∓ 3.32 48.64∓ 3.64

0.9 44.18∓ 3.71 46.56∓ 2.35 50.27∓ 4.50

1.0 46.82∓ 2.93 46.44∓ 2.19 47.18∓ 5.19

Tabella A.1: Metrica: numero passi per convergere al primo episodio. Media e

deviazione standard di ogni esecuzione dell’esperimento per λ variabile al variare

del learning rate, espressa per ogni algoritmo.

97

A. Tabelle

λAlgoritmo (µ∓ σ)


0.0 47.36∓ 2.16 46.36∓ 2.42 48.09∓ 3.96

0.1 46.45∓ 3.72 45.00∓ 2.86 48.27∓ 3.85

0.2 45.09∓ 2.34 46.09∓ 3.73 50.09∓ 3.45

0.3 46.55∓ 2.46 44.27∓ 2.80 46.45∓ 3.50

0.4 47.09∓ 3.51 47.18∓ 3.19 49.27∓ 3.85

0.5 45.91∓ 3.18 47.55∓ 2.88 47.45∓ 4.34

0.6 47.64∓ 3.44 46.27∓ 3.26 48.09∓ 2.77

0.7 47.18∓ 2.27 45.00∓ 3.44 48.55∓ 3.98

0.8 46.82∓ 1.83 44.45∓ 2.91 48.27∓ 3.61

0.9 44.73∓ 4.52 46.50∓ 3.51 49.45∓ 4.30

1.0 46.73∓ 3.23 −− 48.91∓ 3.51


deviazione standard di ogni esecuzione dell’esperimento per learning rate, al variare

di λ, espressa per ogni algoritmo.

98

A. Tabelle



0.0 26.82∓ 0.60 28.40∓ 0.84 29.09∓ 0.70

0.1 27.09∓ 0.83 27.40∓ 0.97 28.91∓ 0.83

0.2 27.45∓ 0.93 28.10∓ 1.37 29.55∓ 1.13

0.3 27.00∓ 0.89 27.70∓ 1.25 29.45∓ 0.69

0.4 27.09∓ 0.70 28.10∓ 1.10 29.27∓ 0.90

0.5 27.27∓ 0.47 28.30∓ 1.06 29.45∓ 0.93

0.6 27.55∓ 0.93 28.70∓ 1.06 29.55∓ 0.69

0.7 27.27∓ 0.79 28.50∓ 0.97 29.55∓ 0.82

0.8 27.36∓ 0.92 28.78∓ 0.97 29.73∓ 0.65

0.9 27.09∓ 0.94 28.22∓ 0.83 29.64∓ 0.50

1.0 27.00∓ 0.77 27.88∓ 0.99 29.55∓ 0.93

Tabella A.3: Metrica: numero passi per convergere all’ultimo episodio. Media e



99

A. Tabelle



0.0 27.45∓ 0.69 28.27∓ 1.35 29.45∓ 0.82

0.1 27.27∓ 0.90 28.09∓ 1.04 29.55∓ 0.82

0.2 27.27∓ 1.01 28.27∓ 1.01 29.45∓ 0.82

0.3 27.18∓ 0.87 28.18∓ 0.87 29.73∓ 0.47

0.4 27.18∓ 0.75 28.27∓ 1.27 29.55∓ 0.82

0.5 27.09∓ 0.70 28.09∓ 1.38 29.18∓ 0.75

0.6 27.18∓ 0.87 28.18∓ 1.33 29.64∓ 0.81

0.7 27.00∓ 0.77 28.09∓ 1.04 29.27∓ 0.79

0.8 27.18∓ 0.75 28.20∓ 1.03 28.73∓ 0.90

0.9 27.00∓ 0.89 28.25∓ 0.46 29.36∓ 0.92

1.0 27.18∓ 0.87 −− 29.82∓ 0.75




100

A. Tabelle



0.0 3.34∓ 5.22 1.41∓ 3.54 6.37∓ 5.83

0.1 3.34∓ 5.24 3.63∓ 5.38 2.32∓ 4.52

0.2 5.36∓ 5.83 3.63∓ 5.38 4.34∓ 5.63

0.3 3.33∓ 5.21 4.76∓ 5.77 3.33∓ 5.22

0.4 4.35∓ 5.64 4.75∓ 5.76 2.32∓ 4.52

0.5 5.37∓ 5.84 2.51∓ 4.69 3.33∓ 5.21

0.6 3.33∓ 5.21 4.75∓ 5.76 3.33∓ 5.21

0.7 3.33∓ 5.22 5.86∓ 5.88 5.36∓ 5.83

0.8 1.30∓ 3.35 7.74∓ 5.59 4.35∓ 5.63

0.9 2.32∓ 4.53 2.77∓ 4.93 5.36∓ 5.82

1.0 5.37∓ 5.84 2.77∓ 4.93 3.33∓ 5.21

Tabella A.5: Metrica: reward accumulata alla fine del primo episodio. Media e



101

A. Tabelle



0.0 2.32∓ 4.52 2.32∓ 4.53 2.31∓ 4.51

0.1 3.33∓ 5.22 2.32∓ 4.53 4.34∓ 5.63

0.2 4.35∓ 5.64 5.35∓ 5.82 1.30∓ 3.36

0.3 2.32∓ 4.52 4.33∓ 5.62 4.35∓ 5.63

0.4 4.35∓ 5.64 3.33∓ 5.21 6.37∓ 5.83

0.5 5.35∓ 5.82 5.36∓ 5.83 4.35∓ 5.63

0.6 3.33∓ 5.22 5.36∓ 5.83 2.32∓ 4.52

0.7 4.35∓ 5.64 6.37∓ 5.82 3.33∓ 5.22

0.8 5.37∓ 5.84 3.34∓ 5.23 4.34∓ 5.63

0.9 2.32∓ 4.53 1.68∓ 3.95 4.34∓ 5.63

1.0 3.34∓ 5.24 −− 6.37∓ 5.83




102

A. Tabelle

A.2 Esperimento 2



0.0 179.00∓ 64.05 238.11∓ 65.14 374.45∓ 43.33

0.1 279.36∓ 85.61 183.44∓ 29.54 324.55∓ 68.96

0.2 211.82∓ 69.08 188.89∓ 43.88 271.36∓ 107.82

0.3 236.64∓ 80.95 231.00∓ 102.34 306.00∓ 197.24

0.4 271.00∓ 116.92 212.22∓ 68.33 286.91∓ 106.06

0.5 191.45∓ 64.23 195.33∓ 38.07 277.91∓ 92.23

0.6 212.73∓ 93.58 177.67∓ 11.78 270.36∓ 108.27

0.7 185.45∓ 84.39 170.44∓ 12.46 329.82∓ 103.27

0.8 250.64∓ 95.87 192.44∓ 41.82 303.00∓ 100.40

0.9 226.82∓ 101.48 179.33∓ 55.39 343.55∓ 92.61

1.0 262.73∓ 108.50 170.00∓ 7.78 258.09∓ 103.22




103

A. Tabelle



0.0 205.55∓ 64.43 203.00∓ 48.57 308.18∓ 109.73

0.1 200.82∓ 69.71 184.64∓ 29.68 314.09∓ 92.61

0.2 302.09∓ 96.98 195.00∓ 74.20 323.64∓ 118.19

0.3 283.18∓ 120.97 210.55∓ 85.15 276.91∓ 91.72

0.4 218.73∓ 82.72 202.73∓ 63.96 352.45∓ 181.50

0.5 204.64∓ 61.38 210.18∓ 60.04 277.55∓ 89.84

0.6 231.09∓ 90.70 180.18∓ 28.23 302.55∓ 99.40

0.7 220.00∓ 93.52 182.36∓ 29.29 328.09∓ 103.05

0.8 194.00∓ 78.76 182.50∓ 35.65 297.91∓ 117.25

0.9 225.82∓ 96.95 −− 292.73∓ 101.07

1.0 221.73∓ 110.28 −− 271.91∓ 87.52




104

A. Tabelle



0.0 60.18∓ 23.53 87.89∓ 17.65 87.73∓ 19.28

0.1 79.91∓ 18.71 62.11∓ 19.28 74.00∓ 22.91

0.2 77.82∓ 23.27 73.89∓ 22.82 85.00∓ 14.57

0.3 84.45∓ 20.13 69.78∓ 24.22 71.00∓ 21.17

0.4 80.64∓ 25.58 78.11∓ 23.35 71.36∓ 21.78

0.5 77.91∓ 16.18 80.11∓ 21.32 77.09∓ 23.53

0.6 80.73∓ 23.62 67.33∓ 23.59 73.82∓ 20.02

0.7 78.45∓ 24.57 94.56∓ 9.37 75.64∓ 22.62

0.8 73.55∓ 30.05 94.44∓ 10.90 73.18∓ 19.01

0.9 81.55∓ 24.58 69.89∓ 38.05 72.82∓ 20.31

1.0 84.18∓ 17.49 80.88∓ 23.12 77.27∓ 18.79




105

A. Tabelle



0.0 69.09∓ 24.46 74.91∓ 24.58 85.00∓ 18.71

0.1 86.36∓ 21.33 86.82∓ 18.86 70.27∓ 22.03

0.2 64.64∓ 23.62 74.82∓ 25.35 72.09∓ 15.98

0.3 83.55∓ 25.28 75.36∓ 23.93 72.73∓ 22.79

0.4 80.36∓ 22.54 87.36∓ 17.56 77.00∓ 23.90

0.5 86.00∓ 21.72 85.91∓ 21.86 73.91∓ 20.86

0.6 83.36∓ 24.06 73.73∓ 25.11 73.18∓ 17.47

0.7 79.45∓ 20.71 75.36∓ 22.93 68.18∓ 23.22

0.8 85.27∓ 18.91 67.30∓ 31.43 89.55∓ 16.06

0.9 60.45∓ 17.53 −− 76.00∓ 18.57

1.0 80.82∓ 20.51 −− 81.00∓ 20.47




106

A. Tabelle



0.0 32.57∓ 2.44 32.06∓ 3.03 32.75∓ 2.99

0.1 31.18∓ 4.44 32.27∓ 2.41 31.39∓ 4.31

0.2 32.99∓ 2.50 33.16∓ 3.10 34.79∓ 4.14

0.3 31.73∓ 2.26 31.32∓ 4.20 33.47∓ 3.29

0.4 33.89∓ 2.70 30.97∓ 1.97 32.01∓ 3.20

0.5 33.75∓ 5.33 31.94∓ 2.43 34.58∓ 3.70

0.6 32.02∓ 3.06 33.43∓ 2.85 34.82∓ 2.97

0.7 30.15∓ 4.23 33.03∓ 2.52 31.60∓ 4.40

0.8 28.92∓ 5.97 31.76∓ 2.79 31.11∓ 3.57

0.9 31.13∓ 4.63 31.87∓ 3.48 33.17∓ 4.74

1.0 30.64∓ 4.06 31.33∓ 1.90 33.83∓ 3.20




107

A. Tabelle



0.0 31.13∓ 5.25 32.16∓ 2.68 33.68∓ 3.40

0.1 32.34∓ 3.77 31.29∓ 1.86 31.90∓ 4.15

0.2 30.33∓ 4.18 31.82∓ 2.11 33.62∓ 4.00

0.3 32.51∓ 5.42 31.26∓ 2.99 34.30∓ 4.04

0.4 31.60∓ 3.78 32.13∓ 3.88 35.16∓ 3.30

0.5 30.41∓ 4.52 33.40∓ 2.98 32.88∓ 3.06

0.6 32.01∓ 4.07 31.90∓ 3.06 32.29∓ 3.74

0.7 32.79∓ 2.51 33.17∓ 3.25 32.77∓ 4.05

0.8 31.86∓ 3.09 31.86∓ 2.30 32.77∓ 3.79

0.9 32.73∓ 3.81 −− 31.63∓ 4.25

1.0 31.26∓ 4.57 −− 32.52∓ 4.21




108

Bibliografia

[AM96] Leslie Pack Kaelbling e Michael Littman e Andrew Moore.

“Reinforcement Learning: A Survey”. In: Journal of Artificial

Intelligence Research 4 (1996), pp. 237–285.

[Asi] Asio. url: http://think-async.com.

[Bon+04] A. Bondavalli et al. “Effective Fault Treatment for Improving

the Dependability of COTS and Legacy-Based Applications”.

In: IEEE Transactions on Dependable and Secure Computing 1.4

(2004).

[Boo] Boost. url: www.boost.org.

[Cas94] Anthony R. Cassandra. “Exact and Approximate Algorithms For

Partially Observable Markov Decision Processes”. Tesi di dott.

Brown University, 1994.

[Cha+04] R. Chandra et al. “A Global-State-Triggered Fault Injector

for Distributed System Evaluation”. In: IEEE Transactions on

Parallel and Distributed Systems (2004).

[Cha98] Ramesh U.V. Chandra. “Loki: A State-Driven Fault Injector For

Distributed Systems”. Tesi di laurea mag. Indian Institute of

Technology, Madras, 1998.

109

http://think-async.com

www.boost.org

Bibliografia

[DM06] J.A. Duraes e H.S. Madeira. “Emulation of Software faults:

A Field Data Study and a Practical Approach”. In: IEEE

Transactions on Software Engineering 32.11 (2006).

[DME08] D. Dig, J. Marrero e M.D. Ernst. How do programs become mo-

re concurrent? A story of program transformations. Rapp. tecn.

MIT-CSAIL-TR-2008-053. MIT, 2008.

[DME09] D. Dig, J. Marrero e M.D. Ernst. “Refactoring Sequential Java

Code for Concurrency via Concurrent Libraries”. In: Proc. 31st

Intl. Conf. on Software Engineering. 2009.

[Gra85] Jim Gray. “Why Do Computers Stop and What Can Be Do-

ne About It?” In: Proc. 5th Symp. on Reliability in Distributed

Software and Database Systems. 1985.

[GT07] M. Grottke e K.S. Trivedi. “Fighting Bugs: Remove, Retry,

Replicate, and Rejuvenate”. In: IEEE Computer 40.2 (2007).

[LI93] I. Lee e RK Iyer. “Faults, Symptoms, and Software Fault To-

lerance in the Tandem GUARDIAN90 Operating System”. In:

Proc. 23th Symp. on Fault-Tolerant Computing. 1993.

[Lu+08] Shan Lu et al. “Learning from mistakes — A Comprehensive Stu-

dy on Real World Concurrency Bug Characteristics”. In: Proc.

Intl. Conf. on Architecture Support for Programming Languages

and Operating Systems. 2008.

[Mar94] Martin L. Puterman. Markov Decision Processes: Discrete Sto-

chastic Dynamic Programming. New York, NY: John WileySons,

1994, 649.

[MS97] S. Maffeis e DC Schmidt. “Constructing Reliable Distri-

buted Communication Systems with CORBA”. In: IEEE

Communications Magazine 35.2 (1997).

[NC10] R. Natella e D. Cotroneo. “Emulation of Transient Soft-

ware Faults for Dependability Assessment: A Case Study”. In:

2010 European Dependable Computing Conference. IEEE. 2010,

pp. 23–32.

110

Bibliografia

[Neu05] Gerhard Neumann. “The Reinforcement Learning Toolbox,

Reinforcement Learning for Optimal Control Tasks.” Tesi di

laurea mag. University of Technology (Graz), 2005.

[NJ00] Andrew Y. Ng e Michael Jordan. “PEGASUS:A policy search

method for large MDPs and POMDPs”. In: Proceedings of Un-

certainty in Artificial Intelligence (UAI) 2000. 2000, pp. 406–

415.

[Qin+05] Feng Qin et al. “Rx: Treating Bugs as Allergies—A Safe Method

to Survive Software Failures”. In: Symp. on Operating Systems

Principles. 2005.

[SB98] Richard S. Sutton e Andrew G. Barto. Reinforcement Learning:

An Introduction. Cambridge, MA: MIT Press, 1998.

[SC91] M. Sullivan e R. Chillarege. “Software Defects and their Impact

on System Availability: A Study of Field Failures in Operating

Systems”. In: Proc. Intl. Symp. on Fault-Tolerant Computing.

1991.

[Tes02] Gerald Tesauro. “Programming backgammon using self-teaching

neural nets”. In: Artificial Intelligence 134 (2002).

[Wan+97] Y.M. Wang et al. “Progressive Retry for Software Failure Reco-

very in Message-Passing Applications”. In: IEEE Transactions

on Computers 46.10 (1997).

111

un approccio per la generazione di scenari di test in sistemi ... · distribuito: loki. in ne,...

Documents