검색해서 넣을 것인가, 통째로 넣을 것인가

지난 글에서 예산을 넘겼을 때 무엇부터 버릴지를 정했다면, 그보다 한 단계 앞의 질문이 남는다. 애초에 문서를 검색해서 필요한 조각만 넣을 것인가, 아니면 통째로 창에 밀어 넣을 것인가.

창이 100만 토큰까지 커지면서 "이제 검색은 필요 없다"는 말이 자주 나온다. 반대로 "긴 창은 비싸기만 하다"는 말도 같이 나온다. 둘 다 조건을 빼고 말해서 그렇지, 실제로는 몇 가지 값만 확인하면 어느 쪽인지 대체로 정해진다.

두 방식은 같은 문제를 다르게 푼다

두 방식 모두 "모델이 답에 필요한 근거를 보게 한다"는 같은 목적을 갖는다. 다른 것은 그 선별을 언제 누가 하느냐다. 검색은 요청 전에 우리 코드가 고르고, 긴 문맥은 요청 후에 모델이 어텐션으로 고른다.

	검색해서 넣기	통째로 넣기
선별하는 주체	우리 코드	모델
요청당 입력 토큰	작다 (조각 몇 개)	크다 (문서 전체)
준비 비용	색인·임베딩·갱신	없다
놓치는 방식	검색이 못 찾으면 끝	창 안에 있어도 못 볼 수 있다
근거 표시	조각 단위로 명확하다	문서 어디인지 모른다
문서가 바뀔 때	재색인이 필요하다	그냥 새로 넣으면 된다

여기서 자주 놓치는 줄이 마지막 두 개다. 검색은 어느 조각을 넣었는지 우리가 알기 때문에 인용과 근거 표시를 붙일 수 있다. 통째로 넣으면 모델이 "문서에 따르면"이라고 말해도 그게 어느 문단인지 확인할 길이 없다. 반대로 문서가 시시각각 바뀌는 자료라면 색인 갱신이 늘 뒤처지는 쪽이 검색이다.

비용은 두 번째 요청에서 갈린다

한 번만 물어볼 문서라면 계산이 간단하다. 검색을 붙이는 데 드는 임베딩·색인 비용이 그냥 넣는 입력 비용보다 크면 검색이 손해다. 문제는 같은 문서에 질문이 여러 번 올 때다.

문서 토큰 수를 $D$, 질문 수를 $N$, 입력 토큰당 단가를 $c$, 검색으로 줄여 넣는 조각의 토큰 수를 $R$이라 하면 대략 이렇게 된다.

$C_{\text{긴 문맥}} = N \cdot D \cdot c, \qquad C_{\text{검색}} = N \cdot R \cdot c + C_{\text{색인}}$

$R$이 $D$의 5% 정도라면 질문이 몇 번만 반복돼도 검색이 이긴다. 그런데 프롬프트 캐시를 쓸 수 있으면 식이 한 번 더 바뀐다. 캐시 적중 시 단가를 $c_h$라 하면 긴 문맥 쪽은 첫 요청만 제값을 내고 나머지는 할인된 값을 낸다.

$C_{\text{긴 문맥+캐시}} = D \cdot c + (N-1) \cdot D \cdot c_h$

$c_h$가 $c$의 10분의 1 수준이면 $D \cdot c_h$와 $R \cdot c$가 비슷한 구간이 생긴다. 즉 캐시가 되는 상황에서는 긴 문맥의 비용 불리함이 상당 부분 사라진다. 다만 캐시는 조건이 까다롭다 — 앞부분이 토큰 단위로 완전히 같아야 하고, 유효 시간이 짧고, 질문이 여러 사용자에 흩어져 있으면 적중률이 떨어진다.

여기까지가 비용 얘기이고, 지연은 따로 봐야 한다. 입력이 길면 첫 토큰까지 걸리는 시간이 늘어난다. 캐시가 적중해도 비용은 줄지만 지연은 그만큼 줄지 않는 경우가 많다.

정확도는 창 크기가 아니라 문서 수가 정한다

"창에 들어가니까 다 넣자"가 위험한 이유는 앞서 본 대로 창 안에 있다고 다 쓰이지는 않기 때문이다. 그런데 이 손실은 문서 길이보다 경쟁하는 후보의 수에 더 민감하다.

• 관련 문서 한 편을 통째로 넣는 것 — 대체로 잘 된다. 문맥이 이어져 있어 오히려 조각보다 낫다.
• 비슷한 문서 서른 편을 넣는 것 — 답이 흔들리기 시작한다. 비슷한 내용이 여러 벌 있으면 모델이 어느 것을 근거로 삼았는지 일관되지 않는다.
• 관련 없는 문서가 섞인 것 — 가장 나쁘다. 무관한 내용이 답에 끌려 들어온다.

그래서 실무의 판단은 "창에 들어가는가"가 아니라 "넣으려는 것 중 무관한 비율이 얼마인가"다. 이 비율이 높으면 창이 아무리 커도 검색이나 필터로 걸러야 한다. 반대로 문서 한 편에 대한 질의응답이라면 조각으로 쪼개는 것이 손해일 수 있다 — 표가 잘리고 앞뒤 문맥이 끊긴다.

첫 갈림길의 "들어가는가"는 예산을 뺀 뒤로 센다. 창이 20만 토큰이라도 출력 상한과 안전 여유, 시스템 지시와 대화 이력을 빼면 실제로 쓸 수 있는 자리는 그보다 훨씬 적다.

섞어 쓰는 세 가지 방식

실제로 둘 중 하나만 고르는 경우는 드물다. 자주 쓰는 조합이 셋 있다.

첫째, 넓게 찾아 통째로 넣기. 검색으로 문서 단위까지만 좁히고, 고른 문서는 조각내지 않고 전문을 넣는다. 문서가 수천 개인데 질문마다 두세 편만 관련 있는 상황에 맞는다. 검색의 역할이 "정답 문단 찾기"에서 "무관한 것 버리기"로 바뀌므로 검색 품질에 대한 요구가 낮아진다.

둘째, 캐시 위에 검색 얹기. 자주 쓰는 공통 자료(제품 설명서, 정책 문서)는 캐시되는 앞부분에 고정으로 넣고, 질문마다 달라지는 부분만 검색해서 뒤에 붙인다. 앞부분이 안 변해야 캐시가 살아 있으므로 순서를 뒤집으면 안 된다.

셋째, 두 단계로 나누기. 긴 문맥 모델에게 먼저 "이 문서에서 질문과 관련된 부분의 위치"를 뽑게 하고, 그 부분만 다시 넣어 답을 만든다. 호출이 두 번이라 지연이 늘지만, 근거가 명시되고 최종 답변 단계의 입력이 짧아진다.

def answer(question, doc_ids):
    docs = load(doc_ids)
    if estimate(docs) <= INPUT_BUDGET and len(docs) <= DOC_CAP:
        return ask(system, docs, question)          # 통째로

    hits = search(question, doc_ids, k=TOP_K)       # 검색으로 좁힌다
    if whole_doc_fits(hits):
        return ask(system, load(hits.doc_ids), question)   # 문서 단위로 복원
    return ask(system, hits.chunks, question)       # 조각으로

이 코드에서 중요한 것은 whole_doc_fits 한 줄이다. 검색으로 좁힌 뒤 조각을 그 문서의 전문으로 되돌릴 수 있으면 되돌리는 것이 대체로 낫다. 조각화의 손실은 대부분 여기서 회복된다.

무엇을 재야 결정할 수 있나

이 판단은 감으로 하면 매번 뒤집힌다. 로그에서 네 값만 뽑아 두면 대화가 짧아진다.

값	어떻게 쓰는가
질문당 관련 문서 수의 분포	상위 백분위가 문서 상한을 정한다
같은 문서에 오는 질문 수	1에 가까우면 검색이 손해다
캐시 적중률	낮으면 긴 문맥의 비용 계산이 뒤집힌다
검색 상위 $k$의 재현율	낮으면 창을 키워도 답이 안 좋아진다

마지막 줄이 특히 중요하다. 검색이 정답 조각을 놓치고 있는데 창을 키우는 것으로 대응하면, 무관한 문서를 더 많이 넣어 정확도가 오히려 떨어진다. 창을 키우기 전에 검색의 재현율부터 확인해야 한다.

정리하면 이 선택은 하나를 고르고 끝나는 것이 아니다. 질문 수가 적고 문서가 확실하면 통째로 넣고, 후보가 많고 무관한 비율이 높으면 검색으로 거르고, 반복되는 공통 자료는 캐시에 고정한다. 세 경로가 한 시스템 안에 함께 있는 것이 정상이며, 어느 경로로 갔는지를 로그에 남기는 것이 나중에 이 판단을 다시 할 수 있게 해 준다.

---

읽어주셔서 감사합니다. 😊