RAG에 대한 구조화되지 않은 데이터 파이프라인 빌드

이 문서에서는 Gen AI 애플리케이션에 대한 구조화되지 않은 데이터 파이프라인을 빌드하는 방법을 설명합니다. 구조화되지 않은 파이프라인은 RAG(Retrieval-Augmented Generation) 애플리케이션에 특히 유용합니다.

텍스트 파일 및 PDF와 같은 구조화되지 않은 콘텐츠를 AI 에이전트 또는 다른 검색자가 쿼리할 수 있는 벡터 인덱스로 변환하는 방법을 알아봅니다. 또한 파이프라인을 실험하고 조정하여 청크 분할, 인덱싱 및 구문 분석 데이터를 최적화하여 파이프라인 문제를 해결하고 실험하여 더 나은 결과를 얻을 수 있도록 하는 방법을 알아봅니다.

비정형 데이터 파이프라인 노트북

다음 노트북에서는 이 문서의 정보를 활용하여 비구조화된 데이터 파이프라인을 만드는 방법을 보여 줍니다.

Databricks 비정형 데이터 파이프라인

노트북 받기

데이터 파이프라인의 주요 구성 요소

비정형 데이터를 사용하는 모든 RAG 애플리케이션의 기본은 데이터 파이프라인입니다. 이 파이프라인은 RAG 애플리케이션이 효과적으로 사용할 수 있는 형식으로 구조화되지 않은 데이터를 큐레이팅하고 준비하는 작업을 담당합니다.

이 데이터 파이프라인은 사용 사례에 따라 복잡해질 수 있지만 RAG 애플리케이션을 처음 빌드할 때 고려해야 하는 주요 구성 요소는 다음과 같습니다.

1. 코퍼스 구성 및 수집: 특정 사용 사례에 따라 올바른 데이터 원본 및 콘텐츠를 선택합니다.
2. 데이터 전처리: 원시 데이터를 포함 및 검색에 적합한 깨끗하고 일관된 형식으로 변환합니다.
   1. 구문 분석: 적절한 구문 분석 기술을 사용하여 원시 데이터에서 관련 정보를 추출합니다.
   2. 보강: 추가 메타데이터를 사용하여 데이터를 보강하고 노이즈를 제거합니다.
      1. 메타데이터 추출: 유용한 메타데이터를 추출하여 더 빠르고 효율적인 데이터 검색을 구현합니다.
      2. 중복 제거: 문서를 분석하여 중복되거나 거의 중복된 문서를 식별하고 제거합니다.
      3. 필터링: 컬렉션에서 관련이 없거나 원치 않는 문서를 제거합니다.
3. 청크 분할: 효율적인 검색을 위해 구문 분석된 데이터를 더 작고 관리하기 쉬운 청크로 분할합니다.
4. 임베딩: 청크화된 텍스트 데이터를 의미론적 의미를 포착하는 숫자 벡터 표현으로 변환합니다.
5. 인덱싱 및 스토리지: 최적화된 검색 성능을 위한 효율적인 벡터 인덱스를 만듭니다.

코퍼스 구성 및 수집

RAG 애플리케이션은 올바른 데이터 모음 없이 사용자 쿼리에 응답하는 데 필요한 정보를 검색할 수 없습니다. 올바른 데이터는 전적으로 애플리케이션의 특정 요구 사항 및 목표에 따라 달라지므로 사용 가능한 데이터의 미묘한 차이를 이해하는 데 시간을 할애하는 것이 중요합니다. 자세한 내용은 생성 AI 앱 개발자 워크플로를 참조하세요.

예를 들어 고객 지원 봇을 빌드할 때 다음을 포함하는 것이 좋습니다.

• 기술 자료 문서
• FAQ(질문과 대답)
• 제품 설명서 및 사양
• 문제 해결 가이드

모든 프로젝트의 시작 부분에서 도메인 전문가 및 이해 관계자를 참여시켜 데이터 모음의 품질과 범위를 향상시킬 수 있는 관련 콘텐츠를 식별하고 큐레이팅할 수 있습니다. 사용자가 제출할 가능성이 있는 쿼리 유형에 대한 인사이트를 제공하고 포함할 가장 중요한 정보의 우선 순위를 지정하는 데 도움이 될 수 있습니다.

Databricks는 확장 가능하고 증분 방식으로 데이터를 수집하는 것이 좋습니다. Azure Databricks는 SaaS 애플리케이션 및 API 통합을 위한 완전 관리형 커넥터를 포함하여 데이터 수집을 위한 다양한 방법을 제공합니다. 모범 사례로 원시 원본 데이터를 수집하여 대상 테이블에 저장해야 합니다. 이 방법은 데이터 보존, 추적 가능성 및 감사를 보장합니다. Lakeflow Connect의 표준 커넥터를 참조하세요.

데이터 전처리

데이터를 로드한 후에는 원시 데이터를 정리하고 임베딩 및 검색에 적합한 일관된 형식으로 지정해야 합니다.

구문 분석

검색기 애플리케이션에 적합한 데이터 원본을 식별한 후 다음 단계는 원시 데이터에서 필요한 정보를 추출하는 것입니다. 구문 분석이라고 하는 이 프로세스에는 구조화되지 않은 데이터를 RAG 애플리케이션이 효과적으로 사용할 수 있는 형식으로 변환하는 작업이 포함됩니다.

사용하는 특정 구문 분석 기술 및 도구는 작업 중인 데이터 유형에 따라 달라집니다. 예시:

• 텍스트 문서(PDF, Word 문서):비정형 및 PyPDF2와 같은 기존 라이브러리는 다양한 파일 형식을 처리하고 구문 분석 프로세스를 사용자 지정하기 위한 옵션을 제공할 수 있습니다.
• HTML 문서:BeautifulSoup 및 lxml 과 같은 HTML 구문 분석 라이브러리를 사용하여 웹 페이지에서 관련 콘텐츠를 추출할 수 있습니다. 이러한 라이브러리는 HTML 구조를 탐색하고, 특정 요소를 선택하고, 원하는 텍스트 또는 특성을 추출하는 데 도움이 될 수 있습니다.
• 이미지 및 스캔한 문서: OCR(광학 문자 인식) 기술은 일반적으로 이미지에서 텍스트를 추출하는 데 필요합니다. 인기 있는 OCR 라이브러리에는 Tesseract 또는 Amazon Textract, Azure AI Vision OCR 및 Google Cloud Vision API와 같은 SaaS 버전과 같은 오픈 소스 라이브러리가 포함됩니다.

데이터 구문 분석을 위한 모범 사례

구문 분석은 데이터가 깨끗하고 구조화되어 임베딩 생성 및 벡터 검색을 위한 준비가 갖춰지도록 합니다. 데이터를 구문 분석할 때 다음 모범 사례를 고려하세요.

• 데이터 정리: 추출된 텍스트를 전처리하여 머리글, 바닥글 또는 특수 문자와 같은 관련이 없거나 시끄러운 정보를 제거합니다. RAG 체인에서 처리해야 하는 불필요하거나 형식이 잘못된 정보의 양을 줄입니다.
• 오류 및 예외 처리: 오류 처리 및 로깅 메커니즘을 구현하여 구문 분석 프로세스 중에 발생한 문제를 식별하고 해결합니다. 이렇게 하면 문제를 빠르게 식별하고 해결할 수 있습니다. 이렇게 하면 종종 원본 데이터의 품질과 관련된 업스트림 문제를 가리킵니다.
• 구문 분석 논리 사용자 지정: 데이터의 구조 및 형식에 따라 구문 분석 논리를 사용자 지정하여 가장 관련성이 큰 정보를 추출해야 할 수 있습니다. 추가적인 노력이 필요할 수 있지만 필요한 경우 많은 다운스트림 품질 문제를 방지하므로 이 작업을 수행하는 데 시간을 투자합니다.
• 구문 분석 품질 평가: 출력 샘플을 수동으로 검토하여 구문 분석된 데이터의 품질을 정기적으로 평가합니다. 이렇게 하면 구문 분석 프로세스의 개선 영역 또는 문제를 식별하는 데 도움이 될 수 있습니다.

농축

추가 메타데이터를 사용하여 데이터를 보강하고 노이즈를 제거합니다. 보강은 선택 사항이지만 애플리케이션의 전반적인 성능을 크게 향상시킬 수 있습니다.

메타데이터 추출

문서의 콘텐츠, 컨텍스트 및 구조에 대한 필수 정보를 캡처하는 메타데이터를 생성하고 추출하면 RAG 애플리케이션의 검색 품질 및 성능이 크게 향상될 수 있습니다. 메타데이터는 관련성을 향상시키고, 고급 필터링을 사용하도록 설정하고, 도메인별 검색 요구 사항을 지원하는 추가 신호를 제공합니다.

LangChain 및 LlamaIndex와 같은 라이브러리는 연결된 표준 메타데이터를 자동으로 추출할 수 있는 기본 제공 파서를 제공하지만, 이를 특정 사용 사례에 맞게 조정된 사용자 지정 메타데이터로 보완하는 것이 도움이 되는 경우가 많습니다. 이 방법을 사용하면 중요한 도메인별 정보가 캡처되어 다운스트림 검색 및 생성이 향상됩니다. LLM(큰 언어 모델)을 사용하여 메타데이터 향상을 자동화할 수도 있습니다.

메타데이터 유형은 다음과 같습니다.

• 문서 수준 메타데이터: 파일 이름, URL, 작성자 정보, 생성 및 수정 타임스탬프, GPS 좌표 및 문서 버전 관리.
• 콘텐츠 기반 메타데이터: 추출된 키워드, 요약, 토픽, 명명된 엔터티 및 도메인별 태그(PII 또는 HIPAA와 같은 제품 이름 및 범주).
• 구조적 메타데이터: 섹션 머리글, 목차, 페이지 번호 및 의미 체계 콘텐츠 경계(장 또는 하위 섹션)입니다.
• 컨텍스트 메타데이터: 원본 시스템, 수집 날짜, 데이터 민감도 수준, 원래 언어 또는 다국적 지침입니다.

최적의 성능을 위해서는 청크 분할된 문서 또는 해당 포함 항목과 함께 메타데이터를 저장해야 합니다. 또한 검색된 정보를 좁히고 애플리케이션의 정확도와 확장성을 개선하는 데 도움이 됩니다. 또한 메타데이터를 하이브리드 검색 파이프라인에 통합하면 벡터 유사성 검색과 키워드 기반 필터링을 결합하면 특히 큰 데이터 세트 또는 특정 검색 조건 시나리오에서 관련성이 향상됩니다.

중복 제거

원본에 따라 중복된 문서 또는 거의 중복된 문서로 끝날 수 있습니다. 예를 들어 하나 이상의 공유 드라이브에서 가져오는 경우 동일한 문서의 여러 복사본이 여러 위치에 있을 수 있습니다. 이러한 복사본 중 일부는 약간 수정되었을 수 있습니다. 마찬가지로 기술 자료에는 제품 설명서의 복사본이나 블로그 게시물의 초안 복사본이 있을 수 있습니다. 이러한 중복 항목이 코퍼스에 남아 있는 경우 최종 인덱스에 매우 중복된 청크가 있으면 애플리케이션의 성능을 저하시킬 수 있습니다.

메타데이터만 사용하여 일부 중복 항목을 제거할 수 있습니다. 예를 들어 항목의 제목과 생성 날짜가 같지만 여러 원본 또는 위치의 항목이 여러 개 있는 경우 메타데이터를 기준으로 필터링할 수 있습니다.

그러나 이것으로는 충분하지 않을 수 있습니다. 문서의 내용에 따라 중복 항목을 식별하고 제거하려면 지역성을 구분하는 해시라고 하는 기술을 사용할 수 있습니다. 특히 MinHash 라는 기술은 여기에서 잘 작동하며 Spark 구현은 이미 Spark ML에서 사용할 수 있습니다. 포함된 단어에 따라 문서에 대한 해시를 만들어서 작동하며, 해당 해시에 조인하여 중복 항목 또는 거의 중복 항목을 효율적으로 식별할 수 있습니다. 매우 높은 수준에서 이것은 4단계 프로세스입니다.

1. 각 문서에 대한 기능 벡터를 만듭니다. 필요한 경우 불용어 제거, 어근 추출, 어간화와 같은 기술을 적용하여 결과를 개선한 다음 n-그램으로 토큰화할 수 있습니다.
2. MinHash 모델에 맞게 자카드 거리에 MinHash를 사용하여 벡터를 해시합니다.
3. 이러한 해시를 사용하여 유사성 조인을 실행하여 각 중복 문서 또는 거의 중복된 문서에 대한 결과 집합을 생성합니다.
4. 유지하지 않으려는 중복 항목을 필터링합니다.

기준 중복 제거 단계에서는 임의로 유지할 문서를 선택할 수 있습니다(예: 각 중복 결과의 첫 번째 문서 또는 중복 항목 중 임의 선택). 잠재적인 개선은 다른 논리(예: 가장 최근에 업데이트됨, 게시 상태 또는 가장 신뢰할 수 있는 원본)를 사용하여 중복의 "최적" 버전을 선택하는 것입니다. 또한 일치 결과를 개선하기 위해 MinHash 모델에서 사용되는 기능화 단계 및 해시 테이블 수를 실험해야 할 수 있습니다.

자세한 내용은 지역별 해시에 대한 Spark 설명서를 참조하세요.

필터링

모음에 수집한 문서 중 일부는 목적과 무관하거나, 너무 오래되었거나, 신뢰할 수 없거나, 유해한 언어와 같은 문제가 있는 콘텐츠를 포함하기 때문에 에이전트에 유용하지 않을 수 있습니다. 하지만 다른 문서에는 에이전트를 통해 노출하지 않으려는 중요한 정보가 포함될 수 있습니다.

따라서 필터로 사용할 수 있는 예측을 생성하기 위해 문서에 독성 분류자를 적용하는 것과 같은 메타데이터를 사용하여 이러한 문서를 필터링하는 단계를 파이프라인에 포함하는 것이 좋습니다. 또 다른 예는 문서를 필터링하기 위해 PII(개인 식별 정보) 검색 알고리즘을 문서에 적용하는 것입니다.

마지막으로 에이전트에 피드하는 모든 문서 원본은 악의적인 행위자가 데이터 중독 공격을 시작할 수 있는 잠재적인 공격 벡터입니다. 검색 및 필터링 메커니즘을 추가하여 해당 메커니즘을 식별하고 제거하는 것도 고려할 수 있습니다.

청크

원시 데이터를 보다 구조화된 형식으로 구문 분석하고, 중복 항목을 제거하고, 원치 않는 정보를 필터링한 후 다음 단계는 청크라는 더 작고 관리 가능한 단위로 분해하는 것입니다. 큰 문서를 의미 체계적으로 집중된 작은 청크로 분할하면 검색된 데이터가 LLM의 컨텍스트에 맞는지 확인하는 동시에 주의가 산만하거나 관련이 없는 정보가 포함되는 것을 최소화할 수 있습니다. 청크 분할에 대한 선택은 LLM이 제공하는 검색된 데이터에 직접적인 영향을 미치므로 RAG 애플리케이션의 첫 번째 최적화 계층 중 하나입니다.

데이터를 청크 분할할 때 다음 요소를 고려합니다.

• 청크 분할 전략: 원래 텍스트를 청크로 분할하는 데 사용하는 방법. 여기에는 문장별 분할, 단락, 특정 문자/토큰 개수 및 고급 문서별 분할 전략과 같은 기본 기술이 포함될 수 있습니다.
• 청크 크기: 작은 청크는 특정 세부 정보에 초점을 맞출 수 있지만 일부 주변 컨텍스트 정보를 잃을 수 있습니다. 청크가 크면 더 많은 컨텍스트를 캡처할 수 있지만 관련 없는 정보를 포함하거나 계산 비용이 많이 들 수 있습니다.
• 청크 간 겹침: 데이터를 청크로 분할할 때 중요한 정보가 손실되지 않도록 하려면 인접한 청크 간에 일부 겹침을 포함하는 것이 좋습니다. 겹치면 청크 간에 연속성과 컨텍스트를 보존하고 검색 결과를 향상시킬 수 있습니다.
• 의미 체계 일관성: 가능하면 관련 정보를 포함하지만 의미 있는 텍스트 단위로 독립적으로 설 수 있는 의미 체계적으로 일관된 청크를 만드는 것을 목표로 합니다. 단락, 섹션 또는 주제 경계와 같은 원래 데이터의 구조를 고려하여 이 작업을 수행할 수 있습니다.
• 메타데이터:원본 문서 이름, 섹션 제목 또는 제품 이름과 같은 관련 메타데이터는 검색을 향상시킬 수 있습니다. 이 추가 정보는 검색 쿼리를 청크에 일치시킬 수 있습니다.

데이터 조각화 전략

적절한 청크링 메서드를 찾는 것은 반복적이고 컨텍스트에 따라 달라집니다. 만능 해결책은 없습니다. 최적의 청크 크기와 방법은 특정 사용 사례 및 처리 중인 데이터의 특성에 따라 달라집니다. 대체로 청크 분할 전략은 다음과 같이 볼 수 있습니다.

• 고정 크기 청크: 텍스트를 고정된 수의 문자 또는 토큰(예: LangChain CharacterTextSplitter)과 같이 미리 결정된 크기의 청크로 분할합니다. 임의 수의 문자/토큰으로 분할은 빠르고 쉽게 설정할 수 있지만 일반적으로 의미 체계가 일관된 청크가 생성되지 않습니다. 이 방법은 프로덕션 등급 애플리케이션에서 거의 작동하지 않습니다.
• 단락 기반 청크: 텍스트의 자연 단락 경계를 사용하여 청크를 정의합니다. 이 메서드는 단락에 관련 정보(예: LangChain RecursiveCharacterTextSplitter)가 포함된 경우가 많기 때문에 청크의 의미 일관성을 유지하는 데 도움이 될 수 있습니다.
• 형식별 청크: Markdown 또는 HTML과 같은 형식에는 청크 경계(예: markdown 헤더)를 정의할 수 있는 고유 구조가 있습니다. 이러한 용도로 LangChain의 MarkdownHeaderTextSplitter 또는 HTML 헤더/섹션 기반 분할자와 같은 도구를 사용할 수 있습니다.
• 의미 체계 청크: 토픽 모델링과 같은 기술을 적용하여 텍스트의 의미상 일관된 섹션을 식별할 수 있습니다. 이러한 방법은 각 문서의 콘텐츠 또는 구조를 분석하여 토픽 이동에 따라 가장 적절한 청크 경계를 결정합니다. 기본 방법보다 의미 체계 청크가 더 많이 관련되어 있지만, 의미 체계 청크는 텍스트의 자연 의미 체계 구분에 더 잘 맞는 청크를 만드는 데 도움이 될 수 있습니다(예: LangChain SemanticChunker 참조).

예: 크기가 고정된 조각

LangChain의 RecursiveCharacterTextSplitter 를 chunk_size=100 및 chunk_overlap=20과 함께 사용하는 고정 크기 청크 예제입니다. ChunkViz는 Langchain의 문자 분할자와 함께 다양한 청크 크기와 겹치는 값이 결과 청크에 미치는 영향을 시각화하는 인터랙티브 방식을 제공합니다.

임베딩

데이터를 청크 분할한 후 다음 단계는 포함 모델을 사용하여 텍스트 청크를 벡터 표현으로 변환하는 것입니다. 임베딩 모델은 각 텍스트 청크를 의미를 포착하는 벡터 표현으로 변환합니다. 청크를 조밀한 벡터로 나타내면 포함을 통해 검색 쿼리와 의미 체계 유사성에 따라 가장 관련성이 높은 청크를 빠르고 정확하게 검색할 수 있습니다. 검색 쿼리는 데이터 파이프라인에 청크를 포함하는 데 사용되는 것과 동일한 포함 모델을 사용하여 쿼리 시 변환됩니다.

포함 모델을 선택할 때 다음 요소를 고려합니다.

• 모델 선택: 각 포함 모델에는 미묘한 차이가 있으며 사용 가능한 벤치마크는 데이터의 특정 특성을 캡처하지 못할 수 있습니다. 유사한 데이터에 대해 학습된 모델을 선택하는 것이 중요합니다. 특정 작업을 위해 설계된 사용 가능한 임베딩 모델을 탐색하는 것도 도움이 될 수 있습니다. 다양한 시중의 포함 모델을 실험해 보십시오. 이에는 MTEB와 같은 표준 순위표에서 순위가 낮을 수 있는 모델도 포함됩니다. 고려해야 할 몇 가지 예는 다음과 같습니다.
  • GTE-Large-v1.5
  • OpenAI의 텍스트 임베딩 ada-002, 임베딩 대형 및 임베딩 소형
• 최대 토큰: 선택한 포함 모델의 최대 토큰 제한을 알고 있습니다. 이 한도를 초과하는 청크를 전달할 경우, 해당 청크가 잘려서 중요한 정보가 손실될 수 있습니다. 예를 들어 bge-large-en-v1.5에서 최대 토큰 한도는 512입니다.
• 모델 크기: 더 큰 포함 모델은 일반적으로 더 나은 성능을 제공하지만 더 많은 계산 리소스가 필요합니다. 특정 사용 사례 및 사용 가능한 리소스에 따라 성능과 효율성의 균형을 유지해야 합니다.
• 미세 조정: RAG 애플리케이션이 도메인 특정 언어(예: 내부 회사 약어 또는 용어)를 다루는 경우 도메인별 데이터에 포함 모델을 미세 조정하는 것이 좋습니다. 이렇게 하면 모델이 특정 도메인의 뉘앙스와 용어를 더 잘 캡처할 수 있으며 검색 성능이 향상되는 경우가 많습니다.

인덱싱 및 스토리지

파이프라인의 다음 단계는 포함 및 이전 단계에서 생성된 메타데이터에 대한 인덱스를 만드는 것입니다. 이 단계에서는 빠르고 정확한 유사성 검색을 가능하게 하는 효율적인 데이터 구조로 고차원 벡터 포함을 구성합니다.

Mosaic AI Vector Search는 벡터 검색 엔드포인트 및 인덱스를 배포할 때 최신 인덱싱 기술을 사용하여 벡터 검색 쿼리에 대한 빠르고 효율적인 조회를 보장합니다. 최상의 인덱싱 기술을 테스트하고 선택하는 것에 대해 걱정할 필요가 없습니다.

인덱스를 빌드하고 배포한 후에는 확장 가능하고 짧은 대기 시간 쿼리를 지원하는 시스템에 저장할 준비가 됩니다. 큰 데이터 세트가 있는 프로덕션 RAG 파이프라인의 경우 벡터 데이터베이스 또는 확장 가능한 검색 서비스를 사용하여 짧은 대기 시간과 높은 처리량을 보장합니다. 추가 메타데이터를 임베딩과 함께 저장하여 검색 시 효율적으로 필터링할 수 있도록 합니다.