Resumo Técnico: DisasterLex

Definição do Problema

A gestão de desastres depende do acesso rápido a dados geoespaciais estruturados e densos em informações (perigo, exposição, vulnerabilidade e infraestrutura) para coordenar respostas em tempo crítico. Embora as interfaces de linguagem natural (Text-to-SQL) tenham avançado, elas falham no domínio de desastres por três razões primárias:

1. Heterogeneidade de Esquema: Os bancos de dados de desastres abrangem dezenas de tabelas com semânticas especializadas, valores sentinela para ausência de dados e convenções de pontuação invertidas (ex: pontuações mais altas indicando maior vulnerabilidade em um conjunto de dados, mas resiliência em outro).
2. Lacunas de Raciocínio Causal: Especialistas do domínio raciocinam sobre cadeias causais (ex: baixa resiliência $\rightarrow$ capacidade de resposta reduzida; profundidade da inundação $\rightarrow$ danos estruturais). Modelos padrão de Text-to-SQL carecem desses codificamentos causais externos, levando a alucinações de junções (joins) entre tabelas semanticamente não relacionadas que compartilham apenas uma chave geográfica.
3. Descompasso de Recuperação: A recuperação padrão (RAG) recupera passagens de texto, enquanto a análise de desastres requer SQL executável sobre tabelas estruturadas. Métodos existentes de RAG aumentados por grafos melhoram a recuperação de passagens, mas não resolvem o problema de seleção de esquema necessário para a resposta de consultas estruturadas.

Metodologia: Estrutura DisasterLex

O DisasterLex é uma estrutura de agentes mediada por grafos de conhecimento, projetada para fazer a ponte entre consultas em linguagem natural e bancos de dados geoespaciais estruturados. Consiste em três componentes integrados:

1. Grafo de Conhecimento Unificado

O sistema hospeda um grafo unificado no Neo4j, combinando dois subgrafos:

• Grafo de Catálogo de Dados de Desastres (DDCG): Auto-introspecionado a partir do banco de dados relacional (DuckDB). Ele representa tabelas como nós DataTable, colunas como nós DataColumn e padrões de junção válidos como nós JoinRule.
• Grafo de Conhecimento de Especialista (EKG): Um grafo direcionado curado de 107 conceitos de domínio conectados por 117 arestas tipadas (tipos: AUMENTA, REDUZ, INDICA, REQUER, ESCALA). Cada conceito inclui listas de sinônimos para correspondência difusa (fuzzy matching).
• Ponte Conceito-Esquema: 52 arestas explícitas mapeiam nós de conceitos do EKG para nós DataTable específicos no DDCG. Isso permite que o sistema transite de um conceito de linguagem natural do usuário (ex: "ocorrência de inundação") para as tabelas de banco de dados específicas (ex: HP_FLD_002) necessárias para a execução.

2. Recuperação de Esquema Consciente de Conceitos

Em vez de injetar o esquema completo de 150 colunas no prompt, o DisasterLex realiza uma recuperação em três etapas:

1. Correspondência de Conceitos: Utiliza expressões regulares de fronteira de token para corresponder termos da consulta aos sinônimos dos conceitos do EKG.
2. Travessia de Grafo: Realiza uma travessia de 1 salto (1-hop) em Cypher a partir dos conceitos ativados até os nós DataTable conectados, recuperando colunas relevantes, regras de junção e avisos de qualidade de dados.
3. Injeção de Contexto: Substitui o esquema completo por um bloco compacto de 10 a 20 colunas relevantes, reduzindo significativamente a diluição da atenção.

3. Pipeline de Orquestração de Quatro Estágios

Implementado como um grafo direcionado no LangGraph, o pipeline impõe uma estrutura operacional derivada do Sistema de Comando de Incidentes (ICS):

1. Extração de Contexto e Criticidade: Analisa a consulta em busca de área de interesse, tipo de perigo e um nível de criticidade (1–5). Realiza verificações de disponibilidade de dados baseadas em regras para evidenciar tabelas ausentes ou bloqueadas.
2. Classificação de Domínio Operacional: Direciona a consulta para um de três clusters motivados pelo ICS: Operações de Segurança da Vida, Avaliação de Danos e Resposta, ou Mitigação de Infraestrutura. Cada cluster utiliza um template de prompt especializado.
3. Planejamento Informado por Causalidade: Um agente ReAct recupera arestas causais do EKG e realiza buscas na web (se necessário) para construir um plano de análise estruturado, decompondo a consulta em sub-tarefas e identificando métricas necessárias.
4. Execução Aumentada por Ferramentas: Um segundo agente ReAct executa o plano usando duas ferramentas:
   • Ferramenta Text-to-SQL: Gera SQL baseado no esquema consciente de conceitos, com validação de sintaxe e lógica de tentativa e erro (retry logic).
   • Ferramenta de Grafo de Conhecimento: Percorre regras causais para sintetizar evidências.
     O agente sintetiza um relatório de incidente com achados, recomendações (controladas pela criticidade) e evidências.

Principais Contribuições

1. Vinculação de Esquema em Nível de Conceito: A introdução de um Grafo de Conhecimento de Especialista (EKG) como uma camada de seleção de esquema. Ao interpor 107 conceitos e 117 arestas causais entre as consultas e um esquema de 36 tabelas, o sistema reduz o contexto do prompt de 150 colunas para aproximadamente 10–20, abordando o modo de falha de seleção de esquema de abordagens anteriores de Text-to-SQL e RAG.
2. Orquestração Motivada pelo ICS: Um pipeline de quatro estágios que decompõe consultas de análise de desastres em extração de criticidade, roteamento de cluster, planejamento causal e execução fundamentada. Estudos de ablação demonstram que remover o roteamento ou o planejamento degrada significativamente o desempenho, particularmente para composição multi-tabela.
3. Benchmark Diagnóstico de Quatro Níveis: Um conjunto de testes de 75 casos organizado em quatro níveis para isolar modos de falha específicos:
   • Nível R (Roteamento): Seleção correta de cluster e tipo de consulta.
   • Nível K (Fundamentação EKG): Presença de tokens causais esperados na resposta.
   • Nível M (Multi-Tabela): Junções SQL corretas entre 2 a 4 tabelas.
   • Nível D (Divulgação): Relato transparente de dados ausentes ou bloqueados.
4. Evidência entre Modelos: Avaliação em sete modelos base (variando de 8B a 70B parâmetros, incluindo famílias de código aberto e fonte fechada) e quatro baselines de estado da arte (LightRAG, HippoRAG 2, ReFoRCE, CHESS).

Resultados

Avaliado em um conjunto de teste de 75 consultas sobre um banco de dados de análise de desastres em todo o Texas (36 tabelas, 150 colunas):

• Desempenho: O DisasterLex alcançou pontuações gerais entre 1,65 e 3,56 (em uma escala de 5,0) nos sete modelos base.
• Comparação: Superou quatro baselines de estado da arte em 1,4× a 2,75× em cada modelo base. Todos os baselines externos pontuaram abaixo de 2,0 no total, enquanto o DisasterLex excedeu 2,5 em cinco de sete modelos.
• Análise de Falhas: As falhas dos baselines concentraram-se em roteamento (Nível R) e composição SQL multi-tabela (Nível M). O DisasterLex aborda isso explicitamente através de sua camada de roteamento e recuperação de esquema consciente de conceitos.
• Insights de Ablação:
  • O Roteamento foi universalmente crítico; remover o roteamento causou as maiores quedas nos scores do Nível M (0,81–2,67 pontos) em todos os modelos.
  • Os efeitos de Planejamento e EKG variaram conforme a capacidade do modelo. Por exemplo, remover o planejamento reduziu os scores do Nível K em 3,19 no Qwen 3.6, mas apenas 0,20–0,48 em outros modelos, sugerindo que o valor da orquestração explícita é modulado pelas capacidades intrínsecas de raciocínio do modelo base.

Significância e Alegações

O artigo afirma que, para a análise de desastres, a camada de conceito-para-esquema mais a orquestração importam mais do que a escolha do substrato de recuperação ou do agente Text-to-SQL. Os resultados sugerem que pipelines de recuperação de propósito geral e Text-to-SQL são insuficientes para domínios que exigem raciocínio causal sobre dados geoespaciais estruturados e heterogêneos.

O DisasterLex demonstra que um grafo de conceitos causais curado por especialistas, atuando como uma camada de seleção de esquema específica do domínio, pode mediar efetivamente a linguagem natural e bancos de dados relacionais complexos. Os autores postulam que este padrão é transferível para outros domínios onde o conhecimento causal especializado coexiste com dados estruturados sensíveis ao tempo, como triagem médica ou interrupção de cadeia de suprimentos.

O trabalho é apresentado como uma ferramenta de suporte à decisão, observando explicitamente que seus outputs não são orientações de comando de incidente autoritativas e requerem revisão humana, particularmente para recomendações de alta criticidade. O sistema é projetado para expor a incerteza (via divulgações de disponibilidade de dados) em vez de substituir o julgamento do especialista.