편집

다음을 통해 공유


청크

Azure AI 서비스
Azure AI Search
Azure OpenAI Service
Azure Machine Learning

이제 테스트 문서 및 쿼리를 수집하고 준비 단계에서 문서 분석을 수행했으므로 다음 단계는 청크 분할입니다. 문서를 의미 체계적으로 관련된 콘텐츠가 포함된 오른쪽 크기의 청크 컬렉션으로 분할하는 것은 RAG(Retrieval-augmented Generation) 구현의 성공의 핵심 요소입니다. 전체 문서 또는 대형 청크를 전달하는 것은 비용이 많이 들고 모델의 토큰 한도를 초과할 수 있으며 최상의 결과를 생성하지 못합니다. 쿼리와 관련이 없는 언어 모델에 정보를 전달하면 환각이 발생할 수 있습니다. 관련 정보를 전달하고 관련 없는 정보를 제거하는 프로세스를 최적화해야 합니다. 효과적인 청크 분할 및 검색 전략을 사용하여 가양성 및 진양성을 최소화하고 참 긍정 및 참 부정을 최대화하여 이 최적화를 수행합니다.

너무 작고 쿼리를 해결하기에 충분한 컨텍스트가 없는 청크를 전달하면 결과가 저하됩니다. 여러 청크에 존재하는 관련 컨텍스트는 캡처되지 않을 수 있습니다. 이 아트는 특정 문서 형식과 해당 구조 및 콘텐츠에 대한 효과적인 청크 분할 방법을 구현하고 있습니다. 적용된 문서의 유형과 구조에 따라 각각 고유한 비용 영향과 효율성을 고려하여 고려해야 할 다양한 청크 접근 방식이 있습니다.

이 문서에서는 다양한 청크 분할 방법을 설명하고 문서의 구조가 선택한 청크 분할 방식에 어떻게 영향을 줄 수 있는지 살펴봅니다.

이 문서는 시리즈의 일부입니다. 소개를 읽습니다.

청크 경제

전체 청크 분할 전략을 결정할 때는 문서 모음에 대한 품질 및 처리량 요구 사항과 함께 예산을 고려해야 합니다. 각 고유한 청크 구현의 디자인 및 구현에 대한 엔지니어링 비용과 접근 방식에 따라 다른 문서당 처리 비용이 있습니다. 문서에 포함된 미디어 또는 연결된 미디어가 있는 경우 해당 요소를 처리하는 경제성을 고려해야 합니다. 청크의 경우 이 처리는 일반적으로 언어 모델을 사용하여 미디어에 대한 설명을 생성하고 해당 설명은 청크로 분할됩니다. 일부 미디어의 다른 접근 방식은 추론 시 다중 모달 모델에 있는 그대로 전달하는 것이지만, 이러한 접근 방식은 청크 경제에 영향을 미치지 않습니다.

이 섹션에서는 청크 이미지와 전체 솔루션의 경제성을 모두 살펴봅니다.

이미지 청크 경제

언어 모델을 사용하여 이미지에 대한 설명을 생성한 다음 청크로 분할하는 데 드는 비용이 있습니다. 예를 들어 Azure OpenAI와 같은 클라우드 기반 서비스는 트랜잭션당 기본 또는 선불 프로비저닝 기준으로 요금을 청구합니다. 이미지가 클수록 비용이 더 많이 듭니다. 문서 분석을 통해 청크에 중요한 이미지와 무시해야 하는 이미지를 결정해야 합니다. 여기에서 솔루션에 있는 이미지의 수와 크기를 이해해야 하며 이미지 설명을 청크하는 값을 해당 설명을 생성하는 비용과 비교할 수 있어야 합니다.

처리할 이미지를 결정하는 한 가지 방법은 Azure AI 비전과 같은 서비스를 사용하여 이미지를 분류하거나, 이미지를 태그 지정하거나, 로고 검색을 수행하는 것입니다. 그런 다음 결과 및 신뢰도 지표를 사용하여 이미지가 의미 있는 상황별 값을 추가하고 처리해야 하는지 여부를 결정할 수 있습니다. Azure AI 비전에 대한 호출은 언어 모델 호출보다 비용이 적게 들 수 있으므로 이 방법을 사용하면 비용을 절감할 수 있습니다. 데이터에 가장 적합한 결과를 제공하는 신뢰도 수준과 분류 또는 태그를 확인하기 위해 실험해야 합니다. 또 다른 옵션은 사용자 고유의 분류자 모델을 빌드하는 것입니다. 고유한 분류자 모델을 빌드, 호스팅 및 유지 관리하는 데 드는 비용을 고려해야 합니다.

또 다른 비용 최적화는 캐시 배제 패턴을 사용하여 캐싱하는 것입니다. 이미지의 해시에 따라 키를 생성할 수 있습니다. 첫 번째 단계로 이전 실행 또는 이전에 처리된 문서에서 캐시된 결과가 있는지 확인할 수 있습니다. 이 경우 해당 결과를 사용할 수 있습니다. 이 방법을 사용하면 분류자 또는 언어 모델을 호출하는 비용에서 비롯됩니다. 캐시가 없는 경우 분류자 또는 언어 모델을 호출할 때 결과를 캐시합니다. 이 이미지에 대한 향후 호출은 캐시를 사용합니다.

이러한 모든 비용 최적화 프로세스를 통합하는 간단한 워크플로는 다음과 같습니다.

  1. 이미지 처리가 캐시되었는지 확인합니다. 그렇다면 캐시된 결과를 사용합니다.
  2. 분류자를 실행하여 이미지를 처리해야 하는지 확인합니다. 분류 결과를 캐시합니다. 분류 논리가 이를 지시하는 경우에만 계속 진행합니다.
  3. 이미지에 대한 설명을 생성합니다. 결과를 캐시합니다.

전체 솔루션의 경제성

다음은 전체 솔루션의 비용을 살펴볼 때 고려해야 할 요소입니다.

  • 고유한 청크 구현 수 - 각 고유 구현에는 엔지니어링 및 유지 관리 비용이 모두 있습니다. 모음의 고유한 문서 형식 수와 각각에 대한 고유한 구현의 비용 대 품질 장단위를 고려해야 합니다.
  • 각 구현의 문서별 비용 - 일부 청크 접근 방식은 더 나은 품질 청크로 이어질 수 있지만 이러한 청크를 생성하기 위한 재무 및 임시 비용이 더 높습니다. 예를 들어 Azure AI 문서 인텔리전스에서 미리 빌드된 모델을 사용하면 순수 텍스트 구문 분석 구현보다 문서당 비용이 더 높을 수 있지만 청크가 향상될 수 있습니다.
  • 초기 문서 수 - 솔루션을 시작하기 위해 처리해야 하는 초기 문서 수입니다.
  • 증분 문서 수 - 시스템의 지속적인 유지 관리를 위해 처리해야 하는 새 문서의 수와 비율입니다.

로드 및 청크

논리적으로 청크 분할 중에 먼저 문서를 어떤 형식으로 메모리에 로드해야 합니다. 청크 코드는 문서의 메모리 내 표현에 대해 작동합니다. 로드 코드를 청크 분할과 결합하도록 선택하거나 로드를 자체 단계로 분리할 수 있습니다. 선택하는 방법은 주로 아키텍처 제약 조건 및 기본 설정에 따라 결정됩니다. 이 섹션에서는 두 옵션을 간략하게 탐색한 다음 몇 가지 일반적인 권장 사항을 제공합니다.

별도의 로딩 및 청크

로드 및 청크 단계를 구분하도록 선택할 수 있는 몇 가지 이유가 있습니다. 로딩 코드에서 논리를 캡슐화할 수 있습니다. 특히 처리 시간 또는 비용을 절약하기 위해 다양한 청크 순열을 실험하는 경우 청크 분할 전에 로드 코드의 결과를 유지할 수 있습니다. 마지막으로 PII 제거와 관련된 프로세스 격벽 처리 또는 보안 구분과 같은 아키텍처상의 이유로 별도의 프로세스에서 로드 및 청크 코드를 실행할 수 있습니다.

로드 코드에서 논리 캡슐화

로드 단계에서 전처리 논리를 캡슐화하도록 선택할 수 있습니다. 이렇게 하면 전처리를 수행할 필요가 없으므로 청크 코드가 간소화됩니다. 전처리는 워터마크, 머리글, 바닥글 등 문서 분석에서 무시하려는 문서의 일부를 제거하거나 주석을 추가하는 것만큼 간단하거나 문서 서식을 다시 지정하는 것만큼 복잡할 수 있습니다. 다음은 로드 단계에서 캡슐화하도록 선택할 수 있는 전처리의 몇 가지 예입니다.

  • 무시하려는 항목을 제거하거나 주석을 추가합니다.
  • 이미지 참조를 이미지 설명으로 대체합니다. 이 단계에서는 LLM을 사용하여 이미지에 대한 설명을 생성하고 해당 설명으로 문서를 업데이트합니다. 문서 분석에서 이미지에 중요한 컨텍스트를 제공하는 주변 텍스트가 있다고 판단한 경우 이미지와 함께 LLM에 전달합니다.
  • Azure Data Lake와 같은 파일 스토리지에 이미지를 다운로드하거나 복사하여 문서 텍스트와 별도로 처리합니다. 문서 분석에서 이미지에 중요한 컨텍스트를 제공하는 주변 텍스트가 있다고 판단한 경우 파일 스토리지에 이미지와 함께 이 텍스트를 저장해야 합니다.
  • 테이블을 더 쉽게 처리할 수 있도록 다시 포맷합니다.

로드 코드의 결과 유지

로드 코드의 결과를 유지하기 위해 선택할 수 있는 여러 가지 이유가 있습니다. 한 가지 이유는 문서를 로드하고 미리 처리한 후 청크 논리가 실행되기 전에 검사하는 기능을 원하는 경우입니다. 또 다른 이유는 개발 또는 프로덕션 환경에서 동일한 사전 처리된 코드에 대해 서로 다른 청크 논리를 실행할 수 있기 때문입니다. 로드된 코드를 유지하면 이 프로세스의 속도가 빨라지게 됩니다.

별도의 프로세스에서 코드 로드 및 청크 분할 실행

로드 및 청크 코드를 별도의 프로세스로 분리하면 동일한 사전 처리된 코드에 대해 여러 청크 분할 구현을 실행할 수 있습니다. 또한 이러한 분리를 통해 다른 컴퓨팅 환경 및 다른 하드웨어에서 로드 및 청크 코드를 실행할 수 있습니다. 또한 이 디자인을 사용하면 로드 및 청크에 사용되는 컴퓨팅의 크기를 독립적으로 조정할 수 있습니다.

로드 및 청크 결합

대부분의 경우 로드 및 청크 코드를 결합하는 것이 더 간단한 구현입니다. 별도의 로드 단계에서 전처리에서 수행할 수 있는 대부분의 작업은 청크 분할 단계에서 수행할 수 있습니다. 예를 들어 이미지 URL을 로드 단계의 설명으로 바꾸는 대신 청크 논리는 LLM을 호출하여 텍스트 설명을 얻고 설명을 청크할 수 있습니다.

이미지에 대한 참조가 있는 태그가 있는 HTML과 같은 문서 형식이 있는 경우 청크 코드에서 사용하는 판독기 또는 파서가 태그를 제거하지 않도록 해야 합니다. 청크 코드는 이미지 참조를 식별할 수 있어야 합니다.

권장 사항

다음은 청크 논리를 결합할지 구분할지 결정할 때 고려해야 할 몇 가지 권장 사항입니다.

  • 로딩 및 청크 논리 결합으로 시작합니다. 솔루션에 필요한 경우 분리합니다.
  • 프로세스를 분리하도록 선택하는 경우 문서를 중간 형식으로 변환하지 마십시오. 이와 같은 작업은 손실될 수 있습니다.

청크 접근 방식

이 섹션에서는 몇 가지 일반적인 청크 분할 방법에 대한 개요를 제공합니다. 이 목록은 완전하지 않고 일반적인 몇 가지 대표적인 접근 방식입니다. 언어 모델을 사용하여 나열된 여러 접근 방식과 이미지의 텍스트 표현을 가져오는 것과 같이 구현에서 여러 가지 방법을 사용할 수 있습니다.

각 접근 방식에는 도구, 관련 비용 등을 강조 표시하는 요약된 의사 결정 매트릭스가 함께 제공됩니다. 엔지니어링 작업 및 처리 비용은 주관적이며 상대적 비교를 위해 포함됩니다.

문장 기반 구문 분석

이 간단한 방법은 텍스트 문서를 전체 문장으로 구성된 청크로 나눕니다. 이 방법의 이점은 구현 비용이 저렴하고, 처리 비용이 낮으며, 산문으로 작성된 텍스트 기반 문서 또는 전체 문장에 적용할 수 있다는 것입니다. 이 접근 방식의 과제는 각 청크가 생각이나 의미의 전체 컨텍스트를 캡처하지 못할 수 있다는 것입니다. 의미 체계적 의미를 포착하려면 여러 문장을 함께 사용해야 하는 경우가 많습니다.

도구: SpaCy sentence tokenizer, LangChain recursive text splitter, NLTK sentence tokenizer
엔지니어링 작업: 낮음
처리 비용: 낮음
사용 사례: 산문으로 작성된 구조화되지 않은 문서 또는 전체 문장 및 문서 모음에는 개별 청크 전략을 작성하기 위한 다양한 문서 형식이 포함됩니다
: 설문 조사, 포럼 게시물, 리뷰, 전자 메일 메시지, 소설 또는 에세이의 개방형 피드백과 같은 사용자 생성 콘텐츠

고정 크기 구문 분석(중첩 포함)

이 방법은 고정된 수의 문자 또는 토큰에 따라 문서를 청크로 분할하고 청크 간에 문자가 일부 겹칠 수 있도록 합니다. 이 방법은 문장 기반 구문 분석과 동일한 장점과 단점이 많이 있습니다. 이 방법이 문장 기반 구문 분석보다 장점은 여러 문장에 걸쳐 있는 의미 체계를 사용하여 청크를 가져올 수 있다는 것입니다.

청크의 고정 크기와 겹치는 양을 선택해야 합니다. 결과는 문서 형식마다 다르기 때문에 HuggingFace 청크 시각화 도우미와 같은 도구를 사용하여 예비 분석을 수행하는 것이 가장 좋습니다. 이와 같은 도구를 사용하면 결정을 내릴 때 문서가 청크되는 방식을 시각화할 수 있습니다. 고정 크기 구문 분석을 사용하는 경우 문자 수에 대해 BERT 토큰을 사용하는 것이 가장 좋습니다. BERT 토큰은 의미 있는 언어 단위를 기반으로 하므로 문자 수보다 더 많은 의미 체계 정보를 유지합니다.

도구: LangChain recursive text splitter, Hugging Face chunk visualizer
엔지니어링 작업: 낮음
처리 비용: 낮음
사용 사례: 전체 또는 불완전한 문장이 있는 산문 또는 비문으로 작성된 구조화되지 않은 문서입니다. 문서 모음에는 개별 청크 전략을 작성하기 위한 다양한 문서 형식이 포함되어 있습니다
: 설문 조사, 포럼 게시물, 리뷰, 전자 메일 메시지, 개인 또는 연구 노트 또는 목록의 개방형 피드백과 같은 사용자 생성 콘텐츠

사용자 지정 코드

이 방법은 사용자 지정 코드를 사용하여 청크를 만드는 문서를 구문 분석합니다. 이 방법은 구조가 알려져 있거나 유추될 수 있고 청크 생성에 대한 높은 수준의 제어가 필요한 텍스트 기반 문서에 가장 성공합니다. 정규식과 같은 텍스트 구문 분석 기술을 사용하여 문서 구조 내의 패턴에 따라 청크를 만들 수 있습니다. 목표는 길이가 비슷한 청크 및 고유한 콘텐츠가 있는 청크를 만드는 것입니다. 많은 프로그래밍 언어는 정규식을 지원하며, 일부 언어에는 더 우아한 문자열 조작 기능을 제공하는 라이브러리 또는 패키지가 있습니다.

도구: Python (re, regex, BeautifulSoup, lxml, html5lib, marko), R (stringr, xml2), Julia (Gumbo.jl)
엔지니어링 작업: 중간
처리 비용: 낮음
사용 사례: 구조를 유추할 수 있는 반구조화된 문서
: 특허 출원, 연구 논문, 보험 정책, 스크립트 및 시나리오

언어 모델 확대

언어 모델을 사용하여 청크를 만들 수 있습니다. 일반적인 사용 사례는 GPT-4와 같은 큰 언어 모델을 사용하여 청크로 사용할 수 있는 테이블의 텍스트 표현 또는 테이블 요약을 생성하는 것입니다. 언어 모델 확대는 사용자 지정 코드와 같은 다른 청크 접근 방식과 함께 사용됩니다.

문서 분석 섹션의 이미지 부분에서 이미지 앞이나 뒤의 텍스트가 몇 가지 질문에 답하는 데 필요하다고 경우 이 추가 컨텍스트를 언어 모델에 전달해야 합니다. 이 추가 컨텍스트가 솔루션의 성능을 향상시키거나 개선하지 않는지 여부를 확인하기 위해 실험하는 것이 중요합니다.

청크 논리가 이미지 설명을 여러 청크로 분할하는 경우 각 청크에 이미지 URL을 포함해야 합니다. 각 청크에 이미지 URL을 포함하면 이미지에서 제공하는 모든 쿼리에 대해 메타데이터가 반환됩니다. 특히 최종 사용자가 해당 URL을 통해 원본 이미지에 액세스할 수 있는 기능이 필요하거나 유추 시간 동안 원시 이미지를 사용하려는 시나리오에 대해 메타데이터가 반환됩니다.

도구: Azure OpenAI, OpenAI
엔지니어링 작업: 중간
처리 비용: 높음
사용 사례: 이미지, 테이블
: 테이블 및 이미지의 텍스트 표현 생성, 모임, 연설, 인터뷰 또는 팟캐스트의 대본 요약

문서 레이아웃 분석

문서 레이아웃 분석 라이브러리 및 서비스는 OCR(광학 문자 인식) 기능을 딥 러닝 모델과 결합하여 문서 구조와 텍스트를 모두 추출합니다. 구조적 요소에는 머리글, 바닥글, 제목, 섹션 머리글, 표 및 그림이 포함될 수 있습니다. 목표는 문서에 포함된 콘텐츠에 더 나은 의미 체계적 의미를 제공하는 것입니다.

문서 레이아웃 분석 라이브러리 및 서비스는 문서의 구조 및 텍스트 콘텐츠를 나타내는 모델을 노출합니다. 모델과 상호 작용하는 코드를 작성해야 합니다.

참고 항목

Azure AI 문서 인텔리전스는 문서를 서비스에 업로드해야 하는 클라우드 기반 서비스입니다. 보안 및 규정 준수 규정을 통해 다음과 같은 서비스에 문서를 업로드할 수 있는지 확인해야 합니다.

도구: Azure AI Document Intelligence document analysis models, Donut, Layout Parser
엔지니어링 작업: 중간
처리 비용: 중간
사용 사례: 반구조화된 문서
: 뉴스 기사, 웹 페이지, 이력서

미리 빌드된 모델

다양한 문서 형식에 활용할 수 있는 미리 빌드된 모델을 제공하는 Azure AI 문서 인텔리전스와 같은 서비스가 있습니다. 일부 모델은 미국 세금 W-2 양식과 같은 특정 문서 형식에 대해 학습되는 반면, 다른 모델은 청구서와 같은 광범위한 문서 형식을 대상으로 합니다.

도구: Azure AI Document Intelligence prebuilt models, Power Automate Intelligent Document Processing, LayoutLMv3
엔지니어링 작업: 낮음
처리 비용: 중간/높음
사용 사례: 미리 빌드된 모델이 있는 구조적 문서
특정 예제: 청구서, 영수증, 건강 보험 카드, W-2 양식

사용자 지정 모델

미리 빌드된 모델이 없는 고도로 구조화된 문서의 경우 사용자 지정 모델을 빌드해야 할 수 있습니다. 이 방법은 고도로 구조화된 이미지 또는 문서에 효과적일 수 있으므로 텍스트 구문 분석 기술을 사용하기가 어렵습니다.

도구: Azure AI Document Intelligence custom models, Tesseract
엔지니어링 작업: 높음
처리 비용: 중간/높음
사용 사례: 미리 빌드된 모델이 없는 구조적 문서
: 자동차 수리 및 유지 관리 일정, 교육 기록 및 기록, 기술 설명서, 운영 절차, 유지 관리 지침

문서 구조

문서는 구조의 양에 따라 다릅니다. 정부 양식과 같은 일부 문서에는 W-2 미국 세금 문서와 같이 복잡하고 잘 알려진 구조가 있습니다. 스펙트럼의 다른 쪽 끝에는 자유 형식 노트와 같은 구조화되지 않은 문서가 있습니다. 문서 형식의 구조 정도는 효과적인 청크 분할 방법을 결정하기 위한 좋은 출발점입니다. 딱딱하고 빠른 규칙은 없지만 이 섹션에서는 따라야 할 몇 가지 지침을 제공합니다.

Diagram showing chunking approaches by document structure.문서 구조별 청크 접근 방식을 보여 주는 다이어그램.

그림 1 문서 구조에 맞는 청크 처리 방식

구조화된 문서

고정 형식 문서라고도 하는 구조화된 문서에는 레이아웃이 정의되어 있습니다. 이러한 문서의 데이터는 고정된 위치에 있습니다. 예를 들어 날짜 또는 고객 패밀리 이름은 동일한 고정 형식의 모든 문서에서 동일한 위치에 있습니다. 고정 서식 문서의 예로는 W-2 미국 세금 문서가 있습니다.

수정된 서식 문서는 손으로 채워지거나 복잡한 레이아웃 구조가 있는 원본 문서의 이미지를 스캔하여 기본 텍스트 구문 분석 방법을 사용하여 처리하기 어려울 수 있습니다. 복잡한 문서 구조를 처리하는 일반적인 방법은 기계 학습 모델을 사용하여 데이터를 추출하고 가능한 경우 해당 데이터에 의미 체계 의미를 적용하는 것입니다.

: W-2 양식, 보험 카드
일반적인 방법: 미리 빌드된 모델, 사용자 지정 모델

반구조화된 문서

반구조화된 문서에는 W-2 양식과 같은 고정된 형식이나 스키마가 없지만 형식이나 스키마에 대한 일관성을 제공합니다. 예를 들어 모든 청구서는 동일하게 배치되지 않지만 일반적으로 일관된 스키마가 있습니다. 청구서에는 invoice numberbill toship to 형태의 이름과 주소가 포함될 것으로 예상할 수 있습니다. 웹 페이지에는 스키마 일관성이 없을 수 있지만 구조 또는 레이아웃 요소(예: body, title, H1, p)가 비슷하며 주변 텍스트에 의미 체계 의미를 추가하는 데 사용할 수 있습니다.

구조화된 문서와 마찬가지로 복잡한 레이아웃 구조의 반구조화된 문서는 텍스트 구문 분석으로 처리하기가 어렵습니다. 이러한 문서 형식의 경우 기계 학습 모델이 좋은 방법입니다. 청구서, 계약 또는 건강 보험과 같은 일관된 스키마가 있는 특정 도메인에 대해 미리 빌드된 모델이 있습니다. 미리 빌드된 모델이 없는 복잡한 구조체에 대한 사용자 지정 모델을 빌드하는 것이 좋습니다.

: 청구서, 영수증, 웹 페이지, markdown 파일
일반적인 방법: 문서 분석 모델

유추된 구조체

일부 문서에는 구조가 있지만 태그로 작성되지 않습니다. 이러한 문서의 경우 구조를 유추해야 합니다. 좋은 예는 다음 EU 규정 문서입니다.

Diagram showing an EU regulation as an example of a document with inferred structure.유추된 구조가 있는 문서의 예로 EU 규정을 보여 주는 다이어그램

그림 2. 유추된 구조를 보여주는 EU 규정

문서의 구조를 명확하게 이해할 수 있고 알려진 모델이 없으므로 사용자 지정 코드를 작성할 수 있는지 확인할 수 있습니다. 이와 같은 문서 형식은 작업 중인 이 유형의 여러 문서 수에 따라 사용자 지정 모델을 만들기 위한 노력을 보증하지 않을 수 있습니다. 예를 들어 모음이 모든 EU 규정 또는 미국 주법인 경우 사용자 지정 모델이 좋은 방법일 수 있습니다. 예제의 EU 규정과 같은 단일 문서로 작업하는 경우 사용자 지정 코드가 더 비용 효율적일 수 있습니다.

: 법률 문서, 스크립트, 제조 사양
일반적인 방법: 사용자 지정 코드, 사용자 지정 모델

비구조화된 문서

구조가 거의 없거나 전혀 없는 문서에 적합한 방법은 겹치는 접근 방식을 사용하는 문장 기반 또는 고정 크기입니다.

: 설문 조사, 포럼 게시물 또는 리뷰, 전자 메일 메시지, 개인 또는 연구 노트 또는 목록의 개방형 피드백과 같은 사용자 생성 콘텐츠
일반적인 방법: 문장 기반 또는 겹치는 경계 기반

실험

각 청크 접근 방식에 가장 적합한 방법이 나열되어 있지만 실제로는 모든 방법 중 어느 것이든 문서 유형에 적합할 수 있습니다. 예를 들어 문장 기반 구문 분석이 고도로 구조화된 문서에 적합하거나 사용자 지정 모델이 구조화되지 않은 문서에 적합할 수 있습니다. RAG 솔루션 최적화의 일부는 리소스 수, 리소스의 기술 기술 및 처리해야 하는 문서 볼륨을 고려하여 다양한 청크 분할 방법을 실험하는 것입니다. 최적의 청크 분할 전략을 달성하려면 테스트하는 각 방법의 장점과 장단점을 관찰하여 사용 사례에 적합한 방법을 선택해야 합니다.

다음 단계