이득:
- 엔드투엔드 엔터프라이즈 RAG 어시스턴트의 구성 요소 및 데이터 흐름 설계
- 다중 소스 데이터(위키, 티켓, PDF, 데이터베이스)를 단일 도우미로 결합
- 확장성, 캐싱 및 대기 시간에 대한 아키텍처 결정을 내립니다.
이전 단원에서는 임베딩, 벡터 데이터베이스, 청킹, 검색 부분을 하나씩 배웠습니다. 이제 이들을 결합하여 회사 데이터와 통신하는 어시스턴트의 엔드투엔드 아키텍처를 구축해 보겠습니다. 목표는 직원이 "우리의 휴가 정책은 무엇입니까?"라고 질문하도록 하는 것입니다. 사람들이 질문하고 답변은 실제 내부 문서와 인용을 기반으로 하며 여러 데이터 소스를 결합할 수 있는 시스템입니다. 이 단위는 전체 아키텍처, 데이터 흐름 및 생산 수준 결정을 처리합니다.
엔드투엔드 구성요소
기업 RAG 도우미는 두 개의 개별 회선으로 구성됩니다. 인덱싱 라인(오프라인)은 데이터를 준비합니다. 쿼리 라인(온라인)이 질문에 답합니다.
인덱싱 라인 구성요소:
- 커넥터: 위키, 티켓 시스템, 파일 저장소, 데이터베이스, 이메일 등 소스에서 데이터를 가져오는 커넥터입니다.
- 정규화: 다양한 형식(PDF, HTML, DOCX)을 깨끗한 텍스트로 변환합니다. 머리글/바닥글 청소.
- 청킹 + 메타데이터: 청킹 및 태그 지정(소스, 날짜, 권한).
- 임베딩 + 로딩: 벡터 데이터베이스에 벡터와 메타데이터를 작성합니다.
쿼리 파이프라인 구성요소:
- 쿼리 전처리: 재작성, 분산화.
- 검색: 하이브리드 검색 + 메타데이터 필터 + 순위 재지정.
- 프롬프트 생성: 컨텍스트 + 질문 + 지침을 템플릿에 배치합니다.
- 생성: 모델 + 소스의 근거 있는(문맥상) 답변입니다.
- 후처리: 인용 서식, 보안 확인, 로깅.
팁: 인덱싱 라인을 쿼리 라인과 물리적으로 분리하세요. 인덱싱은 느리고 주기적입니다(야간 일괄 실행). 문의 방법은 가볍고 즉각적이어야 합니다. 두 줄을 혼합하면 사용자가 기다리는 동안 처리량이 많아집니다.
데이터 흐름 시각화
[INDEXING - 오프라인]리소스 → 정규화 → 청크+메타데이터 → Embed → 벡터 DB(wiki, ticket, PDF, DB)[QUERY - 온라인]사용자 질문 → 전처리 → 검색(하이브리드+필터+순위 변경) → 프롬프트(컨텍스트+질문+지시) → 모델 → 답변+소스 → 사용자
다중 소스 데이터 결합
실제 회사에서는 답이 한 곳에 머물지 않습니다. “고객에게 환불을 어떻게 처리하나요?” 질문에 대한 답변은 도움말 문서(절차), 티켓 기록(실제 예) 및 정책 PDF(규칙)에서 모두 찾을 수 있습니다. 어시스턴트는 하나의 풀에서 모두 검색해야 합니다.
중요한 점: 리소스를 단일 벡터 저장소로 결합할 때 각 샤드는 `source_tour` 메타데이터를 전달해야 합니다. 그래서 모두 검색하고 "공식 정책만 가져오세요"와 같이 필요하다면 필터링할 수 있습니다. 또한 공식 정책 > 도움말 문서 > 직원의 티켓 메모 등 소스마다 신뢰성 수준이 다릅니다. 순위 재지정 또는 프롬프트에서 이 우선순위를 지정할 수 있습니다.
소스
콘텐츠 유형
신뢰
업데이트 빈도
정책 PDF
공식적인 규칙
높다
매달
도움말 문서
절차
중간 높이
매주
티켓 내역
실제 샘플
중간
연속
위키
혼합/현재 음표
변수
연속
확장성, 캐시 및 지연 시간
제작 과정에서 세 가지 문제가 두드러집니다. 지연 시간: 사용자가 2초 이상 기다리면 경험이 저하됩니다. 해결 방법: 답변을 스트리밍 형식으로 표시합니다. 모델이 글을 쓰는 동안 답변이 화면에 쏟아집니다. 캐시: 자주 묻는 질문과 반복적인 컨텍스트의 경우 캐시를 사용하면 속도가 향상되고 비용이 절감됩니다. Scale: 사용자가 증가함에 따라 검색 및 모델 호출을 수평적으로 확장할 수 있어야 합니다.
비용 측면의 경험 법칙: 가장 비용이 많이 드는 단계는 일반적으로 더 큰 모델로 이동하는 토큰 수입니다. 따라서 순위를 다시 지정하여 컨텍스트를 4개의 양호한 부품으로 줄이면 품질과 비용이 모두 향상됩니다. 일반적인 설계는 간단한 분류 또는 라우팅을 위해 더 작고 빠른 모델을 사용하고 최종 답변을 위해 더 강력한 모델을 사용하는 것입니다(예: clude-opus-4-8).
주의: "한 번만 수행하고 잊어버리세요"로 인덱싱을 설정하지 마세요. 문서가 변경, 삭제, 추가됩니다. 재인덱싱 전략 수립: 변경된 문서를 감지하고 해당 문서만 재처리합니다. 오래된 색인은 현재인 것처럼 보이지만 잘못된 답변을 생성합니다.
약한 아키텍처 / 강한 아키텍처
약함(단일 스크립트, 모든 것이 혼합됨):
사용자가 묻는 경우: 그 순간 문서를 읽고, 파쇄하고, 삽입하고, 검색하고, 답변합니다.# 문제: 각 질문에 대해 모든 색인화가 반복됩니다. 초 지연, # 소스 분리 없음, 필터 없음, 새로 고침 없음.
강력함(분할 파이프 + 메타데이터 + 캐시 + 스트리밍):
인덱싱: 야간에 일괄 실행되어 변경된 문서를 새로 고칩니다. 쿼리: 경량 라인 — 전처리 → 하이브리드 검색+필터 → 순위 변경 → 프롬프트 → 모델(스트리밍) → 인용 → 로그. 자주 묻는 질문과 출처가 캐시되어 있습니다.
미니 케이스 3개
사례 1 — 회선 혼란, 심한 지연. 한 스타트업에서는 각 질문에 대해 PDF를 재처리하는 스크립트를 작성했습니다. 각 답변에는 평균 11초가 걸렸습니다. 인덱싱 라인을 분리하고 데이터를 이전에 벡터 저장소로 전송했을 때 쿼리 시간은 1.3초로 단축되었으며 스트리밍을 사용하면 "첫 번째 단어"가 400ms에 나타났습니다.
사례 2 — 리소스가 너무 많아 우선순위가 잘못되었습니다. 지원 보조원은 정책 PDF와 이전 티켓 메모에 동일한 비중을 두었습니다. 이 모델은 때때로 2년 전 직원의 잘못된 평가를 공식 규칙으로 제시했습니다. source_tour 메타데이터와 "충돌 시 공식 정책 고려" 지침이 프롬프트에 추가되었을 때 잘못된 우선순위 오류가 89% 감소했습니다.
사례 3 - 오래된 인덱스. HR 보조원이 3개월 동안 업데이트되지 않은 지수로 작업하고 있었습니다. 휴가 정책이 바뀌었는데 보조원이 옛날 얘기를 하더라구요. 변경된 파일을 감지하는 데일리 리프레시(Daily Refresh)를 설치하자 현재 응답률이 70%에서 99%로 높아졌다.
일반적인 실수
- 인덱싱 및 쿼리 줄 혼합: 사용자가 기다리는 동안 과도한 처리가 수행됩니다. 지연이 폭발합니다.
- 메타데이터에 소스 유형을 넣지 않음: 우선순위 지정 및 필터링이 없습니다. 신뢰할 수 없는 출처는 공식적인 것으로 보입니다.
- 새로 고침 전략을 설정하지 않음: 인덱스가 오래되었습니다. 현재 나타나는 잘못된 답변이 생성됩니다.
- 스트리밍 건너뛰기: 사용자가 빈 화면을 봅니다. 인지된 지연이 높아집니다.
- 각 단계에서 가장 큰 모델 사용: 비용이 불필요하게 증가합니다. 스티어링은 더 작은 모델에 맡기세요.
요약하면
- 기업 RAG 도우미는 오프라인 인덱싱과 온라인 쿼리라는 두 개의 개별 라인으로 구성됩니다. 물리적으로 분리하세요.
- 인덱싱 = 커넥터 + 정규화 + 청크/메타데이터 + 삽입/업로드; 쿼리 = 전처리 + 검색 + 프롬프트 + 생성 + 후처리.
- 다중 소스 데이터는 단일 저장소로 결합되지만 source_type 메타데이터와 신뢰 우선순위는 유지됩니다.
- 대기 시간을 위한 스트리밍 및 캐시, 비용을 위한 컨텍스트 조절 및 모델 선택이 중요합니다.
- 다시 색인을 생성하지 않으면 색인이 오래됩니다. 변경된 문서를 정기적으로 재처리합니다.
응용과제
자신의 팀을 위한 어시스턴트의 아키텍처 다이어그램을 그립니다. (1) 실제 데이터 소스를 3개 이상 식별하고 각각에 대한 커넥터 요구 사항, 업데이트 빈도 및 신뢰 수준을 기록합니다. (2) 상자 화살표 다이어그램을 사용하여 인덱싱 라인과 쿼리 라인을 별도로 그립니다. (3) “이 어시스턴트의 지연 시간과 비용을 어디에서 줄일 수 있나요?” 질문에 대해 최소한 두 가지 구체적인 결정을 작성하십시오. (4) 새로 고침 전략을 한 문장으로 설명하십시오. 어떤 리소스가 재색인되며 얼마나 자주 수행됩니까?
체크리스트
- [ ] 인덱싱 라인과 쿼리 라인을 올바른 구성 요소를 사용하여 개별적으로 그릴 수 있습니다.
- [ ] 다중 소스 데이터를 source_type 및 신뢰 우선순위와 결합할 수 있습니다.
- [ ] 지연 시간에 대한 스트리밍/캐시 결정을 내리고 비용에 대한 모델 선택을 내릴 수 있습니다.
- [ ] 재인덱싱 전략이 왜 필수적인지 알고 있습니다.
- [ ] 내 아키텍처에서 가장 비용이 많이 드는 단계는 일반적으로 더 큰 모델로 이동하는 토큰이라는 점을 명심합니다.