제3장 — 검색 증강 생성

LLM Primer V: 실전 LLM 애플리케이션 구축을 챕터별로 따라가는 워크스루의 세 번째 글입니다. RAG 파이프라인을 끝에서 끝까지 걷고, 여러분의 즐겨찾기 열 개 문서에서만 잘 돌아가는 데모와 실제 코퍼스와 접촉하고도 살아남는 시스템 사이를 가르는 장입니다.

이 장이 존재하는 이유

파운데이션 모델은 자신의 훈련 코퍼스가 보여 준 것만 알고, 그 밖은 알지 못합니다. 여러분이 만드는 제품은 거의 확실히 모델이 그 코퍼스 바깥의 것 — 내부 문서, 지난주에 들어온 티켓, 고객의 주문 이력, 오늘 아침에 배포된 정책 — 에 대해 추론하기를 요구합니다. 검색 증강 생성은 그 격차를 닫는 엔지니어링 학문입니다. 질의 시점에 원장 시스템에서 관련 자료를 가져오고, 그것을 프롬프트로 다듬어 모델이 그 위에서 생성하게 하는 것입니다. 소박한 버전은 임베딩 호출 한 번과 top-k 조회 한 번입니다. 프로덕션 버전은 청킹 전략, 쿼리 변환, 하이브리드 스코어링, 리랭킹, 그리고 평가 루프를 지닌 파이프라인입니다. 제3장은 그 파이프라인을 끝에서 끝까지 걷고, 이어서 데모 파이프라인을 배포로 바꾸는 기법을 짚습니다.

3.1 다섯 단계 파이프라인과 하이브리드 검색

최소 RAG 파이프라인은 다섯 단계이고, 각 단계는 나중에 돌이켜 보면 뻔한 방식으로 서로 얽힙니다. 로더는 구조를 보존합니다 — 헤딩, 섹션 경로, 타임스탬프, 소스 URL, 접근 제어 레이블 — 이후 모든 것이 로더가 무엇을 남겼는지에 의존하기 때문입니다. 청커는 임의의 토큰 수가 아니라 문서의 자연스러운 결을 따라 자릅니다. 임베더는 청크를 벡터 공간에 투영하는데, 그 공간의 기하는 전적으로 임베딩 모델의 훈련 분포가 결정합니다. 리트리버는 최근접 이웃을 찾습니다. 생성기는 검색된 컨텍스트로 프롬프트되며, 어조가 중요합니다. 「아래 컨텍스트만 사용해 답하고, 그 밖의 경우는 “정보가 없습니다”라고 답하라」는 것이 프로덕션 RAG에서 환각을 줄이는 가장 효과적인 단일 패턴입니다. 순수 밀집 검색은 재구성된 표현을 이해하지만 정확한 식별자를 놓치고, 어휘 검색은 식별자를 잡지만 의미를 놓치며, Reciprocal Rank Fusion으로 융합된 하이브리드 검색은 두 효과를 모두 얻고, 융합된 top-50 위의 크로스인코더 리랭커는 정밀도를 추가로 10~20% 벌어 줍니다.

3.2 품질이 살고 죽는 곳, 청킹

「500 토큰마다 자르고 50 토큰씩 겹친다」는 기본값은 놀랍게도 상당한 비율의 일반 코퍼스에서는 통하고, 특수화된 코퍼스에서는 거의 대부분 실패합니다. 구조 기반 청커는 HTML 또는 Markdown을 헤딩 수준별로 걷고, 조상 헤딩의 브레드크럼을 접두로 붙여 리프 섹션마다 하나의 청크를 방출합니다. 부모-자식 청커는 검색 정밀도를 위해 작은 자식 청크를 임베드하지만, 히트가 나오면 생성기에 넘기기 전에 각 히트를 부모 문단으로 확장해, 검색 단위와 컨텍스트 단위를 분리합니다. 의미 기반 청커는 문장 임베딩의 시퀀스를 걷고, 주제가 바뀌는 곳에서 자릅니다. 조합해 — 구조 기반을 먼저, 그 아래 긴 섹션 안에서 의미 기반을 — 쓰면 이 두 패턴만으로도 실제 코퍼스가 담는 거의 모든 소스 유형을 감당할 수 있습니다. 그리고 모든 청크는 강화 메타데이터 — 소스, URL, 타임스탬프, 헤딩 경로, 언어, 가시성 범위 — 를 지니고 다니는데, 이 필드들이 검색된 청크를 귀속 가능하게 만들고, 필터 가능하게 만들며, 시스템의 나머지 부분이 그 청크를 읽을 수 있게 해 주기 때문입니다.

3.3 쿼리 변환, 멀티모달, text-to-SQL

사용자의 질의는 검색에 이상적인 질의인 경우가 드뭅니다. 멀티 쿼리 확장은 모델에 여러 가지 재구성된 표현을 요청해 각각을 검색하고 융합합니다. HyDE — Hypothetical Document Embeddings — 는 모델에 그럴싸한 답을 상상하게 하고 질문 대신 그 답을 임베드합니다. 답이 임베딩 공간에서 사는 지역이 질문이 사는 지역과 다르다는 이론에 근거한 방법입니다. 스텝백 프롬프팅은 질문의 더 일반적인 버전을 만들어 두 버전 모두에 대해 검색하고, 모델이 그 프레이밍을 사용해 구체적인 사례에 답하게 합니다. 분해는 복합 질문을 리트리버가 하나씩 다룰 수 있는 하위 질문들로 쪼갭니다. 반복 검색은 다음에 무엇을 가져올지 모델이 결정하게 합니다 — RAG와 에이전트를 잇는 다리입니다. RAG는 텍스트를 넘어 확장되기도 합니다. CLIP 스타일의 이미지-텍스트 공동 임베딩 공간은 멀티모달 검색을 지원하고, text-to-SQL은 데이터베이스 스키마를 검색 코퍼스로 다루며 타임아웃과 함께 읽기 전용 복제본에 질의를 생성합니다. 라우터는 모든 변환을 다 돌리는 대신, 질의별로 알맞은 변환을 고릅니다.

제3장이 준비하는 것

RAG는 여러 능력 중 하나입니다. 프로덕션 어시스턴트가 검색만으로 사는 경우는 드뭅니다. 고객의 최근 주문을 가져오고, 다른 시스템에서 재고를 확인하고, 결과를 요약하고, 명확화 질문을 하고, 언제 어느 것을 할지 스스로 결정해야 합니다. 그 동작에 어울리는 프레이밍이 에이전트적입니다 — 모델이 도구 집합에서 하나를 고르고, 시스템이 그 도구를 실행하고, 결과가 모델로 돌아오고, 과제가 끝날 때까지 루프가 이어집니다. 이 프레이밍에서 검색은 에이전트가 손을 뻗을 수 있는 하나의 도구입니다. 제4장은 그 래퍼를 에이전트로 바꿉니다: ReAct 루프, 계약으로서의 도구 스키마, 그리고 에이전트가 턴 사이의 상태를 붙들게 해 주는 세 층의 메모리.

다음 → 제4장: AI 에이전트와 도구 호출. 상태 없는 모델을 목표를 좇는 행위자로 바꾸는 루프 — 도구, 메모리, 그리고 폭주 행동에 대한 단단한 경계와 함께.