지난 10월 21일, 한 연구 그룹이 개인 에이전트가 사용자에게 원하는 것을 어떻게 기억하는지에 대한 벤치마크를 발표했습니다(arXiv 2610.30485). 그들은 여러 메모리 시스템을 시뮬레이션된 사용자와 비교하여, 에이전트가 적절한 순간에 올바른 선호도를 적용하는지 측정했습니다. 초록에서 나온 두 문장이 제게 와닿았습니다. 첫 번째는 “검색 기반 시스템(Retrieval-based systems) (예: Mem0, MemOS, 단순 RAG)은 메모리가 없는 경우를 능가하지 못한다”였습니다. 두 번째는 “파일 기반 메모리는 정확도를 향상시키지만 관련성 범위를 넘어선 곳에 선호도를 적용한다”는 것이었습니다.
저의 세컨드 브레인은 파일 메모리입니다. 그것은 git 레포지토리 내의 마크다운 노트이며, 에이전트가 이를 읽고, 제가 하루 동안 말한 내용을 적절한 노트로 라우팅하는 야간 작업(night job)을 수행합니다. 저는 이 시스템이 어떻게 테스트되는지에 대해 지난 9월에 글을 썼습니다(https://gil-neto.com/blog/the-index-was-lying-and-the-eval-knew). 그들의 벤치마크는 선호도(언제 질문할지, 언제 그냥 행동할지)에 관한 것이었고, 저의 시스템은 단순한 사실 관계에서 실패했습니다. 하지만, 실패의 형태가 충분히 유사했기 때문에 저는 제 자신의 수치를 확인해 보았습니다.
잘못된 아침
매일 밤, 이 뇌는 시험을 치릅니다. 알려진 답이 있는 질문 세트와 노트를 받는 답변자(answerer), 그리고 결과물을 채점하는 심사위원(judge)으로 구성되어 있습니다. 10월 28일에는 48개 중 42개를 통과했습니다. 노트 검색 계층은 10월 20일부터 매일 밤 단 한 번의 누락도 없이 작동했습니다.
같은 아침, 그것은 저에게 거짓말을 했습니다.
며칠 전, 저는 친구를 대신하여 청구서를 발행한 적이 있습니다. 고객이 저에게 돈을 지불했고, 저는 그 금액 중 친구 몫을 그녀에게 전달했으며, 이 사실을 메시지로 알려주었습니다. 야간 작업은 돈을 보내는 부분에 대한 내용은 라우팅했지만, 고객이 먼저 저에게 돈을 지불했다는 문장을 찾지 못했기 때문에 “결제가 들어왔는지 기록되지 않음”이라는 경고를 올렸습니다. 그러자 아침 브리핑은 같은 채팅 내용을 읽었고, 제 메시지를 확인했음에도 불구하고 여전히 그 경고를 해결되지 않은 항목으로 화면에 표시했습니다.
따라서 노트에는 아무것도 빠진 것이 없었다. 노트에 "미확인"이라고 적혀 있었고, 시험은 그 노트가 그렇게 말했기 때문에 "미확인"이라는 답변을 정답으로 채점했을 것이다.
시험이 측정했던 것
시험은 단 하나의 질문만 했다. 즉, 에이전트가 노트에 쓰여 있는 것을 찾을 수 있는지 여부다. 이 부분에서는 잘 수행했고, 이것이 바로 시스템이 침묵하게 된 이유이다. 일주일 동안 오답이 없다는 것은 테스트가 더 이상 찾아낼 것이 없었다는 의미였다.
하지만 시험은 노트 자체가 진실인지 아닌지는 묻지 않았다. 내 받은 편지함(inbox), 달력, 채팅방의 내용은 계속 변하는데, 노트는 요약 모델을 통해 밤에야 따라잡는다. 이 두 가지 사이의 모든 간극은 노트 자체로 구성된 시험에는 보이지 않는 영역이다.
두 번째, 더 작은 문제가 있었다. 야간 작업(night job)은 그날 학습한 내용을 바탕으로 새로운 시험 문제를 제안했고, 이것들은 내가 승인하기를 기다렸다. 28일에는 31개의 문제가 대기 중이었다. 나는 그것들을 읽지 않았기 때문에, 시험은 내가 마지막으로 신경 써서 승인했던 내용에 고정된 채 유지되었다.
제가 수정한 부분
이 두 가지 기능 모두 28일에 배포되었다.
- 검증 가능한 단일 답변을 가진 질문의 자동 제안. 하나의 사실적 답변(날짜, 금액, 이름, 상태, 기록된 결정)만 있고 그 답변의 모든 핵심 토큰이 실제로 출처 노트에 포함되어 있는 경우, 제안된 질문은 스스로 올라온다. 읽기나 결론 도출을 요구하는 질문은 여전히 나를 기다리게 하며, 만료되었거나 중복되는 것은 자동으로 제외된다. 대기 중이던 31개 문제 중 27개가 이 규칙에 따라 반영되었고 4개는 보류되었다. 이 결정 과정에는 모델이 없으므로, 매일 밤 같은 질문은 항상 같은 판정을 받는다.
- 출처를 통한 진실성 검증(Truth check). 매일 밤, 시스템이 내 메일, 달력, WhatsApp을 읽은 후, 브레인은 현재 외부 세계에 대해 주장하는 내용들(제기된 플래그, 각 프로젝트의 현재 상태, "다음 날" 라인 등)을 이 출처들을 대상으로 읽기 전용으로 검증한다. 주장은 일치함(matching), 세상과 불일치함(behind the world), 또는 증거가 없음(no evidence) 중 하나로 반환된다. '불일치'로 인정받으려면 반드시 진술 그대로의 인용구와 출처가 필요하며, 그렇지 않으면 카운트되지 않는다.
뒤에 있는 모든 주장들은 제가 기록하는 것과 같은 받은 편지함으로 들어갑니다. 따라서 그 직후 실행되는 라우팅 단계가 밤새 메모를 수정합니다.
저는 28일 오후에 처음으로 진실 확인(truth check)을 실행했습니다. 총 21개의 주장이 있었는데, 3개는 일치했고, 5개는 뒤늦게 발견되었으며, 나머지 13개는 어느 쪽에서도 증거가 없었습니다. 이는 이메일로 언급되지 않는 빌드 상태와 같은 경우에 정상적인 수치입니다. 뒤늦게 발견된 다섯 가지 사례는 모두 실제였습니다. 그날 오전에 변경된 통화 일정이 세 군데 다른 곳에 여전히 10:00으로 적혀 있었습니다. 제 메모에서 '미확인'이라고 불렀던 송장 승인 건은 실제로 작업 메일함에 번호와 금액이 들어와 있었습니다. 그리고 제가 메모에 '날짜 확인 필요'라고 기재했던 콘서트도 이미 달력에 등록되어 있었습니다.
하지만 결제는 포착하지 못했습니다. 이 주장은 증거가 없다는 답변을 받았고, 그 이유를 살펴보니 그것이 정확한 답이었습니다. 채팅 기록도, 이메일도, 달력 항목도 고객이 저에게 돈을 지불했다는 내용을 담고 있지 않았습니다. 친구에게 보낸 제 메시지는 그렇게 암시하고 있고 저는 실제로 일어났다는 것을 알고 있지만, 이것을 실제로 기록하는 유일한 장소는 제 은행 계좌이며, 이 두뇌(brain)는 제 은행 계좌를 읽지 못합니다.
같은 간극, 다른 곳에서
따라서 이 모든 것의 시작이 된 단 하나의 누락된 정보는 오직 은행 명세서에 의해서만 해결될 수 있습니다. 이것이 제가 Damasqo Flow(구 Kelaro)에서 다루고 있는 문제입니다. 회계 도구는 자체 원장(ledger)이 맞는지 확인할 수는 있지만, 여전히 은행과 불일치할 수 있으며, 중요한 검증은 바로 명세서에 대한 검증입니다. Flow는 이 검증을 중심으로 구축되었습니다.
저는 리스본의 창업자 겸 엔지니어입니다. B2B 유틸리티를 끝에서 끝까지 직접 개발하며, 최근에는 에이전트가 저를 대신하여 무엇을 결정하고 무엇을 결정해서는 안 되는지에 대한 질문에 많은 시간을 할애하고 있습니다. 제품이 필요로 하는 어떤 것이든 분할 계약(fractional) 또는 위탁 작업(contract build work)에 열려 있습니다. [email protected] 또는 gil-neto.com을 통해 연락 주십시오.