"검색 결과를 몇 개나 넣어야 하죠?" 사내 Q&A 시스템을 처음 만들 때 저도 이 질문 앞에서 한참 멈췄습니다. 많이 넣으면 더 좋은 답이 나올 것 같은데, 실제로 해보면 꼭 그렇지만은 않습니다. 이 글은 그 시행착오를 정리한 기록입니다.
검색 결과를 많이 넣으면 정말 더 좋아질까요
처음에 저는 top_k=10으로 설정해 검색된 문서 청크(chunk) 10개를 모두 컨텍스트에 넣었습니다. 여기서 청크란 긴 문서를 LLM이 처리할 수 있도록 일정 크기로 잘라낸 조각을 의미합니다. 답변이 길고 풍성해 보이니 잘 되는 것 같았습니다.
그런데 실제 사용자 피드백을 받아보니 상황이 달랐습니다. 핵심 답변이 여러 청크 사이에서 희석되거나, 서로 약간씩 다른 내용을 담은 문서들이 동시에 주입되면서 모델이 모순된 답변을 내놓는 경우가 생겼습니다. 솔직히 이건 예상 밖이었습니다. 정보를 많이 줄수록 더 정확해질 거라는 직관이 완전히 빗나간 순간이었습니다.
이 문제의 원인은 어텐션 메커니즘(attention mechanism)에 있습니다. 어텐션 메커니즘이란 LLM이 입력된 텍스트에서 어떤 부분에 얼마나 집중할지를 결정하는 핵심 구조입니다. 관련 없는 청크가 많아질수록 모델의 어텐션이 분산되고, 노이즈가 섞여 정작 중요한 정보를 제대로 활용하지 못하게 됩니다. RAG 최적화는 엔지니어링보다 편집자의 감각에 가깝다는 생각이 든 건 이때부터였습니다.
컨텍스트 배치 순서가 답변 품질을 바꿉니다
검색 결과를 줄이는 것만으로는 부족했습니다. 어떤 순서로 넣느냐도 중요하다는 걸 알게 됐습니다.
Liu 등의 연구에 따르면 LLM은 컨텍스트 윈도우(context window)의 앞부분과 끝부분에 위치한 정보를 중간보다 훨씬 잘 활용하는 경향이 있다고 합니다. 컨텍스트 윈도우란 LLM이 한 번에 처리할 수 있는 텍스트의 최대 범위를 뜻합니다. 이 현상은 "Lost in the Middle"이라는 표현으로 불리며, 중간에 배치된 정보는 사실상 묻혀버리는 경우가 많습니다(출처: arXiv).
저는 이 연구를 접한 뒤 바로 청크 배치 순서를 바꿨습니다. 코사인 유사도(cosine similarity) 기준으로 가장 관련성 높은 청크는 컨텍스트 맨 앞에, 두 번째로 중요한 청크는 맨 뒤에 배치했습니다. 코사인 유사도란 두 벡터 간의 방향 유사성을 0에서 1 사이의 수치로 나타낸 것으로, RAG에서 쿼리와 청크의 의미적 유사성을 측정하는 데 쓰입니다. 이 순서 재배치만으로도 답변 정확도가 체감상 올라갔습니다. 코드 한 줄 바꾸지 않고 얻은 개선이었기에 인상적이었습니다.
핵심은 단순히 관련도 순서대로 쌓는 게 아니라, 모델이 실제로 잘 읽는 위치에 중요한 정보를 배치하는 전략적 편집이라는 점입니다.
재순위화 모델을 붙이면서 달라진 것들
청크 배치 순서를 조정한 뒤에도 여전히 아쉬운 부분이 있었습니다. 1차 벡터 검색 자체가 의미적으로 유사하지만 질문의 의도와는 어긋난 문서를 올려보내는 경우가 있었거든요.
이때 도입한 것이 재순위화(re-ranking) 단계입니다. 재순위화란 1차 검색으로 걸러낸 후보 문서들을 더 정교한 모델로 다시 평가해 순위를 재조정하는 과정입니다. 저는 Cohere Rerank와 크로스인코더(cross-encoder) 모델을 비교 테스트했습니다. 크로스인코더란 쿼리와 문서를 쌍으로 묶어 함께 입력받아 관련도를 직접 계산하는 방식으로, 양방향 어텐션을 활용하기 때문에 단순 벡터 유사도보다 정밀합니다.
제가 직접 써봤는데, top_k를 10에서 3~4로 줄이고 재순위화를 붙였을 때 답변 품질은 유지되거나 오히려 나아졌고, 토큰 사용량은 눈에 띄게 줄었습니다. 토큰 비용이 실제로 절감되는 걸 수치로 확인했을 때는 꽤 뿌듯했습니다.
현재 저의 파이프라인에서 효과적이라고 확인된 설정을 정리하면 다음과 같습니다.
- 1차 벡터 검색: top_k=10~20으로 후보 풀 확보
- 재순위화: Cohere Rerank 또는 cross-encoder로 재정렬
- 최종 컨텍스트 주입: 상위 3~4개 청크만 선별
- 배치 순서: 최고 관련 청크는 앞, 두 번째는 끝 배치
토큰 예산을 명시적으로 나눠 관리하는 이유
재순위화까지 도입하고 나니 자연스럽게 토큰 예산 관리가 필요해졌습니다. 컨텍스트를 줄였더니 다른 영역에 쓸 수 있는 토큰이 늘어났고, 이를 체계적으로 배분할 필요가 생겼습니다.
토큰 예산(token budget)이란 LLM에 입력하고 출력하는 텍스트 전체를 토큰 단위로 계산해 각 구성 요소에 할당량을 정해두는 방식입니다. 저는 쿼리, 시스템 프롬프트, 검색 결과, 출력 이렇게 네 영역으로 나눠 명시적으로 관리하기 시작했습니다. Anthropic의 공식 가이드에서도 컨텍스트 구성 시 각 요소의 토큰 비중을 의식적으로 설계할 것을 권장합니다(출처: Anthropic).
이 관리 방식이 생기고 나서 가장 달라진 점은, 시스템 프롬프트가 예상보다 많은 토큰을 잡아먹고 있다는 사실을 발견한 것입니다. 개선 여지가 어디에 있는지 숫자로 보이니 의사결정이 훨씬 명확해졌습니다.
한 가지 덧붙이고 싶은 건, 최적의 top_k 값은 도메인과 문서 유형에 따라 크게 달라진다는 점입니다. 단일 설정을 전체 시스템에 적용하는 건 위험합니다. 질문 복잡도에 따라 동적으로 검색 개수를 조정하는 적응형 RAG(adaptive RAG) 방식이 더 현실적인 솔루션일 수 있습니다. 이 분야는 아직 표준화된 베스트 프랙티스가 부족하고, 실험과 평가 루프를 직접 구축하는 것이 현 시점에서는 가장 확실한 접근이라고 봅니다.
RAG 파이프라인을 고민 중이라면, 일단 top_k를 줄이고 재순위화를 붙이는 것부터 시작해 보시길 권합니다. 많이 넣는 게 능사가 아니라는 걸, 저는 꽤 많은 토큰 낭비를 겪고 나서야 제대로 이해했습니다. 시스템의 복잡도보다 먼저 평가 기준을 세우는 것이 순서라는 것도, 이 작업을 통해 배운 가장 실용적인 교훈입니다.
참고:
- Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. https://arxiv.org/abs/2005.11401
- Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. arXiv. https://arxiv.org/abs/2307.03172
- Anthropic. (2024). Retrieval augmented generation (RAG). https://docs.anthropic.com/en/docs/build-with-claude/retrieval-augmented-generation