LLM记忆变程序分析：漏洞研究新思路
I accidentally turned LLM memory into program analysis
我在用LLM进行漏洞研究时，发现模型在长时间对话中容易遗忘关键结论或基于错误假设继续推理。为了解决这个问题，我尝试将LLM的记忆系统改造为类似程序分析的逻辑引擎。通过引入Datalog规则，我开发了Lemmalog，让LLM负责理解模糊的自然语言和调试输出，而由数据库负责维护结构化事实及其推导关系。这样，当某个观察结果被修正时，所有依赖它的结论会自动失效，并能追溯推导来源。这种思路让漏洞调查过程更像静态分析，既保留了LLM的灵活性，又引入了确定性推理的严谨性。
向量数据库擅长回答过去哪些信息与当前问题相关，但无法判断基于现有知识当前哪些结论依然成立。
HN 评论区
83- akkad33
有人试过用形式化验证来处理 AI 生成的代码吗？我没法说服公司采用，但我意识到，在自己的 PR 上让 Claude 本地添加一个验证步骤其实非常简单。
- sim04ful
我得出了类似的结论：LLM 真正应该只处于请求履行的两端。
1. 用户请求理解：自然语言 -> 更严谨的表示（在我这里是 Datalog）。
2. 结果解释：事实与推导出的事实 -> 自然语言。
在这两端之间，工作应该是对某种本体或形式化知识结构的机械推理。
这联系到我一直在思考的另一个原则，我称之为“风化”（Weathering）：有用的推理应该改变系统的形态。如果一个 LLM 已经推断出某种关系、映射、规则或抽象，那么重复使用应该将这种推断“磨损”进系统中，使得下一次类似的请求无需从头重新发现它。
因此，随着持续使用，一个具备风化能力的系统对于重复性工作所需的概率性智能应该越来越少。换句话说，认知的边际成本应该下降，因为智能的产物会固化成结构，从而可以被后续机械地复用和评估。
- akkad33
我曾尝试通过用关键词索引我的笔记并将其放入 SQLite 数据库，然后让 Claude 使用全文搜索来查询，以此从 Claude 那里获得长期记忆。不知道效果如何，看起来它能找到东西。我的目标是保持上下文精简，只让 Claude 索取它需要的内容。Datalog 听起来是个很棒的主意，肯定会试试。
- Animats
所以他是在用 LLM 生成存储在 'is_a' 表示法中的数据。
这太经典 AI 了。
很快他就会发现自己需要量词。然后发现 'for all'（全称量词）有时太强了，需要 'for most'（大多数）。这条路通向 Cyc。
这不是个坏主意。但它确实有历史包袱。
- keeda
非常酷。我记得有一个 HN 提交（可惜我手头一时找不到）做了类似的事情——它使用 LLM 将文章分解为一组陈述，用于构建事实和事件的实体关系图。然后它使用传统的图查询方法来查询该图，就像这里的 DataLog / Lemmalog 所做的那样。我记得它在回答基于时间线的查询方面特别有效，而当时的 LLM 在这方面很弱。
（另见 Cyc: https://en.wikipedia.org/wiki/Cyc）
我认为这类方法将成为（或者也许已经是？）将 LLM 回复有效锚定在权威数据源的基础。应该能够精确定位任何错误是源于错误的遍历还是错误的“事实”。不过，这种方法最适合具体、无歧义的事实；模糊、歧义或基于观点的信息可能仍将是 LLM 的领域。