RAG 파이프라인 만들기

문서를 잘라 넣고 검색해서 답하게 하는 것까지. 단계마다 기본값으로 뭘 고르고 언제 바꾸는지만 적었다. 개념은 embeddings-and-vector-search 로 위임한다.

0. 먼저 — RAG 를 안 만들어도 되는 경우

이 절을 맨 앞에 둔 이유가 있다. 대부분은 여기서 끝난다.

RAG 를 짓는 건 문서가 컨텍스트에 안 들어갈 만큼 많고, 자주 바뀌고, 질의가 단발성일 때다. 그게 아니면 위 네 줄이 더 싸고 정확하다.

롱컨텍스트가 RAG 를 없애지는 않는다. 규모가 커지면 결국 검색이 필요하다. 다만 시작부터 RAG 를 지을 이유는 대부분 없다.

1. 청킹 — 정답 없음, 512 토큰에서 시작

기본값: recursive 청킹, 512 토큰, 10~20% 오버랩 (verified 2026-08).

의미 기반(semantic) 청킹이 항상 이기지 않는다. 문서 종류에 따라 단순 recursive 분할이 더 나은 경우가 흔하다. 도메인마다 다르니 재보고 정하라 — 이게 정직한 답이다.

⚠️ 오버랩은 통념만큼 만능이 아니다. 리트리버 종류에 따라 이득 없이 저장·임베딩 비용만 늘 수 있다 (재확인 필요). 오버랩을 늘리기 전에 그게 실제로 recall 을 올리는지 재봐라.

RAG 실패의 대부분은 LLM 이 아니라 적재·청킹 단계에서 생긴다. 여기를 대충 하고 뒷단을 튜닝하는 게 가장 흔한 시간 낭비다.

2. 임베딩과 저장

모델 선택 기준(차원·다국어·비용)과 벡터DB 비교는 embeddings-and-vector-search 에 있다. 요약하면:

• 이미 Postgres 를 쓰고 있으면 pgvector 로 시작하라. 전용 벡터DB 는 규모가 실제로 커진 뒤에.
• 임베딩 모델은 나중에 바꾸면 전체 재색인이다. 처음에 다국어 지원 여부를 확인해라 — 한국어 문서가 섞이면 특히.
• 청크와 함께 메타데이터(문서 ID, 섹션 제목, 갱신일)를 저장해라. 3단계 필터링과 6단계 인용에 쓴다.

3. 검색 — 하이브리드가 기본이다

dense(벡터) 단독은 정확 매칭을 놓친다. 제품 코드, 법조문 번호, 고유명사, 에러 코드 — 의미는 비슷한데 글자가 정확히 맞아야 하는 것들이다.

기본값: BM25(sparse) + dense 를 각각 top-50 검색 → RRF 로 합침.

RRF(Reciprocal Rank Fusion)는 순위만 쓰는 단순한 결합이다. score = Σ 1/(k + rank), k = 60 이 관례. 점수 스케일이 다른 두 검색기를 정규화 없이 합칠 수 있어서 널리 쓰인다. 일반 QA 라면 dense 0.6 / sparse 0.4 가중치에서 시작한다.

지연은 거의 안 늘고 recall 은 눈에 띄게 오른다. 하이브리드를 안 할 이유가 별로 없다.

4. 리랭킹 — 가장 가성비 높은 한 수

RAG 파이프라인에 하나만 더 붙일 수 있다면 리랭커다.

패턴: 20~50개 후보를 검색 → 리랭커로 상위 5개 추림 → LLM 에 전달.

cross-encoder 는 쿼리와 문서를 같이 읽어서 점수를 매긴다. 그래서 임베딩 유사도보다 정확하지만 느리다 — 수백만 건을 통째로 리랭크할 순 없다. 그래서 항상 "넓게 검색 → 좁게 리랭크" 2단이다.

정밀도가 확실히 오르는 대신 지연이 붙는다. 실시간 채팅이면 이 지연을 감당할 수 있는지 재봐라.

5. 프롬프트 조립

• 가장 관련 높은 청크를 맨 끝에 둬라. 모델은 컨텍스트 끝에 더 주의를 준다. 중간에 묻히는 문제는 tokens-and-context-windows 참고.
• 청크마다 출처 메타를 붙여라: [출처: {document_id} | 섹션: {heading}]
• 조립한 컨텍스트를 무작정 키우지 마라. 길수록 좋아지지 않는다 — 리랭커로 걸러낸 소수만 넣는 게 낫다.

6. Grounding 과 인용

Claude 는 search_result 콘텐츠 블록으로 자체 문서를 웹 검색 결과처럼 인용하게 할 수 있다. 베타 헤더 없이 표준 Messages API 로 동작한다 (verified 2026-08).

{
    "type": "search_result",
    "source": "https://intra.example.com/policy/2026-q3",   # 필수
    "title": "2026 Q3 환불 정책",                            # 필수
    "content": [{"type": "text", "text": chunk_text}],      # 필수, 텍스트만
    "citations": {"enabled": True},                          # 기본 꺼짐 — 켜야 인용한다
}

두 가지로 넣을 수 있다 — 검색 툴이 tool_result 로 반환하거나(동적), user 메시지에 직접 넣거나(사전 조회). 둘 다 citations 를 켜면 별도 프롬프팅 없이 알아서 인용한다.

⚠️ 한 요청 안의 모든 search_result 는 citations 설정이 같아야 한다. 섞으면 안 된다. 그리고 content 는 텍스트만 — 이미지는 못 넣는다.

인용을 강제하는 게 환각 완화에 실질적으로 가장 효과가 큰 축에 든다. hallucination 참고.

7. 평가 — 이거 없이 튜닝하지 마라

여기가 이 문서에서 제일 중요한 절이다. 평가 세트 없이 청킹 크기나 임베딩 모델을 바꾸는 건 눈 감고 손대는 것이다. 좋아졌는지 나빠졌는지 알 방법이 없다.

골든셋: 라벨링된 질의 50~100개. 도메인 전문가가 쓴 것 25~30개를 코어로 두고 나머지는 합성·실제 로그에서 채운다.

네 지표를 분리해서 봐라 — 검색이 틀린 건지 생성이 틀린 건지 구분돼야 고칠 수 있다:

RAGAS 같은 도구가 이 지표들을 계산해준다. 권장 임계값이 돌아다니지만 표준이 아니다 — 프로젝트마다 다시 정해라 (재확인 필요). 청킹·임베딩·검색·프롬프트를 바꿀 때마다 CI 에서 돌려라.

운영에서 추가로

• 시맨틱 캐싱 — 비슷한 질의가 반복되면 검색·생성을 건너뛴다. 반복 질의가 많은 서비스에서 효과가 크다.
• 무결과 알림 — 검색 결과 0건 비율이 튀면 지식베이스 커버리지 구멍이다. 모니터링해라.
• 에이전틱 RAG 는 필요할 때만. 여러 번 순차 검색이 필요한 복잡한 질의에만. LLM 호출이 배로 늘고 느려진다 — 대부분의 질의엔 과하다.

참고

• embeddings-and-vector-search — 임베딩 모델·벡터DB·청킹 개념
• set-up-tool-use — 검색을 툴로 붙이는 법
• hallucination — grounding 이 왜 가장 효과적인 완화책인가
• tokens-and-context-windows — 컨텍스트 끝에 두라는 이유
• prompt-caching — RAG 대신 통째로 캐싱하는 선택지
• context-engineering — 검색 결과를 컨텍스트 예산에 어떻게 배분할까

출처: search_result 블록·인용은 Anthropic 공식 [HIGH]. 청킹·하이브리드·리랭킹·평가 기본값은 서드파티 프로덕션 가이드 [MED aggregator] — 수치가 아니라 방향으로 읽어라. 원본 → 2026-08-01-playbooks-tooluse-rag