일반 AI 비서에게 회사의 환불 정책에 대해 물어보면 추측만 할 뿐입니다. 귀하의 문서를 본 적이 없습니다. 검색 증강 생성(Retrieval-Augmented Generation)의 약자인 RAG는 올바른 정보를 찾아 질문과 함께 모델에 전달하여 이 문제를 해결합니다.

이 가이드에서는 각 단계를 일반 언어로 설명한 다음 Python의 표준 라이브러리만 사용하여 작은 버전을 빌드합니다. 우리는 Python 3.13에서 해당 코드를 실행했으며 표시된 점수는 해당 실행에서 나온 것입니다. 언어 모델을 사용하지 않으므로 검색 및 프롬프트 구축을 보여주며 최종 답변 단계를 테스트하지 않았습니다.

RAG란 무엇인가요?

검색 증강 생성은 검색 단계와 언어 모델을 결합하는 기술입니다. 질문이 도착하면 시스템은 지식 소스를 검색하고 프롬프트에 최상의 결과를 추가한 다음 해당 자료를 기반으로 모델에 답변하도록 요청합니다.

오픈북 시험을 생각해 보세요. 비공개 책을 읽는 학생은 기억에 의존하므로 자신있게 기억을 잘못할 수도 있습니다. 오픈북 학생은 먼저 올바른 페이지를 찾아볼 수 있습니다. RAG는 ​​모델에게 해당 책을 제공하고, 어떤 페이지를 사용했는지 알려줍니다.

RAG가 해결하는 문제

언어 모델 자체에는 비즈니스 용도로 세 가지 제한이 있습니다.

• 귀하의 개인 데이터를 알지 못합니다. 귀하의 정책, 티켓 및 계약은 교육의 일부가 아닙니다.
• 알림에는 컷오프가 있습니다. 오늘 아침에 변경한 가격에 대해서는 알 수 없습니다.
• 답을 만들어낼 수 있습니다. 확실하지 않을 때 그럴듯하면서도 거짓된 결과를 만들어낼 수 있습니다.

RAG는 ​​이 세 가지를 모두 다루므로 어떤 것도 재교육할 필요가 없습니다. 문서를 업데이트하고 다시 색인화하면 바로 다음 답변에서 사용할 수 있습니다.

RAG 작동 방식(단계별)

RAG 시스템에는 두 개의 파이프라인이 있습니다. 하나는 미리 데이터를 준비하고 다른 하나는 모든 질문에 대해 실행됩니다.

인덱싱: 데이터 준비

1. 로드: PDF, 위키, 데이터베이스 또는 티켓에서 콘텐츠를 수집합니다.
2. 정리 및 청크: 정크를 제거한 다음 문서를 작은 부분으로 나눕니다.
3. 임베드: 각 구절을 해당 의미를 포착하는 임베딩이라고 하는 숫자 목록으로 변환합니다.
4. 저장: 임베딩을 검색 가능한 인덱스(종종 벡터 데이터베이스)에 저장합니다.

질의: 질문에 대답하기

1. 검색: 질문을 삽입하고 의미가 가장 가까운 구절을 찾습니다.
2. 추가: 해당 구절을 프롬프트에 삽입하세요.
3. 생성: 모델은 해당 컨텍스트를 사용하여 답변을 작성합니다.

검색에는 벡터를 사용할 필요가 없습니다. 데이터에 대한 올바른 정보를 찾는 것은 키워드 검색일 수도 있고 심지어 SQL 쿼리일 수도 있습니다.

작은 작업 예

움직이는 부분을 명확하게 보기 위해 라이브러리가 없는 작은 리트리버를 보여드리겠습니다. 텍스트를 실제 임베딩에 대한 훨씬 간단한 대체 방법인 단어 수로 표현하고 코사인 측정값을 사용하여 유사성 점수를 매깁니다.

import math, re
from collections import Counter

DOCS = {
    "refunds": "Refunds are paid within 7 days to the original payment method.",
    "shipping": "Standard shipping takes 3 to 5 working days across India.",
    "warranty": "All keyboards include a 2 year warranty against defects.",
}

def vectorize(text):
    return Counter(re.findall(r"[a-z0-9]+", text.lower()))

def similarity(a, b):
    dot = sum(a[word] * b[word] for word in a)
    size = math.sqrt(sum(v * v for v in a.values()))
    size *= math.sqrt(sum(v * v for v in b.values()))
    return dot / size if size else 0

def retrieve(question, k=1):
    q = vectorize(question)
    scored = [(similarity(q, vectorize(t)), name) for name, t in DOCS.items()]
    return sorted(scored, reverse=True)[:k]

def build_prompt(question):
    (score, name), = retrieve(question)
    return (
        "Answer using only the context. If it is not there, say you do not know.\n"
        f"Context: {DOCS[name]}\n"
        f"Question: {question}"
    )

환불에 대해 질문하면 올바른 구절을 찾고 다음 프롬프트가 생성됩니다.

print(retrieve("How many days until refunds are paid?"))
# [(0.4558..., 'refunds')]

print(build_prompt("How many days until refunds are paid?"))
# Answer using only the context. If it is not there, say you do not know.
# Context: Refunds are paid within 7 days to the original payment method.
# Question: How many days until refunds are paid?

전체 시스템에서는 이제 해당 프롬프트를 언어 모델로 보냅니다. 중요한 세부 사항은 답변이 누락되었을 때 이를 인정하라는 지침입니다. 이에 대한 자세한 내용은 신속한 엔지니어링 가이드에서 확인할 수 있습니다.

우리의 예가 놓친 것

이제 동일한 의미이지만 다른 단어를 사용하는 질문을 시도해 보세요.

print(retrieve("When can I get my money back?", k=3))
# [(0.0, 'warranty'), (0.0, 'shipping'), (0.0, 'refunds')]

질문이 어떤 문서와도 단어를 공유하지 않기 때문에 모든 점수는 0입니다. “환불”은 인간에게 환불을 의미하지만 단어 수로는 알 수 없습니다. 이 단일 출력은 실제 시스템이 유사한 단어가 없더라도 유사한 의미를 가진 텍스트가 비슷한 숫자로 끝나도록 설계된 임베딩을 사용하는 이유를 설명합니다.

하지만 임베딩이 모든 것을 해결한다고 가정하지 마세요. 키워드 검색이 매우 잘 처리되는 제품 코드 및 오류 번호와 같은 정확한 용어로 인해 어려움을 겪을 수 있습니다. 이것이 바로 많은 생산 시스템이 두 가지 접근 방식을 결합하여 하이브리드 검색을 사용하는 이유입니다.

청킹: 사람들이 과소평가하는 단계

전체 파일이 너무 길고 검색하기가 부정확하기 때문에 문서가 여러 개의 청크로 분할됩니다. 선택한 크기에는 실제 절충안이 포함됩니다.

청크 사이에 약간 겹치는 수백 단어가 일반적인 시작점이지만 이를 테스트할 첫 번째 추측으로 간주합니다. 가능하면 제목과 같은 자연스러운 경계를 따라 분할하세요. 문서 제목, 날짜, 부서 등의 메타데이터를 첨부하면 결과를 필터링하고 출처를 인용할 수 있습니다.

검색 개선

답변이 좋지 않은 경우 시도해 볼 가치가 있는 업그레이드는 대략 다음과 같습니다.

• 데이터를 정리합니다. 오래되고 중복된 문서를 먼저 제거하세요. 어떤 알고리즘도 모순되는 소스를 수정하지 않습니다.
• 하이브리드 검색을 사용합니다. 의미 기반 검색결과와 키워드 검색결과를 결합합니다.
• 재순위 지정자를 추가합니다. 더 많은 후보자를 가져온 다음 특수 모델을 사용하여 관련성에 따라 재정렬합니다.
• 메타데이터로 필터링합니다. 검색하기 전에 제품, 지역 또는 날짜별로 결과를 제한합니다.
• 쿼리를 다시 작성하세요. “두 번째는 어떻습니까?”와 같은 모호한 후속 조치를 취하세요. 완전한 질문으로.

RAG 대 미세 조정

그것들은 상호 배타적이지 않습니다. RAG, 미세 조정 및 신속한 엔지니어링을 비교하여 더 깊이 있는 선택 방법을 다룹니다.

RAG 시스템을 테스트하는 방법

RAG는 소프트웨어이므로 다른 소프트웨어와 마찬가지로 테스트가 필요합니다. 예상되는 구절 및 답변과 함께 일련의 실제 질문을 만든 다음 두 단계를 개별적으로 측정하십시오.

데이터에 답이 없는 질문, 다른 표현을 사용하는 질문, 소스가 충돌하는 질문 등 어색한 경우도 포함하세요. 회귀 세트처럼 청크, 모델 또는 프롬프트를 변경할 때마다 이 세트를 다시 실행하십시오. 우리의 pytest 튜토리얼은 단일 테스트를 통해 많은 입력을 실행하는 방법을 보여줍니다.

RAG 시스템이 실패하는 이유

• 답은 데이터에 없습니다. 모델은 여전히 시도할 수 있으므로 거절하는 방법을 알려주세요.
• 올바른 청크가 검색되지 않았습니다. 이는 청크 또는 검색 문제인 경우가 많습니다.
• 맥락이 너무 많습니다. 관련 없는 구절은 모델의 주의를 산만하게 하고 비용을 증가시킬 수 있습니다.
• 낡은 문서. 오래된 정책도 현재 정책만큼 확실하게 검색할 수 있습니다.
• 테이블과 PDF가 잘못 구문 분석되었습니다. 추출로 인해 텍스트가 뒤섞이면 검색이 결코 복구되지 않습니다.
• 데모 질문만으로 테스트합니다. 실제 사용자는 내용을 매우 다르게 표현합니다.

보안 및 권한

RAG는 놓치기 쉬운 두 가지 위험을 가져옵니다. 첫째, 액세스 제어: 인덱스에 HR 파일이 포함된 경우 하급 직원의 질문으로 해당 파일을 검색하면 안 됩니다. 모델에 비밀을 유지하도록 지시하는 것은 신뢰할 수 있는 보호 장치가 아니기 때문에 검색 중에 각 사용자의 권한을 적용하십시오.

둘째, 즉시 주입. 검색된 웹페이지나 문서에는 “지침 무시”와 같은 텍스트가 포함될 수 있습니다. 검색된 콘텐츠를 신뢰할 수 없는 데이터로 취급하고, 모델이 수행할 수 있는 작업을 제한하고, 민감한 작업을 사람이 승인하도록 요구합니다.

마무리

RAG는 ​​실용적인 세부 사항이 많이 포함된 간단한 아이디어입니다. 올바른 정보를 찾은 다음 모델에 이를 사용하도록 요청합니다. 작고 깔끔한 문서 세트와 약 20개의 실제 질문으로 시작하세요. 복잡성을 추가하기 전에 검색이 제대로 작동하도록 하세요. 좋은 데이터가 포함된 적당한 파이프라인이 일반적으로 잘못된 데이터가 포함된 정교한 파이프라인보다 우수하기 때문입니다.

자주 묻는 질문

계속 학습하세요