RAG 파이프라인 구축은 문서를 청크로 나눠 임베딩한 뒤 질의에 맞는 조각을 검색해 생성 모델에 넣는 구성입니다. 프로덕션은 오프라인 인덱싱과 온라인 질의 두 흐름으로 나뉩니다. 인덱싱과 질의에는 같은 임베딩 모델과 설정을 써야 벡터 공간이 맞습니다.
수집은 로더에서 벡터 인덱스까지 이어지고 질의는 전처리 후 검색과 재순위화를 거쳐 답을 씁니다. 청크는 보통 200~500 토큰에 이웃 오버랩을 두고 초기 후보는 5~20개에서 고릅니다. 페이지가 너무 크면 제목과 문단 경계로 더 나누는 편이 검색 정밀도에 유리하고 생성 근거도 분명해집니다. 질의 임베딩도 수집 때와 같은 모델로 맞춰야 후보 순위가 인덱스와 맞게 안정됩니다.
RAG 파이프라인이 하는 일과 핵심 구성
프로덕션 RAG는 오프라인 인덱싱으로 수집·청크·임베딩·벡터 저장을 끝내고 온라인 질의에서 검색·재순위화·생성을 돌립니다. 인덱싱을 한 번 잘 만들어 두면 질의 쪽에서 같은 벡터를 반복해 쓸 수 있어 응답 경로가 짧고 단순해집니다. LangChain 검색 파이프라인도 소스에서 Document Loader, 청크 분할, 임베딩, 벡터 스토어 순으로 이어진 뒤 질의 임베딩으로 문서를 찾습니다.
질의 임베딩으로 찾은 문서를 LLM이 근거로 사용하며 출처 없는 문장은 답에서 빼게 합니다. 한쪽에만 모델을 바꾸면 검색이 어긋나므로 배포 전에 토큰화 방식과 출력 차원, 정규화를 맞춰 두십시오. 벡터 저장소에는 본문과 함께 출처 URL과 제목을 남겨 생성이 문장 옆에 인용을 붙일 수 있게 합니다. 이 골격이 같아야 이후 재순위화도 후보를 질문과 가까.
검색과 생성의 역할 나누기
검색은 관련 청크를 고르는 일이고 생성은 그 청크를 근거로 답을 쓰는 일입니다. 검색이 빗나가면 생성 품질이 바로 떨어지므로 후보를 넉넉히 가져온 뒤 재순위화로 좁혀 상위만 남기는 편이 안전합니다. 생성 단계에 원문 전체를 넣으면 노이즈가 늘고 지연도 커지며 모델이 엉뚱한 문장을 섞어 근거 추적이 어려워집니다.
생성 프롬프트에는 선택된 조각만 넣고 근거 밖 단정을 막으십시오. 인용을 남기면 오답 추적이 쉬워지고 사내 규정처럼 출처가 중요한 질의에도 문장 단위로 대응하기 좋습니다. 검색 점수와 생성 문장을 같이 로그에 남기면 어느 단계에서 틀렸는지 구분하기 좋습니다. 역할이 섞이면 환각과 근거 누락을 나중에 가르기 어렵고 수정 범위도 넓어져 운영 비용과 재작업 시간이 커집니다.
RAG 파이프라인 구축 검색과 생성의 역할 나누기에서 검색자가 실제로 확인하고 싶어 하는 조건과 예외를 중심으로 설명합니다.
벡터 DB·임베딩 모델 고르는 기준
인덱싱과 질의에 같은 임베딩 모델 계열과 설정을 써야 합니다. 불일치하면 벡터 공간이 어긋나 검색 품질이 떨어지며 실제로 가까운 문서가 순위 밖으로 밀려 답이 빈약해집니다. 고를 때는 차원 수, 다국어 지원, 지연 시간, API 비용, 필터에 쓸 메타데이터 필드를 같이 보고 샘플 질의로 순위를 확인하십시오.
모델을 바꾸면 기존 벡터는 쓰지 말고 전 코퍼스 인덱스를 처음부터 다시 만드십시오. 벡터 DB는 메타데이터 필터와 용량, 백업, 운영 부담을 기준으로 고르면 됩니다. 한국어 사내 문서가 많으면 해당 언어에서 검증된 임베딩을 우선하는 편이 질의 매칭에 안정적입니다. 차원만 크고 도메인 문체가 안 맞으면 질문과 무관한 문서가 위에 올라오고 재순위화 부담과 지연도 커집니다.
문서 수집부터 임베딩·검색까지 단계별 구축
(출처: 테디노트 TeddyNote)
수집은 로더로 원문을 읽고 청커로 나눈 뒤 임베딩해 벡터 인덱스에 넣습니다. 질의는 같은 모델로 임베딩한 뒤 최근접 검색으로 후보를 고르고 필요한 메타데이터 필터를 같은 요청에 같이 겁니다. PDF와 HTML은 로더가 표와 머리글, 각주를 어떻게 읽는지 샘플 파일로 먼저 확인하고 깨진 본문은 제외하십시오.
페이지 단위는 검색에 너무 거칠 수 있어 문단과 제목 경계로 더 쪼개야 합니다. 일반 텍스트에는 RecursiveCharacterTextSplitter가 권장됩니다. 코드나 표는 구분자 규칙을 따로 두고 한 덩어리가 함수나 표 같은 의미 단위를 넘지 않게 자르십시오. 빈 페이지와 중복 본문은 임베딩 전에 걸러야 인덱스 용량을 낭비하지 않고 유사 문서끼리 순위가 갈리지 않으며 질의 지연과 중복 피해도 줄습니다.
청크 크기와 메타데이터 설계
청크는 보통 200~500 토큰에 이웃 오버랩을 두어 문장 중간이 잘려도 앞뒤 맥락이 남게 합니다. 질의는 수집과 같은 모델로 임베딩한 뒤 최근접 검색으로 5~20개 후보를 뽑습니다. 출처·제목·날짜·권한 메타데이터를 붙여야 필터와 인용에 쓰이고 권한 밖 문서는 검색에서 빠집니다.
오버랩이 없으면 문장 경계에서 맥락이 끊기고 답에 넣을 근거가 빠지며 인접 청크가 서로 연결되지 않습니다. 청크가 너무 길면 유사도가 희석되고 너무 짧으면 질문이 가리키는 조건을 담지 못해 오검색이 늘습니다. 권한 필드를 빼면 검색이 열려서 비공개 문장이 생성에 섞일 수 있으니 색인 전에 접근 범위를 넣으십시오. 날짜를 남기면 최신 규정만 골라 쓰는 질의에도 맞춰 필터하기 쉽고 철회된 문서를 날짜 필터로 빼기도 좋습니다.
생성 품질을 올리는 청크·프롬프트·재순위화
초기 검색 후 크로스 인코더 재순위화로 후보를 재정렬하면 질문과 본문을 같이 보고 정밀도가 오릅니다. 보통 상위 소수만 남기며 예로 top 20을 재순위화해 5개를 유지하는 식이 흔합니다. 고급 RAG에서는 최종보다 많은 문서를 검색한 뒤 더 강한 모델로 재순위화하고 top_k만 프롬프트 컨텍스트로 넣어 토큰을 아낍니다.
프롬프트에는 출처를 남기고 컨텍스트에 없는 내용을 단정하지 말라고 적으십시오. 재순위화 점수가 낮은 조각은 컨텍스트에 넣지 않는 편이 생성 안정에 유리하고 토큰도 줄어듭니다. 청크가 짧으면 문맥이 빠지고 길면 노이즈가 섞이므로 재순위화 전후에 길이를 같이 보십시오. 동일 출처 중복은 한 개만 남겨 답변 창에 같은 문단이 반복되지 않게 하고 근거 목록도 짧게 읽히고 중복 인용이 줄어듭니다.
RAG 파이프라인 구축 체크리스트와 마무리
배포 전에 임베딩 일치 여부, 청크 200~500 토큰과 오버랩, 메타데이터, 검색 후보 수, 재순위화 후 유지 개수를 확인하십시오. 프롬프트에 근거 제한과 인용 형식을 넣었는지도 같이 보십니다. 로더가 빈 페이지를 넣지 않는지와 삭제 문서가 인덱스에서 빠지는지도 점검하고 재색인 주기와 실패 알림 채널을 정해 두십시오.
| 구분 | 단계 | 실무 기준 |
|---|---|---|
| 인덱싱 | 로더, 청크, 임베딩, 벡터 저장 | 질의와 같은 임베딩 설정 |
| 질의 | 전처리, 검색, 재순위화, 생성 | 후보 5~20개 후 상위만 유지 |
| 품질 | 청크 200~500 토큰, 오버랩, 메타데이터 | 크로스 인코더로 top 20을 5개로 |
RAG 파이프라인 구축은 인덱싱과 질의를 같은 설정으로 묶고 청크와 재순위화로 컨텍스트를 골라 생성에 넘기는 일입니다. 수집부터 생성까지 한 번씩 점검하면 실무에서 검색 정밀도와 답변 근거를 같이 유지하기 쉽고 장애 구간을 빨리 찾아 바로 고칩니다. 모델만 바꾸지 말고 검색 경로와 프롬프트 제한을 함께 조정하고 실패 질의와 검색 점수를 운영 로그로 남겨 다음 배포 개선에 쓰십시오.
