Embed Size (px)
DESCRIPTION
Sugestões de Assuntos de Projetos Métodos de Computação Inteligentes 2002. Jacques Robin DI-UFPE. Roteiro. Lista dos assuntos Assuntos sobre agentes de gerenciamento de informação na web Assuntos sobre sistemas inteligentes multi-agentes Futebol de robô Cálculo de eventos - PowerPoint PPT Presentation
Citation preview
Sugestões de Assuntos de ProjetosSugestões de Assuntos de ProjetosMétodos de Computação Métodos de Computação
InteligentesInteligentes20022002
Jacques RobinDI-UFPE
RoteiroRoteiro
Lista dos assuntos Assuntos sobre agentes de gerenciamento de
informação na web Assuntos sobre sistemas inteligentes multi-agentes Futebol de robô Cálculo de eventos Abdução com cálculo de eventos Lógica de escolhas independentes
Lista do assuntosLista do assuntos
Agentes de gerenciamento de informação na web: Agente gerenciador de currículos múltiplos na web Agente facilitador de alocação de docente, horário e
sala para disciplinas baseado na resolução de restrições
Estudo de viabilidade de uma máquina de inferência baseada em XSLT
Futebol de robô: Componente de agente reativo com estado interno de futebol
de robô Ontologia para um simulador 3D de futebol de robô
Representação de conhecimento e raciocínio multi-agentes Planejador abdutivo lógico orientado a objetos baseado no
cálculo de evento Maquina de inferência lógica orientada a objetos bayesiana
baseada em conceitos das teorias da decisão e dos jogos?
Agente gerenciador de Agente gerenciador de currículos múltiplos na web currículos múltiplos na web
Agentes de extração e manutenção de informação da web
Agente monitora páginas web com currículos de uma pessoa em formatos diferentes
Quando uma página é modificada, regras de correspondência entre os campos dos vários currículos são aplicadas para propagar as modificações automaticamente para os outros currículos.
Interface de notificação por e-mail Implementação JEOPS ou Java+XSLT Estudo de caso com necessidade prática real no CIn
Agente facilitador de alocaçãoAgente facilitador de alocaçãode docente, horário e sala para de docente, horário e sala para
disciplinas baseado na resolução de disciplinas baseado na resolução de restrições restrições
Agentes web de automação de tarefas administrativas Alocação docentes: dados conjunto de disciplinas a ministrar,
carga horária a cumprir por cada docente, área de pesquisa de cada docente, preferências de cada docente, avaliação docentes por discentes, experiência prévia de ensino de cada docente, alocar um ou dois docentes por cada disciplina
Alocação de horário e sala: dados conjuntos de disciplinas com docente alocado e alunos matriculados, restrições de horários do docente e dos alunos e a capacidade das salas, alocar um horário e uma sala para cada disciplina
Todos os dados mantidos em um BD persistente e acessível em leitura e escritura via formulário web
Implementação usando Java para camada de interface, SQL para camada de dados e Eclipse para camada de resolução automática de restrições
Estudo de caso com necessidade prática real no CIn
Estudo de viabilidade de Estudo de viabilidade de uma máquina de inferência baseada em uma máquina de inferência baseada em
XSLT XSLT
Web semântica Agentes de informação inteligentes baseados em XML Estudo da literatura comparando sistemas dedutivos e sistemas de
re-escritura Estudo da literatura sobre uso de XSLT para raciocínio automático Monografia sugerindo um mapeamento entre os conceitos de
Prolog ou sistemas de produção e conceitos de XSLT Tentativa de implementação de um protótipo de um interpretador
Prolog ou sistemas de produção em XSLT Usar como entrada e saída RuleML, uma codificação em XML de
regras e termos de Prolog ou de sistemas de produção Teste sobre programas Prolog ou sistemas de produção brinquedos Potencial para publicação
<?xml version=“1.0” encoding=“iso-8859-1”?><greeting>Hello, world!</greeting>
Hello.xml
<html><head>
<title>Today’s greeting</title></head><body>
<p>Hello, world!</p></body></html>
Hello.html
<?xml version=“1.0” encoding=“iso-8859-1”?><xsl:stylesheet version=“1.0” xmlns:xsl=“http://www.w3.org/1999/XSL/Transform”><xsl:template match=“/”>
<html><head>
<title>Today’s greeting</title></head><body>
<p><xsl:value-of select=“greeting”/></p></body></html>
</xsl:template></xsl:stylesheet>
Hello.xsl
Linha de comando para transformar Hello.xml em Hello.html via Hello.xsl:
saxon Hello.xml Hello.xsl > Hello.html
Motivação e desafios da RoboCupMotivação e desafios da RoboCup
Integrar pesquisa e tecnologia fragmentadas da IA Percepção computacional (visão, integração de sensores) Robótica (controle e integração de ações físicas) Raciocínio automático, representação do conhecimento e
planejamento (reativo e deliberativo) Aprendizagem de máquina Sistemas multi-agentes e IA distribuída (comunicação,
cooperação, inteligência coletiva emergente) IA tempo-real
Problemática: Arquitetura de sistemas multi-agentes Metodologia de desenvolvimento de sistemas multi-agentes IA embarcada
Motivação e desafios da RoboCupMotivação e desafios da RoboCup Novo teste de Turing para a IA depois do xadrez
1997:2 x 1
2050?:2 x 1
DivisãoDivisãoSoftbotsSoftbots
Soccer ServerUDP/IP UDP/IP
Client 1
Client 11Client 11
Client 1
Time A Time BSoccer Monitor
SoccerServer: propriocepçãoSoccerServer: propriocepção
Parâmetros: senseBody(Time, % momento da propriocepção
viewMode(Quality, Width), % compromisso entre largura, % qualidade e freqüência da visão stamina(Stamina, % reserva de energia do jogador % parcialmente: - consumida por cada ação % - reabastecida a cada ciclo Effort) % f(Stamina) = percentual da força desejada % da próxima ação efetivamente disponível Speed, % ~ velocidade do jogador HeadAngle, % ângulo cabeça/corpo actionCounts(Kicks, Dashes, Turns, Says, NeckTurns) % número de ações de cada tipo já executada pelo jogador )
Freqüência: 1 por ciclo
SoccerServer: parâmetros da visãoSoccerServer: parâmetros da visão
see(Time, % tempo da visão ObjName, % estrutura identificando objeto visto Distance, % posição relativa do objeto visto em coords Direção, % polares centrado no jogador olhando DistChng, DirChng, % derivadas dessas coordenadas
polares BodyDir, % quando objeto visto é um jogador, orientação HeadDir) % do corpo e da cabeça relativamente a direção
ObjName = ball | player(Team,Number) | goal({l;r}) | % l = left, r = right line({l|r|t|b}) % t = top, b = bottom flag/1 | % pontos de referência no campo: flag/2 | % com argumentos l,r,t,b, e/ou flag/3). % c = center, p = penalty area, g = goalpoast.
SoccerServer: limites da visãoSoccerServer: limites da visão
Campo: circulo de raio VisibleDistance fixo ao redor do jogador cone centrado no rosto do jogador de ângulo ViewWidth
= {180;90;45} escolhido pelo jogado Clareza: diminuí com a distância
de perto direção e distância do objeto e se for jogador também cor e número
de longe apenas direção do objeto e se for jogador sem cor nem número
variação contínua entre os dois influência pela escolha de ViewQuality pelo jogador
Confiabilidade: ruído aumenta com distância Freqüência: inversamente proporcional a
ViewQuality e ViewWidth
SoccerServer: audiçãoSoccerServer: audição
Parâmetros: hear(Time, % tempo da audição
Direction, % angulo da procedência da mensagem auditíva % 2 exceções: Direction = self ou refereeMessage) % string da mensagem em linguagem natural % exceção: linguagem artificial para mensagens % do juiz = kick_off_l | kick_in_l | % corner_kick_r | ...
Limites: Raio = 50m Freqüência:
1 mensagem de jogador por ciclo caso vários são mandados, apenas o primeiro é ouvido
Nenhum limite para mensagens do juiz
SoccerServer: açõesSoccerServer: ações
move(X,Y): posicionar jogador no início do jogo
dash(Power): acelerar no eixo com força Power
turn(Moment): girar corpo de um angulo dependente de Moment e da velocidade do jogador
turnNeck(Angle): girar pescoço relativo ao corpo
kick(Power,Dir): chutar na direção Dir com força Power
catch(Dir): mergulhar na direção Dir para pegar bola; reservado para goleiros
say(Message): mandar string no único canal de comunicação compartilhado pelos 22 jogadores
change_view(Angle,Quality): mudar compromisso entre largura, profundidade e freqüência da visão Angle = ângulo do cone de visão,
180, 90 ou 45 Quality =
high: direção e distancia de cada objeto no cone de visão
low: apenas direção dos mesmos Freqüência diminua
automaticamente quando Angle e Quality aumentam
SoccerServer: tipo de ambienteSoccerServer: tipo de ambiente
inacessível (percepção parcial e ruidosa) não determinístico:
execução ruidosa das ações imprevisibilidade das escolhas do agentes adversários não confiabilidade de UDP/IP
dinâmico (o jogo é tempo-real, limite de 100ms para raciocinar sem o ambiente mudar)
contínuo (parâmetros reais em algumas percepções e ações) ambos cooperativo e antagônico relacional: envolve raciocinar sobre várias e complexas
relações espaciais, temporais e inter-agentes multi-granular: requer vários níveis de abstração entre
percepções e ações atômicas
SoccerServer: tipos de conhecimento e SoccerServer: tipos de conhecimento e raciocínios necessários raciocínios necessários
Interpretar percepções para atualizar: Modelo do ambiente Objetivo corrente Percepções físicas x comunicativas
Prever estado futuro do ambiente resultando: Da continuação dos eventos interpretados Dos efeitos das ações a executar
Escolher a melhor próxima ação em função: Do objetivo corrente Da previsão do estado futuro do ambiente resultando dessa
ação (ou da seqüência de ações iniciada) Ações de atuação x de percepção x de comunicação
Ontologia para um simulador Ontologia para um simulador 3D de futebol de robô 3D de futebol de robô
Representação do conhecimento e ontologia de um domínio complexo
Modelar em UML uma API para um SoccerServer 3D Definir ontologia (classes de entidades e relações,
restrições de valores) de um ambiente de simulação de futebol 3D
Definir vários conjuntos de percepções e ações dos agentes, cada um a um nível diferente de abstração
Usar diagramas de classe e restrições OCL Relevância prática essencialmente para jogos,
sistemas multi-agentes, simulação e robótica
Projeto Maracatu RFCProjeto Maracatu RFC
Engenharia de software, representação de conhecimento e raciocínio automático para software multi-agentes
Estudo de caso: desenvolver time de futebol de robô simulado do CIn para mandar para RoboCup em 2003 ou 2004
Estado atual: Protótipo parcial de time desenvolvido pelo mestrando Alexandre
Damasceno (candidato ao doutorado) Agente reativo com estado interno baseado na dedução
automática Abordagem atual:
Modelagem detalhado com UML e OCL Implementação em Flora, uma linguagem de programação e
representação do conhecimento híbrida lógica orientada a objetos Futuro:
Agente misto reativo, deliberativo, otimizador e aprendiz Integração de redes de decisões probabilistas, aprendizagem por
reforço e programação em lógica indutiva
Arquitetura do Maracatu RFCArquitetura do Maracatu RFC
RoboFlora
Comportamento
Preditor
ReativoReativoObjetivo
Delibera-tivo
Dedutivo
Delibera-tivo
DedutivoHierárqui-
co
Delibera-tivo
Abdutivo
Delibera-tivo
AbdutivoHierárqui-
co
Interno
Externo
PreditorComunicação
VestuárioRegras Intransigentes
Estado Interno
ObjetivosSituação Modelo do
Ambiente
Formação Situação
Ação deAtuação
Ação dePercepção
Comunicação Comunicação
Atualização
Componente de agente reativo Componente de agente reativo com estado interno de futebol de robô com estado interno de futebol de robô
Representação híbrida de conhecimento objetos + regras + lógica, para sistemas multiagentes
Raciocínio automático multiagentes híbrido dedução + herança Planejamento situado multiagentes sem cooperação explícita
mas emergindo da interação no ambiente de agentes reativos com modelo do ambiente e dos outros agentes
Metodologia de desenvolvimento combinando tecnologia padrão de engenharia de software com tecnologias experimentais de IA
Focalizado nas camadas de alto níveis estratégicas do agente através do uso da API RoboFlora que cuida da interface com o SoccerServer, da manutenção do modelo do ambiente e da decomposição de ações abstratas de alto níveis em ações primitivas diretamente executáveis pelo SoccerServer
Relevância prática essencialmente para jogos, sistemas multiagentes, simulação e robótica
Potencial para publicação e participação na RoboCup 2003
Cálculo de eventos: definição e Cálculo de eventos: definição e motivaçãomotivação
Conjunto de regras (axiomas) e predicados independentes do domínio de aplicação para manutenção do modelo de um ambiente dinâmico usando programação em lógica
Mais flexíveis do que o cálculo de situações por: modelar o tempo em termos de intervalos de tempo no lugar
de apenas pontos de tempo permitir raciocinar em termos de eventos com duração e não
apenas de situações instantâneas permitir raciocinar em termos de narrativas (sucessões de
eventos) incompletas e não apenas cadeias completas de situações
Útil tanto para interpretação das percepções, como para previsão das conseqüências das ações e seu planejamento
Cálculo de eventos: Cálculo de eventos: exemplo de axiomatizaçãoexemplo de axiomatização
holdsAt(F,T) :- initiallyp(F), not_Clipped(0,F,T).
holdsAt(F,T3) :- happens(A,T1,T2), initiates(A,F,T1), T2 < T3,
clipped(T1,F,T3).
not_HoldsAt(F,T) :- initiallyN(F), not_Clipped(0, F, T).
not_HoldsAt(F,T3) :- happens(A,T1,T2), terminates(A,F,T1), T2 < T3, not_Declipped(T1, F, T3).
clipped(T1, F, T4) :- happens(A, T2, T3), T1<T3, T2<T4, (terminates(A,F,T2);
releases(A, F, T2)).
decliped(T1, F, T4) :- happens(A, T2, T3), T1<T3, T2<T4, (initiates(A, F, T2); releases(A,F,T2)).
happens(A,T1,T2) :- T1<=T2.
Cálculo de eventos: exemplo de base de Cálculo de eventos: exemplo de base de conhecimento do domínioconhecimento do domínio
Definição do modelo do ambientes:initiates(go(X),at(X),T).terminates(go(X),at(Y),T) :- not (X = Y).initiates(buy(X),have(X),T) :- sells(Y,X), holds_at(at(Y),T).sells(hws,drill).sells(sm,milk).sells(sm,banana).
Regras estrategicas:buy(milk) :- holds_at(have(milk),T).buy(drill) :- holds_at(have(drill),T).
Abdução x DeduçãoAbdução x Dedução
Dedução: Dado regra causal C P1 P2, e fatos F1, F2
se unificando respectivamente com P1, P2 Concluir: C
Abdução: Dado regra causal C P1 P2, fato C, e fato F2 se
unificando com P2 Fazer a hipótese que F1 que se unifica com P1 ocorreu,
e que F1 (junto a F2) explica então a ocorrência de C Equivalente a deduzir F1
a partir dos fatos C, F2 e a regra diagnóstica P1 C P2
Uma máquina de inferência abdutiva Uma máquina de inferência abdutiva usando o cálculo de eventousando o cálculo de evento
Sem negação por falha:abdemo([], R, R).abdemo([G|Gs], R1, R2) :- abducible(G), abdemo(Gs, [G|R1], R2).abdemo([G|Gs1], R1, R2) :- axiom(G,Gs2), append(Gs2, Gs1, Gs3),
abdemo(Gs3, R1, R2).
Com negação por falha:abdemo([], R, R, N).abdemo([G|Gs], R1, R3, N) :- abducible(G), abdemo_nafs(N, [G|R1], R2),
abdemo(Gs, R2, R3, N).abdemo([G|Gs1], R1, R2, N) :- axiom(G,Gs2), append(Gs2, Gs1, Gs3),
abdemo(Gs3, R1, R2, N).abdemo([not(G)|Gs], R1, R3, N) :- abdemo_naf([G], R1, R2),
abdemo(Gs, R2, R3, [[G] | N]).abdemo_naf([G|Gs1], R1, R2) :- not resolve(G, R, Gs3).abdemo_naf([G|Gs1], R1, R2) :- findall(Gs2, (resolve(G1, R1, Gs3), append(Gs3, Gs1, Gs2)), Gss), abdemo_nafs(Gss, R1, R2).
Abdução com cálculo de eventos: Abdução com cálculo de eventos: aplicaçõesaplicações
Interpretar percepções: Dado:
modelo parcial model1 percepção percept regra causal percept model1 model2
Abduzir modelo mais completo model1 model2 Planejamento:
Dado: modelo do ambiente atual modelAtual objetivo futuro a atingir objetivo regra causal objetivo modelAtual plano
Abduzir seqüência de ação a executar plano
Projeto Florabdemo:Projeto Florabdemo:
Planejador abdutivo lógico orientado a objetos baseado no cálculo de evento
Representação híbrida de conhecimento objetos + regras + lógica Raciocínio automático híbrido dedução + abdução + herança Raciocínio em ambiente inacessível dinâmico por agente reativo
com estado interno e por agente deliberativo Meta-programação em lógica orientada a objeto Desenvolver versão Flora do planejador abdutivo Abdemo Prolog
baseado no cálculo de evento Teste com domínios brinquedos (Mundo dos Blocos, Shakey) e, se
tiver tempo, com agente deliberativo de futebol de robô simulado Relevância prática essencialmente para jogos, simulação e
robótica Potencial para uma publicação Para saber mais sobre atualização do modelo do ambiente e
planejamento por um agente como abdução usando o cálculo de evento ver as publicações de Murray Shanahan http://casbah.ee.ic.ac.uk/~mpsha/pubs.html
Lógica de escolhas independentes:Lógica de escolhas independentes:definição e motivaçãodefinição e motivação
Lógica de escolhas independentes (ICL) Formalismo de representação de conhecimento para sistemas
multi-agentes otimizadores em ambientes inacessíveis, não deterministas, dinâmicos, relacionais e contínuos
Integração de: programação em lógica redes bayesianas teoria da decisão teoria dos jogos
Para saber mais sobre esse formalismo de especificação e implementação de agentes inteligentes, ver a página das publicações de David Poole: http://www.cs.ubc.ca/spider/poole/pubs.html
ICL: exemplo ilustrando integraçãoICL: exemplo ilustrando integração lógica com probabilidades lógica com probabilidades
carrying(key,s(T)) <- do(pickup(key),T) & at(robot,Pos,T) & at(key,Pos,T) & pickup_succeeds(T).
carrying(key,s(T)) <- ~ do(pickup(key),T)& ~ do(putdown(key),T) & carrying(key,T)& ~ drops(key,T).
random([pickup_succeeds(T): 0.7, pickup_fails(T):0.3]).
drops(key,T) <- slippery(key,T) & drop_slippery_key(T).
drops(key,T) <- ~ slippery(key,T) & fumbles_key(T).random([drop_slippery_key(T):0.9, holds_slippery_key(T):0.1]).random([fumbles_key(T):0.2, retains_key(T):0.8]).
at(key,Pos,T) <- carrying(key,T) & at(robot,Pos,T).at(key,Pos,s(T)) <- ~ carrying(key,s(T)) &
at(key,Pos,T).
at(robot,Pos,s(T)) <- do(goto(Pos),T) & goto_succeeds(T).
at(robot,Pos1,s(T)) <- do(goto(Pos),T) & at(robot,Pos1,T) & ~ goto_succeeds(T).
at(robot,Pos,s(T)) <- ~ goto_action(T) & at(robot,Pos,T).
goto_action(T) <- do(goto(Pos),T).
random([goto_succeeds(T):0.93,goto_fails(T):0.07]).
slippery(key,s(T)) <- slippery(key,T) & stays_slippery(T).
slippery(key,0) <- initially_slippery(key).
random([stays_slippery(T):0.75,
stops_being_slippery(T):0.25]).
random([becomes_slippery(T):0.05,
stays_unslippery(T):0.95]).
random([initially_slippery(key):0.5,
initially_unslippery(key):0.5]).
ICL: exemplo ilustrando integraçãoICL: exemplo ilustrando integraçãocom teoria da decisãocom teoria da decisão
Exemplo do pênalti:utility(kicker, 1) :- goal.utility(kicker, 0) :- not goal.utility(goalie, 1) :- goal.utility(goalie, 0) :- not goal.
goal :- kicks(D), jumps(D), goal_if_same_dir.goal :- kicks(left), jumps(right), goal_if_kl_jr.goal :- kicks(right), jumps(left), goal_if_kr_jl.
Alternativas: para o chutador: {kicks(right), kicks(left)} para o goaleiro: {jumps(right), jumps(left)} para o ambiente: {goal_if_same_dir,no_goal_if_same_dir},
{goal_if_kl_jr,no_ goal_if_kl_jr}, {goal_if_kr_jl,no_goal_if_kr_jl}
ICL: exemplo ilustrando integraçãoICL: exemplo ilustrando integraçãocom teoria da decisãocom teoria da decisão
Probabilidades do ambiente:p0(goal_if_same_dir) = 0.9.p0(goal_if_kl_jr) = 0.1.p0(goal_if_kr_jl) = 0.2.
Estratégias probabilistas dos agentes:Pg = Pgoalie(jump(right))Pk = Pkicker(kick(right))
Resultado do raciocínio: P(goal) = PkPg0.9 + (1-Pk)(1-Pg)0.9 + (1-Pk)Pg0.1+(1-Pg)0.2
Uma máquina de inferência baseada na Uma máquina de inferência baseada na lógica de escolhas independentelógica de escolhas independente
rule(R): Os fatos são dados em forma de rule(R), onde R é uma regra da forma H:-B ou um átomo.
H <- B: é o mesmo que uma regra (H :- B). Regras com corpo vazio é representada como (H <- true) ou rule(H).
random(X, h, [x1:p1,...,xn,pn]): onde h é um átomo que contem a variável X, e xi são termos diferentes. Isso declara o átomo h com X substituído por cada xi onde P(h[xi]) = pi.
controllable([h1, ..., hn]): declara as variáveis disjuntas hi (o agente pode escolher um dos hi).
explain(G, C): busca por todas as explicações de G dadoo controllable C.
thconsult(filename): chama o arquivo chamado filename.how(G,C,N): usado para explicar a N-ésima explicação para G dado
C. diff(G,C,N,M): imprime a diferença na árvore de prova para a N-
ésima explicação de G dado C.
Uma máquina de inferência baseada na Uma máquina de inferência baseada na lógica de escolhas independentelógica de escolhas independente
check(G): checa por regras disjuntas da explciação de G.check(G1, G2): checa cada caso onde G1 e G2 são verdadeiros.recap(G): recauchuta a explicação de G, com a probailidade de
cada explicação dado G.recap: dá a probabildaide de todos os objetivos explicados.check_undef: procura por átomos não definidos.clear: limpa a base de conhecimento.
Projeto OICLProjeto OICL
Maquina de inferência lógica orientada a objetos bayesiana baseada em conceitos das teorias da decisão e dos jogos
Representação híbrida de conhecimento objetos + regras + lógica + probabilidades + utilidade
Raciocínio automático híbrido dedução + abdução + herança + otimização probabilística de utilidade
Raciocínio em ambiente inacessível, dinâmico e não determinista por agente reativo com estado interno
Meta-programação em lógica orientada a objeto Desenvolver versão Flora do meta-interpretador Prolog para
Independent Choice Logic (ICL) que integra dedução lógica da 1a ordem com otimização probabilística de utilidade
Teste com domínios brinquedos (Mundo dos Blocos, Shakey) e, se tiver tempo, com agente reativo com estado interno de futebol de robô simulado
Relevância prática essencialmente para jogos, simulação e robótica
Potencial para uma publicação
