고객 지원을 위한 RAG: AI 응답을 실제로 정확하게 만드는 방법

검색이 없으면, LLM은 "비밀번호를 어떻게 재설정하나요?"라는 질문에 그럴듯하지만 아마도 틀린 답을 내놓습니다 — 다른 버튼, 다른 흐름, 다른 URL. RAG(검색 증강 생성)는 모델이 말하기 전에 당신의 문서에서 올바른 청크를 프롬프트에 주입함으로써 이를 해결합니다.

파이프라인 한눈에 보기

세 단계: 수집, 검색, 생성.

1. 수집

• 지식 UI를 통해 PDF, Markdown, Office 파일 업로드
• Worker가 텍스트를 추출하고, 약 800 token으로 100 token 겹침을 두어 청크화
• 각 청크는 text-embedding-3-small(1536차원)로 임베딩
• pgvector 확장을 갖춘 Postgres에 저장

2. 검색

방문자가 메시지를 보내면, 쿼리를 임베딩하고 해당 테넌트의 청크에 대해 코사인 거리 검색을 실행합니다. Top-K(기본값 5)가 가져와지고, 유사도 임계값으로 관련 없는 매치를 제거합니다.

SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM knowledge_chunks
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 5;

3. 생성

검색된 청크는 명시적 지침과 함께 시스템 프롬프트 앞에 추가됩니다: 출처를 인용하고, 맥락이 질문을 다루지 않으면 답변을 거부하고, 확신도가 낮으면 사람에게 인계합니다.

토큰 청구서 줄이기

대규모 지식 베이스에서 실제로 비용을 아끼는 세 가지 요령:

• 임베딩 캐시 — 같은 쿼리 텍스트 → 같은 임베딩. SHA1 해시 키, Redis에서 24시간 TTL. 반복되는 질문에 대한 재임베딩 비용을 0으로 만듭니다.
• 프롬프트 캐싱 — Anthropic의 cache_control와 OpenAI의 자동 캐싱 덕분에 정적 시스템 프롬프트는 5분 창마다 한 번만 계산됩니다.
• 임계값 기반 건너뛰기— 유사도 임계값을 통과하는 청크가 없으면 아무것도 주입하지 않습니다. 모델이 "모르겠습니다."라고 말하게 합니다.

RAG로 충분하지 않을 때

RAG는 "X를 어떻게 하나요?" 유형의 질문을 잘 처리합니다. 개인화된 데이터 ("제 주문은 어디에 있나요?")에서는 실패합니다 — 그것은 함수 호출이 필요하며, 별도의 글에서 다룹니다. 이 조합이 바로 적은 비용으로 Intercom 수준의 AI를 제공하는 것입니다.