El modelo rápido escribe el código, el inteligente arregla la lógica: cómo montar una búsqueda con n8n y PostgreSQL

Se escribe mucho sobre los modelos de primer nivel, pero casi nada sobre cómo repartir los roles entre un modelo rápido y uno «pensante» en una tarea real. El autor de este análisis tomó un proyecto de trabajo y probó el enfoque en la práctica.

La tarea y por qué no hay LLM en tiempo de ejecución

Hacía falta una búsqueda sobre un catálogo de piezas artesanales de piedras. En una página privada de Tilda, el especialista marca ámbitos (amor, dinero, salud, etc.) y elige un diseño: femenino, masculino o unisex. Como respuesta recibe hasta cinco tarjetas de una tabla de PostgreSQL con 1684 registros.

El autor rechazó la tentación de poner entre el formulario y la base de datos un modelo que «entienda la consulta» por tres razones. La primera es la latencia: para buscar entre 1684 filas no hace falta una llamada de red. La segunda, el coste y la variabilidad: las reglas de búsqueda se pueden escribir de forma explícita. La tercera, la fuente de verdad: SQL devuelve solo lo que hay en el catálogo, mientras que un modelo podría añadir una propiedad verosímil pero inventada. Por eso los LLM trabajan solo durante el desarrollo.

Los roles fueron estos. Particle-1 en Cline fue las «manos»: escribía SQL y código para nodos de n8n, y arreglaba comillas y nombres de campos. GPT-6 Luna Pro fue el «cerebro»: se le llamaba cuando el problema ya no era de sintaxis sino de diagnóstico. Las ejecuciones, la comprobación de la respuesta HTTP y las decisiones de producto las reservó el autor para sí.

Una salvedad importante: esto no es un test A/B. Las sesiones difieren en volumen, así que 0,49 USD frente a 0,04 USD no pueden compararse como el precio de resolver una sola tarea. Los datos de latencia de OpenRouter tampoco son más que una referencia para una fecha concreta.

Cinco trampas por orden

1. El operador &. Para contar etiquetas comunes, el modelo usó & para text[], que no existe en PostgreSQL. El operador && solo responde «¿hay intersección?», pero no cuenta. Solución: && en WHERE para seleccionar candidatos, y las coincidencias las cuenta una subconsulta con unnest.

2. Syntax error near undefined. El nodo Code devolvía el campo sql_query, mientras que el nodo Postgres leía otro nombre. Y el nodo Code se veía en verde. Conclusión: contrasta el OUTPUT real del nodo anterior con el INPUT del siguiente, no la bonita expresión de los parámetros.

3. El literal de array. Hacen falta dos niveles de comillas: dobles dentro para los elementos, simples fuera para la cadena SQL. El modelo perdió la capa exterior. Al autor no le salió parametrizar el array con $1, pero no afirma con honestidad que n8n no pueda hacerlo. En una producción nueva, primero conseguiría una consulta parametrizada.

4. Cinco filas en SQL, una tarjeta en el sitio. Según la documentación, Respond to Webhook se ejecuta una sola vez, sobre el primer item. Ayuda el modo All Incoming Items. El diagnóstico se complicó además porque arriba quedaba un registro unisex amplio con ocho etiquetas, y parecía que SQL devolvía siempre lo mismo.

5. Diseño femenino: un registro de 1684. El filtro no está roto, los datos están sesgados: casi todo cayó en unisex. El autor no tocó el algoritmo, sino que fijó una regla de producto: una consulta femenina admite female y unisex, y en caso de empate la coincidencia exacta de género va primero. El modelo no podía decidir si se trataba de un error de importación.

El agujero que los modelos no vieron

En la revisión final, el autor no preguntó «por qué falla», sino «qué pasa si se salta el formulario». Se escapaban la barra invertida y la comilla doble, pero no la simple, y el literal estaba envuelto precisamente en comillas simples. Con curl se podía romper la cadena y alterar la consulta. La contraseña de la página de Tilda protege solo el HTML, no las peticiones a n8n. Una clave de API en el JS del cliente tampoco habría servido de nada. Se corrigió en el servidor: lista blanca de valores para spheres y gender, más un escapado correcto de ambos niveles.

Qué llevarse de todo esto

La división «ejecutor rápido más diagnosticador lento» funciona si eres tú quien determina el momento del cambio: un error de sintaxis o de comportamiento del sistema. El estado verde de un nodo no demuestra que el circuito sea coherente. Ordenar por cardinality(tags) no impide que gane un registro amplio. Y una lista de ámbitos vacía desactiva el filtro en silencio, por lo que en una API pública es mejor devolver 400. La revisión de seguridad sigue siendo trabajo humano: en este caso, ninguno de los dos modelos señaló la inyección.