온톡 Onto-K의 영상 **「RAG 파이프라인 기본 3단계 | 벡터DB부터 LLM 연동까지」**에서는 RAG를 가장 기본적인 세 단계로 나눠 설명합니다. 핵심 구조는 **Indexing → Retrieval → Generation** 입니다. ## 1. Indexing 문서를 불러오고, 작은 Chunk로 나누고, Embedding Vector로 변환한 뒤 Vector DB에 저장합니다. 즉: **Document → Chunk → Embedding → Vector DB** ## 2. Retrieval 사용자 질문도 Embedding으로 바꾼 뒤 Vector DB에서 의미적으로 가까운 문서 Chunk를 찾습니다. 즉: **Query → Query Embedding → Similarity Search → Top-K Context** 여기서 중요한 점은 단순 키워드 일치가 아니라 의미 유사도 검색이라는 것입니다. ## 3. Generation 검색된 문서 조각을 사용자 질문과 함께 LLM에 전달하고 최종 답변을 생성합니다. 즉: **Question + Retrieved Context → LLM → Answer** ## 왜 RAG가 필요한가? LLM이 모르는 최신 정보, 사내 문서, 비공개 자료, 특정 정책 등을 외부 근거로 제공할 수 있기 때문입니다. 이를 통해 Hallucination을 완전히 없앨 수는 없지만 근거 없는 추측을 줄이고 출처 기반 답변을 만들 수 있습니다. ## Embedding의 역할 Embedding은 문장이나 문서의 의미를 Vector로 표현합니다. 그래서 '환불', '반품', '돈 돌려받기'처럼 표현은 달라도 의미가 비슷한 문서를 가까운 위치에서 찾을 수 있습니다. ## Top-K가 중요한 이유 가장 관련 있는 문서 K개만 LLM에 전달합니다. K가 너무 작으면 중요한 근거를 놓치고, 너무 크면 불필요한 Context가 섞여 품질이 떨어질 수 있습니다. ## 전체 흐름 사전 준비: **Document → Chunk → Embedding → Vector DB** 질문 시점: **Question → Query Embedding → Similarity Search → Top-K Context → LLM → Answer** ## 핵심 정리 RAG는 결국 **찾고(Retrieval), 근거를 붙이고(Context), 답하게 하는(Generation)** 구조입니다. 이 세 단계를 이해하면 LangChain, Chroma, Pinecone, pgvector 같은 도구가 어느 위치에서 사용되는지도 쉽게 이해할 수 있습니다.