[LLM] RAG 고도화 여정기 — Naive RAG에서 GraphRAG까지, 그런데 시작은 Ingestion이다

처음 RAG를 붙였을 때 꽤 많은 팀이 비슷한 반응을 한다.

FIRST RAG EXPERIENCE

“어...? 생각보다 별론데?”

문서를 잘게 자르고, embedding해서 Vector DB에 넣고, 질문과 가까운 chunk 몇 개를 LLM에게 넘기면 꽤 그럴듯한 답이 나올 것 같았다.

실제로는 제품명 하나를 못 찾고, 다른 버전의 약관을 가져오고, 표는 반쯤 깨지고, 문장의 주어를 잃어버린 chunk가 검색되고, 정답 문서가 11등이라 Top-10에서 잘리는 일이 생긴다.

그래서 RAG를 운영하다 보면 자연스럽게 Hybrid Search, Reranker, Query Rewrite, GraphRAG 같은 기법을 하나씩 만나게 된다.

그런데 요즘 내가 더 강하게 느끼는 건 따로 있다.

MY TAKE

RAG에서 Retrieval만큼,
아니 어쩌면 그보다 먼저 봐야 하는 게 Ingestion이다.

검색기가 아무리 좋아도 인덱스에 잘못 들어간 지식은 복구할 수 없다. 잘린 표, 사라진 heading, 잘못 붙은 버전, 문맥을 잃은 chunk는 retrieval 단계에서 갑자기 원래 모습으로 돌아오지 않는다.

01. RAG를 “검색 알고리즘”으로만 보면 반쪽짜리다

RAG를 단순화하면 보통 이렇게 그린다.

Documents → Chunk → Embed → Retrieve → Generate

그런데 Production에서는 사실 두 개의 파이프라인이 있다.

RAG = OFFLINE KNOWLEDGE PIPELINE + ONLINE QUERY PIPELINE

INGESTION · OFFLINE

Parse → Normalize → Structure → Chunk → Enrich → Metadata → Embed → Index → Validate

↓ knowledge representation

RETRIEVAL · ONLINE

Query → Filter → Search → Fusion → Rerank → Context Assembly → Generate

Retrieval은 이미 만들어진 knowledge representation 안에서 정답을 찾는다.

즉 ingestion에서 지식을 어떻게 표현했는지가 retrieval의 탐색 공간을 결정한다.

02. “Naive RAG 정확도는 44%”라고 말하기 어려운 이유

RAG 자료를 보다 보면 “Naive RAG는 정확도가 대략 몇 %다” 같은 숫자를 종종 보게 된다.

이건 조금 조심해야 한다.

RAG 성능은 corpus, query difficulty, embedding model, chunking, Top-K, generator, 평가 방식에 따라 너무 크게 달라진다.

예를 들어 2026년 A-RAG 연구의 baseline만 봐도 Naive RAG의 LLM 평가 정확도는 데이터셋별로 크게 달라진다.

POINT

“Naive RAG는 44%라서 나쁘다”가 핵심이 아니다.

더 중요한 건 어디에서 실패하는지 모르는 Naive RAG가 문제라는 것이다. Retrieval recall이 낮은 건지, chunk가 나쁜 건지, 정답 context는 들어왔는데 generator가 놓친 건지부터 분리해야 한다.

Amazon 연구진의 RAGChecker도 같은 방향이다. RAG를 하나의 answer score로만 보지 않고 retriever와 generator를 분리해 진단할 수 있는 세부 metric을 제안한다.

03. 그리고 RAG 고도화는 RPG 스킬트리가 아니다

GraphRAG가 Naive RAG의 “최종 진화형”인 것처럼 설명되는 글도 많다.

실제로는 그렇지 않다.

WRONG MENTAL MODEL

Vector RAG
↓
Hybrid
↓
Reranker
↓
GraphRAG
↓
✨ FINAL BOSS ✨

기술은 문제 유형에 맞춰 선택해야 한다.

정확한 상품코드를 찾는 문제에 knowledge graph를 만드는 것보다 BM25 하나 붙이는 게 훨씬 나을 수 있고, 데이터셋 전체의 주요 테마를 묻는 질문에는 일반 Top-K vector search보다 GraphRAG가 훨씬 자연스럽다.

최근 연구도 “복잡한 기법 = 항상 우위”가 아님을 계속 보여준다.

• 2026년 academic-text chunking 비교에서는 cluster 기반 semantic chunking이 테스트 조건에서 fixed/recursive chunking을 이기지 못했다.
• 2026년 production-style RAG Fusion 연구에서는 multi-query가 raw recall은 높였지만, reranking과 context budget을 거치면서 이득이 사라졌고 일부 구성에서는 Hit@10이 0.51→0.48로 감소했다.

그래서 원칙은 하나

Technique-driven RAG가 아니라 Failure-driven RAG.

멋있어 보여서 GraphRAG를 붙이는 게 아니라, 현재 failure mode가 GraphRAG가 해결하는 문제인지 먼저 확인한다.

04. Stage 0 — 나는 이제 RAG 고도화를 Ingestion부터 본다

이 부분이 이번 글에서 제일 강조하고 싶은 내용이다.

흔히 ingestion은 그냥 “파일 읽어서 chunk 만들고 embedding 하는 배치 작업” 정도로 취급된다.

실제로는 RAG의 knowledge model을 만드는 과정이다.

PRODUCTION RAG INGESTION

Source Documents

↓

Parse
Text · Table · Layout

Normalize
Clean · Dedup

Version
Hash · Effective Date

↓

Structure
Heading · Section

Chunk
Child · Parent

Enrich
Context · Entity

↓

Metadata & Provenance
document_id · version · section_path · dates · source · ACL · derived labels

↓

Dense Index
Embeddings

Lexical Index
BM25

Optional Structure
Graph / Summary

↓

Ingestion Validation
coverage · orphan chunks · broken tables · duplicates · metadata completeness

이 단계가 약하면 뒤에서 아무리 retrieval을 고도화해도 계속 이상한 현상이 생긴다.

05. PDF에서 텍스트가 “추출됐다”와 지식이 “보존됐다”는 다르다

특히 금융 문서는 layout 자체가 의미인 경우가 많다.

제3조 보험금 지급사유
① 다음 각 호의 경우 ...
② 단, 별표 2의 기준에 따라 ...

[별표 2]
가입시점 | 보장조건 | 지급비율

단순 text extraction에서 reading order가 틀어지거나 표의 column 관계가 사라지면, embedding은 깨진 의미를 아주 성실하게 embedding할 뿐이다.

Azure AI Document Intelligence의 RAG 가이드도 fixed-size split과 별개로 layout/semantic structure를 활용한 chunking을 강조한다.

Ingestion에서 먼저 확인할 것

✓ heading hierarchy가 보존되는가?
✓ table row/column 관계가 보존되는가?
✓ footnote가 본문에 엉뚱하게 끼어들지 않는가?
✓ page break 때문에 하나의 조항이 두 의미 없는 chunk로 갈라지지 않는가?
✓ OCR confidence가 낮은 페이지를 식별할 수 있는가?

06. Chunking은 글자 수 자르기가 아니라 Retrieval Unit 설계다

“500 tokens + overlap 50”은 훌륭한 baseline이다.

하지만 그것이 정답은 아니다.

Dense X Retrieval 연구는 document, passage, sentence보다 더 미세한 proposition 단위까지 비교했고, retrieval unit 자체가 검색과 downstream QA 성능에 큰 영향을 준다는 것을 보였다.

Document
↓
Section
↓
Paragraph / Passage
↓
Sentence
↓
Proposition

너무 큰 chunk는 여러 주제가 embedding 하나에 압축된다. 너무 작은 chunk는 정밀하지만 문맥을 잃는다.

그래서 실무에서는 검색 단위와 LLM에게 전달할 단위를 분리하는 Parent-Child / Sentence Window 전략이 상당히 유용하다.

Search
small child chunk
↓ hit
Return to LLM
larger parent / surrounding window

ARAGOG 실험에서도 Sentence Window Retrieval이 비교 대상 중 retrieval precision에서 가장 강한 결과를 보였다. 다만 answer similarity에서는 일관되게 최고가 아니었다.

이것도 중요한 교훈이다.

retrieval metric 하나가 좋아졌다고 최종 answer quality도 반드시 같이 오르지는 않는다.

07. 최근 Chunking 연구들이 말하는 것: “문맥을 버리지 마라. 하지만 무조건 복잡하게도 하지 마라”

Late Chunking

일반적인 chunking은 먼저 문서를 자르고 각각 따로 embedding한다. 그래서 앞뒤 문맥이 embedding에 반영되지 않는다.

Late Chunking은 반대로 long-context embedding model로 문서 전체 token representation을 먼저 계산한 뒤 pooling 직전에 chunk 경계를 적용한다.

NORMAL

Chunk
↓
Embed

LATE CHUNKING

Whole Document Context
↓
Encode
↓
Chunk Pooling

아이디어는 Contextual Retrieval과 비슷한 문제의식에서 출발한다. 작은 retrieval unit은 유지하되, embedding representation에는 더 큰 문맥을 담자.

HiChunk / 2026 Chunking Evaluation

2025년 HiChunk는 hierarchical chunking을 위한 benchmark와 구조화 방법을 제안했고, 2026년에는 실제 긴 academic document를 대상으로 fixed, recursive, cluster-semantic chunking을 비교한 연구도 나왔다.

재미있는 점은 후자의 실험에서 더 복잡한 semantic chunking이 단순한 전략을 이기지 못했다는 것이다.

Chunking에도 No Free Lunch

문서 포맷, 질문 유형, embedding model, retrieval budget이 다르면 결과도 달라진다.

따라서 “semantic chunking이 무조건 더 좋다”가 아니라 내 corpus의 evidence가 어떤 granularity에 존재하는지를 먼저 봐야 한다.

08. 금융권 RAG에서는 Embedding보다 Metadata가 먼저 정답을 절반쯤 좁혀줄 때가 있다

보험 문서를 예로 들어보자.

같은 상품명이라도 가입 시점, 특약, 개정 버전에 따라 적용되는 약관이 다를 수 있다.

이런 문제를 전부 semantic similarity에게 맡기는 건 이상하다.

json · chunk metadata example

{
  "document_id": "POLICY-2026-001",
  "document_type": "policy_terms",
  "product_code": "P1234",
  "rider_code": "R07",
  "effective_from": "2026-01-01",
  "effective_to": null,
  "section_path": [
    "보험금 지급",
    "제3조 지급사유"
  ],
  "clause_id": "ART-3-2",
  "page": 17,
  "source_version": "v4",
  "content_hash": "...",
  "access_class": "internal",
  "derived_topics": [
    "입원",
    "면책"
  ]
}

Query 시점에는 먼저 deterministic metadata로 candidate space를 줄이고, 그 안에서 lexical/vector retrieval을 하는 구조가 훨씬 자연스러울 수 있다.

User Context
↓
Product / Version / Effective Date Filter
↓
Hybrid Retrieval
↓
Rerank
↓
Generation

여기서도 한 가지 원칙을 두는 게 좋다.

AUTHORITATIVE vs DERIVED

가입일, 약관 효력일, 상품코드처럼 정답을 결정하는 authoritative metadata를 LLM이 추측해서 만들게 해서는 안 된다.

LLM은 topic, intent, summary 같은 derived metadata를 보강하는 데 활용하고, 생성 모델·prompt version·confidence를 함께 남기는 편이 좋다.

09. Stage 1 — Contextual Retrieval: Chunk가 어디서 왔는지 알려준다

Anthropic의 Contextual Retrieval은 ingestion의 중요성을 보여주는 대표적인 예다.

이런 chunk가 있다고 해보자.

“회사의 매출은 전분기 대비 3% 증가했다.”

문장 자체만 보면 어느 회사인지, 언제인지 알 수 없다.

Contextual Retrieval은 전체 문서를 바탕으로 chunk 앞에 짧은 설명을 붙인다.

“이 chunk는 ACME Corp의 2023년 Q2 실적 보고서에 관한 내용이다.”

회사의 매출은 전분기 대비 3% 증가했다.

Anthropic 실험에서는 baseline의 top-20 retrieval failure rate 5.7%가 Contextual Embeddings만으로 3.7%, Contextual Embeddings + Contextual BM25에서 2.9%로 줄었다.

여기에 reranking까지 결합했을 때 1.9%까지 낮아졌다. 즉 baseline 대비 retrieval failure가 67% 감소했다.

여기서 재미있는 건 개선이 query-time 알고리즘만으로 일어난 게 아니라는 것이다.

chunk가 인덱스에 들어갈 때부터 더 좋은 표현을 만들어놨다.

10. Stage 2 — Hybrid Retrieval: Vector Search만 믿지 않는다

Embedding은 의미적으로 비슷한 표현을 찾는 데 강하다.

대신 제품코드, 오류코드, 약관 번호, 사람 이름처럼 문자열 자체가 중요한 query를 놓칠 수 있다.

VECTOR

Semantic Match

의역 · 동의어 · 개념 유사성

BM25

Lexical Match

상품명 · 코드 · 고유명사 · 정확한 문구

둘을 RRF 같은 rank fusion으로 합치는 Hybrid Search는 여전히 가장 먼저 시도할 만한 개선 중 하나다.

Anthropic의 실험에서도 embeddings 단독보다 BM25를 같이 쓰는 방향이 더 강했다.

11. Stage 3 — Reranking: “찾기”와 “순서 정하기”를 분리한다

첫 retrieval은 빠르게 candidate를 넓게 가져온다.

그 다음 cross-encoder나 reranker가 query와 candidate를 한 쌍으로 직접 보고 다시 점수를 매긴다.

Hybrid Search
↓
Top 50 candidates
↓
Cross-Encoder Reranker
↓
Top 5–10 context

효과는 분명히 있을 수 있지만 “reranker를 붙이면 항상 좋아진다”도 아니다.

ARAGOG 실험에서는 LLM reranking과 HyDE가 retrieval precision을 높인 반면, 테스트한 Cohere reranker나 MMR은 Naive RAG 대비 명확한 우위를 보이지 못했다.

반대로 Anthropic의 Contextual Retrieval 실험에서는 reranker가 큰 추가 이득을 줬다.

결론은 간단하다.

Reranker는 제품명이 아니라 실험 항목이다.

12. Stage 4 — Query Intelligence: 사용자의 질문 자체가 검색에 좋은 형태가 아닐 수 있다

HyDE

HyDE는 원 질문을 바로 embedding하지 않고, LLM에게 “정답 문서라면 대충 이렇게 생겼을 것”이라는 hypothetical document를 먼저 쓰게 한 뒤 그것을 embedding해 검색한다.

Short Query
↓
LLM-generated hypothetical answer/document
↓
Embed
↓
Retrieve real documents

원 HyDE 연구의 TREC DL19 결과에서는 unsupervised Contriever가 nDCG@10 44.5였던 데 비해 HyDE는 61.3까지 올라갔다.

다만 이 숫자는 특정 benchmark와 baseline에 대한 결과다. 모든 enterprise query에 같은 폭의 개선이 난다는 뜻은 아니다.

RAG Fusion / Multi-query

하나의 질문을 여러 관점으로 rewrite한 뒤 각각 검색하고, RRF로 결과를 합친다.

질문 표현이 corpus vocabulary와 안 맞는 경우 recall을 높일 수 있다.

하지만 2026년 production-style 연구가 보여준 것처럼 candidate를 많이 만드는 것이 최종 Top-K와 answer quality 개선으로 이어지지 않을 수도 있다.

특히 reranking budget이 작고 context window가 제한된 시스템이라면 늘어난 recall을 뒤 단계에서 다시 버릴 수 있다.

13. Stage 5 — Corrective / Adaptive RAG: 검색 결과를 무조건 믿지 않는다

CRAG

Corrective RAG는 retrieval evaluator로 검색 결과 품질을 판단하고, 결과가 좋지 않으면 다른 knowledge retrieval action을 수행한다.

원 논문에서는 external web search까지 활용한다.

Retrieve
↓
Retrieval Evaluator
↓
Good → Generate
Ambiguous → Refine
Bad → Alternate Retrieval

금융권이라면 여기서 “web fallback”을 그대로 복사하기보다 승인된 내부 source tier 안에서 fallback하는 식으로 바꾸는 편이 자연스럽다.

예를 들면:

Product Terms Index
↓ fail
Official Internal Policy DB
↓ fail
Human Escalation

Self-RAG

Self-RAG는 retrieval이 필요한지, 가져온 passage가 relevant한지, 생성 결과가 grounded한지를 reflection token을 이용해 모델 자체가 판단하도록 학습한다.

중요한 차이는 이것이 단순한 orchestration wrapper가 아니라 원 연구에서는 별도 학습이 필요한 모델 접근법이라는 점이다.

14. Stage 6 — Adaptive RAG: 모든 질문에 같은 파이프라인을 태우지 않는다

“회사 주소가 뭐야?”와 “지난 5년간 이 기업의 리스크 요인이 어떻게 변했어?”는 같은 retrieval budget을 쓸 필요가 없다.

Query
↓
Complexity / Intent Router
↓
Simple → No Retrieval / Direct lookup
Medium → Single Retrieval
Complex → Iterative / Multi-hop Retrieval

Adaptive-RAG 연구도 query complexity에 따라 서로 다른 retrieval strategy를 동적으로 선택하는 방향을 제안했다.

Production 관점에서는 이게 성능뿐 아니라 latency와 cost control에도 중요하다.

15. Stage 7 — RAPTOR: 긴 문서는 한 레벨의 chunk로만 이해하기 어렵다

일반 RAG는 짧은 contiguous chunk 몇 개를 가져오는 데 강하다.

그런데 질문이 문서 전체의 흐름이나 여러 장에 흩어진 정보를 요구하면 local chunk만으로는 부족할 수 있다.

RAPTOR는 leaf chunk를 embedding한 뒤 비슷한 chunk를 clustering하고, cluster를 다시 요약하고, 그 요약도 다시 clustering하면서 여러 abstraction level의 tree를 만든다.

High-level Summary
/ \
Topic Summary Topic Summary
/ \ / \
Chunk Chunk Chunk Chunk

원 논문에서는 GPT-4와 RAPTOR를 결합했을 때 QuALITY benchmark의 기존 best performance를 절대 정확도 기준 20% 향상시켰다고 보고했다.

16. Stage 8 — GraphRAG: “가장 비슷한 chunk”가 아니라 “관계”가 필요한 질문

Microsoft GraphRAG의 출발점은 꽤 명확하다.

일반 RAG는 “이 데이터 전체에서 주요 테마는 무엇인가?” 같은 global question에 약하다.

이 질문에는 가장 가까운 chunk 5개가 아니라 corpus 전체의 구조를 이해해야 하기 때문이다.

Documents
↓
Entity / Relationship Extraction
↓
Knowledge Graph
↓
Community Detection
↓
Community Summaries
↓
Global / Local Search

Microsoft의 원 연구에서는 약 1M-token 규모의 corpus에서 global sensemaking question에 대해 conventional RAG보다 answer comprehensiveness와 diversity가 개선됐다.

다만 GraphRAG는 indexing 자체가 훨씬 비싸고 복잡하다.

또한 simple fact lookup을 해결하려고 graph부터 만드는 것은 과할 수 있다.

GraphRAG를 고려할 신호

✓ 답이 여러 문서에 분산되어 있다.
✓ Entity 간 관계가 핵심이다.
✓ “전체적으로 어떤 패턴/테마가 있나?”가 중요하다.
✓ Multi-hop / global sensemaking query가 자주 등장한다.
✓ 높은 indexing cost를 정당화할 query volume/value가 있다.

Microsoft는 이후 DRIFT Search처럼 global community context와 local search를 결합하는 방향도 확장했다.

17. 재미있는 점: RAPTOR와 GraphRAG도 결국 “고급 Ingestion”이다

여기까지 오면 하나의 공통점이 보인다.

RAPTOR

Chunk를 clustering + summarization하여
tree representation을 미리 만든다

 

GRAPHRAG

Entity/relationship/community를 추출해
graph representation을 미리 만든다

고급 RAG라고 부르는 많은 기법이 사실 query-time search를 복잡하게 만드는 것만이 아니라 ingestion 단계에서 corpus를 더 풍부하게 구조화하는 방법이다.

이걸 깨닫고 나면 RAG architecture를 보는 시선이 조금 달라진다.

18. 내가 생각하는 Ingestion Maturity Level

LEVEL 0

Raw Split

PDF text → fixed chunk → embedding

LEVEL 1

Structure-aware

Heading · table · section · page lineage 보존

LEVEL 2

Retrieval-aware

Parent-child · contextualization · lexical + dense indexes

LEVEL 3

Domain-aware

Authoritative metadata · version · effective dates · taxonomy

LEVEL 4

Multi-representation

Chunk · summary · proposition · graph · hierarchical representation

LEVEL 5

Governed & Evaluated

Versioned pipeline · quality gate · re-index strategy · lineage · eval

19. Ingestion도 평가해야 한다 — “에러 안 났으니 성공”이면 부족하다

대부분의 ingestion batch는 이런 식으로 monitoring한다.

processed_files = 1,024
failed_files = 0
inserted_chunks = 84,231

✅ SUCCESS

그런데 84,231개의 chunk가 좋은 chunk인지는 전혀 알 수 없다.

나는 ingestion quality에도 별도 gate가 필요하다고 본다.

Layer	검증 예시
Parsing	추출 coverage · table count · OCR low-confidence
Chunking	size distribution · orphan heading · boundary 품질
Metadata	필수 field completeness · date validity · code mapping
Versioning	duplicate · stale version · effective-date overlap
Retrievability	gold question의 source chunk가 Top-K에 들어오는가

마지막 Retrievability Test가 특히 중요하다.

Ingestion이 끝난 뒤 실제 query set으로 retrieval test를 돌려야 한다. 그래야 “index build 성공”이 아니라 “지식이 검색 가능한 형태로 들어갔다”고 말할 수 있다.

20. RAG Eval도 End-to-End Accuracy 하나로 보면 원인을 못 찾는다

Ingestion Coverage
↓
Retrieval Recall
↓
Rerank Precision
↓
Context Utilization
↓
Answer Correctness / Groundedness

예를 들어 정답이 틀렸을 때 최소한 다음은 구분해야 한다.

Q1. Source data 자체가 index에 있었나?
Q2. 정답 evidence가 온전한 chunk로 존재했나?
Q3. Retriever가 Top-K 안에 가져왔나?
Q4. Reranker가 정답을 떨어뜨리진 않았나?
Q5. LLM context 안에는 들어갔나?
Q6. 들어갔는데도 LLM이 잘못 답했나?

이걸 안 나누면 retrieval 문제를 prompt 수정으로 해결하려 하고, parsing 문제를 reranker 교체로 해결하려는 일이 생긴다.

21. 실무용 증상별 처방표 — 이제는 Ingestion까지 포함해서

증상	먼저 의심할 것	후보 솔루션
표/조항 내용이 자꾸 깨짐	Parsing / Chunk boundary	Layout-aware extraction · structure chunking
다른 버전 문서를 가져옴	Metadata / Versioning	Effective-date filter · authoritative metadata
정확한 코드/상품명 누락	Lexical recall	Hybrid BM25 + Vector
좋은 후보는 찾는데 순위가 낮음	Ranking	Cross-encoder / LLM rerank
작은 chunk가 문맥을 잃음	Representation	Parent-child · Contextual Retrieval · Late Chunking
짧은 query가 corpus 표현과 안 맞음	Query representation	HyDE · query rewrite
한 표현으로는 recall 부족	Query coverage	RAG Fusion — 단, 비용/Top-K eval 필수
검색 결과 자체가 불량한 경우가 잦음	Retrieval confidence	CRAG-style corrective route
긴 문서 전체 흐름을 놓침	Abstraction level	RAPTOR · hierarchical summaries
관계/전체 테마 질문에 약함	Corpus structure	GraphRAG / DRIFT

22. 금융권 RAG라면 나는 이 순서로 돈을 쓸 것 같다

1

문서 파싱과 Version/Metadata 정리

정답 문서를 잘못 정의하면 뒤 단계가 전부 무의미하다.

2

Gold set + Source Evidence 구축

정답만이 아니라 어느 document/span이 근거인지 연결.

3

Hybrid Retrieval baseline

BM25 + dense + metadata filter.

4

Chunk / Context representation 실험

Parent-child · contextual · late chunking 등을 corpus 기준으로 비교.

5

Reranker / Query rewrite

측정된 failure가 있을 때만 추가.

6

Graph / Hierarchical RAG

실제 query가 multi-hop/global reasoning을 요구할 때 투자.

23. 결국 Retrieval의 상한선은 Ingestion이 정한다

예전에는 RAG 성능이 안 나오면 제일 먼저 retrieval algorithm부터 봤다.

Vector Search를 Hybrid로 바꾸고, Top-K를 조정하고, reranker를 붙이고, query rewrite를 해봤다.

물론 다 중요하다.

그런데 실제로 오래 붙잡고 있을수록 그보다 먼저 물어야 할 질문이 보인다.

정답 문서는 제대로 파싱됐나?
↓
정답이 하나의 의미 있는 unit으로 존재하나?
↓
상품 / 버전 / 날짜 metadata가 정확한가?
↓
이 chunk가 어디서 나온 것인지 문맥이 남아 있나?
↓
stale / duplicate 문서가 섞이지 않았나?
↓
그 다음에야 “검색기가 잘 찾나?”

MY TAKE

Retrieval은 이미 만들어진 지식 표현에서 답을 찾는다.
Ingestion은 무엇을 지식으로 만들지 결정한다.

그래서 RAG의 품질 상한선은 검색기보다 앞에서 결정되는 경우가 많다. 특히 보험 약관처럼 구조·버전·효력일·관계가 정답의 일부인 데이터에서는 더 그렇다.

Contextual Retrieval, Late Chunking, RAPTOR, GraphRAG를 쭉 놓고 보면 결국 하나의 흐름으로도 읽힌다.

Raw Text
↓
Better Chunks
↓
Context-aware Chunks
↓
Hierarchical Representations
↓
Graph Representations

좋은 RAG는 검색을 잘하는 시스템이기도 하지만, 그 전에 기업 지식을 검색 가능한 형태로 잘 만들어놓은 시스템이다.

그래서 요즘은 “Retrieval을 어떻게 고도화할까?”보다
“우리는 지식을 어떻게 ingest하고 있는가?”를 먼저 묻게 된다.

---

Papers & References

01. Anthropic — Introducing Contextual Retrieval

02. Chen et al. — Dense X Retrieval: What Retrieval Granularity Should We Use?

03. Günther et al. — Late Chunking: Contextual Chunk Embeddings Using Long-Context Embedding Models

04. Lu et al. — HiChunk: Evaluating and Enhancing RAG with Hierarchical Chunking

05. Kreileder et al. — Evaluating Chunking Strategies for RAG on Academic Texts

06. Eibich et al. — ARAGOG: Advanced RAG Output Grading

07. Gao et al. — Precise Zero-Shot Dense Retrieval without Relevance Labels (HyDE)

08. Rackauckas — RAG-Fusion: a New Take on Retrieval-Augmented Generation

09. Medrano et al. — Scaling RAG with RAG Fusion: Lessons from an Industry Deployment

10. Yan et al. — Corrective Retrieval Augmented Generation (CRAG)

11. Asai et al. — Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection

12. Sarthi et al. — RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval

13. Edge et al. — From Local to Global: A Graph RAG Approach to Query-Focused Summarization

14. Microsoft Research — DRIFT Search

15. Ru et al. — RAGChecker: A Fine-grained Framework for Diagnosing RAG

16. Microsoft — RAG with Azure AI Document Intelligence / Semantic Chunking

written by rubrub · AI / LLM / RAG Engineering