LLM 메모리를 Datalog로 바꿨더니 프로그램 분석이 됐다 (Lemmalog)

TL;DR Highlight

LLM 메모리를 Datalog 규칙으로 유지했더니 지식 갱신 문항에서 최고점이 나왔다

Who Should Read

장시간 에이전트 작업에서 이미 반증된 가정을 LLM이 계속 쓰는 문제로 고민하는 에이전트 개발자

Core Mechanics

기억은 '검색'과 '현재 참'으로 나뉜다
- 벡터 DB는 질문과 관련 있는 과거 기록을 잘 찾는다.
- 하지만 그 기록이 나중에 반증됐는지, 그 위에 쌓인 결론이 무효인지는 모른다.
LLM은 사실 추출만, 추론은 DB가 한다
- LLM이 로그·디버거 출력·자연어를 구조화된 사실로 바꾼다.
- 규칙으로 결론을 도출하고 관리하는 일은 Datalog 엔진(Lemmalog)이 한다.
사실을 빼면 결론도 자동 무효화된다
- 결론이 어떤 사실에서 나왔는지 추적해 근거가 둘 이상이면 하나가 빠져도 유지한다.
- 근거가 하나도 안 남으면 결론도 사라진다.
'왜 그렇게 믿는지' 물을 수 있다
- 모든 결론에 출처(provenance, 어떤 관찰·규칙에서 나왔는지)가 붙는다.
- 출처 없는 결론은 유지되는 상태에 들어가지 못한다.
사실에 유효 구간을 붙여 과거 상태도 보존한다
- 예: viable(primitive_a) [10:14, 12:37), not_viable(primitive_a) [12:37, ...).
- 지금 상태와 '예전엔 왜 그렇게 생각했나'를 모두 답할 수 있다.

Community Reactions

풀컨텍스트 대비 지식 갱신에서 앞섰다
- LongMemEval Knowledge Update에서 Lemmalog 0.579, PropMem 0.528, Full Context 0.202였다.
- 반면 Multi-Session은 Lemmalog 0.211로 PropMem 0.582보다 크게 낮았다.
LoCoMo 전체에서는 3위권이다
- 3회 실행 F1 0.533±0.001로 PropMem 0.605, OpenClaw 0.557, Full Context 0.542 다음이다.
- 적대적(거짓 전제) 질문은 0.707로 Full Context 0.509보다 높았다.
실패 원인은 추론이 아니라 추출 누락이었다
- Multi-Session 실패는 연결 오류가 아니라 사실이 아예 추출되지 않은 경우가 많았다.
- 추출 모델은 Claude Sonnet 4.6이고 이후 단계는 벤치마크 표준 reader·judge를 썼다.
긴 리서치에서 반증된 사실이 남는 문제는 흔하다는 경험담
- 댓글에서 Claude가 반증된 내용을 여러 곳에 기록해 두고 계속 사실처럼 쓴다는 경험이 나왔다.
- 하드웨어 장애 조사에서 배제한 원인을 LLM이 계속 되살려 반복해서 일깨워야 했다는 경험도 있었다.
결정 로그 파일로 비슷한 문제를 푼다는 경험담
- 댓글에서 CLAUDE.md로 모든 결정을 시점·맥락과 함께 파일에 기록하게 했더니 잘 동작한다는 사례가 있었다.

How to Apply

에이전트 작업 노트에 '철회 목록'을 두기
- 오늘 쓰는 CLAUDE.md나 작업 노트에 '기각된 가정'과 '그 가정에 기댄 결론' 섹션을 만들어라.
- 가정을 뒤집을 때마다 의존 결론을 같이 지우거나 '무효' 표시하도록 지시하라.
메모리를 검색용과 현재 상태용으로 나누기
- 벡터 검색 메모리는 그대로 두고, 현재 참인 사실만 담는 별도 저장소를 추가하라.
- 답변 시 현재 상태를 우선 쓰고 검색 결과는 보조로 쓰게 하라.
결론마다 근거 ID를 강제하기
- 에이전트가 결론을 쓸 때 근거 관찰 ID를 필수 필드로 요구하라.
- 근거 없는 결론은 상태에 반영하지 않도록 검증 단계를 넣어라.
'근거 확인' 지시가 거절을 부르는지 점검하기
- 환각 방지 프롬프트를 넣었다면 답할 수 있는 질문 세트로 거절률을 측정하라.
- 전제가 없으면 거절, 근거가 있으나 세기·비교·정렬이 필요하면 추론하라고 구분해 써라.

Try It

복사해서 바로 해보기

# Claude나 ChatGPT 대화 맨 앞에 붙여넣기 (논문 방법의 간이 버전: Datalog 없이 프롬프트로 흉내)

너는 조사 보조 에이전트다. 대화 내내 아래 형식의 '유지 상태'를 관리하라.
- FACTS: 번호 붙은 관찰 (F1, F2...). 각각 상태: 유효/철회
- CONCLUSIONS: 번호 붙은 결론 (C1...). 각각 근거 FACT 번호를 반드시 표기
- 규칙: FACT가 철회되면, 그 FACT에만 의존하는 CONCLUSION을 즉시 '무효'로 바꿔라. 다른 유효한 근거가 남은 결론은 유지하라.
- 근거 번호가 없는 결론은 쓰지 마라.
- 매 답변 끝에 갱신된 상태를 출력하라.

주제: {{조사 주제}}

지금부터 내가 관찰을 알려줄 테니 상태를 갱신하라. 첫 관찰: {{관찰 1}}

이어서 해 볼 것: 나중에 '{{관찰 1}}은 틀렸다'고 말한 뒤 어떤 결론이 무효가 되는지, 왜 그런지 설명하게 시켜 보라.

Terminology

Datalog사실과 규칙을 적어두면 거기서 새 사실을 자동으로 계산해 주는 선언형 언어다. 스프레드시트 수식처럼 입력이 바뀌면 결과도 따라 바뀐다.

Provenance결론이 어떤 사실과 규칙에서 나왔는지 기록한 계보다. git blame의 결론 버전이라 보면 된다.

Retraction이미 넣은 사실을 철회하는 것이다. 다른 근거가 남은 결론은 유지하고 근거가 사라진 결론만 지운다.

Incremental evaluation입력이 바뀌면 영향받는 부분만 다시 계산하는 방식이다. 빌드 시스템이 바뀐 파일만 다시 컴파일하는 것과 같다.

LongMemEval / LoCoMo긴 대화 기록에 대한 질문으로 LLM 메모리 시스템을 평가하는 벤치마크다.