Datalog para LLMs: memoria que no olvida conclusiones

En pocas palabras: El 28 de agosto de 2026, Jordy Zomer resolvió el problema de memoria de los LLMs en tareas largas de análisis guardando el estado del modelo en una base Datalog con dependencias lógicas, logrando mejores resultados en benchmarks de memoria extensa.

Si alguna vez pasaste más de dos horas investigando una vulnerabilidad con un modelo de lenguaje, sabés lo que pasa: el modelo arranca bárbaro, encontrás cosas interesantes, y de repente —tres horas después— te sugiere un approach que vos mismo descartaste en los primeros 20 minutos. O peor, sigue razonando como cierto algo que ya probaste que no funciona. El 28 de agosto de 2026, Jordy Zomer publicó en su blog pwning.systems un experimento donde convirtió ese problema de memoria de LLM en un motor de análisis de programas usando Datalog, y los resultados en benchmarks de memoria larga dieron mucho mejor de lo que esperaba.

La idea es simple de explicar pero potente en ejecución: en vez de pedirle al modelo que reconstruya su estado mental desde una transcripción kilométrica cada vez que necesita recordar algo, mantenemos ese estado en una base de datos que entiende dependencias lógicas. El LLM hace lo que mejor le sale —extraer significado de texto desprolijo, código, logs de debugger— y el motor de razonamiento hace lo mejor le sale a él: mantener consistencia cuando las cosas cambian.

Lemmalog es un motor de razonamiento determinista basado en Datalog —un lenguaje declarativo de hechos y reglas— diseñado para mantener el estado de conocimiento de un agente de LLM durante investigaciones que duran horas. A diferencia de una base de datos vectorial que recupera información por similitud semántica, Lemmalog trackea qué conclusiones dependen de qué observaciones, y cuando una observación cambia, invalida solo las conclusiones afectadas sin necesidad de re-evaluar todo desde cero.

¿Qué problema tiene la memoria de los LLMs en investigaciones largas?

Ponele que estás analizando un kernel module y en la primera hora de investigación establecés tres cosas: el atacante controla object_a, object_a apunta a object_b, y object_b es un objeto del kernel. Conclusión: el atacante puede controlar un objeto del kernel.

Dos horas después, metido en LLDB, descubrís que object_a no apunta a object_b — esa observación estaba basada en una suposición incorrecta. En una conversación normal con un LLM, tu historial ahora contiene afirmaciones contradictorias: “object_a apunta a object_b”, “object_b es controlable por el atacante”, “object_a en realidad no apunta a object_b”. Le pedís al modelo que considere todo esto junto y recemos para que correctamente deduzca qué conclusiones siguen siendo válidas.

Spoiler: muchas veces no lo hace.

Zomer notó exactamente este patrón: “It might suggest an approach that we had already ruled out, forget that an assumption turned out to be false, or confidently continue reasoning from an observation that was no longer valid.” El problema no es que el modelo sea malo razonando —es que le estamos pidiendo que reconstruya un grafo de dependencias completo desde una transcripción lineal, cada vez que necesita actualizar su estado. Eso no escala cuando la investigación dura seis horas y tiene 40 conclusiones entrelazadas. Más contexto en seguridad con Microsoft Intune.

¿Cómo se relaciona este problema con el análisis de programas?

Acá viene lo interesante. Zomer labura en análisis de programas, y en un momento se dio cuenta de que lo que quería de un LLM durante una investigación de vulnerabilidades era exactamente lo mismo que hace un motor de análisis estático cuando procesa código: tenés hechos de entrada, reglas que derivan nuevos hechos, y cuando un hecho de entrada cambia, actualizás incrementalmente solo las conclusiones afectadas en vez de recalcular todo.

Si sabés que main() llama a parse_input() y parse_input() puede llegar a process_data(), entonces derivás que main() puede llegar a process_data(). Si después descubrís que parse_input() en realidad no llama a process_data(), un motor de análisis serio no tira todas las conclusiones a la basura y empieza de cero — sabe exactamente qué dependencias se rompieron y las invalida quirúrgicamente.

Lo que me gusta del planteo de Zomer es que admite que llegó a esto medio de carambola: “This is how I somehow ended up writing a Datalog engine for LLMs.” La idea es genuina: se preguntó por qué carajo le estamos pidiendo al LLM que mantenga estado mental cuando podemos mantenerlo nosotros en una base de datos que entiende dependencias.

¿Qué es Datalog y cómo funciona Lemmalog para mantener el estado de una investigación?

Datalog es un lenguaje de programación lógica declarativa donde en vez de escribir instrucciones paso a paso, definís hechos y reglas. El motor deriva hechos nuevos aplicando esas reglas hasta que no queda nada más por derivar — lo que se llama un punto fijo.

Un ejemplo concreto del artículo:

• Hechos de entrada: controls(attacker, object_a), points_to(object_a, object_b), kernel_object(object_b)
• Regla: si controls(X, A) y points_to(A, B) y kernel_object(B), entonces controls_kernel_object(X)
• Hecho derivado: controls_kernel_object(attacker)

La magia viene cuando points_to(object_a, object_b) resulta ser falso. Como Lemmalog trackeó que controls_kernel_object(attacker) se derivó de ese hecho entre otros, sabe exactamente que esa conclusión ahora es inválida y la elimina. Nada de “che modelo, releé las últimas 15 páginas de conversación y fijate si encontrás algo inconsistente”.

Separación de responsabilidades: el LLM hace lo difuso, Lemmalog hace lo determinista

El sistema parte el problema en dos. El LLM toma inputs desprolijos —notas en lenguaje natural, output de LLDB, fragmentos de código fuente— y los convierte en hechos estructurados. De un comentario tipo “el objeto liberado se reutiliza como destino de escritura después del free”, el modelo extrae reused_as(object_a, write_target). Una vez que la información está en la base de hechos, Lemmalog se encarga de derivar conclusiones y mantener consistencia. Si un hecho cambia, el modelo no tiene que re-evaluar nada — la base de datos ya sabe qué cayó. Cubrimos ese tema en detalle en nuestra guía completa de ChatGPT.

¿Cómo maneja Lemmalog la eliminación de hechos y el soporte múltiple?

El tema con borrar hechos en Datalog no es trivial. Imaginá que conclusion_a se derivó a partir de dos caminos independientes: hecho_1 + hecho_2 y también hecho_3 + hecho_4. Si borrás hecho_1, no podés simplemente volar conclusion_a — porque hecho_3 + hecho_4 todavía la soportan. Pero si después también borrás hecho_3, ahora sí: la conclusión se cae porque perdió todo su soporte.

Acá es donde se pone piola. Zomer implementó conteo de soporte en Lemmalog justamente porque en vulnerability research una conclusión puede tener múltiples caminos que la justifiquen. “Candidate three is exploitable” puede seguir siendo cierto aunque una primitiva de explotación en particular no funcione, si hay otra ruta independiente que llega al mismo resultado. (Esto es exactamente lo que harías mentalmente: “bueno, por acá no funcionó, pero todavía tenemos esta otra forma de llegar.”)

Procedencia: preguntarle “por qué” a la base de conocimiento

Como efecto secundario de trackear el soporte, Lemmalog puede responder consultas de procedencia. Le preguntás “¿por qué candidate_3 es explotable?” y te devuelve algo como:

• candidate_3_is_exploitable
• → depende de attacker_controls_pointer
• → depende de pointer_reaches_target

Si más tarde attacker_controls_pointer resulta incorrecto, sabés que esta conclusión se invalida. Pero además —y esto es oro puro cuando llevás horas de investigación— podés auditar si lo que el modelo está afirmando tiene sustento real en la base de hechos o es una alucinación. Zomer lo cuenta así: si una conclusión existe en Lemmalog, le podés preguntar de dónde salió; si no tiene procedencia que la respalde, no es parte del estado mantenido. No evita que el LLM alucine durante la extracción, pero hace mucho más difícil que conclusiones infundadas se filtren silenciosamente a la investigación.

¿Por qué no alcanza con una base de datos vectorial para esto?

Las bases vectoriales son útiles, no me malinterpretes. Si preguntás “¿qué encontramos sobre este allocation path?”, la búsqueda semántica es justo lo que necesitás. Pero —y acá está la diferencia clave— “cosine vibe similarity” y “verdad actual” no son lo mismo.

Una base vectorial puede devolverte object_a points to object_b porque es relevante para tu pregunta. Lo que no sabe es que ese hecho fue refutado dos horas después, ni que cinco conclusiones dependían de él y por lo tanto tampoco deberían considerarse válidas. Zomer lo plantea clarito: hay dos problemas distintos escondidos bajo la palabra “memoria”. El primero es “¿qué información del pasado es relevante para esta pregunta?” —para eso las vectoriales van como piña. El segundo es “dado todo lo que aprendimos hasta ahora, ¿qué es cierto ahora?” —ahí es donde entra Lemmalog. Actualmente él combina ambas cosas: búsqueda vectorial para recuperación y Lemmalog para mantener la verdad actual. Relacionado: modelos de lenguaje con razonamiento.

¿Cómo se gestionan los cambios temporales en la investigación?

Otra sutileza: reemplazar hechos viejos por nuevos no es lo mismo que borrarlos. Imaginate que a las 11:00 creemos que primitive_a es viable, y a las 13:30 descubrimos que no lo es. Para responder “¿es viable ahora?”, solo nos importa el estado actual. Pero para entender por qué hace tres horas exploramos una estrategia de exploit en particular, el estado viejo también sirve.

Lemmalog asocia hechos con intervalos de validez. Conceptualizás el estado como viable(primitive_a) [11:00, 13:30) y not_viable(primitive_a) [13:30, ...). Podés responder “¿es viable ahora?” y también “¿por qué creíamos que era viable antes?” sin tener dos hechos contradictorios flotando y pidiéndole al LLM que adivine cuál aplica. Zomer aclara que esto no es un problema de modelo de lenguaje — es un problema de base de datos.

¿Lemmalog realmente mejora el rendimiento en benchmarks?

Probado en LongMemEval y LoCoMo —dos benchmarks diseñados para medir memoria en conversaciones largas— usando Claude Sonnet 4.6 como extractor (chunked y file-cached, con costo único por conversación) y los readers y jueces estandarizados de cada benchmark. Los resultados fueron, en palabras de Zomer, “a little better than I expected.”

Ojo, el autor es honesto: esto sigue siendo un experimento. Él mismo dice que probablemente agregó más features de Datalog de las necesarias porque “implementing Datalog features is more fun than I expected” (sí, en serio), y lo presenta más como prueba de concepto que como producto terminado. Pero los números en benchmarks estandarizados sugieren que separar la extracción difusa del mantenimiento determinista de estado es un approach que efectivamente mejora la precisión en sesiones largas.

El sistema expone un MCP server para que agentes puedan usar Lemmalog directamente, y conceptualmente podés pensarlo como un compilador extraño: el LLM es el front-end que parsea lenguaje natural a hechos estructurados, Lemmalog es la representación intermedia y el motor de análisis, y otra invocación del LLM puede convertir ese estado de vuelta a lenguaje natural o sugerir el próximo experimento. Lo gracioso es que el parser es probabilístico —todo lo que viene después no tiene por qué serlo.

Comparación entre enfoques de memoria para LLMs

Enfoque	Recuperación	Mantiene consistencia	Trackea dependencias	Soporte múltiple
Base vectorial	✓ (semántica)	✗	✗	✗
Memoria en prompt (contexto crudo)	✓ (atención)	✗	✗	✗
Lemmalog (Datalog)	✓ (híbrido con vectorial)	✓	✓	✓

¿Dónde puedo encontrar el código de Lemmalog?

El artículo de Zomer en pwning.systems detalla la arquitectura completa y los benchmarks, pero al momento de publicar esto no hay un repositorio público de Lemmalog. El autor menciona que implementó incremental evaluation, retractions, procedencia, hechos temporales, agregaciones, reconciliación de entidades, recuperación híbrida y queries on-demand, además del MCP server — todo todavía en etapa experimental. Si te interesa replicar el approach, el paper y la explicación de la metodología son suficiente punto de partida, aunque vas a tener que armarte tu propio motor Datalog si querés algo similar hoy.

Errores comunes al intentar mantener estado en agentes de LLM

Confiar en que el LLM va a “darse cuenta” de las contradicciones. Si metés 40 páginas de historial y esperás que el modelo detecte que la conclusión 7 se basaba en un hecho que después resultó falso, estás delegando razonamiento determinista a un sistema probabilístico. Lemmalog invierte la lógica: el LLM extrae hechos, la base de datos mantiene verdad. Cada uno en lo suyo. Ya lo cubrimos antes en herramientas de Google disponibles.

Usar solo búsqueda vectorial como “memoria”. La relevancia semántica no es lo mismo que verdad actual. Podés recuperar un hecho muy relevante que resulta ser falso, y el modelo no tiene forma de saberlo a menos que también recuperes la retracción (y que el embedding de la retracción sea lo suficientemente cercano al query, lo cual no es garantía).

No trackear procedencia. Cuando un agente lleva tres horas de investigación y afirma que tal candidato es explotable, querés poder preguntarle “¿de dónde sacaste eso?”. Sin un sistema que rastree dependencias, cada afirmación del modelo flota en el vacío y no tenés forma de auditar si tiene sustento o es humo.

Preguntas Frecuentes

¿Qué es Datalog y para qué sirve con LLMs?

Datalog es un lenguaje declarativo de programación lógica donde definís hechos y reglas en vez de instrucciones paso a paso. Con LLMs, sirve como motor determinista que mantiene el estado de conocimiento de una investigación, trackeando qué conclusiones dependen de qué observaciones y actualizando todo incrementalmente cuando un hecho cambia.

¿Cómo evitar que un LLM olvide conclusiones durante una investigación larga?

La estrategia de Lemmalog es no delegarle esa responsabilidad al modelo. El LLM extrae hechos estructurados a partir de inputs desprolijos (código, logs, debugger), y un motor Datalog externo mantiene las conclusiones y sus dependencias. Si un hecho cambia, el motor invalida quirúrgicamente lo afectado sin que el modelo tenga que re-leer todo el historial.

¿Se puede combinar un LLM con un motor de razonamiento formal?

Sí, ese es exactamente el approach de Lemmalog. El LLM actúa como parser probabilístico que convierte lenguaje natural en hechos estructurados, el motor Datalog hace el razonamiento determinista con esos hechos, y otra invocación del LLM puede traducir el estado resultante de vuelta a lenguaje natural o sugerir próximos pasos. Lo interesante es que solo el front-end es probabilístico.

¿Qué benchmarks se usaron para probar Lemmalog?

Se probó en LongMemEval y LoCoMo, dos benchmarks diseñados para evaluar la capacidad de mantener contexto en conversaciones extensas, usando Claude Sonnet 4.6 como extractor y los readers estandarizados de cada benchmark. Los resultados mostraron mejoras en precisión, aunque el autor lo presenta como experimento inicial, no como producto terminado.

Conclusión

Lo que Zomer armó sin querer es una idea potente que probablemente veamos adoptada en herramientas de security research asistido por IA durante los próximos meses: el LLM no debería ser responsable de mantener la consistencia de su propio conocimiento. Para entender texto, encontrar patrones y explicar subsistemas — fenómeno, nadie le gana. Pero para trackear que la conclusión C depende de los hechos A y B, y que si A resulta falso entonces C se cae — eso es un problema de bases de datos, no de modelos de lenguaje.

Lo más práctico que podés hacer hoy si trabajás con agentes de LLM en investigaciones largas es pensar dónde termina lo probabilístico y dónde empieza lo determinista en tu pipeline. La separación de responsabilidades que plantea Lemmalog —extracción difusa por un lado, mantenimiento de verdad por el otro— va a ser cada vez más relevante a medida que los agentes pasen de sesiones de 20 minutos a investigaciones que duran días. Y si además te gusta Datalog, el approach de Zomer te da una excusa perfecta para meterte.

Fuentes

• I accidentally turned LLM memory into program analysis — pwning.systems
• Motores de razonamiento formal para LLM y análisis de código — DonWeb Blog
• LLM security reports, code analysis y falsos negativos en producción — juanchi.dev