검색 증강 생성(Retrieval Augmented Generation, RAG)은 검색한 원문 조각을 생성 모델의 근거로 제공한다. 벡터(vector)는 그 조각을 찾기 위한 수치 표현이며 답변 자체가 아니다.
입력 → 처리 → 출력
- 수집과 분할: 애플리케이션이 문서를 읽어 검색 가능한 형태로 바꾸고 적절한 크기의 청크(chunk)로 나눈다. 이 준비 작업은 질문을 처리하기 전에 수행한다.
- 인덱싱(indexing): 임베딩(embedding) 모델이 청크를 숫자 벡터로 바꾼다. 저장할 때는 어느 원문에서 나온 벡터인지도 함께 기록한다.
- 검색(retrieval): 사용자 질문을 벡터로 표현한 뒤, 의미상 관련된 문서 청크를 찾는다.
- 생성(generation): 검색한 청크와 사용자 질문을 생성 모델에 전달해 답변을 만든다.
청킹(chunking)은 문서 분할이며 토큰화(tokenization)와 동일하지 않다. 임베딩은 검색용 의미 표현이고 생성 답변 자체가 아니다. 원문 대응 정보가 없으면 좋은 답을 얻더라도 출처를 추적하기 어렵다.
고유 제약
벡터(vector)의 저장 형식도 선택해야 한다. 바이너리 벡터(binary vector)는 차원당 1비트, float32 벡터는 차원당 32비트를 사용한다. 하지만 이 차이만으로 서비스 전체 비용이 같은 비율로 줄어든다고 계산할 수는 없다. 바이너리 형식을 쓰려면 임베딩 모델(embedding model)과 벡터 저장소(vector store)가 모두 지원해야 하며, 표현의 정확도와 저장 비용 사이의 절충(trade-off)을 평가해야 한다.
전처리 대상인 비정형 문서는 정해진 테이블 스키마가 없는 자료다. 공식 한국어 본문에 “구조화된 프라이빗 데이터”라는 표현이 있지만 같은 절의 영어는 unstructured private data를 가리킨다. 이 교재에서는 비정형 데이터로 구분하며, 저장소에 넣었다는 이유로 문서 내용이 정형화됐다고 보지 않는다.
적용 범위: 벡터 형식과 저장소의 호환 조건은 양쪽 문서를 확인한다. 문서·청크·벡터의 대응을 보존해야 한다.