RAG 기본기 Q&A — 청킹부터 리랭커까지 20문답

RAG를 설계하다 보면 같은 질문이 반복해서 돌아온다. "청크를 얼마로 잡나", "top-k를 늘리면 안전한가", "임베딩 모델을 바꾸면 어떻게 되나" 같은 것들이다. 이 글은 그 질문들에 결론부터 답하고 근거를 뒤에 붙인다.

절반은 오해를 교정하는 문항이다. "청크를 키우면 답이 좋아진다", "리랭커를 넣으면 검색이 좋아진다" 같은 직관이 왜 틀렸는지가 실제로는 더 중요하다. 전체 구조는 RAG 파이프라인 8단계 시리즈에 있다. 파싱과 검증 쪽 질문은 품질 Q&A, 비용·관측·거버넌스 쪽은 운영 Q&A로 나눠 두었다.

핵심 수치 정리

설계에서 반복해 등장하는 값들이다. 값만 외우면 응용이 안 되므로 왜 그 값인지를 함께 둔다.

Q. 문서를 통째로 넣지 않고 분할하는 이유는 무엇인가

정확성과 효율성 두 가지다. 그런데 두 번째가 첫 번째로 이어진다는 점이 중요하다.

"구글이 앤스로픽에 투자한 금액은 얼마인가"라는 한 문장에 답하려고 보고서 전체를 넣을 이유가 없다. 넣으면 비용만 드는 것이 아니라 정보에 파묻혀 답을 못 찾는다.

Q. 청크를 크게 하면 답이 좋아지나

아니다. 양방향 트레이드오프라 한쪽만 좋아지지 않는다.

크게 잡으면 문맥은 늘지만 검색 정밀도가 떨어지고 노이즈·비용이 늘며, 긴 문맥에서는 중간 정보가 묻힌다. 증상별로 방향이 갈린다.

Q. dense와 sparse 중 무엇을 쓰나

둘 다 쓴다. 하이브리드가 실무 기본값이고, 서로의 약점을 정확히 메우기 때문이다.

dense 단독으로 가면 제품코드·연도·약어 검색이 조용히 실패한다. 그것이 하이브리드를 기본값으로 두는 이유다.

Q. BM25는 TF-IDF와 무엇이 다른가

문서 길이를 보정한다는 점이 결정적 차이다.

TF-IDF는 단어가 문서에 나타나는 빈도와 그 단어가 몇 개 문서에서 나타나는지를 반영한다. 자주 나타나면서 전체 문서 집합에서는 드문 단어가 높은 가중치를 받는다.

BM25는 여기에 두 가지를 더한다.

두 개선 모두 토큰이 무엇인지 정해진 뒤에 작동한다. 한국어에서 그 토큰을 정하는 것이 형태소 분석기이고, 사전에 무엇을 등록했느냐에 따라 같은 문장이 다르게 쪼개진다 — 한글 검색 구현에서 다룬다.

Q. 벡터DB 하나면 검색이 다 되나

아니다. dense 단독은 정확 일치가 필요한 질의에 약하다.

임베딩은 희귀 토큰을 잘 표현하지 못한다. 제품코드·약어·연도처럼 의미가 아니라 문자열 자체가 정답인 경우에 BM25 병행이 필요하다.

Q. 임베딩 모델을 바꾸면 어떤 일이 생기나

전체 재색인이 필요하다. 운영에서 가장 비싼 변경이다.

그래서 "성능 좋은 걸로 아무거나"는 위험한 선택이다. 모델을 고르는 시점에 언어(한국어 문서면 다국어 성능이 검증됐는지), 차원 수, 최대 입력 길이, 비용, 보안을 한 번에 결정해야 한다.

Q. 벡터스토어는 무엇을 기준으로 고르나

성능 비교표가 아니라 기존 운영 스택·데이터 규모·보안 요건의 함수다.

세 번째와 네 번째 행이 실무에서 가장 자주 정답이 된다. 이미 운영 중인 것이 있으면 총비용에서 대체로 앞선다.

Q. 리랭커는 왜 필요하고 언제 넣나

1차 검색은 빠르지만 정확도가 떨어지기 때문이고, 정답이 검색 결과에는 있는데 순위가 낮을 때 넣는다.

핵심은 두 단계의 역할 분담이다. Retriever는 넓고 빠르게, Reranker는 좁고 정확하게다.

Q. 리랭커를 넣으면 검색이 좋아지나

1차 검색이 정답을 아예 못 가져오면 아무 소용이 없다. 리랭커는 순위만 고친다.

그래서 리랭커를 붙이기 전에 진단이 먼저다.

"리랭커를 붙였는데 품질이 그대로"라는 증상은 거의 항상 첫 번째 행이다.

Q. Bi-Encoder와 Cross-Encoder는 어떻게 다른가

질문과 문서를 따로 인코딩하느냐, 같이 인코딩하느냐가 전부다.

같이 넣기 때문에 문맥을 고려한 심층 분석이 가능하지만, 그 대가로 미리 계산해 둘 수 없다.

Q. Cross-Encoder를 전체 문서에 적용하면 안 되나

사전 인덱싱이 불가능해 문서 수만큼 실시간 추론이 필요하다. 이것이 리랭커의 명시적 한계다.

100만 건 인덱스에 Cross-Encoder를 직접 걸면 질의 한 번에 100만 회 추론이다. 그래서 구조가 2단계로 고정된다 — Bi-Encoder로 5~10개까지 좁힌 뒤에만 Cross-Encoder를 쓴다.

Q. top-k를 크게 하면 안전하지 않나

아니다. 세 가지가 동시에 나빠진다.

k를 늘리는 대신 리랭커로 상위만 정제하는 편이 낫다. 후보를 넓게 가져오되 프롬프트에 넣는 것은 좁히는 구조다.

Q. MMR은 언제 켜고 λ를 어떻게 정하나

질의 유형별로 다르게 둔다. "MMR을 기본으로 켠다"는 선택은 틀렸다.

그리고 fetch_k를 함께 봐야 한다. fetch_k를 k와 같게 두면 MMR은 무력화된다 — 고를 후보가 없으니 유사도 순서를 거의 그대로 내보낸다. k의 4~10배가 기준이다.

MMR을 쓰지 말아야 할 경우도 명확하다. 단일 사실 조회(다양성이 정답을 밀어냄), 인덱스에 문서가 애초에 적을 때(후보 풀이 좁음), 이미 리랭커를 붙였을 때(역할이 겹침)다. 알고리즘의 동작 원리는 토큰 비용과 MMR에 정리했다.

Q. RAG를 쓰면 할루시네이션이 없어지나

줄이는 방법이지 없애는 방법이 아니다. 이 구분은 어휘 문제가 아니라 설계 문제다.

검색이 틀린 문서를 가져오면 RAG는 오히려 더 그럴듯한 오답을 만든다. 그래서 생성 단계가 아니라 검색·검증 단계에서 막아야 한다.

Q. temperature는 기본값을 써도 되나

0에 가깝게 둔다. RAG는 창작이 아니라 근거 기반 요약·추출이기 때문이다.

같은 이유로 분류·추출·판정 노드도 전부 0으로 둔다. 판정은 특히 재현성이 생명이라, 같은 입력에 같은 결과가 나와야 지표가 의미를 갖는다.

Q. 문서를 지우면 검색에서도 사라지나

청크 ID와 원문 ID의 매핑을 관리하지 않으면 사라지지 않는다.

문서는 청크 단위로 저장되므로, 원문 1개가 인덱스에서는 수십 개의 레코드다. 삭제하려면 그 수십 개를 찾아낼 키가 있어야 한다.

이것은 나중에 붙일 수 없다. 적재 설계 시점에 정해야 할 문제다.

Q. 상용 챗봇에 파일을 올리면 되지 않나

과정이 블랙박스라 실패 원인을 특정할 수 없다는 것이 결정적 차이다.

마지막 행이 실무에서 결정적이다. 개선 수단이 "문서 형태를 바꾸는 것"뿐인데 사내 문서 전체의 형태를 바꾸는 것은 현실적으로 불가능하다.

Q. RunnablePassthrough는 왜 필요한가

입력 하나(질문)가 두 갈래로 갈라져야 하기 때문이다.

chain = (
    {"context": retriever | format_docs, "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)

한 갈래는 검색기로 들어가 문맥이 되고, 다른 한 갈래는 원본 그대로 프롬프트의 질문 자리로 간다. RunnablePassthrough가 그 두 번째 갈래다. 이것이 빠지면 프롬프트의 {question} 자리가 비어 버린다.

Q. 출력파서는 왜 쓰나

LLM 출력은 자유형식 텍스트라 후속 시스템이 그대로 쓸 수 없기 때문이다.

파싱이 실패하는 전형적 원인은 LLM이 코드펜스나 설명문을 덧붙이는 것이다. 프롬프트에 형식 지시를 넣고, 스키마 강제가 필요하면 Pydantic 파서로 검증한다.

Q. RAG 답변 품질이 낮다는 신고가 오면 무엇부터 확인하나

정답 문서가 검색 결과에 들어 있는지부터 본다. 이 분기 하나가 이후 진단을 전부 가른다.

이 순서를 건너뛰고 프롬프트를 고치거나 모델을 바꾸면 원인과 무관한 곳을 만지게 된다. 전체 진단표는 실패 모드 종합 진단에 있다.

용어 정리