Lab 01: 콘솔로 관리형 RAG 만들기

• 관리형 RAG가 콘솔에서 어떤 단계로 구성되는지 전체 흐름을 파악합니다
• 원본 문서(PDF)를 S3에 올리고 Knowledge Base의 데이터 소스로 연결합니다
• 청킹 / 임베딩 / 벡터 저장소가 각각 무슨 일을 하는지, 그리고 콘솔이 이를 어떻게 자동화하는지 이해합니다
• Sync가 실제로 문서를 잘라 벡터로 바꿔 저장하는 과정임을 확인합니다
• Test 패널로 “검색만(Retrieval only)“과 “검색 + 생성(Retrieval and response generation)“의 차이를 비교합니다
• 답변의 근거(citation)가 실제 문서 문장과 연결되는 것을 눈으로 확인합니다

시작 전 확인 사항

• 리전: us-east-1 (N. Virginia) — 콘솔 우측 상단에서 반드시 확인하세요. 리전이 다르면 모델 액세스와 벡터 저장소가 보이지 않습니다.
• IAM 사용자로 접속 — 루트 사용자로는 Knowledge Base를 생성할 수 없습니다.

RAG가 콘솔에서 만들어지는 흐름

관리형 RAG는 결국 다음 단계의 묶음입니다. 콘솔은 이 전부를 자동으로 처리하지만, 각 단계가 무엇인지 알아야 결과를 신뢰하고 문제를 진단할 수 있습니다.

graph TD
  A["원본 PDF (주주서한)"] --> B["S3 업로드"]
  B --> C["Knowledge Base 생성"]
  C --> D["청킹 — 문서를 조각으로 자르기"]
  D --> E["임베딩 — 조각을 숫자 벡터로 변환 (Titan V2)"]
  E --> F["벡터 저장소 — S3 Vectors에 저장"]
  F --> G["Test — 검색 / 검색+생성"]

핵심: 콘솔이 대신 해 주던 일을 코드로 펼쳐 보면, RAG는 마법이 아니라 임베딩 + 벡터검색 + 프롬프트 조립의 합임이 드러납니다. 이 Lab의 모든 단계에서 “지금 이게 오후의 어느 코드에 해당하는가”를 의식하며 진행하세요.

RAG는 두 종류의 모델을 씁니다. 임베딩 모델(문서와 질문을 벡터로 변환)과 생성 모델(검색 결과를 바탕으로 답변 작성)입니다. 두 모델 모두 사용 권한이 열려 있어야 Knowledge Base가 동작합니다.

이번 실습 환경에서는 필요한 모델이 미리 활성화되어 있습니다. 따로 설정할 것은 없고, 아래 두 모델이 각각 무슨 역할인지만 짚고 넘어갑니다.

• Titan Text Embeddings V2 — 임베딩용. 문서 조각과 질문을 숫자 벡터로 바꾸는 데 사용됩니다.
• Claude Haiku 4.5 — 생성·테스트용. 검색된 문서를 근거로 답변을 만듭니다.

💡 새 계정에서 Bedrock을 처음 쓰는 경우에는, 일부 LLM 제공사(예: Anthropic)가 모델을 켜기 전에 간단한 사용 사례(use case) 정보를 제출하도록 요구하기도 합니다. 최초 한 번만 하면 되고 보통 금방 승인됩니다. 이번 실습 환경에서는 이미 처리되어 있어 신경 쓸 필요가 없습니다.

임베딩 모델과 생성 모델은 역할이 완전히 다릅니다. 임베딩 모델은 “의미를 좌표로 바꾸는” 일만 하고 답변을 쓰지 않습니다. 생성 모델은 벡터를 만들지 않고, 검색으로 찾아온 문서를 읽고 사람이 읽을 답변을 씁니다. RAG는 이 둘의 분업으로 굴러갑니다.

왜 S3에 올리는가

Knowledge Base는 문서 원본을 자기 안에 저장하지 않습니다. 대신 “원본 문서가 어디 있는지”만 가리키면, 그 문서를 잘라 임베딩으로 바꿔 벡터 저장소에 넣는 일을 대신해 줍니다. 그 원본이 놓이는 자리가 S3입니다. 나중에 문서를 추가하거나 교체할 때도 S3에 올리고 다시 동기화하면 되므로, S3는 RAG의 “문서 보관 창고” 역할을 합니다.

이번 실습에서는 제공된 2019–2022 아마존 주주서한 PDF 4개를 사용합니다. Knowledge Base는 PDF를 그대로 읽어 파싱·청킹하므로 별도 변환이 필요 없습니다.

업로드 절차

1. 콘솔에서 S3로 이동합니다.
2. 본인 실습용 버킷을 엽니다. 버킷이 없으면 Create bucket으로 만듭니다.
   • 버킷 이름은 전 세계 계정에서 유일해야 합니다(예: rag-shareholder-letters-2026).
   • 버킷 이름은 Username으로 시작해야 합니다(예: user-01-s3).
   • 리전은 us-east-1.
3. 버킷 안에서 Upload → 주주서한 PDF 4개 선택 → Upload.

⚠️ S3 버킷과 Knowledge Base는 같은 리전(us-east-1)에 있어야 합니다. 리전이 어긋나면 데이터 소스 연결 단계에서 버킷이 보이지 않거나 동기화가 실패합니다.

이제 Bedrock에게 “이 S3 문서로 RAG를 만들어 줘”라고 지시합니다.

생성 시작

1. Bedrock 콘솔 좌측 내비게이션 → Knowledge Bases.
2. Create Managed KB 드롭다운 → Unstructured Vector Store KB 선택.
   • “Provide Knowledge Base details” 페이지가 열립니다.

기본 정보와 IAM 역할

3. Knowledge Base name: 본인 것을 알아볼 수 있게 짓습니다(예: rag-user-01-kb).
4. IAM permissions: Create and use a new service role를 선택합니다(권장).
5. Choose data source: Amazon S3 선택 → Next.

새 서비스 역할(service role)이란? Knowledge Base가 동작하려면 “S3 버킷에서 문서를 읽고, 임베딩 모델을 호출하고, 벡터 저장소에 쓰는” 권한이 필요합니다. Create and use a new service role를 고르면 Bedrock이 정확히 그 일에 필요한 최소 권한만 가진 IAM 역할을 자동 생성합니다. 권한을 직접 짜다 실수하는 일을 막아 주는, 실습에서 가장 안전한 선택입니다.

이 화면에서 “어떤 문서를, 어떻게 잘라서” Knowledge Base에 넣을지 정합니다. 청킹은 RAG 품질을 좌우하는 핵심 설정이라 특히 주의가 필요합니다.

데이터 소스 설정

1. Data source name: 자유롭게 짓습니다(예: rag-user-01-letters).
2. S3 URI: Browse S3를 눌러 Step 2에서 업로드한 S3 버킷을 선택합니다.
   • 같은 계정의 버킷이면 기본값(This AWS account) 그대로 둡니다.
3. Parsing strategy: Amazon Bedrock default parser — 일반 텍스트 PDF에는 이걸로 충분하며 추가 비용이 없습니다.
4. Chunking strategy: Fixed-size chunking(고정 크기 청킹) — 예측 가능하고 단순해서 학습용으로 적합합니다.
5. Next.

청킹이 왜 필요한가 (그리고 무슨 일이 일어나는가)

LLM에게 문서 “전체”를 한 번에 넣을 수는 없습니다. 너무 길어 토큰 한도를 넘고, 질문과 무관한 내용까지 섞여 답변 품질이 떨어집니다. 그래서 문서를 검색 가능한 작은 조각(chunk)으로 자릅니다. 질문이 들어오면 전체 문서가 아니라 질문과 가장 관련 있는 조각 몇 개만 골라 모델에게 전달합니다.

• Fixed-size chunking — 문서를 일정한 토큰/문자 길이로 기계적으로 자릅니다. 동작이 예측 가능하고 단순합니다.
• 여기서 콘솔이 자동으로 해 주는 이 “자르기”가, 오후 코드 실습의 load_chunks()(문단 단위로 자르기)와 정확히 같은 일입니다.

⚠️ 파싱·청킹 설정은 Knowledge Base 생성 후에는 바꿀 수 없습니다. 잘못 골랐다면 Knowledge Base를 다시 만들어야 합니다. 그래서 이 화면에서 신중하게 선택해야 합니다.

청킹으로 자른 조각들을 숫자 벡터로 바꾸고(임베딩), 그 벡터를 저장·검색할 곳(벡터 저장소)을 정하는 단계입니다.

임베딩 모델 선택

1. Embeddings model: Titan Text Embeddings V2 선택.
   • Additional configurations에서 벡터 차원을 볼 수 있습니다 — 기본값 1024. 오후 코드 실습에서 dim=1024로 다시 만나게 됩니다.

임베딩이란 “의미를 좌표로 바꾸는” 일입니다. 각 문서 조각을 1024개의 숫자로 이루어진 벡터로 변환하면, 의미가 비슷한 글은 벡터 공간에서 서로 가까이 놓입니다. 나중에 질문도 같은 방식으로 벡터로 바꾼 뒤, “질문 벡터와 가까운 조각”을 찾으면 그게 곧 관련 문서 검색입니다. 이 단계가 오후 lab5의 embed() 함수와 정확히 같은 일입니다(텍스트 → 숫자 벡터).

벡터 저장소 선택

2. Vector database → Quick create a new vector store → Amazon S3 Vectors 선택.
3. Next → 검토 페이지에서 내용 확인 → Create Knowledge Base.
   • 생성에는 보통 1~3분 걸립니다. 상태가 Available이 되면 완료입니다.

Quick create를 고르면 Bedrock이 S3 벡터 버킷과 벡터 인덱스를 자동으로 만들어 줍니다. 직접 데이터베이스를 띄우거나 설정할 필요가 없습니다. 이 벡터 인덱스가 바로 “어떤 조각이 어떤 벡터인지”의 목록이며, 오후 코드 실습의 INDEX(청크-벡터 목록)에 해당합니다. 콘솔은 이 목록을 S3에 영구 저장해 줄 뿐입니다.

Knowledge Base를 만들었다고 해서 문서가 곧바로 검색되는 것은 아닙니다. Sync(동기화)를 실행해야 비로소 S3의 원본 문서가 벡터로 변환되어 저장됩니다.

동기화 절차

1. 생성된 Knowledge Base를 엽니다.
2. Data source 영역에서 데이터 소스를 선택 → Sync.
   • Sync 상태가 Syncing → Completed로 바뀝니다(문서 양에 따라 1~5분).

Sync가 실제로 하는 일

Sync를 누르는 순간 Bedrock이 내부적으로 다음을 순서대로 실행합니다. 이 네 단계가 오후에 여러분이 손으로 구현할 전 과정입니다.

graph LR
  A["S3 원본 문서"] --> B["파싱"]
  B --> C["청킹 (Fixed-size)"]
  C --> D["Titan 임베딩"]
  D --> E["S3 Vectors에 저장"]

⚠️ 문서를 바꾸거나 추가하면 반드시 다시 Sync해야 반영됩니다. S3에 새 파일을 올리는 것만으로는 Knowledge Base에 들어가지 않습니다. Sync는 “S3의 현재 상태를 벡터 저장소에 반영하는” 작업입니다.

이제 만든 RAG가 제대로 동작하는지 확인합니다. Test 패널의 두 모드를 비교하면 “검색”과 “생성”이 어떻게 다른 일인지가 명확하게 드러납니다.

테스트 절차

1. Knowledge Base 화면 우측의 Test 패널을 엽니다.
2. 상단 토글로 두 모드를 비교합니다.
   • Retrieval only (Retrieve API) — 검색된 원본 청크와 점수만 봅니다. 모델이 답변을 만들지 않습니다. → 오후 lab4.retrieve()에 해당.
   • Retrieval and response generation (RetrieveAndGenerate API) — 검색 + 모델 생성까지 합니다. → 오후 lab4.retrieve_and_generate()에 해당.
3. 모델 선택에서 **Claude Haiku 4.5 (US Anthropic Claude Haiku 4.5)**를 고릅니다.

예시 질문

다음 질문을 던져 봅니다(주주서한 내용 기반).

• “아마존이 말하는 ‘Day 1’은 무엇인가?”
• “AWS는 어떻게 시작됐나?”
• “아마존은 왜 자유현금흐름(FCF)을 강조하나?”

답변과 함께 표시되는 출처(citation)/청크를 눌러, “이 답이 어느 문장에서 나왔는지” 확인합니다.

두 모드를 비교하며 보기

• Retrieval only에서는 “검색”이 무엇인지 날것 그대로 보입니다. 질문 벡터와 가까운 청크들이 유사도 점수와 함께 나열됩니다. 아직 답변은 없습니다.
• Retrieval and response generation은 그 청크들을 모델에게 컨텍스트로 넘겨 사람이 읽을 답변을 만들어 줍니다. 답변 끝의 citation을 누르면 근거 청크로 연결됩니다.

✅ 이것이 RAG의 핵심입니다. 모델이 학습하지 않은 주주서한 내용도, 검색된 문서를 프롬프트에 넣어 주면 정확하게 답합니다. 그리고 citation으로 “답변의 근거가 실제 문서 문장과 연결되는 것”을 눈으로 확인할 수 있어, 환각(Hallucination) 여부를 검증할 수 있습니다.

📌 본인 Knowledge Base ID 메모

Knowledge Base 상세 화면 상단에 Knowledge base ID(예: XXXXXXXXXX)가 있습니다. 이 값을 반드시 메모해 두세요. Lab 04의 코드 실습에서 이 ID로 같은 Knowledge Base를 boto3로 호출합니다.

콘솔에서 클릭 몇 번으로 끝난 이 과정은, 실은 RAG를 구성하는 모든 단계의 묶음이었습니다.

“콘솔이 대신 해 주던 일”을 코드로 펼쳐 보면, RAG가 마법이 아니라 임베딩 + 벡터검색 + 프롬프트 조립의 합임이 드러납니다. 이 표의 오른쪽 열이 앞으로의 Lab에서 여러분이 직접 만들 내용입니다.

• 같은 질문을 한국어 vs 영어로 던지면 검색되는 출처(청크)가 달라질까요? 왜 그럴까요?
• 청킹 크기를 더 크게/작게 골랐다면, 같은 질문의 답이 어떻게 달라졌을까요?