Quality-Driven Agentic Reasoning for LLM-Assisted Software Design: Questions-of-Thoughts (QoT) as a Time-Series Self-QA Chain

O artigo apresenta o Questions-of-Thoughts (QoT), um método de raciocínio agênico que transforma objetivos de usuário em sequências de etapas de engenharia com autoquestionamento para verificar restrições, demonstrando melhorias consistentes na qualidade de designs de software assistidos por LLMs em domínios como APIs, comunicação de dados e sistemas de arquivos, especialmente em modelos maiores e tarefas complexas.

O essencial

Imagine que você pediu a um assistente de IA muito inteligente que ele escreva o código para um novo aplicativo de reservas de hotéis. O problema é que, embora a IA seja ótima em escrever frases e trechos de código, ela às vezes "alucina" ou esquece detalhes importantes, como segurança, organização ou o que acontece quando algo dá errado. O resultado? Um código que funciona no teste, mas que desmorona no mundo real.

Este artigo apresenta uma solução chamada QoT (Questions-of-Thoughts), ou "Perguntas do Pensamento". Para explicar de forma simples, vamos usar uma analogia:

A Analogia do Arquiteto vs. O Aluno Apressado

Imagine que você precisa construir uma casa.

• O Modelo de IA comum (sem QoT) é como um aluno muito rápido, mas apressado. Ele pega o pedido, corre para a prancheta e começa a desenhar a casa inteira de uma vez só. Ele pode desenhar um telhado bonito, mas esquece de colocar janelas, não calcula se a fundação aguenta o peso e, pior, não verifica se o projeto tem segurança contra incêndio. Ele entrega o desenho e diz: "Pronto!".
• O Modelo com QoT é como um Arquiteto Sênior e Metódico. Antes de desenhar qualquer linha, ele para e faz uma série de perguntas para si mesmo, passo a passo:
  1. "Espere, qual é o objetivo exato?"
  2. "Preciso de um sistema de login? Como vamos proteger as senhas?"
  3. "Se o servidor cair, o que acontece com os dados dos hóspedes?"
  4. "Essa parte do código conversa bem com aquela outra?"

O QoT força a IA a agir como esse Arquiteto. Em vez de apenas "escrever código", ela conversa consigo mesma antes e durante o processo, verificando cada detalhe, como se estivesse preenchendo um checklist de qualidade.

Como Funciona na Prática?

O sistema funciona em três etapas principais, como se fosse uma linha de montagem inteligente:

1. O Plano (A Lista de Passos): A IA não pula direto para a ação. Ela primeiro quebra o grande problema (ex: "criar um sistema de reservas") em pequenos passos lógicos (ex: "criar usuários", "criar quartos", "fazer a reserva", "enviar e-mail").
2. O Interrogatório (A Cadeia de Perguntas): Para cada um desses passos, a IA gera perguntas para si mesma.
   • Passo: "Criar sistema de login".
   • Pergunta da IA: "E se o usuário digitar uma senha fraca? E se alguém tentar invadir? Onde guardamos os dados?"
   • Resposta: "Vamos adicionar criptografia e validação de força."
     Isso garante que nada seja esquecido.
3. O Caderno de Notas (A Memória): A IA mantém um "caderno" onde anota todas essas decisões e descobertas. Quando ela vai para o próximo passo, ela olha no caderno para garantir que o que está fazendo agora não quebra o que foi feito antes.

O Que Eles Descobriram?

Os autores testaram essa ideia em três áreas difíceis: design de APIs (como sistemas conversam), comunicação de dados e sistemas de arquivos.

• Resultados: O método QoT fez os códigos gerados serem muito mais organizados, seguros e completos.
• O Surpresa: Modelos de IA menores (que normalmente são menos inteligentes) conseguiram fazer um trabalho quase tão bom quanto os modelos gigantes quando usaram o método QoT. É como se o "aluno apressado" tivesse aprendido a usar uma "lista de verificação" e, de repente, parou de cometer erros bobos.
• O Custo: A única desvantagem é que demora um pouco mais. Como a IA precisa "pensar" e fazer perguntas antes de responder, o processo é mais lento do que a resposta automática. Mas, para coisas importantes (como bancos ou hospitais), vale a pena ter um código seguro em vez de um código rápido e cheio de falhas.

Resumo em Uma Frase

O QoT é como ensinar a Inteligência Artificial a não ter pressa: em vez de apenas "adivinhar" a resposta, ela para, faz perguntas críticas para si mesma, verifica se está tudo seguro e organizado, e só então entrega o trabalho final. Isso transforma códigos quebrados em sistemas robustos e confiáveis.

Resumo técnico

Resumo Técnico: Questions-of-Thoughts (QoT)

1. O Problema

O avanço dos Grandes Modelos de Linguagem (LLMs) acelerou o desenvolvimento de software assistido por IA, transformando-os de meros assistentes de "autocompletar" em sistemas agentes capazes de fluxos de trabalho end-to-end. No entanto, a implantação prática enfrenta três barreiras críticas:

• Correção não confiável: Falhas em tarefas de longo horizonte e sob mudanças de distribuição.
• Falta de transparência: Dificuldade em fornecer evidências de por que uma solução deve ser confiável (auditabilidade).
• Avaliação instável: Benchmarks existentes focam excessivamente na correção funcional (passagem de testes simples), negligenciando atributos de qualidade de software essenciais para produção, como escalabilidade, modularidade, manutenibilidade e segurança.

O artigo identifica que os pipelines de agentes atuais otimizam taxas de aprovação sem modelar explicitamente atributos de qualidade de software, resultando em sistemas frágeis, com tratamento de erros insuficiente e vulnerabilidades de segurança.

2. Metodologia: Questions-of-Thoughts (QoT)

Os autores propõem o QoT (Questions-of-Thoughts), um scaffold de raciocínio orientado à qualidade que opera no tempo de inferência (sem re-treinamento do modelo). O QoT transforma um objetivo do usuário em uma cadeia temporal de auto-questionamento (Self-QA) estruturada.

A arquitetura do QoT consiste em três componentes principais:

1. Cadeia de Processos Sequenciais (Sequential Process Chain):

   • Decompõe um problema de alto nível em uma sequência ordenada de etapas de engenharia ($S_1, S_2, ..., S_n$).
   • Garante que o raciocínio siga uma progressão lógica, evitando redundâncias e omissões, focando na definição do problema e dependências entre módulos.

2. Cadeia de Perguntas e Respostas (Question-Answer Chain):

   • Para cada etapa $S_i$, o modelo gera um conjunto de perguntas internas ($Q_{i,j}$) baseadas no método socrático.
   • Essas perguntas visam esclarecer restrições, expandir detalhes e verificar informações antes da geração do código.
   • O objetivo é identificar precocemente restrições de design e potenciais omissões, estabilizando as decisões subsequentes.

3. Base de Conhecimento de Raciocínio (Reasoning Knowledge Base):

   • Atua como memória e módulo de decisão, acumulando insights intermediários e rastreando dependências.
   • Mantém dois componentes: o Processo de Pensamento (TP) (armazenamento dinâmico de passos de raciocínio) e a Resposta (R) (solução progressivamente atualizada).
   • Isso permite que o agente refine sua saída com base em um estado de conhecimento evolutivo.

Algoritmo: O fluxo segue: Geração de Etapas $\rightarrow$ Geração de Perguntas por Etapa $\rightarrow$ Resposta às Perguntas $\rightarrow$ Acumulação no TP $\rightarrow$ Atualização da Resposta Final. Se ocorrerem erros em qualquer etapa, o sistema retorna uma mensagem estruturada de erro, permitindo estratégias de retry.

3. Contribuições Principais

• Protocolo de Raciocínio Agente Estruturado: Introdução do QoT, que acopla planejamento sequencial com auto-verificação (Self-QA) passo a passo e rastreamento de restrições.
• Benchmark de Domínios Práticos: Avaliação em três domínios de engenharia de backend: Design de API, Comunicação de Dados e Sistemas de Arquivos. Cada tarefa exige decomposição multi-módulo e lida com preocupações reais (validação, controle de acesso, tratamento de falhas).
• Rubrica de Avaliação Orientada a Dados: Uso de uma métrica baseada nas normas ISO/IEC 9126 e 25010 para avaliar quatro dimensões: Escalabilidade, Completude, Modularidade e Segurança. A avaliação é feita via "LLM-as-a-Judge" (usando o Gemini 3.1 Pro) com contexto sobreposto para garantir consistência.
• Artefato Aberto: Disponibilização de prompts, diretrizes de pontuação, gerações brutas e scripts para reprodução dos resultados.

4. Resultados Experimentais

Os experimentos foram conduzidos em vários modelos (Llama 3.1, 3.2, 3.3 em tamanhos de 3B, 8B e 70B) comparando QoT contra baselines sem QoT (NoQoT) e contra Chain-of-Thought (CoT).

• Melhoria Geral de Qualidade: O QoT demonstrou melhorias consistentes na pontuação total de qualidade, especialmente em modularidade, validação de entrada e controles de segurança.
• Dependência da Capacidade do Modelo:
  • Modelos Grandes (ex: Llama 70B): Apresentaram ganhos significativos (ex: +5.8 em Design de API e +6.6 em Comunicação de Dados comparado ao CoT).
  • Modelos Pequenos (ex: Llama 3B/8B): Também mostraram melhorias, embora moderadas. O QoT ajudou modelos menores a reduzir a dependência de modelos massivos, embora a variância seja maior, sugerindo que a qualidade das perguntas intermediárias pode ser um gargalo em modelos com capacidade de raciocínio limitada.
• Trade-offs e Riscos:
  • Em alguns cenários complexos (especificamente no domínio de Sistemas de Arquivos para modelos grandes), observou-se uma degradação de desempenho (pontuação negativa). Os autores atribuem isso ao risco de "super-pensamento" (over-thinking) ou "super-engenharia", onde o excesso de etapas de raciocínio introduz complexidade desnecessária ou erros de planejamento.
• Eficiência: O QoT permite que modelos menores alcancem níveis de qualidade próximos aos de modelos maiores em configurações de geração única, demonstrando que o processo de raciocínio estruturado compensa parcialmente a falta de parâmetros.

5. Significado e Impacto

• Mudança de Paradigma: O QoT desloca o foco da geração de código "funcional" para a geração de sistemas "confiáveis e auditáveis". Ele transforma a síntese de código de uma tarefa de passagem única em um processo rastreável onde as restrições de design são explicitadas.
• Aplicabilidade em Engenharia Real: Ao incorporar verificações de confiança inspiradas em sistemas RAG (Retrieval-Augmented Generation) e padrões de qualidade ISO, o QoT atende às necessidades de pipelines de IA aplicada que exigem conformidade, auditoria e manutenção a longo prazo.
• Custo vs. Benefício: Embora o QoT introduza uma sobrecarga computacional (complexidade $O(S \times Q \times T)$), o custo é justificado em cenários de alta criticidade (backend, integração, componentes sensíveis à conformidade), onde a redução de erros de design e a diminuição do esforço de depuração superam a latência adicional.
• Futuro: O trabalho sugere a integração futura do QoT com pipelines de verificação automatizada (análise estática, síntese de testes) para criar agentes de engenharia de software verdadeiramente confiáveis e governáveis.

Em suma, o artigo demonstra que raciocínio estruturado e auto-questionamento orientado a critérios de qualidade são fundamentais para superar as limitações atuais dos LLMs na geração de software de nível empresarial, oferecendo um caminho viável para sistemas de IA mais robustos e seguros.