RAG 체인 품질 개선

이 문서에서는 RAG 체인의 구성 요소를 사용하여 RAG 앱의 품질을 개선하는 방법을 설명합니다.

RAG 체인은 사용자 쿼리를 입력으로 사용하고, 해당 쿼리에 지정된 관련 정보를 검색하고, 검색된 데이터에 근거한 적절한 응답을 생성합니다. RAG 체인 내의 정확한 단계는 사용 사례 및 요구 사항에 따라 크게 달라질 수 있지만 RAG 체인을 빌드할 때 고려해야 할 주요 구성 요소는 다음과 같습니다.

1. 쿼리 이해: 사용자 쿼리를 분석 및 변환하여 의도를 더 잘 나타내고 필터 또는 키워드와 같은 관련 정보를 추출하여 검색 프로세스를 개선합니다.
2. 검색: 검색 쿼리가 제공된 가장 관련성이 큰 정보 청크 찾기 구조화되지 않은 데이터 사례에서 일반적으로 의미 체계 또는 키워드 기반 검색의 조합 또는 하나가 포함됩니다.
3. 프롬프트 확대: 사용자 쿼리를 검색된 정보 및 지침과 결합하여 LLM이 고품질 응답을 생성하도록 안내합니다.
4. LLM: 성능, 대기 시간 및 비용을 최적화/분산하기 위해 애플리케이션에 가장 적합한 모델(및 모델 매개 변수)을 선택합니다.
5. 후처리 및 가드레일: LLM 생성 응답이 토픽에 포함되고, 실제로 일관되며, 특정 지침 또는 제약 조건을 준수하도록 추가 처리 단계 및 안전 조치를 적용합니다.

품질 수정을 반복적으로 구현하고 평가하면 체인의 구성 요소를 반복하는 방법을 보여 줍니다.

쿼리 이해

사용자 쿼리를 검색 쿼리로 직접 사용하면 일부 쿼리에서 작동할 수 있습니다. 그러나 일반적으로 검색 단계 전에 쿼리를 다시 포맷하는 것이 좋습니다. 쿼리 이해는 의도를 더 잘 나타내고, 관련 정보를 추출하고, 궁극적으로 후속 검색 프로세스를 돕기 위해 사용자 쿼리를 분석하고 변환하는 체인의 시작 부분에 있는 단계(또는 일련의 단계)로 구성됩니다. 검색을 개선하기 위해 사용자 쿼리를 변환하는 방법은 다음과 같습니다.

1. 쿼리 다시 쓰기: 쿼리 다시 작성에는 사용자 쿼리를 원래 의도를 더 잘 나타내는 하나 이상의 쿼리로 변환하는 작업이 포함됩니다. 목표는 검색 단계에서 가장 관련성이 높은 문서를 찾을 가능성을 높이는 방식으로 쿼리를 다시 포맷하는 것입니다. 이는 검색 문서에 사용된 용어와 직접 일치하지 않을 수 있는 복잡하거나 모호한 쿼리를 처리할 때 특히 유용할 수 있습니다.

   예:

   • 멀티 턴 채팅에서 대화 기록의 매개 변수 지정
   • 사용자의 쿼리에서 맞춤법 오류 수정
   • 사용자 쿼리의 단어 또는 구를 동의어로 바꿔 더 광범위한 관련 문서를 캡처합니다.

   Important

   쿼리 다시 쓰기는 검색 구성 요소의 변경 내용과 함께 수행해야 합니다.

2. 필터 추출: 경우에 따라 사용자 쿼리에 검색 결과의 범위를 좁히는 데 사용할 수 있는 특정 필터 또는 조건이 포함될 수 있습니다. 필터 추출에는 쿼리에서 이러한 필터를 식별하고 추출하여 검색 단계에 추가 매개 변수로 전달하는 작업이 포함됩니다. 이렇게 하면 사용 가능한 데이터의 특정 하위 집합에 집중하여 검색된 문서의 관련성을 향상시킬 수 있습니다.

   예:

   • 쿼리에 언급된 특정 기간(예: "지난 6개월의 문서" 또는 "2023년의 보고서")을 추출합니다.
   • 쿼리에서 특정 제품, 서비스 또는 범주에 대한 언급(예: "Databricks Professional Services" 또는 "노트북")을 식별합니다.
   • 쿼리에서 도시 이름 또는 국가 코드와 같은 지리적 엔터티 추출

   참고 항목

   필터 추출은 메타데이터 추출 데이터 파이프라인 및 리트리버 체인 구성 요소의 변경 내용과 함께 수행해야 합니다. 메타데이터 추출 단계에서는 각 문서/청크에 관련 메타데이터 필드를 사용할 수 있도록 해야 하며 추출된 필터를 수락하고 적용하기 위해 검색 단계를 구현해야 합니다.

쿼리 재작성 및 필터 추출 외에도 쿼리 이해의 또 다른 중요한 고려 사항은 단일 LLM 호출 또는 여러 호출을 사용할지 여부입니다. 신중하게 작성된 프롬프트와 함께 단일 호출을 사용하는 것이 효율적일 수 있지만 쿼리 이해 프로세스를 여러 LLM 호출로 분해하면 더 나은 결과를 초래할 수 있는 경우가 있습니다. 이는 여러 복잡한 논리 단계를 단일 프롬프트로 구현하려고 할 때 일반적으로 적용할 수 있는 엄지 손가락 규칙입니다.

예를 들어 하나의 LLM 호출을 사용하여 쿼리 의도를 분류하고, 다른 하나는 관련 엔터티를 추출하고, 세 번째는 추출된 정보를 기반으로 쿼리를 다시 작성할 수 있습니다. 이 방법은 전체 프로세스에 약간의 대기 시간을 추가할 수 있지만 보다 세분화된 제어를 허용하고 검색된 문서의 품질을 향상시킬 수 있습니다.

지원 봇에 대한 다중 단계 쿼리 이해

다단계 쿼리 이해 구성 요소가 고객 지원 봇을 찾는 방법은 다음과 같습니다.

1. 의도 분류: LLM을 사용하여 사용자의 쿼리를 "제품 정보", "문제 해결" 또는 "계정 관리"와 같은 미리 정의된 범주로 분류합니다.
2. 엔터티 추출: 식별된 의도에 따라 다른 LLM 호출을 사용하여 제품 이름, 보고된 오류 또는 계정 번호와 같은 관련 엔터티를 쿼리에서 추출합니다.
3. 쿼리 다시 쓰기: 추출된 의도 및 엔터티를 사용하여 원래 쿼리를 보다 구체적이고 대상이 지정된 형식으로 다시 작성합니다. 예를 들어 "내 RAG 체인이 모델 제공에 배포하지 못했습니다. 다음 오류가 표시됩니다...".

검색

RAG 체인의 검색 구성 요소는 검색 쿼리에서 가장 관련성이 큰 정보 청크를 찾는 역할을 담당합니다. 구조화되지 않은 데이터의 컨텍스트에서 검색에는 일반적으로 의미 체계 검색, 키워드 기반 검색 및 메타데이터 필터링의 하나 또는 조합이 포함됩니다. 검색 전략의 선택은 애플리케이션의 특정 요구 사항, 데이터의 특성 및 처리할 쿼리 유형에 따라 달라집니다. 다음 옵션을 비교해 보겠습니다.

1. 의미 체계 검색: 의미 체계 검색은 포함 모델을 사용하여 각 텍스트 청크를 의미 체계 의미를 캡처하는 벡터 표현으로 변환합니다. 검색 쿼리의 벡터 표현과 청크의 벡터 표현을 비교하여 의미 체계 검색은 쿼리의 정확한 키워드를 포함하지 않더라도 개념적으로 유사한 문서를 검색할 수 있습니다.
2. 키워드 기반 검색: 키워드 기반 검색은 검색 쿼리와 인덱싱된 문서 간에 공유 단어의 빈도 및 분포를 분석하여 문서의 관련성을 결정합니다. 쿼리와 문서에 동일한 단어가 표시되는 경우가 많을수록 해당 문서에 할당된 관련성 점수가 높아질 수 있습니다.
3. 하이브리드 검색: 하이브리드 검색은 2단계 검색 프로세스를 사용하여 의미 체계 및 키워드 기반 검색의 장점을 결합합니다. 먼저 의미 체계 검색을 수행하여 개념적으로 관련된 문서 집합을 검색합니다. 그런 다음, 이 축소된 집합에 키워드 기반 검색을 적용하여 정확한 키워드 일치를 기반으로 결과를 더욱 구체화합니다. 마지막으로 두 단계의 점수를 결합하여 문서의 순위를 지정합니다.

검색 전략 비교

다음 표에서는 이러한 각 검색 전략을 서로 대조합니다.

	의미 체계 검색	키워드 검색	하이브리드 검색
간단한 설명	쿼리 및 잠재적 문서에 동일한 개념 이 표시되면 관련이 있습니다.	쿼리와 잠재적인 문서에 동일한 단어가 표시되면 관련이 있습니다. 문서에서 쿼리의 단어가 많을수록 해당 문서의 관련성이 높아집니다.	의미 체계 검색 및 키워드 검색을 모두 실행한 다음 결과를 결합합니다.
예제 사용 사례	사용자 쿼리가 제품 설명서의 단어와 다른 고객 지원. 예: "휴대폰을 켜려면 어떻게 하나요?" 수동 섹션을 "전원 전환"이라고 합니다.	쿼리에 설명이 없는 특정 기술 용어가 포함된 고객 지원. 예: "모델 HD7-8D는 무엇을 합니까?"	의미 체계 및 기술 용어를 모두 결합한 고객 지원 쿼리 예: "HD7-8D를 켜려면 어떻게 해야 하나요?"
기술 접근 방식	포함을 사용하여 연속 벡터 공간의 텍스트를 나타내며 의미 체계 검색을 사용하도록 설정합니다.	키워드 일치를 위해 단어 모음, TF-IDF, BM25와 같은 개별 토큰 기반 메서드를 사용합니다.	순위 재순위 접근 방식을 사용하여 상호 순위 융합 또는 순위 다시 매기기 모델과 같은 결과를 결합합니다.
강점	정확한 단어가 사용되지 않더라도 쿼리와 컨텍스트적으로 유사한 정보를 검색합니다.	정확한 키워드 일치가 필요한 시나리오로, 제품 이름과 같은 특정 용어 중심 쿼리에 적합합니다.	두 방법 중 가장 좋은 방법을 결합합니다.

검색 프로세스를 향상시키는 방법

이러한 핵심 검색 전략 외에도 검색 프로세스를 더욱 향상시키기 위해 적용할 수 있는 몇 가지 기술이 있습니다.

• 쿼리 확장: 쿼리 확장은 검색 쿼리의 여러 변형을 사용하여 광범위한 관련 문서를 캡처하는 데 도움이 될 수 있습니다. 이 작업은 확장된 각 쿼리에 대해 개별 검색을 수행하거나 단일 검색 쿼리에서 확장된 모든 검색 쿼리를 연결하여 수행할 수 있습니다.

참고 항목

쿼리 확장은 RAG 체인(쿼리 이해 구성 요소)의 변경 내용과 함께 수행해야 합니다. 검색 쿼리의 여러 변형은 일반적으로 이 단계에서 생성됩니다.

• 순위 다시 지정: 초기 청크 집합을 검색한 후 추가 순위 조건(예: 시간별 정렬) 또는 재랜커 모델을 적용하여 결과를 다시 정렬합니다. 순위를 다시 지정하면 특정 검색 쿼리에 따라 가장 관련성이 높은 청크의 우선 순위를 지정하는 데 도움이 될 수 있습니다. mxbai-rerank 및 ColBERTv2와 같은 크로스 인코더 모델로 다시 실행하면 검색 성능이 향상될 수 있습니다.
• 메타데이터 필터링: 쿼리 이해 단계에서 추출한 메타데이터 필터를 사용하여 특정 조건에 따라 검색 공간의 범위를 좁힐 수 있습니다. 메타데이터 필터에는 문서 유형, 생성 날짜, 작성자 또는 도메인별 태그와 같은 특성이 포함될 수 있습니다. 메타데이터 필터를 의미 체계 또는 키워드 기반 검색과 결합하여 보다 대상적이고 효율적인 검색을 만들 수 있습니다.

참고 항목

메타데이터 필터링은 RAG 체인(쿼리 이해) 및 메타데이터 추출(데이터 파이프라인) 구성 요소에 대한 변경 내용과 함께 수행해야 합니다.

프롬프트 확대

프롬프트 확대는 사용자 쿼리를 프롬프트 템플릿의 검색된 정보 및 지침과 결합하여 언어 모델을 고품질 응답을 생성하는 데 도움이 되는 단계입니다. 이 템플릿을 반복하여 LLM(AKA 프롬프트 엔지니어링)에 제공된 프롬프트를 최적화하려면 모델이 정확하고, 접지되고, 일관된 응답을 생성하도록 유도되어야 합니다.

프롬프트 엔지니어링에 대한 전체 가이드가 있지만 프롬프트 템플릿을 반복할 때 유의해야 할 몇 가지 고려 사항은 다음과 같습니다.

1. 예제 제공
   • 올바른 형식의 쿼리 예제와 프롬프트 템플릿 자체(몇 번의 학습)에 해당되는 이상적인 응답을 포함합니다. 이렇게 하면 모델이 응답의 원하는 형식, 스타일 및 콘텐츠를 이해할 수 있습니다.
   • 좋은 예제를 마련하는 한 가지 유용한 방법은 체인이 어려움을 겪고 있는 쿼리 유형을 식별하는 것입니다. 이러한 쿼리에 대한 골드 표준 응답을 만들고 프롬프트에 예제로 포함합니다.
   • 사용자가 제공하는 예제가 유추 시간에 예상하는 사용자 쿼리를 나타내는지 확인합니다. 모델이 더 잘 일반화될 수 있도록 다양한 범위의 예상 쿼리를 다루는 것을 목표로 합니다.
2. 프롬프트 템플릿 매개 변수화
   • 검색된 데이터 및 사용자 쿼리 이외의 추가 정보를 통합하도록 매개 변수화하여 프롬프트 템플릿을 유연하게 디자인합니다. 현재 날짜, 사용자 컨텍스트 또는 기타 관련 메타데이터와 같은 변수일 수 있습니다.
   • 이러한 변수를 유추 시간에 프롬프트에 삽입하면 보다 개인화되거나 컨텍스트 인식 응답을 사용할 수 있습니다.
3. 생각의 사슬 프롬프트 고려
   • 직접 답변이 쉽게 표시되지 않는 복잡한 쿼리의 경우 CoT(Chain-of-Thought) 프롬프트를 고려하세요. 이 프롬프트 엔지니어링 전략은 복잡한 질문을 더 간단하고 순차적인 단계로 분석하여 논리적 추론 프로세스를 통해 LLM을 안내합니다.
   • 모델에 "문제를 단계별로 생각하라"는 메시지를 표시하면 다단계 또는 개방형 쿼리를 처리하는 데 특히 효과적일 수 있는 보다 상세하고 합리적인 응답을 제공하는 것이 좋습니다.
4. 프롬프트가 모델 간에 전송되지 않을 수 있음
   • 프롬프트가 다른 언어 모델 간에 원활하게 전송되지 않는 경우가 많다는 것을 인식합니다. 각 모델에는 한 모델에 대해 잘 작동하는 프롬프트가 다른 모델에는 효과적이지 않을 수 있는 고유한 특성이 있습니다.
   • 다양한 프롬프트 형식과 길이를 실험하고, 온라인 가이드(예: OpenAI Cookbook, Anthropic Cookbook)를 참조하고, 모델 간에 전환할 때 프롬프트를 조정하고 구체화할 준비를 합니다.

LLM

RAG 체인의 생성 구성 요소는 이전 단계에서 보강된 프롬프트 템플릿을 가져와 LLM에 전달합니다. RAG 체인의 생성 구성 요소에 대해 LLM을 선택하고 최적화하는 경우 LLM 호출과 관련된 다른 모든 단계에 동일하게 적용되는 다음 요소를 고려합니다.

1. 다양한 기성품 모델을 실험합니다.
   • 각 모델에는 고유한 속성, 강점 및 약점이 있습니다. 일부 모델은 특정 도메인을 더 잘 이해하거나 특정 작업에서 더 나은 성능을 발휘할 수 있습니다.
   • 앞에서 설명한 것처럼 모델 선택은 다른 모델이 동일한 프롬프트에 다르게 응답할 수 있으므로 프롬프트 엔지니어링 프로세스에도 영향을 줄 수 있습니다.
   • 생성 단계 외에도 쿼리 이해에 대한 호출과 같이 LLM이 필요한 여러 단계가 체인에 있는 경우 다른 단계에 다른 모델을 사용하는 것이 좋습니다. 더 비싸고 범용 모델은 사용자 쿼리의 의도를 결정하는 것과 같은 작업에 지나치게 적합할 수 있습니다.
2. 작게 시작하고 필요에 따라 강화합니다.
   • 사용 가능한 가장 강력하고 유능한 모델(예: GPT-4, Claude)에 즉시 도달하려는 경우가 많지만 더 작고 가벼운 모델로 시작하는 것이 더 효율적입니다.
   • 대부분의 경우, Llama 3 또는 DBRX와 같은 더 작은 오픈 소스 대안은 저렴한 비용과 더 빠른 유추 시간을 통해 만족스러운 결과를 제공할 수 있습니다. 이러한 모델은 매우 복잡한 추론 또는 광범위한 세계 지식이 필요하지 않은 작업에 특히 효과적일 수 있습니다.
   • RAG 체인을 개발하고 구체화할 때 선택한 모델의 성능과 제한 사항을 지속적으로 평가합니다. 모델이 특정 유형의 쿼리에 어려움을 겪거나 충분히 상세하거나 정확한 응답을 제공하지 못하는 경우 더 유능한 모델로 확장하는 것이 좋습니다.
   • 응답 품질, 대기 시간 및 비용과 같은 주요 메트릭에 대한 모델 변경의 영향을 모니터링하여 특정 사용 사례의 요구 사항에 적합한 균형을 맞추도록 합니다.
3. 모델 매개 변수 최적화
   • 다른 매개 변수 설정을 실험하여 응답 품질, 다양성 및 일관성 간의 최적 균형을 찾습니다. 예를 들어 온도를 조정하면 생성된 텍스트의 임의성을 제어할 수 있지만 max_tokens 응답 길이를 제한할 수 있습니다.
   • 최적의 매개 변수 설정은 특정 작업, 프롬프트 및 원하는 출력 스타일에 따라 달라질 수 있습니다. 생성된 응답의 평가에 따라 이러한 설정을 반복적으로 테스트하고 구체화합니다.
4. 작업별 미세 조정
   • 성능을 구체화할 때는 쿼리 이해와 같이 RAG 체인 내의 특정 하위 작업에 대해 더 작은 모델을 미세 조정하는 것이 좋습니다.
   • RAG 체인을 사용하여 개별 작업에 대한 특수 모델을 학습하면 모든 작업에 단일 대형 모델을 사용하는 것에 비해 전반적인 성능을 향상시키고 대기 시간을 줄이며 유추 비용을 줄일 수 있습니다.
5. 계속된 사전 학습
   • RAG 애플리케이션이 특수 도메인을 처리하거나 미리 학습된 LLM에 잘 표시되지 않는 지식이 필요한 경우 도메인별 데이터에 대해 CPT(지속적인 사전 학습)를 수행하는 것이 좋습니다.
   • 지속적인 사전 학습은 도메인에 고유한 특정 용어 또는 개념에 대한 모델의 이해를 향상시킬 수 있습니다. 따라서 광범위한 프롬프트 엔지니어링 또는 몇 가지 예제의 필요성을 줄일 수 있습니다.

후처리 및 가드레일

LLM이 응답을 생성한 후에는 출력이 원하는 형식, 스타일 및 콘텐츠 요구 사항을 충족하는지 확인하기 위해 사후 처리 기술 또는 가드레일을 적용해야 하는 경우가 많습니다. 체인의 이 마지막 단계(또는 여러 단계)는 생성된 응답에서 일관성과 품질을 유지하는 데 도움이 될 수 있습니다. 후처리 및 가드레일을 구현하는 경우 다음 중 일부를 고려합니다.

1. 출력 형식 적용
   • 사용 사례에 따라 생성된 응답이 구조화된 템플릿 또는 특정 파일 형식(예: JSON, HTML, Markdown 등)과 같은 특정 형식을 준수하도록 요구할 수 있습니다.
   • 구조화된 출력이 필요한 경우 강사 또는 개요와 같은 라이브러리는 이러한 종류의 유효성 검사 단계를 구현하기 위한 좋은 시작점을 제공합니다.
   • 개발할 때는 필요한 형식을 유지하면서 생성된 응답의 변형을 처리할 수 있을 만큼 사후 처리 단계가 유연하도록 하는 데 시간이 소요됩니다.
2. 스타일 일관성 유지 관리
   • RAG 애플리케이션에 특정 스타일 지침 또는 톤 요구 사항(예: 공식 및 캐주얼, 간결 및 상세)이 있는 경우 사후 처리 단계에서는 생성된 응답에서 이러한 스타일 특성을 확인하고 적용할 수 있습니다.
3. 콘텐츠 필터 및 안전 보호책
   • RAG 애플리케이션의 특성 및 생성된 콘텐츠와 관련된 잠재적 위험에 따라 부적절하거나 공격적이거나 유해한 정보의 출력을 방지하기 위해 콘텐츠 필터 또는 안전 보호책을 구현하는 것이 중요할 수 있습니다.
   • OpenAI의 조정 API와 같은 con텐트 모드ration 및 안전을 위해 특별히 설계된 Llama Guard 또는 API와 같은 모델을 사용하여 안전 가드레일을 구현하는 것이 좋습니다.
4. 환각 처리
   • 환각에 대한 방어는 사후 처리 단계로 구현될 수도 있습니다. 여기에는 생성된 출력을 검색된 문서와 상호 참조하거나 추가 LLM을 사용하여 응답의 사실 정확도를 확인하는 작업이 포함될 수 있습니다.
   • 생성된 응답이 대체 응답 생성 또는 사용자에게 고지 사항 제공과 같은 사실 정확도 요구 사항을 충족하지 못하는 경우를 처리하는 대체 메커니즘을 개발합니다.
5. 오류 처리
   • 사후 처리 단계를 사용하면 단계에서 문제가 발생하거나 만족스러운 응답을 생성하지 못하는 경우를 정상적으로 처리하는 메커니즘을 구현합니다. 여기에는 기본 응답을 생성하거나 수동 검토를 위해 사용자 운영자에게 문제를 에스컬레이션하는 작업이 포함될 수 있습니다.