CBR-to-SQL: Rethinking Retrieval-based Text-to-SQL using Case-based Reasoning in the Healthcare Domain

O artigo apresenta o CBR-to-SQL, um novo framework baseado em Raciocínio Baseado em Casos que supera as limitações dos métodos RAG tradicionais na tradução de linguagem natural para SQL no domínio da saúde, alcançando maior precisão lógica e eficiência amostral ao utilizar um processo de recuperação em duas etapas para lidar com a variabilidade da terminologia médica.

O essencial

Imagine que você tem um hospital gigante, cheio de milhões de fichas médicas digitais (os chamados Electronic Health Records ou EHR). Essas fichas guardam segredos vitais sobre pacientes, tratamentos e doenças. Mas, para tirar proveito desses dados, você precisa fazer perguntas complexas, como: "Quantos pacientes diabéticos com mais de 60 anos foram tratados com insulina no último mês?"

O problema é que essas fichas estão organizadas em uma linguagem de computador chamada SQL. Para um médico ou pesquisador, pedir isso em SQL é como tentar pedir uma pizza falando em código binário. É difícil, técnico e cheio de barreiras.

Aqui entra a Inteligência Artificial (os Grandes Modelos de Linguagem, ou LLMs), que promete traduzir a pergunta simples do médico para o código SQL. Mas, no mundo da medicina, as coisas são complicadas: os termos mudam, há erros de digitação, siglas confusas e jargões específicos.

O artigo "CBR-to-SQL" propõe uma solução inteligente para esse problema, usando uma ideia antiga da psicologia chamada Raciocínio Baseado em Casos (CBR). Vamos entender como funciona com uma analogia simples.

O Problema: O "Banco de Memória" Bagunçado

Imagine que você tem um assistente de pesquisa (o modelo de IA) que tenta responder suas perguntas olhando em um arquivo de exemplos anteriores (pergunta antiga + resposta SQL antiga).

• A abordagem antiga (RAG padrão): É como se o assistente tentasse encontrar um exemplo exatamente igual ao que você pediu. Se você perguntar sobre "dor de barriga", ele só acha algo se houver um exemplo escrito exatamente "dor de barriga". Se o exemplo antigo estiver escrito como "abdômen doloroso" ou "cólica", ele pode não achar nada ou se confundir. Para tentar resolver isso, as pessoas enchem o arquivo de milhões de exemplos, mas isso cria uma bagunça (ruído) e deixa o sistema lento e confuso.

A Solução: O "Arquiteto de Padrões" (CBR-to-SQL)

Os autores criaram o CBR-to-SQL, que funciona como um arquiteto experiente que não apenas copia e cola, mas entende a estrutura do problema. Eles dividiram o trabalho em três etapas mágicas:

1. O "Desenhista de Esqueletos" (Case Retain)

Em vez de guardar a pergunta completa com todos os nomes de remédios e doenças, o sistema primeiro "apaga" os detalhes específicos e guarda apenas o esqueleto da pergunta.

• Analogia: Imagine que você tem uma receita de bolo. Em vez de guardar "Use 2 xícaras de farinha da marca X e 3 ovos da granja Y", o sistema guarda apenas: "Use [INGREDIENTE] e [OUTRO INGREDIENTE] para fazer um bolo".
• Isso transforma milhares de perguntas diferentes em poucos modelos de padrão. Assim, se alguém perguntar sobre "diabetes" ou "hipertensão", o sistema reconhece que ambas são "doenças" e usam o mesmo esqueleto lógico.

2. O "Arquiteto de Estrutura" (Template Construction)

Quando chega uma nova pergunta, o sistema primeiro procura no arquivo qual é o esqueleto mais parecido.

• Ele não tenta adivinhar o remédio específico ainda. Ele apenas monta a "estrutura da frase" em SQL.
• Analogia: É como montar um quebra-cabeça onde você já sabe que a peça do céu é azul e a da grama é verde, mas ainda não sabe exatamente qual nuvem ou qual flor vai encaixar. O sistema cria um "rascunho" do SQL com espaços em branco (como [NOME_DO_REMEDIO]) esperando para ser preenchido.

3. O "Detetive de Nomes" (Source Discovery)

Agora que a estrutura está pronta, o sistema entra na fase de detetive. Ele olha para os espaços em branco do rascunho e vai até o banco de dados real do hospital para encontrar o nome correto e oficial daquele item.

• Se a pergunta diz "remédio para dor de cabeça", o sistema procura no banco de dados se o nome oficial é "Paracetamol", "Dipirona" ou "Ibuprofeno", e qual tabela eles estão guardados.
• Analogia: É como se você tivesse o esqueleto do bolo e agora fosse à despensa pegar exatamente o pacote de farinha e os ovos certos, garantindo que não use "farinha de trigo" quando a receita pedia "farinha de amêndoas".

Por que isso é melhor?

1. Funciona com Poucos Exemplos: Como o sistema aprende os padrões (esqueletos) e não apenas a copiar frases, ele funciona muito bem mesmo quando há poucos dados disponíveis (o que é comum em hospitais menores ou doenças raras).
2. É Mais Robusto: Se você digitar "dor de barriga" em vez de "dor abdominal", o sistema não entra em pânico. Ele entende que é o mesmo tipo de problema e usa o esqueleto correto, depois o detetive encontra o termo técnico certo.
3. Menos Erros: Ao separar a lógica (o esqueleto) dos nomes (os detalhes), o sistema comete menos erros de lógica. Ele não tenta adivinhar tudo de uma vez.

O Resultado Final

Os pesquisadores testaram isso em dados reais do hospital MIMIC (um banco de dados médico famoso). O resultado foi impressionante:

• O sistema CBR-to-SQL foi mais preciso do que os métodos tradicionais.
• Ele foi mais eficiente, precisando de menos exemplos para aprender.
• Ele foi mais resistente a erros e a falta de dados.

Em resumo: O CBR-to-SQL é como transformar um assistente que apenas "decora" respostas em um consultor inteligente que entende a lógica por trás das perguntas médicas, separa o que é estrutura do que é detalhe, e só então preenche as informações corretas. Isso torna a tecnologia muito mais útil e segura para médicos e pesquisadores que precisam tomar decisões baseadas em dados.

Resumo técnico

Resumo Técnico: CBR-to-SQL

1. O Problema

A extração de insights de Bancos de Dados de Registros Eletrônicos de Saúde (EHR) é fundamental para a tomada de decisões clínicas e pesquisa, mas exige expertise em SQL, criando uma barreira para usuários não técnicos. Embora os Modelos de Linguagem de Grande Porte (LLMs) combinados com Geração Aumentada por Recuperação (RAG) sejam promissores para traduzir perguntas em linguagem natural (NL) para SQL, sua aplicação no domínio da saúde enfrenta desafios significativos:

• Variabilidade e Ruído: Terminologia médica, jargão, abreviações e erros de digitação nas perguntas dos usuários dificultam a recuperação precisa de exemplos.
• Limitações do RAG Padrão: Estratégias de RAG convencionais dependem de uma recuperação em etapa única de um pool estático de exemplos. Isso frequentemente falha em alinhar simultaneamente a estrutura lógica da consulta e os entidades específicas (ex: nomes de drogas, diagnósticos) referenciados na pergunta.
• Escalabilidade e Ruído: Tentativas de melhorar a cobertura expandindo o pool de exemplos introduzem ruído, redundância e sobrecarga computacional, limitando a generalização.

2. Metodologia: CBR-to-SQL

Os autores propõem o CBR-to-SQL, um framework inspirado no Raciocínio Baseado em Casos (CBR). A abordagem fundamentaliza o problema de Text-to-SQL como um ciclo de CBR, decompondo a recuperação em duas fases distintas para otimizar subproblemas específicos.

A arquitetura consiste em três módulos principais:

• A. Retenção de Casos (Offline - Case Retain):

  • Transforma pares estáticos de (Pergunta-SQL) em modelos de casos abstratos (case templates).
  • Utiliza um processo de máscara de entidades: um LLM identifica e substitui entidades específicas (ex: "diabetes", "metformina") por tags de categorias semânticas gerais (ex: DIAGNOSIS, DRUG).
  • Isso remove o ruído de detalhes específicos do esquema, expondo o padrão subjacente do problema (estrutura lógica). Os modelos mascarados são indexados em um banco de dados vetorial.

• B. Construção de Modelo (Online - Template Construction):

  • Para uma nova pergunta, aplica-se a mesma máscara para recuperar os $k$ casos mais semelhantes com base na similaridade estrutural.
  • Um LLM gera um modelo SQL provisório (draft) baseado nos casos recuperados.
  • O modelo SQL contém tokens de preenchimento (placeholders) para as entidades mascaradas (ex: [ELEMENT] @TAG), indicando onde os valores específicos devem ser inseridos, mas sem tentar adivinhar os valores errados prematuramente.

• C. Descoberta de Fonte (Online - Source Discovery):

  • Esta etapa resolve os placeholders preenchendo-os com entidades reais do esquema do banco de dados (EHR).
  • Constrói uma tabela de consulta (lookup table) com valores únicos do banco de dados e suas localizações no esquema.
  • Realiza uma recuperação de entidades em duas etapas:
    1. Busca Semântica: Usa um modelo de embedding médico para encontrar candidatos semanticamente relacionados (capturando sinônimos e paráfrases).
    2. Reclassificação (Re-ranking): Refina a precisão usando a distância de Levenshtein para corrigir erros de digitação ou variações sintáticas.
  • Um agente LLM, com contexto da pergunta original e dos candidatos, seleciona a entidade correta e preenche o modelo SQL final.

3. Principais Contribuições

1. Formulação CBR para Saúde: Propõe uma nova formulação que utiliza modelos de casos mascarados em vez de exemplos estáticos de perguntas-SQL, melhorando a generalização e a escalabilidade ao focar na estrutura lógica subjacente.
2. Decomposição da Recuperação: Apresenta um framework que separa a recuperação da estrutura lógica da recuperação de entidades. Isso permite otimizar cada etapa independentemente, aumentando a eficiência de amostras, a interpretabilidade e a robustez.
3. Novo Setup de Avaliação: Introduz configurações de avaliação mais desafiadoras, incluindo um ambiente de Banco de Dados Incompleto (IDB) para testar a robustez sob escassez de dados e uma métrica de Fragilidade (Brittleness) para quantificar a sensibilidade do modelo à remoção dos casos recuperados mais bem classificados.

4. Resultados Experimentais

Os experimentos foram conduzidos no dataset MIMICSQL (baseado no banco de dados EHR MIMIC-III), comparando o CBR-to-SQL com abordagens de RAG padrão, modelos de fine-tuning (como MedTS, GE-SQL) e métodos neurais tradicionais.

• Ambiente de Banco de Dados Completo (CDB):

  • O CBR-to-SQL atingiu o estado da arte (SOTA) em Precisão da Forma Lógica (AccLF) (0.828 vs 0.811 do RAG padrão).
  • Alcançou alta precisão de execução (AccEX) de 0.882, superando o RAG padrão e competindo com modelos de fine-tuning mais complexos.
  • Demonstrou ser menos frágil: sofreu uma queda menor de desempenho quando os casos recuperados de topo foram removidos aleatoriamente, indicando melhor generalização.

• Ambiente de Banco de Dados Incompleto (IDB) - Escassez de Dados:

  • Neste cenário crítico, onde há poucos exemplos estruturalmente únicos, a vantagem do CBR-to-SQL foi ainda mais pronunciada.
  • A diferença de desempenho entre CBR-to-SQL e RAG padrão quase dobrou em comparação ao ambiente CDB.
  • O CBR-to-SQL manteve uma robustez superior, provando que sua abordagem baseada em padrões abstratos funciona melhor com dados limitados do que a recuperação direta de exemplos estáticos.

• Análise de Componentes (Ablation Studies):

  • Remover a etapa de "Descoberta de Fonte" causou uma queda drástica de desempenho, confirmando que a separação entre estrutura e entidades é crucial.
  • Substituir a "Construção de Modelo" por RAG padrão (sem máscara) resultou em desempenho inferior, validando a importância de focar em padrões estruturais abstratos.

5. Significado e Implicações

• Eficiência de Amostra: O CBR-to-SQL demonstra que é possível obter alta precisão em domínios especializados com menos dados de treinamento, uma vantagem crítica em saúde onde dados anotados são escassos.
• Interpretabilidade e Depuração: A arquitetura de múltiplas etapas torna o processo de raciocínio transparente. Diferente do RAG de "caixa preta", é possível identificar se o erro ocorreu na recuperação da estrutura lógica ou na resolução da entidade, facilitando a depuração em ambientes de alto risco.
• Custo Computacional vs. Benefício: Embora o CBR-to-SQL tenha um custo computacional ligeiramente maior (mais tokens e latência) devido às etapas adicionais, o artigo argumenta que o ganho em precisão e robustez justifica esse custo em cenários clínicos, onde a correção é prioritária.
• Futuro: O trabalho sugere que princípios de CBR devem ser adotados mais amplamente para mover o campo de Text-to-SQL de abordagens genéricas de RAG para arquiteturas modulares, transparentes e centradas em dados.

Em resumo, o CBR-to-SQL oferece uma solução robusta e escalável para a tradução de linguagem natural para SQL em saúde, superando as limitações do RAG tradicional ao tratar a recuperação de estrutura e entidades como problemas distintos e complementares.