사내 문서를 LLM에게 물어볼 수 있게 만들고 싶다—— 그렇게 생각하여 RAG를 조사하면, "청킹 (Chunking)", "임베딩 (Embedding)", "벡터 DB (Vector DB)", "리랭킹 (Reranking)" 등 용어가 한꺼번에 등장한다.

개별 개념은 이해할 수 있어도, 전체가 어떻게 연결되어 있는지가 보이지 않는 것이 초보자가 겪는 어려움이다.

이 기사에서는 RAG 파이프라인을 데이터 수집부터 답변 생성까지의 4단계로 나누어, 각 단계의 역할과 입출력을 정리한다.

┌─────────────────────────────────────────────────────────┐
│ 오프라인 (데이터 업데이트 시 실행) │
│ │
...

수집은 원본 데이터를 RAG가 다룰 수 있는 텍스트로 변환하는 공정이다. 여기가 부실하면 후속 단계에서 아무리 공을 들여도 정밀도는 올라가지 않는다.

노이즈 제거: 헤더·푸터·페이지 번호·광고 텍스트 삭제 -
인코딩 정규화: 글자 깨짐·전각 반각 통일 -
메타데이터 부여: 원본 파일명, 섹션 제목, 업데이트 날짜, URL, 권한 정보 -
중복 제거: 동일한 내용의 복사본을 인덱스에 넣지 않음

메타데이터는 검색 시 필터("2024년 이후의 문서만" 등)로 사용할 수 있으므로, 처음부터 설계해 두면 나중에 편하다.

텍스트를 **검색 가능한 단위(청크, Chunk)**로 분할하고, 벡터화하여 데이터베이스에 등록하는 단계다.

초보자를 위한 초기값은 "5001000토큰, 오버랩 1020%"가 무난하다. 너무 작으면 문맥이 끊기고, 너무 크면 검색 정밀도가 떨어진다.

청크 텍스트
→ 임베딩 모델 (text-embedding-3-small, multilingual-e5 등)
→ 768~3072차원의 벡터
...

인덱스 구축은 데이터 업데이트 시마다 재실행한다. 차분 업데이트 (변경분만 upsert)에 대응하도록 설계해 두면 대규모 데이터에서도 운용하기 쉽다.

사용자의 질문이 왔을 때, 인덱스에서 관련되어 보이는 청크를 추출하는 단계다.

질문 「PostgreSQL에서 벡터 검색 인덱스를 만들려면?」
↓ (임의) 쿼리 변환: 바꾸어 말하기, HyDE, 멀티 쿼리 전개
↓ 벡터 검색: 질문을 임베딩 → 코사인 유사도로 Top-50
...

검색에서 반환하는 건수 (Top-K)는 LLM의 컨텍스트 길이와 비용의 균형에 따라 결정한다. 3~5건이 많은 구현의 초기값이다.

검색 결과를 프롬프트에 포함하여, LLM이 최종 답변을 생성하는 단계다. RAG의 "G (Generation)"는 이곳을 가리킨다.

【시스템 프롬프트】
당신은 사내 문서를 바탕으로 답변하는 어시스턴트입니다.
제공된 컨텍스트에 없는 정보는 추측하지 말고, "자료에 기재되어 있지 않습니다"라고 답변해 주세요.
...

파이프라인 설계에서 가장 혼란스러워하기 쉬운 것이, 언제 무엇이 작동하는가의 구분이다.

오프라인 처리를 온라인 경로에 섞으면 사용자가 체감하는 레이턴시 (Latency)가 급증한다. 반대로, 온라인에서 매번 임베딩 (Embedding)을 재계산하는 설계도 피해야 한다.

| 프레임워크 | 수집 | 청크 분할 | 임베딩 | 검색 | 생성 |
|---|---|---|---|---|
| LangChain | Document Loaders | Text Splitters | Embeddings 클래스 | Retriever | LLM Chain |
| ... |

프레임워크를 사용할 때도 내부에서는 위의 4단계가 실행된다. 추상화된 이름이 다를 뿐, 개념은 동일하다.

오프라인 (인덱스 구축)

• 수집 시 메타데이터 (source, updated_at, 권한)를 부여하고 있는가
• 청크 크기 (Chunk size)와 오버랩 (Overlap)을 설정 파일에 명시하고 있는가
• 임베딩 (Embedding) 모델을 고정하여 검색 시와 동일한 모델을 사용하고 있는가
• 데이터 업데이트 시 차분 upsert / 전체 재구축 방침을 결정했는가

온라인 (질의응답)

• 검색의 Top-K (3~5)를 컨텍스트 길이 (Context length)와 비용으로부터 역산하고 있는가
• 시스템 프롬프트 (System Prompt)에 "컨텍스트 외의 내용은 추측하지 말 것"이라는 지시를 넣었는가
• 답변에 출처 (파일명·페이지·URL)를 포함하도록 설계되었는가
• 검색 결과가 0건일 때의 폴백 (Fallback, "관련 정보를 찾을 수 없습니다")을 구현했는가

운영·품질

• 오프라인과 온라인 처리를 분리하고, 온라인 경로의 레이턴시 (Latency)를 측정하고 있는가
• 테스트 질문 20개로 검색 결과의 타당성을 수동으로 확인하고 있는가
• 인덱스 업데이트 후 스모크 테스트 (Smoke Test, 대표 질문 3개)를 자동 실행하고 있는가

패턴 1: 청크 분할을 미루고 전체 텍스트 검색을 수행함

수백 페이지의 PDF를 하나의 청크 (Chunk)로 임베딩한다. 검색 시 "관련 부분"만 추출할 수 없다.

→ 대책: 반드시 청크 분할 (Chunking)을 수행한다. 기술 문서라면 제목 단위의 구조적 분할부터 시작한다.

패턴 2: 오프라인과 온라인의 임베딩 모델이 불일치함

인덱스 구축 시와 검색 시에 서로 다른 모델을 사용하여, 벡터 공간 (Vector space)이 어긋나 검색 정밀도가 망가진다.

→ 대책: 모델명을 설정 파일에서 일원 관리하며, 변경 시에는 인덱스 전체를 재구축한다.

패턴 3: 검색 결과를 그대로 LLM에 전달하고 출처를 표시하지 않음

답변은 그럴싸하지만, 사용자가 어떤 문서에 기반했는지 검증할 수 없다.

→ 대책: 청크의 메타데이터를 프롬프트와 답변 모두에 포함한다.

패턴 4: 인덱스 업데이트를 잊어 오래된 정보로 답변함

3개월 전의 매뉴얼이 인덱스에 남아 있어, 최신 버전의 변경 사항이 반영되지 않는다.

→ 대책: 문서 업데이트 시 인덱스 재구축을 트리거한다 (Webhook, 정기 배치 등).

• RAG 파이프라인은 수집 → 인덱스 구축 → 검색 → 생성의 4단계로 나누어 이해한다.

• 전반부 2단계는 오프라인 (데이터 업데이트 시), 후반부 2단계는 온라인 (질문 시마다)으로 작동한다.

• 각 단계의 입출력을 명확히 하면, 정밀도 개선 시 "어디를 수정할지" 판단하기 쉬워진다.

• 프레임워크의 이름은 달라도 개념은 같다. 먼저 전체상을 파악한 뒤 개별 기술을 깊게 파고드는 것이 좋다.

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (원 논문)

• LangChain — Document Loaders

• LangChain — Text Splitters

• LlamaIndex — High-Level Concepts

• Pinecone — What is RAG?

• Weaviate — RAG

• OpenAI — Embeddings Guide