Field Log · Entry

Long Context vs RAG: 언제 무엇을 쓸까? (6/10)

질문의 corpus 범위, freshness, ACL, citation, cost 조건에 따라 Long Context, RAG, retrieve-then-read hybrid로 분기하는 의사결정 흐름

오늘의 결론

Context window에 들어간다와 model이 필요한 evidence를 안정적으로 사용한다는 같은 말이 아닙니다.

Long Context는 corpus가 작고 고정돼 있으며 전체 구조를 읽어야 할 때 강력한 기준선입니다.

RAG는 corpus가 크거나 자주 바뀌고, ACL·citation·비용 통제가 필요할 때 여전히 핵심입니다.

가장 실용적인 구조는 양자택일이 아니라 retrieve documents → long-context read와 query별 router입니다.

선택은 benchmark 평균이 아니라 quality-cost-latency frontier와 실제 query slice로 결정합니다.

앞 글에서는 text와 visual retrieval을 query에 따라 route했습니다. 이번에는 retrieval 자체를 사용할지, 관련 문서를 긴 context에 직접 넣을지 결정합니다.

예를 들어 회사 handbook 40개가 총 350,000 token이라고 합시다.

선택 A  모든 handbook을 prompt에 넣는다.
선택 B  질문마다 top-k chunk를 검색한다.
선택 C  관련 handbook 2개를 검색한 뒤 문서 전체를 넣는다.

Model이 1M token context를 지원한다고 해서 A가 자동으로 정답은 아닙니다. 입력 비용, prefill latency, distractor, 권한, freshness, citation까지 함께 봐야 합니다.

Long Context, RAG, retrieve-then-read hybrid를 corpus 범위와 운영 제약에 따라 선택하는 라우터

그림 1. Context capacity만 보지 않는다. Corpus coverage, evidence density, freshness, ACL, citation, budget을 검사하고 세 실행 경로 중 하나를 선택한다.

Context Window는 무엇을 뜻하는가

Context window는 model이 한 요청에서 처리할 수 있는 token 수의 상한입니다. 보통 다음 입력이 모두 포함됩니다.

system instruction
+ conversation history
+ tool schema
+ retrieved documents
+ user query
+ reserved output tokens
≤ context window

문서에 쓸 수 있는 실제 budget은 advertised window보다 작습니다.

const documentBudget =
  modelContextWindow
  - systemTokens
  - conversationTokens
  - toolSchemaTokens
  - queryTokens
  - reservedOutputTokens
  - safetyMarginTokens;

Capacity와 Effective Use를 구분한다

다음 세 질문은 서로 다릅니다.

입력이 context window 안에 들어가는가?
Model이 어느 위치의 정보도 동일하게 찾는가?
찾은 정보를 여러 distractor 사이에서 정확히 조합하는가?

첫 번째가 참이어도 두 번째와 세 번째는 보장되지 않습니다.

Lost in the Middle이 알려 준 것

Lost in the Middle 연구는 여러 문서를 넣은 질문 응답 등에서 relevant information의 위치에 따라 model 성능이 달라질 수 있음을 보였습니다. 일부 model과 실험 설정에서 시작이나 끝의 정보보다 중간 정보 활용이 약한 U자형 경향이 관찰됐습니다.

이를 다음처럼 과장하면 안 됩니다.

잘못된 일반화: "모든 LLM은 context 중간을 읽지 못한다."
더 정확한 해석: "지원 길이 안에서도 위치·길이·task·model에 따른
                 effective context 품질을 직접 측정해야 한다."

2023년 연구 결과를 최신 모든 model의 고정 법칙으로 취급할 수는 없습니다. 하지만 “token limit 안이므로 retrieval이 필요 없다”는 주장도 실험 없이 할 수 없습니다.

위치 외에도 어려운 이유

비슷하지만 틀린 distractor가 많습니다.
같은 entity의 이전 version과 최신 version이 섞입니다.
여러 문서의 exception을 조합해야 합니다.
긴 문서 안에서 exact evidence span이 희석됩니다.
conversation과 tool 결과가 document budget을 잠식합니다.

Long Context의 강점

1. Retrieval Miss를 줄인다

정답 문서를 통째로 넣으면 chunking이나 top-k에서 evidence가 탈락하는 문제를 피할 수 있습니다.

RAG failure:
gold evidence exists → chunking splits relation → retriever misses → no answer

Long-context path:
whole document included → generator can inspect original relation

2. 넓은 구조를 읽는다

문서 전체의 tone, section dependency, 반복되는 theme, 장거리 reference를 보존합니다.

계약 본문과 appendix
source code 여러 파일의 call relation
회의록 전체의 decision evolution
논문의 method와 limitation

3. Pipeline이 단순해진다

작은 corpus에서는 embedding, vector DB, chunk tuning 없이도 강한 baseline을 만들 수 있습니다.

4. Query 전에 Evidence를 고를 필요가 없다

질문의 의미가 애매하거나 전 corpus 요약이 필요한 경우 retriever가 너무 이르게 scope를 좁히지 않습니다.

Long Context의 비용

Input Token Cost

요청당 대략적인 입력 비용은 다음처럼 생각할 수 있습니다.

input_cost ≈ input_tokens × price_per_input_token

같은 200,000-token corpus를 매 요청에 보낸다면 query가 늘수록 반복 비용이 커집니다. Provider의 prompt caching이 도움을 줄 수 있지만 cache key, retention, discount, invalidation은 환경마다 다르므로 측정해야 합니다.

Prefill Latency

Autoregressive generation은 크게 두 단계입니다.

Prefill: 입력 token 전체를 처리해 KV state 생성
Decode:  한 token씩 다음 token 생성

입력이 길면 prefill 계산과 memory traffic이 증가합니다. 동일 model이라도 context length, hardware, batching, attention implementation에 따라 latency 곡선이 달라집니다.

KV Cache

Self-hosted serving에서는 긴 sequence의 key/value state가 GPU memory를 차지합니다. 단순화하면 KV cache는 다음 축에 비례합니다.

KV bytes ∝ layers × sequence_length × KV_heads × head_dim × bytes × 2(K,V)

정확한 값은 architecture의 GQA/MQA 여부, dtype, paging, quantization에 따라 달라집니다. 중요한 점은 context를 길게 잡을수록 동시 처리 가능한 sequence 수가 줄 수 있다는 것입니다.

Distractor와 충돌

문서를 많이 넣으면 recall은 올라갈 수 있지만 precision은 내려갈 수 있습니다.

policy-v1: 환불 30일
policy-v2: 환불 14일
draft:     환불 60일 제안

세 문서를 모두 넣고 version metadata를 명확히 표시하지 않으면 model이 plausible한 값을 섞을 수 있습니다.

RAG의 강점

1. Corpus가 Window보다 크다

수백만 문서나 지속적으로 쌓이는 log는 한 prompt에 넣을 수 없습니다. Retrieval은 query와 관련된 작은 working set을 만듭니다.

2. Freshness를 제어한다

Index가 최신 source version과 연결돼 있으면 매 query에서 최신 evidence를 선택할 수 있습니다. 물론 stale index를 막는 ingestion SLO가 필요합니다.

3. ACL을 Query마다 적용한다

User identity, tenant, project, document classification에 따라 search space를 먼저 제한할 수 있습니다.

authorized corpus filter
  → retrieve
  → rerank
  → hydrate context

Long Context에서도 권한 있는 문서만 넣어야 하지만, corpus 전체 bundle을 미리 만들면 user별 invalidation과 감사가 어려워질 수 있습니다.

4. Citation과 Trace가 쉽다

어떤 query가 어떤 chunk를 왜 선택했는지 기록할 수 있습니다. Answer claim을 source ID와 연결하기도 쉽습니다.

5. 비용과 Latency를 Budgeting한다

Top-k, reranker depth, context token을 query별로 제한할 수 있습니다.

RAG의 비용

RAG도 공짜가 아닙니다.

parser와 chunking 오류
embedding·index version 관리
retrieval miss
reranker latency
query rewrite drift
duplicate·contradictory context
ACL filter와 ANN recall의 상호작용
observability와 evaluation dataset 운영

특히 gold evidence가 top-k에 없으면 generator가 아무리 좋아도 답할 수 없습니다.

Long Context vs RAG 비교표

기준	Long Context	RAG
Corpus 크기	window와 비용 안의 작은 corpus	매우 큰 corpus
Evidence coverage	포함한 문서는 높음	retriever recall에 의존
Distractor	길수록 증가 가능	top-k로 제어
Freshness	bundle 재구성 필요	index update 필요
ACL	prompt 구성 전에 필터	retrieval 전에 필터
Citation	span extraction 추가	source record가 자연스러움
Query latency	긴 prefill	search + 짧은 prefill
운영 복잡도	작은 corpus에서 낮음	ingestion/index/eval 필요
Corpus-wide synthesis	강점 후보	global retrieval 전략 필요
Exact local lookup	과도할 수 있음	강점 후보

“승자”가 아니라 어느 failure와 비용을 감당할지의 선택입니다.

Hybrid 1: Retrieve Then Read Long

가장 실용적인 절충은 chunk 몇 개가 아니라 관련 문서나 section을 검색한 뒤 넓게 읽는 것입니다.

millions of chunks
  → cheap retrieval finds 2 documents
  → ACL + version validation
  → load full documents or large sections
  → long-context model reads 30k tokens
  → answer with source spans

이 구조는 RAG의 scope control과 Long Context의 broad reading을 결합합니다.

Parent-Child와 연결

34번 글의 parent-child가 바로 이 원리의 작은 형태입니다.

small child hit → larger parent hydration
document hit    → full document hydration

차이는 hydration granularity입니다.

LongRAG: Retrieval Unit을 길게 만들기

LongRAG 연구는 긴 context LLM을 활용해 retrieval unit 자체를 더 길게 구성하는 방향을 탐구합니다. 짧은 chunk 수가 많을 때보다 긴 unit 수가 적어 retrieval task를 단순화하고, 검색된 긴 unit을 reader가 처리하게 합니다.

직관은 다음과 같습니다.

Traditional RAG:
10M short chunks → retrieve many fragments → assemble context

LongRAG-style direction:
fewer long units → retrieve document-scale context → long reader

하지만 unit이 길어지면 embedding이 여러 topic을 섞고, irrelevant token 비용이 커질 수 있습니다. Document 구조와 query 분포에 맞춰 unit length를 실험해야 합니다.

Hybrid 2: Self-Route

Retrieval Augmented Generation or Long-Context LLMs? 연구는 평가한 여러 dataset/model 설정에서 충분한 resource가 있을 때 Long Context가 RAG보다 높은 성능을 보이는 경우와 더 높은 비용을 보고하고, model의 self-reflection을 이용해 query를 route하는 Self-Route를 제안했습니다.

이 결과를 production 법칙으로 그대로 옮기면 안 됩니다.

사용한 corpus와 task가 우리 환경과 다릅니다.
model과 가격은 바뀝니다.
ACL, freshness, citation 요구는 benchmark에 충분히 반영되지 않을 수 있습니다.
Self-reflection label 자체가 틀릴 수 있습니다.

대신 가져갈 원칙은 quality와 cost를 함께 최적화하는 per-query routing입니다.

Router의 입력 Feature

type RouteFeatures = {
  corpusTokenEstimate: number;
  authorizedCorpusTokenEstimate: number;
  queryScope: "local" | "multi_document" | "global";
  evidenceDensityEstimate: number;
  freshnessRequirement: "snapshot" | "latest";
  citationRequired: boolean;
  aclComplexity: "low" | "high";
  conflictRisk: "low" | "high";
  latencyBudgetMs: number;
  costBudgetUsd: number;
  routeConfidence: number;
};

Rule-Based 시작점

def choose_route(f):
    if f.aclComplexity == "high" or f.freshnessRequirement == "latest":
        return "rag"

    if f.queryScope == "local" and f.citationRequired:
        return "rag"

    if f.authorizedCorpusTokenEstimate <= SMALL_CORPUS_LIMIT:
        if fits_latency_and_cost(f):
            return "long_context"

    if f.queryScope in {"multi_document", "global"}:
        return "retrieve_then_read"

    return "rag"

처음부터 LLM router로 만들 필요는 없습니다. Rule은 재현·감사·fallback이 쉽습니다. 이후 offline label이 쌓이면 classifier나 learned policy를 비교합니다.

Route별 Context Contract

Long Context

{
  "route": "long_context",
  "snapshot_id": "handbook-2026-07-16",
  "documents": ["doc-1@v4", "doc-2@v9"],
  "ordering": "source_then_section",
  "token_count": 84200,
  "authorized_for": "user-hash",
  "expires_at": "..."
}

RAG

{
  "route": "rag",
  "index_version": "policy-index-42",
  "query": "...",
  "filters": { "tenant": "t1", "status": "active" },
  "top_k": 12,
  "rerank_k": 5,
  "context_tokens": 4200
}

Retrieve Then Read

{
  "route": "retrieve_then_read",
  "index_version": "policy-index-42",
  "selected_documents": ["doc-18@v7", "doc-21@v2"],
  "hydration": "full_document",
  "context_tokens": 28600,
  "citation_mode": "span"
}

Route가 달라도 source ID, version, ACL decision, context position을 공통 trace로 남깁니다.

Context Ordering도 Retrieval Decision이다

긴 context에 어떤 순서로 문서를 넣을지 결정해야 합니다.

가능한 정책

relevance score 내림차순
가장 중요한 evidence를 시작과 끝에 분산
source 문서 순서 유지
chronology 순서
subgoal별 group
primary source를 먼저, commentary를 뒤에 배치

어느 정책이 좋은지는 task에 따라 다릅니다. Position sensitivity test로 결정합니다.

for position in ["beginning", "middle", "end"]:
    prompt = place_gold_evidence(base_documents, at=position)
    result = answer(prompt)
    record(position, result)

Context Compression은 네 번째 선택지인가

Retrieved document를 요약하거나 irrelevant sentence를 제거하면 token을 줄일 수 있습니다. 그러나 compression도 model call이며 evidence 손실을 만듭니다.

retrieve → compress → generate
               ↑
        새로운 failure stage

Compression artifact에는 source span mapping을 유지하고 다음을 평가합니다.

answer-required fact retention
negation·exception retention
numeric fidelity
compression ratio
added latency와 cost

Abstractive summary만 남기지 말고 중요한 원문 span을 함께 보냅니다.

Security와 Privacy

Long Context는 “필요할지 모르는 문서”를 더 많이 model에 보냅니다. 이는 공격·노출 면적을 넓힐 수 있습니다.

위험

irrelevant 문서의 prompt injection
같은 prompt에 섞인 다른 tenant data
output에 불필요한 sensitive fact가 노출
provider request log에 더 많은 data 전송
stale snapshot에 삭제 요청된 data 잔존

원칙

authorize first
  → minimize corpus
  → mark documents as untrusted evidence
  → enforce output policy
  → log source usage

“Window에 들어가므로 전부 넣는다”는 least-privilege 원칙과 충돌할 수 있습니다.

Evaluation: 세 Route를 같은 조건에서 비교하기

Query Slice

scope:
  - single_fact
  - single_document_synthesis
  - multi_document_comparison
  - corpus_wide_theme
  - multi_hop
evidence:
  - exact_phrase
  - paraphrase
  - sparse
  - dense
  - conflicting_versions
operations:
  - latest_required
  - strict_acl
  - citation_required

Quality Metric

answer correctness
faithfulness
evidence recall
citation precision/recall
conflict resolution
abstention accuracy

Cost·Latency Metric

input/output token
retrieval·rerank·generation 비용
time to first token
end-to-end latency p50/p95
self-hosted GPU memory와 throughput
prompt cache hit rate

Position Stress Test

Gold evidence를 beginning, quartile 1, middle, quartile 3, end로 이동합니다. Distractor 수와 유사도를 함께 변화시킵니다.

stress_grid:
  positions: [0.05, 0.25, 0.50, 0.75, 0.95]
  distractors: [0, 10, 50, 100]
  conflict_versions: [0, 1, 3]

Oracle Ablation

A. short-chunk RAG
B. document retrieval + long read
C. full authorized corpus long context
D. oracle gold chunks
E. oracle gold documents

A < D: retriever 또는 chunking 병목
B < E: document retrieval 병목
E도 낮음: long-context reader의 reasoning 병목
C < E: distractor 또는 position 병목

Quality-Cost Frontier

하나의 평균 score로 결정하지 않습니다.

route               accuracy   p95 latency   input tokens   cost
RAG top-5             0.78        1.2s          4k          $
RAG top-20            0.82        1.8s         14k          $$
retrieve-then-read     0.87        3.1s         42k          $$$
full long context      0.88        8.7s        220k          $$$$$

숫자는 예시입니다. 0.01 quality 향상을 위해 5배 비용을 쓸 가치가 있는 query class만 비싼 route로 보냅니다.

Router 자체의 Metric

route별 선택 비율
oracle best route 대비 regret
budget violation rate
fallback rate
route confidence calibration
quality-cost frontier의 dominated request 비율

구현 순서

1단계: 세 Baseline을 만든다

short-chunk RAG
full-context 가능한 작은 evaluation corpus
retrieve-document-then-read

2단계: 공통 Trace

source와 version
context token 수
evidence position
retrieval candidate
cache status
latency와 cost

3단계: Rule Router

ACL, freshness, corpus size, scope, budget으로 deterministic routing을 시작합니다.

4단계: Shadow Comparison

선택하지 않은 route도 offline 또는 작은 sample에서 실행해 counterfactual quality를 모읍니다.

5단계: Threshold 조정

Query slice별 frontier를 보고 SMALL_CORPUS_LIMIT, top-k, full-document hydration 기준을 바꿉니다.

흔한 오해와 처방

1. 1M Window면 1M Token을 항상 잘 쓴다

Capacity와 position-robust evidence use는 다릅니다.

처방: 실제 model·task로 position와 distractor stress test를 합니다.

2. RAG는 오래된 Model을 위한 임시 기술이다

Retrieval은 context limit뿐 아니라 freshness, ACL, citation, cost control을 해결합니다.

처방: RAG의 목적을 token fit이 아닌 scoped evidence access로 정의합니다.

3. Long Context는 Retrieval Miss가 없다

Gold document가 bundle에 없거나 authorization filter가 틀리면 여전히 miss입니다. 포함돼도 model이 못 찾을 수 있습니다.

처방: corpus coverage와 evidence use를 분리해 측정합니다.

4. Prompt Cache가 비용 문제를 끝낸다

Cache 정책과 hit 조건은 serving 환경에 의존하며, 변경된 document는 invalidation이 필요합니다.

처방: 실제 hit rate와 uncached tail latency를 측정합니다.

5. Router를 LLM에게 물으면 된다

Router model도 틀리고, 항상 비싼 route를 고르거나 자신감을 과대평가할 수 있습니다.

처방: deterministic guardrail, calibrated confidence, budget ceiling을 둡니다.

6. 모든 문서를 넣는 편이 더 안전하다

Untrusted instruction과 sensitive data의 노출 면적이 커집니다.

처방: authorize와 minimize를 context 구성 전에 수행합니다.

Production 체크리스트

스스로 확인하기

Context window에 문서가 들어간다는 사실이 evidence 사용을 보장하지 않는 이유는 무엇인가?
Corpus가 작아도 ACL과 freshness 요구 때문에 RAG가 나을 수 있는 이유는 무엇인가?
Retrieve-then-read는 short-chunk RAG와 full Long Context의 어떤 장점을 결합하는가?
Gold evidence의 위치를 바꾸는 stress test가 필요한 이유는 무엇인가?
여러분의 query 중 품질 1%를 위해 5배 비용을 지불할 가치가 있는 class는 무엇인가?

다음 글에서는 prompt와 index tuning을 넘어, positive·hard negative·synthetic query로 domain dense retriever를 학습하는 방법을 다룹니다.