Prepare web content for Amazon Bedrock Knowledge Bases with Crawl4AI

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Bedrock Web Crawler를 기본 웹 수집 경로로 사용하되, 본문 정제·수집 범위 제어·사용자 정의 메타데이터가 필요하면 Crawl4AI로 Markdown과 메타데이터를 준비해 Amazon S3를 통해 Amazon Bedrock Knowledge Bases에 수집한다.

📌 핵심 요약

• Amazon Bedrock Managed Knowledge Base는 수집·저장·색인·검색을 관리하고 임베딩과 재순위화에 기본적으로 서비스 관리형 모델을 사용한다. 웹 콘텐츠의 기본 선택지인 Amazon Bedrock Web Crawler는 robots.txt를 준수하고, 설정한 범위와 속도로 수집하며, JavaScript로 로드되는 콘텐츠 대기와 예약 동기화를 지원한다. 최초 전체 수집 이후에는 추가·수정·삭제된 콘텐츠를 반영한다.
• Crawl4AI 경로는 본문 영역 선택, 탐색 메뉴 등 상용구 제거, 사용자 정의 메타데이터 부착이 필요한 공개 웹 콘텐츠에 적합하다. CSS 선택자와 수집 범위·깊이·페이지 수·URL 패턴으로 대상을 제한하고 Markdown을 생성하지만, 가지치기 필터는 휴리스틱이므로 대표 결과를 검토해야 한다.
• 샘플은 Amazon EventBridge가 예약에 따라 AWS Fargate의 Amazon ECS 작업을 시작하고, 작업이 수집·Amazon S3 업로드·수집 작업 시작을 순차 실행한다. 공개 페이지만 처리하며 인증 세션은 구현하지 않는다. 로그인 필요 사이트는 먼저 Amazon Bedrock Web Crawler의 인증 옵션을 검토하고, 샘플에 인증을 추가하려면 세션 처리·AWS Secrets Manager 자격 증명 저장·보안 검토가 필요하다.
• 각 Markdown 문서에는 같은 Amazon S3 위치의 메타데이터 사이드카가 대응하며, page.md의 사이드카 이름은 page.md.metadata.json이다. 사이드카는 최대 10 KB이고, 초과하면 두 파일을 쓰기 전에 오류로 실행을 중단한다. 이 Amazon S3 경로는 관리형 지식 기반과 고객 관리형 지식 기반 모두에서 사용할 수 있다.
• Crawl4AI의 역할은 문서와 메타데이터 준비까지이며, 이후 파싱·청킹·임베딩·색인·검색은 Amazon Bedrock Knowledge Bases가 담당한다. 관리형 지식 기반의 기본 청킹은 300토큰과 20% 중첩이며, 고정 크기 청킹과 청킹 없음도 제공한다. 청킹 전략은 데이터 소스 연결 후 변경할 수 없어 대표 페이지와 평가 질문으로 비교해야 하고, 변경하려면 새 데이터 소스를 만들어야 한다. 이 방식은 알려진 웹사이트의 배치 수집이며 추론 시점의 실시간 웹 접근이 아니다.

🧩 주요 포인트

1. 웹 수집 경로 선택 → Amazon Bedrock Web Crawler가 요구사항을 충족하면 이를 사용하고, 본문 정제·범위 제어·사용자 정의 메타데이터가 추가로 필요할 때 Crawl4AI 준비 단계를 적용한다.
2. 준비와 수집의 책임 분리 → Crawl4AI는 Markdown과 메타데이터를 만들고 Amazon S3로 전달하며, Amazon Bedrock Knowledge Bases는 이후 검색용 처리를 맡는다. 공개 페이지 전용 샘플의 인증 제약과 10 KB 사이드카 제한이 적용 범위를 결정한다.
3. 청킹 결정의 지속성 → 300토큰·20% 중첩을 포함한 전략별 검색 결과를 대표 자료로 비교해야 하며, 연결 후 전략 변경에는 새 데이터 소스가 필요하므로 사전 평가가 중요하다.

🧠 상세 정리

1. 관리형 웹 수집을 기본 경로로 선택

글은 RAG 애플리케이션의 답변 품질이 수집 데이터에 달려 있다는 전제에서 출발하며, Amazon Bedrock Knowledge Bases를 Amazon Bedrock의 완전관리형 RAG 기능으로 소개한다. Amazon Bedrock Managed Knowledge Base에 데이터 소스를 연결하면 서비스가 수집·저장·색인·검색을 담당하므로 사용자가 벡터 저장소를 직접 프로비저닝하거나 확장할 필요가 없고, 임베딩과 재순위화에는 기본적으로 서비스 관리형 모델이 사용된다. 웹 콘텐츠는 수집 권한이 있는 시작 URL이나 사이트맵을 Amazon Bedrock Web Crawler에 제공하는 방식이 우선 권장된다. 이 커넥터는 설정한 범위와 속도 제한 안에서 robots.txt를 준수하며, JavaScript로 로드되는 콘텐츠를 기다리는 기능과 예약 동기화를 지원한다. 최초 전체 수집 이후에는 추가·수정·삭제된 콘텐츠를 반영하므로, 대부분의 공개 웹사이트에서는 별도 크롤러 구축·호스팅·운영 없이 시작할 수 있다는 설명이다.

2. Crawl4AI가 필요한 추가 전처리

일부 웹 자료는 페이지에 접근하는 것만으로 충분하지 않고, 지식 기반에 들어갈 내용을 더 세밀하게 통제해야 한다. 글은 본문 영역만 색인하거나 탐색 메뉴와 반복 문구를 제거하고, 문서마다 자체 메타데이터 속성을 붙여야 하는 경우에 오픈 소스 Python 크롤러인 Crawl4AI를 준비 단계로 제시한다. DefaultMarkdownGenerator에 가지치기 콘텐츠 필터를 적용하면 제목·목록·표를 보존하면서 불필요한 부분을 줄일 수 있지만, 가지치기는 휴리스틱이므로 대상 사이트의 대표 출력물을 검토해야 한다. 선택적 CSS 선택자로 페이지 일부만 추출하고, 시작 URL의 출처와 페이지·경로·호스트 범위, 깊이·페이지 수 상한, URL 패턴으로 너비 우선 탐색을 제한할 수도 있다. 이렇게 준비한 Markdown과 메타데이터는 Amazon S3 데이터 소스로 전달되며, 이 경로는 관리형과 고객 관리형 지식 기반 모두에 적용된다.

3. 예약 실행부터 검색까지의 구성

샘플의 실행 흐름은 Amazon EventBridge가 설정된 일정에 따라 AWS Fargate의 Amazon ECS 작업을 시작하는 데서 출발한다. 작업은 지정된 공개 웹사이트를 수집해 페이지별 Markdown과 메타데이터 사이드카를 만들고, 지식 기반 데이터 소스에 연결된 Amazon S3 버킷으로 업로드한 뒤 수집 작업을 시작한다. Amazon Bedrock Knowledge Bases는 새로 생성되거나 변경된 객체를 읽어 파싱과 선택된 청킹을 수행하고, 임베딩을 생성해 벡터 저장소에 색인하며, 관리형 지식 기반에서는 이 저장소도 서비스가 관리한다. 애플리케이션은 이후 관련 청크를 검색하거나 인용을 포함한 생성 응답을 요청할 수 있고, 작업은 시작 시 비밀정보가 아닌 파이프라인 설정을 AWS Systems Manager Parameter Store에서 읽는다. 기본 샘플은 퍼블릭 서브넷의 Fargate 작업이 인터넷 게이트웨이를 통해 웹사이트에 접근하는 구조이며, 글은 이 구성과 기본값을 서비스의 필수 요건이 아닌 구현 출발점으로 설명한다.

4. 공개 페이지와 배치 수집이라는 적용 범위

이 워크플로는 알려진 웹사이트를 대상으로 문서를 미리 준비하는 배치 수집 방식이며, Amazon Nova의 Web Grounding처럼 추론 시점에 실시간으로 웹에 접근하는 기능과 구분된다. 또한 샘플은 공개 페이지만 처리하고 인증된 세션을 구현하지 않으므로, 로그인이 필요한 사이트에 그대로 적용하는 흐름은 제공하지 않는다. 그런 사이트에서는 먼저 Amazon Bedrock Web Crawler의 인증 옵션을 평가하도록 안내하며, 원문은 기본 인증, 폼 기반 인증, SAML 인증을 지원 항목으로 제시한다. Crawl4AI 샘플 자체에 인증을 추가하려면 세션 처리와 AWS Secrets Manager를 통한 자격 증명 저장, 보안 검토가 필요하다. 따라서 추가 전처리의 필요성뿐 아니라 사이트의 접근 조건도 수집 경로 선택에 영향을 주며, 공개 웹 수집 샘플을 인증 환경으로 확장하는 데에는 별도의 구현 작업이 따른다.

5. 제한된 탐색과 Markdown 추출

AWS CDK 앱은 배포 과정에서 구현을 컨테이너 이미지로 패키징하고, 예약 실행 시 scripts/container_entrypoint.py가 수집·업로드·수집 작업 시작을 순서대로 실행한다. 수집 코드는 JavaScript가 활성화된 헤드리스 브라우저와 BFSDeepCrawlStrategy를 사용하며, 각 시작 URL에서 남은 페이지 수와 최대 깊이를 반영하고 범위 필터를 적용한다. 선택적 URL 포함·제외 패턴, CSS 선택자, robots.txt 확인 여부, 요청 지연 설정도 수집 동작을 제어하며, 전체 구현에는 시작 URL 간 속도 조절과 리디렉션 검사 등이 포함된다. 결과 처리에서는 리디렉션 후 실제 목적지가 범위에 들어오는지 다시 검사하고, 정규화된 URL로 중복을 제거하며, 성공한 결과 중 Markdown이 있는 페이지만 문서로 기록한다. 추출 결과는 fit_markdown을 우선 사용하고 raw_markdown이나 문자열 결과로 대체하며, Markdown을 택한 이유는 원시 HTML 전체를 넘기지 않으면서 제목·목록·표를 보존하기 위해서다.

6. Amazon S3 업로드와 메타데이터 규칙

업로드 단계는 준비된 Markdown 문서와 대응하는 메타데이터 사이드카를 설정된 Amazon S3 버킷의 s3Prefix 아래로 전송한다. 문서가 page.md라면 사이드카는 전체 원본 파일명에 .metadata.json을 붙인 page.md.metadata.json이어야 하며, 문서와 동일한 S3 위치에 저장된다. Amazon Bedrock의 사이드카 크기 제한은 10 KB이고, 샘플은 이를 초과할 경우 두 파일 중 어느 것도 쓰기 전에 오류로 실행을 중단한다. 각 속성은 관리형과 고객 관리형 지식 기반의 Amazon S3 데이터 소스가 모두 받아들이는 형식으로 자료형을 명시하며, 예시는 문자열 source_url, 숫자 crawled_at_epoch, 문자열 content_category를 보여준다. 전체 구현은 제목·수집 시각·콘텐츠 유형·사용자 정의 속성도 추가하고, 업로드 대상은 현재 수집에서 생성된 경로로 한정하므로 로컬에 남은 오래된 파일은 전송되지 않는다.

7. 청킹 전략과 검색 품질 평가

문서가 Amazon S3에 준비되면 수집 파이프라인이 이를 처리하며, 관리형 지식 기반은 기본적으로 콘텐츠에 맞는 파싱 방식을 자동 선택하는 관리형 파서를 사용한다. 청킹 전략은 데이터 소스를 연결할 때 선택하고 이후에는 변경할 수 없으므로, 운영용 데이터 소스를 만들기 전에 선택지를 평가해야 한다. 관리형 지식 기반의 기본 청킹은 300토큰 고정 크기와 20% 중첩을 사용하고, 별도의 고정 크기 청킹에서는 최대 토큰 수와 중첩 비율을 지정할 수 있으며, 청킹 없음은 이미 분할된 콘텐츠 등의 파일 하나를 단일 청크로 취급한다. 청크 경계와 검색 결과는 콘텐츠 및 전략에 따라 달라지므로 대표 페이지와 평가 질문으로 비교해야 하며, 나중에 전략을 바꾸려면 새 데이터 소스를 생성해야 한다. 고객 관리형 지식 기반은 이와 함께 의미 기반·계층형 청킹과 추가 파싱 옵션도 제공하므로, 두 유형의 처리 선택지가 완전히 같지는 않다.

8. 수집 작업 시작과 배포 설명의 범위

샘플은 Amazon S3 업로드 이후 StartIngestionJob을 호출해 준비된 문서가 지식 기반에서 처리되도록 한다. 제시된 Python 함수는 설정된 리전의 bedrock-agent 클라이언트를 만들고 knowledgeBaseId와 dataSourceId를 전달한 뒤, 응답에서 ingestionJobId를 반환한다. StartIngestionJob과 GetIngestionJob은 관리형과 고객 관리형 지식 기반 모두에서 사용할 수 있으며, 수집 진행 상황은 콘솔에서도 확인할 수 있다. 이어지는 배포 설명은 AWS CDK로 워크플로를 AWS 계정에 배포하고 완료 후 정리 절차로 리소스를 제거하도록 안내하며, 두 유형 사이에서는 지식 기반 사전 준비 요건이 다르다고 명시한다. 다만 제공된 원문은 사전 요건 목록 중 AWS 계정과 관리형 지식 기반의 리전 가용성 및 생성 안내를 소개하는 도중에 끝나므로, 이후의 구체적인 배포·검색 검증·정리 절차는 이 입력만으로 확인할 수 없다.

🧾 핵심 주장 / 시사점

• Crawl4AI 도입 여부는 웹 수집 자체의 필요성보다 콘텐츠를 얼마나 정제하고 통제해야 하는지에 따라 판단하는 구조다. 관리형 커넥터로 충분한 경우와 별도 준비 단계가 필요한 경우를 구분하는 것이 글의 출발점이다.
• Markdown과 메타데이터 사이드카는 사용자 정의 전처리 결과를 Amazon Bedrock Knowledge Bases의 관리형 처리로 연결한다. 따라서 수집 범위와 메타데이터 설계는 전처리 단계에서, 청킹과 검색 품질은 지식 기반 처리 단계에서 함께 살펴야 한다.
• 준비된 문서의 품질만으로 검색 품질이 보장되지는 않는다. 휴리스틱 가지치기 결과와 청킹 전략을 대표 콘텐츠로 평가해야 하며, 특히 청킹 전략 변경에 새 데이터 소스가 필요하다는 제약이 초기 선택의 중요성을 높인다.

✅ 액션 아이템

• Amazon Bedrock Web Crawler의 수집 범위·JavaScript 처리·인증 옵션으로 요구사항을 충족하는지 검토하고, 본문 정제나 사용자 정의 메타데이터가 필요하면 Crawl4AI 경로 선택.
• Crawl4AI의 대표 Markdown 출력과 CSS 선택자 적용 결과를 검토하고, 메타데이터 사이드카의 10 KB 제한 및 공개 페이지 전용 제약 확인.
• 대표 페이지와 평가 질문으로 300토큰·20% 중첩 기본 청킹 및 다른 청킹 전략의 검색 결과를 비교한 뒤 데이터 소스 연결 시 적용할 전략 결정.

❓ 열린 질문

• 대상 웹 콘텐츠는 Amazon Bedrock Web Crawler로 충분히 수집할 수 있는가, 아니면 Crawl4AI의 본문 정제·범위 제어·사용자 정의 메타데이터가 필요한가?
• Crawl4AI의 공개 페이지 전용 제약과 메타데이터 사이드카의 10 KB 제한은 대상 콘텐츠의 요구사항을 충족하는가?
• 대표 페이지와 평가 질문에서 300토큰·20% 중첩 기본 청킹은 고정 크기 청킹이나 청킹 없음과 비교해 어떤 검색 결과를 보이는가?