Construindo Agents com Tools Parametrizadas
Por que LLMs não devem gerar SQL
Eu sei! A tentação é grande! Você tem uma base de dados relacional gigante, um LLM, e a ideia surge naturalmente "por que não deixar o modelo gerar consultas SQL dinamicamente?" Afinal, esses modelos demonstram competência em várias linguagens de programação, e SQL não deveria ser exceção. Essa abordagem sedutora, revela-se problemática quando aplicada em ambientes de produção, especialmente quando se trata de agents que precisam operar de forma confiável.
O problema principal não está na capacidade técnica dos LLMs de escrever SQL, mas na natureza imprevisível e contextual dessa geração. Quando construímos sistemas que dependem de consistência operacional, a variabilidade no output dos LLMs torna-se um obstáculo. Um mesmo input pode gerar consultas estruturalmente diferentes, com variações sutis que comprometem a confiabilidade da aplicação.
Geração dinâmica de SQL
Considere um cenário relativamente simples, analisar dados financeiros de empresas públicas. Um usuário solicita "mostre a evolução da receita da NVIDIA nos últimos anos". Um LLM, encarregado de gerar SQL para esta consulta, pode produzir variações como:
Aqui, cada variação é válida, mas produz resultados potencialmente diferentes. A primeira busca pelo símbolo exato, a segunda pela razão social, e a terceira falha por usar o símbolo em minúsculas. Essa inconsistência se torna exponencialmente problemática em produção onde a precisão é o fator crucial.
Além da inconsistência, existe o risco de segurança. LLMs podem gerar consultas que expõem dados sensíveis ou, em cenários mais graves, incluir elementos que comprometem a integridade da base de dados. A sanitização de SQL gerado dinamicamente é complexa e propensa a falhas, especialmente quando lidamos com consultas mais elaboradas.
Tools parametrizadas como contratos
A solução surge de um princípio fundamental de engenharia de software, separação de responsabilidades. Em vez de transformar o LLM em um programador SQL, devemos tratá-lo como um intérprete inteligente de intenções, capaz de mapear linguagem natural para chamadas de funções estruturadas.
Essa abordagem funciona através de tools parametrizadas, funções pré-definidas que encapsulam a lógica de acesso a dados de forma segura e consistente. Vamos ao exemplo:
Esta função representa um contrato bem definido entre o agent e a base de dados. A consulta SQL está fixa e otimizada, os parâmetros são validados e sanitizados automaticamente pelo driver da base de dados, e o comportamento é totalmente previsível. Aqui o LLM concentra-se em sua competência principal, que é entender a intenção do usuário e mapear essa intenção para os parâmetros apropriados.
O mapeamento de linguagem natural para parâmetros estruturados é onde reside a verdadeira elegância desta abordagem. Quando um usuário solicita "dados de receita da NVIDIA dos últimos trimestres", o LLM deve interpretar que symbol="NVDA", report_type="income" e period_type="quarterly". Esta transformação parece trivial, mas envolve conhecimento contextual para reconhecer que "NVIDIA" mapeia para o símbolo "NVDA", que "receita" corresponde a dados de income statement, e que "trimestres" indica periodicidade quarterly.
Este processo de mapeamento pode ser mega sutil. Considere as variações: "faturamento trimestral da Nvidia Corporation", "revenue da NVDA Q1-Q4", ou "earnings trimestrais da empresa de chips gráficos". Cada formulação exige que o LLM extraia os mesmos três parâmetros fundamentais, e isso demonstra sua capacidade de normalizar linguagem natural variada em chamadas de função consistentes.
A definição cuidadosa dos parâmetros da tool também orienta essa interpretação. O parâmetro report_type com enum ["income", "balance", "cash_flow"] força o LLM a categorizar corretamente diferentes tipos de demonstrações financeiras.
A robustez surge da previsibilidade. Independentemente de como o usuário formule a pergunta, "mostre receita da NVIDIA", "como está faturamento NVDA", ou "dados financeiros trimestrais da Nvidia Corporation", o resultado sempre será uma chamada consistente para get_financial_data("NVDA", "income", "quarterly"). O SQL subjacente permanece inalterado, testado e otimizado.
Indo além com tools compostas
A verdadeira potência desta abordagem aparece quando combinamos múltiplas tools em workflows coordenados. Nossa próxima função exemplifica este conceito, utilizando diretamente a função get_financial_data para gerar visualizações completas. Aqui observamos um padrão fundamental, tools que consomem outras tools, criando uma hierarquia de funcionalidades onde cada nível adiciona valor específico ao anterior.
Observe a arquitetura, plot_revenue_evolution é uma tool composta que internamente invoca get_financial_data. Esta composição cria uma hierarquia onde tools de baixo nível (acesso a dados) são combinadas em tools de alto nível (visualização completa). Para o LLM, ambas aparecem como tools disponíveis, mas com propósitos distintos. Quando o usuário quer "dados brutos da NVIDIA", o modelo invoca get_financial_data. Quando solicita "gráfico de evolução da NVIDIA", escolhe plot_revenue_evolution.
A separação entre obtenção de dados, processamento e visualização permite reutilização e manutenção bem superiores. Cada função tem uma responsabilidade específica e bem definida. Mais importante, o SQL continua encapsulado e imutável - seja chamado diretamente via get_financial_data ou indiretamente via plot_revenue_evolution, a consulta permanece a mesma. Se pensar em outras tools que consomem dados de um vector database para gerar um relatório textual complementar, vai seguir a mesma lógica.
Já para análises comparativas, podemos implementar tools mais especializadas:
Implementando Agents com tools parametrizadas
A Anthropic, em sua análise sobre construção de agents eficazes, destaca a importância de patterns bem estabelecidos. O routing pattern é particularmente relevante para esse exemplo, permitindo que diferentes tipos de consultas sejam direcionadas para tools especializadas.
Um agent financeiro bem estruturado poderia implementar este pattern de forma transparente:
O poder desta abordagem reside na autonomia do LLM para escolher e parametrizar as tools apropriadas. Quando um usuário solicita "mostre como a NVIDIA cresceu nos últimos anos", o modelo interpreta a intenção, identifica que precisa de visualização temporal, e invoca plot_revenue_evolution com os parâmetros corretos: {"symbol": "NVDA", "period_type": "annual"}.
Agent-Computer Interface (ACI)
A qualidade da interface entre agent e sistema (Agent-Computer Interface, ou ACI) determina fundamentalmente a eficácia do sistema completo. Tools mal projetadas resultam em agents confusos e inconsistentes, enquanto interfaces bem estruturadas permitem operação fluida e previsível.
Nesse exemplo, uma ACI eficaz para dados financeiros deve considerar aspectos como nomenclatura consistente de parâmetros, validação robusta de inputs, e retornos estruturados que o LLM possa interpretar facilmente. A documentação de cada tool deve ser clara o suficiente para que o modelo entenda exatamente quando e como utilizá-la.
Conclusão
A construção de agents que funcionam não requer sofisticação, mas sim design cuidadoso e separação clara de responsabilidades. Permitir que LLMs gerem SQL dinamicamente introduz variabilidade e riscos desnecessários em sistemas que devem operar de forma confiável e segura.
A abordagem de tools parametrizadas, embora exija mais trabalho inicial na definição e estruturação das funções, oferece uma alternativa bem superior, onde cada componente opera dentro de sua competência principal. O LLM se destaca em interpretação de linguagem natural e tomada de decisões contextuais, enquanto funções especializadas garantem acesso seguro e consistente aos dados. Esta separação não apenas melhora os resultados, mas também facilita manutenção, testes e evolução da aplicação.
No fim, esta abordagem representa não apenas uma escolha técnica superior, mas uma vantagem estratégica fundamental. Principalmente em ambientes de produção onde a consistência é crucial.