임베딩 모델 파인튜닝으로 검색 및 RAG 개선하기

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)

더 나은 검색과 RAG를 위한 임베딩 모델의 파인튜닝

요약: 도메인 내 데이터에서 임베딩 모델을 미세 조정하면 벡터 검색 및 검색-증가 생성(RAG) 정확도를 크게 향상시킬 수 있습니다. Databricks를 이용하면, 수동 라벨링 없이 합성 데이터를 활용하여 특정 사용 사례에 최적화된 검색을 위해 임베딩 모델을 파인튜닝하고, 배포하고, 평가하는 것이 쉽습니다.

왜 중요한가요: 벡터 검색이나 RAG 시스템이 최상의 결과를 가져오지 못한다면, 임베딩 모델을 미세 조정하는 것은 성능을 향상시키는 간단하면서도 강력한 방법입니다. 금융 문서, 지식 기반, 또는 내부 코드 문서와 같은 것을 다루고 있다면, 미세 조정은 더 관련성 있는 검색 결과와 더 나은 하류 LLM 응답을 제공할 수 있습니다.

우리가 발견한 것: 우리는 두 개의 임베딩 모델을 세 개의 엔터프라이즈 데이터셋에 미세조정하고 테스트하여 검색 지표의 큰 개선 (Recall@10)과 하류 RAG 성능을 보았습니다. 이는 수동 라벨링 없이 기존 데이터만을 활용하여 정확도를 크게 향상시킬 수 있는 파인튜닝의 중요성을 의미합니다.

임베딩 파인튜닝을 시도해 보고 싶으신가요? 시작하실 수 있도록 참조 솔루션을 제공합니다. Databricks는 벡터 검색, RAG, 재순위 지정, 그리고 임베딩 파인 튜닝을 쉽게 만듭니다. 자세한 정보를 원하시면 Databricks 계정 담당자 또는 솔루션 아키텍트에게 문의하십시오.

왜 임베딩을 미세조정하는가?

임베딩 모델은 현대 벡터 검색 및 RAG 시스템을 구동합니다. 임베딩 모델은 텍스트를 벡터로 변환하여 키워드가 아닌 의미를 기반으로 관련 콘텐츠를 찾을 수 있게 합니다. 그러나, 상용 모델은 항상 귀하의 특정 도메인에 최적화되어 있지 않습니다—그것이 바로 파인 튜닝이 필요한 이유입니다.

도메인 특정 데이터에서 임베딩 모델을 미세 조정하는 것은 여러 가지 방법으로 도움이 됩니다:

• 검색 정확도 향상: 사용자 정의 임베딩은 데이터와 일치하도록 검색 결과를 개선합니다.
• RAG 성능 향상: 더 나은 검색은 환영 현상을 줄이고 더 실제적인 생성 AI 응답을 가능하게 합니다.
• 비용 및 지연 시간 개선: 더 작은 세부 조정된 모델은 때때로 더 크고 비싼 대안보다 성능이 뛰어날 수 있습니다.

이 블로그 게시물에서는 임베딩 모델을 파인튜닝하는 것이 업무 특화, 기업용 사용 사례에 대한 검색 및 RAG 성능을 향상시키는 효과적인 방법임을 보여줍니다.

결과: 파인튜닝이 효과적입니다

우리는 두 개의 임베딩 모델(gte-large-en-v1.5 및 e5-mistral-7b-instruct)을 합성 데이터에서 미세조정하고, 우리의 도메인 인텔리전스 벤치마크 스위트(DIBS) (FinanceBench, ManufactQA, Databricks DocsQA)에서 세 가지 데이터셋에서 평가했습니다. 그런 다음 우리는 그것들을 OpenAI의 text-embedding-3-large와 비교했습니다.

주요 포인트:

• 파인튜닝은 데이터셋 전반에 걸쳐 검색 정확도를 향상시켰습니다, 종종 기본 모델을 크게 앞섰습니다.
• 세밀하게 조정된 임베딩은 재정렬보다 더 좋거나 같은 성능을 보였습니다 이는 그들이 강력한 독립적인 해결책이 될 수 있음을 보여줍니다.
• 더 나은 검색은 FinanceBench에서 더 나은 RAG 성능을 이끌어냈습니다 이는 종단간 이점을 보여줍니다.

검색 성능

세 가지 데이터셋을 비교한 결과, 임베딩 파인튜닝이 두 데이터셋에서 정확도를 향상시키는 것을 발견했습니다. 그림 1은 FinanceBench와 ManufactQA에서 미세조정된 임베딩이 기본 버전을 능가하고, 때로는 OpenAI의 API 모델(연한 회색)을 이기기도 한다는 것을 보여줍니다. 그러나 Databricks DocsQA의 경우, OpenAI text-embedding-3-large의 정확도가 모든 파인튜닝 모델을 능가합니다. 이는 모델이 공개 Databricks 문서에 대해 훈련되었기 때문일 수 있습니다. 이는 파인튜닝이 효과적일 수 있지만, 훈련 데이터셋과 평가 작업에 크게 의존한다는 것을 보여줍니다.

미세 조정 vs. 재순위 지정

그런 다음 위의 결과를 API 기반 재정렬을 사용하여 voyageai/rerank-1과 비교했습니다 (그림 2). 재정렬기는 일반적으로 임베딩 모델에 의해 검색된 상위 k 결과를 가져와, 이 결과를 검색 쿼리와 관련하여 재정렬하고, 그런 다음 재정렬된 상위 k를 반환합니다 (우리의 경우 k=30 다음에 k=10). 이것은 재정렬기가 일반적으로 임베딩 모델보다 크고 강력한 모델이며, 쿼리와 문서 간의 상호 작용을 더 표현적인 방식으로 모델링하기 때문에 작동합니다.

우리가 발견한 것은:

• gte-large-en-v1.5를 미세조정한 결과 재정렬을 능가했습니다 FinanceBench와 ManufactQA에서.
• OpenAI의 text-embedding-3-large는 재순위 지정에서 이익을 얻었지만, 일부 데이터셋에서 개선 사항은 사소했습니다.
• Databricks DocsQA의 경우, 재순위 지정의 영향은 작았지만, 파인튜닝은 여전히 개선을 가져왔으며, 이는 이러한 방법들이 데이터셋에 따라 다르다는 것을 보여줍니다.

리랭커들은 일반적으로 임베딩 모델에 비해 추가적인 쿼리당 추론 지연 시간과 비용을 발생시킵니다. 그러나, 이들은 기존의 벡터 데이터베이스와 함께 사용될 수 있으며, 경우에 따라서는 새로운 임베딩 모델로 데이터를 재임베딩하는 것보다 비용 효율적일 수 있습니다. 재정렬기를 사용할지 여부는 귀하의 도메인과 대기 시간/비용 요구 사항에 따라 달라집니다.

세부 조정이 RAG 성능을 향상시킵니다

FinanceBench의 경우, 더 나은 검색 결과는 GPT-4o와 결합했을 때 더 나은 RAG 정확도 로 직접 번역되었습니다(부록 참조). 그러나 Databricks DocsQA와 같이 검색이 이미 강력한 분야에서는 파인튜닝이 크게 도움이 되지 않았습니다—검색이 명확한 병목 현상일 때 파인튜닝이 가장 잘 작동한다는 것을 강조합니다.

임베딩 모델을 어떻게 파인튜닝하고 평가했는지

다음은 우리의 합성 데이터 생성, 미세 조정, 그리고 평가에 대한 좀 더 기술적인 세부 사항입니다.

모델 임베딩

우리는 두 개의 오픈 소스 임베딩 모델을 세부 조정했습니다:

• gte-large-en-v1.5 는 BERT Large (434M 매개변수, 1.75 GB)를 기반으로 한 인기 있는 임베딩 모델입니다. 우리는 이 모델의 적당한 크기와 오픈 라이선스 때문에 이 모델에서 실험을 진행하기로 결정했습니다. 이 임베딩 모델은 현재 Databricks Foundation Model API에서 지원됩니다.
• e5-mistral-7b-instruct 는 강력한 LLMs(이 경우 Mistral-7b-instruct-v0.1) 위에 구축된 새로운 클래스의 임베딩 모델에 속합니다. 비록 e5-mistral-7b-instruct가 MTEB 와 같은 표준 임베딩 벤치마크에서 더 좋고, 더 긴 그리고 더 미묘한 프롬프트를 처리할 수 있지만, 이는 gte-large-en-v1.5보다 훨씬 크며(7 billion parameters를 가지고 있기 때문에), 약간 더 느리고 서비스하는 데 더 비쌉니다.

그런 다음 우리는 이를 OpenAI의 text-embedding-3-large와 비교했습니다.

평가 데이터셋

우리는 모든 모델을 우리의 도메인 인텔리전스 벤치마크 스위트(DIBS)에서 다음 데이터셋에서 평가했습니다: FinanceBench, ManufactQA, 그리고 Databricks DocsQA.

우리는 주요 검색 지표로서 recall@10 을 보고합니다; 이는 올바른 문서가 검색된 상위 10개 문서 중에 있는지를 측정합니다.

임베딩 모델 품질의 황금 표준은 MTEB 벤치마크로, BEIR과 같은 검색 작업뿐만 아니라 많은 다른 비검색 작업을 포함합니다. gte-large-en-v1.5 및 e5-mistral-7b-instruct와 같은 모델이 MTEB에서 잘 수행되는 것을 보았지만, 우리의 내부 엔터프라이즈 작업에서 어떻게 수행되는지 궁금했습니다.

트레이닝 데이터

우리는 위의 벤치마크 각각에 맞게 조정된 합성 데이터에서 별도의 모델들을 훈련시켰습니다:

각 도메인의 훈련 세트를 생성하기 위해, 우리는 기존 문서를 가져와 LLMs(예: Llama 3 405B)를 사용하여 각 문서의 내용에 기반한 샘플 쿼리를 생성했습니다. 이 합성 쿼리들은 그 후에 품질을 위해 LLM-as-a-judge (GPT4o)에 의해 필터링되었습니다. 필터링된 쿼리와 그들과 관련된 문서들은 미세 조정을 위한 대조 쌍으로 사용되었습니다. 우리는 대조 훈련을 위해 배치 내 음성을 사용했지만, 어려운 음성을 추가하면 성능을 더욱 향상시킬 수 있습니다(부록 참조).

하이퍼파라미터 튜닝

우리는 다음을 대상으로 sweep를 실행했습니다:

• 학습률, 배치 크기, 소프트맥스 온도
• 에포크 수 (1-3 에포크 테스트됨)
• 쿼리 프롬프트 변형 (예: "쿼리:" vs. 지시 기반 프롬프트)
• 풀링 전략 (평균 풀링 vs. 마지막 토큰 풀링)

모든 파인튜닝은 오픈 소스 mosaicml/composer, mosaicml/llm-foundry, 그리고 mosaicml/streaming 라이브러리를 사용하여 Databricks 플랫폼에서 수행되었습니다.

Databricks에서 벡터 검색 및 RAG를 개선하는 방법

세밀한 조정은 벡터 검색과 RAG 성능을 향상시키는 한 가지 방법일 뿐이며, 아래에 몇 가지 추가적인 접근법을 나열하였습니다.

더 나은 검색을 위해:

• 더 나은 임베딩 모델 사용: 많은 사용자들이 무심코 구식 임베딩을 사용하고 있습니다. 성능이 더 높은 모델로 간단히 교체하면 즉시 이익을 얻을 수 있습니다. 최고의 모델을 확인하려면 MTEB 리더보드 를 확인하세요.
• 하이브리드 검색 시도해보기: 밀도 임베딩과 키워드 기반 검색을 결합하여 정확도를 향상시킵니다. Databricks Vector Search 는 원클릭 솔루션으로 이를 쉽게 만들어줍니다.
• 리랭커 사용: 리랭커는 결과를 관련성에 따라 재정렬하여 결과를 세밀화할 수 있습니다. Databricks는 이를 내장 기능으로 제공합니다(현재는 사적 미리보기 상태입니다). 이 기능을 시도해 보려면 계정 담당자에게 문의하십시오.

더 나은 RAG를 위해:

• 프롬프트 최적화: LLM 프롬프팅에서의 작은 조정이 응답을 크게 향상시킬 수 있습니다. DSPy 는 이 과정을 자동화하는 데 도움이 될 수 있습니다(자세한 내용은 Databricks에서 DSPy를 사용하여 genAI 앱 구축을 참조하세요).
• LLM 업그레이드: 검색이 강하지만 답변이 약하다면, 더 나은 생성 모델을 사용하는 것을 고려해보세요.
• LLM 미세조정: 도메인이 독특하고 충분한 데이터가 있다면, Llama 3과 같은 모델을 미세조정하여 RAG 품질을 더욱 향상시킬 수 있습니다. 자세한 내용은 Mosaic AI 모델 훈련: Databricks에서 특수 작업 및 지식에 대한 LLM 파인튜닝 을 참조하십시오.

Databricks에서 미세 조정 시작하기

임베딩을 미세 조정하는 것은 AI 시스템에서 검색 및 RAG를 향상시키는 데 쉬운 승리 가 될 수 있습니다. Databricks에서는 다음을 수행할 수 있습니다:

• 확장 가능한 인프라에서 임베딩 모델을 세부 조정하고 제공 합니다.
• 벡터 검색, 리랭킹, RAG를 위한 내장 도구 사용.
• 다양한 모델을 빠르게 테스트 하여 사용 사례에 가장 적합한 것을 찾습니다.

시도해 보시겠습니까? 우리는 미세조정을 더 쉽게 만들기 위한 참조 솔루션을 구축했습니다—Databricks 계정 담당자 또는 솔루션 아키텍트에게 연락하여 접근하세요.

부록

표 1: gte-large-en-v1.5, e5-mistral-7b-instruct 그리고 text-embedding-3-large의 비교. 그림 1과 같은 데이터.

합성 훈련 데이터 생성

모든 데이터셋에서, 훈련 세트의 쿼리는 테스트 세트의 쿼리와 동일하지 않았습니다. 그러나, Databricks DocsQA의 경우 (하지만 FinanceBench나 ManufactQA는 아님), 합성 쿼리를 생성하는 데 사용된 문서는 평가 세트에서 사용된 문서와 동일했습니다. 우리 연구의 초점은 특정 작업과 도메인에서 검색을 개선하는 것입니다 (제로샷, 일반화 가능한 임베딩 모델과는 반대); 따라서 우리는 이를 특정 생산 용도로 유효한 접근법으로 보고 있습니다. FinanceBench와 ManufactQA의 경우, 합성 데이터를 생성하는 데 사용된 문서는 평가에 사용된 코퍼스와 겹치지 않았습니다.

대조 훈련을 위해 부정적인 구절을 선택하는 여러 가지 방법이 있습니다. 무작위로 선택하거나, 미리 정의할 수 있습니다. 첫 번째 경우에서, 부정적인 구절은 훈련 배치 내에서 선택됩니다; 이들은 종종 "배치 내 부정적인 것들" 또는 “소프트 부정적인 것들”로 불립니다. 두 번째 경우, 사용자는 의미론적으로 어려운 텍스트 예시를 미리 선택합니다. 즉, 쿼리와 관련이 있지만 약간 잘못되거나 관련이 없을 수 있습니다. 이 두 번째 경우는 때때로 "하드 부정적인 것들"이라고 불립니다. 이 작업에서, 우리는 단순히 배치 내 부정적인 것들을 사용했습니다; 문헌에 따르면 하드 부정적인 것들을 사용하면 더 좋은 결과를 얻을 가능성이 높습니다.

미세 조정 세부 사항

모든 파인튜닝 실험에서, 최대 시퀀스 길이는 2048로 설정됩니다. 그런 다음 모든 체크포인트를 평가했습니다. 모든 벤치마킹에서, 말뭉치 문서는 2048 토큰으로 잘렸습니다(청크화되지 않음), 이는 우리의 특정 데이터셋에 대한 합리적인 제약이었습니다.  쿼리 프롬프트와 풀링 전략을 훑어본 후 각 벤치마크에서 가장 강력한 기준선을 선택합니다. 

RAG 성능 향상

RAG 시스템은 검색기와 생성 모델을 모두 포함합니다. 검색기는 특정 쿼리와 관련된 문서 세트를 선택하고, 이를 생성 모델에 공급합니다. 우리는 최고의 세밀하게 튜닝된 gte-large-en-v1.5 모델을 선택하고, 이를 간단한 RAG 시스템의 첫 번째 검색 단계에 사용했습니다(일반적인 접근 방식은 LLMs의 Long Context RAG 성능 및 OpenAI o1과 Google Gemini의 Long Context RAG 기능에서 설명되어 있습니다). 특히, 우리는 최대 길이가 512 토큰인 각 k=10 문서를 검색하고, GPT4o를 생성 LLM으로 사용했습니다. 최종 정확도는 LLM-as-a-judge (GPT4o)를 사용하여 평가되었습니다.

FinanceBench에서, 그림 3은 파인튜닝된 임베딩 모델을 사용하면 다운스트림 RAG 정확도가 향상된다는 것을 보여줍니다. 또한, 이는 text-embedding-3-large와 경쟁력이 있습니다. 이는 파인튜닝 gte가 기준 gte에 대한 Recall@10 을 크게 향상시켰기 때문에 예상되는 결과입니다 (그림 1). 이 예는 특정 도메인과 데이터셋에서 임베딩 모델 파인튜닝의 효과를 잘 보여줍니다.

Databricks DocsQA 데이터셋에서는, 파인튜닝된 gte 모델을 사용할 때 기본 gte보다 개선된 점을 찾지 못했습니다. 이것은 다소 예상되는 결과로, 그림 1과 2에서 기준 모델과 파인튜닝된 모델 사이의 차이가 작기 때문입니다. 흥미롭게도, text-embedding-3-large가 gte 모델들 중 어느 것보다도 (약간) 높은 Recall@10 을 가지고 있지만, 이는 더 높은 다운스트림 RAG 정확도로 이어지지 않습니다. 그림 1에서 보여지는 것처럼, 모든 임베딩 모델들은 Databricks DocsQA 데이터셋에서 상대적으로 높은 Recall@10 을 가지고 있었는데, 이는 RAG에 대한 검색이 병목 현상이 아닐 가능성이 높으며, 이 데이터셋에서 임베딩 모델을 파인튜닝하는 것이 반드시 가장 유익한 접근 방식이 아님을 나타냅니다.

우리는 이 블로그 포스트에 대한 피드백을 주신 Quinn Leng과 Matei Zaharia에게 감사의 말씀을 드립니다.