As inteligências de planejamento e execução oferecem uma solução mais rápida, econômica e de melhor desempenho para a execução de tarefas do que os projetos anteriores. Este artigo o guiará na criação de três inteligências de planejamento no LangGraph.
Introduzimos três inteligências no modo "planejar e executar" na plataforma LangGraph. Essas inteligências demonstram vários aprimoramentos em relação às inteligências clássicas do modo Reason and Act (ReAct).
Em primeiro lugar, essas inteligências são capazes de executar processos de tarefas de várias etapas mais rapidamente, pois não há necessidade de solicitar o envolvimento de grandes inteligências novamente após a conclusão de cada ação. Cada subtarefa pode ser concluída sem a necessidade de chamadas adicionais ao modelo de linguagem grande (LLM) ou chamadas ao suporte LLM mais leve.
Em segundo lugar, eles podem reduzir efetivamente os custos em comparação com as inteligências do ReAct. Se forem necessárias chamadas de LLM para subtarefas, geralmente são usados modelos menores e específicos do domínio. Os modelos grandes são invocados somente quando as etapas de (re)planejamento precisam ser executadas e as respostas finais geradas.
Por fim, ao solicitar que o planejador "pense" explicitamente, passo a passo, no processo necessário para concluir a tarefa inteira, essas inteligências podem ter um desempenho melhor em termos de taxa e qualidade de conclusão da tarefa. O desenvolvimento de etapas de raciocínio detalhadas tem sido uma técnica de orientação validada para melhorar os resultados. A segmentação do problema também pode levar a um desempenho mais concentrado e eficiente da tarefa.
Histórico
No último ano, agentes inteligentes e máquinas de estado baseadas em modelos de linguagem surgiram como um paradigma de design promissor para o desenvolvimento de produtos de IA flexíveis e eficientes.
O núcleo de um agente é um modelo de linguagem como uma ferramenta genérica de solução de problemas que o conecta a recursos externos para responder a perguntas ou executar tarefas.
Normalmente, os agentes inteligentes baseados em modelos de linguagem passam pelas seguintes etapas principais:
1. propor ação: o modelo de linguagem gera um texto que responde diretamente ao usuário ou é comunicado a uma função.
2) Executar ação: o código chama outro software para realizar, por exemplo, consultas ao banco de dados ou chamadas à API e outras operações.
3. observar Observar: reagir ao feedback das chamadas de ferramentas, seja chamando outra função ou respondendo ao usuário.
ReAct Os agentes inteligentes são um bom exemplo disso, usando ciclos repetitivos de pensamento, ação e observação para orientar o modelo de linguagem:
Pense: eu deveria chamar Search() para procurar o placar da partida atual.
Ação: Search("Qual é a pontuação da partida X atual?")
Observação: o placar atual é 24-21
... (Repetir N vezes)
Essa é uma trajetória típica de um agente inteligente no estilo ReAct.
Essa abordagem utilizaCadeia de pensamentopara que apenas uma única decisão de ação seja tomada em cada etapa. Embora isso possa ser eficaz para tarefas simples, tem algumas desvantagens importantes:
1. cada chamada de ferramenta requer uma chamada de modelo de linguagem.
2) O modelo de linguagem planeja um subproblema de cada vez. Isso pode levar a trajetórias de processamento abaixo do ideal, pois ele não é forçado a "raciocinar" sobre toda a tarefa.
Uma maneira eficaz de superar essas duas deficiências é incluir uma etapa de planejamento explícito. Abaixo estão dois exemplos de projetos desse tipo que implementamos na LangGraph.
Sistema Planejar e Executar
Agentes executores de programas
Essa estrutura simples é baseada no artigo de Wang et al [Dicas de planejamento e resolução] proposto por Yohei Nakajima e baseado em seu [BebêAGI], tornou-se a arquitetura típica do agente de planejamento. Ele contém dois componentes básicos principais:
1. um planejador (A) planejador), é responsável por direcionar um modelo de linguagem (LLM) para gerar planos de várias etapas para tarefas complexas.
2. vários atuadores (Executor(s)) que podem processar os requisitos de consulta do usuário, bem como uma etapa do plano, e invocar uma ou mais ferramentas para executar essa tarefa.
Uma vez concluída a execução da tarefa, o agente é novamente apresentado a um novo prompt de planejamento, no qual ele decide se simplesmente fornece uma resposta para encerrá-la ou se gera outros planos conforme necessário (se o plano original não tiver atingido sua meta).
Esse projeto de agente evita a necessidade de depender de um grande modelo de linguagem de planejamento para cada invocação da ferramenta. No entanto, como ele não oferece suporte a operações de atribuição de variáveis e a ferramenta deve ser chamada em série, é necessário um modelo de linguagem separado para cada tarefa.
Raciocínio além da observação independente
Em [ReWOOEm um estudo da [...], Xu et al. desenvolveram um novo modelo de agente que inverte a maneira tradicional em que cada tarefa deve contar com o Modelo de Linguagem Grande (LLM), permitindo que as tarefas subsequentes contem com os resultados da tarefa anterior. O modelo é implementado pela incorporação da função de atribuição de variáveis no planejamento de saída. A figura a seguir mostra o design desse modelo de agente.
Modelo de agente ReWOO
O planejador é responsável por gerar uma lista de planos que inclui "plan" (raciocínio) alternado com a linha "E#". Por exemplo, para a consulta "Quais são as estatísticas de quarterback para os competidores do Super Bowl deste ano?", o planejador pode gerar o seguinte plano:
O plano: Preciso conhecer as equipes que jogarão no Super Bowl este ano
E1: Procure por [quem está disputando o Super Bowl?]
Plano: Preciso saber quem é o quarterback de cada equipe
E2: LLM [1ª equipe QB #E1]
Plano: Preciso saber quem é o quarterback de cada equipe
E3: LLM [2ª equipe QB #E1]
Plano: Preciso verificar as estatísticas do primeiro quarterback
E4: Pesquisar [estatísticas de quarterback do #E2]
Plano: Preciso verificar as estatísticas do segundo quarterback
E5: Pesquisar [estatísticas de quarterback do #E3]
Observe que o planejador (planejador) Como ele pode se referir à saída anterior por meio de uma sintaxe como `#E2`. Isso significa que é possível executar uma série de tarefas sem precisar reprogramar cada uma delas.
"Trabalhadores (trabalhadorO nó ")" itera por cada tarefa e atribui seus resultados a variáveis predeterminadas. E, quando as chamadas de tarefas subsequentes forem executadas, essas variáveis serão substituídas pelos resultados correspondentes.
Em última análise, o "resolvedor (Solucionador) "Integrar todos os resultados para chegar à resposta final.
Essa filosofia de design de agente pode ser mais eficiente do que um modelo simples de planejar-executar, pois cada tarefa contém apenas as informações contextuais necessárias (ou seja, suas entradas e valores variáveis).
No entanto, esse projeto ainda se baseia na execução sequencial de tarefas, o que pode resultar em tempos de execução gerais mais longos.
LLMCompilador
Agente LLMCompiler
LLMCompilador É uma combinação de [Equipe Kim] desenvolveu uma arquitetura de agente projetada para melhorar a eficiência da execução de tarefas em relação ao plano-execução descrito anteriormente com agentes ReWOO, e ainda mais rápido do que as chamadas de ferramentas paralelas do OpenAI.
O LLMCompiler consiste nas seguintes partes principais:
1. PlanejadorGera um gráfico acíclico direcionado (DAG) de tarefas. Cada tarefa inclui ferramentas, parâmetros e uma lista de dependências.
2. Unidade de busca de tarefas (TFU) Responsável pelo agendamento e execução de tarefas. Ele pode aceitar um fluxo de tarefas e agendá-las assim que suas dependências forem atendidas. Como muitas ferramentas exigem chamadas adicionais ao mecanismo de pesquisa ou ao LLM, essa execução paralela pode aumentar significativamente a velocidade (até 3,6 vezes, de acordo com o documento).
3. Conector (Joiner)Etapa de planejamento: Essa parte pode replanejar ou encerrar dinamicamente a tarefa com base em todo o histórico da execução da tarefa, incluindo os resultados da execução da tarefa. Essa é a etapa da sessão LLM que determina se o resultado final deve ser apresentado diretamente ou se o progresso deve ser devolvido ao planejador para que ele continue o trabalho.
O ponto principal dessa arquitetura para acelerar a implementação é:
- planejadorA saída dotransmissãoEle é capaz de produzir saídas instantâneas de parâmetros de tarefas e suas dependências.
- unidade de aquisição de tarefas Recebe tarefas transmitidas e inicia o agendamento quando todas as dependências são atendidas.
- Os parâmetros da tarefa podem servarianteou seja, os resultados das tarefas anteriores no gráfico acíclico direcionado. Por exemplo, o modelo pode ser representado por
search("${1}")para consultar o conteúdo de pesquisa gerado pela Tarefa 1. Essa abordagem permite que o agente trabalhe com mais eficiência do que as chamadas normais de ferramentas paralelas do OpenAI.
Ao organizar as tarefas em um gráfico acíclico direcionado, ele não apenas economiza um tempo valioso ao invocar a ferramenta, mas também proporciona uma melhor experiência ao usuário.
resumos
Essas três arquiteturas de proxy são protótipos do padrão de design Plan-Do, separando o "planejador" orientado pelo LLM do tempo de execução da ferramenta. Se o seu aplicativo exigir várias chamadas para a ferramenta ou API, essas abordagens podem reduzir o tempo necessário para chegar ao resultado final e ajudá-lo a diminuir os custos, reduzindo o número de chamadas para LLMs de nível superior.
