Perguntas e Respostas

Visão geral

Resposta a Perguntas (Question Answering, QA) é uma tarefa central em Processamento de Linguagem Natural (Natural Language Processing, NLP) na qual um sistema produz uma resposta para uma pergunta em linguagem natural (natural-language question). O que torna QA distintiva é que a resposta deve ser fundamentada (grounded) em alguma fonte de verdade, como:

• uma passagem de contexto fornecida (compreensão de leitura (reading comprehension)),
• um grande corpus externo como a Wikipédia (QA de domínio aberto (open-domain QA)),
• uma base de conhecimento estruturada (QA sobre base de conhecimento (knowledge-base QA)),
• ou um pipeline aumentado por recuperação (retrieval-augmented pipeline) que combina busca com geração.

QA é central para muitos sistemas do mundo real — mecanismos de busca, bots de suporte ao cliente, assistentes de programação e ferramentas de análise — porque transforma informação não estruturada em respostas diretas e acionáveis.

QA se sobrepõe a outras tarefas de NLP, mas difere no objetivo:

• Em comparação com Classificação de Texto, QA produz conteúdo em vez de selecionar um rótulo.
• Em comparação com Reconhecimento de Entidades Nomeadas ou Rotulagem de Sequências, QA precisa integrar múltiplos indícios (entidades, relações, raciocínio e contexto) para produzir uma resposta.

Formulações do problema e configurações de QA

QA extrativa (compreensão de leitura)

QA extrativa (Extractive QA) pressupõe que uma passagem é fornecida e que a resposta é um trecho de texto (span of text) dentro dessa passagem.

Entrada

• Parágrafo(s) de contexto
• Pergunta

Saída

• Posições inicial e final do trecho de resposta (ou uma decisão de “não respondível”)

Exemplo

Contexto:

Marie Curie discovered polonium and radium. She won the Nobel Prize in Physics in 1903 and the Nobel Prize in Chemistry in 1911.

Pergunta:

What did Marie Curie discover?

Resposta extrativa:

“polonium and radium”

Essa configuração é popular porque é fácil de avaliar (métricas de string/sobreposição), mas pode incentivar correspondência superficial de padrões quando conjuntos de dados contêm artefatos de anotação.

QA abstrativa / generativa

Em QA generativa (generative QA), o sistema pode produzir uma resposta que não é um trecho direto do contexto, como uma paráfrase ou uma resposta sintetizada. Modelos de linguagem grandes (large language models, LLMs) modernos frequentemente fazem isso por padrão.

Usando o mesmo exemplo, uma resposta generativa poderia ser:

“She discovered the elements polonium and radium.”

QA generativa costuma ser mais amigável para o usuário, mas aumenta o risco de alucinação (hallucination) (produzir conteúdo plausível, porém sem suporte), de modo que fundamentação e avaliação se tornam mais desafiadoras.

QA de domínio aberto

QA de domínio aberto (Open-domain QA, ODQA) responde a perguntas sem receber o contexto relevante de antemão. O sistema precisa encontrar evidências em um grande corpus (páginas da web, Wikipédia, documentos internos) e então responder.

Sistemas típicos de ODQA incluem:

1. Recuperador (retriever): encontra documentos/passagens relevantes
2. Leitor / Gerador (reader / generator): extrai ou gera uma resposta usando evidências recuperadas

ODQA está muito mais próxima do comportamento real de busca/assistente e é um grande motor por trás de sistemas aumentados por recuperação.

QA sobre base de conhecimento (KBQA)

QA sobre base de conhecimento (Knowledge-base QA, KBQA) responde a perguntas a partir de bancos de dados estruturados (por exemplo, Wikidata) em vez de texto bruto. Frequentemente envolve:

• Vinculação de entidades (entity linking) (mapeando “Paris” → a entidade correta)
• Mapeamento de relações (relation mapping) (mapeando “capital of” → uma relação da base de conhecimento)
• Construção de consultas (query construction) (por exemplo, SPARQL)

Exemplo:

“What is the capital of Canada?”
pode virar uma consulta estruturada como: capital_of(Canada, ?x) → “Ottawa”.

KBQA pode ser altamente precisa quando a base de conhecimento é completa e bem alinhada à pergunta, mas tem dificuldades com fatos ausentes, menções ambíguas e incompatibilidade de esquema (schema mismatch).

QA conversacional e multi-turno

Em QA conversacional, perguntas dependem do histórico do diálogo:

Usuário:

Who founded SpaceX?

Usuário:

When did he start it?

O sistema precisa resolver referências (“he” → Elon Musk) e manter estado. Essa configuração é comum em assistentes e suporte ao cliente.

QA multi-hop e focada em raciocínio

Algumas perguntas exigem combinar múltiplas evidências (“multi-hop”), aritmética ou raciocínio lógico.

Exemplo (multi-hop):

“What country is the author of The Stranger from?”

Um sistema deve conectar:

• The Stranger → Albert Camus
• Albert Camus → (nationality) French (com ressalvas dependendo de definições e fontes)

QA com forte exigência de raciocínio expõe fragilidades em recuperação, correferência (coreference), entendimento temporal e fidelidade.

Perguntas não respondíveis

Um sistema de QA robusto às vezes precisa dizer “não é possível responder a partir do contexto fornecido” ou abster-se (abstain) quando as evidências são insuficientes.

Isso é crucial em cenários de alto risco (médico, jurídico, conformidade corporativa), nos quais chutar é inaceitável.

Abordagens comuns de modelos e sistemas

RI clássica + resposta baseada em regras

Historicamente, sistemas de QA usavam:

• busca por palavras-chave (TF-IDF, BM25),
• padrões codificados manualmente,
• análise sintática superficial (shallow parsing) e heurísticas (heuristics).

Essas abordagens são rápidas e interpretáveis, mas frágeis para paráfrases e raciocínio complexo. Muitos sistemas modernos ainda usam BM25 como um forte recuperador de linha de base (baseline).

Esse componente está intimamente relacionado a Recuperação de Informação.

Leitores neurais extrativos (predição de trechos)

Uma abordagem neural padrão para QA extrativa faz ajuste fino (fine-tuning) de um codificador pré-treinado (pretrained encoder), como modelos do tipo BERT (veja Arquitetura Transformer).

Como funciona (visão geral):

• Concatenar: [CLS] question [SEP] context [SEP]
• Predizer duas distribuições sobre tokens: posição inicial e posição final
• Treinar com perda de entropia cruzada (cross-entropy loss) contra trechos rotulados

Pontos fortes:

• Forte desempenho em benchmarks de compreensão de leitura
• Respostas são fundamentadas na passagem por construção (o trecho precisa existir)

Pontos fracos:

• Não consegue facilmente produzir respostas que não estejam explicitamente presentes
• Sensível a limites de comprimento do contexto (embora modelos de contexto longo ajudem)
• Ainda pode falhar em contextos ambíguos ou adversariais

QA generativa com LLMs codificador–decodificador ou apenas decodificador

Modelos de QA generativa produzem texto livre:

• Codificador–decodificador (encoder–decoder) (por exemplo, estilo T5) “ler e depois gerar”
• LLMs apenas decodificador (decoder-only) com prompts contendo contexto + pergunta

Esses modelos conseguem:

• parafrasear evidências,
• combinar múltiplas frases,
• produzir explicações.

Mas também podem:

• alucinar detalhes sem suporte,
• responder com confiança mesmo quando incertos,
• ser vulneráveis a injeção de prompt (prompt injection) se o contexto incluir instruções adversariais.

Pipelines de QA de domínio aberto (recuperador + leitor)

Uma arquitetura comum de ODQA é:

1. Recuperar (Retrieve) as top-k passagens (esparsa ou densa)
2. Reordenar (Rerank) candidatos (cross-encoder opcional)
3. Ler (Read) (extrair) ou gerar (generate) a resposta a partir das passagens recuperadas

Métodos de recuperação incluem:

• Recuperação esparsa (sparse retrieval): BM25 / índices invertidos
• Recuperação densa (dense retrieval): incorporações (embeddings) de bi-codificador (veja Incorporações)
• Recuperação híbrida (hybrid retrieval): combinar esparsa + densa para melhor recall

A reordenação frequentemente usa um codificador cruzado (cross-encoder) que codifica conjuntamente (pergunta, passagem) para obter maior acurácia a um custo computacional mais alto.

Geração Aumentada por Recuperação (RAG)

Geração Aumentada por Recuperação (Retrieval-Augmented Generation, RAG) combina recuperação com um LLM que sintetiza a resposta final condicionada às evidências recuperadas.

Um fluxo típico de RAG:

• Dividir documentos em passagens (chunks)
• Construir um índice (frequentemente um índice vetorial (vector index); veja Bancos de Dados Vetoriais)
• Para cada pergunta:
  • recuperar as top-k passagens,
  • fornecer ao LLM um prompt com passagens + pergunta,
  • gerar uma resposta (opcionalmente com citações (citations))

RAG é popular porque:

• melhora a factualidade em comparação com QA de LLM “closed-book”,
• permite uso de dados privados/atualizados,
• oferece um lugar natural para anexar citações e proveniência (provenance).

No entanto, RAG introduz novos modos de falha:

• falhas de recuperação (a resposta existe, mas não foi recuperada),
• enchimento de contexto (context stuffing) (texto irrelevante demais prejudica a geração),
• incompatibilidade de citação (o modelo cita uma passagem que não sustenta a alegação).

Abordagens de KBQA

Estratégias comuns em KBQA:

• Análise semântica (semantic parsing): traduzir pergunta → consulta formal (SPARQL/forma lógica)
• Extração de informação para templates de consulta (information extraction to query templates): identificar entidades/relações e preencher slots
• Métodos neurais em grafos (neural graph methods): aprender a percorrer o grafo da base de conhecimento (às vezes via aprendizado por reforço)

KBQA tipicamente requer forte vinculação de entidades e tratamento de ambiguidade (“Apple” empresa vs fruta).

QA aumentada por ferramentas e pipelines agentivos

Sistemas modernos de QA podem encaminhar uma pergunta para ferramentas:

• uma API de busca,
• um motor de consulta a banco de dados,
• uma calculadora,
• um interpretador de código.

Isso pode reduzir alucinações ao terceirizar operações exatas (por exemplo, aritmética, SQL). Também introduz problemas de orquestração (orchestration): seleção de ferramenta, tratamento de erros e segurança.

Conjuntos de dados e tipos de benchmarks

Benchmarks de QA variam pelo formato de supervisão, domínio e se a recuperação é necessária.

Compreensão de leitura (extrativa)

• SQuAD 1.1: perguntas respondíveis baseadas em trechos a partir de passagens da Wikipédia
• SQuAD 2.0: inclui perguntas não respondíveis (unanswerable) para testar abstenção
• NewsQA: perguntas sobre artigos de notícias

Esses benchmarks são amplamente usados, mas podem superestimar a robustez no mundo real porque o contexto é curado e normalmente contém a resposta.

QA de domínio aberto

• Natural Questions (NQ): consultas reais do Google com evidência da Wikipédia; inclui respostas curtas/longas
• TriviaQA: perguntas de trivia com documentos de evidência; testa robustez a evidências ruidosas
• WebQuestions: perguntas derivadas de fatos no estilo Freebase/Wikidata (faz ponte entre ODQA e KBQA)

Conjuntos de dados focados em recuperação

• MS MARCO: ranqueamento de passagens em larga escala e QA; enfatiza recuperação + geração de resposta
• BEIR (suíte de benchmarks): avalia recuperação em tarefas/domínios heterogêneos

Multi-hop e raciocínio

• HotpotQA: perguntas multi-hop que exigem evidências de múltiplos documentos; inclui fatos de apoio
• DROP: raciocínio discreto (adição, contagem) sobre passagens
• StrategyQA: perguntas que exigem raciocínio implícito e conhecimento factual (frequentemente difíceis de fundamentar)

QA conversacional

• CoQA: perguntas conversacionais com respostas em texto livre
• QuAC: diálogo de busca por informação; inclui perguntas não respondíveis

QA específica de domínio

• BioASQ, PubMedQA: QA sobre literatura biomédica (mudança de domínio (domain shift), terminologia)
• Existem benchmarks de QA jurídica e financeira, mas podem ser proprietários devido a licenciamento.

QA multilíngue

• TyDi QA: multilíngue, línguas tipologicamente diversas, necessidades de informação realistas
  QA multilíngue adiciona desafios em tokenização (tokenization), qualidade de recuperação e fundamentação multilíngue (cross-lingual grounding).

Métricas de avaliação

A avaliação depende de as respostas serem trechos, strings ou gerações em texto livre — e se a recuperação faz parte da tarefa.

Métricas de QA extrativa

• Correspondência Exata (Exact Match, EM): a string de resposta coincide exatamente após normalização (regras de caixa/pontuação)
• F1 em nível de token (token-level F1): sobreposição entre tokens previstos e gold (lida mal com paráfrases, mas permite crédito parcial)

Essas são padrão para conjuntos de dados baseados em trechos como o SQuAD.

Métricas de QA generativa (com ressalvas)

• ROUGE / BLEU: sobreposição de n-gramas; frequentemente proxies fracos de correção em QA
• Similaridade semântica (semantic similarity) (métricas baseadas em incorporação): pode recompensar paráfrases, mas pode não detectar erros factuais
• LLM como juiz (LLM-as-a-judge): cada vez mais usado para QA de final aberto, mas exige prompts cuidadosos, calibração e auditorias

Para QA de alto risco, avaliação humana (human evaluation) ou verificações direcionadas de factualidade frequentemente são necessárias.

Métricas de recuperação e ponta a ponta

Para sistemas com recuperação:

• Recall@k: o recuperador buscou uma passagem que contém a resposta?
• MRR / nDCG: qualidade do ranqueamento (especialmente para tarefas de reordenação)

É comum avaliar ambos:

• qualidade de recuperação (você consegue encontrar evidência?)
• qualidade da resposta (você consegue usar a evidência corretamente?)

Avaliação de fundamentação e fidelidade

Sistemas de RAG frequentemente exigem métricas além de “resposta correta”:

• Acurácia de atribuição (attribution accuracy): a passagem citada realmente sustenta a alegação?
• Precisão/recall de citação (citation precision/recall): as citações são relevantes e suficientes?
• Fidelidade (faithfulness): toda alegação-chave é sustentada pelo contexto fornecido?

Essas métricas são mais difíceis de automatizar de forma confiável e frequentemente exigem anotação humana ou protocolos de avaliação cuidadosos.

Abstenção e calibração

Para perguntas não respondíveis ou implantações críticas para segurança:

• medir acurácia de abstenção (abstention accuracy),
• avaliar risco seletivo (selective risk) (taxa de erro a uma dada cobertura),
• aferir calibração de confiança (confidence calibration) (a confiança reflete a correção?).

Exemplos práticos

Exemplo 1: QA extrativa na prática (Hugging Face Transformers)

from transformers import pipeline

qa = pipeline("question-answering", model="distilbert-base-cased-distilled-squad")

context = """Marie Curie discovered polonium and radium.
She won the Nobel Prize in Physics in 1903 and the Nobel Prize in Chemistry in 1911."""

question = "What did Marie Curie discover?"

print(qa(question=question, context=context))

A saída típica inclui:

• answer: trecho extraído
• score: confiança do modelo
• start, end: offsets de caracteres

Este é um arranjo clássico de somente leitor (reader-only): ele assume que o contexto relevante já é conhecido.

Exemplo 2: Pseudocódigo mínimo de RAG

def answer_question(question):
    passages = retrieve_top_k(question, k=5)   # BM25/dense/hybrid
    prompt = format_prompt(question, passages) # include instructions + delimiters
    draft = llm_generate(prompt)
    return draft

Em produção, normalmente você adiciona:

• reordenação,
• deduplicação,
• formatação de citações,
• regras de recusa (“If not in context, say you don’t know”),
• registro (logging) e feedback.

Considerações de projeto de sistema (o que importa em implantações reais)

A qualidade da recuperação frequentemente domina

Em QA de domínio aberto e corporativo, muitas falhas são falhas de recuperação:

• documento errado recuperado,
• documento certo não recuperado,
• informação relevante dividida entre segmentos.

Melhorar a recuperação (melhor segmentação, busca híbrida, filtros por metadados, reordenação) frequentemente traz ganhos maiores do que trocar LLMs.

Segmentação e construção de contexto

Principais escolhas de projeto:

• tamanho do segmento e sobreposição,
• se indexar por parágrafo, seção ou página,
• adicionar títulos/cabeçalhos como metadados,
• incluir timestamps de documentos (ajuda com perguntas temporais).

Uma segmentação ruim pode tornar respostas impossíveis de encontrar mesmo se o corpus as contiver.

Elaboração de prompts para respostas fundamentadas

Práticas comuns de prompts para RAG:

• delimitar claramente as fontes (por exemplo, SOURCE 1: ...),
• instruir o modelo a usar apenas as fontes fornecidas,
• exigir citações por frase ou alegação,
• instruir abstenção quando faltarem evidências.

Mesmo com prompts fortes, modelos ainda podem alucinar — portanto, barreiras de proteção e avaliação são importantes.

Pós-processamento e normalização de respostas

Saídas de QA frequentemente se beneficiam de:

• normalização (datas, unidades),
• extração de respostas curtas a partir de gerações longas,
• validação de entidades contra um esquema (quando apropriado),
• retornar resposta + evidência.

Considerações de segurança: injeção de prompt

Quando QA usa texto recuperado, conteúdo adversarial pode tentar sobrescrever instruções (por exemplo, “Ignore previous directions…”). Mitigações incluem:

• tratar texto recuperado como dados não confiáveis,
• prompts de sistema estritos,
• filtragem de conteúdo,
• isolar instruções de ferramentas do texto dos documentos.

Modos de falha comuns e armadilhas

Ambiguidade e subespecificação

Perguntas como “What is the largest bank?” dependem de região e métrica (ativos, valor de mercado). Sistemas de QA podem responder incorretamente se assumirem uma interpretação padrão sem esclarecer.

Mitigação: fazer uma pergunta de esclarecimento ou fornecer múltiplas respostas plausíveis com condições.

Perguntas não respondíveis

Se a resposta não estiver presente no contexto fornecido, sistemas extrativos ainda podem selecionar um trecho; sistemas generativos podem inventar.

Mitigação: treinar/avaliar com dados não respondíveis, adicionar limiares de abstenção, exigir evidências.

Alucinação (especialmente em QA generativa)

LLMs podem produzir detalhes plausíveis sem suporte das fontes, particularmente quando:

• a recuperação fornece evidência parcial,
• o modelo é pressionado a responder,
• os prompts são longos e ruidosos.

Mitigação: citar evidências, reforçar “responda apenas a partir do contexto”, usar passagens de verificação, ou decodificação estruturada (structured decoding).

Falha de recuperação e “certo pelo motivo errado”

Um sistema pode responder corretamente usando conhecimento memorizado mesmo quando a recuperação está errada — mascarando fragilidades. Por outro lado, pode recuperar evidência correta e ainda assim falhar em usá-la.

Mitigação: avaliar recuperação e geração separadamente; usar testes de atribuição.

Artefatos de conjunto de dados e aprendizado por atalhos

Alguns benchmarks contêm padrões que permitem aos modelos “adivinhar” sem entendimento real (por exemplo, indícios lexicais). Pontuações altas em benchmark podem não se traduzir em cenários reais.

Mitigação: avaliação adversarial, testes fora do domínio e consultas de usuários reais.

Deriva temporal e conhecimento desatualizado

Para fatos de domínio aberto (“current CEO”), os pesos do modelo podem estar desatualizados. A recuperação ajuda, mas apenas se os documentos estiverem atuais e o sistema os respeitar.

Mitigação: indexação sensível ao tempo, preferir fontes autoritativas, exibir timestamps.

Viés e saídas prejudiciais

QA pode amplificar vieses presentes nos dados ou nas fontes recuperadas e pode produzir orientação médica/jurídica insegura.

Mitigação: políticas de segurança, comportamentos de recusa, restrições de domínio e supervisão humana.

Aplicações

Aplicações comuns de QA incluem:

• Aumento de busca: respostas diretas com trechos de apoio
• Suporte ao cliente: responder a partir de documentação de produto e tickets
• Assistentes de conhecimento corporativo: QA sobre wikis internas, PDFs e políticas
• Educação: sistemas tutores que respondem a partir de livros didáticos exibindo citações
• Revisão de literatura científica e médica: sumarizar evidências para perguntas específicas (com forte supervisão)
• Ferramentas para desenvolvedores: QA sobre bases de código e documentação de APIs (frequentemente com uso de ferramentas e recuperação)

Relação com tarefas próximas de NLP

QA interage com muitos outros componentes:

• Reconhecimento de Entidades Nomeadas e vinculação de entidades ajudam a identificar sobre “quem/o quê” a pergunta é feita.
• Recuperação de Informação é fundamental para QA de domínio aberto e RAG.
• Incorporações permitem recuperação densa e busca semântica.
• Arquitetura Transformer sustenta a maioria dos modelos modernos de QA.

Na prática, QA costuma ser menos um único modelo e mais um sistema: recuperação + raciocínio + geração + verificação, ajustado para minimizar alucinações e lidar com incerteza.

Resumo

Resposta a Perguntas abrange um espectro que vai de compreensão de leitura extrativa a recuperação de domínio aberto e geração aumentada por recuperação. Sistemas modernos de QA são julgados não apenas pela correção da resposta, mas também por fundamentação, robustez e tratamento seguro de perguntas não respondíveis ou ambíguas. À medida que QA baseada em LLM se torna onipresente, recuperação forte, elaboração cuidadosa de prompts, atribuição e avaliação rigorosa tornam-se cada vez mais centrais para construir aplicações de QA confiáveis.

---