만약 검색(Retrieval)이 불완전하고 컨텍스트 윈도우(Context Window)가 매우 크다면, 왜 5개의 청크(Chunk) 대신 50개를 검색하여 모델이 스스로 해결하게 두지 않을까요? 그 이유는 재현율(Recall)과 비용(Cost)이 동일한 속도로 증가하지 않으며, 청크가 컨텍스트 내 어디에 위치하느냐가 중요하다는 사실이 밝혀졌기 때문입니다.

유혹

이는 합리적인 본능입니다. 누락된 문서로 인해 발생하는 모든 RAG 실패 사례는 더 큰 k값을 요구하며, 큰 컨텍스트 윈도우를 가진 모델은 이러한 제약이 사라진 것처럼 느끼게 합니다. 50개를 검색하여 모두 전달하면, 무차별 대입(Brute force) 방식으로 재현율 문제를 해결할 수 있을 것 같습니다.

하지만 두 가지 문제가 발생합니다. k가 증가함에 따라 비용은 선형적으로 증가하는 반면 재현율은 평탄해지며(Flatten), 모델은 긴 컨텍스트를 균일하게 주의(Attend)하지 않습니다. 즉, 추가되는 마지막 청크는 가장 비용이 많이 들면서도 읽힐 가능성이 가장 낮은 청크가 됩니다.

발표된 연구 결과

참조할 결과는 Liu 등이 작성한 Lost in the Middle: How Language Models Use Long Contexts (arXiv:2307.03172, 이후 TACL에 게재)입니다. 그들은 정답을 포함한 문서가 방해 요소(Distractors)들 사이의 통제된 위치에 배치되도록 하여, 그 위치를 변화시키는 다중 문서 질의응답(Multi-document question answering) 과업을 구축했습니다.

보고된 패턴은 U자 형태입니다. 관련 문서가 입력의 맨 처음이나 맨 끝에 있을 때 정확도가 가장 높았고, 중간에 있을 때는 정확도가 상당히 떨어졌습니다. 또한 그들은 방해 요소가 충분할 경우, 정답 문서가 중간 위치에 있을 때의 성능이 검색된 문서가 아예 없을 때의 모델 성능보다 낮아질 수 있다고 보고했습니다. 즉, 해당 구성에서의 검색은 아무것도 하지 않았을 때보다 상황을 더 악화시켰습니다.

이를 고정된 불변의 법칙이라기보다는 일련의 행동 양식에 대한 발견으로 취급하십시오. 이는 해당 시기의 모델들을 대상으로 측정된 것이며, 이후 롱 컨텍스트 학습(Long-context training)을 통해 개선되었습니다. 일부 최신 모델들은 훨씬 더 평탄한 곡선을 보여줍니다. 변하지 않은 사실은 이 특성이 모델마다 다르므로 당연하게 가정하기보다는 확인해 볼 가치가 있다는 점과, 효과의 방향성(중간보다 양 끝이 더 낫다)이 후속 연구들을 통해 설계에 반영할 수 있을 만큼 충분히 견고하게 유지되고 있다는 점입니다.

Needle 테스트가 문제를 해결하지 못하는 이유

'건초더미 속 바늘 찾기 (needle-in-a-haystack)' 평가에서 100%를 달성했다고 보여주는 벤더(vendor)가 위에서 언급한 문제를 반박한 것은 아니며, 그 이유를 이해하는 것이 유용한 부분입니다. 바늘(needle) 작업은 채우기용 텍스트(filler text) 안에 이질적이고 독특한 문장 하나를 삽입하고 모델에게 이를 찾도록 요청합니다. 이는 어휘적으로 매우 사소한 검색입니다. 즉, 바늘은 주변 환경과 닮지 않았습니다.

검색된 청크(retrieved chunks)는 그 반대입니다. 50개 모두가 동일한 주제를 다루고 있으며 — 그렇게 되도록 선택되었기 때문입니다 — 그중 몇 개는 올바른 주제를 다루고 있지만 세부 사항이 틀린 '근접 오답(near-misses)'들입니다. 이 작업은 독특한 문자열을 찾는 것이 아니라, 그럴듯한 후보들 사이에서 차별화하고 그중 몇 개를 종합하는 것입니다. 완벽한 바늘 점수는 이 더 어려운 작업에서 발생하는 실제 성능 저하와 일치할 수 있으므로, $k$ 값을 결정할 때 원하는 증거가 아닙니다.

서로 갈라지는 두 곡선

자신의 검색 평가(retrieval evaluation) 수치를 직접 실행해 보십시오. Recall@k는 특유의 형태를 가집니다. 1에서 약 10까지는 가파르게 상승하다가 그 이후에는 평탄해지는데, 이는 대부분의 질문이 검색기가 이미 높게 순위를 매긴 청크에 의해 답변되기 때문이며, 그렇지 않은 질문들은 대개 더 긴 목록보다는 다른 청크 전략(chunking strategy)을 필요로 하기 때문입니다. 비용은 선형적입니다.

500-토큰 청크와 백만 토큰당 $G$인 입력률을 가정합니다.

  k =  5  ->  2,500 컨텍스트 토큰   1.0x 비용
...

리랭커(reranker)는 이러한 트레이드오프(trade-off)를 깨뜨리는 요소이며, 이것이 리랭커를 사용해야 하는 가장 강력한 근거입니다. Recall@50이 상한선이 되도록 50개를 검색하고, 비용, 지연 시간(latency), 그리고 주의 분산(distraction)이 모두 $k = 5$ 수준이 되도록 5개로 리랭킹하십시오. 긴 목록의 재현율(recall)을 확보하면서도 그 토큰들에 대한 비용은 지불하지 않는 방식입니다.

자유 변수로서의 순서

위치 효과(position effect)를 고려할 때, 검색된 청크를 연결하는 순서는 대부분의 파이프라인이 설정하지 않는 실제 매개변수(parameter)입니다. 시도해 볼 가치가 있는 순서대로 나열한 옵션들은 다음과 같습니다:

• 최우선 배치 (Best first). 기본 설정이며 합리적인 방식입니다. 모델이 가장 신뢰성 있게 주목하는 영역에 가장 강력한 증거를 배치합니다.
• 샌드위치 방식 (The sandwich). 가장 좋은 청크를 맨 앞에, 두 번째로 좋은 청크를 맨 뒤에, 나머지를 중간에 배치합니다. U자형 곡선(U-shape) 현상을 직접적으로 활용하며, 구현 비용이 들지 않습니다.
• 최후 배치 (Best last). 질문 바로 직전에 배치합니다. 컨텍스트 내의 최신성(recency)이 종종 과도한 영향을 미치기 때문에 테스트할 가치가 있으며, 이 방식은 가장 강력한 증거를 생성(generation) 단계와 가장 가깝게 배치합니다.
• 소스 순서 (Source order). 청크가 하나의 문서에서 연속된 부분이라면, 점수(score)가 아닌 위치(position)에 따라 정렬하는 것이 모델에게 뒤섞인 문장이 아닌 일관된 산문(prose)을 제공하며, 이는 점수 기반 정렬보다 더 중요할 수 있습니다.

어떤 방식을 선택하든, 소스에 번호를 매기고 인용(citation)을 지시하십시오. 그리고 추론을 통해 판단하기보다는 선택의 결과를 측정하십시오. 이는 인덱스(index)나 모델의 변경 없이 고정된 검색 세트(retrieval set)를 대상으로 수행하는 저렴한 A/B 테스트이며, RAG 파이프라인에서 활용 가능한 몇 안 되는 진정으로 깔끔한 실험 중 하나입니다.

주의력(attention)과는 무관하게 대규모 컨텍스트(large context)의 성능을 저하시키는 요소가 하나 더 있습니다. 청크가 중복(overlapping)되어 있으면 k = 50일 때 동일한 문장을 두세 번씩 자주 보내게 되며, 서로 다른 문서에서 온 거의 중복된 구절(예: 네 곳에서 인용된 정책)은 그 효과가 더욱 증폭됩니다. 모델은 반복을 확증(corroboration)으로 읽는데, 이는 반복이 분할기(splitter)로 인한 인위적인 결과물일 경우 잘못된 추론이 됩니다. 프롬프트를 구성하기 전에 검색된 세트의 중복을 제거하십시오. 소스 범위가 겹치는 청크를 병합하고, 저렴한 유사도 검사(similarity check)를 통해 거의 동일한 텍스트를 제거하십시오. 중복이 심한 코퍼스(corpus)의 경우, 이 작업만으로도 컨텍스트 예산(context budget)의 상당 부분을 비용 없이 확보할 수 있습니다.

2023년 모델들이 어떻게 동작했는지보다 당신의 모델이 어떻게 동작하는지 알고 싶다면, 이 실험은 오후 한나절이면 실행할 수 있을 만큼 규모가 작으면서도 발표된 그 어떤 수치보다 가치가 있습니다. 평가 세트(evaluation set)에서 20개의 질문을 가져와서, 정답을 포함하는 k개의 청크(chunk)로 고정된 컨텍스트(context)를 구축한 뒤, 다른 모든 것은 동일하게 유지한 채 정답의 위치만 — 처음, 중간, 마지막 — 순열(permute)로 변경해 보세요. 각 위치별 정확도(accuracy)를 측정합니다. 이것은 당신이 실제로 서비스하는 코퍼스(corpus)에 대한 깨끗하고 정직하며 단일 변수만을 다루는 측정 방식이며, 순서(ordering)를 엔지니어링할 가치가 있는지를 직접적으로 알려줍니다.

위치 효과(position effect)는 파이프라인(pipeline)이 아닌 모델의 속성이므로, 동일한 컨텍스트라도 두 모델 사이에서 다르게 동작할 수 있습니다. 카탈로그에 광고된 컨텍스트 길이(advertised context lengths)가 있긴 하지만, 모델이 '제대로' 사용하는 길이는 당신의 자체 평가 세트가 답해줄 별개의 문제입니다.

관련 항목

• 리랭킹(Reranking): RAG에서 가장 저렴하게 정확도를 높이는 방법
• 컨텍스트 윈도우(Context Windows)가 거대해진 지금, RAG는 죽었는가?
• 당신의 RAG가 올바른 청크를 찾고도 틀린 답을 내놓는 이유