PseudoRec

Seven Failure Points When Engineering a Retrieval Augmented Generation System

6

Introduction

ChatGPT를 비롯해 LLM을 이용한 어플리케이션이 많아지고 있습니다. 그러나 LLM은 최신 지식, 또는 특정 도메인에 특화된 지식을 다루는 데에는 분명한 한계를 가지고 있습니다. 이러한 니즈에 대응하는 방식은 크게 두 가지입니다.

  1. LLM을 파인튜닝하는 것
  2. RAG를 이용하여 LLM의 답변 생성을 돕는 것

이 논문에서는 RAG 이용 쪽에 초점을 맞추어, RAG 시스템을 구축하고 사용할 때 고민해야 하는 점들에 대해 다룹니다.

RAG란?

아마 이 발표를 듣고 있는 분들이라면 RAG가 뭔지는 다들 아시겠죠?

RAG는 "Retrieval-Augmented Generation"의 약자로, 정보 검색과 생성 언어 모델을 결합한 접근 방식을 의미합니다. 이 방법은 다음과 같은 과정을 포함합니다:

  1. 정보 검색: 사용자의 질문이나 요청에 대한 관련 정보를 외부 데이터베이스나 문서에서 검색합니다. 이 단계는 사용자가 필요로 하는 정확하고 구체적인 정보를 찾아내기 위해 이루어집니다.

  2. 정보 생성: 검색된 정보를 기반으로 언어 모델이 응답을 생성합니다. 이 과정에서는 검색된 데이터와 모델의 사전 지식이 결합되어 사용자에게 적절한 답변을 제공합니다.

이러한 방식은 특히 복잡한 질문이나 다양한 정보가 요구되는 상황에서 효과적이며, 최신 정보나 특정 데이터에 대한 정확성을 높이는 데 기여합니다. RAG는 고객 지원, 교육, 정보 검색 시스템 등 다양한 분야에서 활용될 수 있습니다.

...라고 ChatGPT가 말하네요.

이 논문에서는 3개 분야(연구, 교육, 생의학)의 사례 연구를 통해, RAG가 제대로 작동하지 않는 경우를 7가지 정리해보았다고 합니다.

Related Works

RAG 파이프라인에서, LLM은 정보 수집 / 데이터 생성 / 편집 등 다양한 용도로 사용됩니다. 이런 RAG에서 생길 수 있는 문제들은 기존의 information retrieval system에서 생길 수 있는 문제들과 맞닿아 있다고 합니다. 아래와 같은 것들이 있다고 하네요.

  1. 쿼리 재작성(query re-writing)에 대한 평가 지표 없음
  2. 문서 재등급(document re-ranking)
  3. 효율적인 문서 요약

Retrieval-Augmented Generation (RAG)

ChatGPT, Claude, Bard와 같은 대형 언어 모델(LLM) 서비스가 급격히 인기를 얻으면서 사람들은 이들을 질문-답변 시스템으로 활용하기 시작했습니다. 성능은 인상적이지만 두 가지 근본적인 문제점이 있습니다:

  • LLM의 문제

    1. 환각(hallucinations) - LLM이 겉보기에는 맞는 것 같지만 실제로는 잘못된 답변을 생성하는 경우,

    2. 비제어성(unbounded) - 출력 결과를 특정 방향으로 유도하거나 업데이트할 수 있는 방법이 부족하다는 점 (프롬프트 엔지니어링을 제외하고).

→ RAG 시스템은 LLM을 직접 사용하는 데 발생하는 이러한 한계를 극복하기 위해 설계된 정보 검색 방식입니다.

  • RAG 프로세스 및 실패할 수 있는 부분

image

  • 시스템을 만들기 위해 필요한 (1)인덱싱 및 (2)쿼리 프로세스

이 그림은 Retrieval Augmented Generation (RAG) 시스템을 구축할 때 필요한 인덱싱(Indexing) 과정과 쿼리(Query) 과정(2가지의 별도 절차)을 시각적으로 설명한 다이어그램입니다.

1. 인덱싱 과정 (Index Process):

RAG 시스템에서 검색 시스템은 문서의 압축된 의미 표현을 제공하는 임베딩을 사용합니다. 임베딩은 숫자로 표현된 벡터입니다. 인덱싱 과정에서는 각 문서를 더 작은 조각으로 분할하고, 이를 임베딩 모델을 사용해 임베딩으로 변환합니다. 이 원본 조각과 임베딩은 데이터베이스에 인덱싱됩니다.

[프로세스]

  • Documents (문서): 먼저, 시스템은 다양한 문서를 처리해야 합니다.
  • Chunker (문서 분할기): 문서는 작은 조각들로 분할되며, 이를 "Chunks"라 부릅니다. 이 단계에서는 문서를 적절하게 나누는 것이 중요한데, 너무 작은 조각이면 필요한 정보를 모두 담지 못하고, 너무 크면 답변 생성 시 잡음이 발생할 수 있습니다.
  • Database (데이터베이스): 분할된 문서 조각들은 임베딩을 통해 벡터화되고, 데이터베이스에 저장됩니다.
  • **실패 지점 (빨간색 박스)**:
    • "Missing Content" (누락된 내용): 인덱싱 단계에서 문서의 중요한 부분이 누락될 수 있는 문제가 발생할 수 있습니다.

[문서 유형에 따른 분할과 처리 단계]

문서 유형에 따라 분할과 처리 단계가 다를 수 있습니다. 예를 들어, 비디오 콘텐츠는 인코딩 전에 오디오를 추출해 텍스트로 변환하는 전사 파이프라인이 필요합니다.

[임베딩 선택]

어떤 임베딩을 사용할지 선택하는 것도 중요한데, 임베딩 전략을 바꾸면 모든 조각을 다시 인덱싱해야 하기 때문입니다. 임베딩은 의미적으로 올바른 응답을 검색할 수 있는 능력에 따라 선택되어야 합니다.

이 과정은 조각의 크기, 예상되는 질문 유형, 콘텐츠 구조, 그리고 애플리케이션 도메인에 따라 달라집니다.

2. 쿼리 과정 (Query Process):

쿼리 프로세스는 실시간으로 이루어집니다.

[프로세스]

  • Query (질문): 사용자가 자연어로 질문을 입력합니다.
  • Rewriter (재작성기): 이 질문은 새로운 쿼리로 변환됩니다. 여기에는 이전 대화나 맥락이 포함될 수 있습니다.
    • 자연어로 표현된 질문은 먼저 일반 쿼리로 변환됩니다. (이를 일반화하기 위해 LLM을 사용)
  • Retriever (검색기): 변환된 쿼리는 데이터베이스에서 관련된 문서 조각들을 찾아냅니다.
    • 그 다음 새 쿼리에서 임베딩이 계산되어, 데이터베이스에서 관련 문서를 찾는 데 사용됩니다. 코사인 유사도와 같은 유사도 방법을 사용하여 유사한 상위 k개의 문서가 검색됩니다.
    • (카카오 - 벡터 데이터베이스는 검색 시간을 단축시키기 위해 역인덱스 기술을 사용하기도 합니다). 질문과 의미적으로 가까운 조각들이 답을 포함할 가능성이 큽니다.
  • Reranker (재정렬기): 검색된 문서 조각들은 재정렬되어, 가장 관련성이 높은 조각이 상단에 오도록 합니다.
    • (카카오 Optional - llm 사용)
  • Consolidator (통합기): 이 단계에서는 검색된 문서 조각들을 처리하여 문맥에 맞는 답변을 생성할 수 있도록 합니다.
    • 이 단계는 LLM의 한계인 1) 토큰 제한과 2) 속도 제한을 극복하기 위해 필요합니다.
    • 예를 들어 OpenAI 서비스는 프롬프트에 포함할 수 있는 텍스트 양에 대해 엄격한 제한을 두고 있으며, 답변을 추출하기 위해 프롬프트에 포함할 수 있는 조각 수를 제한합니다. 이러한 서비스는 일정 시간 내에 사용할 수 있는 토큰 수에도 제한을 두어 시스템의 지연 시간에도 영향을 미칩니다. 소프트웨어 엔지니어들은 RAG 시스템을 설계할 때 이러한 타협점을 고려해야 합니다.

[프로세스 - RAG 파이프라인의 마지막 단계는 생성된 텍스트에서 답변을 추출하는 단계입니다.]

  • Reader (리더): 생성된 답변을 최종적으로 필터링하고, 형식화하여 사용자에게 반환할 수 있는 형태로 만듭니다.
    • 프롬프트에서 잡음을 걸러내고, 형식화 지침(예: 질문을 목록 형식으로 답변) 등을 따르며, 쿼리에 대한 결과물을 생성하는 역할을 합니다.
  • Response (응답): 최종적으로 사용자에게 제공되는 답변입니다.
  • **실패 지점 (빨간색 박스)**:
    • "Missed Top Ranked" (상위 순위 놓침): 검색된 문서들 중 가장 중요한 정보가 상위에 오지 못할 수 있습니다.
    • "Not in Context" (문맥에 맞지 않음): 통합 단계에서 문서가 맥락에 맞지 않는 방식으로 처리될 수 있습니다.
    • "Wrong Format" (잘못된 형식): 리더 단계에서 답변의 형식이 잘못되거나 요구 사항에 맞지 않게 될 수 있습니다.
    • "Not Extracted" (추출 실패): 답변 생성 과정에서 적절한 답변을 추출하지 못할 수 있습니다.
    • "Incomplete" (불완전한 답변): 최종적으로 사용자에게 제공되는 답변이 불완전할 수 있습니다.
    • “Incorrect Specificity” (부정확한 구체성): RAG 시스템에서 발생할 수 있는 실패 지점 중 하나로, 반환된 답변이 사용자의 질문에 대해 너무 구체적이거나 반대로 너무 일반적인 경우를 의미합니다.

[RAG 장점과 한계]

  • 장점
    • 문서에서 실시간으로 질문에 답변을 생성하는 대형 언어 모델의 사용은 새로운 질문-답변 능력이 필요한 응용 분야를 열어줍니다.
  • 단점
    • RAG 시스템은 테스트하기가 어려운데, 기존에 데이터가 없고

      a) 합성 데이터 생성 또는

      b) 최소한의 테스트를 거친 시스템 시범 운용을 통해 실험적으로 발견해야 하기 때문입니다.

사례 연구

이 연구는 RAG 시스템을 구현할 때 발생하는 문제들을 발견하기 위해 세 가지 사례 연구를 진행했습니다. 각 사례 연구의 요약은 표 1에 나와 있습니다.

모든 스크립트, 데이터, 그리고 BioASQ 사례 연구에서 발생한 실패 지점들의 예시는 온라인에서 제공됩니다. 다른 두 사례 연구는 기밀 유지 문제로 제외되었습니다.

imageTable 1

1) 인지 리뷰어 (Cognitive Reviewer)

Cognitive Reviewer는 과학 문서를 분석하는 데 연구자들을 지원하기 위한 RAG 시스템입니다.

연구자들은 연구 질문이나 목표를 지정한 후 관련 연구 논문들을 업로드합니다. 모든 문서는 연구자가 수동으로 검토할 수 있도록 지정된 목표에 따라 순위가 매겨집니다. 연구자는 또한 업로드된 모든 문서에 대해 직접 질문을 할 수 있습니다.

Cognitive Reviewer는 현재 Deakin 대학교의 박사 과정 학생들이 문헌 리뷰를 지원받기 위해 사용하고 있습니다. 이 시스템은 인덱싱 과정을 실시간으로 수행하며, 업로드된 문서를 처리하기 위해 견고한 데이터 처리 파이프라인을 필요로 합니다(개발 단계에서는 품질 관리를 할 수 없음). 이 시스템은 또한 업로드된 문서를 정렬하기 위한 순위 매기기 알고리즘을 사용합니다.

2) AI 튜터 (AI Tutor)

AI Tutor는 학생들이 수업 내용에 대해 질문할 수 있는 RAG 시스템이며, 답변은 학습 자료에서 추출됩니다. 학생들은 답변의 출처 목록을 확인하여 답변이 어디에서 왔는지 확인할 수 있습니다.

AI TutorDeakin 대학교의 학습 관리 시스템에 통합되어 있으며, PDF 문서, 비디오, 텍스트 문서 등을 모두 인덱싱합니다. 인덱싱 과정의 일부로, 비디오는 Whisper라는 딥러닝 모델을 사용해 전사(음성을 텍스트로 변환)된 후 분할됩니다.

AI Tutor는 2023년 8월부터 11월까지 개발되어 2023년 10월 30일부터 시작된 200명의 학생이 있는 파일럿 유닛에서 사용되고 있습니다. 이 시스템 구현에서 얻은 교훈을 제시하고, 파일럿이 종료된 후 추가적인 결과를 발표할 예정입니다.

이 RAG 파이프라인은 쿼리를 일반화하기 위해 재작성기(rewriter)를 포함하고 있습니다. 우리는 이전 대화 내용을 바탕으로 문맥을 반영하여 쿼리를 재작성하는 채팅 인터페이스를 구현했습니다. 이 재작성기는 "이 개념을 더 설명해 주세요."와 같은 모호한 요청을 해결하기 위해 문맥을 고려하여 쿼리를 수정합니다.

3) 생의학 질문과 답변 (Biomedical Question and Answer)

앞선 사례 연구들은 작은 콘텐츠 크기의 문서들에 초점을 맞췄습니다.

더 큰 규모에서 발생하는 문제를 탐구하기 위해 우리는 BioASQ 데이터 세트를 사용한 RAG 시스템을 만들었습니다. 이 데이터 세트는 질문, 문서 링크, 그리고 답변으로 구성되어 있습니다. 질문에 대한 답변은 '예/아니오', 텍스트 요약, 사실 확인, 또는 목록 형태였습니다.

이 데이터 세트는 생의학 전문가들이 준비한 자료로, 특정 도메인에 맞춘 질문과 답변 쌍을 포함하고 있습니다. 우리는 BioASQ 데이터 세트에서 4017개의 오픈 액세스 문서를 다운로드하여 총 1000개의 질문을 만들었습니다.

모든 문서를 인덱싱하고 RAG 시스템에서 질문에 대한 답변을 생성했습니다. 생성된 질문은 OpenEvals 기술을 사용해 평가되었으며, 이 기술은 OpenAI에서 구현했습니다. 생성된 질문 중 40개의 문제를 수동으로 검사했고, OpenEvals에서 부정확하다고 표시된 모든 문제를 확인했습니다.

우리는 자동화된 평가가 인간 평가자보다 더 비관적이라는 것을 발견했습니다. 그러나 이 결과의 신뢰성에 대한 한 가지 위협 요소는 BioASQ가 특정 도메인의 데이터 세트라는 점이며, 리뷰어들이 해당 분야의 전문가가 아니었다는 점입니다. 즉, LLM이 비전문가보다 더 많은 지식을 가지고 있을 수 있습니다.

  • OpenEvals: OpenAI에서 제공하는 자동화된 평가 시스템으로, 생성된 답변의 정확도를 평가하는 데 사용됩니다.

RAG 시스템의 실패 지점

사례 연구를 통해 우리는 RAG 시스템을 구현할 때 발생할 수 있는 몇 가지 실패 지점을 확인했습니다. 다음은 이 연구에서 다룬 연구 질문인 RAG 시스템을 설계할 때 발생하는 실패 지점은 무엇인가? 에 대한 답변입니다.

[Index Process]

  • FP1: 누락된 내용 (Missing Content)

    첫 번째 실패는 제공된 문서에서 답변을 찾을 수 없을 때 발생합니다.

    이상적인 경우 RAG 시스템은 "죄송합니다, 답을 알 수 없습니다"와 같은 응답을 제공해야 합니다. 하지만 질문이 문서와 관련이 있지만 답변이 없는 경우, 시스템은 잘못된 답변을 할 수 있습니다.

[Query Process]

  • FP2: 상위 순위 문서를 놓침 (Missed the Top Ranked Documents)

    답변이 문서에 포함되어 있지만, 상위 순위에 들지 못해 사용자에게 반환되지 않은 경우입니다. 이론적으로 모든 문서는 순위가 매겨져 사용되지만, 실제로는 성능을 고려해 상위 K개의 문서만 반환됩니다.

  • FP3: 문맥에 포함되지 않음 (Not in Context - Consolidation Strategy Limitations)

    답변이 포함된 문서가 데이터베이스에서 검색되었지만, 답변을 생성하는 과정에서 문맥에 포함되지 않은 경우입니다.

    이는 너무 많은 문서가 반환될 때 발생하며, 이때 통합 과정에서 일부 문서가 누락될 수 있습니다.

  • FP4: 추출되지 않음 (Not Extracted)

    문맥에 답이 포함되어 있지만, 대형 언어 모델이 올바른 답변을 추출하지 못한 경우입니다.

    보통 문맥에 너무 많은 잡음이나 상반되는 정보가 있을 때 발생합니다.

  • FP5: 잘못된 형식 (Wrong Format)

    질문에서 표나 목록과 같은 특정 형식으로 정보를 추출해야 하지만, 대형 언어 모델이 그 지침을 무시한 경우입니다.

  • FP6: 부정확한 구체성 (Incorrect Specificity)

    답변이 반환되었지만 사용자의 요구에 맞게 너무 구체적이거나 너무 일반적인 경우입니다.

    이는 특히 교육 콘텐츠처럼 특정 질문에 대해 구체적인 정보를 제공해야 하는 경우 발생할 수 있습니다. 또한 사용자가 질문을 너무 일반적으로 물어볼 때도 발생할 수 있습니다.

  • FP7: 불완전함 (Incomplete)

    답변이 틀리지는 않지만, 문맥에 정보가 있음에도 불구하고 일부 정보를 놓친 경우입니다.

    예를 들어, "문서 A, B, C에서 다룬 주요 내용을 알려주세요"라는 질문이 있을 때, 이 질문들을 별도로 물어보는 것이 더 나은 접근 방식입니다.

교훈 및 향후 연구 방향

세 가지 사례 연구에서 얻은 교훈은 표 2에 나와 있습니다. 이 섹션에서는 “RAG 시스템을 설계할 때 고려해야 할 주요 사항은 무엇인가?”라는 연구 질문에 대한 결과를 제시합니다.

이 연구에서 얻은 통찰을 바탕으로, RAG 시스템과 관련된 여러 잠재적인 연구 분야를 식별했습니다.

image

💡 각 실패 지점에서 얻은 중요한 교훈을 설명합니다.

  1. FP4 추출되지 않음 (Not Extracted): 더 넓은 문맥이 더 나은 결과를 가져옴
    • 더 넓은 문맥(8K vs 4K)을 사용할 때 더 정확한 응답이 생성되었음.
    • 사례 연구: AI Tutor
  2. FP1 누락된 내용 (Missing Content): 의미론적 캐싱이 비용과 지연 시간을 줄임
    • 자주 묻는 질문을 미리 캐싱하면 성능이 향상되고, 동시 사용자 문제를 해결할 수 있음.
    • 사례 연구: AI Tutor
  3. FP5-7: Jailbreak가 RAG 시스템을 우회함
    • 잘못된 형식 (Wrong Format), 부정확한 구체성 (Incorrect Specificity), 불완전함 (Incomplete)
    • 일부 연구에서는 LLM(대규모 언어 모델, Large Language Models)을 미세 조정(fine-tuning)하면 안전 훈련의 효과가 약화될 수 있다는 것을 시사합니다.
    • 이를 해결하기 위해, 연구에서는 모든 미세 조정된 LLMRAG 시스템에서 제대로 동작하는지 테스트할 필요가 있다고 제안.
      • Jailbreaks는 원래 시스템이 설정한 규칙이나 제한을 피해서, AI가 원래 허용되지 않은 답변이나 행동을 할 수 있게 만드는 방법을 말합니다.
    • 사례 연구: AI Tutor
  4. FP2, FP4: 메타데이터 추가는 검색 성능을 향상시킴
    • 상위 순위 문서를 놓침 (Missed the Top Ranked Documents), 추출되지 않음 (Not Extracted)
    • 파일 이름 및 문서의 특정 부분 번호를 추가하면 검색 성능을 개선할 수 있음.
    • 사례 연구: BioASQ, AI Tutor
  5. FP2, FP4-7: 오픈 소스 임베딩 모델이 짧은 텍스트에서 더 나은 성능을 발휘함
    • 오픈 소스 임베딩 모델이 특히 짧은 텍스트에 대한 성능이 우수하거나, 상업적으로 사용되는 클로즈드 소스 모델들과 비슷한 성능을 보여준다.
    • 사례 연구: BioASQ, AI Tutor
  6. FP2-7: RAG 시스템은 지속적인 보정이 필요함
    • 시스템은 계속해서 새로운 입력 데이터를 받아들이므로, 지속적인 모니터링과 조정이 필요함.
    • 사례 연구: AI Tutor, BioASQ
  7. FP1, FP2: RAG 파이프라인을 구현하여 설정을 진행
    • 누락된 내용 (Missing Content), 상위 순위 문서를 놓침 (Missed the Top Ranked Documents)
    • RAG 시스템을 최적화하려면 (청크 크기, 임베딩 전략, 청크 처리 전략, 검색 전략, 통합 전략, 컨텍스트 크기, 프롬프트 등)의 요소를 조정해야 한다.
    • 사례 연구: Cognitive Reviewer, AI Tutor, BioASQ
  8. FP2, FP4: 맞춤형 솔루션을 사용한 RAG 파이프라인은 최적이 아님
    • 상위 순위 문서를 놓침 (Missed the Top Ranked Documents), 추출되지 않음 (Not Extracted)
    • 맞춤형 솔루션으로 구성된 RAG 파이프라인이 비효율적(suboptimal)일 수 있다는 지적
    • 이러한 파이프라인은 최적화되지 않은 결과를 가져올 수 있습니다. 그리고 도메인 적응을 향상시키기 위해서는 끝까지(end-to-end) 학습을 해야 한다.
    • 사례 연구: BioASQ, AI Tutor
  9. FP2-7: 성능 특성 테스트는 실행 중에만 가능함
    • 오프라인 평가 기술인 G-Evals가 유망해 보이지만, 이는 라벨이 지정된 질문과 답변 쌍에 접근할 수 있다는 전제가 필요하다는 한계점이 있다고 설명
    • 사례 연구: Cognitive Reviewer, AI Tutor

교훈

1) 문서 분할과 임베딩 (Chunking and Embeddings)

문서를 분할하는 것은 간단해 보일 수 있지만, 분할의 질은 검색 과정에 여러 방식으로 영향을 미칩니다. 특히 임베딩이 사용자의 질문과 조각을 얼마나 잘 일치시키는지에 영향을 미칩니다. 문서를 분할하는 방법에는 두 가지가 있습니다:

  • 휴리스틱 기반 분할: 구두점이나 문단 끝 등을 기준으로 분할하는 방식
  • 의미 기반 분할: 텍스트의 의미를 바탕으로 시작과 끝을 정하는 방식

이 두 방법의 장단점을 탐구하고, 임베딩과 유사도 매칭 같은 다운스트림 프로세스에 미치는 영향을 연구할 필요가 있습니다. 이와 관련된 평가 프레임워크를 마련하여 분할 기술이 검색 정확도와 쿼리 적합성에 미치는 영향을 비교하는 것이 중요합니다.

또한, 표나 그림, 수식과 같은 멀티미디어 및 멀티모달 데이터를 위한 임베딩 생성도 활발한 연구 분야입니다. 문서가 인덱싱될 때 임베딩이 한 번 생성되며, 쿼리 전처리가 RAG 시스템의 성능에 큰 영향을 미칩니다. 부정적이거나 모호한 쿼리를 처리하는 방법에 대한 연구가 추가로 필요합니다.

  • 요약 (문서 분할의 방식이 RAG 시스템의 성능에 중요한 영향을 미침.)

    • 휴리스틱 기반 분할: 구두점이나 문단 등을 기준으로 분할.
    • 의미 기반 분할: 텍스트의 의미에 따라 분할.

    두 방법의 장단점을 탐구하고, 쿼리 적합성과 검색 정확도에 미치는 영향을 평가할 필요가 있음. 멀티미디어 데이터를 위한 임베딩 생성도 중요한 연구 분야로, 쿼리 전처리 과정이 시스템 성능에 크게 영향을 미침.

2) RAG와 미세 조정 (RAG vs Finetuning)

대형 언어 모델은 방대한 학습 데이터를 통해 일반적인 세계 지식을 가지고 있지만, 특정 도메인에 대한 지식이 부족하거나 최신 정보를 포함하지 못할 수 있습니다. 미세 조정(Finetuning)RAG는 각각의 맞춤화 경로를 제공하며, 서로 다른 장단점을 가지고 있습니다. 미세 조정은 내부 데이터를 활용하여 LLM을 학습시키는 방식이지만, 모델 자체가 진화하거나 새로운 데이터가 추가되면 다시 미세 조정을 해야 합니다. 반면, RAG 시스템은 문서를 필요한 만큼 분할하고 관련된 조각만 사용하여 LLM이 답변을 생성하게 함으로써 더 유연한 접근 방식을 제공합니다.

  • 요약

    • 미세 조정(Finetuning): 특정 도메인에 맞춰 LLM을 학습시키지만, 모델이 업데이트될 때마다 재학습이 필요함.
    • RAG 시스템: 문서를 조각내어 필요한 정보만 사용하여 더 유연하게 답변을 생성함.

    두 방법의 장단점을 비교 연구하여 정확성, 비용, 성능 등을 고려할 필요가 있음.

3) RAG 시스템의 테스트 및 모니터링 (Testing and Monitoring RAG systems)

RAG 시스템에 대한 소프트웨어 엔지니어링 모범 사례는 아직 발전 중입니다. RAG 시스템은 비구조화된 문서를 인덱싱할 때 특정 애플리케이션에 맞는 질문과 답변이 필요합니다. 대형 언어 모델을 사용해 문서에서 질문을 생성하는 연구도 진행 중이지만, 실제 도메인에 맞는 질문과 답변을 생성하는 문제는 아직 해결되지 않았습니다. 테스트 데이터를 마련한 후 품질 지표를 통해 엔지니어들이 품질을 판단할 수 있어야 합니다.

대형 언어 모델은 비용이 많이 들고 지연 시간이 발생하며, 새로운 릴리스가 나올 때마다 성능 특성이 달라질 수 있습니다. 이를 해결하기 위해 자동 적응 시스템 개념을 도입하여 RAG 시스템을 모니터링하고 조정하는 작업이 필요할 것입니다.

  • 요약
    • RAG 시스템의 테스트와 모니터링을 위한 소프트웨어 엔지니어링 모범 사례가 아직 발전 중.
    • RAG 시스템은 특정 도메인에 맞는 질문과 답변을 생성하기 위한 체계적인 테스트가 필요하며, 자동 적응 시스템을 도입하여 성능을 지속적으로 모니터링하고 조정해야 함.

결론

RAG(정보 검색 보강 생성) 시스템은 대형 언어 모델(LLM)을 활용한 새로운 정보 검색 방식입니다. 소프트웨어 엔지니어들은 RAG 시스템을 점점 더 많이 사용하고 있으며, 이는 두 가지 방식으로 이루어집니다:

a) 의미론적 검색을 구현하는 방식,

b) 새로운 코드 의존 작업을 수행하는 방식.

이 논문에서는 3개의 사례 연구에서 얻은 교훈을 제시했으며, 15,000개의 문서와 1,000개의 질문을 포함한 실험적 조사를 다루었습니다. 우리의 연구 결과는 RAG 시스템을 구현할 때 직면하는 도전 과제들을 설명하고, 실무자들에게 지침을 제공합니다.

또한 RAG 시스템과 관련된 향후 연구 방향도 제시했습니다:

  1. 문서 분할과 임베딩(chunking and embeddings),
  2. RAG 시스템과 미세 조정의 비교(RAG vs Finetuning),
  3. 테스트와 모니터링(Test and Monitoring).

대형 언어 모델은 앞으로도 소프트웨어 엔지니어와 연구자들에게 흥미로운 새로운 기능을 계속 제공할 것입니다. 이 논문은 소프트웨어 엔지니어링 관점에서 RAG 시스템에 대한 최초의 연구를 제시합니다.


Table of Contents

Leave a Comment:

Comments:

No comments yet. Be the first to comment!