RAG는 왜 긴 문맥을 넣어도 실패하는가

긴 context는 더 많은 정보를 담을 수 있게 하지만, 어떤 정보를 보여줄지 결정해 주지는 않습니다. 관련 문서가 너무 늦게 배치되거나 비슷한 noise에 둘러싸이면 모델은 중요한 근거를 놓칠 수 있습니다. 비용과 latency도 입력 길이에 따라 함께 증가합니다.

question
→ query normalization
→ embedding / search
→ top-k candidates
→ reranking / filtering
→ context assembly
→ generation
→ citation validation

최종 답이 틀렸다고 해서 항상 generation model이 문제인 것은 아닙니다. 질문이 검색용 query로 잘 바뀌지 않았을 수 있고, 필요한 chunk가 index에 없거나, 후보에는 있었지만 reranker가 떨어뜨렸거나, prompt 안에서 불리한 위치에 배치됐을 수 있습니다.

더 많은 chunk를 넣으면 필요한 근거가 포함될 가능성은 커집니다. 동시에 irrelevant context와 중복 문장이 늘고, 모델이 근거를 고르는 부담도 커집니다. 따라서 k 하나를 전역 상수로 두기보다 질문 유형과 confidence, reranker 성능, token budget에 따라 조절해야 합니다.

작은 chunk는 검색에 유리하지만 원래 문서의 제목, 장, 시점, 대상 같은 배경을 잃기 쉽습니다. Chunk를 embedding하기 전에 짧은 문서 맥락을 붙이거나 metadata filter를 함께 사용하면, 같은 단어를 가진 다른 문서와 구분하는 데 도움이 됩니다.

1. 정답 근거가 문서의 앞, 중간, 뒤에 있는 세 질문을 만듭니다.
2. Full document, naive top-k, reranked top-k, contextual chunk 네 조건을 비교합니다.
3. 후보 recall, 최종 context precision, groundedness, citation correctness를 따로 기록합니다.
4. 정답 여부와 함께 token, time to first token, total latency를 비교합니다.
5. 실패한 질문에서 근거가 어느 단계에서 사라졌는지 trace로 표시합니다.