베이스라인 점수가 0.000이라고요? 승리를 발표하기 전에, 제가 현재 실행하고 있는 체크리스트를 확인해 보세요. 베이스라인에서 0점이 나오는 것은 거의 결코 결과가 아니기 때문입니다. 그것은 대개 당신의 하네스 (harness) 문제입니다.

이번 주에 저는 r/Rag의 한 빌더가 드물게 행동하는 것을 지켜보았습니다. 그는 자신의 메모리 라이브러리를 일반적인 RAG와 벤치마킹하여 승리를 기대했지만, 세 번의 null 결과를 얻었고, 승리 대신 혼란스러운 결과들을 게시했습니다. 그가 발견한 버그 중 두 가지는 매우 흔하고 조용해서, 모든 RAG 또는 에이전트-메모리 (agent-memory) 벤치마크는 구조적으로 이를 차단해야 한다고 생각합니다. 이 포스트는 해당 스레드에서 도출된 체크리스트입니다.

버그 1: 각 팔(arm)의 컨텍스트 예산(context budget)이 다름

그의 첫 번째 실행은 k=20개의 문장 단위 히트(hits)를 검색하는 메모리 팔(arm)과 전체 세션을 반환하는 BM25 팔(arm)을 비교했습니다. 서류상으로는 동일한 "top-k"였습니다. 하지만 글자 수로 따지면, 한쪽 팔은 1.3k의 컨텍스트를 얻었고 다른 쪽은 11.9k를 얻었습니다. BM25가 극적으로 더 좋아 보였습니다.

일단 예산을 맞추자, 메모리 팔(arm)의 정확도는 0.28에서 0.59로 올라갔고 순위가 뒤바뀌었습니다. 원래의 결과는 입도(granularity)라는 가면을 쓴 예산 차이였습니다.

해결책은 당황스러울 정도로 간단합니다. 각 팔(arm)별로 모든 정확도 수치 옆에 글자 수 또는 토큰(token) 단위의 컨텍스트 크기를 출력하세요. 비교 시 예산의 동일성(budget parity)이 명시되지 않는다면, 그 숫자는 아무런 의미가 없습니다. 청크(Chunked) 대 전체 문서(whole-document) 비교는 특히 이러한 오류에 취약한데, "top-k"가 10배의 예산 차이를 눈앞에서 숨겨버리기 때문입니다.

버그 2: 깨끗한 로그에도 불구하고 0.000을 기록한 베이스라인

그는 경쟁 관계에 있는 메모리 도구를 베이스라인으로 실행했습니다. 점수는 0.000이었습니다. 그는 더 강력한 추출 모델(extraction model)로 다시 실행했습니다. 로그는 깨끗했지만 결과는 다시 0.000이었습니다. "경쟁사가 부하 상황에서 메모리를 버린다"라고 발표하고 싶은 매우 유혹적인 상황이었습니다.

그것은 그의 버그였고, 두 번이나 반복되었습니다. 그의 하네스 (harness)는 주입된 증거를 잘라버리며 인입(ingestion) 전 각 세션을 6,000자로 잘라냈습니다. 또한 그는 파라미터가 top_k=인 API에 limit=를 전달하고 있었기에, 그의 설정은 조용히 무시되었습니다.

두 번째 사례는 별도의 문단으로 다룰 가치가 있습니다. 왜냐하면 이 생태계 어디에나 존재하기 때문입니다: 에러를 발생시키지 않고 알 수 없는 kwargs(키워드 인자)를 수용하는 API들입니다. 이들은 잘못된 설정을 마치 깔끔한 손실(loss)인 것처럼 보이게 만듭니다. 벤치마크를 수행할 때, 알 수 없는 파라미터를 삼켜버리는 클라이언트는 적대적인 것으로 간주하십시오. 파라미터가 무언가 역할을 수행했을 것이라고 믿지 마십시오. 단언(Assert)하십시오: 만약 top_k를 5에서 20으로 변경했다면, 검색된 개수도 반드시 변해야 합니다. 만약 변하지 않는다면, 당신의 하네스(harness)는 아무것도 설정하고 있지 않은 것입니다.

결과를 신뢰할 수 있게 만드는 세 가지 게이트 (gates)

그 대화로부터 저는 이제 메모리 및 RAG 벤치마크를 위한 최소한의 기준으로 간주하는 하네스 구조를 도출했습니다. 실행 전에 미리 등록된, 각각 고유한 중단 메시지를 가진 세 개의 별도 활성 게이트(liveness gates)입니다.

1. 각 암(arm)별 양성 대조군 (A positive control per arm). 모든 암에는 코퍼스(corpus) 자체의 정답(ground truth)을 기반으로 구축된, 실패할 수 없는 프로브(probe)가 할당됩니다. 만약 어떤 암이라도 실행 전에 기록해 둔 임계값(threshold) 미만의 점수를 기록한다면, 전체 벤치마크는

이러한 요소들을 하나의 통합된 무결성 검사(sanity check)로 묶어버리고 싶은 유혹이 생길 것입니다. 하지만 그렇게 하지 마십시오. 게이트(gate)의 진정한 가치는 그 실패가 어떤 레이어(layer)가 고장 났는지를 지목한다는 데 있습니다. 문맥 내 증거(Evidence-in-context)가 실패한다는 것은 검색(retrieval)이 전혀 이루어지지 않았음을 의미합니다. 양성 대조군(positive control)이 실패한다는 것은 저장소(store)나 답변자(answerer)가 작동하지 않는다는 의미입니다. 효능 단언(efficacy assertion)이 실패한다는 것은 당신의 설정(configuration)이 허구라는 의미입니다. 하나의 통합된 게이트는 단지 "무언가 잘못되었다"라고만 알려줄 뿐이며, 당신 앞에는 여전히 한 시간 이상의 디버깅(debugging) 시간이 남아 있게 됩니다.

이 모든 것 아래에는 일반적인 교훈이 있습니다. 벤치마크 하네스(benchmark harness)는 기본적으로 거짓말을 하는 소프트웨어입니다. 왜냐하면 하네스가 가진 모든 버그(bug)가 충돌(crash) 대신 그럴싸해 보이는 숫자를 만들어내기 때문입니다. 이를 해결하는 규율은 에이전트 평가(agent evaluation) 전반을 해결하는 규율과 동일합니다. 시스템이 직접 건드릴 수 없는 무언가가 검증하지 않는 한, 시스템이 스스로에 대해 내리는 주장을 절대 믿지 마십시오. 실패할 것이라는 사실이 증명되지 않은 테스트는 영원히 기쁘게 통과될 것입니다.

공로를 돌리자면, 이 글을 쓰게 만든 '결과 없음(null-result)'에 관한 보고서는 전문을 읽어볼 가치가 있습니다. 작성자 본인이 자신의 양성 대조군(positive control) 덕분에 구제받기 전, 경쟁사에 대해 잘못된 발견을 절반쯤 작성하고 있었음을 스스로 깨달은 부분도 포함되어 있습니다. 이러한 내용을 공개하는 것은 승리를 공개하는 것보다 더 큰 용기가 필요합니다.

저는 Mac을 위한 로컬 우선(local-first) 어시스턴트를 구축하고 있으며, 그렇기에 매일 검색 평가(retrieval evals)에 시간을 보냅니다. 제품 홍보는 아닙니다. 이 체크리스트 자체로 충분한 가치가 있습니다.