Análise Semântica

O que é análise semântica?

Análise semântica (semantic parsing) é a tarefa de converter um enunciado em linguagem natural (natural-language utterance) (uma pergunta, comando ou instrução) em uma representação estruturada de significado (structured meaning representation) que uma máquina possa executar (por exemplo, consultar um banco de dados, chamar uma API, executar uma ferramenta) ou raciocinar sobre (por exemplo, realizar inferência lógica).

Ao contrário da análise sintática (que foca na estrutura gramatical), a análise semântica busca capturar o que o usuário quer dizer em uma linguagem formal com semântica bem definida. Isso a torna uma tecnologia-chave para sistemas que precisam fazer algo com linguagem: assistentes de dados, perguntas e respostas sobre bancos de dados, agentes de diálogo, seguimento de instruções em robótica e agentes modernos de LLMs que usam ferramentas (“tool-using” LLM agents).

A análise semântica é intimamente relacionada (e às vezes se sobrepõe) a tarefas como Recuperação de Informação e Extração de Conhecimento, mas o diferencial é que a saída normalmente é uma estrutura do tipo programa com significado composicional explícito.

Representações de significado (formalismos)

Uma representação de significado é a “linguagem-alvo” que o analisador produz. A escolha certa depende do que você precisa executar ou sobre o que precisa raciocinar.

Formas lógicas (cálculo lambda (lambda calculus), lógica de primeira ordem (first-order logic))

A análise semântica clássica frequentemente produz uma forma lógica (logical form) que pode ser avaliada contra uma base de conhecimento.

Exemplo de enunciado:

“Quais rios passam pelo Texas?”

Uma forma lógica possível (ilustrativa):

answer(x) := river(x) ∧ runs_through(x, Texas)

Representações mais composicionais, no estilo de cálculo lambda, são comuns em conjuntos de dados acadêmicos (por exemplo, GeoQuery):

λx. river(x) ∧ traverse(x, texas)

Formas lógicas são atraentes porque oferecem suporte a verificação de tipos, composição e, às vezes, inferência formal.

Linguagens de consulta a bancos de dados (SQL)

Texto-para-SQL (text-to-SQL) é uma das formas mais usadas e mais avaliadas em benchmarks de análise semântica: mapear uma pergunta para uma consulta SQL sobre um esquema relacional.

Enunciado:

“Mostre os nomes dos funcionários contratados após 2020 no departamento de vendas.”

SQL (uma versão correta):

SELECT e.name
FROM employees AS e
JOIN departments AS d ON e.department_id = d.id
WHERE d.name = 'Sales'
  AND e.hire_date >= '2021-01-01';

SQL é executável, testável (via resultados da consulta) e fortemente restringido por um esquema — o que o torna ideal para avaliar “estamos obtendo a resposta certa?”

Linguagens de consulta a grafos (SPARQL) e consultas a bases de conhecimento

Para grafos de conhecimento (triplas RDF), analisadores semânticos frequentemente têm como alvo SPARQL.

SELECT ?river WHERE {
  ?river rdf:type :River .
  ?river :runsThrough :Texas .
}

Linguagens específicas de domínio (domain-specific languages, DSLs)

Muitas aplicações usam uma DSL adaptada ao ambiente:

  • Uma DSL de assistente de calendário (“create_event”, “invite”, “time_range”)
  • Uma DSL de comando de robô (“move”, “pick”, “place”)
  • DSLs de analytics (filtros, group-by, métricas)

DSLs podem ser projetadas para tornar a decodificação mais fácil (menos graus de liberdade do que código de propósito geral) e mais segura (operações limitadas).

Chamadas de API / chamadas de ferramenta (tool calls) (estilo de “chamada de função” (function calling) em JSON)

Assistentes modernos frequentemente mapeiam texto para invocações estruturadas de ferramentas — uma forma de análise semântica especialmente importante para sistemas de LLMs que usam ferramentas.

Enunciado:

“Marque uma reunião de 30 minutos com a Maya na próxima semana, na terça-feira à tarde.”

Chamada de ferramenta:

{
  "tool": "calendar.create_event",
  "arguments": {
    "title": "Meeting with Maya",
    "duration_minutes": 30,
    "attendees": ["maya@example.com"],
    "time_window": {
      "start": "2026-01-13T12:00:00",
      "end": "2026-01-13T17:00:00"
    }
  }
}

Isso é executável, auditável e mais fácil de validar do que texto livre.

Representação Abstrata de Significado (Abstract Meaning Representation, AMR) e semântica não executável

Representações como AMR buscam capturar o significado da sentença, mas não são inerentemente executáveis. Elas são úteis para raciocínio a jusante ou normalização, mas muitas aplicações de análise semântica preferem alvos executáveis.

Por que análise semântica é difícil

A análise semântica fica na interseção entre compreensão de linguagem e síntese de programas (program synthesis). Dificuldades comuns incluem:

  • Ambiguidade: “funcionários em vendas” pode significar nome do departamento, função, centro de custo etc.
  • Composicionalidade: o significado depende de combinar partes (“top 3”, “após 2020”, “para cada departamento”).
  • Ancoragem (grounding): vincular menções a entidades/colunas/argumentos de API (vinculação ao esquema (schema linking), resolução de entidades (entity resolution)).
  • Contexto: histórico do diálogo, preferências do usuário, tempo (“próxima terça”), suposições ocultas.
  • Programas espúrios (spurious programs): múltiplos programas podem produzir a mesma resposta em dados limitados, mas apenas um generaliza.
  • Generalização para novos esquemas/domínios: crítica em texto-para-SQL e uso de ferramentas.

Esses desafios moldam tanto as abordagens de modelagem quanto a avaliação.

Abordagens de modelagem

Em linhas gerais, métodos de análise semântica se dividem em (1) abordagens baseadas em gramática (grammar-based approaches), (2) modelos neurais de sequência (neural sequence models) (especialmente Transformers (Transformers)), e (3) abordagens de decodificação restrita (constrained decoding) / híbridas que impõem correção.

Abordagens baseadas em gramática e simbólicas

Historicamente, analisadores semânticos eram construídos usando gramáticas explícitas e semântica composicional, às vezes inspiradas na linguística formal.

Ideias comuns:

  • Gramáticas síncronas (synchronous grammars): mapear sintaxe e semântica conjuntamente.
  • Gramática Categorial Combinatória (Combinatory Categorial Grammar, CCG): gramática lexicalizada com anexos semânticos.
  • Parsing por tabela / CKY (chart parsing / CKY): programação dinâmica sobre regras gramaticais.
  • Composição guiada por tipos (type-driven composition): só compor expressões se os tipos combinarem.

Um esboço simplificado de composição baseada em regras:

  • “funcionários” → Employees() (uma tabela ou conjunto)
  • “em Vendas” → Filter(department = 'Sales')
  • Combine → Filter(Employees(), department = 'Sales')

Prós

  • Interpretabilidade e garantias explícitas (bem tipado, estruturas válidas)
  • Frequentemente mais eficiente em dados em domínios estreitos

Contras

  • Custo de engenharia de gramática
  • Problemas de cobertura com a variabilidade de linguagem do mundo real
  • Mais difícil de escalar para muitos esquemas/ferramentas sem automação significativa

Muitos sistemas modernos incorporam ideias de gramática, mas dependem de modelos neurais para escolher regras.

Análise semântica neural (sequência a sequência (seq2seq) e Transformers)

A análise semântica neural trata o problema como geração condicional:

[ p(\text{meaning} \mid \text{utterance}, \text{context}) ]

A maioria dos sistemas atuais usa Transformers codificador–decodificador (encoder–decoder Transformers) (ver Arquitetura Transformer):

  • O codificador lê o enunciado (e possivelmente descrições de esquema/ferramentas).
  • O decodificador gera a representação de significado token por token.

Técnicas-chave:

  • Atenção (attention) e mecanismos de cópia/ponteiro (copy/pointer mechanisms): copiar nomes de colunas, entidades, valores de argumentos de API.
  • Pré-treinamento + ajuste fino (pretraining + finetuning): inicializar a partir de modelos de linguagem grandes (large language models, LLMs) treinados via Modelagem de Linguagem.
  • Codificação de esquema / vinculação ao esquema (texto-para-SQL):
    • Fornecer nomes de tabelas/colunas e, opcionalmente, descrições.
    • Vincular trechos do enunciado a colunas (“contratados após” → hire_date).
  • Aumento por recuperação (retrieval augmentation):
    • Recuperar exemplos semelhantes, trechos de documentação ou esquemas de ferramentas e condicionar a geração neles.

Exemplo: linearizar SQL como uma sequência de tokens:

SELECT employees.name FROM employees JOIN departments ...

Isso é simples e eficaz, mas pode gerar SQL inválido a menos que seja restringido.

Prós

  • Forte desempenho com dados suficientes e bom pré-treinamento
  • Flexível entre tarefas (SQL, chamadas de API, DSLs)

Contras

  • Pode produzir saídas inválidas ou inseguras
  • Propenso a colunas/ferramentas “alucinadas” se não houver restrições
  • A generalização para esquemas não vistos continua desafiadora sem um desenho cuidadoso

Decodificação estruturada em árvore

Em vez de gerar uma string plana, muitos analisadores semânticos geram uma árvore de sintaxe abstrata (abstract syntax tree, AST):

  • Predizer tipos de nós e filhos recursivamente
  • Impor estrutura de forma mais natural do que a decodificação em texto puro

Por exemplo, uma chamada de ferramenta pode ser uma estrutura do tipo AST:

Call(
  tool="calendar.create_event",
  args={duration_minutes: 30, ...}
)

A decodificação em árvore frequentemente combina bem com restrições (tipos, argumentos obrigatórios).

Decodificação restrita e análise guiada por execução

Decodificação restrita injeta restrições formais para que o modelo só possa gerar estruturas válidas. Isso é crucial para saídas executáveis.

Mecanismos comuns de restrição:

  • Decodificação restrita por gramática (grammar-constrained decoding) (CFG/PEG):
    • O decodificador só pode emitir tokens que mantenham a saída parcial sintaticamente válida.
  • Restrições de estado finito (finite-state constraints):
    • Úteis para templates ou padrões de DSL restritos.
  • Restrições de tipo (type constraints):
    • Garantir, por exemplo, que uma cláusula WHERE compare tipos compatíveis (data vs número).
  • Restrições de esquema (schema constraints) (texto-para-SQL):
    • Permitir apenas nomes de colunas que existam no esquema do banco de dados fornecido.
  • Validação de argumentos (argument validation) (chamadas de ferramenta):
    • Impor argumentos obrigatórios, enums, esquema JSON etc.

Decodificação guiada por execução (execution-guided decoding) vai além: durante a busca em feixe (beam search), candidatos parcialmente formados são executados (ou verificados) e podados se falharem (erro de sintaxe, erro de tipo, resultados vazios etc.). Para SQL, isso pode eliminar muitas consultas inválidas cedo.

Um esboço conceitual:

for candidate in beam:
  if not parses(candidate): discard
  if violates_schema(candidate): discard
  if can_execute(candidate) and execution_error: discard

Isso é especialmente eficaz quando:

  • a execução é barata,
  • as restrições são fortes,
  • e o modelo poderia alucinar de outra forma.

Sistemas híbridos

Muitos analisadores semânticos práticos combinam componentes:

  • Modelo neural propõe candidatos
  • Uma gramática/validador os restringe
  • Um reclassificador (reranker) escolhe entre candidatos usando sinais adicionais
  • Filtragem guiada por execução opcional

Híbridos são comuns em produção porque melhoram a confiabilidade e a facilidade de depuração.

Sinais de treinamento e supervisão

A análise semântica pode ser treinada sob diferentes regimes de supervisão:

Totalmente supervisionado (fully supervised) (enunciado → representação de significado gold)

Este é o padrão quando você tem pares rotulados:

  • “pergunta” + SQL gold
  • “comando” + JSON gold de chamada de ferramenta

A perda (loss) é tipicamente entropia cruzada em nível de token (token-level cross-entropy) (forçamento pelo professor (teacher forcing)). Isso é direto, mas caro de rotular em escala.

Supervisão fraca (weak supervision) (apenas denotações (denotations) / resultados de execução)

Às vezes você só conhece a resposta (denotação), não o programa:

  • Você conhece as linhas retornadas, não o SQL.
  • Você conhece o resultado da ferramenta, não a chamada exata da API.

O treinamento então precisa buscar programas que produzam a denotação correta. Abordagens incluem:

  • Aprendizado por reforço (reinforcement learning) / gradientes de política (policy gradients)
  • Máxima verossimilhança marginal (maximum marginal likelihood) sobre programas latentes (latent programs)
  • Busca heurística + aprendizado para ranqueamento (learning-to-rank)

Uma grande armadilha são programas espúrios: programas incorretos que, por acaso, produzem a resposta certa nos exemplos de treino.

Dados sintéticos e auto-treinamento (self-training)

Para domínios em que você consegue gerar programas facilmente, você pode criar enunciados sintéticos:

  • Gerar programas em DSL → parafrasear em linguagem natural
  • Usar LLMs para criar paráfrases diversas e então filtrar/validar

Isso ajuda a dar partida em novos domínios, mas exige filtragem cuidadosa para evitar ensinar ao modelo mapeamentos errados.

Avaliação

Como a análise semântica produz objetos estruturados, a avaliação é mais sutil do que comparar strings.

Correspondência exata (exact match) (correspondência estrutural/de string)

A métrica mais rígida: a representação de significado prevista deve corresponder exatamente ao programa gold (muitas vezes após normalização).

  • Prós: simples, determinística
  • Contras: penaliza programas semanticamente equivalentes com sintaxe diferente (comum em SQL)

Acurácia de execução (execution accuracy) (correspondência de denotação (denotation match))

Executar o programa previsto e comparar resultados com o resultado gold.

  • Prós: mede o que importa para muitas aplicações
  • Contras:
    • Múltiplas consultas erradas às vezes podem retornar o mesmo resultado (especialmente em bancos pequenos)
    • A execução pode ser não determinística (APIs dependentes de tempo)
    • Preocupações de segurança/segurança operacional ao executar código não confiável

Benchmarks de texto-para-SQL frequentemente reportam tanto correspondência exata quanto acurácia de execução.

Métricas em nível de componente e baseadas em restrições

Para diagnosticar erros, sistemas também medem:

  • Colunas corretas no SELECT
  • Condições corretas no WHERE
  • Joins corretos/caminhos de chave estrangeira corretos
  • Nome correto da ferramenta / argumentos obrigatórios presentes
  • Acurácia de preenchimento de slots (slot-filling) (para chamadas de API)

Essas métricas ajudam na depuração e em melhorias incrementais.

Avaliação humana e sucesso na tarefa

Em execução de ferramentas e configurações de diálogo, “correção” pode ser:

  • satisfação do usuário,
  • taxa de conclusão,
  • número de turnos de esclarecimento,
  • ausência de ações inseguras.

Métricas tradicionais de NLP como BLEU geralmente não são recomendadas como métricas principais para representações de significado executáveis (ver Avaliação para NLP para armadilhas mais amplas de métricas).

Benchmarks e conjuntos de dados comuns

Alguns benchmarks influentes ilustram diferentes regimes de análise semântica:

  • GeoQuery: análise semântica composicional clássica para formas lógicas sobre geografia dos EUA.
  • ATIS: consultas de reserva de voos; preenchimento de slots inicial + semântica composicional.
  • WikiSQL: texto-para-SQL com consultas relativamente simples de uma única tabela.
  • Spider: texto-para-SQL complexo com generalização entre domínios para esquemas não vistos; enfatiza joins, aninhamento e vinculação ao esquema.

Conjuntos de dados de uso de ferramentas são mais fragmentados e frequentemente proprietários, mas os mesmos princípios de avaliação se aplicam.

Aplicações práticas

Assistentes de dados texto-para-SQL

Caso de uso: “Faça perguntas ao banco de dados da sua empresa em inglês simples.”

O pipeline frequentemente inclui:

  1. Ingestão do esquema (tabelas, colunas, tipos, descrições)
  2. Vinculação ao esquema (mapear “contratado” → hire_date)
  3. Análise para SQL com restrições
  4. Execução + formatação do resultado
  5. Esclarecimento opcional de acompanhamento (“Você quer dizer departamento de Vendas ou região de vendas?”)

Texto-para-SQL é popular porque o sucesso é mensurável e a saída é diretamente útil.

Execução de ferramentas em agentes de LLMs (APIs, funções, fluxos de trabalho)

Assistentes modernos frequentemente mapeiam linguagem para invocações de ferramentas:

  • ferramentas de busca
  • calendários/e-mail
  • criação de tickets
  • operações em nuvem
  • transformações de dados

Aqui, preocupações de análise semântica incluem:

  • correção do esquema JSON
  • validação de argumentos
  • seleção de ferramenta
  • padrões seguros e verificações de permissão

Em muitos sistemas, a “representação de significado” é um grafo de chamadas de ferramenta (tool call graph) ou uma sequência de chamadas de ferramenta (um plano).

Análise semântica em diálogo e conversacional

Em configurações de múltiplos turnos, a representação de significado depende do contexto:

Usuário:

“Mostre a receita por mês em 2024.”

Usuário:

“Agora separe por região.”

O segundo turno pode compilar para uma consulta modificada que reutiliza restrições anteriores e adiciona uma dimensão de agrupamento. Isso exige rastreamento de estado (state tracking) e análise sensível ao contexto.

Robótica e seguimento de instruções ancorado

Comandos como:

“Pegue o bloco vermelho e coloque-o sobre o azul.”

podem mapear para um plano estruturado em uma DSL, ancorado nos IDs de objetos de um sistema de percepção. A análise semântica precisa se integrar com ancoragem, incerteza e restrições de segurança.

Padrões de implementação e dicas (o que importa na prática)

Escolha uma representação que você consiga validar

Se a execução importa, prefira uma linguagem-alvo com:

  • uma gramática formal,
  • informação de tipos,
  • e um validador (parser, esquema JSON, parser de SQL).

Mesmo com modelos fortes, validação evita muitos modos de falha.

Restrinja a geração o mais cedo possível

Uma lição comum em produção: correção pós-hoc (post-hoc fixing) é menos confiável do que decodificação restrita.

Exemplos:

  • Permitir apenas nomes de ferramentas que existam.
  • Permitir apenas colunas SQL que existam no esquema fornecido.
  • Impor argumentos obrigatórios de API.

Forneça contexto rico e estruturado ao modelo

Para texto-para-SQL:

  • inclua nomes de tabelas/colunas, tipos e descrições opcionais;
  • formate de maneira consistente;
  • considere adicionar relacionamentos de chave estrangeira.

Para uso de ferramentas:

  • inclua descrições de ferramentas e esquemas de argumentos;
  • inclua exemplos de chamadas válidas.

Como você representa texto e contexto no nível de tokens pode importar; veja Aprofundamento em Tokenização e Representação de Texto para base.

Trate a vinculação de esquema/entidade como um problema de primeira classe

Uma grande fração dos erros vem de vinculação:

  • “vendas” → departamento vs categoria de produto
  • “último trimestre” → resolução de intervalo de datas
  • “Maya” → qual contato

Modelos explícitos de vinculação, ou recuperação sobre esquema/docs, frequentemente melhoram a acurácia mais do que ajustar a decodificação.

Registre artefatos intermediários para depuração

Falhas de análise semântica são mais fáceis de depurar se você registrar:

  • entidades/colunas vinculadas
  • decisões de decodificação restrita
  • programas candidatos (feixe)
  • erros de execução e exceções do banco de dados

Isso dá suporte a iteração rápida e avaliação direcionada.

Desafios em aberto e direções de pesquisa

  • Generalização robusta: ter bom desempenho em esquemas/ferramentas não vistos e novas construções linguísticas.
  • Generalização composicional: recombinar corretamente primitivos conhecidos de maneiras novas.
  • Fidelidade (faithfulness) e segurança: garantir que programas gerados correspondam à intenção do usuário e obedeçam permissões.
  • Espuriedade (spuriousness) sob supervisão fraca: aprender o programa certo quando apenas denotações são observadas.
  • Análise semântica interativa (interactive semantic parsing): fazer perguntas de esclarecimento quando ambiguidade é detectada.
  • Uso de ferramentas de longo horizonte (long-horizon tool use): representar e executar planos de múltiplas etapas de forma confiável (análise semântica encontra planejamento (planning)).

A análise semântica continua sendo uma tarefa fundamental de NLP: ela transforma linguagem em ações e respostas. Com a ascensão de sistemas de LLMs que usam ferramentas, ela é cada vez mais central para construir IA que não seja apenas fluente, mas também operacionalmente correta e verificavelmente ancorada.