영수증과 함께하는 기억: 무언가를 되돌릴 수 있는 에이전트 메모리 구축하기

에이전트가 '인보이스 104는 지불되었다'고 적힌 웹페이지를 읽습니다. 그리고 그 사실을 저장합니다. 요약본(summary)이 그것을 가져갑니다. 청구서 에이전트가 인보이스를 마감 처리합니다. 그러다 누군가가 그 페이지가 위조된 것을 알아차립니다.

그 사실을 삭제하면 한 줄은 수정됩니다. 하지만 요약본에는 여전히 남아있습니다. 결정은 그대로 유지됩니다. 그리고 시스템의 어떤 것도 이전에 왜 그 사실을 믿었는지 알려줄 수 없습니다.

이것이 에이전트 메모리의 조용한 결함입니다. 대부분의 시스템은 에이전트가 무엇을 들었는지만 저장합니다. 그것이 왜 믿어졌는지는 거의 아무도 저장하지 않습니다. 그래서 증거가 무너질 때, 당신은 삭제하거나, 아니면 가장하는 것밖에 할 수 없습니다. 저는 Graph Hacks를 위해 WYSE를 구축하여 세 번째 행동, 즉 여전히 무엇이 서 있는지 정확히 파악할 수 있도록 했습니다.

믿음은 형태를 갖는다

WYSE에서 아무것도 단순한 사실(bare fact)이 아닙니다. 주장은 정당화(justification)에 의해 뒷받침되며, 정당화는 그래프의 노드입니다. 이는 매우 다른 두 가지 의미를 가질 수 있습니다:

• 대안적 증명 (OR). 결제 제공업체의 기록이나 은행 명세서 각각이 인보이스가 해결되었음을 보여줄 수 있습니다. 하나를 잃어도, 주장은 다른 것으로 살아남습니다.
• 공동 전제(Joint premises) (AND). '고객은 아무것도 빚지지 않았다'는 것은 인보이스가 해결되고 다른 미결제 인보이스가 없다는 것을 필요로 합니다. 둘 중 하나라도 잃으면, 그것은 무너집니다.

단순한 '파생됨(derived from)' 간의 엣지 그래프로는 이를 구별할 수 없습니다. 정당화 노드는 다음을 할 수 있습니다: 모든 전제를 요구하며, 여러 정당화가 하나의 주소를 가리킬 수 있습니다. 지원은 그 구조에서 유효한 관찰로부터 바깥쪽으로 계산되는 가장 적은 고정점(least fixed point)입니다. 전제가 없는 정당화는 결코 유효하지 않으며, 서로만 정당화하는 두 개의 주장은 서로를 지탱할 수 없습니다.

출처가 나빠지면 어떻게 될까

위조된 페이지를 격리하고 WYSE는 다섯 가지 일을 합니다:

1. 하나의 원자적 쓰기(atomic write)가 출처를 표시하므로, 바로 다음 읽기는 안전합니다.
2. 이는 지원을 재계산합니다. 위조된 페이지에만 근거한 인보이스 9는 실패합니다. 결제 제공업체에도 근거한 인보이스 104는 살아남습니다.
3. 검색 게이트웨이는 실패한 청구(claims)를 보류하고 그 내용을 절대 반환하지 않습니다. 오염된 문장은 메모리를 통해 모델에 도달할 수 없습니다.
4. 영향을 받은 청구에 의존했던 모든 결정에는 레이블이 지정됩니다: 수정, 보상 또는 검토입니다.
5. 해당 사건은 전체 결과와 함께 기록됩니다.

네 번째 요점이 제가 가장 마음에 드는 부분입니다. 인보이스 104는 여전히 올바른 믿음(belief)입니다. 하지만 청구 결정은 이후 잘못된 증거에 근거했으므로, 검토가 필요합니다. 믿음은 참으로 유지될 수 있지만, 결정의 근거가 더 이상 받아들여지지 않을 수 있습니다. 오직 사실만을 추적하는 시스템은 이를 말할 수 없습니다.

세 개의 에이전트, 하나의 이메일

교차 검증(Corroboration)에는 함정이 있습니다. 만약 세 명의 에이전트가 공급업체의 새 은행 계좌를 확인한다면, 이는 세 표처럼 보입니다. 하지만 세 에이전트 모두가 동일한 손상된 이메일을 읽었다면, 그것은 하나의 출처(source)일 뿐입니다.

WYSE는 각 청구의 근본 관찰(root observations)들 사이에서 투표 수(votes)가 아닌 고유한 출처 수를 계산합니다. 벤치마크에서는 표 계산이 진실이 1인 경우에도 10개의 확인을 보고하지만, WYSE는 1을 보고합니다.

왜 그래프인가

폭발 반경(Blast radius), 선택적 생존(selective survival), 독립적인 교차 검증 및 결정 재현(decision replay)은 모두 경로에 관한 질문입니다. FalkorDB는 토폴로지(topology)를 보유하며, 모든 테넌트와 모든 에이전트에 자체 그래프를 제공하고 무결성(integrity)을 강제합니다: 고유하고 필수적인 제약 조건, 원자적 단일 쿼리 쓰기, 그리고 비교-설정 업데이트(compare-and-set updates). 영향 발견(Impact discovery)은 의존성 그래프에서 Cypher를 따라가며, 쿼리당 한 레벨씩 진행하는데, 이는 의존성이 방향을 번갈아 바꾸고 단일 가변 길이 패턴으로는 이를 따를 수 없기 때문입니다. 또한 사이클도 견딜 수 있습니다.

분할에 대해 정확히 말하자면: 지원 평가 자체는 로드된 연결 그래프 위에서 애플리케이션 내에서 실행됩니다. Cypher와 알고리즘은 리포지토리(repository)에 작성되어 있습니다.

작동하는가? 속이는 것을 잡으려고 시도했습니다.

저는 씨앗 기반의 벤치마크를 구축했습니다: 12개의 소스 중 3개가 손상된, 70개의 주장(claims)과 20개의 결정(decisions)으로 구성된 계층적 증거 그래프입니다. 정답은 엔진 코드를 절대 가져오지 않는 약 30줄 분량의 집합 논리(set logic) 오라클에서 나옵니다. 세 시스템이 동일한 입력을 받습니다: 소스 출처가 지정된 일반 메모리, 삭제 연쇄 기반선(delete-cascade baseline), 그리고 WYSE입니다. 총 20개 이상의 시드에 걸쳐 다음과 같습니다:

다음으로, 제가 건너뛰지 않고 읽어주셨으면 하는 부분입니다. 두 번째 실행에서, 대체 증명(alternative proofs)의 절반이 비밀리에 손상된 소스의 미러(mirror)로부터 나오고, 시스템들은 주된 것(primary)에 대해서만 통보받습니다. 삭제 연쇄는 아무런 오염 주장도 제공하지 않습니다. 왜냐하면 모든 것을 다운스트림에서 삭제하기 때문입니다. WYSE는 17.7%를 제공합니다. 그 안전성은 독립성이 실제라는 것에 달려 있는데, 숨겨진 미러가 그것을 깨뜨립니다. 여전히 진정으로 잘못된 모든 결정을 플래그했지만, 수정이 필요했던 검토(reviews) 중 8.7%만 레이블링했습니다. 저는 이 숫자를 숨기느니 공개하고 싶습니다.

과정에서 무너진 것들

• 사일런트 트렁케이션(Silent truncation). 20,000개의 노드와 일치하는 쿼리가 오류 없이 정확히 10,000개의 행을 반환합니다. 제 첫 번째 로더는 대규모 테넌트의 절반을 조용히 누락했을 것입니다. 이제 벌크 리드는 페이지 단위로 처리됩니다.
• 손실된 업데이트(Lost updates). 16개 및 40개의 동시 작성자 환경에서, 읽기 후 쓰기를 수행하는 작업은 오류 없이 각각 800개 중 90개와 2000개 중 112개의 업데이트를 유지했습니다. 단일 쿼리 쓰기는 모든 업데이트를 유지합니다. 이제 모든 상태 변경은 하나의 쿼리 또는 비교-및-설정(compare-and-set)으로 처리됩니다.
• 벤치마크 설계가 잡아낸 버그. 벤치마크를 설계하는 과정에서 저는 연속된 두 개의 격리(quarantine) 과정을 추적하게 되었습니다. 두 번째 과정에서는 '수정(correction)'으로 표시된 결정을 '검토(review)'로 조용히 하향 조정할 수 있었습니다. 이를 테스트한 것이 없었습니다. 이제 라벨은 사고 발생 시 심각도만 상향 이동합니다.

Limits

시나리오는 합성적이며 제가 직접 만든 생성기에서 비롯되었고, 오라클은 엔진의 지원 의미론(support semantics)을 공유합니다. 따라서 이 벤치마크는 모델이 모든 실제 배포에 적합한지를 확인하는 것이 아니라 구현 자체를 테스트합니다. 지연 시간은 테넌트당 70개의 클레임에서 측정되었으며, 엔진은 전체 테넌트를 로드하므로 대규모 테넌트는 비용이 더 많이 들 것입니다.

Try it

저장소에는 고정된 FalkorDB 이미지가 포함되어 있으며, 엔드투엔드 데모, 신원 및 신뢰 계층이 인자가 아닌 MCP 서버가 12개의 도구를 가지고 있고, 82개의 테스트가 있습니다.

• 코드: https://github.com/bitbyrizbit/wyse
• 방법 및 결과: docs/BENCHMARK.md

Graph Hacks의 Track 02를 위해 단독으로 구축되었습니다. AI 코딩 어시스턴트는 설계 검토 및 초안 작성에 사용되었으며, 모든 쿼리와 설계 결정은 제가 설명할 수 있습니다.

이유를 기억하세요.