계측(Instrument)하지 않은 RAG는 디버깅할 수 없습니다
요약
RAG 시스템의 성능 저하 문제를 해결하기 위해 검색(retrieval) 단계를 계측(instrumentation)하는 방법론을 제시합니다. 단순히 최종 답변만 로그로 남기는 것이 아니라, 검색된 전체 후보군과 제외된 항목의 이유를 기록해야 정확한 디버깅이 가능합니다.
핵심 포인트
- 검색 단계의 블랙박스를 해소하기 위해 검색 매니페스트를 유지해야 함
- 인용된 문서뿐만 아니라 점수가 포함된 전체 후보군을 로그로 남겨야 함
- 제외된 후보의 사유(필터링, 중복 제거 등)를 기록하는 것이 디버깅의 핵심
- 매니페스트를 통해 추론 문제와 근거 문제를 명확히 구분 가능
몇 주마다 누군가가 "AI가 점점 나빠지는 것 같아요"라는 식의 티켓을 생성합니다. 답변은 여전히 유창하고, 여전히 자신감이 있으며, 여전히 인용(cited)되어 있습니다. 다만 미묘하게 틀릴 뿐이며, 사람들이 알아차릴 정도로 빈번하지만 명백하게 무언가 고장 날 정도로 빈번하지는 않습니다. 그러다 며칠 동안 조용히 그 문제 속으로 사라지곤 합니다.
본능적으로 항상 모델이나 프롬프트(prompt)를 살펴보게 됩니다. 제가 이런 문제를 추적했을 때 거의 매번 모델은 지시받은 대로 정확히 수행했습니다. 상위 문서들을 읽고 그 문서들을 바탕으로 답변했습니다. 문제는 상류(upstream), 즉 무엇이 검색(retrieved)되어 모델에게 전달되었는지에 있었으며, 이를 찾는 데 며칠이 걸린 이유는 검색(retrieval) 단계가 블랙박스(black box)였기 때문입니다. 우리는 최종 답변을 로그(log)로 남깁니다. 때로는 인용(citations)을 남기기도 합니다. 하지만 리트리버(retriever)가 실제로 무엇을 보았고 무엇 사이에서 선택했는지는 거의 남기지 않습니다.
계측(instrument)하지 않은 것은 디버깅할 수 없습니다.
실제로 무엇을 로그로 남겨야 하는가
모든 답변에 대해, 저는 그 옆에 작은 검색 매니페스트(retrieval manifest)를 유지합니다. 세 가지 항목입니다:
- 무엇이 검색되었는가. 인용된 것뿐만 아니라 점수(scores)가 포함된 전체 후보군(candidate set)입니다. 이것은 여러분이 예상하는 부분입니다.
- 무엇이 제외되었으며, 그 이유는 무엇인가. 각 제외된 후보와 그 이유 코드(reason code): 순위 컷오프(rank cutoff) 미만, 메타데이터(metadata)에 의한 필터링, 대체되었거나 오래됨(superseded or stale), 라이선스 범위 외, 중복 제거(deduplicated). 이것은 아무도 로그를 남기지 않는 부분이며, 바로 여기에 사각지대(blind spots)가 존재합니다.
- 무엇이 인용되었는가. 실제로 답변에 포함된 내용입니다.
다음은 한 항목의 대략적인 형태입니다:
{
"query": "what is our refund window for enterprise?",
"retrieved": [
...
잠시 그것을 살펴보십시오. 인용된 문서는 14개월 전의 것이며, 단지 더 깔끔하게 작성되었다는 이유만으로 현재의 문서보다 더 높은 점수를 받았습니다. 답변 내에서는 이것이 보이지 않습니다. 하지만 매니페스트(manifest)에서는 가장 먼저 보이는 것입니다.
이를 통해 얻는 것
과거에는 추측에 의존해야 했던 두 가지 사항이 기계적인 과정이 됩니다.
추론 문제(reasoning problem)와 근거 문제(evidence problem)를 구분할 수 있습니다. 두 번의 실행 결과가 다르거나, 동일한 모델의 두 배포(deployment)가 서로 다른 답변을 내놓을 때, 먼저 매니페스트(manifest)를 비교(diff)하십시오. 동일한 근거 세트(evidence set)임에도 답변이 다르다면 그것은 모델의 문제이거나 비결정론(nondeterminism)의 문제입니다. 근거 세트가 다르다면 그것은 검색(retrieval)의 문제이며, 프롬프트(prompt)를 수정한다고 해서 해결될 수 있는 문제가 아닙니다. 현재 대부분의 사람들은 경계(boundary)를 캡처하지 못했기 때문에, 출력값(outputs)만 뚫어지게 쳐다보며 거꾸로 디버깅을 하고 있습니다.
오래된 문서 버그(stale-document bug)가 며칠이 아닌 몇 분 만에 드러납니다. 최신 문서보다 오래된 문서가 조용히 더 높은 순위를 차지하는 전형적인 실패 사례는 답변 자체에서는 전혀 나타나지 않습니다. 하지만 매니페스트에서는 오래된 타임스탬프를 가진 최상위 결과로 즉시 나타납니다. 이제 추측을 멈추고 읽기 시작하면 됩니다.
사람들이 잘못 알고 있는 부분
제외 로그(exclusion log)는 노이즈가 많습니다. 모든 쿼리마다 이를 읽을 수는 없으며, 시도한다 하더라도 정보의 홍수에 빠지게 될 것입니다. 따라서 로그는 항상 남기되, 답변이 플래그(flag)로 표시되거나 두 결과가 일치하지 않을 때만 드러내십시오. 이것은 대시보드(dashboard)가 아니라 블랙박스 기록장치(black box recorder)입니다.
또 다른 함정은 드리프트(drift)입니다. 매니페스트는 검색(retrieval) 코드가 실행되는 동안 이를 방출할 때만 도움이 됩니다. 사후에 매니페스트를 다시 구축하거나 수동으로 유지 관리하는 순간, 그것은 현실과 조용히 어긋날 수 있는 또 다른 요소가 되며, 결국 디버깅을 디버깅하는 상황에 처하게 됩니다.
한 줄 요약
인용(Citations)은 무엇이 답변을 뒷받침했는지 알려줍니다. 제외 로그(exclusion log)는 답변이 무엇을 보지 못했는지 알려줍니다. 시스템을 신뢰하기 위해서는 두 가지 모두가 필요하지만, 거의 모든 사람은 첫 번째 것만 유지합니다.
대부분의 "모델이 환각(hallucination)을 일으키고 있다"라는 티켓은 실제로는 "검색기(retriever)가 잘못된 근거를 전달했고, 모델은 그것을 충실히 사용했다"는 의미입니다. 경계(boundary)를 계측(instrument)하면 모델은 더 이상 기본 용의자가 되지 않습니다. 이것이 제가 RAG의 품질을 구축해 온 방향이며, 검색 단계가 맹목적인 믿음에 의존하는 대신 스스로를 측정하고 보고해야 한다는 아이디어입니다.
그래서 저는 궁금합니다. 현재 여러분의 리트리버(Retriever)에서 실제로 무엇을 로그(Log)로 남기고 계신가요? 단지 인용(Citation) 정보뿐인가요, 전체 후보군(Candidate set)인가요, 아니면 무언가 문제가 발생할 때까지 아무것도 남기지 않고 계신가요?
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기