notdecidedyet

오픈 소스 Python 기반 구현은 https://aka.ms/graphrag 곧 제공될 예정

0 Abstract

• "데이터셋의 주요 주제는 무엇인가?"와 같은 전체 텍스트 말뭉치를 대상으로 하는 전역적 질문에 대해서 잘 작동 안함
• 명시적인 검색 작업이 아닌 Query Focused Summarization(QFS) 작업이기 때문임
• Graph RAG는 RAG, QFA를 결합함
  • 1. 문서에서 중요 개념과 관계를 추출해서 지식 그래프를 만듬
  • 그래프에서 비슷한 개념들을 그룹화하고, 각 그룹에 대한 요약을 미리 생성

RAPTOR와 비슷한데..? 다만 RAPTOR는 노드간의 edge정보가 없음. & 과거 개발 되었던 알고리즘으로 GRAPH를 구성

1. Introduction

• 최근 대규모 언어 모델(LLM)를 사용해 복잡한 분야에서 인간과 유사한 센스메이킹을 자동화하려는 시도가 이루어지고 있음.
• 하지만 전체 텍스트 말뭉치에 대한 질문에 답하는 것은 여전히 어려움.
• 기존의 RAG 방식은 지역적인 정보 검색에는 효과적이지만, 전체 데이터셋에 대한 포괄적인 이해를 요구하는 질문에는 적합하지 않음
  
  • 모델의 컨텍스트창이 커지며, 많은 문장을 입력으로 사용할 수 있으나, Lost in the middle로 손실될 수 있는 정보들이 있음.
• 이 논문에서는 이러한 한계를 극복하기 위해 'Graph RAG' 제안 (Figure 1)
  • 이 방법은 LLM을 사용하여 문서에서 지식 그래프를 추출
  • 그래프 구조를 활용하여 효율적으로 전체 데이터셋을 요약
  • 실험 결과, 이 방법은 기존 RAG 방식보다 더 포괄적이고 다양한 답변을 생성할 수 있음을 보임

2 Graph RAG Approach & Pipeline

2.1 Source Document -> Text Chunks

문서에서 추출한 입력 텍스트를 처리를 위해 얼마나 짧게 텍스트 청크로 분할할 것인가 하는 것이다.

• 긴 청크 : LLM 호출 횟수를 줄이지만, 필요 없는 정보가 들어갈 수 있음.
• 작은 청크 : 더 많은 엔티티를 참조하여 추출해야함.

2.2 Text Chunks -> Element Instances

각 청크에서 그래프 노드와 엣지의 인스턴스를 식별 및 추출

• 다중 파트 LLM 프롬프트 사용해서 수행
  • 텍스트에서 모든 엔티티를 식별(이름, 유형, 설명 등)
  • 명확하게 관련된 엔티티 간의 모든 관계를 식별 (출발점, 도착점, edge에 관한 설명 포함)
  • 두 종류의 요소 인스턴스(엔티티-노드, 관계)는 모두 튜플 목록으로 출력
• 프롬프트로 엔티티, 관계 추출하는 방법
  • In-context Learning
    • 예를 들어, 이 연구의 기본 프롬프트는 사람, 장소, 조직과 같은 광범위한 "명명된 엔티티"를 추출 가능
      (과학, 의학, 법률)과 같은 전문 지식이 필요한 분야에서는 해당 도메인에 특화된 예시를 사용하면 더 좋은 결과를 얻을 수 있다.
  • 보조 추출 프롬프트 : 엔티티, 엣지 외에 추가적인 정보를 추출하기 위한 별도 지시문
    • 기본 속성 프롬프트 : 감지된 엔티티와 엣지를 추출하는 것을 목표
      여기에는 주제, 객체, 유형, 설명, 원본 텍스트 범위, 시작 및 종료 날짜가 포함
    • 예) 아인슈타인은 1921년에 노벨 물리학상을 수상했다
      • 주제 : 아인슈타인
      • 객체 : 노벨 물리학상
      • 유형 : 사실 진술
      • 설명 : 1921년에 노벨 물리학상 수상
      • 시작 날짜 : 1921년
  • 글리닝(Gleaning) : 이전에 놓친 정보를 다시한번 살피는 과정
    • 효율성과 품질의 균형을 맞추기 위해, 우리는 지정된 최대치까지 여러 라운드의 "글리닝"을 사용
    • LLM이 추출에서 놓친 엔티티를 감지하도록함.
      
      • 1) LLM에게 모든 엔티티가 추출되었는지 평가하도록 요청. 이때 예/아니오 결정을 강제하기 위해 100의 로짓 바이어스를 사용
      • 2) LLM이 엔티티가 누락되었다고 응답하면, "마지막 추출에서 많은 엔티티가 누락되었다"는 프롬프트를 사용하여 LLM이 이 누락된 엔티티들을 글리닝하도록 함.
    • 이 접근 방식을 통해 품질 저하나 노이즈 유입 없이 더 큰 청크 크기를 사용할 수 있다.(Figure 2)

2.3 Element Instances →Element Summaries

• LLM을 사용한 "추출"은 이미 일종의 추상적 요약 과정이다.
  
  • 문장 -> 노드, 엣지, 다양한 주제들
• 상위 그래프로 만들기 위해선, 단일 설명 텍스트로 변환을 해야하는데, 이때 LLM의 요약이 필요함.
  • 잠재적 문제: LLM이 동일한 엔티티를 일관되지 않게 추출할 수 있다.
    -> 이로 인해 중복 엔티티나 중복 노드가 생길 수 있다.
  • 해결책: 다음 단계에서 관련 엔티티들의 "커뮤니티"를 감지하고 요약한다.
    -> 중복된 노드들이 하나의 공통 엔티티에 속할 것이기에 로버스트하다.
    -> 단, 전제는, 같은 커뮤니티에 묶인 경우, 공통적인 주제에 대해서 묶여야 한다는 부분은 있음.

• 일반적인 graph와 차별화
  
  • 지식 그래프는 주로 간결한 지식 트리플(주제, 술어, 객체)에 의존
  • 반면, 풍부하게 텍스트로 설명을 함.

2.4 Element Summaries →Graph Communities

• 2.3 단계에서 생성된 인덱스는 '방향이 없고', '엣지에 가중'이 있는 그래프로 모델링
  • 엔티티가 노드
  • 관계가 엣지
  • 엣지 가중치는 (1/인스턴스)로 가중치가 부여됨.
• 커뮤니티 감지 알고리즘을 사용하여 그래프를 노드 커뮤니티로 분할한다.
• 이 파이프라인에서는 Leiden 알고리즘을 사용
  • 커뮤니티 수 등을 정함.
  • 개요 : 뇌피셜임.
    1) 각 노드를 개별 커뮤니티로 시작함.
    2) 개별 노드를 이웃 커뮤니티로 이동시켜보고, 모듈성 변화를 계산해봄
         (Computation Cost가 많을 것 같은데, 이에대한 최적화가 있을 것으로 예상함)
    3) 모듈성이 가장 많이 증가하는 이동을 선택
    4) 모듈성 증가가 없으면 노드는 원래 커뮤니티에 남는다.
    5) 1-4는 bottom Up이고, 완성된 Bottom Up에서 Top Down으로 이동 단계를 다시 수행해봄.

2.5 Graph Communities →Community Summaries

• Leiden 계층 구조의 각 커뮤니티에 대해 보고서 형식의 요약을 만드는 것
• 그래프 계층 구조는 Leiden으로 만들어짐.
• 목적 : 전역 쿼리에 답변하는데 사용되는 '인덱스'의 역할을 하기 위해, 요약 생성.
  - 이러한 요약은 그 자체로 데이터셋의 전체 구조와 의미를 이해하는 데 유용
  - 질문이 없는 상태에서도 말뭉치를 이해하는 데 사용될 수 있다.

• 커뮤니티 요약은 다음과 같은 방식으로 생성
  • 리프 레벨 커뮤니티: 엣지 중요도 계산
    • 우선순위가 정해진 후 토큰 제한에 도달할 때까지 반복적으로 LLM 컨텍스트 윈도우에 추가된다.
    • 우선순위 지정은 다음과 같이 이루어짐 :
      • 노드의 중요도 계산 : 노드가 얼마나 많은 연결을 가지고 잇는지 카운트(차수 라고 함)
        연결이 많을수록 그 노드는 중요하다고 간주 됨
      • 엣지의 중요도 결정 : 각 엣지는 두개의 노드를 연결하는데, 이 두 노드의 차수를 합산하여 엣지의 중요도를 결정
      • 엣지 정렬 : 모든 엣지를 중요도에 따라 내림차순으로 정렬 (노드의 중요도는 정렬시에 사용안함)
      • 정보 추가 : 엣지가 정렬된 순서대로 각 엣지에 대해:
        a) 소스 노드에 대한 설명 추가
        b) 타겟 노드에 대한 설명 추가
        c) 이 노드들과 관련된 추가 속성 정보 추가
        d) 엣지 자체(즉, 두 노드 간의 관계)에 대한 설명 추가
  • 상위 레벨 커뮤니티: 요약 생성
    • 모든 정보를 한번에 처리 가능한 경우(컨텍스트 윈도우)
      • 커뮤니티의 모든 요소(노드 엣지 등)에 대한 요약이 컨텍스트 윈도우에 다 들어가면,
      • 모든 요소에 대한 상세한 정보를 포함해 요약 생성
    • 정보가 너무 많아 한번에 처리 불가한 경우
      • a) 서브 커뮤니티(더 작은 하위 그룹)를 크기순으로 정렬. 더 많은 정보를 가진 서브 커뮤니티가 우선순위를 갖는다
      • b) 가장 큰 서브 커뮤니티부터 시작하여, 그 서브 커뮤니티의 전체 요약(더 짧은 버전)을 사용
      • c) 이 과정을 반복하면서 더 작은 서브 커뮤니티의 요약을 추가
      • d) 모든 정보가 주어진 공간에 맞을 때까지 이 과정을 계속 진행.

2.6 Community Summaries →Community Answers →Global Answer

• 사용자 쿼리가 주어지면, 이전 단계에서 생성된 커뮤니티 요약을 사용하여 여러단계 과정을 통해 최종 답변을 생성
• 쿼리와 모든 커뮤니티쌍 간의 요약을 만들고, 관련 있는 커뮤니티들만 필터링해서 점차 global answer로 다가감
  -> Cost가 상당히 많이 들어가겠는데?
• 최적의 균형 : 뇌피셜
  • 너무 상위 레벨을 사용하면 답변이 너무 일반적일 수 있고, 너무 하위 레벨을 사용하면 전체적인 맥락을 놓칠 수 있다.
  • 예: "전체적인 주제는 무엇인가요?"라는 질문에는 상위 레벨 요약이 적합할 수 있다.
  • 반면, "특정 주제에 대한 세부 정보는 무엇인가요?"라는 질문에는 하위 레벨 요약이 더 적합할 수 있다
  • 논문의 3절에서는 이러한 다양한 레벨의 요약을 사용했을 때의 효과를 실제로 평가
• 답변 생성 3 단계 :
  • Prepare community summaries : 정보를 균등하게 분배하여 중요한 내용이 누락되지 않도록 한다.
    • 과정:
      a) 모든 커뮤니티 요약을 모으고
      b) 이 요약들을 무작위로 섞는다
      c) 섞인 요약을 일정 크기(예: 500토큰)의 청크로 나눈다.
    • 이유 : LLM은 주어진 컨텍스트의 시작과 끝 부분에 더 주목하는 경향이 있어, 무작위로 섞음으로써 모든 정보가 고르게 주목받을 기회를 갖게 된다. 
  • Map community answers : 각 청크에서 관련 정보를 추출하여 중간 답변을 생성
    • 과정:
      a) 각 청크를 별도의 LLM 인스턴스에 입력으로 제공
      b) LLM은 각 청크에 대해 두 가지 생성
      • 사용자 질문에 대한 중간 답변
      • 이 답변의 유용성을 0-100 사이의 점수로 평가 
      • 0점인 답변은 제거
  • Reduce to global answer : 중간 답변들을 종합하여 최종적인 포괄적 답변을 생성
    • 과정:
      a) 중간 답변들을 유용성 점수에 따라 내림차순으로 정렬
      b) 높은 점수의 답변부터 시작하여 새로운 컨텍스트 윈도우에 추가
      c) 컨텍스트 윈도우의 토큰 제한에 도달할 때까지 이 과정을 반복
      d) 최종적으로 채워진 컨텍스트를 사용하여 LLM이 종합적인 전역 답변을 생성
    • 이유: 가장 관련성 높은 정보를 우선적으로 사용하면서도, 다양한 커뮤니티의 정보를 포함하여 포괄적인 답변을 만들 수 있다

3. Evaluation

3.1 데이터 : 팟캐스트 전사본, 뉴스 기사

3.2 Queries

• 기존 벤치마크 데이터는 검색에 맞춤화 되어있는 데이터셋이라 '활동 중심 접근법'을 사용
• 이 내용은 생략 하겠음

3.3 Conditions

총 6가지 방법을 비교함

• Graph RAG(C0) : 루트 레벨(가장 높은 레벨) 요약(가장 적은 수)를 사용 
• Graph RAG(C1) : 고수준 커뮤니티 요약을 사용(C0의 하위 커뮤니티)
• Graph RAG(C2) : 중간 레벨 커뮤니티 요약을 사용(C1의 하유 커뮤니티)
• Graph RAG(C3) : 저수준 커뮤니티(가장 많은 수)(리프노드)
• 텍스트 요약 방법(TS) : 2.6절에서 설명한 방법
• 단순한 "의미론적 검색" RAG 접근법(SS) : 텍스트 청크를 검색하여, 컨텍스트 윈도우에 근접할 때까지 추가한 RAG

그래프 인덱싱 과정에서 팟캐스트 데이터셋의 경우 글리닝(놓칠 수 있는 정보를 다시 한번 살펴 추출하는 과정)

600 토큰의 컨텍스트 윈도우 크기 사용

3.4 Merics

3.2의 데이터는 ground truth가 없기에 LLM을 사용해 head-to-head comparison방법을 사용하였다.

일대일 측정 항목 : 

• 포괄성: 답변이 질문의 모든 측면과 세부사항을 다루기 위해 얼마나 많은 세부정보를 제공하는가?
• 다양성: 질문에 대해 얼마나 다양하고 풍부한 관점과 통찰을 제공하는가?
• 권한 부여: 답변이 독자가 주제를 이해하고 정보에 기반한 판단을 내리는 데 얼마나 도움이 되는가?
• 직접성: 답변이 얼마나 구체적이고 명확하게 질문을 다루는가?

평가를 위해 LLM에게

• 질문, 목표 메트릭, 그리고 한 쌍의 답변을 제공(표2에서는 Graph RAG와 Naive RAG 비교)
  한 데이터 셋에 대해서 6C2 (15개) 만큼의 비교가 필요
• 메트릭에 따라 어떤 답변이 더 나은지 평가하도록 함.
• 그 이유도 설명하도록 함.
• LLM은 승자가 있으면 승자를, 그렇지 않으면 근본적으로 유사하고 차이가 무시할 만한 경우 동점을 부여함.
• LLM의 확률적 특성을 고려하여 각 비교를 5번 실행하고 평균 점수를 사용(표 2)

3.5 Configuration

• 목적: 컨텍스트 윈도우 크기가 성능에 미치는 영향을 탐구
• 배경:
  • gpt-4-turbo와 같은 모델은 128k 토큰과 같이 큰 컨텍스트 크기를 가짐
  • 긴 컨텍스트에서 "중간에 정보가 손실"될 수 있는 문제 존재
• 테스트 방법:
  • 4가지 컨텍스트 윈도우 크기 테스트: 8k, 16k, 32k, 64k
  • 기준 조건(SS)에 대한 최적의 컨텍스트 크기 결정
• 결과:
  • 가장 작은 크기인 8k가 포괄성 비교에서 가장 우수 (평균 승률 58.1%)
  • 다양성(평균 승률 52.4%)과 권한 부여(평균 승률 51.3%)에서도 8k가 다른 크기와 비슷한 성능
• 결론:
  
  • 최종 평가에 8k 토큰의 고정 컨텍스트 윈도우 크기 사용

3.6 Results

• 인덱싱 결과:
  • 팟캐스트 데이터셋: 8,564 노드, 20,691 엣지
  • 뉴스 데이터셋: 15,754 노드, 19,520 엣지
• Global Approach vs. 단순 RAG:
  • 모든 Global 접근법이 단순 RAG보다 포괄성과 다양성 측면에서 일관되게 우수
• 커뮤니티 요약 vs. 원본 텍스트:
  • 커뮤니티 요약이 대체로 답변의 포괄성과 다양성에서 작지만 일관된 개선 보임
    (루트 레벨 요약 제외)
• 효율성:
  • Graph RAG가 원본 텍스트 요약보다 더 적은 컨텍스트 토큰 필요
  • 저수준 커뮤니티 요약(C3): 26-33% 더 적은 토큰 사용
  • 루트 레벨 커뮤니티 요약(C0): 97% 이상 더 적은 토큰 사용
    2.6방법을 사용하면 쿼리와 모든 커뮤니티에 대해서 요약을 진행해야 하는데, 이에대한 것은 고려 된 부분인가?
• Matrix Empowerment:
  • 전역적 접근법 vs. 단순 RAG(SS), Graph RAG vs. 원본 텍스트 요약(TS) 우세가 없음.

4. Related Work

생략

5. Discussion 

• 평가의 한계:
  • 약 100만 토큰 범위의 두 말뭉치(팟캐스트 전사본, 뉴스 기사)에 대한 특정 유형의 질문만 평가
  • 다양한 질문 유형, 데이터 유형, 데이터셋 크기에 따른 성능 변화 연구 필요
  • 센스메이킹 질문과 목표 메트릭(포괄성, 다양성, 권한 부여, 직접성)에 대한 최종 사용자 검증 필요
  • SelfCheckGPT와 같은 도구를 사용한 hallucination 비율 비교 필요
• 그래프 인덱스 구축의 트레이드오프:
  • Graph RAG가 다른 방법들보다 일관되게 우수한 성능 보임
  • 그래프를 사용하지 않는 원본 텍스트 전역 요약 접근법도 경쟁력 있는 성능 보여줌
  • 실제 적용 시 고려할 요소: 계산 예산, 데이터셋당 예상 쿼리 횟수, 그래프 인덱스의 부가 가치(일반 커뮤니티 요약, 다른 그래프 관련 RAG 접근법 활용 등)
• 향후 연구 방향:
  • 사용자 쿼리와 그래프 주석 간 임베딩 기반 매칭을 통한 지역적 RAG 접근법 개발
  • 커뮤니티 보고에 대한 임베딩 기반 매칭과, 맵-리듀스 요약을 결합한 하이브리드 RAG 방식 개발
  • 커뮤니티 계층의 더 많은 레벨에 걸친 "롤업" 작업 확장
  • 상위 레벨 커뮤니티 요약 정보를 따라가는 탐색적 "드릴 다운" 메커니즘 구현

0 Abstract

기존의 검색 증강 생성(RAG) 한계 :

• 명시적으로 제시된 질문과 잘 정리된 지식 사이의 관련성만을 매칭할 수 있음
• 모호한 정보 요구나 비정형 지식을 다루는 작업은 잘 못함.
  -> 결과, 기존 RAG 시스템은 주로 간단한 질의응답 작업에만 효과적임.

이러한 한계를 극복하기 위해 우리는 MemoRAG를 제안(두가지로 구성) :

1. 경량화된 광범위 처리 언어 모델:
   - 이 모델은 데이터베이스의 전체적인 내용을 포괄적으로 이해하고 기억
   - 특정 작업이 주어지면, 이 모델이 먼저 초안 답변을 생성.
   - 이 초안은 데이터베이스 내에서 유용한 정보를 찾아내는 데 중요한 단서 역할을 함.
2. 고성능 표현 언어 모델:
   - 이 모델은 검색된 정보를 바탕으로 최종 답변을 생성.
   - 첫 번째 모델이 제공한 단서를 활용해 더욱 정확하고 상세한 답변을 생성

1 Introduction

LM은 좋으나, 응용에 한계가 있음.

• 할루시네이션
• 오래된 과거 내용 생성
• 제한된 컨텍스트 길이로 인해 사용자와의 장기적인 대화 어려움
  
  

유망한 해결책 : RAG

단점 :

• 종종 명확하게 명시된 정보 요구 필요
• 잘 구성된 Knowledge Base필요
  -> 그 결과, RAG의 적용은 주로 간단한 질의응답 작업에 국한되어 있음.
  -> 하지만 실제 세계의 많은 문제는, 정보 요구가 모호하고 외부 지식이 비정형적인 경우가 많다.
  
  
• 예를 들어, 책의 독자가 주요 등장인물들 간의 상호 관계를 이해하고 싶어 할 수 있다. 이 문제를 해결하기 위해서는 시스템이 먼저 주요 등장인물들의 이름을 식별한 다음, 해당 이름들이 함께 등장하는 부분을 찾아 그들의 상호 관계를 추론해야 한다.
  -> 즉, 책의 전반적인 맥락을 이해한 후에야 관련 정보를 효과적으로 검색할 수 있는 것다.
  
  

제안 : MemoRAG

• Query와 데이터베이스의 관련 지식을 연결하는 인터페이스 제안
• Query가 주어질 때마다 MemoRAG는 메모리 모듈을 통해 검색 단서를 생성.
• 이 단서들은 메모리를 바탕으로 한 초안 답변이다.
  세부 사항에 오류가 있을 수 있지만, 이 단서들은 주어진 작업에 대한 기본적인 정보 요구를 명확히 드러낸다. 이 단서들은 실제 소스 정보와 직접 연관될 수 있다. MemoRAG는 이러한 단서들을 쿼리로 사용하여 데이터베이스에서 필요한 지식을 효과적으로 검색할 수 있다.
  -> 최근 hybrid 연구들을 보면, 시멘틱 서치만으로는 좋은 결과를 도출하지 못하여, 단어기반 서치도 섞어서 진행함. 만약 데이터베이스에 저장된 단어로(표현)으로 쿼리를 변경하여 시멘틱서치를 진행한다면 좋은 성능이 있을 것 같긴함.

위에서 설명한 메커니즘에 따르면, 메모리 모듈은 다음과 같은 특성을 가져야 한다 :

1. 기억력 : 전체 데이터베이스의 글로벌 정보를 기억할 수 있어야 한다.
2. 지시력 : 필요한 모든 지식을 종합적으로 검색할 수 있는 유용한 단서를 제공해야 한다.

따라서 MemoRAG의 성능을 최적화하기 위해 다음과 같은 설계를 제안 :

1. 첫째, 이중 시스템 아키텍처를 도입.
   1. 가벼운 LLM을 메모리로 사용 : 메모리로 사용되는 가벼운 LLM은 비용 효율적이면서도 긴 컨텍스트를 처리할 수 있어야 한다. 이를 통해 제한된 컴퓨팅 리소스로도 전체 데이터베이스를 수용할 수 있음.
   2. 무거운 LLM을 검색 증강 생성에 사용
      
2.  둘째, 메모리 미세 조정(fine-tuning)수행 : 생성된 단서들이 최적의 검색 품질을 달성할 수 있도록 하기 위함

MemoRAG의 효과를 평가하기 위해, 우리는 ULTRADOMAIN이라는 종합적인 벤치마크를 개발.
이 벤치마크는 다양한 분야에서 긴 입력 컨텍스트를 가진 복잡한 RAG 작업으로 구성되어 있다.

2. MemoRAG

• C 부분은 query와 D(database)로 부터 얻은 결과물인 C(RAG)이며, 이 정보를 Θ(LLM)에 입력으로query와 같이 주입한다.

• term 정리
  • Θ : LLM (OpenAI GPT, OpenSourceLLM ,...) 거대 모델
  • Γ : Retrieval (BM25, Semantic)
  • Θ_mem : Small LM (Mistral-7b) with long context size
• 이 논문에서 제안하는 부분은 (2)식의 세번째 term이다. 세번째 term이 왜 필요한지에 대한 내용을 설명하자면,,
  • 일반적으로 일반적인 사용자가 쿼리 : 구체적이지 않은 쿼리를 작성하는 경우가 많다.
    -> 시멘틱한 정보 검색으로 쿼리와 관련성이 높은 정보를 database로 추출하기는 쉽지 않다.
    -> 따라서 사용자 쿼리와, database사이의 다리 역할을 하는 모델을 도입한다.
• y = Θ_mem(q, D | θ_mem) :
  • y는 불완전하거나, 세부 사항이 부족할 수 있다.
  • 다만 database와 관련성이 높기 때문에, 관련성이 높은 정보를 database에 찾아질 확률이 높아진다.
  • 컨텍스트가 긴 어떠한 모델도 좋다. (예, mistral-7b-inst : 150K token)

2.1 Memory Module

Back To Transformer : 트렌스포머 아키텍쳐에 대해서 간략하게 설명하고 있으며,

여러 개의 Layer를 통과해서 X의 내용을 이해하게 되는데, 이는 사람의 short-term memory와 비슷하다.

Short-term Memory에서 Long-term Memor로 전환하기 위해 memory token을 제안한다.

• memory token이 long term memory를 갖을 것으로 생각하고, 도입함.

Memory Tokens : 

• 매우 복잡해 보이는 term들이 많이 보이지만, 차분히 뜯어보면 어렵지 않다. 공식 github이 없기에, 블로그 주인장이 추측하는데로 써보고자함.
• 용어 정리
  
  • W : Learnable Parameters for projection to latent space
  • X : 입력 토큰들 {x1, x2, ..., x_n}
  • Θ : LLM
  • X : LLM에 입력 토큰을 넣어서 나온 hidden state ( Θ(X) = X : hidden state )
  • Memory Token : 임의의 벡터로 Init 함
    - 실제 토큰이 있는 것이 아니라, 가상의 메모리를 만드는 것이므로, 임의의 토큰을 할당하는 것으로 보임.
    - Transformer에서 비유하자면 embedding Layer를 진행한 것으로 생각할 수 있음.
  • K, V cache : memory token들을 auto regressive하게 생성(예측)할 것인데, 이때 효율적인 계산을 위해 KV cache를 사용하고, 이는 식(7)으로 표시함.
  • Qm : 추측하기로, Qm은 메모리 토큰들이 순차적으로 생성, 계산될 때, 임의의 위치(1~k) 토큰들 중에 하나인 a라고 가정하면, a 토큰 이전에 나왔던 memory의 cache를 KV cache로 정의함
• X[0:l] : 실제 토큰들인 (x1~x_l)으로 memory 토큰들의 hidden을 생성 -> (xm_1, xm_2, ...)
  • 실제 토큰들을 날려버리고, memory 토큰들의 hidden을 만을 남겨둠
  • Θ(X) -> Θ_mem(X) = {x_m(1,1), ... , x_m(1,k), ..., x_m(1,k),...,x_m(n,k)}  BOLD 표시로 된 메모리 블록으로 표현.
  • n개의 context windows만큼 메모리 블록이 생성된다.
• 개인적인 생각으로는, 앞부분에 있던 실제 토큰들을 memory토큰에 요약하는 정보를 담는 것을 의도한 것으로 보임
  물론 Loss function을 살펴보아야 정확하겠으나, 지금까지 읽은 느낌으로는 그러한 의도를 표한것 같음.
• 아래는 예시이나, 논문을 보고 추정한 것으로, 공식 코드를 살펴봐야 좀더 정확할 것으로 예상함.

예를 들어:
	전체 입력 길이가 1000 토큰
	각 컨텍스트 창의 크기(l)가 100 토큰
	각 창마다 생성되는 메모리 토큰의 수(k)가 10개라고 가정

계산 과정:
	a) 1번째 창: 토큰 1-100 처리 → 메모리 토큰 10개 생성
	b) 2번째 창: 토큰 101-200 처리 → 메모리 토큰 10개 생성
	c) 3번째 창: 토큰 201-300 처리 → 메모리 토큰 10개 생성
	...
	j) 10번째 창: 토큰 901-1000 처리 → 메모리 토큰 10개 생성

이 경우 n = 10이 되며, 총 10번의 계산을 통해 전체 입력을 처리

2.2 Training for Memory Module

• Freeze Parameter : {x_1, x_2, ..., x_n}토큰들의 맵핑 행렬(W)는 고정
• NonFreeze Parameter : W_Q_m, W_K_m, W_V_m을 새로 초기화 및 훈련 과정 동안 업데이트

두 단계로 훈련을 진행 ( 사실상 일반적인 LM을 만드는 것 )

1. 사전 훈련(Pre-training): RedPajama 데이터셋에서 무작위로 샘플링한 긴 컨텍스트를 사용하여 모델을 사전 훈련한다. 이를 통해 MemoRAG의 메모리 모듈이 원본 데이터로부터 메모리를 형성하는 방법을 학습함.
2. 지도 학습 미세 조정(Supervised Fine-tuning, SFT): 작업별 SFT 데이터를 사용하여 MemoRAG가 형성된 메모리를 기반으로 작업별 단서를 생성할 수 있도록 진행.
   Instruction Dataset을 만드는 것도 일이겠네...

Training Object (Loss Function)

• 2.1에서 생성한 Θ_mem(X) 메모리들을 조건으로 넣어주고, next token이 가장 높도록, 모델의 파라미터를 업데이트
  NLL일 것으로 예상함.

2.3 The MemoRAG FrameWork

• MemoRAG사용하지 방법 : Y = Θ_mem(X_m, q|θ)와 같이, 메모리와 쿼리(Instruction)를 LLM의 인풋으로 입력하여 사용, 답변을 생성하도록 사용.
  여기서 X_m은 Θ_mem(X)를 통해서 토큰들({x_1, ..., x_n})을 메모리 메트릭스로 변환
  (Eq. (7) 쪽 Text에서 해당 부분 참고 Θ(X) -> Θ_mem(X))

• MemoRAG를 사용 : 실제 답변과, 쿼리와의 간극을 매우는 역할을 한다.
  • 전체 흐름 : 
    1) 쿼리
    2) Θ_mem(X_m,q|θ) -> y (중간 다리)
    3) 정보 검색
    4) C^ : 검색된 정보와 query를 한세트로
    5) LLM으로 답변을 생성
    
    
  • MemoRAG에서 전역 메모리(X_m)은 단서(y)를 생성하는 데 사용된다.
  • 생성된 단서(y)를 사용해, Document를 Retrieve한다.
  • 최종 답변 생성 : Y = Θ_gen(X^, q|θ).
    X^ : (Query, C^)
    C^ : retrieved context
  • Θ_gen : 생성모델은 아무 모델이 될 수 있다. (OpenAI GPT도 가능)
  • guess : [query;memoryToken] 형태로 concnat 되어 모델에 입력될 가능성이 높음.

• X_m은 원본 토큰 시퀀스(X)의 고도로 압축된 형태이기 때문에 정보의 정확성 낮을 수 있다. 허나, 이는 인간이 기억에서 상세한 정보를 회상하는 데 어려움을 겪지만, 초안 답변을 생성한 다음 관련 증거를 다시 찾아 정제하는 방식과 비슷하다.

2.4 Applicability

전역 메모리가 RAG보다 더 적합한지 설명 : 

• 모호한 쿼리는 RAG에 쉽지 않은 작업
  • 사용자의 의도가 명시적으로 표현되지 않아, 맥락 이해와 추론이 필요하기 때문이다.
  • 이를 해결하기 위해 MemoRAG는 관련 데이터베이스 전체에 걸쳐 전역 메모리를 생성하여 모호한 쿼리의 근본적인 의도를 추론(예: 더 구체적인 답변 단서)을 생성함으로써 MemoRAG는 쿼리와 검색 프로세스 사이의 간극을 메운다.

• Information Seeking with Distributed Evidence Query : 
  
  • 넓게 분포된 정보를 통합적으로 수집해야 하는 경우, RAG는 어려움을 겪음.
  • 이 문제를 해결하기 위해 MemoRAG는 전역 메모리 기능을 활용하여 데이터베이스 내의 여러 단계에 걸친 관련 정보를 연결

• Information Aggregation : 
  • 긴 문서 요약과 같은 작업은 대량의 비구조화된 데이터를 간결하고 일관된 출력으로 압축하는 능력이 필요함. RAG 이러한 작업에  어려움을 겪는다. RAG는 개별 정보 조각을 검색하는 데 의존하지만, 이를 포괄적으로 효과적으로 결합하고 요약하는 메커니즘은 부족하기 때문
  • MemoRAG는 이 문제를 전체 데이터셋의 핵심 포인트를 포착하고 종합하는 전역 메모리를 활용하여 해결함

• Personalized Assistant :
  • 개인화된 추천 작업은 사용자의 고유한 특성과 히스토리에 대한 이해가 있어야 함. 허나, 개인화된 정보는 모호하고, 사용자의 개별 페르소나에 크게 영향을 받아 RAG 시스템은 이러한 작업에 어려움을 겪음. RAG는 일반적으로 일반적인 관련성 매칭에 의존한다.
  • MemoRAG는 사용자의 대화 히스토리를 분석하고 이해하기 위해 전역 메모리를 활용하여 개인화를 강화함. 이를 통해 MemoRAG는 사용자의 음악 선호도, 지식 배경, 나이, 그리고 과거 상호작용에서 추론할 수 있는 기타 관련 요인들과 같은 핵심 단서를 식별하고 활용함.

• Life-Long Conversational Search
  • 대화는 이전 상호작용 대화 맥락에 의존하여 -> 쿼리가 생략된 의미를 포함함.
  • RAG는 컨텍스트가 바뀌는 대화를 효과적으로 추적하고 추론하는 능력이 부족함.
  • MemoRAG : 전역 메모리를 활용하여 대화 기록의 전체 맥락을 유지하고 활용, 이전 대화를 참조하여 생략된 의미를 해석.
    생각해보면, 실시간 대화에서는 사용 못하지 않음? MemoRAG부분 모델 훈련이 필요한데..?

3. Experiment

3.1 Dataset

• MemoRAG의 효과를 표준 RAG 시스템과 비교하여 평가하기 위해, 우리는 MemoRAG와 기준 모델들을 13개의 기존 벤치마크 데이터셋을 사용하여 평가
• MemoRAG와 표준 RAG 시스템을 광범위한 응용 분야에서 평가하기 위해, 우리는 ULTRADOMAIN 벤치마크를 구축

3.2 BaseLines

(1) Full: LLM의 최대 길이에 맞춰 전체 맥락을 직접 LLM에 입력

(2) BGE-M3: 일반 목적 검색기, 표준 RAG를 수행합니다.

(3) Stella-en-1.5B-v5: MTEB 리더보드에서 상위 3위를 차지한 모델로, 이를 사용하여 표준 RAG를 수행

(4) RQ-RAG: LLM에 입력 쿼리를 명시적 재작성, 분해, 명확화 측면에서 더 나은 검색을 위한 여러 쿼리로 해결하도록 하는 프롬프트. 입력 쿼리와 정제된 쿼리 모두를 사용하여 검색

(5) HyDE: 쿼리만 제공하여 LLM에 가짜 문서를 생성하도록 직접 프롬프트하고, 그 다음 가짜 문서를 사용하여 구절을 검색한 후, 검색된 구절에 따라 최종 답변을 생성

3.3 Experiments on UltraDomain

3.4 Experiments on all benchmarks

• 첫째, 오픈 도메인 QA 작업에 대해 MemoRAG는 하나를 제외한 모든 데이터셋에서 모든 기준 모델들보다 성능이 향상.
  명시적인 쿼리를 가진 데이터에서, MemoRAG가 원본 컨텍스트 내에서 증거를 RAG보다 더 잘 찾을 수 있음을 확인
• 둘째, 대부분의 이전 RAG 방법들은 요약 작업(예: MultiNews, GovReport, en.sum)과 같이 쿼리를 포함하지 않는 작업에 어려움을 겪으나, MemoRAG는 더 많은 세부 사항을 검색하여 포괄적인 요약을 형성할 수 있게 한다.
• 셋째, 도메인 특화 작업(예: Financial 및 Legal)에 대해 MemoRAG는 상당한 개선을 보여주며, 이는 MemoRAG가 긴 컨텍스트를 가진 복잡한 작업을 처리하는 데 있어 우수함을 나타낸다.
• 요약하면, 이 결과들은 MemoRAG가 다양한 데이터셋과 쿼리 유형에 걸쳐 표준 RAG 방법들과 다른 기준 모델들보다 성능을 크게 향상시킴을 보여줌. MemoRAG의 복잡하고 긴 컨텍스트 작업을 효과적으로 처리하는 능력은 특히 표준 RAG 시스템이 어려움을 겪는 시나리오에서 그 장점을 강조한다. 

0 Abstract

• 검색 증강 지시 학습(SAIL) 새로운 방법을 제안
  - 내부 및 외부 검색 엔진에서 생성된 복잡한 검색 결과를 바탕으로 언어 생성과 지시 따르기 능력을 향상
• 데이터셋 구축
  - 연구진은 Instruct 튜닝 데이터셋을 사용하여, 다양한 검색 API와 도메인에서 수집
  - 이를 통해 (지시사항, 근거 정보, 응답) 형태의 새로운 검색 기반 학습 데이터셋을 구축
• 파인튜닝
  - LLaMA-7B 모델 파인튜닝.
  - 수집된 결과에는 관련 없는 내용 및 서로 상충되는 정보가 포함되어 있음.
  - 파인튜닝 과정에서, 모델 스스로가 신뢰할 수 있는 검색 결과인지 판단하고, 방해가 되는 내용을 걸러내며, 목표 응답을 생성하는 법을 기대함
• 실험 결과
  - SAIL-7B 모델은, 투명성이 중요한 작업(예: 개방형 질문 답변 및 사실 확인)에서 상당히 더 나은 성능을 보임.

1 Introduction

• 최근 LLM
  - 제로샷 추론과 소수의 예시만 인상적인 성능 보여줌
  - Instruction Tuning을 통해 큰 이점을 얻음(제로샷 과제에서 일반 LLM보다 훨씬 뛰어난 성능을 보임),
     자연어 지시, 자연어와 프로그래밍 언어 모두를 생성할 수 있는 능력을 보여줌.
     반면 사전 학습된 LLM이 같은 목표를 달성하려면 문맥 내 학습을 위해 다수의 주석이 달린 예시가 필요
• 그러나, 몇 가지 문제가 있다.
  • 과거 정보 : 학습 이후에 발생한 정보에 대해 알지 못함.
    • 극복 방법 : 업데이트된 학습 말뭉치로 전체 모델을 다시 학습
      -> 비용, 시간이 높음.
  • 투명성 부족 : 생성된 내용이 신뢰할 수 있는 출처에 근거하지 않음
    • 극복 방법 : 검색 시스템, 특히 상용 검색 엔진과 연결.
      LLM이 최신 지식 베이스에서 검색한 정보를 바탕으로 예측, 생성된 내용의 출처가 사용자에게 투명하게 공개될 수 있다.
      
    •  그러나, 한가지 과제가 남음 : LLM이 활용할 수 있는 신뢰할 만한 검색 모델과 지식 베이스가 있을까?
• Knowledge Base : 
  • 기존 연구 : 지식 베이스로 위키피디아를 선택
  • 그러나, 최근 연구에 따르면 위키피디아는 최신화가 되어 있지 않음. 따라서 위키피디아에만 의존하는 것은 LLM에만 전적으로 의존하는 것보다 더 나쁜 결과를 초래할 수 있다.
  • 대안 : Google, Bing, DuckDuckGo.com과 같은 인터넷 검색 엔진을 활용
    • 그들의 검색 정확도는 제한적이며 외부 사용자가 모델 수준에서 성능을 제어할 수 없다.
    • 검색 결과에 노이즈가 있을 수 있으며 관련 없는 정보가 검색될 수 있다.
    • 이는 자체 검색 엔진을 사용하는 것과 외부 검색 엔진을 사용하는 것 사이에 트레이드오프가 있음을 시사함.
    • LLM에게 검색 결과를 직접 사용하도록 프롬프트를 줄 수 있지만, 방해가 되는 검색 결과는 모델은 성능에 부정적인 영향을 미칠 수 있다. (그림 1에서 볼 수 있듯, ChatGPT는 방해가 되는 문단으로 인해 혼란을 겪고 잘못된 사실 확인 결과를 생성)
  •  정적인 지식 베이스와, 검색엔진은 : 최신 상태가 아님, 혹은 LLM에 부정적인 영향을 끼칠 수 있음.(정확성)
• 검색 증강 지시 학습(SAIL) 모델 제안
  • 주어진 instruction 및 context : 모델은 노이즈가 있는 검색 결과를 바탕으로 응답을 생성하도록 훈련
    -> 모델은 검색 결과에서 노이즈를 제거하고, 고품질 응답을 생성하는 법을 학습

2. Method

2.1 Search Result Collection

• Alpaca 팀이 만든 52,000개의 데이터셋, GPT-4가 생성한 해당 응답을 사용
  - 각 지시사항과 입력을 연결하여 검색 쿼리를 구성하고, 검색 엔진의 제한을 충족시키기 위해 쿼리를 최대 60단어로 제한함.
• 구성된 쿼리는 DuckDuckGo 검색 엔진과 BM25 위키피디아 검색기에 입력되며, 상위 3개의 검색 결과를 사용.
  - 각 검색 결과는 세가지 필드로 구성 : (제목, 짧은 미리보기, 해당 웹페이지의 URL)
• 각 학습에는 서로 다른 검색 결과 할당 : DuckDuckGO의 상위 3개와 BM25의 상위 2개 검색 결과, 총 5개의 검색 결과를 pooling.
  - 20%, 20%, 20%, 40%의 확률로 각각 0개, 1개, 2개, 3개의 검색 결과를 무작위로 샘플.

2.2 In-context Retrieval Selection

• 검색으로 얻어진 정보들에, Search Filtering Sequence를 앞부분에 작성한다.
  예를 들어, "검색 결과 (1)은 유익하고 검색 결과 (2)는 방해가 되므로, 나는 검색 결과 (1)의 정보를 사용할 것이다."
• 그러나 각 검색 결과는 레이블이 없음
  이 문제를 해결하기 위해, Luo와 Glass(2023)가 제안한 함의 분류 모델을 사용한다.
  
• 각 검색된 문단과 해당 응답을 함의 모델에 입력으로 하여, 함의 점수와 모순 점수를 비교한다.
  대부분의 예측이 응답에 대해 중립적이다.
  결과적으로, 우리는 함의 점수가 모순 점수보다 높으면 "검색 결과 (i)는 유익합니다"라고 레이블을 지정하고, 그렇지 않으면 해당 검색 항목은 방해가 되는 것으로 간주한다.(그림 1에서 보이는 것과 같은 문맥 내 검색 선별 시퀀스를 생성할 수 있다.)
• 정리하자면 : Query -> 검색 -> 검색겨과 함의 모델의 입력 값으로 함의점수, 모순점수 비교 -> Search Filtering Sequence 작성 -> LLM 답변 생성
  그렇다면 함의모델의 성능이 중요한 것 아닌가.?

2.3 Fine-tuning

(2.2)검색 결과 선별 시퀀스를 생성한 후, 우리는 그림 2(b) GPT-4가 생성한 응답으로 입력 프롬프트를 구성한다.

가장 관련성 높은 검색 결과를 지시사항에 가장 가까운 위치에 배치하여 모델이 정보를 더 잘 활용할 수 있도록 함.

구성된 프롬프트로 LLaMA-7b 모델을 미세 조정하여 문맥 내 검색 결과 선별과 주석이 달린 응답을 모두 생성하도록 함.

2.4 Evaluation

SAIL for instruction following

• GPT-4가 생성한 답변과, SAIL로 생성한 답변을 비교
• GPT-4로 점수를 매겨 다양한 모델의 지시 따르기 품질을 평가
  • (지시사항, GPT-4 응답, 대상 모델의 응답)으로 평가 프롬프트를 구성
  • 평가 프롬프트를 GPT-4에 입력하고 두 응답에 대해 0에서 10 사이의 점수를 매기도록 요청
    -> LLM은 integer한 평가 점수를 매기는 것에 강건하지 않은 것으로 알고 있는데,,
•  Vicuna-Instructions-80 코퍼스 데이터셋을 사용하여 평가
  - 80개의 질문, 모델이 모든 질문에 대해 받은 총점을 계산
  - 최고 가능 점수는 80 × 10 = 800점
  - GPT-4로 생성한 답변은, 비교군이 다를 때마다 다른 점수를 받을 수 있음.
     -> 이 차이를 정규화하기 위해, Peng et al. (2023)에서 구현한 대로 각 테스트 사례에 대해 (모델 점수 / GPT-4 점수)의 비율을 최종 평가로 계산한다.

예를 들어,
지시사항: "5G 기술의 장단점을 설명하시오."
GPT-4의 응답 점수: 9점 (10점 만점)
평가 대상 모델(예: SAIL-7B)의 응답 점수: 7점 (10점 만점)

이 경우, 이 특정 테스트 사례에 대한 평가 점수는 다음과 같이 계산:
평가 점수 = 모델 점수 / GPT-4 점수
= 7 / 9
≈ 0.778 또는 약 77.8%

예를 들어, 80개 지시사항에 대한 점수가 다음과 같다고 가정:

20개 지시사항: 평균 80%
30개 지시사항: 평균 85%
20개 지시사항: 평균 75%
10개 지시사항: 평균 90%

전체 평균 = (80% * 20 + 85% * 30 + 75% * 20 + 90% * 10) / 80
= 81.875%
따라서 이 모델의 최종 평가 점수는 81.875%
이 모델이 GPT-4의 성능의 약 81.875%에 해당하는 성능을 보인다는 것을 의미함.

SAIL for Question Answering

• 모델의 상식적 질문에 대한 답변 능력도 평가
• 종류 : 
  • Instruct ZeroShot
  • 검색 증강 모드
• 데이터 셋 : 
  • CommonsenseQA (CSQA), OpenbookQA (OBQA), ARC-Challenge.

SAIL for Fact and Fairness Checking

LLM이 생성한 정보는 (허위 정보, 고정관념, 그리고 유해성) 우려사항이다. 최근 연구에 따르면 적절한 지시와 프롬프트를 사용하면 LLM이 통합된 사실 및 공정성 확인을 수행할 수 있다. 그러나 다른 시도들은 외부 소스에 근거하지 않고 LLM에만 의존했기 때문에 확인 결과의 신뢰성과 투명성이 낮다.

UniLC 벤치마크를 사용하여 지시된 사실 및 공정성 확인을 평가한다.

3. Experiments

3.1 Instruction Following

Automatic Evaluation With GPT-4

GPT-4와 ChatGPT 모델에 대해 다른 모델들의 성능을 비교(점수 결과는 그림 3)

SAIL-7B 모델이 더 적은 훈련 데이터셋, 파라미터를 사용하면서도 다른 모든 모델들(Vicuna-13B와 GPT-3.5-turbo로 구동되는 ChatGPT를 포함한 강력한 기준 모델들)을 크게 능가하는 성능(90% vs <85%)을 보임.

• 이는 근거 정보가 제공될 때, 모델이 지식을 기억하기 위해 많은 파라미터를 필요로 하지 않는다는 것을 나타낸다.

검색 증강이 다른 모든 모델들보다 SAIL 모델에 훨씬 더 큰 긍정적인 기여 함.

• ChatGPT의 경우, 검색 증강 프롬프트를 제공하였으나 매우 작은 개선만이 있음.
• Vicuna와 LLaMA-GPT4의 경우, 모델의 성능이 낮아질 수 있음.
  • GPT4와 비교할 때, Vicuna-13B는 검색 결과로 인해 약간 개선되지만, ChatGPT와 비교할 때는 이러한 개선이 나타나지 않음.
  • Vicuna-7B와 LLaMA-7B-GPT4 기준 모델의 경우, 입력 프롬프트에 검색 엔진 출력을 추가하는 것은 두 평가 모두에서 상당한 부정적 영향을 끼침.
  • 반면, SAIL-7B에 검색 증강을 적용하면 두 실험 모두에서 모델 성능이 크게 향상(84%에서 90%로, 98%에서 103%로)

다음과 같은 결론을 내릴 수 있음.

• 검색 결과에는 언어 모델의 성능을 향상시킬 수 있는 유용한 정보가 포함되어 있다.
• Search-augmented fine-tuning 없이는 언어 모델이 복잡한 검색 결과 중에서 가치 있는 정보를 활용하기 어렵고, 방해가 되는 검색 결과가 -> 답변을 생성하는데 부정적인 영향을 끼칠 수 있음.
• Search-augmented instruction learning은 모델이 노이즈가 있는 검색 결과 중에서 가치 있는 정보를 더 잘 활용하고 성능을 향상시키는 데 도움을 줄 수 있다.

Data Statistics

• 검색 증강을 통해 SAIL-7B는 GPT의 생성과 겹치지 않는 동사를 더 많이 생성(표 1)
  -> 이는 검색 결과를 바탕으로 하여 언어 모델의 생성 선호도를 바꿀 수 있음을 나타냄.
• (표2) GPT-4는 가장 길고 다양한 응답을 생성하는 반면, ChatGPT는 더 짧고 단순한 답변을 생성하는 경향이 있다.
  검색 증강 없이 SAIL-7B가 생성한 시퀀스의 길이는 Vicuna 모델들과 비슷하나, 검색을 하면 생성 길이가 늘어난다.
  -> 이는 검색 증강이 생성된 응답의 길이를 증가시킬 수 있음

3.2 Question Answering

결론:

• SAIL-7B는 검색 결과의 유용한 정보를 효과적으로 활용
• 다른 모델들은 검색 결과 활용에 어려움을 겪음 (어떤 모델의 경우 성능이 좋아지고, 어떤 모델의 경우 성능이 낮아짐)
• 검색 증강 학습의 효과성 입증

3.3 Fact and Fairness Checking

사실 확인 / 혐오 발언 탐지 / 고정관념 인식을 포함하는 네 가지 하위 작업으로 구성된 데이터셋에 검증 진행

제로샷 성능 평가(실험 결과는 표 4)

-> SAIL-7B 모델은 사실 확인 작업에 대해 근거 정보가 제공되지 않았음에도 불구하고 모든 작업에서 가장 높은 정확도와 F1 점수를 달성

검색 결과가 모든 모델에 도움이 되지는 않는다는 것을 보여준다.
->검색 결과에 방해가 되는 정보가 포함되어 있어 모델이 노이즈 속에서 유용한 증거를 활용하는 것을 방해한다는 것을 보임

그러나 SAIL은 방해가 되는 언어에 대해 더 강건하며, 같은 검색 결과 세트에 대해 사실 확인 성능이 향상된다(표 5 참조)

4 Related Work

4.1 Capabilities

• LLM : 생략
• Instruction following : LLM을 더 확장 가능하게 만들고 제로샷 성능을 향상시키기 위해, Ouyang et al. (2022)은 지시-응답 코퍼스로 GPT3를 훈련시키는 방법을 제안. 그 결과, InstructGPT, ChatGPT, GPT4는 어떤 예시도 보지 않고 광범위한 작업을 처리할 수 있게 되었다.
• Retrieval-augmented language models :
  - 선구적인 접근 방식인 REALM(Guu et al., 2020)과 RAG(Lewis et al., 2020)는 검색기와 함께 언어 모델을 종단간으로 훈련시키고자 했다.
  - RETRO(Borgeaud et al., 2022)는 (훈련이 안되는) 검색기와 LM을 훈련시키는 아이디어를 도입한다.
  - RePlug(Shi et al., 2023)와 In-context RALM(Ram et al., 2023) : 고정된 LM을 사용하면서 검색 모듈을 미세 조정(훈련)
• RALM의 성공에도 불구하고, 이러한 모델들은 대부분
  • 1) 위키피디아와 같은 폐쇄된 코퍼스로 검색 공간을 제한하고
    2) 방해가 되는 검색 결과를 무시하는 과정이 없으며
    3) RALM 훈련 중 지시 미세 조정을 고려하지 않고 적은 예시 문맥 내 학습 설정을 적용한다는 한계가 있다.
    -> 결과적으로, 질문 답변과 언어 모델링과 같은 작업에 상대적으로 좁게 집중되어 있다.
  • SAIL은 이러한 한계를 해결한다.
    1) 실제 검색 엔진을 사용하고,
    2) 방해가 되는 정보를 필터링할 수 있는 검색 결과 노이즈 제거 프로세스를 도입하며,
    3) instruction 미세 조정을 포함한다.
    -> 결과적으로, SAIL은 실제 검색 엔진에서 검색한 최신 정보에 접근할 수 있는 이점을 가진 챗봇용 지시 따르기, 사실 및 공정성 확인 등 더 넓은 응용 분야에서 우수성을 보여준다.

4.2 Trustworthiness : 생략

요약 : 

Abstract

• Retrieval-Augmented LM (RALM, 검색증강언어모델) : 텍스트 생성 과정에서 LM에 관련 정보를 제공하여 성능 향상됨이 입증.
  또한, 할루시네이션 문제를 줄이고, 정보의 출처제공하는 장점도 있음.
• 기존 문제 : 기존의 RALM 접근법들은 외부 정보를 통합하기 위해 LM 구조 자체를 변경해야 했다.
• 이 논문에서는 대안으로 '문맥 기반 RALM'을 제안 :
  LM 구조를 그대로 유지한 채, 입력 텍스트 앞에 관련 문서를 추가하는 방식으로, LM의 추가 학습 없이도 적용할 수 있다.
  API에서 활용할 수 없음.

1. Introduction

• 현 LM은 좋긴 좋으나, 외부 지식에 접근하는 데 있어 본질적인 한계를 가지고 있다.
• 언어 모델은 출처가 없다.
  학습 과정에서 접하지 못한 최신 정보를 반영하기 위해서는 추가 학습이 필요하며, 사실과 다른 내용이나 오류를 생성하는 경향이 있다이 문제는 모든 LM 생성에서 나타나며, 특히 일반적이지 않은 도메인이나 개인 데이터를 다룰 때 더욱 심각하다.
  • 이러한 문제를 해결하기 위해
    검색 증강 언어 모델링(RALM)이 있다
    - RALM은 텍스트 생성 과정에서 외부 지식 소스에서 관련 문서를 검색하여 LM에 제공함으로써 모델의 출력을 보강한다.
       (i) 문서 선택
       (ii) 문서 읽기: 선택된 문서를 LM 생성 과정에 어떻게 통합할지 결정하는 과정
• 최근 소개된 주요 RALM 시스템들은 :
  • 주로 언어 모델 아키텍처를 변경하는 데 초점을 맞추고 있다
    • RETRO : 문서 읽기를 위해 LM 아키텍처에 상당한 수정을 가하고 추가 학습을 필요로 하는 반면, 문서 선택에서는 기존의 고정된 BERT를 사용한다. 아키텍처 변경과 재학습의 필요성으로 인해 활용성이 낮았다.
• 본 논문에서는 :
  • 간단한 문서 읽기(document reading) 메커니즘으로도 큰 효과를 얻음
  • 문서 선택 메커니즘을 언어 모델링 작업에 맞게 조정하여 성능 향상을 얻음.
  • 기성 언어 모델을 사용하면서도, (심지어 API를 통해 접근하는 경우에도) RALM의 많은 이점을 실현할 수 있음을 보인다.
    • 문맥 내 RALM'이라 명명한 간단하지만 강력한 RALM 프레임워크를 제안(3장).
      매우 간단한 문서 읽기 메커니즘 : 선택된 문서를 LM의 입력 텍스트 앞에 단순히 추가하는 것(그림 2 참조).
      -> LM의 변수를 2-3배 늘리는 것과 동등한 성능 향상

2. Related Work

RALM 접근법은 크게 두 가지 모델군으로 나눌 수 있다:

• (i) 최근접 이웃 언어 모델(kNN-LM이라고도 함)
• (ii) 검색 및 읽기 모델 : 이 연구는 두 번째 그룹에 속하나, LM의 추가 학습이 필요 없다
  
  • 문서 선택과 문서 읽기 구성 요소가 있다.
    이전의 모든 연구는 LM 훈련을 포함한다
  • 과거 연구들...
    - 인코더-디코더 아키텍처를 미세 조정
    - 문장 임베딩 공간에서 최근접 이웃 클러스터에 대해 자기회귀 LM을 사전 학습
    - 고정된 LM을 프롬프트 튜닝하여 리더로 사용
    - 검색 증강 양방향 마스크 LM을 사전 학습했고, 이후 개방형 질문 답변을 위해 미세 조정
    
  • RETRO : 이 논문과 유사한 연구
    • 청크 단위로 나뉘어진 문서들... 
    • autoregressive LM을 수정하여, decoding시에 청크들과 cross-attention을 수행하여, 관련된 문서 정보에 집중한다.
  • 이 연구와 RETRO연구와 다른점은...
    • LM학습 없음.
    • LM 성능 향상을 위해 문서를 선택하는 방법에 초점을 맞춤.

3. Our Framework

3.1 In-Context RALM

LM의 next token prediction : 
이전 토큰들의 시퀀스 -> 다음 시퀀스의 확률이 가장 높은 xi를 선택함.

검색 증강 언어 모델(RALM)은

• 외부 코퍼스 C에서 하나 이상의 문서를 검색
• 이 문서들을 기반으로 위의 LM 예측을 조건화(prefix로 넣음)
  • 구체적으로, xi를 예측할 때, 외부 코퍼스 C로부터의 검색 작업은 그 접두사(RC)에 의존된다.
  • 따라서 가장 일반적인 RALM은:
    • p(x1, ..., xn) = Πni=1 p(xi|x<i, RC(x<i)). 

In-Context Learning의 성공에서 영감을 받아... In-Context RALM을 제안

생성될 토큰들의 앞부분에 Retrieve된 문서들을 넣어준다.

• Query : 해리포터 시리즈에서 주인공의 성장과정을 설명해주세요
  • Retrieved Documents:
    - 11살의 해리는 자신이 마법사라는 사실을 모른채 살아왔다...
    - 볼드모트와의 첫 대결에서 해리는 용기와 결단력을 보여주었다...
    ...
  • In-Context RALM 예시
    - P(xi | (11살의 해리는..., 볼드모트와의 첫...) ; (해리는 11살까지 마법사임을))

일반적인 트랜스포머 기반 LM 구현은 제한된 길이의 입력 시퀀스만 지원하기 때문에, 이 제한을 초과할 경우, 앞부분의 토큰들을 제거해간다.

3.2 RALM Design Choices

RALM 시스템에서 자주 이루어지는 두 가지 실용적인 설계 선택에 대해 논의(Retrieval Stride, Retrieval Query Length)

• Retrieval Stride : 
  • 매 토큰을 생성할때마다 retrieval 작업을 수행할 수 있으나, 비용상의 이유로 s > 1 토큰마다, 검색을 수행함.
  • 이때 여기서 s를 검색 간격(Retrieval Stride)라고 명명 
  • 아래 식에서, n_s = n/s 로, 검색 간격을 의미함.
  • 아래 식에서 s=1인 경우 식(2)로 치환됨.

• Retrieval Stride는 두가지 런타임 비용이 발생
  • a) applying the retriever itself
  • b) Prefix 임베딩을 재계산 
  • 이 부분은 큰 모델로 한번만 retrieve를 하는 것보다, 작은 모델로 토큰생성시에 필요한 정보를 자주 retrieve하는게 좋다는 것을 5.2절에서 말하고 있음. -> API에서 불가함... -> 응용해볼 여지는 있음.
• Retrieval Query Length :
  • 식(3)에서 Rc부분에 x<= s*j 가 있음 -> Retrival은 prefix token들에 의존하는데, 특히 end of the prefix가 관련있는 토큰임
  • 이때 retrieval query가 너무 길면, 필요한 정보가 희석될 수 있다.(여기서 retrieval query는 Rc)
  • 이 현상을 피하기위해, Rc 부분에 마지막 L개의 토큰을 사용한다. (여기서 L은 retrieval query length로 명명함)
  • 이렇게 하여, 검색의 효율을 높이고, 가장 최근 관련 정보에 집중하게 한다.

4. Experimental Details

4.1 DataSet

• Overall
  데이터셋 : 다양한 언어모델링 데이터셋
  Open QA : 2개
• Models
  GPT-2 : 4가지 버전
  GPT-Neo : 3가지 버전
  GPT-J : 3가지 버전
  OPT : 8가지 버전
  LLaMA : 3가지 모델
• Retrievers
  단어기반 검색 : BM25
  신경망 검색 : 1.BERT-base, 2Contriever, 3Spider
• ReRanking
  RoBERTa-base

4.2 Implementation Details

• Retrieval Corpora : WikiText, ODQA데이터의 경우, Karpukhin et al의 전처리 방법을 사용
  - 색 코퍼스는 100단어(데이터 대부분의 경우 150토큰 미만)의 겹치지 않는 구절들로 구성되어 있다. 따라서 모델에 입력할 때 검색된 구절을 256토큰으로 잘랐으나, 일반적으로 그보다 훨씬 작았음

5. The Effectiveness of In-Context RALM with Off-the-Shelf Retrievers

간단한 문서 읽기 메커니즘에서도, 문맥 내 RALM이 상당한 LM 성능 향상이 있었음

이 섹션의 실험을 통해 우리는 문맥 내 RALM을 적용하기 위한 파라미터를 찾음: ℓ = 32 쿼리 토큰을 받는 BM25 검색기를 사용하고 가능한 한 자주 사용한다. 실험에서는 s = 4 토큰마다 검색한다

표 1은 GPT-2 모델에 대해, 조사된 모든 코퍼스에 걸쳐 , RALM이 2-3배 더 큰 모델의 성능과 맞먹는 LM 퍼플렉시티 향상을 제공함을 보여줌.

그림 4와 표 2, 5는 이러한 추세가 WikiText-103과 RealNews 모두에서 66B 파라미터까지의 모델 크기에 걸쳐 유지된다는 것을 보여준다.

-> 큰 모델에서도 잘 작동한다

5.1 BM25 Outperforms Off-the-Shelf Neural Retrievers in Language Modeling

• 실험한 검색기 : BM25, 세가지 신경망 검색기(RETRO, Contriever, Spider)
• BM25 : BM25가 제로샷 설정에서 광범위한 작업에 걸쳐 신경망 검색기를 능가한다는 이전 연구 결과와 일치한다.
  이 결과는 BM25 검색기를 적용하는 것이 신경망 대안들보다 훨씬 저렴하여 더 좋은 선택일 수 있다.
  ℓ = 32의 경우가 최적임을 발견함
  
• 신경망 : ℓ = 64의 경우가 최적

5.2 Frequent Retrieval Improves Language Modeling

검색 간격 s과 성능의 상관성 : 그림 5는 검색 작업이 더 빈번할 때 LM 성능이 향상함을 보여줌.

5.3 A Contextualization vs. Recency Tradeoff in Query Length

• 검색할 대상 쿼리가 너무 짧으면 : 맥락을 충분히 파악하지 못해 검색된 문서의 관련성이 떨어진다고 추측
• 검색할 대상 쿼리가 너무 길면 : 접두사의 맨 끝에 있는 토큰들의 중요성을 감소시켜 쿼리의 LM 작업 관련성이 낮아진다.

• 왜 re-랭킹이 필요한가?
  1. 기존의 BM25는 단순히 단어 일치에 기반하여 문서를 찾는다. 이는 문맥이나 의미를 충분히 고려하지 못할 수 있다.
  2. 더 관련성 높은 문서를 선택할 수 있다면, 성능을 더 높일 수 있다.

• 이 연구에서는...
  1. BM25로 상위 k개(여기서는 16개) 문서를 검색
  2. 이 k개의 문서 중에서 가장 적절한 문서를 선택하는 방법 제안
  
  
• 두 가지 재랭킹 방법을 제안
  
  • 1. 제로샷 재랭킹 (6.1절)
    
    • 기존의 언어 모델을 사용하여 BM25가 찾은 문서들의 순위를 다시 매긴다.
    • 추가 학습 없이 바로 적용할 수 있는 방법
  •  2. 예측적 재랭킹 (6.2절)
    • 새로운 모델을 학습.
    • 이 모델은 언어 모델의 출력을 예측하는 데 가장 도움이 될 문서를 선택하도록 훈련
•  결과:
  • 두 방법 모두 기본 BM25 검색보다 더 나은 성능을 보임
  • 특히 예측적 재랭킹 방법이 좋은 성능을 보임

6.1 LMs as Zero-Shot Rerankers

• retrieved documents : k개
• retrieve 횟수 : j 번
• next token generate : x(s*k + 1) ~ x(s*k+s) : s token 개
• 생성된 토큰 및 retrieved document들로 y가 최대가 되도록 document k를 찾고 싶다.
  허나 아직 y들을 생성한 것이 아니기에, document k를 찾을 수 없음
  
  예)
  생성된 토큰 : 
  - 최근 두 달 사이 한국 주식시장을 파랗게 질리게 만든 중심에 삼성전자가 있다. 
  Retrieved Documents : 
  - 삼성전자의 미래 전략...
  - 삼성전자의 현황...
  
  파란색(y)을 생성할 때 어떤 document k들이 가장 유의미한지 알기 어려움.
  
  
• 다음과 같은 방법으로 실험을 진행함.

y'을 새로 정의함 : 식5에서 알고 있던 토큰 x들에서 s'만큼의 토큰들을 제외하고, 제외한 토큰 s'들을 y'으로 정의함.

위 예시에서 작성한 문장을 인용하여 설명하자면,
파란(y)부분을 생성하고, y가 없다로 가정하고, 
Retrieved Documents들을 조합하며 y값들의 확률값을 계산.

예) 

- d1, d2, d3 순서로 ranking을 하는 경우 : 확률값 - 중심에(0.93), 삼성전자가(0.3), 있다(0.8)
- d1, d3, d2 순서로 ranking을 하는 경우 : 확률값 - 중심에(0.95), 삼성전자가(0.5), 있다(0.9)

...
가장 높은 확률값을 생성하는 케이스로 d들을 ranking함.

1. 현재 상태:
   • x(s*j) 개의 토큰들이 이미 생성되어 있음.
   • 다음 s개의 토큰을 생성하려함.
2. 사전 준비:
   • 이미 생성된 토큰 중 마지막 s'개를 사용 -> x(s*j - s')
   • y' = x(sj-s'+1) 부터 x(sj)까지의 생성될 확률값을 계산함.
3. ReRank 과정:
   • BM25로 검색된 k개의 문서 (d1부터 dk)를 순회
   • 가장 높은 확률을 제공하는 문서를 선택( 확률 값은 y'이 나올 확률을 계산)

API를 이용해서 사용할 수도 있음.

• Re랭킹은 오픈소스 모델로 진행을하고, ReRank한 Retrieved document를 API에 제공

6.2 Training LM-dedicated Rerankers

• 예측적 재랭킹 : BM25가 검색한 상위 k개 문서 중 하나를 선택하도록 하는 rerank 모델을 훈련.
  - 재랭킹 모델이 다음 텍스트를 '예측'하는 데 가장 도움이 될 문서를 선택하는 법을 학습
• 방법
  • Condition : X ≤ s*j 까지의 토큰
  • 문서 di : BM25가 검색한 k개의 후보 중 하나
  • 모델 : RoBERTAa-base
  • 입력 형식: [CLS] 접두사 x≤s·j [SEP] 문서 di [SEP]
  • 출력 계산 : [CLS] 토큰의 임베딩을 DenseLayer를 통해서 Scalar를 계산함.

Collecting Training Examples

1. 훈련 데이터에서 접두사 x≤s·j를 샘플링
2. 이 접두사 다음에 올 텍스트인 y := xs·j+1, ..., xs·j+s를 타겟으로 정의
3. 접두사 x≤s·j에서 도출된 쿼리 q(s,ℓ)_j를 사용하여 BM25 검색을 시행
   • 이를 통해 k개의 후보 문서 {d1, ..., dk}를 얻음.
4. 각 후보 문서 di에 대해, 언어 모델을 하여 pθ(y| [di; x≤s·j])를 계산함. (식 4 와 비슷)

Training(ReRank) : Loss Function

LM weight인 θ부분은 Freeze하고, Rank부분의 ReRank의 weight만을 업데이트 한다.

Result(ReRank)

예측적 재랭킹을 통해 상당한 성능 향상을 관찰할 수 있었다.(표1)

• GPT-2 110M (S)의 퍼플렉시티가 29.6에서 26.8로 개선
• GPT-2 1.5B (XL)의 퍼플렉시티가 16.6에서 15.4로 개선

이러한 성능 향상 추세는 다른 두 모델(GPT-2 M과 L)에서도 일관되게 나타남.

이 결과는 특정 도메인의 데이터로 재랭킹 모델을 훈련시키는 것이 제로샷 재랭킹(6.1절에서 설명)보다 더 효과적임을 보임.

여전히 개선의 여지가 있다.
상위 16개 BM25 문서에 대한 오라클 결과(그림 7 참조)와 비교해보면,
이 연구의 방법이 아직 이상적인 성능에 도달하지 못했음을 알 수 있다. 더 나아가, 오라클 결과도 다음과 같은 방법으로 개선될 수 있다:

1. BM25 검색기를 통해 k > 16 문서를 검색하는 것
2. RALM 작업에 특화된 더 강력한 검색기를 훈련시키는 것

문서 선택 과정을 개선함으로써 RALM의 성능을 크게 향상시킬 수 있음을 보임.

특히, 언어 모델링 작업에 특화된 재랭킹 모델을 훈련시키는 것이 매우 효과적

자연어 평가하는 메트릭이 코드 생성에도 유효한가?

-> Result부분

-> 결론 : 코드 생성 모델을 평가할 때, 단일 메트릭에 의존하지 말고 여러 메트릭을 사용하라.
      특히 ChrF와 ROUGE-L을 주로 참고하되, 점수 차이가 n점 이상일 때만 의미 있는 차이로 해석하자.
      BLEU는 좋은 메트릭이 아니였음.
      이 연구에서는 코드를 평가하기 위한 메트릭(CodeBLEU)이 좋은 메트릭이 아니였음.

0. Abstract

• 사람이 직접 평가하는 것은 불가능
  -> BLEU와 같은 자동 평가 지표를 도입
  허나, 코드 생성 작업에 적용 가능한지, 그리고 이 작업에서 사람의 평가와 얼마나 잘 일치하는지는 명확하지 않다.
• CodeBLEU와 RUBY -> 코드의 유사성을 평가하고 코드의 특성을 고려하기 위해 개발
  그러나 이 지표들의 평가와 사람의 평가와 얼마나 일치하는지에 대한 연구는 거의 없다.
• 이 논문에서는 BLEU, ROUGE-L, METEOR, ChrF, CodeBLEU, RUBY 등 6가지 지표에 대해 적용가능한지 살펴본다.
  -> 두가지 데이터 셋에대해 조사
  -> 사람 평가를 통해 이 데이터셋에서 실행된 모든 모델의 품질을 평가함.
• 이러한 발견을 바탕으로 코드 생성 작업에서 모델 성능을 추정하기 위한 몇 가지 권장 사항을 도출하였음.

1. Introduction

• 현 평가 방법
  • 정확도
  • BLEU 메트릭
  • CodeBLEU 메트릭
•  BLEU는 자연어 처리를 위한 기계 번역의 품질을 평가하기 위해 만들어졌으며, 자연어 텍스트의 번역 품질에 대한 인간의 판단과 상관관계가 있다는 것이 경험적으로 검증됨.
• 그러나 코드 생성 작업에 대해서는 이러한 검증이 존재하지 않음
  • (Tran)BLEU 결과가 인간의 판단과 약한 상관관계만을 가진다는 것을 보여줌.
  • (Roy)BLEU 메트릭이 METEOR나 ChrF와 같은 다른 메트릭들보다 덜 신뢰할 만한 지표라는 것을 보여줌
•  BLEU 메트릭의 세가지 문제점
  • 기존 메트릭들이 코드 생성 모델을 평가하는 데 적합한지 불분명
  • 메트릭 결과가 얼마나 중요한지, 그리고 한 모델의 상대적으로 더 좋다는 부분을 주장하기 위해 점수 차이가 얼마나 커야 하는지 불분명
  • 메트릭 점수가 인간의 판단과 얼마나 상관관계가 있는지 불분명
• 연구를 통해 코드 생성 모델의 평가 방법을 개선하고 더 신뢰할 수 있는 성능 비교 기준을 제시하고자 한다.
  • 코드 스니펫 제공 : 개발자들에게 생성된 코드 스니펫을 제공하여, 문제를 해결하는데 얼마나 도움이 되었는지 0~4까지의 척도로 평가하도록 함.

2. Background(생략 가능 - 인사이트 없음)

2.1 Code Generation

2.2 Evaluation of Code Generation Models

• 코드 생성을 위한 평가 방식은 크게 세 가지 범주로 나눌 수 있다.
  • 기계 번역 분야에서 가져온 메트릭
  • 코드 스니펫을 비교하기 위해 개발된 메트릭
  • 생성된 코드를 실행하고 테스트하는 방법

2.2.1 Metrics from machine translation.

• BLEU(BiLingual Evaluation Understudy) 메트릭은 원래 기계 번역 텍스트의 품질 평가를 위해 개발된 메트릭이다.
• 다른 메트릭도 존재함.
  • ROUGE-L: 참조와 후보 사이의 가장 긴 공통 부분 시퀀스를 찾는 재현율 지향 메트릭
  • METEOR: 정밀도와 재현율을 혼합한 메트릭으로, 참조에서 인접한 유니그램이 후보에서 인접하지 않은 경우 패널티를 부과함.
  • ChrF: 문자 n-gram F-점수 메트릭으로, 1-gram부터 6-gram까지의 문자에 대해 평균을 낸 정밀도와 재현율을 사용
  • 정확도 : 종종 이것도 사용함.

2.2.2 Metrics designed for code

• BLEU(METEOR와 ROUGE-L도 마찬가지)가 원래 자연어의 기계 번역 모델 평가를 위해 만들어졌음에도 불구하고, 코드 생성, 코드 마이그레이션, 코드 요약 모델 평가에 널리 사용된다.
• Tran et al.은 코드 마이그레이션 작업에서 BLEU의 적합성을 확인하기 위한 연구를 수행하였고, BLEU 메트릭은 인간 평가와 0.583이란 약한 상관관계를 보였다.
  • 이 문제를 해결하기 위해 코드 구조를 고려하는 새로운 메트릭인 RUBY를 고안
  • 이 메트릭은 참조와 후보의 프로그램 의존성 그래프(PDG)를 비교한다. PDG를 구축할 수 없는 경우 AST를 비교하고, AST도 구축할 수 없는 경우 (토큰화된) 참조와 후보 시퀀스 간의 가중치 문자열 편집 거리를 비교한다.
• Ren et al.은 코드 생성, 코드 번역, 코드 정제 작업의 품질을 평가하기 위한 CodeBLEU라는 새로운 메트릭을 제안함.
  • CodeBLEU는 코드를 데이터 흐름 그래프, 추상 구문 트리, 텍스트 등 4가지 다른 하위 메트릭의 가중 평균

2.2.3 Test-based evaluation

• 생성된 코드를 미리 작성된 단위 테스트에서 실행하고 주어진 문제를 해결하는지 확인
• 예를 들어, Codex의 저자들은 프로그래밍 작업과 생성된 코드의 정확성을 검증하는 테스트로 구성된 HumanEval이라는 데이터셋을 제시
• 테스트셋, 언어 등 고려할 부분이 많음.

3. Motivation

인간의 평가가 가장 신뢰할 만한 기준이라면, 메트릭은 인간의 판단과 최대한 일치해야 한다

BLEU가 처음에는 이 분야에 도입되었지만, 인간의 판단과 매우 낮은 상관관계를 가진다는 것이 밝혀졌다.

3.1 Merics and Test-based Evaluation

최근 HumanEval의 도입으로 생성된 Python 코드를 실제와 가까운 환경에서 실행하고 테스트할 수 있게 되었으나, 메트릭 사용은 다음과 같은 중요성을 갖고 있다.

• 인력 : 테스트 기반 평가 데이터셋을 수집하려면 테스트 세트를 개발하고 테스트로 커버하는 데 상당한 인력이 필요함.
• 비용 : Codex와 같은 매우 큰 모델의 훈련과 추론은 비용이 많이 들고 기술적으로 어렵다.
• 상대적 비교 : 두 모델이 생성한 코드가 어떤 테스트도 통과하지 못하더라도, 어느 코드가 더 정답에 가까운지 판단할 수 있다.\예를 들어, "딕셔너리 d에서 None 값 제거하기"라는 문제에 대해 다음과 같은 두 코드 조각이 있다고 가정하자.
  1. print(dict((k,v) for k,v in d.items() if v)))
  2. list(d.values())
  첫 번째 코드가 테스트를 통과하지 못하더라도 올바른 해결책에 훨씬 더 가깝다. 테스트를 통과하지 못한 코드의 품질을 평가할 수 있는 것도 중요하다.(개발자들이 일부 생성된 스니펫을 수정하고 자신의 코드에 통합하기 더 쉽다고 느낄 수 있음)

3.2 Are Existing Metrics Suitable for Code Generation?

기존 메트릭은 최적이 아닐 수 있다.

3.2.1 Differences between code and natural language

• 결론 : 코드 스니펫의 구조와 구문을 고려하는 메트릭을 개발하면 좋다(사람의 평가와 비슷할 것이다)
  • (코드는 엄격한 구문 구조를 갖고 있음)

3.2.2 BLEU has been outperformed in other tasks

• 코드 생성 작업에 대해 BLEU나 다른 메트릭 점수가 인간의 평가와 얼마나 잘 상관관계가 있는지는 불분명하다. 
• Reiter의 리뷰에 따르면 자연어 생성 작업에 대한 (BLEU&인간) 상관관계는 낮으며, BLEU는 기계 번역 NLP 시스템을 평가하는 데만 사용해야 한다고 주장한다.
• 코드 마이그레이션 문제에 대해, BLEU 점수와 인간 등급 사이의 상관관계가 0.583로 상당히 약하다는 것도 밝혀짐.
• BLEU, 정확도, CodeBLEU 메트릭에 대한 메트릭-인간 상관관계 연구가 있는데, 이는 CodeBLEU 메트릭이 정확도나 BLEU보다 인간 의견과 더 잘 상관관계가 있음을 보여주었다
  (그러나 이 연구는 다른 Metric은 보여주지 않아 객관성이 떨어짐)

3.2.3 Translation from metrics to human assessment

• 메트릭과 품질과 상관성 : 메트릭 점수의 증가가 코드 스니펫의 품질 증가와 선형적으로 관련되어 있는지는 불분명함
• 예)
  • Task: concatenate a list of strings ['a', 'b', 'c']
    Baseline : set(['a','b','b'])
    best-tranx-rerank solution: ''.join(['a','b','c'])
  • Baseline은 틀렸으나, BLEU기준 48.09를 얻음
  • Bset tranx rerank solution은 맞췄고 100 BLEU 점수를 받았다
• 이제 두 개의 가상의 모델 A, B의 출력을 고려하자.
  A : 모델 A의 모든 데이터 셋에 대해 BLEU는 50이고 위의 예와 유사한 품질을 가진다
  B : 모델 B의 절반은 BLEU 0이고 나머지 절반은 BLEU 100이다
  -> 이 경우, BLEU 점수가 비슷하더라도 모델 B가 모델 A보다 낫다고 주장할 수 있다.
  위의 예를 고려하면, 모델 A는 관련 없는 코드 스니펫을 생성하는 반면, 모델 B는 절반의 경우 완벽한 코드를 생성

인간 평가와 메트릭 값 사이의 의존성이 선형적이지 않다면, 모델의 인간 평가를 반영하기 위해 단순히 모든 스니펫에 대한 메트릭 값의 평균을 내는 것은 적절하지 않을 수 있다.

3.3 Do We Use Automated Metrics Correctly?

• 현재 : 
  • 전체 테스트 데이터셋에 대해 평균한 BLEU 또는 CodeBLEU 점수를 비교함
    그러나 BLEU 점수가 29에서 30으로 향상되었다고 주장할 때, 이 향상의 통계적 유의성에 대한 데이터로 거의 뒷받침되지 않음 
    -> 따라서 특정 데이터셋에 대해 두 모델의 메트릭 점수 차이가 얼마나 커야 한 모델이 다른 모델보다 더 낫다고 주장할 수 있는지 연구하는 것이 중요하다

4. STUDY OF METRICS FOR CODE SUMMARIZATION

• 최근 연구 :
  • Roy et al. [33]은 코드 요약 작업에 대한 자동화된 메트릭의 적용을 연구함.
    BLEU점수 기준 1.5점 미만은 모델들 사이에 차이가 없음을 보임. 특히, 점수 차이가 2점 미만일 경우 인간 평가의 신뢰할 수 없음
  • Roy et al.이 고려한 모든 메트릭 중 METEOR, ChrF, BERTScore가 인간의 판단과 일치하였다.

4.0.1 Dataset and labeling(데이터셋 설명)

• Roy et al. Java 코드 요약 데이터셋을 사용
  • 추출 : 383개의 스니펫을 무작위로 샘플링
    요약 : 5개의 다른 모델로 요약을 생성
    평가 : 사람이 생성된 5개의 요약과 참조 요약을 5점 리커트 척도로 평가(간결성, 유창성, 내용 적절성)
              요약 품질에 대한 의견을 반영하는 0-100 척도의 직접 평가(DA) 점수를 할당

4.0.2 Corpus-level metric assessment

Roy et al. 목표

• 첫째, 메트릭이 모델들간의 품질을 구별할 수 있는지
  둘째, 메트릭이 (모델의 요약본을 평가할 때) 인간이 평가한 것과 비슷한 평가를 할 수 있는지

결과 : 

• 1. 메트릭 차이가 2점 미만일 경우, 요약 품질 차이를 정확하게 포착할 수 없음.
  2. METEOR, BERTScore,chrF가 1종 오류와 2종 오류 측면에서 가장 좋은 성능을 보임
  3. BLUE 차이의 크기에 관계없이 가장 높은 1종 오류율을 보임.

4.0.3 Snippet-level analysis

Roy et al. 은...

• 스니펫 수준에서 메트릭 성능을 고려
  - 스니펫 수준 메트릭 결과 분석은 모델의 세밀한 성능을 추적하여 좋음
  - 그러나 Mathur et al. [24] 안정적인 점수를 제공하기 위해서는 스니펫당 최소 15개의 사람의 평가가 있어야한다고 한다.
• 스니펫 수준 분석을 수행하기 위해 '직접 평가 상대 순위 지정 기법'을 사용한다.
  두 스니펫의 쌍별 상대 점수를 비교(5점 척도의 주석에는 적용할 수 없다)

5. Methodology

연구 질문

• RQ1: 모델들의 성능이 메트릭 점수에 비례하여 유의하게 다른가?
• RQ2: 자동화된 메트릭의 결과가 얼마나 유의미한지, 그리고 두 모델의 메트릭 점수 차이가 얼마나 커야 한 모델이 다른 모델보다 더 좋다고 주장할 수 있는지?
• RQ3: 생성된 코드에 대한 메트릭 평가와 사람 평가가 얼마나 비슷한지?

접근 방식은 다음과 같은 단계로 구성

• 7단계가 있음.
• 연구 결과에 대해서만 살펴보자.

5.1 Datasets and Models

데이터 :

• 종류 : CoNaLa, Hearthstone
• 선택 이유 : 대부분 한줄짜리, 적절한 난이도, 명확한 설명으로 인한 평가 용이, 독립적이고 완결된 코드 스니펫
• 평가 방법 : BLEU, ROUGE-L, METEOR, ChrF, CodeBLEU, RUBY
• 인간 평가 : 0~4 척도
• 실험한 모델 수 : CoNaLa-5개(transformer based models), Heartstone-2개(NL2code, GCNN)

5.2 Corpus-level model performance

• RQ1을 검증하기 위해, 메트릭 점수 차이 유의성을 비교
  
  • 검증방법 : paired bootstrap resamplling -> 1000개의 샘플 사용(생성?) (randomized significance testing)
    구체적인 방법( 모델 A, B가 있다고 가정)
    1. 테스트 셋 : 100개의 문제가 있음 -> 각 문제에 대해 BLEU 점수를 산출
        모델A 점수 : [0.5, 0.6, ..., 0.5]  모델 B 점수 : [0.6, 0.3, ... , 0.5]
    2. Paired Bootstrap Resampling :
        1000번 반복 수행(아래 액션을 1000번 수행)
        각 반복에서 100개의 문제를 무작위로 복원 추출 -> 각 모델의 평균 BLEU 점수를 계산 -> 두 모델의 점수 차이를 계산
    3. 유의성 판단 : 1000번의 반복중 B가 A보다 좋은 비율을 계산
        950번 B가 좋았으면, 신뢰도는 95%
    4. 결론 : P-value 0.05라면 95%이상이 되어야 유의하게 차이가 있는 것으로 판단.
    5. BLEU, ROUGUE-L, METEOR등에 대해서 수행

5.3 Automated Metric Scores Significance

• RQ2를 검증하기 위해 다양한 모델 쌍에 대한 메트릭 점수 차이 유의성을 검토함
  • 모델의 BLEU결과물이 29.5와 30이 나오는 것보다 20과 80이 나오는 경우가 더 좋은 모델일 가능성이 있다.
    -> 결과물의 Range로 비교한다. 예) (29.5, 30)
  • 범주(경험적으로 구간을 결정함)
    • CoNaLa : [0, 2), [2, 5), [5, 10), [10, 100)
      HeartStone : [0, 1), [1, 2), [2, 4), [4, 100)
• 5.3.1 Building Synthetic Models
  
  • 목적 : 새로운 모델을 훈련시키지 않고도, 다양한 성능 수준의 "모델"을 얻을 수 있다.
    다양한 모델들이 있어야, 모델과, 메트릭 간의 관계를 비교할 수 있음 -> 따라서 다양한 모델들이 필요한데, 다양한 모델들을 만드는 것은 현실적으로 어려운 부분이 있음.
  • 예시) 모델 하나 선택
    1. 모델이 생성한 코드 스니펫중 하위 점수 X%를 선택함(사람이 평가)
    2. 다른 모델들이 생성한 코드 스니펫으로 X%를 대체함.
  • 대체 비율: 1%, 3%, 5%, 10%, 15%, 20%, 25%, 30% 등 다양한 비율로 스니펫을 대체
  • 모든 메트릭에 대해 paired differences 테스트를 수행

5.4 Agreement Between Metrics and Human Evaluation

• RQ3을 검증하기 위해, 인간 평가와 메트릭 점수 간의 일치도를 평가
• RQ2에서 사용한 원래 및 합성 모델을 모두 활용

5.4.1 Bins for Corpus-level Assessment.

• 주어진 모델 쌍 A, B에 대해 인간 평가자와 메트릭 사이에 다음과 같은 불일치가 있을 수 있음.

1. 메트릭에 따르면 A가 B보다 낫지만, 인간에 따르면 두 모델이 동등할 때 (1종 오류).
2. 메트릭에 따르면 모델 A와 B가 동등하지만, 인간에 따르면 한 모델이 다른 모델보다 나을 때 (2종 오류).
3. 메트릭에 따르면 모델 A가 B보다 낫지만, 인간에 따르면 모델 B가 A보다 나을 때 (1종 오류).

모든 모델 쌍(합성 및 원본 모델 모두)에 대해 인간 평가와 메트릭 평가에 대한 paired differences 테스트를 수행

• 집계된 인간 점수를 기준으로 삼아 메트릭의 1종 오류와 2종 오류를 정량화
• 두 모델의 점수 차이가 클수록 메트릭 오류를 범할 확률이 낮아질 것으로 예상되어, 메트릭 오류에 대한 데이터를 여러 구간으로 나눔.
• "NS" 구간은 메트릭에 따른 두 모델의 점수 차이가 유의미하지 않은 경우에 해당함.
  - 이 구간의 모든 오류는 2종 오류
  - 다른 구간은 메트릭에 따른 모델 점수 차이가 유의미한 경우에 해당
• 예)
  • Paired Differences 테스트:
    • BLEU 점수: 모델 A (30.5), 모델 B (32.0)
    • 인간 평가 점수: 모델 A (3.2/4), 모델 B (3.3/4)
  • 구간 나누기: BLEU 점수 차이에 따라 구간을 나눔. 예를 들어:
    • [0, 2): 0-2점 차이
    • [2, 5): 2-5점 차이
    • [5, 10): 5-10점 차이
    • [10, 100): 10점 이상 차이
    • NS: 통계적으로 유의미하지 않은 차이
  • 오류 분석: BLEU 점수 차이는 1.5점으로, [0, 2) 구간에 속함.
    • 만약 paired differences 테스트 결과, 이 차이가 통계적으로 유의미하다고 나온다면:
      • BLEU는 B가 A보다 낫다고 판단합니다.
      • 그러나 인간 평가 점수 차이(0.1)가 매우 작다면, 인간은 두 모델이 비슷하다고 평가함.
      • 이 경우 1종 오류가 발생한 것으로 간주
    • 만약 paired differences 테스트 결과, 이 차이가 통계적으로 유의미하지 않다고 나온다면:
      • 이 모델 쌍은 "NS" 구간에 속함.
      • 만약 인간 평가자들이 B가 A보다 확실히 낫다고 판단했다면, 이는 2종 오류로 간주
  • 구간별 분석: 각 구간에서 이러한 오류의 비율을 계산. 예를 들어:
    • [0, 2) 구간: 1종 오류 10%, 2종 오류 5%
    • [2, 5) 구간: 1종 오류 5%, 2종 오류 2%
    • [5, 10) 구간: 1종 오류 1%, 2종 오류 0.5%
• 이러한 분석을 통해 우리는 메트릭 점수의 차이가 클수록 메트릭이 인간 평가와 일치할 가능성이 높아진다는 것을 확인할 수 있다.
  또한 어느 정도의 점수 차이가 있어야 메트릭이 신뢰할 만한 결과를 제공하는지 파악할 수 있다.

5.4.2 Human Evaluation
0. 스니펫이 전혀 도움이 되지 않으며, 문제와 관련이 없음.
1. 스니펫이 약간 도움이 되며, 문제와 관련된 정보를 포함하지만 처음부터 해결책을 작성하는 것이 더 쉬움.
2. 스니펫이 어느 정도 도움이 되지만, 스니펫의 크기에 비해 상당한 변경이 필요하나 여전히 유용함.
3. 스니펫이 도움이 되지만 문제를 해결하기 위해 약간의 변경이 필요함.
4. 스니펫이 매우 도움이 되며, 문제를 완벽히 해결함.

6. Results

6.1 Corpus-level Model Performance

6.1.1 CoNaLaDataset : 

• 결론 : CoNaLa 데이터셋에 대해, 여러 메트릭(특히 BLEU, RUBY, CodeBLEU)이 일부 모델들 간의 성능 차이를 제대로 구별하지 못했으며, 이는 이러한 메트릭들이 코드 생성 모델의 품질을 평가하는 데 있어 한계가 있음을 시사한다.

6.1.2 HearthStone Dataset

• 메트릭 간 불일치가 존재 : ROUGE-L, METEOR, BLEU는 NL2Code가 GCNN보다 우수하다고 판단하지만, 다른 메트릭들은 그렇지 않다.
• 결론 : 단일 메트릭에 의존하는 것은 위험할 수 있으며, 다양한 메트릭을 사용하여 모델을 종합적으로 평가하는 것이 중요하다.
  훈련 조건과 데이터셋의 특성이 모델 성능과 평가 결과에 큰 영향을 미칠 수 있다.

6.3 Agreement Between Metrics and Human Evaluation

해석)

• Delta : 모델 2개의 비교할 경우 점수 차이
  Missmatch : 인간의 평가와, 메트릭의 평가가 다른 비율
  Pairs : 데이터 수
• 결론 :
  • 점수 차이가 커질수록(오른쪽으로 갈수록) 대체로 불일치율이 감소
  • chrF가 전반적으로 가장 낮은 불일치율을 보임
  • BLEU는 예상 외로 높은 불일치율을 보임
  • Delta: [2, 5) 구간에서 대부분의 메트릭이 높은 불일치율을 보임 -> 생성된 코드의 점수차이가 작은 경우 신뢰할 수 없음.
  • Delta: [10, 100) 구간에서는 BLEU를 제외하고 모든 메트릭이 일치
    

6.3.1 CoNaLa Dataset

CoNaLa 데이터셋에 대한 주요 결과 :

1. 메트릭의 신뢰성 문제: 예를 들어, BLEU 점수가 모델 A는 30점, 모델 B는 32점. 이 2점 차이는 실제로 의미 있는 차이가 아닐 수 있다. -> 인간은 두 모델의 결과물이 비슷하다고 판단할 수 있다.
2. 점수 차이의 중요성: 메트릭 점수 차이가 5점 이상일 때만 신뢰할만함.
   예를 들어) 모델 A의 ROUGE-L 점수가 45점, 모델 B가 51점이라면, 이때는 모델 B가 실제로 더 나을 가능성이 높다.
3. 메트릭 간 성능 차이: ChrF와 ROUGE-L이 가장 신뢰할 만한 메트릭으로 나타남. 반면 BLEU는 예상 외로 성능이 좋지 않음.
   예를 들어) ChrF나 ROUGE-L은 인간 평가와 80% 일치, BLEU는 60%만 일치했다
4. 코드 전용 메트릭의 한계: RUBY와 CodeBLEU같이 코드 평가를 위해 특별히 만들어진 메트릭도 기존의 텍스트 평가 메트릭보다 더 나은 성능을 보이지 않음.
5. 권장사항: 코드 생성 모델을 평가할 때, 단일 메트릭에 의존하지 말고 여러 메트릭을 사용하라. 특히 ChrF와 ROUGE-L을 주로 참고하되, 점수 차이가 5점 이상일 때만 의미 있는 차이로 해석.

HearthStone 데이터셋에 대한 주요 결과 : 

• ROUGE-L이 가장 신뢰할 만한 메트릭
• ChrF가 두 번째로 좋은 성능을 보임
• BLEU는 예상외로 성능이 좋지 않음
• RUBY와 CodeBLEU는 코드 평가를 위해 특별히 만들어졌지만, 기존의 텍스트 평가 메트릭(ROUGE-L, ChrF)보다 더 나은 성능을 보이지 않음.

7. Threats to validity

• 데이터셋 : Python 한 줄 코드 데이터에서 실험을 하여, 일반화 해서 말할 수 없음.
• 모델 선택 문제 : 실험에 사용한 (pretrained)모델의 수가 5개 미만
• 언어 : Python에서만 실험을 진행하였음. 다른 언어에서도 같은 결과가 나올지 보장할수 없음.
• 평가자 사람 수 부족 : 평가에 참여한 개발자 수가 제한적이라, 인간 평가 점수와 메트릭 점수간의 관계 실험이 유의하지 않을 수 있음.
• 평가자 편향 : 평가자의 코드 생성 편향이 있을 수 있음.