RAG 완벽 가이드 - LLM의 한계를 극복하는 지능형 검색 시스템

LLM의 Hallucination과 정보 부족 문제를 해결하는 RAG(Retrieval-Augmented Generation) 시스템을 초급자도 이해할 수 있도록 실무 스토리와 코드로 설명합니다. 검색과 생성을 결합한 차세대 AI 시스템의 핵심을 배워보세요.

1. RAG의 개념과 필요성

어느 날 최주니어 개발자는 회사에 ChatGPT를 도입하려다가 큰 문제에 부딪혔습니다. "우리 회사 제품 정보를 물어보니까 엉뚱한 답변을 하네요?" 팀장님이 다가와 물었습니다.

"RAG는 알아봤어요?"

RAG(Retrieval-Augmented Generation) 는 LLM이 답변을 생성하기 전에 관련 정보를 먼저 검색해서 참고하도록 만드는 기술입니다. 마치 시험을 볼 때 교과서를 펼쳐놓고 보는 것과 같습니다.

LLM의 기억력 한계와 거짓 정보 생성 문제를 해결할 수 있습니다.

다음 코드를 살펴봅시다.

# 기본 RAG 개념 시뮬레이션
def simple_rag_concept(user_question):
    # 1단계: 관련 문서 검색 (Retrieval)
    relevant_docs = search_knowledge_base(user_question)

    # 2단계: 검색 결과를 컨텍스트에 추가 (Augmentation)
    context = f"참고 자료: {relevant_docs}"

    # 3단계: LLM에게 컨텍스트와 함께 질문 (Generation)
    prompt = f"{context}\n\n질문: {user_question}"
    answer = llm.generate(prompt)

    return answer

최주니어 개발자는 입사 6개월 차 백엔드 개발자입니다. 최근 회사에서 AI 챗봇 프로젝트를 맡게 되었습니다.

"ChatGPT API만 연결하면 되겠지"라고 생각했지만, 현실은 달랐습니다. 첫 번째 테스트에서 고객이 물었습니다.

"귀사의 프리미엄 요금제 가격이 어떻게 되나요?" ChatGPT는 자신있게 대답했습니다. "월 29,000원입니다." 하지만 실제 가격은 49,000원이었습니다.

이런 현상을 **Hallucination(환각)**이라고 부릅니다. 두 번째 문제도 있었습니다.

"작년 12월에 출시한 신제품 기능을 알려주세요." ChatGPT는 답했습니다. "죄송하지만 2023년 4월 이후의 정보는 알지 못합니다." 학습 데이터의 시점 제한 때문이었습니다.

바로 이때 선배 개발자 강시니어 씨가 다가왔습니다. "RAG라는 걸 한번 알아보세요.

LLM의 한계를 극복할 수 있어요." 그렇다면 RAG란 정확히 무엇일까요? 쉽게 비유하자면, RAG는 마치 오픈북 시험과 같습니다.

학생이 모든 것을 암기하는 대신, 시험장에 교과서를 가져가서 필요한 부분을 찾아보며 답을 작성하는 것입니다. LLM도 마찬가지입니다.

모든 정보를 기억하려 하지 않고, 질문을 받으면 관련 자료를 먼저 찾아본 후 답변합니다. RAG는 세 단계로 작동합니다.

첫 번째는 Retrieval(검색) 단계입니다. 사용자의 질문을 분석해서 관련 있는 문서나 정보를 데이터베이스에서 찾아냅니다.

마치 도서관 사서가 책을 찾아주는 것처럼 말이죠. 두 번째는 Augmentation(보강) 단계입니다.

검색한 정보를 LLM이 이해할 수 있는 형태로 정리해서 컨텍스트에 추가합니다. "이 정보를 참고해서 답변해줘"라고 알려주는 것입니다.

세 번째는 Generation(생성) 단계입니다. LLM이 검색된 정보를 바탕으로 정확한 답변을 생성합니다.

이제 LLM은 근거 있는 답변을 할 수 있습니다. RAG가 없던 시절에는 어땠을까요?

개발자들은 LLM을 회사 데이터와 연결하려면 파인튜닝(Fine-tuning) 을 해야 했습니다. 회사의 모든 문서를 LLM에게 재학습시키는 작업이었죠.

문제는 시간과 비용이었습니다. 수천만 원의 비용과 몇 주의 시간이 필요했습니다.

더 큰 문제는 정보가 업데이트될 때마다 다시 학습해야 한다는 점이었습니다. 신제품이 출시되거나 가격이 변경되면?

또다시 파인튜닝을 해야 했습니다. 중소기업에게는 현실적으로 불가능한 일이었습니다.

바로 이런 문제를 해결하기 위해 RAG가 등장했습니다. RAG를 사용하면 파인튜닝 없이도 최신 정보를 활용할 수 있습니다.

문서 데이터베이스만 업데이트하면 됩니다. 비용도 획기적으로 줄어듭니다.

파인튜닝 대비 1/100 수준의 비용으로 구현 가능합니다. 무엇보다 정확성이라는 큰 이점이 있습니다.

LLM이 근거 없이 지어낸 답변을 하는 대신, 실제 문서에 기반한 답변을 합니다. 어떤 문서를 참고했는지 출처도 표시할 수 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 search_knowledge_base 함수에서 사용자 질문과 관련된 문서를 찾습니다.

이 부분이 핵심입니다. 다음으로 검색된 문서를 컨텍스트에 포함시킵니다.

마지막으로 LLM에게 "이 정보를 참고해서 답변해줘"라고 요청하면 정확한 답변이 반환됩니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 전자상거래 고객센터 챗봇을 개발한다고 가정해봅시다. 고객이 "반품 정책이 어떻게 되나요?"라고 물으면, RAG 시스템은 먼저 회사의 반품 정책 문서를 검색합니다.

그리고 해당 문서 내용을 바탕으로 정확한 답변을 생성합니다. 네이버, 카카오 등 많은 기업에서 이런 패턴을 적극적으로 사용하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 많은 문서를 검색해서 컨텍스트에 넣는 것입니다.

이렇게 하면 LLM이 핵심을 파악하지 못하고 혼란스러워할 수 있습니다. 따라서 가장 관련성 높은 상위 3-5개 문서만 선별해서 사용해야 합니다.

다시 최주니어 개발자의 이야기로 돌아가 봅시다. 강시니어 씨의 설명을 들은 최주니어 씨는 고개를 끄덕였습니다.

"아, 그래서 요즘 AI 챗봇들이 정확한 답변을 하는 거군요!" RAG를 제대로 이해하면 더 똑똑하고 신뢰할 수 있는 AI 시스템을 구축할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - RAG는 파인튜닝보다 훨씬 저렴하고 빠르게 구현할 수 있습니다

검색 품질이 전체 시스템의 성능을 좌우하므로 검색 로직에 집중하세요
출처를 함께 표시하면 사용자 신뢰도가 크게 향상됩니다

2. LLM의 한계 극복

박신입 개발자는 회사 블로그에 ChatGPT 리뷰를 쓰다가 당황했습니다. "GPT한테 우리 회사 창립일을 물어봤더니 완전히 틀린 날짜를 알려주네요?" 이것이 바로 LLM의 대표적인 한계였습니다.

LLM의 주요 한계는 크게 두 가지입니다. 첫째는 Hallucination(환각) 으로, 모르는 내용을 그럴듯하게 지어내는 현상입니다.

둘째는 시점 제한으로, 학습 데이터 이후의 최신 정보를 알지 못합니다. RAG는 이 두 문제를 외부 지식 검색으로 해결합니다.

다음 코드를 살펴봅시다.

# LLM의 한계 vs RAG 해결책
def without_rag(question):
    # 문제: 학습 데이터에 없으면 지어냄
    answer = llm.generate(question)
    return answer  # Hallucination 위험

def with_rag(question):
    # 해결: 실제 문서에서 정보를 가져옴
    docs = vector_db.search(question, top_k=3)
    context = "\n".join([doc.content for doc in docs])

    prompt = f"다음 정보를 바탕으로 답변하세요:\n{context}\n\n질문: {question}"
    answer = llm.generate(prompt)

    # 출처도 함께 반환
    return {"answer": answer, "sources": [doc.source for doc in docs]}

박신입 개발자는 회사 기술 블로그 담당자입니다. 오늘은 "우리 회사의 AI 도입 사례"라는 글을 작성하기로 했습니다.

먼저 ChatGPT에게 회사 정보를 물어봤습니다. "OOO 회사는 언제 창립되었나요?" ChatGPT가 자신있게 답했습니다.

"2015년 3월에 창립되었습니다." 하지만 실제 창립일은 2018년 6월이었습니다. 박신입 씨는 깜짝 놀랐습니다.

더 심각한 문제도 있었습니다. "우리 회사 최신 제품의 주요 기능을 설명해주세요." ChatGPT는 이렇게 답했습니다.

"죄송합니다. 해당 회사의 구체적인 제품 정보는 제 학습 데이터에 포함되어 있지 않습니다." CTO 김테크 씨가 박신입 씨의 모니터를 보고 설명했습니다.

"이게 바로 LLM의 두 가지 치명적인 한계예요." 첫 번째 한계는 Hallucination(환각) 입니다. LLM은 확률 기반으로 다음 단어를 예측하는 모델입니다.

따라서 정확한 정보를 모를 때도 그럴듯한 문장을 생성합니다. 마치 시험 문제를 모를 때 찍는 것과 비슷합니다.

문제는 LLM이 매우 자신있게 거짓 정보를 말한다는 점입니다. 한 연구에 따르면, GPT-3.5는 약 15-20%의 답변에서 사실이 아닌 내용을 포함한다고 합니다.

의료, 법률, 금융처럼 정확성이 중요한 분야에서는 치명적입니다. "환자에게 이 약을 처방하세요"라고 했는데 그게 틀린 정보라면 어떻게 될까요?

두 번째 한계는 시점 제한입니다. GPT-4의 학습 데이터는 2023년 4월까지입니다.

그 이후에 일어난 일은 전혀 모릅니다. 작년에 출시된 신제품도, 최근 변경된 법률도, 어제 발표된 기술 스펙도 모릅니다.

빠르게 변하는 IT 업계에서는 큰 문제입니다. 기업 환경에서는 더 심각합니다.

회사 내부 문서, 제품 매뉴얼, 고객 데이터는 애초에 학습 데이터에 포함될 수 없습니다. 보안상 외부로 내보낼 수 없기 때문입니다.

결국 LLM은 회사 정보에 대해 아무것도 모르는 상태입니다. 그렇다면 어떻게 해결할까요?

전통적인 방법은 파인튜닝이었습니다. 회사 데이터로 LLM을 재학습시키는 것이죠.

하지만 이 방법은 몇 가지 문제가 있습니다. 첫째, 엄청난 비용이 듭니다.

GPT-3.5 파인튜닝에만 수백만 원이 필요합니다. 둘째, 시간이 오래 걸립니다.

데이터 준비부터 학습, 검증까지 수 주가 소요됩니다. 셋째, 업데이트가 어렵습니다.

정보가 바뀔 때마다 재학습해야 합니다. 스타트업이나 중소기업에게는 현실적이지 않은 방법입니다.

바로 이때 RAG가 등장합니다. RAG는 근본적으로 다른 접근 방식을 취합니다.

LLM에게 정보를 주입하는 대신, 필요할 때마다 정보를 찾아서 보여줍니다. 마치 학생에게 모든 내용을 암기시키는 대신, 도서관 이용법을 가르치는 것과 같습니다.

Hallucination 문제는 어떻게 해결될까요? LLM이 더 이상 "모르는 내용을 지어낼" 필요가 없습니다.

검색된 문서에 답이 없으면 "관련 정보를 찾을 수 없습니다"라고 정직하게 답변합니다. 시점 제한 문제는요?

데이터베이스만 최신으로 유지하면 됩니다. 오늘 작성된 문서도, 방금 업데이트된 가격표도 즉시 검색 가능합니다.

재학습 없이 실시간 정보를 제공할 수 있습니다. 위의 코드를 비교해 보겠습니다.

without_rag 함수는 그냥 LLM에게 질문을 던집니다. LLM은 학습된 지식만으로 답변하려 하고, 모르면 지어냅니다.

반면 with_rag 함수는 먼저 벡터 데이터베이스에서 관련 문서를 검색합니다. 그리고 "이 정보를 바탕으로" 답변하라고 명시적으로 지시합니다.

실무에서는 어떤 차이가 있을까요? 한 법률 자문 서비스 스타트업의 사례입니다.

처음에는 일반 ChatGPT API를 사용했습니다. 결과는 참담했습니다.

30%의 법률 조언이 부정확했고, 일부는 폐지된 법령을 인용했습니다. 고객 신뢰도가 급락했습니다.

RAG를 도입한 후 정확도가 95%로 향상되었습니다. 시스템은 항상 최신 법령 데이터베이스를 검색한 후 답변했습니다.

어떤 법조문을 참고했는지 출처도 표시했습니다. 고객 만족도가 크게 올랐습니다.

하지만 RAG도 만능은 아닙니다. 검색 품질에 모든 것이 달려 있습니다.

엉뚱한 문서를 검색하면 엉뚱한 답변이 나옵니다. 또한 데이터베이스 구축과 관리에 노력이 필요합니다.

문서를 잘 정리하고, 주기적으로 업데이트해야 합니다. 김테크 CTO는 마지막으로 조언했습니다.

"RAG는 LLM의 한계를 극복하는 현실적인 해법이에요. 하지만 검색 시스템 설계가 핵심입니다.

여기에 집중하세요." 박신입 개발자는 이제 RAG의 가치를 이해했습니다. 다음 날부터 회사 문서 데이터베이스 구축을 시작했습니다.

실전 팁

💡 - Hallucination 방지를 위해 LLM에게 "모르면 모른다고 답하라"고 명시적으로 지시하세요

답변과 함께 출처를 표시하면 사용자가 팩트 체크할 수 있습니다
검색 품질이 답변 품질을 결정하므로 검색 로직을 최우선으로 개선하세요

3. Retrieval → Augmentation → Generation 흐름

이개발 씨는 RAG의 원리를 이해하고 싶었지만 설명이 너무 추상적이었습니다. "검색하고 보강하고 생성한다는데, 구체적으로 뭘 어떻게 한다는 거지?" 팀장 정아키텍트 씨가 화이트보드에 그림을 그리며 설명하기 시작했습니다.

RAG의 3단계 파이프라인은 정보 검색, 컨텍스트 보강, 답변 생성으로 이루어집니다. Retrieval은 벡터 검색으로 관련 문서를 찾고, Augmentation은 프롬프트에 문서를 삽입하며, Generation은 LLM이 컨텍스트 기반으로 답변을 생성합니다.

다음 코드를 살펴봅시다.

from sentence_transformers import SentenceTransformer
import numpy as np

class RAGPipeline:
    def __init__(self, documents, llm):
        self.encoder = SentenceTransformer('all-MiniLM-L6-v2')
        self.llm = llm
        # 1. Retrieval 준비: 문서를 벡터로 변환
        self.doc_embeddings = self.encoder.encode(documents)
        self.documents = documents

    def search(self, query, top_k=3):
        # 2. Retrieval: 질문을 벡터로 변환 후 유사도 검색
        query_embedding = self.encoder.encode([query])[0]
        similarities = np.dot(self.doc_embeddings, query_embedding)
        top_indices = np.argsort(similarities)[-top_k:][::-1]
        return [self.documents[i] for i in top_indices]

    def generate(self, query):
        # 3. Augmentation: 검색 결과를 프롬프트에 추가
        retrieved_docs = self.search(query)
        context = "\n\n".join([f"문서 {i+1}: {doc}" for i, doc in enumerate(retrieved_docs)])

        prompt = f"""다음 문서들을 참고하여 질문에 답변하세요.

{context}

질문: {query}
답변:"""

        # 4. Generation: LLM이 컨텍스트 기반 답변 생성
        answer = self.llm.generate(prompt)
        return answer

이개발 씨는 3년차 풀스택 개발자입니다. RAG 개념은 이해했지만 실제로 어떻게 작동하는지 감이 잡히지 않았습니다.

"검색한다는 건 SQL SELECT 같은 건가요? 보강한다는 건 뭘 보강한다는 거죠?" 팀장 정아키텍트 씨가 화이트보드에 세 개의 박스를 그렸습니다.

"RAG는 이 세 단계로 작동해요. 하나씩 설명해 드릴게요." 첫 번째 박스에는 Retrieval(검색) 이라고 적혀 있었습니다.

"일반적인 데이터베이스 검색과는 좀 달라요." 정팀장이 설명을 시작했습니다. "SQL의 WHERE 절처럼 정확히 일치하는 걸 찾는 게 아니라, 의미적으로 유사한 문서를 찾는 거예요." 어떻게 의미를 비교할까요?

바로 벡터 임베딩(Vector Embedding) 을 사용합니다. 텍스트를 숫자 배열로 변환하는 것입니다.

예를 들어 "강아지"는 [0.2, 0.8, 0.1, ...], "개"는 [0.21, 0.79, 0.12, ...]처럼 변환됩니다. 비슷한 의미를 가진 단어는 비슷한 벡터 값을 갖습니다.

"강아지"와 "개"의 벡터는 매우 가깝고, "강아지"와 "비행기"의 벡터는 멉니다. 이 원리로 문서의 유사도를 계산할 수 있습니다.

사용자가 "반품 정책이 뭔가요?"라고 물으면, 이 질문도 벡터로 변환됩니다. 그리고 데이터베이스에 저장된 모든 문서 벡터와 비교합니다.

가장 유사한 상위 3-5개 문서를 선택합니다. 이것이 Retrieval 단계입니다.

두 번째 박스에는 Augmentation(보강) 이라고 적혀 있었습니다. "검색한 문서를 그냥 LLM에게 던지는 게 아니에요." 정팀장이 계속 설명했습니다.

"프롬프트에 체계적으로 삽입해야 해요." 예를 들어봅시다. 검색 결과로 세 개의 문서를 찾았다고 가정합니다.

이제 이 문서들을 LLM이 이해할 수 있는 형태로 정리합니다. "다음 정보를 참고하세요"라는 지시와 함께 문서 내용을 프롬프트 앞부분에 추가합니다.

여기서 중요한 점이 있습니다. 단순히 문서를 나열하는 게 아니라, 구조화해야 합니다.

"문서 1: [내용]", "문서 2: [내용]" 형식으로 명확하게 구분합니다. 출처 정보도 함께 포함합니다.

프롬프트 끝부분에는 사용자의 원래 질문을 추가합니다. "위 정보를 바탕으로 다음 질문에 답변하세요: [질문]" 이렇게 하면 LLM이 컨텍스트를 고려해서 답변할 수 있습니다.

이것이 Augmentation 단계입니다. 세 번째 박스에는 Generation(생성) 이라고 적혀 있었습니다.

"이제 준비가 끝났어요." 정팀장이 미소를 지었습니다. "보강된 프롬프트를 LLM에게 보내면 됩니다." LLM은 이제 풍부한 컨텍스트를 가지고 있습니다.

사용자 질문과 관련된 구체적인 정보가 프롬프트에 포함되어 있습니다. 더 이상 기억에만 의존하지 않습니다.

눈앞에 참고 자료가 있는 것과 같습니다. LLM은 제공된 문서를 분석하고, 질문과 관련된 부분을 추출하고, 자연스러운 문장으로 재구성합니다.

"귀사의 반품 정책은 구매일로부터 14일 이내 가능하며, 제품 포장이 훼손되지 않아야 합니다." 이런 식으로 정확한 답변이 생성됩니다. 위의 코드를 자세히 살펴봅시다.

__init__ 메서드에서는 문서들을 미리 벡터로 변환해 둡니다. 이것을 인덱싱이라고 합니다.

매번 변환하면 느리기 때문에 초기화 시점에 한 번만 수행합니다. search 메서드가 Retrieval 을 담당합니다.

사용자 질문을 벡터로 변환하고, 코사인 유사도로 가장 비슷한 문서를 찾습니다. np.argsort로 유사도가 높은 순서대로 정렬하고, 상위 K개를 선택합니다.

generate 메서드가 Augmentation과 Generation을 모두 처리합니다. 검색된 문서를 프롬프트에 체계적으로 배치하고, LLM에게 전달합니다.

실무에서는 더 정교한 기법들이 사용됩니다. Re-ranking이라는 기법이 있습니다.

초기 검색에서 10개 문서를 찾은 후, 더 정밀한 모델로 재평가해서 최종 3개를 선택하는 것입니다. 정확도가 크게 향상됩니다.

Hybrid Search도 있습니다. 벡터 검색과 키워드 검색을 결합하는 방법입니다.

"2023년 12월 보고서"처럼 날짜나 고유명사가 중요한 경우, 키워드 검색이 더 정확합니다. 두 방식의 결과를 합쳐서 사용합니다.

Chunk Size도 중요합니다. 문서를 얼마나 작은 단위로 나눌 것인가의 문제입니다.

너무 크면 관련 없는 내용이 많이 포함되고, 너무 작으면 맥락을 잃습니다. 보통 500-1000 토큰 단위로 나눕니다.

한 e-커머스 회사의 사례를 보겠습니다. 처음에는 단순한 키워드 검색을 사용했습니다.

"배송 얼마나 걸려요?"라는 질문에 "배송"이라는 키워드가 들어간 모든 문서를 찾았습니다. 결과는 엉망이었습니다.

배송 정책, 배송 추적, 반품 시 반송 배송 등 관련 없는 내용이 섞여 나왔습니다. 벡터 검색을 도입한 후 정확도가 30%에서 85%로 향상되었습니다.

"배송 얼마나 걸려요?"는 "배송 기간", "소요 시간" 같은 의미적으로 유사한 문서를 찾았습니다. 사용자가 만족하는 답변이 나왔습니다.

하지만 초보자들이 자주 하는 실수가 있습니다. 너무 많은 문서를 프롬프트에 넣는 것입니다.

"많을수록 좋겠지"라고 생각해서 20-30개 문서를 넣으면, LLM이 오히려 핵심을 놓칩니다. 보통 3-5개가 적당합니다.

출처 정보를 무시하는 것도 문제입니다. 어떤 문서를 참고했는지 기록해두지 않으면, 나중에 검증할 방법이 없습니다.

항상 문서 ID나 페이지 번호를 함께 저장하세요. 정아키텍트 팀장이 마무리했습니다.

"이 세 단계가 유기적으로 연결되어야 좋은 RAG 시스템이 만들어져요. 어느 하나라도 부실하면 전체 품질이 떨어집니다." 이개발 씨는 이제 RAG의 작동 원리를 명확하게 이해했습니다.

다음 날부터 실제 구현을 시작할 준비가 되었습니다.

실전 팁

💡 - 벡터 데이터베이스는 Pinecone, Weaviate, ChromaDB 등을 활용하세요

검색 결과는 3-5개가 적당하며, 너무 많으면 오히려 성능이 떨어집니다
프롬프트에 "제공된 정보에 없으면 모른다고 답하라"는 지시를 추가하세요

4. RAG vs Fine-tuning

신스타트업 CTO 한고민 씨는 선택의 기로에 섰습니다. "RAG로 갈까요, 파인튜닝으로 갈까요?" 투자자 미팅에서 "ChatGPT를 우리 제품에 맞게 커스터마이징"하겠다고 했는데, 방법이 두 가지였습니다.

자문을 구하러 AI 전문가 조박사를 찾아갔습니다.

RAG는 외부 지식 검색으로 LLM을 보강하는 방식이고, Fine-tuning은 LLM 자체를 재학습시키는 방식입니다. RAG는 빠르고 저렴하며 업데이트가 쉽지만, Fine-tuning은 모델의 행동 패턴 자체를 바꿀 수 있습니다.

대부분의 경우 RAG가 더 실용적입니다.

다음 코드를 살펴봅시다.

# RAG 방식: 검색 + 생성
class RAGApproach:
    def __init__(self, knowledge_base, llm):
        self.kb = knowledge_base  # 문서 DB (언제든 업데이트 가능)
        self.llm = llm  # 기본 LLM (변경 없음)

    def answer(self, question):
        docs = self.kb.search(question)
        context = "\n".join(docs)
        prompt = f"참고: {context}\n질문: {question}"
        return self.llm.generate(prompt)

    def update_knowledge(self, new_docs):
        # 즉시 업데이트 가능 (재학습 불필요)
        self.kb.add_documents(new_docs)

# Fine-tuning 방식: 모델 재학습
class FineTuningApproach:
    def __init__(self, base_model):
        self.model = base_model

    def train(self, training_data):
        # 수천 개의 예제로 재학습 (시간과 비용 소요)
        # 몇 시간~며칠 소요
        self.model.fine_tune(training_data, epochs=3)

    def answer(self, question):
        # 학습된 지식으로 바로 답변
        return self.model.generate(question)

    def update_knowledge(self, new_data):
        # 전체 재학습 필요 (시간과 비용 재소요)
        self.train(new_data)

한고민 CTO는 시리즈 A 투자를 막 유치한 스타트업의 기술 책임자입니다. 투자자들 앞에서 "AI 기반 고객 상담 서비스"를 만들겠다고 발표했습니다.

문제는 구체적인 방법이었습니다. "ChatGPT API를 그냥 쓰면 우리 회사 제품을 모르잖아요." 한고민 CTO는 고민에 빠졌습니다.

구글링을 해보니 두 가지 방법이 나왔습니다. RAG와 Fine-tuning.

어떤 게 나을까요? AI 자문 조박사를 찾아갔습니다.

"둘 다 LLM을 회사 데이터와 연결하는 방법이에요. 하지만 접근 방식이 완전히 다릅니다." Fine-tuning부터 살펴봅시다.

Fine-tuning은 마치 학생을 재교육하는 것과 같습니다. 기본 교육을 받은 학생에게 특수 분야를 집중적으로 가르치는 것이죠.

LLM도 마찬가지입니다. GPT-3.5 같은 기본 모델을 가져와서, 회사 데이터로 추가 학습시킵니다.

수천 개의 질문-답변 쌍을 준비합니다. "Q: 프리미엄 요금제 가격은?

A: 월 49,000원입니다." 이런 식으로 회사 관련 지식을 학습시킵니다. 모델의 가중치가 업데이트되면서, 회사 정보를 "기억"하게 됩니다.

장점은 명확합니다. 답변 속도가 빠릅니다.

매번 검색할 필요 없이 바로 답변합니다. 또한 특정한 말투나 스타일을 학습시킬 수 있습니다.

"친근한 캐주얼 톤" 같은 페르소나를 주입할 수 있습니다. 하지만 문제가 많습니다.

첫째, 비용입니다. OpenAI GPT-3.5 Fine-tuning은 학습 데이터 1만 토큰당 약 8달러입니다.

중간 규모 데이터셋이면 수백만 원이 들 수 있습니다. 스타트업에게는 부담스러운 금액입니다.

둘째, 시간입니다. 데이터 준비에 며칠, 학습에 몇 시간에서 며칠이 걸립니다.

급하게 서비스를 론칭해야 하는데 일주일씩 기다릴 수 없습니다. 셋째, 업데이트 문제입니다.

신제품이 나왔다면? 가격이 바뀌었다면?

전체를 다시 학습해야 합니다. 매번 비용과 시간이 다시 듭니다.

변화가 빠른 비즈니스에는 맞지 않습니다. 넷째, 데이터 양입니다.

효과적인 Fine-tuning에는 보통 수천 개 이상의 고품질 예제가 필요합니다. 데이터가 부족한 초기 스타트업에는 어렵습니다.

이제 RAG를 봅시다. RAG는 학생을 재교육하는 대신, 시험장에 참고서를 가져가게 하는 것과 같습니다.

LLM 자체는 바꾸지 않습니다. 대신 필요할 때마다 정보를 검색해서 제공합니다.

문서 데이터베이스를 구축합니다. 회사 매뉴얼, 제품 설명서, FAQ 등을 벡터 DB에 저장합니다.

질문이 들어오면 관련 문서를 찾아서 프롬프트에 추가합니다. LLM은 그 정보를 바탕으로 답변합니다.

장점이 압도적입니다. 첫째, 비용이 저렴합니다.

벡터 DB 구축 비용은 파인튜닝의 1/10 수준입니다. ChromaDB 같은 오픈소스를 쓰면 거의 무료입니다.

둘째, 구축 속도가 빠릅니다. 문서만 준비되면 하루 만에 시스템을 구축할 수 있습니다.

벡터 변환은 자동으로 됩니다. 셋째, 업데이트가 즉각적입니다.

새 문서를 DB에 추가하면 끝입니다. 재학습 없이 바로 반영됩니다.

실시간으로 변하는 정보도 문제없습니다. 넷째, 투명성이 있습니다.

어떤 문서를 참고해서 답변했는지 출처를 표시할 수 있습니다. 사용자가 직접 확인할 수 있어 신뢰도가 높습니다.

다섯째, 데이터 양이 적어도 됩니다. 문서만 있으면 됩니다.

수천 개의 Q&A 쌍을 만들 필요가 없습니다. "그럼 RAG가 항상 좋은 건가요?" 한고민 CTO가 물었습니다.

조박사가 고개를 저었습니다. "특정 상황에서는 Fine-tuning이 필요해요." Fine-tuning이 적합한 경우는 다음과 같습니다.

특정 스타일이나 포맷이 중요할 때입니다. 예를 들어 의료 보고서를 특정 형식으로 작성해야 한다면, Fine-tuning이 더 일관된 결과를 냅니다.

RAG는 매번 검색 결과에 따라 스타일이 조금씩 달라질 수 있습니다. 검색이 어려운 지식일 때도 유용합니다.

복잡한 수학 공식이나 프로그래밍 패턴처럼 "암묵적 지식"은 문서화하기 어렵습니다. 이런 건 예제로 학습시키는 게 낫습니다.

응답 속도가 극도로 중요할 때도 고려할 수 있습니다. RAG는 검색 단계가 추가되므로 0.5-1초 정도 느립니다.

실시간 채팅에서는 체감될 수 있습니다. 하지만 대부분의 비즈니스 사례에서는 RAG가 압도적으로 유리합니다.

위의 코드를 비교해 보세요. RAGApproach는 update_knowledge 메서드가 매우 간단합니다.

그냥 문서를 추가하면 끝입니다. 반면 FineTuningApproach는 업데이트할 때마다 전체 재학습을 해야 합니다.

실제 기업 사례를 보겠습니다. 한 중견 보험사는 처음에 Fine-tuning을 시도했습니다.

보험 상품 Q&A 5,000개로 GPT-3.5를 학습시켰습니다. 비용은 300만 원, 시간은 2주였습니다.

결과는 괜찮았습니다. 문제는 3개월 후 발생했습니다.

신상품 5개가 출시되고, 약관이 일부 변경되었습니다. 다시 학습해야 했습니다.

또 300만 원, 또 2주. 연간 유지보수 비용이 2,000만 원을 넘어섰습니다.

결국 RAG로 전환했습니다. 초기 구축에 1주일, 비용은 50만 원이었습니다.

신상품 출시? 문서만 업데이트하면 즉시 반영됩니다.

추가 비용 없습니다. 연간 유지비가 1/20로 줄었습니다.

조박사가 조언했습니다. "대부분의 경우 RAG로 시작하세요.

정말 필요하다는 확신이 들 때만 Fine-tuning을 고려하세요." 한고민 CTO는 결정을 내렸습니다. "RAG로 가겠습니다.

빠르게 MVP를 만들고, 피드백을 받으면서 개선하는 게 스타트업 방식에 맞네요."

실전 팁

💡 - 90% 이상의 케이스에서 RAG가 더 실용적입니다

Fine-tuning은 스타일/톤을 바꾸거나 특수한 포맷이 필요할 때만 고려하세요
RAG와 Fine-tuning을 함께 쓸 수도 있습니다 (Fine-tuned 모델 + RAG)

5. 실습: 간단한 RAG 시스템 구축

드디어 실습 시간입니다. 오백엔드 개발자는 회사 제품 매뉴얼로 RAG 챗봇을 만들기로 했습니다.

"이론은 알겠는데, 실제로 어떻게 코드를 짜야 하지?" Python을 켜고, 필요한 라이브러리부터 찾아보기 시작했습니다.

간단한 RAG 시스템은 ChromaDB(벡터 DB), Sentence-Transformers(임베딩), OpenAI API(LLM) 세 가지만 있으면 구축할 수 있습니다. 문서를 임베딩해서 저장하고, 질문과 유사한 문서를 검색한 뒤, LLM에게 컨텍스트와 함께 전달하면 됩니다.

다음 코드를 살펴봅시다.

import chromadb
from sentence_transformers import SentenceTransformer
import openai

# 1. 벡터 DB 초기화
client = chromadb.Client()
collection = client.create_collection("product_docs")

# 2. 임베딩 모델 준비
encoder = SentenceTransformer('all-MiniLM-L6-v2')

# 3. 문서 추가 함수
def add_documents(docs):
    embeddings = encoder.encode(docs)
    collection.add(
        embeddings=embeddings.tolist(),
        documents=docs,
        ids=[f"doc_{i}" for i in range(len(docs))]
    )

# 4. RAG 질의 함수
def rag_query(question, top_k=3):
    # 질문을 임베딩
    q_embedding = encoder.encode([question])[0]

    # 유사 문서 검색
    results = collection.query(
        query_embeddings=[q_embedding.tolist()],
        n_results=top_k
    )

    # 컨텍스트 구성
    context = "\n\n".join(results['documents'][0])

    # LLM에 질의
    response = openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        messages=[
            {"role": "system", "content": "다음 문서를 참고하여 답변하세요:\n" + context},
            {"role": "user", "content": question}
        ]
    )

    return response.choices[0].message.content

# 5. 사용 예시
docs = [
    "프리미엄 요금제는 월 49,000원이며 무제한 API 호출을 제공합니다.",
    "환불 정책: 구매 후 14일 이내 전액 환불 가능합니다.",
    "고객센터 운영시간은 평일 09:00-18:00입니다."
]
add_documents(docs)
answer = rag_query("요금제 가격이 얼마인가요?")
print(answer)

오백엔드 개발자는 3년차 파이썬 개발자입니다. 이론 공부는 끝났고, 이제 직접 만들어볼 시간입니다.

"일단 가장 간단한 버전부터 만들어보자." 먼저 필요한 것들을 정리했습니다. 벡터 데이터베이스가 필요합니다.

문서를 벡터로 변환해서 저장하고, 유사도 검색을 지원해야 합니다. 오백엔드 씨는 ChromaDB를 선택했습니다.

오픈소스이고, 설치가 간단하며, 초보자도 사용하기 쉽기 때문입니다. 임베딩 모델도 필요합니다.

텍스트를 벡터로 변환하는 모델이죠. Sentence-Transformers 라이브러리의 all-MiniLM-L6-v2 모델을 선택했습니다.

가볍고 빠르며, 품질도 괜찮습니다. 마지막으로 LLM API가 필요합니다.

OpenAI의 GPT-3.5-turbo를 사용하기로 했습니다. 가장 대중적이고, 문서도 잘 되어 있습니다.

라이브러리를 설치합니다. 터미널에 명령어를 입력합니다.

pip install chromadb sentence-transformers openai 몇 분 안에 설치가 완료됩니다. 생각보다 간단합니다.

이제 코드를 작성합니다. 먼저 ChromaDB 클라이언트를 초기화합니다.

client = chromadb.Client() 이것은 인메모리 DB를 생성합니다. 개발용으로는 충분합니다.

프로덕션에서는 영구 저장소를 사용해야 합니다. 컬렉션을 만듭니다.

collection = client.create_collection("product_docs") 컬렉션은 RDB의 테이블과 비슷한 개념입니다. 여기에 문서들을 저장할 것입니다.

임베딩 모델을 로드합니다. encoder = SentenceTransformer('all-MiniLM-L6-v2') 처음 실행하면 모델을 다운로드합니다.

약 80MB 정도입니다. 문서 추가 함수를 만듭니다.

add_documents 함수는 문서 리스트를 받아서 벡터 DB에 저장합니다. encoder.encode(docs)로 문서를 벡터로 변환합니다.

이 벡터가 의미적 표현입니다. collection.add()로 컬렉션에 추가합니다.

임베딩뿐만 아니라 원본 텍스트도 함께 저장합니다. 나중에 검색 결과로 원본 텍스트를 가져오기 위해서입니다.

각 문서에 고유 ID도 부여합니다. 이제 핵심인 RAG 질의 함수를 만듭니다.

rag_query 함수는 사용자 질문을 받아서 답변을 반환합니다. 먼저 질문을 임베딩합니다.

encoder.encode([question])[0] 질문도 문서와 같은 벡터 공간에 매핑됩니다. collection.query()로 유사한 문서를 검색합니다.

n_results=top_k로 상위 K개만 가져옵니다. 보통 3-5개가 적당합니다.

ChromaDB는 내부적으로 코사인 유사도를 계산해서 가장 비슷한 문서를 찾아줍니다. 검색된 문서들을 하나의 컨텍스트로 합칩니다.

"\n\n".join()으로 문서들을 줄바꿈으로 연결합니다. 이렇게 하면 LLM이 여러 문서를 구분할 수 있습니다.

OpenAI API를 호출합니다. System 메시지에 컨텍스트를 넣고, User 메시지에 질문을 넣습니다.

"다음 문서를 참고하여 답변하세요"라고 명시적으로 지시합니다. 실제로 사용해 봅시다.

샘플 문서 세 개를 준비합니다. 요금제 정보, 환불 정책, 고객센터 운영시간 같은 실무적인 내용입니다.

add_documents(docs)로 벡터 DB에 저장합니다. "요금제 가격이 얼마인가요?"라고 질문합니다.

RAG 시스템이 작동합니다. 질문을 벡터로 변환하고, 유사한 문서를 찾고, LLM이 답변을 생성합니다.

"프리미엄 요금제는 월 49,000원입니다." 정확한 답변이 나옵니다! 오백엔드 씨는 감탄했습니다.

"생각보다 간단하네요. 50줄도 안 되는 코드로 RAG 시스템이 만들어졌어요!" 하지만 실무에서는 더 고려해야 할 것들이 있습니다.

청킹(Chunking) 전략이 필요합니다. 긴 문서는 적절한 크기로 나눠야 합니다.

한 문서가 너무 길면 임베딩의 품질이 떨어집니다. 보통 500-1000 토큰 단위로 나눕니다.

메타데이터도 저장해야 합니다. 문서 출처, 작성일, 카테고리 같은 정보를 함께 저장하면 필터링이 가능합니다.

"2024년 이후 문서만 검색" 같은 조건을 걸 수 있습니다. 프롬프트 엔지니어링도 중요합니다.

"제공된 정보에 없으면 '모르겠습니다'라고 답하세요" 같은 지시를 추가하면 Hallucination을 줄일 수 있습니다. 에러 핸들링도 빠지면 안 됩니다.

검색 결과가 없을 때, API 호출이 실패할 때 등의 상황을 처리해야 합니다. 선배 개발자 김시니어가 오백엔드 씨의 화면을 봤습니다.

"오, 벌써 작동하네요! 이제 실제 문서를 넣어보고, 성능을 테스트해 보세요.

처음 만든 버전은 보통 정확도가 70% 정도 나와요. 거기서부터 개선하는 게 진짜 시작입니다." 오백엔드 씨는 노트북에 TODO를 적었습니다.

"1. 실제 매뉴얼 PDF를 텍스트로 변환하기, 2.

청킹 전략 구현하기, 3. 정확도 측정 시스템 만들기." 할 일이 많지만, 첫 걸음을 떼었다는 게 뿌듯했습니다.

실전 팁

💡 - 로컬 테스트에는 인메모리 ChromaDB로 충분하지만, 프로덕션에서는 영구 저장소를 사용하세요

임베딩 모델은 다국어 지원이 필요하면 'paraphrase-multilingual-MiniLM-L12-v2'를 사용하세요
OpenAI API 키는 환경변수로 관리하고, 절대 코드에 하드코딩하지 마세요

6. 실습: RAG vs Non-RAG 비교

마지막 실습입니다. 유데이터 분석가는 "RAG가 정말 효과 있을까?"라는 의심을 품었습니다.

"직접 비교해보지 않고는 못 믿겠어." 같은 질문을 RAG 시스템과 일반 LLM에 각각 던져보기로 했습니다. 결과는 놀라웠습니다.

RAG와 Non-RAG 비교 실험은 같은 질문에 대한 답변 품질을 측정하는 것입니다. Non-RAG는 LLM의 내부 지식만으로 답변하므로 Hallucination과 정보 부족이 발생하고, RAG는 실제 문서 기반으로 정확한 답변을 제공합니다.

정확도 차이가 보통 2-3배 이상 납니다.

다음 코드를 살펴봅시다.

import openai

# 실험용 회사 문서
company_docs = """
[회사명] 테크이노베이션
[설립일] 2021년 3월 15일
[주력 제품] AI 챗봇 플랫폼 'ChatGenius'
[요금제]
  - 스타터: 월 29,000원 (월 1만 호출)
  - 프로: 월 49,000원 (월 10만 호출)
  - 엔터프라이즈: 월 199,000원 (무제한)
[최근 업데이트] 2024년 2월 - 한국어 감성분석 기능 추가
"""

# 1. Non-RAG: 순수 LLM만 사용
def non_rag_answer(question):
    response = openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        messages=[
            {"role": "user", "content": question}
        ]
    )
    return response.choices[0].message.content

# 2. RAG: 문서 컨텍스트 포함
def rag_answer(question, context):
    response = openai.ChatCompletion.create(
        model="gpt-3.5-turbo",
        messages=[
            {"role": "system", "content": f"다음 정보를 참고하여 답변하세요. 정보에 없는 내용은 '제공된 정보에 없습니다'라고 답하세요:\n\n{context}"},
            {"role": "user", "content": question}
        ]
    )
    return response.choices[0].message.content

# 3. 비교 실험
test_questions = [
    "테크이노베이션은 언제 설립되었나요?",
    "프로 요금제 가격은 얼마인가요?",
    "최근에 추가된 기능은 무엇인가요?"
]

print("=" * 50)
for q in test_questions:
    print(f"\n질문: {q}")
    print(f"\n[Non-RAG 답변]")
    print(non_rag_answer(q))
    print(f"\n[RAG 답변]")
    print(rag_answer(q, company_docs))
    print("=" * 50)

유데이터 분석가는 5년차 데이터 사이언티스트입니다. "A/B 테스트 없이는 아무것도 믿지 않는다"가 그의 모토입니다.

RAG 도입을 검토하면서도 "정말 효과가 있을까?"라는 의심을 버릴 수 없었습니다. "직접 실험해보자." 유데이터 씨는 비교 실험을 설계했습니다.

실험 설계는 간단합니다. 가상의 회사 정보를 만들고, 그에 대한 질문을 준비합니다.

같은 질문을 두 시스템에 각각 던지고, 답변을 비교합니다. 어느 쪽이 더 정확한지 확인하는 것입니다.

먼저 회사 문서를 작성했습니다. "테크이노베이션"이라는 가상의 회사를 만들었습니다.

설립일은 2021년 3월 15일, 주력 제품은 AI 챗봇 플랫폼, 요금제는 세 가지로 구성됩니다. 최근 업데이트로 한국어 감성분석 기능을 추가했다는 설정입니다.

이 정보는 LLM의 학습 데이터에 절대 없습니다. 지금 막 만든 가상의 정보이기 때문입니다.

따라서 Non-RAG 시스템은 답을 알 수가 없습니다. 질문 세 개를 준비했습니다.

"테크이노베이션은 언제 설립되었나요?" - 구체적인 날짜를 묻는 질문입니다. "프로 요금제 가격은 얼마인가요?" - 정확한 숫자를 요구합니다.

"최근에 추가된 기능은 무엇인가요?" - 최신 정보를 묻습니다. 첫 번째 시스템은 Non-RAG입니다.

그냥 OpenAI API를 호출합니다. 어떤 컨텍스트도 제공하지 않습니다.

LLM은 자신의 학습된 지식만으로 답변해야 합니다. 하지만 테크이노베이션은 실제로 존재하지 않는 회사입니다.

실험을 돌려봤습니다. 질문: "테크이노베이션은 언제 설립되었나요?" Non-RAG 답변: "죄송하지만 테크이노베이션이라는 회사에 대한 정보가 제 학습 데이터에 없습니다." 좋습니다.

정직하게 모른다고 답했습니다. 하지만 실무에서는 이게 문제입니다.

고객이 우리 회사에 대해 물었는데 "모른다"고 하면 어떻게 될까요? 때로는 더 나쁜 일이 일어납니다.

질문: "프로 요금제 가격은 얼마인가요?" Non-RAG 답변: "일반적으로 프로 요금제는 월 $99 정도입니다만, 정확한 가격은 공식 웹사이트를 확인해주세요." 이것이 Hallucination입니다. LLM이 "일반적인" 가격을 추측해서 답했습니다.

문제는 실제 가격(49,000원)과 전혀 다르다는 점입니다. 잘못된 정보를 자신있게 말하는 것이 가장 위험합니다.

이제 두 번째 시스템, RAG를 실행합니다. 같은 질문을 하지만, 이번에는 회사 문서를 컨텍스트로 제공합니다.

System 메시지에 "다음 정보를 참고하여 답변하세요"라고 명시합니다. 회사 문서 전체를 포함시킵니다.

결과는 확연히 달랐습니다. 질문: "테크이노베이션은 언제 설립되었나요?" RAG 답변: "테크이노베이션은 2021년 3월 15일에 설립되었습니다." 정확합니다!

문서에 있는 그대로 답변했습니다. 질문: "프로 요금제 가격은 얼마인가요?" RAG 답변: "프로 요금제는 월 49,000원이며, 월 10만 호출까지 사용 가능합니다." 이것도 완벽합니다.

가격뿐만 아니라 호출 제한까지 정확히 답변했습니다. 질문: "최근에 추가된 기능은 무엇인가요?" RAG 답변: "2024년 2월에 한국어 감성분석 기능이 추가되었습니다." Non-RAG는 이 질문에 답할 방법이 없었습니다.

학습 데이터 이후의 정보이기 때문입니다. 하지만 RAG는 문서에서 정보를 찾아서 정확히 답변했습니다.

유데이터 씨는 결과를 정리했습니다. 정확도: Non-RAG 0%, RAG 100%.

세 질문 모두 RAG만 정확히 답변했습니다. Hallucination: Non-RAG는 한 번 발생, RAG는 없음.

프롬프트에 "정보에 없으면 모른다고 답하라"는 지시가 있었기 때문입니다. 최신 정보: Non-RAG는 불가능, RAG는 즉시 반영.

문서만 업데이트하면 됩니다. 실제 기업 데이터로도 테스트해봤습니다.

한 고객사의 FAQ 100개를 사용했습니다. Non-RAG는 정확도 23%였습니다.

대부분 "모른다"고 답하거나, 일반적인 답변으로 회피했습니다. 일부는 잘못된 정보를 제공했습니다.

RAG는 정확도 87%였습니다. 대부분의 질문에 정확히 답변했습니다.

13%의 오류는 주로 검색 실패 때문이었습니다. 질문이 애매하거나, 관련 문서가 정말 없는 경우였습니다.

더 흥미로운 발견도 있었습니다. 출처 표시: RAG 시스템에 어떤 문서를 참고했는지 표시하도록 수정했습니다.

사용자들이 답변을 훨씬 더 신뢰했습니다. "이 정보는 '제품 매뉴얼 3.2절'에서 가져왔습니다" 같은 출처가 있으니까요.

업데이트 속도: 신제품 정보를 추가하는 테스트를 했습니다. Non-RAG는 재학습이 필요하므로 불가능했습니다.

RAG는 문서를 DB에 추가하는 데 5초, 즉시 검색 가능했습니다. 비용: 100개 질문 처리 비용을 계산했습니다.

Non-RAG는 API 호출 비용만 약 $0.5였습니다. RAG는 임베딩 비용 + API 비용으로 약 $0.8였습니다.

60% 더 비싸지만, 정확도가 4배 높으니 충분히 가치 있습니다. 하지만 RAG의 한계도 발견했습니다.

검색 실패: 질문이 너무 애매하면 관련 문서를 못 찾습니다. "저거 얼마예요?"처럼 지시대명사가 있으면 어려워합니다.

대화 컨텍스트를 유지하는 로직이 추가로 필요합니다. 속도: Non-RAG는 평균 응답 시간 0.8초, RAG는 1.3초였습니다.

검색 단계가 추가되면서 0.5초 느려졌습니다. 대부분의 경우 큰 문제는 아니지만, 실시간 채팅에서는 체감될 수 있습니다.

유데이터 씨는 보고서를 작성했습니다. "RAG 도입을 강력히 권장합니다.

정확도 향상이 비용 증가를 압도합니다. 특히 회사 고유 정보에 대한 질문에서 Non-RAG는 사실상 사용 불가능합니다." CTO가 보고서를 읽고 승인했습니다.

"좋습니다. 다음 스프린트에 RAG 시스템 구축을 포함시키세요." 유데이터 씨는 만족스러웠습니다.

데이터로 증명했으니까요.

실전 팁

💡 - A/B 테스트를 할 때는 실제 사용자 질문 로그를 활용하세요

정확도뿐만 아니라 응답 시간, 비용도 함께 측정하세요
"모른다"고 정직하게 답하는 것도 좋은 답변입니다 - Hallucination보다 훨씬 낫습니다

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

#Python#RAG#LLM#VectorDB#Embeddings#RAG,LLM,기초

RAG 완벽 가이드 - LLM의 한계를 극복하는 지능형 검색 시스템

# RAG 완벽 가이드 - LLM의 한계를 극복하는 지능형 검색 시스템 LLM의 Hallucination과 정보 부족 문제를 해결하는 RAG(Retrieval-Augmented Generation) 시스템을 초급자도 이해할 수 있도록 실무 스토리와 코드로 설명합니다. 검색과 생성을 결합한 차세대 AI 시스템의 핵심을 배워보세요. --- ## 목차 1. [RAG의 개념과 필요성](#rag의-개념과-필요성) 2. [LLM의 한계 극복](#llm의-한계-극복) 3. [Retrieval → Augmentation → Generation 흐름](#retrieval-→-augmentation-→-generation-흐름) 4. [RAG vs Fine-tuning](#rag-vs-fine-tuning) 5. [실습: 간단한 RAG 시스템 구축](#실습:-간단한-rag-시스템-구축) 6. [실습: RAG vs Non-RAG 비교](#실습:-rag-vs-non-rag-비교) --- ## 1. RAG의 개념과 필요성 어느 날 최주니어 개발자는 회사에 ChatGPT를 도입하려다가 큰 문제에 부딪혔습니다. "우리 회사 제품 정보를 물어보니까 엉뚱한 답변을 하네요?" 팀장님이 다가와 물었습니다. "RAG는 알아봤어요?" **RAG(Retrieval-Augmented Generation)** 는 LLM이 답변을 생성하기 전에 관련 정보를 먼저 검색해서 참고하도록 만드는 기술입니다. 마치 시험을 볼 때 교과서를 펼쳐놓고 보는 것과 같습니다. LLM의 기억력 한계와 거짓 정보 생성 문제를 해결할 수 있습니다. 다음 코드를 살펴봅시다. ```python # 기본 RAG 개념 시뮬레이션 def simple_rag_concept(user_question): # 1단계: 관련 문서 검색 (Retrieval) relevant_docs = search_knowledge_base(user_question) # 2단계: 검색 결과를 컨텍스트에 추가 (Augmentation) context = f"참고 자료: {relevant_docs}" # 3단계: LLM에게 컨텍스트와 함께 질문 (Generation) prompt = f"{context}\n\n질문: {user_question}" answer = llm.generate(prompt) return answer ``` 최주니어 개발자는 입사 6개월 차 백엔드 개발자입니다. 최근 회사에서 AI 챗봇 프로젝트를 맡게 되었습니다. "ChatGPT API만 연결하면 되겠지"라고 생각했지만, 현실은 달랐습니다. 첫 번째 테스트에서 고객이 물었습니다. "귀사의 프리미엄 요금제 가격이 어떻게 되나요?" ChatGPT는 자신있게 대답했습니다. "월 29,000원입니다." 하지만 실제 가격은 49,000원이었습니다. 이런 현상을 **Hallucination(환각)**이라고 부릅니다. 두 번째 문제도 있었습니다. "작년 12월에 출시한 신제품 기능을 알려주세요." ChatGPT는 답했습니다. "죄송하지만 2023년 4월 이후의 정보는 알지 못합니다." 학습 데이터의 시점 제한 때문이었습니다. 바로 이때 선배 개발자 강시니어 씨가 다가왔습니다. "RAG라는 걸 한번 알아보세요. LLM의 한계를 극복할 수 있어요." 그렇다면 **RAG**란 정확히 무엇일까요? 쉽게 비유하자면, RAG는 마치 오픈북 시험과 같습니다. 학생이 모든 것을 암기하는 대신, 시험장에 교과서를 가져가서 필요한 부분을 찾아보며 답을 작성하는 것입니다. LLM도 마찬가지입니다. 모든 정보를 기억하려 하지 않고, 질문을 받으면 관련 자료를 먼저 찾아본 후 답변합니다. RAG는 세 단계로 작동합니다. 첫 번째는 **Retrieval(검색)** 단계입니다. 사용자의 질문을 분석해서 관련 있는 문서나 정보를 데이터베이스에서 찾아냅니다. 마치 도서관 사서가 책을 찾아주는 것처럼 말이죠. 두 번째는 **Augmentation(보강)** 단계입니다. 검색한 정보를 LLM이 이해할 수 있는 형태로 정리해서 컨텍스트에 추가합니다. "이 정보를 참고해서 답변해줘"라고 알려주는 것입니다. 세 번째는 **Generation(생성)** 단계입니다. LLM이 검색된 정보를 바탕으로 정확한 답변을 생성합니다. 이제 LLM은 근거 있는 답변을 할 수 있습니다. RAG가 없던 시절에는 어땠을까요? 개발자들은 LLM을 회사 데이터와 연결하려면 **파인튜닝(Fine-tuning)** 을 해야 했습니다. 회사의 모든 문서를 LLM에게 재학습시키는 작업이었죠. 문제는 시간과 비용이었습니다. 수천만 원의 비용과 몇 주의 시간이 필요했습니다. 더 큰 문제는 정보가 업데이트될 때마다 다시 학습해야 한다는 점이었습니다. 신제품이 출시되거나 가격이 변경되면? 또다시 파인튜닝을 해야 했습니다. 중소기업에게는 현실적으로 불가능한 일이었습니다. 바로 이런 문제를 해결하기 위해 **RAG**가 등장했습니다. RAG를 사용하면 파인튜닝 없이도 최신 정보를 활용할 수 있습니다. 문서 데이터베이스만 업데이트하면 됩니다. 비용도 획기적으로 줄어듭니다. 파인튜닝 대비 1/100 수준의 비용으로 구현 가능합니다. 무엇보다 **정확성**이라는 큰 이점이 있습니다. LLM이 근거 없이 지어낸 답변을 하는 대신, 실제 문서에 기반한 답변을 합니다. 어떤 문서를 참고했는지 출처도 표시할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 `search_knowledge_base` 함수에서 사용자 질문과 관련된 문서를 찾습니다. 이 부분이 핵심입니다. 다음으로 검색된 문서를 컨텍스트에 포함시킵니다. 마지막으로 LLM에게 "이 정보를 참고해서 답변해줘"라고 요청하면 정확한 답변이 반환됩니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 전자상거래 고객센터 챗봇을 개발한다고 가정해봅시다. 고객이 "반품 정책이 어떻게 되나요?"라고 물으면, RAG 시스템은 먼저 회사의 반품 정책 문서를 검색합니다. 그리고 해당 문서 내용을 바탕으로 정확한 답변을 생성합니다. 네이버, 카카오 등 많은 기업에서 이런 패턴을 적극적으로 사용하고 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 많은 문서를 검색해서 컨텍스트에 넣는 것입니다. 이렇게 하면 LLM이 핵심을 파악하지 못하고 혼란스러워할 수 있습니다. 따라서 가장 관련성 높은 상위 3-5개 문서만 선별해서 사용해야 합니다. 다시 최주니어 개발자의 이야기로 돌아가 봅시다. 강시니어 씨의 설명을 들은 최주니어 씨는 고개를 끄덕였습니다. "아, 그래서 요즘 AI 챗봇들이 정확한 답변을 하는 거군요!" RAG를 제대로 이해하면 더 똑똑하고 신뢰할 수 있는 AI 시스템을 구축할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - RAG는 파인튜닝보다 훨씬 저렴하고 빠르게 구현할 수 있습니다 - 검색 품질이 전체 시스템의 성능을 좌우하므로 검색 로직에 집중하세요 - 출처를 함께 표시하면 사용자 신뢰도가 크게 향상됩니다 --- ## 2. LLM의 한계 극복 박신입 개발자는 회사 블로그에 ChatGPT 리뷰를 쓰다가 당황했습니다. "GPT한테 우리 회사 창립일을 물어봤더니 완전히 틀린 날짜를 알려주네요?" 이것이 바로 LLM의 대표적인 한계였습니다. **LLM의 주요 한계**는 크게 두 가지입니다. 첫째는 **Hallucination(환각)** 으로, 모르는 내용을 그럴듯하게 지어내는 현상입니다. 둘째는 **시점 제한**으로, 학습 데이터 이후의 최신 정보를 알지 못합니다. RAG는 이 두 문제를 외부 지식 검색으로 해결합니다. 다음 코드를 살펴봅시다. ```python # LLM의 한계 vs RAG 해결책 def without_rag(question): # 문제: 학습 데이터에 없으면 지어냄 answer = llm.generate(question) return answer # Hallucination 위험 def with_rag(question): # 해결: 실제 문서에서 정보를 가져옴 docs = vector_db.search(question, top_k=3) context = "\n".join([doc.content for doc in docs]) prompt = f"다음 정보를 바탕으로 답변하세요:\n{context}\n\n질문: {question}" answer = llm.generate(prompt) # 출처도 함께 반환 return {"answer": answer, "sources": [doc.source for doc in docs]} ``` 박신입 개발자는 회사 기술 블로그 담당자입니다. 오늘은 "우리 회사의 AI 도입 사례"라는 글을 작성하기로 했습니다. 먼저 ChatGPT에게 회사 정보를 물어봤습니다. "OOO 회사는 언제 창립되었나요?" ChatGPT가 자신있게 답했습니다. "2015년 3월에 창립되었습니다." 하지만 실제 창립일은 2018년 6월이었습니다. 박신입 씨는 깜짝 놀랐습니다. 더 심각한 문제도 있었습니다. "우리 회사 최신 제품의 주요 기능을 설명해주세요." ChatGPT는 이렇게 답했습니다. "죄송합니다. 해당 회사의 구체적인 제품 정보는 제 학습 데이터에 포함되어 있지 않습니다." CTO 김테크 씨가 박신입 씨의 모니터를 보고 설명했습니다. "이게 바로 LLM의 두 가지 치명적인 한계예요." 첫 번째 한계는 **Hallucination(환각)** 입니다. LLM은 확률 기반으로 다음 단어를 예측하는 모델입니다. 따라서 정확한 정보를 모를 때도 그럴듯한 문장을 생성합니다. 마치 시험 문제를 모를 때 찍는 것과 비슷합니다. 문제는 LLM이 매우 자신있게 거짓 정보를 말한다는 점입니다. 한 연구에 따르면, GPT-3.5는 약 15-20%의 답변에서 사실이 아닌 내용을 포함한다고 합니다. 의료, 법률, 금융처럼 정확성이 중요한 분야에서는 치명적입니다. "환자에게 이 약을 처방하세요"라고 했는데 그게 틀린 정보라면 어떻게 될까요? 두 번째 한계는 **시점 제한**입니다. GPT-4의 학습 데이터는 2023년 4월까지입니다. 그 이후에 일어난 일은 전혀 모릅니다. 작년에 출시된 신제품도, 최근 변경된 법률도, 어제 발표된 기술 스펙도 모릅니다. 빠르게 변하는 IT 업계에서는 큰 문제입니다. 기업 환경에서는 더 심각합니다. 회사 내부 문서, 제품 매뉴얼, 고객 데이터는 애초에 학습 데이터에 포함될 수 없습니다. 보안상 외부로 내보낼 수 없기 때문입니다. 결국 LLM은 회사 정보에 대해 아무것도 모르는 상태입니다. 그렇다면 어떻게 해결할까요? 전통적인 방법은 **파인튜닝**이었습니다. 회사 데이터로 LLM을 재학습시키는 것이죠. 하지만 이 방법은 몇 가지 문제가 있습니다. 첫째, 엄청난 비용이 듭니다. GPT-3.5 파인튜닝에만 수백만 원이 필요합니다. 둘째, 시간이 오래 걸립니다. 데이터 준비부터 학습, 검증까지 수 주가 소요됩니다. 셋째, 업데이트가 어렵습니다. 정보가 바뀔 때마다 재학습해야 합니다. 스타트업이나 중소기업에게는 현실적이지 않은 방법입니다. 바로 이때 **RAG**가 등장합니다. RAG는 근본적으로 다른 접근 방식을 취합니다. LLM에게 정보를 주입하는 대신, 필요할 때마다 정보를 찾아서 보여줍니다. 마치 학생에게 모든 내용을 암기시키는 대신, 도서관 이용법을 가르치는 것과 같습니다. Hallucination 문제는 어떻게 해결될까요? LLM이 더 이상 "모르는 내용을 지어낼" 필요가 없습니다. 검색된 문서에 답이 없으면 "관련 정보를 찾을 수 없습니다"라고 정직하게 답변합니다. 시점 제한 문제는요? 데이터베이스만 최신으로 유지하면 됩니다. 오늘 작성된 문서도, 방금 업데이트된 가격표도 즉시 검색 가능합니다. 재학습 없이 실시간 정보를 제공할 수 있습니다. 위의 코드를 비교해 보겠습니다. `without_rag` 함수는 그냥 LLM에게 질문을 던집니다. LLM은 학습된 지식만으로 답변하려 하고, 모르면 지어냅니다. 반면 `with_rag` 함수는 먼저 벡터 데이터베이스에서 관련 문서를 검색합니다. 그리고 "이 정보를 바탕으로" 답변하라고 명시적으로 지시합니다. 실무에서는 어떤 차이가 있을까요? 한 법률 자문 서비스 스타트업의 사례입니다. 처음에는 일반 ChatGPT API를 사용했습니다. 결과는 참담했습니다. 30%의 법률 조언이 부정확했고, 일부는 폐지된 법령을 인용했습니다. 고객 신뢰도가 급락했습니다. RAG를 도입한 후 정확도가 95%로 향상되었습니다. 시스템은 항상 최신 법령 데이터베이스를 검색한 후 답변했습니다. 어떤 법조문을 참고했는지 출처도 표시했습니다. 고객 만족도가 크게 올랐습니다. 하지만 RAG도 만능은 아닙니다. 검색 품질에 모든 것이 달려 있습니다. 엉뚱한 문서를 검색하면 엉뚱한 답변이 나옵니다. 또한 데이터베이스 구축과 관리에 노력이 필요합니다. 문서를 잘 정리하고, 주기적으로 업데이트해야 합니다. 김테크 CTO는 마지막으로 조언했습니다. "RAG는 LLM의 한계를 극복하는 현실적인 해법이에요. 하지만 검색 시스템 설계가 핵심입니다. 여기에 집중하세요." 박신입 개발자는 이제 RAG의 가치를 이해했습니다. 다음 날부터 회사 문서 데이터베이스 구축을 시작했습니다. **실전 팁** 💡 - Hallucination 방지를 위해 LLM에게 "모르면 모른다고 답하라"고 명시적으로 지시하세요 - 답변과 함께 출처를 표시하면 사용자가 팩트 체크할 수 있습니다 - 검색 품질이 답변 품질을 결정하므로 검색 로직을 최우선으로 개선하세요 --- ## 3. Retrieval → Augmentation → Generation 흐름 이개발 씨는 RAG의 원리를 이해하고 싶었지만 설명이 너무 추상적이었습니다. "검색하고 보강하고 생성한다는데, 구체적으로 뭘 어떻게 한다는 거지?" 팀장 정아키텍트 씨가 화이트보드에 그림을 그리며 설명하기 시작했습니다. RAG의 **3단계 파이프라인**은 정보 검색, 컨텍스트 보강, 답변 생성으로 이루어집니다. **Retrieval**은 벡터 검색으로 관련 문서를 찾고, **Augmentation**은 프롬프트에 문서를 삽입하며, **Generation**은 LLM이 컨텍스트 기반으로 답변을 생성합니다. 다음 코드를 살펴봅시다. ```python from sentence_transformers import SentenceTransformer import numpy as np class RAGPipeline: def __init__(self, documents, llm): self.encoder = SentenceTransformer('all-MiniLM-L6-v2') self.llm = llm # 1. Retrieval 준비: 문서를 벡터로 변환 self.doc_embeddings = self.encoder.encode(documents) self.documents = documents def search(self, query, top_k=3): # 2. Retrieval: 질문을 벡터로 변환 후 유사도 검색 query_embedding = self.encoder.encode([query])[0] similarities = np.dot(self.doc_embeddings, query_embedding) top_indices = np.argsort(similarities)[-top_k:][::-1] return [self.documents[i] for i in top_indices] def generate(self, query): # 3. Augmentation: 검색 결과를 프롬프트에 추가 retrieved_docs = self.search(query) context = "\n\n".join([f"문서 {i+1}: {doc}" for i, doc in enumerate(retrieved_docs)]) prompt = f"""다음 문서들을 참고하여 질문에 답변하세요. {context} 질문: {query} 답변:""" # 4. Generation: LLM이 컨텍스트 기반 답변 생성 answer = self.llm.generate(prompt) return answer ``` 이개발 씨는 3년차 풀스택 개발자입니다. RAG 개념은 이해했지만 실제로 어떻게 작동하는지 감이 잡히지 않았습니다. "검색한다는 건 SQL SELECT 같은 건가요? 보강한다는 건 뭘 보강한다는 거죠?" 팀장 정아키텍트 씨가 화이트보드에 세 개의 박스를 그렸습니다. "RAG는 이 세 단계로 작동해요. 하나씩 설명해 드릴게요." 첫 번째 박스에는 **Retrieval(검색)** 이라고 적혀 있었습니다. "일반적인 데이터베이스 검색과는 좀 달라요." 정팀장이 설명을 시작했습니다. "SQL의 WHERE 절처럼 정확히 일치하는 걸 찾는 게 아니라, **의미적으로 유사한** 문서를 찾는 거예요." 어떻게 의미를 비교할까요? 바로 **벡터 임베딩(Vector Embedding)** 을 사용합니다. 텍스트를 숫자 배열로 변환하는 것입니다. 예를 들어 "강아지"는 [0.2, 0.8, 0.1, ...], "개"는 [0.21, 0.79, 0.12, ...]처럼 변환됩니다. 비슷한 의미를 가진 단어는 비슷한 벡터 값을 갖습니다. "강아지"와 "개"의 벡터는 매우 가깝고, "강아지"와 "비행기"의 벡터는 멉니다. 이 원리로 문서의 유사도를 계산할 수 있습니다. 사용자가 "반품 정책이 뭔가요?"라고 물으면, 이 질문도 벡터로 변환됩니다. 그리고 데이터베이스에 저장된 모든 문서 벡터와 비교합니다. 가장 유사한 상위 3-5개 문서를 선택합니다. 이것이 **Retrieval** 단계입니다. 두 번째 박스에는 **Augmentation(보강)** 이라고 적혀 있었습니다. "검색한 문서를 그냥 LLM에게 던지는 게 아니에요." 정팀장이 계속 설명했습니다. "프롬프트에 체계적으로 삽입해야 해요." 예를 들어봅시다. 검색 결과로 세 개의 문서를 찾았다고 가정합니다. 이제 이 문서들을 LLM이 이해할 수 있는 형태로 정리합니다. "다음 정보를 참고하세요"라는 지시와 함께 문서 내용을 프롬프트 앞부분에 추가합니다. 여기서 중요한 점이 있습니다. 단순히 문서를 나열하는 게 아니라, **구조화**해야 합니다. "문서 1: [내용]", "문서 2: [내용]" 형식으로 명확하게 구분합니다. 출처 정보도 함께 포함합니다. 프롬프트 끝부분에는 사용자의 원래 질문을 추가합니다. "위 정보를 바탕으로 다음 질문에 답변하세요: [질문]" 이렇게 하면 LLM이 컨텍스트를 고려해서 답변할 수 있습니다. 이것이 **Augmentation** 단계입니다. 세 번째 박스에는 **Generation(생성)** 이라고 적혀 있었습니다. "이제 준비가 끝났어요." 정팀장이 미소를 지었습니다. "보강된 프롬프트를 LLM에게 보내면 됩니다." LLM은 이제 풍부한 컨텍스트를 가지고 있습니다. 사용자 질문과 관련된 구체적인 정보가 프롬프트에 포함되어 있습니다. 더 이상 기억에만 의존하지 않습니다. 눈앞에 참고 자료가 있는 것과 같습니다. LLM은 제공된 문서를 분석하고, 질문과 관련된 부분을 추출하고, 자연스러운 문장으로 재구성합니다. "귀사의 반품 정책은 구매일로부터 14일 이내 가능하며, 제품 포장이 훼손되지 않아야 합니다." 이런 식으로 정확한 답변이 생성됩니다. 위의 코드를 자세히 살펴봅시다. `__init__` 메서드에서는 문서들을 미리 벡터로 변환해 둡니다. 이것을 **인덱싱**이라고 합니다. 매번 변환하면 느리기 때문에 초기화 시점에 한 번만 수행합니다. `search` 메서드가 **Retrieval** 을 담당합니다. 사용자 질문을 벡터로 변환하고, 코사인 유사도로 가장 비슷한 문서를 찾습니다. `np.argsort`로 유사도가 높은 순서대로 정렬하고, 상위 K개를 선택합니다. `generate` 메서드가 **Augmentation과 Generation**을 모두 처리합니다. 검색된 문서를 프롬프트에 체계적으로 배치하고, LLM에게 전달합니다. 실무에서는 더 정교한 기법들이 사용됩니다. **Re-ranking**이라는 기법이 있습니다. 초기 검색에서 10개 문서를 찾은 후, 더 정밀한 모델로 재평가해서 최종 3개를 선택하는 것입니다. 정확도가 크게 향상됩니다. **Hybrid Search**도 있습니다. 벡터 검색과 키워드 검색을 결합하는 방법입니다. "2023년 12월 보고서"처럼 날짜나 고유명사가 중요한 경우, 키워드 검색이 더 정확합니다. 두 방식의 결과를 합쳐서 사용합니다. **Chunk Size**도 중요합니다. 문서를 얼마나 작은 단위로 나눌 것인가의 문제입니다. 너무 크면 관련 없는 내용이 많이 포함되고, 너무 작으면 맥락을 잃습니다. 보통 500-1000 토큰 단위로 나눕니다. 한 e-커머스 회사의 사례를 보겠습니다. 처음에는 단순한 키워드 검색을 사용했습니다. "배송 얼마나 걸려요?"라는 질문에 "배송"이라는 키워드가 들어간 모든 문서를 찾았습니다. 결과는 엉망이었습니다. 배송 정책, 배송 추적, 반품 시 반송 배송 등 관련 없는 내용이 섞여 나왔습니다. 벡터 검색을 도입한 후 정확도가 30%에서 85%로 향상되었습니다. "배송 얼마나 걸려요?"는 "배송 기간", "소요 시간" 같은 의미적으로 유사한 문서를 찾았습니다. 사용자가 만족하는 답변이 나왔습니다. 하지만 초보자들이 자주 하는 실수가 있습니다. 너무 많은 문서를 프롬프트에 넣는 것입니다. "많을수록 좋겠지"라고 생각해서 20-30개 문서를 넣으면, LLM이 오히려 핵심을 놓칩니다. 보통 3-5개가 적당합니다. 출처 정보를 무시하는 것도 문제입니다. 어떤 문서를 참고했는지 기록해두지 않으면, 나중에 검증할 방법이 없습니다. 항상 문서 ID나 페이지 번호를 함께 저장하세요. 정아키텍트 팀장이 마무리했습니다. "이 세 단계가 유기적으로 연결되어야 좋은 RAG 시스템이 만들어져요. 어느 하나라도 부실하면 전체 품질이 떨어집니다." 이개발 씨는 이제 RAG의 작동 원리를 명확하게 이해했습니다. 다음 날부터 실제 구현을 시작할 준비가 되었습니다. **실전 팁** 💡 - 벡터 데이터베이스는 Pinecone, Weaviate, ChromaDB 등을 활용하세요 - 검색 결과는 3-5개가 적당하며, 너무 많으면 오히려 성능이 떨어집니다 - 프롬프트에 "제공된 정보에 없으면 모른다고 답하라"는 지시를 추가하세요 --- ## 4. RAG vs Fine-tuning 신스타트업 CTO 한고민 씨는 선택의 기로에 섰습니다. "RAG로 갈까요, 파인튜닝으로 갈까요?" 투자자 미팅에서 "ChatGPT를 우리 제품에 맞게 커스터마이징"하겠다고 했는데, 방법이 두 가지였습니다. 자문을 구하러 AI 전문가 조박사를 찾아갔습니다. **RAG**는 외부 지식 검색으로 LLM을 보강하는 방식이고, **Fine-tuning**은 LLM 자체를 재학습시키는 방식입니다. RAG는 빠르고 저렴하며 업데이트가 쉽지만, Fine-tuning은 모델의 행동 패턴 자체를 바꿀 수 있습니다. 대부분의 경우 RAG가 더 실용적입니다. 다음 코드를 살펴봅시다. ```python # RAG 방식: 검색 + 생성 class RAGApproach: def __init__(self, knowledge_base, llm): self.kb = knowledge_base # 문서 DB (언제든 업데이트 가능) self.llm = llm # 기본 LLM (변경 없음) def answer(self, question): docs = self.kb.search(question) context = "\n".join(docs) prompt = f"참고: {context}\n질문: {question}" return self.llm.generate(prompt) def update_knowledge(self, new_docs): # 즉시 업데이트 가능 (재학습 불필요) self.kb.add_documents(new_docs) # Fine-tuning 방식: 모델 재학습 class FineTuningApproach: def __init__(self, base_model): self.model = base_model def train(self, training_data): # 수천 개의 예제로 재학습 (시간과 비용 소요) # 몇 시간~며칠 소요 self.model.fine_tune(training_data, epochs=3) def answer(self, question): # 학습된 지식으로 바로 답변 return self.model.generate(question) def update_knowledge(self, new_data): # 전체 재학습 필요 (시간과 비용 재소요) self.train(new_data) ``` 한고민 CTO는 시리즈 A 투자를 막 유치한 스타트업의 기술 책임자입니다. 투자자들 앞에서 "AI 기반 고객 상담 서비스"를 만들겠다고 발표했습니다. 문제는 구체적인 방법이었습니다. "ChatGPT API를 그냥 쓰면 우리 회사 제품을 모르잖아요." 한고민 CTO는 고민에 빠졌습니다. 구글링을 해보니 두 가지 방법이 나왔습니다. **RAG**와 **Fine-tuning**. 어떤 게 나을까요? AI 자문 조박사를 찾아갔습니다. "둘 다 LLM을 회사 데이터와 연결하는 방법이에요. 하지만 접근 방식이 완전히 다릅니다." **Fine-tuning**부터 살펴봅시다. Fine-tuning은 마치 학생을 재교육하는 것과 같습니다. 기본 교육을 받은 학생에게 특수 분야를 집중적으로 가르치는 것이죠. LLM도 마찬가지입니다. GPT-3.5 같은 기본 모델을 가져와서, 회사 데이터로 추가 학습시킵니다. 수천 개의 질문-답변 쌍을 준비합니다. "Q: 프리미엄 요금제 가격은? A: 월 49,000원입니다." 이런 식으로 회사 관련 지식을 학습시킵니다. 모델의 가중치가 업데이트되면서, 회사 정보를 "기억"하게 됩니다. 장점은 명확합니다. 답변 속도가 빠릅니다. 매번 검색할 필요 없이 바로 답변합니다. 또한 특정한 말투나 스타일을 학습시킬 수 있습니다. "친근한 캐주얼 톤" 같은 페르소나를 주입할 수 있습니다. 하지만 문제가 많습니다. 첫째, **비용**입니다. OpenAI GPT-3.5 Fine-tuning은 학습 데이터 1만 토큰당 약 8달러입니다. 중간 규모 데이터셋이면 수백만 원이 들 수 있습니다. 스타트업에게는 부담스러운 금액입니다. 둘째, **시간**입니다. 데이터 준비에 며칠, 학습에 몇 시간에서 며칠이 걸립니다. 급하게 서비스를 론칭해야 하는데 일주일씩 기다릴 수 없습니다. 셋째, **업데이트 문제**입니다. 신제품이 나왔다면? 가격이 바뀌었다면? 전체를 다시 학습해야 합니다. 매번 비용과 시간이 다시 듭니다. 변화가 빠른 비즈니스에는 맞지 않습니다. 넷째, **데이터 양**입니다. 효과적인 Fine-tuning에는 보통 수천 개 이상의 고품질 예제가 필요합니다. 데이터가 부족한 초기 스타트업에는 어렵습니다. 이제 **RAG**를 봅시다. RAG는 학생을 재교육하는 대신, 시험장에 참고서를 가져가게 하는 것과 같습니다. LLM 자체는 바꾸지 않습니다. 대신 필요할 때마다 정보를 검색해서 제공합니다. 문서 데이터베이스를 구축합니다. 회사 매뉴얼, 제품 설명서, FAQ 등을 벡터 DB에 저장합니다. 질문이 들어오면 관련 문서를 찾아서 프롬프트에 추가합니다. LLM은 그 정보를 바탕으로 답변합니다. 장점이 압도적입니다. 첫째, **비용**이 저렴합니다. 벡터 DB 구축 비용은 파인튜닝의 1/10 수준입니다. ChromaDB 같은 오픈소스를 쓰면 거의 무료입니다. 둘째, **구축 속도**가 빠릅니다. 문서만 준비되면 하루 만에 시스템을 구축할 수 있습니다. 벡터 변환은 자동으로 됩니다. 셋째, **업데이트**가 즉각적입니다. 새 문서를 DB에 추가하면 끝입니다. 재학습 없이 바로 반영됩니다. 실시간으로 변하는 정보도 문제없습니다. 넷째, **투명성**이 있습니다. 어떤 문서를 참고해서 답변했는지 출처를 표시할 수 있습니다. 사용자가 직접 확인할 수 있어 신뢰도가 높습니다. 다섯째, **데이터 양**이 적어도 됩니다. 문서만 있으면 됩니다. 수천 개의 Q&A 쌍을 만들 필요가 없습니다. "그럼 RAG가 항상 좋은 건가요?" 한고민 CTO가 물었습니다. 조박사가 고개를 저었습니다. "특정 상황에서는 Fine-tuning이 필요해요." Fine-tuning이 적합한 경우는 다음과 같습니다. **특정 스타일이나 포맷**이 중요할 때입니다. 예를 들어 의료 보고서를 특정 형식으로 작성해야 한다면, Fine-tuning이 더 일관된 결과를 냅니다. RAG는 매번 검색 결과에 따라 스타일이 조금씩 달라질 수 있습니다. **검색이 어려운 지식**일 때도 유용합니다. 복잡한 수학 공식이나 프로그래밍 패턴처럼 "암묵적 지식"은 문서화하기 어렵습니다. 이런 건 예제로 학습시키는 게 낫습니다. **응답 속도가 극도로 중요**할 때도 고려할 수 있습니다. RAG는 검색 단계가 추가되므로 0.5-1초 정도 느립니다. 실시간 채팅에서는 체감될 수 있습니다. 하지만 대부분의 비즈니스 사례에서는 **RAG가 압도적으로 유리**합니다. 위의 코드를 비교해 보세요. `RAGApproach`는 `update_knowledge` 메서드가 매우 간단합니다. 그냥 문서를 추가하면 끝입니다. 반면 `FineTuningApproach`는 업데이트할 때마다 전체 재학습을 해야 합니다. 실제 기업 사례를 보겠습니다. 한 중견 보험사는 처음에 Fine-tuning을 시도했습니다. 보험 상품 Q&A 5,000개로 GPT-3.5를 학습시켰습니다. 비용은 300만 원, 시간은 2주였습니다. 결과는 괜찮았습니다. 문제는 3개월 후 발생했습니다. 신상품 5개가 출시되고, 약관이 일부 변경되었습니다. 다시 학습해야 했습니다. 또 300만 원, 또 2주. 연간 유지보수 비용이 2,000만 원을 넘어섰습니다. 결국 RAG로 전환했습니다. 초기 구축에 1주일, 비용은 50만 원이었습니다. 신상품 출시? 문서만 업데이트하면 즉시 반영됩니다. 추가 비용 없습니다. 연간 유지비가 1/20로 줄었습니다. 조박사가 조언했습니다. "대부분의 경우 RAG로 시작하세요. 정말 필요하다는 확신이 들 때만 Fine-tuning을 고려하세요." 한고민 CTO는 결정을 내렸습니다. "RAG로 가겠습니다. 빠르게 MVP를 만들고, 피드백을 받으면서 개선하는 게 스타트업 방식에 맞네요." **실전 팁** 💡 - 90% 이상의 케이스에서 RAG가 더 실용적입니다 - Fine-tuning은 스타일/톤을 바꾸거나 특수한 포맷이 필요할 때만 고려하세요 - RAG와 Fine-tuning을 함께 쓸 수도 있습니다 (Fine-tuned 모델 + RAG) --- ## 5. 실습: 간단한 RAG 시스템 구축 드디어 실습 시간입니다. 오백엔드 개발자는 회사 제품 매뉴얼로 RAG 챗봇을 만들기로 했습니다. "이론은 알겠는데, 실제로 어떻게 코드를 짜야 하지?" Python을 켜고, 필요한 라이브러리부터 찾아보기 시작했습니다. **간단한 RAG 시스템**은 ChromaDB(벡터 DB), Sentence-Transformers(임베딩), OpenAI API(LLM) 세 가지만 있으면 구축할 수 있습니다. 문서를 임베딩해서 저장하고, 질문과 유사한 문서를 검색한 뒤, LLM에게 컨텍스트와 함께 전달하면 됩니다. 다음 코드를 살펴봅시다. ```python import chromadb from sentence_transformers import SentenceTransformer import openai # 1. 벡터 DB 초기화 client = chromadb.Client() collection = client.create_collection("product_docs") # 2. 임베딩 모델 준비 encoder = SentenceTransformer('all-MiniLM-L6-v2') # 3. 문서 추가 함수 def add_documents(docs): embeddings = encoder.encode(docs) collection.add( embeddings=embeddings.tolist(), documents=docs, ids=[f"doc_{i}" for i in range(len(docs))] ) # 4. RAG 질의 함수 def rag_query(question, top_k=3): # 질문을 임베딩 q_embedding = encoder.encode([question])[0] # 유사 문서 검색 results = collection.query( query_embeddings=[q_embedding.tolist()], n_results=top_k ) # 컨텍스트 구성 context = "\n\n".join(results['documents'][0]) # LLM에 질의 response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=[ {"role": "system", "content": "다음 문서를 참고하여 답변하세요:\n" + context}, {"role": "user", "content": question} ] ) return response.choices[0].message.content # 5. 사용 예시 docs = [ "프리미엄 요금제는 월 49,000원이며 무제한 API 호출을 제공합니다.", "환불 정책: 구매 후 14일 이내 전액 환불 가능합니다.", "고객센터 운영시간은 평일 09:00-18:00입니다." ] add_documents(docs) answer = rag_query("요금제 가격이 얼마인가요?") print(answer) ``` 오백엔드 개발자는 3년차 파이썬 개발자입니다. 이론 공부는 끝났고, 이제 직접 만들어볼 시간입니다. "일단 가장 간단한 버전부터 만들어보자." 먼저 필요한 것들을 정리했습니다. **벡터 데이터베이스**가 필요합니다. 문서를 벡터로 변환해서 저장하고, 유사도 검색을 지원해야 합니다. 오백엔드 씨는 **ChromaDB**를 선택했습니다. 오픈소스이고, 설치가 간단하며, 초보자도 사용하기 쉽기 때문입니다. **임베딩 모델**도 필요합니다. 텍스트를 벡터로 변환하는 모델이죠. **Sentence-Transformers** 라이브러리의 `all-MiniLM-L6-v2` 모델을 선택했습니다. 가볍고 빠르며, 품질도 괜찮습니다. 마지막으로 **LLM API**가 필요합니다. OpenAI의 GPT-3.5-turbo를 사용하기로 했습니다. 가장 대중적이고, 문서도 잘 되어 있습니다. 라이브러리를 설치합니다. 터미널에 명령어를 입력합니다. `pip install chromadb sentence-transformers openai` 몇 분 안에 설치가 완료됩니다. 생각보다 간단합니다. 이제 코드를 작성합니다. 먼저 ChromaDB 클라이언트를 초기화합니다. `client = chromadb.Client()` 이것은 인메모리 DB를 생성합니다. 개발용으로는 충분합니다. 프로덕션에서는 영구 저장소를 사용해야 합니다. 컬렉션을 만듭니다. `collection = client.create_collection("product_docs")` 컬렉션은 RDB의 테이블과 비슷한 개념입니다. 여기에 문서들을 저장할 것입니다. 임베딩 모델을 로드합니다. `encoder = SentenceTransformer('all-MiniLM-L6-v2')` 처음 실행하면 모델을 다운로드합니다. 약 80MB 정도입니다. 문서 추가 함수를 만듭니다. `add_documents` 함수는 문서 리스트를 받아서 벡터 DB에 저장합니다. `encoder.encode(docs)`로 문서를 벡터로 변환합니다. 이 벡터가 **의미적 표현**입니다. `collection.add()`로 컬렉션에 추가합니다. 임베딩뿐만 아니라 원본 텍스트도 함께 저장합니다. 나중에 검색 결과로 원본 텍스트를 가져오기 위해서입니다. 각 문서에 고유 ID도 부여합니다. 이제 핵심인 RAG 질의 함수를 만듭니다. `rag_query` 함수는 사용자 질문을 받아서 답변을 반환합니다. 먼저 질문을 임베딩합니다. `encoder.encode([question])[0]` 질문도 문서와 같은 벡터 공간에 매핑됩니다. `collection.query()`로 유사한 문서를 검색합니다. `n_results=top_k`로 상위 K개만 가져옵니다. 보통 3-5개가 적당합니다. ChromaDB는 내부적으로 코사인 유사도를 계산해서 가장 비슷한 문서를 찾아줍니다. 검색된 문서들을 하나의 컨텍스트로 합칩니다. `"\n\n".join()`으로 문서들을 줄바꿈으로 연결합니다. 이렇게 하면 LLM이 여러 문서를 구분할 수 있습니다. OpenAI API를 호출합니다. System 메시지에 컨텍스트를 넣고, User 메시지에 질문을 넣습니다. "다음 문서를 참고하여 답변하세요"라고 명시적으로 지시합니다. 실제로 사용해 봅시다. 샘플 문서 세 개를 준비합니다. 요금제 정보, 환불 정책, 고객센터 운영시간 같은 실무적인 내용입니다. `add_documents(docs)`로 벡터 DB에 저장합니다. "요금제 가격이 얼마인가요?"라고 질문합니다. RAG 시스템이 작동합니다. 질문을 벡터로 변환하고, 유사한 문서를 찾고, LLM이 답변을 생성합니다. "프리미엄 요금제는 월 49,000원입니다." 정확한 답변이 나옵니다! 오백엔드 씨는 감탄했습니다. "생각보다 간단하네요. 50줄도 안 되는 코드로 RAG 시스템이 만들어졌어요!" 하지만 실무에서는 더 고려해야 할 것들이 있습니다. **청킹(Chunking)** 전략이 필요합니다. 긴 문서는 적절한 크기로 나눠야 합니다. 한 문서가 너무 길면 임베딩의 품질이 떨어집니다. 보통 500-1000 토큰 단위로 나눕니다. **메타데이터**도 저장해야 합니다. 문서 출처, 작성일, 카테고리 같은 정보를 함께 저장하면 필터링이 가능합니다. "2024년 이후 문서만 검색" 같은 조건을 걸 수 있습니다. **프롬프트 엔지니어링**도 중요합니다. "제공된 정보에 없으면 '모르겠습니다'라고 답하세요" 같은 지시를 추가하면 Hallucination을 줄일 수 있습니다. **에러 핸들링**도 빠지면 안 됩니다. 검색 결과가 없을 때, API 호출이 실패할 때 등의 상황을 처리해야 합니다. 선배 개발자 김시니어가 오백엔드 씨의 화면을 봤습니다. "오, 벌써 작동하네요! 이제 실제 문서를 넣어보고, 성능을 테스트해 보세요. 처음 만든 버전은 보통 정확도가 70% 정도 나와요. 거기서부터 개선하는 게 진짜 시작입니다." 오백엔드 씨는 노트북에 TODO를 적었습니다. "1. 실제 매뉴얼 PDF를 텍스트로 변환하기, 2. 청킹 전략 구현하기, 3. 정확도 측정 시스템 만들기." 할 일이 많지만, 첫 걸음을 떼었다는 게 뿌듯했습니다. **실전 팁** 💡 - 로컬 테스트에는 인메모리 ChromaDB로 충분하지만, 프로덕션에서는 영구 저장소를 사용하세요 - 임베딩 모델은 다국어 지원이 필요하면 'paraphrase-multilingual-MiniLM-L12-v2'를 사용하세요 - OpenAI API 키는 환경변수로 관리하고, 절대 코드에 하드코딩하지 마세요 --- ## 6. 실습: RAG vs Non-RAG 비교 마지막 실습입니다. 유데이터 분석가는 "RAG가 정말 효과 있을까?"라는 의심을 품었습니다. "직접 비교해보지 않고는 못 믿겠어." 같은 질문을 RAG 시스템과 일반 LLM에 각각 던져보기로 했습니다. 결과는 놀라웠습니다. **RAG와 Non-RAG 비교 실험**은 같은 질문에 대한 답변 품질을 측정하는 것입니다. Non-RAG는 LLM의 내부 지식만으로 답변하므로 Hallucination과 정보 부족이 발생하고, RAG는 실제 문서 기반으로 정확한 답변을 제공합니다. 정확도 차이가 보통 2-3배 이상 납니다. 다음 코드를 살펴봅시다. ```python import openai # 실험용 회사 문서 company_docs = """ [회사명] 테크이노베이션 [설립일] 2021년 3월 15일 [주력 제품] AI 챗봇 플랫폼 'ChatGenius' [요금제] - 스타터: 월 29,000원 (월 1만 호출) - 프로: 월 49,000원 (월 10만 호출) - 엔터프라이즈: 월 199,000원 (무제한) [최근 업데이트] 2024년 2월 - 한국어 감성분석 기능 추가 """ # 1. Non-RAG: 순수 LLM만 사용 def non_rag_answer(question): response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=[ {"role": "user", "content": question} ] ) return response.choices[0].message.content # 2. RAG: 문서 컨텍스트 포함 def rag_answer(question, context): response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=[ {"role": "system", "content": f"다음 정보를 참고하여 답변하세요. 정보에 없는 내용은 '제공된 정보에 없습니다'라고 답하세요:\n\n{context}"}, {"role": "user", "content": question} ] ) return response.choices[0].message.content # 3. 비교 실험 test_questions = [ "테크이노베이션은 언제 설립되었나요?", "프로 요금제 가격은 얼마인가요?", "최근에 추가된 기능은 무엇인가요?" ] print("=" * 50) for q in test_questions: print(f"\n질문: {q}") print(f"\n[Non-RAG 답변]") print(non_rag_answer(q)) print(f"\n[RAG 답변]") print(rag_answer(q, company_docs)) print("=" * 50) ``` 유데이터 분석가는 5년차 데이터 사이언티스트입니다. "A/B 테스트 없이는 아무것도 믿지 않는다"가 그의 모토입니다. RAG 도입을 검토하면서도 "정말 효과가 있을까?"라는 의심을 버릴 수 없었습니다. "직접 실험해보자." 유데이터 씨는 비교 실험을 설계했습니다. 실험 설계는 간단합니다. 가상의 회사 정보를 만들고, 그에 대한 질문을 준비합니다. 같은 질문을 두 시스템에 각각 던지고, 답변을 비교합니다. 어느 쪽이 더 정확한지 확인하는 것입니다. 먼저 회사 문서를 작성했습니다. "테크이노베이션"이라는 가상의 회사를 만들었습니다. 설립일은 2021년 3월 15일, 주력 제품은 AI 챗봇 플랫폼, 요금제는 세 가지로 구성됩니다. 최근 업데이트로 한국어 감성분석 기능을 추가했다는 설정입니다. 이 정보는 **LLM의 학습 데이터에 절대 없습니다**. 지금 막 만든 가상의 정보이기 때문입니다. 따라서 Non-RAG 시스템은 답을 알 수가 없습니다. 질문 세 개를 준비했습니다. "테크이노베이션은 언제 설립되었나요?" - 구체적인 날짜를 묻는 질문입니다. "프로 요금제 가격은 얼마인가요?" - 정확한 숫자를 요구합니다. "최근에 추가된 기능은 무엇인가요?" - 최신 정보를 묻습니다. 첫 번째 시스템은 **Non-RAG**입니다. 그냥 OpenAI API를 호출합니다. 어떤 컨텍스트도 제공하지 않습니다. LLM은 자신의 학습된 지식만으로 답변해야 합니다. 하지만 테크이노베이션은 실제로 존재하지 않는 회사입니다. 실험을 돌려봤습니다. 질문: "테크이노베이션은 언제 설립되었나요?" Non-RAG 답변: "죄송하지만 테크이노베이션이라는 회사에 대한 정보가 제 학습 데이터에 없습니다." 좋습니다. 정직하게 모른다고 답했습니다. 하지만 실무에서는 이게 문제입니다. 고객이 우리 회사에 대해 물었는데 "모른다"고 하면 어떻게 될까요? 때로는 더 나쁜 일이 일어납니다. 질문: "프로 요금제 가격은 얼마인가요?" Non-RAG 답변: "일반적으로 프로 요금제는 월 $99 정도입니다만, 정확한 가격은 공식 웹사이트를 확인해주세요." 이것이 **Hallucination**입니다. LLM이 "일반적인" 가격을 추측해서 답했습니다. 문제는 실제 가격(49,000원)과 전혀 다르다는 점입니다. 잘못된 정보를 자신있게 말하는 것이 가장 위험합니다. 이제 두 번째 시스템, **RAG**를 실행합니다. 같은 질문을 하지만, 이번에는 회사 문서를 컨텍스트로 제공합니다. System 메시지에 "다음 정보를 참고하여 답변하세요"라고 명시합니다. 회사 문서 전체를 포함시킵니다. 결과는 확연히 달랐습니다. 질문: "테크이노베이션은 언제 설립되었나요?" RAG 답변: "테크이노베이션은 2021년 3월 15일에 설립되었습니다." 정확합니다! 문서에 있는 그대로 답변했습니다. 질문: "프로 요금제 가격은 얼마인가요?" RAG 답변: "프로 요금제는 월 49,000원이며, 월 10만 호출까지 사용 가능합니다." 이것도 완벽합니다. 가격뿐만 아니라 호출 제한까지 정확히 답변했습니다. 질문: "최근에 추가된 기능은 무엇인가요?" RAG 답변: "2024년 2월에 한국어 감성분석 기능이 추가되었습니다." Non-RAG는 이 질문에 답할 방법이 없었습니다. 학습 데이터 이후의 정보이기 때문입니다. 하지만 RAG는 문서에서 정보를 찾아서 정확히 답변했습니다. 유데이터 씨는 결과를 정리했습니다. **정확도**: Non-RAG 0%, RAG 100%. 세 질문 모두 RAG만 정확히 답변했습니다. **Hallucination**: Non-RAG는 한 번 발생, RAG는 없음. 프롬프트에 "정보에 없으면 모른다고 답하라"는 지시가 있었기 때문입니다. **최신 정보**: Non-RAG는 불가능, RAG는 즉시 반영. 문서만 업데이트하면 됩니다. 실제 기업 데이터로도 테스트해봤습니다. 한 고객사의 FAQ 100개를 사용했습니다. Non-RAG는 정확도 23%였습니다. 대부분 "모른다"고 답하거나, 일반적인 답변으로 회피했습니다. 일부는 잘못된 정보를 제공했습니다. RAG는 정확도 87%였습니다. 대부분의 질문에 정확히 답변했습니다. 13%의 오류는 주로 검색 실패 때문이었습니다. 질문이 애매하거나, 관련 문서가 정말 없는 경우였습니다. 더 흥미로운 발견도 있었습니다. **출처 표시**: RAG 시스템에 어떤 문서를 참고했는지 표시하도록 수정했습니다. 사용자들이 답변을 훨씬 더 신뢰했습니다. "이 정보는 '제품 매뉴얼 3.2절'에서 가져왔습니다" 같은 출처가 있으니까요. **업데이트 속도**: 신제품 정보를 추가하는 테스트를 했습니다. Non-RAG는 재학습이 필요하므로 불가능했습니다. RAG는 문서를 DB에 추가하는 데 5초, 즉시 검색 가능했습니다. **비용**: 100개 질문 처리 비용을 계산했습니다. Non-RAG는 API 호출 비용만 약 $0.5였습니다. RAG는 임베딩 비용 + API 비용으로 약 $0.8였습니다. 60% 더 비싸지만, 정확도가 4배 높으니 충분히 가치 있습니다. 하지만 RAG의 한계도 발견했습니다. **검색 실패**: 질문이 너무 애매하면 관련 문서를 못 찾습니다. "저거 얼마예요?"처럼 지시대명사가 있으면 어려워합니다. 대화 컨텍스트를 유지하는 로직이 추가로 필요합니다. **속도**: Non-RAG는 평균 응답 시간 0.8초, RAG는 1.3초였습니다. 검색 단계가 추가되면서 0.5초 느려졌습니다. 대부분의 경우 큰 문제는 아니지만, 실시간 채팅에서는 체감될 수 있습니다. 유데이터 씨는 보고서를 작성했습니다. "RAG 도입을 강력히 권장합니다. 정확도 향상이 비용 증가를 압도합니다. 특히 회사 고유 정보에 대한 질문에서 Non-RAG는 사실상 사용 불가능합니다." CTO가 보고서를 읽고 승인했습니다. "좋습니다. 다음 스프린트에 RAG 시스템 구축을 포함시키세요." 유데이터 씨는 만족스러웠습니다. 데이터로 증명했으니까요. **실전 팁** 💡 - A/B 테스트를 할 때는 실제 사용자 질문 로그를 활용하세요 - 정확도뿐만 아니라 응답 시간, 비용도 함께 측정하세요 - "모른다"고 정직하게 답하는 것도 좋은 답변입니다 - Hallucination보다 훨씬 낫습니다 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: RAG,LLM,기초

언어: Python

태그: Python, RAG, LLM, VectorDB, Embeddings, RAG,LLM,기초

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

RAG 완벽 가이드 - LLM의 한계를 극복하는 지능형 검색 시스템

목차

1. RAG의 개념과 필요성

2. LLM의 한계 극복

3. Retrieval → Augmentation → Generation 흐름

4. RAG vs Fine-tuning

5. 실습: 간단한 RAG 시스템 구축

6. 실습: RAG vs Non-RAG 비교

댓글 (0)

함께 보면 좋은 카드 뉴스

ReAct 패턴 마스터 완벽 가이드

AI 에이전트의 모든 것 - 개념부터 실습까지

프로덕션 RAG 시스템 완벽 가이드

RAG 캐싱 전략 완벽 가이드

실시간으로 답변하는 RAG 시스템 만들기