ReasoningBank: Auditar a memória auto-evolutiva antes da promoção

A resposta útil ao ReasoningBank: Agente de Escalação Autoevolução com Memória de Raciocínio não é deixar o agente reescrever sua memória após cada corrida. O artigo apresenta uma maneira promissora de destilar estratégias de bem sucedidas e trajetórias fracassadas. Um operador ainda precisa de uma regra separada para decidir quando uma dessas estratégias pode afectar o trabalho ao vivo. Use a quarentena como padrão. Mantenha um novo item de memória fora da recuperação ativa até que possa rastrear de onde veio, provar que foi armazenado corretamente, verificar o resultado da fonte de forma independente sempre que possível, executá lo contra um conjunto fixo de sombras e retornar ao banco anterior se o comportamento regressar. A promoção deve ser uma decisão explícita, não um efeito colateral da extracção. Esse limite preserva a idéia central do artigo enquanto aborda uma questão diferente: não se a memória de raciocínio pode melhorar o desempenho de referência, mas se uma atualização de memória em particular é saudável o suficiente para influenciar a próxima tarefa real. O que contribui o ReasoningBanke o que verifica O O artigo do ReasoningBank substitui a reutilização de trajetória bruta por memórias de estratégia compactas. Cada item tem um título, uma descrição de uma frase e conteúdo que contém passos de raciocínio, razões de decisão ou lições operacionais. O ciclo tem três partes: 1. Recuperar elementos relevantes para uma nova tarefa; 2. julgar a trajetória concluída e, em seguida, extrair lições do sucesso ou do fracasso; 3. Consolidar essas posições de volta ao banco. O caminho do fracasso importa. Uma trajetória de navegador falhada pode dar uma lição preventiva, como verificar um identificador de página antes de repetir uma ação de pagination. Isso é mais reutilizável do que armazenar uma longa sequência de cliques. O Explicação do Google Research descreve o mesmo ciclo de recuperação, extração e consolidação e relata melhorias sobre linhas de base de memória sem memória e anteriores no WebArena e no SWE Bench Verified. Estes resultados constituem provas do método no âmbito da instalação avaliada, e não uma garantia de produção. O artigo usa um LLM as a judge para rotular trajetórias sem retroalimentação da verdade básica. Os produtos recém extraídos são anexados diretamente, sem poda. A recuperação baseia se na incorporação de semelhanças. Os autores deliberadamente mantêm essas peças simples para que possam isolar o valor do conteúdo orientado para o raciocínio. O projeto Repositório de referência reforça o limite: libera o código WebArena e SWE Bench, enquanto o seu README diz que o projeto é para demonstração e não é destinado à produção. Isso é um aviso útil, não um defeito. A implementação de pesquisas e o controlo operacional resolvem diferentes problemas. Conteúdo de memória separado da autoridade de promoção ReasoningBanks {title, description, content} esquema é legível pelo homem e fácil de injetar em um prompt. Não requer um ID de trajetória de origem, hash de extração, tipo de verificador, versão, expiração, conjunto de conflitos, resultado de sombra, aprovador ou ponteiro de retrocesso. Isso é apropriado para a experiência. É insuficiente como único registro por trás de uma alteração que afeta a produção. Envolver cada item extraído num envelope do operador: Este envelope não torna a memória verdadeira. Faz a decisão inspecionável. Ele também separa cinco eventos que são fáceis de colapsar em um: extração concluída, uma escrita bem sucedida, o item sobreviveu a uma releitura, o conselho ajudado em casos de sombra, e uma pessoa autorizada permitiu a recuperação ativa. A distinção é importante porque a atividade não é progresso. Um banco de memória pode crescer após cada tarefa enquanto a qualidade da recuperação diminui. Na própria ablação do artigo, a utilização de uma experiência relevante batia a utilização de conjuntos maiores; o sucesso caiu quando 2, 3 e 4 experiências foram recuperadas nesse cenário avaliado. O resultado não define um top k universal, mas refuta uma suposição operacional tentadora: o material mais lembrado não é automaticamente mais saudável. Exigir cinco provas antes da promoção As cinco provas abaixo são deliberadamente independentes. Uma passagem numa coluna não compensa uma falha noutra. 1. Província Registrar a trajetória da fonte, o seu resultado observado, o prompt ou versão de extracção e um hash do item induzido. Uma memória sem origem deve permanecer em quarentena, mesmo que os conselhos pareçam sensatos. Caso contrário, o operador não pode distinguir uma extração corrente de uma importação obsoleta, de um item duplicado ou de uma edição manual. 2. Persistência duradoura Não equipare uma chamada de escrita bem sucedida com memória retida. Leia novamente o item armazenado através do mesmo limite que o runtime usará, compare o hash e repita a verificação após a reinicialização ou atualização do índice relevante. Um item perdido ou alterado é uma falha de persistência; um caminho de leitura não disponível é unknown , não saudável. 3. Evidências independentes de resultados O artigo relata robustez para julgar ruído, mas também lista a dependência do LLM como juiz como uma limitação. Para uma promoção operacional, prefira um verificador determinístico: hash de arquivo esperado, teste de passagem, estado da API, contagem de filas ou outro recibo específico de tarefa. Utilize revisão humana quando o resultado não possa ser verificado mecanicamente. Um veredicto LLM pode priorizar a revisão, mas não deve ser a única autoridade para uma memória que muda o comportamento futuro. 4. Regressão das sombras e cobertura de deriva Exerce o candidato contra uma suíte de versões sem deixar que afete tarefas ao vivo. Incluir os casos em que a estratégia deve ajudar, os casos em que ela deve ser irrelevante e pelo menos um caso limite em que a aplicação excessiva seria prejudicial. Comparar resultados, não fluência. Seguir a versão bancária, modelo, ferramentas e versão fixa para que uma mudança posterior não se mascara como deriva de memória. O limiar pertence ao risco da tarefa. O sistema de acompanhamento utiliza quatro casos e uma taxa de aprovação de 80% apenas para tornar a regra de decisão reprodutível; esses números não constituem uma recomendação geral. Uma ferramenta destrutiva pode exigir que todos os casos críticos sejam aprovados. Um assistente de redacção reversível pode tolerar um limite diferente. 5. Aprovação explícita e prontidão para o retrocesso Passar os controlos técnicos significa estar pronto para aprovação, não promover automaticamente. Mantém imutável o banco anterior, grava a versão ativa e define o sinal que desencadeará o retrocesso. Após a promoção, reinicie um pequeno conjunto de canários e assista aos resultados verificados da tarefa. Se aparecer uma regressão crítica, restaurar a versão anterior primeiro; investigar em segundo lugar. Reproduzir a regra da decisão em seis casos inconvenientes Encodei o gate como um pequeno classificador Node.js e corri contra seis candidatos. A regra verifica a proveniência, um recibo de persistência write plus reread, evidências deterministas ou humanas de resultados, cobertura de sombras, conflitos de memória ativa e um ponteiro de retrocesso. Aplica se então esta prioridade: O pedido é intencional. Uma regressão ativa requer um retrocesso mesmo que a promoção original tenha sido aprovada. As provas faltantes não podem ser reparadas com aprovação. Um conflito não é automaticamente um fracasso porque duas estratégias podem ter escopo diferente, mas precisa de uma pessoa ou de uma regra determinista mais forte antes da ativação. Execute o dispositivo com: A saída fixa foi: Candidato Condição da prova Decisão mem 001 Não há origem; veredicto apenas do juiz. quarantine mem 002 a proveniência presente; o juiz continua a ser a única prova de resultado quarantine mem 003 Todas as provas são aprovadas; conflitos com um item ativo review conflict mem 004 aprovação das provas técnicas; não aprovação do operador ready for approval mem 005 Todas as provas passam e a aprovação é registada. promote mem 006 item ativo agora falha o limite de sombra rollback Esta fixação adiciona informações que o jornal não tenta fornecer: um limite de autoridade concreto em torno de uma única memória induzida. Reproduz Znot os índices de referência do papel, valida cada estratégia extraída, ou prova que uma pontuação de sombra de 80% irá generalizar. A mudança de distribuição ainda pode derrotar a suite. Os conflitos podem ser sutis. A aprovação humana ainda pode ser errada. Operar o ciclo sem fingir que está resolvido Uma implementação prática do ReasoningBank deve, portanto, ter dois bancos, e não um conjunto não diferenciado: um banco de quarentena que aceite novos itens extraídos e conserve as suas provas; um banco ativo que contenha apenas itens aprovados em versão utilizados para a recuperação ao vivo. Medir a transição entre eles. Os sinais úteis incluem a idade do candidato, a proveniência ausente, as falhas de leitura persistente, a cobertura do verificador, as regressões de sombra, os conflitos não resolvidos, a versão do banco ativo, a prontidão para o retrocesso e a deriva de resultados pós promoção. Não utilize a contagem de memória como métrica de saúde do título. Tratar os estados de espera e de bloqueio de forma diferente. Um candidato à espera de um revisor autorizado não é quebrado se tiver um proprietário e prazo. Um candidato repetidamente re extraído sem obter provas faltantes fica preso. Um item ativo cujo verificador não está disponível é incerto. Um item ativo com regressão crítica verificada deve ser retirado. Finalmente, mantenha as alegações de produtos honestas. A Sidewisp está atualmente em prévia privada. Seu site público e sistema de artigos estão ao vivo, mas a coleta de agentes de produção saúde, adaptadores de tempo de execução e recuperação automática ou guiada geralmente não são enviados. O portão neste artigo é um padrão de operador que se encaixa no território de saúde do Sidewisp; não é uma alegação de que o Sidewisp atualmente monitorize o ReasoningBank, promova memórias ou realiza rollback. O próximo passo razoável é pequeno: escolher uma família de tarefas limitadas, congelar um banco de base, adicionar proveniência e recibos de sombra às memórias dos candidatos e promover apenas um item através da aprovação explícita. Se o resultado permanecer estável, expandir a suíte antes de expandir a autoridade.