我不小心把LLM记忆变成了程序分析

在过去的几个月里，我与 LLM 代理进行了相当多的接触，特别是在漏洞研究方面。他们在浏览大型代码库、解释不熟悉的子系统以及帮助探索潜在的攻击面方面变得令人惊讶。然而，一旦调查开始需要几个小时，我就会不断遇到同样的问题：模型会慢慢失去我们实际建立的轨迹。它可能表明我们已经排除了一种方法，忘记了一个假设被证明是错误的，或者自信地继续从不再有效的观察中进行推理。显然，告诉法学硕士有问题并不一定意味着它会停止相信所有依赖它的事情:)我最初开始研究内存系统是因为我想让法学硕士对复杂的漏洞研究更有用，并减少这种类型的幻觉。当然，已经有很多解决方案可以为法学硕士提供记忆。通常，这涉及将旧的对话或观察结果存储在某处，嵌入它们，然后在模型再次需要它们时检索最相关的部分。这工作得相当好，但有一些事情让我困扰。在漏洞研究期间，我不仅仅希望模型记住我们所说的话。我希望它保持我们目前所知道的。想象一下，在调查过程中，我们建立以下内容： 攻击者控制 object_a object_a 指向 object_b object_b 是一个内核对象 由此，我们可以得出结论，攻击者可以控制内核对象。正常的内存系统可以存储所有这些观察结果，并在我们询问错误的可利用性时再次检索它们。法学硕士随后得出了相同的结论。伟大的！然而，假设两个小时后我们在 LLDB 中发现 object_a 实际上并不指向 object_b ，并且我们之前的观察是基于错误的假设。此时我们的内存可能包含如下内容： object_a 指向 object_b 攻击者可以控制 object_b object_a 实际上并不指向 object_b 现在我们检索这些内存的一些子集，并希望 LLM 正确地找出哪些结论仍然有效。我开始觉得有点熟悉。这看起来像程序分析 我平时做的很多工作都涉及到程序分析。在分析程序时，我们通常有一堆关于该程序的事实以及一些从中派生出其他事实的规则。例如，假设我们知道：调用（foo，bar）调用（bar，baz）我们可以定义一个规则，规定如果一个函数调用另一个函数，而另一个函数本身可以到达第三个函数，那么第一个函数也可以到达第三个函数。最终我们计算出一个固定点，其中包含我们可以从程序中得出的所有内容。更重要的是，如果我们的输入事实之一发生变化，有很多技术可以仅更新受影响的结果，而不是从头开始重新运行所有内容。这也正是我在漏洞研究期间对法学硕士的期望。如果观察发生变化，我不希望模型从记录中重建整个调查并希望注意到所有后果。我希望受影响的结论自动失效。当从这个角度看问题时，我开始想知道为什么我们要让法学硕士一遍又一遍地重建其整个状态。如果我们只是维护它呢？这就是我最终为法学硕士编写数据日志引擎的方式:) 数据日志 在我们继续之前，简要解释一下数据日志实际上是什么可能很有用。 Datalog 是一种声明性逻辑编程语言。我们不是编写描述如何计算某些内容的指令，而是描述可以从中导出新事实的事实和规则。例如，我们可以存储以下事实：控制（attacker，object_a）。指向（对象a，对象b）。内核对象（object_b）。然后定义以下规则：controls_kernel_object ( Attacker ) :-controls ( Attacker , ObjectA ),points_to ( ObjectA , ObjectB ), kernel_object ( ObjectB )。根据我们现有的事实，引擎可以得出：controls_kernel_object（攻击者）。目前还没有什么特别令人兴奋的事情。然而，假设我们后来发现：points_to ( object_a , object_b )。是不正确的。如果controls_kernel_object(attacker)是从这个事实派生出来的，我们就确切地知道哪个结论取决于刚刚改变的观察，并且我们可以自动使其无效。这比将所有旧信息放入提示中并要求法学硕士希望注意到同样的事情要好得多。 Lemmalog 这最终变成了 Lemmalog 。基本思想是法学硕士不一定要负责维护自己的知识。相反，我将问题分为两部分。 LLM 处理模糊部分：“LLDB 显示释放的对象是 l