Retrieval-Augmented Self-Recall의 파트 4입니다. 코드: RE-call. Part 3: the honesty guards 참고.

표준 RAG(Retrieval-Augmented Generation) 벤치마크는, 시스템이 데이터가 없는 질문에 자신 있게 답변할 때도 검색기(retriever)에게 만점 점수를 주었습니다.

이는 제 시스템의 버그가 아닙니다. 이는 해당 벤치마크들이 요구하는 것의 공백입니다. 그들 모두 같은 것을 묻습니다: 답변이 있었을 때, 그것을 가장 높은 순위로 배치했는가? 아무도 에이전트 메모리가 안전한지 결정하는 질문, 즉 _답변이 없었을 때, 그렇게 말했는가?_를 묻지 않습니다.

그래서 RE-call은 자체적인 하네스(harness)를 출시했습니다. 작동 방식과 그 하네스가 도출한 첫 번째 결과를 소개합니다.

테스트 세트: 답변할 수 없는 질문이 핵심입니다

평가는 합성 코퍼스(synthetic corpus)에 대한 14개의 답변 가능한 질문 + 5개의 답변 불가능한 질문으로 진행됩니다.

그 5개의 답변 불가능한 질문이야말로 이 하네스가 존재하는 전적인 이유입니다. 그것들은 코퍼스가 진정으로 답할 수 없는 질문이며, 여기서 올바른 행동은 삼가하는 것(abstain)입니다—즉, 가장 가까운 메모를 자신 있게 반환하는 것이 아니라 gap_warning을 발생시키는 것입니다. 표준 검색 벤치마크는 오직 답변 가능한 질문들로만 구성되어 있어,

둘 다 필요한 이유가 핵심입니다: 시스템은 뛰어난 MRR을 기록하면서도 끔찍한 FCR을 보일 수 있습니다. 답변이 존재하는 경우에는 아름답게 순위를 매기지만, 존재하지 않는 경우에는 자신감 있게 거짓말합니다. 대부분의 RAG 평가(evals)에서 그렇듯이 오직 순위 측정 지표만 본다면, 이러한 실패는 완전히 눈에 띄지 않습니다. FCR이야말로 이 문제를 수면 위로 끌어올립니다.

제거 실험: 모든 임베더 × 모든 융합 단계

이 하네스는 전체 매트릭스를 실행합니다: 각 임베더(HashingEmbedder, bge-small, voyage-3)를 각각의 **융합 구성(fusion configuration)**과 교차합니다 (dense only → hybrid → hybrid + rerank). 이를 통해 단순히 모든 파이프라인에 리랭커를 덧붙이는 것이 아니라,

이 숫자들은 메모리 내의 장난감(toy)에서 나온 것이 아닙니다. 이 숫자들은 실제 Postgres 환경에서, 의존성 감사(dependency audit)와 함께 매 커밋마다 실행되는 동일한 하네스(harness)에서 나옵니다. _결과물(findings)_을 신뢰할 수 있는 이유는 _측정(measurement)_이 재현 가능하기 때문입니다. 이것이 이 트랙의 전체적인 핵심 주장입니다: 당신의 작업이 덜 인상적으로 보이게 만드는 부분까지 포함하여 정직하게 측정하는 것입니다.

이는 좋은 연결고리가 되는데, 왜냐하면 동일한 제거 연구(ablation)가 특정 임베더(embedders)에서 제 나의 gap_warning 디자인을 쓸모없어 보이게 만든 무언가를 표면화했기 때문입니다. 저는 그것이 올 것이라고 예상하지 못했습니다.

다음 내용 (Next)

Part 5는 제가 계속해서 강조하는 발견점입니다: 저는 합리적으로 보이는 부재(abstention) 임계값을 설정하고, 임베더를 변경했으며, 거부되었어야 할 모든 쿼리가 자신감 있는 답변으로 통과하는 것을 지켜보았습니다. 왜 하드코딩된 유사도 임계값이 지뢰밭이 되는지—그리고 대신 무엇을 해야 하는지에 대한 내용입니다.

(하네스 자체는 이 글이 작성된 이후 계속 성장해 왔습니다—이제 선언적-우월성(declared-supersession) 대 타임스탬프를 점수화하며, 어떤 임계값으로도 구성상 포착할 수 없는 보류된