Executive Summary
여러 세션에 걸쳐 일하는 에이전트는 쌓인 대화가 정해진 토큰 예산을 넘으면 저장한 것을 버려야 한다. 예산을 조일수록 정확도가 얼마나 깎이는지를 그린 곡선은 이미 여러 편 나와 있는데, 그 숫자 하나에 고칠 곳이 정반대인 두 가지 실패가 섞여 있다. 필요한 근거가 이미 퇴출돼 없을 수도 있고, 저장소에 남아 있는데 검색이 못 찾아왔을 수도 있다. 9월 8일 arXiv에 올라온 이 논문은 그 둘을 질문 하나 단위로 갈라 재는 장치를 내놓는다.
방법은 지운 것을 도로 넣어 보는 것이다. 퇴출이 끝난 저장소에서 틀린 질문을 골라 그 질문의 정답 근거를 읽기 시점 맥락에 되돌려 넣고, 같은 모델을 같은 설정으로 다시 돌린다. 답이 맞게 뒤집혔는지와 그 근거가 퇴출됐었는지를 함께 보면 오답이 세 칸으로 갈린다. 예산이 넉넉해 보이는 8만 토큰에서도 복원으로 정답이 된 오답 가운데 지워진 근거 탓이 0.60에서 0.73이었고, 8천 토큰에서는 네 정책 모두 1.00이 됐다.
5절까지는 논문이 잰 것과 저자가 스스로 그어 둔 유보를 따라간다. 6절에서 데이터 거버넌스의 삭제 결정으로 옮겨 적는 부분은 논문에 없는 이 글의 해석이다.
주요 수치
출처: Chen Shen, What Eviction Destroys: A Restore-Counterfactual Audit of Forgetting in Agent Memory, arXiv:2609.08279(2026) 표 1 및 §5, 부록 C
0.60~0.73
8만 토큰에서 복구 불능이 차지한 몫
복원으로 정답이 된 오답을 분모로 잰 네 정책의 값
1.00
8천 토큰에서 네 정책 전부
검색을 고쳐 되살릴 오답이 사실상 남지 않는 지점
98%
남은 저장소를 통째로 넣어도 그대로 오답
복구 불능 2,276건 가운데 45건만 뒤집혔다
+0.29~+0.33
읽기 방식만 바꿨을 때 벌어진 격차
8만 토큰 세 정책, Holm 보정 뒤에도 유의(p=.007)
한 숫자에 서로 다른 두 실패가 섞여 있다
에이전트가 며칠, 몇 주에 걸쳐 한 사람을 상대하면 겪은 것이 맥락 창보다 빨리 불어난다. 그래서 메모리 파이프라인은 무엇을 적을지, 그중 무엇을 남기고 버릴지, 필요할 때 어떤 기록을 꺼내 읽을지를 차례로 정한다. 예산이 넘쳐 저장한 것을 골라 버리는 이 단계를 논문은 퇴출이라 부른다. 예산을 조일 때 정확도가 얼마나 깎이는지를 그린 곡선은 이론에서도 실측에서도 이미 나와 있다. 그 곡선은 손실의 크기를 말하지만 손실의 구성은 말하지 않는다.
이 대목에 쌓인 선행 연구가 적지 않다. 어디까지 잊어도 되는지의 최적 경계는 이미 이론으로 세워졌고, LoCoMo와 LongMemEval에서 비용과 정확도의 곡선을 실측한 연구도 나와 있으며, 예산 안에서 무엇을 남길지를 아예 학습시키는 방법까지 제안됐다. 그중 실측 연구는 최종 정확도를 보고하지만, 그 정확도가 깎인 이유까지 나누지는 않는다. 실패를 나눠 본 시도도 있다. WhenLoss는 기록 단계와 검색 단계 중 어느 쪽 몫이 큰지를 전체 합으로 갈랐고, 저자가 가장 가깝다고 꼽는 연구는 에이전트가 스스로 쓴 저장소에 정답을 짝지어 넣어 기록과 검색과 활용의 실패를 진단했다. 다만 그 연구가 겨냥한 것은 직접 꾸민 시나리오에서의 노화 기제이지 예산이 정한 퇴출이 아니다. 이번 논문이 앞선 연구와 갈라지는 곳은 가르는 단위가 전체 합이 아니라 질문 하나라는 점, 그리고 원인을 퇴출 결정 하나에 귀속시킨다는 점이다.
같은 예산에서 정확도가 똑같이 떨어져도 원인은 둘로 갈린다. 질문에 필요한 근거가 이미 저장소에서 밀려났다면 어떤 검색기를 붙여도 돌아오지 않고, 더 보존하는 것 말고는 길이 없다. 근거가 살아남았는데 검색이 못 집어 왔다면 보존을 늘릴 이유가 없고 검색을 고치면 된다. 논문 서론은 이 상황을 한 문장으로 요약한다.
“A frontier point conflates two failure modes with opposite remedies. … An all-recoverable frontier and an all-irreversible frontier can look identical on the accuracy axis but require different interventions.”
퇴출을 아예 끄고 재 보면 구분이 왜 필요한지가 더 분명해진다. 아무것도 버리지 않은 기준선에서도 오답 95건이 남았고, 그중 38건은 근거가 저장소에 멀쩡히 있는데 검색이 놓친 것이었다. 파괴가 0인 조건에서도 검색은 새고 있었다는 뜻이다. 반대로 예산을 조인 조건에서 정확도가 떨어졌을 때, 그 하락분이 새 검색기로 메워질 몫인지 아닌지는 곡선만 봐서는 알 수 없다.
지운 것을 도로 넣어 보고 판정한다
더 간단한 대안부터 지워 두는 편이 낫다. 퇴출을 켠 정확도에서 끈 정확도를 빼면 손실이 한 숫자로 요약되지만, 그 숫자는 퇴출이 입힌 피해와 어긋날 수 있다. KV 캐시를 다룬 최근 연구에서는 캐시를 골라 버린 쪽이 통째로 남긴 쪽보다 성적이 좋게 나오기도 했다. 합산한 차이 하나로는 무엇이 부서졌는지 셀 수 없다.
복원 대조(restore counterfactual)는 질문 하나하나에 거는 개입이다. 퇴출이 끝난 저장소 위에서 모델이 틀린 질문을 고르고, 그 질문의 정답 근거를 읽기 시점 맥락에 강제로 되돌려 넣은 다음, 같은 모델을 같은 프롬프트와 같은 온도로 다시 돌린다. 읽기 모델도 채점 모델도 랭커도 그대로 두므로 달라지는 것은 근거의 유무 하나뿐이다. 정답 여부가 어떻게 바뀌었는지를 restore_gain(q) = acc(복원) − acc(정책)으로 적고, 값은 −1, 0, 1 셋 중 하나다.
판정은 두 물음의 조합으로 끝난다. 답이 틀림에서 맞음으로 뒤집혔는가, 그리고 그 질문의 정답 근거 중 하나라도 퇴출됐는가. 뒤집혔고 근거가 퇴출됐으면 복구 불능이다. 파괴가 일어났고 고칠 방법은 보존을 늘리는 것뿐이다. 뒤집혔는데 근거가 전부 남아 있었다면 복구 가능이다. 검색이 놓친 것이니 검색기를 고치면 된다. 근거를 다 되돌려 줘도 여전히 틀리면 잔여로 따로 센다. 증거를 손에 쥐고도 읽기 모델이 못 쓴 경우다.
논문이 든 실제 사례는 통근 시간을 묻는 질문이다. 8만 토큰 예산에서 선입선출 정책이 그 기록이 담긴 세션을 밀어냈고, 모델은 “모른다”고 답했다. 밀려난 세션을 도로 넣자 “편도 45분”이라는 정답이 나왔다. 근거 하나가 퇴출된 상태에서 복원이 답을 뒤집었으니 복구 불능이고, 고칠 자리는 그 세션을 남겨 두는 것뿐이다.
“모른다”는 답도 지시받은 대로 나온 것이다. 부록에 실린 읽기 프롬프트는 주어진 기억 조각에 답이 정말 없으면 정확히 “모른다”라고만 답하라고 적어 두었다. 그래서 저 답은 모델이 얼버무린 흔적이 아니라 근거가 사라진 자리의 표시로 읽힌다.
나머지 두 칸에도 실제 사례가 붙어 있다. 복구 가능 쪽은 잡지 구독이 몇 개냐고 묻는 질문이다. 정답은 둘인데 퇴출을 하지 않은 조건에서도 모델은 “하나(뉴요커)”라고 답했다. 상위 60개를 뽑는 검색이 뉴요커 항목만 가져오고 다른 하나를 빠뜨린 탓이라, 놓친 항목을 도로 넣자 “둘(뉴요커와 아키텍처럴 다이제스트)”로 고쳐졌다. 버린 것이 하나도 없는 조건에서도 오답이 난다는 점에서 이 칸의 성격이 드러난다.
이 분해에는 분모를 좁히는 손질이 하나 더 들어간다. 깨끗한 정답 근거를 통째로 줬을 때 원래 맞히는 질문만 센다. 그러면 채점된 오답은 “모델이 못 풀 질문이었다”가 아니라 “예산이 근거에 무엇을 했는가”를 가리키게 된다. LongMemEval-S의 근거 라벨 470문항에서 답을 유보해야 하는 문항을 뺀 뒤 이 조건을 걸어, 기준 격자의 분모는 336문항이 됐다. 세션 이력은 한 건당 10만 토큰 안팎이라 8만·3만·8천 토큰 세 예산이 모두 실제로 퇴출을 일으킨다.
측정을 본격적으로 시작하기 전에 저자는 장치 자체가 헐겁지 않은지부터 확인했다. 복원이 오히려 맞던 답을 틀리게 만드는 −1도 값으로 열려 있어서, 40문항 보정에서 그 비율부터 쟀다. 상한 0.05에 대해 실측은 0.00이었고, 채점 모델의 반복 일치도는 기준 0.90에 대해 1.00이었다. 설령 −1이 나오더라도 복구 불능 값은 0에서 잘리므로 복원이 답을 망친 경우가 파괴로 세어지지는 않는다. 정답이 담긴 세션 번호는 읽기 모델에도 채점 모델에도 보여 주지 않고, 되돌려 넣는 분량에는 2,000토큰 상한을 두는데 실제 정답 근거 묶음은 가장 큰 것도 1,000토큰 안팎이라 잘려 나가는 경우가 없다.
8만 토큰에서도 7할은 지워진 근거였다
논문이 머리기사로 쓰는 비중은 복원으로 정답이 된 오답만 모아 놓고 그 안에서 복구 불능이 차지하는 몫이다. 잔여는 빠져 있다. 잔여까지 넣은 세 칸 몫으로 보면 8만 토큰에서 선입선출·무작위·중복 인지형은 0.40에서 0.44 사이로 내려간다. 같은 표가 두 가지로 읽히므로 수치를 옮길 때는 어느 쪽 분모인지를 늘 함께 적어야 한다.
아래는 예산이 가장 넉넉한 8만 토큰에서, 실제 조건인 상위 60개 검색으로 잰 값이다. 퇴출을 하지 않은 기준선과 고의로 근거를 밀어내는 대조군을 같이 놓아야 가운데 네 줄이 읽힌다.
| 퇴출 정책 | 오답 | 복구 불능 | 복구 가능 | 잔여 | 복구 불능 몫 |
|---|---|---|---|---|---|
| 퇴출 없음(기준선) | 95 | 0 | 38 | 57 | 0.00 |
| 선입선출(FIFO) | 124 | 55 | 22 | 47 | 0.71 |
| 무작위 | 387 | 168 | 61 | 158 | 0.73 |
| 중복 인지형 | 127 | 51 | 25 | 51 | 0.67 |
| LLM 중요도 | 102 | 34 | 23 | 45 | 0.60 |
| 고의 파괴 대조군 | 244 | 204 | 0 | 40 | 1.00 |
8만 토큰 예산, 상위 60개 검색 조건, 주 읽기 모델 GPT-4o-mini 기준. 마지막 열은 복구 불능 ÷ (복구 불능 + 복구 가능)이다. 분모는 336문항이며 무작위만 시드 3개를 합쳐 1,008, LLM 중요도는 별도 격자라 332다. 선입선출의 0.71은 신뢰구간 .61~.81, LLM 중요도의 0.60은 .47~.72로 0.5를 걸친다. 출처: arXiv:2609.08279 표 1.
예산을 조이면 구성이 한쪽으로 쏠린다. 3만 토큰에서 복구 불능 몫은 0.98에서 0.99, 8천 토큰에서는 네 정책 모두 1.00이다. 비중보다 건수가 더 분명하다. 선입선출의 복구 가능 오답은 22건에서 3건을 거쳐 0건이 됐고, 중복 인지형은 25건에서 3건을 거쳐 1건, LLM 중요도는 23건에서 4건을 거쳐 0건이 됐다. 예산이 좁아질수록 검색을 고쳐 되살릴 오답 자체가 사라진다. 논문이 토론 절에서 내놓는 처방도 같은 방향이다. 예산이 빠듯한 구간에서는 보존을 먼저 늘리지 않는 한 검색기를 손봐도 얻을 것이 거의 없다.
질문의 생김새도 구성을 가른다. 한 세션 안에서 답이 끝나는 질문은 95% 안팎이 복구 불능으로 떨어지고, 여러 세션을 넘나들거나 시간을 따져야 하는 질문은 잔여가 23%에서 34%를 차지한다. 읽기 모델을 더 강한 GPT-5.4-mini로 바꿔도 기각 개수와 정책 순서는 그대로였고, 달라진 것은 잔여 칸 하나뿐이었다.
검색 방식을 밝히지 않으면 견줄 수 없다
조건을 둘로 나눈 이유는 앞선 연구에서 왔다. 고정된 검색기는 저장소에 멀쩡히 남아 있는 근거도 놓친다는 사실이 이미 여러 번 확인됐다. 그러면 퇴출의 효과는 검색 조건을 통제한 상태에서만 해석할 수 있고, 논문은 그 조건 차이 자체를 결과의 하나로 올렸다.
논문은 읽기 시점 조건을 두 가지로 나눠 같은 실험을 두 번 돌렸다. 하나는 살아남은 정답 근거를 무조건 읽히는 강제 주입이고, 다른 하나는 어휘 겹침으로 상위 60개를 뽑는 고정 랭커다. 앞쪽은 파괴만 남기려고 만든 조건이라 복구 가능 칸이 정의상 비고, 복구 불능 몫은 언제나 1.00으로 나온다. 이 1.00은 발견이 아니라 항등식이다. 논문도 그 점을 분명히 하고, 실제 숫자는 뒤쪽 조건에서만 나온다고 못 박는다.
두 조건의 차이 자체가 결과다. 8만 토큰에서 복구 가능 몫의 격차는 선입선출 +0.29(신뢰구간 .19~.39), 무작위 +0.27, 중복 인지형 +0.33이었고 Holm 보정 뒤에도 유의했다(p=.007). 퇴출이 없는 기준선에서는 격차가 +1.00이다. 3만 토큰의 무작위에서도 작은 격차(+0.019)가 보정 뒤 살아남았다. 퇴출이 있는 정책·예산 조합 12개 가운데 4개에서 기각됐고, 퇴출을 하지 않은 3개 조합은 강제 주입에서 분모가 비어 이 셈에서 빠진다. 격차가 8만 토큰에 몰리는 이유는 단순하다. 예산이 더 좁아지면 근거가 아예 파괴되므로 검색이 놓칠 것도 남지 않는다.
같은 예산에서 잰 정확도라도 읽기 시점 검색 설정이 다르면 두 수치는 애초에 같은 축에 놓이지 않는다. 논문이 기여 목록에 올리고 토론에서 다시 되풀이하는 문장은 이렇다. “budget–accuracy frontiers are not directly comparable unless the retrieval regime is reported.” 예산과 정확도만 적힌 그래프 두 장은, 읽기 방식이 적혀 있지 않으면 비교의 재료가 되지 못한다는 뜻이다.
이 요구는 논문 자신에게도 그대로 걸린다. 여기서 쓴 랭커는 어휘 겹침만 보는 고정형이라, 복구 가능으로 분류된 몫은 그 랭커가 놓친 양이지 검색 일반의 한계가 아니다. 더 나은 랭커를 쓰면 그 오답들은 애초에 오답으로 남지 않으므로, 복구 가능 칸은 줄고 복구 불능이 차지하는 몫은 올라간다. 그래서 이 감사를 자기 파이프라인에 옮길 때 먼저 기록해야 할 것은 예산이 아니라 읽기 시점 설정이다. 지난달 수치와 이번 달 수치를 견줄 때도 같은 조건이 붙는다.
어느 정책이 나은지는 답하지 않는다
이 절의 비교는 사전에 등록해 둔 검정이 아니다. 처음 등록한 통계는 강제 주입 조건에서 복구 불능 몫을 보는 것이었는데, 그 조건에서는 값이 구조상 1.00에 고정돼 어떤 차이도 잡아낼 수 없었다. 저자는 이를 퇴화한 통계라고 부르며 측정이 끝난 뒤 검정을 바꿨다고 밝히고, 바뀐 쪽에 탐색적 분석이라는 표시를 붙여 둔다. 등록한 대로 남은 확증 검정은 둘이다. 분해가 제대로 정의됐는지, 그리고 두 검색 조건 사이에 격차가 있는지를 본다.
정확도를 맞춰 놓고 정책끼리 견주면 차이가 보이지 않는다. 정확도 차이 0.05 안에서 짝지은 기준 정책 세 쌍을 세 예산에서 비교한 9건 모두 복구 불능 비율의 차이가 검출되지 않았고, 신뢰구간이 전부 0을 걸쳤다. 질문을 보지 않고 1점에서 10점으로 일반적 중요도만 매기는 LLM 중요도 정책도 정확도가 맞는 6건에서 마찬가지였다.
8만 토큰에서 LLM 중요도의 복구 불능 몫이 0.60으로 가장 낮게 찍히지만, 그 비교는 정확도가 맞지 않는다. 0.69 대 0.62 이하로 캘리퍼 밖이라 비교 대상에서 빠진다. 논문은 이 숫자를 기술적 관찰로만 두고 정책 순위로 읽지 말라고 선을 긋는다. 정확도가 맞는 3만·8천 토큰에서는 기준 정책들과 차이가 잡히지 않았다. 그 정책이 쓰는 프롬프트는 부록에 원문이 실려 있다. 기억 조각 하나가 사용자에 대해 기억해 둘 만큼 일반적으로 중요한지를 1점(시시한 잡담)에서 10점(오래 갈 사실이나 선호, 약속)으로 매기라는 지시인데, 나중에 무엇을 물어볼지는 알려 주지 않는다.
그렇다면 장치가 무딘 탓일까. 정답 근거를 기준선의 약 세 배 속도로 일부러 밀어내는 대조군을 넣었더니 9건 비교 전부에서 유의한 차이가 나왔다. 장치가 큰 파괴를 놓치지는 않는다는 확인이다. 다만 논문은 이 대조들이 정확도를 맞춘 쌍이 아니어서 캘리퍼 안의 검출력을 세운 것은 아니라고 스스로 단서를 단다. 맞춘 비교의 민감도는 짝 부트스트랩 신뢰구간 반폭인 1.2%p에서 6%p다. 그래서 논문의 결론 문장은 “차이가 없다”가 아니라 “이 해상도에서는 차이가 검출되지 않았다”이다. 동등성을 주장하려면 별도의 검정이 필요하다며 후속 과제로 남겼다.
잔여 칸은 읽기 모델 쪽 문제로 정리된다. 근거를 다 줘도 틀리는 경우는 거의 세션을 넘나드는 세기와 합산에서 나온다. 한 해 자전거 지출 합계가 185달러인 질문에 65달러라고 답한 사례가 그렇다. 채점이 지나치게 엄격해서 틀렸다고 볼 수 있는 경우는 보수적으로 잡아도 20% 이하다. 채점 프롬프트가 날짜와 숫자의 값이 맞아야 한다고 요구하므로 65달러를 185달러로 봐줄 여지가 없다. 더 강한 읽기 모델로 바꾸면 이 칸은 절반 아래로 줄고(퇴출 없음·8만 토큰·강제 주입에서 59건이 28건으로), 고쳐진 것이 정확히 그 합산 오류들이었다.
복구 불능 판정이 부풀려진 것은 아닌지도 따로 쟀다. 복구 불능으로 분류된 2,276건 가운데 87%는 정답 근거가 한 조각도 살아남지 않은 경우였다. 남아 있던 근거만 되돌려 넣으면 0.3%가 복구 가능으로 재분류되고, 남은 저장소를 통째로 밀어 넣어도 2.0%만 뒤집힌다. 98%는 저장소에 남은 어떤 내용으로도 답이 되지 않았다는 뜻이다. 길이가 같은 무관한 텍스트를 정답 근거 자리에 넣는 위약 검사에서는 8.3%가 뒤집혔고, 진짜 근거를 넣었을 때는 100%가 뒤집혔다. 자리 효과가 아니라 근거의 유무가 답을 갈랐다.
규정이 시킨 삭제에도 같은 물음이 남는다
여기까지가 논문이다. 데이터를 다루는 쪽에서 보면 낯익은 결정이 하나 보인다. 보존 기간이 끝났거나 삭제 요청이 들어오면 우리는 레코드를 지운다. 무엇을 지웠는지는 로그에 남지만, 그 삭제가 나중에 무엇을 못 하게 만들었는지는 어디에도 남지 않는다. 삭제 대상을 특정하는 문제는 이 블로그에서 이름표 없는 기억은 지울 수 없다로 다룬 적이 있는데, 이번 논문이 겨냥하는 곳은 그다음이다. 삭제가 이미 집행된 뒤에 남는 물음이다.
저자도 윤리 절에서 이 문제를 직접 짚는다. 프라이버시와 데이터 보호 요구 때문에 잊는 것이 반드시 필요할 때가 있고, 그럴 때는 더 보존하는 편이 오히려 허용되지 않는다고 적은 다음 이렇게 잇는다.
“The instrument quantifies the task cost of a forgetting decision without prescribing whether information should be retained or deleted; the same decomposition can audit whether a required deletion incurs recoverable or irreversible task loss.”
지워야 하는지 아닌지는 이 계측이 판정하지 않는다. 다만 이미 집행된 삭제가 되돌릴 수 있는 손실을 냈는지는 잰다. 에이전트 파이프라인 밖으로 옮겨 볼 만한 조각은 세 가지다.
- 삭제 로그와 별개로 “무엇을 못 하게 됐는가”를 재는 자리를 둔다. 지운 목록이 아니라 지운 뒤 실패한 작업을 기준으로 헤아려야 손실이 보인다.
- 실패한 작업을 두 칸으로 나눈다. 어딘가에서 다시 끌어오면 되는 것과, 원본이 없어 되돌릴 수 없는 것은 대응이 정반대다. 앞쪽에 인덱스를 더 붙이는 일은 뒤쪽에 아무 도움이 되지 않는다.
- 검색 설정을 결과와 함께 기록한다. 같은 파이프라인의 지난 분기 수치와 이번 분기 수치도 꺼내 읽는 방식이 달라졌다면 나란히 놓을 수 없다.
옮겨 쓰기 전에 논문이 그어 둔 선도 함께 봐야 한다. 이 감사는 질문마다 정답 근거 라벨이 있어야 돌아가므로 벤치마크 분석에 쓸 수 있고, 운영 중인 시스템에 그대로 붙이지는 못한다. 시험한 퇴출 방식도 상용 메모리 시스템이 아니라 정책 클래스를 흉내 낸 것이다. 벤치마크 하나, 읽기 모델 둘, 주 채점 모델 하나로 잰 결과이고 채점 모델은 읽기 모델과 공급사가 같다. 별도 채점 모델과의 일치율은 95.7%(코헨의 카파 0.90)였지만 그 채점 모델도 같은 회사 제품이라, 저자는 다른 공급사의 모델이나 사람 채점이 더 강한 확인이 될 것이라고 적었다. 엇갈린 건수는 대부분 새 채점 모델이 더 엄하게 준 쪽이었다. 범위도 좁혀 읽어야 한다. 답을 유보해야 하는 문항은 되돌릴 근거 자리가 없어서 처음에 걸러 냈으므로, 에이전트가 모를 때 모른다고 답하는지는 이 감사가 말해 주지 않는다.
Editor's Note
페블러스가 데이터 품질을 진단할 때 자주 마주치는 상황이 “예전에 있었는데 지금은 없다”는 말이다. 그 말을 들으면 우리가 먼저 물어보는 것은 지금 그게 어딘가에 남아 있는데 못 찾는 상태인지, 아니면 정말로 사라진 상태인지다. 두 경우에 해야 할 일이 전혀 다른데, 대개는 그 구분이 기록으로 남아 있지 않아 양쪽을 다 해 보는 수밖에 없다.
여기까지 읽어 주신 데 감사드린다. 원문은 arXiv:2609.08279에서 볼 수 있고, 평가 코드와 질문별 기록은 github.com/megagonlabs/restore-counterfactual에 공개됐다. 지운 뒤에도 검색 결과가 흔들리는 반대편 사례는 벡터 DB에서 지운 문서가 검색 결과를 계속 흔들었다에 적어 두었다. 삭제한 레코드가 나중에 필요해졌을 때, 그것이 검색 실패인지 영구 손실인지 가르는 장치를 이미 운영하는 팀도 있을 것이다. 무엇을 기준으로 나누었는지 나눠 주시면 좋겠다.