
Definição numa frase
Adaptación temporal del comportamiento a instrucciones y ejemplos presentes en el contexto sin actualizar los pesos del modelo.
Definição: adaptação dentro do contexto
A aprendizagem em contexto — in-context learning ou ICL — é a capacidade observável de um modelo produzir uma resposta condicionada pelas informações que recebe em uma solicitação: instruções, exemplos e a nova tarefa. Em vez de modificar o modelo por meio de um processo de treinamento, essas informações são incluídas na entrada para orientar a resposta durante aquela interação.
Em uma solicitação, o contexto pode indicar o que fazer, qual formato usar e quais exemplos mostram a relação entre uma entrada e a saída esperada. Em seguida, o modelo gera uma resposta com base na entrada completa. No uso habitual do termo, «aprendizagem» descreve a aparente mudança de comportamento diante do contexto; isso não significa necessariamente que o modelo tenha atualizado seus parâmetros ou adquirido uma habilidade permanente.
Esta definição se refere à interação comum com um modelo já disponível. Por si só, ela não abrange processos externos que uma aplicação possa executar, como salvar dados, atualizar uma base de conhecimento ou iniciar um treinamento. Por isso, é mais preciso dizer que o modelo se adapta temporariamente às informações da solicitação do que afirmar que aprende de forma permanente.
Como a ICL aparece em uma solicitação
Uma solicitação com ICL costuma combinar três componentes: uma instrução que delimita a tarefa, uma ou mais demonstrações que relacionam entradas a saídas e um novo item que o modelo deve processar. As demonstrações não são obrigatórias em todas as formas de ICL: uma instrução, por si só, também pode orientar a resposta. Ainda assim, exemplos explícitos são uma maneira comum de mostrar ao modelo qual transformação se espera.
A estrutura pode ser escrita em linguagem natural ou em um formato regular. Se forem solicitados rótulos, é conveniente defini-los e mantê-los consistentes; se houver extração de campos, é útil especificar o que fazer quando uma informação não estiver presente. Essas decisões fazem parte do desenho da solicitação. Elas não tornam automaticamente a resposta correta: apenas deixam a tarefa explícita e facilitam a avaliação do resultado.
O modelo processa o contexto disponível ao gerar a resposta. Em uma interação normal, isso não equivale a incorporar permanentemente a demonstração aos parâmetros do modelo. A informação pode deixar de influenciar o resultado quando outra solicitação é enviada sem incluí-la, a menos que o sistema ao redor a mantenha ou volte a inseri-la.
Esquema mínimo de uso
O procedimento separa as instruções, as demonstrações e o caso que se quer resolver. Ele não garante o resultado; permite construir uma solicitação que possa ser testada.
- 01Defina a tarefa e as saídas permitidas.
- 02Acrescente exemplos representativos de entrada e saída, se forem necessários.
- 03Apresente o novo caso no mesmo formato.
- 04Revise a resposta e compare-a com o resultado esperado.
Três exemplos práticos
Os casos a seguir mostram como estruturar uma solicitação. São exemplos de desenho, não resultados de testes com um modelo específico nem garantias de que um sistema classificará ou extrairá informações corretamente. Em cada área, é preciso definir previamente as categorias, os campos e como lidar com ambiguidades.
O que significa «aprender» — e o que não podemos concluir
Neste termo, «aprendizagem» se refere ao fato de o modelo parecer inferir um padrão a partir do contexto e responder de acordo com ele. A resposta, por si só, não revela como esse padrão foi produzido internamente. Um modelo pode acertar uma classificação depois de ver exemplos, mas esse acerto não demonstra que tenha realizado uma atualização de parâmetros, que represente a tarefa de uma forma específica ou que transfira essa capacidade para qualquer caso novo.
Uma formulação de pesquisa mencionada entre as fontes descreve a ICL, em modelos autorregressivos, como a possibilidade de resolver tarefas por meio da previsão do próximo token e sem treinamento adicional. Essa descrição ajuda a distinguir o uso do contexto do treinamento, mas não deve ser transformada em uma explicação universal para todos os sistemas ou mecanismos internos. As fontes disponíveis não permitem afirmar que exista uma explicação mecanística única e aceita para o fenômeno.
Também é importante separar o resultado observável da explicação causal. O fato de uma instrução ou um exemplo influenciar a saída permite dizer que o comportamento está condicionado pelo contexto. Isso não basta para identificar qual representação interna o modelo usa, por que uma demonstração específica é útil nem se o modelo está aplicando uma regra, reconhecendo uma estrutura familiar ou combinando diferentes sinais.
ICL, poucos exemplos e métodos relacionados
«Aprendizagem em contexto» e «aprendizagem com poucos exemplos» se sobrepõem no uso cotidiano, mas não são termos intercambiáveis em todos os textos técnicos. Quando exemplos são incluídos na solicitação para orientar a resposta, costuma-se falar em aprendizagem em contexto ou em prompting com poucos exemplos. Por outro lado, «few-shot learning» também pode designar abordagens nas quais o modelo se adapta por meio de treinamento com poucos exemplos. Por isso, é importante verificar se uma fonte se refere a exemplos incluídos na entrada ou a um procedimento de treinamento.
O ajuste fino é diferente do uso comum de ICL: ele envolve treinar ou ajustar o modelo com dados para modificar seu comportamento, enquanto a ICL fornece informações no contexto da solicitação. A recuperação de documentos também é uma operação distinta: ela seleciona informações externas que uma aplicação pode acrescentar ao contexto. Se, depois disso, o modelo gerar uma resposta condicionada por essas informações, a geração poderá usar ICL, mas a busca e a aprendizagem em contexto não são a mesma etapa.
A ICL também não deve ser confundida com aprendizagem contínua. Incluir um exemplo em uma solicitação não significa que o modelo vá lembrá-lo em interações futuras. A persistência depende de como o sistema ao redor foi construído e de ele voltar ou não a fornecer essa informação.
Como distinguir os conceitos
A terminologia varia conforme o contexto. Esta tabela diferencia os métodos pelo local em que as informações são incorporadas, não pelo resultado esperado.
| Conceito | Onde as informações são incorporadas | O que isso não implica, por si só |
|---|---|---|
| Aprendizagem em contexto (ICL) | Na entrada ou no contexto da solicitação, por meio de instruções, exemplos ou outros sinais | Uma atualização permanente dos pesos |
| Prompting com poucos exemplos | Na solicitação, por meio de demonstrações de entrada e saída | Que «few-shot learning» sempre se refira a essa técnica |
| Ajuste fino | Em um processo de treinamento ou ajuste do modelo | Que o modelo responderá bem a toda tarefa nova |
| Recuperação de documentos | Em informações externas que um sistema busca e pode acrescentar ao contexto | Que a recuperação e a ICL sejam o mesmo processo |
| Aprendizagem contínua | Em mecanismos que retêm ou incorporam informações para além de uma solicitação | Que um exemplo de uma interação seja lembrado automaticamente |
Limites e erros frequentes de desenho
Os exemplos podem não representar a variedade de entradas reais. Se todos forem claros e curtos, uma solicitação pode parecer eficaz e ainda assim falhar diante de mensagens ambíguas, campos ausentes ou expressões pouco comuns. Aumentar o número de demonstrações não resolve automaticamente esse problema: o que importa é que sejam pertinentes, corretas e suficientemente diversas para a tarefa.
A seleção e a ordem dos exemplos também podem afetar a resposta. Não se deve interpretar um acerto isolado como prova de robustez nem atribuir uma falha exclusivamente ao modelo sem revisar a instrução, o formato e os dados de demonstração. Uma categoria mal definida pode gerar divergências até entre pessoas; um formato de saída ambíguo pode dificultar a avaliação mesmo quando a interpretação geral é razoável.
Entre os erros frequentes estão misturar categorias incompatíveis, fornecer exemplos que contradizem a instrução, não especificar como responder quando faltam informações e avaliar apenas casos semelhantes aos já incluídos na solicitação. Outro erro é confundir uma saída convincente com uma extração verificada: em usos operacionais, os campos e as classificações relevantes precisam de controles adequados ao risco.
Como verificar se os exemplos ajudam
A maneira prática de avaliar a ICL é comparar a mesma tarefa com e sem exemplos, mantendo constantes, tanto quanto possível, o modelo, a instrução, os casos de teste e as demais condições. O conjunto de avaliação deve incluir entradas representativas e casos difíceis que não sejam simples cópias das demonstrações. É preciso guardar as respostas e registrar os erros, em vez de selecionar apenas os acertos que confirmem uma impressão inicial.
A comparação pode medir a exatidão dos rótulos, a proporção de campos omitidos ou incorretos, a conformidade com o formato e a quantidade de casos que precisam de revisão. A métrica específica depende do objetivo: uma classificação de solicitações de suporte não é avaliada da mesma forma que a extração de valores. Se erros em determinadas categorias tiverem consequências diferentes, eles devem ser analisados separadamente.
Um teste pequeno pode ajudar a identificar problemas de desenho, mas não garante que o comportamento se mantenha em produção. Se a distribuição das solicitações, dos documentos ou da linguagem dos clientes mudar, os resultados também podem mudar. Por isso, os exemplos devem ser revisados com dados pertinentes e a avaliação deve ser repetida quando a tarefa ou as condições de uso mudarem.
Teste comparativo simples
O objetivo é estimar se as demonstrações melhoram o desempenho em casos que não foram usados para elaborá-las. A comparação não comprova, por si só, um mecanismo interno.
- 01Defina uma tarefa, uma saída esperada e critérios de erro antes de testar.
- 02Separe os exemplos usados no desenho dos casos de avaliação; não avalie apenas as próprias demonstrações.
- 03Execute a mesma instrução sem demonstrações e com demonstrações, em condições comparáveis.
- 04Compare acertos, erros, omissões, formato e casos que exigem revisão.
- 05Revise os exemplos e os resultados se a melhoria for irregular ou estiver concentrada nos casos mais simples.
Critérios práticos e conceitos relacionados
A ICL é uma opção razoável quando a tarefa pode ser descrita com clareza, os exemplos cabem no contexto disponível e é possível revisar a saída. Antes de adotá-la, verifique se cada demonstração está correta, se os novos casos se parecem o suficiente com a tarefa prevista e se há uma resposta aceitável para situações ambíguas ou fora do escopo.
Se os exemplos não melhorarem os resultados em casos representativos, comece revisando a definição da tarefa, os rótulos, o formato e a seleção dos casos. Se houver necessidade de persistência entre interações ou de uma mudança duradoura de comportamento, acrescentar exemplos a cada solicitação não resolve essa necessidade por si só. A comparação entre ICL e ajuste por instruções também aparece em pesquisas sobre modelos pequenos e multilíngues, mas uma observação sobre essa comparação não permite determinar qual método é adequado para qualquer modelo ou tarefa.
Para continuar, consulte a seção do glossário, a ficha relacionada sobre aprendizagem em contexto e a seção de comparações. Os nomes internos correspondem a «glossary.index», «glossary:in-context-learning» e «compare.index»; a disponibilidade e o conteúdo dessas rotas dependem do site.