Extração de Conhecimento

Extração de conhecimento (knowledge extraction) (frequentemente usada de forma intercambiável com extração de informação (information extraction)) é o processo de transformar texto não estruturado (unstructured text) em fatos estruturados e legíveis por máquina (machine-readable facts). Na prática, isso geralmente significa identificar entidades (entities) (pessoas, organizações, locais, produtos, leis, substâncias químicas), atributos (attributes) (datas, valores, papéis) e relações/eventos (relations/events) (works_for, acquired, located_in, diagnosed_with) e então emitir isso como registros, tabelas ou um grafo de conhecimento (knowledge graph).

Este artigo foca em extração de informação e extração de relações (relation extraction) a partir de texto: o que está sendo extraído, como sistemas modernos fazem isso, como avaliar e como construir pipelines práticos.

O que a “extração de conhecimento” abrange

Uma pilha típica de extração de conhecimento inclui várias subtarefas intimamente relacionadas:

  • Extração de entidades (entity extraction) (frequentemente via Reconhecimento de Entidades Nomeadas (Named Entity Recognition, NER)): encontrar menções de entidades e rotular seus tipos.
  • Vinculação de entidades (entity linking): mapear uma menção (“Apple”) para um ID canônico (Apple Inc. vs apple fruit).
  • Resolução de correferência (coreference resolution): conectar menções que se referem à mesma entidade (“Tim Cook” ↔ “he”).
  • Extração de relações (RE): identificar relacionamentos semânticos entre entidades.
  • Extração de eventos (event extraction): identificar eventos (por exemplo, acquisition, earthquake) e seus argumentos (comprador, vendedor, preço, data).
  • Preenchimento de campos / preenchimento de modelos (slot filling / template filling): extrair campos específicos de acordo com um esquema (por exemplo, total da fatura, data de vencimento).
  • Extração Aberta de Informação (Open Information Extraction, OpenIE): extrair tuplas relacionais sem um esquema predefinido (útil para exploração, mais ruidosa).

A extração de conhecimento fica próxima de outros blocos de construção de PLN (NLP):

Um exemplo concreto (entidades + relações)

Considere a frase:

“Apple acquired Beats for $3 billion in 2014.”

Uma extração estruturada poderia ser assim:

{
  "entities": [
    {"text": "Apple", "type": "ORG"},
    {"text": "Beats", "type": "ORG"},
    {"text": "$3 billion", "type": "MONEY"},
    {"text": "2014", "type": "DATE"}
  ],
  "relations": [
    {"type": "ACQUIRED", "head": "Apple", "tail": "Beats"},
    {"type": "PURCHASE_PRICE", "head": "Apple", "tail": "$3 billion"},
    {"type": "ACQUISITION_DATE", "head": "Apple", "tail": "2014"}
  ]
}

Em um grafo de conhecimento (KG), isso poderia virar nós (Apple, Beats) e arestas (acquired), além de atributos (preço, data).

Por que é difícil: ambiguidade, contexto e esquema

A extração de conhecimento parece simples, mas é desafiadora devido a:

  • Ambiguidade: “Apple” (empresa vs fruta), “Jordan” (pessoa vs país).
  • Contexto de longo alcance (long-range context): relações podem atravessar frases ou depender do contexto do documento.
  • Correferência: “The company… it… the Cupertino-based firm…”.
  • Menções aninhadas e sobrepostas: “University of California, Berkeley”.
  • Linguagem de domínio: medicina, direito, finanças exigem tipos de entidades e relações especializados.
  • Projeto de esquema (schema design): escolher rótulos de relações e tipos de entidades afeta tanto a modelagem quanto a avaliação.

Por isso, sistemas modernos frequentemente combinam aprendizado estatístico (statistical learning), restrições (constraints) e, às vezes, extração baseada em modelos de linguagem grandes (large language models, LLMs).

Formulações de tarefa

Extração de entidades (rotulagem de sequência (sequence labeling) vs previsão de trecho (span prediction))

Duas formulações comuns:

  1. Rotulagem de sequência (marcação BIO/BILOU): rotular cada token como Beginning/Inside/Outside de uma entidade.

    • Exemplo: Apple/B-ORG acquired/O Beats/B-ORG ...

  2. Extração baseada em trechos (span-based): prever offsets de início/fim (e tipos) para trechos de entidades.

    • Útil para entidades aninhadas e algumas configurações em nível de documento.

Historicamente, modelos clássicos como Campos Aleatórios Condicionais (Conditional Random Fields, CRFs) foram fortes para NER; sistemas modernos tipicamente fazem ajuste fino (fine-tuning) de Transformers e, opcionalmente, usam uma camada de decodificação CRF.

Extração de relações (classificação (classification) vs geração (generation))

A extração de relações costuma ser formulada como:

  • Classificação par a par (pairwise classification): para cada par candidato de entidades em uma frase/documento, prever um rótulo de relação (ou “no relation”).
  • Preenchimento de tabela (table filling): construir uma matriz entidade-por-entidade e rotular células com tipos de relação.
  • Previsão trecho-a-trecho (span-to-span): prever conjuntamente entidades e relações como uma saída estruturada.
  • Geração sequência a sequência (sequence-to-sequence): gerar triplas relacionais como texto (popular para IE “ponta a ponta (end-to-end)”).

Cada escolha envolve trade-offs entre:

  • Acurácia vs computação (par a par pode ser quadrática no número de entidades),
  • extração específica de esquema vs aberta,
  • facilidade de supervisão e decodificação.

Abordagens: de regras a Transformers a LLMs

Extração baseada em regras e em padrões

Sistemas baseados em regras usam:

  • Expressões regulares (datas, moeda, IDs),
  • Padrões de dependência (“X acquired Y”),
  • Listas de entidades (gazetteers),
  • Heurísticas (heuristics) (capitalização de título, sufixos como “Inc.”).

Prós:

  • Alta precisão em domínios estreitos,
  • Transparente e controlável.

Contras:

  • Frágil diante de paráfrases,
  • Baixa revocação e difícil de escalar.

A extração baseada em regras ainda tem papel como uma camada de precisão ou como fonte de rótulos fracos.

ML clássico: CRFs e engenharia de atributos

CRFs foram um padrão para marcação de sequência (NER), usando atributos como:

  • formato da palavra (word shape), prefixos/sufixos,
  • etiquetas de classe gramatical (part-of-speech, POS),
  • padrões de capitalização,
  • tokens ao redor.

Eles funcionam bem com poucos dados, mas em geral são superados por codificadores baseados em Transformer em benchmarks gerais.

Abordagens neurais: codificadores Transformer (padrão moderno)

A abordagem padrão hoje é:

  1. Tokenizar o texto (ver Aprofundamento em Tokenização (Tokenization Deep Dive)).
  2. Codificar tokens com um Transformer (do tipo BERT/RoBERTa/DeBERTa).
  3. Adicionar uma cabeça de tarefa:
    • classificação de token para NER,
    • classificação par a par para RE,
    • cabeças de trecho para início/fim.

Transformers ajudam porque aprendem representações contextualizadas (uma ideia central em Modelos de Embeddings (Embedding Models)) e conseguem capturar paráfrase e sintaxe sem atributos manuais.

Extração conjunta: entidades e relações ao mesmo tempo

Erros de extração de entidades se propagam para a extração de relações. Modelos conjuntos reduzem isso ao prever entidades e relações simultaneamente, muitas vezes via:

  • codificador compartilhado + decodificação estruturada,
  • representações de trechos usadas tanto para tipagem de entidades quanto para classificação de relações,
  • restrições (por exemplo, argumentos da relação devem ser trechos de entidades válidos).

Abordagens conjuntas são úteis quando as relações são sutis ou quando os limites das entidades são incertos.

Supervisão fraca e supervisão distante

Rotular relações é caro. Duas alternativas amplamente usadas:

  • Supervisão distante (distant supervision): alinhar um KG existente com texto bruto. Se o KG diz (Apple, acquired, Beats), então qualquer frase que mencione ambas pode ser rotulada como “acquired”.

    • Produz rótulos ruidosos (a frase pode mencionar ambas as entidades, mas não a relação).
    • Mitigações comuns: aprendizado multi-instância (multi-instance learning), remoção de ruído (denoising), aprendizado por currículo (curriculum learning).

  • Supervisão fraca (weak supervision): combinar heurísticas, padrões e regras para criar rótulos probabilísticos e, então, treinar um modelo para generalizar.

    • Especialmente útil para extração específica de domínio.

Extração baseada em LLMs (elaboração de prompts (prompting) e decodificação restrita (constrained decoding))

Modelos de linguagem grandes podem extrair fatos estruturados com prompts como “Return JSON with entities and relations.” Isso pode ser eficaz em domínios com poucos dados, mas introduz novas preocupações:

  • Deriva de esquema (schema drift): as saídas podem não corresponder exatamente aos rótulos/campos permitidos.
  • Fatos alucinados (hallucinated facts): relações plausíveis, porém sem suporte no texto.
  • Formatação inconsistente: parsing downstream frágil, a menos que haja restrição.

Boas práticas:

  • Usar esquemas JSON estritos (strict JSON schemas) e validar as saídas.
  • Preferir comportamento extrativo (extractive) (“apenas fatos explicitamente declarados”).
  • Usar ancoragem por recuperação (retrieval grounding) e trilhas de auditoria (audit trails) (armazenar trechos/offsets de origem).
  • Considerar ajuste fino ou restrições de ferramenta/formulário quando a confiabilidade importa.

Arquitetura prática de pipeline

Um pipeline robusto de extração de conhecimento frequentemente se parece com isto:

  1. Ingerir texto
  2. Segmentar
    • Separação de frases, limites de parágrafo, cabeçalhos de seção.
  3. Extração de entidades
    • NER + normalização (datas/unidades de moeda), possivelmente léxicos de domínio.
  4. Vinculação de entidades (opcional, mas comum)
    • Mapear menções para IDs canônicos; mesclar duplicatas.
  5. Correferência (opcional)
    • Melhorar relações em nível de documento (“he”, “the company”).
  6. Geração de candidatos para relações
    • Todos os pares de entidades dentro de uma janela, ou candidatos baseados em sintaxe.
  7. Extração de relações
    • Classificação/geração em nível de frase ou de documento.
  8. Pós-processamento
    • Aplicar restrições (compatibilidade de tipos), deduplicar, limiares de confiança.
  9. Armazenar resultados
    • Como tabelas, JSONL ou um KG (RDF/grafo de propriedades (property graph)), com proveniência (provenance) (id do documento, offsets).
  10. Avaliar e monitorar
  • Acompanhar deriva de precisão/revocação; executar análises periódicas de erro.

Exemplo: NER simples com Hugging Face (Python)

Abaixo está um exemplo mínimo usando um pipeline de NER pré-treinado:

from transformers import pipeline

ner = pipeline("token-classification", model="dslim/bert-base-NER", aggregation_strategy="simple")
text = "Apple acquired Beats for $3 billion in 2014."
print(ner(text))

Você obterá trechos de entidades com rótulos (ORG, MONEY, DATE etc.). A extração de relações tipicamente exige um modelo dedicado ou uma segunda etapa (classificador par a par, extrator de triplas seq2seq, ou LLM com restrições de esquema).

Exemplo: extração de relações como classificação par a par (conceitual)

Uma configuração supervisionada comum:

  • Entrada: frase + entidades marcadas (por exemplo, tokens especiais ao redor dos trechos).
  • Saída: rótulo de relação dentre um conjunto fixo (+ “no_relation”).

Pseudoformato:

[CLS] [E1] Apple [/E1] acquired [E2] Beats [/E2] for $3B in 2014. [SEP]
→ ACQUIRED

Esse método é simples, rápido e preciso quando as relações são majoritariamente locais à frase.

Avaliação: como medir a qualidade da extração

A extração de conhecimento geralmente é avaliada com precisão (precision), revocação (recall) e F1. O desafio é definir o que conta como correto.

Métricas de extração de entidades

Variantes comuns:

  • Correspondência exata (exact match): limites do trecho e tipo devem corresponder exatamente.
  • Correspondência parcial/sobreposta (partial/overlap match): permite imprecisão nos limites (útil em OCR ruidoso).
  • Média micro vs macro (micro vs macro averaging): micro é dominada por tipos frequentes; macro destaca tipos raros.

Métricas de extração de relações

Uma predição de relação geralmente é correta se:

  • o rótulo da relação corresponde,
  • ambos os argumentos correspondem às entidades gold (por ID ou trecho).

A avaliação pode ser:

  • Em nível de frase (a maioria dos benchmarks clássicos),
  • Em nível de documento (mais difícil; exige correferência e raciocínio entre frases).

Para sistemas modernos, o desenho da avaliação importa tanto quanto o modelo. Veja Avaliação para PLN (Evaluation for NLP) para orientações mais amplas sobre armadilhas de métricas e artefatos de datasets.

Proveniência e fidelidade

Em produção, você frequentemente precisa de mais do que um rótulo:

  • qual trecho de texto sustenta o fato,
  • escores de confiança,
  • metadados do documento/fonte.

Isso é essencial para auditoria, conformidade e depuração.

Datasets e benchmarks comuns (visão geral)

Benchmarks conhecidos moldaram o campo:

  • CoNLL-2003 (NER): entidades em textos jornalísticos (PER/ORG/LOC/MISC).
  • ACE 2005 (entidades + relações + eventos): esquema mais rico, mais difícil.
  • TACRED / Re-TACRED (extração de relações): relações em nível de frase com sujeito/objeto.
  • DocRED (extração de relações em nível de documento): relações entre frases.

Esses datasets são úteis, mas aplicações reais frequentemente exigem esquemas personalizados e adaptação de domínio.

Aplicações em sistemas reais

Busca e analytics corporativos

Extrair entidades e relações de documentos internos para viabilizar:

  • busca centrada em entidades (“todos os contratos mencionando o Fornecedor X”),
  • análise de tendências (“incidentes por componente e severidade”),
  • monitoramento de conformidade.

Isso frequentemente se combina com Busca Semântica para recuperar documentos relevantes e, em seguida, extração para produzir painéis estruturados.

Construção e enriquecimento de grafos de conhecimento

A extração pode preencher ou atualizar um KG:

  • adicionar novas entidades (produtos, clientes),
  • adicionar arestas (subsidiary_of, acquired),
  • anexar atributos (receita, datas).

Muitos pipelines usam extração + vinculação de entidades + deduplicação para manter o grafo consistente.

Saúde, jurídico e finanças

Extração específica de domínio dá suporte a:

  • extração de conceitos clínicos (condições, medicações),
  • extração de cláusulas e obrigações legais,
  • extração de eventos financeiros (resultados, guidance, M&A).

Esses cenários geralmente exigem:

  • fortes restrições de esquema,
  • alta precisão,
  • validação com humano no loop (human-in-the-loop).

Suporte ao cliente e gestão de incidentes

A partir de tickets e logs de chat:

  • extrair nomes de produto, códigos de erro, componentes, impacto,
  • vincular a problemas conhecidos,
  • evidenciar relações de causa raiz (“erro X causado por config Y”).

Escolhas de design e trade-offs

Esquema fechado vs aberto

  • Esquema fechado: conjunto fixo de tipos de entidades e relações.

    • Prós: avaliação mais fácil, saídas consistentes.
    • Contras: perde relações novas (“partnership”, “lawsuit”) a menos que sejam modeladas.

  • Extração aberta: tenta extrair relações arbitrárias.

    • Prós: descoberta e exploração.
    • Contras: normalização (normalization) é difícil (“bought”, “acquired”, “purchased” precisam ser canonizadas).

Um compromisso comum é extração aberta → normalização para uma ontologia controlada (controlled ontology).

Extração em nível de frase vs em nível de documento

  • Modelos em nível de frase são mais simples e frequentemente precisos para relações locais.
  • Extração em nível de documento lida com:
    • referências entre frases,
    • pronomes/correferência,
    • contexto de seção (por exemplo, “Risk Factors” vs “Results”).

Sistemas em nível de documento tipicamente precisam de mais computação e avaliação cuidadosa.

Pipelines com foco em precisão vs foco em revocação

  • Fluxos de conformidade e regulados tendem a otimizar precisão (evitar falsos positivos).
  • Descoberta e analytics podem otimizar revocação (capturar mais, filtrar depois).

Definição de limiares (thresholding), calibração (calibration) e filas de revisão humana são ferramentas práticas para equilibrar isso.

Dicas práticas para construir um sistema de extração

  1. Comece pelo esquema
    • Defina tipos de entidades e rótulos de relação; escreva exemplos e casos de borda.
  2. Colete dados representativos
    • Inclua os casos “bagunçados”: abreviações, erros de OCR, texto informal.
  3. Crie um baseline cedo
    • Um NER simples + regras + padrões de palavras-chave podem revelar se o problema é viável.
  4. Invista em diretrizes de anotação (annotation guidelines)
    • Consistência importa; ambiguidade nos rótulos vira incerteza do modelo.
  5. Use proveniência
    • Armazene offsets e trechos de origem para cada fato extraído.
  6. Faça análise de erros (error analysis) direcionada
    • Modos de falha típicos:
      • erros de limite (“University of California” vs “University of California, Berkeley”),
      • confusão de tipo (ORG vs PRODUCT),
      • erros de direção da relação (supplier_of vs customer_of),
      • super/subprevisão de “no relation”.
  7. Planeje para deriva (drift)
    • Novos nomes de produto, novos termos legais, novos formatos: monitore e atualize.

Conexões com tópicos vizinhos de PLN

Resumo

A extração de conhecimento transforma texto em fatos estruturados ao detectar entidades, vincular menções e identificar relações/eventos. Sistemas modernos geralmente são baseados em Transformers, muitas vezes combinados com supervisão fraca, restrições de esquema e pós-processamento. Os desafios centrais são ambiguidade, contexto em nível de documento e rigor na avaliação. Em produção, as abordagens mais bem-sucedidas tratam a extração como um pipeline ponta a ponta: desenho de esquema, dados, modelos, restrições, proveniência e monitoramento — tudo alinhado às necessidades de precisão/revocação da aplicação.