기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon Bedrock Knowledge Bases 작동 방식 Amazon Bedrock Knowledge Bases는 데이터 저장소에서 정보를 가져와 대규모 언어 모델(LLM)에서 생성된 응답을 보강하는 것으로 널리 사용되는 기술인 검색 증강 생성(RAG)을 활용할 수 있도록 도와줍니다. 데이터 소스로 지식 기반을 설정하면 애플리케이션에서 지식 기반을 쿼리하여 소스에서 직접 인용하거나 쿼리 결과에서 생성된 자연스러운 응답으로 쿼리에 답하는 정보를 반환할 수 있습니다. Amazon Bedrock Knowledge Bases를 사용하면 지식 기반을 쿼리하여 검색한 컨텍스트를 통해 보강된 애플리케이션을 구축할 수 있습니다. 복잡한 구축 파이프라인을 축약하고 바로 사용할 수 있는 RAG 솔루션을 제공하여 애플리케이션 빌드 시간을 단축함으로써 출시 시간을 단축할 수 있습니다. 지식 기반을 추가하면 프라이빗 데이터를 활용하기 위해 모델을 지속적으로 학습시킬 필요가 없으므로 비용 효율성도 향상됩니다. 다음 다이어그램은 RAG가 수행되는 방식을 개략적으로 보여 줍니다. 지식 기반은 이 프로세스의 여러 단계를 자동화하여 RAG의 설정 및 구현을 간소화합니다. **비정형 데이터 사전 처리** 구조화된 프라이빗 데이터(구조화된 데이터 스토어에 존재하지 않는 데이터)에서 효과적으로 검색할 수 있도록 하기 위한 일반적인 방법은 데이터를 텍스트로 변환하고 이를 관리 가능한 청크로 분할하는 것입니다. 그런 다음 청크는 원본 문서와의 매핑을 유지하면서 임베딩으로 변환되고 벡터 인덱스에 작성됩니다. 이러한 임베딩은 데이터 소스의 쿼리와 텍스트 간의 시맨틱 유사성을 결정하는 데 사용됩니다. 아래 이미지에서는 벡터 데이터베이스의 데이터 사전 처리 과정을 보여줍니다. ![\[검색 증강 생성을 위한 데이터 사전 처리\]](http://docs.aws.amazon.com/ko_kr/bedrock/latest/userguide/images/kb/rag-preprocess.png) 벡터 임베딩은 각 텍스트 청크를 나타내는 일련의 숫자입니다. 모델은 각 텍스트 청크를 벡터라고 하는 일련의 숫자로 변환하므로 텍스트를 수학적으로 비교할 수 있습니다. 이러한 벡터는 부동 소수점 숫자(float32) 또는 바이너리 숫자일 수 있습니다. Amazon Bedrock에서 지원하는 대부분의 임베딩 모델은 기본적으로 부동 소수점 벡터를 사용합니다. 그러나 일부 모델은 바이너리 벡터를 지원합니다. 바이너리 임베딩 모델을 선택하는 경우 바이너리 벡터를 지원하는 모델 및 벡터 스토어도 선택해야 합니다. 차원당 1비트만 사용하는 이진 벡터는 차원당 32비트를 사용하는 부동 소수점(float32) 벡터만큼 스토리지 비용이 많이 들지 않습니다. 그러나 이진 벡터는 텍스트 표현에서 부동 소수점 벡터만큼 정확하지 않습니다. 다음 예제에서는 텍스트 조각을 세 가지 표현으로 보여줍니다. **** | 표시 | 값 | | --- | --- | | 텍스트 | “Amazon Bedrock은 선도적인 AI 회사 및 Amazon의 고성능 파운데이션 모델을 사용합니다.” | | 부동 소수점 벡터 | [0.041..., 0.056..., -0.018..., -0.012..., -0.020..., ...] | | 이진 벡터 | [1,1,0,0,0, ...] | **런타임 실행** 런타임 시 임베딩 모델을 사용하여 사용자 쿼리를 벡터로 변환합니다. 그런 다음, 벡터 인덱스를 쿼리하여 문서 벡터와 사용자 쿼리 벡터를 비교하는 방식으로 사용자 쿼리와 의미상 유사한 문서를 찾습니다. 마지막 단계에서는 벡터 인덱스에서 검색된 청크의 추가 컨텍스트를 사용하여 사용자 프롬프트를 증강합니다. 그런 다음 추가 컨텍스트와 함께 프롬프트가 모델로 전송되어 사용자를 위한 응답을 생성합니다. 아래 이미지에서는 RAG가 런타임 시 어떤 방식으로 작동하여 사용자 쿼리에 대한 응답을 증강하는지 보여줍니다. ![\[런타임 시 검색 증강 생성\]](http://docs.aws.amazon.com/ko_kr/bedrock/latest/userguide/images/kb/rag-runtime.png) 데이터를 지식 기반으로 전환하는 방법, 지식 기반을 설정한 후 쿼리하는 방법, 수집 중에 데이터 소스에 적용할 수 있는 사용자 지정에 대해 자세히 알아보려면 다음 주제를 참조하세요. **Topics** + [데이터를 지식 기반으로 전환](kb-how-data.md) + [Amazon Bedrock Knowledge Bases를 사용하여 데이터 소스에서 정보 검색](kb-how-retrieval.md) + [지식 기반 사용자 지정](kb-how-customization.md) # 데이터를 지식 기반으로 전환 지식 기반을 생성하려면 지식 기반이 액세스할 수 있도록 하려는 지원되는 데이터 소스에 연결합니다. 지식 기반은 사용자 쿼리에 응답하거나 검색된 데이터를 기반으로 응답을 생성할 수 있습니다. Amazon Bedrock Knowledge Bases는 테이블, 차트, 다이어그램 및 기타 이미지가 포함된 텍스트, 이미지 또는 멀티모달 문서를 비롯한 다양한 문서를 지원합니다. *멀티모달* 데이터는 텍스트와 시각적 데이터의 조합을 나타냅니다. 비정형 데이터가 포함된 파일 유형의 예로는 텍스트, 마크다운, HTML 및 PDF가 있습니다. 다음 섹션에서는 Amazon Bedrock Knowledge Bases가 지원하는 데이터 유형과 각 데이터 유형에 대해 지식 기반을 연결할 수 있는 서비스에 대해 설명합니다. ## 비정형 데이터 비정형 데이터는 사전 정의된 구조로 강제되지 않는 데이터를 말합니다. Amazon Bedrock Knowledge Bases는 다음 서비스에 연결하여 지식 기반에 비정형 데이터를 추가할 수 있도록 지원합니다. + Amazon S3 + Confluence(미리 보기) + Microsoft SharePoint(미리 보기) + Salesforce(미리 보기) + Web Crawler(미리 보기) + 사용자 지정 데이터 소스(동기화할 필요 없이 데이터를 지식 기반으로 직접 수집할 수 있음) 데이터 소스에는 문서의 원시 형식이 포함됩니다. 쿼리 프로세스를 최적화하기 위해 지식 기반은 원시 데이터를 데이터의 수치 표현인 *벡터 임베딩*으로 변환하여 벡터 임베딩으로도 변환되는 쿼리와의 유사성을 정량화합니다. Amazon Bedrock Knowledge Bases는 데이터 소스를 변환하는 과정에서 다음 리소스를 사용합니다. + 임베딩 모델 - 데이터를 벡터 임베딩으로 변환하는 파운데이션 모델입니다. 텍스트와 이미지를 모두 포함하는 멀티모달 데이터의 경우 Amazon Titan Multimodal Embeddings G1 또는 Cohere Embed v3와 같은 멀티모달 임베딩 모델을 사용할 수 있습니다. + 벡터 스토어 - 데이터의 벡터 표현을 저장하는 서비스입니다. 다음 벡터 스토어가 지원됩니다. + Amazon OpenSearch Serverless + Amazon Neptune + Amazon Aurora(RDS) + Pinecone + Redis Enterprise Cloud + MongoDB 아틀라스 데이터를 벡터 임베딩으로 변환하는 프로세스를 *수집*이라고 합니다. 데이터를 지식 기반으로 전환하는 수집 프로세스에는 다음 단계가 포함됩니다. **수집** 1. 데이터는 선택한 구문 분석기에 의해 구문 분석됩니다. 구문 분석에 대한 자세한 내용은 [데이터 소스에 대한 구문 분석 옵션](kb-advanced-parsing.md) 섹션을 참조하세요. 1. 데이터 소스의 각 문서는 토큰 수 및 기타 파라미터로 정의할 수 있는 데이터의 하위 분할인 *청크*로 분할됩니다. 청킹에 대한 자세한 내용은 [지식 기반에서 콘텐츠 청킹 작동 방식](kb-chunking.md) 섹션을 참조하세요. 1. 선택한 임베딩 모델은 데이터를 벡터 임베딩으로 변환합니다. 멀티모달 콘텐츠의 경우 이미지는 시각적 벡터로 포함되고 텍스트는 텍스트 벡터로 포함되므로 두 모달 모두에서 검색할 수 있습니다. 1. 벡터 임베딩은 선택한 벡터 스토어의 벡터 인덱스에 기록됩니다. 수집 프로세스가 완료되면 지식 기반을 쿼리할 준비가 된 것입니다. 지식 기반에서 정보를 쿼리하고 검색하는 방법에 대한 자세한 내용은 [Amazon Bedrock Knowledge Bases를 사용하여 데이터 소스에서 정보 검색](kb-how-retrieval.md) 섹션을 참조하세요. 데이터 소스를 변경하는 경우 추가, 수정 및 삭제에 대한 변경 사항을 지식 기반에 동기화해야 합니다. 일부 데이터 소스는 지식 기반으로 파일을 직접 수집하거나 삭제할 수 있도록 지원하므로 데이터 소스 수정 및 수집을 별도의 단계로 처리하고 항상 전체 동기화를 수행할 필요가 없습니다. 문서를 지식 기반 및 이를 지원하는 데이터 소스에 직접 수집하는 방법을 알아보려면 [변경 사항을 지식 기반에 직접 수집](kb-direct-ingestion.md) 섹션을 참조하세요. Amazon Bedrock Knowledge Bases는 데이터 수집 방식을 사용자 지정하는 다양한 옵션을 제공합니다. 이 프로세스의 사용자 지정에 대한 자세한 내용은 [지식 기반 사용자 지정](kb-how-customization.md) 섹션을 참조하세요. ## 구조화된 데이터 구조화된 데이터는 존재하는 데이터 스토어에 의해 사전 정의된 형식의 테이블 형식 데이터를 나타냅니다. Amazon Bedrock Knowledge Bases는 Amazon Redshift 쿼리 엔진을 통해 지원되는 구조화된 데이터 스토어에 연결됩니다. Amazon Bedrock Knowledge Bases는 쿼리 패턴, 쿼리 기록 및 스키마 메타데이터를 분석하여 자연어 쿼리를 SQL 쿼리로 변환하는 완전관리형 메커니즘을 제공합니다. 이렇게 변환된 쿼리는 지원되는 데이터 소스에서 관련 정보를 검색하는 데 사용됩니다. Amazon Bedrock Knowledge Bases는 다음 서비스에 연결하여 지식 기반에 구조화된 데이터 스토어를 추가할 수 있도록 지원합니다. + Amazon Redshift + AWS Glue Data Catalog(AWS Lake Formation) 지식 기반을 구조화된 데이터 스토어에 연결하는 경우 데이터를 벡터 임베딩으로 변환할 필요가 없습니다. 대신 Amazon Bedrock Knowledge Bases는 구조화된 데이터 스토어를 직접 쿼리할 수 있습니다. 쿼리 중에 Amazon Bedrock Knowledge Bases는 사용자 쿼리를 SQL 쿼리로 변환하여 사용자 쿼리와 관련된 데이터를 검색하고 더 정확한 응답을 생성할 수 있습니다. 데이터를 검색하지 않고 SQL 쿼리를 생성하고 다른 워크플로에서 사용할 수도 있습니다. 예를 들어 데이터베이스 리포지토리에는 고객 및 구매에 대한 정보가 포함된 다음 테이블이 포함되어 있습니다. **** | 고객 ID | 2020년에 구매한 금액 | 2021년에 구매한 금액 | 2022년에 구매한 금액 | 현재까지 구매한 총 금액 | | --- | --- | --- | --- | --- | | 1 | 200 | 300 | 500 | 1000 | | 2 | 150 | 100 | 120 | 370 | | 3 | 300 | 300 | 300 | 900 | | 4 | 720 | 180 | 100 | 900 | | 5 | 500 | 400 | 100 | 1000 | | 6 | 900 | 800 | 1000 | 2700 | | 7 | 470 | 420 | 400 | 1290 | | 8 | 250 | 280 | 250 | 780 | | 9 | 620 | 830 | 740 | 2190 | | 10 | 300 | 200 | 300 | 800 | 사용자 쿼리에 "상위 5개 지출 고객에 대한 요약 제공"이라고 표시되면 지식 기반에서 다음을 수행할 수 있습니다. + 쿼리를 SQL 쿼리로 변환합니다. + 테이블에서 다음을 포함하는 발췌문을 반환합니다. + 관련 테이블 열 "고객 ID" 및 "현재까지 총 구매 금액" + 지출이 가장 많은 고객 10명의 총 구매 금액이 포함된 테이블 행 + 어떤 고객이 상위 5개 지출 고객이고 얼마나 많이 구매했는지를 설명하는 응답을 생성합니다. 지식 기반이 테이블 발췌문을 생성할 수 있는 쿼리의 다른 예는 다음과 같습니다. + “2020년 지출 기준 상위 5개 고객” + "2020년 구매 금액별 상위 고객" + “2020-2022의 구매 금액별 상위 5개 고객” + “2020-2022년 지출이 가장 많은 상위 5개 고객” + “총 구매 금액이 \$110 미만인 고객” + "최저 지출 고객 5명" 쿼리가 더 구체적이거나 세부적일수록 지식 기반에서 반환할 정확한 정보의 범위를 좁힐 수 있습니다. 예를 들어 쿼리 "2020년 지출 기준 상위 10개 고객" 대신에 보다 구체적인 쿼리는 "2020년 현재까지 고객의 총 구매 금액 중 가장 높은 10개를 찾습니다"입니다. 특정 쿼리는 고객 지출 데이터베이스 테이블의 열 이름 "총 구매 금액 종료 날짜"를 참조하며 데이터를 "가장 높음"으로 정렬해야 함을 나타냅니다. # Amazon Bedrock Knowledge Bases를 사용하여 데이터 소스에서 정보 검색 지식 기반을 설정한 후 애플리케이션을 설정하여 해당 지식 기반의 데이터 소스를 쿼리할 수 있습니다. 지식 기반을 쿼리하려면 다음 API 작업을 활용할 수 있습니다. + [https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_Retrieve.html](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_Retrieve.html) - 쿼리와 가장 관련성이 높은 데이터에서 소스 청크 또는 이미지를 검색하고 응답에서 이를 배열로 반환합니다. + [https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_RetrieveAndGenerate.html](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_RetrieveAndGenerate.html) - Amazon Bedrock의 [InvokeModel](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModel.html) 작업과 `Retrieve`를 조인하여 쿼리와 가장 관련성이 높은 데이터에서 소스 청크를 검색하고 자연어 응답을 생성합니다. 데이터의 특정 소스 청크에 대한 인용을 포함합니다. 데이터 소스에 시각적 요소가 포함된 경우 모델은 텍스트 응답을 생성할 때 이러한 이미지의 인사이트를 활용하고 이미지에 대한 소스 속성을 제공합니다. + [GenerateQuery](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_GenerateQuery.html) - 자연어 사용자 쿼리를 구조화된 데이터 스토어에 적합한 형식의 쿼리로 변환합니다. `RetrieveAndGenerate` 작업은 기본적으로 `GenerateQuery`(지식 기반이 구조화된 데이터 스토어에 연결된 경우) `Retrieve` 및 `InvokeModel`을 사용하여 전체 RAG 프로세스를 수행하는 결합된 작업입니다. Amazon Bedrock Knowledge Bases는 `Retrieve` 작업에 대한 액세스 권한도 제공하므로 RAG의 단계를 분리하여 특정 사용 사례에 맞게 사용자 지정할 수 있는 유연성이 있습니다. `Retrieve` 또는 `RetrieveAndGenerate`를 사용할 때 [순위 변경 모델](rerank.md)을 사용하여 쿼리 중에 검색된 문서의 관련성 순위를 다시 매길 수도 있습니다. 지식 기반을 쿼리할 때 이러한 API 작업을 사용하는 방법을 알아보려면 [쿼리 및 응답을 사용하여 지식 기반 테스트](knowledge-base-test.md) 섹션을 참조하세요. # 지식 기반 사용자 지정 Amazon Bedrock Knowledge Bases는 데이터 소스가 지식 기반으로 처리되는 방식을 사용자 지정하여 데이터를 저장, 구문 분석 및 최종 사용자에게 반환하는 방법에 유연성을 제공하는 옵션을 제공합니다. 지식 기반을 설정하는 동안 고려할 수 있는 사용자 지정 옵션에 대해 자세히 알아보려면 다음 주제 중 하나를 선택합니다. **Topics** + [지식 기반에서 콘텐츠 청킹 작동 방식](kb-chunking.md) + [데이터 소스에 대한 구문 분석 옵션](kb-advanced-parsing.md) + [사용자 지정 변환 Lambda 함수를 사용하여 데이터 수집 방법 정의](kb-custom-transformation.md) + [데이터 소스에 메타데이터를 포함하여 지식 기반 쿼리 개선](kb-metadata.md) # 지식 기반에서 콘텐츠 청킹 작동 방식 데이터를 수집할 때 Amazon Bedrock은 먼저 효율적인 데이터 검색을 위해 문서 또는 콘텐츠를 관리 가능한 청크로 분할합니다. 그런 다음 청크는 원본 문서와의 매핑을 유지하면서 임베딩으로 변환되고 벡터 인덱스(데이터의 벡터 표현)에 작성됩니다. 벡터 임베딩을 사용하면 텍스트를 양적으로 비교할 수 있습니다. **Topics** + [표준 청킹](#kb-standard-chunking) + [계층적 청킹](#kb-hiearchical-chunking) + [시맨틱 청킹](#kb-semantic-chunking) + [멀티모달 콘텐츠 청킹](#kb-multimodal-chunking) ## 표준 청킹 Amazon Bedrock은 청킹에 대해 다음과 같은 표준 접근 방식을 지원합니다. **참고** 텍스트 청킹 전략은 텍스트 문서에만 적용됩니다. 멀티모달 콘텐츠(오디오, 비디오, 이미지)의 경우 청킹은 이러한 텍스트 기반 전략이 아닌 임베딩 모델 수준에서 발생합니다. + 고정 크기 청킹: 청크당 토큰 수와 중복 비율을 지정하여 원하는 청크 크기를 구성할 수 있으므로 특정 요구 사항에 맞는 유연한 조정이 가능합니다. 청크당 초과할 수 없는 최대 토큰 수와 연속된 청크 간의 오버랩 비율을 설정할 수 있습니다. **참고** 구문 분석된 콘텐츠(예: 고급 구문 분석기를 사용하거나 HTML에서 변환된 콘텐츠)의 경우 Amazon Bedrock 지식 기반은 최상의 결과를 위해 콘텐츠를 청크하여 최적화할 수 있습니다. 청커는 논리적 문서 경계(예: 페이지 또는 섹션)를 존중하며 최대 토큰 크기를 늘리면 더 큰 청크가 허용되더라도 이러한 경계를 넘어 콘텐츠를 병합하지 않습니다. + 기본 청킹: 콘텐츠를 약 300개의 토큰으로 구성된 텍스트 청크로 분할합니다. 청킹 프로세스는 문장 경계를 고려하여 각 청크 내에 완전한 문장이 유지되도록 합니다. 문서에 대해 청킹 없음을 선택할 수도 있습니다. 그러면 각 문서가 단일 텍스트 청크로 처리됩니다. 청킹 접근 방식/전략으로 청킹 없음을 선택하려면 먼저 문서를 별도의 파일로 분할하여 사전 처리하는 것이 좋습니다. 문서에 청킹을 선택하지 않으면 인용에서 페이지 번호를 보거나 *x-amz-bedrock-kb-document-page-number* 메타데이터 필드/속성을 기준으로 필터링할 수 없습니다. ## 계층적 청킹 계층적 청킹에는 하위 청크와 상위 청크의 중첩 구조로 정보를 구성하는 작업이 포함됩니다. 데이터 소스를 만들 때 상위 청크 크기와 하위 청크 크기, 각 청크 간의 오버랩 토큰 수를 정의할 수 있습니다. 검색 과정에서 시스템이 하위 청크를 먼저 검색하지만, 모델에 보다 포괄적인 컨텍스트를 제공할 수 있도록 이후에 이를 더 광범위한 상위 청크로 대체합니다. 작은 텍스트 임베딩은 더 정확하지만, 검색에서는 포괄적인 컨텍스트를 목표로 합니다. 계층적 청킹 시스템은 필요한 경우 검색된 하위 청크를 상위 청크로 대체하여 이러한 요구 사항의 균형을 맞춥니다. **참고** 하위 청크는 검색 중에 상위 청크로 대체되므로 반환된 결과 수가 요청된 양보다 적을 수 있습니다. S3 벡터 버킷을 벡터 스토어로 사용할 때는 계층적 청킹이 권장되지 않습니다. 청킹에 많은 수의 토큰을 사용하는 경우(합계 8,000개 이상의 토큰) 메타데이터 크기 제한이 발생할 수 있습니다. 계층적 청킹에서 Amazon Bedrock Knowledge Bases는 청킹에 대해 두 가지 수준 또는 다음과 같은 깊이를 지정할 수 있도록 지원합니다. + 상위: 최대 상위 청크 토큰 크기를 설정합니다. + 하위: 최대 하위 청크 토큰 크기를 설정합니다. 청크 간 오버랩 토큰도 설정합니다. 연속된 상위 청크와 연속된 하위 청크 간 오버랩 토큰의 절대 수를 설정합니다. ## 시맨틱 청킹 시맨틱 청킹은 텍스트를 의미 있는 청크로 나누어 이해도와 정보 검색을 향상시키는 자연어 처리 기법입니다. 이는 단지 구문 구조가 아닌 의미적 콘텐츠에 집중하여 검색 정확도를 개선하는 것을 목표로 합니다. 이렇게 하면 관련 정보를 보다 정확하게 추출하고 조작할 수 있습니다. 시맨틱 청킹을 구성할 때 다음과 같은 하이퍼파라미터를 지정할 수 있습니다. + 최대 토큰: 문장 경계를 고려하면서 단일 청크에 포함되어야 하는 최대 토큰 수입니다. + 버퍼 크기: 지정된 문장의 경우 버퍼 크기는 임베딩 생성을 위해 추가할 주변 문장 수를 정의합니다. 예를 들어 버퍼 크기가 1이면 3개의 문장(현재, 이전 및 다음 문장)이 결합되고 임베딩됩니다. 이 파라미터는 각 청크의 경계를 결정하기 위해 함께 검사되는 텍스트의 양에 영향을 미칠 수 있으며, 이는 결과 청크의 세분성과 일관성에 영향을 미칩니다. 버퍼 크기가 클수록 더 많은 컨텍스트를 캡처할 수 있지만, 노이즈가 발생할 수도 있습니다. 또한 버퍼 크기가 작을수록 중요한 컨텍스트를 놓칠 수 있지만, 더 정확한 청킹을 보장할 수 있습니다. + 중단점 백분위수 임계값: 문장 사이의 중단점을 찾기 위한 문장 간 거리/유사성의 백분위수 임계값입니다. 더 높은 임계값을 적용하려면 문장을 여러 부분으로 나눌 수 있도록 문장의 구별이 더 쉬워야 합니다. 임계값이 높을수록 청크 수가 줄어들고 일반적으로 평균 청크 크기가 커집니다. **참고** 파운데이션 모델을 사용하기 때문에 시맨틱 청킹을 사용하면 추가 비용이 발생합니다. 비용은 보유한 데이터의 양에 따라 달라집니다. 파운데이션 모델의 비용에 대한 자세한 내용은 [Amazon Bedrock 요금](https://aws.amazon.com/bedrock/pricing/)을 참조하세요. ## 멀티모달 콘텐츠 청킹 멀티모달 콘텐츠(오디오, 비디오, 이미지)의 경우 청킹 동작은 텍스트 문서와 다릅니다. + **Nova 멀티모달 임베딩:** 청킹은 임베딩 모델 수준에서 발생합니다. 오디오 및 비디오 청크 지속 시간을 1\$130초(기본값: 5초)로 구성할 수 있습니다. 비디오 파일의 경우 비디오에 오디오가 포함되어 있더라도 비디오 청크 기간만 적용됩니다. 오디오 청크 지속 시간은 독립 실행형 오디오 파일에만 적용됩니다. + **Bedrock Data Automation(BDA) 구문 분석기:** 콘텐츠는 먼저 텍스트(트랜스크립트 및 장면 요약)로 변환된 다음 변환된 텍스트에 표준 텍스트 청킹 전략이 적용됩니다. **참고** Nova 멀티모달 임베딩을 사용하는 경우 지식 기반에 구성된 텍스트 청킹 전략은 오디오, 비디오 또는 이미지 파일이 아닌 데이터 소스의 텍스트 문서에만 영향을 미칩니다. # 데이터 소스에 대한 구문 분석 옵션 구문 분석이란 원시 데이터에서 콘텐츠를 이해하고 추출하는 것을 말합니다. Amazon Bedrock Knowledge Bases는 수집 중에 데이터 소스를 구문 분석하기 위한 다음 옵션을 제공합니다. + **Amazon Bedrock 기본 구문 분석기** - .txt, .md, .html, .doc/.docx, .xls/.xlsx 및 .pdf 파일을 포함한 텍스트 파일의 텍스트만 구문 분석합니다. 이 구문 분석기에는 사용 요금이 발생하지 않습니다. **참고** 기본 구문 분석기는 텍스트만 출력하므로 문서에 그림, 차트, 테이블 또는 이미지가 포함된 경우 Amazon Bedrock Data Automation 또는 파운데이션 모델을 기본 구문 분석기 대신 구문 분석기로 사용하는 것이 좋습니다. Amazon Bedrock Data Automation 및 파운데이션 모델은 문서에서 이러한 요소를 추출하여 출력으로 반환할 수 있습니다. + Amazon Bedrock Knowledge Bases는 .jpeg 및 .png 이미지 파일 외에도 .pdf 파일의 그림, 차트 및 테이블을 포함한 멀티모달 데이터를 구문 분석하는 다음과 같은 구문 분석기를 제공합니다. 또한 이러한 파서는 이러한 그림, 차트, 테이블 및 이미지를 추출하여 지식 기반 생성 중에 지정한 S3 대상에 파일로 저장할 수 있습니다. 지식 기반 검색 중에 이러한 파일을 응답 또는 소스 속성으로 반환할 수 있습니다. + **Amazon Bedrock 데이터 자동화** - 추가 프롬프트를 제공할 필요 없이 멀티모달 데이터를 효과적으로 처리하는 완전관리형 서비스입니다. 이 구문 분석기의 비용은 문서의 페이지 수 또는 처리할 이미지 수에 따라 달라집니다. 이 서비스에 대한 자세한 내용은 [Amazon Bedrock 데이터 자동화](bda.md)를 참조하세요. + **파운데이션 모델** - 파운데이션 모델을 사용하여 멀티모달 데이터를 처리합니다. 이 구문 분석기는 데이터 추출에 사용되는 기본 프롬프트를 사용자 지정하는 옵션을 제공합니다. 이 구문 분석기의 비용은 파운데이션 모델에서 처리한 입력 및 출력 토큰 수에 따라 달라집니다. Amazon Bedrock Knowledge Bases 데이터 구문 분석을 지원하는 모델 목록은 [구분 분석에 지원되는 모델 및 리전](knowledge-base-supported.md#knowledge-base-supported-parsing) 섹션을 참조하세요. **중요** Amazon Bedrock Data Automation 또는 파운데이션 모델을 구문 분석기로 선택하면 .pdf 파일에 텍스트만 포함되어 있더라도 선택한 메서드를 사용하여 데이터 소스의 모든 .pdf 파일을 구문 분석합니다. 기본 구문 분석기는 이러한 .pdf 파일을 구문 분석하는 데 사용되지 않습니다. 계정에 Amazon Bedrock Data Automation 또는 파운데이션 모델을 사용하여 이러한 파일을 구문 분석하면 요금이 부과됩니다. 데이터 구문 분석 방법을 선택할 때는 다음 사항을 고려하세요. + 데이터가 순전히 텍스트인지 아니면 지식 기반이 쿼리할 수 있게 하려는 이미지, 그래프 및 차트와 같은 멀티모달 데이터가 포함되어 있는지 여부입니다. + 데이터를 구문 분석하는 방법을 모델에 지시하는 데 사용되는 프롬프트를 옵션을 사용자 지정할지 여부입니다. + 구문 분석기의 비용입니다. Amazon Bedrock Data Automation은 페이지당 요금을 사용하는 반면 파운데이션 모델 파서는 입력 및 출력 토큰을 기준으로 요금을 부과합니다. 자세한 내용은 [Amazon Bedrock 요금](https://aws.amazon.com/bedrock/pricing/)을 참조하세요. + 총 파일 크기 제한입니다. 파운데이션 모델을 구문 분석기로 사용하는 경우 모든 파일의 총 파일 크기는 100GB를 초과할 수 없습니다. 지식 기반 구문 분석 방법을 구성하는 방법을 알아보려면 [데이터 소스를 지식 기반에 연결](data-source-connectors.md)의 데이터 소스에 대한 연결 구성을 참조하세요. # 사용자 지정 변환 Lambda 함수를 사용하여 데이터 수집 방법 정의 사용자 지정 변환 Lambda 함수를 정의하여 지식 기반 수집 프로세스에 자체 로직을 주입할 수 있습니다. Amazon Bedrock Knowledge Bases에서 기본적으로 지원되지 않는 특정 청킹 로직이 있을 수 있습니다. 청킹 없음 전략 옵션을 사용하고 해당 청킹 로직이 포함된 Lambda 함수를 지정합니다. 또한 Lambda 함수에서 청킹할 파일을 작성하려면 지식 기반에 Amazon S3 버킷을 지정해야 합니다. 청킹 후 Lambda 함수는 청킹된 파일을 동일한 버킷에 다시 쓰고 추가 처리를 위해 지식 기반에 대한 참조를 반환합니다. 필요한 경우 S3 버킷에 저장되는 파일의 암호화를 위한 자체 AWS KMS 키를 제공할 수 있습니다. **참고** 웹 커넥터를 사용하는 경우 HTML 대신 마크다운 텍스트가 Lambda에 전달됩니다. 또는 청크 수준 메타데이터를 지정하고 지식 기반이 기본적으로 지원되는 청킹 전략 중 하나를 적용하도록 할 수도 있습니다. 이 경우 사전 정의된 청킹 전략(예: 기본 또는 고정 크기 청킹) 중 하나를 선택하고 Lambda 함수 및 S3 버킷에 대한 참조를 제공합니다. 이 경우 지식 기반은 사전 정의된 S3 버킷에 구문 분석 및 사전 청킹된 파일을 저장한 후 Lambda 함수를 직접적으로 호출하여 청크 수준 메타데이터를 추가합니다. 청크 수준 메타데이터를 추가한 후 Lambda 함수는 청킹된 파일을 동일한 버킷에 다시 쓰고 추가 처리를 위해 지식 기반에 대한 참조를 반환합니다. 충돌이 발생할 경우 청크 수준 메타데이터가 우선하며 파일 수준 메타데이터를 덮어씁니다. 사용자 지정 청킹에 Python Lambda 함수를 사용하는 예제는 [Lambda 함수를 사용하여 사용자 지정 청킹](https://github.com/aws-samples/amazon-bedrock-samples/blob/main/rag/knowledge-bases/features-examples/03-optimizing-accuracy-retrieved-results/advanced_chunking_options.ipynb)을 참조하세요. API 및 파일 계약은 아래 구조를 참조하세요. **Lambda 함수를 사용하여 사용자 지정 변환을 추가할 때의 API 계약** ``` { ... "vectorIngestionConfiguration": { "customTransformationConfiguration": { // Custom transformation "intermediateStorage": { "s3Location": { // the location where input/output of the Lambda is expected "uri": "string" } }, "transformations": [{ "transformationFunction": { "transformationLambdaConfiguration": { "lambdaArn": "string" } }, "stepToApply": "string" // enum of POST_CHUNKING }] }, "chunkingConfiguration": { "chunkingStrategy": "string", "fixedSizeChunkingConfiguration": { "maxTokens": "number", "overlapPercentage": "number" } ... } } } ``` **사용자 지정 Lambda 변환 입력 형식** ``` { "version": "1.0", "knowledgeBaseId": "string", "dataSourceId": "string", "ingestionJobId": "string", "bucketName": "string", "priorTask": "string", "inputFiles": [{ "originalFileLocation": { "type": "S3", "s3_location": { "uri": "string" } }, "fileMetadata": { "key1": "value1", "key2": "value2" }, "contentBatches": [{ "key":"string" }] }] } ``` **사용자 지정 Lambda 변환 출력 형식** ``` { "outputFiles": [{ "originalFileLocation": { "type": "S3", "s3_location": { "uri": "string" } }, "fileMetadata": { "key1": "value1", "key2": "value2" }, "contentBatches": [{ "key": "string" }] }] } ``` **에서 참조된 객체에 대한 파일 형식`fileContents`** ``` { "fileContents": [{ "contentBody": "...", "contentType": "string", // enum of TEXT, PDF, ... "contentMetadata": { "key1": "value1", "key2": "value2" } } ... ] } ``` # 데이터 소스에 메타데이터를 포함하여 지식 기반 쿼리 개선 CSV(쉼표로 구분된 값) 파일을 수집할 때 지식 기반이 특정 열을 콘텐츠 필드와 메타데이터 필드로 취급하도록 할 수 있습니다. 이제 수백 또는 수천 개의 콘텐츠/메타데이터 파일 페어를 처리하는 대신 단일 CSV 파일과 해당 metadata.json 파일을 사용해 CSV 내의 각 열을 처리하는 방법에 대한 지식 기반 힌트를 제공할 수 있습니다. 청크당 문서 메타데이터 필드/속성에는 한도가 있습니다. [지식 기반 할당량](https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.html)을 참조하세요 CSV 파일을 수집하기 전에 다음을 확인합니다. + CSV가 RFC4180 형식이며 UTF-8로 인코딩되어 있습니다. + CSV의 첫 번째 행에 헤더 정보가 포함되어 있습니다. + metadata.json 파일에 제공된 메타데이터 필드가 CSV에 열로 표시됩니다. + 다음 형식의 fileName.csv.metadata.json 파일을 제공해야 합니다. ``` { "metadataAttributes": { "${attribute1}": "${value1}", "${attribute2}": "${value2}", ... }, "documentStructureConfiguration": { "type": "RECORD_BASED_STRUCTURE_METADATA", "recordBasedStructureMetadata": { "contentFields": [ { "fieldName": "string" } ], "metadataFieldsSpecification": { "fieldsToInclude": [ { "fieldName": "string" } ], "fieldsToExclude": [ { "fieldName": "string" } ] } } } } ``` CSV 파일은 한 번에 한 행씩 구문 분석되고 청킹 전략과 벡터 임베딩이 콘텐츠 필드에 적용됩니다. Amazon Bedrock Knowledge Bases는 현재 하나의 콘텐츠 필드를 지원합니다. 콘텐츠 필드는 청크로 분할되고 각 청크와 연결된 메타데이터 필드(열)는 문자열 값으로 처리됩니다. 예를 들어 'Description' 열과 'Creation\$1Date' 열이 있는 CSV가 있다고 가정해 보겠습니다. 설명 필드는 콘텐츠 필드이고 생성 날짜는 연결된 메타데이터 필드입니다. 설명 텍스트는 청크로 분할되고 CSV의 각 행에 대해 벡터 임베딩으로 변환됩니다. 생성 날짜 값은 날짜를 문자열로 표현한 것으로 취급되며 설명의 각 청크와 연결됩니다. 포함/제외 필드가 제공되지 않으면 콘텐츠 열을 제외한 모든 열이 메타데이터 열로 처리됩니다. 포함 필드만 제공된 경우 제공된 열만 메타데이터로 처리됩니다. 제외 필드만 제공된 경우 제외 열을 제외한 모든 열이 메타데이터로 처리됩니다. `fieldsToInclude` 및 `fieldsToExclude` 모두에서 동일한 `fieldName`을 제공하는 경우 Amazon Bedrock은 검증 예외를 발생시킵니다. 포함과 제외 사이에 충돌이 있는 경우 실패로 이어집니다. CSV 내에서 발견된 빈 행은 무시되거나 건너뜁니다.