PLN (NLP)

O que é PLN?

Processamento de Linguagem Natural (Natural Language Processing, NLP) é a área da IA (artificial intelligence, AI) voltada a permitir que computadores entendam, gerem e interajam usando linguagem humana. Ela abrange:

Tarefas de processamento de linguagem (por exemplo, classificação, extração, tradução, sumarização, resposta a perguntas (question answering))
Representações (como o texto é codificado como números para que modelos possam aprender a partir dele)
Recuperação (retrieval) (encontrar informações relevantes em grandes coleções de texto, muitas vezes para apoiar a geração a jusante)
Avaliação (evaluation) (medir qualidade, utilidade e segurança de sistemas de PLN)

O PLN moderno é dominado por aprendizado profundo (deep learning) — especialmente pela Arquitetura Transformer (Transformer Architecture) — e por grandes modelos de linguagem pré-treinados (large pretrained language models). Ao mesmo tempo, ideias clássicas (tokenização (tokenization), n-gramas (n-grams), frequência de termo–frequência inversa de documento (term frequency–inverse document frequency, TF‑IDF), BM25) continuam importantes em sistemas práticos, particularmente para recuperação e eficiência.

O PLN também desempenha um papel central em sistemas agentivos (agentic systems) (veja Agentes e Planejamento): a linguagem costuma ser a interface para especificar objetivos, chamar ferramentas, raciocinar sobre documentos recuperados e produzir planos e ações.

Tarefas centrais de processamento de linguagem

As tarefas de PLN são frequentemente agrupadas pelo que produzem: rótulos, dados estruturados, trechos ou texto novo.

Classificação e regressão de texto

Objetivo: Prever um rótulo ou pontuação para um trecho de texto.

Exemplos comuns:

Análise de sentimento (positivo/neutro/negativo)
Classificação de tópico (esportes, política, tecnologia)
Detecção de toxicidade / filtragem de conformidade com políticas
Detecção de intenção para chatbots

Notas práticas:

Frequentemente resolvida com Transformers com ajuste fino (fine-tuning) ou modelos lineares leves sobre incorporações (embeddings).
Linhas de base fortes: TF‑IDF + regressão logística (logistic regression) podem ser surpreendentemente competitivos em conjuntos de dados pequenos.

Rotulagem de sequência (sequence labeling) (tarefas em nível de token)

Objetivo: Atribuir um rótulo a cada token.

Exemplos:

Etiquetagem de classe gramatical (part-of-speech tagging)
Reconhecimento de entidades nomeadas (named entity recognition, NER)
Segmentação em constituintes (chunking)

Essas tarefas são fundamentais para pipelines (pipelines) de extração de informação (information extraction) e ainda são amplamente usadas em PLN corporativo (por exemplo, extraindo organizações e datas de contratos).

Extração de trechos (span extraction) e predição estruturada (structured prediction)

Objetivo: Extrair campos estruturados a partir de texto.

Exemplos:

Extrair totais de fatura e datas de vencimento
Encontrar trechos de resposta em uma passagem (perguntas e respostas extrativas (extractive QA))
Extrair relações (por exemplo, pessoa trabalha_para empresa)

Sistemas modernos frequentemente usam:

Codificadores Transformer com cabeças de span
Extração com modelos de linguagem de grande porte guiada por instrução (prompt) e saída restrita (por exemplo, esquema JSON (JSON schema))

Geração de texto

Objetivo: Produzir texto condicionado a uma entrada.

Exemplos:

Tradução automática (machine translation)
Sumarização
Diálogo e chat
Geração de código
Dados-para-texto e geração de relatórios

A qualidade da geração depende fortemente da estratégia de decodificação (decoding strategy) (gulosa (greedy) vs busca em feixe (beam search) vs amostragem (sampling)), do objetivo de treinamento (training objective) (modelo de linguagem causal (causal LM) vs modelo sequência-a-sequência (sequence-to-sequence, seq2seq)) e de técnicas de alinhamento (alignment techniques) (veja Aprendizado por Reforço com Feedback Humano (Reinforcement Learning from Human Feedback, RLHF)).

Busca semântica (semantic search) e resposta a perguntas

Objetivo: Recuperar documentos/passagens relevantes e, opcionalmente, produzir uma resposta.

Dois padrões amplos:

Apenas recuperação: retornar os principais documentos
Recuperação + geração: recuperar evidências e então gerar uma resposta (frequentemente chamada de Geração Aumentada por Recuperação (Retrieval-Augmented Generation, RAG))

Essa categoria é central para PLN em produção porque ajuda a ancorar (grounding) respostas em documentos reais, melhora a factualidade e fornece citações.

Representações de texto: de tokens a significado

Modelos de PLN não conseguem operar diretamente sobre strings; eles exigem representações numéricas.

Tokenização

A tokenização define as unidades atômicas que um modelo enxerga.

Tokenização por palavras: separa por espaços em branco/pontuação; simples, mas tem dificuldades com palavras raras e morfologia.
Tokenização por caracteres: robusta a erros de digitação; as sequências ficam longas.
Tokenização por subpalavras (dominante hoje): equilibra tamanho do vocabulário e cobertura.

Abordagens populares de subpalavras:

BPE (codificação por par de bytes, Byte Pair Encoding)
WordPiece
Tokenização por modelo de linguagem unigram (Unigram language model tokenization)
BPE em nível de byte (Byte-level BPE) (robusta a texto arbitrário e entrada multilíngue)

Por que isso importa:

A tokenização afeta o comprimento do contexto, a latência, o desempenho multilíngue e até vieses a jusante (por exemplo, como nomes ou dialetos são segmentados).

Representações esparsas: saco de palavras (bag-of-words), n-gramas, TF‑IDF

O PLN clássico representa um documento como um vetor esparso de alta dimensionalidade.

Saco de palavras: conta ocorrências de tokens, ignora a ordem
n-gramas: inclui sequências curtas (por exemplo, bigramas) para capturar uma ordem de palavras limitada
TF‑IDF: repondera contagens para que palavras comuns importem menos

Essas representações continuam valiosas:

Linhas de base rápidas e interpretáveis
Fortes para busca por palavra-chave e classificação com poucos dados
Úteis em sistemas híbridos de recuperação

Exemplo: busca por similaridade com TF‑IDF (simplificado)

from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity

docs = [
    "Transformers use attention to model long-range dependencies.",
    "TF-IDF is a classic sparse representation for text.",
    "Retrieval-augmented generation combines search with generation."
]
query = "How does retrieval help generation?"

vec = TfidfVectorizer()
X = vec.fit_transform(docs + [query])
doc_vecs, q_vec = X[:-1], X[-1]

scores = cosine_similarity(doc_vecs, q_vec)
best = scores.argmax()
print("Best doc:", docs[best], "score:", float(scores[best]))

Representações densas: vetores de incorporação

Vetores de incorporação mapeiam texto para vetores densos em que similaridade semântica corresponde a proximidade geométrica (por exemplo, similaridade do cosseno (cosine similarity)). Isso habilita busca semântica e agrupamento (clustering).

Tipos:

Vetores de incorporação estáticos de palavras: um vetor por palavra (por exemplo, word2vec, GloVe). Bons para capturar similaridade geral, mas não conseguem representar sentidos diferentes (“banco”).
Vetores de incorporação contextuais: vetores de token dependem do contexto ao redor (codificadores Transformer como modelos no estilo BERT (BERT-style models)).
Vetores de incorporação de sentença/documento: um único vetor para um trecho de texto, otimizado para tarefas de similaridade.

Vetores de incorporação densos são fundamentais para:

Busca vetorial (vector search) sobre milhões de passagens
Detecção de duplicatas e agrupamento
Recuperação baseada em similaridade para pipelines de geração aumentada por recuperação

Conceito relacionado: Vetores de Incorporação de Palavras

Modelagem contextual e composicionalidade

O significado da linguagem humana depende de:

Ordem das palavras e sintaxe
Correferência (“ela”, “isso”)
Pragmática (implicatura, intenção)
Conhecimento de mundo

Arquiteturas neurais modernas aproximam esses aspectos via representações aprendidas, padrões de atenção (attention) e pré-treinamento (pretraining) em grandes corpora. Ainda assim, elas continuam tendo dificuldades com generalização composicional (compositional generalization) robusta e consistência de longo horizonte (long-horizon consistency).

Abordagens de modelagem: do aprendizado de máquina clássico (classical ML) aos Transformers

Pipelines clássicos de PLN

Sistemas anteriores eram tipicamente modulares:

Tokenizar → normalizar
Extração de atributos (n-gramas, TF‑IDF, léxicos)
Classificador linear / CRF / HMM
Regras de pós-processamento

Eles ainda podem ser a melhor opção quando:

Você precisa de interpretabilidade
Os dados são escassos
As restrições de latência são rígidas
A tarefa é bem definida e estreita

Modelos neurais de sequência (pré-Transformer)

RNNs/LSTMs/GRUs: processam tokens sequencialmente; têm dificuldades com contextos muito longos e com paralelismo.
CNNs para texto: capturam padrões locais; eficientes, mas com contexto global limitado.

Eles são menos comuns no estado da arte do PLN geral, mas continuam relevantes em ambientes com recursos limitados.

Transformers e grandes modelos de linguagem

Transformers substituíram recorrência por atenção, permitindo:

Treinamento paralelo
Modelagem forte de dependências de longo alcance
Pré-treinamento escalável

Veja: Arquitetura Transformer

Dois paradigmas comuns de pré-treinamento:

Modelagem de linguagem causal (causal language modeling) (prever o próximo token): usada em muitos grandes modelos de linguagem.
Modelagem de linguagem mascarada (masked language modeling) (prever tokens mascarados): usada em modelos codificadores (do tipo BERT), forte para tarefas de compreensão.

O objetivo de modelagem de linguagem normalmente maximiza a log-verossimilhança (log-likelihood):

[ \max_\theta \sum_{t=1}^{T} \log p_\theta(x_t \mid x_{<t}) ]

Implicações práticas:

O pré-treinamento constrói ampla competência linguística e conhecimento.
Ajuste fino ou ajuste por instruções (instruction tuning) adapta o comportamento às tarefas.
Uso de ferramentas (tool use) e integração com recuperação tornam os sistemas mais confiáveis em cenários do mundo real.

Relacionado: Modelos de Linguagem

Recuperação no PLN: por palavra-chave, semântica e híbrida

A recuperação é a espinha dorsal de muitas aplicações modernas de PLN: busca, perguntas e respostas, geração aumentada por recuperação, suporte ao cliente, recomendações e analytics.

Recuperação por palavras-chave (índice invertido (inverted index), BM25)

BM25 é um método tradicional forte de ranqueamento (ranking) baseado em frequência de termos e normalização pelo comprimento do documento. Ele se destaca quando:

Consultas contêm termos exatos encontrados em documentos relevantes
Precisão em palavras-chave específicas importa (jurídico, códigos médicos)
Você precisa de um comportamento de correspondência transparente

Recuperação densa (dense retrieval) (busca vetorial)

A recuperação densa usa vetores de incorporação:

Codificar consulta e documentos em vetores
Recuperar vizinhos mais próximos por similaridade do cosseno ou produto escalar

Ela se destaca quando:

Consultas são parafraseadas ou conceituais
A terminologia varia entre documentos
Você quer correspondência semântica além de palavras exatas

Isso é comumente implementado com índices de vizinhos mais próximos aproximados (approximate nearest neighbor, ANN).

Relacionado: Bancos de Dados Vetoriais, Recuperação de Informação

Recuperação híbrida (hybrid retrieval)

Sistemas híbridos combinam:

Sinais por palavra-chave (BM25)
Similaridade densa
Filtros de metadados (tempo, autor, produto)
Reranqueamento (re-ranking) com um codificador cruzado (cross-encoder) ou um modelo de linguagem de grande porte

A recuperação híbrida costuma ser a abordagem mais robusta em produção.

Geração aumentada por recuperação

Na geração aumentada por recuperação, a recuperação fornece evidências a um gerador:

Consulta do usuário
Recuperar as top-k passagens
Compor uma instrução/contexto aumentado
Gerar uma resposta com citações ou evidências citadas literalmente

Principais escolhas de projeto:

Estratégia de fragmentação em blocos (tamanho, sobreposição, divisão sensível à estrutura)
Seleção do modelo de vetores de incorporação
Modelo de reranqueamento
Gestão da janela de contexto (context window) (o que incluir/excluir)
Formato de citação e ancoragem

Relacionado: Geração Aumentada por Recuperação

Avaliação: medindo a qualidade de sistemas de PLN

A avaliação em PLN é desafiadora porque a qualidade da linguagem é multidimensional: correção, relevância, fluência, fidelidade, segurança e utilidade.

Avaliação intrínseca (intrinsic evaluation) vs extrínseca (extrinsic evaluation)

Avaliação intrínseca: mede diretamente um componente (por exemplo, similaridade de vetores de incorporação, perplexidade).
Avaliação extrínseca: mede o impacto em uma tarefa final (por exemplo, acurácia em perguntas e respostas, satisfação do usuário).

A avaliação extrínseca costuma ser mais significativa, mas é mais lenta e mais cara.

Métricas automáticas comuns

Classificação / extração

Acurácia
Precisão / Revocação / F1
Correspondência exata (para campos estruturados)
AUROC / AUPRC para conjuntos de dados desbalanceados

Geração

BLEU (tradução): sobreposição de n-gramas; pode subvalorizar paráfrases válidas.
ROUGE (sumarização): focada em sobreposição; correlaciona-se de forma imperfeita com a qualidade.
METEOR: inclui stemming/sinônimos; menos comum hoje.
BERTScore: usa vetores de incorporação contextuais para medir similaridade semântica.
Perplexidade (perplexity): mede quão bem um modelo prediz texto; não é uma métrica direta de qualidade para seguimento de instruções.

Recuperação

Recall@k, Precision@k
MRR (mean reciprocal rank)
nDCG (qualidade de ranqueamento com relevância graduada)

Avaliação humana

Julgamentos humanos ainda são essenciais para:

Utilidade e completude
Factualidade e fidelidade
Tom e segurança
Comparações de preferência entre modelos

Boas práticas:

Usar rubricas claras e múltiplos anotadores
Medir concordância entre anotadores (inter-annotator agreement)
Randomizar e usar condições cegas (blind) para reduzir viés

Modelo de linguagem como juiz (LLM-as-judge) e avaliação baseada em modelos

Usar um modelo de linguagem de grande porte para avaliar saídas é cada vez mais comum, especialmente em tarefas abertas. Benefícios:

Escala melhor do que revisão humana
Pode aplicar rubricas consistentes

Riscos:

Viés a favor de respostas verbosas ou estilisticamente semelhantes
Sensibilidade à redação da instrução
Possível falha em detectar erros factuais sutis

Uma abordagem prática é a triangulação (triangulation): combinar métricas automáticas, testes unitários direcionados e revisão humana amostrada.

Robustez, segurança e contaminação

A avaliação moderna também considera:

Robustez adversarial (adversarial robustness) (injeção de prompt (prompt injection), fugas de restrição (jailbreaks))
Contaminação de dados (data contamination) (treinar em benchmarks de teste)
Mudança de distribuição (distribution shift) (novos domínios, novos estilos de escrita)
Equidade (fairness) entre idiomas e demografias

Para sistemas de geração aumentada por recuperação, avalie a fidelidade de ponta a ponta (end-to-end faithfulness):

As alegações são sustentadas por fontes recuperadas?
O modelo alucina além das evidências?

Pipelines práticos de PLN (de dados à implantação (deployment))

Preparação de dados

Etapas típicas:

Limpeza de texto (cuidado: limpeza excessiva pode remover significado)
Identificação de idioma e filtragem
Deduplicação (deduplication) (importante tanto para qualidade de treinamento quanto para integridade de avaliação)
Divisão treino/validação/teste com prevenção de vazamento (leakage) (por exemplo, por documento, usuário ou tempo)

Escolhendo uma estratégia de modelagem

Uma árvore de decisão comum:

Precisa de correspondência exata e transparência → comece com BM25 / linha de base (baseline) de TF‑IDF
Precisa de correspondência semântica → vetores de incorporação + busca vetorial
Precisa de extração estruturada → codificador com ajuste fino ou geração restrita
Precisa de geração aberta → modelo de linguagem ajustado por instruções, frequentemente com geração aumentada por recuperação

Exemplo: loop mínimo de recuperação semântica (ilustrativo)

# Pseudocode-style example; replace `embed()` and `vector_index` with real libraries.
docs = ["Return policy: 30 days with receipt.", "Shipping takes 3-5 business days."]
doc_vecs = [embed(d) for d in docs]
vector_index = build_ann_index(doc_vecs)

query = "How long do I have to return an item?"
q_vec = embed(query)
top_ids = vector_index.search(q_vec, k=1)
context = docs[top_ids[0]]

prompt = f"Answer using only this policy:\n{context}\n\nQuestion: {query}\nAnswer:"
answer = generate(prompt)
print(answer)

Em produção, você adicionaria:

Documentos fragmentados em blocos com metadados
Recuperação híbrida + reranqueamento
Um formato de ancoragem/citação
Salvaguardas (guardrails) para consultas fora de escopo

Aplicações de PLN

O PLN é amplamente implantado em:

Mecanismos de busca e bases de conhecimento corporativas
Automação e roteamento de suporte ao cliente
Compreensão de documentos (contratos, notas médicas, compliance)
Ferramentas para desenvolvedores (autocompletar código, refatoração, documentação)
Educação (tutoria, feedback)
Acessibilidade (fala para texto (speech-to-text) + sumarização, simplificação de texto)
Analytics (mineração de tendências, sentimento, vinculação de entidades (entity linking))

Em sistemas agentivos, o PLN dá suporte a:

Interpretar objetivos do usuário
Planejar etapas em linguagem natural
Chamar ferramentas e APIs com argumentos estruturados
Sumarizar resultados intermediários para memória (veja Agentes e Planejamento)

Principais desafios e problemas em aberto

Ancoragem e alucinação (hallucination)

Modelos generativos podem produzir alegações fluentes, porém sem suporte. Geração aumentada por recuperação, citações, decodificação restrita e etapas de verificação ajudam, mas não resolvem completamente o problema.

Raciocínio em contexto longo (long-context reasoning) e memória

Mesmo com janelas de contexto longas, modelos podem:

Deixar passar detalhes relevantes
Falhar em integrar evidências de forma consistente
Perder o controle de restrições ao longo de diálogos longos

Isso se cruza com o projeto de agentes (agent design) (memória, planejamento, uso de ferramentas).

Multilinguismo (multilinguality) e cenários de poucos recursos (low-resource settings)

Muitos idiomas têm poucos dados rotulados e menos texto na web para pré-treinamento, afetando qualidade e equidade. Técnicas incluem pré-treinamento multilíngue, aprendizado por transferência (transfer learning) e aumento de dados (data augmentation).

Privacidade, direitos autorais e governança

PLN no mundo real deve abordar:

Manuseio e redação de dados sensíveis
Proveniência de dados de treinamento
Filtragem de saída e conformidade com políticas
Auditoria e monitoramento ao longo do tempo

Resumo

O PLN combina tarefas (classificação, extração, geração, perguntas e respostas), representações (tokens, TF‑IDF, vetores de incorporação), recuperação (BM25, vetores densos, híbridos, geração aumentada por recuperação) e avaliação (métricas, julgamentos humanos, robustez). Sistemas modernos integram cada vez mais esses componentes: a recuperação fornece ancoragem, os vetores de incorporação fornecem acesso semântico, Transformers fornecem generalização, e uma avaliação cuidadosa garante que o sistema funcione de forma confiável no mundo real.

Se você está construindo um sistema de PLN hoje, um padrão prático forte é: comece com uma linha de base simples, adicione recuperação para ancoragem, use vetores de incorporação para correspondência semântica e avalie ponta a ponta com métricas da tarefa e revisão humana.