RAG란?
RAG(Retrieval-Augmented Generation)는 LLM의 단점 중 ‘사실 관계 오류 가능성’과 ‘맥락 이해의 한계’ 를 개선하는데 초점을 맞춘 방법
RAG는 LLM에 외부 지식 베이시를 연결하여 모델의 생성 능력과 사실 관계 파악 능력을 향상시키는 기술
사용 방식
- 외부 지식 활용
- 대규모의 구조화된 지식 베이스(예: DB, 위키피디아)를 모델에 연결
- 주어진 질의에 대한 관련 정보를 지식 베이스에 검색 및 추출
- 증거 기반 생성
- 검색된 지식 정보를 증거로 활용하여 보다 사실에 기반한 답변 생성
- 생성된 답변의 출처를 명시함으로써 신뢰성 향상
- 맥락 이해력 향상
- 외부 지식을 통해 질의에 대한 배경 지식과 맥락 정보를 파악
- 단순한 패턴 매칭이 아닌 추론 능력을 바탕으로 한 답변 생성
즉, RAG는 기존 LLM의 생성 능력과 외부 지식 베이스의 정보를 결합함으로써, 보다 정확하고 사실에 기반한 답변을 제공할 수 있음. 또한 모델의 출력결과에 대한 증거를 제시할 수 있어 설명 가능성과 신뢰성을 높일 수 있음
구성 요소
- 질의 인코더(Query Encoder): 사용자가 질문을 이해가 위한 언어 모델. 주어진 질문을 벡터 형태로 인코더
- 지식 검색기(Knowledge Retriever): 인코딩된 질문을 바탕으로 외부 지식 베이스에서 관련 정보를 검색
- 지식 증강 생성기 (Knowledge-Augmented Generator): 검색된 지식을 활용하여 질문에 대한 답변을 생성하는 언어 모델. 기존의 LLM과 유사하지만, 검색된 지식을 추가 입력으로 받아 보다 정확하고 풍부한 답변 생성
RAG의 동작 과정 요약
- 사용자의 질문이 주어지면 질의 인코더가 이를 이해하기 쉬운 형태로 변환
- 지식 검색기가 인코딩된 질문을 바탕으로 외부 지식 베이스에서 정보를 검색
- 검색된 지식은 지식 증강 생성기의 입력으로 전달
- 지식 증강 생성기는 지식을 활용하여 사용자 질문에 대한 답변 생성
RAG의 등장 배경과 필요성
RAG는 자연어 처리와 인공지능 기술의 발전, 그리고 증가하는 사용자의 요구에 따라 등장하게 되었습니다. RAG의 등장 배경과 필요성을 다음과 같이 정리할 수 있습니다.
- 지식 기반 질의응답 시스템의 한계
- 초기의 질의응답 시스템은 주로 제한된 도메인의 구조화된 데이터를 기반으로 동작했습니다. 이는 시스템이 다룰 수 있는 주제와 질문의 유형이 한정적이라는 문제가 있었습니다.
- 사용자의 다양한 정보 요구를 충족시키기 위해서는 보다 광범위한 지식을 활용할 수 있는 시스템이 필요하게 되었습니다.
- 비정형 텍스트 데이터의 폭발적 증가
- 인터넷의 발달과 디지털 기기의 보급으로 웹페이지, 뉴스 기사, 소셜 미디어 게시물 등 비정형 텍스트 데이터가 기하급수적으로 증가하고 있습니다.
- 이러한 대규모 텍스트 데이터는 방대한 지식을 포함하고 있어, 질의응답 시스템의 지식 베이스로 활용할 수 있는 잠재력이 높습니다.
- 그러나 비정형 데이터를 효과적으로 처리하고 활용하기 위해서는 기존과는 다른 접근 방식이 필요했습니다.
- 사전 학습된 언어 모델의 발전
- BERT, GPT 등 사전 학습된 대규모 언어 모델의 등장은 자연어 처리 분야에 큰 변화를 가져왔습니다.
- 이러한 언어 모델은 방대한 텍스트 데이터로부터 언어의 구조와 의미를 학습하여, 다양한 언어 이해 및 생성 태스크에서 뛰어난 성능을 보여주었습니다.
- 사전 학습된 언어 모델을 질의응답 시스템에 활용함으로써, 보다 자연스럽고 문맥을 고려한 답변 생성이 가능해졌습니다.
- 실시간 정보 제공에 대한 사용자의 요구 증대
- 인터넷과 모바일 기기의 발달로 사용자들은 언제 어디서나 필요한 정보를 즉시 얻고자 하는 요구가 커지고 있습니다.
- 단순히 정보를 검색하는 것을 넘어, 대화형 인터페이스를 통해 원하는 정보를 직관적으로 얻고자 하는 사용자가 늘어났습니다.
- 이에 따라 사용자의 질문을 이해하고 적절한 답변을 실시간으로 제공할 수 있는 지능형 질의응답 시스템의 필요성이 대두되었습니다.
- 지식 검색과 답변 생성의 통합 필요성
- 기존의 질의응답 시스템은 지식 검색과 답변 생성을 별도의 단계로 처리하는 경우가 많았습니다. 이로 인해 검색된 정보와 생성된 답변 사이의 정합성이 떨어지는 문제가 발생했습니다.
- 지식 검색과 답변 생성을 통합적으로 수행할 수 있는 프레임워크의 필요성이 제기되었고, 이는 RAG 아키텍처의 등장으로 이어졌습니다.
RAG 기술 접목 사례
- Anthropic's Constitutional AI (CAI)
- Anthropic사는 RAG 기술을 활용한 대화형 AI 모델인 CAI를 개발했습니다.
- CAI는 대화 과정에서 외부 지식을 활용하여 사용자의 질문에 답변을 생성합니다.
- 생성된 응답의 근거가 되는 출처를 명시하여 신뢰성을 높였습니다.
- Perplexity AI
- Perplexity AI는 RAG 기반의 질의응답 서비스를 제공하는 스타트업입니다.
- 사용자의 질문에 대해 웹 검색을 통해 관련 정보를 수집하고, 이를 바탕으로 응답을 생성합니다.
- 제공된 응답의 출처와 검색 과정을 사용자에게 투명하게 공개합니다.
RAG 적용 과정
1. 데이터 준비 및 Chunking
- EDM 예시 보고서, 증빙 문서 수집: 내부 보고서, 정책, 실적 자료 등.
- Chunking(쪼개기):
- 각 문서를 “논리적 단위(섹션, 헤딩, 표 항목)”로 나누고, 메타데이터(카테고리, 연도,보고서 종류 등)를 붙임
2. 임베딩 및 벡터화
- 임베딩 모델 선정:
- OpenAI, Cohere, HuggingFace(국문이면 KoSimCSE/BGE-me)
- 벡터 추출:
- 각 chunk(문단/항목)를 임베딩 모델로 벡터화
3. 벡터 DB 저장
- ChromaDB, Pinecone, mindsDB, Weaviate 등 오픈소스 또는 클라우드 벡터 DB 사용
- 저장 정보:
- 벡터, chunk의 원문, 메타데이터(특히 heading, 구분, 문서ID)
4. RAG 유형 파이프라인 연결
- 질의(Report 생성 요청) → 벡터화
- 벡터DB에서 의미적으로 가장 유사한 chunk Top-N Retrieval
- Retrieval chunk를 LLM 프롬프트로 증강(augementation)
- LLM(예: GPT-4, Gemini 등)에 전달하여 실제 리포트 생성
샘플 코드 (LlamaIndex + ChromaDB)
아래 코드는 “EDM 예시 보고서”를 RAG 시스템에 저장하고, AI 기반 자동 보고서 생성을 수행하는 과정의 예입니다.
from llama_index.core import SimpleDirectoryReader, VectorStoreIndex, StorageContext, ServiceContext
from llama_index.vector_stores.chroma import ChromaVectorStore
from chromadb.config import Settings
from llama_index.llms.openai import OpenAI
docs = SimpleDirectoryReader("edm_sample_docs/").load_data()
db = chromadb.PersistentClient(path="edm_vectordb")
chroma_store = ChromaVectorStore(chroma_client=db, collection_name="edm_reports")
storage_context = StorageContext.from_defaults(vector_store=chroma_store)
index = VectorStoreIndex.from_documents(docs, storage_context=storage_context, service_context=ServiceContext.from_defaults(llm=OpenAI("gpt-3.5-turbo", temperature=0)))
query_engine = index.as_query_engine()
answer = query_engine.query("2024년 우리 회사 환경 실적 보고서를 써줘.")
print(answer)
파이프라인 요약
- EDM 문서 수집 → 논리적 chunk로 분해
- 각 chunk를 임베딩(벡터화) 및 벡터DB 저장
- 리포트 요청(질의) → 벡터화 → 유사 chunk top-N 검색
- 검색 chunk + 질문 조합하여 LLM 프롬프트 구성
- LLM에게 결과 생성 요청 → 리포트 생성 및 사용자 제공
RAG 프레임워크
LlamaIndex
특징
- RAG(검색증강생성) 특화: LLM과 외부 데이터를 효율적으로 연결해, 인덱싱·검색·프롬프트 증강을 자동화합니다.
- 여러 데이터 소스 통합: API, DB, 파일(PDF, 워드 등), S3, 구글드라이브, SharePoint 등 다양한 커넥터를 지원.
- 고급 인덱스 설계: 벡터·트리·리스트·키워드 인덱스 등 데이터 특성에 맞게 다양한 구조 설계.
- 빠르고 직관적: 몇 줄의 파이썬 코드만으로 PoC~프로덕션까지 구현 가능, ramp-up(도입 장벽)이 낮음.
- 풍부한 확장성: Prompt, LLM, Embedding 모델을 쉽게 교체·조합, LangChain 등 다른 프레임워크와 연동 가능.
주요 기능 & 사용 흐름
- 데이터 수집/파싱(Ingestion)
- 내부 문서, DB, 웹 등에서 데이터 수집 및 자동 파싱.
- 청킹(Chunking) & 인덱싱
- 문서를 논리 단위 단락(chunk)별로 분할, 메타데이터와 함께 인덱스 형성.
- 임베딩(Embedding)
- 각 chunk를 임베딩 모델로 벡터화 후 벡터DB에 저장.
- 검색 & 프롬프트 증강
- 사용자 질의를 임베딩해 유사 chunk를 검색 후, 프롬프트에 증거(문맥)로 자동 조합.
- LLM 응답
- 프롬프트를 LLM에 전달, 증빙 기반의 정확한 생성 결과 제공.
비용 구조
- LlamaIndex 자체: 오픈소스 버전은 무료, 관리형 SaaS 플랫폼은 크레딧 기반(Free~Enterprise, 2025년 기준).
- Free(10,000크레딧/월), Starter, Pro, Enterprise 등 플랜 선택 가능.
- 추가 사용분은 $1/1,000 크레딧 기준 별도 과금.
- LLM/Embedding 호출 비용: 실제 비용은 사용 LLM(OpenAI, Gemini 등)·Embedding API 비용이 별도 발생.
- 예) GPT-3.5-turbo는 1,000토큰 당 $0.002
- 인덱스 구축 시에도 일부 인덱스(TreeIndex 등)에 LLM 호출 필요.
- 비용 예측: 개발 단계에서 토큰 예측기/MockLLM으로 예상 비용 시뮬레이션 가능
난이도
- 도입/학습 곡선:
- RAG 관점에서는 매우 쉽고, 튜토리얼·샘플코드가 많음.
- 커스텀 인덱스 설계, 대규모 데이터/멀티소스 통합, 성능 튜닝 등은 중급 이상의 숙련 필요.
- 운영 난이도:
- 수백만 단위 대규모 데이터에도 안정적으로 확장(스케일), 파이프라인 관리 용이.
강점
- 특화된 RAG 성능: 대규모 데이터(수천~수억 문서)에서도 빠르고 정확한 검색·응답.
- 높은 확장성/유연성: 거의 모든 LLM, 벡터DB, 프레임워크와 연동(Plug&Play).
- 실패/재현 방지: 프롬프트 증강·메타데이터 활용 등 고급기능 내장.
- 커뮤니티 성장: 빠른 기능 개선, 다양한 실전 예제와 문서 지원.
단점 및 한계
- 범용 에이전트 프레임워크(X): LangChain만큼의 '체인/에이전트/워크플로우' 복잡 응용은 다소 제한적.
- 복잡한 커스텀화 시 곡선↑: 고급 인덱스 튜닝, 멀티쿼리, 구조화 데이터 지원 등은 내부 구조 숙지가 필요할 수 있음.
- 소규모 프로젝트에 과할 수 있음: 소규모(몇 페이지)라면 인덱스 구축이 오버헤드.
- 에코시스템 상대 열세: 최대 커뮤니티 규모는 LangChain/LangGraph 등이 더 큼.
- 엔터프라이즈 운영: 대용량+보안+고가용성 요구 시 지속적인 관리·업데이트 필요.
실제 적용 시 TIP
- ESG/EDM에 최적: PDF, 정책문서, 실적보고 등 구조화+비정형 혼합데이터의 증거기반 보고서 자동화에 강력.
- PoC~프로덕션 단계별 사용: 무료 플랜→유료 크레딧 방식으로 확장 무난.
- 데이터 커넥터(LlamaHub) 적극 활용: 내부 ERP/DB~클라우드 스토리지와 손쉽게 연동 가능.
결론:
LlamaIndex는 대용량, 복잡 문서 기반의 AI 검색/생성/RAG 솔루션에 크게 특화된 데이터-LLM 연동 프레임워크입니다.
학습 난이도 대비 강력한 기능, 저렴하거나 예측 가능한 비용, 뛰어난 유연성을 바탕으로 ESG 데이터관리·보고서 자동화 등 EDM 업무에 매우 적합합니다.
PoC~대규모 서비스까지, 실제 데이터를 중심으로 한 실전 최적화가 가능합니다.
LangChain
특징
- 목적: ChatGPT, GPT-4 등 LLM을 바탕으로 복잡한 프로세스(데이터 수집→임베딩→검색→생성...)를 쉽고 유연하게 연결하는 프레임워크
- 체인(Chain) 구조: “단계별 작업(문서 쪼개기→임베딩→DB검색→생성)” 등을 한데 묶어 순차적으로 실행. 단계 간 데이터 전달 및 후처리 정의가 명확.
- 에이전트(Agent): LLM이 상황에 맞춰 다양한 도구(검색API, 계산기, DB, 코드실행…)를 동적으로 호출 예: “웹에서 자료 찾고, 요약한 뒤, 엑셀 파일로 출력”
- 방대한 연결성:
- 30여개 이상 LLM(OpenAI, Anthropic, Google 등) 지원
- 각종 벡터DB, 일반DB, 클라우드, PDF/웹/Slack/GoogleSheet 등 플러그인 형태로 손쉬운 연동
- 데이터 파이프라인, 챗봇, RAG 시스템, 자동화 워크플로우 등 테스트→서비스 스케일 확장
- 커뮤니티·예제·확장성: 가장 많은 사용자와 빠른 업데이트, 사용사례 및 튜토리얼 풍부 오픈소스+커머셜(사업자용) 모두 지원
비용 구조
- 자체 사용비: 오픈소스 프레임워크 자체는 무료 단, 실제 LLM/임베딩 모델/서드파티 툴(벡터DB 등)의 API 사용에 따라 별도 비용 발생
- 운영비용: 코드 구조에 따라 API 호출 반복, 외부 시스템(검색/DB 트래픽 등)에 따른 직접비가 늘 수 있음 대량 서비스/멀티에이전트 설계 시 토큰 소모 예측 필요
난이도 및 적용성
- 학습 난이도: 구조 이해(체인/에이전트/메모리)를 한 번 익히면 매우 유연 복잡한 업무(질문→검색→로그 저장→후처리 등)를 한 곳에서 통합 관리 가능 입문 튜토리얼/실무 예제가 매우 많음
- 확장성: 신규 API, DB, LLM 등 추가 연결/교체가 쉬움 수십 개의 체인, 자동화 플로우도 일관되게 설계 가능
강점
- 모듈/워크플로우 설계 유연성: 다양한 데이터/툴/LLM/후처리를 단일 레시피로 손쉽게 조합
- Agent(에이전트) 방식을 통한 동적 작업: 사용자의 질문과 상황에 따라 자동으로 “웹검색→QR코드 생성→메일 발송”도 현업에 적용 가능
- 방대한 벤더·도구·API 지원: OpenAI, Google, Slack, Pinecone, Chroma, Salesforce 등 수십종 쉽게 통합
- 대형 프로젝트, 복합 서비스에 적합: (QA+챗봇+자동 문서화+다국어 번역+코드실행 등 동시에 요구시)
단점 및 한계
- 복잡한 구조의 오버헤드: 단일 기능만 쓴다면 구조가 과할 수 있음(학습/코드 길이↑)
- 디버깅/모니터링: 체인이 길어지거나 Agent가 동적으로 움직일 때, 중간과정 추적이 불편한 편
- 실행 환경/의존성: 꼭 필요한 최소 모듈만 불러오는 것이 중요. (기본 설치 시 의존성 패키지가 많아질 수 있음)
- 성능: 워크플로우가 복잡할수록 실제 응답 속도는 간단한 파이프라인 대비 느려질 수 있음
실제 적용 팁
- 단순 RAG만 할 경우 LlamaIndex가 더 쉽고 빠르지만, 여러 데이터, LLM, 워크플로우·자동화 까지 필요하다면 LangChain이 필수
- 여러 LLM/벡터DB/Agent를 자유롭게 조합해 데모~서비스까지 일관 설계 가능
- ESG/EDM 분야:
- 외부 벤치마킹 연동, 업무별 자동화(예: ESG 공시 대응 챗봇, 다중 평가보고서 자동화 등)
- 보고서 생성→파일화→이메일 발송까지 전 프로세스 일관 설계
비교 요약
정리:
- 정교한 문서 검색·증거 반영에 집중: → LlamaIndex
- 여러 도구·워크플로우 체인, Agent 동작 등 복합 자동화: → LangChain
구분 | LlamaIndex | LangChain |
---|
주요 목적 | RAG(검색증강생성)에 특화된 데이터 인덱싱 및 검색 | LLM 오케스트레이션(체인, 에이전트, 통합) 범용 프레임워크 |
핵심 강점 | - 문서 데이터 기반 정밀 인덱싱 및 검색에 최적화- 고급 인덱스 구조 지원(트리, 리스트 등)- 쉽고 빠른 PoC 및 간단한 코드 구현 가능 | - 다양한 LLM, 도구, API 연동 폭넓음- 복잡한 워크플로우(체인, 에이전트) 구성 가능- 동적 도구 호출 및 멀티태스크 지원 |
사용성/학습곡선 | 초보자도 빠르게 도입 가능, 검색 중심으로 상대적 간단함 | 강력하지만 구조 복잡, 체인과 에이전트 개념 학습 필요 |
데이터 소스 지원 | API, DB, PDF, 문서 등 데이터 인덱싱 중심 | 다양한 데이터 소스(웹, PDF, API, DB 등) 및 멀티모달 지원 |
프롬프트 처리 | 검색 결과 기반 자동 프롬프트 증강에 초점 | 프롬프트 관리, 체인 내 데이터 흐름 제어에 유연성 있음 |
확장성 | 데이터 인덱싱 및 검색에 최적화, LangChain과 연동 가능 | API, LLM, DB 등 다양한 시스템과 광범위한 통합 환경에 적합 |
복잡한 응용 | 주로 검색증강생성 중심 응용에 적합 | 챗봇, 에이전트, 자동화 등 복합 AI 워크플로우 구현에 강함 |
성능/확장성 | 대용량 데이터 빠른 검색 및 응답에 강점 | 대규모/복잡한 작업 처리에 적합, 실제 속도는 파이프라인 복잡도에 영향 |
커뮤니티/생태계 | 빠르게 성장 중, 문서 및 예제가 풍부 | 가장 큰 커뮤니티와 생태계, 다양한 예제와 플러그인 존재 |
비용 | 오픈소스 기본 무료, LLM 호출 API 비용 별도 | 오픈소스 기본 무료, LLM 호출 및 외부 API 별도 비용 발생 |
적합 사례 | - ESG 문서, 법률, 보고서 등 비정형+구조문서 검색- 증거 기반 리포트 자동화 | - 복잡한 멀티모달 데이터 처리- 동적 에이전트, 복합 워크플로우 자동화 |