Knowledge Bases

Knowledge Bases

RAG 파이프라인의 전 단계를 대신 돌리는 Bedrock의 관리형 RAG

Knowledge Base 처리 흐름

DIY 파이프라인이 하던 파싱·청킹·임베딩·검색 — 인제스트 잡 하나와 API 호출 하나로

DIY에서 Knowledge Bases로

직접 만든 파이프라인 각 단계의 관리형 대응

Knowledge Bases 3종

워크로드에 맞는 Knowledge Base 유형 선택 — 셋 다 Knowledge Bases, 다른 것은 관리 범위

데이터 소스 6종

문서가 어디에 있든 연결하는 순간 지식이 되는 소스들 — Vector Store 기준 6종, Managed는 7종(Google Drive·OneDrive 포함)

Knowledge Base 생성과 동기화

S3 연결 후 동기화 한 줄 — 파싱부터 인덱싱까지 자동

핵심 포인트

create_data_source

S3 버킷 연결 — inclusionPrefixes로 대상 문서 범위 지정

start_ingestion_job

동기화 한 줄 — 파싱 → 청킹 → 임베딩 → 인덱싱 자동 수행

증분 처리

변경된 문서만 재처리 — 전체 재인덱싱이 아님

bedrock-agent

구축은 bedrock-agent, 검색은 bedrock-agent-runtime 클라이언트

코드

import boto3
bedrock_agent = boto3.client("bedrock-agent", region_name="us-east-1")

# 데이터 소스 연결 — S3 버킷과 접두사만 지정
response = bedrock_agent.create_data_source(
    knowledgeBaseId="SUPPORT-KB-001",
    name="support-docs",
    dataSourceConfiguration={"type": "S3", "s3Configuration": {
        "bucketArn": "arn:aws:s3:::support-docs-bucket",
        # restaurant-policy.pdf는 policy/ 아래 — rag 모듈과 같은 문서
        "inclusionPrefixes": ["policy/", "faq/"],
    }},
)

# 동기화 시작 — 파싱, 청킹, 임베딩, 인덱싱을 자동 수행
bedrock_agent.start_ingestion_job(
    knowledgeBaseId="SUPPORT-KB-001",
    dataSourceId=response["dataSource"]["dataSourceId"])

개발자의 네 가지 결정

RAG 파이프라인 모듈에서 배운 판단이 여기서는 콘솔의 선택지가 됩니다 — 전부 생성 시점의 결정

인제스트 운영 — 상태·실패·상한

동기화는 한 줄 — 상한과 실패를 아는 데서 시작하는 운영

파일 50MB 상한

초과 문서는 failureReasons에 기록되고 스킵 — 큰 문서는 분할·압축 후 업로드

동시 인제스트 잡 50/Knowledge Base

데이터 소스는 Knowledge Base당 최대 200개 — 둘 다 Managed Knowledge Base 전용 쿼터, 소스별 잡이 병렬로 돕니다.

직접 인제스트

IngestKnowledgeBaseDocuments로 S3 없이 최대 25문서 인라인 주입 (콘솔은 10)

원시 데이터 10TB/Knowledge Base

Managed Knowledge Base 기준 — 쿼리 입력 10,000자 · Retrieve 300회/분

Retrieve vs RetrieveAndGenerate

검색만 가져올 것인가, 답변까지 맡길 것인가 — Knowledge Base의 두 가지 검색 API

RetrieveAndGenerate — 답변과 출처 한 번에

가장 빨리 RAG를 체험하는 경로 — 검색·증강·생성이 호출 하나에

import boto3
rt = boto3.client("bedrock-agent-runtime", region_name="us-east-1")

# 검색 + 증강 + 생성을 호출 하나로
response = rt.retrieve_and_generate(
    input={"text": "예약금 환불 규정이 어떻게 되나요?"},  # ① 자연어 질문
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        # ② Knowledge Base ID + 생성에 쓸 모델
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": "SUPPORT-KB-001",
            "modelArn": "us.anthropic.claude-sonnet-4-6",
        },
    },
)

print(response["output"]["text"])          # ③ 생성된 답변
for c in response["citations"]:            # ④ 세그먼트별 근거
    for ref in c["retrievedReferences"]:
        print(ref["location"]["s3Location"]["uri"])

Retrieve 호출과 응답 구조

청크 텍스트 · 유사도 점수 · 원본 위치 — 프롬프트에 넣을 재료를 그대로 받는 검색 전용 API

핵심 포인트

retrievalQuery

자연어 질문 그대로 전달 — 임베딩 변환은 Knowledge Base가 수행

score

상대 관련도 점수 — 동일 설정 내 비교·임계값 필터 기준

location

원본 S3 문서 URI — 출처 표시(Citation)의 재료

다음 단계

이 호출을 @tool로 감싸면 Agentic RAG — 해당 모듈에서 계속

코드

import boto3
bedrock_rt = boto3.client("bedrock-agent-runtime", region_name="us-east-1")

# 검색만 수행 — 프롬프트 구성과 생성은 직접 제어한다
response = bedrock_rt.retrieve(
    knowledgeBaseId="SUPPORT-KB-001",
    retrievalQuery={"text": "예약금 환불 규정이 어떻게 되나요?"},
    retrievalConfiguration={"vectorSearchConfiguration": {"numberOfResults": 3}},
)

# 응답 — 청크 텍스트 + 유사도 점수 + 원본 문서 위치
for r in response["retrievalResults"]:
    print(r["score"])                          # 상대 관련도 (동일 설정 내 비교용)
    print(r["content"]["text"])                # 청크 원문
    print(r["location"]["s3Location"]["uri"])  # 출처 문서

Retrieve 응답의 실물

앞 장 코드가 받는 것 — 필드별로 열어보는 retrievalResults 한 건

검색 품질 조율

요청 하나가 후보를 좁혀 가는 순서 — 네 단계 모두 요청 파라미터로 조절 가능

1. 1
   메타데이터 필터

   찾아도 되는 범위부터 확정 — 부서·연도·테넌트 격리

2. 2
   검색 타입

   SEMANTIC 또는 HYBRID로 유사 후보 선정

3. 3
   리랭커

   후보를 쿼리와 정밀 비교하여 순서 재조정

4. 4
   Top-K 반환

   numberOfResults만큼만 최종 반환

검색 타입 — 시맨틱과 하이브리드

RAG 파이프라인 모듈의 하이브리드 검색이 Knowledge Base에서는 요청 파라미터 하나

필터와 Top-K — 후보를 다스리기

유사한 것을 찾는 일과 찾아도 되는 범위를 정하는 일의 차이

메타데이터 필터

문서에 붙인 메타데이터로 검색 범위 제한 — 부서·연도·문서 유형별 격리

numberOfResults

반환 청크 수(Top-K) — 많을수록 재현율↑, 컨텍스트 비용↑

score 임계값

응답의 score(상대 관련도)로 클라이언트 측 필터 — 절대 기준보다 동일 설정 내 상대 비교용

요청 상한

쿼리 입력 10,000자 · Retrieve 분당 300회 (Managed Knowledge Base 기준)

리랭커 — 마지막 순서 재조정

벡터 검색이 빠르게 추린 후보를 리랭커가 다시 줄 세우는 2단 구조

rerankingConfiguration

vectorSearch 결과에 재순위 적용 — type은 BEDROCK_RERANKING_MODEL (유일값)

modelArn · numberOfRerankedResults

리랭킹에 쓸 모델과 최종 반환 개수 지정

metadataConfiguration

리랭킹 판단에 포함/제외할 메타데이터 필드 선택

Managed Knowledge Base

관리형 리랭커가 기본 포함 — 별도 구성 없이 적용

컬렉션과 인덱스

Vector Store Knowledge Base(BYO)가 소유하게 되는 저장 구조

인덱스 매핑

knn_vector 필드 선언 — dimension은 임베딩 모델 차원과 일치해야 한다

PUT /kb-refund-index
{
  "settings": { "index.knn": true },
  "mappings": { "properties": {
    "chunk_vector": {
      "type": "knn_vector", "dimension": 1024,
      "method": { "name": "hnsw", "engine": "faiss", "space_type": "l2" }
    },
    "chunk_text": { "type": "text" }, "metadata": { "type": "keyword" }
  } }
}

kNN 검색과 거리 메트릭

질의 벡터와 가까운 k개를 찾는 검색 — "가깝다"의 정의가 space_type

kNN 질의

GET /kb-refund-index/_search
{
  "size": 5,
  "query": { "knn": {
    "chunk_vector": {
      "vector": [0.12, -0.48, ...],
      "k": 5
    }
  } }
}

거리 메트릭 — space_type

l2

유클리드 거리 — 좌표 공간의 직선 거리

cosinesimil

코사인 유사도 — 크기를 무시한 방향 비교

innerproduct

내적 — 크기까지 반영한 유사도