notdecidedyet

0 Abstract

📌 기존 RAG 시스템의 한계:

• 평면적 데이터 표현 사용, 맥락 인식 부족, 복잡한 상호의존성 포착 실패, 단편적인 답변 생성

📌 제안하는 해결책: LightRAG

• 주요 특징:
  • 그래프 구조를 텍스트 색인과 검색 프로세스에 통합
  • Dual-level 검색 시스템 도입
    • Low-level
    • High-level
• 핵심 기술:
  • 그래프 구조와 벡터 표현 통합
  • 효율적인 엔티티 및 관계 검색
  • 증분 업데이트 알고리즘 구현

1 Instruction

기존 RAG시스템의 한계가 있다

• 첫째, 많은 방법들이 엔티티 간의 복잡한 관계를 이해하고 검색하는 능력을 제한하는 평면적인 데이터 표현에 의존
• 둘째, 이러한 시스템들은 종종 다양한 엔티티와 그들의 상호 관계에 걸친 맥락 인식이 부족하기 때문에, 사용자 쿼리에 답변을 못하는 경우가 있음. 사용자는 이러한 주제들 간의 복잡한 상호 의존성을 적절히 포착하지 못하는 단편적인 답변을 받을 수 있다.
• 더보기
  예를 들어사용자가 "전기 자동차의 증가가 도시 대기질과 대중교통 인프라에 어떤 영향을 미치나요?"라고 물으면,
  기존 RAG 방법들은 전기 자동차, 대기 오염, 대중교통 문제에 대한 별도의 문서들을 검색할 수 있지만,
  일관된 응답으로 종합하는 데 어려움을 겪을 수 있다
  전기 자동차 채택이 대기질을 어떻게 개선할 수 있는지, 이것이 다시 대중교통 계획에 어떤 영향을 미칠 수 있는지를 설명하지 못할수 있다

📌  제안하는 해결방안 : 그래프 구조 통합

• 엔티티 간 상호의존성 효과적 표현
• 관계에 대한 미묘한 이해 가능
• 다중 소스 정보의 일관된 통합
• 맥락이 풍부한 응답 생성

LightRAG의 주요 특징

• 그래프 기반 텍스트 색인 패러다임
• Dual-level 검색 프레임워크
  • Low-level: 특정 엔티티와 관계에 대한 정확한 정보
  • High-level: 더 넓은 주제와 테마 포괄
• 그래프 구조와 벡터 표현 통합

📌  해결해야 할 주요 과제

1. 포괄적인 정보 검색
   • 상호 의존적 엔티티의 전체 맥락 포착
   • 모든 문서에서의 효과적인 정보 추출
2. 향상된 검색 효율성
   • 그래프 기반 지식 구조 검색 개선
   • (응답 시간 단축)
3. 새로운 데이터 적응
   • 동적 환경에서의 시스템 관련성 유지
   • 빠른 데이터 업데이트 처리

2. RETRIEVAL-AUGMENTED GENERATION

주요 구성요소:

• Retrieval Component (검색 구성요소)
• Generation Component (생성 구성요소)

수학적 정의 : 

• $M = \{G, R = (\phi, \psi)\}$
• $M(q; D) = G(q, \psi(q; \hat{D}))$
• $\hat{D} = \phi(D)$
  • $G$: 생성 모듈
  • $R$: 검색 모듈
  • $q$: 입력 쿼리
  • $D$: 외부 데이터베이스
  • $\phi$: 데이터 인덱서 : 외부 데이터베이스 D를 기반으로 특정 데이터 구조 $\hat{D}$를 구축하는 작업을 포함함
  • $\psi$: 데이터 검색기 : 인덱싱된 데이터와 쿼리를 비교하여 관련 문서를 얻으며, 이를 "관련 문서"라고함
• ψ(·)를 통해 검색된 정보와 초기 쿼리 q를 활용하여 글로벌 정보를 효율적으로 추출, 생성 모델 G(·)는 맥락적으로 관련된 응답을 생성

3. THE LIGHTRAG ARCHITECTURE

3.1 GRAPH-BASED TEXT INDEXING

Graph-Enhanced Entity and Relationship Extraction :

• 문서를 더 작은 조각으로 분할함으로써 검색 시스템을 향상(관리하기 쉬워짐)
  -> 전체 문서를 분석할 필요 없이 관련 정보를 빠르게 식별하고 접근할 수 있게 함.
• LLM을 활용하여 다양한 엔티티(예: 이름, 날짜, 위치, 이벤트)와 이들 간의 관계를 식별하고 추출
  -> 포괄적인 지식 그래프를 만드는 데 사용
• 이 그래프 생성 모듈을 공식적으로 다음과 같이 표현:
  • $\hat{D} = (\hat{V}, \hat{E}) = Dedupe \circ Prof(V, E)\ \ \ \ V, E = \cup_{D_i \in D} Recog(D_i)$
    - $\hat{V}$ : 중복 제거된 노드 집합
    - $\hat{E}$ : 중복 제거된 엣지 집합
    - Dedupe : Deduplicate
    - Prof(V, E) : 추출된 엔티티와 관계에 대한 상세 정보 생성
    - Recog : 각 문서에서 엔티티와 관계를 인식하는 함수
  • 처리 순서 :
    1. Recog($D_i$) : 각 문서에서 엔티티와 관계 추출
    2. U : 모든 추출 결과 통합
    3. Prof : 통합된 결과에 대한 프로파일링
    4. Dedupe : 중복 제거
    5. 최종 결과 : $\hat{D} = (\hat{V}, \hat{E})$
  • $\hat{D}$는 생성된 지식 그래프를 나타냄.
    이 데이터를 생성하기 위해, 텍스트 문서 $D_i$에 세 가지 주요 처리 단계를 적용(LLM을 사용)
    • 엔티티 및 관계 추출 R(·) - Recog: LLM을 사용하여 텍스트 데이터 내의 엔티티(노드)와 그들의 관계(엣지)를 추출
      
      • 더보기
        - 입력 텍스트: "심장전문의 김철수 교수는 서울대학교병원에서 심장병 환자들을 진료하고 있다."
        
        추출되는 정보:
        1) 엔티티:
            - 사람: "김철수" (직업: 심장전문의, 직위: 교수)
            - 조직: "서울대학교병원"
            - 의료조건: "심장병"
        
        2) 관계:
            - "김철수 - 근무 - 서울대학교병원"
            - "김철수 - 진료 - 심장병 환자"
    • LLM Profiling을 통한 Key-Value 쌍 생성. P(·): LLM 기반 프로파일링 함수 P(·)를 사용하여 V의 각 엔티티 노드와 E의 관계 엣지에 대한 텍스트 key-value 쌍 (K, V)를 생성.
      • 각 인덱스 키는 효율적인 검색을 가능하게 하는 단어나 짧은 구문이며, 해당하는 값은 텍스트 생성을 돕기 위해 외부 데이터에서 관련된 스니펫을 요약한 텍스트 단락
      • 엔티티는 이름을 유일한 인덱스 키로 사용하는 반면, 관계는 여러 인덱스 키를 가질 수 있다.
      • 더보기

        엔티티에 대한 Key-Value 생성
        1) 엔티티: 삼성전자
           Key: "삼성전자"
           Value: "한국의 대표적인 전자기업으로, 스마트폰, 가전제품 등을 생산하는 글로벌 기업. 
                  갤럭시 시리즈를 통해 스마트폰 시장에서 선도적 위치를 차지하고 있음."
        
        2) 엔티티: 갤럭시
           Key: "갤럭시"
           Value: "삼성전자의 대표적인 스마트폰 브랜드로, 2024년 신형 모델이 출시되어 
                  시장에서 높은 성과를 기록. 혁신적인 기술과 디자인으로 주목받는 제품군."
        
        3) 엔티티: 스마트폰 시장
           Key: "스마트폰_시장"
           Value: "모바일 기기 산업의 핵심 시장으로, 다양한 제조사들이 경쟁하는 분야. 
                  기술 혁신과 소비자 선호도에 따라 빠르게 변화하는 특성을 가짐."
        
        관계에 대한 Key-Value 생성
        1) 관계: 삼성전자의 갤럭시 출시
           Keys: ["삼성_신제품", "갤럭시_출시", "스마트폰_런칭"]
           Value: "삼성전자가 2024년 신형 갤럭시 스마트폰을 출시하여 시장에 선보임. 
                  신제품은 최신 기술과 혁신적 기능을 탑재하여 주목을 받음."
        
        2) 관계: 갤럭시의 시장 성과
           Keys: ["갤럭시_실적", "스마트폰_매출", "시장_성과"]
           Value: "신형 갤럭시는 스마트폰 시장에서 높은 매출을 기록하며 성공적인 시장 반응을 얻음. 
                  제품의 혁신성과 브랜드 가치가 성과에 기여."
        
        실제 사용 예시
        질문: "2024년 갤럭시의 시장 성과는 어땠나요?"
        프로세스:
        1. "갤럭시_실적", "스마트폰_매출" 등의 키를 통해 관련 정보 검색
        2. 관련된 Value들을 결합하여 답변 생성
        3. 필요시 엔티티 정보(삼성전자, 갤럭시)를 추가하여 맥락 보완
      • 그래프 연산 최적화를 위한 중복 제거. D(·): 원천 텍스트 $D_i$의 서로 다른 세그먼트에서 동일한 엔티티와 관계를 식별하고 병합하는 중복 제거 함수 D(·)를 구현(구체적인 방법에 대해서는 서술하지 않음)

3.2 DUAL-LEVEL RETRIEVAL PARADIGM

상세한 레벨과 추상 레벨 모두에서 쿼리 키를 생성(Profiling 단계에서 생성)

• 상세한 쿼리: 세부사항을 묻는 쿼리, 특정 노드나 엣지와 관련된 정보의 정확한 검색이 필요 (예"'오만과 편견'을 누가 썼나요?")
• 추상 쿼리: 더 개념적이며, 더 넓은 주제, 요약, 또는 전반적인 테마를 포괄. (예 "인공지능이 현대 교육에 어떤 영향을 미치나요?")

두 가지 구분된 검색 전략을 사용 : 다양한 쿼리 유형을 수용하기 위해

• Low-Level 검색: 주로 특정 엔티티와 그들의 관련 속성이나 관계를 검색하는 데 중점. (세부사항 지향적)
• High-Level 검색: 더 넓은 주제와 전반적인 테마를 다룬다. 이 레벨의 쿼리는 여러 관련 엔티티와 관계에 걸쳐 정보를 집계하여, 특정 세부사항보다는 고차원적 개념과 요약에 대한 통찰을 제공
• 더보기

  예) Query : 전기 자동차의 증가가 도시 대기질과 대중교통 인프라에 어떤 영향을 미치나요?
  -> 엔티티, 관계 추출
  -> 엔티티(전기자동차, 대기질, 대중교통, 등...)
  -> 관계(전기자동차가 대기질에 미치는 영향, ...)
  
  키워드 생성 :
  Low-level : 전기자동차, 대기질, 대중교통
  High-level : 환경 영향, 도시 계획, 공중 보건, 지속가능성, 등..

효율적인 검색을 위한 그래프와 벡터 통합 : 검색 알고리즘이 로컬 및 글로벌 키워드를 모두 효과적으로 활용할 수 있게 하여 성능 높아짐

• (i) 쿼리 키워드 추출: 주어진 쿼리 q에 대해, 로컬 쿼리 키워드 $k^{(l)}$와 글로벌 쿼리 키워드 $k^{(g)}$ 모두를 추출.
• (ii) 키워드 매칭: 벡터 데이터베이스를 사용하여 로컬 쿼리 키워드를 후보 엔티티와 매칭하고, 글로벌 쿼리 키워드를 글로벌 키와 연결된 관계와 매칭
  -> 벡터 데이터베이스를 사용하는 것으로 보아 - V,E,D등을 벡터화 한 것으로 추측
• (iii) 높은 관련성 통합: 검색된 그래프 요소들의 로컬 서브그래프 내의 이웃 노드들을 추가로 수집. 이 프로세스는 집합 ${v_i|v_i \in V \wedge (v_i \in N_v \vee v_i \in N_e)}$를 포함하며, 여기서 $N_v$와 $N_e$는 각각 검색된 노드 v와 엣지 e의 원-홉 이웃 노드들을 나타낸다. ( 논문에 의하면 1 hop만 하는것으로 보임)
  
  더보기

  - V : 전체 그래프의 모든 노드 집합
  - v_i : V의 각 개별 노드
  - ∧ : "V에 속하면서"라는 조건
  - N_v, N_e : Neighbor_v, Neighbor_e를 의미,
  
  [전체 그래프 구조] : 고혈압이 첫 노드인 경우.
             운동
               ↓
               [예방]
               ↓
            두통 ←[증상]--- 고혈압 ---[증상]→ 어지러움
                             |
                           [치료]
                             ↓
                           혈압약
                             |
                           [관리]
                             |
                           저염식
  
  

  1. $N_v$ (직접 이웃):

  • 고혈압 노드와 직접 연결된 노드들
  • 결과: {두통, 어지러움, 혈압약}

  1. $N_e$ (관계/엣지로 연결된 이웃):

  • "예방", "관리" 등의 관계를 통해 연결된 노드들
  • 결과: {운동, 저염식}

이 dual-level 검색 패러다임은 키워드 매칭을 통해 관련 엔티티와 관계를 효율적으로 검색할 뿐만 아니라, 구성된 지식 그래프에서 관련 구조적 정보를 통합하여 결과의 포괄성을 향상.

3.3 RETRIEVAL-AUGMENTED ANSWER GENERATION

• 3.1, 3.2, 3.3 정리
  1. 그래프 구축 (3.1절)
     └── 텍스트를 그래프 데이터베이스로 변환 ($\hat{D}$ 생성)
         ├── 엔티티 추출
         ├── 관계 추출
         └── 중복 제거 및 최적화
  
  2. 검색 프로세스 (3.2절)
     └── 쿼리 처리 및 관련 정보 검색
         ├── Low-level 검색 (specific entities)
         ├── High-level 검색 (broader themes)
         └── 그래프-벡터 통합 검색
  
  3. 답변 생성 (3.3절)
     └── 최종 응답 생성 프로세스
         ├── 검색된 정보 구조화
         └── LLM 기반 응답 생성
  
  
• 검색된 정보의 활용:
  • 검색된 정보 ψ(q; $\hat{D}$)과 LLM을 사용,
  • 이 데이터는 프로파일링 함수 P(·)에 의해 생성된 관련 엔티티와 관계로부터의 연결된 값 V로 구성.
    • 여기에는 엔티티와 관계의 이름, 설명, 그리고 원본 텍스트의 발췌문이 포함.(아래 예시 참고)
  • 더보기

    # 예시 쿼리: "자율주행 자동차의 안전 시스템은 어떻게 작동하나요?"
    
    # 원본 텍스트 예시:
    "테슬라의 자율주행 시스템은 8개의 카메라와 12개의 초음파 센서를 사용합니다.
    라이다 센서는 물체까지의 거리를 측정하는 데 사용됩니다.
    자율주행 차량은 AI 기반 충돌 방지 시스템을 통해 보행자를 감지합니다..."
    
    # 3.1 그래프 구축 : 엔티티 추출
    # 엔티티 추출:
        - Entity1: 자율주행 시스템
                속성: {유형: "기술", 목적: "차량 제어"}
        - Entity2: 센서
                속성: {종류: ["카메라", "초음파", "라이다"]}
        - Entity3: 충돌 방지 시스템
                속성: {유형: "안전", 기술: "AI"}
    # 관계 추출:
        - Relation1: (자율주행 시스템) -[사용]-> (센서)
        - Relation2: (센서) -[감지]-> (물체/보행자)
        - Relation3: (충돌 방지 시스템) -[포함]-> (자율주행 시스템)
    
    
    # 3.2 검색 프로세스 : 
    # 쿼리에서 키워드 추출:
        - Low-level 키워드: ["자율주행", "안전", "시스템"]
        - High-level 키워드: ["차량 안전", "센서 기술"]
    # 검색 결과:
        - Low-level 검색:
            * 자율주행 시스템
            * 센서
            * 충돌 방지 시스템
        - High-level 검색:
            * 안전 관련 시스템 간 관계
            * 센서-안전 연관 정보
    
    # 3.3 답변 생성 : 구조화
    # 구조화된 정보:
    {
        "core_systems": {
            "sensors": ["카메라", "초음파", "라이다"],
            "processing": "AI 기반 처리",
            "safety_features": ["충돌 방지", "물체 감지"]
        },
        "relationships": {
            "sensor_safety": "센서 데이터 → AI 처리 → 안전 기능 작동",
            "system_hierarchy": "자율주행 시스템 > 충돌 방지 > 센서 작동"
        }
    }
    
    # 프로파일링 함수 P(·)가 수행하는 작업:
    1. 엔티티 분류 및 그룹화
        - 하드웨어 요소 (sensors)
        - 처리 요소 (processing)
        - 기능적 요소 (safety_features)
    
    2. 관계 분석 및 계층화
        - 시스템 간 상호작용
        - 작동 순서 및 의존성

맥락 통합과 답변 생성: retreive한 엔티티들, 관계들, 원본 텍스트를 모아 LLM으로 하여금 종합적인 답변 생성.

3.4 COMPLEXITY ANALYSIS OF THE LIGHTRAG FRAMEWORK(생략)

4. Evaluation

• (RQ1): 생성 성능 측면에서 LightRAG는 기존 RAG 기준선 방법들과 어떻게 비교되는가?
• (RQ2): dual-level 검색과 그래프 기반 인덱싱은 어떻게 LightRAG의 생성 품질을 향상시키는가?
• (RQ3): LightRAG는 다양한 시나리오에서 어떤 구체적인 장점을 보여주는가?
• (RQ4): LightRAG와 관련된 비용은 무엇이며, 데이터 변화에 대한 적응성은 어떠한가?

4.1 실험 설정

평가 데이터 셋 : Agriculture, Legal, CS, Mixed

비교군 : 

• Naive RAG (Gao et al., 2023): 코사인 유사도가 가장 높은 텍스트 청크 검색
• RQ-RAG (Chan et al., 2024): LLM을 활용하여 입력 쿼리를 여러 하위 쿼리로 분해, 하위 쿼리들은 재작성, 분해, 모호성 해소와 같은 명시적 기법을 활용하여 검색 정확도를 향상
• HyDE (Gao et al., 2022): 입력 쿼리를 기반으로 가상의 문서를 생성하기 위해 LLM을 사용. 이 생성된 문서는 관련 텍스트 청크를 검색하는 데 사용되며, 이후 최종 답변을 공식화하는 데 활용
• GraphRAG (Edge et al., 2024): LLM을 사용하여 텍스트에서 엔티티와 관계를 추출하여 노드와 엣지로 표현. 

평가 방법(7.3.4) - GraphRag 평가 방법론 차용 :

• i) 포괄성: 답변이 질문의 모든 측면과 세부사항을 얼마나 철저하게 다루는가?
• ii) 다양성: 질문과 관련된 서로 다른 관점과 통찰을 제공하는 데 있어 답변이 얼마나 다양하고 풍부한가?
• iii) 임파워먼트: 답변이 독자가 주제를 이해하고 정보에 입각한 판단을 내리는 것을 얼마나 효과적으로 가능하게 하는가?
• iv) 전반적: 이 차원은 앞의 세 가지 기준에 걸친 누적 성능을 평가하여 전반적으로 가장 좋은 답변을 식별
  - Pairwise 평가 : 두 답변을 직접 비교하고 각 기준에 대해 우수한 응답을 선택

4.2 Comparison of LightRAG with existing RAG Methods (RQ1)

• 대규모 코퍼스에서 우수함 : LightRAG와 GraphRAG 같은 그래프 기반 시스템이 기존 청크 기반 방법들보다 우수
  데이터셋 크기가 클수록 성능 격차가 더 증가
• 다양성 측면 : Diversity 메트릭에서 LightRAG가 현저한 우위
  Dual-level 검색 패러다임 덕분에 더 포괄적인 정보 검색 가능
• GraphRAG와의 비교 : 
  둘 다 그래프 기반이지만 LightRAG가 일관되게 우수(복잡한 언어 맥락 처리에서 더 효과적)

4.3 Ablation Studies(RQ2)

• Dual-Level 검색 패러다임 효과성 : 각각 하나의 모듈을 제거한뒤 평가
  • Low-level로만 검색(-High) : 
    • 거의 모든 데이터셋, 메트릭에서 상당한 성능 하락 있음.
    • 추측 : 특정 정보(엔티티)에 대해 과도하게 집중하여 그런것으로 추측. 포괄적인 통찰이 필요한 부분에서 정보 수집이 어려운 것으로 보임
  • High-level로만 검색(-Low) : 
    • 특정 엔티티를 심도 있게 조사하는 능력이 감소하여, 상세한 답변 불가
  • 원본 텍스트 제거 (-Origin) : 그래프 구조에서 추출된 정보만 사용
    • 그래프 기반 인덱싱 프로세스 만으로도 핵심 정보 전달 가능(쿼리에 답변하기에 충분한 맥락 제공)
    • 원본 텍스트는 노이즈를 유발할 수 있는 관련 없는 정보 포함.

4.4 CaseStudy(RQ3) (생략)

4.5 Model Cost and Adaptability Analysis (RQ4) (생략)

5. Related Work 생략

LightRAG예시

Graph 생성 예시

Keyword 추출 예시

RAG Evaluation 예시

논문을 읽었으나, 구조가 복잡하여, 코드를 살펴봐야 할 것

https://github.com/cpacker/MemGPT

Abstract

• 제한된 context window로 인해 긴 대화나 문서 분석과 같은 작업에서는 퍼포먼스가 약함
• context window 범위를 넘어서는 context를 활용하기 위해, virtual context management 기술을 제안
  *(운영체제가 physical memory와 disk 사이의 paging을 통해 확장된 virtual memory를 제공하는 것과 유사함.)
• MemGPT(MemoryGPT) : 제한된 context window 내에서 효과적으로 확장된 context를 제공하기 위해 서로 다른 storage tier를 관리하는 시스템
  1. 문서 분석: MemGPT는 기존 LLM의 context window를 크게 초과하는 대규모 문서를 분석할 수 있다.
  2. 다중 세션 채팅: MemGPT는 대화형 에이전트가 사용자와의 장기적인 상호작용을 통해 기억하고, 반영하고, 동적으로 발전한다.

1. Introduction

• 현 LLM은 다방면에서 잘하고 있음
  허나, 제한된 context window로 인해 적용 가능성을 크게 제한한다. 
  최근 연구에 따르면 long-context 모델이 context를 효과적으로 활용하는 데 어려움을 겪는다는 것을 보여준다. 
• 이 논문에서, 고정 context를 사용하며 무한한 context를 사용하는 방법을 연구함.
• LLM 에이전트의 function calling을 활용하여 virtual context management를 위한 LLM 시스템인 MemGPT를 설계
  • Function call을 통해 LLM 에이전트는 외부 데이터 소스를 읽고, 쓰고, 자체 context를 수정하고, 사용자에게 응답을 제공하는 시점을 선택한다.
  • 이러한 기능을 통해 context window("main memory"에 해당)과 외부 저장소 사이에서 효과적으로 정보를 "paging" 한다.
  • function call은 context 관리, 응답 생성, 사용자 상호작용 간의 제어 흐름을 관리하는 데 활용
  • 이를 통해 에이전트가 단일 작업에 대해 context에 있는 내용을 반복적으로 수정하여 제한된 context를 더 효과적으로 활용
  • function calling과 이벤트 기반 제어 흐름의 메모리 계층을 결합하여 사용하여 MemGPT는 유한한 context window를 가진 LLM을 사용해 무제한의 context를 처리한다
• 평가 :
  • 문서 분석: 표준 텍스트 파일의 길이가 현대 LLM의 입력 용량을 빠르게 초과할 수 있는 영역
  • 대화형 에이전트: 제한된 대화 window로 인해 LLM이 확장된 대화 중에 context 인식, 페르소나 일관성, 장기 기억이 부족한 영역
  • 두 설정 모두에서 MemGPT는 유한한 context의 제한을 극복하여 기존 LLM 기반 접근 방식보다 더 나은 성능을 보여줌

2. MemGPT(MemoryGPT)

두 가지 주요 메모리 유형을 구분 : 

1. Main context (main memory/physical memory/RAM과 유사)
   - LLM prompt tokens로 구성 : main contedt에 있는 모든 것은 In-context로 간주되어, 추론하는 동안 LLM processor에 의해 접근이 가능함.
2. External context (disk memory/disk storage와 유사)
   - 외부에 저장된 모든 데이터를 의미함. out-of-context 데이터는 inference중에 LLM processor에 전달되기 위해서는, 반드시 main context로 데이터를 이동 시켜야 한다.

MemGPT는 LLM processor가 사용자 개입 없이 자체 메모리를 관리할 수 있도록 function call을 제공한다.

2.1 Main Context (Prompt Tokens)

(Figure 3의 상단 부분)MemGPT의 prompt tokens는 세 개의 연속된 섹션으로 구성되어 있다.

1. System instructions
   - 읽기 전용(정적), (control flow / 다른 메모리 레벨의 사용법 / MemGPT 함수 사용법 - out-of-context데이터를 검색하는 방법)을 포함한다.
2. Working context
   - 고정된 크기의 읽기/쓰기 블록으로, 비정형 텍스트를 저장하는 용도로 사용하며, MemGPT의 function call을 통해서 쓰기 가능하다. system instruction과 달리 수정이 가능하다
   - 핵심 사실 저장, 사용자 선호도 저장, 에이전트의 페르소나 관련 중요 정보 저장, 대화 맥락에서 자주 참조되는 중요 정보 유지 등에 사용된다
3. FIFO Queue
   - 롤링 히스토리 형태로 데이터를 저장한다. 새로운 메시지가 들어오면 가장 오래된 메시지부터 제거하며, 동적으로 크기가 변한다.
   - 에이전트와 사용자 간의 대화 메시지를 저장하고, 시스템 미시지, function call 입력 출력 등을 저장한다.
   
   1. Warning Token Count( context window 70% 도달 시)
      - 중요 정보를 working context, archival storage로 정보를 이동시킴
   2. Flush token count (context window 100% 도달 시)
      - Context window 50% 제거
      - 제거된 메시지는 recall storage에 저장

• 정리하자면, system instruction은 절대 바뀌지 않을 정보들이 저장 (AI는 인간을 헤칠수 없어 와 같은 절대적 룰들)
  working context는 장기 기억이 필요한 중요 정보를 저장 - long memory
  fifo queue는 현재 진행중인 대화의 흐름 관리 - short memory

2.2 Queue Manager(storage, overflow제어, flush token count)

recall storage와 FIFO queue의 메시지를 관리함.(Figure 3의 하단 부분, 파란 화살표)

• 시스템이 새 메시지를 받으면 queue manager는 : 
  • 수신 메시지를 FIFO queue에 추가
  • Prompt Tokens에 연결
  • LLM output을 생성하기 위해 LLM inference를 실행

• Queue Manager는 수신 메시지 및 LLM출력물을 모두 recall storage에 기록함.
  • MemGPT가 function call을 통해 Recall Storage에서 메시지 검색 요청
  • Queue Manager가 검색된 메시지를 FIFO Queue 끝에 추가
  • 추가된 메시지는 LLM의 Context Window에서 접근 가능
    -> 위 과정은 dynamic RAG와 비슷함.
    [Recall Storage] ---(Function Call)---> [Queue Manager] ---(추가)---> [FIFO Queue] ---> [Context Window]

• Queue Manger는 queue eviction policy를 통해 context overflow 제어
  • 목적 : context overflow 방지, 중요 정보 보존
  • 작동 : Prompt token이 70% 정도 차지하게 되면, 작동함.

• Queue Manager는 flush token count를 통해 context window 제어
  • Prompt tokens가 context window 100% 초과시
  • 추가적인 context window가 필요함.
  • 작동 : Context Window의 50%에 해당하는 메시지를 큐에서 제거
    -> 제거되는 텍스트는 recall storage로 이동
    -> 제거되는 텍스트는 요약하여 FIFO Queue의 첫 번째 위치에 저장
• queue eviction policy와 flush token count는 비슷한것 같은데?
  • eviction : 예방 단계
  • Flush : 강제 정리 단계

2.3 Function Executor

기본 역할

• function call을 통해 main context와 external contxt사이 데이터 이동을 조율함.
• LLM processor가 생성한 function call을 처리
• 대화 기록이 너무 길어질 때(그림 1에서 보여지는 것처럼) context 간에 항목을 이동하고, 현재의 목표와 책임에 대한 이해를 더 잘 반영하도록 main context를 수정

메모리 관리 자율성

• Self-directed 메모리 편집과 검색
• 대화 기록이 길어질 때 context 간 데이터 이동
• 현재 목표에 맞게 main context 수정

구현 방식

• system instructions에 명시적 지침 포함
  1. 메모리 계층에 대한 설명
  2. Function schema(메모리 접근 및 수정용 함수 정의)

2.4 Control flow and function chaining

• Event system
  • 목적 : LLM 추론을 트리거하는 입력 시스템
  • 이벤트 종류 : 
    • 1. 사용자 관련 이벤트
      • 채팅 메시지, 로그인/로그아웃, 문서 업로드 완료
    • 2. 시스템 이벤트
      • Main context용량 경고
      • 메모리 관리 알림
    • 3. 자동화된 이벤트
      • 예약된 주기적인 실행
      • 사용자 개입없는 자동 실행
• Function Chaining
  • 목적 : 복잡한 작업을 순차적 함수 실행

recall storage와 archival storage차이

• Recall Storage:
  • 대화 히스토리나 메시지를 저장하는데 특화
  • Queue Manager가 관리하며, 모든 incoming 메시지와 생성된 LLM 출력을 자동으로 저장
  • 주로 이전 대화 내용을 검색하고 참조하는데 사용
  • FIFO queue와 긴밀하게 연동되어 작동
• Archival Storage:
  • 일반적인 목적의 읽기/쓰기가 가능한 데이터베이스
  • 임의 길이의 텍스트 객체를 저장
  • 문서 분석에서 주로 사용되며, 전체 문서 콘텐츠를 저장
  • Vector 검색 기능이 있어 (예: pgvector) 유사도 기반 검색 가능
  • 보다 영구적인 정보 저장에 사용

3. Experiment

긴 context를 활용하는 데이터 셋에서 실험을 진행

3.1 MemGPT for conversational agents

사용자와 대화할 때, 이러한 에이전트는 두 가지 핵심 기준을 만족해야 함:

1. 일관성 - 에이전트는 대화의 일관성을 유지해야 함. 언급된 새로운 사실, 선호도, 사건들은 이전 진술과 일치해야함.
2. 참여도 - 에이전트는 사용자에 대한 장기적 지식을 활용하여 응답을 개인화해야함.

3.1.1, 3.1.2 생략 - 평가 메트릭 설명

3.2 MemGPT for document ananlysis

retrieval로 OpenAi text-embedding-ada-002, cosine similarity를 사용함

3.2.1 Multi-Document Question-Answering

Retrieve하는 Document의 수에 관계없이 MemGPT는 일정한 성능을 보임.

Abstract

• Knowledge Graphs (KGs)는 (head, relation, tail) 형태의 triplet
• Graph Neural Networks (GNNs)는 KG에 저장된 복잡한 그래프 정보를 처리할 수 있어 KGQuestioning Anaswering Task에서 널리 사용
• GNN-RAG를 소개 : RAG 방식으로 LLM의 언어 이해 능력과 GNN의 추론 능력을 결합하는 새로운 방법
  • 첫째, GNN이 주어진 질문에 대한 답변 후보를 찾기 위해 dense KG subgraph에 대해 추론을 수행
  • 둘째, KG 내에서 질문 엔티티와 답변 후보를 연결하는 최단 경로를 추출하여 KG 추론 경로를 표현
    • 추출된 경로는 자연어로 변환되어 LLM의 RAG 추론을 위한 입력으로 제공
  •  GNN-RAG 프레임워크에서 GNN은 유용한 그래프 정보를 추출하는 dense subgraph reasoner로 작동하고, LLM은 궁극적인 KGQA를 위한 자연어 처리 역량을 씀.
•  GNN-RAG와 함께 KGQA 성능을 더욱 향상시키기 위한 retrieval augmentation (RA) 기술을 개발
• 실험 결과
  • 최고 성능을 달성
  • 7B tuned LLM으로 GPT-4의 성능을 능가하거나 비슷함.
  • GNN-RAG는 multi-hop 및 multi-entity 질문에서 뛰어남

1 Introduction

• LLM의 특성과 한계
  • LLM은 자연어 이해에 뛰어나며 많은 NLP 태스크에서 최고 성능을 보임
  • 이러한 능력은 대규모 텍스트 데이터에 대한 사전학습에서 비롯됨
  • 하지만 사전학습이 비용과 시간이 많이 들기 때문에:
    • 새로운 지식이나 도메인별 지식에 쉽게 적응하지 못함
    • Hallucination(환각, 잘못된 정보 생성) 문제가 있음
• Knowledge Graphs (KGs)의 특성
  • 구조화된 형태로 정보를 저장하는 데이터베이스
  • 정보는 triplet 형태로 저장 (예: <Jamaica → language_spoken → English>)
  • 장점:
    • 쉽게 업데이트 가능
    • 복잡한 상호작용(예: multi-hop relations) 표현 가능
    • 지식 집약적 태스크(예: QA)에 널리 사용됨
• Retrieval-augmented generation (RAG)
  • LLM의 hallucination을 줄이기 위한 프레임워크
  • KG에서 얻은 최신의 정확한 정보로 입력 컨텍스트를 보강
  •  예시:
    • 입력: "Knowledge: Jamaica → language_spoken → English"
    • 질문: "Which language do Jamaican people speak?"
  •  하지만 RAG의 성능은 검색된 KG 품질에 크게 의존함
• 현재 검색 방법의 문제점
  • KG는 수백만 개의 사실을 포함하는 복잡한 그래프 정보 저장
  • 올바른 정보 검색이 어려움
  • 부적절한 정보 검색은 LLM의 KGQA 추론을 방해할 수 있음
  • 기존 LLM 기반 검색 방법의 한계:
    • 복잡한 그래프 정보 처리 능력 부족
    • Multi-hop KGQA에서 성능 저하
    • 누락된 정보를 보완하기 위해 GPT-4와 같은 대형 LLM에 의존
      (누락한 정보는 LLM의 Reasoning성능으로 대체)
• GNN-RAG의 제안
  • GNN의 그래프 처리 능력과 LLM의 자연어 이해 능력을 결합
  • 주요 프로세스:
    • GNN이 dense KG subgraph에서 답변 후보 검색
    • 질문 엔티티와 GNN 기반 답변을 연결하는 최단 경로 추출
    • 추출된 경로를 자연어로 변환하여 LLM에 입력
• 논문의 주요 기여
  • Framework: GNN-RAG 개발 및 retrieval augmentation 기술
  • Effectiveness & Faithfulness: 최신 성능 달성, 특히 복잡한 질문에서 우수
  • Efficiency: 추가 LLM 호출 없이 성능 향상, 7B LLM으로 GPT-4 수준 달성

2 Related Work

2.1 KGQA Methods (지식 그래프 질의응답 방법)

• A) Semantic Parsing (SP) 방법:
  • 작동 방식: 자연어 질문을 논리적 형태(예: SPARQL 쿼리)의 쿼리로 변환, 변환된 쿼리를 KG에서 실행하여 답변 획득
  • 한계점:
    • 학습을 위해 ground-truth 논리적 쿼리가 필요함
    • 이러한 데이터는 실제로 만들기 어려움
    • 구문이나 의미 오류로 인해 실행 불가능한 쿼리가 생성될 수 있음
• B) Information Retrieval (IR) 방법:
  • 특징: 작은양의-supervised KGQA 설정에 중점, 학습을 위해 질문-답변 쌍만 필요
  • 작동 방식:
    • KG 정보 검색(예: KG subgraph) : query에 들어있는 entity기반으로 KG에서 entity search. search된 entity의 relation들을 살펴봄.
    • 검색된 정보를 KGQA 추론의 입력으로 사용

2.2 Graph-Augmented LM

• A) Latent Graph Information을 활용한 방법:
  • GNN으로 얻은 잠재 그래프 정보로 LM 강화
  • 한계점 : 언어와 그래프 간의 모달리티 불일치 문제, 지식 집약적 태스크에서 성능 저하
• B) Verbalized Graph Information을 활용한 방법:
  • RAG와 유사하게 자연어로 변환된 그래프 정보를 입력으로 사용
  • 한계점: 그래프가 큰 경우 노이즈가 있는 정보를 가져올 수 있음 -> 이는 LM의 추론 능력을 저하시킬 수 있음

3. Problem Statement & Background

• KGQA : (v, r, v') 표현되는 KG(G)가 주어진다
  - G와 자연어 질문 q가 주어졌을 때, KGQA의 태스크는 q에 정확하게 답하는 엔티티 집합 {a} ∈ G를 추출하는 것
  - 학습을 위해 질문-답변 쌍은 주어지지만, 답변으로 이어지는 ground-truth 경로는 주어지지 않음.
  • v : head entity
  • v' : tail entity
  • r : 두 엔티티의 관계
• Retrieval & Reasoning
  • KG는 보통 수백만 개의 노드를 포함하기 때문에, 질문 q에 대해 특정 서브그래프 $G_q$가 검색된다(예: entity linking과 neighbor extraction을 통해).
  • 이상적으로는, 질문에 대한 모든 정확한 답변이 검색된 서브그래프에 포함되어 있어야 한다. ({a} ∈ $G_q$).
  • 검색된 서브그래프 $G_q$와 질문 q는 추론모델(GNN, LLM)의 입력으로 사용되어 정확한 답변을 출력
• GNNs:
  • KGQA는 KG 엔티티들을 주어진 질문에 대한 답변과 비답변으로 분류하는 노드 분류 문제로 볼 수 있다.
    (연관이 있는지 없는지)
  • GNN은 노드 분류와 같은 태스크에 강함.
  • GNN은 각 이웃 v'로부터의 메시지 $m^{(l)}_{vv'}$를 집계하여 layer l에서 노드 v의 표현 $h^{(l)}_v$를 업데이트.
  • Eq1 : $h^{(l)}v = \psi(h^{(l-1)}v, \sum{v' \in N_v} \omega(q,r) \cdot m^{(l)}{vv'})$
    • 여기서:
      • 함수 ω(·)는 fact (v, r, v')의 관계 r이 질문 q와 얼마나 관련있는지를 측정
        (잘 보면 가중합)
      • 이웃 메시지 $m^{(l)}_{vv'}$는 GNN에서 일반적으로 사용되는 sum-operator Σ로 집계)(정보를 섞음)
      • 함수 ψ(·)는 연속된 GNN 레이어의 표현을 결합(NeuralNet)
• LLMs:
  • LLM은 KG 정보를 사용하여 RAG 수행
    • 검색된 서브그래프는 LLM이 처리할 수 있도록 자연어로 변환
    • LLM에 주어지는 입력은 KG 정보와 함께 질문과 프롬프트를 포함
    • 예를 들어, 입력은 다음과 같다:
      "Knowledge: Jamaica → language_spoken → English
      "Question: Which language do Jamaican people speak?"

• Landscape of KGQA method(Figure 2)
  • Figure 2는 KG 검색과 추론 측면에서 현재 존재하는 KGQA 방법론들의 현황 보여줌
  • GNN 기반 방법: GraftNet, NSM, ReaRev와 같은 GNN 기반 방법들은 복잡한 그래프 정보를 처리할 수 있는 GNN의 능력을 활용하여 dense KG subgraph에서 추론을 수행
  • LLM 기반 방법: 최근의 LLM 기반 방법들은 검색과 추론 모두에 LLM의 능력을 활용:
    - ToG: LLM을 사용하여 hop-by-hop으로 관련 사실들을 검색
    - RoG: LLM을 사용하여 가능성 있는 관계 경로를 생성하고, 이를 KG에 매핑하여 관련 정보를 검색
• LLM-based Retriever.
  • RoG의 예시 :
    1. 학습을 위한 질문-답변 쌍이 주어졌을 때, RoG는 retriever를 fine-tuning하기 위해 question 엔티티에서 시작하여 답변으로 이어지는 최단 경로를 추출.
    2. 추출된 경로를 기반으로, LLM(LLaMA2-Chat-7B)은 질문 q가 주어졌을 때 추론 경로를 생성하도록 fine-tuning
    Eq2 : LLM(prompt, q) ⇒ {r₁ → ··· → rₜ}ᵏ
    - 여기서 프롬프트는 "Please generate a valid relation path that can be helpful for answering the following question: {Question}" 이다.
    - 더 나은 답변 커버리지를 위해 beam-search 디코딩을 사용하여 k개의 다양한 추론 경로 집합을 생성
  • 생성된 경로는 질문 엔티티에서 시작하여 KG에 매핑되어 RAG를 위한 중간 엔티티들을 검색
    예: <Jamaica → language_spoken → English>

4. GNN-RAG

RAG 방식으로 LLM의 언어 이해 능력과 GNN의 추론 능력을 결합하는 방법인 GNN-RAG를 제안.

• 첫째, GNN이 주어진 질문에 대한 답변 후보를 검색하기 위해 dense KG subgraph에 대해 추론 수행
• 둘째, 질문의 엔티티와 GNN 기반 답변을 연결하는 KG 내의 최단 경로를 추출하여 유용한 KG 추론 경로를 표현
  • 추출된 경로는 자연어로 변환되어 LLM의 RAG 추론을 위한 입력으로 제공.
  • GNN-RAG 프레임워크에서
    • GNN : 유용한 그래프 정보를 추출하는 dense subgraph reasoner로 작동
    • LLM : 자연어 처리 능력을 활용하여 최종 KGQA를 수행

4.1 GNN

• embedding 방법 대신 GNN을 선호하는 이유는
• 복잡한 그래프 상호작용을 처리하고 multi-hop 질문에 답할 수 있는 능력 때문
  (multi-hop : 여러 단계의 추론이 필요한 경우)
  
  • GNN은 다양한 추론 경로를 탐색하는 구조적 이점으로 인해 높은 answer recall을 달성하여 검색에 적합한 후보가 된다
  • GNN 추론이 완료되면(Equation 1을 통한 L번의 GNN 업데이트), 서브그래프의 모든 노드는 최종 GNN 표현 $h^{(L)}_v$를 기반으로 답변과 비답변으로 점수가 매겨지고, softmax(·) 연산이 뒤따른다. GNN 파라미터는 학습 질문-답변 쌍을 사용하여 노드 분류(답변 vs. 비답변)를 통해 최적화됨
  • 결론 : GNN Neural Network를 학습하여, 해당 노드의 정보가 유용한지 안한지 판단.
  • 추론 시
    • 임계값보다 높은 확률 점수를 가진 노드들이 후보 답변으로 반환, 질문 엔티티와 후보 답변을 연결하는 최단 경로(추론 경로)도 함께 반환. 검색된 추론 경로는 LLM 기반 RAG의 입력으로 사용
    • 서로 다른 GNN은 RAG를 위해 서로 다른 추론 경로를 가져올 수 있다. Equation 3에서 보여지듯이, GNN 추론은 question-relation matching 연산 ω(q, r)에 의존
      • Eq3 : $q^{(k)} = γ_k(LM(q))$, $r = γ_c(LM(r))$
      • ω : question-relation matching function(0~1 사이 값)
      • r : KG의 관계를 벡터 형태로 표현한 것
      • ω(q, r) : query와 r의 관계를 계산
      • γ_k : attention-based pooling
        -> Query : What language are spoken in Jamaica?
        -> Attention을 기반으로 하여, Embedding 가중치를 주어 Query를 Embedding함.
        -> 학습 가능한 파라미터를 포함한 동적 pooling
        -> 질문의 다양한 의미적 측면을 포착
      • γ_c : [CLS]  token pooling
        -> 관계를 단일 벡터로 압축.
        -> 고정된 위치의 토큰을 사용하는 단순 pooling
        -> 관계의 전체적인 의미를 효율적으로 표현
    •  ω(q, r)의 일반적인 구현은 ϕ(q^(k) ⊙ r) : query가 k개의 layer를 통과한 뒤의 hidden state과 relation의 원소 곱을하고, ϕ(신경망)으로 score계산
  • Appendix B에서 우리는 GNN의 출력이 question-relation matching 연산 ω(q, r)에 의존한다는 것을 보여주는 정리함, 
• 서로 다른 GNN 아키텍처를 시도하는 대신, 서로 다른 출력 노드 표현을 결과로 내는 서로 다른 LM을 Equation 3에서 사용.
  구체적으로, 두 개의 별도 GNN 모델을 학습 : 
  • SBERT와 같은 사전학습된 LM을 사용하는 모델
  • KG에서의 question-relation matching을 위해 사전학습된 LM_SR(GNN Pretrained Model)을 사용하는 모델
•  다른 GNN들이 서로 다른 KG 정보를 검색하지만, 둘 다 RAG 기반 KGQA를 개선한다는 것을 보여줌.

4.2 LLM

GNN-RAG로부터 추론 경로를 얻은 후, 자연어로 변환하여 ChatGPT나 LLaMA와 같은 downstream LLM에 입력으로 제공

• 하지만 LLM은 입력 프롬프트 템플릿과 그래프 정보가 자연어로 변환되는 방식에 민감
  • 학습이 가능한 LLM에 대해 RAG 프롬프트 튜닝을 진행(LLaMA2-Chat-7B 모델)
  • 다음과 같은 프롬프트가 주어졌을 때 정확한 답변 목록을 생성하도록 학습 질문-답변 쌍을 기반으로 fine-tuning :
    • "Based on the reasoning paths, please answer the given question.
      Reasoning Paths: {Reasoning Paths}
      Question: {Question}"
    • 예) 
      입력 예시:
        "Based on the reasoning paths, please answer the given question. Reasoning Paths:
          Jamaica → language_spoken → English Jamaica → official_language → English
      Question: Which language do Jamaican people speak?"
        목표 출력: "English"
      
    • 추론 경로는 다음과 같이 자연어로 변환:
      "{question entity} → {relation} → {entity} → ··· → {relation} → {answer entity} \n" (Figure 3 참조)
  • 학습 중에는 추론 경로가 질문 엔티티에서 답변 엔티티로 이어지는 최단 경로.
    추론 시에는 추론 경로가 GNN-RAG를 통해 얻어짐

4.3 Retrieval Analysis: Why GNNs & Their Limitations

GNN은 그래프 구조를 활용하여 multi-hop 정보를 포함하는 KG의 관련 부분을 검색

GNN이 복잡한 multi-hop 질문에서는 뛰어나지만, 단순한 질문에서는 LLM이 더 효과적이라는 것을 실험적으로 입증
-> GNN-RAG + RA를 제안하는 근거가 됨

4.4 Retrieval Augmentation (RA)

4.3의 결과에 인사이트를 얻어, 우리는 GNN retriever를 LLM 기반 retriever와 결합하는 (GNN-RGA+RA) 제시

그래서 어떻게 GNN에서 Retrieve하는 거지?

# 논문에서 언급된 구현 세부사항:

1. 초기 subgraph 추출

- Entity Linking을 통해 질문에서 언급된 엔티티들을 KG의 엔티티와 매핑

- PageRank Nibble (PRN) 알고리즘을 사용하여 링크된 엔티티에서 시작

     시작점 : 링크된 엔티티들
     목표 : top-m 엔티티 선택하여 subgraph구성

- Top-m개(m = 2,000)의 엔티티를 포함하는 서브그래프 선택 - 2000개의 score를 계산.

2. Query-graph matching : 

- Equation 3에 의해, query와 relation을 embedding변환

- 질문과 관계 간의 점수 계산 : ω(q, r) = ϕ(q^(k) ⊙ r) 

3. GNN을 통한 정보 전파 :
- Equation 1에 의해, GNN업데이트

4. 답변 후보 선택:

- 모든 노드에 대해 softmax를 통해 답변 확률 계산

- 확률이 임계값 보다 높은 노드들을 후보로 선택

- 선택된 후보 노드들까지의 최단 경로 추출

5. Experiment Setup 생략

6. Results 생략

7. Conclusion 생략

Introduction

• 어려운 문제에 직면했을 때 여러 단계를 거쳐 신중하게 생각하고 이미 시도했던 것을 기억해야 하는 경우가 많다.
• LLM 에이전트는 언어 모델 애플리케이션에서 이러한 상황을 위해 설계되었다.
• 철저한 데이터 분석, 전략적 계획, 데이터 검색, 과거 작업에서 학습하는 능력을 결합하여 복잡한 문제를 해결한다
  이 글에서는 LLM 에이전트의 정의, 이점, 능력, 실제 사례, 직면한 과제에 대해 살펴본다.

What are LLM agents?

복잠한 테스크에서 순차적 추론이 필요한 곳에서 문제를 풀수 있는(답을 생성할 수 있는)AI 시스템이다.

미리 생각하고, 과거의 대화를 기억하며, 다양한 도구를 사용하여 필요한 상황과 스타일에 따라 응답을 조정할 수 있다.

예를 들어:

“캘리포니아에서 특정 유형의 계약 위반이 발생할 경우 발생할 수 있는 법적 결과는 무엇인가요?”

RAG 시스템을 갖춘 기본 LLM은 법률 데이터베이스에서 필요한 정보를 쉽게 가져올 수 있다.

허나,

“새로운 데이터 개인정보 보호법에 비추어 볼 때, 기업이 직면하는 일반적인 법적 문제는 무엇이며 법원은 이러한 문제를 어떻게 해결해 왔나요?”

이 답을 하기 위해서는, 새로운 규정이 여러 기업에 어떤 영향을 미치는지 이해하고, 이에 대해 법원이 어떤 판결을 내렸는지 알아야 한다.

단순한 RAG 시스템은 관련 법률과 판례를 검색할 수는 있지만, 이러한 법률을 실제 비즈니스 상황과 연결하거나 법원 판결을 심층적으로 분석할 수 있는 기능은 부족하다.

이에 답을 하기 위해서는 

• 첫 번째 하위 작업은 법률 데이터베이스에 액세스하여 최신 법률 및 규정을 검색
• 두 번째로 이전에 유사한 문제가 어떻게 처리되었는지에 대한 과거 기준선을 설정할 수 있다. 또 다른 하위 작업은 법률 문서를 요약하고 관찰된 패턴을 기반으로 향후 추세를 예측하는 것이다.

이러한 하위 작업을 완료하려면 LLM 에이전트에게 구조화된 계획, 진행 상황을 추적할 수 있는 안정적인 메모리, 필요한 도구에 대한 액세스가 필요하다. 이러한 구성 요소는 LLM 에이전트의 워크플로우의 근간을 형성한다.

LLM agent components

4가지 구성 요소로 구성되어 있다.

• Agent/brain
• Planning
• Memory
• Tool use

Agent/brain : 

• LLM 에이전트의 핵심은 학습된 방대한 양의 데이터를 기반으로 언어를 처리하고 이해하는 언어 모델이다.
• LLM 에이전트를 사용할 때는 특정 프롬프트를 제공하는 것으로 시작한다.
• 이 프롬프트는 에이전트가 응답하는 방법, 사용할 도구, 상호작용 중에 달성해야 하는 목표를 안내하는 매우 중요한 역할을 한다. 
  (컨트롤 센터 같은 역할을 함)
• 기본적으로 LLM 에이전트의 핵심은 고급 처리 능력과 사용자 지정 가능한 기능을 결합하여 다양한 작업과 상호작용을 효과적으로 처리하고 적응할 수 있도록 하는 것이다.

Memory : 

• 메모리에서는 이전에 수행한 작업의 기록함.
• 이를 통해 복잡한 LLM 작업을 처리하는 데 도움을 함.
• 메모리 두 가지 주요 유형 :
  • 단기 메모리: 이는 대화 중에 중요한 세부 사항을 빠르게 기록하는 에이전트의 메모장과 같은 역할.
    진행 중인 토론을 추적하여 모델이 즉각적인 맥락에 맞게 적절하게 응답할 수 있도록 도와줌.
    하지만 이 메모리는 일시적인 것으로, 당면한 작업이 완료되면 지워진다.
  • 장기 기억: 몇 주 또는 몇 달에 걸친 과거 상호작용에서 얻은 인사이트와 정보를 저장함.
    이는 단순히 데이터를 보관하는 것이 아니라 패턴을 이해하고, 이전 작업에서 학습하며, 이 정보를 기억하여 향후 상호작용에서 더 나은 결정을 내리기 위한 것이다.
    -> 이를 어떻게 저장할지도 중요한 연구 과제
    -> 단기 메모리와, 장기 기억 사이의 가중치, 장기 기억간의 가중치를 어떻게 줄 것인가

Planning

• 계획을 통해 복잡한 작업을 더 작고 관리하기 쉬운 부분으로 나누고 각 부분에 대한 구체적인 계획을 수립할 수 있다.
  (허나, LLM은 Planning을 못한다고 알려져 있음)
• 또한 작업이 발전함에 따라 상담원은 계획을 반영하고 조정하여 실제 상황과 관련성을 유지할 수 있다.
  -> 작업이 산으로 가지 않게 막아줌.
• 계획에는 일반적으로 계획 수립과 계획 반영이라는 두 가지 주요 단계가 포함
  
  • Plan formulation
    • 큰 작업을 더 작은 하위 작업으로 세분화한다
    • CoT : 일부 작업 세분화 접근 방식은 세부 계획을 한꺼번에 만든 다음 단계별로 따르도록 함
    • ToT : 문제를 해결하기 위해 다양한 경로를 탐색함으로써 CoT 기법을 한 단계 더 발전시킨 또 다른 접근 방식
      문제를 여러 단계로 나누고 각 단계마다 여러 아이디어를 생성하여 나무의 가지처럼 배열
    • Tree형태 : 계획을 확정하기 전에 가능한 모든 옵션을 고려하여 계층적 접근 방식을 사용. LLM 기반 에이전트는 일반적으로 지식이 풍부하지만 전문 지식이 필요한 작업에 어려움을 겪을 때가 있다. 이러한 에이전트를 도메인별 플래너와 통합하면 성능이 향상되는 것으로 입증되었다.
  • Plan reflection
    • 계획을 수립한 후에는 그 효과를 검토하고 평가하는 것이 중요하다.
    • 효과적인 방법은 ReAct와 Reflexion이 있음.
    • ReAct는 (생각, 행동, 관찰)의 순서를 순환하면서 필요에 따라 이러한 단계를 반복하여 복잡한 과제를 해결하는데 도움을 줌

Tools use

• 이 용어의 도구는 LLM 에이전트가 외부 환경과 연결하여 특정 작업을 수행하는 데 도움이 되는 다양한 함수.
• 데이터베이스에서 정보 추출, 쿼리, 코딩 및 에이전트가 작동하는 데 필요한 기타 모든 작업이 포함될 수 있다.
• LLM 에이전트는 이러한 도구를 사용할 때 특정 워크플로우를 따라 작업을 수행하거나 관찰 정보를 수집하거나 하위 작업을 완료하고 사용자 요청을 이행하는 데 필요한 정보를 수집한다.
• 한 실험에서 : 산술 문제에 계산기를 사용하도록 LLM을 훈련시켰다. 연구 결과, LLM은 직접적인 수학 쿼리는 처리할 수 있었지만 텍스트에서 숫자와 연산을 추출해야 하는 단어 문제에서는 어려움을 겪는 것으로 나타났다. 이는 외부 도구를 효과적으로 사용하는 시기와 방법을 아는 것이 중요하다는 것을 강조한다.
  -> 상황 및 Tools를 사용하는 방법을 알려주는것이 key
  -> 이러하여 Transactories를 in context learning 하나 봄.

LLM agent challenges

• 제한된 컨텍스트 : 한 번에 제한된 양의 정보만 추적할 수 있다. 대화 초반의 중요한 세부 정보를 기억하지 못하거나 중요한 지침을 놓칠 수 있다
• 장기적인 계획의 어려움 : 예상치 못한 문제가 발생했을 때 적응하는 데 어려움을 겪는 경우가 많다. 사람이 문제 해결에 접근하는 방식에 비해 유연성이 떨어질 수 있다.
• 일관성 없는 출력 : LLM 에이전트는 자연어에 의존하여 다른 도구 및 데이터베이스와 상호 작용하기 때문에 때때로 신뢰할 수 없는 출력을 생성한다. 서식을 잘못 지정하거나 지침을 올바르게 따르지 않아서 수행하는 작업에서 오류가 발생할 수 있다.
• 특정 역할에 적응하기 : 흔하지 않은 역할을 부여받을 경우, 또한 사람이 생각한대로 role을 세세하게 조정하는 것은 어렵다.
• 프롬프트 의존성 : 프롬프트를 기반으로 작동하여 프롬프트는 매우 정확해야 한다. 작은 변화도 큰 실수로 이어질 수 있으므로 이러한 프롬프트를 만들고 개선하는 것은 섬세한 과정
• Managing Knowledge : 관련 없는 정보가 너무 많으면 잘못된 결론을 내리거나 오래된 사실에 따라 행동하게 될 수 있다.
• 비용 효율성 : LLM 에이전트를 운영하는 것은 리소스가 많이 필요하다. 많은 양의 데이터를 빠르게 처리해야 하는 경우가 많기 때문에 비용이 많이 들 수 있으며, 제대로 관리하지 않으면 성능이 저하될 수 있다.

https://www.superannotate.com/blog/llm-agents

https://www.promptingguide.ai/research/llm-agents

0 Abstract

• 리포지토리 수준의 코드 완성 작업 : 리포지토리의 더 넓은 컨텍스트를 기반으로 미완성된 코드를 작성
  • 허나, 자동화된 코드 완성 도구의 경우 여러 파일에 흩어져 있는 유용한 정보를 활용 어려움.
• 이러한 문제를 해결하기 위해 간단하고 일반적이며 효과적인 프레임워크인 RepoCoder를 제안
  • 유사성 기반 검색 및 사전 학습된 코드 언어 모델을 사용
  • 리포지토리 수준의 정보를 효과적으로 활용
  • 다양한 수준의 세분화된 코드를 생성할 수 있음
  • 새로운 벤치마크 RepoEval을 제안
  • 실험 결과 : 모든 설정에서 베이스라인 10% 이상 크게 개선
    - 바닐라 검색 방식보다 일관되게 우수한 성능을 보임

1 Introduction

• 리포지토리 내의 다른 파일들을 인지하는 것이 매우 중요
• 리포지토리 수준의 코드 완성이 주목받음.
  • 단순히 파일 내 정보에만 의존하지 않음
  • 리포지토리의 더 넓은 컨텍스트를 활용하여 미완성된 코드를 완성하도록 하고자함.
• 리포지토리 내의 코드 파일들은 종종 상호 연관되어 있음.
  • 여기에는 모듈화로 인한 공유 유틸리티, 설정, 교차 API 호출
  • 각 리포지토리는 일반적으로 가독성과 유지보수성을 향상시키는 커스텀 명명 규칙과 코딩 스타일을 따름
• 효과적인 리포지토리 수준의 코드 완성은 정복하지 못함.
  • 정적 코드 분석(프로그램 실행하지 않고)과 휴리스틱 규칙에 의존하는 접근 방식은 레포지터리를 만드는데는 한계가 있음
  • 튜닝 : 레이블된 데이터로 언어 모델을 튜닝하는 연구들은 재훈련 없이 새로운 리포지토리에 적용하는데 어려움을 겪음.

본 논문에서...

• 가치 있는 정보 찾기 : 기존 검색기를 활용
• RepoCoder를 소개(그림 1)
  - 파일 내 코드 완성 방식을 개선하여 검색 증강 생성(RAG) 기술을 통합
  - 생성된 코드 완성을 활용하여 검색 프로세스를 향상시키는 반복적 파이프라인을 사용
    (-> 검색 컨텍스트와 의도된 목표 사이의 간극을 줄이는 데 도움)

그림2. 설계 배경

• 미완성 코드만으로는 리포지토리에서 유용한 정보를 검색하기에 충분하지 않음을 보임
• 예) 그림 2 : 
  • 첫 번째 반복 : COLMAP API를 호출
    - 예측된 매개변수들은 타당해 보이지만 정확하지 않음.
    - Unfinished Code(불완전한 코드)가 RetrieveCode를 검색하는 쿼리용으로 적절하지 않기 때문임.
    - 그러나 모델이 생성한 코드를 사용하여 추후에 검색을 수행하여, 관련 코드를 검색해오고 코드를 완성할 수 있었다.

RepoEval 벤치마크

• 리포지토리 수준의 코드 완성 작업을 평가하기 위해
• GitHub에서 가져온 고품질 리포지토리 사용하여 구축
• RepoEval을 도입함으로써, 우리는 리포지토리 수준 시나리오에서 확립된 벤치마크가 부족한 문제를 해결합니다. 특히, RepoEval은 (라인, API 호출, 함수 본문)이라는 세 가지 수준의 코드 완성 평가
• 단위 테스트를 활용하여 평가의 정확성을 높임.  -> 유사성 기반 메트릭의 한계를 극복

RepoCoder의 효과 검증

• GPT-3.5-Turbo
• CODEGEN
• 외에 다양한 언어 모델을 사용

반복적 프레임워크는 일관되게 기존의 검색 증강 생성 성능을 향상시킴

2 Methodology

2.1 Overall Framework

Formula

• 언어모델 : $M$
• 미완성 코드 : $X$
• 언어모델 (코드 완성 작업) : $\hat{Y} = M(X)$
• 코드 검색 모델 : $R$
• 리포지토리 코드 스니펫 모음 : $C_{repo} = {c_1, c_2, \cdots }$
  -> 코드 스니펫 별로 분할하여 검색 데이터베이스 구축

코드 생성 과정 : 

• $\hat{Y} = M(C_{ret}, X)$ : 검색모델 $R$을 사용, 미완성 코드 $X$를 검색 쿼리로 활용, $C_{repo}$에서 가장 관련성 높은 코드 스니펫을 추출하고, LLM을 통해 코드 생성
• 그러나 미완성 코드 $X$만을 검색 쿼리로 사용하면 그림 2에서 예시로 든 것처럼 검색 맥락과 완성 사이에 간극이 있음.
• 이러한 한계를 해결하기 위해, 우리는 RepoCoder를 제안 -> 반복적 검색-생성 파이프라인
  • 이전 모델 예측 $\hat{Y}{i-1}$을 활용하여 검색을 위한 새로운 쿼리를 구성
  • 또 다른 관련 코드 스니펫 집합 $C^i{ret} = R(C_{repo}, X, \hat{Y}{i-1})$을 생성
  • 이어서 $C^i{ret}$를 사용하여 새로운 프롬프트가 구성되어 새로운 예측 $\hat{Y}i = M(C^i{ret}, X)$이 생성
• $M$과 $R$의 매개변수는 변경되지 않음.
• 검색 데이터베이스를 구축하기 위해 정적 코드 분석 도구나 휴리스틱 규칙이 필요하지 않음.

2.2 Code Retrieval

검색기 : 

• 특정 쿼리가 주어졌을 때 관련 문서를 검색할 수 있는 모든 모델이 될 수 있음
• 검색 데이터베이스를 구축하기 위해 슬라이딩 윈도우 접근 방식을 사용
• 슬라이딩 윈도우는 리포지토리의 파일들을 순회하며 윈도우 크기 $S_w$ 내에 맞는 연속된 코드 라인을 추출
• 슬라이딩 윈도우는 각 반복마다 고정된 수의 라인만큼 이동하는데, 이를 슬라이딩 크기 $S_s$라고 정의

사용 예시 :

• 첫 쿼리 : 미완성 코드 $X$의 마지막 $S_w$ 라인을 사용, 가장 유사한 코드 스니펫 검색 $C^1_{ret} = R(C_{repo}, X)$
• 괴리 : $X$를 기반으로 한 검색 컨텍스트와 $X$를 계속 작성하려는 의도는 간극이 존재.
  가능한 해결책 : $C^1_{ret}$를 조정하여 각 코드 스니펫을 몇 줄 아래로 이동시켜 후속 코드를 포함
• RepoCoder는 $i$번째 반복($i > 1$)에서 이전에 생성된 코드 $\hat{Y}{i-1}$로 검색 쿼리를 보충함.
• 생성된 코드 $\hat{Y}{i-1}$는 정확하지 않으나, 검색 과정에서 보충 정보를 제공할 수 있음. 따라서 $i$번째 검색 반복($i > 1$)에서 쿼리는 $X$의 마지막 $(S_w - S_s)$ 라인과 $\hat{Y}{i-1}$의 첫 $S_s$ 라인을 연결하여 구성( $C^i{ret} = R(C_{repo}, X, \hat{Y}_{i-1})$ )

2.3 Code Generation

RepoCoder 프레임워크에서 사용되는 LM

• 특정 프롬프트가 주어졌을 때 후속 토큰을 예측할 수 있는 모든 사전 훈련된 언어 모델 가능
• (그림 3)효과적인 코드 완성을 위해서는 리포지토리의 컨텍스트 $C_{repo}$와 대상 파일 내의 컨텍스트를 모두 통합
• Rerank : 쿼리와의 유사도 점수를 기준으로 오름차순으로 정렬
  - 경로 제공 : 각 코드 스니펫에는 파일 경로가 함께 제공
  - 코드 스니펫의 최대 개수 : $K$는 사용 가능한 프롬프트 길이에 따라 달라짐. 가능한 한 많은 관련 정보를 포함

3. Benchmark Construction (생략)

LineCompletion

API Invocation Completion

Function Body Completion

4. Experimental Setup

4.1 Methods for Comparison

In-File Completion : 제공된 컨텍스트를 기반으로 제로샷 방식으로 코드를 생성. 파일 내 컨텍스트만 활용

Oracle Method : 미완성 코드의 마지막 부분과 정답 코드의 첫 부분을 사용하여 단일 검색을 수행한 후 코드를 생성. RepoCoder의 성능 상한선 제시

4.2 Implementation Details

Retrieval Model : Sparse bag-of_words
- 쿼리와 후보 코드 스니펫을 토큰 집합으로 변환하고 자카드 지수를 사용하여 유사도를 계산

Generation Model : GPT-3.5-Turbo, CODEGEN(350M, 2B, 6B)

Hyper-parameters : 

4.3 Evaluation Metrics

Similarity-based Evaluation :  편집 유사도(Edit Similarity, ES), 정확한 일치(Exact Match, EM)

Execution-based Evaluation : Excute the completed code and report the Pass Rate, PR is 1 if the code passes all the test case, and 0 otherwise

5 Experimental Results

5.1 Line and API completion Dataset

• 데이터 :  라인 및 API 호출 완성 데이터셋
• 모델 : 네 가지 사전 훈련된 언어 모델
• RAG : 다양한 검색 사용

• (표 2a와 2b) RepoCoder가 모든 모델에서 두 데이터셋 In-File에서 개선됨을 보임
• 정확히 일치(EM) 및 편집 유사도(ES) 점수 개선은 각각 10%와 8%를 상회
• Oracle 방법과 비교하여 경쟁력 있는 결과를 보여줌.
• 바닐라 RAG보다 높은 성능 보임 : 두 번 이상의 반복에서 vanila-RAG 능가
• GPT-3.5-Trubo와 비슷한 성능을 보임 : CODEGEN(350M) RepoCoder와 같이 사용시. In-File 완성에서 GPT-3.5-Turbo 모델과 비슷한 성능을 보임
• 검색 방법론에 강건함 : UniXcoder로 구동되는 Dense 검색 사용하여 RepoCoder를 테스트, 간단한 Sparse 검색기와 동일한 성능을 함을 발견 -> RepoCoder가 다양한 코드 검색 및 생성 모델에 걸쳐 견고함을 보임.

5.2 Function Completion Dataset(함수 완성)

• 함수 완성은 어려운 작업으로, 컨텍스트 길이가 더 길고, 더 큰 모델인 GPT-3.5-Trubo모델을 사용
• RepoCoder는 In-File 완성 방법에 비해 상당한 개선을 보이며 Oracle 방법과 비교하여 경쟁력 있는 성능을 보임.

6. Analysis

6.1 Quality of Retrieved Code

• 검색된 코드의 품질이 성능에 상당한 영향을 미침
• 가장 도움이 되는 코드 스니펫 : 목표로 하는 코드와 유사한 코드를 포함하거나, API호출 예시 사용법이 있는 경우
  -> In Context Learning, Few Shot Learning이 가장 좋았다는 거네.

GT-Code : -> 정답에 사용된API를 알 수 없으니, 현실에서는 사용할 수 없음.

• 정답에 사용된 API의 호출을 하는 코드 스니펫을 찾는다.
• 코드 스니펫을 미완성 코드와의 유사성을 기반으로 순위를 매기
• 가장 유사한 것들을 선택하여 완성 프롬프트에 포함

표 4의 결과 :

• 정답 API 호출 예시를 활용하는 GT-Code 방법이 최고의 성능을 달성
• 두 번의 반복을 거친 RepoCoder는 단일 반복에 비해 정답 API 호출에 대해 더 높은 리콜을 보임

6.2 Location of Retrieved Code

7. Related Work

• Repository Context in Code Completion
• 재순위 : 전통적인 방법, 잠재적인 제안을 식별하여, 재순위함.
  - 단점 : 디테일한 코드 생성하는 유연성 부족
• 다음 토큰 생성 : 코드 완성을 언어 모델링으로 접근함. 
  - 단점 : 레이블화, 데이터 수집. 미세조정은 많은 노력이 필요함
• LLM : Shrivastava et al. (2022)의 연구
  - 리포지토리의 전체 컨텍스트를 활용해, 코드 완성을 위한 프롬프트를 생성하는 방법을 제안
  - 편집중인 파일과 관련된 리포지토리에서 정보를 추출하여 프롬프트 구성
  - 휴리스틱 사용 : 관련 정보 식별, 추출을 위해 (파일간의 유사성, 가져오기, 함수 호출 패턴 등) 고려
  - 클래시파이어 훈련 : 프롬프트에 포함될 높은 정보를 뽑기 위해, 모델 훈련
  - 단점 : 유연하지 않은 휴리스틱 및 클래시파이어 모델에 의존함.
• 검색 및 생성 모델링
• 모델의 예측을 컨텍스트로 활용

8. Conclustion and Future Work

Limitations : 

• Limited Effectiveness for Repositories with Low Code Duplication : 리포지토리에 코드 중복 인스턴스가 거의 없는 경우 RepoCoder가 큰 성능 향상을 가져오지 못할 수 있다. (Few shot이 안되기 때문)
• Difficulty in Identifying the Optimal Number of Iterations : 옵티멀한 iteration을 찾기 어려움. 여러 방법을 생각해 보았으나, 찾지 못했음.
  LLM to validate하면?, 특정 Metric들에 대해서 Valid Loss Tracking하는 것과 같이 한다면?
• Time Efficiency for Real-Time Deployment
• Limited Exploration of Different Experimental Settings