O modelo rápido escreve o código, o inteligente conserta a lógica: como montar uma busca com n8n e PostgreSQL

Escreve-se muito sobre os modelos de ponta, mas quase nada sobre como dividir os papéis entre um modelo rápido e um «pensante» numa tarefa real. O autor desta análise pegou um projeto de trabalho e testou a abordagem na prática.

A tarefa e por que não há LLM em tempo de execução

Precisava-se de uma busca em um catálogo de peças artesanais de pedras. Em uma página fechada do Tilda, o especialista marca áreas (amor, dinheiro, saúde e assim por diante) e escolhe um design: feminino, masculino ou unissex. Em resposta, recebe até cinco cartões de uma tabela do PostgreSQL com 1684 registros.

O autor rejeitou a tentação de colocar entre o formulário e o banco de dados um modelo que «entende a consulta» por três motivos. O primeiro é a latência: para buscar em 1684 linhas, uma chamada de rede é desnecessária. O segundo, custo e variabilidade: as regras de busca podem ser escritas de forma explícita. O terceiro, a fonte da verdade: o SQL devolve apenas o que existe no catálogo, enquanto um modelo poderia acrescentar uma propriedade plausível, porém inventada. Por isso os LLMs trabalham somente na fase de desenvolvimento.

Os papéis foram estes. O Particle-1 no Cline foi as «mãos»: escrevia SQL e código para nós do n8n, corrigia aspas e nomes de campos. O GPT-6 Luna Pro foi o «cérebro»: era chamado quando o problema já não era de sintaxe, mas de diagnóstico. As execuções, a verificação da resposta HTTP e as decisões de produto o autor reservou para si.

Uma ressalva importante: isto não é um teste A/B. As sessões diferem em volume, então 0,49 USD contra 0,04 USD não podem ser comparados como o preço de resolver uma única tarefa. Os dados de latência do OpenRouter também são apenas uma referência para uma data específica.

Cinco armadilhas em ordem

1. O operador &. Para contar tags em comum, o modelo usou & para text[], que não existe no PostgreSQL. O operador && apenas responde «há interseção?», mas não conta. Solução: && no WHERE para selecionar candidatos, e as coincidências são contadas por uma subconsulta com unnest.

2. Syntax error near undefined. O nó Code entregava o campo sql_query, enquanto o nó Postgres lia outro nome. Enquanto isso, o nó Code estava verde. Conclusão: confira o OUTPUT real do nó anterior com o INPUT do seguinte, e não a bela expressão nos parâmetros.

3. O literal de array. São necessários dois níveis de aspas: duplas por dentro para os elementos, simples por fora para a string SQL. O modelo perdeu a camada externa. O autor não conseguiu parametrizar o array via $1, mas honestamente não afirma que o n8n não consiga fazer isso. Para uma nova produção, ele primeiro buscaria uma consulta parametrizada.

4. Cinco linhas no SQL, um cartão no site. Segundo a documentação, o Respond to Webhook é executado uma vez, no primeiro item. O modo All Incoming Items resolve. O diagnóstico ainda foi atrapalhado porque no topo ficava um registro unissex amplo com oito tags, e parecia que o SQL sempre devolvia a mesma coisa.

5. Design feminino: um registro em 1684. O filtro não está quebrado, os dados é que estão distorcidos: quase tudo foi parar em unissex. O autor não mexeu no algoritmo, mas fixou uma regra de produto: uma consulta feminina admite female e unisex, e em caso de empate a correspondência exata de gênero fica na frente. O modelo não podia decidir se isso era um erro de importação.

O buraco que os modelos não notaram

Na revisão final, o autor perguntou não «por que cai», mas «o que acontece se o formulário for contornado». Eram escapadas a barra invertida e a aspa dupla, mas não a simples, e o literal era envolvido justamente em aspas simples. Via curl era possível quebrar a string e alterar a consulta. A senha na página do Tilda protege apenas o HTML, não as requisições ao n8n. Uma chave de API no JS do cliente também não adiantaria nada. A correção foi feita no servidor: lista branca de valores para spheres e gender, mais escape correto dos dois níveis.

O que levar disso

A divisão «executor rápido mais diagnosticador lento» funciona se você mesmo define o momento da troca: erro de sintaxe ou de comportamento do sistema. O status verde de um nó não prova a consistência do circuito. O ranqueamento por cardinality(tags) não impede que um registro amplo vença. E uma lista vazia de áreas desativa o filtro silenciosamente, por isso, em uma API pública, é melhor devolver 400. A revisão de segurança continua sendo trabalho humano: neste caso, nenhum dos dois modelos apontou a injeção.