Rag (chunking, fixed-window, Semantic)

📚 기본 배경지식: 청킹(Chunking)이란?
RAG(검색 증강 생성) 시스템을 만들 때, 수백 페이지짜리 책을 AI에게 통째로 주면 기억을 잘 못하거나 비용이 많이 듭니다. 그래서 책을 잘게 쪼개서 저장하는데, 이 쪼개는 과정을 청킹(Chunking)이라고 합니다. 대표적인 방법 두 가지가 문제에 나왔습니다.
1. 고정 창 청킹 (Fixed-window / Fixed-size Chunking):
• 방식: 의미와 상관없이 무조건 글자 수나 토큰 수(예: 300글자씩)로 뚝뚝 자르는 방식입니다.
• 장점: 속도가 매우 빠르고 컴퓨터 연산 비용이 거의 들지 않아 단순하고 예측 가능합니다.
2. 시맨틱 청킹 (Semantic Chunking):
• 방식: 문장들을 읽어 내려가다가 '이야기의 주제나 맥락이 바뀌는 지점(의미적 경계)'을 찾아내어 유연하게 자르는 방식입니다.
• 장점: 문맥이 중간에 끊기지 않아 이론적으로는 검색 품질이 더 좋아질 것이라 기대합니다.

RAG 파이프라인 3단계 법칙
시험에서 시스템의 흐름(Pipeline)을 묻는 순서 배치나 역할 문제가 자주 나옵니다.
• 1단계 (지식 베이스 분할): 대규모 문서를 인덱스에 저장/점수 매길 수 있도록 작은 조각(Chunk)으로 쪼갭니다.
• 2단계 (임베딩 및 인덱싱): 각 청크를 숫자로 변환(Embedding)하여 저장(Index)합니다.
• 3단계 (프롬프트 주입): 질문과 가장 관련 있는 청크를 뽑아 프롬프트에 주입(Context Grounding)하여 모델이 두뇌(메모리)가 아닌 주어진 본문에서 답변하게 만듭니다.
• ⚠️ 시험 출제 포인트: "청킹은 후속 전체 프로세스의 천장(Ceiling)을 결정한다." 즉, 1단계(청킹)에서 데이터를 잘못 쪼개면 아무리 검색기나 LLM이 똑똑해도 오답을 냅니다.

많은 개발 팀이 "무조건 의미대로 쪼개는 시맨틱 청킹이 검색을 더 잘하겠지?"라고 착각(Assume)합니다.
하지만 대규모 벤치마크와 실제 연구 결과는 다릅니다.
• 임베딩 품질의 중요성: 텍스트를 아무리 의미 있게 잘 쪼개도, 그 텍스트를 숫자로 변환해 주는 '임베딩 모델(Embedding Model)'의 지능(품질)이 낮으면 서로 관련 있는 내용을 찾아내지 못합니다.
• 반대로, 훌륭한 임베딩 모델을 사용하면 약간의 텍스트 겹침(Overlap)을 둔 고정 창 청킹만 써도 시맨틱 청킹과 성능이 비슷하거나 오히려 더 안정적인 결과를 보여줍니다. 청킹 전략 자체보다 어떤 임베딩 모델을 썼느냐가 검색 품질을 좌우(Dominate)하는 경우가 대부분입니다.

청킹을 조절하는 3가지 노브 (Knobs)
아키텍처 설계 시 수치적 장단점(Trade-off)을 비교하는 문제로 출제됩니다.
• 크기 (Size): 청크의 토큰 수
• 작게 쪼개면: 정밀도(Precision)가 높아져 좁은 범위의 질문에 강함. 대신 문맥이 끊김.
• 크게 쪼개면: 주변 문맥을 잘 보존함. 대신 노이즈가 섞여 검색 신호가 희석(Dilute)됨.
• 경계 (Boundary): 어디서 자를 것인가
• 고정 창(Fixed-window): 의미 무시, 정해진 토큰 수로 무조건 자름.
• 시맨틱(Semantic): 문맥, 주제, 섹션이 바뀌는 지점을 찾아서 자름.
• 오버랩 (Overlap): 앞뒤 청크 사이에 겹치게 두는 토큰 수
• 목적: 경계면에 걸쳐진 중요한 아이디어가 쪼개져 소실되는 것을 방지함.
• 비용: 인덱스 저장 공간이 중복으로 늘어남.
3. [★가장 중요] 시험 단골 오답 함정과 진실
Anthropic(클로드 개발사)의 공식 가이드라인에 기반한 시험지 정답 단골 멘트들입니다.
• ❌ 함정 선지: "시맨틱 청킹은 언제나 고정 창 청킹보다 뛰어난 검색 품질을 보장한다."
• ⭕ 실제 정답: 고정 창 방식도 시맨틱과 비교할 만한(Comparable) 성능을 냅니다. 시맨틱은 비용이 많이 들고 튜닝이 어려우며, 노력 대비 얻는 이득이 적은 경우가 많습니다.
• ⭕ 진실 (Priority): 임베딩 모델의 품질(Embedding Quality)이 청킹 전략보다 검색 품질을 지배(Dominate)합니다. 팀들이 성능 낮은 임베딩 모델을 쓰면서 청킹 방식만 고민하느라 시간을 낭비하는데, 이를 뒤집어(Flip) "똑똑한 임베딩 모델을 먼저 확보"하는 것이 핵심입니다.
4. 디버깅 및 트러블슈팅 용어
에러 상황이 주어지고 원인을 찾는 문제에 나오는 키워드입니다.
• 파편화 문제 (Bare fragment problem): 청크 하나를 문서에서 떼어냈을 때 주변 맥락이 사라져 덩그러니 남는 현상. 질문이 누락된 맥락에 의존할 때 검색 품질을 떨어뜨림.
• Recall at K: 상위 K개의 검색 결과 안에 진짜 관련된 청크가 얼마나 포함되어 있는지를 뜻하는 지표. 시스템 성능을 직관적으로 측정할 때 씀.

🎯 시험 합격을 위한 아키텍트의 표준 행동 지침 (Order of Method)
시험 문제에서 "새로운 지식 베이스를 구축할 때 아키텍트가 취해야 할 올바른 순서는?" 하고 물으면 이 순서를 고르세요.
1. Baseline 구축: 단순하고 강력한 고정 창(Fixed-window) 방식으로 기준점을 잡는다.
2. Overlap 추가: 경계면 데이터 손실을 막기 위해 적절한 오버랩을 설정한다.
3. Embedder 투자: 청킹을 더 복잡하게 바꾸기 전에, 강력한 임베딩 모델을 도입한다.
4. Measure (측정): 실제 쿼리를 던져 Recall at K 등의 지표(숫자)를 확인하고, 지표가 증명할 때만 시맨틱 청킹 등의 복잡성을 추가한다. (직관에 의존 금지)

콘텍스트 기반 검색(Contextual Retrieval)'**의 핵심 메커니즘

1. 기술의 정의 및 개념
   • Contextual Retrieval(콘텍스트 기반 검색): 텍스트를 쪼갠 각 청크(Chunk)가 전체 문서 내에서 어떤 위치와 의미를 가졌는지 설명하는 '짧은 콘텍스트 요약'을 작성하여, 청크 앞에 붙인(Prepend) 후 인덱싱하는 Anthropic의 독자적인 기술입니다.
   • Chunk Context Generation(청크 콘텍스트 생성): LLM을 사용해 각 조각이 원본 문서의 어느 위치에 속해 있는지 설명하는 약 50~100 토큰 내외의 짧은 설명을 자동으로 만들어내는 과정입니다.
2. ⚠️ 시험에서 무조건 파고드는 '핵심 단서' (Timing)
   시험 문제에서 아키텍처의 부하(Overhead)나 비용, 작동 타이밍을 묻는 보기가 나올 때 오답을 골라낼 수 있는 가장 중요한 포인트입니다.
   • 수행 시점은 무조건 '인덱싱 시간(Indexing Time)'입니다.
   • ❌ 시험 함정: "사용자가 질문을 던지는 실시간 검색(Query/Inference Time) 단계에서 각 청크의 콘텍스트를 생성한다."
   • ⭕ 진실: 질문을 받기 전, 지식 베이스(Knowledge Base)를 처음 구축하고 벡터 DB에 저장(Indexing)하는 시점에 미리 LLM을 돌려 콘텍스트를 붙여두는 것입니다.
3. 이 기술이 해결하는 실전 아키텍처 문제
   이 기술은 앞선 강의에서 언급된 '파편화 문제(Bare fragment problem)'를 완벽하게 치료합니다.
   • 기존 문제점: 수백 페이지짜리 재무제표 문서에서 "2024년 2분기 순이익은 5% 증가했다"라는 한 줄을 뚝 떼어내어 청크로 만들면, 나중에 사용자가 "A회사의 2024년 2분기 순이익이 어때?"라고 물었을 때, 청크 자체에 'A회사'라는 단어가 없어서 검색기가 이 청크를 찾지 못하고 놓칩니다.
   • Contextual Retrieval의 해결책: 청크 앞에 [이 조각은 A회사의 2024년 재무제표 중 2분기 실적 발표 섹션에 포함된 내용입니다]라는 50~100 토큰짜리 배경 설명을 LLM이 미리 적어서 붙여줍니다. 덕분에 검색기가 핵심 키워드(A회사, 재무제표 등)를 쉽게 인식하고 정확하게 찾아올 수 있습니다.

🎯 시험 대비 핵심 요약 키워드
• 동작: 청크 앞에 50~100 토큰의 배경 설명을 Prepend(앞에 추가) 함.
• 타이밍: 사용자가 질문할 때가 아니라, 데이터베이스를 만드는 Indexing Time(인덱싱 시점)에 실행됨.
• 효과: 컨텍스트가 단절된 파편화된 청크에 '문맥적 똬리(Anchor)'를 틀어주어 검색 정확도를 극적으로 향상시킴.

3단계 하이브리드 검색 적층(Stacking) 구조와 성능 지표
시험 문제에서 "Anthropic 가이드라인에 따라 하이브리드 검색 성능을 극대화하는 올바른 아키텍처 적층 방식은?" 또는 각 단계별 누적 효과를 묻는 연산형 문제가 출제됩니다. Anthropic은 검색 실패율 감소(Reduction in retrieval failure) 지표를 기준으로 설명합니다.
• Layer 1: Contextual Embeddings (콘텍스트 기반 임베딩)
• 설명: 배경 설명(Context)이 추가된 청크를 고차원 의미 매칭을 하는 밀집 벡터 인덱스(Dense Vector Index)에 저장.
• 성능: 단독 적용 시 검색 실패율 약 35% 감소.
• Layer 2: Contextual BM25 (콘텍스트 기반 BM25)
• 설명: 동일한 콘텍스트 강화 청크를 정확한 키워드/고유명사 매칭을 하는 희소 어휘 인덱스(Sparse Lexical Index)에 중복 저장.
• 성능: Layer 1과 결합 시(하이브리드) 실패율 약 49% 감소 (임베딩 단독 효과가 아님을 인지할 것).
• Layer 3: Re-ranking (리랭킹)
• 설명: 위 두 인덱스에서 넓게 뽑아온 후보군을 크로스 인코더(Cross-encoder) 리랭커 모델로 다시 정렬하여 최종 압축.
• 성능: 전체 스택 완성 시 실패율 약 67% 감소.
• ⚠️ 시험 출제 포인트: 이 수치들은 범용 상수가 아닌 Anthropic 자체 벤치마크 결과입니다. 시험에서는 "각 레이어는 독립적으로 도입 및 측정이 가능하며, 결합할수록 효과가 누적(Compound/Stacking)된다"는 아키텍처적 본질이 정답으로 출제됩니다.
2. 경제성 및 지연 시간(Latency) 최적화의 핵심: 프롬프트 캐싱
시험에서 가장 많이 파고드는 "비용(Cost)과 성능의 트레이드오프" 단골 문제입니다.
• 실시간 처리(Query Time)가 아님: 콘텍스트 생성은 사용자가 질문할 때 일어나는 것이 아니라, 데이터를 파싱하는 인덱싱 시점(Indexing Time)에 딱 한 번 실행됩니다. 따라서 사용자가 체감하는 실시간 답변 속도(Query Latency)에는 추가적인 오버헤드가 전혀 없습니다.
• 프롬프트 캐싱(Prompt Cashing)의 역할: 매 청크마다 수백 페이지의 원본 문서를 처음부터 다시 읽히면 비용이 파산 수준으로 커집니다. 아키텍트는 원본 문서를 한 번 캐시(Cache)에 로드해 두고, 그 안에서 모든 청크의 콘텍스트(50~100 토큰)를 캐시 읽기 방식으로 저렴하게 생성해야 합니다.
• ⚠️ 시험 출제 포인트: 콘텍스트 기반 검색을 대규모 환경에서 경제적으로 현실성 있게(Affordable/Economical) 만드는 일등 공신은 모델의 단가 하락이 아니라 "프롬프트 캐싱 아키텍처 기법" 그 자체입니다.
3. 아키텍트의 콘텍스트 기반 검색 도입 기준 (언제 쓸 것인가?)

이 기술은 앞선 강의에서 언급된 '파편화 문제(Bare fragment problem)'를 완벽하게 치료합니다.
• 기존 문제점: 수백 페이지짜리 재무제표 문서에서 "2024년 2분기 순이익은 5% 증가했다"라는 한 줄을 뚝 떼어내어 청크로 만들면, 나중에 사용자가 "A회사의 2024년 2분기 순이익이 어때?"라고 물었을 때, 청크 자체에 'A회사'라는 단어가 없어서 검색기가 이 청크를 찾지 못하고 놓칩니다.
• Contextual Retrieval의 해결책: 청크 앞에 [이 조각은 A회사의 2024년 재무제표 중 2분기 실적 발표 섹션에 포함된 내용입니다]라는 50~100 토큰짜리 배경 설명을 LLM이 미리 적어서 붙여줍니다. 덕분에 검색기가 핵심 키워드(A회사, 재무제표 등)를 쉽게 인식하고 정확하게 찾아올 수 있습니다.

틀린 예시
( Semantic chunking reliably outperforms fixed-window across most corpora and query types : 시맨틱 청킹이 대부분의 상황에서 고정 창을 압도한다):
실제 대규모 벤치마크 결과, 단순 고정 창 방식이 시맨틱 청킹보다 최종 답변 정확도가 더 높게 나오는 경우가 많아 틀린 설명입니다. 시맨틱 청킹은 문장이 너무 짧게 쪼개지거나 파이프라인이 복잡해지는 부작용이 있습니다

(Chunk boundary precision is the single largest factor in retrieval quality : 청크 경계의 정밀도가 검색 품질의 단일 최대 요인이다):
글자를 정확히 어디서 자르느냐(경계면)보다는 청크의 전체적인 크기(Size)나 임베딩/리랭커(Reranker) 모델의 성능이 품질에 훨씬 더 큰 영향을 미치므로 틀린 설명입니다.

(Larger chunks tend to improve recall because more context is embedded : 청크가 커지면 컨텍스트가 더 많이 임베딩되므로 재현율이 향상되는 경향이 있다):
청크 크기가 너무 커지면 중요한 핵심 정보(Signal)가 주변의 쓸데없는 텍스트에 파묻혀 희석(Dilute)되기 때문에 검색 품질이 오히려 나빠집니다. 무조건 커진다고 검색 품질이 좋아지지 않으므로 틀린 설명입니다.