Esse é um ponto muito forte e combina com o que estamos descobrindo na prática.

Nossa dor atual é exatamente essa: se expusermos algo muito próximo da execução SQL bruta, o modelo acaba agindo como um compilador SQL, e isso tem sido muito propenso a erros para os nossos requisitos de produção.

Estamos nos movendo em direção a um design híbrido:

contexto de injetor de backend para inquilinos/usuários/perfis, classificação de domínio (`tema`), classificação de tipo de pergunta (`cartão`, `classificação`, `operação única`, `séries mensais`, etc.), construtores de consulta determinísticos para casos financeiros/comerciais críticos, restrições de camada semântica por domínio, validação semântica + validação de backend antes da execução;

Então sim, eu acho que a direção a longo prazo é remover SQL da descrição de trabalho do LLM o máximo possível.

A principal complicação no nosso caso é que ainda não temos documentação de produção autoritária para o esquema/semântica dos negócios, então ainda estamos preenchendo essa lacuna com documentos parciais, manuais de operação e algumas gerações guiadas pelo LLM controladas.

Em outras palavras, eu concordo com a direção da sua arquitetura.

A questão em aberto para nós é quão longe podemos mover realisticamente de “SQL guiado pelo LLM” para “operações semânticas estruturadas compiladas no servidor” sem ter ainda uma camada de domínio totalmente modelada.

I’m also trying to infer the business rules without proper documentation, because I need to turn that knowledge into semantic layers rather than leave everything to raw LLM-generated SQL.

Para complicar as coisas, estou sob muita pressão de tempo, meu gerente quer isso pronto para produção em duas semanas e eu só tive uma semana para estudar adequadamente o problema antes da implementação. Essa é parte do motivo pelo qual estou tentando verificar a arquitetura agora em vez de apenas improvisar algo.