Podemos escrever um procedimento explicitamente ou ajustar um modelo a partir de casos. A diferença não é entre sistemas que têm programação e sistemas que não têm: ela está em como parte do comportamento é definida.
Uma equipe precisa separar mensagens sobre pagamento, entrega e cadastro. Uma possibilidade é escrever regras com palavras e condições. Outra é reunir mensagens já classificadas e treinar um modelo. As duas estratégias procuram apoiar a mesma tarefa, mas organizam o conhecimento de modos diferentes.
Essa comparação nos ajuda a compreender uma tensão histórica da IA sem transformar o campo em dois times que nunca conversam. Sistemas reais podem combinar regras, modelos aprendidos e revisão humana. Para escolher, precisamos observar a estrutura do problema e os erros que cada abordagem produz.
Quando o conhecimento vira uma regra explícita
Uma regra pode ter a forma “se determinada condição ocorrer, faça determinada ação”. Em um exemplo didático de cadastro, se um campo obrigatório estiver vazio, o sistema solicita seu preenchimento. A condição é diretamente verificável e a ação é conhecida.
Na tradição simbólica da IA, símbolos e relações podem representar situações, objetivos e operações. Allen Newell e Herbert Simon discutiram em 1976 a manipulação de símbolos e a busca como elementos de sua abordagem à resolução de problemas. A formulação é uma hipótese sobre sistemas inteligentes e uma agenda de investigação, não uma prova de que toda inteligência se reduz a uma lista de regras simples. [1]
Busca, aqui, significa explorar alternativas. Em um quebra-cabeça, um estado descreve a situação atual, e uma ação leva a outro estado. O programa procura uma sequência que alcance a meta. Uma heurística pode orientar a escolha de alternativas promissoras sem garantir, em qualquer contexto, a melhor solução.
Escrever todas as exceções pode ficar difícil
Retome as mensagens de atendimento. Uma regra que procura “entrega” encontrará “minha entrega atrasou”. Mas o usuário pode escrever “a encomenda não chegou”. Também pode dizer “não tenho problema com a entrega; preciso alterar o cadastro”. A presença de uma palavra não determina sozinha o sentido da solicitação.
É possível acrescentar regras, sinônimos e condições. Em alguns domínios, essa estratégia é adequada e transparente. Em outros, a variedade cresce a ponto de tornar a manutenção trabalhosa. Uma mudança pode resolver um caso e produzir um conflito com outra regra.
O limite não é simplesmente “regras são ruins”. Muitas restrições de negócio precisam ser explícitas e estáveis. A pergunta é quais aspectos da tarefa podem ser descritos desse modo com custo e confiabilidade aceitáveis.
Aprender com exemplos muda a construção da regra
Em aprendizado supervisionado, fornecemos exemplos associados a respostas esperadas, frequentemente chamadas rótulos. Um procedimento de treinamento ajusta um modelo para relacionar entradas e saídas. Depois, avaliamos seu comportamento em exemplos que não foram usados da mesma maneira no ajuste.
No artigo de 1958 sobre o perceptron, Frank Rosenblatt investigou uma forma de sistema capaz de ajustar relações entre entradas e resposta. O trabalho tornou-se um marco na história das redes artificiais. É importante preservar sua especificidade: o perceptron não era um modelo de linguagem moderno nem uma descrição de toda aprendizagem possível. [2]
O aprendizado não elimina a programação. Pessoas definem representações, arquitetura, objetivo de treinamento e procedimentos de avaliação. Parte da regra de decisão deixa de ser escrita caso a caso e passa a resultar do ajuste realizado sobre os exemplos.
Um modelo pequeno para enxergar o princípio
Considere uma decisão fictícia baseada em duas características numéricas. A primeira vale 0 ou 1; a segunda também. Multiplicamos cada valor por um peso, somamos e comparamos o resultado com um limiar. Conforme a comparação, a saída recebe uma de duas classes.
Os pesos determinam quanto cada entrada contribui. Durante um treinamento, esses valores podem ser modificados para reduzir erros sobre exemplos. O desenho exato do ajuste depende do algoritmo. Não basta dizer que o sistema “viu dados”; precisamos saber o que foi alterado e segundo qual objetivo.
Uma unidade linear com limiar consegue separar certos conjuntos de pontos por uma fronteira reta. Há configurações, como o padrão conhecido como “ou exclusivo”, que uma única fronteira desse tipo não separa. Combinar unidades ou modificar representações amplia possibilidades, mas também altera a construção do sistema. [3]
Aprender um padrão não é descobrir automaticamente a causa
Imagine que todas as mensagens de uma categoria no conjunto de treinamento vieram de um mesmo formulário. O modelo pode usar marcas desse formulário como atalho. Quando a organização muda o canal de entrada, o desempenho cai, embora o significado das solicitações continue parecido.
O exemplo é hipotético e mostra uma questão geral: a regularidade observada pode depender de circunstâncias do conjunto de dados. Acertar uma classificação não significa ter identificado a causa do fenômeno ou aprendido a relação que o projetista desejava.
Por isso, precisamos examinar exemplos novos, condições diferentes e tipos de erro. O treinamento informa como o modelo foi ajustado. A avaliação procura evidência de que esse ajuste serve ao uso pretendido.
Transparência tem mais de uma dimensão
Uma regra escrita pode ser fácil de ler: “se falta o documento, peça o documento”. Isso não garante que a política seja justa, completa ou apropriada. A transparência do procedimento não substitui o exame do critério.
Um modelo aprendido pode ter uma estrutura mais difícil de explicar caso a caso. Ainda assim, podemos avaliar desempenho, investigar erros e limitar sua função no processo. Explicabilidade, previsibilidade e qualidade são dimensões relacionadas que não devem ser tratadas como sinônimos.
Na prática, uma combinação pode ser útil. Um modelo sugere a categoria de uma mensagem; regras verificam campos obrigatórios; casos ambíguos seguem para uma pessoa. Essa é uma proposta de arquitetura, não uma garantia de desempenho. Cada componente precisa ser testado dentro do conjunto.
Qual abordagem combina com o problema?
Se a condição é definida e pode ser verificada diretamente, uma regra pode ser suficiente. Não há obrigação de treinar um modelo para descobrir que um campo está vazio. Se a tarefa envolve variações difíceis de enumerar, exemplos podem oferecer uma maneira mais produtiva de representar o comportamento desejado.
Mas exemplos precisam existir em quantidade e qualidade adequadas. Se os próprios avaliadores discordam sobre o rótulo, o projeto deve examinar essa divergência antes de tratá-la como verdade única. Talvez falte uma definição; talvez a tarefa admita múltiplas respostas legítimas.
Uma boa escolha começa pelo problema e por uma referência simples de comparação. O método mais sofisticado não é automaticamente o mais útil. O ganho precisa aparecer em resultados relevantes, incluindo o esforço de manter e conferir o sistema.
A história continua na interface
Regras e aprendizagem ajudam a explicar como um sistema produz respostas. O próximo capítulo acrescenta outra dimensão: como as pessoas interpretam essas respostas. Com ELIZA, veremos que uma conversa aparentemente compreensiva pode surgir de mecanismos bastante delimitados. O comportamento do programa e a leitura humana desse comportamento fazem parte da mesma história de uso.
