Agente de IA genera SQL pero deja de ejecutarse después de la segunda consulta

Preguntas
,
1

Hola a todos,

Estoy intentando crear un flujo de trabajo con el nodo de agente IA, Ollama y PostgreSQL.
Todo va bien para las dos primeras preguntas que necesitan generar una consulta SQL. Pero en la tercera pregunta que necesita datos de la base de datos, Ollama genera la consulta SQL correctamente pero se detiene y no la ejecuta en el nodo GetData.

Por favor, comparte tu flujo de trabajo

Información sobre tu configuración de n8n

  • Versión de n8n: 2.21.5
  • Base de datos (predeterminada: SQLite): SQLite
  • Configuración n8n EXECUTIONS_PROCESS (predeterminada: own, main):
  • Ejecutar n8n mediante: Docker
  • Sistema operativo: Linux
2

@flipflip, ¿puedes probar esto?

3

Hola @flipflip

Creo que la causa es tu configuración numPredict: 1024 en el nodo de Ollama. Esto limita la respuesta del modelo a 1024 tokens por turno. Después de 2 consultas, tu historial de conversación (llamadas de herramientas, resultados, estructuras de tablas) crece, y el modelo se queda sin tokens de salida antes de poder terminar de generar la llamada de herramienta.

Dos cosas que puedes probar:

  1. Aumenta numPredict a al menos 4096 en las opciones del nodo de Ollama.

  2. Reduce contextWindowLength en tu Chat Memory de Postgres de 20 a algo como 5-10. Cada mensaje incluye los resultados completos de las llamadas de herramientas, así que 20 mensajes consume rápidamente tu ventana de contexto de 16384.

Combina eso con los cambios del prompt del sistema de @kjooleng y debería pasar la 3ª consulta.

¡Cuéntanos si esto te ayuda!

4

@flipflip

mira si esto te sirve:
GitLab MCP Server.json (5,0,KB)

5

Dos cosas que vale la pena verificar: primero, revisa la configuración del nodo AI Agent y comprueba el valor de “Max Iterations” - los modelos de Ollama a veces agotan el presupuesto de iteraciones después de procesar 2 llamadas de herramientas, lo que explicaría que el agente genere el SQL pero no continúe con la llamada GetData. Aumentalo a 15-20 y prueba.

Segundo, comprueba cómo tu nodo PostgreSQL está conectado como herramienta. Si está usando la operación “Execute Query” y el SQL se pasa a través de una expresión como {{ $fromAI('query') }}, asegúrate de que el nombre del campo en fromAI coincida exactamente con lo que el agente está generando. Una discrepancia allí causa que la herramienta se ejecute pero no devuelva nada, y Ollama se detiene silenciosamente en lugar de reintentar.

6

El culpable más probable aquí es que qwen3:14b no genera de manera confiable una llamada de herramienta adecuada después de generar el SQL. El nodo del Agente IA espera a que el LLM devuelva una llamada de herramienta estructurada — si el modelo simplemente escribe el SQL como texto plano y se detiene, el agente nunca activa el nodo getData. No ve ninguna llamada de herramienta, considera la tarea completada y devuelve una respuesta vacía.

Algunas cosas que puedes intentar, en orden:

  1. Habilita pasos intermedios temporalmente. En el nodo del Agente, activa «Devolver Pasos Intermedios». Vuelve a ejecutar la misma tercera pregunta. Verás exactamente qué hizo el agente — si llamó a getData y con qué consulta, o si simplemente se detuvo después de generar texto SQL. Eso te dice inmediatamente dónde está la desconexión.
  2. Verifica tu indicación de sistema. Si es solo un marcador de posición «Mi indicación», el agente no sabe que debe usar la herramienta getData para cada solicitud de datos. Añade algo explícito:
    «Siempre que el usuario haga una pregunta que requiera datos de la base de datos, debes llamar a la herramienta «getData» con la consulta SQL apropiada. No generes SQL directamente; siempre usa la herramienta».
  3. Prueba un modelo con capacidad de llamada de funciones. qwen3:14b puede no tener soporte nativo de llamada de funciones en Ollama, así que el agente recurre a un analizador basado en texto que es frágil. Cambia a llama3.1:8b-instruct o mistral:7b-instruct (ambos confirmados para funcionar con llamadas de herramientas a través de Ollama) y prueba si se ejecuta la tercera consulta. Si lo hace, el modelo era el problema.
  4. Aumenta numPredict o elimina el límite. Tu numPredict es 1024 tokens. Si la consulta SQL más la sintaxis de llamada de herramienta exceden eso, el modelo podría cortarse antes de emitir la } final que señala una llamada de herramienta. Establece numPredict a -1 (ilimitado) o auméntalo a 4096.
  5. Verifica el consumo de memoria de Postgres. Aunque es poco probable que cause una detención abrupta exactamente en la segunda consulta, una ventana de memoria larga puede saturar el contexto y confundir al modelo. Establece temporalmente contextWindowLength a 5 y prueba. Si la tercera consulta funciona entonces, puedes ajustarlo de nuevo hacia arriba.

Comienza con #1 y #3 — esos son los más rápidos de descartar. Si ves en los pasos intermedios que el agente nunca llama a la herramienta, es un problema de salida del modelo. Cuéntanos qué encuentres.

7

Hola a todos,

con las sugerencias de @kjooleng y @houda_ben, logré solucionar el problema. Por ahora, no he vuelto a encontrar el problema a pesar de 10 preguntas que requieren una mezcla de consultas de memoria y base de datos. Por supuesto, enriquecí significativamente el prompt base para integrar mis restricciones y requisitos.

Gracias a todos por su ayuda.