이커머스 챗봇을 위한 RAG 수집 파이프라인 구축 과정

고객 챗봇은 언어 모델만으로는 충분하지 않습니다. 적절한 스토어 정보, 그 정보를 업데이트하는 방법, 그리고 가장 기본적인 질문에 대한 신뢰할 수 있는 답변—즉, 새로운 콘텐츠가 실제로 검색 준비가 되었는지 여부—이 필요합니다.

저는 ProxyAI의 창립자이자 개발자인 Jimmy입니다. Retrieval-Augmented Generation (RAG) 파이프라인을 구축하는 과정에서, 저는 문서 수집(document ingestion)을 조정하는 것이 검색 자체만큼 많은 주의를 기울여야 할 부분임을 알게 되었습니다.

제가 시스템의 이 부분을 어떻게 구조화했는지 설명해 드리겠습니다.

명확한 경계부터 시작하기

RAG는 관련 정보를 검색하여 답변의 컨텍스트로 제공합니다. 이커머스의 경우, 여기에는 배송 정책, 반품 지침 및 기타 스토어 콘텐츠가 포함될 수 있습니다.

저는 이러한 지식을 변경 가능한 문서 컬렉션으로 취급합니다. 판매자가 정책을 수정할 때, 여러 개의 상충되는 버전이 검색에 사용 가능하도록 두기보다는 기존 문서를 대체해야 합니다.

본 글은 바로 그 수집 계층(ingestion layer)에 초점을 맞춥니다. 실시간 재고, 고객별 주문 및 권한 관리는 별개의 문제입니다. 문서 인덱스는 빠르게 변경되거나 사적인 거래 데이터의 권위로 취급되어서는 안 됩니다.

한 번 업로드하고 작업을 위임하기

수집 흐름은 다음과 같습니다:

Document upload to R2
        |
Manifest creation event
...

문서는 오브젝트 스토리지로 전송됩니다. 매니페스트(manifest)는 업로드가 백그라운드 처리가 준비되었음을 표시하는 지점입니다. 이 매니페스트의 생성은 큐 컨슈머(queue consumer)를 트리거합니다.

이러한 위임 과정이 중요합니다. 매니페스트가 작성되면, 큐가 작업을 소유하게 됩니다. 판매자는 인덱싱이 완료될 때까지 업로드 페이지를 열어둘 필요가 없습니다.

워커(worker)는 애플리케이션 백엔드를 통해 작업을 가져옵니다. 이 백엔드의 작업 기록은 권위 있는 문서 식별자 및 업로드 세부 정보를 제공합니다. 브라우저에서 작성된 매니페스트는 트리거일 뿐, 임의의 콘텐츠나 목적지를 선택할 수 있는 권한을 의미하지 않습니다.

문서에 안정적인 식별자를 부여하기

ProxyAI에서는 문서 이름이 단순한 표시 파일명이 아니라 식별자(identity)입니다. 수정된 문서는 동일한 식별자를 사용할 수 있으며, 동기화된 WordPress 페이지는 고유 URL(permalink)을 사용할 수 있습니다.

교체본을 업로드하기 전에 소비자(consumer)가 저장된 버전을 삭제합니다. 이렇게 하면 일반적인 콘텐츠 업데이트가 구식 복사본이 쌓이는 것을 방지할 수 있습니다.

여기에는 트레이드오프가 있습니다. 삭제 후 업로드는 원자적 스왑(atomic swap)이 아닙니다. 만약 업로드에 실패하면, 교체 작업은 재시도되어야 합니다. 안정적인 식별자는 이러한 재시도를 이해하기 쉽게 만들지만, 모든 실패 모드를 제거하지는 못합니다.

검색 서비스가 청킹을 담당하게 하라

저는 문서를 통째로 Cloudflare AI Search에 업로드하고, 청킹(chunking)과 임베딩(embedding) 처리를 맡깁니다. 이렇게 하면 제 애플리케이션이 조정해야 하는 중간 객체와 큐 메시지 수를 줄일 수 있습니다.

AI Search는 또한 시맨틱 매칭(semantic matching)과 키워드 매칭(keyword matching)을 결합하는 하이브리드 검색(hybrid retrieval)도 지원합니다. 이는 질문에 자연어와 정확한 제품 용어가 혼합되어 있을 때 유용합니다. 현재 기능은 Cloudflare의 AI Search 문서를 참조하십시오.

트레이드오프는 청킹이 검색 서비스 구성의 일부가 된다는 것입니다. 이 구성을 변경하면 원본 텍스트가 동일하더라도 검색 결과가 바뀔 수 있습니다.

업로드와 대기 과정을 분리하라

큐 워커(queue worker)가 문서를 업로드한 다음, IngestJob Durable Object에 추적을 넘깁니다. 인덱싱을 기다리며 오랜 루프 속에 머무르지 않습니다.

이 객체는 작업의 상태를 저장하고 알람(alarms)을 사용하여 진행 상황을 확인합니다. 작업이 계속되는 동안 작업 임대 기간(job lease)을 갱신하고, 완료 또는 실패를 백엔드에 보고합니다.

이는 여전히 인덱싱 서비스에 폴링(polling)하는 방식입니다. 개선점은 대기하는 장소와 그 상태가 중단에도 살아남는 방법입니다.

재연결에는 스냅샷이 필요하다

대시보드는 WebSocket을 통해 진행 상황을 받습니다. 하지만 일련의 이벤트들이 작업에 대한 완전한 기록은 아닙니다.

판매자는 인덱싱 도중에 탭을 닫았다가 나중에 돌아올 수 있습니다. 연결되거나 재연결될 때 대시보드는 단순히 미래의 알림뿐만 아니라 현재 상태를 필요로 합니다.

또한 소켓 연결이 불가능한 환경을 위해 폴링(polling)도 유지합니다. 진행 상황 연결이 끊어졌다고 해서 자동적으로 데이터 수집(ingestion)에 실패했다고 간주해서는 안 됩니다.

완료 처리를 재시도해도 안전하게 만들기

백그라운드 작업은 성공적으로 완료되었지만, 그 성공을 인정하는 요청이 실패할 수 있습니다. 따라서 완료 호출(completion call)을 재시도하더라도 고객에게 다시 요금을 부과해서는 안 됩니다.

결제 처리 경로(settlement path)는 그러므로 **멱등성(idempotent)**을 갖추어야 합니다. 중복된 완료 호출은 또 다른 청구 이벤트를 생성하기보다는 동일한 완료된 작업과 청구를 보존해야 합니다.

개발 환경과 운영 환경 모두 별도의 스토리지와 큐가 필요합니다. 그렇지 않으면 업로드가 해당 작업이 존재하지 않는 데이터베이스에 연결된 컨슈머를 트리거할 수 있습니다.

다른 RAG 프로젝트에 가져갈 것들

안정적인 문서 식별자(stable document identities)를 사용하세요. 브라우저에서 백그라운드 처리로의 인계 과정을 명시적으로 만드세요. 작업 상태는 브라우저 외부에 유지하세요. 알림은 권위 있는 상태(authoritative state)라기보다는 편의 기능으로 취급하세요. 재시도와 결제 처리를 함께 설계하세요.

이러한 선택들은 업로드, 인덱싱, 네트워크 연결, 그리고 청구까지 모두 동시에 성공하지 못할 때 파이프라인을 이해하기 쉽게 만듭니다.

저는 ProxyAI에서 이것을 구축하고 있습니다. ProxyAI는 구독료가 없고 사용한 만큼만 비용을 지불하는 AI 고객 채팅 플랫폼입니다.

혹시 비슷한 파이프라인을 구축해 보셨다면, 재인덱싱(reindexing) 중에 오래된 콘텐츠를 남겨두지 않으면서 문서를 교체하는 방법은 어떻게 처리하시나요?