2026-08-01T08:39:09.696Z
ReasoningBank: Auditoría de la memoria autoevolucionante antes de la promoción
Transformar ReasoningBank en una puerta de memoria lista para el operador con procedencia, persistencia, verificación independiente, pruebas de regresión de sombra y retroceso.
La respuesta útil a ReasoningBank: Scaling Agent Self Evolving with Reasoning Memory no es dejar que el agente reescriba su memoria después de cada carrera. El documento presenta una forma prometedora de destilar estrategias de exitosas y trayectorias fallidas. Un operador todavía necesita una regla separada para decidir cuándo una de esas estrategias puede afectar el trabajo en vivo. Utilice la cuarentena como opción predeterminada. Mantenga un nuevo elemento de memoria fuera de recuperación activa hasta que pueda rastrear de dónde vino, probar que fue almacenado correctamente, verificar el resultado de origen de forma independiente cuando sea posible, ejecutarlo contra una suite de sombra fija, y volver al banco anterior si el comportamiento regresa. La promoción debe ser una decisión explícita, no un efecto secundario de la extracción. Este límite preserva la idea central del documento mientras se aborda una pregunta diferente: no si la memoria de razonamiento puede mejorar el rendimiento de referencia, sino si una actualización de memoria en particular es lo suficientemente saludable como para influir en la siguiente tarea real. ¿Qué contribuye ReasoningBank y qué prueba? El documento del Banco de Razonamiento reemplaza la reutilización de trayectoria en bruto con memorias de estrategia compactas. Cada elemento tiene un título, una descripción de una frase y un contenido que contiene pasos de razonamiento, razones de decisión o lecciones operativas. El bucle tiene tres partes: 1. recuperar elementos pertinentes para una nueva tarea; 2. evaluar la trayectoria completada, y luego extraer lecciones del éxito o del fracaso; 3. consolidar esos elementos de nuevo en el banco. El camino del fracaso importa. Una trayectoria de navegador fallida puede dar una lección preventiva como comprobar un identificador de página antes de repetir una acción de paginado. Eso es más reutilizable que almacenar una larga secuencia de clics. El Explicación de Google Research describe el mismo bucle de recuperación, extracción y consolidación y informa mejoras sobre líneas de base de memoria sin memoria y anteriores en WebArena y SWE Bench Verified. Dichos resultados constituyen evidencia del método dentro de la instalación evaluada, no una garantía de producción. El documento utiliza un LLM as a judge para etiquetar las trayectorias sin retroalimentación de la verdad básica. Los artículos recién extraídos se adjuntan directamente, sin poda. La recuperación se basa en la incorporación de similitud. Los autores deliberadamente mantienen esas piezas simples para poder aislar el valor del contenido orientado al razonamiento. El proyecto Repositorio de referencia refuerza el límite: libera el código WebArena y SWE Bench, mientras que su README dice que el proyecto es para demostración y no está destinado a la producción. Esa es una advertencia útil, no un defecto. Una aplicación de la investigación y un control operativo resuelven diferentes problemas. Contenido de memoria separado de la autoridad de promoción El esquema ReasoningBanks {title, description, content} es legible para el hombre y fácil de inyectar en un prompt. No requiere un ID de trayectoria de origen, hash de extracción, tipo de verificador, versión, caducidad, conjunto de conflictos, resultado de sombra, aprobación o puntero de retroceso. Eso es apropiado para el experimento. Es insuficiente como único registro detrás de un cambio que afecta a la producción. Envuelva cada artículo extraído en un envase para el operador: Este sobre no hace que el recuerdo sea verdadero. Esto hace que la decisión sea inspectable. También separa cinco eventos que son fáciles de desmoronarse en uno: la extracción completada, una escritura exitosa, el artículo sobrevivió a una relectura, el consejo ayudó en casos de sombra, y una persona autorizada permitió su recuperación activa. La distinción es importante porque la actividad no es progreso. Un banco de memoria puede crecer después de cada tarea mientras la calidad de recuperación disminuye. En la propia ablación del documento, el uso de una experiencia relevante superó el uso de conjuntos más grandes; el éxito cayó cuando se recuperaron 2, 3 y 4 experiencias en ese entorno evaluado. El resultado no define un top k universal, pero refuta una suposición operativa tentadora: un material más recordado no es automáticamente más saludable. Requerir cinco pruebas antes de la promoción Las cinco pruebas a continuación son deliberadamente independientes. Un pase en una columna no compensa un fracaso en otra. 1. Origen de la procedencia Registrar la trayectoria de la fuente, su resultado observado, el prompt o versión de extracción y un hash del elemento inducido. Una memoria sin procedencia debe permanecer en cuarentena incluso si su consejo suena razonable. De lo contrario, el operador no puede distinguir una extracción actual de una importación obsoleta, un artículo duplicado o una edición manual. 2. Persistencia duradera No compares una llamada de escritura exitosa con la memoria retenida. Leer de nuevo el elemento almacenado a través del mismo límite que utilizará el tiempo de ejecución, comparar su hash y repetir la verificación después del reinicio o actualización de índice correspondiente. Un elemento faltante o modificado es una falla de persistencia; una ruta de lectura no disponible es unknown , no saludable. 3. Evidencia independiente de los resultados El documento informa robustez para juzgar el ruido, pero también enumera la dependencia de LLM as a judge como una limitación. Para una promoción operativa, prefiere un verificador determinístico: hash de archivo esperado, prueba de aprobación, estado de API, recuento de filas u otro recibo específico de la tarea. Utilice la revisión humana cuando el resultado no pueda ser verificado mecánicamente. Un veredicto de LLM puede priorizar la revisión, pero no debe ser la única autoridad para una memoria que cambie el comportamiento futuro. 4. Regresión de las sombras y cobertura de deriva Ejecutar al candidato contra una suite versionada sin dejar que afecte a las tareas en vivo. Incluir casos en los que la estrategia debería ayudar, casos en los que debería ser irrelevante y al menos un caso límite en el que una aplicación excesiva sería perjudicial. Comparar los resultados, no fluidez. Rastrear la versión bancaria, modelo, herramientas y versión fija para que un cambio posterior no se disfrace de deriva de memoria. El umbral pertenece al riesgo de la tarea. La fijación de acompañamiento utiliza cuatro casos y una tasa de aprobación del 80% sólo para hacer reproducible la regla de decisión; estos números no son una recomendación general. Una herramienta destructiva puede requerir que pase cada caso crítico. Un asistente de redacción reversible puede tolerar un límite diferente. 5. Aprobación explícita y preparación para el retroceso Pasar los controles técnicos significa estar listo para la aprobación, no promocionar automáticamente. Mantener el banco anterior inmutable, grabar la versión activa y definir la señal que desencadene el retroceso. Después de la promoción, vuelva a ejecutar un pequeño juego de canarios y observa los resultados verificados de la tarea. Si aparece una regresión crítica, restablezca primero la versión anterior; investigue en segundo lugar. Reproducir la regla de decisión en seis casos incómodos Encripté la puerta como un pequeño clasificador Node.js y la ejecuté contra seis candidatos. La regla comprueba la procedencia, un recibo de persistencia de escritura más re lectura, evidencia determinista o humana de resultados, cobertura de sombra, conflictos de memoria activa y un puntero de retroceso. A continuación, se aplica esta prioridad: El pedido es intencional. Una regresión activa requiere un retroceso incluso si la promoción original fue aprobada. Las pruebas faltantes no pueden ser reparadas mediante aprobación. Un conflicto no es automáticamente un fracaso porque dos estrategias pueden tener ámbitos diferentes, pero necesita una persona o una regla determinista más fuerte antes de la activación. Ejecutar el dispositivo con: La salida fija fue: El candidato Condición de la prueba Decisión de la Comisión mem 001 No proviene; sólo el veredicto del juez. quarantine mem 002 la procedencia presente; el juez sigue siendo la única prueba de resultado quarantine mem 003 todas las pruebas pasan; conflictos con un elemento activo review conflict mem 004 Pases de pruebas técnicas; no hay aprobación del operador ready for approval mem 005 se registran todas las pruebas y se registra la aprobación promote mem 006 elemento activo ahora falla en el límite de la sombra rollback Esta fijación agrega información que el documento no intenta proporcionar: un límite de autoridad concreto alrededor de una sola memoria inducida. Znot reproduce los puntos de referencia del papel, valida cada estrategia extraída, o prueba que un 80% de puntaje de sombra se generalizará. El cambio de distribución todavía puede derrotar a la suite. Los conflictos pueden ser sutiles. La aprobación humana todavía puede ser errónea. Operar el bucle sin pretender que está resuelto Por lo tanto, un despliegue práctico de ReasoningBank debería tener dos bancos, no un grupo de bancos no diferenciado: un banco de cuarentena que acepte nuevos objetos extraídos y conserve sus pruebas; un banco activo que contenga únicamente artículos versionados y aprobados utilizados para la extracción en vivo. Medir la transición entre ellos. Las señales útiles incluyen la edad del candidato, la procedencia ausente, las fallas en la lectura de persistencia, la cobertura de los verificadores, las regresiones de sombra, los conflictos no resueltos, la versión de banco activo, la preparación para el retroceso y la deriva de resultados después de la promoción. No utilice el recuento de objetos de memoria como métrica de salud de los titulares. Tratar los estados de espera y atrapado de manera diferente. Un candidato que espera a un revisor autorizado no se rompe si tiene un propietario y una fecha límite. Un candidato repetidamente extraído sin obtener pruebas faltantes se queda atrapado. Un elemento activo cuyo verificador no esté disponible es incierto. Un elemento activo con una regresión crítica verificada debe ser retirado. Por último, mantenga las afirmaciones de productos honestas. Sidewisp se encuentra actualmente en versión preliminar privada. Su sitio público y sistema de artículos están en vivo, pero la colección de agentes de producción salud, adaptadores de tiempo de ejecución y recuperación automática o guiada generalmente no se envían. La puerta en este artículo es un patrón de operador que se ajusta al territorio de salud de Sidewisp; no es una afirmación de que Sidewisp actualmente monitoree ReasoningBank, promueve recuerdos o realice retrocesos. El siguiente paso razonable es pequeño: elegir una familia de tareas limitada, congelar un banco de referencia, agregar providencia y recibos de sombra a los recuerdos de los candidatos, y promover solo un artículo a través de la aprobación explícita. Si el resultado se mantiene estable, expandir la suite antes de expandir la autoridad.