RAG 파이프라인 완성 — 문서 청킹 → 임베딩 → PG 저장 → 유사도 검색 → LLM 연동 → CI4 API
📋 실습 안내
✏️ CODE EDITOR (JSX)
▶ 실행 버튼을 눌러 코드를 테스트하세요.
👁️ 내 미리보기
내 코드 실행 결과
🎯 완성 미리보기
목표
위 에디터 코드를 수정해서 이 결과물과 똑같이 만들어보세요!
💡 TODO 주석을 채워서 위 결과물처럼 동작하게 만들어보세요
🤖 AI 선생님에게 질문하기
이번 강의 전용
▼
선생님이 답변 중이에요...
⚠️ 학습 관련 질문만 답변합니다. 관련 없는 질문은 자동으로 학습으로 유도됩니다.
Q1. RAG(Retrieval-Augmented Generation)에서 "Retrieval" 단계의 역할은?
💡 RAG에서 Retrieval은 사용자 질문을 임베딩으로 변환한 뒤 벡터 DB(pgvector 등)에서 의미적으로 가장 유사한 문서 청크를 검색하는 단계입니다. 이 검색 결과가 LLM의 컨텍스트로 제공되어 정확한 답변 생성을 돕습니다.
Q2. 문서 청킹(Chunking)에서 "overlap(중복)"을 두는 이유는?
💡 청크 사이에 overlap을 두면 이전 청크의 마지막 부분과 현재 청크의 시작 부분이 겹쳐, 경계에서 중요한 정보가 잘리는 것을 방지합니다. 일반적으로 청크 크기의 10~20% (50~100자)를 overlap으로 설정합니다.
Q3. RAG 시스템에서 LLM에 전달하는 프롬프트의 올바른 구성은?
💡 RAG 프롬프트는 보통 세 부분으로 구성됩니다: (1) 시스템 역할 지시문(답변 방식 안내), (2) 검색된 관련 청크들(컨텍스트), (3) 사용자 질문. 이렇게 하면 LLM이 컨텍스트 내 정보를 근거로 답변하고, 없는 내용은 모른다고 말하도록 유도할 수 있습니다.
Q4. 임베딩 모델을 교체할 때 반드시 해야 하는 작업은?
💡 각 임베딩 모델은 서로 다른 벡터 공간을 사용합니다. 구 모델로 저장된 벡터와 새 모델로 생성한 쿼리 벡터를 비교하면 의미 없는 결과가 나옵니다. 따라서 기존 벡터를 모두 새 모델로 재생성해야 하며, 차원도 달라질 수 있어 컬럼 타입 변경이 필요할 수 있습니다.
Q5. pgvector 기반 RAG에서 "같은 문서에서 과도하게 많은 청크가 반환되는 문제"를 해결하는 SQL 기법은?
💡 ROW_NUMBER() OVER (PARTITION BY doc_id ORDER BY similarity DESC)를 사용하면 각 문서 내에서 유사도 순으로 순위를 매길 수 있습니다. 이후 WHERE rn <= 2 같은 조건으로 문서당 최대 2개 청크만 포함시켜 결과 다양성을 보장합니다. DISTINCT ON은 문서당 1개만 허용하므로 유연성이 낮습니다.
😅
아쉽네요!
점수: 0점 — 70점 이상이 되어야 통과합니다.