2014 monografia final

Bruno Vinicius Silva

Mineração de dados para análise quantitativade chutes a gol em um ambiente de simulação

de futebol de robôs em duas dimensões

Salvador-BA, Brasil

14 de julho de 2014


Mineração de dados para análise quantitativa de chutes agol em um ambiente de simulação de futebol de robôs

em duas dimensões

Monografia para Trabalho de Conclusão deCurso de graduação. Áreas de estudo: Mine-ração de Dados, Aprendizado de Máquina,Reconhecimento de Padrões, Análise Quanti-tativa Esportiva e Robótica Inteligente.

UNEB - Universidade do Estado da Bahia

Departamento de Ciências Exatas e da Terra

Curso de Sistemas de Informação

Orientador: Prof. MSc. Marco Antônio Costa Simões

Salvador-BA, Brasil14 de julho de 2014


Mineração de dados para análise quantitativa de chutes agol em um ambiente de simulação de futebol de robôs

em duas dimensões

Monografia para Trabalho de Conclusão deCurso de graduação. Áreas de estudo: Mine-ração de Dados, Aprendizado de Máquina,Reconhecimento de Padrões, Análise Quanti-tativa Esportiva e Robótica Inteligente.

Monografia apresentada como exigência para obtenção do grau de bacharel nocurso de Sistemas de Informação da Universidade Estadual da Bahia. Entregue por BrunoVinicius Silva em 14 de julho de 2014, Salvador-BA, Brasil:

Prof. MSc. Marco Antônio Costa SimõesOrientador, Professor da DisciplinaUniversidade do Estado da Bahia

Prof. Ph.D Diego Gervasio Frías SuárezProfessor Convidado

Universidade do Estado da Bahia

Prof. Ph.D Josemar Rodrigues de SouzaProfessor Convidado

Universidade do Estado da Bahia

Salvador-BA, Brasil14 de julho de 2014

Ao visionário, ao guerreiro,ao mestre e ao curador.

Agradecimentos

Essa monografia é uma festa. Do “homem das máquinas” para sua avó Vivalda,que esperou enquanto pôde. E o primeiro pedaço vai para minha mãe, por sempre mecuidar com tudo que pode. O segundo vai para meu tio José, que me ajudou a realizartudo que pude. A vocês, mais do que todos, sou grato.

A minha madrinha, todos meus outros tios e familiares, aprendo cada vez maissobre a importância de vocês. À família que eu escolhi, Zélia e todos os seus filhos: Ohana.A Felipe e Raul, que me acompanharam do primeiro trabalho à monografia, agora sócios,eu não teria conseguido se não estivéssemos juntos nessa. A Ju em especial, companheira,competidora e tantos outros papéis em (quase) todas as disciplinas e na vida.

A Caio, grande parceiro de crescimento, por segurar todas as pontas para queeu pudesse terminar esse trabalho e pelas incontáveis horas de conversa. A Adailton eAdriano, grandes amigos, apesar da traição de se formarem primeiro: agora sigo logo atrásde vocês. A Grimaldo, pela inspiração e pela ajuda com modelagem: imagino que não éfácil ajudar alguém que sempre quer ter razão. Aos amigos não citados, de antes, durantee depois da UNEB, sem mimimi, sou grato a todos vocês.

Ao ACSO, que fez parte de quase toda minha caminhada na UNEB e foi tambémo caminho. Voltar para uma monografia sobre futebol de robôs, não poderia ser diferente.A Marco Simões, que curiosamente nunca foi meu professor numa disciplina, mas queaté mesmo virou noite junto programando o Bahia2D, durante as alegrias e tensões dasRobocups. Isso contou muito mais. A Diego Frias por me inspirar, não teria entrado nomundo da modelagem computacional sem sua participação.

A Cláudio Amorim, figura raríssima, por ter me levado muito além do tékhne(#somostodosornitorrincos). A Jorge Farias pelo primeiro impulso, que me carrega atéhoje, ensinando de forma brilhante os meus primeiros algoritmos. A Ana America, pornos cuidar enquanto esteve no colegiado. E sem dúvida, a todo colegiado, professores ecoordenador por me aturarem mais tempo do que o devido, dando uma chance a esseteimoso.

Devo agradecer também a muitos que nunca vi, mas que foram fundamentais. Aempresa Opta por fornecer de modo solícito as definições dos eventos de futebol. Aosportugueses Luís Paulo e Pedro Abreu, ombros sobre os quais me apoiei mais diretamentedo que os demais. A Robocup, em especial a Itsuki Noda, Hidehisa Akiyama e todos quetrabalharam nas ferramentas e bibliotecas públicas relacionadas. Ao grupo que mantém opacote Abntex2 para o LaTeX, não faço ideia de quantas horas me pouparam, para quepudesse focar no mais importante. Ao Ian Witten e todos envolvidos na Univesidade de

Waikato com a ferramenta WEKA, excelente trabalho (também pelo curso aberto oferecidoao mundo). A todos, de tantas linhas de código, dos softwares gratuitos que pude utilizar.

Muito obrigado.

“Everything should be made as simple as possible,but not simpler.”

Albert Einstein

“Un faro quieto nada seríaguía, mientras no deje de girar

no es la luz lo que importa en verdadson los 12 segundos de oscuridad.

Para que se vea desde alta mar...De poco le sirve al navegante

que no sepa esperar.

Pie detrás de pieno hay otra manera de caminar”

Jorge Drexler / Vitor Ramil

ResumoEste trabalho demonstra que é possível classificar automaticamente eventos complexosocorridos durante jogos de futebol de robôs da Liga de Futebol Simulado Robocup 2D.Utilizando a metodologia CRISP-DM foi realizado um processo completo de Descoberta deConhecimento em Bases de Dados sobre os logs das partidas. O objetivo desse processo foiextrair conhecimento acerca de chutes a gol, o que está relacionado a algumas das métricasmais importantes no futebol para analisar o desempenho de uma equipe e também comos eventos com a pior classificação automatizada reportada na literatura (ABREU etal., 2011). Utilizando uma análise pós-simulação, offline, baseada em técnicas clássicasde mineração de dados, foi criado um classificador que melhorou em 13,99% o baselineexistente. Esse trabalho é um bom indicativo da viabilidade de desenvolver uma ferramentade análise de desempenho completa, que capte as diversas métricas utilizadas no futebolreal também no ambiente de futebol de robôs simulado, o que significaria uma importanteevolução nos métodos de teste e experimentação utilizados atualmente.

Palavras-chave: Mineração de Dados. Aprendizado de Máquina. Reconhecimento dePadrões. Análise Quantitativa Esportiva. Robótica Inteligente. Robocup.

AbstractThis project shows that it is possible to automatically classify complex events that takeplace during robot soccer games from the RoboCup 2D Soccer Simulation League. Usingthe CRISP-DM methodology a complete Knowledge Discovery in Databases process wasrun over matches log files. The purpose was to extract knowledge about shots on goal, whichare related to some of the most important soccer metrics to analyze the performance of ateam and are also related with the events with worst automated classification, accordingto literature (ABREU et al., 2011). Using an offline post-simulation analysis, based onclassic data mining techniques, it was created a classifier that has improved the existentbaseline by 13,99%. This project offers a good indicative on the feasibility of developing atool to do a complete performance analysis, one that would capture the several key metricsused on real soccer now on simulated soccer, which could mean an important improvementto testing and experimentation methods currently being used.

Keywords: Data Mining. Machine Learning. Pattern Recognition. Quantitative Analysisin Sports. Intelligent Robotics. Robocup.

Lista de ilustrações

Figura 1 – Visão geral da Robocup 2012 durantes as competições . . . . . . . . . 21Figura 2 – Arquitetura do Robocup Soccer Simulator . . . . . . . . . . . . . . . . 26Figura 3 – Soccer Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figura 4 – LogPlayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Figura 5 – As flags e linhas do campo simulado . . . . . . . . . . . . . . . . . . . 31Figura 6 – Área do tackle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 7 – Área do catch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 8 – Exemplo de conteúdo dos arquivos RCG e RCL . . . . . . . . . . . . . 42Figura 9 – Interface do TeamAssistant2003 . . . . . . . . . . . . . . . . . . . . . . 47Figura 10 – Interface do LogAlyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figura 11 – Interface do OptaPro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Figura 12 – A essência da mineração de dados . . . . . . . . . . . . . . . . . . . . . 60Figura 13 – As fases do processo CRISP-DM . . . . . . . . . . . . . . . . . . . . . 61Figura 14 – A tarefa de classificação . . . . . . . . . . . . . . . . . . . . . . . . . . 63Figura 15 – Abordagem geral para construir um modelo de classificação . . . . . . 64Figura 16 – Scatterplot Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Figura 17 – Caras de Chernoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Figura 18 – Exemplo de overfitting . . . . . . . . . . . . . . . . . . . . . . . . . . . 67Figura 19 – Aba de classificação da ferramenta WEKA . . . . . . . . . . . . . . . . 76Figura 20 – Metodologia do projeto: dos dados aos resultados . . . . . . . . . . . . 80Figura 21 – Fase 2: Compreensão dos dados . . . . . . . . . . . . . . . . . . . . . . 82Figura 22 – Estudo sobre a velocidade da bola em chutes do time Bahia2D . . . . . 86Figura 23 – Fase 3: Preparação dos dados . . . . . . . . . . . . . . . . . . . . . . . 88Figura 24 – Diagrama ER do Repositório Intermediário . . . . . . . . . . . . . . . 89Figura 25 – Diagrama de Classes do RCG2DB . . . . . . . . . . . . . . . . . . . . . 90Figura 26 – Diagrama de Classes do ShotCandidatesDetector . . . . . . . . . . . . 91Figura 27 – O problema da bola fora . . . . . . . . . . . . . . . . . . . . . . . . . . 93Figura 28 – Lances e decisões do algoritmo de detecção de candidatos . . . . . . . . 94Figura 29 – Diagrama de Classes do RCGCutter . . . . . . . . . . . . . . . . . . . 95Figura 30 – Lance de Shot on target sendo visualizado e classificado . . . . . . . . . 96Figura 31 – Exemplo das 4 cenas selecionadas em um caso de Shot on target . . . . 98Figura 32 – Diagrama de Classes do FeatureSE . . . . . . . . . . . . . . . . . . . . 101Figura 33 – Diagrama de Sequência do FeatureSE . . . . . . . . . . . . . . . . . . . 102Figura 34 – Fase 4: Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Figura 35 – Totais das classes finais . . . . . . . . . . . . . . . . . . . . . . . . . . 104Figura 36 – Distribuição das classes por algumas características . . . . . . . . . . . 105

Figura 37 – Diferença dos ângulos x Distância da bola no lastKick . . . . . . . . . 106Figura 38 – Exemplo de casos filtrados . . . . . . . . . . . . . . . . . . . . . . . . . 108Figura 39 – Conjunto final mais balanceado após filtragens . . . . . . . . . . . . . . 108Figura 40 – Experimento configurado e pronto para ser executado . . . . . . . . . . 111Figura 41 – Comparação dos modelos sendo realizada no WEKA . . . . . . . . . . 114Figura 42 – Ferramenta para visualizar chutes a gol . . . . . . . . . . . . . . . . . . 120Figura 43 – Métricas de desempenho de acordo com a força dos times . . . . . . . . 121

Lista de tabelas

Tabela 1 – Comparação entre os ambientes do xadrez e do futebol . . . . . . . . . 23Tabela 2 – Parâmetros do servidor relacionados ao modelo de movimento . . . . . 34Tabela 3 – Capacidade de atuação - ações primárias . . . . . . . . . . . . . . . . . 38Tabela 4 – Capacidade de atuação - ações concorrentes . . . . . . . . . . . . . . . 38Tabela 5 – Parâmetros relacionados aos jogadores heterogêneos . . . . . . . . . . . 39Tabela 6 – Mensagens enviadas pelo juiz . . . . . . . . . . . . . . . . . . . . . . . 41Tabela 7 – Dados sobre chutes a gol (ABREU et al., 2011) . . . . . . . . . . . . . 49Tabela 8 – Resultados para a detecção de chutes a gol (ABREU et al., 2011) . . . 49Tabela 9 – Hierarquia sobre a relação entre organizações e dados esportivos . . . . 54Tabela 10 – Matriz de confusão para um classificador multiclasse . . . . . . . . . . 67Tabela 11 – Matriz de confusão para um classificador binário . . . . . . . . . . . . 72Tabela 12 – Matriz de confusão um-contra-todos para classe 𝐶1 . . . . . . . . . . . 75Tabela 13 – Divisão dos times da Robocup 2013 . . . . . . . . . . . . . . . . . . . . 83Tabela 14 – Resumo dos casos na classificação manual . . . . . . . . . . . . . . . . 96Tabela 15 – Resumo das características numéricas . . . . . . . . . . . . . . . . . . . 104Tabela 16 – Variações nas características finais . . . . . . . . . . . . . . . . . . . . 109Tabela 17 – Resultados do segundo experimento . . . . . . . . . . . . . . . . . . . . 115Tabela 18 – Matriz de confusão do modelo vencedor . . . . . . . . . . . . . . . . . 116Tabela 19 – Resultados por classe e métrica para o modelo vencedor . . . . . . . . 117Tabela 20 – Comparação entre o modelo vencedor e a heurística de Abreu . . . . . 117Tabela 21 – Médias de cada métrica de acordo com a força dos times . . . . . . . . 121Tabela 22 – Espaço amostral - times fortes . . . . . . . . . . . . . . . . . . . . . . . 131Tabela 23 – Espaço amostral - times médios . . . . . . . . . . . . . . . . . . . . . . 132Tabela 24 – Espaço amostral - times fracos . . . . . . . . . . . . . . . . . . . . . . 132Tabela 25 – Algoritmos e parâmetros utilizados no WEKA: árvores . . . . . . . . . 133Tabela 26 – Algoritmos e parâmetros utilizados no WEKA: regras e bayes . . . . . 133Tabela 27 – Algoritmos e parâmetros utilizados no WEKA: funções e lazy . . . . . 134Tabela 28 – Algoritmos e parâmetros utilizados no WEKA: meta e outros . . . . . 134

Lista de abreviaturas e siglas

ACC Accuracy

ACSO Núcleo de Arquitetura de Computadores e Sistemas Operacionais

ARFF Attribute-Relation File Format

CRISP-DM Cross Industry Standard Process for Data Mining

CSV Comma-separated Values

DM Mineração de Dados (Data Mining)

FDR False discovery rate

FN False negative

FNR False negative rate

FP False positive

FPR False positive rate

IA Inteligência Artificial

KDD Descoberta de Conhecimento em Bases de Dados (Knowledge Discoveryin Databases)

MDL Minimum Description Length

MIT Massachusetts Institute of Technology

NPV Negative predictive value

OvA Um-contra-todos (One-vs-All)

PPV Positive predictive value

ROC Receiver operating characteristic

SVM Support Vector Machines

TDP Team Description Paper

TN True negative

TP True positive

TNR True negative rate

TPR True positive rate

UNEB Universidade do Estado da Bahia

WEKA Waikato Enviroment for Knowledge Analysis

Sumário

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

I Referenciais teóricos 201 Robot World Cup (Robocup) . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.1 Robocup Soccer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.2 Liga de Futebol Simulado Robocup 2D (Simulação 2D) . . . . . . . . . . . 23

1.2.1 Ferramenta de simulação Robocup Soccer Simulator . . . . . . . . . 251.2.1.1 Soccer Server . . . . . . . . . . . . . . . . . . . . . . . . . 261.2.1.2 Soccer Monitor . . . . . . . . . . . . . . . . . . . . . . . . 271.2.1.3 LogPlayer . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.2.2 O ambiente simulado pelo Soccer Server . . . . . . . . . . . . . . . 291.2.2.1 O campo e os objetos fixos . . . . . . . . . . . . . . . . . . 301.2.2.2 Objetos móveis . . . . . . . . . . . . . . . . . . . . . . . . 301.2.2.3 Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341.2.2.4 Atuadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 351.2.2.5 Jogadores heterogêneos . . . . . . . . . . . . . . . . . . . 391.2.2.6 Técnico online e offline . . . . . . . . . . . . . . . . . . . . 391.2.2.7 Juízes e estados do jogo . . . . . . . . . . . . . . . . . . . 40

1.2.3 Os logs das partidas . . . . . . . . . . . . . . . . . . . . . . . . . . 411.3 Testes e experimentos na Simulação 2D . . . . . . . . . . . . . . . . . . . . 441.4 Outras ferramentas e trabalhos relacionados . . . . . . . . . . . . . . . . . 471.5 Semelhanças entre futebol real e simulado . . . . . . . . . . . . . . . . . . 50

2 Análise quantitativa nos esportes . . . . . . . . . . . . . . . . . . . . . . . . 522.1 Esportes e mineração de dados . . . . . . . . . . . . . . . . . . . . . . . . . 522.2 Ferramentas comerciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542.3 Definição de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.4 Diferenças entre o futebol profissional e o de robôs . . . . . . . . . . . . . . 58

3 Mineração de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.1 Metodologia CRISP-DM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.2 Classificação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.3 Visualização de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.4 Generalização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.5 Técnicas de validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693.6 Avaliação e comparação de modelos . . . . . . . . . . . . . . . . . . . . . . 71

3.6.1 Métricas de desempenho para classificadores . . . . . . . . . . . . . 72

3.6.2 F-measure para classificadores multiclasse . . . . . . . . . . . . . . 753.7 WEKA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

II Projeto 784 Fase 1: Compreensão do problema . . . . . . . . . . . . . . . . . . . . . . . 795 Fase 2: Compreensão dos dados . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.1 Análise qualitativa dos logs . . . . . . . . . . . . . . . . . . . . . . . . . . 835.2 Análise objetiva e descrição dos dados . . . . . . . . . . . . . . . . . . . . . 835.3 Seleção do espaço amostral . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6 Fase 3: Preparação dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . 886.1 Carga do Repositório Intermediário . . . . . . . . . . . . . . . . . . . . . . 886.2 Seleção de casos candidatos . . . . . . . . . . . . . . . . . . . . . . . . . . 906.3 Edição de logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 946.4 Classificação manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 956.5 Engenharia de características . . . . . . . . . . . . . . . . . . . . . . . . . 97

6.5.1 Seleção de características . . . . . . . . . . . . . . . . . . . . . . . . 976.5.2 Extração de características . . . . . . . . . . . . . . . . . . . . . . . 996.5.3 Criação do vetor de características . . . . . . . . . . . . . . . . . . 101

7 Fase 4: Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.1 Pré-processamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.1.1 Visualização e exploração dos dados . . . . . . . . . . . . . . . . . . 1037.1.2 Filtragem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1067.1.3 Seleção de atributos . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7.2 Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

III Resultados 1128 Fase 5: Avaliação dos resultados . . . . . . . . . . . . . . . . . . . . . . . . 113

8.1 Comparação entre os modelos criados . . . . . . . . . . . . . . . . . . . . . 1138.2 Comparação com a literatura . . . . . . . . . . . . . . . . . . . . . . . . . 1168.3 Revisão do processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

9 Fase 6: Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1199.1 Sugestão de implantação do modelo . . . . . . . . . . . . . . . . . . . . . . 1199.2 Análise da utilidade dos modelos . . . . . . . . . . . . . . . . . . . . . . . 1209.3 Manutenção e evolução dos modelos . . . . . . . . . . . . . . . . . . . . . . 122

IV Conclusão 123Conclusões e trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Apêndices 130APÊNDICE A Logs do espaço amostral . . . . . . . . . . . . . . . . . . . . . 131APÊNDICE B Algoritmos de aprendizado utilizados no WEKA . . . . . . . . 133

Anexos 135ANEXO A Definições dos eventos da ferramenta OptaPro . . . . . . . . . . . 136

17

Introdução

Este trabalho demonstra que é possível classificar automaticamente eventos com-plexos ocorridos durante jogos de futebol de robôs da Liga de Futebol Simulado Robocup2D (Simulação 2D). Foi realizado um processo completo de Descoberta de Conhecimentoem Bases de Dados (Knowledge Discovery in Databases, KDD) sobre os logs das partidaspara extrair conhecimento acerca de chutes a gol, uma das métricas mais importantesno futebol para analisar o desempenho de uma equipe e também o evento com a piorclassificação automatizada reportada na literatura (ABREU, 2010). Utilizando uma análisepós-simulação, offline, baseada em técnicas clássicas de mineração de dados (data mining,DM) foi criado um classificador superior ao baseline proposto, alcançando qualidade similarà classificação realizada manualmente por especialistas.

Atualmente o tempo necessário para analisar de forma robusta o impacto que umamudança no software dos agentes inteligentes causa no desempenho do sistema como umtodo, o que demanda a análise manual de uma grande quantidade de logs, inviabiliza quetestes integrados sejam realizados do modo ideal e na frequência ideal. Uma das abordagensmais comuns para superar essa limitação é definir o desempenho das equipes apenas emfunção da quantidade de gols feitos e tomados, como vemos em artigos de descrição dasequipes (TDPs) de 2013 (RAMOS et al., 2013; LIN, 2013; PROKOPENKO et al., 2013;HUANG et al., 2013; ZEKAI-CHENG et al., 2013).

Essa abordagem, apesar de funcionar como um método para avaliação do desem-penho, desconsidera o potencial das informações escondidas nos dados de cada log. Issotorna mais difícil que os resultados observados nos experimentos sejam compreendidos eque novas hipóteses sejam levantadas: os gols podem definir o desempenho da equipe masnão revelam nenhuma pista do porquê desse desempenho.

Esse cenário no ambiente de pesquisa do futebol de robôs contrasta com o ambientecomercial do futebol real, onde especialistas de domínio como técnicos e olheiros possuemuma ampla variedade de estatísticas de alto nível sobre as quais podem pautar importantestomadas de decisão. Empresas como a Opta Sports, por exemplo, coletam mais de 200variáveis por jogo (BATEMAN, 2012), além de fornecerem ferramentas para realizardiversas interações com esses dados.

Esse trabalho buscou diminuir a distância entre esses dois campos demonstrando aviabilidade de classificar automaticamente eventos complexos da Simulação 2D, apresen-tando um caminho viável para o desenvolvimento de ferramentas similares para o domínioda pesquisa científica com futebol de robôs. Com a extração automática de conhecimento apartir dos logs, orientado pelo que vem sendo aplicado comercialmente no futebol, torna-se

Introdução 18

mais fácil realizar comparações entre o futebol de robôs e o futebol real, como a realizadaem (ABREU et al., 2012), úteis para a compreensão do avanço da área.

Ainda mais importante, o trabalho colabora com a discussão sobre o difícil problemade testar os sistemas multiagentes (GATTI; STAA, 2006), podendo seus resultados seremutilizados como a base para uma abordagem caixa-preta de testes integrados dos timesparticipantes da Simulação 2D. Isso porque estatísticas de alto nível podem ser a basepara uma metodologia robusta para análise de desempenho na Simulação 2D, problemade pesquisa que ganhou destaque durante uma competição em 1998 e permanece umproblema aberto (CHEN et al., 2003).

Por fim, cria novos caminhos para melhorar o desempenho das equipes, pois atese de doutoramento de Abreu (2010), que teve como questão de pesquisa: “How toimprove the performance of a soccer team through the calculation of final game statistics”1,comprovou que é possível melhorar o desempenho dos times da Simulação 2D a partir douso de estatísticas de alto nível.

O restante da monografia está organizada como segue:

1. Parte I: Referenciais teóricos

a) O Capítulo 1 detalha o contexto do problema. Primeiro é apresentada aRobot World Cup Initiative (Robocup), e os dados dos logs são estudadosa fundo a partir de informações técnicas sobre o ambiente da Simulação 2D.Depois os métodos de teste utilizados na liga são explorados para deixar clara anecessidade de métricas de desempenho. O capítulo termina com a apresentaçãodos trabalhos relacionados mais importantes;

b) O Capítulo 2 aponta para a solução ao introduzir a análise quantitativa doponto de vista do futebol profissional. É apresentada uma análise sobre asmétricas de desempenho utilizadas nesse domínio e são selecionados e definidosos eventos a serem detectados na Simulação 2D. Aqui também são explicitadasas diferenças entre o futebol real e o futebol simulado, incluindo o estado daarte da análise quantitativa em ambas as áreas;

c) O Capítulo 3 mostra o caminho para se chegar do problema até a solução. Aárea da Mineração de Dados é explorada, com foco no problema de classificação.São discutidas a metodologia para o desenvolvimento do trabalho, além dosproblemas relacionados mais importantes, como generalização e validação.

2. Parte II: Projeto1 “Como melhorar o desempenho de um time de futebol através do cálculo de estatísticas finais de jogo”

(Tradução do autor)

Introdução 19

a) O Capítulo 4 ao Capítulo 7 apresentam as 4 primeiras etapas do KDD,que vão desde a definição dos objetivos do projeto até o desenvolvimento dosclassificadores.

3. Parte III: Resultados

a) O Capítulo 8 e Capítulo 9 apresentam as 2 últimas etapas do KDD, onde osresultados obtidos são analisados, o processo é revisado e a evolução do modeloproposto é documentada.

4. Parte IV: Conclusão

a) Resume as contribuições da monografia e destaca possibilidades interessantesde trabalhos futuros.

Parte I

Referenciais teóricos

21

1 Robot World Cup (Robocup)

A Liga de Futebol Simulado Robocup 2D, ou apenas Simulação 2D, é a plataformaque foi utilizada nesse trabalho. Ela é uma das ligas de simulação que fazem parte daRobocup, projeto que visa promover a pesquisa e educação sobre Robótica e a InteligênciaArtificial (IA) através, principalmente, do futebol de robôs (KITANO et al., 1997). Ainiciativa teve sua origem em 1993 no Japão, como uma competição nacional de robótica,mas devido a aderência que obteve da comunidade científica internacional, em apenasum mês o projeto já havia sido renomeado como Robot World Cup Inititive (Robocup) eganhado proporções mundiais (ROBOCUP, 2013a).

Figura 1 – Visão geral da Robocup 2012 durantes as competições

Fonte: (The Verge, 2012)

Desde então, anualmente a Robocup promove num país diferente o que se tornouum dos maiores e mais importantes eventos de robótica autônoma do mundo, em queparticipam pesquisadores de mais de 40 países e que conta com competições, diversasdemonstrações e também com um simpósio onde são discutidos e compartilhados osavanços científicos na área (a Figura 1 mostra a dimensão do evento). Apesar de suaorigem ter se dado por conta do futebol de robôs e esse continuar sendo o principal foco dainiciativa, o amadurecimento da Robocup levou a criação de diferentes categorias. Comovisto em (ROBOCUP, 2013c), as 6 categorias do evento oficial de 2013 foram:

Capítulo 1. Robot World Cup (Robocup) 22

• Robocup Soccer para robôs especializados em jogar futebol;

• Robocup@Home para robôs domésticos;

• Robocup Rescue para robôs de resgate;

• Robocup@Work para robôs industriais;

• Robocup Sponsored que em 2013 trouxe um desafio para aplicações de robótica naárea de logística;

• RobocupJunior voltada para introduzir estudantes do primário e ginásio no universoda robótica.

1.1 Robocup SoccerRobocup Soccer, principal categoria da Robocup, é a categoria relevante para esse

trabalho. Seu arrojado objetivo é, como publicado em (ROBOCUP, 2013a):

By mid-21st century, a team of fully autonomous humanoid robot soccerplayers shall win the soccer game, comply with the official rule of theFIFA, against the winner of the most recent World Cup1.

Utilizar jogos entre máquinas e humanos é uma abordagem comum na InteligênciaArtificial (IA), já que especialistas humanos são um excelente baseline para inteligência.Essa estratégia é útil tanto por ajudar a medir o progresso na área quanto por manterpesquisadores focados e motivados, uma vez que o desafio da IA quando vista de modogeral é muito grande, como explica em (HAMM, 2012) um dos projetistas do Deep Blue,Murray Campbell:

If you try to tackle something like general intelligence, you’ll die out ofthe blocks. It’s too much. But, with games, you focus on one specificproblem. You have a chance to make progress and produce something ofvalue that can be used as a component of something bigger.2

O IBM Deep Blue foi um supercomputador criado para ser especialista em jogarxadrez, e tem um papel de destaque na história da IA por ter derrotado pela primeira vezum campeão do mundo na modalidade. O feito se deu sobre Garry Kasparov, consideradoum dos maiores enxadristas da história, em maio de 1997. O desafio do futebol, proposto5 anos antes dessa representativa vitória do Deep Blue, gera na comunidade científica um1 “Em meados do século 21, um time de robôs humanoides jogadores de futebol completamente autônomos

deve ganhar um jogo de futebol, utilizando as regras da FIFA, contra o mais recente vencedor da Copado Mundo.” (Tradução do autor)

2 “Se você tentar lidar com algo como inteligência geral, você vai falhar. Isso é demais. Mas, com jogos,você pode focar em um problema específico. Você tem a chance de fazer progresso e produzir algo devalor que pode ser usado como componente de algo maior.” (Tradução do autor)


impulso similar, capaz de redefinir o estado da arte da pesquisa nessa área, mas guardatambém importantes diferenças para o desafio do xadrez. Um resumo dessas diferenças deacordo com classificação proposta em (RUSSEL; NORVIG, 2003) é listado na Tabela 1.

Tabela 1 – Comparação entre os ambientes do xadrez e do futebol

Propriedade Xadrez FutebolAmbiente Estático DinâmicoResultado das ações Determinístico EstocásticoMudança de estado Por turno Tempo realAcesso a informação Completa IncompletaControle Central Distribuído

Fonte: Adaptado de (ROBOCUP, 2013a)

Essas características tornam o futebol um ambiente mais interessante que o xadrezpor reunir maior similaridade com ambientes reais e complexos, que representam desafiosatuais para a robótica. Sendo mais específico, o futebol abre espaço para endereçarproblemas como fusão de sensores, comportamento reativo, reconhecimento de contexto,aprendizado de máquina, planejamento em tempo real, sistemas multiagentes, visãocomputacional e controle motor. Um resumo sobre a conexão do futebol de robôs com essesproblemas é encontrada em (KITANO et al., 1997). Dada a complexidade desse ambiente eo atual estado da arte na resolução desses diferentes desafios, a categoria Robocup Soccerse encontra ainda subdividida em 6 ligas:

• Simulação 2D;

• Simulação 3D;

• Small Size;

• Middle Size;

• Standard Platform;

• Humanoide.

1.2 Liga de Futebol Simulado Robocup 2D (Simulação 2D)Cada liga colabora de modo diferente para a grande meta da Robocup Soccer,

variando num espectro que vai desde ambientes 100% simulados, como a simulação 2D,onde se abstrai a complexidade do hardware e do controle do robô, tornando o foco da ligaa elaboração e execução de estratégias coordenadas de alto nível; até ambientes 100% físicose com robôs humanoides desenvolvidos de forma independente, como a Liga Humanoide,


onde o principal desafio está no projeto, controle dos robôs e na execução bem realizadadas ações.

No estado atual de desenvolvimento da robótica autônoma para futebol é naSimulação 2D onde podemos assistir partidas de futebol que mais se assemelham a umapartida de futebol de verdade, tanto pela capacidade de jogar demonstrada pelas equipesde ponta, quanto pela semelhança entre as regras utilizadas na simulação com as regras daFIFA. O foco na estratégia presente na Simulação 2D e a sua semelhança com o futebolreal tornam essa liga o ambiente mais propício para a aplicação desse trabalho. Dada adinâmica dos jogos é provável que em nenhuma outra liga da Robocup uma visão resumidado que acontece numa partida na forma de estatísticas de futebol traga o mesmo impactopara as pesquisas.

A Simulação 2D é uma das ligas mais antigas da Robocup, presente desde a primeiraedição do evento, ocorrida em 1997, o que colabora para que a ambiente seja muito estávele existam tantas equipes maduras. Já no ano seguinte à primeira Robocup, o grupo quedesenvolveu a primeira versão do simulador propôs que fosse criada uma ferramenta queextraísse estatísticas de futebol para auxiliar as equipes a identificar suas forças e fraquezase mapear seus avanços (TANAKA et al., 1998). Apesar disso uma ferramenta de extraçãode estatísticas de alto nível aberta às equipes não existe até hoje.

Um caso interesssante, relatado no próprio manual oficial do servidor da liga, reforçae até mesmo amplia a relevância de uma ferramenta com esse propósito. A competiçãode 1998 foi a primeira a abrigar uma sessão para avaliar a contribuição científica dosparticipantes e estimular a transferência de conhecimento, foi a Multi-agent ScientificEvaluation Session. Nesse evento, a adaptabilidade dos times era testada através de 4 jogoscontra um mesmo oponente, nos quais 3 jogadores eram desabilitados gradativamente.Durante a sessão, dada a dificuldade em avaliar o desempenho das equipes de formacriteriosa, encontrar uma metodologia para medir o desempenho dos sistemas e analisar osresultados em si, foi considerado um problema de pesquisa em aberto (CHEN et al., 2003):

Very early on, even during the session itself, it became clear that while infact most participants agreed intuitively with the evaluation protocol, itwasn’t clear how to quantitatively, or even qualitatively, analyse the data.The most obvious measure of the goal-difference at the end of each halfmay not be sufficient: some teams seem to do better with less players,some do worse. [...] The evaluation methodology itself and analysis ofthe results became open research problems in themselves.3

3 “Muito cedo, ainda durante a sessão, ficou claro que apesar da maioria dos participantes concordaremintuitivamente com o protocolo de avaliação, não ficou claro como quantitativamente, ou mesmoqualitativamente, analisar os dados. A medida mais óbvia de saldo de gols ao final de cada tempopode não ser suficiente: alguns times parecem jogar melhor com menos jogadores, alguns jogam pior.[...] A metodologia de avaliação em si e a análise dos resultados se tornaram problemas de pesquisaem aberto.” (Tradução do autor)


Esse trabalho, ao ampliar a oferta de dados sobre cada partida de modo prático,é um passo intermediário para o desenvolvimento de uma ferramenta que suporte umametodologia robusta para análise de desempenho. Como conhecer profundamente os dadosé parte fundamental de qualquer trabalho de mineração de dados, o restante dessa seçãodescreve em detalhes os aspectos relevantes da Simulação 2D para a detecção automáticade estatísticas. A motivação para a escolha de chutes a gol é explicada na seção 1.4, apartir da análise dos trabalhos relacionados.

1.2.1 Ferramenta de simulação Robocup Soccer Simulator

Segundo (RUSSEL; NORVIG, 2003), um agente inteligente é uma entidade autô-noma que percebe seu ambiente através de sensores e age nesse ambiente através deatuadores de modo a maximizar o seu desempenho. O Simulador de futebol da Robocup éum sistema que permite que agentes inteligentes desenvolvidos em diferentes linguagenspossam jogar futebol entre si (CHEN et al., 2003). Ele foi desenvolvido inicialmente em1993 pelo Dr. Itsuki Noda no Japão e foi posteriormente adotado como o servidor padrãopara a liga 2D (BOER; KOK, 2002). O artigo de 1997 (NODA et al., 1998), ano em queocorreu a primeira Robocup, apresenta o simulador como uma importante ferramentapara realizar pesquisas sobre sistemas multiagentes. Desde então ele já foi utilizado emdiversas competições internacionais e desafios de pesquisa, se tornando uma ferramentaconsagrada.

Atualmente o simulador é um projeto aberto mantido por pesquisadores envolvidoscom a Robocup e se encontra na sua versão 15 4. Ele possui uma arquitetura cliente-servidore se comunica com os clientes através de conexões UDP (Figura 2), sendo três os seusmódulos principais (NODA et al., 1998; CHEN et al., 2003):

• Soccer Server: é o servidor central, principal componente da simulação. Ele provê umcampo virtual onde as partidas são disputadas, controla toda a física do ambiente,aplica as regras de futebol e intermedia as interações entre os clientes.

• Soccer Monitor: esse módulo permite que as partidas sejam visualizadas por humanosem tempo real. Ele se conecta com o SoccerServer para receber as posições de todosos objetos no campo e cria uma representação gráfica do jogo a partir disso.

• LogPlayer: funciona como um reprodutor de vídeo, permitindo que as partidas sejamvisualizadas a qualquer momento a partir dos logs gerados pelo SoccerServer no fimde cada partida. Agrega também algumas funções úteis para análise das partidas.

4 O simulador pode ser baixado de sua página no Source Forge: <http://sourceforge.net/projects/sserver/>

http://sourceforge.net/projects/sserver/



Figura 2 – Arquitetura do Robocup Soccer Simulator

Fonte: (ABREU, 2010)

1.2.1.1 Soccer Server

O principal componente da simulação é um servidor central chamado RobocupSoccer Server, que controla toda a física do ambiente, aplica as regras de futebol eintermedia as interações entre os 11 jogadores (10 de linha e 1 goleiro) e 1 técnico decada um dos dois times. Cada jogador e técnico é controlado por um agente de softwareautônomo e independente que recebe informações do servidor através de seus sensoresvirtuais e deve decidir as ações que irá executar, de modo a influenciar o ambiente natentativa de maximizar seus objetivos. Os agentes funcionam então como os cérebrosdos jogadores e técnicos, tendo como únicas restrições obedecerem aos protocolos decomunicação estabelecidos pelo Soccer Server e nunca se comunicarem diretamente.

O servidor é um sistema de tempo-real onde o tempo transcorre de forma discreta.Cada partida é dividida em 6000 ciclos de 100 milissegundos (valor atual do parâmetrosimulator_step), que representam uma janela na qual cada agente pode enviar um conjuntode comandos para serem processados pelo servidor. A cada ciclo o mundo é então atualizadoe o servidor envia as informações sensoriais pertinentes para cada agente. São simuladasdiversas complexidades do mundo real, por exemplo, inserindo ruído nas informaçõesvisuais que cada agente recebe de acordo com a distância dele para outros objetos nocampo. Isso significa que um agente pode não saber a que time pertence outro jogador


que esteja muito distante no campo, ou a distância real dele para os outros objetos em seucampo visual. O funcionamento dos sensores e atuadores dos agentes são detalhados nasseções 1.2.2.3 e 1.2.2.4, respectivamente.

Como pode ser visto na Figura 2, o Soccer Server possui três componentes principais(descritos em (NODA et al., 1998)):

• Field Simulator: controla a física do ambiente e as posições dos objetos em campo,calculando a movimentação resultante das ações dos agentes e de fatores externoscomo o vento, também gerenciando as colisões (quando um objeto sobrepõe o outro);

• Messages Board: gerencia a comunicação entre os clientes e o servidor, recebendo asações e enviando as informações sensoriais de cada agente individualmente;

• Referee: garante que as regras do jogo sejam aplicadas corretamente, controlandoos estados do jogo (playmodes), checando o fim do primeiro e segundo tempo, golse o placar, laterais, tiros-de-meta, impedimentos, faltas, punições com cartões egarantindo o posicionamento correto dos jogadores em situações especiais (comodistância da bola no caso de faltas).

O arquivo de configuração server.conf permite que diversos aspectos da simulaçãosejam configuráveis, como por exemplo o valor padrão para a área em que um agenteconsegue influenciar a bola, equivalente ao alcance da perna, dada pelo parâmetro kicka-ble_margin (atualmente 0.7). Esse tipo de parâmetro é importante durante a terceira fasedo projeto, Preparação dos Dados (Capítulo 6), pois são utilizados para derivar atributosque não constam nos logs.

1.2.1.2 Soccer Monitor

O Soccer Monitor é um módulo que se conecta com o servidor e permite que asimulação sendo processada pelo Soccer Server seja visualizada em tempo-real por humanos.A arquitetura do servidor permite que mais de um monitor seja conectado ao mesmotempo. Usando o sistema X window ele gera uma representação gráfica do campo defutebol e dos objetos da partida tornando intuitivo acompanhar o jogo. Guardados oslimites da comparação, é como assistir a uma partida de futebol de cima. A Figura 3mostra o Monitor durante uma partida.

O Monitor mostra o nome dos dois times jogando, o placar do jogo, o playmodeatual, o tempo transcorrido de jogo (em número de ciclos), os limites e marcações docampo, os jogadores (como círculos maiores numerados) e a bola (como um círculo menorsem número). Para diferenciar os times, cada um recebe uma cor diferente, assim como osgoleiros, que possuem uma cor diferente dos jogadores de linha. As costas dos jogadores é


Figura 3 – Soccer Monitor mostrando o ciclo 203 da final da Robocup 2013 entre o campeãoWrightEagle da China (em amarelo) e o Helios2013 do Japão (em vermelho)

Fonte: Elaborado pelo autor (captura de tela)

representada pela metade escura em cada agente, e um traço na parte colorida representaa posição atual do pescoço. Alguns jogadores possuem tamanhos diferentes, o que estárelacionado com suas características heterogêneas (mais na subseção 1.2.2.5). Algumasopções especiais, como mostrar os jogadores que receberam cartão amarelo, também podemser habilitadas.

Uma das funções importantes do Monitor é permitir que um árbitro humanointerfira durante a partida. Para isso alguns comandos podem ser enviados diretamentecom o mouse, como reposicionar a bola ou os jogadores, determinar o início da partida(kickoff ) e finalizar o jogo (quit, que desconecta os agentes, salva os logs e finaliza asimulação). Ao longo dos anos diferentes monitores já foram desenvolvidos 5. A escolha domonitor não interfere em nada na partida, e ele sequer precisa estar conectado para queum jogo ocorra.

1.2.1.3 LogPlayer

O LogPlayer é um software auxiliar para assistir partidas através dos logs geradospelo Soccer Server. Ele torna os logs muito mais compreensíveis ao processá-los visualmentecomo um jogo de futebol (Figura 4). A primeira vista ele é parecido com o Soccer Monitor,entretanto possui diversas funcionalidades extras que facilitam realizar análises das partidas.Criado de forma similar a um reprodutor de vídeo, ele permite avançar e voltar no jogoconforme desejado, vendo o jogo de forma acelerada ou ciclo a ciclo, além de saltar para5 A Robocup oficialmente disponibiliza dois deles em <http://sourceforge.net/projects/sserver/>



momentos específicos. Os ciclos em que ocorreram gols, por exemplo, já ficam marcadospara facilitar a visualização do replay.

Figura 4 – Replay de uma partida sendo exibida no Logplayer a partir dos arquivos de log


Entre as diversas funcionalidades do LogPlayer podemos ver um resumo doscomandos utilizados por cada agente, traçar a trajetória dos objetos ao longo de todapartida de modo a visualizar as zonas de maior atividade, prever a trajetória da bola deacordo com as forças atuando nela a cada ciclo e ver em detalhe o campo de visão de cadajogador. Essas características tornam o LogPlayer uma das ferramentas mais importantespara que os pesquisadores possam avaliar suas equipes.

Apesar disso, a carência não suprida é detectar e contabilizar automaticamente oseventos que ocorrem enquanto a “bola está rolando”, playmode definido como play_on noservidor, criando dessa forma uma visão resumida dos acontecimentos mais relevantes dapartida: número de passes por tipo, dribles, chutes a gol. Seriam as estatísticas de jogocomumente analisadas nos jogos de futebol profissional e que são abordadas na seção 2.3.

1.2.2 O ambiente simulado pelo Soccer Server

Nesta seção alguns detalhes da Simulação 2D são observados mais de perto. Nemtodos os aspectos da simulação serão apresentados pois não influenciam diretamente nasolução, como por exemplo alguns modelos de ruído, uma vez que os dados a seremutilizados são armazenados nos logs com precisão diretamente pelo servidor. Estudar asrestrições do ambiente, por outro lado, ajuda a entender a origem dos dados que estãonos logs, permitindo uma compreensão mais profunda sobre o problema. A partir desse


estudo é possível entender, por exemplo, quais as variações que podem ocorrer nos dadosde um ciclo para o outro, sendo para isso necessário um entendimento básico da física doambiente, das regras e das limitações a que os agentes estão submetidos.

Essa seção baseia-se nas informações contidas em (BOER; KOK, 2002; CHEN etal., 2003; NODA et al., 1998). Como essas fontes (que incluem a documentação oficialmais recente, de 2003) são antigas e estão em parte obsoletas, onde foi relevante para acompreensão do entendimento da simulação elas foram atualizadas. Isso foi feito com basenos arquivos de changelog e no código do Soccer Server e documentadas nas subseçõesseguintes.

Como o nome sugere, a 2D é disputada num ambiente simulado de duas dimensões(a altura é a dimensão inexistente). À parte essa diferença, a 2D provê um ambientebastante complexo, simulando características do mundo real como ruídos nos sensores eatuadores, energia (stamina), percepção limitada do ambiente e restrições de comunicação.O mundo simulado se restringe a uma partida de futebol e seus componentes. Como tal,o objetivo de cada time é levar a bola até dentro do gol adversário marcando um ponto,enquanto evita que o adversário faça o mesmo. Ganha o time que tiver mais pontos nofinal. Esse conflito de objetivos cria um ambiente complexo onde 24 agentes (11 jogadorese 1 técnico de cada lado) competem e cooperam simultaneamente.

1.2.2.1 O campo e os objetos fixos

O campo da Simulação 2D tem as dimensões pitch_length X pitch_width, o quepor padrão na versão atual do servidor significa 105m x 68m, dentro das dimensões de umcampo oficial de futebol. Já as traves, uma vez que sem a dimensão da altura ficaria muitomais difícil fazer gols, ficam a 14.02m uma da outra (parâmetro goal_width), o dobro dadistância oficial. Isso mostra que nem sempre os parâmetros da simulação serão idênticos aodo futebol real, mas em geral, incluindo a física do ambiente, serão similares. As traves sãoobjetos circulares com 6 cm de raio e ficam nas posições 𝑥 = +− (pitch_length×0.5−6𝑐𝑚)e 𝑦 = +− (goal_width× 0.5 + 6𝑐𝑚). A Figura 5 mostra as flags e linhas do campo, que sãomuito importantes como referências para que cada agente possa determinar sua posiçãono campo, sua orientação e sua velocidade.

1.2.2.2 Objetos móveis

Entender o comportamento dos objetos é importante pois está estritamente relacio-nado a variação dos dados encontrados nos logs a cada ciclo. As estatísticas de alto nívelpodem ser entendidas como padrões de movimentação nos objetos do campo. Por contadisso, as equações que regem a movimentação em geral serão apresentadas nessa seção. Osmodelos aqui presentes se baseiam no excelente trabalho descritivo realizado em (BOER;KOK, 2002).


Figura 5 – As flags e linhas do campo simulado

Fonte: (CHEN et al., 2003)

Existem dois tipos de objetos móveis no ambiente da 2D, jogadores e bola. Re-sumidamente o movimento desses objetos são simulados do seguinte modo: durante apassagem do ciclo 𝑡 para o 𝑡+1, o vetor velocidade do objeto é acrescido do vetor aceleraçãoresultante dos comandos enviados pelos agentes, e dos vetores de ruído, compondo umanova velocidade a partir da qual a nova posição do objeto é calculada. Depois a aceleraçãoretorna a zero e a velocidade decai de modo a simular a perda de movimento do objeto. Omodelo detalhado obedece as seguintes equações:

(𝑢𝑡+1𝑥 , 𝑢𝑡+1

𝑦 ) = (𝑣𝑡𝑥, 𝑣𝑡

𝑦) + (𝑎𝑡𝑥, 𝑎𝑡

𝑦) + (𝑟1, 𝑟2) + (𝑤1, 𝑤2): nova velocidade (1.1)

(𝑝𝑡+1𝑥 , 𝑝𝑡+1

𝑦 ) = (𝑝𝑡𝑥, 𝑝𝑡

𝑦) + (𝑢𝑡+1𝑥 , 𝑢𝑡+1

𝑦 ): movimento (1.2)

(𝑣𝑡+1𝑥 , 𝑣𝑡+1

𝑦 ) = decay× (𝑢𝑡+1𝑥 , 𝑢𝑡+1

𝑦 ): velocidade final (1.3)

(𝑎𝑡+1𝑥 , 𝑎𝑡+1

𝑦 ) = (0, 0): aceleracao final (reiniciada) (1.4)


onde, (𝑢𝑡+1𝑥 , 𝑢𝑡+1

𝑦 ) é a velocidade resultante da interação das forças do ciclo 𝑡. Essasforças são a velocidade do objeto: (𝑣𝑡

𝑥, 𝑣𝑡𝑦), a aceleração resultante dos comandos enviados

pelos agentes: (𝑎𝑡𝑥, 𝑎𝑡

𝑦), o vetor de ruído do movimento do objeto: (𝑟1, 𝑟2) e o vetor de vento:(𝑤1, 𝑤2). O vetor (𝑎𝑡

𝑥, 𝑎𝑡𝑦) deriva do parâmetro Força passado para o comando dash (no caso

do objeto ser um jogador) ou kick (no caso de ser a bola), ou ainda do resultado de umtackle, caso em que depende do ângulo passado para o comando. A partir desses comandosé possível calcular a força efetiva 𝑓𝑒 que é utilizada para o cálculo da aceleração:

(𝑎𝑡𝑥, 𝑎𝑡

𝑦) = fe × power_rate × (cos (𝜃𝑡), sin (𝜃𝑡)): aceleracao (1.5)

onde 𝜃𝑡 é a direção do objeto no ciclo 𝑡 e power_rate pode ser dash_power_rate,kick_power_rate ou tackle_power_rate a depender da ação em questão. No caso do kick, atransformação de Força em 𝑓𝑒 se dá através da seguinte equação:

𝑓𝑒 = 𝐹𝑜𝑟𝑐𝑎×(︂

1− 0.25× 𝑑𝑖𝑓_𝑑𝑖𝑟

180∘ − 0.25× 𝑑𝑖𝑓_𝑑𝑖𝑠𝑡

𝑘𝑖𝑐𝑘𝑎𝑏𝑙𝑒_𝑚𝑎𝑟𝑔𝑖𝑛

)︂(1.6)

onde 𝐹𝑜𝑟𝑐𝑎 é valor de força enviado pelo agente como primeiro argumento docomando kick, 𝑑𝑖𝑓_𝑑𝑖𝑟 é o valor absoluto do ângulo entre a bola e a direção do corpo dojogador, 𝑑𝑖𝑓_𝑑𝑖𝑠𝑡 é a distância entre o jogador e bola, ou seja, a distância mínima entreas camadas mais externas do jogador e da bola, e kickable_margin é um parâmetro dosjogadores heterogêneos (mais na subseção 1.2.2.5) que determina o alcance da perna. Nocaso do tackle 𝑓𝑒 é dado por:

𝑓𝑒 = 𝑚𝑎𝑥_𝑡𝑎𝑐𝑘𝑙𝑒_𝑝𝑜𝑤𝑒𝑟 ×(︂

1− fabs(𝐴𝑛𝑔𝑙𝑒)𝜋 𝑟𝑎𝑑

)︂(1.7)

onde max_tackle_power é um parâmetro do servidor que regula a força do tackle efabs(Angle) é o módulo do ângulo passado no comando tackle. No caso do dash, 𝑓𝑒 é dadopor:

𝑓𝑒 = 𝐹𝑜𝑟𝑐𝑎× Effort (1.8)

onde 𝐹𝑜𝑟𝑐𝑎 é o valor de força enviado pelo agente como argumento do dash e Efforté um atributo dos jogadores que pode variar durante a partida (mais na subseção 1.2.2.5).A direção, no caso do jogador é dada pela direção de seu corpo, e no caso da bola pelafórmula:

𝜃𝑡𝑏𝑎𝑙𝑙 = 𝜃𝑡

𝑘𝑖𝑐𝑘𝑒𝑟 + Direction: direcao (1.9)


onde 𝜃𝑡𝑏𝑎𝑙𝑙 e 𝜃𝑡

𝑘𝑖𝑐𝑘𝑒𝑟 são respectivamente a direção da bola e do jogador que a chutou,e Direction é o segundo parâmetro do comando kick. A multiplicação por (cos (𝜃𝑡), sin (𝜃𝑡))transforma os valores em um vetor.

O vetor de ruído (𝑟1, 𝑟2) é inserido para simular o movimento impreciso ou ines-perado dos objetos no mundo real, por exemplo, desvios ocasionados por irregularidadesno campo. O vetor de ruído na Equação 1.1 contém dois números aleatórios 𝑟𝑖, obtidosa partir de uma distribuição uniforme sobre o intervalo [−𝑟𝑚𝑎𝑥, 𝑟𝑚𝑎𝑥]. 𝑟𝑚𝑎𝑥 depende davelocidade do objeto (acrescida da aceleração) e é calculado como segue:

𝑟𝑚𝑎𝑥 = rand× | (𝑣𝑡𝑥, 𝑣𝑡

𝑦) + (𝑎𝑡𝑥, 𝑎𝑡

𝑦) | : ruido (1.10)

sendo rand o erro no movimento dos objetos, representado por player_rand no casodo jogador e ball_rand no caso da bola. O vento, que aparece na Equação 1.1 como o vetor(𝑤1, 𝑤2), é uma forma de ruído natural que também pode ser inserido na Simulação 2D.Porém, como na versão atual do servidor o ruído do vento não está sendo inserido, ou seja,os parâmetros relacionados ao vento estão todos configurados para 0.0, seu funcionamentonão será explicado.

Com essas informações pode ser calculada a Equação 1.1, onde se obtém o novovetor de velocidade (𝑢𝑡+1

𝑥 , 𝑢𝑡+1𝑦 ). Esse vetor é então normalizado, no caso da bola pelo valor

de ball_speed_max e no caso dos jogadores pelo valor de player_speed_max.

Com este vetor é calculada a nova posição do objeto utilizando a Equação 1.2,onde (𝑝𝑡

𝑥, 𝑝𝑡𝑦) representa a posição do objeto no ciclo 𝑡. Após determinada a nova posição

do objeto, a velocidade (𝑢𝑡+1𝑥 , 𝑢𝑡+1

𝑦 ) decai de acordo com a Equação 1.3, onde o decayrepresenta a taxa em que a velocidade é reduzida, podendo ser player_decay para osjogadores ou ball_decay para a bola.

A velocidade e posição do jogador no ciclo seguinte, respectivamente (𝑣𝑡+1𝑥 , 𝑣𝑡+1

𝑦 ) e(𝑝𝑡+1

𝑥 , 𝑝𝑡+1𝑦 ), estão obtidas. Por fim, a aceleração do ciclo seguinte (𝑎𝑡+1

𝑥 , 𝑎𝑡+1𝑦 ) é determinada

como nula de acordo com a Equação 1.4. A Tabela 2 mostra os parâmetros do servidorque são relevantes para o modelo de movimento.

Se no final do ciclo dois objetos estiverem sobrepostos, i.e. tiverem colidido, eles sãomovidos para trás na direção que vieram até encontrar uma área livre, e suas velocidadessão multiplicadas por -0.1, exceto pela colisão da bola com a trave que obedece a umadinâmica elástica. É importante notar que com este modelo objetos podem passar “através”dos outros desde que não estejam sobrepostos no fim do ciclo. Isso é mais comum ocorrercom a bola devido a sua menor área.


Tabela 2 – Parâmetros do servidor relacionados ao modelo de movimento e os seus valorespadrões

Parâmetro Valor Parâmetro Valorball_accel_max 2,7 player_accel_max 1,0

ball_decay 0,94 player_decay 0,4ball_rand 0,05 player_rand 0,1ball_size 0,085 player_size 0,3

ball_speed_max 3,0 player_speed_max 1,05ball_weight 0,2 player_weight 60,0

dash_power_rate 0,006 tackle_power_rate 0,027kick_power_rate 0,027 wind_dir 0,0max_dash_power 100 wind_force 0,0max_tackle_power 100 wind_rand 0,0

max_power 100

Fonte: Adaptado de (BOER; KOK, 2002)

1.2.2.3 Sensores

Como esse trabalho lida com o comportamento externo observado nos agentes, enão com seus estados internos, as percepções dos agentes tem um papel menos importantee serão analisadas apenas superficialmente. O agente possui 3 sensores:

• Auditivo ou aural: detecta as mensagens enviadas pelo juiz, pelos companheiros deequipe, pelo técnico e pelos oponentes. A comunicação entre os agentes é regulada poruma série de restrições, como por exemplo, o “limite do alcance da voz” (atualmente50m);

• Visual: obtém informações visuais (como distância e direção) dos objetos que estão nocampo de visão do agente. As informações são sempre em relação ao próprio agente,nunca absolutas. Uma série de ruídos e incertezas são adicionadas nas mensagensvisuais, tornando a coleta de informações um desafio a parte;

• Corpóreo: detecta o estado do agente, como sua energia, velocidade e posição dopescoço.

Com as informações providas por esses diferentes sensores cada agente cria umapercepção do mundo e decide as ações que vai executar a cada ciclo. Uma característicacomplexa da simulação é que sentir e atuar são tarefas assíncronas. Enquanto por padrãoas informações visuais são enviadas para o agente em intervalos de 150ms, ele pode realizarações a cada 100ms (tempo do ciclo). De forma a maximizar seu desempenho e nãoperder nenhuma oportunidade de agir, passa a ser desejável que ele seja capaz de atuarbaseando-se apenas em informações dos outros sensores e de ciclos anteriores. Essa tarefa


é um desafio pois ele precisa realizar predições, fusão de informações e tomar uma decisãocomplexa, tudo isso em tempo real.

1.2.2.4 Atuadores

Os atuadores são o conjunto de dispositivos que um agente pode utilizar parainfluenciar o ambiente onde está inserido. No caso da Simulação 2D, como não há um robôreal sendo simulado, faz mais sentido falar em ações que o agente pode realizar. Assimcomo nos sensores, as ações estão sujeitas a diversos ruídos e incertezas, o que torna oambiente estocástico. O nível de abstração que foi utilizado na definição das ações na2D é um ponto importante do projeto do servidor e mostra como a inclusão do nívelestratégico foi uma decisão de projeto para a liga. Em (NODA et al., 1998), os autores doSoccer Server deixam claro que houve a intenção de encontrar um ponto de equilíbrio quepermitisse aos desenvolvedores focarem os seus esforços no aspecto estratégico do jogo, masque mantivesse o desafio de controlar os robôs, evitando que se perdesse a característicade tempo real presente no futebol:

The level of abstraction chosen for representing these messagens wasan important consideration during design of Soccer Server. One possi-bility was a low-level, physical description, for example allowing powervalues for drive motors to be specified. However, it was felt that sucha representation would concentrate users’ attention too much on theactual control of a players’ actions, relegating true investigation of themulti-agent nature of team-play to the level of a secondary objective. [...]On the other hand, a more abstract representation, maybe using tacticalcommands such as pass-ball-to and block-shoot-course, would produce agame in which the real-world nature of soccer becomes obscured. Thus,our representation is a compromise, using basic control commands suchas turn, dash, and kick.6

Existem dois tipos de ações: primárias e concorrentes. Em cada ciclo de jogoum agente pode realizar apenas uma ação do tipo primária, enquanto diversas açõesconcorrentes podem ser executadas simultaneamente. Como organizado em (ABREU,2010), as ações primárias podem estar relacionadas a movimento (dash, turn e move) ouinteração com a bola (kick, tackle e catch). Já as ações concorrentes se relacionam a controleda percepção (turn_neck, attentionto e change_view) ou comunicação (say e pointto).

Os efeitos das ações primárias são:6 “O nível de abstração escolhido para representar essas mensagens foi uma consideração importante

durante o projeto do Soccer Server. Uma possibilidade era uma descrição de baixo nível, física, porexemplo permitindo que valores de força para os motores fossem específicados. Entretanto, sentiu-seque tal representação iria concentrar demais a atenção dos usuários no controle das ações dos jogadores,relegando uma investigação verdadeira da natureza multiagente do trabalho em equipe para o nível deum objetivo secundário. [...] Por outro lado, uma representação mais abstrata, talvez usando comandostáticos como passe-bola-para e bloqueie-chute, iria produzir um jogo em que a natureza de tempo-realdo futebol se tornaria obscura. Então, nossa representação é um balanço, usando comandos de controlebásicos como turn, dash, e kick.” (Tradução do autor)


• Dash: acelera o jogador com uma certa força em qualquer direção. Realizar um dashconsome energia do jogador, impedindo que ele corra indefinidamente e tenha quegerenciar muito bem esse recurso. A energia é recuperada lentamente durante cadaciclo, mas o jogador pode acabar fatigado, ficando limitado a usar apenas sua energiaextra (parâmetro extra_stamina, ver mais na subseção 1.2.2.5). O jogador tambémestá limitado a uma velocidade máxima (dada pelo parâmetro player_speed_max);

• Turn: altera a direção do corpo do jogador. A velocidade do jogador e a sua inérciaexercem influência sobre sua capacidade de girar, tornando a ação mais complexa.É importante notar que como turn e dash são ambas ações primárias, o agente nãopode acelerar e rotacionar o corpo no mesmo ciclo;

• Move: permite aos jogadores se moverem diretamente para qualquer ponto do camposempre que ocorre um gol, ou antes do início de cada tempo. Serve ao propósito dereposicionar os times sem a necessidade de deslocamento. É permitido ao goleiroutilizar o move até 2 vezes para dentro de sua grande área após agarrar a bola. Essaregra serve para facilitar a reposição de bola, uma vez que as limitações do ambientenão permitem que ele jogue a bola pelo alto, opção comum ao goleiro;

• Kick: permite ao jogador chutar a bola com uma certa força e direção, influenciandoa sua trajetória. Para realizar um chute com sucesso a bola precisa estar ao seualcance (o centro do jogador e o centro da bola devem estar a uma distância máximaigual ao raio do jogador + raio da bola + parâmetro kickable_margin). A posiçãoda bola em relação ao jogador influencia a eficiência do chute. Com os parâmetrosatuais do servidor o chute mais forte possível é capaz de fazer a bola percorrer cercade 45 metros;

• Tackle: realiza o movimento conhecido como “carrinho” no futebol. Para ter chancede acertar, a bola precisa estar num retângulo relativo a frente do jogador definidopor tackle_width e tackle_dist, atualmente 1.25m e 2.0m respectivamente (Figura 6).Uma das vantagens do tackle é permitir ao jogador alcançar bolas mais distantes,que não seriam alcançáveis utilizando um kick. Desde a versão 14 do servidor otackle pode acabar resultando em falta, passível de punição com cartão amarelo ouvermelho. O cartão vermelho resulta na desconexão do agente punido da partida. ASimulação 2D é tão rica em detalhes, que um agente pode até mesmo tentar realizara falta propositalmente como uma opção para finalizar uma jogada, porém, corremaior risco de ser punido;

• Catch: permite agarrar a bola com a mão. O único jogador que pode realizar essecomando é o goleiro. Para isso a bola precisa estar em jogo e dentro de uma árearetangular na direção em que foi realizado o catch, de comprimento catchable_area_le largura catchable_area_w, atualmente 1.2m e 1.0m respectivamente (Figura 7).


Jogadores heterogêneos (subseção 1.2.2.5) podem ter o valor de catchable_area_lacrescido por um delta dado por catchable_area_l× (catchable_area_l_stretch−1.0).

Figura 6 – Jogador 11 (azul) tem a bola próxima ao limite da área (vermelho) em quepode executar um tackle

Fonte: Elaborado pelo autor

Figura 7 – Área de um comando catch com 45 graus

Fonte: Manual do servidor (CHEN et al., 2003)

Os efeitos das ações concorrentes são:

• Turn neck: rotaciona o pescoço do agente mudando seu campo de visão e permitindoa ele flexibilidade sobre a captação de informações visuais. Como este comando podeser realizado simultaneamente a um turn, é importante existir sincronismo entreo corpo e o pescoço do agente para que ele possa olhar para o local desejado. Opescoço pode ser movido 90 graus para cada lado em relação ao corpo do agente;

• Change view: altera o foco visual do agente, permitindo controle sobre a abertura,qualidade e frequência da captação de informações visuais;


• Attention to: altera o foco auditivo do agente, permitindo que ele ouça melhoralgum companheiro de equipe específico;

• Say: permite se comunicar através da voz com os companheiros mais próximos(limite de 50m);

• Point to: faz o agente apontar durante alguns ciclos para uma determinada posiçãodo campo, simulando comunicação através dos braços.

Em (RUSSEL; NORVIG, 2003) aparece o conceito de capacidade de atuação(effectoric capability), que consiste no mapeamento do conjunto de ações possíveis de seremexecutadas por um agente. A Tabela 3 contém a capacidade de atuação dos agentes da 2Dpara as ações primárias e a Tabela 4 para as ações concorrentes.

Tabela 3 – Capacidade de atuação - ações primárias

Comando Sintaxe ArgumentosDash (dash double double) Força [-100.0, 100.0] e Direção [-180.0, 180.0]Turn (turn double) Momentum [-180.0, 180.0]Move (move double double) Eixos do campo: X [-52.5, 52.5] e Y [-34.0, 34.0]Kick (kick double double) Força [-100.0, 100.0] e Direção [-180.0, 180.0]

Tackle (tackle double {boolean}) Direção [-180.0, 180.0] e Falta {true | false}Catch (catch double) Direção [-180.0, 180.0]


Tabela 4 – Capacidade de atuação - ações concorrentes

Comando Sintaxe ArgumentosTurn neck (turn_neck double) Momentum [-180.0, 180.0]

Change view (change_view string string) Largura [narrow|normal|wide] e Qualidade [high|low]Attention to (attentionto string integer) Time [opp | our | l | r | left | right] e Jogador [0, 11]

Say (say string) Mensagem contendo [0..9a..zA..Z().+-*/? <>]Point to (pointto double double) Distância [+∞] e Direção [-180.0, 180.0]


Esta subseção detalhou as ações enviadas pelos agentes para o servidor pois elassão parte do comportamento externo observável dos jogadores, sendo então um recursoimportante para a extração das estatísticas de futebol desejadas. Para realizar as açõescomplexas que fazem parte do jogo, um agente deve combinar diferentes ações de baixonível primárias e concorrentes. Dessa forma, um dos desafios do projeto se deve ao fato deque um mesmo comando básico como um kick pode representar diferentes ações de altonível, como um passe, um chute a gol, um domínio ou condução de bola, sendo necessárioum mecanismo de classificação robusto para lidar com essas ambiguidades.

Os comandos de kick, tackle e catch juntamente com as colisões bola-jogador ebola-trave são os eventos de baixo nível mais importantes para a detecção de chutes agol pois resumem as situações em que a aceleração da bola é modificada por um eventoexterno (além do seu ruído natural no movimento explicado na Equação 1.10).


1.2.2.5 Jogadores heterogêneos

No começo de cada partida é criado aleatoriamente um conjunto de tipos de joga-dores (atualmente 18, regido pelo parâmetro player_types) com características diferentes,como velocidade máxima e capacidade de drible. Antes da versão 7 do servidor todos os jo-gadores em campo possuiam as mesmas características. A introdução dessa funcionalidadeabriu espaço na 2D para pesquisa sobre alocação dinâmica de recursos (ABREU, 2010).

As características de cada tipo são balanceadas a partir de alguns trade-offspreestabelecidos, como jogadores mais velozes cansarem mais rápido, ou os que chutammais forte terem menos precisão no chute. Para manter o equilíbrio da partida cada equipedispõe do mesmo conjunto para escalar 11 titulares e 7 reservas de acordo com suasestratégias. Durante o jogo cada time pode ainda realizar até 3 substituições (parâmetrosubs_max).

É importante considerar os jogadores heterogêneos na fase de Preparação dosDados do projeto pois uma mesma configuração dos objetos no campo pode ter significadosdiferentes a depender dos jogadores envolvidos na cena. Uma bola que esteja a 0.8m deum jogador, por exemplo, pode estar ou não sobre a influência dele a depender do seuatributo kickable_margin, que varia de 0.7 a 0.9 metros. A Tabela 5 lista o valor padrão decada atributo dos jogadores e as suas possíveis variações 7.

Tabela 5 – Parâmetros relacionados aos jogadores heterogêneos

Parâmetro Padrão Variação Descrição da varianteplayer_speed_max 1.0 [1.0, 1.2] Jogador com velocidade máxima maiorstamina_inc_max 45.0 [25.0, 45.0] Jogador que recupera menos energia por cicloplayer_decay 0.4 [0.4, 0.6] Jogador cuja velocidade decresce mais devagarinertia_moment 5.0 [5.0, 10.0] Jogador com dificuldade de girar em movimentodash_power_rate 0.006 [0.006, 0.008] Jogador com maior aceleraçãoplayer_size 0.3 [0.1, 0.3] Jogador com corpo menorkickable_margin 0.7 [0.7, 0.9] Jogador com maior alcance da bolakick_rand 0.0 [0.0, 0.1] Jogador com menos precisão no chuteextra_stamina 0.0 [0.0, 100.0] Jogador com energia extraeffort_max 1.0 [0.8, 1.0] Jogador com menor eficiência máxima no movimentoeffort_min 0.6 [0.6, 0.8] Jogador com maior eficiência mínima no movimentokick_power_rate 0.027 [0.027, 0.027] Força do chute. Variação não implementada.foul_detect_probability 0.5 [0.5, 0.5] Chance de fazer falta. Variação não implementadacatchable_area_l 1.2 [1.2, 1.56] Goleiro com maior alcance com a mão

Fonte: Adaptado de (ABREU, 2010)

1.2.2.6 Técnico online e offline

Além dos 11 jogadores cada time também possui 1 agente técnico. Ele é um agentecom algumas habilidades especiais, sendo a principal delas receber informações visuaissem ruído de todo o campo. Ele não possui uma representação física na simulação e atuatrocando mensagens com o servidor e se comunicando com sua equipe. Existem 2 tipos deagente técnico: online e offline.7 Adaptada de (ABREU, 2010) e atualizada a partir do código da versão 15.2.2 do Soccer Server


O técnico online é o responsável por selecionar os jogadores heterogêneos e realizara escalação do time no começo do jogo, realizar substituições durante a partida e o maisimportante, dadas as informações privilegiadas que recebe e a menor pressão por atuar emtempo real, ser o responsável por definir as estratégias da equipe. O técnico online pode,por exemplo, tentar identificar a estratégia do adversário e alterar o modo de jogar de seutime. Para se comunicar com sua equipe o técnico deve utilizar um protocolo conhecidocomo CLang, que impõe restrições sobre as informações que ele pode compartilhar (docontrário perderia o sentido o modelo de incertezas associado aos sensores dos agentes).

Já o técnico offline, além de todas as habilidades do técnico online, pode tambémcontrolar diretamente alguns aspectos da simulação. Entre elas, é permitido que ele mudeo playmode do jogo, recupere a energia dos jogadores e até mesmo altere as posições detodos os objetos móveis no campo. Por conta dessas habilidades, o técnico offline nãopode ser utilizado em partidas oficiais, tendo o propósito de ser utilizado durante a fasede desenvolvimento do time. Exemplos de uso comum do técnico offline incluem a criaçãode cenários de teste específicos ou depuração do sistema.

Por receber informação completa da partida enquanto o jogo permanece em exe-cução, o agente técnico pode ser fundamental para uma posterior aplicação em temporeal dos resultados alcançados nesse trabalho. Estatísticas de alto nível em tempo realpermitiriam uma tomada de decisões estratégicas mais rápida, por perceber que o timenão está bem antes mesmo de tomar um gol, e mais robusta, por compreender nuances doque está acontecendo na partida e poder corrigir detalhes do comportamento da equipe.

1.2.2.7 Juízes e estados do jogo

Como dito na subseção 1.2.1.1 o Soccer Server possui um módulo chamado Refereeque funciona como o juiz da partida. Ele é responsável por garantir que as regras do jogosejam seguidas, gerenciando as situações automaticamente, por exemplo, garantindo que adistância mínima para a bola seja respeitada pelos jogadores adversários em faltas. Paralidar com algumas situações mais complexas, como falta de fairplay ou obstrução de algumjogador, as partidas oficiais também contam com um juiz humano (nomeado pelo Comitêde Organização responsável) que pode realizar interverções através da interface do SoccerMonitor (subseção 1.2.1.2).

Ao longo dos anos, porém, o juiz automático evoluiu bastante, tornando extrema-mente rara a necessidade de qualquer tipo de participação do juiz humano, para além deexecutar os scripts das partidas. O juiz automático controla os estados do jogo, conhecidoscomo playmodes, de modo que todos os agentes saibam como se comportar corretamentede acordo com a situação, como em faltas, meio de campo e laterais. A maior parte dojogo, no entanto, se passa no playmode play_on, que significa que a bola está rolandonormalmente. O juiz automático se comunica com os agentes através do broadcast de


mensagens sobre a partida.

A Tabela 6 mostra as mensagens que podem ser enviadas pelo juíz (incluindoos playmodes). Toda mudança de playmode é registrada nos logs. Eles influenciam naextração de estatísticas de chute a gol pois diversos chutes terminam com uma mudançade playmode para o estado correspondente, por exemplo, a escanteio, tiro de meta ouindicação de que o goleiro agarrou a bola.

Tabela 6 – Mensagens enviadas pelo juiz. SIDE pode ser l ou r de acordo com time sendoreferenciado (de left ou right). OSIDE se refere ao time oposto. 𝑇 é a quantidadede ciclos até o próximo playmode ser anunciado.

Mensagem T Próximo playmode Descriçãobefore_kick_off 0 kick_off_SIDE No início de cada tempoplay_on - Bola rolando normalmentetime_over - Depois da partidakick_off_SIDE - Anuncia o início do jogokick_in_SIDE - play_on Lateral. O playmode muda após a bola

ser chutadafree_kick_SIDE - play_on Falta ou goleiro agarra a bola. O play-

mode muda após a bola ser chutadafree_kick_fault_SIDE 30 free_kick_OSIDE Infração durante free_kick_SIDEcorner_kick_SIDE - play_on Escanteio. O playmode muda após a bola

ser chutadagoal_kick_SIDE - play_on Tiro de meta. O playmode muda quando

a bola deixa a grande área.drop_ball 0 play_on Ocorre quando a bola não é colocada em

jogo depois de drop_ball_time cycles.offside_SIDE 30 free_kick_OSIDE Falta de impedimentogoal_SIDE_N 50 kick_off_OSIDE Anuncia o enésimo gol para SIDEfoul_charge_SIDE 30 free_kick_OSIDE ou indi-

rect_free_kick_OSIDEFalta cometida com tackle por SIDE

yellow_card_SIDE_P - Cartão amarelo para jogador P do timeSIDE

red_card_SIDE_P - Cartão vermelho para jogador P do timeSIDE

back_pass_SIDE 30 free_kick_OSIDE Recuo de bola pego de mão pelo goleirode SIDE

time_up_without_a_team 0 time_over Se oponente não conecta até o fim do se-gundo tempo

time_up 0 time_over Fim da partida (quando não há empateou prorrogação)

half_time 0 before_kick_off Fim do primeiro tempotime_extended 0 before_kick_off Fim do segundo tempo (quando há em-

pate e há prorrogação)

Fonte: Adaptado de (BOER; KOK, 2002)

1.2.3 Os logs das partidas

A cada partida o Soccer Server gera 2 arquivos de log em texto: o RCG e o RCL.A maior parte das informações ficam registradas no RCG, que sozinho pode ser utilizadopara reproduzir uma partida. Já o RCL registra todas as mensagens trocadas via servidor,incluindo as ações básicas enviadas pelos agentes, mensagens dos técnicos, e até mesmoas mensagens enviadas pelo juíz. Como o ambiente não é determinístico, é impossívelreproduzir um jogo a partir apenas das mensagens no RCL.


A Figura 8 mostra os trechos de arquivos RCG e RCL correspondentes ao mesmociclo de uma partida. Por uma restrição de escopo apenas o arquivo RCG foi utilizadocomo fonte de dados para esse projeto. Foi a partir dos dados de baixo nível contidosnesses arquivos que se extraíram estatísticas de chute a gol.

Figura 8 – Exemplo de conteúdo dos arquivos RCG e RCL para o ciclo 7 da simulaçãoentre os times WrightEagle e HELIOS2013 valendo pela final da Robocup 2013

(a) Trecho de log RCG

(b) Trecho de log RCL


Dentro de um arquivo RCG encontram-se as seguintes mensagens:

• Header: informa a versão do log. Aparece uma vez no começo do RCG;

• server_param: guarda todos os parâmetros relativos a partida utilizados na simulação.Aparece uma vez logo após o Header;

• player_param: guarda todos os parâmetros relativos aos jogadores heterogêneos.Aparece uma vez logo após server_param;


• player_type: mostra todos os tipos heterogêneos gerados com os valores de seusatributos. Aparece uma vez para cada tipo heterogêneo (atualmente 18, comoobservado na subseção 1.2.2.5);

• MSG: relativo a atributos extras como o logotipo dos times, quando existente, e umamensagem final com timestamp e o resultado da partida;

• playmode: informa sempre que há uma mudança no estado do jogo;

• team: informa o estado do placar. Aparece uma vez no início do log e sempre queacontece um gol;

• show: principal mensagem do log, aparece uma vez para cada ciclo. Contém todas asinformações relevantes sobre a bola e os jogadores.

A mensagem de show é a principal fonte de dados para realizar o projeto. Elacontém:

1. (show <time> .. ): cabeçalho e o ciclo de jogo;

2. ((b) x y vx vy): registro sobre a bola. Contém a flag “(b)”, a posição (x, y) e velocidade(vx, vy);

3. ((side unum) type state x y vx vy body neck [pointx pointy] (v Q W) (s sta eff rec[cap])[(f side unum)] (c c1 c2 c3 c4 c5 c6 c7 c8 c9 c10 c11)) : registro sobre um jogador.Onde:

• (side unum): o time e o número do jogador;

• type state: o tipo do heterogêneo e um valor em hexadecimal que representa oestado do jogador (caído, cartão amarelo, chutou etc);

• x y vx vy: posição e velocidade do jogador;

• body neck: direção do corpo e do pescoço;

• [pointx pointy]: posição para qual o jogador está apontando (opcional);

• (v Q W): registro sobre informação visual. Flag “v”, a qualidade de captação ea abertura da visão;

• (s sta eff rec [cap]): registro sobre a energia do agente. Flag “s”, energia atual,atributo effort, recuperação de energia e capacidade de energia total (opcional);

• [(f side unum)]: registro sobre o foco do agente (opcional). Time e jogador noqual sua atenção está focada;


• (c c1 c2 c3 c4 c5 c6 c7 c8 c9 c10 c11): contador de ações básicas. Flag “c” e ototal de comandos utilizados, na seguinte ordem: kick, dash, turn, catch, move,turn_neck, change_view, say, tackle, pointto e attentionto.

O RCL é um arquivo mais simples, possuindo apenas um tipo de registro. Elecontém o ciclo da partida (incluindo contador de ciclos de bola parada), o nome do time eo jogador a que o registro se refere, e as mensagens enviadas a cada ciclo. No caso dosjogadores as mensagens são compostas pelos padrões que aparecem nas Tabelas 3 e 4, e nocaso do técnico elas obedecem ao protocolo CLang (mencionado na subseção 1.2.2.6). Osregistros relativos ao árbitro são principalmente relativos a mudanças de playmodes. OsRCLs não foram utilizados no projeto pois agregariam pouco a um alto custo de tratá-los.

Não foi encontrada uma documentação oficial relacionada ao formato dos logs. Asinformações contidas nesta seção foram obtidas a partir da análise do código-fonte daversão 15.2.2 do servidor.

1.3 Testes e experimentos na Simulação 2DComo visto em (GATTI; STAA, 2006), os agentes dentro de um sistema multiagentes

costumam atuar de forma concorrente, assíncrona e descentralizada. Além disso, são nãodeterminísticos, uma vez que não é possível determinar à priori quais interações ocorrerãodurante uma execução do sistema, tornando sistemas multiagentes muito complexos deserem testados e depurados. Essa é exatamente a realidade encontrada na Simulação 2D.Essa seção foca nas abordagens mais utilizadas para testar os times de futebol simulado2D e explica como esse trabalho pode aprimorar o ambiente de testes associado.

Um dos métodos mais utilizados é assistir aos replays de partidas no LogPlayer eobservar o comportamento do time. Essa atividade pode ser auxiliada por um arquivo delog ou debug gerado pelos processos dos agentes durante a execução da simulação, para quedepois se busque manualmente os lances importantes para observar algum comportamentodesejado.

Outra forma muito comum é rodar uma bateria de testes contra equipes selecionadase depois assistir a todos os jogos contabilizando manualmente algum comportamentoparticular que se tenha interesse, como por exemplo, percentual de passes corretos. Porém,essas abordagens são muito custosas em tempo, inviabilizando utilizá-las em escala. Se fornecessário rodar os testes novamente todo o trabalho manual precisa ser refeito.

A escala é uma questão essencial quando se trata de testes dos sistemas multiagentesnum ambiente de futebol. Como no futebol real, o resultado de uma única partida poderepresentar muito pouco sobre o desempenho de uma equipe, e apenas através de repetiçõesda simulação de uma partida entre as duas mesmas equipes, sem alterações no software


dos agentes, pode-se esperar conseguir um resultado sólido estatisticamente. Além dissoé necessário rodar simulações contra diferentes tipos de equipes, com diferentes forças efraquezas, para garantir que a estratégia desenvolvida não é por demais enviesada, ouverificar se a equipe sabe se adaptar suficientemente bem, o que costuma denotar ummaior grau de inteligência. Essas demandas podem gerar uma séria restrição de tempopara analisar os testes.

Supondo um setup de teste em que se deseja contabilizar o total de passes realizadospela equipe antes e depois de uma alteração no código ou nos parâmetros que afete ocomportamento dos agentes, para que o teste seja robusto, são selecionadas pelo menos 5equipes com características distintas, todas participantes do último mundial. Para cadaequipe decide-se rodar ao menos 10 simulações para que o resultado tenha relevânciaestatística. Isso gera um total de 50 simulações para cada versão a ser testada. Comcada simulação durando cerca de 10 minutos (6.000 ciclos de 100 milissegundos), teremos1.000 minutos para serem analisados por conta de um único teste, totalizando mais de16 horas de trabalho (isso considerando que não se volte para analisar algum lance commais cuidado, o que não é a realidade). Ainda mais crítico, num processo robusto, testessimilares deveriam ser exigidos sempre antes de fechar uma versão do sistema, para evitarque uma alteração de código indesejável seja inserida na equipe.

A partir da síntese dos TDPs do mundial de 2013 (disponíveis em (ROBOCUP,2013d) e (ROBOCUP, 2013e)) nota-se que o setup mais comum é de fato rodar diversaspartidas contra diferentes times, mas analisar apenas os gols feitos e tomados, pois essaé uma medida fácil de ser obtida. Apenas gols, porém, são uma medida muito indiretapara alguns testes, podendo levar a falsas interpretações. É possível por exemplo, que aodesenvolver um novo algoritmo para cruzamentos que é pior do que o anterior, uma equipepasse a fazer mais gols pois isso favoreceu um tipo de interceptação de bola em que ela émuito boa. Ou ainda, se uma equipe mantiver o mesmo saldo de gols contra duas equipesdistintas isso não significa que ela esteja tendo as mesmas dificuldades contra ambas.

As imprecisões associadas a medir o desempenho das equipes apenas através degols ocasionaram uma discussão durante a Robocup de 1998, relatada na seção 1.2, ondese concluiu que medir desempenho em si é um problema de pesquisa relevante e que não seresolve apenas medindo saldo de gols. Essa questão permanece em aberto até hoje. Assim, oque se espera extraindo conhecimento dos logs é criar uma visão mais apurada das métricasque denotam o desempenho das equipes, abrindo caminho para tornar as pesquisas maisprecisas e menos subjetivas, tornando mais fácil descobrir onde os verdadeiros problemasou soluções residem.

Uma abordagem alternativa utilizada por algumas equipes para fazer testes maismodulares e análises que vão além dos gols feitos, é realizar experimentos sobre cenáriosespecíficos de jogo. A ideia aqui é criar uma situação que se deseja testar, como por exemplo


um lance de jogada ensaiada, e repetir exaustivamente apenas essa situação, contabilizandoa taxa de sucesso. Isso é possível utilizando a funcionalidade de reposicionamento dotécnico offline, apresentado na subseção 1.2.2.6.

Em (ZHANG et al., 2013), o WrightEagle, uma das principais equipes da Simulação2D, 3 vezes campeã do mundo, fala sobre a dificuldade em realizar testes na 2D e sobreuma ferramenta lançada por eles, chamada Trainer, que serve justamente ao propósitode facilitar a criação desses cenários e a execução de testes modularizados. Ela funcionarecriando um cenário de um jogo real a partir de um arquivo de log RCG e o número dociclo que se pretende reproduzir. Uma ferramenta similar, chamada LabManager, tambémhavia sido desenvolvida em 2010 no projeto do Bahia2D8 (SILVA et al., 2010; SILVA etal., 2011).

Esse tipo de ferramenta é um acréscimo muito importante para a liga, principalmentepara testar situações que ocorrem com pouca frequência em jogos normais, mas existemalgumas ressalvas importantes feitas pelos próprios autores. Como dito anteriormente a 2Dé um ambiente que simula diversas complexidades do mundo real, incluindo a percepçãolimitada que cada agente tem do ambiente. Ao longo de uma partida normal, um agentearmazena diversas informações em memória, como o posicionamento dos objetos no campo,inclusive previsões sobre aqueles que estão momentaneamente fora do seu campo visual,criando uma expectativa sobre o comportamento do mundo.

Ao reproduzir um ciclo de jogo repentinamente, mexendo na posição dos agentesde um modo que eles não esperam, ainda que esses agentes permaneçam fixados em suanova posição por alguns ciclos para permitir que eles atualizem seu modelo de mundo,como fazem o Trainer e o LabManager, o comportamento normal do time é afetado e oestado interno do agente pode perder parte de sua coerência. Com isso o desempenho dasequipes acabarão variando numa medida não conhecida, em geral levando a uma quedanos desempenhos dos times de um modo não uniforme, com alguns agentes, a dependerde sua implementação, sendo mais prejudicados que outros. Isso torna os resultados deexperimentos utilizando essa abordagem menos confiáveis. A complexidade inerente à 2Dtorna difícil que o viés dessa abordagem seja superado.

Dito isso, decorre-se o fato de que atualmente o método mais confiável de realizarum teste integrado do sistema é rodando partidas completas sem intervenção, ainda que sedeseje testar apenas um módulo. Além disso, esse tipo de teste integrado é fundamental paraverificar os impactos que uma mudança, por mais pontual que pareça, causa sobre outrascaracterísticas do time. Dada a complexidade do ambiente, por mais que os componentes deum agente sejam testados unitariamente, o funcionamento do sistema em conjunto, aindamais num contexto competitivo que envolve outro sistema multiagente independente, torna-8 Desenvolvido pelo próprio autor enquanto foi bolsista no Núcleo de Arquitetura de Computadores e

Sistemas Operacionais (ACSO), grupo de pesquisa da Universidade do Estado da Bahia (UNEB)


se extremamente difícil de prever, sendo comum surgirem comportamentos inesperados.

Esses aspectos reforçam os benefícios da solução proposta neste trabalho. Ao serpossível criar automaticamente uma camada de visualização em cima dos logs, torna-se factível realizar um teste integrado do tipo caixa-preta (focado no comportamentoexterno do sistema) que verifica se o conjunto funciona como esperado. A abordagemdas estatísticas de futebol ainda possuem a vantagem de servirem tanto para testar odesempenho do sistema como um todo, quanto para dar respostas sobre o desempenho deagentes individualmente, além de poder ser utilizada por todos os times pois se baseiaem métricas de desempenho adotadas amplamente no futebol. No fim das contas jogarfutebol bem é o objetivo de todos os sistemas nesse contexto.

1.4 Outras ferramentas e trabalhos relacionadosAo longo dos anos de simulação 2D surgiram outras ferramentas de análise de logs

além do LogPlayer, como o TeamAssistant2003 (SHAHRI, 2013) (Figura 9), o LogAlyzer(BEZEK, 2013) (Figura 10) e o SoccerScope2. Essas ferramentas estendem algumasfuncionalidades do LogPLayer, como permitir depurar o modelo de mundo dos agentes eaté mesmo contabilizar algumas situações como passes básicos. Entretanto nenhuma delas,como mostra (ABREU, 2010)9, extrai estatísticas de alto nível. Outro problema é que amaior parte das ferramentas não oficiais acabaram deixando de receber manutenção e setornaram obsoletas, perdendo compatibilidade com as versões mais novas do servidor.

Figura 9 – Interface do TeamAssistant2003

Fonte: (SHAHRI, 2013)

9 As citações sobre as ferramentas possuem data posterior pois são citações dos sites dos projetos


Figura 10 – Interface do LogAlyzer

Fonte: (BEZEK, 2013)

A Robocup pode ganhar bastante com o amadurecimento das ferramentas deanálise de desempenho para futebol de robôs em suas ligas, uma vez que análises manuaisde muitos logs a cada teste não são factíveis (seção 1.3). Em (STONE; AUGUST, 2013)encontramos uma ampla coleção dos artigos já publicados que se relacionam às ligassimuladas da Robocup. Nota-se que não são raros trabalhos que precisem detectar algumaação de alto nível, como passe, de modo a poder realizar alguns experimentos, comovemos em (RILEY; VELOSO, 2000), (TANAKA et al., 1998) e (TAKAHASHI, 2000).Mas esses trabalhos propõem soluções heurísticas simplificadas para essa detecção e nãose preocupam em avaliar a qualidade das heurísticas, dado que possuem outro enfoque.

O primeiro trabalho a realizar a detecção de estatísticas de alto nível no ambiente da2D e avaliar a qualidade dessa detecção é apresentado em (ABREU, 2010). Sua abordagemtambém utiliza heurísticas (criadas a partir de dados que podem ser encontrados no RCG)e teve como base para comparação avaliações feitas manualmente por uma equipe deespecialistas sobre 12 partidas. Entre as métricas avaliadas estão passes corretos e errados,chutes no gol, chutes interceptados, chutes pra fora, gols e impedimentos. A verificação dodesempenho das heurísticas foi feita utilizando True Positive Rate (também chamada derecall). Como reportado no artigo (ABREU et al., 2011), exceto para os 3 tipos de chutesa gol que tiveram um recall médio ponderado de 76,33% (ponderado pelo número de casosobservados para cada tipo de chute), todas as métricas foram detectadas com um recallacima de 92% 10.10 O autor cita accuracy nas conclusões, talvez em sentido mais abrangente, mas pelas tabelas apresen-


Os 3 tipos de chute são definidos por Abreu et al. (2011) como segue:

• Shot on target: quando jogador chuta a bola na direção do gol com força suficientepara cruzar a linha de fundo entre as traves (com uma tolerância de 0.5m para cadalado);

• Shot: quando a bola chutada não tem a direção geral do gol, mas ainda cruza a linhade fundo dentro do limite da área de penâlti;

• Intercepted shot: quando um oponente intercepta uma bola, com todas as condiçõespara ser Shot on target ou Shot, depois do primeiro jogador ter chutado.

A Tabela 7 apresenta os dados brutos de (ABREU et al., 2011) para os 3 tiposde chute nas 12 partidas avaliadas: “Observados” são os lances daquele tipo identificadosna avaliação manual; “TP” são True Positives: lances detectados corretamente; FNsão False Negatives: lances observados mas não detectados; e FP são False Positives:lances incorretamente detectados como um chute. Vale notar que True Negatives: lancescorretamente descartados, não são reportados. Já a Tabela 8 apresenta os resultados paracada tipo de chute em função da métrica recall que é utilizada no artigo, e também emfunção de precision e F-measure (calculada a partir dos dados fornecidos e que serão úteisposteriormente, sendo explicadas na seção 3.6).

Tabela 7 – Dados sobre chutes a gol observados sobre 12 partidas (ABREU et al., 2011)

Tipo de chute Observados TP FN FPShot on target 35 30 5 1

Shot 56 41 15 6Intercepted shot 78 58 20 6

Fonte: Adaptado de (ABREU et al., 2011)

Tabela 8 – Resultados para a detecção de chutes a gol (ABREU et al., 2011)

Tipo de chute Recall Precision F-measureShot on target 0,8571 0,9677 0,9091

Shot 0,7321 0,8723 0,7961Intercepted shot 0,7436 0,9063 0,8169

Total (média ponderada) a 0,7633 0,9077 0,8291a Ponderada pelo número de instâncias em cada classe como realizada na ferramenta WEKA (seção 3.7),

diferentemente da ponderação pelo número de jogos em grupos predefinidos feita no artigo

Fonte: Adaptado de (ABREU et al., 2011)

Ainda em (ABREU et al., 2011), o autor discute suas hipóteses sobre a menoreficiência para detecção de chutes e cita as ambiguidades relacionadas a esse tipo de lance,

tadas nota-se que se referia ao recall


que por acontecer mais próximo do gol geralmente possui muitos jogadores aglomerados emuma menor região do campo, tornando mais difícil determinar através de uma heurística,por exemplo, a posse de bola. Esses resultados levantaram um grande risco quanto a criaçãode uma ferramenta para extração de estatísticas, pois diversas das principais métricasde desempenho no futebol (sendo o próprio chute a gol uma das principais) envolvemcomumente lances com disputa de bola entre diferentes jogadores.

O presente trabalho partiu da hipótese de que a utilização de mineração de dadosno lugar de heurísticas traria um aumento da qualidade na detecção dos eventos de chutea gol, abrindo caminho para futuramente realizar uma detecção completa das mais de 200métricas utilizadas amplamente no futebol real (abordadas no Capítulo 2).

1.5 Semelhanças entre futebol real e simuladoPara resumir as características do servidor e compará-lo com o futebol real serão

utilizadas as propriedades do ambiente de tarefa (RUSSEL; NORVIG, 2003), que já foramem parte apresentadas na Tabela 1.

Completamente observável vs Parcialmente observável

A simulação 2D é parcialmente observável pois os agentes em campo estão limitadospelos seus sensores a perceberam apenas parte do que está ocorrendo no jogo a cada ciclo.O modelo de visão é o principal limitador, tornando a coleta de informações um problemaessencial de ser bem resolvido para ser possível uma boa tomada de decisões. A únicaexceção é o técnico, que recebe informação visual completa da partida mas possui limitaçõespara se comunicar com o time. Um aprofundamento do trabalho atual, a extração deestatísticas de alto nível em tempo real pelo técnico, pode ser uma estratégia interessantepara aprimorar o uso dessa sua vantagem natural.

No futebol real os jogadores também possuem apenas uma visão parcial do queestá acontecendo a cada momento na partida, sendo parte importante do jogo decidir oque observar, como olhar para a área antes de realizar um cruzamento ou notar se umadversário se aproxima por trás para tomar a bola. O fato do técnico ter a informaçãocompleta sobre cada ciclo na Simulação 2D não é essencialmente idêntico ao mundo realmas reflete o fato do técnico estar em posição privilegiada para observar o jogo, contandoinclusive com auxiliares para realizar essa tarefa.

Determinístico vs Estocástico

Podemos classificar o ambiente como estocástico, pois uma mesma ação realizadaduas vezes sobre condições idênticas pode gerar efeitos diferentes, inclusive falhando emobter o efeito desejado. Elementos comuns de uma partida de futebol real, como vento,ruídos na informação e imprecisão na realização de determinadas ações são responsáveis


pela estocasticidade da Simulação 2D. Isso reflete o fato de que no futebol real ainda queum jogador esteja sobre as mesmas condições gerais dificilmente conseguirá repetir, porexemplo, um chute de forma idêntica, devido aos inúmeros pequenos detalhes envolvidosnesta ação.

Episódico vs Sequencial

O ambiente é episódico em relação a uma série de partidas, porém sequencial emrelação as decisões tomadas dentro de um mesmo jogo, ou seja, a escolha do agente emum dado ciclo pode afetar suas futuras possibilidades e decisões, exatamente como ocorreno futebol real.

Estático vs Dinâmico

O agente dispõe de 1 ciclo para escolha de sua ação primária, e nos casos ondese omitir e não realizar nenhuma ação, o jogo prossegue normalmente, como no futebolreal. Devido a esta independência do fluxo do jogo em relação aos agentes, o ambienteé classificado como dinâmico. Uma partida prosseguirá até o fim, mesmo que todos osagentes de ambos os times não tomem nenhuma ação.

Discreto vs Contínuo

O futebol é por natureza um problema contínuo. Porém, diferentemente de cate-gorias como a Humanoide onde esta característica é preservada, a simulação 2D utilizaum modelo de ação discreto, sendo uma aplicação de pseudo tempo-real, onde o agentepossui um número limitado de distintas e claramente definidas ações e percepções. Este éo aspecto que mais difere do futebol real, onde não é natural se falar em ciclos discretos.

Agente único vs Multiagente

O futebol simulado 2D é, assim como o futebol real, disputado entre dois timesde 11 jogadores, e conta inclusive com técnico e jogadores reservas. É, deste modo, umambiente multiagente que envolve competição e cooperação.

Além das características acima o ambiente da 2D ainda inclui, como destacado em(ABREU, 2010), diferentes atributos para cada jogador em campo, modelos realistas deenergia e um amplo conjunto de ações de baixo nível para compor os comportamentosdos agentes, tornando o ambiente simulado 2D muito similar a um ambiente de futebolreal (à parte as diferenças no estilo de jogo resultantes principalmente da inexistência dadimensão da altura). Essas semelhanças justificam a busca empreendida no Capítulo 2 porsoluções para análise de desempenho que estejam sendo aplicadas no futebol profissional.

52

2 Análise quantitativa nos esportes

O campo da análise quantitativa nos esportes busca atingir a excelência na tomadade decisões através de fortes evidências pautadas em dados. Ela busca indicadores dedesempenho mensuráveis em um mundo abundante em dados, com o objetivo de aprimoraros resultados alcançados em relação a quando se confia apenas na intuição e experiênciade especialistas de domínio (SCHUMAKER; SOLIEMAN; CHEN, 2010).

A área está em franco crescimento nos últimos anos, tendo surgido grandes eventoscomo o Sports Analytics Innovation Summit (Innovation Enterprise LTD, 2013), inúmerosblogs, publicações como o Journal of Quantitative Analysis in Sports (ALBERT, 2013) elivros como The Numbers Game (ANDERSON; SALLY, 2013b), todos especializados noassunto. A revista de divulgação científica Galileu, trouxe o tema como capa do mês denovembro de 2013, onde afirma que o futebol deixou de ser uma “caixinha de surpresas”.Como citam os autores do The Numbers Game em seu blog Soccer By The Numbers(ANDERSON; SALLY, 2013a):

After all, no matter how you define data, one thing we all share incommon is the goal to discover patterns, communicate them, and usethem to improve some aspect of decision making and ultimately teamperformance, either through efficiency or innovation.1

Esses elementos tornam oportuna a realização desse trabalho nesse momento, dadasua aderência a essa nova área que se mostra como uma forte tendência dentro do futebol.A ideia de realizar análises quantitativas para avaliar com precisão o desempenho dasequipes de futebol de robôs se inspira nas abordagens sendo utilizadas no futebol real, quecomo mostrou a seção 1.5 é muito similar a Simulação 2D.

2.1 Esportes e mineração de dadosAlguns esportes profissionais comportam os ambientes mais competitivos da atuali-

dade. Nesse contexto, equipes precisam extrair o máximo de suas decisões para conseguiralguma vantagem. Como visto em (SOLIEMAN, 2006), a busca em nível profissionalpor aprimoramentos faz parte da cultura nos esportes desde que eles se mostraram umempreendimento rentável, mais de um século atrás. A prova disso é a antiga tarefa descouting, em que olheiros observam novos atletas e times adversários para gerar relatórios1 “No fim das contas, não importa como você defina dados, uma coisa que todos temos em comum é a

meta de descobrir padrões, comunicá-los, e usá-los para melhorar algum aspecto da tomada de decisõese, em última instância, desempenho do time, seja através da eficiência ou inovação.” (Tradução doautor)

Capítulo 2. Análise quantitativa nos esportes 53

que possam ajudar sua equipe a definir a melhor estratégia ou fazer uma contrataçãoimportante.

Mais recentemente, ao se perceber a riqueza escondida nos abundantes dadosgerados a cada partida, novas abordagens ganharam peso, com detaque ao uso de mineraçãode dados. Vários times hoje empregam estatísticos e analistas para auxiliar o trabalhotradicional dos especialistas no domínio (técnicos, olheiros e gerentes). O filme de 2011MoneyBall, baseado em livro homônimo (LEWIS, 2003), popularizou o assunto ao contarnos cinemas a história real de como o gerente de baseball Billy Beane construiu um timecompetitivo de baixo custo em 2002, desafiando o status quo no esporte ao utilizar umaabordagem baseada em novas medidas de desempenho pautadas em estatísticas.

Desde então, pode-se dizer que mineração de dados já iniciou uma pequena revoluçãonos esportes, como nota-se no livro Sports and Data Mining (SCHUMAKER; SOLIEMAN;CHEN, 2010):

From players improving their game-time performance using video analysistechniques, to scouts using statistical analysis and projection techniquesto identify what talent will provide the biggest impact, data mining isquickly becoming an integral part of the sports decision making landscapewhere manager/coaches using machine learning and simulation techniquescan find optimal strategies for an entire upcoming season.2

Em apresentação no Massachusetts Institute of Technology (MIT) (GOLOVNYA,2011), o especialista Mikhail Golovnya afirma que mineração de dados é uma evoluçãodentro dos esportes. Ele mostra que dados históricos são a base para utilização de mineraçãode dados e que o domínio esportivo é muito rico em dados. Devido a sua natureza, os jogospossuem uma estrutura natural que facilita que os dados sejam coletados corretamente, oque, junto com o grande interesse público, faz com que seja comum existirem bases dedados abertas na internet com excelente qualidade, seja com dados sobre times, jogadoresindividuais, partidas específicas ou temporadas completas.

Em resumo, esportes possuem dados abundantes com qualidade e muita necessidadede informação, o contexto ideal para utilizar mineração de dados. Soma-se a isso os altosvalores transacionados pelos melhores atletas, que são o principal investimento das equipes,fazendo com que saber escolhê-los ou prever lesões, por exemplo, sejam atividades quevalem milhões de dólares. Numa hierarquia definida em (SCHUMAKER; SOLIEMAN;CHEN, 2010) sobre a relação entre organizações profissionais e o uso de técnicas paraanalisar os seus dados, mineração de dados ocupa o nível mais alto, como pode ser vistona Tabela 9.2 “De jogadores melhorando seus desempenho nos jogos usando técnicas de análise de vídeo, até olheiros

usando análise estatística e técnicas de projeção para identificar quais talentos causarão o maiorimpacto, mineração de dados está rapidamente se tornando uma parte integral da tomada de decisõesnos esportes, onde gerentes/técnicos usindo aprendizado de máquina e técnicas de simulação podemencontrar estratégias ótimas para a próxima temporada inteira.” (Tradução do autor)


Tabela 9 – Hierarquia sobre a relação entre organizações e dados esportivos

Nível RelaçãoUm Nenhuma relaçãoDois Especialistas de domínio fazendo predições usando instinto e intuiçãoTrês Especialistas de domínio fazendo predições usando dados históricos

Quatro Uso de estatísticas no processo de tomada de decisãoCinco Uso de mineração de dados no processo de tomada de decisão

Fonte: Adaptado de (SCHUMAKER; SOLIEMAN; CHEN, 2010)

Com o amadurecimento da tecnologia a tendência é que cada vez mais equipesavancem para os níveis mais altos dessa hierarquia, sendo que em ligas como a PremierLeague da Inglaterra, muitas já estão no nível 5. Enquanto isso, na Simulação 2D, arealidade bastante diferente é que a maioria dos participantes encontram-se entre o nível 2e 3, carecendo de ferramentas que popularizem as técnicas e, principalmente, aumentema oferta de dados históricos sobre as partidas. No presente, mineração de dados já seprovou útil no domínio da análise esportiva, e o futuro, ao menos como imaginado por(SCHUMAKER; SOLIEMAN; CHEN, 2010), será muito promissor para área:

With more and more sports organizations embracing the digital era, itmay soon become a battle of the better algorithm or performance metric,where the back-office analysts may be just as important as the playerson the field.3

2.2 Ferramentas comerciaisO crescimento da área é acompanhado pela evolução comercial, com diversas

empresas concorrendo para fornecer dados estatísticos e ferramentas de análise paraequipes e para a mídia esportiva, como Infostrada Sports, Wyscout, Sportstec, Prozonee Stats, com destaque para a Opta Sports que lidera o mercado. A Opta existe desde1996, inicialmente como fornecedor de dados para mídia, mas lançou nos últimos 2 anos aferramenta OptaPro, focada em clubes profissionais. Na Figura 11 é possível ver uma dasinterfaces do OptaPro.

A base dessas ferramentas são os dados de cada partida. Um dos diferenciais daOpta é prover os dados em tempo real. Para isso um grupo de três profissionais assistemaos jogos munidos de ferramentas através das quais realizam a contagem das estatísticas amedida que cada lance ocorre (PRINCE, 2013a). Apesar de existirem ferramentas paracoletar parte dos dados automaticamente, através de sistemas de câmera especiais e análisede vídeo ou outras tecnologias de rastreamento como wi-fi ou rádio, para obter uma3 “Com mais e mais organizações esportivas abraçando a era digital, isso pode em breve se tornar uma

batalha entre o melhor algoritmo ou métrica de desempenho, onde os analistas no escritório podemser tão importantes quanto os jogadores no campo.” (Tradução do autor)


Figura 11 – Uma das interfaces da ferramenta OptaPro destacando os passes longos dojogador David Beckham

Fonte: (PRINCE, 2013b)

análise rápida, completa e de qualidade os sistemas comerciais ainda se baseiam em dadoscomputados por humanos.

A Opta afirma possuir os bancos de dados esportivos mais detalhados do mercado,tendo sido adotada como fornecedora de dados padrão de grandes equipes do mundo todo,incluindo em seu portfolio, a partir de agosto de 2013, até mesmo a Confederação Brasileirade Futebol (Opta Sports, 2013). Dada a maturidade do mercado, com o aval das maioresequipes do mundo, as abordagens utilizadas por essas ferramentas análiticas comerciaisservirão como orientação sobre quais variáveis são as mais importantes de serem coletadas,ao invés de utilizar as definições em (ABREU et al., 2011) (descritas na seção 1.4). Outravantagem dessa escolha é poder realizar mais facilmente comparações diretas com dadoshistóricos coletados no futebol real.

2.3 Definição de eventosNão existe um consenso no futebol sobre quais as métricas mais importantes, com

cada equipe utilizando os dados disponíveis de modo particular. O que é certo, é queprimeiro se precisa de dados abundantes para apenas depois estudar as correlações queexistem entre determinados eventos e o sucesso das equipes, dados estes que não estãodisponíveis na Simulação 2D. O foco desse trabalho foi encontrar um método para extrairautomaticamente dos jogos da 2D as estatísticas relacionadas a eventos de chutes a gol,que se mostraram de difícil detectação com qualidade através de heurísticas (seção 1.4).

Para se chegar ao conjunto de métricas a serem detectadas foram estudados


os eventos coletados no ambiente profissional e disponibilizados através da ferramentaOptaPro, que como mostrado na seção 2.2 é a líder de mercado e possui bastante maturidadeno setor. A empresa foi contatada por email e forneceu uma lista completa com a definiçãodos eventos que utiliza, informação que era mantida online em (BATEMAN, 2012) epode ser vista no Anexo A. Existem 4 métricas diretamente relacionadas aos chutes, queadaptadas ao ambiente da 2D foram assim definidas:

1. Goal/Own goal: os gols e gols contra. Sempre que a bola passa entre as travescom o playmode play_on, resultando no playmode goal_[l|r]. Quando o último toquena bola antes de entrar no gol é dado apenas por um jogador defensor, o gol éconsiderado gol contra.

2. Shot on target: Toda tentativa de chutar no gol que:

• Termina em gol;

• Bola iria para o gol mas é interrompida por uma defesa do goleiro;

• Bola iria para o gol mas é interrompida por um defensor que é o último jogadorque pode parar a bola.

3. Shot off target: Toda tentativa de chutar no gol que acerta a trave ou vai pra forapassando pelo limite da área de penâlti;

4. Blocked shot: Toda tentativa de chutar no gol que é bloqueada por um defensor,onde existam outros defensores ou o goleiro entre o jogador que bloqueou e o gol.

Gols e gols contra são eventos simples de serem detectados através de heurísticas, opróprio artigo de (ABREU et al., 2011) cita um método para realizar a detecção com altataxa de sucesso, sendo desnecessária a criação de um classificador mais robusto. Com oevento de gols descartado, o foco da classificação foram os eventos de Shot on target, Shotoff target e Blocked shot. Para Shot off target foi adotado o limite da área do penâlti (assimcomo Intercepted shot de Abreu, mas diferente da definição da Opta que não possui essarestrição) pois os atuais modelos de chute na 2D são mais precisos que os chutes humanos,não ocorrendo um caso onde um robô queira chutar no gol e consiga, por exemplo, concederum lateral, como em casos limites podem acontecer no futebol real.

É importante notar que os eventos definidos pela Opta são muito similares aoseventos definidos em (ABREU et al., 2011) (listados na seção 1.4), havendo uma corres-pondência entre Blocked shot e Intercepted shot, ambos os casos definidos como Shot ontarget e entre Shot off target e Shot. Nos detalhes, porém, todas as definições possuemcasos que as diferem: uma bola salva pelo goleiro ou pelo último defensor é classificadacomo Shot on target pela Opta enquanto é Intercepted shot em Abreu; bolas na trave ou


que passem a até 0.5m do gol são Shot off target para Opta enquanto são Shot on targetpara Abreu.

O resultado dessa diferença é que apesar de todos os chutes a gol dados nos jogosestarem incluídos em ambas as definições, a classe onde cada chute é colocado podevariar, ou seja, apesar da soma de todos os chutes dados no gol em um jogo ser a mesmatanto para Opta quanto para Abreu, os chutes provavelmente estarão agrupados de formadistinta. Observadas de perto, nota-se qua a abordagem da Opta torna mais difícil realizara classificação uma vez que na definição de Abreu todas as bolas bloqueadas estão apenasem um grupo, todas as bolas que passam perto do gol, incluindo a trave, estão em outro,e as bolas que claramente vão para fora estão todas agrupadas no último. A classificaçãoda Opta exige, por exemplo, que caso seja identificado um bloqueio na bola, ainda sejaanalisada as posições dos outros defensores na área para chegar a conclusão se foi um Shoton target ou Blocked shot.

Retornando à lista de eventos da Opta, existem ainda 2 métricas relacionadas achute que são derivadas a partir das 4 primeiras, e podem ser calculadas facilmente apartir da classificação automática das primeiras. São elas:

• Chance conversion ou Goals-to-shot ratio: representam as oportunidas conver-tidas em gol, dada pelos gols marcados dividido pelo total de chutes (excluídos osBlocked shots);

• Shooting accuracy: representa a precisão ao chutar pro gol, dada pelo total deShots on target dividido pelo total de chutes (excluídos os Blocked shots).

Apesar da extensa lista de eventos da Opta que precisarão ser alvo de trabalhosfuturos, permitir a classificação automática e com qualidade dos 6 eventos definidos acimajá representa um grande benefício para os pesquisadores investigando o desempenho dossistemas multiagentes sobre os quais trabalham. Essas são, juntamente com os passesdecisivos e posse de bola, algumas das métricas mais importantes para analisar o desempe-nho de uma equipe de futebol, sendo amplamente comunicadas, por exemplo, durante astransmissões esportivas. Na copa de 2014, por exemplo, toda substituição de jogador foiacompanhada pelas informações sobre total de gols, total de finalizações (Shots on target+ Shots off target) e finalizações no gol (Shots on target). Todos esses eventos podem serusados tanto para avaliar o desempenho da equipe como um todo, quanto de um robô emparticular.


2.4 Diferenças entre o futebol profissional e o de robôsEssa seção faz uma rápida análise sobre o uso de estatísticas no futebol real e no

futebol de robôs simulado. Em ambos os casos há interesse em informações estatísticas,porém, por motivações diferentes. Enquanto no futebol real o principal motivador éfinanceiro, uma vez que uma única decisão pode custar milhões de dólares para um clube,no futebol de robôs as estatísticas de alto nível são o primeiro passo para criação de umametodologia de análise de desempenho que ajude os pesquisadores a avaliar melhor suasteorias, modelos, algoritmos e arquiteturas, definindo um ambiente mais completo paratestes e experimentações.

A realidade do estado da arte em ambos os contextos difere bastante, o queprovavelmente se explica facilmente pelos bilhões que o futebol profissional movimenta.Nesse caso, os jogos oficiais atraem o interesse de grande parte da sociedade (o futebol éconsiderado atualmente o esporte mais popular do mundo (Enciclopédia Britânica, 2013)),tornando factível que as empresas especializadas tenham uma equipe focada em cada jogopara realizar coletas de dados manualmente em tempo real, processo explicado na seção 2.2.Já sobre o interesse na ciência, foi emblemático o tempo recebido para a demonstraçãodo projeto Andar de Novo, liderado pelo cientista brasileiro Miguel Nicolelis, durante aabertura da Copa do Mundo de 2014.

Apesar das ferramentas de coleta automática estarem evoluindo, uma comparaçãorealizada em (ABREU, 2010) mostra que mesmo nesses casos é comum ser necessárioalgum tipo de processamento manual, pois há um desafio inerente à coleta de dados básicoscomo a posição dos jogadores e da bola (processamento de imagens, ruídos na detectaçãoetc). Por outro lado, a grande vantagem do futebol simulado é possuir um servidor centralque possui informações básicas precisas sobre o estado do mundo, o que permitiu que acoleta manual dos eventos de chute se tornasse desnecessária. Na 2D, em que o interesseem cada jogo é consideravelmente menor (particular dos pesquisadores envolvidos) e aquantidade de jogos a ser processados pode ser muito maior (dado que um único teste podeexigir que se rode diversas simulações), realizar detecções automaticamente é fundamentalpara que seja factível obter estatísticas de futebol na Simulação 2D e diminuir a distânciapara o estado da arte no futebol profissional.

59

3 Mineração de dados

O trabalho partiu da hipótese de que seria possível solucionar o problema da coletade estatísticas de chutes a gol utilizando técnicas clássicas de mineração de dados. Issoper si já é uma diferença para os trabalhos relacionados mostrados na seção 1.4, queutilizaram heurísticas para realizar as detecções. Ao longo desse trabalho mineração dedados é entendida como o processo completo associado a Descoberta de Conhecimento emBases de Dados (KDD). Apesar de ser muito comum os dois termos serem usados comosinônimos, como é feito aqui, é amplamente aceita a distinção técnica feita em (FAYYAD;PIATETSKY-SHAPIRO; SMYTH, 1996):

In our view, KDD refers to the overall process of discovering usefulknowledge from data, and data mining refers to a particular step inthis process. Data mining is the application of specific algorithms forextracting patterns from data.1

No mesmo artigo também há uma definição mais detalhada para KDD: “KDDis the nontrivial process of identifying valid, novel, potentially useful, and ultimatelyunderstandable patterns in data”2. A Figura 12 apresenta uma visão geral sobre mineraçãode dados, mostrando que ela pode ser entendida como usar dados históricos para ganharinsights sobre a população que gerou esses dados e / ou fazer predições sobre novos dadosoriundos dessa população (GOLOVNYA, 2011).

São esses então os dois objetivos de alto-nível comuns para um trabalho de mineraçãode dados: (a) prever valores futuros ou desconhecidos de variáveis de interesse, ou (b)descrever os dados através de padrões reconhecíveis por humanos (FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996). Essas metas podem ser alcançadas através de uma variedade demétodos, como classificação, agrupamento (clustering), regressão e associação. O objetivodesse trabalho pode ser decomposto na tarefa de atribuir registros extraídos dos logs daSimulação 2D para classes nominais e discretas predefinidas (eventos estabelecidos naseção 2.3), que é essencialmente um problema de classificação.

O restante do capítulo detalha a metodologia para desenvolvimento da solução,se aprofunda na área de classificação, mostra os principais algoritmos que foram usadospara derivar modelos de classificação para o problema em mãos e explica alguns tópicosespeciais referentes ao trabalho de minerar dados, como cuidados para se obter um modelogenérico, e técnicas de validação e visualização dos resultados. Por fim é apresentada aprincipal ferramenta utilizada na etapa de modelagem.1 “Em nossa visão, KDD se refere ao processo geral de descoberta de conhecimento útil a partir de

dados, e mineração de dados se refere a um passo particular deste processo. Mineração de dados é aaplicação de algoritmos específicos para extrair padrões dos dados.” (Tradução do autor)

2 KDD é o processo não trivial de identificar padrões válidos, originais, potencialmente úteis, e emúltima instância compreensíveis, nos dados

Capítulo 3. Mineração de dados 60

Figura 12 – A essência da mineração de dados

Fonte: Adaptado de (GOLOVNYA, 2011)

3.1 Metodologia CRISP-DMA metodologia CRISP-DM (Cross Industry Standard Process for Data Mining)

(CHAPMAN et al., 2000) foi a diretriz utilizada para realizar o projeto. Essa metodologiafoi escolhida por ser amplamente utilizada, sendo considerada em (MARISCAL; SEGOVIA,2009) como sendo “‘de facto standard’ for developing DM & KD projects”3. Apesar deser desenvolvida para o mercado, sua robustez permite que seja aplicada no processocientífico com adaptações sutis, entendendo que prioridades científicas são diferentes deprioridades de negócio. Ela possui tarefas distribuídas em 4 níveis de abstração, mas parafins de objetividade a metodologia será descrita aqui apenas do nível mais alto, o das fases(Figura 13).

A primeira fase, Compreensão do Problema (Business Understanding), está rela-cionada a compreensão do objetivo que se deseja alcançar com mineração de dados, asrestrições envolvidas e a elaboração de um cronograma. As metas são definidas tanto emtermos do problema que se quer resolver (business goal) quanto em termos mais práticosrelativo ao que se pretende realizar com mineração de dados (data mining goal). Tambémé definido o critério de sucesso do projeto e as ferramentas chave a serem utilizadas. Aprincipal delas foi o Waikato Enviroment for Knowledge Analysis (WEKA), um softwareque é apresentado na seção 3.7.

Na fase 2, Compreensão dos Dados (Data Understanding), uma das principais3 “’De facto padrão’ para desenvolver projetos de DM e KD” (Tradução do autor)


Figura 13 – As fases do processo CRISP-DM

Fonte: (AGENCY, 2013)

atividades é a coleta inicial dos dados e sua descrição. Essa etapa envolveu uma análisequalitativa dos dados, em que diversas partidas foram assistidas, e também uma análisemais objetiva, estudando os dados para entender sua estrutura e que atributos são úteispara a realização da tarefa de classificação. No fim dessa etapa foi realizada a seleção doespaço amostral que seria utilizado no restante do projeto, uma vez que a classificaçãomanual feita na próxima fase restringe a massa de dados sobre a qual é viável trabalhar.Esse contato prévio com os dados servem ao propósito de identificar possíveis problemas omais cedo possível, derivar os primeiros insights e entender algumas relações existentesnos dados, elementos estes que são importantes nas decisões das próximas etapas.

Na terceira fase, Preparação dos Dados (Data Preparation), os dados brutos dos logssão extraídos e carregados num repositório intermediário. Depois, uma versão final (apesarde ser comum iterar sobre essa fase) do conjunto de dados utilizado para modelagem écriada a partir de diversas transformações nos dados originais, como limpeza para garantirqualidade, derivação de atributos, criação de novas entradas e integração de dados dediferentes fontes. Ao fim dessa fase, tem-se um vetor de características normalizado quepode ser utilizado como entrada para os algoritmos de aprendizagem supervisionadautilizados na etapa seguinte. Atenção particular foi dada a esta fase, pois como citadoem (SANTOS, 2006), “No caso particular de análise de logs, é indispensável, custosa eproblemática”.

Na fase seguinte, Modelagem (Modeling), o conjunto de dados final é pré-processado


e técnicas de modelagem são selecionadas, aplicadas e otimizadas. Para selecionar astécnicas mais propícias foi empreendido um trabalho empírico de testes exaustivos comdiferentes algoritmos de aprendizagem supervisionada. Como diferentes técnicas podemser utilizadas para resolver o mesmo problema, foi necessário mais de uma iteração deprototipação para encontrar a técnica apropriada.

Selecionadas as técnicas, é necessário criar um mecanismo para validação. Existemdiferentes métodos clássicos para proceder com o setup do mecanismo de validação, comoo n-fold cross-validation (TAN; STEINBACH; KUMAR, 2006), que é melhor detalhadona seção 3.5. Por fim, as técnicas de modelagem são aplicadas sobre os dados preparados esoluções são obtidas. Essas soluções podem ser chamadas de modelos, e representam aaplicação de um método específico mais os parâmetros utilizados para maximizar algumindicador de desempenho. Ainda nessa fase, é feita uma análise prévia sobre os resultadosgerados e decide-se sobre iterar na construção de modelos ou prosseguir.

Quando encontrado pelo menos um modelo satisfatório, entra-se na penúltima fase,Avaliação dos Resultados (Evaluation). Aqui uma análise mais profunda sobre os modelosgerados é feita e eles são comparados entre si e com o baseline definido pela literatura. Oresultado alcançado é comparado com os objetivos da pesquisa, permitindo que os modelosfinais sejam aceites como uma solução satisfatória para o problema. É importante tambémrevisar o processo e verificar se todas as tarefas foram conduzidas corretamente, ou se algoprecisará ser refeito.

A última etapa, Implantação (Deployment), envolve a organização e apresentaçãodo conhecimento adquirido. Nessa etapa o modelo pode ser aplicado em um contexto real ecolocado em produção, mas como o objetivo desse projeto era encontrar um melhor modelo,a aplicação do modelo não foi incluída no escopo, apesar de que sua utilidade foi avaliada.Alguns cuidados sobre a manutenção dos modelos também podem ser listados nessemomento, afinal serão necessárias atualizações para que eles continuem tendo validade,uma vez que é possível haverem mudanças nas regras do jogo, na física do ambiente eprincipalmente, no comportamento das equipes ao longo do tempo. Como mostrado em(GOLOVNYA, 2006), mineração de dados não se refere a leis de longo prazo como é comumna ciência, restando apenas usar um modelo enquanto ele continua tendo aderência aosdados sobre os quais ele foi desenvolvido (mais sobre isso na seção 9.3).

3.2 ClassificaçãoClassificação é definida em (TAN; STEINBACH; KUMAR, 2006): “Classification

is the task of learning a target function 𝑓 that maps each attribute set 𝑥 to one of


the predefined class labels 𝑦”4, com essa função 𝑓 sendo conhecida como um modelode classificação (Figura 14). Isso é feito pelo exame de dados já classificados (casos) eindutivamente encontrando um padrão para prever essas classes. Como visto em (TwoCrows, 2005), as fontes para os casos podem ser dados históricos, experimentos, ou comonesse trabalho, advir de classificações feitas manualmente sobre algumas amostras dosdados disponíveis.

Figura 14 – Classificação como a tarefa de mapear uma conjunto de atributos de entrada𝑥 para sua classe 𝑦

Fonte: Adaptado de (TAN; STEINBACH; KUMAR, 2006)

Um exemplo de aplicação de classificadores é a filtragem de emails com spam baseadano cabeçalho e no conteúdo da mensagem. Um outro caso clássico é a identificação deimagens em grandes bancos de dados, como classificar galáxias de acordo com seus formatos(TAN; STEINBACH; KUMAR, 2006). Classificar se diferencia de agrupar essencialmenteporque no caso do agrupamento não se sabe os grupos que serão formados, ou dito deoutro modo, as classes finais. Em relação a regressão, a principal diferença é que enquantona regressão a saída 𝑦 é contínua, na classificação 𝑦 deve ter um valor discreto (restriçãoque não se aplica as entradas 𝑥, que podem ser contínuas).

Mais especificamente, classificadores são mais apropriados para descrever ou realizarpredições em conjuntos com categorias binárias ou nominais (caso da Simulação 2D), sendomenos efetivos sobre categorias ordinais por não considerar a ordem implicita nas categorias.Diferentes tipos de modelos podem ser aplicados para solucionar problemas de classificação,como árvores de decisão, classificadores baseados em regras, redes neurais, support vectormachines (SVM) e classificadores naïve Bayes (TAN; STEINBACH; KUMAR, 2006).Cada técnica possui diferentes implementações concretas de algoritmos de aprendizadosupervisionado para extrair um modelo que represente a relação entre os dados de entradae a classe de saída. A Figura 15 apresenta uma visão geral desse processo.

Os dados alvo comumente são divididos em dois grupos, um para realizar o trei-namento do classificador e outro formado por dados independentes, não utilizados paragerar o modelo final, de modo que seja possível medir a taxa de erro do classificador e4 “Classificação é a tarefa de aprender uma determinada função 𝑓 que mapeia cada conjunto de atributos

𝑥 para um dos rótulos de classe predefinidos” (Tradução do autor)


Figura 15 – Abordagem geral para construir um modelo de classificação


determinar a sua qualidade (mais sobre validação na seção 3.5). Em geral os problemasde classificação são entendidos como problemas de aprendizagem supervisionada, pois assaídas para cada exemplo do conjunto de treino são conhecidas.

Apesar da importância da etapa de modelagem, que foi o principal foco dessa seçãoe é a que mais recebe atenção na literatura, a etapa de preparação dos dados costumaser a mais trabalhosa no processo de construção de um classificador. Os algoritmos deaprendizado funcionam sobre vetores de dados de tamanho fixo, conhecido como vetores decaracterísticas, e até chegar nesses vetores os dados originais precisam ser compreendidose transformados de forma significativa, envolvendo um grande número de detalhes.

3.3 Visualização de dadosVisualização de dados é um campo à parte no KDD. Seu principal objetivo é criar

meios de comunicar informações graficamente com clareza e eficiência. Sua relevância édescrita em (Two Crows, 2005):

Graphing and visualization tools are a vital aid in data preparation andtheir importance to effective data analysis cannot be overemphasized.Data visualization most often provides the Aha! leading to new insightsand success.5

5 “Ferramentas de visualização e criação de gráficos são uma ajuda vital na preparação dos dados esua importância para uma análise de dados efetiva não pode ser subestimada. Visualização de dadosgeralmente provê o Ahá! que leva a novas descobertas e ao sucesso.” (Tradução do autor)


Visualização dos dados tem um papel importante tanto no início quanto no fimdo processo de modelagem. Durante o pré-processamento é essencial para se conhecermelhor os dados, servindo por exemplo para se ter uma ideia de sua distribuição, desuas relações, para selecionar atributos e para orientar a escolha dos tipos de modelosque podem ser aplicados (SANTOS, 2012). Durante a validação servem para clarificar osresultados obtidos, e durante a implantação podem ser fundamentais para que os usuáriosfinais extraiam valor de todo o processo.

Em (SANTOS, 2012) são listadas diversas técnicas de visualização famosas divididasem 3 categorias. A primeira se refere à técnicas geométricas como Matriz Scatterplot(Figura 16), Coordenadas Paralelas e Mapas de Kohonen. A segunda à técnicas baseadas emícones que criam dimensões adicionais, como a curiosa representação conhecida como Carasde Chernoff (Figura 17). Por último são listadas técnicas hierárquicas, que particionam asdimensões em subdimensões, como Dimensional Stacking e Treemap.

Figura 16 – Scatterplot Matrix criada no WEKA com cruzamentos entre algumas dascaracterísticas dos chutes a gol



Gráficos possuem um poder representacional muito grande quando comparadoa textos e números, tornando muito mais fácil a visualização de alguns padrões, comocorrelações lineares entre variáveis contínuas no caso da matriz scatterplot, e a exploraçãosobre os dados. Entretanto a área possui um enorme desafio que é conseguir representarmodelos com muitas dimensões em uma tela de computador ou no papel, sendo necessárioformas criativas e inteligentes para colapsar N dimensões em apenas 2 (Two Crows, 2005).Outro empecilho são os limites da cognição humana, que como se brinca em (SANTOS,2012), possui também suas próprias limitações de hardware.

Figura 17 – Caras de Chernoff

Fonte: (SANTOS, 2012)

Já no processo de avaliação dos resultados, uma técnica bem simples porém bastanteutilizada em problemas de classificação são as matrizes de confusão (confusion matrices)(Two Crows, 2005). Elas facilitam a avaliação do desempenho do modelo gerado cruzando ostotais de predições corretas e incorretas, mostrando inclusive qual o tipo de erro cometido.A Tabela 10 mostra uma matriz de confusão, sua diagonal contendo as informações preditascorretamente. No exemplo, das 75 instâncias da Classe A, 70 foram preditas de formacorreta e 5 erros foram cometidos, 4 como Classe B e 1 como Classe C. Matrizes de confusãoservem de base para a definição de diversas métricas de desempenho de classificadorescomo descrito na seção 3.6.

3.4 GeneralizaçãoUma das características mais importantes de um classificador é que além de

representar bem a estrutura dos dados do conjunto de treinamento, ele deve ser capaz


Tabela 10 – Matriz de confusão para um classificador multiclasse

Valor preditoValor real Classe A Classe B Classe CClasse A 70 4 1Classe B 3 74 2Classe C 7 2 77


de definir corretamente as classes para dados com os quais o algoritmo de aprendizadonão tenha tido contato. Isto é conhecido como a capacidade de generalização do modelo.Existem dois problemas clássicos relacionados: underfitting e, o principal deles, overfitting.

Underfitting ocorre quando um modelo ainda não consegue representar bem osdados sendo trabalhados, consequentemente tendo uma alta taxa de erro tanto no conjuntode treinamento (chamado de erro aparente) quanto no conjunto de teste (chamado deerro de generalização). Já o fenômeno de overfitting ocorre quando um modelo passa arepresentar o conjunto de treinamento cada vez melhor, ao passo que as taxas de erro degeneralização aumentam. A Figura 18 mostra um exemplo de overfitting na aplicação deum modelo de árvores de decisão.

Figura 18 – Exemplo de overfitting. A partir de certo ponto, a medida que cresce o númerode nós na árvore, a taxa de erro diminui no conjunto de treinamento enquantoaumenta no de teste


Uma das causas do overfitting é que ao se adequar tão bem ao conjunto de trei-namento o modelo pode representar também os ruídos presentes nos dados. (FAYYAD;


PIATETSKY-SHAPIRO; SMYTH, 1996) apresenta o problema e algumas possíveis solu-ções:

When the algorithm searches for the best parameters for one particularmodel using a limited set of data, it can model not only the generalpatterns in the data but also any noise specific to the data set, resultingin poor performance of the model on test data. Possible solutions in-clude cross-validation, regularization, and other sophisticated statisticalstrategies.6

É comum, por exemplo, que um modelo mais complexo seja pior do que um modelomais simples, apresentando uma menor taxa de erro aparente mas uma maior taxa de errode generalização. Favorecer modelos mais simples está em concordância com o princípioda Navalha de Occam, que aplicada no contexto de KDD leva a seguinte definição (TAN;STEINBACH; KUMAR, 2006): “Given two models with the same generalization errors,the simpler model is preferred over the more complex model”7. Existem métodos específicospara verificar a simplicidade de um modelo como Minimum Description Length (MDL)(WITTEN; FRANK; HALL, 2011).

Uma grande vantagem do contexto da Simulação 2D é a alta qualidade dos dadosque foram utilizados como base, uma vez que estes são logados pelo próprio simulador (comomostrado na subseção 1.2.3). Isso diminui consideralmente a possibilidade de overfittingpor conta de ruídos nos dados. Algum ruído significativo, porém, ainda é adicionado aosdados durante a classificação manual e a etapa de seleção e extração de característicasrealizadas na fase 3, Preparação dos Dados.

Por conta disso é necessário que cuidados especiais sejam tomados nesta etapa,realizando por exemplo uma dupla checagem das classificações realizadas manualmente.Ainda assim, é muito provável que algumas situações raras e difíceis de classificar tenhamgerado algum ruído, o que é aceitável (TAN; STEINBACH; KUMAR, 2006): “Errors dueto exceptional cases are often unavoidable and establish the minimum error rate achievableby any classifier“8. Isso nos lembra que não existem modelos perfeitos, eles são sempremodelos.

Quando a base utilizada é muito pequena surge um outro fator importante que podelevar ao overfitting, a ausência de casos representativos. Outro ponto forte do contextoda 2D é o fato de se tratar de um ambiente simulado, onde gerar novos casos não é um6 “Quando um algoritmo busca pelos melhores parâmetros para um modelo particular usando um

conjunto limitado de dados, ele pode modelar não apenas os padrões gerais nos dados mas tambémqualquer ruído específico ao conjunto de dados, resultando em um desempenho ruim do modelosobre dados de teste. Soluções possíveis incluem cross-validation, regularização, e outras estratégiasestatísticas sofisticadas.” (Tradução do autor)

7 “Dados dois modelos com os mesmos erros de generalização, o modelo mais simples é preferível sobreo mais complexo.” (Tradução do autor)

8 “Erros devido a casos excepcionais geralmente são inevitáveis e estabelecem a taxa de erro mínimaalcançável por qualquer classificador”


problema. Novamente, o gargalo se tornou a etapa de classificação manual durante a fasede Preparação dos Dados. Isso se deve ao alto custo em tempo necessário para analisar aspartidas (detalhado na seção 1.3), o que reduziu o tamanho da base de dados disponívelpara a classificação.

Isso tornou essencial que a escolha do espaço amostral fosse bastante criteriosa,garantindo que times com diferentes características e também cruzamentos variados entreesses times, fossem incluídos no conjunto de dados final. Isso reforça a importância dasegunda fase do projeto, Compreensão dos Dados, sem a qual essa escolha criteriosa nãoseria possível.

Algumas técnicas para resolver o problema do overfitting estão associados ao tipode modelo sendo utilizado, como pré-poda ou pós-poda, no caso de árvores de decisão.Outras soluções podem ser mais genéricas, como as relacionadas à técnicas de validação,exemplo de cross-validation citada acima, que será discutida na seção 3.5.

3.5 Técnicas de validaçãoComo visto na seção 3.2, para determinar a qualidade de um classificador é preciso

aplicar o modelo gerado a partir de um conjunto de treinamento em um conjunto de testeindependente, que não tenha sido utilizado na modelagem. Isso porque o erro aparente(medido sobre o conjunto de treino) é uma medida por demais otimista, uma vez que omodelo foi desenvolvido justamente para representar bem os dados de treinamento, sendoinsuficiente para prever o desempenho do modelo em novos dados, ou seja, sua capacidadede generalização. Nessa seção serão analisadas técnicas para realizar a separação dos dadosdisponíveis nos conjuntos de treinamento e teste.

Quando o volume dos dados é grande não há problemas: é possível treinar e testar omodelo usando uma quantidade de dados significativa em ambas atividades, o que em geralleva a um melhor resultado (desde que se garanta que os 2 grupos sejam representativos dototal dos dados). Porém, quando o total de dados disponíveis são uma restrição, técnicasespecíficas precisam ser aplicadas para se obter um melhor resultado. Esse tipo de restriçãoé comum quando os dados precisam ser classificados manualmente, uma tarefa intensiva ecustosa, que precisou ser realizada nesse projeto.

O problema surge pois para construir um bom classificador é importante ter muitosdados para treinamento, ao mesmo tempo em que para avaliá-lo de forma confiável, énecessário possuir muitos dados para o conjunto de teste. Em alguns casos a questão podeser ainda mais crítica, pois pode ser necessária a criação de um terceiro conjunto, chamadode conjunto de validação. Ele pode ser necessário para realizar a otimização de algunsparâmetros do modelo, e uma vez que também precisa ser um conjunto independente,ainda menos dados estarão disponíveis para o treinamento e teste.


Quando apenas é feita a separação do conjunto independente de teste, o processo éconhecido como validação simples ou método holdout. O conjunto de treinamento deveser o maior entre os dois, comumente contendo pelo menos 2/3 das amostras (WITTEN;FRANK; HALL, 2011). Ao criar os conjuntos, atenção especial deve ser dada ao métodode seleção das amostras que irão compor cada um deles, de modo que ambos sejamrepresentativos do total dos dados. Garantir que a seleção seja aleatória não é suficiente,sendo comum a aplicação de um método conhecido como estratificação (WITTEN; FRANK;HALL, 2011), que cria subgrupos de dados homogêneos em cima dos quais a aleatorizaçãoé feita de modo controlado.

Entre as técnicas mais sofisticadas, que apresentam um melhor desempenho quandohá poucos dados, destacam-se cross-validation e bootstrap. Essas técnicas utilizam meca-nismos que permitem que todos os dados disponíveis sejam utilizados para o treinamento.A essência da cross-validation é realizar a divisão do conjunto total em N subconjuntosdisjuntos de tamanho similar, executando o processo completo N vezes, de modo que cadaum dos subconjuntos assuma o papel do conjunto de teste uma vez. A taxa de erro totalé definida como o somatório ou a média dos erros de todas as execuções. Esse método éconhecido como n-fold cross-validation. É possível, ainda, realizar um treinamento finalcom todos os dados disponíveis, de modo a obter um melhor resultado do treino, masmantendo o erro obtido a partir das N execuções anteriores (WITTEN; FRANK; HALL,2011).

Apesar de não serem conclusivos, diferentes estudos sobre variados conjuntos dedados e modelos apontam o 10-fold cross-validation como a aplicação específica dessemétodo que gera os melhores resultados. Na prática a divisão em 10 subconjuntos já setornou uma espécie de padrão, sendo comumente a escolha adotada. É comum ainda quepara alcançar uma maior precisão nos resultados, todo o processo seja repetido 10 vezes,totalizando 110 execuções (com treinamento final) do mesmo algoritmo de aprendizadosobre o mesmo conjunto de dados. Isso é feito para reduzir o efeito da variação aleatóriano processo de criação dos subgrupos. O resumo é um processo intensivo com um totalde 110 execuções de uma mesma configuração (algoritmo de aprendizado e conjunto dedados inicial) para obter uma medida de desempenho confiável para um modelo. Todo oprocesso é explicado em (WITTEN; FRANK; HALL, 2011).

Um tipo específico de n-fold cross-validation que merece destaque é a leave-one-out,onde N é o tamanho total do conjunto. Uma das vantagens desse método é a utilizaçãoda maior quantidade de dados possível para realizar cada iteração de treinamento. Eletambém tem o atrativo de ser determinístico, uma vez que o conjunto de testes possuiapenas 1 elemento. A sua desvantagem principal é custo computacional envolvido, oque pode torná-lo impraticável para grandes conjuntos de dados. Alguns casos especiaistambém precisam ser observados. Mais sobre o assunto pode ser encontrado em (WITTEN;


FRANK; HALL, 2011).

O outro método citado, o bootstrap, também é bastante popular. A principaldiferença para o cross-validation é que o conjunto de treinamento é gerado utilizando oprocesso de amostragem com substituição. Isso significa que ao selecionar uma amostra oconjunto inicial não é alterado, permitindo que o mesmo caso seja selecionado repetidasvezes. A variante mais comum do método é conhecida como 0.632.

Nela um novo conjunto do mesmo tamanho do original é gerado utilizando aamostragem com substituição, ou seja, apesar de ter o mesmo tamanho, ele possui diversasinstâncias repetidas. As amostras que não forem selecionadas nenhuma vez compõem oconjunto de teste. O modelo obtido do treinamento é aplicado no conjunto de teste e ataxa de erro (𝑒𝑖) é determinada. O procedimento é então repetido 𝑏 vezes e a taxa de errofinal é calculada como uma média da combinação do erro aparente (ou de resubstituição)do conjunto de treino (𝑎𝑐𝑐𝑖) com o erro de generalização de cada iteração, utilizando aseguinte fórmula (TAN; STEINBACH; KUMAR, 2006):

𝑒𝑏𝑜𝑜𝑡 = 1𝑏

𝑏∑︁𝑖=1

(0.632× 𝑒𝑖 + 0.368× 𝑎𝑐𝑐𝑖) (3.1)

Um estudo comparativo realizado em (KOHAVI, 1995), que incluiu as técnicas debootstrap e cross-validation, apontou que o 10-fold cross-validation estratificado é a melhorforma de estimar o erro de um modelo. Por isso será essa a técnica adotada nesse projeto.

Vale ressaltar que apesar das técnicas de validação aqui discutidas serem um bomindicativo de quão bem um modelo desempenhará sobre dados futuros, elas não garantemque o modelo esteja correto. Elas apenas mostram que aplicados em dados similares, essesmodelos terão uma taxa de erro aproximada da taxa encontrada. É desejável então queantes de utilizar o modelo em produção, testes sejam realizados no mundo real, pois, porexemplo, casos representativos podem ter sido deixados de fora do processo de modelagemou o comportamento de alguma variável pode ter se alterado.

3.6 Avaliação e comparação de modelosA capacidade de avaliar os modelos gerados é essencial para fazer progressos

concretos na tarefa de mineração. Dada a natureza iterativa e experimental do processode escolher os modelos e algoritmos para resolver um problema, é necessário um métodosistemático para avaliar a qualidade de cada modelo e poder compará-los para definir omelhor. Os critérios para avaliação são medidas quantitativas de quão bem um padrão(um modelo e seus parâmetros) atinge as metas do processo de KDD, sejam elas preditivasou descritivas (FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996).


A avaliação de quão bem um modelo realiza uma tarefa de classificação se dápela contagem dos casos de teste preditos corretamente e incorretamente. Um modo fácilde visualizar esses casos em detalhes é criando uma matriz de confusão (apresentada naseção 3.3). Em um problema de classificação binário com as classes sim e não, as entradastabuladas na matriz de confusão (Tabela 11) tem os seguintes significados:

Tabela 11 – Matriz de confusão para um classificador binário com as classes sim e não

Classe preditasim não

sim true positive false negativeClasse real não false positive true negative


• True positive (TP): Elementos corretamente identificados.

• True negative (TN): Elementos corretamente rejeitados.

• False positive (FP): Elementos incorretamente preditos como sim (positivo), quandona realidade são da classe não (negativo), também conhecido como erro tipo I.

• False negative (FN): Elementos incorretamente preditos como não (negativo), quandona realidade são da classe sim (positivo), também conhecido como erro tipo II.

As classificações corretas se encontram então na diagonal principal, sendo a somade TP + TN. As incorretas são os casos fora dessa diagonal, dado pela soma de FP +FN. Uma das vantagens de analisar os resultados com uma matriz de confusão é saberexatamente a quantidade de erros de cada tipo cometidos pelo classificador, informaçãoessa que pode ser utilizada para realizar uma análise de custo, por exemplo. Geralmente,para problemas extraídos do mundo real, cada erro possui um impacto diferente para oproblema sendo resolvido (WITTEN; FRANK; HALL, 2011).

3.6.1 Métricas de desempenho para classificadores

Apesar da matriz de confusão ser suficiente para demonstrar a qualidade de umclassificador, para tornar mais fácil a comparação entre diferentes modelos costuma-seresumir essas informações em um único número, dado por uma das diversas métricas dedesempenho existentes (TAN; STEINBACH; KUMAR, 2006). Uma das mais comumenteutilizadas é accuracy9:

𝐴𝑐𝑐𝑢𝑟𝑎𝑐𝑦 (𝐴𝐶𝐶) = 𝐶𝑜𝑟𝑟𝑒𝑡𝑎𝑠

𝑇𝑜𝑡𝑎𝑙= 𝑇𝑃 + 𝑇𝑁

𝑇𝑃 + 𝑇𝑁 + 𝐹𝑃 + 𝐹𝑁(3.2)

9 Mantida em inglês para evitar confusão com a métrica precision, e em consequência, todas as medidasassim o foram


Outra métrica comum é error rate (taxa de erro), que é 1− accuracy, ou:

𝐸𝑟𝑟𝑜𝑟 𝑟𝑎𝑡𝑒 = 𝐼𝑛𝑐𝑜𝑟𝑟𝑒𝑡𝑎𝑠

𝑇𝑜𝑡𝑎𝑙= 𝐹𝑃 + 𝐹𝑁

𝑇𝑃 + 𝑇𝑁 + 𝐹𝑃 + 𝐹𝑁(3.3)

Entretanto accuracy nem sempre é a melhor forma de avaliar um modelo. Conside-rando por exemplo uma aplicação médica de um classificador para prever uma patologiaque se manifesta raramente, 99,9% dos casos serão negativos. Um modelo que simplesmenteclassifique todas as intâncias como falsas terá uma accuracy extremamente alta de 99,9%,apesar de ser inútil pois não revela nada sobre os 0,1% dos casos que interessam, que équando a patologia se manifesta. Esse é um problema comum em conjuntos de dados comas classes desbalanceadas (GARCÍA; MOLLINEDA; SOTOCA, 2007), como é caso dosdados de chutes a gol. É importante então considerar outras métricas10. Métricas cujodenominador envolve apenas casos que são de fato positivos:

𝑅𝑒𝑐𝑎𝑙𝑙 𝑜𝑢 𝑇𝑟𝑢𝑒 𝑝𝑜𝑠𝑖𝑡𝑖𝑣𝑒 𝑟𝑎𝑡𝑒 (𝑇𝑃𝑅) = 𝑇𝑃

𝑇𝑃 + 𝐹𝑁(3.4)

𝐹𝑎𝑙𝑠𝑒 𝑛𝑒𝑔𝑎𝑡𝑖𝑣𝑒 𝑟𝑎𝑡𝑒 (𝐹𝑁𝑅) = 𝐹𝑁

𝑇𝑃 + 𝐹𝑁(3.5)

True positive rate é também chamada de recall no domínio da recuperação deinformação ou sensitivity na medicina. A soma entre essas duas métricas é igual a 1.Métricas cujo denominador envolve apenas casos que são de fato negativos:

𝑇𝑟𝑢𝑒 𝑛𝑒𝑔𝑎𝑡𝑖𝑣𝑒 𝑟𝑎𝑡𝑒 (𝑇𝑁𝑅) = 𝑇𝑁

𝑇𝑁 + 𝐹𝑃(3.6)

𝐹𝑎𝑙𝑠𝑒 𝑝𝑜𝑠𝑖𝑡𝑖𝑣𝑒 𝑟𝑎𝑡𝑒 (𝐹𝑃𝑅) = 𝐹𝑃

𝑇𝑁 + 𝐹𝑃(3.7)

True negative rate é também chamada de specificity (SPC) no domínio da medicinae false positive rate é chamado de fall-out no domínio de recuperação de informação. Asoma entre essas duas métricas é igual a 1. Métricas cujo denominador envolve apenascasos preditos como positivos:

𝑃𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛 𝑜𝑢 𝑃𝑜𝑠𝑖𝑡𝑖𝑣𝑒 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑣𝑒 𝑣𝑎𝑙𝑢𝑒 (𝑃𝑃𝑉 ) = 𝑇𝑃

𝑇𝑃 + 𝐹𝑃(3.8)

𝐹𝑎𝑙𝑠𝑒 𝑑𝑖𝑠𝑐𝑜𝑣𝑒𝑟𝑦 𝑟𝑎𝑡𝑒 (𝐹𝐷𝑅) = 𝐹𝑃

𝑇𝑃 + 𝐹𝑃(3.9)

10 Em (HARTEMINK, 2014) um simples e bom resumo foi encontrado


Positive predictive value é também chamado de precision no domínio de recuperaçãode informação. A soma entre essas duas métricas é igual a 1. Métricas cujo denominadorenvolve apenas casos preditos como negativos:

𝑁𝑒𝑔𝑎𝑡𝑖𝑣𝑒 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑣𝑒 𝑣𝑎𝑙𝑢𝑒 (𝑁𝑃𝑉 ) = 𝑇𝑁

𝑇𝑁 + 𝐹𝑁(3.10)

Em alguns contextos mais do que uma das métricas apresentadas são importantes,sendo combinadas em uma nova métrica como é o caso das curvas ROC (Receiver operatingcharacteristic) e de F-measure. A primeira advém do contexto de detecção de sinais erepresenta um balanço entre TPR (Equação 3.4) e FPR (Equação 3.7), enquanto a segundaé mais utilizada no contexto de recuperação de informação e representa um balanço entrerecall (Equação 3.4) e precision (Equação 3.8).

Para a detecção de lances de chute a gol TN não é importante (seriam os não-chutes, análogos aos documentos irrelevantes no contexto de recuperação de informação).O que importa é que os lances verdadeiros de chute sejam identificados sem que pra issodiversos lances falsos sejam incluídos como verdadeiros. Isso pode ser expresso através deF-measure, que combina recall, que nos dá uma noção de completude (porcentagem delances corretamente identificados de todos os lances verdadeiros existentes), e precision,que nos dá uma noção de qualidade (porcentagem de lances corretamente identificadosde todos os lances que foram preditos como verdadeiros). Por esses motivos F-measurefoi a métrica de desempenho escolhida para avaliar os modelos gerados nesse trabalho,combinando simplicidade e expressividade.

Em mais detalhes, F-measure é a média harmônica entre recall e precision. Naprática o resultado de sua aplicação é um novo valor que estará mais próximo da menormedida entre recall e precision. Ela é dada pela seguinte equação (WITTEN; FRANK;HALL, 2011):

𝐹 −𝑚𝑒𝑎𝑠𝑢𝑟𝑒 (𝐹1) = 2× 𝑟𝑒𝑐𝑎𝑙𝑙 × 𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛

𝑟𝑒𝑐𝑎𝑙𝑙 + 𝑝𝑟𝑒𝑐𝑖𝑠𝑖𝑜𝑛= 2× 𝑇𝑃

2× 𝑇𝑃 + 𝐹𝑃 + 𝐹𝑁(3.11)

Existem diferentes versões de F-measure que podem ser utilizadas a depender dopeso que se queira dar para recall e precision. Por exemplo, em 𝐹2 o peso de recall édobrado enquanto em 𝐹0.5 é precision que tem o dobro do peso. 𝐹1 (apresentada acima)foi escolhida pois no contexto da detecção de chutes a gol, em que se pretende utilizar osclassificadores criados para medir o desempenho das equipes, deixar de incluir um Shot ontarget que aconteceu, por exemplo, afasta o analisador da visão do desempenho real dotime tanto quanto incluir um Shot on target inexistente.


3.6.2 F-measure para classificadores multiclasse

Recall, precision e consequentemente F-measure, são medidas para classificadoresbinários. Entretanto, o classificador para chutes a gol que foi desenvolvido envolve 4 classes,as 3 classes de chute definidas na seção 2.3 e uma classe falso, para os não-chutes. Todo casodeve ser classificado em apenas uma classe, caracterizando o problema como multiclasse.Uma forma para generalizar F-measure para um problema multiclasse é conhecida como aabordagem um-contra-todos (One-vs-all, OvA), que avalia cada classe individualmentecontra todas as outras agrupadas.

A Tabela 12 mostra um exemplo de OvA para a primeira classe da matriz. Sobreessa matriz adaptada é possível calcular precision, recall e F-measure para a classe 𝐶1.O processo é repetido para cada classe e as métricas para cada uma são obtidas. Paranovamente ter uma única medida para o classificador como um todo, a média de F-measureponderada pelo número de casos verdadeiros em cada classe é calculada.

Tabela 12 – Matriz de confusão um-contra-todos para classe 𝐶1

Classe predita𝐶1 𝐶2 𝐶3 ... 𝐶𝑛

𝐶1 𝑇𝑃 𝐹𝑁 𝐹𝑁 ... 𝐹𝑁𝐶2 𝐹𝑃 𝑇𝑁 𝑇𝑁 ... 𝑇𝑁𝐶3 𝐹𝑃 𝑇𝑁 𝑇𝑁 ... 𝑇𝑁... ... ... ... ... ...

Classe real

𝐶𝑛 𝐹𝑃 𝑇𝑁 𝑇𝑁 ... 𝑇𝑁


Por fim, para definir de modo estatisticamente válido que um classificador ésuperior a outro não basta apenas comparar diretamente os valores de suas métricas. Épreciso aplicar algum teste estatístico para fazer essa afirmação dentro de um intervalode confiança. Um exemplo é o corrected resampled T-Test que pode ser aplicado com oauxílio da ferramenta WEKA (seção 3.7). Normalmente os testes são aplicados com umasignificância de 1% ou 5% (WITTEN; FRANK; HALL, 2011).

3.7 WEKAO WEKA11, criado na Universidade de Waikato na Nova Zelândia, foi a principal

ferramenta utilizada no projeto. Ele é um software open source desenvolvido em Java quecontém uma coleção de algoritmos de aprendizado de máquina no estado da arte e outrasferramentas úteis para as diversas fases do projeto (WITTEN; FRANK; HALL, 2011). OWEKA funciona independente de plataforma e é atualmente uma das ferramentas maisutilizadas em projetos de mineração de dados, apesar de existirem outras opções populares11 Disponível em <http://www.cs.waikato.ac.nz/ml/weka/>

http://www.cs.waikato.ac.nz/ml/weka/


como o R. Suas funcionalidades podem ser acessadas através de uma interface gráficaintuitiva que facilita bastante o processo de mineração.

Essa interface possui 3 divisões. No Explorer, primeira delas, é possível testardiferentes algoritmos de aprendizado nos dados carregados. Uma das limitações do Exploreré que todos os dados são carregados na memória, limitando sua utilização a conjuntosrelativamente pequenos. Já na interface Knowledge Flow é possível conectar diferentesalgoritmos e fontes de dados, possibilitando o processamento de bases de dados maiores. Aúltima interface, Experimenter, permite que diferentes métodos sejam comparados dentroda própria ferramenta, facilitando a escolha das soluções mais eficazes para o problemasendo resolvido.

O Explorer possui uma aba voltada exclusivamente para classificação, onde osalgoritmos de aprendizado contidos no WEKA podem ser aplicados e os resultados obtidosvalidados através de mecanismos como o 10-fold cross-validation estratificado (seção 3.5).A matriz de confusão do classificador pode ser impressa, e o modelo pode ser analisadode acordo com diferentes métricas de desempenho, e em alguns casos, como quandotrabalhando com árvores de decisão, é possível visualizar até mesmo o modelo gerado. AFigura 19 mostra a interface do Explorer com a aba de classificação selecionada.

Figura 19 – Aba de classificação da ferramenta WEKA

Fonte: (Waikato University, 2013)

Segundo os criadores, os recursos mais valiosos do WEKA são as implementaçõesdos algoritmos de aprendizado, seguido de perto pelas ferramentas de pré-processamento(chamadas de filters). Uma flexibilidade interessante é que os algoritmos utilizados no


WEKA podem também ser integrados em aplicações externas através das bibliotecasfornecidas. A entrada dos dados (vetores de características resultante da fase de Preparaçãodos Dados) para realizar a modelagem também é bastante flexível, podendo ser feita viaarquivos ARFF (Attribute-Relation File Format, desenvolvido para ser utilizado peloWEKA), CSV (comma-separated values) ou conexão com bancos de dados.

Nesse projeto o WEKA foi utilizado para auxiliar 5 importantes processos:

• Visualização dos dados: no Explorer existem 2 boas opções de visualização dos dados.Na aba Preprocess é possível visualizar a distribuição das classes de acordo com cadaatributo e na aba Visualize é possível acessar a matriz scatterplot (seção 3.3) paraos dados de entrada;

• Filtragem: na aba Preprocess do Explorer é possível aplicar filtros para alterar osdados de entrada, eliminar linhas, colunas e fazer outras modificações;

• Seleção de atributos: na aba Select attributes, ainda no Explorer, é possível aplicaralgoritmos de seleção automática de atributos;

• Experimentação: no Experimenter é possível realizar experimentações combinando di-ferentes conjuntos de dados e algoritmos de modelagem de forma massiva, facilitandoa tarefa de testar diferentes cenários;

• Avaliação dos resultados: na aba Analyse do Experimenter os resultados dos experi-mentos executados podem ser comparados utilizando diversas métricas de desempe-nho (seção 3.6) e testes estatísticos.

Seus criadores escreveram um livro que além de ser uma referência sobre o processode mineração como um todo, cobre amplamente a utilização da ferramenta, é o DataMining: Practical Machine Learning Tools and Techniques (WITTEN; FRANK; HALL,2011). A Universidade de Waikato oferece também o curso online Data Mining with WEKA(WITTEN, 2013), ministrado por um dos autores do livro.

Parte II

Projeto

79

4 Fase 1: Compreensão do problema

O projeto segue a metologia CRISP-DM e possui as 6 fases descritas na seção 3.1.O restante da monografia descreve a execução de cada fase em um capítulo. A principaltarefa da primeira fase é identificar claramente os objetivos do projeto. O primeiro passo foia compreensão do estado da arte na 2D em relação a coleta automatizada de estatísticas. Atese de doutoramento de Abreu (2010) foi identificada como o principal trabalho relacionadotanto por validar as estatísticas coletadas quanto por coletar diversas estatíticas sobrecada partida.

A partir do trabalho de Abreu foi identificado que o principal risco para se construiruma ferramenta de coleta de estatísticas robusta e completa seria conseguir extrairconhecimento em lances ambíguos, caracterizados principalmente por altas chances dedisputa de bola e envolvimento de muitos jogadores numa pequena área do campo. Issofoi demonstrado pelo baixo desempenho das heurísticas criadas em (ABREU, 2010) paracoletar os 3 tipos de chutes a gol definidos e pela análise que o próprio autor faz em(ABREU et al., 2011). Os resultados de Abreu foram analisados na seção 1.4.

A partir da compreensão desse risco o Objetivo de Pesquisa (equivalente ao “Obje-tivo de Negócio” na CRISP-DM) foi definido como: Investigar a viabilidade de construçãode uma ferramenta de coleta automatizada de estatísticas de alto nível para o ambientede futebol simulado Robocup 2D, utilizando técnicas clássicas de mineração de dados parasuperar os problemas na detecção de métricas relacionadas a chutes a gol descritos naliteratura.

A partir desse objetivo foi verificada a viabilidade do projeto. O principal pontoa ser checado era a disponibilidade de dados históricos que fossem representativos doproblema. Como todos os anos a Robocup promove um evento mundial onde as principaisequipes de pesquisa se encontram e disputam diversas partidas num torneio, e como todasessas partidas são logadas pelo servidor, a escolha natural foi utilizar os logs do últimomundial (no caso, ocorrido entre junho e julho de 2013 em Eindhoven, Países Baixos)1.

O mundial é uma excelente fonte por reunir os binários mais atualizados das equipes,20 em 2013, gerando ao todo 180 partidas oficiais, garantindo 4,6 gigas de dados com muitaqualidade e diversidade. O mundial também é bom por ser uma fonte regular para novosdados, característica importante para permitir atualizações dos modelos gerados. Por fim,usar dados recentes de partidas reais das equipes participantes do mundial teve também aintenção de levantar o interesse da comunidade científica envolvida pelos resultados da1 O trabalho foi finalizado pouco antes do mundial de 2014 ocorrer, durante o mês de julho em João

Pessoa, Brasil

Capítulo 4. Fase 1: Compreensão do problema 80

pesquisa, já que ela permite insights sobre o desempenho de suas equipes.

Estudado o estado da arte na 2D (seção 1.4) e no futebol real (seção 2.2) foi definidoo Objetivo de Mineração: Desenvolver um classificador para as 3 métricas de chute a goldefinidas pela Opta, utilizando os logs da Simulação 2D da Robocup 2013, alcançando umF-measure superior a 0,90. Esse objetivo foi definido por aproximar o grau de sucessona detecção de chutes a gol das outras métricas reportadas em (ABREU et al., 2011). AFigura 20 dá uma visão geral do processo mostrando todas as etapas e transformaçõesocorridas nos dados até se chegar aos classificadores desejados.

Figura 20 – Metodologia do projeto: dos dados aos resultados


Por fim, as ferramentas utilizadas no projeto também foram definidas nessa fase.Diversos programas foram criados para realizar as transformações nos dados. Eles foramcodificados com a linguagem de programação C++ de modo a facilitar a reutilização debibliotecas relacionadas à Simulação 2D. Os programas foram criados utilizando a IDEEclipseCDT versão Kepler Service Release 2, e compilados utilizando o GCC 4.7.3. parao Linux/Ubuntu 13.04. Para criação de scripts foi utilizado o GNU Bash 4.2.45. Para

Capítulo 4. Fase 1: Compreensão do problema 81

armazenamento intermediário dos dados foi utilizado o PostgreSQL 9.3.4, assim como abiblioteca libpqxx 4.0.1, que é um conector C++ para o PostgreSQL.

Os componentes da 2D utilizados para estudar o servidor, assistir partidas edesenvolver os programas foram o rcssserver-15.2.2, rcsslogplayer-15.1.0 e a librcsc-4.1.02.Foram também utilizados trechos do código do time de Simulação 2D Bahia2D (baseadono UvA Trilearn (BOER; KOK, 2002)), time desenvolvido pelo grupo de pesquisa ACSO3.A versão do WEKA, ferramenta de modelagem já apresentada na seção 3.7, foi a 3.6.11.Para gerenciar a parte prática do projeto foi utilizada a ferramenta web Trello, paragerenciar a pesquisa foi utilizado o Mendeley Desktop e para criar diagramas foi utilizadaa ferramenta web LucidChart.

2 Pode ser baixada em <http://pt.sourceforge.jp/projects/rctools/>3 Time que o autor integrou de 2007 a 2010, conhecendo bem o código

http://pt.sourceforge.jp/projects/rctools/

82

5 Fase 2: Compreensão dos dados

O principal objetivo dessa fase foi consolidar o conhecimento sobre o domíniodo problema, fundamental como mostra (FAYYAD; PIATETSKY-SHAPIRO; SMYTH,1996):

Finally, and perhaps one of the most important considerations, is priorknowledge. It is useful to know something about the domain —what arethe important fields, what are the likely relationships, what is the userutility function, what patterns are already known, and so on.1

O passo que marcou a transição da primeira para a segunda fase foi a coleta dosdados2. A partir dos dados foram realizados dois processos: uma análise qualitativa apartir da reprodução de partidas no LogPlayer, e a análise e descrição dos dados brutos.Essas atividades serviram de entrada para o último processo dessa fase, a seleção do espaçoamostral. A Figura 21 esquematiza as atividades dessa fase.

Figura 21 – Fase 2: Compreensão dos dados


1 “Finalmente, e talvez uma das mais importantes considerações, é conhecimento prévio. É útil saberalgo sobre o domínio — quais são os campos importantes, quais são as relações prováveis, qual é afunção de utilidade do usuário, quais padrões já são conhecidos, e assim por diante.” (Tradução doautor)

2 Os logs se encontram disponíveis em (ROBOCUP, 2013b), mas vale notar que o site estava fora do arna última checagem realizada, em 04 julho de 2014

Capítulo 5. Fase 2: Compreensão dos dados 83

5.1 Análise qualitativa dos logsPara se familiarizar com os lances que seriam detectados, observar o estilo de chute

das diferentes equipes e compreender os cenários em que eles ocorrem foram selecionados30 logs para serem assistidos através do LogPLayer. A seleção dos logs garantiu que seriamassistidas partidas de todos os times contra equipes de diferentes níveis. Para isso os 20times que participaram do mundial foram divididos em 3 categorias de acordo com as suasposições finais no torneio3(Tabela 13): fortes, médios e fracos.

Tabela 13 – Divisão dos times da Robocup 2013

Fortes Médios Fracos1. WrightEagle 7. AUT 14. UTAustinVilla2. HELIOS2013 8. Cyrus 15. GPR-2D3. YuShan2013 9. GDUT_Tiji2013 16. WarthogRobotics4. Axiom 10. FC-Perspolis 17. CSU_Yunlu20135. Gliders 11. LegenDary 18. ThunderBots6. Oxsy 12. FCPortugal 19. HfutEngine2013

13. ITAndroids 20. Ri-one


A partir da observação dos jogos foi criado um documento descrevendo as equipese os chutes na Simulação 2D4, destacando os jogos em que ocorriam chutes incomuns oude difícil detecção. Alguns detalhes que chamaram a atenção:

• Chutes para o gol usando o tackle são mais comuns do que se esperava;

• Chutes de longe (fora da área) são incomuns;

• Equipes fortes só chutam quando tem uma grande certeza do gol pois a ausênciada altura dificulta para os atacantes, mesmo com uma maior largura do gol (comodescrito na subseção 1.2.2.1);

• Entre os lances ambíguos os mais comuns são bolas divididas e passes que podemser considerados chutes;

• O modelo de chute da 2D, apesar dos ruídos inseridos, ainda cria um chute muitomais preciso (que vai próximo de onde o jogador deseja) do que no futebol real.

5.2 Análise objetiva e descrição dos dadosNessa etapa o ambiente da 2D foi estudado e o principal resultado desse processo é

a documentação detalhada no Capítulo 1. Dois acréscimos que podem ser feitos é sobre a3 Disponível em <http://www.oliverobst.eu/research/robocup/rc2013-simleague-2d/>4 Disponível em <http://bit.ly/AnaliseQualitativa>

http://www.oliverobst.eu/research/robocup/rc2013-simleague-2d/

http://bit.ly/AnaliseQualitativa


organização dos dados e sobre quais as informações mais importantes disponíveis em cadalog. Sobre a organização, são 6 grupos principais de dados:

• Parâmetros do servidor: se relacionam a partida como um todo e inclui dados comoaceleração e velocidade máxima da bola, tempo de jogo, variações nas regras evelocidade máxima dos jogadores;

• Parâmetros dos heterogêneos: delta de valores que originam os atributos dos jogadoresheterogêneos (subseção 1.2.2.5);

• Jogadores heterogêneos: conjunto dos atributos para os 18 jogadores heterogêneosgerados para a partida;

• Bola a cada ciclo: velocidade e posição;

• Jogadores a cada ciclo: velocidade, posição, estado do jogador e outros dados;

• Dados sobre estado do jogo a cada ciclo: playmode, tempo e o placar.

Os parâmetros dos heterogêneos são um conjunto descartável, pois só importamos heterogêneos que de fato foram gerados para cada partida. Todos os outros grupospossuem informações importantes mas as principais para a detecção de chutes a gol sãoposição e velocidade dos jogadores e da bola a cada ciclo, e a variável state dos jogadores.A existência dessa última nos logs RCG foi fundamental para uma melhor detecção doslances, uma vez que entre seus registros está incluso, por exemplo, se um jogador chutouou deu carrinho. State é um número hexadecimal disponível todo ciclo para cada jogadore que pode representar qualquer conjunto das seguintes situações:

• DISABLE = 0x00000000: jogador desconectado da partida;

• STAND = 0x00000001: jogador de pé;

• KICK = 0x00000002: jogador chutou no ciclo anterior;

• KICK_FAULT = 0x00000004: jogador chutou no ciclo anterior sem a bola estar emsua área chutável;

• GOALIE = 0x00000008: jogador é goleiro;

• CATCH = 0x00000010: jogador agarrou a bola com a mão no ciclo anterior;

• CATCH_FAULT = 0x00000020: tentou agarrar com as mãos uma bola fora do seualcance no ciclo anterior;

• BALL_COLLIDE = 0x00000400: jogador colidiu com a bola no ciclo atual;


• PLAYER_COLLIDE = 0x00000800: jogador colidiu com outro jogador no cicloatual;

• TACKLE = 0x00001000: jogador está no chão após realizar um carrinho em algumciclo anterior;

• TACKLE_FAULT = 0x00002000: jogador está no chão pois executou um carrinhosem sucesso em algum ciclo anterio;

• POST_COLLIDE = 0x00010000: jogador colidiu com alguma trave no ciclo atual;

• FOUL_CHARGED = 0x00020000: jogador está caído após receber um carrinho emalgum ciclo anterior;

• YELLOW_CARD = 0x00040000: jogador recebeu cartão amarelo;

• RED_CARD = 0x00080000: jogador recebeu cartão vermelho.

Importante notar que os lances que envolvem tackle não necessariamente ocorreramno ciclo imediatamente anterior pois os jogadores ficam no mesmo estado por algunsciclos após a jogada, sendo necessário recorrer a contagem de comandos para determinar omomento exato que um tackle foi executado.

Por fim, um padrão já estudado anteriormente foi resgatado, referente a velocidadeda bola em lances de chute do time Bahia2D. A Figura 22 mostra uma plotagem sobrepostadas velocidades da bola em chutes contra diferentes equipes (cores das barras). Esse estudodeixou claro que em geral há uma diferença entre as velocidades da bola em cada tipo delance, com o primeiro pico (velocidades próximas de 0,0) representando domínios de bola,o segundo pico (por volta de 0,5) representando conduções de bola e o último grupo (de 1,5a 2,6, bem separado do resto por um pequeno vale destacado em vermelho) representandochutes a gol e passes. Essa análise demonstrou o potencial de incluir velocidade da bolalogo após o toque de um jogador como característica importante para detectar chutes agol.

5.3 Seleção do espaço amostralReduzir o conjunto dos 180 jogos iniciais era fundamental para tornar viável a

classificação manual, processo da fase 3, Preparação dos Dados. A seleção do espaçoamostral seguiu a mesma ideia de cruzar todos os times contra adversários de força variadautilizada para selecionar os jogos da análise qualitativa (seção 5.1). Entretanto, priorizoua inclusão de jogos que já haviam sido assistidos e possuiam lances importantes. Essecritério busca garantir que os mais diversos tipos de chute a gol estejam representados noconjunto final. Os passos seguidos foram:


Figura 22 – Estudo sobre a velocidade da bola em chutes do time Bahia2D


1. Jogos marcados durante a análise qualitativa como importantes (por possuíremlances difíceis ou raros) foram incluídos primeiro. 11 jogos pareados (em que os 2times envolvidos ainda não tinham adversário com força correspondente) e 1 sempar foram incluídos por esse critério;

2. Em seguida, foram acrescentados jogos de acordo com a disponibilidade, de modoque o melhor time do grupo dos fortes enfrentasse o melhor time disponível decada grupo (Tabela 13), e assim sucessivamente até todos os jogos possíveis estarempareados. 16 jogos pareados foram escolhidos com esse critério;

3. Mais 5 jogos sem par foram adicionados para garantir que todos os times tivessempelo menos 1 adversário de cada grupo;

4. Jogos do Round 0 da competição, que é uma rodada de testes, foram evitados poisos times poderiam não estar com o seu melhor binário. Houve apenas 1 exceção nocaso do time Ri-one, que só cruzou com um time do grupo dos fracos nesse Round;

5. Nos casos do passo 2 em que havia mais de um jogo entre um determinado par foidada preferência para jogos no Round do torneio que tinham menos jogos escolhidos(o que ajudou a ter mais jogos das fases finais).

Esse processo resultou em um espaço amostral final com 33 jogos (27 pareados e 6sem par), pouco mais do que 1/6 dos jogos disponíveis, e garantiu que todos os 20 times


fossem incluídos como fonte de dados em partidas com adversários de 3 níveis diferentes(forte, médio e fraco). O Apêndice A informa quais os logs selecionados.

88

6 Fase 3: Preparação dos dados

A seleção do espaço amostral marca a transição para essa fase. O principal objetivoaqui foi gerar os vetores de características (conjunto de dados de tamanho fixo querepresentam os casos de chute) a partir dos logs RCG selecionados. É a partir dessesvetores que os algoritmos de aprendizado constroem modelos que representam conhecimentosobre os logs. Classificação é uma tarefa de aprendizado supervisionado, o que significaque cada vetor de característica precisa ter sua classe determinada previamente, o quetambém foi feito nessa fase.

Essa foi a etapa mais trabalhosa do projeto, o que é comum em processos deKDD (Two Crows, 2005): “Data preparation is by far the most time-consuming aspect ofdata mining. Everything a tool can do to ease this process will greatly expedite modeldevelopment”1. As transformações realizadas nessa fase podem ser vistas na Figura 23. Orestante desse capítulo apresenta cada uma dessas transformações nos dados.

Figura 23 – Fase 3: Preparação dos dados


6.1 Carga do Repositório IntermediárioA primeira transformação nos dados foi sair do formato texto dos RCGs para uma

representação em banco de dados, mais estruturada e durável, para que os dados estivessem1 “Preparação de dados é de longe o aspecto de mineração de dados que consome mais tempo. Tudo

que uma ferramenta puder fazer para facilitar esse processo irá acelerar bastante o desenvolvimento demodelos.” (Tradução do autor)

Capítulo 6. Fase 3: Preparação dos dados 89

disponíveis e flexíveis para as etapas subsequentes. Para realizar essa transformação foicriado o programa RCG2DB, que recebe um arquivo de log como parâmetro e o persistenum banco com a estrutura mostrada na Figura 24. Apenas as principais colunas sãodescritas nesse diagrama.

Figura 24 – Diagrama ER do Repositório Intermediário


Para criar o RCG2DB o código do LogPlayer foi estudado para que o mesmo parserfosse reutilizado. Apesar do esforço empreendido, uma vez que há pouca documentaçãodisponível e boa parte dos exemplos estão desatualizados, fez-se questão de usar o mesmoparser para minimar a possibilidade de inserir ruídos aos dados nessa etapa, uma vez queos códigos das ferramentas oficiais já foram amplamente testados.

Para tratar os dados o LogPlayer possui uma classe Parser que trabalha em conjuntocom uma interface chamada Handler. O Parser é responsável por quebrar as entradas no log,compor objetos que organizam esses dados e passá-los para o Handler. A implementaçãoconcreta de Handler é que define o que será feito com os dados. No LogPlayer existemalgumas utilizações distintas de Handler, como para converter os logs de uma versão paraoutra ou escrevê-lo em XML. O Diagrama de Classes do RCG2DB é visto na Figura 25,as classes reutilizadas em amarelo.


Figura 25 – Diagrama de Classes do RCG2DB


A classe PersistRCGHandler é a implementação concreta de Handler criada. Ela possuiuma referência para um objeto da classe Holder e para um objeto da classe Persister. Holderrecebe as informações do log a medida que elas vão sendo extraídas, sendo responsávelpor manter em memória todos os dados do log. Após todo o arquivo de log ser lido,uma referência de Holder é passada para o método persist, que se conecta ao banco e fazo carregamento dos dados. Persister é uma interface genérica para tornar fácil a trocado método de persistência. Nesse caso, PersistPostgresDB foi a implementação concretautilizada. Ela é uma classe que faz uso da biblioteca libpqxx para acessar o PostgreSQL.

Como RCG2DB só persiste 1 log de cada vez, foi criado um script em bash parabuscar todos os arquivos RCG numa árvore de diretórios e chamar o RCG2DB para cadaum. Apesar do espaço amostral já estar definido, decidiu-se por carregar todos os logs nobanco para qualquer eventualidade. O carregamento completo levou cerca de 3 horas paraser finalizado. A tabela mais larga é tb_server_param com 193 colunas, e a mais extensa étb_player com 26.384.556 linhas2.

6.2 Seleção de casos candidatosDurante a maior parte de uma partida não estão ocorrendo chutes a gol. Isso

significa que a maior parte do log não interessa para o projeto. Para selecionar apenas oslances de interesse foi criado o programa ShotCandidatesDetector. A principal preocupaçãofoi garantir que todos os lances possíveis de serem chutes a gol fossem incluídos, semexceções. A contrapartida é que a maior parte dos lances potenciais são na verdade falsoscandidatos. Isso foi tratado no pré-processamento da fase de modelagem (seção 7.1).

O princípio para identificar um chute a gol é o mesmo definido em (ABREU, 2010):chutes dados no campo de ataque, na direção geral do gol (até o limite da grande área) e2 Todo o código do RCG2DB, assim como os scripts bash e de criação do esquema do banco estão

disponíveis em <http://bit.ly/carregamentoRI>

http://bit.ly/carregamentoRI


com força suficiente para cruzar a linha de fundo. Essa mesma definição geral é importantepara que os resultados alcançados possam ser comparados com os de Abreu. O Diagramade Classes do detector é mostrado na Figura 26.

Figura 26 – Diagrama de Classes do ShotCandidatesDetector


A classe RCGDAO é responsável por recuperar todos os dados de uma partidae carregar num objeto da classe Holder. Esse objeto é passado para o método run doDetectorManager que é responsável por invocar o método detect de todos os detectoresque tiverem sidos adicionados a ele. Isso permite que diferentes algoritmos de detecçãoencapsulados através da interface Detector sejam executados sobre o mesmo log3. Essaflexibilidade foi criada pensando em futuras extensões da ferramenta, em que outros tiposde eventos precisarão ser detectados.

ShotDetector encapsula o algoritmo de detecção de chutes. Ele varre os ciclos dapartida contida em Holder criando um objeto ShotCandidateT sempre que identifica umcandidato a chute a gol. Todos os candidatos são armazenados num vetor para que no fimsejam impressos num arquivo CSV com o mesmo nome do log. Cada registro de candidatoimpresso no CSV contém as informações: número do candidato, o time ofensivo (team_leftou team_right), o ciclo de início, o ciclo final e o playmode em que o lance termina. Opseudocódigo do método de detecção é descrito no Algoritmo 1.

O algoritmo checa os ciclos em ordem e aos pares para verificar as mudanças queocorreram entre duas cenas subsequentes. Basicamente ele checa por alguns critérios paradefinir se um lance candidato começou e se terminou. Algumas observações:3 Similar ao padrão de projeto Strategy, mas ao invés de intercambiar o algoritmo, todas as versões são

invocadas


Algorithm 1 Algoritmo de seleção de candidatos1: function Detect(ℎ𝑜𝑙𝑑𝑒𝑟) ◁ holder contém todos os ciclos da partida2: 𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑜_𝑎𝑏𝑒𝑟𝑡𝑜← false3: 𝑐𝐴𝑛𝑡← holder.primeiroCiclo() ◁ inicia ciclo anterior4: for all Ciclo 𝑐𝐴𝑡𝑢 em holder do ◁ pega ciclo atual5: if 𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑜_𝑎𝑏𝑒𝑟𝑡𝑜 then ◁ verifica se terminou lance6: if mudouBola(𝑐𝐴𝑛𝑡, 𝑐𝐴𝑡𝑢) || mudouPlaymode(𝑐𝐴𝑛𝑡, 𝑐𝐴𝑡𝑢) then7: registraCandidato()8: 𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑜_𝑎𝑏𝑒𝑟𝑡𝑜← false9: end if

10: end if11: if !𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑜_𝑎𝑏𝑒𝑟𝑡𝑜 then ◁ verifica se abriu lance12: if bolaRolando(𝑐𝐴𝑛𝑡) && mudouBola(𝑐𝐴𝑛𝑡, 𝑐𝐴𝑡𝑢) then13: if bolaRolando(𝑐𝐴𝑡𝑢) then14: if podeAlcançarLinhaDeChute(𝑐𝐴𝑛𝑡, 𝑐𝐴𝑡𝑢) then15: 𝑐𝑎𝑛𝑑𝑖𝑑𝑎𝑡𝑜_𝑎𝑏𝑒𝑟𝑡𝑜← true ◁ caso normal, fecha depois16: end if17: else18: if saiuPelaLinhaDeChute(𝑐𝐴𝑛𝑡, 𝑐𝐴𝑡𝑢) then19: registraCandidato() ◁ caso especial, registra logo20: end if21: end if22: end if23: end if24: 𝑐𝐴𝑛𝑡← 𝑐𝐴𝑡𝑢 ◁ atualiza ciclo anterior25: end for26: end function

• Um candidato sempre se inicia em lance de bola rolando (playmode igual play_on),uma vez que não existe tiro livre direto ou penâlti no meio de uma partida naSimulação 2D;

• O método mudouBola nas linhas 6 e 12 é um dos principais componentes. Ele verificase entre os ciclos houve alguma influência externa na posição ou velocidade da bolaconsiderando os ruídos naturais inseridos pelo servidor;

• Uma mudança no comportamento esperado da bola indica que ela passou por pelomenos um dos seguintes eventos: kick, tackle, catch, colisão com jogador, colisão comtrave ou mudança de posição feita pelo juiz;

• No for, primeiro é checado o fechamento para depois ser checada a abertura pois umevento que finaliza um lance candidato pode ser o mesmo evento que inicia outro;

• O método podeAlcançarLinhaDeChute projeta a bola ciclo a ciclo de acordo com asequações de movimento do servidor apresentadas na subseção 1.2.2.2. Ele tambémconsidera os ruídos inseridos de modo que a posição da bola é uma área e não um


ponto. Se qualquer parte dessa área projetada a cada ciclo alcançar a linha de chute(linha de fundo, entre os limites da grande área) o método retorna true;

• A linha 17 trata um caso especial. Uma particularidade descoberta sobre o servidoré que ele não deixa a bola sair do campo (Figura 27). Se ele verifica que a bola vaipra fora já reposiciona a bola para a jogada devida e altera o playmode. Por contadisso pode ocorrer um lance em que um jogador próximo da linha de fundo envieum comando de chute no ciclo 𝑡, e no ciclo 𝑡 + 1 a bola simplesmente já reapareçareposicionada pelo servidor e com um novo playmode, sem a bola sequer aparecerem alguma cena sobre o efeito desse chute;

• Esses casos especiais são os únicos em que um lance candidato pode durar apenas 2ciclos, sendo aberto e fechado na mesma passagem pelo for. Nesses casos a verificaçãode que a bola saiu pela linha de fundo é feita usando uma abordagem alternativade acordo com o playmode final do lance e posição da bola no ciclo anterior. Esseslances com 2 ciclos também precisaram de tratamentos especiais em alguns processossubsequentes;

• Para construção do detector de chutes foi utilizada a parte geométrica da librcsc4.1.0.

Figura 27 – Cenas subsequentes sem a bola fora: exemplo de candidato com 2 ciclos

(a) Ciclo 3976: Bola será chutada para fora (b) Ciclo 3977: Já aparece no tiro de meta


Para testar o algoritmo, 4 jogos completos foram checados lance a lance, além dediversas visualizações ad hoc. Um script bash foi criado para a detecção ser realizada emtodos os 33 logs do espaço amostral. No total foram detectados 1488 candidatos, porémlances que terminaram em impedimento ou falta foram pós-filtrados, pois as métricas de


chute não devem ser contabilizadas nesses casos. Com 22 candidatos filtrados por essecritério restaram 1466 candidatos, uma média de 44,42 por jogo4.

Figura 28 – Lances e respectivas decisões do algoritmo de detecção de candidatos

(a) Cena de lance candidato (b) Cena de lance descartado


6.3 Edição de logsA tarefa de classificação manual é bastante custosa em tempo. Para torná-la mais

objetiva e permitir uma análise mais focada foi criado um editor de logs, chamado deRCGCutter, para que apenas os trechos de interesse precisassem ser analisados. Ele cortaos logs reutilizando a classe Serializer que é usada pelo servidor para gerar os logs. Cadalance é cortado de acordo com os ciclos iniciais e finais presentes nos arquivos CSV geradosna seleção de candidatos, mais uma quantidade parametrizável de ciclos extras que ajudamna compreensão do contexto em que o lance ocorreu. A Figura 29 mostra o Diagrama deClasses do RCGCutter, o componente reutilizado em amarelo.

A classe RCGCutter recebe um ostream que é o novo arquivo de log que deve gerar,um istream que é o arquivo CSV com os candidatos e um int que é a quantidade de ciclosextras. As informações do log são recuperadas em um objeto Holder e passadas para eleatravés do método cutRCG que restaura os candidatos e gera um novo log editado comauxílio do RCGSerializerV5, objeto que compõe RCGCutter. Para editar todos os logs foinovamente utilizado um script bash. A saída desse processo são os 33 arquivos de log doespaço amostral devidamente editados5.4 O código do ShotCandidatesDetector, o script em bash e todos os 33 arquivos CSV gerados se

encontram disponíveis em <http://bit.ly/DeteccaoCandidatos>5 O código do RCGCutter, assim como o script bash e todos os logs editados se encontram disponíveis

em <http://bit.ly/EdicaoLogs>

http://bit.ly/DeteccaoCandidatos

http://bit.ly/EdicaoLogs


Figura 29 – Diagrama de Classes do RCGCutter


6.4 Classificação manualA partir dos logs editados e dos arquivos CSV com os lances candidatos, os 1466

lances foram analisados cuidadosamente e classificados manualmente. A classificação foirealizada pelo próprio autor, que trabalhou durante 4 anos com o time de simulaçãoBahia2D, participando de 2 mundiais e 4 competições nacionais, acumulando experiênciasobre o domínio do problema. Essa é uma alternativa comum em casos de aprendizadosupervisionado (Two Crows, 2005): “Sometimes an expert classifies a sample of the database,and this classification is then used to create the model which will be applied to the entiredatabase”6.

Além dos 3 tipos de chute, os falsos candidatos também receberam uma classificaçãomais específica do que apenas “falso” (como domínio de bola, passe em enfiada), de modoa criar uma melhor compreensão sobre os não-chutes e entender como diferenciá-los. Paraclassificar os lances os logs editados foram assistidos no LogPlayer e a classe de cadacandidato foi anotada no próprio CSV (Figura 30). As funções do LogPlayer de projetar abola, de mostrar os comandos enviados pelos agentes e de permitir assistir ao log ciclo aciclo foram muito úteis no processo.

Ao final, para minimizar os ruídos inseridos no processo e aumentar a consistênciada classificação (lances similares serem avaliados seguindo os mesmos critérios), todaa classificação foi revisada. Isso foi especialmente importante nos lances ambíguos, porexemplo, passes fortes em direção ao gol e bolas divididas. Informações sobre os 1466lances classificados são resumidas na Tabela 147.

Dos 293 lances de chute, 74% foram Shot on target, 13,7% foram Blocked shot e12,3% foram Shot off target. Uma comparação com as classes similares da classificaçãomanual em (ABREU et al., 2011) (20,7%, 45,2% e 33,1% respectivamente, dados na6 “Algumas vezes um especialista classifica uma amostra do banco de dados, e essa classificação é então

usada para criar o modelo que será aplicado no banco de dados inteiro” (Tradução do autor)7 O mapeamento completo pode ser acessado em <http://bit.ly/MapeamentoClassificacaoManual>

http://bit.ly/MapeamentoClassificacaoManual


Figura 30 – Lance de Shot on target sendo visualizado e classificado


Tabela 14 – Resumo dos casos na classificação manual

Classe Total MédiaPositivos

Shot on target 217 6,58Blocked shot 40 1,21

Shot off target 36 1,09Métricas derivadas

Goals 169 5,12Chance conversion - 0,66Shooting accuracy - 0,85

Negativos mais comunsCondução de bola 488 14,79Domínio de bola 191 5,79

Passe direto 128 3,88Resumo

Positivos 293 8,88Negativos 1173 35,55

Total 1466 44,42


Tabela 7) ressaltam as diferenças entre a definição utilizada por Abreu e a da Opta,apontadas na seção 2.3. Por exemplo, enquanto aqui bolas defendidas pelo goleiro (lancecomum) são Shot on target, em Abreu elas são Intercepted shot, explicando em parte amaior quantidade de Shot on target encontrados aqui8.8 Em <http://bit.ly/CandidatosClassificados> estão disponíveis os 33 arquivos CSV com os candidatos

classificados

http://bit.ly/CandidatosClassificados


6.5 Engenharia de característicasA última etapa antes de iniciar a modelagem é construir o vetor de características

sobre os quais os algoritmos de aprendizado supervisionado criam os modelos. Ele é umvetor de tamanho fixo com N atributos que representam um objeto, no caso, os candidatosa chute. O principal desafio dessa etapa foi definir chutes a gol, que podem ser lances comvariadas configurações e diferentes durações (de 2 a 50 ciclos), em termos de um conjuntofixo de atributos.

Além disso os dados originais não representam nada diretamente em termos dechutes a gol, sequer existe a informação de onde fica o gol nos dados do log. Essas relaçõesmais representativas precisaram ser derivadas dos dados originais. Conhecimento sobre odomínio do problema foi utilizado para realizar a seleção e extração das características.Esses processos são fundamentais também por reduzir a dimensionalidade do problema,uma vez que os dados dos logs possuem muitas colunas e registros, grande parte irrelevante.(FAYYAD; PIATETSKY-SHAPIRO; SMYTH, 1996) sobre alta dimensionadidade:

A high-dimensional data set creates problems in terms of increasing thesize of the search space for model induction in a combinatorially explosivemanner. In addition, it increases the chances that a data-mining algorithmwill find spurious patterns that are not valid in general. Approaches tothis problem include methods to reduce the effective dimensionality of theproblem and the use of prior knowledge to identify irrelevant variables.9

6.5.1 Seleção de características

Durante a criação do algoritmo de detecção de candidatos e a realização daclassificação manual aconteceram os insights sobre como transformar os candidatos emum vetor n-dimensional. Apesar das diferentes durações de um chute a gol, os pontos maisimportantes de um chute são sempre o início e o fim. As movimentações que acontecemenquanto a bola se desloca e ninguém a toca podem ser representadas pelas diferençasentre a cena inicial e final.

Entretanto, como visto na seção 6.2, para capturar todos os detalhes de um toquena bola é importante analisar 2 cenas subsequentes: numa cena a bola está parada eum agente vai executar um comando que influencia a bola, na cena seguinte vemos odeslocamento e velocidade da bola em consequência desse comando. Para cada candidatoforam então selecionadas 2 cenas iniciais e 2 cenas finais:

1. PreKick: cena em que será dado o chute que inicia o candidato (Figura 31a);9 “Um conjunto de dados com muitas dimensões cria problemas em termos do aumento do espaço de

busca para induzir o modelo de um modo exponencial. Além disso, aumenta as chances de que oalgoritmo de mineração de dados encontre falsos padrões que não são válidos em geral. Abordagenspara esse problema incluem métodos para reduzir as dimensões efetivas do problema e o uso deconhecimento prévio para identificar variáveis irrelevantes.” (Tradução do autor)


2. InitKick: primeira cena com a bola em movimento em consequência do preKick(Figura 31b);

3. LastKick: última cena em que bola se desloca em consequência do preKick (Figura31c);

4. PostKick: primeira cena após o final do chute, exemplos são a bola se deslocando emoutra direção ou já posicionada para um escanteio (Figura 31d).

Figura 31 – Exemplo das 4 cenas selecionadas em um caso de Shot on target10

(a) PreKick: ciclo 136 (b) InitKick: ciclo 137

(c) LastKick: ciclo 139 (d) PostKick: ciclo 140


O fato de que o servidor não mostra a bola fora de campo, problema descrito naseção 6.2, atrapalharia a seleção de cenas, pois nos casos em que isso ocorre o LastKicknão representaria o limite do deslocamento da bola. Um lance que termina em escanteio,por exemplo, teria como LastKick uma cena em que a bola está dentro de campo. Para10 O exemplo caracteriza um Shot on target e não Blocked shot pois a bola é bloqueada pelo último

defensor


corrigir essa incongruência os lances que envolviam bola fora foram tratados durante aseleção de características, com a cena com a bola fora sendo adicionada artificialmente.Para isso o movimento da bola foi simulado de acordo com a última cena em que ela estáem campo, e o movimento dos jogadores de acordo com o movimento que eles realizaramno ciclo posterior a saída da bola.

Com esse tratamento, candidatos cuja duração era de apenas 2 ciclos (justamentecasos que envolviam a saída da bola, como mostrado na seção 6.2) passaram a durar 3ciclos. Para candidatos com 3 ciclos, InitKick e LastKick são as mesmas cenas. Todos osdados contidos nos logs relacionados às 4 cenas descritas para cada um dos 1466 candidatosforam selecionados e passados para a extração.

6.5.2 Extração de características

A partir das 4 cenas selecionadas para cada candidato e das informações sobreas flags do campo (Figura 5), 20 características (nominais e numéricas) foram extraídaspara representar chutes a gol. Algumas delas envolvem conhecimento detalhado sobre ofuncionamento do servidor e cálculos geométricos. As numéricas foram:

1. Vel_ball_inK: Velocidade da bola na cena initKick;

2. Dist_ball_prK: Distância da bola pro gol no preKick;

3. Dist_ball_laK: Distância da bola pro gol no lastKick;

4. Diff_dist_prLaK: A diferença entre as distâncias;

5. Ang_goal_prK: O ângulo de abertura entre a bola e as duas traves no preKick;

6. Ang_goal_laK: O ângulo de abertura entra a bola e as duas traves no lastKick. 0caso tenha entrado no gol, 180 caso tenha saído do campo;

7. Diff_ang_prLaK: A diferença entre os ângulos;

8. Cycles_prInK: Quantos ciclos a bola levaria para cruzar a linha de fundo a partirdo preKick;

9. Cycles_laK: Quantos ciclos faltavam para a bola cruzar a linha de fundo no lastKick.0 no caso de já ter cruzado;

10. Goal_line_Y: Valor absoluto do Y do ponto onde a projeção da bola a partir doinitKick cruzaria a linha de fundo;

11. Off_power_prInK: Qual bem posicionado para chutar forte estava o atacante quedeu o principal toque na bola no preKick, dado pela Equação 1.6 e Equação 1.7;


12. Off_bodyG_prInK: Quão bem posicionado para chutar no gol estava o atacante quedeu o principal toque na bola no preKick, dado pelo ângulo do corpo do atacantepara o centro do gol;

13. Def_power_laPoK: Quão bem posicionado para chutar forte estava o defensor nolastKick, dado pela Equação 1.6 e Equação 1.7, ou 3,0 caso o goleiro possa fazer umcatch.

E as nominais foram:

1. On_ball_prK: Quem poderia influenciar a bola no preKick (attack, both, defense ounone);

2. Touched_prInK: Quem de fato tocou a bola no preKick (attack, both, defense ounone);

3. Off_touch_prInK: Qual o principal toque dado pelo time atacante no início do lance(kick, none, tackle);

4. On_ball_laK: Quem poderia influenciar a bola no lastKick (attack, both, defense ounone);

5. Touched_laPoK: Quem de fato tocou a bola no lastKick (attack, both, defense ounone);

6. Def_touch_laPoK: Toque dado pelo defensor para terminar um chute (none, tackle,kick, collision ou catch);

7. Pmode_poK: Playmode no postKick (goal, play_on, corner_kick, free_kick, goal_kickou back_pass).

O fato de existirem características nominais e numéricas restringe a possibilidadede aplicação de alguns algoritmos do WEKA. O último passo é adicionar as classesidentificadas na avaliação manual para cada vetor. Basicamente as 3 classes de chute agol foram repassadas sem alteração, enquanto todas as outras classes receberam o rótulo“falso”. Um arquivo CSV único com os 1466 vetores de características foi gerado nesseprocesso11.11 O CSV com os vetores pode ser baixado em <http://bit.ly/VetoresDeCaracteristicasFinal>

http://bit.ly/VetoresDeCaracteristicasFinal


6.5.3 Criação do vetor de características

Para implementar a seleção e extração de características foi criado o programaFeatureSE. Ele recebe como parâmetro o arquivo com candidatos a chute e o arquivo ondedeve escrever os vetores finais. O código do Bahia2D foi transformado numa bibliotecaestática para que a parte geométrica fosse reutilizada. Alguns componentes de geometriada librcsc4.1.0 também foram utilizados. A Figura 32 mostra o Diagrama de Classes doFeatureSE.

Figura 32 – Diagrama de Classes do FeatureSE


Novamente RCGDAO restaura os dados de um log num objeto da classe Holder.Esse objeto é passado para LocalWorldModel, uma classe com diversos métodos utilitáriospara realizar cálculos geométricos, fazer projeções e cálculos relacionados ao funcionamentodo servidor. LocalWorldModel é composto por WorldModel, classe reutilizada do Bahia2D,que possui também alguns métodos geométricos. FeatureSelector é a classe que faz aseleção dos dados nas cenas e FeatureExtractor a derivação das características finais.Ambas possuem uma referência para o mesmo LocalWorldModel.

FeatureSelector usa LocalWorldModel para fazer os tratamento de bolas fora,criando as cenas extras a partir das cenas originais. Já FeatureExtractor o utiliza para boaparte das derivações de atributos. CsvIO é responsável por ler o arquivo de candidatos eescrever o vetor de características final. FeatureSelector é composto por SelectedFeaturesT,


estrutura que guarda os dados sobre os candidatos e as 4 cenas: preKick, initKick, lastKicke postKick. FeatureSelector cria novos SelectedFeaturesT a medida que vai tratando todosos candidatos que recebe de CsvIO.

Depois de todos os dados estarem selecionados e armazenados em um vetor deSelectedFeaturesT pelo FeatureSelector, eles são passados para o FeatureExtractor, quederiva as características finais e as guarda num vetor de vetores de strings. Por fim oCsvIO recebe as strings com as características finais do FeatureExtractor e as acrescentano final do arquivo definido. O Diagrama de Sequência na Figura 33 mostra as interaçõesentre os objetos principais do FeatureSE. Para realizar a seleção e extração para os 33 logsfoi criado um script bash que lê todos os arquivos de candidatos numa pasta e chama oFeatureSE para cada um deles passando o mesmo arquivo de saída (onde os vetores finaisvão sendo armazenados)12.

Figura 33 – Diagrama de Sequência mostrando as interações principais do FeatureSE


12 O código do FeatureSE e o script de carregamento estão disponíveis em <http://bit.ly/FeatureSE>

http://bit.ly/FeatureSE

103

7 Fase 4: Modelagem

Essa é a fase em que propriamente ocorre o que é tecnicamente chamado demineração de dados ou modelagem. Antes ainda, entretanto, os dados passam por algunspré-processamentos. A Figura 34 mostra as transformações que ocorrem nos dados nessaetapa. Além dessas transformações existe também a visualização e exploração dos vetoresde características, que é a primeira atividade desta fase, parte do pré-processamento.

Figura 34 – Fase 4: Modelagem


7.1 Pré-processamentoAntes dos algoritmos de aprendizado serem aplicados sobre os dados, uma última

etapa de checagem da qualidade dos dados é realizada. Os dados produzidos na fase dePreparação dos Dados são analisados em busca de ruídos, dados discrepantes (outliers),irrelevantes ou redundantes. Tudo para um melhor resultado quando a modelagem forrealizada. Esse processo é conhecido como pré-processamento e foi inteiramente realizadocom o auxílio da ferramenta WEKA.

7.1.1 Visualização e exploração dos dados

A visualização permite aprofundar o conhecimento sobre os dados para tomardecisões sobre filtragem e seleção de atributos. O primeiro passo da visualização é analisaro resumo dos dados. Ele é criado automaticamente pelo WEKA na aba Preprocess aoimportar o CSV com os dados. Para os valores numéricos é possível ver o mínimo, máximo,

Capítulo 7. Fase 4: Modelagem 104

média e desvio padrão de cada característica (Tabela 15). Para os valores nominais épossível ver os totais de cada tipo.

Tabela 15 – Resumo das características numéricas

Característica Mínimo Máximo Média Desvio padrãoVel_ball_inK 0,099 3,126 1,521 0,904Dist_ball_prK 0,634 51,423 14,384 7,381Dist_ball_laK 0,0 39,983 9,821 6,477

Diff_dist_prLaK -11,091 36,983 4,564 5,083Ang_goal_prK 0,278 160,68 29,751 26,002Ang_goal_laK 0,0 180,0 45,99 57,61

Diff_ang_prLaK -125,389 158,942 16,239 43,093Cycles_prInK 1 51 18,762 14,766Cycles_laK 0 51 14,869 15,359

Goal_lineY_inK 0,007 48,963 11,012 6,369Off_power_prInK 0,0 2,7 1,928 0,744Off_bodyG_prInK -100,0 175,172 26,862 57,124Def_power_laPoK 0,0 3,0 0,538 1,011


Uma parte valiosa da visualização fornecida pelo WEKA é a distribuição das classesde chute a gol para cada característica. Os dados sobre velocidade (Figura 36a), porexemplo, mostram que a menor velocidade que indica um chute a gol é por volta de 1,6,confirmando a expectativa criada pelo estudo anterior apresentado na Figura 22. Umgrande volume de falsos se acumulam em lances de bola com baixa velocidade, prováveisconduções e domínios de bola, tornando velocidade um atributo interessante para identificarfalsos candidatos.

Figura 35 – Totais das classes finais


O ângulo final para as traves (Figura 36b) também se mostrou um atributo interes-sante, fazendo uma separação razoável entre Shot on target e Blocked shot, que é um casodifícil. Como bolas bloqueadas geralmente terminam mais longe do gol, consequentemente


Figura 36 – Distribuição das classes por algumas características

(a) Distribuição em função da velocidade

(b) Distribuição em função da ângulo final para as traves

(c) Distribuição em função do posicionamento do atacante


é comum terem ângulos mais fechados. Ele separa bem também os Shot off target dosoutros chutes, pois em chutes para fora o ângulo pro gol fica completamente fechado nofinal (exceto nos casos de bola na trave, que aparecem como uma linha muito fina nascolunas com 13 e 14 ocorrências, em destaque).

A visualização permitiu também perceber que algumas das características finaispouco dizem sobre chutes a gol. O ângulo do corpo do atacante em relação ao centro do


gol, por exemplo, que se esperava influenciar pois denota um atacante melhor posicionado,apresenta proporcionalmente a mesma distribuição de classes independente do ângulo(Figura 36c). Isso se deve ao modelo de chute na 2D, em que a força do chute só dependeda posição da bola em relação ao atacante (Equação 1.6) e não da direção final do chute,permitindo chutes fortes e precisos mesmo com o atacante de costas para o gol.

Outra forma interessante de visualizar os dados provida pelo WEKA é a matrizscatterplot (exemplo com dados de chutes a gol na Figura 16), que permite percebercorrelações entre variáveis. Porém, tirando correlações óbvias como entre os atributos deângulo inicial e final, ou entre os atributos de distância inicial e final, não foram feitasgrandes descobertas. Um dos gráficos mais interessantes da matriz, por separar todos osgrupos relativamente bem e mostrar uma correlação entre ângulo e distância, pode servisto na Figura 37. A visualização garantiu também que os totais para cada classe estavamcorretos, evitando ruídos nos dados por conta de erros de digitação.

Figura 37 – Diferença dos ângulos para as traves x Distância da bola para o gol no lastKick


7.1.2 Filtragem

A partir da visualização alguns filtros foram aplicados no WEKA, ainda na abaPreprocess do Explorer. Os filtros no WEKA são muito poderosos, permitindo que diversastransformações sejam realizadas. Entretanto o único filtro necessário foi o RemoveWithVa-lues, que permite remover casos específicos a partir de valores de alguma característica.


Primeiro os dados discrepantes foram verificados caso a caso. Apenas 1 problema foiconfirmado, um caso em que nenhum jogador estava na bola na cena inicial (On_ball_prKigual a none). O lance é um caso raro em consequência do tratamento para o caso especialdo algoritmo de seleção de candidatos (Algoritmo 1, linha 17), em que a bola acaba saindodentro do limite da grande área devido ao ruído do servidor, após um chute inicial emque ela iria sair em um ponto mais distante. Havia sido observado na análise manual, masacabou não sendo limpo anteriormente.

Pela Figura 35 é possível notar como os dados finais eram desbalanceados, coma grande maioria dos casos sendo da classe falso. Analisando os dados percebeu-se quediversos dos casos falsos poderiam ser eliminados usando alguns valores das variáveisnominais que continham apenas casos falsos. São eles:

1. Bolas cujo toque inicial é dado apenas por algum defensor (Touched_prInK igual adefense), casos de recuos de bola e passes para trás;

2. Bolas cujo toque final é dado por algum atacante (Touched_laPoK igual a attack),casos de condução de bola, por exemplo, que o atacante toca e vai atrás da bolapara tocar novamente;

3. Cena final com a bola está dividida (On_ball_laK igual a both), por exemplo, casosde passe que o receptor recebe sob pressão.

O segundo caso representou a principal filtragem. É possível ver o grande volumede casos falsos separados por essa variável na Figura 38. Essas 3 filtragens identificadospoderão futuramente já serem realizadas na etapa de seleção de candidatos, a partir demelhorias no algoritmo de detecção. Isso não foi feito devido ao conhecimento incompletoque se tinha sobre o dado state contido nos logs (que mostra o estado dos jogadores,discutido na seção 5.2) durante a criação do algoritmo de detecção de candidatos.

As filtragens eliminaram 1060 casos falsos, deixando 406 candidatos num conjuntode dados muito mais balanceado (Figura 39).

7.1.3 Seleção de atributos

Enquanto na filtragem casos inteiros foram eliminados (linhas), na seleção deatributos o objetivo foi criar algumas variações de conjuntos de dados a partir da eliminaçãode algumas características (colunas). Ao todo foram criadas 9 variações em cima do conjuntocom 406 casos e 20 características. 2 delas foram criadas utilizando conhecimento sobreo domínio do problema e as observações feitas na exploração dos dados. Outras 7 foramcriadas aplicando algoritmos de seleção automática que compõe a ferramenta de seleçãode atributos do WEKA (na aba Select Attributes do Explorer).


Figura 38 – Exemplo de casos filtrados


Figura 39 – Conjunto final mais balanceado após filtragens


Para o primeiro caso criado usando conhecimento sobre o domínio a abordagem foieliminar os piores atributos, aqueles que demonstraram representar pouco sobre chutes agol ou que após a filtragem fariam pouco sentido em serem mantidos. Foram eliminadas 8características segundo esse critério. A segunda abordagem foi apenas deixar os melhoresatributos, onde os 7 que foram considerados mais representativos foram mantidos.

Para as abordagens automáticas foram testados os algoritmos de avaliação desubconjunto Cfs e Consistency (com o método de busca exhaustive), e os algoritmos deavaliação de atributos individuais InfoGain, GainRaio, OneR, Relief e Symmetrical (commétodo de busca ranked). Mais sobre os métodos de seleção de atributos disponíveis noWEKA em (WITTEN; FRANK; HALL, 2011).

A Tabela 16 apresenta os atributos escolhidos nas abordagens que tiveram mais


sucesso (conjuntos sobre os quais foram gerados modelos com as maiores médias ponderadaspara F-measure). Os atributos escolhidos estão marcados com ’x’ ou com o número querepresenta sua posição quando o método de busca ranked foi utilizado. Esse processoproduziu 10 arquivos ARFF1 com variações de conjuntos de dados para serem testadosdurante a modelagem.

Tabela 16 – Variações nas características finais

Original Sem piores Só melhores Consistency InfoGain SymmetricalVel_bal_inK x

Dist_ball_prK x xDist_ball_laK x x x 2 2

Diff_dist_prLaK xAng_goal_prK x 10 8Ang_goal_laK x x 1 1

Diff_ang_prLaK x x 3 3Cycles_prInK x x x 7 7Cycles_laK x x 5 5

Goal_lineY_InK x x 6 6On_ball_prK x

Touched_prInKOff_touch_prInKOff_power_prInKOff_bodyG_prInK

On_ball_laKTouched_laPoK x

Def_touch_laPoK x x x 8 10Def_power_laPoK 9 9

Pmode_poK x x x 4 4


7.2 ModelagemA modelagem começou com a realização de alguns simples testes no Explorer do

WEKA para ter as primeiras noções sobre a qualidade dos modelos que poderiam sergerados. Existia uma grande expectativa sobre a etapa de modelagem mas ela acabouse revelando anticlimática, pois logo nos primeiros testes alguns resultados promissoresapareceram, já acima do baseline de Abreu. De todo modo, testes mais organizados foramrealizados para se obter um resultado mais consistente. Foi o momento de sair do Explorerdo WEKA e partir para o Experimenter (onde experimentações massivas podem serrealizadas). Configurar um experimento no WEKA consiste basicamente de 5 passos:

1. Definir um arquivo onde as informações sobre o processo serão salvas, essas informa-ções são a base para análise dos resultados;

2. Carregar os conjuntos de dados que serão utilizados;1 Arquivos ARFF disponíveis em <http://bit.ly/VariacoesDeDatasets>

http://bit.ly/VariacoesDeDatasets


3. Definir o tipo de experimento, o que está relacionado ao método de validação;

4. Definir quantas iterações serão realizadas, importante para diminuir a variância e seobter um resultado mais confiável;

5. Escolher os algoritmos (e seus parâmetros) que serão aplicados.

Os dados foram os 10 conjuntos preparados no pré-processamento (arquivos ARFF).O tipo de experimento foi 10-fold cross-validation, que na seção 3.5 foi definido comométodo mais adequado, principalmente por permitir utilizar todos os dados disponíveispara criar o modelo. O número de iterações escolhido foi 10, suficiente segundo (WITTEN;FRANK; HALL, 2011).

Sobre os algoritmos, viu-se mais de uma vez na literatura que é difícil definir essaescolha sem experiência prévia, como em (FAYYAD; PIATETSKY-SHAPIRO; SMYTH,1996): “Thus, there is no universal data mining method, and choosing a particular algorithmfor a particular application is something of an art”2. Ou em (WITTEN; FRANK; HALL,2011): “Which methods and parameter values work best for the given problem? Thereis usually no way to answer this question a priori”3. Ou ainda em (Two Crows, 2005):“You may not be able to determine which model type is best until you’ve tried severalapproaches” 4.

Por conta disso, na ausência de um método que pudesse guiar alguém menosexperiente na área, e dada a possibilidade criada pelo WEKA de aplicar facilmentediferentes algoritmos e ver na prática os seus resultados concretos, uma abordagemempírica foi escolhida. Todos os algoritmos disponíveis no WEKA que eram aplicáveis aoproblema foram selecionados para serem testados, totalizando 44 algoritmos, divididos em7 categorias: árvores, regras, funções, lazy (preguiçoso), bayes, meta (que utilizam outroalgoritmo como base) e outros (ver o Apêndice B para a lista completa utilizada).

Considerando que foram selecionados 44 algoritmos para serem testados em 10bases, temos 440 modelos gerados; e que cada combinação de algoritmo × base é executada110 vezes (11 por conta da técnica de cross-validation escolhida, iterada 10 vezes), temos atarefa de criação de um modelo sendo repetida 48.400 vezes: 44× 10× 110 = 48.400. Esseprocesso de experimentação completo levou pouco mais de 8 horas para ser completado.

Após análise dos resultados do primeiro experimento, os 5 algoritmos com melhordesempenho foram testados isoladamente com as 4 bases onde os melhores desempenhosocorreram, de modo a obter resultados mais limpos e mais fáceis de serem analisados.2 “Então, não há nenhum método universal de mineração de dados, e escolher um algoritmo particular

para uma aplicação específica é algo como uma arte.” (Tradução do autor)3 “Que métodos e parâmetros funcionam melhor para um dado problema? Normalmente não há nenhum

modo de responder essa questão a priori.” (Tradução do autor)4 “Você pode não ser capaz de determinar que tipo de modelo é melhor até que você tenha tentado

várias abordagens.” (Tradução do autor)


Figura 40 – Experimento configurado e pronto para ser executado


Nesse último experimento, foi mantido o algoritmo ZeroR, que simplesmente classificatodas as instâncias com a classe de maior ocorrência. Ele serve como baseline interno,permitindo analisar o desempenho dessa estratégia simples no conjunto de dados sendotrabalhado e quanto os outros algoritmos superam essa estratégia5. Os resultados sãodiscutidos na próxima parte da monografia.

5 Em <http://bit.ly/ExperimentosWEKA> estão disponibilizados os arquivos de setup e os dadosgerados pelos experimentos

http://bit.ly/ExperimentosWEKA

Parte III

Resultados

113

8 Fase 5: Avaliação dos resultados

Nesse capítulo os modelos gerados são comparados entre si e um modelo é escolhido.O modelo escolhido é comparado ao baseline de (ABREU et al., 2011). O processo comoum todo é revisado e os objetivos traçados são avaliados em face aos resultados alcançados.

8.1 Comparação entre os modelos criadosO próprio Experimenter do WEKA, na aba Analyse, oferece todo o suporte para

a realização da comparação entre os modelos criados nos 2 experimentos descritos naseção 7.2. Os principais passos para realizar a análise são:

1. Carregar o experimento que se quer analisar;

2. Escolher o tipo de teste estatístico que será utilizado;

3. Escolher a métrica de desempenho que será utilizada na comparação;

4. Escolher a significância estatística;

5. Definir um algoritmo para ser o baseline.

As análises foram realizadas utilizando o Paired T-Tester (corrected), recomendadoem (WITTEN; FRANK; HALL, 2011). A métrica de desempenho utilizada foi a médiaponderada de F-measure, como explicado na seção 3.6. A significância escolhida paracomparar os modelos foi de 5%, valor comum de ser utilizado também segundo (WITTEN;FRANK; HALL, 2011). Visualizar os resultados utilizando diferentes algoritmos comobaseline ajudam na compreensão. A Figura 41 mostra a análise sendo realizada utilizandoo algoritmo meta.LogitBoost como baseline, que foi o que obteve o valor mais alto para amédia ponderada de F-measure, com 0,933.

Nessa análise, além dos 10 conjuntos de dados definidos no pré-processamento, oconjunto original com 1466 candidatos também foi avaliado. Isso mostrou que para esseconjunto desbalanceado, com um grande volume de falsos, mesmo utilizando F-measurecomo base (que é uma boa métrica em conjuntos desbalanceados), o resultado acabariasendo um desempenho exageradamente otimista. Isso se dá devido ao grande volume decasos fáceis de falsos candidatos classificados corretamente quando esse conjunto é usado,elevando a média de F-measure para próximo de 0,98 em alguns casos. Esse grande valorde F-measure porém não é tão representativo para o problema em questão, pois seria um

Capítulo 8. Fase 5: Avaliação dos resultados 114

Figura 41 – Comparação dos modelos sendo realizada no WEKA


aumento forçado pelo peso da classe falso nesse cenário, ao passo que nas 3 classes de fatoimportantes chega a ocorrer uma queda em F-measure.

A questão aqui é que um maior volume de casos falsos corretamente classificados,não representam um melhor clasificador para o problema de chutes a gol: “não-chutes”corretos são irrelevantes. Dos falsos importam apenas os erros cometidos, mas sejameles falsos negativos ou falsos positivos, já entram no cálculo de precision ou recall (econsequentemente F-measure) para as outras classes. Por conta disso, o mais correto éavaliar o F-measure ponderado apenas pelas 3 classes de chute, tirando a influência dovolume de casos falsos corretamente classificados.

Entretanto, como o WEKA não oferece essa possibilidade em sua interface, porpraticidade, na comparação interna entre os 440 modelos gerados foi utilizado o F-measureponderado por todas as classes, o que não é grave uma vez que os 10 conjuntos dedados usados nessa comparação envolvem os mesmos 406 casos. Já na comparação coma literatura, em que é preciso recalcular o valor de F-measure apenas para o modeloescolhido, esse ajuste será feito. Isso é inclusive mais correto para o baseline de (ABREUet al., 2011), uma vez que ele só reporta os valores para as 3 classes de interesse.


Voltando ao WEKA, ele permite visualizar o valor obtido para a métrica dedesempenho por cada algoritmo sobre cada um dos conjuntos de dados. A ferramentafacilita a comparação dos resultados do algoritmo definido como baseline com todosos outros, mostrando se com o intervalo de confiança definido é possível afirmar que oalgoritmo tem um melhor desempenho. Para meta.LogitBoost, por exemplo, apesar de terobtido o melhor resultado, não é possível afirmar estatisticamente, com uma significânciade 5%, que ele é melhor que 14 dos outros 43 algoritmos utilizados. O algoritmo rules.NNgecom 0,9111 de F-measure ponderado, por exemplo, está tecnicamente empatado commeta.LogitBoost com seus 0,933.

O segundo experimento foi analisado com as mesmas configurações. Lembrando, amodelagem foi repetida apenas com os 5 algoritmos que obtiveram os melhores resultadose com o ZeroR para servir de baseline. A Tabela 17 reproduz os resultados. O “v” ao ladode cada valor de F-measure ponderado confirma que o algoritmo supera o baseline. Essesresultados mostram uma grande superioridade desses algoritmos sobre a simples estratégiado ZeroR. Estão destacados em verde os 3 melhores resultados, únicos a ficarem acima de0,93.

Tabela 17 – Resultados do segundo experimento

Dados ZeroR LMT SimpleLogistic ViaRegression LogitBoost MultiClassOriginal 0,3724 0,9328v 0,9328v 0,9210v 0,9188v 0,9066v

Só melhores 0,3724 0,9177v 0,9179v 0,9214v 0,9330v 0,9148vSem piores 0,3724 0,9192v 0,9191v 0,9214v 0,9189v 0,9269vConsistency 0,3724 0,9132v 0,9132v 0,9241v 0,9187v 0,9165v

Average 0,3724 0,9207 0,9208 0,9220 0,9223 0,9162


Vale notar que todos os 5 melhores resultados foram obtidos com algoritmos queutilizam técnicas de regressão como base. Também que o LMT, que é um algoritmo deárvore de decisão que usa regressão logística nas folhas, gera os mesmos modelos queSimpleLogistic nos casos em que tem apenas um nó. Essa situação acontece no caso queambos tiveram melhor desempenho, destacados na Tabela 17.

Uma vez que diferentes modelos ficaram tecnicamente empatados, diferentes critériospodem ser utilizados para escolher algum desses modelos a depender da aplicação. Omodelo com o menor tamanho serializado pode ser escolhido levando em conta que possuiuma representação mais simples para o conhecimento (seguindo o princípio da Navalha deOccam). Ou para o caso de uma análise de desempenho em que os erros cometidos sobrealguma classe específica sejam mais relevantes, uma análise de custo pode ser feita paraescolher o modelo que gera o menor custo. Ou ainda, algum modelo de árvore pode serconsiderado o mais interessante por permitir uma melhor interpretação dos resultados.


O modelo vencedor aqui foi o criado com o algoritmo meta.LogitBoost sobre osegundo conjunto de dados, chamado de “Só melhores”. Suas vantagens: ele é o de menortamanho serializado, é o que usa menos dados como entrada (apenas 7 características -ver Tabela 16), no fim das contas é o que teve o melhor F-measure ponderado, tambémteve o melhor desempenho sobre a classe Shot on target que em geral é a métrica maisimportante das 3, e ainda é o modelo em que o treinamento ocorre mais rapidamente1.

8.2 Comparação com a literaturaNessa seção o modelo vencedor é comparado com o baseline selecionado na literatura,

que como definido e detalhado na seção 1.4 é o trabalho de (ABREU et al., 2011).Para realizar a comparação, dada a decisão de descartar o peso dos falsos corretamenteclassificados, que foi explicada no início da seção anterior, é necessário obter a matriz deconfusão para o modelo vencedor e recalcular a média ponderada de F-measure. A matriznão é gerada na modelagem feita com o Experimenter, então o Explorer foi utilizado pararecriar o modelo e obter a matriz.

O resultado gerado não é completamente idêntico, uma vez que a divisão dos dadosna cross-validation acaba sendo diferente, mas são muito próximos pois em ambos oscasos foram feitas 10 iterações para reduzir a variância, além claro das 10 repetiçõespara mensurar o desempenho do modelo já realizadas naturalmente pela cross-validation.Não obstante, o valor de F-measure ponderado por todas as classes, que havia sido de0,933, mudou apenas levemente para 0,936. A matriz de confusão obtida pode ser vista naTabela 18.

Tabela 18 – Matriz de confusão do modelo vencedor

Valor preditoValor real Shot on target False Shot off target Blocked shot

Shot on target 213 0 1 3False 3 103 4 3

Shot off target 0 5 31 0Blocked shot 2 5 0 33


A partir dela podem ser calculados os valores de precision, recall e F-measure pracada classe, utilizando a abordagem um-contra-todos (seção 3.6). A Tabela 19 mostra osvalores calculados para cada uma das métricas para o modelo vencedor. Já a Tabela 20resume as métricas de desempenho do modelo vencedor, resgata os valores obtidos por1 A partir dos dados dos experimentos, disponíveis em <http://bit.ly/ExperimentosWEKA>, é possível

carregar a interface de análise no WEKA sem precisar repetir a modelagem e analisar todas essasinformações

http://bit.ly/ExperimentosWEKA


Abreu (Tabela 8) e mostra quanto o novo classificador gerado melhorou precision, recall eF-measure.

Tabela 19 – Resultados por classe e métrica para o modelo vencedor

Tipo de chute Recall Precision F-measureShot on target 0,982 0,977 0,979Shot off target 0,861 0,861 0,861Blocked shot 0,825 0,846 0,835

Total (média ponderada) a 0,9453 0,9449 0,9451a Ponderada pelo número de instâncias em cada classe. Os valores não são calculados para a classe falso,

que também não é reportada em Abreu


Tabela 20 – Comparação entre o modelo vencedor e a heurística de Abreu

Tipo de chute Recall Precision F-measureHeurística de Abreu 0,7633 0,9077 0,8291

Modelo vencedor 0,9453 0,9449 0,9451Melhoria 23,84% 4,10% 13,99%


Os resultados mostraram claramente que a principal melhoria do classificadorcriado foi aumentar o recall, ou seja, ampliar o percentual dos lances relevantes sendodetectados (em 23,84%). É importante notar que isso não foi feito ao custo de adicionarfalsos positivos, pelo contrário, uma melhoria também foi observada em precision, apesarde menos expressiva. Em suma, a média ponderada de F-measure, que foi a métrica dedesempenho escolhida para avaliar os modelos, melhorou em 13,99%.

8.3 Revisão do processoEssa seção lista diversos pontos do processo que devem ser alvo de melhoria

numa próxima iteração. Todas as oportunidades de melhoria identificadas estão na fase 3,Preparação dos Dados, e na fase 4, Modelagem. São elas:

• Fase 3, Detecção de candidatos: os casos falsos filtrados no pré-processamentopodem ser filtrados já na detecção de candidatos utilizando os dados de state. Issodiminuiria consideravelmente a quantidade de eventos que precisam ser classificadosmanualmente, tornando o processo mais rápido ou permitindo que mais jogos sejamclassificados num mesmo período;

• Fase 3, Classificação manual: pode ser realizada por um grupo, o que traria umavisão mais consensual sobre eventos ambíguos, difíceis de serem classificados;


• Fase 3, Seleção de características: lances que terminam em colisão ficariam melhorcaracterizados com um tratamento especial. A cena que está sendo pega comolastKick é o último ciclo antes da colisão, com a bola ainda distante do jogador emque colide, mas deveria ser a bola já próxima, mostrando o limite do deslocamentodela e deixando claro que existia um jogador próximo da bola nesta última cena;

• Fase 3, Seleção de características: o ciclo extra inserido em lances de bola fora precisade uma correção nos dados de state dos jogadores para torná-los coerentes. Essasduas mudanças na seleção de características provavelmente eliminarão um pouco deruído, podendo sozinhas já causarem uma melhoria nos resultados;

• Fase 3, Extração de características: o modelo vencedor teve um desempenho piorpara Shot off target e Blocked shot (Tabela 19), o que pode indicar que faltamcaracterísticas para melhor identificar esses tipos de lance. No caso de Blocked shot,por exemplo, devem ser acrescentadas informações sobre o posicionamento da defesa,o que foi deixado de fora nas iterações realizadas;

• Fase 4, Revisão: seria interessante utilizar o WEKA para avaliar os casos classificadosincorretamente para tentar entender o que pode ser feito para melhorar a classificaçãodesses casos, como definir novas características para serem extraídas, item acima;

• Fase 4, Modelagem: realizar novas iterações, entendendo melhor os algoritmos quepodem ser utilizados e fazendo ajustes finos na escolha dos parâmetros;

Para além das melhorias identificadas, o processo realizado obteve os resultadospropostos. O Objetivo de Mineração de alcançar um F-measure de 0,90 foi superado ecom isso, o Objetivo de Pesquisa de investigar a viabilidade de construir uma ferramentade coleta de estatísticas completa a partir dos chutes a gol mostrou um cenário bastantepromissor. As métricas de chute estão entre as principais métricas de desempenho nofutebol e agora possuem um modelo de coleta satistório. Esse é um forte indicativo de queoutras métricas podem ser coletadas com sucesso, pois em grande parte são os mesmostipos de ambiguidade enfrentados e superados aqui que serão encontrados, como bolasdivididas.

119

9 Fase 6: Implantação

A organização e apresentação de todas as informações sobre o processo, que foramdispostas na Parte II e III da monografia, integraram essa fase. A criação de uma ferramentaprática aplicando o modelo num contexto real não foi incluído no escopo do projeto (verMetodologia, seção 3.1), mas nesse capítulo é mostrada uma sugestão de ferramentautilizando os mesmos dados da OPTA. Também é analisada a utilidade das métricas dedesempenho possíveis de serem extraídas com o uso dos modelos criados. Por fim, sãolistados alguns cuidados relacionados a manutenção e atualização dos modelos.

9.1 Sugestão de implantação do modeloUma grande vantagem de utilizar a mesma definição de dados da OPTA, além

de permitir uma comparação mais direta com o futebol real, é poder se inspirar emferramentas que utilizam os mesmos dados. Uma dessas ferramentas é o Stats Zone do siteFourFourTwo. Nela é possível visualizar todos os eventos de uma partida separado portime ou por jogador. Numa única tela é possível visualizar todos os chutes a gol que umtime deu num jogo. A Figura 42, por exemplo, mostra todos os chutes a gol dados peloBrasil na fatídica derrota por 7x1 para a Alemanha no mundial de 20141.

Nessa interface é possível ainda aplicar diversos filtros, como recortar um deter-minado período da partida ou visualizar apenas chutes dados de fora da área. Poder vertodos os chutes dados num jogo em poucos segundos, lado a lado, ou quem sabe aindapoder analisar as médias comparadas de dois conjuntos de partidas, representariam umaevolução no modo de avaliar e testar os sistemas que jogam futebol quando comparadocom as alternativas mais comumente utilizadas atualmente: contabilizar apenas gols ouassistir jogos no LogPlayer e registrar eventos manualmente.

O modelo vencedor seria a base para desenvolver uma ferramenta similar para aSimulação 2D. O WEKA inclusive gera o código do modelo em Java, de modo que possaser utilizado externamente. Levando em consideração que os programas de detecção decandidatos (ShotCandidatesDetector) e extração de características (FeatureSE) já foramcriados durante esse projeto, para construir essa ferramenta seria necessário: mesclardetecção e extração num único programa para gerar vetores de características a partir denovos logs, passar esses vetores para o modelo em Java para serem classificados, e criaruma interface final similar a do FourFourTwo para apresentar as informações.

Outra possibilidade interessante, uma vez que todas as características que o modelo1 Esse interface pode ser acessada publicamente em <http://bit.ly/FourFourTwoExample>

http://bit.ly/FourFourTwoExample

Capítulo 9. Fase 6: Implantação 120

Figura 42 – Ferramenta para visualizar chutes a gol


vencedor utiliza para classificar um caso estão acessíveis para o técnico durante uma partida,seria usar as estatísticas em tempo real, para que o técnico tome decisões estratégicasdurante o jogo.

9.2 Análise da utilidade dos modelosPara demonstrar o potencial dos eventos coletados pelo modelo, os dados dos 33

jogos classificados manualmente foram analisados de acordo com as 6 métricas relacionadasa chutes a gol apresentadas na seção 2.3 (as 3 coletadas pelo modelo, gols e as 2 derivadas).


Os times foram novamente separados em 3 grupos de acordo com suas forças (Tabela 13),como feito para selecionar o espaço amostral. A Tabela 21 apresenta as médias por jogode cada métrica, separada pela força dos times. Entre parênteses está a quantidade devezes em que um time com aquela força aparece nas partidas analisadas (“Fortes” possuimenos partidas porque o grupo ficou com 6 times, 1 a menos que os outros 2).

Tabela 21 – Médias de cada métrica de acordo com a força dos times

Métrica Fortes (18) Médios (21) Fracos (21)Shot on target 4,89 2,81 1,33Shot off target 0,72 0,76 0,14Blocked shot 0,72 0,67 0,43

Goals 3,83 2,19 0,86Chance conversion 0,67 0,51 0,3Shooting accuracy 0,85 0,7 0,51


Pelos dados tabelados é possível perceber como o grupo dos times fortes de fatosupera os outros times em praticamente todas as métricas. A única exceção foi em chutespara fora (Shot off target), o que não é ruim e pode simplesmente significar chutes maisprecisos (como de fato mostra Shooting accuracy). Para melhor visualizar esses dados, elesforam plotados num gráfico de radar - Figura 43 (com as 4 primeiras métricas da Tabela 21sendo normalizadas pelo maior valor). No gráfico é ainda mais fácil visualizar como ostimes fortes dominam os médios, que por sua vez também dominam os fracos. Sair deapenas gols para esse conjunto de métricas acrescenta mais textura a análise de um time2.

Figura 43 – Radar com métricas de desempenho de acordo com a força dos times


2 Os dados completos por time estão disponível em <http://bit.ly/utilidadeMetricas>

http://bit.ly/utilidadeMetricas


9.3 Manutenção e evolução dos modelosÉ difícil afirmar nesse momento com que frequência os modelos devem ser atu-

alizados. O ideal será aproveitar os dados do próximo mundial para verificar quantaqualidade o modelo perde após um ano de evolução dos times. Porém, como o servidorjá está bastante estável e poucos mudanças estão sendo inseridas recentemente, como aamostragem utilizada para criar os modelos atuais foi bastante variada, e como em umano de trabalho sobre um time muitas vezes nada se altera em relação ao modo como sãodados os chutes a gol, espera-se que os modelos criados não fiquem obsoletos tão rápidos.

Para checar a qualidade do modelo o ideal é que já exista uma ferramenta criadapara utilizá-lo sobre novos logs, como a descrita na seção 9.1. Com ela o processo poderiaser simplificado para utilizá-la sobre novos logs (uma seleção criteriosa de espaço amostral,garantindo representatividade) e comparar as classificações geradas pela ferramenta comuma classificação manual. Catalogar esses dados numa matriz de confusão permitiriachecar se o F-measure do modelo se deteriorou.

O caso mais comum provavelmente será o de surgirem novas jogadas que nãoestavam representadas nos dados de treinamento da versão atual. Se o modelo se mostrarincapaz de generalizar esses casos e isso estiver causando um grande impacto sobre F-measure, por exemplo levando-a novamente para um valor abaixo de 0,90, isso tornarianecessário repetir o treinamento com novos dados. Outro aspecto, tão importante de serobservado quanto é incomum de acontecer, são mudanças no formato do log do servidor,o que demandaria uma análise sobre a mudança inserida e o impacto que ela causa nasdiversas ferramentas desenvolvidas nesse projeto.

Parte IV

Conclusão

124

Conclusões e trabalhos futuros

A última década marcou uma grande mudança na relação entre o futebol profissionale os seus dados. Das contratações à escalação das equipes, passando pelo condicionamentofísico, são utilizadas ferramentas analíticas e estatísticas para apoiar a tomada de decisões.Nesse período, entretanto, o ambiente da pesquisa científica com futebol de robôs nãoacompanhou a evolução dessas ferramentas. Esse estudo buscou aproximar os dois camposao investigar como realizar a coleta automatizada de estatísticas utilizadas no futebolprofissional a partir dos logs das partidas da Simulação 2D.

O primeiro resultado prático são diversas ferramentas auxiliares que foram construí-das para realizar o processo de Preparação dos Dados, etapa mais trabalhosa, que podemser reutilizadas em novos processos de Descoberta de Conhecimento nos dados da Simula-ção 2D. Segundo, foram criados modelos para detecção de chutes a gol, uma das métricasmais importantes no futebol e que ainda não haviam sido detectadas de modo satisfatóriosegundo a literatura. Esses modelos aprimoraram o F-measure da alternativa existente em13,99%. O uso em si de F-measure como medida de desempenho para classificadores deeventos de futebol é uma escolha importante.

O trabalho é um bom indicativo de que com os dados contidos nos logs da Simulação2D e a metodologia utilizada é possível realizar a detecção com qualidade dos outrosdiversos eventos contabilizados no futebol profissional. Essa expansão para outros eventosé, aliás, um dos trabalhos futuros importantes de serem realizados. Outro, é construiruma ferramenta que utilize os modelos gerados nesse trabalho para detectar e visualizaros eventos de chutes a gol em novos logs, ferramenta essa que poderia ser utilizada paratestes na Simulação 2D, promovendo uma evolução nos métodos de experimentação naliga.

Com a coleta detalhada de eventos e uma maior oferta de dados históricos é possívelter uma visão muito mais clara não só sobre os avanços de cada time independentemente,mas sobre a evolução da liga como um todo, ano após ano. Como os eventos são os mesmosutilizados no futebol real, torna-se também mais fácil realizar comparações deste coma Simulação 2D, contribuindo para medir a evolução rumo a meta da Robocup. Essacomparação pode servir de guia para realizar atualizações que mantenham a 2D comouma liga relevante dentro da Robocup, potencial que ela tem, desde que consiga se tornarcada vez ainda mais parecida com o futebol real.

A coleta de estatísticas sobre as partidas é apenas um primeiro passo para que sejapossível estudar as relações mais profundas que existem nos dados, desdobrando essasdiversas aplicações. É um passo fundamental de ser dado não apenas na Simulação 2D,

Conclusões 125

mas por todas as ligas da Robocup em que os jogos se tornem dinâmicos e mais complexosde serem entendidos, afinal análise de desempenho é um problema transversal. Em suma,para que a Robocup continue a caminhar firme para sua meta, é importante também queacompanhe as evoluções do esporte.

126

Referências

ABREU, P. et al. Human versus virtual robotics soccer: A technical analysis. EuropeanJournal of Sport Science, n. January 2012, p. 37–41, 2012. 18

ABREU, P. H. Artificial Intelligence Methodologies Applied in the Analysis andOptimization of Soccer Teams Performance. 280 p. Tese (Tese de Doutorado) —Universidade do Porto, 2010. 17, 18, 26, 35, 39, 47, 48, 51, 58, 79, 90

ABREU, P. H. et al. Performance analysis in soccer: a Cartesian coordinates basedapproach using RoboCup data. Soft Computing, v. 16, n. 1, p. 47–61, maio 2011. ISSN1432-7643. Disponível em: <http://link.springer.com/10.1007/s00500-011-0733-0>. 7, 8,11, 48, 49, 55, 56, 79, 80, 95, 113, 114, 116

AGENCY, T. M. As fases do CRISP-DM. 2013. Disponível em: <http://the-modeling-agency.com/series-package/>. 61

ALBERT, J. (Ed.). Journal of Quantitative Analysis in Sports. Berlin, Boston: DeGruyter, 2013. Disponível em: <http://www.degruyter.com/view/j/jqas>. 52

ANDERSON, C.; SALLY, D. Soccer By The Numbers. 2013. Disponível em: <http://www.soccerbythenumbers.com/2013/03/what-exactly-is-football-analytics-what.html>.52

ANDERSON, C.; SALLY, D. The numbers game. Viking, 2013. 384 p. ISBN 0670922242.Disponível em: <http://www.amazon.co.uk/The-Numbers-Game-Everything-Football/dp/0670922242>. 52

BATEMAN, R. OptaPro’s event definitions, and the importance of consistent data. 2012.Disponível em: <http://www.optasportspro.com/en/about/optapro-blog/posts/2012/optapro’s-event-definitions.aspx>. 17, 56, 136

BEZEK, A. Logalyzer. 2013. Disponível em: <http://dis.ijs.si/andraz/logalyzer/>. 47, 48

BOER, R. de; KOK, J. The Incremental Development of a Synthetic Multi-Agent System:The UvA Trilearn 2001 Robotic Soccer Simulation Team. 217 p. Tese (Tese de mestrado) —University of Amsterdam, 2002. 25, 30, 34, 41, 81

BOUCKAERT, R. R. et al. WEKA Manual for Version 3-6-8. 2012. 133

CHAPMAN, P. et al. Crisp-dm 1.0. [S.l.], 2000. 78 p. 60

CHEN, M. et al. RoboCup Soccer Server 7.07, Manual. [S.l.], 2003. 150 p. 18, 24, 25, 30,31, 37

Enciclopédia Britânica. Enciclopédia britânica sobre futebol. 2013. Disponível em:<http://global.britannica.com/EBchecked/topic/550852/football>. 58

FAYYAD, U.; PIATETSKY-SHAPIRO, G.; SMYTH, P. From Data Mining to KnowledgeDiscovery in Databases. AI Magazine, v. 17, n. 3, p. 37–54, 1996. 59, 68, 71, 82, 97, 110

http://link.springer.com/10.1007/s00500-011-0733-0

http://the-modeling-agency.com/series-package/

http://the-modeling-agency.com/series-package/

http://www.degruyter.com/view/j/jqas

http://www.soccerbythenumbers.com/2013/03/what-exactly-is-football-analytics-what.html

http://www.soccerbythenumbers.com/2013/03/what-exactly-is-football-analytics-what.html

http://www.amazon.co.uk/The-Numbers-Game-Everything-Football/dp/0670922242

http://www.amazon.co.uk/The-Numbers-Game-Everything-Football/dp/0670922242

http://www.optasportspro.com/en/about/optapro-blog/posts/2012/optapro's-event-definitions.aspx

http://www.optasportspro.com/en/about/optapro-blog/posts/2012/optapro's-event-definitions.aspx

http://dis.ijs.si/andraz/logalyzer/

http://global.britannica.com/EBchecked/topic/550852/football

Referências 127

GARCÍA, V.; MOLLINEDA, J. S. S. R. A.; SOTOCA, R. A. J. M. The class imbalanceproblem in pattern classification and learning. II Congreso Español de Informática, 2007.73

GATTI, M. A. d. C.; STAA, A. von. Testing & Debugging Multi-Agent Systems: A Stateof the Art Report. Rio de Janeiro, 2006. 28 p. 18, 44

GOLOVNYA, M. Introdution to Data Mining. 2006. Disponível em: <http://www.salford-systems.com/products/treenet/testimonials/127-all/videos/introductory/81-introduction-to-data-mining>. 62

GOLOVNYA, M. A Step by Step Introduction to Data Mining for Sports Analysis. MITVideo, 2011. Disponível em: <http://mit.tv/wr99gv>. 53, 59, 60

HAMM, S. GrandChallenges. 2012. Disponível em: <http://asmarterplanet.com/blog/2012/05/ibm’s-grand-challenges-pitting-machine-against-man.html>. 22

HARTEMINK, A. Clarifying various terms for evaluating classifier (or hypothesis testing)performance. 2014. Disponível em: <http://www.cs.duke.edu/courses/spring11/cps262/classifier.evaluation.updated.txt>. 73

HUANG, H. et al. GDUT TiJi 2013 2D Soccer Simulation Team Description. 2013. 17

Innovation Enterprise LTD. Sports Analytics Innovation Summit. 2013. Disponível em:<http://theinnovationenterprise.com/summits/sports-analytics-london-2013>. 52

KITANO, H. et al. RoboCup: A challenge problem for AI. AI magazine, v. 18, n. 1, p.73–85, 1997. Disponível em: <http://www.aaai.org/ojs/index.php/aimagazine/article/viewArticle/1276>. 21, 23

KOHAVI, R. A Study of Cross-Validation and Bootstrap for Accuracy Estimation andModel Selection. International Joint on Artificial Intelligence, 1995. 71

LEWIS, M. Moneyball: The Art of Winning an Unfair Game. [S.l.: s.n.], 2003. 53

LIN, T. Y.-y. 2013 Team Description Paper: UBC Thunderbots Simultation. 2013. 17

MARISCAL, G.; SEGOVIA, J. A Data Mining & Knowledge Discovery Process Model.In: PONCE, J.; KARAHOCA, A. (Ed.). Data Mining and Knowledge Discovery in RealLife Applications. Vienna: I-Tech Education and Publishing, 2009. cap. 1, p. 1–17. ISBN9783902613530. Disponível em: <http://cdn.intechopen.com/pdfs/5937/InTech-A\_data\_mining\_amp\_knowledge\_discovery\_process\_model.pdf>. 60

NODA, I. et al. Soccer Server: a tool for research on multi-agent systems. AppliedArtificial Intelligence, v. 12, p. 233–250, 1998. 25, 27, 30, 35

Opta Sports. OptaPro named as Official Data Partner for the Brazilian National Team.2013. Disponível em: <http://www.optasportspro.com/en/about/optapro-blog/posts/2013/news-optapro-named-as-official-data-partner-for-the-brazilian-national-team.aspx>. 55

PRINCE, J. How Opta altered the Premier League, and soccer, fore-ver. 2013. Disponível em: <http://prosoccertalk.nbcsports.com/2013/10/02/how-opta-has-helped-alter-the-premier-league-and-soccer-forever-part-i/>. 54

http://www.salford-systems.com/products/treenet/testimonials/127-all/videos/introductory/81-introduction-to-data-mining



http://mit.tv/wr99gv

http://asmarterplanet.com/blog/2012/05/ibm's-grand-challenges-pitting-machine-against-man.html

http://asmarterplanet.com/blog/2012/05/ibm's-grand-challenges-pitting-machine-against-man.html

http://www.cs.duke.edu/courses/spring11/cps262/classifier.evaluation.updated.txt

http://www.cs.duke.edu/courses/spring11/cps262/classifier.evaluation.updated.txt

http://theinnovationenterprise.com/summits/sports-analytics-london-2013

http://www.aaai.org/ojs/index.php/aimagazine/article/viewArticle/1276

http://www.aaai.org/ojs/index.php/aimagazine/article/viewArticle/1276

http://cdn.intechopen.com/pdfs/5937/InTech-A\_data\_mining\_amp\_knowledge\_discovery\_process\_model.pdf

http://cdn.intechopen.com/pdfs/5937/InTech-A\_data\_mining\_amp\_knowledge\_discovery\_process\_model.pdf

http://www.optasportspro.com/en/about/optapro-blog/posts/2013/news-optapro-named-as-official-data-partner-for-the-brazilian-national-team.aspx



http://prosoccertalk.nbcsports.com/2013/10/02/how-opta-has-helped-alter-the-premier-league-and-soccer-forever-part-i/

http://prosoccertalk.nbcsports.com/2013/10/02/how-opta-has-helped-alter-the-premier-league-and-soccer-forever-part-i/

Referências 128

PRINCE, J. Opta and MLS - a beautiful game they play. 2013.Disponível em: <http://prosoccertalk.nbcsports.com/2013/10/03/opta-and-mls-progressing-soccer-in-north-america/>. 55

PROKOPENKO, M. et al. Gliders2013: Tactical Analysis with Information Dynamics.2013. 17

RAMOS, L. et al. ITAndroids 2D Soccer Simulation Team Description 2013. 2013. 17

RILEY, P.; VELOSO, M. On Behavior Classification in Adversarial Environments.In: PARKER, L.; BEKEY, G.; BARHEN, J. (Ed.). Distributed Autonomous RoboticSystems 4. Springer Japan, 2000. p. 371–380. ISBN 978-4-431-67991-2. Disponível em:<http://dx.doi.org/10.1007/978-4-431-67919-6\_35>. 48

ROBOCUP. A Brief History of Robocup. 2013. Disponível em: <http://www.robocup.org/about-robocup/a-brief-history-of-robocup>. 21, 22, 23

ROBOCUP. Logs do campeonato de 2013. 2013. Disponível em: <http://www.socsim.robocup.org/files/2D/log/RoboCup2013/>. 82

ROBOCUP. Página oficial da Robocup 2013. 2013. Disponível em: <http://www.robocup2013.org/>. 21

ROBOCUP. TDPs de 2013. 2013. Disponível em: <http://staff.science.uva.nl/~arnoud/activities/robocup/RoboCup2013/Symposium/TeamDescriptionPapers/SoccerSimulation/index.html>. 45

ROBOCUP. TDPs de todos os anos. 2013. Disponível em: <http://www.socsim.robocup.org/files/2D/tdp/>. 45

RUSSEL, S. J.; NORVIG, P. Artificial Intelligence: A Modern Approach. 2. ed. [S.l.]:Pearson Education, 2003. ISBN 0137903952. 23, 25, 38, 50

SANTOS, R. Análise de Logs : Abordagens Tradicionais e por Data Mining. 2006. 100 p.61

SANTOS, R. Princípios e Aplicações de Mineração de Dados (aula 4). 2012. 43 p. 65, 66

SCHUMAKER, R. P.; SOLIEMAN, O. K.; CHEN, H. Sports Data Mining. Boston,MA: Springer US, 2010. 176 p. (Integrated Series in Information Systems, v. 26). ISBN978-1-4419-6729-9. Disponível em: <http://www.springerlink.com/index/10.1007/978-1-4419-6730-5>. 52, 53, 54

SHAHRI, A. H. TeamAssistant2003. 2013. Disponível em: <http://sourceforge.net/p/team-assistant/wiki/Home/>. 47

SILVA, B. et al. Bahia2D 2010: Team Description. 2010. 46

SILVA, B. et al. Implementação do nível cognitivo na arquitetura multiagentes do time defutebol de robôs simulado Bahia2D. 63º Reunião Anual da Sociedade Brasileira para oProgresso da Ciência, 2011. 46

SOLIEMAN, O. K. Data Mining in Sports: A Research Overview. 76 p. Tese (Doutorado),2006. 52

http://prosoccertalk.nbcsports.com/2013/10/03/opta-and-mls-progressing-soccer-in-north-america/

http://prosoccertalk.nbcsports.com/2013/10/03/opta-and-mls-progressing-soccer-in-north-america/

http://dx.doi.org/10.1007/978-4-431-67919-6\_35

http://www.robocup.org/about-robocup/a-brief-history-of-robocup

http://www.robocup.org/about-robocup/a-brief-history-of-robocup

http://www.socsim.robocup.org/files/2D/log/RoboCup2013/

http://www.socsim.robocup.org/files/2D/log/RoboCup2013/

http://www.robocup2013.org/

http://www.robocup2013.org/

http://staff.science.uva.nl/~arnoud/activities/robocup/RoboCup2013/Symposium/TeamDescriptionPapers/SoccerSimulation/index.html



http://www.socsim.robocup.org/files/2D/tdp/

http://www.socsim.robocup.org/files/2D/tdp/

http://www.springerlink.com/index/10.1007/978-1-4419-6730-5

http://www.springerlink.com/index/10.1007/978-1-4419-6730-5

http://sourceforge.net/p/team-assistant/wiki/Home/

http://sourceforge.net/p/team-assistant/wiki/Home/

Referências 129

STONE, P.; AUGUST, G. K. Publications Related to the RoboCup Soccer SimulationLeague. [S.l.], 2013. v. 6, n. 5, 893–910 p. 48

TAKAHASHI, T. LogMonitor: From Player’s Action Analysis to Collaboration Analysisand Advice on Formation. In: VELOSO, M.; PAGELLO, E.; KITANO, H. (Ed.).RoboCup-99: Robot Soccer World Cup III. [S.l.]: Springer Berlin Heidelberg, 2000. cap.LogMonitor, p. 103–113. ISBN 978-3-540-45327-7. 48

TAN; STEINBACH; KUMAR. Classification: Basic Concepts, Decision Trees, and ModelEvaluation. In: Introduction to Data Mining. 1. ed. Addison-Wesley, 2006. cap. 4. Classif,p. 769. ISBN 0321321367. Disponível em: <http://www-users.cs.umn.edu/~kumar/dmbook/ch4.pdf>. 62, 63, 64, 67, 68, 71, 72

TANAKA, K. et al. A Statistical Perspective on the Robocup Simulator League: Progressand Prospects. 1998. 24, 48

The Verge. Real steel: the broken robot necks and baby steps of RoboCup2012. 2012. Disponível em: <http://www.theverge.com/2012/9/7/3287515/robocup-2012-robots-soccer-broken-necks-baby-steps>. 21

Two Crows. Introduction to Data Mining and Kowledge Discovery. 3. ed. Two CrowsCorporation, 2005. 36 p. Disponível em: <http://www.twocrows.com/intro-dm.pdf>. 63,64, 66, 88, 95, 110

Waikato University. Página web do projeto WEKA. 2013. Disponível em:<http://www.cs.waikato.ac.nz/~ml/weka/gui\_explorer.html>. 76

WITTEN, I. H. Data Mining with WEKA. 2013. Disponível em: <https://weka.waikato.ac.nz/>. 77

WITTEN, I. H.; FRANK, E.; HALL, M. A. Data Mining: Practical Machine LearningTools and Techniques. 3. ed. San Francisco: Morgan Kaufmann Publishers Inc, 2011. ISBN978-0-12-374856-0. Disponível em: <http://www.cs.waikato.ac.nz/ml/weka/book.html>.68, 70, 71, 72, 74, 75, 77, 108, 110, 113, 133

ZEKAI-CHENG et al. Yu Shan Soccer 2D Simulation Team Description Paper forRoboCup 2013. 2013. 17

ZHANG, H. et al. WrightEagle 2D Soccer Simulation Team Description 2013. p. 3–8,2013. 46

http://www-users.cs.umn.edu/~kumar/dmbook/ch4.pdf

http://www-users.cs.umn.edu/~kumar/dmbook/ch4.pdf

http://www.theverge.com/2012/9/7/3287515/robocup-2012-robots-soccer-broken-necks-baby-steps

http://www.theverge.com/2012/9/7/3287515/robocup-2012-robots-soccer-broken-necks-baby-steps

http://www.twocrows.com/intro-dm.pdf

http://www.cs.waikato.ac.nz/~ml/weka/gui\_explorer.html

https://weka.waikato.ac.nz/

https://weka.waikato.ac.nz/

http://www.cs.waikato.ac.nz/ml/weka/book.html

Apêndices

131

APÊNDICE A – Logs do espaço amostral

As tabelas abaixo mostram os jogos incluídos no espaço amostral. A primeira colunarepresenta a força do time adversário segundo a Tabela 13. A segunda coluna indica se éum “Jogo” selecionado, se é apenas o “Espelho” de um jogo já incluído no espaço amostral,ou se é um jogo em que não foi feito um pareamento perfeito e apenas um dos times era ofoco da avaliação, marcado como “Único”. A terceira coluna indica o nome do adversário.A quarta coluna indica o critério que definiu a escolha do jogo, “Prioridade” indica umjogo que possui lances representativos e foi incluído antecipadamente, “Força” indica quefoi escolhido normalmente pelo critério da força, e os jogos espelho são marcados com “-”pois são incluídos por consequência de um outro jogo ter sido adicionado. A última colunamostra o timestamp do jogo que permite identificar o arquivo de log unicamente.

Tabela 22 – Espaço amostral - times fortes

WrightEagleForte Jogo Helios2013 Força 20130630132958(...).rcgMédio Jogo AUT Força 20130630092901(...).rcgFraco Jogo UTAustinVilla Força 20130629135833(...).rcg

HELIOS2013Forte Espelho WrightEagle - -Médio Jogo GDUT_Tiji2013 Força 20130629133635(...).rcgFraco Jogo GPR-2D Força 20130628121215(...).rcg

YuShan2013Forte Jogo Axiom Força 20130630105407(...).rcgMédio Jogo FC-Perspolis Força 20130629151846(...).rcgFraco Jogo CSU_Yunlu2013 Força 20130628121632(...).rcg

AxiomForte Espelho YuShan2013 - -Médio Jogo Cyrus Força 20130629141215(...).rcgFraco Jogo WarthogsRobotics Força 20130628131043(...).rcg

Gliders2013Forte Jogo Oxsy Força 20130630105409(...).rcgMédio Jogo LegenDary Prioridade 20130629140255(...).rcgFraco Jogo Ri-one Força 20130628144006(...).rcg

OxsyForte Espelho Gliders2013 - -Médio Jogo FCPortugal Prioridade 20130628124345(...).rcgFraco Jogo HfutEngine2013 Prioridade 20130628144522(...).rcg


O Round 0, de testes, teve apenas 1 jogo selecionado (apenas pois não possívelparear de outra forma). Do Round 1 (primeira fase) foram selecionados 16 jogos. DoRound 2 (segunda fase), 9 jogos. Do Round 3 (terceira fase), 2 jogos. Do Round 4(double-elimination), 4 jogos. E do Round 5 (final), o único jogo possível foi selecionado.

APÊNDICE A. Logs do espaço amostral 132

Tabela 23 – Espaço amostral - times médios

AUTForte Espelho WrightEagle - -Médio Jogo Cyrus Força 20130630103945(...).rcgFraco Espelho UTAustinVila - -

CyrusForte Espelho Axiom - -Médio Espelho AUT - -Fraco Jogo GPR-2D Força 20130629120009(...).rcg

GDUT_Tiji2013Forte Espelho Helios2013 - -Médio Jogo LegenDary Prioridade 20130629122918(...).rcgFraco Jogo WarthogsRobotics Prioridade 20130629160346(...).rcg

FC-PerspolisForte Espelho YuShan2013 - -Médio Espelho FCPortugal - -Fraco Jogo ThunderBots Prioridade 20130628122518(...).rcg

LegenDaryForte Espelho Gliders2013 - -Médio Espelho GDUT_Tiji2013 - -Fraco Jogo CSU_Yunlu2013 Força 20130628105538(...).rcg

FCPortugalForte Espelho Oxsy - -Médio Jogo FC-Perspolis Prioridade 20130629172117(...).rcgFraco Jogo HfutEngine2013 Prioridade 20130628133736(...).rcg

ITAndroidsForte Único Oxsy Força 20130629145630(...).rcgMédio Único LegenDary Força 20130629164055(...).rcgFraco Único ThunderBots Prioridade 20130628115913(...).rcg


Tabela 24 – Espaço amostral - times fracos

UTAustinVillaForte Espelho WrightEagle - -Médio Jogo AUT Prioridade 20130628122928(...).rcgFraco Jogo CSU_Yunlu2013 Prioridade 20130628110905(...).rcg

GPR-2DForte Espelho Helios2013 - -Médio Espelho Cyrus - -Fraco Jogo ThunderBots Prioridade 20130628110628(...).rcg

WarthogRoboticsForte Espelho Axiom - -Médio Espelho GDUT_Tiji2013 - -Fraco Jogo HfutEngine2013 Força 20130628132413(...).rcg

CSU_Yunlu2013Forte Espelho YuShan2013 - -Médio Espelho LegenDary - -Fraco Espelho UTAustinVila - -

ThunderBotsForte Único Helios2013 Força 20130628111930(...).rcgMédio Espelho FC-Perspolis - -Fraco Espelho GPR-2D - -

HfutEngine2013Forte Espelho AUT - -Médio Espelho FCPortugal - -Fraco Espelho WarthogsRobotics - -

Ri-oneForte Espelho Gliders2013 - -Médio Único Cyrus Força 20130628131813(...).rcgFraco Único CSU_Yunlu2013 Forçaa 20130627132605(...).rcg

a Jogo do Round 0


133

APÊNDICE B – Algoritmos de aprendizadoutilizados no WEKA

As tabelas a seguir mostram os algoritmos do WEKA utilizados nos experimentos,separados pela família a qual pertecem. A linha de comando é mostrada nas tabelas poisatravés dela é possível saber todos os parâmetros aplicados na utilização do algoritmo.Mais sobre cada família e algoritmos pode ser encontrado em (WITTEN; FRANK; HALL,2011), (BOUCKAERT et al., 2012) e também clicando em cada algoritmo na própriaferramenta WEKA (onde há referências para os principais artigos relacionados).

Tabela 25 – Algoritmos e parâmetros utilizados no WEKA: árvores

ÁrvoreAlgoritmo Linha de comando

BFTree trees.BFTree ’-S 1 -M 2 -N 5 -C 1.0 -P POSTPRUNED’DecisionStump trees.DecisionStump ”

FT trees.FT ’-I 15 -F 0 -M 15 -W 0.0’J48 trees.J48 ’-C 0.25 -M 2’

J48graft trees.J48graft ’-C 0.25 -M 2’LADTree trees.LADTree ’-B 10’

LMT trees.LMT ’-I -1 -M 15 -W 0.0’NBTree trees.NBTree ”

RandomForest trees.RandomForest ’-I 10 -K 0 -S 1’RandomTree trees.RandomTree ’-K 0 -M 1.0 -S 1’

REPTree trees.REPTree ’-M 2 -V 0.0010 -N 3 -S 1 -L -1’SimplesCART trees.SimpleCart ’-S 1 -M 2.0 -N 5 -C 1.0’


Tabela 26 – Algoritmos e parâmetros utilizados no WEKA: regras e bayes

Regras e BayesAlgoritmo Linha de comando

ConjuntiveRule rules.ConjunctiveRule ’-N 3 -M 2.0 -P -1 -S 1’DecisionTable rules.DecisionTable ’-X 1 -S “BestFirst -D 1 -N 5”’

DTNB rules.DTNB ’-X 1’JRip rules.JRip ’-F 3 -N 2.0 -O 2 -S 1’NNge rules.NNge ’-G 5 -I 5’ 4084742275553788972OneR rules.OneR ’-B 6’PART rules.PART ’-M 2 -C 0.25 -Q 1’Ridor rules.Ridor ’-F 3 -S 1 -N 2.0’ZeroR rules.ZeroR ”

BayesNet bayes.BayesNet ’-D -Q bayes.net.search.local.K2 – -P 1 -S BAYES-E bayes.net.estimate.SimpleEstimator – -A 0.5’

NaiveBayes bayes.NaiveBayes ”


APÊNDICE B. Algoritmos de aprendizado utilizados no WEKA 134

Tabela 27 – Algoritmos e parâmetros utilizados no WEKA: funções e lazy

Funções e LazyAlgoritmo Linha de comandoLogistic functions.Logistic ’-R 1.0E-8 -M -1’

MultilayerPerceptron functions.MultilayerPerceptron ’-L 0.3 -M 0.2 -N 500 -V 0 -S 0 -E 20 -Ha’

RBFNetwork functions.RBFNetwork ’-B 2 -S 1 -R 1.0E-8 -M -1 -W 0.1’SimpleLogistic functions.SimpleLogistic ’-I 0 -M 500 -H 50 -W 0.0’

SMO functions.SMO ’-C 1.0 -L 0.0010 -P 1.0E-12 -N 0 -V -1 -W 1 -K “functi-ons.supportVector.PolyKernel -C 250007 -E 1.0”’

IB1 lazy.IB1 ”IBk lazy.IBk ’-K 1 -W 0 -A “weka.core.neighboursearch.LinearNNSearch -A

“weka.core.EuclideanDistance -R first-last””’KStar lazy.KStar ’-B 20 -M a’LWL lazy.LWL ’-U 0 -K -1 -A “weka.core.neighboursearch.LinearNNSearch -A

“weka.core.EuclideanDistance -R first-last”” -W trees.DecisionStump’


Tabela 28 – Algoritmos e parâmetros utilizados no WEKA: meta e outros

Meta e outrosAlgoritmo Linha de comando

ViaRegression meta.ClassificationViaRegression ’-W trees.M5P – -M 4.0’END meta.END ’-S 1 -I 10 -W meta.nestedDichotomies.ND – -S 1 -W trees.J48 – -C

0.25 -M 2’LogitBoost meta.LogitBoost ’-P 100 -F 0 -R 1 -L -1.7976931348623157E308 -H 1.0 -S 1 -I

10 -W trees.DecisionStump’MultiBoost meta.MultiBoostAB ’-C 3 -P 100 -S 1 -I 10 -W trees.LMT – -I -1 -M 15 -W 0.0’MultiClass meta.MultiClassClassifier ’-M 0 -R 2.0 -S 1 -W functions.Logistic – -R 1.0E-8

-M -1’ClassBalancedND meta.nestedDichotomies.ClassBalancedND ’-S 1 -W trees.J48 – -C 0.25 -M 2’

ND meta.nestedDichotomies.ND ’-S 1 -W trees.J48 – -C 0.25 -M 2’RandComittee meta.RandomCommittee ’-S 1 -I 10 -W trees.RandomTree – -K 0 -M 1.0 -S 1’

RandomSubSpace meta.RandomSubSpace ’-P 0.5 -S 1 -I 10 -W trees.REPTree – -M 2 -V 0.0010-N 3 -S 1 -L -1’

RotationForest meta.RotationForest ’-G 3 -H 3 -P 50 -F “unsupervised.attribute.PrincipalComponents -R 1.0 -A 5 -M -1” -S 1 -I 10 -W trees.J48 – -C 0.25 -M 2’

HyperPipes misc.HyperPipes ”VFI misc.VFI ’-B 0.6’


Anexos

136

ANEXO A – Definições dos eventos daferramenta OptaPro

Como disponível no blog da ferramenta OptaPro em 27 de novembro de 2013(BATEMAN, 2012).

Opta’s key strength is the ability to provide in-depth, accessible data that isconsistent across the globe. Without this certainty, Opta’s player and team statistics canbe far less valuable and there would be a danger that different leagues would be analysedin conflicting ways, rendering proper player comparison invalid.

To avoid this, Opta have a long-established a consistent list of ’Event Definitions’in football that are adhered to across all data collection centres.

Opta Glossary

This is a list of the main football events logged by Opta:

Goal/Own Goal - While this one may seem obvious, different governing bodieshave different rules and Opta usually works with the relevant people to reflect their officialdecisions on goalscorers.

Shot on target - Any goal attempt that:

1. Goes into the net;

2. Would have gone into the net but for being stopped by a goalkeeper’s save;

3. Would have gone into the net but for being stopped by a defender who is the lastman.

Shot off target - Any goal attempt where the ball is going wide of the target,misses the goal or hits the woodwork.

Blocked Shot - Any goal attempt heading roughly on target toward goal which isblocked by a defender, where there are other defenders or a goalkeeper behind the blocker.

Chance conversion/Goals-to-shots ratio - A calculation of goals scored dividedby shots attempted (excluding blocked attempts).

Shooting Accuracy - A calculation of Shots on target divided by all shots(excluding blocked attempts).

Pattern of play for Goals/Attempts - Set Piece goals/attempts are thosewhere the ball starts from a dead ball situation such as a corner, a free kick, a penalty or

ANEXO A. Definições dos eventos da ferramenta OptaPro 137

a Throw-in and results in a shot before the phase of play has broken down into open play.The exact point at which it becomes open play is usually clear but set pieces which arecleared and then the ball is put straight back into the penalty area are still deemed to bepart of the set piece as the defending team is still positioned to deal with the set play.

Big Chances - A situation where a player should reasonably be expected to scoreusually in a one-on-one scenario or from very close range.

Goal Assist - The final pass or pass-cum-shot leading to the recipient of the ballscoring a goal.

Fantasy Goal Assist - From Summer 2013, Opta have started to collect a rangeof other assists used by fantasy football, but also available to clients to determine theirown definition should they wish:

• Heavily deflected pass

• Shot on target saved, rebound scored

• Shot blocked rebound scored

• Shot hit woodwork rebound scored

• Penalty won

• Free kick won by foul

• Free kick instigated by forced handball

• Instigating own goal through shot/pass

Second Assist/Key Pass - A pass/cross that is instrumental in creating a goal-scoring opportunity, for example a corner or free-kick to a player who then assists anattempt, a chance-creating through ball or cross into a dangerous position.

Key Pass - The final pass or pass-cum-shot leading to the recipient of the ballhaving an attempt at goal without scoring.

Chances Created - Assists plus Key passes.

Passes - An intentional played ball from one player to another. Opta adds a wholerange of qualifiers to each pass event, so that various things can be measured:

• Chipped pass - a lofted ball where there is a clear intended recipient

• Headed pass - a header where there is a clear intended recipient

• Launch - a long high ball into space or into an area for players to chase or challengefor the ball


• Cross - a pass from a wide position into a specific area in front of the goal

• Flick-on - a glancing pass with head or foot onto a team mate where the ball ishelped on in the same general direction

• Pull back - a pass inside the penalty area which is pulled back from the goal-line tothe centre of the penalty area

• Lay-off - a ball returned back to where it came from (usually by a forward) with onetouch

• Through Ball - a pass splitting the defence for a team-mate to run on to.

Each pass is logged with X and Y co-ordinates for its point of origin and destination.This allows Opta to log the following:

• Passes broken down area of the pitch for example by own half/opposition half ordefensive/middle/final third or left/right/centre

• Passes broken down by half, for example short/long, short medium/long

• Pass direction, for example backwards/sideways/forwards.

Of course, the event based nature of the data is such that you can calculate anycombination such as chipped passes over 20 yards in the final third that go sideways. Optaalso logs whether the pass is from open play or a dead ball situation such as a corner, afree kick, a throw or goalkeeper distribution from hands or goal kicks.

Pass completion - This is simply a formula where Successful passes are dividedby Total attempted passes in whichever combination of passes is selected. Usually, passcompletion excludes crosses. Crosses are usually treated separately and Crossing success isthe percentage of successful crosses out of the total attempted.

Touch/Unsuccessful touch - When the ball bounces off a player and there is nointentional pass, we award a touch. Where there is a mis-control we award an Unsuccessfultouch.

Dribbles/Take-ons - This is an attempt by a player to beat an opponent inpossession of the ball. A successful dribble means the player beats the defender whileretaining possession, unsuccessful ones are where the dribbler is tackled, Opta also logattempted dribbles where the player overruns the ball.

Tackles - A tackle is defined as where a player connects with the ball in groundchallenge where he successfully takes the ball away from the man in possession. All tacklesare really a successful event. A Tackle Won is deemed to be where the tackler or one of his


team-mates regains possession as a result of the challenge, or that the ball goes out of playand is "safe". A Tackle Lost is where a tackle is made but the ball goes to an oppositionplayer.

Missed Tackles - This is where a player attempts to challenge for the ball anddoes not make it – it is calculated by adding fouls with an attempted tackle qualifier tochallenge lost.

Clearance - This is a defensive action where a player kicks the ball away from hisown goal with no intended recipient of the ball.

Block - This is where a player blocks a shot from an opposing player.

Interception - This is where a player intentionally intercepts a pass by movinginto the line of the intended ball.

Recovery - This is where a player wins back the ball when it has gone loose orwhere the ball has been played directly to him.

Shield ball out of play - Where a player shields the ball from an opponent andis successful in letting it run out of play.

Foul conceded - Any infringement that is penalised as foul play by a referee.

Foul won - Where a player is fouled by an opponent. There is no foul won for ahandball or a dive where a free kick is conceded.

Offside - Awarded to the player deemed to be in an offside position where a freekick is awarded.

Duels - A duel is an 50-50 contest between two players of opposing sides in thematch. For every Duel Won there is a corresponding Duel Lost depending on the outcomeof the Duel.

Aerial Challenge won - Aerial Challenge lost - This is where two playerschallenge in the air against each other. The player that wins the ball is deemed to havewon the duel. When more than two players are involved the player closest to the duelwinner is given an Aerial Duel lost.

Successful Take-on/Dribble - Challenge lost - The player who has beenbeaten is given a Challenge lost if they do not win the ball.

Tackle - Unsuccessful Take-on/Dispossessed - A tackle is awarded if a playerwins the ball from another player who is in possession. If he is attempting to beat thetackler, the other player will get an unsuccessful Take-on. If he is in possession but notattempting to "beat"his man, then he will get a dispossessed.

Smother - Unsuccessful Take-on - A goalkeeper who comes out and claims theball at the feet of a forward gets a smother, similar to a tackle.


Foul won-Foul conceded - The player winning the foul is deemed to have wonthe duel and the player committing the foul having lost the duel.

Save - A goalkeeper preventing the ball from entering the goal with any part ofhis body. Saves are broken down into:

• Hands/Feet/Body

• Caught/Collected/Parried Safe/Parried Danger area/Fingertip

• Diving/Standing/Reaching/Stooping

Clean Sheet - A player or team who does not concede a goal for the full match.

Penalty faced - We log which way a goalkeeper dives regardless of the outcomeof the penalty.

Catch - A high ball that is caught by the goalkeeper

Punch - A high ball that is punched clear by the goalkeeper.

Drop - A high ball where the goalkeeper gets hands on the ball but drops it fromhis grasp.

Cross not claimed - When a goalkeeper comes off his goal line to claim a highball and misses the ball.

Catch Success - The percentage of high balls that a goalkeeper tries to deal withwhere he is successful - Catches+Punches divided by total high balls he came for.

Keeper Sweeper - When a goalkeeper comes out of his goal to sweep up behindhis defence and attempt to clear the ball.

Touches - A sum of all events where a player touches the ball, so excludes thingslike Aerial challenge lost or Challenge lost.

Disciplinary Points - For Opta Discipline tables, we award one point per foulconceded, three points per yellow card and six per red card. For Referees’ tables we alsoadd three points per penalty awarded.

2014 monografia final

Documents