벡터 검색부터 강력한 REST API까지, Elasticsearch는 개발자에게 가장 폭넓은 검색 도구 키트를 제공합니다. GitHub의 샘플 노트북을 살펴보고 새로운 기능을 시험해 보세요. 무료 체험판을 시작하거나 지금 바로 Elasticsearch를 로컬에서 실행할 수도 있습니다.
모든 코드는 Searchlabs 리포지토리의 고급-걸레-기술 브랜치에서찾을 수 있습니다.
고급 RAG 기법에 대한 글 2부에 오신 것을 환영합니다! 이 시리즈의 1부에서는 고급 RAG 파이프라인의 데이터 처리 구성 요소를 설정하고, 논의하고, 구현하는 방법을 살펴봤습니다:

저자가 사용한 RAG 파이프라인입니다.
이 부분에서는 쿼리 및 구현 테스트를 진행하겠습니다. 바로 본론으로 들어가 보겠습니다!
목차
검색 및 검색, 답변 생성
첫 번째 질문은 주로 연례 보고서에서 찾을 수 있는 정보에 대해 물어보겠습니다. 어때요?
이제 몇 가지 기술을 적용하여 쿼리를 개선해 보겠습니다.
동의어로 쿼리 강화하기
먼저, 쿼리 문구의 다양성을 높이고 이를 Elasticsearch 쿼리로 쉽게 처리할 수 있는 형태로 바꿔보겠습니다. 쿼리를 OR 절의 목록으로 변환하기 위해 GPT-4o의 도움을 받겠습니다. 이 프롬프트를 작성해 보겠습니다:
쿼리에 적용하면 GPT-4o는 기본 쿼리의 동의어와 관련 어휘를 생성합니다.
ESQueryMaker 클래스에서 쿼리를 분할하는 함수를 정의했습니다:
이 OR 절의 문자열을 가져와 용어 목록으로 분할하여 주요 문서 필드에서 다중 일치를 수행할 수 있도록 하는 역할을 합니다:
마지막으로 이 쿼리로 마무리합니다:
이렇게 하면 원래 쿼리보다 더 많은 기반을 포함하므로 동의어를 잊어버려 검색 결과가 누락되는 위험을 줄일 수 있습니다. 하지만 더 많은 일을 할 수 있습니다.
HyDE(가상의 문서 임베딩)
이번에는 HyDE를 구현하기 위해 GPT-4o를 다시 사용해 보겠습니다.
HyDE의 기본 전제는 가상의 문서, 즉 원래 쿼리에 대한 답변이 포함될 가능성이 있는 문서를 생성하는 것입니다. 문서의 사실 여부나 정확성은 문제가 되지 않습니다. 이를 염두에 두고 다음 프롬프트를 작성해 보겠습니다:
벡터 검색은 일반적으로 코사인 벡터 유사성을 기반으로 작동하므로, HyDE의 전제는 쿼리와 문서가 아닌 문서와 문서를 일치시킴으로써 더 나은 결과를 얻을 수 있다는 것입니다.
우리가 신경 쓰는 것은 구조, 흐름, 용어입니다. 사실과 다릅니다. GPT-4o는 다음과 같이 HyDE 문서를 출력합니다:
색인하려는 종류의 문서에 이상적인 후보처럼 꽤 그럴듯해 보입니다. 이를 임베드하여 하이브리드 검색에 사용하겠습니다.
하이브리드 검색
이것이 바로 검색 로직의 핵심입니다. 어휘 검색 구성 요소는 생성된 OR 절 문자열이 됩니다. 고밀도 벡터 컴포넌트에는 HyDE 문서(일명 검색 벡터)가 내장됩니다. KNN을 사용하여 검색 벡터에 가장 가까운 여러 후보 문서를 효율적으로 식별합니다. 기본적으로 어휘 검색 컴포넌트를 TF-IDF 및 BM25를 사용한 점수화라고 부릅니다. 마지막으로, 어휘와 밀도 벡터 점수는 Wang 등이 권장하는 30/70 비율을 사용하여 결합됩니다.
마지막으로 RAG 함수를 조합할 수 있습니다. 쿼리부터 답변까지 RAG는 이 흐름을 따릅니다:
- 쿼리를 OR 절로 변환합니다.
- HyDE 문서를 생성하고 임베드합니다.
- 둘 다 하이브리드 검색에 입력으로 전달합니다.
- LLM의 컨텍스트 메모리(역 패킹) 역 패킹 예제에서 가장 관련성이 높은 점수가 "가장 최근의" 이 되도록 상위 n개의 결과를 검색하여 역 패킹합니다: 쿼리: "Elasticsearch 쿼리 최적화 기술" 검색된 문서(관련성 순으로 정렬): LLM 컨텍스트에 대한 순서가 역순입니다: 순서를 반대로 하면 가장 관련성이 높은 정보(1)가 컨텍스트의 마지막에 표시되어 답변 생성 중에 LLM으로부터 더 많은 관심을 받을 수 있습니다.
- "부울 쿼리를 사용하여 여러 검색 기준을 효율적으로 결합할 수 있습니다."
- "캐싱 전략을 구현하여 쿼리 응답 시간을 개선하세요."
- "더 빠른 검색 성능을 위해 인덱스 매핑을 최적화하세요."
- "더 빠른 검색 성능을 위해 인덱스 매핑을 최적화하세요."
- "캐싱 전략을 구현하여 쿼리 응답 시간을 개선하세요."
- "부울 쿼리를 사용하여 여러 검색 기준을 효율적으로 결합할 수 있습니다."
- 생성할 컨텍스트를 LLM에 전달합니다.
쿼리를 실행하여 답변을 확인해 보겠습니다:
멋지네요. 맞습니다.
실험
지금 대답해야 할 중요한 질문이 있습니다. 이러한 구현에 많은 노력과 추가적인 복잡성을 투자하여 얻은 것은 무엇일까요?
간단한 비교를 해보겠습니다. 개선 사항 없이 기본 하이브리드 검색과 비교하여 구현한 RAG 파이프라인. 몇 가지 테스트를 실행하여 실질적인 차이를 발견할 수 있는지 확인해 보겠습니다. 방금 구현한 RAG를 AdvancedRAG라고 하고 기본 파이프라인을 SimpleRAG라고 하겠습니다.

종소리와 휘파람이 없는 간단한 RAG 파이프라인
결과 요약
이 표에는 두 RAG 파이프라인에 대한 5가지 테스트 결과가 요약되어 있습니다. 답변의 세부 사항과 품질을 기준으로 각 방법의 상대적 우열을 판단했지만 이는 전적으로 주관적인 판단입니다. 이 표 아래에 실제 답변이 재현되어 있으므로 참고하시기 바랍니다. 그럼 이제 그 결과를 살펴보도록 하겠습니다!
SimpleRAG는 질문 1에 답할 수 없었습니다 & 5. AdvancedRAG는 질문 2, 3, 4에 대해서도 훨씬 더 자세히 설명했습니다. 더 자세히 설명한 것을 바탕으로 저는 AdvancedRAG의 답변 품질이 더 좋다고 판단했습니다.
| 테스트 | 질문 | 고급RAG 성능 | SimpleRAG 성능 | AdvancedRAG 지연 시간 | SimpleRAG 지연 시간 | 우승자 |
|---|---|---|---|---|---|---|
| 1 | 누가 Elastic을 감사하나요? | 감사인으로 PwC를 올바르게 식별했습니다. | 감사자를 식별하지 못했습니다. | 11.6s | 4.4s | AdvancedRAG |
| 2 | 2023년 총 수익은 얼마였나요? | 정확한 수익 수치를 제공했습니다. 전년도 수익에 대한 추가 컨텍스트가 포함되어 있습니다. | 정확한 수익 수치를 제공했습니다. | 13.3s | 2.8s | AdvancedRAG |
| 3 | 성장은 주로 어떤 제품에 의존하나요? 얼마예요? | 핵심 동인으로 Elastic Cloud를 올바르게 식별했습니다. 전체 수익 컨텍스트 포함 & 더 자세한 내용. | 핵심 동인으로 Elastic Cloud를 올바르게 식별했습니다. | 14.1s | 12.8s | AdvancedRAG |
| 4 | 직원 복리후생 계획 설명 | 퇴직 계획, 건강 프로그램 및 기타 혜택에 대한 포괄적인 설명을 제공합니다. 연도별 구체적인 기부 금액이 포함되어 있습니다. | 보상, 퇴직 계획, 근무 환경, Elastic Cares 프로그램을 포함한 복리후생에 대한 좋은 개요를 제공했습니다. | 26.6s | 11.6s | AdvancedRAG |
| 5 | Elastic은 어떤 회사를 인수했나요? | 보고서에 언급된 최근 인수를 올바르게 나열했습니다(CmdWatch, 빌드 시큐리티, 옵티마이즈). 일부 인수 날짜와 구매 가격을 제공했습니다. | 제공된 컨텍스트에서 관련 정보를 검색하지 못했습니다. | 11.9s | 2.7s | AdvancedRAG |
테스트 1: 누가 Elastic을 감사하나요?
AdvancedRAG
SimpleRAG
요약: SimpleRAG는 PWC를 감사인으로 지정하지 않았습니다.
사실 꽤 놀랍습니다. SimpleRAG 측의 검색 실패로 보입니다. 감사 관련 문서가 검색되지 않았습니다. 다음 테스트에서는 난이도를 조금 낮춰보겠습니다.
테스트 2: 총 수익 2023년
AdvancedRAG
SimpleRAG
요약: 두 RAG 모두 2023년 총 수익 1,068,989,000달러라는 정답을 얻었습니다.
둘 다 바로 여기에 있었습니다. AdvancedRAG가 더 광범위한 문서를 확보한 것 같나요? 물론 답변은 더 상세하고 지난 몇 년간의 정보를 포함하고 있습니다. 개선 사항을 고려할 때 예상되는 부분이지만, 아직 확정하기에는 이르다고 할 수 있습니다.
난이도를 높여 보겠습니다.
테스트 3: 성장은 주로 어떤 제품에 의존하나요? 얼마예요?
AdvancedRAG
SimpleRAG
요약: 두 RAG 모두 Elastic Cloud를 핵심 성장 동력으로 정확하게 파악했습니다. 그러나 AdvancedRAG에는 구독 수익과 고객 성장을 고려한 더 자세한 내용이 포함되어 있으며, 다른 Elastic 제품에 대해서도 명시적으로 언급하고 있습니다.
테스트 4: 직원 복리후생 계획 설명
AdvancedRAG
SimpleRAG
요약: AdvancedRAG는 미국 거주 직원을 위한 401K 플랜을 언급하고 미국 외 지역의 기여금 플랜을 정의하는 등 훨씬 더 깊이 있고 자세하게 설명합니다. 또한 건강 및 웰빙 플랜에 대해서는 언급하고 있지만 SimpleRAG에서 언급하는 Elastic Cares 프로그램은 누락되어 있습니다.
테스트 5: Elastic은 어떤 회사를 인수했나요?
AdvancedRAG
SimpleRAG
요약: SimpleRAG가 인수에 대한 관련 정보를 검색하지 않아 답변이 실패했습니다. AdvancedRAG는 보고서에 나열된 주요 인수 기업인 CmdWatch, Build Security 및 Optimyze를 올바르게 나열합니다.
결론
테스트 결과, 고급 기술은 제시되는 정보의 범위와 깊이를 증가시켜 잠재적으로 RAG 답변의 품질을 향상시키는 것으로 나타났습니다.
또한 Which companies did Elastic acquire?, Who audits Elastic 같은 모호한 단어로 된 질문은 AdvancedRAG에서는 정답을 맞혔지만 SimpleRAG에서는 그렇지 않았기 때문에 신뢰도가 개선될 수 있습니다.
그러나 5건 중 3건의 경우, 하이브리드 검색을 포함하지만 다른 기술은 사용하지 않는 기본 RAG 파이프라인이 대부분의 핵심 정보를 포착하는 답변을 생성했다는 점을 유념할 필요가 있습니다.
데이터 준비 및 쿼리 단계에 LLM이 통합되어 있기 때문에 AdvancedRAG의 지연 시간은 일반적으로 SimpleRAG보다 2~5배 더 길다는 점에 유의해야 합니다. 이는 상당한 비용이므로 지연 시간보다 응답 품질이 우선시되는 상황에서만 AdvancedRAG가 적합할 수 있습니다.
데이터 준비 단계에서 클로드 하이쿠나 GPT-4o-mini와 같은 더 작고 저렴한 LLM을 사용하면 상당한 지연 비용을 줄일 수 있습니다. 답변 생성을 위해 고급 모델을 저장합니다.
이는 Wang 등의 연구 결과와 일치합니다. 연구 결과에서 알 수 있듯이 개선 사항은 비교적 점진적으로 이루어졌습니다. 간단히 말해, 간단한 기본 RAG를 사용하면 저렴하고 빠르게 부팅할 수 있으면서도 괜찮은 최종 제품을 만들 수 있습니다. 저에게는 흥미로운 결론입니다. 속도와 효율성이 중요한 사용 사례의 경우 SimpleRAG가 현명한 선택입니다. 마지막 한 방울의 성능까지 끌어올려야 하는 사용 사례의 경우 AdvancedRAG에 통합된 기술이 한 가지 방법을 제시할 수 있습니다.

Wang 등의 연구 결과에 따르면 고급 기술을 사용하면 일관적이면서도 점진적인 개선 효과를 얻을 수 있습니다.
부록
프롬프트
RAG 질문 답변 프롬프트
쿼리 및 컨텍스트에 따라 LLM이 답변을 생성하도록 하기 위한 프롬프트입니다.
Elastic 쿼리 생성기 프롬프트
동의어로 쿼리를 보강하고 OR 형식으로 변환하는 프롬프트입니다.
잠재적 질문 생성기 프롬프트
잠재적인 질문을 생성하고 문서 메타데이터를 보강하는 프롬프트입니다.
HyDE 생성기 프롬프트
HyDE를 사용하여 가상의 문서를 생성하는 프롬프트




