INTRODUÇÃO

O capítulo 3 deste livro, revisa a pesquisa literária envolvida com os componentes de modelagem do aluno de sistemas tutores inteligentes. Revisa soluções que tem sido encontradas para o problema de modelagem do aluno e discute as técnicas que tem sido descobertas.

Um sistema tutor inteligentes, ou ITS, é um programa de computador que instrui o aluno de forma inteligente. Não há uma definição aceita do que é ensinar inteligentemente. Porém uma característica compartilhada por muitos ITSs é a de que eles deduzem um modelo de compreensão atual do aluno através de um assunto e usam este modelo individualizado para adaptar a instrução às necessidades do aluno.

O componente de um ITS que representa o estado atual de conhecimento do aluno é chamado modelo do aluno (student model). A dedução do modelo do aluno é chamada diagnóstico (diagnosis), por ser parecido com o trabalho de um médico que pode deduzir uma doença oculta através da observação dos sintomas. Um sistema de diagnóstico ITS descobre um estado cognitivo oculto (o conhecimento do aluno sobre o assunto) através de comportamento observável.

O modelo do aluno e o módulo de diagnóstico são fortemente entrelaçados. O modelo do aluno é uma estrutura de dados e o diagnóstico é um processo que manipula esses dados. Os dois componentes devem ser planejados juntos. Este projeto do problema é chamado problema de modelagem do aluno (student modeling problem).

O PROBLEMA DA MODELAGEM DE ALUNO

Em geral, a entrada para o diagnóstico é garantida através da interação com o aluno. Os tipos particulares de informação disponíveis para o módulo de diagnóstico depende de toda aplicação ITS. As informações poderiam ser respostas para as perguntas feitas pelo ITS: ex.: movimentos feitos em um jogo, ou comandos emitidos a um editor.

Assim como a entrada a saída do módulo de diagnóstico também é difícil de limitar. Na realidade, não faz sentido falar sobre o produto do diagnóstico como "saída" (resultado) (Aqui a analogia ao diagnóstico de um médico é quebrada). O resultado é uma base de dados, o modelo do aluno, que reflete exatamente o estado de conhecimento do aluno. O modelo de aluno é passado para outros módulos do ITS por vários propósitos. A seguir são listados alguns usos do modelo do aluno:

FUNÇÕES QUE UTILIZAM O MODELO DE ALUNO:

AVANÇADO

Advancement: Alguns ITS usam um curso estruturado, ou seja, um aluno é movido para o próximo tópico do currículo somente quando ele tem dominado o tópico atual. Em tais aplicações, o modelo do aluno é representado pelo seu nível de domínio. Periodicamente, os ITS consultam o modelo do aluno sobre o nível de domínio do tópico atual, pesa, e decide se avança o aluno para o próximo tópico. O Advancement é útil não somente com curso linearmente estruturado, onde as instruções habitam um tópico de cada vez, mas também num curso estruturado, onde o aluno exercita vários temas ou técnicas ao mesmo tempo. Exemplo: WUSOR ITS (Goldstein, 1982). (ver exemplo do WUSOR ITS no artigo original)

OFERECENDO UM CONSELHO NÃO SOLICITADO

Oferring unsolicited advice: Alguns ITSs são como treinadores atléticos que dão conselhos somente quando eles vêem que o aluno precisa. Se o aluno esta desempenhando bem, o treinador permanece em silêncio. Um bom treinador irá também permanecer em silêncio se o aluno cometer um erro numa situação que seja muito complicada para que uma interação pedagógica bem-sucedida aconteça. Para oferecer um conselho não solicitado no momento certo, o ITS deve conhecer o estado do conhecimento do aluno. Para isto, ele lê o modelo do aluno.

GERAÇÃO DO PROBLEMA

Problem generation: Alguns ITS geram problemas para o aluno dinamicamente ao invés de seqüencializar através de uma lista predefinida de problemas ou permitem ao aluno inventar problemas para resolver. Em muitas aplicações, um bom problema é apenas um pouco além das capacidades atuais do aluno. Para encontrar onde a capacidade atual do aluno falha, o módulo de geração do problema consulta o modelo do aluno.

ADAPTANDO EXPLICAÇÕES

Adapting explanations: Quando bons tutores explicam algo aos alunos, eles usam somente conceitos que os alunos já conhecem. Para um ITS emitir boas explicações, ele tem que determinar o que os alunos já sabem. Para fazer isso, ele consulta o modelo do aluno.

 

As funções anteriores são alguns dos modos mais comuns de componentes ITS que usam o modelo de aluno, pois há muitos modos de se usar o modelo de aluno. Não se pode falar sensatamente sobre a saída do modulo de diagnóstico, nem classificar problemas de modelagem do aluno pelo relacionamento entrada-saída desejada. Faz sentido classificar estes problemas de acordo com as propriedades estruturais do modelo do aluno.

UM ESPAÇO TRIDIMENSIONAL DE MODELAGEM DE ALUNO

Esta seção revisa sistemas de modelagem do aluno existentes no contexto de uma classificação baseada parcialmente nas propriedades estruturais do modelo do aluno e parcialmente na entrada disponível do módulo de diagnóstico. Foram construídos aproximadamente vinte sistemas de modelagem do aluno e há outros em desenvolvimento. Há muitas diferenças entre eles. A classificação apresentada aqui tem intenção de apresentar as diferenças nos problemas de modelagem de aluno que realmente se diferem nas técnicas de solução. Se a classificação é correta, ela pode ser usada para predizer que tipos de técnicas de modelo de aluno poderiam ser mais úteis para alguma novo problema de modelagem de aluno. É necessário dizer que, tais predições poderiam ser só o ponto de partida em um longo processo de projeto que resulta em um sistema adaptado às demandas de um ITS particular. Realmente, como mais ITS são construídos, a percepção de que diferenças realmente importam pode ser esperado que mude. A mudança é uma razão de porque a construção de ITS esta ainda em estágio de pesquisa e não tem ainda se tornada uma tecnologia madura. Em resumo, a seguinte classificação é ambas heurística e tentativa.

A classificação tem três dimensões. A primeira relata a entrada, e as outras são propriedades intelectuais e modelo do aluno.

VOLUME DE DADOS

A entrada para a unidade de diagnóstico consiste em vários tipos de informação sobre o que o aluno está fazendo ou está dizendo. Disto, a unidade de diagnóstico tem que deduzir que o aluno está pensando e acreditando. Claramente, quanto menos informação a unidade tem, mais difícil é sua tarefa. A dimensão do volume de dados é uma categorização aproximada da quantidade e qualidade da entrada.

Três níveis de informação bastam para captar variações entre os ITS existentes. Para explicá-lo assume-se que os alunos colocam seus próprios problemas ou são colocados pelo ITS. Se a resolução do problema levar mais do que poucos milisegundos, então pode-se seguramente assumir que o aluno vá inserir uma série de estados mentais.

O maior volume de dados que um ITS poderia atingir seria uma lista de estados mentais que o aluno atravessa para resolver seus problemas. Estados mentais humanos não são completamente acessíveis por máquina. Assim nenhum ITS pode alcançar realmente este estado mental de volume de dados. Contudo, por perguntar várias questões ou por extrair protocolos verbais, um ITS pode obter informações indiretas que se aproximam ao estado mental do aluno. Então a categoria máxima de volume de dados são os estados mentais aproximados (approximate mental states).

Formas mais complicadas de resolução de problema, tais como resolução de equações algébricas ou jogos de xadres, o aluno faz mudanças observáveis que levam o problema de um estado de não resolução para o final, o estado resolução. Isto resulta em uma série de estados intermediários observáveis, tais como as posições num tabuleiro de xadrez ou equações escritas antes da última equação durante a resolução de uma equação algébrica.

Às vezes um ITS tem acesso a estes estados intermediários, e às vezes ele pode ver somente o estado final - Isto é, a resposta. As outras duas categorias de volume de dados são estados finais e estados intermediários (final states and intermediate states).

Para resumir, as três categorias, da máximo ao mínimo volume de dados, são os estados mentais, estados intermediário e estado final. Cada categoria é planejada para incluir informações de categorias abaixo dela. Os estados mentais incluem o estado intermediário e final . Estado intermediário inclui o estado final.

O Tutor LISP (Reiser, Anderson, & Farrel, 1985) ilustra bem o nível de volume de dados dos estados mentais. O Spade ITS (Miller, 1982) nunca foi completado, mas se tivesse sido, ilustraria o segundo nível de volume de dados. Em contraste, PROUST (Johson & Soloway, 1984; Johnson & Soloway, 1984b) é dado como o primeiro programa completo que o aluno submete ao compilador PASCAL. (ver explicacões sobre tais tutores no artigo original).

A dimensão do volume de dados é talvez a mais importante das três dimensões. Mais do que as outras, ela determina o algoritmo usado para o diagnóstico. Como é mostrado nas Técnicas de Diagnóstico, onde algoritmos de diagnóstico são discutidos em detalhes, são nove os algoritmos básicos. Cinco são úteis ao sistemas de volume de dados de estados finais, três são apropriados para sistemas de volume de dados de estados intermediários e um é apropriado para sistemas de volume de dados de estados mentais.

TIPO DE CONHECIMENTO ALVO

O modelo de aluno usado em sistemas antigos para treinamento baseado em computador não pode de fato gerar soluções de problema, embora eles sejam capazes de gerar uma probabilidade de uma solução correta.

A resolução de problemas requer alguns tipos de processo de interpretação que aplica conhecimento no modelo de aluno para o problema. Há dois tipos comum de interpretação, uma para o conhecimento procedural e um para o conhecimento declarativo. O interpretador para conhecimento procedural é simples. Ele não faz buscas mas toma decisões baseadas no conhecimento local.

Um intérprete declarativo procura constantemente sobre toda sua base de conhecimento. É como um bibliotecário que busca as respostas para uma pergunta do cliente através de referências, fatos e deduzindo as resposta. A representação do conhecimento procedural tem sido usada na resolução de equações algébricas, jogos, aritmética multicolumn, resolução de cáculos de integrais. A representação do conhecimento declarativo tem sido usado pela geografia e metereologia.

A distinção entre conhecimento procedural e declarativo é notório na inteligência artificial com uma leve diferenciação raramente útil. Porque ela está baseada na quantidade de trabalho que o intérprete executa, e porque o trabalho é uma qualidade essencialmente contínua, o limite entre eles não é nítido.

Exemplo: Medicina do conhecimento de GUIDON é parcialmente declarativa e parcialmente procedural. Programação do conhecimento de PROUST é ainda mais difícil de classificar.

A distinção entre conhecimento procedural e conhecimento declarativo é importante aqui porque a complexidade dos diagnósticos são diretamente proporcional a complexidade da interpretação. Na verdade, diagnóstico é o inverso da interpretação. A interpretação toma uma base do conhecimento e um problema e produz uma solução. O diagnóstico toma um problema e uma solução e produz uma base conhecimento. Quando o conhecimento declarativo é interpretado, muitos itens podem ser acessados de maneira a produzir uma solução. Quando o conhecimento declarativo é diagnosticado, a responsabilidade para uma resposta errada pode ficar com qualquer um dos vários itens que podem ser acessados produzindo esta resposta.

Estas considerações representam uma segunda dimensão do espaço dos problemas de modelagem de aluno. A maior distinção -procedural versus declarativa - já foi mencionada. Ela é útil para dividir conhecimento procedural dentro de duas sub-categorias plano e hierárquico. A representação hierárquica permite sub-objetivação enquanto que os planos não. A distinção entre a representação plana e a hierárquica afeta o diagnóstico. Um sistema diagnóstico para a representação plana precisa deduzir que condições estado-problema ativa cada operador. Isto é fácil porque o sistema pode ver ambos (estados problema e a aplicação do operador). Um sistema de diagnóstico para a representação hierárquica precisa deduzir condições, o estado-problema e os sub-objetivo. Mas ele não pode ver a atividade atual dos sub-objetivos, então a sua dedução do problema é muito difícil.

DIFERENÇA ENTRE ALUNO E ESPECIALISTA

ITSs, geralmente, empregam um modelo especialista bem como um modelo de aluno. O modelo especialista é usado para muitos propósitos, como prover explicações sobre o forma correta para resolver um problema. Os alunos se movem gradualmente de seus estados iniciais de conhecimento em direção ao domínio. A modelagem do aluno deve ser capazes de trocar naturalmente de uma representação iniciante para uma representação especialista. Conseqüentemente, muitos ITS usam a mesma linguagem de representação do conhecimento tanto para o modelo de aluno como para o modelo especialista. Conceitualmente, o ITS tem uma base de conhecimento para representar o especialista uma base de conhecimento diferente para representar o aluno.

Alguns sistemas que modelam alunos podem representar somente a falta de conceitos. Conceitualmente, o modelo de aluno é um subconjunto próprio do modelo especialista. Tais modelos de alunos são chamados de overlay models porque o modelo de aluno pode ser visualizado como um pedaço de papel furado que é colocado sobre o modelo especialista. Permitindo que somente um pouco do conhecimento seja acessado. Um modelo de aluno, então, consiste de um modelo especialista mais uma lista de itens que estão perdidos.

O tipo mais comum de modelo de aluno nesta classe emprega uma biblioteca de conceitos pré-definidos e conceitos perdidos. Os membros da biblioteca são chamados de bugs. Um modelo de aluno consiste de um modelo especialista mais uma lista de bugs. Esta técnica de biblioteca de bugs é o segundo tipo mais comum de modelagem do aluno.

Uma alternativa para a abordagem de bibliotecas de bugs é construir bugs de uma biblioteca parcial de bugs. Para resumir, as três maiores técnicas para representar as diferenças entre alunos e especialistas são: overlays, bibliotecas de bugs e bibliotecas parciais de bugs.

UM MAPA DO ESPAÇO

TÉCNICAS DE DIAGNÓSTICO

Nove técnicas de diagnóstico aparecem na literatura de ITS.

MODELO DE TREINAMENTO

A técnica model-tracing é provavelmente a técnica mais fácil de implementar porque ela assume que todos os estados mentais, significantes, do aluno estão disponíveis para o programa de diagnóstico. A idéia básica é usar um interpretador sub-determinado para modelar a resolução do problema. Com cada passo na resolução do problema, o interpretador sub-determinado pode sugerir um conjunto inteiro de regras que devem ser aplicadas a seguir, considerando que um interpretador determinístico pode sugerir somente uma regra. O algoritmo de diagnóstico "queima" todas essas regras, obtendo um conjunto de possíveis próximos estados. Um desses estados deve corresponder ao estado gerado pelo aluno. Sendo assim então é razoavelmente certo que o aluno utilize a regra correspondente para gerar o próximo estado mental. O nome model-tracing vem do fato de que o programa de diagnóstico somente traça a execução do modelo e compara com a atividade do aluno. O modelo de resolução de problemas deve ser altamente plausível psicologicamente para essas técnicas serem aplicadas.

PATH FINDING

Se o volume de dados não for grande o bastante para garantir a suposição de que o estudante tenha aplicado somente uma regra mental, então o modelo traçado torna-se inaplicável. Porém, ele é possível para um algoritmo path-finding antes do algoritmo model-tracing. Dados dois estados consecutivos, ele encontra um caminho, ou encadeia a aplicação das regras, que compreende o primeiro estado no segundo estado. O caminho é então dado para um algoritmo model-tracing, o qual considera ele como uma fiel reedição da seqüência do estado mental do aluno. O principal problema técnico do path finding é que existem, geralmente, muitos caminhos entre os dois estados dados. O path finding deve enviar todos os caminhos para o modelo investigador e ele permite a transação com a ambigüidade? Ele deve usar heurísticas para rejeitar caminhos improváveis ? Ele deve perguntar aos alunos o que eles fizeram? Esses temas merecem uma pesquisa posterior.

CONDIÇÃO INDUTIVA

Model-tracing assume que quaisquer dois estados consecutivos, no problema resolvido pelo aluno, podem ser conectados a uma regra em seu modelo. Eles colocam fortes demandas na perfeição do modelo. Revestindo modelos geralmente ele não trabalhará. Modelos de bibliotecas de bugs contêm um grande número de bugs. Parte da biblioteca de bugs é então usada como base para a modelagem do aluno. Dados dois estados consecutivos, o sistema constrói uma regra que converte um estado no outro. Apesar deles serem potencialmente de muitas formas, para construir tais regras buggy, a única técnica que tem sido experimentada é até aqui uma indução de condição.

Esta técnica requer duas bibliotecas. Uma é uma biblioteca de operadores que converte um estado em outro. A outra é uma biblioteca de predicados. A técnica assume que uma biblioteca de operadores é mais rica que quaisquer dois estados mentais consecutivos podendo ser igualados a aplicação de algum operador. Esse operador se torna o lado da ação da regra de produção que será gerada. O trabalho difícil é a determinação de que combinação lógica de predicados devem constituir o lado da condição de produção. A condição deve ser verdadeira para estados em que a regra tenha sido aplicada e falsa nos outros casos. O sistema correntemente tem um estado para o qual ele é verdadeiro; que é, o primeiro estado do par de estados. A confiança induz uma condição necessária para examinar mais estados. Estes estados podem vir de um registro de resoluções de problemas anteriores pelo aluno. O sistema pode também demorar na construção de regras até mais estados serem examinados na resolução posterior de problemas. Esta técnica parece requerer muito mais dados para a resolução de problemas do estudante como técnicas de diagnóstico para encobrir modelos ou bibliotecas de bugs feitas. Uma parte da biblioteca de bugs pode representar mais hipóteses para outros tipos de modelos, assim mais dados são necessários para discriminar entre eles.

RECONHECIMENTO DE PLANOS

A princípio, o path finding seguiu o modelo model tracing, com ou sem indução de regras, que pode diagnosticar qualquer coisa. Porém, quando os caminhos observados entre os estados são muito longos, o diagnóstico pode se tornar impossível ou não muito confiável. Reconhecimento de planos é um diagnóstico técnico que é similar ao path finding em que ele é um front end para o model tracing. Porém, ele é mais efetivo que o path finding para as circunstâncias especiais onde ele é aplicado.

Reconhecimento de planos requer que o conhecimento do modelo de aluno seja procedural e hierárquico, estados observados na solução de problemas por alunos são produzidos e disponibilizados para o programa de diagnóstico. Estes dois requisitos juntos ditam que um episódio da solução de problemas que pode ser analisado como uma árvore. Partindo das árvores estão as ações primitivas, como o movimento de uma peça de xadrez ou de escrever uma equação. Os nonleaf node da árvore são sub-objetivos, como que para pegar a rainha do oponente ou fatorar uma equação do segundo grau. O root node da árvore é o objetivo global. Links entre nodos da árvore representam os relacionamentos entre objetivos e sub-objetivos. Como tal uma árvore é, geralmente, chamada de plano, um misnomer de seu desenvolvimento prematuro na robótica. Reconhecimento de planos é o processo de inferência de uma árvore quando somente suas folhas são dadas. Computacionalmente, reconhecimento de planos é similar ao parsing de uma string com uma gramática livre de contexto, uma árvore parse é construída onde suas folhas são os elementos da string. O sistema CIRRUS, utiliza parsing para o reconhecimento de planos.

Quando o reconhecimento de planos é utilizada em diagnósticos, ela serve de front end para o model tracing. Assumindo que o reconhecimento de planos encontrando uma única árvore de planos que mede as ações do aluno, então o caminho mental do aluno é assumido como sendo uma primeira representação, esquerda-para-direita, transversal da árvore. Este caminho pode ser introduzido em um algoritmo model-tracing, o qual atualiza o modelo de aluno adequadamente.

São dois os temas técnicos a serem considerados: quando o reconhecedor de planos encontra mais que uma árvore consistente com as ações do aluno, o que fazer? e quando ele não encontra nenhuma? Para evitar a segunda situação, o sistema de reconhecimento de planos, geralmente usa o modelo de biblioteca de bugs em lugar de overlay models.

MODELO DE TREINAMENTO

A técnica model tracing assume técnicas e as regras do modelo de aluno que são modelos psicológicos bastante precisos de unidades de conhecimento empregados por um aluno. Em alguns casos, o modelo detalhado de cognição de aluno é impossível ou desnecessário. Em particular, um modelo de aluno bem granulado é provavelmente mais trabalhoso onde o tutor não pode ser adaptado para as intrincidades das concepções de alunos. Por exemplo, um modelo perfeito de erro na subtração do aluno é necessário se a solução do tutor é somente para ensinar o procedimento novamente. Em geral, o nível de diagnóstico e tutoring deve ser o mesmo.

Se um altamente granulado modelo de aluno é desejado, então uma variação do modelo tracing chamado issue tracing é apropriado. Ele é baseado na análise de um curto episódio da resolução de um problema em um conjunto de microskills ou papéis que são empregados durante o processo. A análise não explica como os temas interagem ou que papéis eles representaram na resolução do problema.

O primeiro passo no issue tracing é analisar os movimentos do aluno e os movimentos do especialista no tema. Cada tema tem dois contadores, usados ou deixados. Os contadores usados são incrementados por todos os temas nos movimentos do aluno. Contadores deixados são incrementados por todos os temas nos movimentos dos especialistas que não estão nos movimentos dos alunos. Se os contadores usados são altos e os contadores deixados são baixos, o estudante provavelmente entendeu o tema. Se os contadores deixados são altos (muitos) e os contadores usados baixos (poucos), então o aluno não entendeu o tema. Se ambos contadores são nulos o tema não foi iniciado ainda.

Este único processo de diagnóstico tem um problema oculto. Ignorância de qualquer um dos temas envolvidos nos movimentos do especialista é suficiente para causar uma negligência naquele movimento; contudo o modelo culpa o tema uniformemente por incrementar todos os seus contadores deixados. Isto introduz alguma inexatidão no modelo de aluno.

Estas probabilidades anteriores são dobradas na avaliação de que um aluno sabe o tema ou não. Avaliações baseadas em funções estatísticas tem sido utilizadas no tutor de cálculo de Kimball e outros sistemas de propósitos similares.

SISTEMAS ESPECIALISTAS

O sistema GUIDON de Clancey usa um modelo de aluno bastante granulado, da mesma maneira que o WEST e o WUSOR fazem. Em vez de temas, GUIDON usa regras de inferência. As regras concernem diagnósticos médicos e modelam moderadamente grande parte do conhecimento que sumariza uma variedade de operações cognitivas. Uma regra típica é:

Regra 545

Se -1. A infecção foi adquirida enquanto o paciente estava hospitalizado, e

2. a contagem de glóbulos brancos no sangue é menor que 2500 então

a. esta é uma forte evidência que o organismo é E. coli, e

b. esta é uma evidência que sugere que o organismo é uma pneumonia Klebsiella, e

c. esta é uma evidência que sugere que o organismo é o Pseudomonas.

ÁRVORE DE DECISÃO

Todas as técnicas de diagnósticos devem lidar com o fato de que alunos raramente tem somente uma falha em seu conhecimento. Eles geralmente tem várias. Diagnósticos de múltiplos bugs deveriam ser simples se os sistemas pudessem gerar os sintomas da co-ocorrência de bugs tomando a união dos sintomas eles mostrariam os bugs isolamento. Isso não é sempre possível.

A técnica de árvores de decisão é uma abordagem de força bruta para a composição do bug. Elas são empregadas pelo sistema de diagnóstico BUGGY. BUGGY amplia a biblioteca de bugs formando todas os pares possíveis. Antes tinha-se 55 bugs, depois dessa expansão ficaram 3025 pares de bugs. Para que ele diagnostique esses bugs a mais , BUGGY pré-analisa os teste que o aluno realiza e forma uma árvore de decisão que indexa os bugs por suas respostas para os problemas.

A árvore é a parte mais clara da computação. Diagnostica se a resposta do aluno é simples, pelo menos a princípio. Se um aluno não produz nenhum erro por descuido, então sua ou suas respostas são usadas para guiar o BUGGY no caminho do nó root, para o diagnóstico que é mais apropriado. Claro que, os alunos fazem erros não intencionais, como a subtração 9 - 5 e o resto 3.

A vantagem da abordagem de árvores de decisão é que a busca nas árvores é bastante simples para ser implementada em um microcomputador. Um grande computador pode ser usado para a computacionalidade intensiva do processo de construção das árvores de decisão. A desvantagem desta técnica é que ela não efetua realmente a manipulação de múltiplas ocorrências de bugs. Ao invés, ele calcula antecipadamente todas as possíveis combinações e trata as combinações de bugs somente com os bugs primitivos. Para o BUGGY diagnosticar estes alunos iria requerer aproximadamente 9 000 000 de tuplas de bugs, as quais significam uma árvore de diagnóstico com trilhões de nodos.

GERAR E TESTAR

DEBUGGY foi projetado para diagnosticar até quatro ou cinco co-ocorrências de bugs. Ao contrário do BUGGY, ele não efetua cálculo para os bugs co-ocorrentes com antecedência. Ele gera combinações de bugs dinamicamente. Ele inicia encontrando um pequeno conjunto de bugs, mas não necessariamente todos. Eles podem ter 10 bugs neste conjunto. Ele também produz pares utilizando um reservatório de bugs que são conhecidos por ser dificultoso para ver porque eles, geralmente, foram cobertos por outros bugs. O algoritmo DEBUGGY é uma espécie de técnica muito geral para diagnostico, chamada gerar e testar. O algoritmo de diagnóstico gera um conjunto de diagnósticos, encontra as respostas para cada prognóstico, testa essas respostas contra as respostas do aluno, e mantêm as que melhor se eqüivalem. Em geral, gerar e testar é bastante ineficiente. Heurísticas para domínios específicos são, geralmente, utilizadas para que a velocidade seja maior.

DIAGNÓSTICO INTERATIVO

DEBUGGY e BUGGY trabalham com testes de subtrações pré-definidas e as respostas do aluno para elas. Assim, eles podem ser usados para sistemas de diagnóstico off-line. O professor administra o teste, remete as respostas para o DEBUGGY, obtendo o diagnóstico alguns dias depois, administra a introdução do remédio apropriado. IDEBUGGY é como um sistema. Dá um conjunto de diagnósticos consistente com as respostas do aluno, ele tenta construir uma substração do problema que causará cada diagnóstico para gerar diferentes respostas. Não é sempre possível encontrar um problema, assim o IDEBUGGY situa somente uma quantidade fixa para esta estratégia, então apresenta o melhor problema que ele encontrou para o aluno.

TEMAS DE PESQUISA

Diagnóstico cognitivo é um novo campo, existindo um vasto número de questões a serem pesquisadas a serem executadas. "Produzir técnicas X que trabalhem bem com modelos de alunos da forma Y serem submetidos ao domínio Z?" Do ponto de vista da engenharia e da educação esta é a mais importante questão em que devem ser norteadas as pesquisas. Pesquisas orientadas em direção a modelagem do aluno podem ir em diversas direções. Uma é o emprego explicito de modelos de aprendizagem.