Optimizador de memoria de Janitor + Nadia - El secreto bajo su piel

Traducido del inglés

Janitor Memory Optimizer + Nadia - The Secret Under Her Skin

76

1,5 mil

Nadia — El secreto bajo su piel

Tu mejor amiga gótico-punk desde el instituto acaba de salvarte de un vampiro. ¿El problema? Tuvo que convertirse en hombre lobo para lograrlo.

Fête de la Musique, demasiada cerveza, demasiadas hamburguesas, música a todo volumen por todas partes—y un depredador que eligió al humano borracho equivocado al que morder. Nadia ha pasado años ocultando lo que realmente es de {{user}}. Esta noche, ese secreto es ceniza sobre el asfalto.


Qué esperar

  • RP de revelación sobrenatural con amigos de toda la vida.

  • Una licántropa gótico-punk marimacho con intereses en videojuegos, cómics, informática, senderismo y acampada.

  • La amistad primero; el romance es opcional y nunca se da por hecho.

  • Rutas de misterio sobrenatural urbano con vampiros, secretismo, amenazas y las consecuencias de la revelación de Nadia.

  • Diseñado como personaje de prueba de chat largo en vivo para Janitor Memory Optimizer v1.0.0.

Cómo jugar

Simplemente responde con naturalidad. Interroga a Nadia, recházala, acéptala, investiga al vampiro, busca un lugar privado o intenta evitar que la noche se vuelva aún más extraña. No hay comandos de memoria ni menús de configuración.

Notas de contenido

Alcohol, tabaco, ataque vampírico, violencia sobrenatural, sangre/colmillos, lenguaje soez, humor vulgar, miedo al rechazo. {{user}}Los sentimientos y decisiones de nunca están predeterminados.


Versión de prueba: 2026-08-18


Janitor Memory Optimizer v1.0.0

Motor de memoria pasiva definitivo

Memoria de rol a largo plazo para JanitorAI — totalmente pasiva, lista para usar e invisible para el usuario.

Janitor Memory Optimizer es un motor de memoria ES5 avanzado diseñado para JanitorAI Scripts Beta. Su objetivo es simple: ayudar a un personaje a conservar información importante, relaciones, eventos, promesas, ubicaciones, objetos, misiones, conflictos y arcos argumentales prolongados sin depender de un historial de chat en bruto que no deja de crecer.

No hay comandos que aprender, ni botones que pulsar, ni menú de memoria que gestionar, ni configuración que vigilar. Instala el script, adjúntalo a tu personaje y chatea con normalidad.

El motor lee la conversación en silencio, decide qué importa, lo organiza en varias capas de memoria y escribe solo el resultado útil en el Scenario en tiempo de ejecución del personaje para que el LLM pueda volver a leerlo en turnos futuros.

Nunca inyecta mensajes falsos en la conversación.


Para todos: ¿Qué hace realmente?

Imagina un rol largo en el que, cientos de mensajes atrás:

  • Nadia te dijo que era tu hermana.

  • Descubriste una llave de latón en un archivo abandonado.

  • Samira traicionó a Nadia.

  • Nadia dejó de confiar en Samira por esa traición.

  • Prometiste encontrarte con alguien más tarde en la Estación Central.

  • Un misterio se desarrolló lentamente a través de varias escenas distintas.

Normalmente, la información antigua acaba volviéndose difícil de mantener disponible para un modelo de lenguaje a medida que crece la conversación.

Janitor Memory Optimizer convierte continuamente las partes importantes de la conversación en un sistema de memoria compacto y estructurado.

Más adelante, si la conversación vuelve a ser relevante para Nadia, el motor puede recordar lo que importa sobre Nadia sin volcar cientos de mensajes antiguos de nuevo en el contexto.

Si haces una pregunta amplia como:

¿Cómo ha cambiado mi relación con Nadia?

puede recordar el arco compacto de la relación a largo plazo.

Si preguntas:

¿Cuándo exactamente dejó Nadia de confiar en Samira?

puede profundizar automáticamente desde el arco argumental a largo plazo hasta el episodio relevante y, cuando sea necesario, hasta la evidencia atómica original.

No le dices al motor de memoria cómo hacer nada de esto. Simplemente haces rol.


Conecta & Juega

Todo el sistema se diseñó específicamente para requerir la menor interacción posible del usuario.

  1. Abre Scripts Beta en JanitorAI.

  2. Crea un script Advanced.

  3. Pega el script completo de Janitor Memory Optimizer v1.0.0.

  4. Guárdalo.

  5. Adjúntalo a tu personaje.

  6. Eso es todo.

No hay asistente de configuración. No hay comandos obligatorios. No hay interfaz de depuración para el jugador de rol. No hay presupuestos de tokens manuales que mantener.

La experiencia prevista es: instálalo una vez y luego olvida que el motor de memoria existe.


Memoria en lenguaje natural 100 % pasiva

El optimizador observa la conversación normal y evalúa la información automáticamente.

Las peticiones explícitas en lenguaje natural también pueden reforzar o eliminar recuerdos:

Recuerda que Nadia es mi hermana.
No olvides que la llave del archivo pertenece a Samira.
Olvida todo sobre Nadia.
Olvida lo que dije sobre la llave de latón.

Estas son frases normales, no comandos.

El script no responde con mensajes como "Memoria guardada" o "Memoria eliminada". El personaje simplemente continúa el rol.

Los cambios narrativos normales se tratan de forma distinta al olvido. Por ejemplo:

Ya no confío en Nadia.

no borra el pasado. El optimizador puede conservar el estado anterior de la relación como historia y registrar el estado más reciente como un cambio.


Sin inyección en el chat

Esta es una de las reglas de diseño más importantes de todo el proyecto.

La conversación en sí es de solo lectura.

El script puede leer superficies de conversación disponibles como:

  • context.chat.last_message

  • context.chat.last_messages

  • context.chat.message_count

No añade mensajes de usuario, mensajes del asistente ni mensajes de sistema sintéticos.

No usa:

  • script_output para la memoria;

  • example_dialogs para la memoria;

  • entradas de conversación falsas;

  • comandos pseudo-chat ocultos.

La única superficie de memoria activa visible para el LLM es:

context.character.scenario

La bóveda privada en tiempo de ejecución bajo context.chat.jai_memory_optimizer_v10 es estado técnico, no un mensaje de conversación.


Cómo funciona el motor de memoria

Internamente, Janitor Memory Optimizer usa varias capas progresivamente más abstractas:

Chat de solo lectura → Hechos atómicos → Fragmentos con hash → Dossiers semánticos → Grafo temporal → Inteligencia de entidades → Memoria episódica → Hilos narrativos → Recuperación jerárquica → Scenario

1. Hechos atómicos

La información importante se conserva primero como hechos atómicos rastreables. Un hecho puede llevar información como su tipo, fuente, importancia, turno, aciertos de relevancia, entidades asociadas e ID de evidencia.

Estas memorias atómicas siguen siendo lo más parecido a una fuente de verdad dentro del motor. Los resúmenes de nivel superior no las reemplazan en silencio.

2. Bóveda con hash direccionada por contenido

Los hechos se organizan en fragmentos orientados a temas almacenados en estado privado en tiempo de ejecución.

Los fragmentos usan hashes de contenido para que la memoria sin cambios pueda reutilizarse en lugar de reescribirse constantemente.

Los hashes son direcciones y comprobaciones de integridad, no cifrado.

3. Dossiers semánticos

Las memorias relacionadas se agrupan en perfiles semánticos derivados.

Un dossier puede distinguir:

  • información estable;

  • información actual;

  • información histórica.

Esto permite que el modelo reciba una visión general útil de una persona o tema sin recibir todas las memorias individuales a la vez.

4. Grafo de memoria temporal

El optimizador puede construir relaciones entre personas, lugares, objetos, misiones y eventos.

Las aristas temporales distinguen deliberadamente:

  • causas — solo cuando la fuente respalda explícitamente la causalidad;

  • precede — orden cronológico sin afirmar causalidad;

  • reemplaza — un estado más reciente que reemplaza o contradice uno anterior.

En otras palabras, el motor no asume que, porque el Evento B ocurrió después del Evento A, el Evento A causó el Evento B.

5. Inteligencia de entidades

El motor realiza una resolución conservadora de entidades para:

  • alias explícitos;

  • apodos;

  • algunas relaciones de nombre completo / apellido;

  • pronombres inequívocos de ventana corta;

  • algunas referencias de relación inequívocas como "mi hermana".

Cuando una referencia es ambigua, el optimizador prefiere no fusionar identidades antes que inventar con confianza la conexión equivocada.

6. Temperatura de memoria adaptativa

Las memorias se tratan dinámicamente como calientes, tibias o frías.

La temperatura se ve influida por más que la antigüedad. El motor considera la utilidad observada, la importancia, la recencia, la estabilidad y la relevancia repetida.

Una memoria antigua que se vuelve útil repetidamente puede seguir siendo importante. Una memoria fría no se considera automáticamente falsa ni se borra simplemente por estar fría; principalmente se le resta prioridad.

7. Consolidación episódica

Los grupos más antiguos de eventos relacionados pueden convertirse en memorias episódicas compactas.

En lugar de llevar permanentemente diez eventos detallados en el recuerdo activo, el optimizador puede conservar un episodio extractivo que contenga los momentos clave de lo ocurrido.

La evidencia atómica subyacente puede permanecer adjunta a ese episodio, permitiendo profundizar más tarde cuando se requieran detalles exactos.

8. Hilos narrativos

Múltiples episodios pueden convertirse a su vez en arcos narrativos prolongados.

Las familias de hilos admitidas incluyen:

  • entity:*

  • relationship:*

  • quest:*

  • location:*

  • mystery:*

  • conflict:*

  • topic:*

Un solo episodio puede participar en varios hilos narrativos sin duplicar su evidencia original.

Esto significa que una escena que involucre a Nadia, un misterio de archivo y la misión del Hilo de Plata puede contribuir a los tres arcos argumentales mientras sigue siendo una única pieza subyacente de la historia.

9. Recuperación jerárquica

El optimizador intenta satisfacer las necesidades de memoria usando la capa útil más barata.

Una pregunta amplia puede requerir solo un Hilo Narrativo.

Una pregunta más precisa puede descender automáticamente a través de:

Hilo → Episodio → Evidencia atómica

Esto ayuda a preservar el detalle sin forzar cada detalle en cada prompt.


Recuperación reversible: Depósito en garantía JMO10

El Scenario también lleva un punto de control de recuperación acotado.

La capa de recuperación usa:

serialización compacta → LZW12 → Base64 → suma de verificación

Si el estado privado en tiempo de ejecución desaparece mientras el punto de control anterior del Scenario sigue disponible, el optimizador puede reconstruir la memoria desde ese punto de control.

Conceptualmente:

Scenario → Depósito en garantía JMO10 → Hechos atómicos / Episodios archivados → Dossiers semánticos → Grafo temporal → Hilos narrativos

Los datos de depósito en garantía corruptos se rechazan en lugar de convertirse en memoria fabricada.

JMO10 también puede leer formatos de depósito en garantía antiguos JMO3–JMO9 para migración y recuperación.


Gestión automática del contexto

El objetivo no es volcar toda la bóveda de memoria en cada generación.

El almacenamiento y el recuerdo se separan deliberadamente.

El motor ajusta automáticamente los presupuestos de recuerdo y recuperación según el espacio disponible y el tipo de información requerida en cada momento.

Una simple continuación necesita menos memoria que una pregunta detallada sobre causalidad, cronología o una relación que abarca cientos de mensajes.

Si es necesario, el optimizador reduce el detalle antes de desbordar su envolvente de trabajo interna.


Salvaguardas internas

Estas son heurísticas del proyecto, no límites oficiales declarados de JanitorAI.

  • Límite blando combinado estimado de Personality + Scenario: 4.000 tokens

  • Fragmentos de tema máximos: 512

  • Grafo temporal: 384 nodos / 768 aristas

  • Archivos episódicos: 160

  • Hilos narrativos: 192

  • Presupuestos de recuerdo y depósito en garantía: adaptativos automáticamente

Estos existen para mantener el sistema de memoria acotado y predecible en lugar de permitir un crecimiento descontrolado.


Seguridad en roles largos & Higiene de memoria

El motor incluye varias salvaguardas conservadoras desarrolladas a lo largo del proyecto:

  • consolidación de duplicados exactos;

  • síntesis de casi duplicados cuando corresponde;

  • reemplazo del estado actual sin destruir ciegamente la historia útil;

  • filtrado de preguntas para que las preguntas no se conviertan automáticamente en hechos establecidos;

  • detección conservadora de causalidad;

  • resolución de entidades consciente de la ambigüedad;

  • olvido dirigido en lenguaje natural;

  • rechazo de puntos de control de recuperación corruptos;

  • recuerdo histórico consciente de la relevancia;

  • aislamiento de relleno para que un "Vale." genérico no arrastre archivos no relacionados al contexto;

  • preservación de la evidencia atómica detrás de los resúmenes de nivel superior;

  • memoria acotada y poda del grafo;

  • migración automática de estados anteriores del optimizador cuando estén disponibles.


Diseñado para roles de larga duración

Janitor Memory Optimizer es particularmente útil para roles que involucran:

  • relaciones de desarrollo lento;

  • repartos con múltiples personajes;

  • misterios e investigaciones;

  • misiones y objetivos;

  • alianzas cambiantes;

  • conflictos prolongados;

  • inventarios persistentes u objetos importantes;

  • lugares recurrentes;

  • desarrollo de personajes;

  • historias que abarcan cientos o miles de turnos.


Validación & Pruebas de estrés

La v1.0.0 no se publicó tras una simple comprobación de sintaxis. Pasó por suites dedicadas de regresión, endurecimiento, recuperación y estrés de horizonte largo.

Validación estática / del paquete del creador

  • Comprobación de sintaxis de Node: PASS

  • Validador ES5 conservador: PASS

  • Errores: 0

  • Advertencias: 0

  • Tamaño en tiempo de ejecución: 191.418 / 400.000 bytes

Pruebas de invariantes de la superficie de salida

  • Sin script_output: PASS

  • Sin escrituras en el historial de chat: PASS

  • last_message permanece sin cambios: PASS

  • message_count permanece sin cambios: PASS

  • Sin escrituras de memoria en example_dialogs: PASS

  • Sin bloque de memoria activo añadido a Personality: PASS

  • Exactamente un destino de memoria visible para el LLM — Scenario: PASS

  • Sin sintaxis de comandos de usuario requerida ni expuesta: PASS

Suite de regresión

21 aserciones dirigidas: PASS

La cobertura incluyó:

  • escenario de 109 turnos;

  • consolidación episódica;

  • hilos narrativos;

  • recuerdo amplio de hilos;

  • profundización en el historial exacto;

  • aislamiento de relleno;

  • recuperación tras pérdida de estado;

  • compatibilidad de migración de versiones anteriores.

Suite de endurecimiento final

23 aserciones adicionales: PASS

Esta suite cubrió específicamente:

  • arquitectura solo de Scenario;

  • migración del estado en vivo de v0.9 a v1.0;

  • recuperación del depósito en garantía heredado JMO9;

  • evidencia atómica que sobrevive a la recuperación heredada;

  • rechazo seguro del depósito en garantía corrupto;

  • olvido dirigido en lenguaje natural;

  • preservación de memorias semánticas no relacionadas durante el olvido dirigido.

Prueba de estrés de 500 turnos

Corpus de prueba:

500 turnos de población + 60 consultas de memoria en lenguaje natural + 3 recuperaciones completas tras pérdida de estado privado.

  • Hechos antes de la recuperación: 42

  • Hechos tras 3 recuperaciones: 42

  • Episodios antes / después: 10 / 10

  • Hilos narrativos antes / después: 5 / 5

  • Recuperaciones completas tras pérdida de estado: 3 / 3 PASS

Prueba de estrés de horizonte largo de 2.000 turnos

También se ejecutó una prueba mucho mayor:

2.000 turnos de población + 60 consultas naturales + 3 recuperaciones completas tras pérdida de estado.

  • Hechos antes / después de la recuperación: 61 / 61

  • Episodios antes / después: 40 / 40

  • Hilos narrativos antes / después: 5 / 5

  • Recuperaciones completas tras pérdida de estado: 3 / 3 PASS

  • Construcciones de hilos: 195

  • Reutilizaciones de firma de hilo: 1.927

  • Construcciones de grafo: 201

  • Reutilizaciones de grafo: 1.860

Esto demuestra que las estructuras derivadas se reutilizan en gran medida en lugar de reconstruirse ciegamente en cada turno.

Optimización del rendimiento

En el mismo arnés local de Node de 500+60:

  • línea base v0.9: aproximadamente 6,49 segundos

  • v1.0 optimizada: aproximadamente 3,87 segundos

  • Reducción relativa: aproximadamente 39 %

Este benchmark mide el script en un arnés de prueba local de VM de Node. Es una medición de regresión/rendimiento relativa del propio script, no una afirmación sobre la latencia del servidor de JanitorAI.


Compatibilidad & Migración

La v1.0.0 escribe el formato de recuperación actual JMO10.

Puede leer puntos de control de depósito en garantía heredados JMO3 a JMO9.

La migración desde estados anteriores de Janitor Memory Optimizer es compatible cuando el estado anterior necesario sigue disponible.

Para una instalación nueva, simplemente usa la v1.0.0.


Vibe-Coded con ChatGPT 5.6

Sí, este proyecto se vibe-codeó con ChatGPT 5.6.

El motor se desarrolló iterativamente mediante diseño, pruebas, depuración, pruebas de estrés y revisiones arquitectónicas repetidas dirigidas por humanos, con ChatGPT 5.6 ayudando con el código.

Evolucionó a través de múltiples prototipos: desde un inyector básico de memoria selectiva hasta una bóveda direccionada por contenido, un sistema de recuperación reversible, una jerarquía de memoria semántica, un grafo temporal, un resolvedor de entidades, un archivo episódico y un motor de hilos narrativos.

La versión final se sometió entonces a suites automatizadas de regresión y estrés en lugar de publicarse simplemente porque el código generado "parecía correcto".

Este es un proyecto comunitario independiente. No es un producto oficial de OpenAI ni de JanitorAI, y mencionar ChatGPT 5.6 describe el proceso de desarrollo en lugar de una certificación o respaldo oficial.


¿Por qué usarlo?

Porque la memoria no debería convertirse en otra mecánica de juego que el jugador de rol tenga que gestionar.

No deberías tener que pausar una escena para escribir:

/save_memory relationship Nadia trust -1

Deberías poder simplemente escribir:

Después de lo que hizo Nadia, no creo que pueda confiar en ella nunca más.

y continuar la historia.

Esa es la filosofía de diseño detrás de Janitor Memory Optimizer.

El procesamiento de la memoria debería ocurrir en segundo plano. El chat debería seguir siendo un chat. Las definiciones de personaje deberían llevar la memoria de trabajo. El LLM debería recibir la menor cantidad útil de contexto para el momento actual.


En resumen

  • Conecta & juega.

  • Totalmente pasivo.

  • Sin comandos.

  • Sin interfaz de memoria.

  • Sin mensajes de chat falsos.

  • Memoria visible para el LLM solo en Scenario.

  • Recordar / olvidar en lenguaje natural.

  • Evidencia atómica.

  • Bóveda de memoria con hash.

  • Dossiers semánticos.

  • Grafo temporal y causal.

  • Inteligencia de entidades conservadora.

  • Memoria adaptativa caliente / tibia / fría.

  • Consolidación episódica a largo plazo.

  • Hilos narrativos persistentes.

  • Recuerdo jerárquico con profundización en la evidencia.

  • Depósito en garantía de recuperación JMO10 reversible.

  • Compatibilidad de recuperación heredada.

  • Presupuesto de contexto automático.

  • Probado bajo estrés con más de 2.000 turnos.

  • 3/3 recuperaciones completas tras pérdida de estado en ambas suites de estrés principales.

  • 0 errores de validación ES5.

  • 0 advertencias de validación ES5.

Pégalo. Adjúntalo. Haz rol con normalidad.
Deja que el personaje recuerde.

Creado 18 ago

Actualizado 18 ago

Publicado 18 ago

proxy permitido

Chats publicados