두 부분으로 구성된 이 시리즈의 첫 번째 기사에서는 최적이 아닌 임베딩 모델, 비효율적인 청킹 전략, 메타데이터 필터링 부족으로 인해 LLM에서 관련 응답을 얻는 것이 어떻게 어려워지는지 살펴봅니다. 이러한 문제를 극복하는 방법은 다음과 같습니다.  다음을 사용하는 생성적 AI 애플리케이션 구축  (RAG)는 다양한 문제를 야기할 수 있습니다. 보다 관련성이 높은 결과를 제공하기 위해 대규모 언어 모델에 대한 프롬프트에 포함되는 관련 컨텍스트를 검색하기 위해 벡터 데이터베이스에 의존하는 RAG 구현의 문제 해결을 살펴보겠습니다.   검색 증강 세대  이 프로세스를 두 가지 주요 부분으로 나누어 보겠습니다. 시리즈의 첫 번째 기사에서 다룰 첫 번째는 임베딩 파이프라인입니다.  임베딩 포함:    벡터 데이터베이스  여기서는 좋지 않은 결과를 초래할 수 있는 세 가지 주요 영역, 즉 최적이 아닌 임베딩 모델, 비효율적인 청킹 전략, 메타데이터 필터링 부족을 고려해 보겠습니다. (다음 기사에서는 LLM과의 실제 상호 작용을 살펴보고 거기서 발생하여 좋지 않은 결과를 초래할 수 있는 몇 가지 일반적인 문제를 조사할 것입니다.)  적절한 임베딩 모델 선택  임베딩 모델 선택은 RAG 애플리케이션의 전반적인 관련성과 유용성에 중요한 영향을 미칩니다. 따라서 각 모델의 기능에 대한 미묘한 이해와 해당 기능이 애플리케이션의 요구 사항에 어떻게 부합하는지에 대한 분석이 필요합니다.  RAG 및 일반적인 임베딩을 비교적 처음 접하는 경우 알아야 할 최고의 리소스 중 하나는 다음과 같습니다.  . 이 게시물에서는 검색 사용 사례에 중점을 두지만, 임베딩은 물론 분류, 클러스터링, 요약을 비롯한 다양한 다른 애플리케이션에도 사용될 수 있습니다.   MTEB(Massive Text Embedding Benchmark) 임베딩 리더보드  순위표는 특정 사용 사례에 가장 적합한 모델을 식별하는 데 도움이 될 수 있습니다.  RAG 성능이 저하되는 가장 일반적인 이유 중 하나는 이 분야를 처음 접하는 개발자가 Google 검색을 통해 임베딩 생성의 예를 찾기 때문입니다. 검색 사용 사례에 적합하지 않은 Word2Vec, sBERT 및 RoBERTa와 같은 임베딩 모델을 사용하는 샘플을 찾는 경우가 많습니다.  관련성이 낮은 결과를 디버깅하고 sBERT와 같은 것을 사용하여 임베딩을 생성했기 때문에 이 문서를 찾았다면 관련성 문제의 원인을 식별했을 가능성이 높습니다.  그렇다면 다음 질문은 유사성 검색 결과를 개선하는 데 사용할 수 있는 임베딩 모델이 무엇인지에 관한 것입니다. 사용 사례의 세부 사항을 알지 못하는 경우 권장되는 세 가지는 다음과 같습니다.  텍스트 임베딩-ada-002(Ada v2)  많은 개발자가 Open AI의 API로 시작하기 때문에 아마도 대부분의 RAG 애플리케이션의 가장 일반적인 시작점이 될 것입니다. Ada v2는 검색 사용 사례에서 탁월한 성능을 발휘하며 텍스트 및 코드를 포함한 다양한 유형의 콘텐츠를 처리하도록 구축되었습니다.   OpenAI의 Ada v2  최대 8,192개 토큰의 최대 입력 시퀀스 길이를 통해 대체 모델보다 훨씬 긴 텍스트 조각에 대한 임베딩을 생성할 수도 있습니다. 이것은 축복이자 저주입니다.  시퀀스 크기가 크면 더 많은 텍스트 콘텐츠에 대한 임베딩을 생성하는 프로세스가 단순화되고 임베딩 모델이 더 큰 텍스트 본문에서 단어와 문장 간의 관계를 식별할 수 있습니다.  그러나 이로 인해 찾고 있는 것이 생성 프로세스를 촉진하기 위한 관련 컨텍스트 덩어리일 때 두 개의 긴 문서의 유사성을 비교할 때 더 모호해질 수 있는 유사성 검색이 발생합니다.  Ada v2에는 두 가지 큰 단점이 있습니다. 첫 번째는 로컬에서 실행할 수 없다는 것입니다. 임베딩을 생성하려면 OpenAI의 API를 사용해야 합니다. 이로 인해 많은 콘텐츠에 대한 임베딩을 생성하려는 경우 병목 현상이 발생할 수 있을 뿐만 아니라 토큰 1,000개당 $0.0001의 비용이 추가됩니다.  두 번째는 Open AI 모델에서 생성된 임베딩이 각각 1,536차원이라는 것입니다. 클라우드 벡터 데이터베이스를 사용하는 경우 벡터 저장 비용이 상당히 증가할 수 있습니다.    API 호출만 필요한 간단한 솔루션을 원하고 잠재적으로 대용량 문서를 벡터화해야 하며 비용은 문제가 되지 않습니다. 선택 시기:  지나-임베딩-v2(지나 v2)  Jina v2는 Ada v2와 동일한 8,000개의 입력 시퀀스 지원을 제공하고 실제로 검색 사용 사례에서 약간 더 나은 점수를 제공하는 새로운 오픈 소스 임베딩 모델입니다.  Jina v2는 Ada v2의 문제에 대한 해독제를 제공합니다. Apache License 2.0에 따른   이며 로컬에서 실행할 수 있습니다. 물론 이 작업을 수행하기 위해 자신의 코드를 실행하지 않으려는 경우에도 단점이 됩니다. 또한 Ada v2 크기의 절반인 임베딩 벡터를 생성합니다. 오픈 소스  따라서 벤치마크 사용 사례에서 약간 더 나은 검색 성능을 얻을 수 있을 뿐만 아니라 벡터 데이터베이스 관점에서 더 낮은 스토리지 및 컴퓨팅 요구 사항으로 향상된 결과를 얻을 수도 있습니다.    오픈 소스 솔루션을 사용하고 싶고 잠재적으로 대용량 문서를 벡터화해야 하며 임베딩 파이프라인을 로컬에서 편안하게 실행할 수 있습니다. 저차원 임베딩으로 벡터 데이터베이스 비용을 줄이고 싶습니다. 선택 시기:  bge-large-en-v1.5    MIT 라이선스에 따라 오픈 소스로 제공되며 현재 검색 사용 사례에 대한 MTEB 순위표에서 최상위 임베딩 모델입니다. 입력 시퀀스가 작을수록 청킹 전략에 대해 더 많이 생각해야 하지만 궁극적으로 검색 사용 사례에 대해 최고의 종합 성능을 제공합니다. bge-large-en-v1.5는  선택 시기: 오픈 소스 솔루션을 사용하고 싶고 입력 크기 제한 내에서 유지하기 위해 청크 전략에 더 많은 시간을 할애할 의향이 있습니다. 임베딩 파이프라인을 로컬에서 편안하게 실행할 수 있습니다. 검색 사용 사례에 가장 적합한 임베딩 모델이 필요합니다.  이 기사의 범위를 벗어나는 동안 MTEB 리더보드의 15개 벤치마크를 자세히 조사하여 특정 상황과 가장 유사한 벤치마크를 식별할 수 있습니다.  다양한 임베딩 모델이 다양한 벤치마크에서 얼마나 잘 수행되는지에 대한 패턴은 분명 있지만, 각 벤치마크에서 눈에 띄는 특정 모델이 있는 경우가 많습니다. 임베딩 선택을 더욱 세분화해야 하는 경우 추가 조사가 가능한 영역입니다.  청킹 전략 최적화  입력 텍스트의 분할 또는 "청크"는 생성된 출력의 관련성과 정확성에 큰 영향을 미치는 중추적인 요소입니다. 다양한 청킹 전략은 고유한 이점을 제공하며 특정 유형의 작업에 적합합니다. 여기에서는 이러한 방법론을 자세히 살펴보고 몇 가지 주요 고려 사항을 포함하여 적용 지침을 제공합니다.   고정 길이 청킹    - 콘텐츠 자체가 고도로 구조화되어 있고 길이가 고정되어 있지 않는 한 일반적으로 다음과 같은 보다 유용한 청크 전략에 의존하고 싶어합니다. 사용 시기    - 구현이 매우 간단하지만 이 청킹 전략은 일반적으로 RAG 애플리케이션에서 좋지 않은 결과를 초래합니다. 기술적 고려사항    RAG 애플리케이션에서 고정 길이 전략을 사용하고 관련 컨텍스트를 검색하는 데 문제가 있는 경우 다른 청킹 접근 방식으로 전환하는 것을 고려해야 합니다. 추가 통찰력   문장 수준 청킹    - 이 전략은 입력 텍스트의 각 문장이 의미와 맥락이 풍부할 때 효과적입니다. 이를 통해 모델은 각 문장 내의 복잡성에 집중할 수 있으므로 보다 일관되고 상황에 맞는 응답을 생성할 수 있습니다. RAG 사용 사례에서는 문장 수준 청크에 거의 의존하지 않습니다. 사용 시기      문장 수준 청크에는 종종 자연어 처리(NLP) 라이브러리를 사용하여 달성할 수 있는 문장 경계를 기반으로 한 토큰화가 포함됩니다. 기술적 고려 사항 -      문장 수준 청크는 특정 텍스트와 의미상 유사한 문장을 찾으려는 회의 기록에서와 같이 특정 문장을 검색할 때 특히 유용할 수 있습니다. 추가 통찰력 -   단락 수준 청킹    - 입력 텍스트가 각각 별도의 아이디어나 주제를 캡슐화하는 별도의 섹션이나 단락으로 구성되어 있는 경우 이 전략을 사용하세요. 이를 통해 모델은 각 단락 내의 관련 정보에 집중할 수 있습니다. 사용 시기      단락 경계를 식별하려면 일반적으로 단락 끝을 나타내는 개행 문자나 기타 구분 기호를 감지해야 합니다. 기술적 고려 사항 -      단락 수준 청크는 동일한 주제의 다양한 측면을 다루는 문서가 있는 경우 유용할 수 있습니다. 예를 들어, 제품 설명서 페이지에서는 제품 기능을 소개하고, 언제 사용하는지 설명하고, 구성 방법을 설명하고, 다양한 구성의 예를 제공할 수 있습니다. 추가 통찰력 -  단락 수준 청크를 사용하면 LLM에 컨텍스트로 제공할 문서의 가장 관련성이 높은 부분을 식별하는 데 도움이 될 수 있습니다.   내용 인식 청킹      텍스트 내 특정 섹션의 관련성이 가장 중요할 때 이 전략을 선택하세요. 예를 들어 법률 문서에서 조항이나 섹션을 기준으로 텍스트를 분할하면 상황에 맞는 응답을 더 많이 얻을 수 있습니다. 사용 시기 -      이 접근 방식에는 텍스트 내의 의미 경계를 이해하기 위해 고급 NLP 기술이 필요할 수 있습니다. 기술적 고려 사항 -      콘텐츠 인식 청크는 정형 또는 반정형 데이터를 처리할 때 특히 유용합니다. 특정 청크를 메타데이터 필터링과 결합하여 보다 정확한 검색을 수행할 수 있기 때문입니다. 추가 통찰력 -  예를 들어 법률 문서에서 모든 보증 또는 면책 조항을 추출하려고 할 수 있으며 벡터 데이터베이스에 청크에 대한 임베딩을 저장할 때 메타데이터를 사용하면 특정 유형의 콘텐츠를 더 쉽게 검색할 수 있습니다. RAG 사용 사례.   재귀적 청킹      재귀 청킹은 계층적 접근 방식을 사용하여 데이터를 더 작은 조각으로 나눕니다. 예를 들어, 텍스트 문서를 청크할 때 텍스트를 먼저 단락으로 나눈 다음 문장, 마지막으로 단어로 나눌 수 있습니다. 사용 시기 -  데이터가 첫 번째 청크 세트로 분할되면 관심 있는 가장 작은 청크 크기에 도달할 때까지 반복하여 각각의 작은 청크에 청킹 프로세스를 반복적으로 적용할 수 있습니다.      재귀 청크를 구현하려면 추가 기준에 따라 청크를 하위 청크로 더 나누는 다단계 구문 분석 전략이 필요할 수 있습니다. 당신이 사용하는 경우  , 재귀 구현은 여기에 설명된 것보다 약간 더 간단합니다. 기술적 고려 사항 -   랭체인      이 접근 방식을 사용하면 모델이 높은 수준의 주제부터 세부적인 뉘앙스까지 다양한 수준에서 컨텍스트를 이해할 수 있으므로 학술 논문, 기술 매뉴얼 또는 법률 계약과 같은 복잡한 문서에 특히 유용합니다. 유사성 검색은 더 광범위하고 짧은 쿼리 모두에 대해 유사한 텍스트를 식별할 수 있으므로 이는 유연성 이점을 제공합니다. 추가 통찰력 -  그러나 이는 동일한 소스 문서의 유사한 청크가 유사성 검색에서도 과도하게 표시될 가능성이 있음을 의미합니다. 특히 텍스트 분할기 구성에서 청크 간에 더 긴 겹침을 선택한 경우 더욱 그렇습니다.  일반적인 접근 방식으로, 큰 자료를 덩어리로 나누어 벡터화하기 전에 데이터를 사용하여 임시 실험을 수행하는 것을 고려해야 합니다.  특정 쿼리에 대해 검색하려는 문서를 수동으로 검사하고, LLM을 제공하려는 이상적인 컨텍스트를 나타내는 청크를 식별한 다음, 청크 전략을 실험하여 가장 관련성이 있다고 생각되는 청크를 제공하는 것이 무엇인지 확인합니다. LLM이 가지고 있는 것입니다.  컨텍스트 창 고려 사항  LLM의 사용 가능한 컨텍스트 창은 청킹 전략을 선택하는 데 중요한 요소입니다. 컨텍스트 창이 작은 경우 가장 관련성이 높은 정보가 포함되도록 모델에 제공하는 청크를 더욱 선택적으로 선택해야 합니다.  반대로, 컨텍스트 창이 더 크면 더 많은 유연성이 허용되므로 모델의 출력을 향상할 수 있는 추가 컨텍스트를 포함할 수 있습니다. 모든 컨텍스트가 반드시 필요하지는 않더라도 마찬가지입니다.  이러한 청킹 전략을 실험하고 이러한 고려 사항을 고려하여 생성된 출력의 관련성에 미치는 영향을 평가할 수 있습니다. 핵심은 선택한 전략을 RAG 애플리케이션의 특정 요구 사항에 맞추고 입력의 의미적 무결성을 유지하며 컨텍스트에 대한 포괄적인 이해를 제공하는 것입니다.  이를 통해 최적의 성능을 위한 올바른 청킹 프로세스를 찾을 수 있습니다.  메타데이터 필터링  검색 인덱스의 임베딩 수가 증가하면 프롬프트에 포함할 관련 컨텍스트를 찾을 때 ANN(근접 인접 이웃)이 덜 유용해집니다. 지식창고에 있는 200개의 기사에 대한 색인화된 임베딩이 있다고 가정해 보겠습니다.  1%의 정확도로 가장 가까운 이웃을 식별할 수 있는 경우 1%가 200개 기사 중 상위 2개 기사를 나타내고 그 둘 중 하나를 얻게 되므로 매우 관련성이 높은 결과를 찾을 가능성이 높습니다.  이제 Wikipedia의 모든 기사가 포함된 검색 색인을 생각해 보세요. 이는 약 670만 개의 기사에 해당합니다. 가장 가까운 이웃이 가장 유사한 기사 중 상위 1%에 속한다면 이는 가장 유사한 기사 67,000개 중 하나를 받고 있다는 의미입니다.  Wikipedia와 같은 자료를 사용하면 이는 여전히 목표에서 크게 벗어날 수 있음을 의미합니다.  메타데이터 필터링을 사용하면 먼저 문서를 필터링한 다음 최근접 이웃 알고리즘을 적용하여 콘텐츠 조각의 범위를 좁힐 수 있습니다. 가능한 많은 수의 일치 항목을 처리하는 경우 이 초기 사전 필터링은 가장 가까운 이웃을 검색하기 전에 가능한 옵션을 좁히는 데 도움이 될 수 있습니다.  다음에는 LLM과의 상호 작용에 대해 자세히 알아보고 좋지 않은 결과를 초래할 수 있는 몇 가지 일반적인 문제를 살펴보겠습니다.      . 노력하다   데이터스택스 아스트라DB 실시간 데이터를 기반으로 생산 수준 AI 애플리케이션을 구축하기 위한 유일한 벡터 데이터베이스입니다  작성자: Chris Latimer, DataStax    게시됨 여기에도

This story contains new, firsthand information uncovered by the writer.

DataStax Astra DB is the vector database for getting GenAI apps into production, fast. Try it for free today!

DataStax

이 오디오는 이야기의 원래 언어로 제작되었습니다!

더 많은 관련 LLM 응답이 필요하십니까? 이러한 검색 증강 세대 문제 해결(1부)

About Author

코멘트

태그 걸기

이 기사는 다음에서 발표되었습니다.

Related Stories

HackerNoon 글쓰기 대회에서 우승하고 싶으신가요? #crypto-api 대회 우승자들이 추천하는 내용은 다음과 같습니다.

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

바다 항해: 데이터 레이크를 사용하여 프로덕션 등급 RAG 애플리케이션 개발

보이지 않는 레이어: 사용자 인터뷰가 대체할 수 없는 자산인 이유

HackerNoon 글쓰기 대회에서 우승하고 싶으신가요? #crypto-api 대회 우승자들이 추천하는 내용은 다음과 같습니다.

이 18가지 개발자 도구로 생산성을 높이세요 🚀🔥

바다 항해: 데이터 레이크를 사용하여 프로덕션 등급 RAG 애플리케이션 개발

보이지 않는 레이어: 사용자 인터뷰가 대체할 수 없는 자산인 이유

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps