리트리벌 시스템은 특정한 방식으로 고장난다. 청크 크기 변경, 임베딩 모델 업데이트, 리랭커 임계값 조정 — 이 중 어느 것이든 집계 지표는 그대로 두면서 좁은 쿼리 범위의 정밀도를 조용히 저하시킬 수 있다.
리트리벌 회귀 프로브는 그 범위가 프로덕션에 도달하기 전에 잡아내는 도구다.
리트리벌 회귀 프로브란
리트리벌 회귀 프로브는 매 배포 전에 리트리벌 레이어에 실행하는 고정 쿼리 세트다. 각 쿼리에는 예상 문서 ID 세트가 있다. 프로브는 precision@k — 상위 k개 검색 문서 중 예상 세트와 일치하는 비율 — 를 측정하고, 정밀도가 정의된 임계값 아래로 떨어지면 배포를 실패 처리한다.
일반 벤치마크가 아니다. 무작위 샘플도 아니다. 이미 프로덕션 장애를 일으킨 쿼리들로 구성된 큐레이션 세트로, 결정론적으로 실행되며 결과는 통과 또는 실패 둘 중 하나다.
목표는 좁다: 알려진 실패 모드가 회귀하지 않았음을 확인하는 것이다.
최소 프로브 구축
10~15개 쿼리로 시작한다. 프로브를 느리거나 유지하기 어렵게 만들지 않으면서 가장 심각한 실패 패턴을 커버하기에 충분하다.
1단계: 실제 장애에서 쿼리를 수집한다. 프로덕션 로그에서 가져온다. 시스템이 해당 쿼리에 대해 사실적으로 틀린 그럴듯한 문서를 검색했거나, 올바른 문서가 상위 k 밖에 랭크된 쿼리를 찾는다. 이것이 프로브 후보다. 합성 쿼리를 만들지 말 것 — 실제로 시스템을 고장내는 분포를 반영하지 않는다.
2단계: 예상 문서 ID를 기록한다. 각 쿼리에 대해 상위 k 결과에 나타나야 할 문서를 식별한다. 이를 예상 ID 목록으로 저장한다. 쿼리에 허용 가능한 답이 둘 이상일 수 있다 — 단일 ID가 아닌 세트로 인코딩한다.
3단계: 노이즈 밴드를 정의한다. 의미 있는 변화가 없어도 precision@k는 배포마다 약간 변동한다. 노이즈에 반응하지 않으면서 실제 드리프트를 표시하는 임계값을 설정한다. 일반적인 시작점: 마지막으로 알려진 정상 배포에서 수립된 기준선보다 precision@5가 10 퍼센트 포인트 이상 떨어지면 실패 처리. 실제 리트리벌 레이어의 안정성에 따라 조정한다.
4단계: 실행을 자동화한다. 프로브는 CI 파이프라인의 배포 전 단계로 실행되어야 한다. 실패하면 배포가 진행되지 않는다. 문서화된 예외 없이 수동 재정의는 없다.
더 넓은 후보 풀이 프로브 동작을 바꾸는 방식
많은 리트리벌 아키텍처는 두 단계 접근 방식을 사용한다: 후보 풀을 생성하는 빠른 어휘 또는 밀집 리트리벌 패스, 그 다음 상위 k를 반환하기 전에 풀을 재정렬하는 리랭커.
후보 풀을 넓히는 것 — 예를 들어 12에서 30으로 — 은 일반적인 튜닝 방법이다. 직관은 타당하다: 리랭커에 더 많은 것을 제공하면 올바른 문서를 표면화할 가능성이 높아진다.
하지만 더 넓은 풀은 프로브가 잡아내고 집계 지표는 잡아내지 못하는 엣지 케이스를 도입한다.
다음과 같은 일이 발생한다:
- 일반 쿼리의 재현율이 향상된다. 올바른 문서가 후보 풀에 더 자주 들어온다. 평균적으로 리랭커 정밀도가 올라간다.
- 모호한 쿼리의 노이즈가 증가한다. 12개 대신 30개 후보로 리랭커는 주제적으로 인접하지만 특정 쿼리에 대해 사실적으로 틀린 문서를 더 많이 본다. 모호한 쿼리 — 프로덕션 장애를 일으킬 가능성이 가장 높은 것들 — 에서 리랭커 정밀도가 떨어질 수 있다.
- 프로브가 모호한 케이스를 잡아낸다. 프로브 쿼리는 실제 장애에서 수집되므로 쿼리 분포의 모호한 쪽으로 치우친다. 평균 precision@5를 4포인트 향상시키는 더 넓은 풀이 동시에 12개 프로브 쿼리 중 3개의 정밀도를 회귀시킬 수 있다. 집계 지표는 이를 숨긴다. 프로브는 이를 표면화한다.
이것이 회귀 프로브의 핵심 가치다: 평균 동작이 아닌 시스템의 알려진 약점에 대해 적대적으로 구성된다.
프로브가 실패할 때 할 일
프로브 실패는 위기가 아니다. 시스템이 올바르게 작동하는 것이다.
프로브가 실패하면:
- 어떤 쿼리가 얼마나 회귀했는지 파악한다.
- 회귀가 후보 풀(리트리벌 단계)에 있는지 리랭커 출력(랭킹 단계)에 있는지 확인한다. 프로브 쿼리에 대해 리랭크 전과 후의 랭킹을 모두 기록한다.
- 회귀가 의도된 변경의 부작용인지 의도치 않은 결과인지 판단한다.
- 배포 전에 회귀를 수정하거나, 트레이드오프를 명시적으로 문서화하고 근거 주석과 함께 프로브 임계값을 업데이트한다.
4단계를 건너뛰지 말 것. 프로브는 임계값이 드리프트에 대한 누적된 허용이 아닌 의도적인 결정을 반영할 때만 유용하다.
운영 규율
리트리벌 회귀 프로브는 한 번만 구축하는 것이 아니다. 유지 관리가 필요하다:
- 프로덕션에서 새로운 실패 모드가 나타나면 새 쿼리를 추가한다.
- 기반 문서가 코퍼스에서 제거되면 쿼리를 폐기한다.
- 코퍼스가 재구성될 때 예상 ID 세트를 검토한다.
정직하게 유지 관리된 15개 쿼리는 런칭 시 한 번 실행된 포괄적인 벤치마크보다 더 많은 회귀를 잡아낼 것이다.
지루하고, 일관되고, 배포 전에. 이것이 리트리벌 시스템을 신뢰할 수 있게 유지하는 패턴이다.
AI 시스템을 구축하거나 감사하면서 리트리벌 아키텍처와 평가 설계에 대해 논의하고 싶다면, 대화 시작하기 →