단위 1 / 11

RAG란 무엇이며 왜 필요한가요?

이득:

  • RAG가 모델의 가중치를 변경하지 않고 컨텍스트를 주입하고 '오픈북 시험' 로직으로 작동함을 설명
  • 비용, 적시성 및 사용 시나리오에 따라 RAG를 미세 조정 및 장기 컨텍스트 접근 방식과 비교
  • 인덱싱 및 쿼리 단계로 구성된 일반적인 RAG 파이프라인의 단계 나열

언어 모델(텍스트를 이해하고 생성하는 인공지능, 이하 줄여서 모델이라고 부르겠습니다)이 아무리 강력해도 회사가 어제 서명한 계약서, 내부 위키(내부 지식 베이스) 페이지, 오늘 아침에 게시된 릴리스 노트를 알 수 없습니다. 모델은 훈련된 날짜까지의 일반 지식으로 제한됩니다. 이를 "교육 마감일"이라고 합니다. RAG(Retrieval-Augmented Generation)는 이러한 격차를 정확하게 메웁니다. 질문과 관련된 회사 문서를 찾아 모델에 컨텍스트(즉, 답변을 생성하는 동안 읽을 추가 텍스트)로 제공하고 이 컨텍스트를 기반으로 답변을 생성합니다.

이 단원에서는 RAG가 무엇인지, 언제 어떤 대안보다 선호되는지, 그리고 일반적인 RAG 파이프라인의 단계를 명확하게 살펴보겠습니다. 모든 후속 유닛은 이 지도의 부분을 하나씩 심화시킵니다.

RAG의 기본 아이디어: 오픈북 시험

RAG를 한 문장으로 설명하겠습니다. "먼저 관련 문서를 찾은 다음 모델이 해당 문서를 읽고 그에 따라 답변을 인쇄하도록 합니다."

가장 유용한 비유는 다음과 같습니다. RAG는 모델을 "비공개 도서 시험"에서 "공개 도서 시험"으로 이동합니다. 비공개 북 시험에서는 학생이 암기해서만 답합니다. 기억하지 못하는 것을 만들어 낼 위험이 높습니다. 오픈북 시험에서는 학생이 자신 앞에 놓인 소스를 보고 답합니다. RAG에서 모델은 더 이상 자체 메모리에서 응답하지 않고 사용자가 제공하는 현재 및 특정 텍스트에서 응답합니다.

중요한 점: RAG는 모델의 가중치, 즉 모델이 학습한 수십억 개의 수치 매개변수를 변경하지 않습니다. 모델을 재교육하지 않습니다. 각 질문에 대해 해당 질문과 관련된 텍스트 덩어리를 프롬프트(모델에 전송되는 지침 텍스트)에 삽입합니다. 따라서 문서가 업데이트될 때 모델을 다시 학습할 필요가 없습니다. 검색 데이터베이스에서 관련 기록을 새로 고치기만 하면 됩니다.

힌트: 두 가지 질문이 RAG의 품질을 결정합니다. (1) 올바른 문서를 찾았습니까? (2) 모델이 올바르게 읽었나요? 첫 번째는 "검색 품질"이고 두 번째는 "생성 품질"입니다. 이 두 가지는 별도로 측정되고 개선됩니다.

RAG, 미세 조정 또는 긴 컨텍스트?

조직 문제에 대한 해결책을 찾을 때 세 가지 경로가 혼동되는 경우가 많습니다. 차이점을 명확히합시다. 미세 조정은 데이터로 모델의 가중치를 업데이트하고 새로운 동작/스타일을 가르치는 것입니다. 긴 컨텍스트는 선택하지 않고 모든 문서를 프롬프트에 직접 입력하는 것을 의미합니다.

접근

무엇을

언제가 적절한가요?

비용/위험

걸레

관련 문서를 컨텍스트로 삽입합니다.

자주 변경되고 광범위하며 구체적인 정보

낮음; 업데이트가 용이하며 출처 인용 가능

미세 조정

새로운 데이터로 가중치를 업데이트합니다.

고정된 스타일/형식/언어 교육

높음; 업데이트할 때마다 재교육 필요

긴 컨텍스트만

모든 문서를 프롬프트에 입력합니다.

작고 고정된 문서 세트

토큰 비용 및 "중간 부분 상실" 위험 증가

일반적으로 미세 조정은 모델에게 말하는 방법을 가르칩니다. RAG는 ​​모델에게 알아야 할 사항을 알려줍니다. 대부분의 기업 시나리오에서는 저렴하고 업데이트가 가능하며 답변의 소스를 표시할 수 있는 RAG가 먼저 시도됩니다. 문서 세트가 매우 작고 고정된 경우(예: 20페이지짜리 단일 매뉴얼) 긴 컨텍스트가 합리적입니다. 그러나 수천 페이지를 사용하면 비용이 많이 들고 모델이 긴 텍스트 중간에 정보를 놓칠 수 있습니다.

일반적인 RAG 파이프라인

RAG는 인덱싱(준비, 한 번 또는 주기적으로 수행)과 쿼리(모든 사용자 질문에 대해 실행)의 두 가지 주요 단계로 구성됩니다.

단계별 색인 생성(오프라인, 사용자 대기 없음):

  1. 수집: 소스(PDF, Wiki, 티켓 시스템, 데이터베이스, 이메일)에서 문서를 가져옵니다.
  2. 청킹: 긴 텍스트를 관리하기 쉬운 작은 조각으로 나눕니다.
  3. Embed: 각 부분을 Embedding(텍스트의 의미를 전달하는 숫자 벡터)으로 변환합니다.
  4. 저장: 텍스트 및 메타데이터(소스, 날짜, 인증 정보)와 함께 벡터를 벡터 데이터베이스에 씁니다.

단계별 쿼리(온라인, 사용자가 기다리는 동안):

  1. 사용자의 질문을 임베딩으로 변환합니다.
  2. 벡터 데이터베이스에서 가장 유사한 부품을 검색합니다.
  3. 이러한 조각과 질문을 프롬프트 템플릿에 배치하세요.
  4. 모델에서 상황별 답변과 해당 소스를 가져옵니다.

# 문의 단계의 개념적 개요(언어에 의존하지 않음)question = "연차 휴가는 며칠입니까?"question_vektor = embed(question)parts = vektor_db.search(question_vektor, top_k=4) # 가장 유사한 partsprompt = f"""아래 CONTEXT를 사용하여 질문에 대답하십시오. 대답이 문맥에 맞지 않으면 "I have no information about this."라고 말하십시오. Fitting.CONTEXT:{parts}QUESTION: {question}"""answer = model.uret(prompt) # 예: 모델: 클로드-오푸스-4-8

이 흐름은 각 단계의 맵으로, 이후 유닛에서 하나씩 풀어보겠습니다.

약한 프롬프트 / 강한 프롬프트

동일한 RAG 컨텍스트를 사용하더라도 프롬프트의 품질에 따라 답변이 달라집니다.

약한 프롬프트(모델 피팅에 개방형, 리소스가 필요하지 않음):

이 정보를 사용하여 연차 휴가를 말하세요: {parts}. 질문: {질문}

강력한 프롬프트(접근 + "모름" 권한 + 리소스 요청):

아래의 CONTEXT를 토대로만 답변하세요. 문맥상 명확한 대답이 없으면 "문서에서 이에 대한 정보를 찾을 수 없습니다"라고 적습니다. 추측하지 마십시오. 답변 끝에 의존하고 있는 작품의 [출처: 파일 이름] 태그를 추가하세요. 맥락: {조각} 질문: {질문}

미니 케이스 3개

사례 1 - HR 보조원(인적 자원부). 한 회사에 340페이지 분량의 HR 핸드북이 있고 직원들은 하루 평균 90개의 질문을 합니다. 미세 조정도 시도했지만 매뉴얼이 매달 업데이트돼 매번 재교육이 필요했다. 비용은 한 달에 수천 달러에 이르렀습니다. RAG로 전환한 후 업데이트가 '문서 재인덱싱' 단계(분)로 줄어들었고, 수동 측정 시 정답률이 71%에서 93%로 높아졌다.

사례 2 - 고객 지원. 지원팀에는 12,000개의 해결 티켓과 800개의 도움말 문서가 있습니다. 담당자가 수동으로 답변을 찾는 데 평균 4분이 소요됩니다. RAG 보조원이 가장 관련성이 높은 5개의 기록을 가져와 응답 초안을 작성했을 때 시간은 40초로 단축되었습니다. 그러나 팀은 "잘못된 기사를 가져와 확신이 없는 것처럼 보이는 것"의 위험성을 인식하고 출처 인용을 의무화했습니다.

사례 3 - 법률. 계약팀은 “어떤 계약에 비밀유지 조항이 5년 동안 유지되나요?”라고 물었다. 그는 질문을 합니다. 긴 맥락 시험에서는 60개의 계약이 단일 프롬프트에 채워졌습니다. 모델은 중간 두 계약을 건너뛰었습니다. RAG로 관련 항목만 도입했을 때 토큰 비용이 80% 감소하고 누락된 건너뛰기가 재설정되었습니다.

왜 RAG가 필요한가요?

  • 최신성: 교육 마감일 이후에 정보에 액세스할 수 있습니다.
  • 특별 정보: 귀하의 내부 문서는 어떤 모델의 교육에도 포함되지 않습니다. 오직 당신만이 줄 수 있습니다.
  • 검증 가능성: 답변의 출처(인용)를 인용할 수 있습니다. 이는 감사와 신뢰에 필수적입니다.
  • 환각 제어: 모델을 구성하기보다는 앞에 배치된 텍스트에 의존합니다.
  • 비용: 미세 조정보다 작동하는 것이 훨씬 저렴하고 빠릅니다.
주의: RAG는 마법이 아닙니다. 잘못된 부분을 가져오면 모델은 "자신감"이 있는 것처럼 보이는 잘못된 답변에 도달합니다. "검색 품질 = RAG 품질"이라는 문구를 명심하세요.

일반적인 실수

  • RAG를 미세 조정으로 착각함: RAG는 가중치를 변경하지 않습니다. 단지 맥락을 추가할 뿐입니다. 이 두 가지를 혼동하면 잘못된 아키텍처를 선택하게 됩니다.
  • "모르겠어요"를 허용하지 않음: 프롬프트에서 모델이 빈칸을 채울 수 있도록 남겨두면 보충됩니다.
  • 출처를 인용하지 않은 경우: 출처가 없는 답변은 확인할 수 없습니다. 사용자는 실수를 알아차릴 수 없습니다.
  • 모든 것을 하나의 프롬프트에 담기: 긴 컨텍스트는 저렴해 보이지만 비용이 많이 들고 중간 정보를 놓칩니다.
  • 검색을 측정하지 않고 생성에 갇히기: 대답이 나쁘면 먼저 "올바른 부분이 도착했나요?"라고 물어보세요. 물어봐야합니다.

요약하면

  • RAG는 질문과 관련된 문서를 모델에 컨텍스트로 삽입하는 접근 방식입니다. 가중치는 변경되지 않습니다("오픈북 시험").
  • 미세 조정은 스타일/형식을 가르치고 RAG는 현재 및 특정 정보를 제공합니다. 긴 컨텍스트는 작은 고정 세트에 적합합니다. 대부분의 시나리오에서는 RAG가 먼저 시도됩니다.
  • 파이프라인에는 오프라인 인덱싱(청크 + 임베딩 + 저장)과 온라인 쿼리(검색 + 프롬프트 + 생성)의 두 단계가 있습니다.
  • RAG는 ​​적시성, 구체적인 정보, 검증 가능성, 환각 제어 및 저렴한 비용을 제공합니다.
  • 시스템의 품질은 검색 품질에 직접적으로 좌우됩니다. 잘못된 부분은 잘못된 답변을 의미합니다.

응용과제

자신의 팀에서 실제 정보 소스를 선택하세요(예: 절차 문서 또는 FAQ 페이지). (1) 이 출처에 관한 사실에 관한 질문 5개를 작성하세요. (2) 문서의 어느 부분에 각 질문에 대한 정답이 포함되어 있는지 확인하십시오. 이것이 "황금 답변" 목록이 됩니다. (3) 위의 "강력한 프롬프트" 템플릿을 사용하여 관련 섹션을 컨텍스트로 수동으로 붙여넣고 모델에게 질문합니다. (4) 모델이 제시한 답을 황금답과 비교하여 참/거짓으로 표시합니다. 이는 향후 단원에서 자동화할 평가의 첫 번째 수동 버전입니다.

체크리스트

  • [ ] RAG는 가중치를 변경하지 않고 컨텍스트만 추가한다는 점을 한 문장으로 설명할 수 있습니다.
  • [ ] RAG, 미세 조정 및 긴 컨텍스트를 구분할 수 있으며 어느 것이 적절한지 알 수 있습니다.
  • [ ] 인덱싱(수집-파쇄-포함-저장) 및 쿼리(포함-가져오기-프롬프트-생성) 단계를 순서대로 셀 수 있습니다.
  • [ ] 프롬프트에 "문맥상 맞지 않으면 모른다고 하세요" 및 "출처 인용" 지침을 추가한 이유를 알겠습니다.
  • [ ] "검색 품질 = RAG 품질"이라는 원칙을 내 사례에 맞게 적용할 수 있습니다.