RAG(Retrieval-Augmented Generation)
사전에 학습된 LLM이 모르는 사실을 외부 지식 베이스에서 검색하여 그 결과를 프롬프트에 주입한 뒤에 생성으로 최종 답을 만드는 패턴이다.
1) Retrieval
LLM이 답을 만들기 전에 외부 지식에서 관련 문서를 찾아오는 단계
2) Augmented
AR/VR의 "증강"이 아닌, 찾아온 텍스트를 프롬프트에 구조적으로 주입하는 것
3) Generation
주입된 컨텍스트를 근거로 최종 답을 작성하는 단계
개발자는 ?
답변을 생성하는 것은 LLM의 역할이고, 우리는 데이터를 잘 가져와서 LLM에게 잘 전달해야한다.
- 데이터를 잘 가져오려면 ? → 일단 잘 저장해야한다.
- 잘 전달하려면 ? → 프롬프트를 잘 활용해야한다. 문맥을 어떻게 제공할 것인가도 매우 중요하다. 잘 가져오더라도 제대로 전달하지 못하면 LLM이 올바른 답변을 제공하지 못하기도 한다.
LangChain
LLM모델, 임베딩, 벡터DB 검색, 프롬프트, 출력 파서 같은 부품들을 같은 규격으로 묶어서 파이프라인(=체인)으로 쉽게 조립하게 해주는 프레임워크이다. 쉽게 말해, LLM 앱을 레고처럼 이어 붙이는 툴이다. RAG의 각 단계를 블록처럼 이어 붙이고 쉽게 바꿀 수 있다.
Vector Database (벡터 DB)
사용자가 원하는 정보 = 사용자의 질문과 관련있는 데이터
관련성이 있다는 것은 어떻게 파악을 하는가 ? → `vector`를 사용한다. (단어 또는 문장의 유사도를 파악하여 관련성을 측정한다.)
Vector를 생성하는 방법은 `embedding 모델`을 활용하여 vector를 생성한다. 여기서 단순히 vector만 저장하는 것이 아닌, metadata도 같이 저장한다. 문서의 이름, 페이지 번호 등을 같이 저장하게 된다.
ChromaDB (로컬 벡터 DB)
가볍고 빠른 로컬 벡터 DB로 폴더에 영구 저장된다.
Pinecone (클라우드 벡터 DB)
임베딩 벡터를 대규모로 저장, 인덱싱, 유사도 검색해 주는 서비스로 클라우드 환경에서 운영이 가능한 데이터베이스이다.
참고
https://www.inflearn.com/course/rag-llm-application개발-langchain/dashboard
후기
처음 해보는 RAG 개발이었는데, LLM + 벡터 DB + 프롬프트 설계가 맞물려 돌아가는 과정이 신기했다. 내가 이번에 학습하면서 배운 내용은 정말 빙산의 일각이겠고, 성능적으로 개선할 수 있는 부분들이 많이 보이기도 하지만, 백엔드 개발만 해오던 나에게는 새로운 패러다임이었던 것 같다.
깃허브
https://github.com/erika0915/rag-llm-chatbot
https://github.com/erika0915/rag-llm-application
'Tech' 카테고리의 다른 글
| [Github] Gemini Code Assist 활용한 코드 리뷰 (0) | 2025.10.14 |
|---|---|
| [Github] CodeRabbit을 활용한 PR 코드 리뷰 (2) | 2025.08.05 |
| [Github] 깃허브 이슈, PR 템플릿 등록하기 (6) | 2025.08.03 |
| [Github] Github Labels 커스텀 한 번에 등록하기 (3) | 2025.08.03 |
| [Jira] Husky로 Jira 커밋 메시지 작성하기 (0) | 2025.07.25 |
