Copy English

Why

RAG exists because early context windows (2–4K tokens) could not hold enough of a document to answer a question, so Lewis et al.'s 2020 paper wired a retriever to a generator: fetch the relevant passages first, then generate from them. That constraint is largely gone — Gemini's 1M–2M-token windows and Claude's 1M-token window (2025) can hold a mid-size codebase or a few hundred pages outright — so the reflex "always RAG" is now often wrong, and the reflex "always long-context" is wrong in a different way. Getting the choice wrong either burns money and latency stuffing irrelevant tokens into every call, or produces a system that answers confidently from whichever chunk scored highest on cosine similarity while the chunk that actually held the fact sat one rank lower and was never fetched. That second failure has no error, no stack trace, nothing to grep for — it just looks like a correct answer that happens to be wrong.

How it works

The case for long context

• No pipeline. Skip document parsing, chunking heuristics, embedding models, a vector database, and cross-encoder re-rankers — stream the raw text into the prompt.
• No retrieval lottery. Vector search can miss the right chunk on vocabulary mismatch or a weak embedding, and the model never sees the fact it needed. That is a silent failure, not a crash.
• Whole-document synthesis. A question that needs two non-contiguous sections compared — an early spec against a later release note — needs the model attending over both at once. Retrieval returns fragments of each but not the gap between them, and the gap is usually the answer.

The case for RAG

• The rereading tax. Feeding 500k tokens on every query means paying quadratic self-attention cost on every request. Prompt caching only discounts a static prefix; a corpus that changes turn to turn gets no discount.
• Attention dilution. Even at 1M+ tokens, needle-in-a-haystack recall on a specific fact buried in a huge context measurably drops — the effect behind "Lost in the Middle" (Liu et al., 2023) and the broader NIAH benchmark family. RAG hands the model pure signal instead of signal plus haystack.
• Enterprise scale. A 1M-token window holds roughly 750k words. Enterprise data is measured in terabytes to petabytes. No window holds a corporate data lake, so an index is mandatory, not optional.

Decision matrix

Read this as a cost curve, not a rulebook: RAG pays once, at index time, and charges little per query; long context pays a little to set up and charges more on every single query. Below a certain corpus size, or above a certain reasoning complexity, the curves cross.

The hybrid: filter, then attend

Use RAG as a coarse filter over the unbounded corpus, narrowing it to a 50k–100k-token cluster of plausibly relevant material, then run a long-context pass over just that cluster. The model gets to do real cross-section reasoning inside the cluster instead of stitching disconnected fragments together. The vector index does not disappear in this pattern — it stays the semantic warehouse for the whole corpus, it just stops being the last step before an answer. Chunk boundaries should still follow semantic units (a function, a doc section) rather than a fixed character count, because a boundary that splits a unit in half degrades both the retrieval step and whatever the long-context pass does with the result afterward.

Where it lands in Jayverse

• alice: an index.md plus grep-before-add is the RAG half of the pattern. Before writing a new Knowledge Notes item, grep the existing markdown for the topic and check a generated index instead of re-skimming 1,300 files; that index is the retrieval layer, and the new item is what a long-context pass would need read whole anyway.
• Auditor: rules never get RAG'd. A rule that is not retrieved is a rule that is not checked, and that failure is silent — no error, just an unaudited change slipping through. Rules are small; they belong whole in context on every run, never behind a similarity search that can miss.
• Knowledge Notes: the add script needs an "already covered?" check. That is the retrieval-lottery risk made concrete — adding a new item is itself a RAG query against 550+ existing ones, and a missed hit produces a silent duplicate, not an error.
• Eng: "when would you not use RAG" is a real interview question now. The honest answer is the decision matrix above — bounded data and cross-document synthesis argue for long context, unbounded data and targeted lookups argue for RAG, and most production systems need both.

Verified and unverified

Verified on 2026-09-21: IBM Technology is a real YouTube channel and this video exists (youtube.com/watch?v=UabBYexBD4k, 11:10); frontier context windows of 1M+ tokens are real and shipped (Gemini 1.5/2.x, Claude with a 1M-token window in 2025); "Lost in the Middle" (Liu et al., 2023) and needle-in-a-haystack benchmarks document attention dilution over long contexts as a measured, reproducible effect; prompt caching for static prompt prefixes is offered by both Anthropic and OpenAI; the RAG architecture traces to Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (2020). Taken from the video summary and not independently checked: the specific 50k–100k-token figure given for the hybrid filter step, and any exact numbers or timestamps the video itself uses beyond the general claims above (no timestamps were given in the source summary for this item). Sources: YouTube — IBM Technology, "Is RAG Still Needed? Choosing the Best Approach for LLMs" · Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks," 2020 · Liu et al., "Lost in the Middle: How Language Models Use Long Contexts," 2023 · related items: Tech #62 (learning greed — raw layer plus generated index.md), Tech #109 (code graph, Graft), Tech #102 (first silent failure, MLflow).

← All Knowledge Notes · Workspace Index · Top ↑

Copy 한국어

RAG냐 긴 컨텍스트냐는 선택이 아니다 — 실전 패턴은 RAG로 거르고 긴 컨텍스트로 주의를 기울이는 것이다

IBM Technology가 11분짜리 영상 "Is RAG Still Needed? Choosing the Best Approach for LLMs"(youtube.com/watch?v=UabBYexBD4k)에서, 최상위 모델의 컨텍스트 윈도우가 100만~200만 토큰에 이른 지금 양쪽 주장을 정리한다. 긴 컨텍스트 쪽 주장은 이렇다. RAG의 파이프라인(파싱, 청킹, 임베딩, 벡터 데이터베이스, 재순위화)과 그 조용한 실패 모드—맞는 청크가 아예 검색되지 않았는데 모델이 태연히 답하는 것—를 없앤다. RAG 쪽 주장은 이렇다. 전체 컨텍스트를 매번 프롬프트에 넣으면 요청마다 제곱 비용의 "다시 읽기 세금"을 내야 하고, 건초더미 속 바늘 찾기 회상에서 측정 가능한 주의 희석이 일어나며, 윈도우가 아무리 커져도 테라바이트~페타바이트 규모의 기업 데이터는 담을 수 없다. 영상 자신의 결론은 의사결정 매트릭스에 더해 하이브리드 패턴이다. RAG로 무한한 코퍼스를 5만~10만 토큰 클러스터로 걸러낸 다음, 그 클러스터에 대해 긴 컨텍스트 어텐션으로 실제 추론을 돌리라는 것.

Jayverse에서 이것은 추상적인 이야기가 아니다. alice 저장소의 Knowledge Notes는 이미 550개 이상의 항목과 약 1,300개의 마크다운 파일을 갖고 있고, "이거 이미 썼던가"는 jay가 매일 손으로 답하는 검색 질의다.

왜

RAG가 존재하는 이유는 초기 컨텍스트 윈도우(2K~4K 토큰)가 질문에 답할 만큼 문서를 담지 못했기 때문이다. 그래서 Lewis 외(2020) 논문은 검색기를 생성기에 연결했다. 먼저 관련 구절을 찾고, 그다음 그것으로부터 생성한다. 그 제약은 이제 대체로 사라졌다. Gemini의 100만~200만 토큰 윈도우와 Claude의 100만 토큰 윈도우(2025)는 중간 규모 코드베이스나 몇백 페이지를 통째로 담을 수 있다. 그래서 "항상 RAG"라는 반사는 이제 종종 틀리고, "항상 긴 컨텍스트"라는 반사는 다른 방식으로 틀린다. 선택을 잘못하면 매 호출에 무관한 토큰을 채워 넣어 돈과 지연을 태우거나, 코사인 유사도 점수가 가장 높았던 청크로부터 자신 있게 답하는 시스템을 만들게 된다. 정작 사실을 담고 있던 청크는 한 순위 아래에 있었고 끝내 검색되지 않았는데도 말이다. 이 두 번째 실패에는 에러도 스택 트레이스도 grep할 대상도 없다. 그저 맞는 답처럼 보이는, 사실은 틀린 답일 뿐이다.

동작 방식

긴 컨텍스트 쪽 주장

• 파이프라인이 없다. 문서 파싱, 청킹 휴리스틱, 임베딩 모델, 벡터 데이터베이스, 크로스 인코더 재순위화를 건너뛰고, 원문을 그대로 프롬프트에 흘려 넣는다.
• 검색 로또가 없다. 벡터 검색은 어휘 불일치나 약한 임베딩 때문에 맞는 청크를 놓칠 수 있고, 모델은 필요했던 사실을 아예 보지 못한다. 이는 크래시가 아니라 조용한 실패다.
• 문서 전체 종합. 서로 떨어진 두 구간을 비교해야 하는 질문—초기 명세서와 나중의 릴리스 로그의 차이—은 모델이 둘을 동시에 주시해야 한다. 검색은 각각의 조각을 돌려줄 뿐 그 사이의 간극은 돌려주지 못하는데, 보통 그 간극이 곧 답이다.

RAG 쪽 주장

• 다시 읽기 세금. 매 질의마다 50만 토큰을 넣는다는 것은 요청마다 제곱 자기어텐션 비용을 낸다는 뜻이다. 프롬프트 캐싱은 고정된 프리픽스만 할인해 주고, 턴마다 바뀌는 코퍼스에는 할인이 없다.
• 주의 희석. 100만 토큰이 넘어도, 거대한 컨텍스트 안에 묻힌 특정 사실에 대한 건초더미 속 바늘 찾기 회상은 측정 가능하게 떨어진다. "Lost in the Middle"(Liu 외, 2023)과 더 넓은 NIAH 벤치마크 군이 보여주는 효과다. RAG는 건초더미 대신 순수한 신호만 모델에 건넨다.
• 기업 규모. 100만 토큰 윈도우는 약 75만 단어를 담는다. 기업 데이터는 테라바이트에서 페타바이트 단위로 측정된다. 어떤 윈도우도 기업 데이터 레이크를 담지 못하므로, 색인은 선택이 아니라 필수다.

의사결정 매트릭스

이 표는 규칙집이 아니라 비용 곡선으로 읽어야 한다. RAG는 색인 시점에 한 번 비용을 내고 질의당 비용은 적다. 긴 컨텍스트는 준비 비용은 작지만 질의마다 더 낸다. 코퍼스 크기가 어떤 임계값 아래거나 추론 복잡도가 어떤 임계값 위면, 두 곡선이 교차한다.

하이브리드: 거르고 나서 주의를 기울인다

RAG를 무한한 코퍼스 위의 성긴 필터로 써서 그럴듯하게 관련 있는 5만~10만 토큰 클러스터로 좁힌 다음, 그 클러스터에만 긴 컨텍스트 패스를 돌린다. 모델은 끊어진 조각들을 이어붙이는 대신 클러스터 안에서 진짜 구간 간 추론을 할 수 있다. 이 패턴에서 벡터 색인은 사라지지 않는다. 코퍼스 전체의 의미 창고로 계속 남고, 다만 답으로 가는 마지막 단계가 아니게 될 뿐이다. 청크 경계는 여전히 고정 글자 수가 아니라 의미 단위(함수 하나, 문서 한 절)를 따라야 한다. 한 단위를 반으로 자르는 경계는 검색 단계와 이후 긴 컨텍스트 패스가 그 결과로 하는 일 모두를 나쁘게 만들기 때문이다.

Jayverse에서의 위치

• alice: index.md와 추가 전 grep이 이 패턴의 RAG 절반이다. 새 Knowledge Notes 항목을 쓰기 전에 기존 마크다운을 주제로 grep하고 생성된 색인을 확인하라, 1,300개 파일을 다시 훑는 대신. 그 색인이 검색 계층이고, 새로 쓸 항목은 어차피 긴 컨텍스트 패스가 통째로 읽어야 할 대상이다.
• Auditor: 규칙은 절대 RAG하지 않는다. 검색되지 않은 규칙은 확인되지 않은 규칙이고, 그 실패는 조용하다. 에러 없이 그냥 감사받지 않은 변경이 통과할 뿐이다. 규칙은 작다. 매 실행마다 통째로 컨텍스트에 있어야 하며, 놓칠 수 있는 유사도 검색 뒤에 숨어서는 안 된다.
• Knowledge Notes: 추가 스크립트에 "이미 다뤘나?" 확인이 필요하다. 이것이 검색 로또 위험의 구체적인 모습이다. 새 항목을 추가하는 것 자체가 기존 550개 이상에 대한 RAG 질의이고, 놓친 히트는 에러가 아니라 조용한 중복을 낳는다.
• Eng: "언제 RAG를 쓰지 않겠는가"는 이제 실제 면접 질문이다. 정직한 답은 위의 의사결정 매트릭스다. 경계가 있는 데이터와 문서 간 종합은 긴 컨텍스트를, 무한한 데이터와 표적 검색은 RAG를 지지하며, 대부분의 실전 시스템은 둘 다 필요하다.

확인된 것과 미확인

2026-09-21 확인: IBM Technology는 실제 YouTube 채널이고 이 영상은 존재한다(youtube.com/watch?v=UabBYexBD4k, 11:10). 100만 토큰 이상의 최상위 컨텍스트 윈도우는 실재하고 출시되어 있다(Gemini 1.5/2.x, 2025년 100만 토큰 윈도우를 갖춘 Claude). "Lost in the Middle"(Liu 외, 2023)과 건초더미 속 바늘 찾기 벤치마크들은 긴 컨텍스트에서의 주의 희석을 측정 가능하고 재현 가능한 효과로 문서화한다. 고정 프롬프트 프리픽스에 대한 프롬프트 캐싱은 Anthropic과 OpenAI 둘 다 제공한다. RAG 아키텍처는 Lewis 외, "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"(2020)로 거슬러 올라간다. 영상 요약에서 가져왔고 독립적으로 확인하지 않은 것: 하이브리드 필터 단계에 제시된 5만~10만 토큰이라는 구체적 수치, 그리고 위의 일반적 주장 이상으로 영상 자체가 사용하는 정확한 수치나 타임스탬프(이 항목의 출처 요약에는 타임스탬프가 없었다).

출처: YouTube — IBM Technology, "Is RAG Still Needed? Choosing the Best Approach for LLMs" · Lewis 외, "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks," 2020 · Liu 외, "Lost in the Middle: How Language Models Use Long Contexts," 2023 · 관련 항목: Tech #62(학습 탐욕 — 원자료 레이어와 생성된 index.md), Tech #109(코드 그래프, Graft), Tech #102(첫 조용한 실패, MLflow).

← 전체 기술 노트 · 워크스페이스 인덱스 · 맨 위 ↑