자연어처리(NLP)에서 RAG는 Retrieval-Augmented Generation의 약자이다.
RAG를 구성한다는 건, 단순히 언어 모델(예: GPT, BERT)을 쓰는 것보다
외부 지식 소스나 문서들을 검색해서, 이것을 답변에 활용하는 시스템을 만든다는 뜻에 가깝다.
RAG를 구성한다는 것은 검색기 모듈(retriever)을 만들고, 생성기 모듈(generator, 보통 LLM)을 연결해서,이 둘이 잘 협업해 결과를 내도록 시스템을 짠다는 것이다.
1️⃣ Retriever (검색기)
→ 질문에 맞는 관련 문서, 지식, 단편 등을 검색.
예: 내가 “프랑스 혁명은 언제야?”라고 물으면, 관련 백과사전 문서들을 찾아온다.
2️⃣ Generator (생성기)
→ 검색해온 내용을 바탕으로 자연스럽고 정확한 답변을 생성한다.
즉, 그냥 모델 속에 있는 지식만 쓰는 게 아니라, 최신 데이터나 외부 자료까지 가져와서 답한다.
“어제 EPL 경기 누가 이겼어?”
“최신 논문 중 GPT-4o 분석한 거 있어?”
→ 일반 GPT 모델은 학습 시점 이후의 정보는 알 수 없다. RAG는 외부 웹이나 문서, 데이터베이스에서 실시간 검색해서 답을 줄 수 있다.
다만 “어제 EPL 경기 결과 알려줘” → 그냥 웹 검색 + LLM으로도 충분히 최신 정보 확인 가능.
회사 내부 정책, 매뉴얼, 보고서 Q&A 챗봇
대형 병원 환자 기록, 의학 논문, 약품 정보 다루는 헬스케어 봇
→ 이런 건 LLM에 다 학습시킬 수도 없고, 계속 업데이트되는 자료가 많아서 RAG로 외부에서 가져와야 한다.
“이 내용 어디서 가져왔어?” → 검색된 문서 링크 같이 제공
금융, 법률, 학술 분야처럼 출처 기반 답변이 중요한 분야
→ RAG는 검색된 구체적 문서 기반이라 신뢰성을 높여준다.
법률문서 해석, 게임 아이템 데이터베이스 검색, 특허 문헌 요약
“우리 회사의 최신 출장비 규정이 뭐야?”
→ 내부망 문서라서, 웹 검색은 못함. 하지만 RAG는 회사 내부 DB에 연결해서 처리할 수 있음.
→ 일반 GPT는 범용 모델이라 잘 모르는 특수 분야가 많다. RAG는 해당 분야의 데이터베이스, 문서, 사내 자료 등과 연결해 정확도를 높힌다.
최신 기사, 보고서, 경기 결과, 시장 데이터 등을 다뤄야 한다.
☐ YES / ☐ NO
LLM 모델 용량에 다 담을 수 없는 자료가 많다.
사내 문서, 전문 데이터베이스, 백과사전 수준의 자료가 필요하다.
☐ YES / ☐ NO
“이거 어디서 가져왔어?” 질문에 답할 수 있어야 한다.
법률, 의학, 금융 등 검증된 자료 기반이 필수다.
☐ YES / ☐ NO
게임 데이터, 특허 문헌, 기업 내부 지식 등 일반 LLM이 모르는 분야다.
내 프로젝트는 매우 좁은 영역의 전문가용 답변이 필요하다.
☐ YES / ☐ NO
질문에 맞는 자료를 먼저 찾아와야 하고, 그걸 바탕으로 자연어로 설명해줘야 한다.
단순히 검색 결과를 나열하는 게 아니라, 잘 요약·생성하는 게 중요하다.
☐ YES / ☐ NO
프로젝트에서 정보가 자주 바뀌고, 그때마다 모델 재학습을 할 수 없다.
외부 DB만 업데이트하면 실시간으로 반영되길 원한다.
☐ YES / ☐ NO
이 프로젝트는 상상력, 창작, 스토리텔링 같은 작업이 아니다.
대신 정확성, 사실 기반, 정보 검색이 중요하다.
☐ YES / ☐ NO
🔹 Function Calling은 “도구를 호출해서 값을 받는 것”
🔹 RAG는 “문서를 찾아서 그 안에서 문장을 뽑아 설명하는 것”
| 항목 | Function Calling | RAG |
|---|---|---|
| 핵심 목적 | LLM이 특정 기능(API 등)을 직접 호출해서 정보 얻기 | 외부 문서에서 텍스트를 검색하고 그걸 바탕으로 생성 |
| 데이터 구조 | 구조화된 데이터 (API 응답: JSON, 숫자, 문자열 등) | 비구조화된 텍스트 (문서, 보고서, 웹페이지 등) |
| 정보 소스 | 명시적으로 설계된 함수/API | 자체 문서 DB, 검색엔진, 벡터 스토어 등 |
| 실행 흐름 | tool calling → JSON 응답 → LLM이 후처리 | query → 문서 검색 → 관련 텍스트 chunk 삽입 → 답 생성 |
| 예시 | “오늘 날씨 어때?” → weather API 호출 | “오늘 날씨 어때?” → 뉴스 기사에서 관련 문장 검색 후 요약 |
| 신뢰성 | API에서 오는 구조화된 값 → 정확하고 신뢰도 높음 | 문서에서 뽑은 문장 → 뉘앙스, 문맥에 따라 해석될 수 있음 |
| 사용 목적 | 계산, 실시간 정보, 명확한 값이 필요한 작업 | 문서 기반 요약, 사실 기반 Q\&A, 복잡한 문맥 처리 |
LangChain은 LLM을 다양한 외부 도구나 데이터, API, DB, 체인(단계)과 연결해주는 파이프라인 프레임워크
즉, GPT 같은 모델 하나만 쓰는 게 아니라:
검색
계산
외부 API 호출
DB 질의
코드 실행
이런 다양한 블록들을 체인(chain)처럼 연결해서 복잡한 작업을 처리할 수 있게 만들어주는 라이브러리다.
✔ 여러 모듈을 체인처럼 묶기
✔ 프롬프트 관리, 체인 설계, 파이프라인 구축
✔ 외부 DB, 문서, API 연동
✔ memory (대화 내 기억) 관리
✔ agent (도구 조합해 실행) 설계
LangChain은 “LLM을 단순히 호출하는 걸 넘어서, 큰 시스템 안에서 다양한 역할을 하게 해주는 도구박스” 이다. (RAG를 포함한 더 큰 설계 프레임워크)
단순히 검색-생성이면 → RAG만 써도 충분.
복잡한 로직, 여러 도구 조합, 멀티스텝 워크플로우면 → LangChain.
그냥 문서 기반 Q&A → RAG
문서 Q&A + 계산 + 예약 API 호출 + 대화 context 기억 → LangChain