What makes prompts a graph: necessary and sufficient conditions for prompt graph engineering
Este artigo propõe uma definição constitutiva e um arcabouço operacional para a "engenharia de grafos de prompts" para caracterizar formalmente os sistemas de prompts modernos como grafos explícitos e executáveis, estabelecendo, assim, condições necessárias, um vocabulário compartilhado e uma agenda de pesquisa para uma prática atualmente onipresente na indústria, mas que carece de uma definição teórica precisa.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que você está tentando ensinar um robô superinteligente a resolver um mistério. No começo, você apenas escreveu uma única carta gigante e perfeita para o robô, esperando que ele descobrisse tudo a partir dessa única mensagem. Esse era o jeito antigo: um comando, uma resposta. Mas conforme os robôs ficavam mais espertos e os mistérios mais difíceis, aquela única carta não era mais suficiente. Os engenheiros perceberam que precisavam decompor o problema. Eles começaram a fazer o robô escrever um plano, depois verificar seu trabalho, depois pedir ajuda a um especialista e, finalmente, votar na melhor resposta. De repente, o "comando" não era mais apenas uma carta; era uma equipe inteira de robôs trabalhando juntos em uma ordem específica.
É aqui que as coisas ficam complicadas. Quando você tem uma equipe de robôs passando bilhetes, você precisa de um mapa para mostrar quem fala com quem, quem espera por quem e quem toma a decisão final. No mundo da ciência da computação, esse mapa é chamado de grafo. Pense em um grafo como um mapa de metrô: as estações são as etapas (como "ler a pista" ou "chamar o especialista") e os trilhos são as instruções dizendo ao robô para onde ir a seguir. Alguns trilhos voltam em loop se um erro for cometido; outros se dividem em dois camos ao mesmo tempo. A grande questão que cientistas e engenheiros enfrentam agora é: quando uma coleção bagunçada de instruções de robôs se torna um "grafo" real e oficial que podemos estudar, consertar e melhorar? Se não conseguirmos concordar sobre o que um grafo realmente é, não poderemos construir ferramentas melhores para gerenciar essas equipes de robôs.
Este artigo, escrito por Sandeco Macedo, é como um detetive tentando desenhar a linha de fronteira oficial para este novo campo. O autor argumenta que temos usado a palavra "grafo" de forma muito imprecisa. Às vezes, as pessoas o utilizam para descrever como um robô pensa dentro de sua própria cabeça, e às vezes o utilizam para descrever um mapa que um engenheiro desenhou para controlar o robô. O artigo sugere que, para algo contar como "Engenharia de Grafo de Prompt", deve ser um tipo específico de mapa projetado, não apenas uma conversa ou um processo de pensamento aleatório.
O autor propõe um teste rigoroso de quatro partes para decidir se um sistema é um verdadeiro "grafo de prompt". Primeiro, o mapa deve ser explícito: você deve conseguir ver as estações e os trilhos no papel (ou no código) antes mesmo de o robô começar a rodar. Segundo, o mapo deve ser separado das notas: você deve ser capaz de alterar as instruções nos trilhos (a estrutura) sem ter que reescrever as cartas que o robô lê (o conteúdo), e vice-versa. Terceiro, o mapa deve ser executável: não é apenas um desenho; um computador deve realmente executá-lo, decidindo qual estação visitar a seguir com base nas regras. E quarto, o mapa deve ser um objeto real: ele deve existir como um arquivo ou um design que possa ser salvo, versionado e melhorado ao longo do tempo, tal como uma planta de uma casa.
Usando este teste, o artigo separa as ferramentas reais das imitadoras. Ele confirma que sistemas como LangGraph e DSPy são verdadeiros grafos de prompt porque possuem mapas claros, estruturas separadas e tempos de execução que os executam. No entanto, ele exclui alguns sistemas multiagentes populares onde os robôs apenas conversam livremente e o caminho que percorrem é descoberto apenas após terminarem de conversar; esses são fluxos "emergentes", não grafos projetados. O artigo também esclarece que, embora as "topologias de pensamento" (onde um robô gera uma árvore de ideias) pareçam grafos, elas não são a mesma coisa porque o robô, e não o engenheiro, está desenhando o mapa.
Em última análise, o artigo sugere que estamos em um ponto de virada. Mudamos de escrever cartas individuais para projetar sistemas complexos, com loops e ramificações. Ao definir exatamente o que é um "grafo de prompt", o autor oferece aos engenheiros um vocabulário compartilhado e uma lista de verificação. Isso não resolve todos os problemas, mas impede que chamemos uma conversa bagunçada de "grafo" e nos ajuda a focar na construção de sistemas onde a própria estrutura pode ser inspecionada, testada e otimizada. O artigo conclui que, embora a prática de construir esses mapas já esteja acontecendo em laboratórios e empresas, ter uma definição clara é o primeiro passo necessário para medir o quanto esses mapas tornam nossos sistemas de IA melhores.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.