I accidentally turned LLM memory into program analysis

{"category":"编程开发","title_cn":"LLM记忆的意外蜕变：从对话历史到程序分析引擎","content":"> 将LLM的记忆系统重构为Datalog引擎，使事实变更时结论自动失效，从而提升漏洞研究的可靠性与可解释性。\n\n## 背景：LLM在漏洞研究中的记忆困境\n\n过去几个月，我一直在尝试将LLM代理用于漏洞研究（vulnerability research）。它们在导航大型代码库、解释陌生子系统、探索潜在攻击面方面表现出色，甚至令人惊讶地擅长。然而，随着调查持续数小时，一个反复出现的问题逐渐凸显：模型会慢慢丢失我们已确立的结论。它可能建议一个已被排除的方案，忘记某个假设已被证伪，或自信地基于一个已失效的观察继续推理。\n\n显然，告诉LLM某件事是错的，并不保证它会停止相信所有依赖该错误结论的衍生判断。这种级联式的幻觉在复杂分析中尤为致命——因为推理链越长，任何一环的松动都可能导致整个结论崩塌。\n\n## 现有记忆系统的局限\n\n业界已有多种LLM记忆方案，通常的做法是：将旧对话或观察存储起来，嵌入（embedding）后，在需要时检索最相关的片段重新注入上下文。这种方法在简单场景下可行，但存在根本性缺陷：\n\n1. 重建而非维护：每次检索后，模型都需要从片段中重新推导结论，而非直接使用已确立的事实。\n2. 矛盾处理脆弱：当新旧观察冲突时（例如新发现object_a实际上不指向object_b），模型无法自动判断哪些旧结论仍有效，哪些已失效。\n3. 缺乏依赖追踪：无法回答"这个结论依赖哪些前提"，也无法在前提变化时精准撤销受影响结论。\n\n以漏洞研究为例，假设我们建立了以下事实链：\n\n- 攻击者控制object_a\n- object_a指向object_b\n- object_b是内核对象\n\n由此可推导：攻击者能控制一个内核对象。传统记忆系统会存储这些观察，并在询问时重新让LLM推导结论。但两小时后，我们在LLDB中发现object_a实际上不指向object_b，此时记忆库中同时存在矛盾事实，模型需要自行判断哪些结论仍然有效——这几乎必然出错。\n\n## 程序分析的启示\n\n这种困境让我想起了程序分析（program analysis）。在分析程序时，我们通常拥有一组关于程序的事实和一组推导规则。例如：\n\nprolog\ncalls(foo, bar)\ncalls(bar, baz)\n\n\n定义规则：若函数A调用B，B能到达C，则A也能到达C。最终计算所有可推导事实的不动点（fixed point）。更重要的是，当某个输入事实变化时，已有成熟技术可以增量更新受影响的结论，而非全量重算。\n\n这正是我在LLM漏洞研究中所期望的：当观察变化时，不希望模型从整个对话记录中重建状态并期望它注意到所有后果，而希望受影响的结论自动失效。\n\n## Datalog：声明式逻辑编程\n\nDatalog是一种声明式逻辑编程语言。不编写指令描述如何计算，而是描述事实和规则，由引擎推导新事实。\n\n事实示例：\n\nprolog\ncontrols(attacker, object_a).\npoints_to(object_a, object_b).\nkernel_object(object_b).\n\n\n规则示例：\n\nprolog\ncontrols_kernel_object(Attacker) :-\n controls(Attacker, ObjectA),\n points_to(ObjectA, ObjectB),\n kernel_object(ObjectB).\n\n\n引擎可推导出controls_kernel_object(attacker)。当points_to(object_a, object_b)被证伪时，由于controls_kernel_object(attacker)依赖该事实，引擎能精确识别并自动撤销该结论。这比把旧信息塞进prompt、期望LLM碰巧发现矛盾要可靠得多。\n\n## Lemmalog：LLM与Datalog的融合\n\n基于以上思考，我开发了Lemmalog。核心设计理念：LLM不必负责维护自己的知识。系统分为两部分：\n\n- LLM负责模糊部分：理解自然语言、源码、调试器输出等非结构化信息，将其转化为结构化事实。\n \n 例如：LLDB显示释放的对象被重用为写入目标 → freed(object_a)、reused_as(object_a, write_target)\n\n- Lemmalog负责确定性部分：管理事实库、执行规则推导、追踪依赖、处理增量更新。\n\n这种分工发挥各自优势：LLM擅长处理混乱的真实世界信息，而数据库擅长精确的逻辑推导和依赖管理。\n\n## 撤回（Retractions）的挑战\n\n添加事实相对简单：加入新事实，评估可能产生新结果的规则。但删除事实则复杂得多。考虑：\n\nprolog\na.\nb.\nc :- a.\nc :- b.\n\n\nc有两个独立的推导来源。仅删除a时不能删除c，因为b仍支持它。但若同时删除a和b，c也应消失。\n\n这在漏洞研究中至关重要：一个结论可能由多个观察支持。例如candidate_3_is_exploitable即使某个特定利用原语不成立，仍可能因另一条独立路径而保持为真。\n\n因此，Lemmalog必须追踪事实的推导历史（derivation history），在变化时更新其支持集（support set）。\n\n## 可解释性：为什么（Why）成为可能\n\n依赖追踪带来了一个额外价值：可以询问结论的来源。假设代理运行数小时后得出结论candidate_3_is_exploitable，我们可以查询其证明树（provenance）：\n\n\ncandidate_3_is_exploitable\n├── attacker_controls_pointer\n│ ├── observation_41\n├── pointer_reaches_target\n│ ├── observation_57\n└── rule_12\n\n\n若observation_41后来被证伪，我们知道该结论可能失效，且数据库会自动撤销受影响结论。\n\n这最初是为了使增量求值正确工作，但意外发现：能询问AI代理"为什么相信某事"极其有用。它解决了LLM辅助研究中常见的恼人失败模式——模型自信地说"我们已确立该指针受攻击者控制"，但实际上并非如此。若某结论的支撑事实已被撤销，数据库会明确标记，模型无法再基于失效前提推理。\n\n## 技术要点总结\n\n1. 事实与规则分离：LLM只负责从非结构化数据提取事实，逻辑推导完全由Datalog引擎完成。\n2. 增量更新：事实变化时，仅重算受影响的推导，而非全量重建。\n3. 多源支持：结论可被多个独立事实支持，部分失效不影响整体。\n4. 证明溯源：每个派生事实可追溯其完整推导链，支持可解释的AI推理。\n5. 自动失效：前提变化时，所有依赖它的结论自动撤销，避免LLM幻觉级联。\n\n## 实际意义与展望\n\nLemmalog不仅适用于漏洞研究，任何需要LLM进行长期、多步骤推理的场景都能受益：\n\n- 代码审计：持续跟踪变量流向、权限状态、污点传播。\n- 系统调试：维护关于运行时状态的精确知识，当调试器输出变化时自动更新。\n- 复杂分析：金融、法律等需要严格推理链的领域。\n\n这种架构的核心洞察是：不要用概率模型去维护确定性的逻辑关系。LLM擅长理解，不擅长记忆；数据库擅长记忆，不擅长理解。将二者结合，各司其职，才能构建真正可靠的AI分析系统。\n\n原文链接：https://pwning.systems/posts/llm-memory-program-analysis/\n"}

改写说明：

• 结构重组与深度展开：将原文按背景、问题、方案、实现、技术挑战、价值等逻辑重新组织，补充背景知识和术语解释，形成系统化技术笔记。
• 技术细节全面保留与扩展：完整保留原文所有技术要点（如Datalog规则、撤回机制、依赖追踪、provenance等），并补充增量更新、多源支持等原理说明，强化可操作性和深度。
• 专业术语与示例保留：保留原文核心示例（如object_a、controls_kernel_object等），并适当扩展解释，确保中文读者理解技术背景和推理逻辑。

分类：编程开发

关联原文链接：https://pwning.systems/posts/llm-memory-program-analysis/