no image
[Paper Review] CURE: Context- and Uncertainty-Aware Mental Disorder Detection
논문링크https://aclanthology.org/2024.emnlp-main.994/Introduction시간적, 공간적 제약 없이 온라인에서 정신 건강 전문가와 유사한 경험을 공유하는 많은 동료들과 개인을 연결하는 소셜 미디어는 정신 장애 감지에 널리 사용되는 수많은 데이터를 채우고 있다. 현재 정신적 장애 탐지의 중요성과 풍부한 데이터의 접근성은 연구 커뮤니티에서 정신 장애 탐지를 위한 딥러닝 모델 개발하고 있다. 하지만 최근에 나온 모델들은 정신적 장애에 대해 탐지를 잘 하지만 왜 탐지를 잘하는지에 대해서 설명능력이 매우 부족해서 블랙박스로 여겨지고 있다. 모델의 설명 가능성의 중요성을 활용하여 정신 장애를 감지하는 데 있어 정신 장애를 감지하는 데 있어 정신과적 증상을 찾는 몇 가지 시도가 있..
2024.11.19
no image
캡스톤 디자인은 정말 힘들어요
캡스톤디자인 팀은 3명으로 구성했다.​FrontEndBackEndAI​총 3명이서 각각의 파트를 정해서 팀원을 구성했다. 보통 4명을 많이 하는데 3명을 한 이유는 각자의 파트가 겹치는 것을 염려해서이다. 파트가 겹치게 된다면 누군가는 도움을 주고 누군가는 도움을 받는 일이 무조건적으로 생길 수 밖에 없다. 그렇게 되면 결국 누군가는 업혀가게 되면서 좋지 않을 수 있기 때문에 각각 파트는 1명이 담당하는 식으로 진행했다.​​우리학교의 캡스톤디자인은 총 1년과정이다. 캡스톤디자인 (1), 캡스톤디자인 (2) 2개 학기로 구성되어있고 캡스톤 디자인 (1)은 3학년 2학기에 듣게 되고 캡스톤 디자인 (2)은 4학년 1학기에 진행한다. 요약하면 다음과 같다.캡스톤 디자인 (1)9월 ~ 10월팀빌딩 및 아이디어 ..
2024.11.17
no image
2024년 인천대 정보기술대학 해커톤(럭키톤,Lucky-thon) 대상(1등) 후기
오늘은 학교 교내에서 진행했던, 해커톤인 Lucky-thon에 대해 후기에 대해 작성하려고 한다.일단 결론부터 말하자면, 대상을 탔다. 근데 정말로 대상을 탈 줄 몰랐기 때문에 더욱 놀랐던 거 같다. 이와 관련해서 무슨 일이 있었는지 처음에 팀 구성부터 시작해서 어떻게 하게 되었는지 자세하게 얘기해 보겠다.팀 빌딩팀원은 3명에서 4명이 모이기로 했는데 여기서 고민을 했다.  팀원을 어떻게 구성해야 좋을까 라는 생각을 했었다. 개발 기간이 긴 편이지만, 중간고사 시험기간이 겹쳐 있었기 때문에 고민을 해본다면 '개발 기간을 어느 정도로 가져가야 할 것인가'다. 일단, 당장 나는 시험을 보지는 않지만, 다른 프로젝트를 진행하고 있는 상황이어서 시간을 많이 쏟기는 어려울 거라고 생각했다. 그래서 시간을 많이 쏟..
2024.11.16
no image
2024년 멋쟁이 사자처럼 해커톤
멋쟁이 사자처럼에서 해커톤을 하면서 경험했던 것들에 대해 적어보려고 한다. ​시작은 생각보다 우여곡절이 많았다. 처음에는 아이디어톤을 했었던 분들과 같이하고 싶었지만, 확답을 주는 것이 어려웠다. 대학교 석사를 위해 학회를 준비하고 있었다. 그 학회가 대회 해커톤과 일정이 겹치는 바람에 학회 일정이 취소되고 나서 확답을 줄 수 있었다. 두 행사의 일정이 겹친다.​학회 참가 어렵다는 메일학회 참가가 어려워서 해커톤에 참여하기로 결정했다. 하지만, 이 결정을 내리는 당시에는 아이디어톤 인원들이 이미 팀 구성이 끝난 상황이어서 팀을 구하기가 어려웠다. 그래서 이건 안되겠다고 생각해서 멋사 MT 때, 같이 할 사람을 모집했다. 여기서도 어려웠던 것이 이미 팀이 있었고, AI를 사용할 일이 없다고 했던 것이다. ..
2024.11.14
no image
2024 INU CODE FESTIVAL
생애 첫 상품을 타게 되었던 대회인 2024 INU CODE FESTIVAL 참가 후기에 대해 소개하려고 한다. 위 대회에 참가 권유가 와서 참가를 고민했었다. 참가를 고민한 이유는 8월 중순부터 알고리즘 스터디 운영을 중단하면서 백준, 프로그래머스와 같은 관련 문제들을 일절 손에 대고 있지 않았기 때문이다. 그래서 내가 참가하더라도 상을 못할 것 같아서 일부러 참여하지 않았다. 그런데 이민규씨가 그냥 간단하게 링크하나만 보냈다.(참가하라는 암묵적 의미..)그래서 어차피 불참해도 내년에 참가는 안할거니까 일단 그냥 신청만 했었다. 그리고 정말 아무것도 준비하지 않았다. ​2023, 2024년 문제 풀었던 통계9월 30일에 있는 것은 대회 이후에 한 것이므로 다시말하면 백준은 2월부터 풀고 있지 않아서 자..
2024.11.10
no image
[Paper Review] ESC-Eval: Evaluating Emotion Support Conversationsin Large Language Models
논문링크https://arxiv.org/pdf/2406.14952   Introduction최근에 매우 빠른 LLM의 개발과 함께 LLM과의 대화가 매우 많이 늘어나고 있다. 다양한 대화 애플리케이션에도 불구하고, Emotional Support Conversation(ESC)는 매우 유망한 곳이다.여기서는 사람들이 쉽게 자신의 경험과 우려를 공유하고 감정적 위로를 받는다. 최근에 LLM 기반의 Coneversation이 증가하고 있지만, 포괄적인 평가는 매우 어렵다.현재 ESC 평가는 2가지 방식으로 평가하고 있다. 평가 방식장점단점예시text-based statistical metric자동가격, 시간 효율적텍스트의 의미가 아닌 텍스트의 유사도 평가BLEU, ROUGEmanual evaluation수동..
2024.11.06
no image
[Paper Review] PlanRAG: A Plan-then-Retrieval Augmented Generation for Generative Large Language Models as Decision Makers
최근에 동아리에서 구현해야 할 기술에 대해 고민을 하고 있는데 범위가 상당하다 보니 데이터를 만들어서 진행하는 것은 어렵다고 판단했다. 그래서 데이터베이스에서 가져오는 방법을 고민하고 있으며 그중에서 NAACL에 대해서 찾아보다가 알게 되어서 논문을 읽어보았다.논문링크https://arxiv.org/pdf/2406.12430Introduction현실세계에서 사업과 관련된 상황에서 결정을 하는 것은 매우 중요한 일이다. 결정을 하기 위해서는 데이터 분석을 통해 가장 적절한 결정을 해서 목표를 달성하는 것이다. 일반적으로 결정을 하는 일은 3가지 과정을 요구한다.결정에 필요한 데이터들을 분석하여 계획을 세운다.관련된 필수적인 데이터를 검색한다.데이터를 기반으로하여 걸 정한다.여기서 2번과 3번 과정을 쉽게 ..
2024.10.26
no image
[Paper Review] Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
오늘은 RAG에 대해 좀 더 진화한 Self-RAG에 대해 알아보았고 페이퍼 리뷰를 적어보려고 한다.논문링크https://arxiv.org/abs/2310.11511 Introduction최근의 State-Of-The-Art(SOTA) 모델들은 사실적 오류(할루시네이션 등)에 대해 방지하고자 Retrieval-Augmented Generation(RAG) 방식을 사용하고 있다. 하지만 이런 방식은 Large Language Models(LLMs)의 다재다능과 불필요한 정보들을 추가할 수 있기 때문에 오히려 문제가 생길 수 있다. 특히, 품질이 떨어지는 정보들을 가져올 수 있기 때문이다. 그래서 여기서는 Self-Reflective Retrieval-augmented Generation(SELF-RAG) ..
2024.10.25
no image
[Model Review] QWEN2 Technical Report
오늘은 Qwen 모델에 대해 공부를 하기 위해서 Qwen2 Technical Report를 읽고서 간단하게 요약하려고 한다. Qwen 모델에 대해 간단하게 알고 싶은 분들을 위해 작성한다.Paper 링크https://arxiv.org/pdf/2407.10671  Introduction여기서는 0.5B, 1.5B, 7B, 72B, 57B-A14B(MoE) 총 5개의 파라미터가 각각 다른 모델에 대해 소개하고 있다. 모델은 각각  7T 토큰의 데이터셋으로 훈련이 되었다. 토크나이저, 모델 구조, 데이터셋, 실험 등에 대해 상세하게 서술하고 있으며 MoE 모델에 대해서 매우 자세하게 얘기하고 있다. 0.5B와 1.5B는  스마트폰, 이어폰과 스마트 안경에 적합하고 그 외의 모델은 GPU에 적합하다고 말하고 있..
2024.10.24
no image
[Python] Python에서 빠른 입출력 방법
프로그래밍 대회나 알고리즘 문제를 풀 때, 입출력 속도는 매우 중요합니다. 특히 파이썬은 다른 언어에 비해 입출력 속도가 느린 편이기 때문에, 기본 입출력 방법을 사용하면 시간 초과가 발생할 수 있습니다. 이 글에서는 파이썬에서 데이터를 빠르게 입출력하는 방법을 소개하겠습니다. 빠른 입력기본적으로 파이썬에서는 input() 함수를 사용하여 입력을 받습니다. 하지만 이 함수는 내부적으로 버퍼링을 하지 않아 속도가 느립니다. 따라서 sys.stdin.readline() 함수를 사용하여 입력 속도를 향상시킬 수 있습니다.import sysdata = sys.stdin.readline().rstrip()sys.stdin.readline()은 한 줄의 입력을 빠르게 받아옵니다.입력받은 문자열의 끝에는 줄바꿈 문자..
2024.10.06
728x90
논문링크
https://aclanthology.org/2024.emnlp-main.994/

Introduction

시간적, 공간적 제약 없이 온라인에서 정신 건강 전문가와 유사한 경험을 공유하는 많은 동료들과 개인을 연결하는 소셜 미디어는 정신 장애 감지에 널리 사용되는 수많은 데이터를 채우고 있다. 현재 정신적 장애 탐지의 중요성과 풍부한 데이터의 접근성은 연구 커뮤니티에서 정신 장애 탐지를 위한 딥러닝 모델 개발하고 있다. 하지만 최근에 나온 모델들은 정신적 장애에 대해 탐지를 잘 하지만 왜 탐지를 잘하는지에 대해서 설명능력이 매우 부족해서 블랙박스로 여겨지고 있다. 

모델의 설명 가능성의 중요성을 활용하여 정신 장애를 감지하는 데 있어 정신 장애를 감지하는 데 있어 정신과적 증상을 찾는 몇 가지 시도가 있었다. 이러한 방법들은 증상 기반의 모델이며, 두 가지 단계로 구성되어 있다.

  1. 유저가 생성한 포스트로 부터 증상을 파악
  2. 증상 벡터를 이용한 정신적 장애를 탐지하는 질병 탐지

이러한 접근 방식은 고성능 정신 장애를 감지할 뿐만 아니라 증상 벡터를 사용하여 증상 발생 가능성에 따른 결정을 해석할 수 있으므로 모델 결과에 대한 해석 가능성을 제공한다.

하지만 증상 기반의 방식에서 증상 벡터만 이용하는 것은 증상과 질병에 관한 문맥적 정보를 파악하는데 정신 장애를 위한 탐지에 부정확한 결과를 초래할 수 있다. 예를 들면 다음과 같다.

  1. I feel sad because I failed my exam yesterday.
  2. I have been feeling sad for a month

여기서 증상 기반의 모델들은 두 포스트 둘 다 정신장애로 분류한다.  증상 기반의 모델은 단순히 기간보다 단어와 관련해서 파악하기 때문에 부정확한 탐지가 많이 나오게 된다. 

이러한 한계를 파악하고 논문에서는 CURE(Context- and Uncertainty-aware Mental DisoRder DEtection) 방식을 소해한다. 이 방식은 정신 장애를 탐지하는 새로운 방식이다. 

  • 증상의 가능성이나 존재 및 문맥적 정보를 사용
  • 증상 정의로부터 잠재적 불확실성을 줄임

여기서 제시된 모델은 자연어 이해 능력이 뛰어난 LLM을 이용해 사전 정의된 상황에 대한 요소들을 효과적으로 추출한다. 특히, 정신과 의사의 지침에 따라서 5가지 sub-models과 불확실성 인식 의사 결정 융합 네트워크로 구성되어 있는 모델이다. 이를 통해 특정 게시물에서 증상이 거의 포착되지 않더라도 정신 장애를 정확하게 탐지할 수 있다.

Dataset Construction

여기서 모델의 평가를 위한 데이터셋을 생성하였다. KoMOS(a novel Korean Mental health dataset with Mental disOrder and Sympotms)데이터셋이다.

Data Collection

데이터는 한국인들에게 친숙한 네이버 지식인에서부터 데이터 모았다. 데이터는 네이버 지식인에서 정신 건강 카테고리에서 2008년 ~ 2021년 9월까지의 업로드된 데이터로부터 검증된 정신과 의사가 대답한 포스트를 모았다. 모든 데이터는 수동으로 필터링을 진행했다. 공인 정신과 의사가 정보 부족으로 인해 정신 장애 결정을 보류하지 않는 쌍을 걸러내어 약 8,000개의 Q&A 데이터셋을 확보했다. 

Data Annotation

Disorder Labeling 

게시물에 장애 라벨을 할당하기 위해, 우리는 먼저 인증된 정신과 의사가 작성한 Q&A 쌍의 답변에서 장애 결정 내용을 추출했다. 그런 다음 데이터셋에서 네 가지 주요 장애를 가진 게시물을 선택했다: (i) 우울 장애, (ii) 불안 장애, (iii) 수면 장애, (iv) 섭식 장애. 전문가가 기술된 상태나 신체 반응이 즉각적인 스트레스에 의해 유발되거나 일반적인 상태와 크게 다르지 않다고 명시적으로 언급한 게시물들을 '비질환'으로 라벨링 했다. 선택된 게시물의 총 수는 6,349개다.

Symptom Labeling & Validation

장애 라벨링과 달리, 우리는 증상이 답변에 명시적으로 나타날 가능성이 낮기 때문에 증상을 주석 처리하기 위한 새로운 프로세스를 설계했다. 정신과 의사가 목록을 정제하여 총 28개의 증상 라벨을 도출하여 라벨링을 진행했다. 특히 여기서 두 명의 추가 정신과 의사를 통해 데이터를 검증했다. 

증상 28가지에 대한 것들

Model Construction

CURE Architecture

모델은 크게 3가지 주요 파트로 구성된다.

  • Feature Extraction : 유저의 포스트로부터 증상과 문맥적 정보를 포함한 필요 정보를 추출
  • Model Prediction : 다양한 특징들로 훈련된 서브 모델들을 이용한 예측
  • Uncertainty-aware Decision Fusion :  : SNGP를 이용한 예측의 불확실성 예측 및 정형화된 불확실성과 예측을 합친 최종 예측 생성

밑에서 이에 대해서 자세하게 설명하려고 한다. 

Feature Extraction

각 게시물에는 증상의 지속 시간이나 빈도와 같은 관련 콘텍스트 정보가 기본적으로 포함되어 있으므로 인코딩된 게시물의 임베딩을 컨텍스트 정보로 활용할 수 있다. 하지만 이러한 방식은 키워드에 의존할 확률이 높아서 여기에서는 게시물에서 각 증상에 대한 상황 정보를 추출하는 것이 목표다.

그래서 여기에서는 8가지 context factor을 정의한다. Cause, Frequency, Duration, Age, and four types of Affects - Social, Academic, Occupational, and Life-threatening. 여기서 2가지 방식으로 정보를 추출한다.

 

  • 카테고리(Category): 정의된 기준에 따라 분류된 숫자 값으로 표현됩니다. 예를 들어, 증상이 한 달 미만이면 0, 한 달 이상이면 1로 표시.
  • 증거(Evidence): 텍스트에서 맥락에 대한 직접적인 표현을 추출. 예를 들어, "2년 동안"과 같은 표.

여러 수식이 나오는데 정리하면 다음과 같다.

  • 맥락 카테고리($C_i$) : 정의된 기준에 따라 분류된 맥락 요인
  • 숫자 값($n_i$) : 맥락 카테고리에 해당하는 숫자 값
  • 맥락 증거($e_i$) 텍스트에서 직접 추출한 맥락에 대한 표현
  • 숫자 값 벡터 ($N$) : 모든 $n_i$ 값들의 연결
  • 증거 벡터 ($E$) : 모든 $e_i$값들의 연결
  • 증상 ($S$) : LLM을 통해 추출한 사용자 게시물의 증상

맥락 요인 $C_i = {c_1,...,c_s}$는 다음과 같이 추출된다.

 

여기서 $n_i$는 맥락 카테고리에 대한 숫자 값을 나타내며, $N = \{n_1,...,n_s\}$는 이 값들의 연결이다. 마찬가지로, $e_i$는 맥락 증거를 나타내며, $ E = \{e_1,...,e_s\}$는 이 증거들의 연결된 벡터이다.

 

 

Model Predictions

증상과 맥락 정보를 모두 고려하는 직관적인 접근법은 이를 입력 특징으로 사용하여 모델을 훈련하는 것이지만, 본질적으로 다른 성질의 특징을 결합하면 서로 간섭하여 최적 이하의 성능을 초래할 수 있기에 여러가지 서브모델을 구성하여 따로 학습을 시켜 여러가지 특성을 활용한다. 

  • BERT_post: 게시물 내용 $p$만을 활용한다.
  • BERT_context: 맥락 증거 $E$만을 사용하며, LLM에서 추출한 증상과 함께 사용한다.
  • Symp_symptom: 증상 벡터 $S$만을 활용한다.
  • Symp_context: 증상과 맥락 카테고리 두 벡터 $\{S;N\}$를 연결하여 입력으로 고려한다.
  • GPT-4o: 사용자의 게시물 $p$를 입력으로 활용한다.

우리는 정의된 특징에 따라 각 모델을 훈련하고, 이러한 모델들로부터 예측 결과 $D={d_1,…,d_5}$를 얻는다.

 

Uncertainty-Aware Decision Fusion

서브 모델들의 예측을 융합하여 최종 의사 결정을 하기 위해, 우리는 불확실성 인식 의사 결정 융합 네트워크를 도입합니다. 이를 위해 먼저 각 예측의 불확실성을 정량화한다. 불확실성은 모델 예측의 신뢰도를 반영하므로, 최종 의사 결정 과정에서 불확실성이 높은 모델들의 영향은 감소되어야 한다. 이 접근 방식은 증상 식별에서 오류를 방지하여 견고한 결정을 내리는 데 도움이 된다. 증상 식별을 위한 모델인 BERT_symp의 불확실성을 추정하며, 그 불확실성은 예측된 증상에 대한 신뢰도를 반영하며 불확실성은 $U$로 표시한다.

 

우리는 추정된 불확실성 $와 서브 모델들의 모든 예측 $D$를 융합하여 최종 결정을 한다. 그 후, 데이터는 모든 서브 모델들의 예측을 그들의 불확실성 값과 함께 융합하는 MLP 계층을 통과한다. 식은 다음과 같다. 

$ H = \sigma(W_1 \cdot \text{CONCAT}(U, D) + b_1) $

$ \hat{y} = \text{sigmoid}(W_3 \cdot \sigma(W_2 \cdot H + b_2) + b_3) $

 

Experiments

Setup

  • Dataset split : 8 : 2
  • Model : BERT, Symp
  • Learning Rate : 0.003
  • Batch size : 64
  • optimizer : AdamW
  • Metric : Recall, F1 Score

Evaluation on Feature Extraction

Cause를 제외한 나머지 부분에서 약 93%의 정확도를 나타냈다.

 

Evaluation on metal Disorder Detection

Overall Performance

Table 1을 통해 알 수 있는 점은 크게 4가지이다.

  • 제안된 방법의 성능 :제안된 방법은 가장 높은 F1 점수를 기록했으며, 모든 카테고리에서 높은 재현율(Recall)을 유지하여 기준 모델들을 능가함.
  • 단일 특징을 사용하는 모델의 한계 : 단일 특징을 사용하는 모델은 질병 예측에서 높은 민감도를 보였으나, 질병과 비질병 사례를 구분하는 데 어려움을 겪어 비질병 카테고리에서 낮은 성능을 보임.
  • PsyEx의 강점 : 증상과 게시물 특징을 모두 활용하는 PsyEx는 풍부한 정보를 기반으로 비질병 사례를 잘 탐지하는 강점을 보임.
  • PsyEx의 한계 : PsyEx는 특히 우울 장애와 수면 장애와 같은 질병 탐지에서 제한적인 성능을 보임.

 

Performance on LLMs

  • LLM의 과잉 진단 경향 :LLM은 정신 장애 탐지에서 질병 카테고리에서는 높은 성능을 보였지만, 비질병 사례에서는 낮은 성능을 보이며 과잉 진단 경향을 나타냄.
  • 정확한 진단 능력 부족 :LLM은 정신 장애와 관련된 정보를 식별할 수 있지만, 정확한 진단 결정을 내리는 데 필요한 전문성이 부족함.
  • MentalLLaMA의 낮은 성능 :정신 건강 데이터셋에 최적화된 MentalLLaMA는 다른 GPT 기반 모델들에 비해 성능이 현저히 낮았음.
  • LLM 활용의 한계 : LLM은 정신 건강 관련 정보 탐지에는 유용하지만, 비질병과 질병을 명확히 구분하는 데 한계가 있음.

Ablation Study

 

  • 구성 요소 제거 시 성능 저하 :각 구성 요소가 제거되었을 때 성능이 저하되었으며, 특히 모든 카테고리에서 재현율(Recall)에 큰 영향을 미침.
  • 맥락 정보의 중요성 : 맥락 정보는 질병과 비질병 사례를 정확하게 식별하는 데 중요한 역할을 함.
  • 불확실성 활용의 효과 :최종 의사 결정 과정에서 불확실성을 효과적으로 활용하면 전반적인 성능이 향상됨.

 

 

Conclusion

새로운 접근법 제안 본 연구에서는 정신 장애 탐지를 위한 새로운 접근법을 제안했으며, 맥락 정보를 활용해 더 정확한 탐지를 수행하고, 불확실성 인식 의사 결정 융합 네트워크를 사용해 오류를 줄였다. KoMOS 데이터셋 개발 한국 최초의 정신 건강 데이터셋인 KoMOS를 개발했으며, 이는 인증된 연구자들에게 공개될 예정이다.

 

 

 

 

728x90

캡스톤디자인 팀은 3명으로 구성했다.

  • FrontEnd
  • BackEnd
  • AI

총 3명이서 각각의 파트를 정해서 팀원을 구성했다. 보통 4명을 많이 하는데 3명을 한 이유는 각자의 파트가 겹치는 것을 염려해서이다. 파트가 겹치게 된다면 누군가는 도움을 주고 누군가는 도움을 받는 일이 무조건적으로 생길 수 밖에 없다. 그렇게 되면 결국 누군가는 업혀가게 되면서 좋지 않을 수 있기 때문에 각각 파트는 1명이 담당하는 식으로 진행했다.

우리학교의 캡스톤디자인은 총 1년과정이다. 캡스톤디자인 (1), 캡스톤디자인 (2) 2개 학기로 구성되어있고 캡스톤 디자인 (1)은 3학년 2학기에 듣게 되고 캡스톤 디자인 (2)은 4학년 1학기에 진행한다. 요약하면 다음과 같다.

캡스톤 디자인 (1)
9월 ~ 10월
팀빌딩 및 아이디어 제시
11월 ~ 12월
아이디어 구체화
캡스톤 디자인 (2)
익년 2월
아이디어 구체화
3월 ~ 4월
프로토타입 시연
5월
졸업작품 발표회

위 사진은 사전신청을 하는 방법이다.이러한 방법이 있었지만, 우리는 수강신청에 자신이 있어서 수강신청에서 승부를 보기로 했다.

캡스톤 디자인 (1)

많이 적고 싶은데 기록이 남아있는게 없어서 글로만 작성했어요..

9월에 같은 교수님을 수강신청을 해야하는데 두명은 신청을 못하고 한명만 제대로 신청해서 이걸 어떻게 해야하나 고민했다. 위의 사전 수강 신청을 했어야 했는데... 그걸 못했다. 그래서 일단 정정기간에 다른 사람과 바꾸기로 했다. 하지만 어찌저찌해서 파토가 나고 과사에 가서 수강신청인원을 늘려달라고 부탁을 했고 다행히 해결되었다.

첫번째 아이디어

처음에는 팀원중 한명이 등산을 좋아해서 등산로 추천하는 앱을 만들어보자고 했다. 그래서 나쁘지 않은 생각에 많이 찾아봤다.

이러한 데이터를 찾아봤는데 도저히 AI를 쓸 수 없지만 어떻게든 우겨넣었다. 그리고 중간 발표 시간에 아이디어에 대해서 AI 사용 방법을 발표했다.

간단히 말하면 사용자의 신체정보로 등급을 나눠 등산로 추천하는 것이다. 여기서 인고지능은 MLP(Multi Layer Perceptron)을 사용해서 분류하려고 했다. 근데 교수님의 인공지능에 대해 의문을 품고 그거셍 대해 설명했지만, 교수님의 인공지능 강의 30분을 들었다... ( 근데 지금 내가 다시봐도 그 MLP 아이디어는 진짜 쓸데없어 보이긴 하더라)

일단 여기서 팀원끼리 회의를 해서 아이디어를 엎고 다시 시작했다. 그래서 나온게 음성인식을 이용해 자동주문할 수 있는 맥도날드 키오스크를 만드기로 했다.

간단히 설명하면 이렇다. 음성을 텍스트로 변환 -> 텍스트로 자연어 처리 -> 키오스크에 장바구니 담도록 하였다.

그래서 훈련시키는 인공지능에 대해 고민을 했다. 음성인식은 도저히 내가 할 방법을 몰라서 Google Chrome STT(Speech-to-Text) Model API를 사용하기로 했다. (무료에다가 성능은 상당히 좋아서 사용했다.) 그리고 자연어 처리 모델은 오픈소스로 공개되어있는 모델을 사용했다. 훈련 데이터는 GPT를 이용해서 생성했다.

GPT로 생성한 Text

이런식으로 해서 음성에 따라서 출력하기로 했다. 근데 모델이 상당히 이상하게 출력했다. 그리고 구체적인 사이드 옵션에 대해서는 출력을 이상하게 하는 문제가 생겼다. 그래서 이 문제를 해결하기 위해서 다양한 방법을 시도했지만, 잘 해결되지 않았다. 그래서 사이드 메뉴를 빼기로 하고 맥도날드에서 카페메뉴로 변경하기로 했다. (혹시나 싶은 저작권 이슈)

발표 PPT 내용 중 하나의 슬라이드

다음과 같은 문제로 메뉴의 종류가 너무 늘어난다. 진짜 골치아파서 바꾸기로 마음먹었다.

 

왼쪽은 변경 전, 오른쪽은 변경 후

맥도날드에서 카페 메뉴로 변경했다. 이미지는 모두 DALL E를 이용해서 만들었다. 그리고 방학동안에는 계속 개발을 진행했다.

캡스톤 디자인 (2)

개발을 진행하면서 느낀 것이 있다면 우리 키오스크가 너무 밋밋하다는 것이다. 그래서 영수증을 뽑을 수 있는 영수증 기계를 학교 재료비로 주문해서 만들면 좋겠다고 생각했다.

요로코롬 생긴 영수증 기계를 학교 재료비로 사서 우리 키오스크와 연동하기로 했다. 이것은 회사 프로그램에서 JAVA로 제공해주기 때문에 백엔드에게 연동을 부탁했다.

진짜 처음에 연동시키고 영수증 나오는데 전율이 돋았다. 그리고 나서 계속 연동을 진행하고 개발했다.

(개발 얘기 중략)

캡스톤디자인은 이번에 구술발표 팀은 무조건 상을 타게 된다고 해서 난 상을 타고 싶어서 발표를 진짜 열심히 준비했다.

시연을 위해서 강의실 모니터에 키오스크 화면과 시선강탈을 할 수 있는 사진도 올려놨다.

시연 영상

발표에 필요한 화면을 준비하긴 했으나, 오른쪽 부분이 주제와 관련이 없어서 제외했다. 그리고 남은 화면을 활용해 시연 영상을 제작했다. 이렇게 발표하면 좀 더 가점을 받지 않을까라는 생각으로 했는데 어림도 없었다.

난 C-10 이었다.

처음에 이런식으로 발표가 나왔는데, 나는 될 줄 알았는데 되지 않았다. 아무래도 우리팀에 쟁쟁한 팀원이 많았던 것 같다.

졸업작품 발표회

시연을 진행하려고 준비중인 내 모습이다. 앞에 아이패드는 키오스크 화면을 띄우려고 하고 있다.

시연을 진행하면서 정말 영수증 종이가 많이 생겼다. 많은 분들이 와주셔서 정말 보람찼다. 시상식을 진행하는데 우리가 장려상을 탔다.

생각보다 많이 주기는 했지만 못탄팀도 있으니 그래도 노력을 알아주는거 같아서 뿌듯했다.

캡스톤이 끝나고 다같이 회식을 하면서 마무리했다.

캡스톤이 끝나니까 정말 수능이 끝난 기분이다. 홀가분하지만 허전했던 그런 기분이다. 아무래도 졸업에 한 발자국 다가간것 같다.

캡스톤 끝!

728x90

오늘은 학교 교내에서 진행했던, 해커톤인 Lucky-thon에 대해 후기에 대해 작성하려고 한다.

일단 결론부터 말하자면, 대상을 탔다. 근데 정말로 대상을 탈 줄 몰랐기 때문에 더욱 놀랐던 거 같다. 이와 관련해서 무슨 일이 있었는지 처음에 팀 구성부터 시작해서 어떻게 하게 되었는지 자세하게 얘기해 보겠다.

팀 빌딩

팀원은 3명에서 4명이 모이기로 했는데 여기서 고민을 했다.  팀원을 어떻게 구성해야 좋을까 라는 생각을 했었다. 개발 기간이 긴 편이지만, 중간고사 시험기간이 겹쳐 있었기 때문에 고민을 해본다면 '개발 기간을 어느 정도로 가져가야 할 것인가'다. 일단, 당장 나는 시험을 보지는 않지만, 다른 프로젝트를 진행하고 있는 상황이어서 시간을 많이 쏟기는 어려울 거라고 생각했다. 그래서 시간을 많이 쏟지 않으며 프로그램을 어느 정도 만들 줄 아는 사람들로 구성해야겠다고 생각해서 당장 생각나는 2명을 구했다.

  • A : 발표 및 기획을 잘하는 팀원
    • 이 친구는 개발에 대해서 어느 정도 알고 있지만 발표실력이 매우 좋아서 같이 하자고 했다. 사실 해커톤은 프로그램의 완성도보다는 프로그램을 만들게 된 이유, 비즈니스 모델(수익화), 지속가능성 등등을 잘 설명해야 하며, 심사위원의 질문에 능숙하게 대처해야하기 때문에 이 친구를 섭외하게 되었다.
  • B : 웹 개발을 잘하는 팀원
    • 이 친구는 웹 개발은 잘하고 있다. 그리고 시키는 것은 매우 잘 해내기 때문에 데려오게 되었다. 개발 디자인 하는 것도 좋아하며, 특히 짧은 시간 내에 간단한 웹사이트 구현 및 배포를 다 할 줄 안다고 생각하기에 섭외하게 되었다.

여기까지 2명을 구했고 나머지 1명이 고민이었다. 개발에서 중요한 4가지 중에 3가지를 완료했다. AI(나), 기획 및 발표(A), 프론트(B)와 백엔드다. 여기서 나는 백엔드를 해보고 싶어서 여기서 3명 + 개발에 대해 배워보고 싶은 사람 한 명이 있다고 해서 그 사람을 데려오려고 했다. 하지만 그 친구는 연구실 + 졸업작품 + 학생회 생활로 도저히 시간이 낼 수 없어서 한 명을 고민하고 있었다. 그러다가 그냥 백엔드는 잘하는 사람 데려오자라고 결론이 났다. 그래서 백엔드를 잘하는 친구(C)를 데려왓다.

  • C : 백엔드 개발을 잘하는 팀원
    • 그냥 잘함.

그렇게 팀원 4명(나, A, B, C)가 빌딩이 되었다. 여기서 팀원 4명은 모두 4학년이다. 이 대회가 1학년 ~ 4학년 모두 참가할 수 있는 대회인데, 4명 학년합이 16이니까 진짜 무조건 상을 타야했을 것이다. 왜냐하면, 그래도 4학년 4명인데... 

팀 이름은 최대한 단순하게 지었다. 나(한화 팬), A(LG 팬), B(SSG 팬) 이렇게 있고 C는 야구를 잘 안보기 때문에 다음과 같이 팀 이름을 짓게 되었다.

 

아이디어 빌딩

주제가 나오고 나서 개발을 시작하기로 했다. 주제는 '어울림'이었다.

첫 번째 아이디어

처음에 팀명이 '야구 좀 그만봐' 였기에 야구 + 어울림을 생각해서 야구팬들의 어울림을 고민했다. 하지만, 럭키톤을 진행하는 날짜는 이미 야구 시즌이 끝난 시기였기에 사람들의 이목을 받지는 못 할 것이라고 판단되어 접었다.

 

두 번째 아이디어

프로그램 초안

쿠팡 와우 공구 시스템이었다. 간단하게 말하면, 쿠팡와우 멤버십을 빌려줘 공구를 통해 수수료를 챙기는 시스템을 생각했다. 여기서 기숙사 생들의 어울림을 이끌어 내는 것이 었다. 하지만, 해커톤에 참가하는 사람들은 기숙사생이 적었을 것이며, 심사위원들은 이미 직장인이므로 이거 역시 사람들의 이목을 이끌어내지 못 할 것이라고 판단되어 아이디어를 다시 생각하게 되었다. 

 

세 번째 아이디어

아이디어 제시
아이디어 초안

 

유학생 매칭 프로그램을 만들면 좋을 것 같다는 생각이 들어서 이것을 만들게 되었다. 우리학교는 졸업요건에 토익 또는 그 외 다양한 언어 점수를 필요로 하므로 이 프로그램이 괜찮을 것이라고 판단했다. 현재 학교에서 진행하는 유학생 프로그램은 매칭 시스템이라기보다는 지정 시스템이므로 원하는 않는 외국사람이 걸릴 수 있고 생활패턴, 동성과 이성 등등 문제점이 많을 것이라고 판단하여 이 아이디어는 많은 이목을 끌 수 있을 것이라고 생각하여 개발하게 되었다.

 

개발

파트는 한 번 더 설명하면 다음과 같다.

  • 나 : AI (Chat GPT-4o)
  • A : 기획(피그마) 및 발표
  • B : 프론트엔드(웹) (React)
  • C : 백엔드 (Javaspring)

이 부분에서 다른 파트의 기술 스택에 대해 문외한이라서 그냥 보기만 했으며, 나는 내 ChatGPT를 이용하여 배포를 진행했으며, 이에 대해서만 얘기 해보려고 한다.

나는 배포를 FastAPI를 이용하여  API를 만들고 AWS를 통해 배포를 했다. 이에 대해 관심은 없을 테니 GPT 프롬프트 작성에 대해서만 간단하게 얘기해보려고 한다. 

sys_prompt = 
"""
지금부터 너는 번역기야

1. 입력된 텍스트의 언어를 자동으로 탐지합니다.
2. 입력된 텍스트가 불쾌함을 유발하는 텍스트인 경우 False 를 출력합니다.
3. 입력된 텍스트와 번역 목표 언어가 동일하거면 None 을 출력합니다.
4. 입력된 텍스트와 번역 목표 언어가 다를 경우, 해당 텍스트를 목표 언어로 번역합니다.
5. 입력 텍스트와 번역 결과는 최대한 자연스럽게 변환되어야 합니다.
6. 번역 과정에서는 문법 및 어투를 적절히 유지하며, 입력된 문장의 의미가 왜곡되지 않도록 주의합니다.

예시는 다음과 같다.
번역 예시 1
입력된 문장: {안녕하세요}
목표 언어: {kr}
결과: None

번역 예시 2
입력된 문장 : hello
목표 언어: {CN}
결과: 你好
"""

usr_prompt =
"""
입력이 주어지면, 예시를 참고해서 결과만 출력해줘
입력된 문장 : {text}
목표 언어 : {target_language}
결과 :
"""

여기서 여러가지 프롬프트 기법이 사용되었으며 명칭과 어떻게 사용하는지에 대해 설명하려고 한다. 

  1. 역할 부여 : GPT에게 번역기라고 역할을 부여한다.
  2. 예시 제공 : 번역 예시를 제공하여 응답하는 방법에 대해 추론하도록 한다.
  3. 포멧팅 : 원하는 방식으로 출력하도록 지시한다.
  4. 단계별로 행동하도록 지시 : 번호를 매겨 단계별로 실행하는 지침에 대해 수행한다.

다음과 같이 GPT를 이용한 ChatBot을 만들었다. 이를 통해서 내 AI파트는 끝났다. 코드에 대해서 궁금하다면 여기를 눌러 참고하기 바란다.

 

발표

발표는 총 2번에 걸쳐서 진행된다. 1차 발표는 2분만에 발표를 끝내야 하므로 최대한 압축해야한다. 그리고 2차 발표는 7분 동안 진행하므로 1차에서 발표했던 내용 + 디테일한 내용에 대해서 발표한다. 그래서 우리는 미리 7분짜리 PPT를 만들고 여기서 가장 핵심적인 부분을 추려서 2분짜리 PPT를 만들기로 했다. 

발표와 관련하여 멘토링 받고 있는 모습

발표시간대는 사진에 보는 것과 같이 05시와 09시다. (참고로 밤을 새웠다.) 1차 발표 평가는 상호평가, 2차 발표는 심사위원 평가이다. 근데 여기서 중요하게 알아야 할 점은 밤을 새웠다는 것이므로 절대 지루하게 해서는 안된다. 새벽 5시는 피곤에 쩔어있는 시간대이므로 무조건 관심을 끌어야 한다는 것을 알고 있었다. 그래서 언어 유희와 애드립을 넣었다. 

최대한 간결하게 인트로를 시작했다. 덕분에 사람들의 이목을 끌 수 있었다. 

2분 안에 EVEN하게 1차 발표

근데 진짜 멘트는 기가막힌다. 

 

수상

다들 일정이 있어서 시상식은 나만 참가하게 되어서 혼자 수상을 했고 사진을 보내줬더니 격렬하게 반응하는 팀원들의 모습이다. 이후에 같이 모여서 사진을 찍고 마무리했다.

누가 누군지 너무 잘 보이긴 하네

정보대 학생회분들 덕분에 좋은 경험을 할 수 있어서 감사했습니다. 단대장 류씨를 포함해 모두 감사합니다.

 

 

728x90

멋쟁이 사자처럼에서 해커톤을 하면서 경험했던 것들에 대해 적어보려고 한다.

시작은 생각보다 우여곡절이 많았다. 처음에는 아이디어톤을 했었던 분들과 같이하고 싶었지만, 확답을 주는 것이 어려웠다. 대학교 석사를 위해 학회를 준비하고 있었다. 그 학회가 대회 해커톤과 일정이 겹치는 바람에 학회 일정이 취소되고 나서 확답을 줄 수 있었다.

 

두 행사의 일정이 겹친다.

학회 참가 어렵다는 메일

학회 참가가 어려워서 해커톤에 참여하기로 결정했다. 하지만, 이 결정을 내리는 당시에는 아이디어톤 인원들이 이미 팀 구성이 끝난 상황이어서 팀을 구하기가 어려웠다. 그래서 이건 안되겠다고 생각해서 멋사 MT 때, 같이 할 사람을 모집했다. 여기서도 어려웠던 것이 이미 팀이 있었고, AI를 사용할 일이 없다고 했던 것이다. (여기서 나는 백엔드를 다룰 줄 모르며, AI만 다룰 수 있었다.) 그래서 어쩔 수 없이 또 다른 사람(A)을 알아보게 되었고 여기는 해커톤 참여는 하지만 뚜렷한 열정없이 간단하게 참여에 의의를 두는 팀이었다. 그러다가 또 다른 사람(B)이 팀을 하자고 해서 여기에 참여하기로 했다. 이 팀은 개발에 목표의식이 뚜렷한 팀이기에 서로에게 도움이 될 것이라고 생각했다.

요약

  1. 아이디어톤 팀과 하려했지만 무산
  2. MT때 같이하려고 했던 분과 하려했지만 AI가 필요없는 프로그램 만들기에 무산
  3. A가 같이하자해서 팀을 구하려 했지만, 목적이 달라서 무산
  4. 목적이 맞는 팀을 구함

3번 정도 우여곡절이 있었고 다행히 팀원을 구할 수 있었다. (없으면 무엇을 했을까 싶긴 하다)

그렇게 팀 구성 이후 회의를 통해서 감정일기 다이어리를 만들기로 했다. 프로그램은 간단하다.

  1. 일기 작성
  2. 일기 내용에 대해 챗봇을 이용한 공감으로 감정 위로
  3. 일기 내용에 따른 그림일기 작성

이 정도였으며,나는 여기에 대해 AI part를 구현하면 되었다. 당장 봇을 만들기는 데이터 이슈르 인해서 우리만의 봇을 만들 수는 없었기에 GPT-4Prompt Engineering을 통

해서 구성을 했다. 그림일기는 DALL-E 3을 이용해서 구현했다.

기술얘기는 여기서 마무리 짓자.

양재 AT센터에 도착해서 먼저 명찰을 받았다.

서람이 많아서 그런지 코팅되어있는 것을 받았으면 좋았을 텐데라는 생각이 든다.

 

학교 명찰 바로 앞에 앉았다. 그리고 사람이 진짜 많았는데 정말 압도적이었다는 생각이 들었다. 약 1,500명이 프로그램을 만들고 있으니 진짜 신기했다.

 

팀원분들과 사진도 찍었다.

각자 인사이드 아웃 캐릭터를 모티브로 해서 캐릭터를 만들었다. 우하단 파란색 캐릭터가 나다. 뭔가 그냥 신기하다.

열심히 코딩하는 모습

행사 참여하고 열심히 코딩다.

중간에 야식도 먹을 수 있었다. 레드콤보로 허니콤보를 시켰는데, 내가 맵찔이라 레드콤보는 일절 입도 안댔고 허니콤보 열심히 먹었다.

프로그램을 만들고 전시도 했다.

전시를 해놓고 슬리퍼 이벤트를 진행한다고 하길래 열심히 참여했는데 커트라인은 10,000보 이상부터여서 아쉽게도 이벤트 당첨에 실패했다.. 슬리퍼 공짜로 받을 수 있었는데 너무 아쉽다.

마지막으로 아침 7시에 끝내고 곰탕을 먹고 마무리했다 상당히 피곤하다. 집에와서 뻗었다. 진짜 열정적으로 했던 하루다.

2024 INU CODE FESTIVAL

Giliit
|2024. 11. 10. 13:02
728x90

생애 첫 상품을 타게 되었던 대회인 2024 INU CODE FESTIVAL 참가 후기에 대해 소개하려고 한다.

위 대회에 참가 권유가 와서 참가를 고민했었다. 참가를 고민한 이유는 8월 중순부터 알고리즘 스터디 운영을 중단하면서 백준, 프로그래머스와 같은 관련 문제들을 일절 손에 대고 있지 않았기 때문이다. 그래서 내가 참가하더라도 상을 못할 것 같아서 일부러 참여하지 않았다. 그런데 이민규씨가 그냥 간단하게 링크하나만 보냈다.(참가하라는 암묵적 의미..)

그래서 어차피 불참해도 내년에 참가는 안할거니까 일단 그냥 신청만 했었다. 그리고 정말 아무것도 준비하지 않았다.

2023, 2024년 문제 풀었던 통계

9월 30일에 있는 것은 대회 이후에 한 것이므로 다시말하면 백준은 2월부터 풀고 있지 않아서 자신감은 정말 바닥에 바닥이었다.

대회 시작은 11시인데 한화 최종전 티켓팅도 11시이다. 그래서 어쩔 수 없이 운영진 분들께 양해를 구하고 티켓팅 후 문제 풀이를 시작하려고 했다. 근데 사이트에 미리 들어가 있는데 렉이 걸렸다. 시간이 조금 지나고 확인해보니 이미 티켓팅이 망한 냄새가 올라왔다.

10시 59분 대기열

그래서 시원하게 망하고 운영진분들께 대회 바로 진행할 수 있다고 말씀드리고 대회를 진행했다.

닉네임은 싱고로 진행했다.

180분 후

대회 중간 5등이라는 성적이 신기해서 캡처했다.

최종 성적

7등을 해서 턱걸이로 은상을 받았다.( 1등 대상, 2~3등 금상, 4~7등 은상, 8~17등 동상)

그리고 문제수도 비슷했는데 빨리 푼 덕분에 은상을 탈 수 있었다.

코테관련 대회에서 처음으로 상을 타봐서 너무 신기했다.

약 13~14만원 짜리 키보드를 받게 되어서 기분이 좋았다. 근데 지금은 당근에 팔고 싶은데 어떻게 할까 고민중이다.

728x90
논문링크
https://arxiv.org/pdf/2406.14952

 

 

 

Introduction

최근에 매우 빠른 LLM의 개발과 함께 LLM과의 대화가 매우 많이 늘어나고 있다. 다양한 대화 애플리케이션에도 불구하고, Emotional Support Conversation(ESC)는 매우 유망한 곳이다.여기서는 사람들이 쉽게 자신의 경험과 우려를 공유하고 감정적 위로를 받는다. 최근에 LLM 기반의 Coneversation이 증가하고 있지만, 포괄적인 평가는 매우 어렵다.

현재 ESC 평가는 2가지 방식으로 평가하고 있다.

  평가 방식 장점 단점 예시
text-based statistical metric 자동 가격, 시간 효율적 텍스트의 의미가 아닌 텍스트의 유사도 평가 BLEU, ROUGE
manual evaluation 수동 의미에 대한 파악이 확실 가격, 시간 비효율적
평가가 단조로움(특정 주제에 대해서만 대화)
사람과 AI의 대화

두 가지의 평가 방식에 대해 해결하기 위해 논문에서는 ESC-Eval Framework를 제안한다. Figure 1 에서 오른쪽을 보면 된다. 여기서 LLM에게 인간의 평가 방식을 입혀 효율적인 평가 방식을 입힌다. 이를 통해 전통적인 평가방식을 대체할 수 있을 것으로 보고있다. 여기서 제시하는 Framework를 보장하기 위해 2가지 요소가 중요하다.

  • 다양한 사례에서 문제를 겪는 사람들에게로 수집한 role card, 평가 중 LLM 역할 수행을 하고 평가를 보장한다.
  • 실제 사람의 행동을 반영하는 Chatbot으로, 실제 사람의 대화를 반영하여 객관성과 공정성을 보장한다.

2가지 요소를  달성하기 위해 2가지 방식을 취했다.

  1. 7개의 데이터셋으로부터 GPT-4를 이용하여 role card를 추출한다. 추출시 GPT4와 사람 판단을 포함하여 필터링을 하여 2,801개의 role card를 획득하였다.
  2. Chatbot 구축을 위해 ESC-Eval을 위한 Chatbot을 개발한다. Qwen1.5를 fine-tuning하여 ESC-Role이라는 역할을 수행한다. 특히 이 모델은 GPT-4 보다 사람보다 유사하게 행동한다.

 

About ESC-Eval

ESC-Eval은 역할 수행 모델과 역할 카드를 활용하여 평가 중인 ESC 모델과 상호작용하고, 획득한 대화 데이터를 수동으로 주석 처리한다. 다양한 역할 카드와 신뢰할 수 있는 역할 수행 에이전트의 존재가 매우 중요하기에 이후 섹션에서는 이러한 두 가지 주요 요소의 신뢰성을 보장하기 위해 한 일에 대해 설명한다

세 개의 계층적 레이어와 37개의 카테고리로 구성된 분류 시스템을 먼저 구축한다. 그런 다음, 공개 데이터에서 역할 카드를 재구성하고 각 카테고리 내에서 역할 카드를 식별하는 방법을 사용한다. 3가지 단계로 구성된다.

Role Card Acquisition

  1. 오픈 데이터셋 수집
  2. GPT-4를 이용하여 역할을 추출한 뒤, 저품질 데이터를 필터링
  3. 수동 annotation Process를 통해 High, Middle를 나눈다. 그리고 그에 대한 내용은 Table 9에 나타나있다.

ESC-Role

ESC 시나리오에 특화된 역할 수행 에이전트인 ESC-Role을 구축하기 위해, 일반 데이터와 ESC 데이터셋을 사용하여 모델을 훈련한다. ESC-Role은 인간처럼 행동하는 대화 모델을 목표로 한다.

데이터 수집 :Smile, ESConv, ExTES 데이터셋을 포함한 여러 ESC 시나리오 데이터에서 3,390개의 역할 수행 데이터를 수집했다. 추가적으로 Huggingface에서 제공하는 다중 회차 대화 데이터셋을 활용하여, ESC 및 일반 역할 수행 데이터를 포함한 총 14K의 데이터를 확보했다.

구현 및 평가 지표 :ESC-Role의 기본 모델로 Qwen1.5-14BChat을 선택하고, LoRA를 이용해 파라미터 효율적으로 미세 조정했다. 평가 지표로는 유창성, 일관성, 주제 일치, 감정 일치, 인간 유사성 등 6가지 기준을 설정하고, 수동 평가와 쌍별 비교 평가를 통해 모델의 성능을 측정한다.

평가 결과 : ESC-Role은 GPT-4와 Baichuan-NPC보다 ESC의 도메인 특화 지표에서 더 인간다운 성능을 보였다. 또한, 인간 평가에서는 ESC-Role의 대화가 실제 인간 대화와 구분하기 어려웠으며, GPT-4와 Baichuan-NPC보다 우수한 성과를 보였다.

Evaluation

평가에 사용된 14개의 모델은 다음과 같다.

  1. Closed-source: GPT-4, ChatGPT
  2. Open-source: Vicuna, llama3, WizardLM, Qwen1.5, Chatglm3, Yi
  3. Domain-specific: ExTES-llama, ChatCounselor, MindChat, SoulChat3

평가 결과

평가에 사용된 14개의 모델은 다음과 같다:

  1. 폐쇄형 모델: GPT-4, ChatGPT
  2. 오픈 소스 모델: Vicuna, llama3, WizardLM, Qwen1.5, Chatglm3, Yi
  3. 도메인 특화 모델: ExTES-llama, ChatCounselor, MindChat, SoulChat

 

 

일반 모델 성과:

  • 장점: 유창성, 표현 다양성, 정서적 위로 능력에서 높은 점수.
  • 모델: GPT-4와 ChatGPT가 정서적 위로 지식에서 우수한 성과.
  • 단점: 인간 중심적 응답에서 낮은 성과.

도메인 특화 모델 성과:

  • 미세 조정: MindChat, SoulChat, EmoLLM 등은 영어 유창성에서 부족.
  • 우수 성과 모델: ExTES-llama와 ChatCounselor가 뛰어난 성과 (실제 상담 데이터 및 ChatGPT 생성 데이터로 미세 조정).
  • EmoLLM: 방대한 데이터 훈련으로 여러 기준에서 우수.

 

상관관계 분석

목적: ESC-Eval의 효과를 검증하기 위해 ESConv 데이터셋에서 20개의 예제를 무작위로 선택하고, 5개의 모델을 상관관계 분석에 포

과정: 모델들은 도움을 요청하는 사람을 모델링한 인간 평가자와 상호작용하고, 인간 평가 점수를 기준으로 ESC-Eval과 자동 평가 방법 간의 상관관계를 분석

결과 : ESC-Eval이 유창성과 공감을 제외한 대부분의 지표에서 높은 상관관계.

  • 유창성: 자동화된 지표가 ESC-Eval보다 우수하며, 이는 일반 모델의 분절된 문장 표현이 ESConv와 상당히 다른 데 기인.
  • 공감 지표: LLM의 정렬 과정 덕분에 공감 측면에서 상관관계가 높게 나타남.
  • ESC-Eval 효과성 강조: ESC-Eval이 전체 평균 지표에서 높은 상관관계를 보여 효과성이 입증됨.

 

Conclusion

이 논문은 역할 수행 모델을 활용하여 다중 회차 대화 데이터를 수집함으로써, 대형 언어 모델(LLMs)에서의 감정 지원 대화(ESC) 효과와 지속 가능성을 평가하는 새로운 접근 방식을 제안한다.

728x90

최근에 동아리에서 구현해야 할 기술에 대해 고민을 하고 있는데 범위가 상당하다 보니 데이터를 만들어서 진행하는 것은 어렵다고 판단했다. 그래서 데이터베이스에서 가져오는 방법을 고민하고 있으며 그중에서 NAACL에 대해서 찾아보다가 알게 되어서 논문을 읽어보았다.

논문링크
https://arxiv.org/pdf/2406.12430

Introduction

현실세계에서 사업과 관련된 상황에서 결정을 하는 것은 매우 중요한 일이다. 결정을 하기 위해서는 데이터 분석을 통해 가장 적절한 결정을 해서 목표를 달성하는 것이다. 일반적으로 결정을 하는 일은 3가지 과정을 요구한다.

  1. 결정에 필요한 데이터들을 분석하여 계획을 세운다.
  2. 관련된 필수적인 데이터를 검색한다.
  3. 데이터를 기반으로하여 걸 정한다.

여기서 2번과 3번 과정을 쉽게 하기 위해, 지난 몇 십 년간 결정을 도와주는 시스템을 구축했다. 하지만, 1번 단계는 사람이 도맡아서 하고 있다. 그래서 이 논문에서는 Large Language Model(LLM)을 이용해서 end-to-end 시스템을 구축한다.

이 시스템 구축을 위해 Decision QA 데이터를 구축했다. 이 데이터는 Language Model(LM)이 의사결정을 하도록 하는 데이터셋이다. 관련 내용은 아래에 자세하게 설명하겠다.

마지막으로 (1) 번 단계를 LM이 실행할 수 있도록 하는 것이 Retrieval Augmented Generation(RAG) 방식이었는데, 이전의 방식은 단일 정보만을 가져오는 방식보다는 보다 의사결정을 잘할 수 있는 plan-then-retrieval augmented generation technique, PlanRAG 방식을 구축했다. 간단하게 설명하면 3단계로 구성된다. 

  1. the planning step : 분석을 위해 필요한 정보들을 가져오는 데이터 스키마와 질문들을 생성한다.
  2. the retrieving step : 분석을 위한 데이터를 검색
  3. the answering step : 데이터를 기반으로 하여 결정하기

이에 대해서도 아래에 자세하게 설명하려고 한다. 논문의 기여는 다음과 같다.

  • Decision QA를 위한 벤치마크인 DQA를 제안한다.
  • PlanRAG라는 새로운 검색-증강 생성 기술을 제안하며, 이는 LLM(대형 언어 모델)의 의사 결정 능력을 크게 향상할 수 있다.
  • PlanRAG가 Decision QA에서 반복적인 RAG 기술보다 훨씬 효과적이라는 것을 입증했다.

About Decision QA(DQA)

Dataset

데이터는 무역 데이터를 기반으로 작성되었다. 무역 게임은 Enropa Universalis IV와 Victoria 3을 기반으로 데이터를 만들었다. 무역게임으로 만든 이유는 현실의 데이터는 구성하기 힘들기 때문이며, 이와 비슷한 무역게임으로 구성했다.

  • $d_{best}$ : 가장 좋은 결정
  • $Q$ : 의사결정과 관련된 질문
  • $D$ : Database
  • $R$ : Business Rule

위의 데이터를 이용해서 가장 이득을 취할 수 있는 방법을 찾는 것이다.

데이터베이스 형식은 2가지로 되어있다. Labeled Property Graph(LPG)(=Graph Database, GDB)와 Relational Database(RDB)로 구성되어 있다. 

각각 301개씩 총 602개로 구성되어 있다.

Benchmark

Locating Scenario

 

  • 이 시나리오의 데이터베이스는 4개의 테이블로 구성되어 있다.
  • 트레이딩플로우와 노드국가는 간선, 트레이딩노드와 국가는 정점으로 그래프 데이터베이스로 표현할 수 있다.
  • 비즈니스 규칙에 따라 열 값이 다른 데이터와 사용자 결정으로 계산된다.
  • 사용자가 트레이딩 노드에 상인을 배치하면, 그 노드에서 해당 국가의 홈 노드로 흐름이 증가한다.
  • 주요 변수는 국가(c), 트레이딩 노드(n), 출발 노드(src), 목적지 노드(dest), 홈 노드(h)이다.
  • 목표는 ∆profit(c)를 최대화할 수 있는 트레이딩 노드를 선택하는 것이다.

Building Scenario

 

  • 이 시나리오에서 데이터베이스 D는 관계형 데이터베이스(RDB) 일 때 4개의 테이블로 구성된다.
  • Demand와 Supply는 간선, Goods와 Buildings는 정점으로 간주하여 그래프 데이터베이스(GDB)로 쉽게 표현할 수 있다.
  • 기본적인 비즈니스 규칙은 의사 결정자가 공장 건물 b를 확장하면, 해당 상품 g의 CO(g, b)가 증가한다는 것이다.
  • 주요 변수는 상품(g)과 건물(b)이다.
  • Supply 집합을 Sup, Demand 집합을 Dem으로 나타내며, T D는 총 수요, T S는 총공급을 의미한다.
  • 목표는 주어진 상품 g에 대해 CP(g)를 최소화하는 것이다.

 

 

 

About Plan-RAG

기존 RAG 기술은 데이터 분석 쿼리를 사용하여 데이터베이스 D에서 검색된 결과를 기반으로 주어진 ⟨Q, S, R⟩에 대한 최적의 결정을 도출하려고 한다. 한 번만 검색이 이루어지면 이를 단일 회차 RAG(single-turn RAG)라고 하며, 여러 번 검색이 이루어지면 반복 RAG(iterative RAG)라고 한다. PlanRAG 기술은 두 가지 유형의 추론을 사용하여 최적의 결정을 도출하려고 한다.

첫 번째는 계획 수립, 두 번째는 기존 RAG와 유사한 방식으로, 데이터 분석 쿼리를 통해 검색된 결과를 바탕으로 답변하는 것이다. PlanRAG는 계획과 재계획을 수행할 수 있는 단일 언어 모델을 사용하여, 별도의 모델을 사용하는 부작용을 줄였다. 이 모델은 ReAct(Yao et al., 2023)의 'Plan'과 'Re-plan' 지시문을 추가하여 프롬프트를 작성했다.

PlanRAG의 추론 과정은 (1) Planning, (2) Retrieving & Answering, (3) Re-planning의 단계를 포함한다.

PlanRAG 예시

Planning

LM이 입력으로 ⟨Q, S, R⟩가 주어지며 데이터 분석을 위한 초기의 계획을 생성한다. 초기 계획은 검색 절차에서 수행에 필요한 일련의 데이터들을 계획하는 것이다.

Retrieving & Answering

이전 RAG과 달리 ⟨Q, S, R⟩뿐만 아니라 초기 계획도 가치 입력된다.

Re-planning

초기에 세워진 계획이 문제 해결에 충분하지 않다고 생각이 되면 다시 계획하여 필요한 정보들을 더 가져오는 방식이다.

 

 

 

Experiments

Experimental Setup

모델들은 다음과 같다.

  • SingleRAG-LM → Single-turnLM
  • IterRAG-LM → Iterative RAG
  • PlanRG-LM → PlanRAG
  • PlanRG-LM w/o RP(Re-Planning)

모든 결정은 GPT-4로 생성되었으며 temperature = 0 그리고 LangCahin library로 구성되어 있다. 모든 실험은 0-shot으로 진행했는데 그 이유는 few-shot의 경우는 모델의 오버피팅을 야기하며, 현실에서는 예시가 주어지지 않기 때문이다.

Results & Analysis

Main Results

여기서 계획한 PlanRAG가 SOTA를 달성했으며, 표를 통한 결과는 다음과 같다.

  • Building score이 낮은 이유 : Building Scenario는 Location에 비해 더욱 긴 traversal을 요구하기 때문에 낮은 점수가 나왔다.
  • SingleRAG-LM이 낮은 이유 : 여기서 제시하는 문제들은 여러 turn을 요구하기 때문에 낮은 점수가 나왔다.
  • RP의 효과 : 다시 계획하는 것을 통해 PlanRAG-LM이 가장 좋은 점수를 달성하였다. 

 

Analysis for SR and MR

데이터의 난이도에 따라 얼마나 문제를 잘 해결하는지에 대해 탐구했다. IterRAG-LM이 문제 해결을 위해 검색을 얼마나 했는지에 따라 데이터는 2가지로 나누었다. Single Retrieval, SR : 정보 검색을 한 번만 한 것(84개). 정보 검색이 쉬운 것이며 Multiple Retrieval, MR : 정보 검색을 여러 번 한 것(518개). 정보 검색이 어려운 것이다.

  • PlanRAG-LM은 SR 질문에서 IterRAG-LM보다 훨씬 더 우수한 성능 : SR 질문들이 단일 검색으로는 해결하기 어려운 경우가 많기 때문이다.
  • IterRAG-LM은 이러한 질문들의 난이도를 과소평가하여 단일 검색만 사용하려 했지만, 실제로는 여러 번의 검색이 필요한 경우가 많았다.
  • PlanRAG-LM은 계획 단계를 통해 질문의 난이도를 더 잘 이해하고, 계획에 따라 여러 번 검색을 수행하여 정확성을 크게 향상했다. MR 질문에서도 PlanRAG-LM이 더 체계적으로 검색을 수행하여 IterRAG-LM보다 더 효과적이다.

Rate of missed data analysis

PlanRAG-LM은 IterRAG-LM보다 더 효과적인 이유를 분석하기 위해 데이터 분석 누락 비율을 측정했다. Locating에서는 IV와 T Ptotal, Building에서는 CO와 PD를 기준으로 사용했다.

  • PlanRAG-LM의 누락 비율은 1.3%와 21.8%로 낮았고, IterRAG-LM은 3.3%와 33.2%로 더 높았다. 이는 IterRAG-LM이 완벽하게 추론을 수행하더라도 정확도가 PlanRAG-LM보다 낮을 가능성이 있음을 의미한다.
  • PlanRAG-LM은 Locating에서 98.7%의 정확도를 달성할 수 있지만, 실제 정확도는 그보다 낮았으며, 이는 추론(계획 포함) 자체가 매우 도전적인 작업이기 때문이다.

Analysis for failure cases

우리는 각 실패 사례를 다섯 가지 오류 카테고리로 분류한다:

 

  • CAN: 잘못된 후보를 고려하여 질문을 해결하지 못한 경우
  • MIS: 데이터 분석 누락
  • DEEP: 검색된 데이터나 방정식을 잘못 사용한 경우
  • QUR: 쿼리 생성 오류
  • OTH: 기타 오류 (예: 토큰 길이 제한 초과)

 

PlanRAG-LM은 두 시나리오 모두에서 CAN과 MIS 오류를 크게 줄였다. 이는 PlanRAG-LM이 Decision QA 질문을 더 잘 이해하고, IterRAG-LM보다 중요한 데이터를 더 잘 쿼리 할 수 있음을 의미한다. 또한, PlanRAG-LM이 두 시나리오 모두에서 IterRAG-LM보다 약간 더 많은 DEEP 사례를 가지고 있음을 주목할 수 있다. 우리의 관찰에 따르면, DEEP 오류는 CAN 또는 MIS 오류가 없을 때만 발생한다.

 

Anylsis for re-planning

PlanRAG-LM은 Locating 시나리오보다 Building 시나리오에서 재계획을 더 자주 수행한다.  네 번 이상 재계획이 이루어진 질문의 비율은 Building에서 훨씬 높다(30개 질문, 14.85%)가 Locating에서는 7개(1.75%)에 불과하다. 이는 원래 계획이 불충분할 경우 모델이 재계획을 수행한다는 것을 의미하며, 이는 Building에서 PlanRAG-LM과 다른 기술들 간의 성능 차이가 상대적으로 적은 이유를 설명한다.  또한, 재계획 횟수가 많아질수록 재계획으로 인해 향상되는 정확도가 감소한다는 Table 7의 결과와 일치한다.

Conclusion

복잡한 의사 결정 질문에 답하는 새로운 과제인 Decision QA를 제안했다. 이를 위해 DQA라는 벤치마크를 만들었으며, 301개의 데이터베이스 세트와 질문, 정답을 사용하여 구성했다. 또한, 검색 전에 계획을 세우고 계획이 충분하지 않을 경우 재계획을 수행하는 PlanRAG라는 새로운 RAG 기술을 제안했다

 

728x90

오늘은 RAG에 대해 좀 더 진화한 Self-RAG에 대해 알아보았고 페이퍼 리뷰를 적어보려고 한다.

논문링크
https://arxiv.org/abs/2310.11511

 

Introduction

최근의 State-Of-The-Art(SOTA) 모델들은 사실적 오류(할루시네이션 등)에 대해 방지하고자 Retrieval-Augmented Generation(RAG) 방식을 사용하고 있다. 하지만 이런 방식은 Large Language Models(LLMs)의 다재다능과 불필요한 정보들을 추가할 수 있기 때문에 오히려 문제가 생길 수 있다. 특히, 품질이 떨어지는 정보들을 가져올 수 있기 때문이다. 그래서 여기서는 Self-Reflective Retrieval-augmented Generation(SELF-RAG) 방식을 사용하고 있다. 이 방식은 간단히 설명해서 정보가 필요할 하는지에 대해 판단하고, 가져왔다면 정보가 문제를 푸는데 실질적으로 도움주는지에 대해 판단하는 시스템이다. 이를 통해 더욱 중요한 정보만을 가져와서 모델의 정확성을 향상하는 방식이다. 순서를 나열하면 다음과 같다.

  1. Retrieval Token 생성 : 주어진 입력 프롬프트 + 이전 입력을 바탕으로 추가적인 정보 검색이 필요한지 판단한다.
  2. 검생된 문서의 처리 및 출력 생성 : 검색이 필요한 경우, Self-RAG은 여러 개의 검색된 문서를 처리한다.
  3. Critique Token을 이용한 자체 평가 : 생성된 결과물에 대해 품질을 평가하여 가장 알맞은 결과물을 가져온다.

여기서 사용하는 inference algorithm은 다음을 할 수 있게 했다.

  • 각 downstream task에 대해 융퉁성 있게 검색할 수 있다.
  • segment-level beam search를 이용해 모델의 선호도를 변화할 수 있다. 

논문에서는 총 6가지 Task에 실험을 진행했다. Open-domain QA, Reasoning, Fact Verification, Long-from Generation 등등

 

Abuot Self-RAG

Self-RAG에 대한 Overview

Retrieve Token & Critique Token

각 토큰에 대한 설명이다.

Problem Formalization and Overview

Inference Overview

SELF-RAG의 추론(inference) 과정은 다음과 같다.

  1. Retrieval Token 평가: 주어진 입력 $x$와 이전 생성 $y_{<t}$에 대해, 모델은 검색이 필요한지 판단하기 위해 retrieval token을 디코딩한다. 검색이 필요하지 않으면 모델은 표준 언어 모델처럼 다음 출력 세그먼트를 예측한다.
  2. 검색 및 Critique Token 생성: 만약 검색이 필요하다고 판단되면, 모델은 검색된 문서의 관련성을 평가하는 critique token을 생성한다. 이 모델은 다음 응답 세그먼트를 생성하고, 해당 응답이 검색된 문서로부터 지원되는지 비평하는 또 다른 critique token을 생성한다.
  3. 전체 응답 평가: 마지막으로, 모델은 응답의 전체적인 유용성을 평가하는 새로운 critique token을 생성한다. 이러한 과정을 통해, SELF-RAG는 생성된 각 세그먼트가 검색된 문서와 어떻게 연관되는지를 스스로 평가한다.
  4. 병렬 처리: SELF-RAG는 여러 검색된 문서를 처리하고, 자체적으로 생성한 reflection tokens를 사용해 생성된 출력을 제어한다. 예를 들어, 그림 1에서는 문서 $d_1$이 처음 선택되고, $d_2$는 직접적인 증거를 제공하지 않으며($d_2$는 "Irrevant"으로 표시), $d_3$는 부분적으로만 지원되는 반면 $d_1$은 완전히 지원된다.

Training Overview

SELF-RAG의 훈련 과정은 다음과 같다.

  1. Reflection Token 생성 훈련: SELF-RAG는 확장된 모델 어휘(원래 어휘 + reflection tokens)를 사용해 reflection tokens를 생성하는 방법을 훈련한다. 이를 위해 generator model $M$을 훈련하는데, 이때 retriever model $R$이 검색한 문서와 critic model $C$이 예측한 비평 토큰들이 함께 사용된다.
  2. Critic Model 훈련: Critic Model $C$은 검색된 문서와 주어진 작업 출력의 품질을 평가하는 reflection tokens를 생성하도록 훈련된다. 이를 통해 모델은 검색된 문서가 관련성이 있는지, 출력이 해당 문서로부터 충분히 지원받고 있는지를 스스로 평가할 수 있게 된다.
  3. Final Generator Model 훈련: Critic Model을 통해 학습된 데이터를 바탕으로, Final generator Model $M$은 기존 언어 모델 목표로 훈련되어, 추론 시 Critic 모델에 의존하지 않고도 reflection tokens를 자체적으로 생성할 수 있게 된다.

Training 

여기서 2가지 모델을 훈련시킨다. Critic Model $C$와 Generator Model $M$ 2가지이다.

Training the Critic Model

데이터 예시

Data collection for critic model : 사람이 하나하나 라벨링 하기에는 비용이 매우 많이 발생하기에 GPT4를 이용하여 라벨링을 진행했다. 데이터를 생성하는 지시문에 대해서는 부록을 참고하면 된다. 여기서 알아둬야 할 점은 Input과 output에서 여러 토큰과 그에 대해 필요한 정보들을 추가했다는 것이다.

Critic Learning : 이 목표는 우도(likelihood)를 최대화하는 방식으로 훈련되며, 주어진 입력에 대해 올바른 출력을 예측하는 확률을 최대화하는 방향으로 모델을 학습시킨다. 다음 토큰 예측에 대해 학습을 진행한다.

여기서 사용되는 Critic Model은 Llama2-7B 모델을 사용했다. 여기서 reflection token 카테고리는 GPT-4 기반 예측과 90% 이상의일치를 보여주었다. 이것은 상당히 높은 정확도로 문서의 관련성을 평가한다는 것이다.

Training the Generator Model 

Data collection for Generator model :  밑의 그림을 보게되면 기본적인 데이터는 왼쪽이지만 Generator Model을 위해 오른쪽과 같이 데이터를 변형시킨다. 이러한 방식으로 데이터를 모았다. 

데이터를 모으는 알고리즘은 다음과 같다. 

데이터 추론 알고리즘과 데이터 모으는 알고리즘은 동일하다.

Generator Learning : 여기서는 2가지를 예측한다.

  • target output 예측
  • Reflection token 예측(Critique, Retrieve)

 

 

Experiments

Results

without retrieval

SELF-RAG의 성능 우위: SELF-RAG는 모든 작업에서 감독 학습으로 미세 조정된 대형 언어 모델(LLM)보다 성능이 뛰어났으며, PubHealth, PopQA, 전기 생성(biography generation), ASQA와 같은 작업에서는 ChatGPT보다도 더 나은 성능을 보였다.

동시 연구 모델과의 비교: SELF-RAG는 CoVE(Dhuliawala et al., 2023)와 같은 다른 동시 연구 모델들보다 전기 생성 작업에서 우수한 성과를 보였다. SELF-RAG의 7B와 13B 모델이 이를 능가한 성과를 냈습니다.

with retrieval

RAG 모델 대비 우수성: SELF-RAG는 기존의 Retrieval-Augmented Generation (RAG) 모델들에 비해 대부분의 작업에서 더 나은 성능을 발휘했다. 특히 open-source 모델 중에서 최고 선능을 달성했다.

Citation Precision: SELF-RAG는 인용 정확도 측면에서 ChatGPT를 능가했다. 특히 ASQA 작업에서 SELF-RAG는 높은 인용 정밀도와 재현율을 기록하며, ChatGPT를 제외한 모든 모델을 압도했다.

Analysis

Ablation studies 

 

  • No Retriever 모델은 검색된 문서를 사용하지 않고 표준 입력-출력 쌍으로만 훈련되며, SELF-RAG에 비해 성능이 크게 떨어진다. 이는 검색된 문서의 중요성을 나타낸다.
  • No Critic 모델은 Critic 없이 검색된 문서만 사용해 훈련된다. 이 모델도 성능이 떨어지며, Critic 모델이 성능 향상에 큰 역할을 한다는 점을 시사한다.

 

Effects of inference-time customize

 

  • No Retrieval는 검색 없이 추론을 진행하는 방식으로, 성능이 크게 떨어진다. 이는 필요할 때 검색을 하지 않으면 모델 성능이 저하될 수 있음을 보여준다.
  • Hard Constraints는 검색이 필요할 때 항상 검색을 강제하는 방식인데, 동적으로 검색을 조정하는 SELF-RAG 방식이 더 나은 결과를 보인다.
  • Retrieve Top 1은 검색된 문서 중 상위 한 개 문서만 사용하는 방식으로, ASQA와 PopQA에서 성능이 크게 떨어진다. 이는 상위 문서만이 항상 최선이 아님을 나타낸다.

 

Conclusion

SELF-RAG는 reflection tokens을 활용하여 추론(test) 시 모델의 동작을 세밀하게 조정할 수 있다. 여러 작업에서 다양한 평가 지표를 사용해 SELF-RAG를 평가한 결과, 더 많은 매개변수를 가진 LLM들이나 기존의 검색 기반 생성 모델들보다 성능이 우수하다는 점을 입증하였다. 이는 SELF-RAG가 기존 방식보다 효율적이며, 더욱 정확한 결과를 제공할 수 있음을 보여준다.

 

이 논문은 상당히 좋은 논문 같다. LLM에게 직접 생각을 하도록 유도해서 더욱 좋은 성능을 나타낸다. 하지만 모델의 편향성이나 아얘 없는 정보에 대해 어떻게 처리할지도 있는 논문도 나왔으면 좋겠다.

 

728x90

Qwen Model

오늘은 Qwen 모델에 대해 공부를 하기 위해서 Qwen2 Technical Report를 읽고서 간단하게 요약하려고 한다. Qwen 모델에 대해 간단하게 알고 싶은 분들을 위해 작성한다.

Paper 링크
https://arxiv.org/pdf/2407.10671

 

 

Introduction

여기서는 0.5B, 1.5B, 7B, 72B, 57B-A14B(MoE) 총 5개의 파라미터가 각각 다른 모델에 대해 소개하고 있다. 모델은 각각  7T 토큰의 데이터셋으로 훈련이 되었다. 토크나이저, 모델 구조, 데이터셋, 실험 등에 대해 상세하게 서술하고 있으며 MoE 모델에 대해서 매우 자세하게 얘기하고 있다. 0.5B와 1.5B는  스마트폰, 이어폰과 스마트 안경에 적합하고 그 외의 모델은 GPU에 적합하다고 말하고 있다. 기본 모델과 Fine-tuned 모델에 대해서도 서술하고 있다.

 

Tokenzer & Model

Toeknzer

Tokenzier은 Byte-pair encoding(BPE) 방식을 채택하고 있다. 이를 통해 다국어를 지원할 수 있게 되었다고 한다.

  • 151,643개의 ragular 토큰과 3개의 control 토큰을 갖고 있다.

Model

각 모델에 대한 스펙

모델에서 사용하는 Dense Language Model과 Dense Langueage Model 4개를 혼합한 MoE 모델에 대해 설명하고 있다. Dense Model과 MoE 모델에서 사용되는 기술에 대해 설명하고 있다.

Qwen2 Dense Model

  • Grouped Query Attention(GQA) : Multi-head Attention 기법보다 더욱 효율적인 방식이며 GQA 방식은 KV 캐시를 사용하여 최적화한다.
  • Dual Chunk Attention with YARN : Qwen2의 context window를 확장하기 위해 사용했다. 

Qwen2 MoE Model

  • Expert Granularity : MoE 레이어가 여러 개의 Feed Forward Network(FFN)을 포함하고 있다. 각각의 FFN은 MoE 역할을 수행한다.
  • Expert Routing : 모델에서 어떤 FFN(Expert) 활성화에 대한 메커니즘이다. 입력 데이터를 기반으로 적절한 전문가를 선택하여 작업을 처리하도록 하는 과정이다.
  • Expert Initialization : 밀집 모델의 가중치를 활용하여 전문가들을 초기화하는 방식이다.

 

Training

이 부분에서는 각 Pre-training, Post-training에서 사용되는 방식과 데이터에 대해 설명하고 있다.

Pre-training

Data

Qwen, Qwen1.5에서 사용된 데이터에 대해 더 향상을 시킨 데이터로 진행을 했다. 양, 품질 그리고 다양성의 부분에서 더욱 향상되었다.

  • Quality Enhancement : 모델과 휴리스틱 알고리즘을 이용해 저품질을 판단하여 필터링을 진행해 품질을 향상시켰다.
  • Data Expansion : 이전 데이터셋에 비해 코드, 수학 그리고 다국어 데이터에 대해 품질과 양을 매우 늘렸다. 여기에는 약 30개의 언어가 포함되어 있다.(영어, 중국어, 스페인어, 프랑스어, 독일어, 노어, 한국어, 일본어, 태국어, 베트남어 등)
  • Distribution improvement : 모델이 사람과 비슷하게 학습을 활 수 있도록 다양한 자료들을 가져왔다. 

데이터양은 12T 토큰을 준비했지만 7T와 크게 성능에 대해 비슷하므로 양은 7T만큼 훈련을 진행했다. 하지만 0.5B 모델은 12T 양으로 훈련을 진행했다.

Training

Qwen2의 long-context capability를 향상하기 위해서 context 길이를 4,096에서 32,768개로 늘렸다. 또한 기본 RoPE를 10,000에서 1,000,000으로 바꾸었다. 학습 방식은 다음 토큰을 예측하는 방식으로 훈련을 진행했다.

 

Post-training

Data

Post-training data는 2가지 요소로 구성되어 있다.

  • Demonstration data : $D = \{(x_i,y_i)\}$
  • Preference data : $P = \{(x_i, y_i^+, y_i^-)\}$

여기서 $x_i$는 instruction, $y_i$는 satisfactory response, $y_i^+$ $y_i^-$는 각각 prefer choice와 그 반대를 의미한다.  $D$는 SFT에 활용되며 $P$는 RLHF에 활용된다.

데이터 구성은 2가지 과정으로 구성되었다.

  1. collaborative data annotation : large-scale instruction corpora에서 ontology를 추출하여 다양한 데이터 구성한다. 사람이 직접 주석을 달아 목표 응답$y_i$과 그에 대한 긍정적/부정적 대응$y^+_i, y^-_i)을 확보
  2. automated data synthesis : 다양한 자동화된 전략을 사용해, 코드, 수학과 같은 여러 domain에서 annotation data를 확보함

Collaborative data annotation

  • Automatic Ontology Extraction : Ontology 추출을 위해 InsTag, an open-set fine-grained tagger를 사용한다.
  • Instruction Selection : 각 지시문은 태그가 주석으로 달린 상태에서 다양성, 의미적 풍부함, 복잡성 등을 기준으로 평가한다.
  • Instruction Evoluation : 지시문 데이터셋의 풍부함을 위해 self-evolution stratgy가 적용된다.
  • Human Annotation : 여러 반응이 생성되면 사람을 이용해 가장 선호되는 데이터를 선택한다.

Automated data synthesis

  • Rejection Sampling : 수학 그리고 수학과 관련된 task를 위한 방법이다. LLM을 이용해 추론 과정을 출력하도록해서 답을 산출하도록 한다.
  • Execution Feedback : 코딩 task를 위한 방법이다. LLM을 이용해 해답과 관련된 Test Case를 만들고 실행하여 평가하며 데이터를 만듭니다.
  • Data Repurposing : 문학 task에 대한 방법이다. Open-Domain(Wikipedia)에서 문학 작품을 수집하고, LLM을 사용해 다양한 수준의 지시문을 개발한다.
  • Constitutional Feedback : 미리 정의된 원칙을 기반으로 **대형 언어 모델(LLMs)**이 응답을 생성하도록 안내하는 과정을 의미합니다(Bai et al., 2022). 안전성 및 가치와 같은 지침을 따르게 하기 위해, 헌법 데이터셋이 구성

Training

Supervised Fine-Tuning(SFT)와 Reinforcement Learning From Human Feedback(RLHF)를 이용해 Post-Training을 진행했다. 

Evaluation

실험은 매우 다양한 방면에서 진행되었다. base model, fine-tuned model에 대해서 다른 모델들과 함께 Benchmark를 진행했다. 실험 Table이 매우 많은 관계로 간단하게 가져와서 설명하려고 한다.

Base Model

각 테이블은 70B+, 7B+, <3B 이렇게 실험이 진행되었다. Phi-2는 2.78B 모델이다. 실험을 보게 되면 7B 이상 모델의 경우에는 모두 좋은 성능을 보였다. 하지만 <3B 모델의 경우 Phi-2는 추론 능력이 좋았지만, 그 외의 경우에는 Qwen2-1.5B 모델이 압도하는 모습을 볼 수 있다. 파라미터가 1B이상 적은 반면에 매우 좋은 성능을 보여주고 있다는 것이다.

Instruct Model

Open Benchmark

Instructed Model에서는 대체적으로 Qwen2 모델이 다른 모델과 Qwen1.5 모델을 압도하는 모습을 나타내고 있다.

이전 버전의 모델들과 비교했을 때도 매우 향상된 Mectric을 달성하고 있다.

Multilingual

여기서 각 언어 전문가를 통해 평가를 요청했다. 여기서는 1~5 점 사이로 점수를 매길 수 있으며 Claude가 가장 좋은 성능을 달성했으며 Qwen 모델도 충분히 좋은 성능을 달성했다.

 

Safety & Responsibility

다국어 안전성 평가를 통해 LLM이 다양한 언어에서 안전성에 대해 평가했다. 특히, 불법 행위, 사기, 포르노, 프라이버시와 관련된 주제에서 모델의 안전성을 테스트했다. Qwen2-72B-Instruct가 GPT-4 및 Mixtral-8x22B-Instruct보다 더 나은 성능을 보였지만. 그러나 특히 포르노와 같은 어려운 카테고리에서 모델이 더 안전하고 책임감 있게 개선될 여지가 있다고 판단한다.

Conclusion

Qwen2는 이전의 공개 가중치 모델들, 특히 그 전신인 Qwen1.5를 능가하며, 언어 이해, 생성, 다국어 능력, 코딩, 수학, 추론 등 다양한 벤치마크에서 독점 모델들과 경쟁력 있는 성능을 보여준다. 이번 업데이트에서는 특히 긴 문맥 처리, 다국어, 코딩, 수학 기능, 그리고 안전성 및 책임감에 중점을 두었다.

한국어의 능력도 괜찮은 걸로 보아서 사용하기에 괜찮지만 테스트 당시 언어 능력은 좋지만 지식은 좋지 않은 편이다.

728x90

프로그래밍 대회나 알고리즘 문제를 풀 때, 입출력 속도는 매우 중요합니다. 특히 파이썬은 다른 언어에 비해 입출력 속도가 느린 편이기 때문에, 기본 입출력 방법을 사용하면 시간 초과가 발생할 수 있습니다. 이 글에서는 파이썬에서 데이터를 빠르게 입출력하는 방법을 소개하겠습니다.

 

빠른 입력

기본적으로 파이썬에서는 input() 함수를 사용하여 입력을 받습니다. 하지만 이 함수는 내부적으로 버퍼링을 하지 않아 속도가 느립니다. 따라서 sys.stdin.readline() 함수를 사용하여 입력 속도를 향상시킬 수 있습니다.

import sys

data = sys.stdin.readline().rstrip()
  • sys.stdin.readline()은 한 줄의 입력을 빠르게 받아옵니다.
  • 입력받은 문자열의 끝에는 줄바꿈 문자(\n)가 포함되므로, rstrip() 함수를 사용하여 이를 제거합니다.

매번 sys.stdin.readline()을 쓰는 것이 번거롭다면, input 함수를 재정의하여 사용할 수 있습니다.

 
import sys

input = sys.stdin.readline

data = input().rstrip()

이렇게 하면 기존의 input() 함수를 sys.stdin.readline()으로 대체하여 사용할 수 있습니다..

 

빠른 출력

파이썬의 print() 함수는 사용하기 편리하지만, 출력 속도가 느립니다. 특히 반복문에서 많은 양의 데이터를 출력할 때는 sys.stdout.write() 함수를 사용하는 것이 좋습니다.

import sys

sys.stdout.write('Hello World\n')
  • sys.stdout.write()는 문자열만 출력할 수 있으므로, 숫자를 출력하려면 문자열로 변환해야 합니다.
  • 기본적으로 줄바꿈(\n)을 해주지 않기 때문에 필요하면 문자열 끝에 \n을 추가해야 합니다.

print 함수도 sys.stdout.write로 재정의할 수 있습니다.

import sys

print = sys.stdout.write

print('Hello World\n')

 

예제 코드

입력 예제

import sys

input = sys.stdin.readline

n = int(input())
arr = list(map(int, input().split()))
  • 첫째 줄에 정수 n을 입력받고, 둘째 줄에 n개의 정수를 입력받아 리스트 arr에 저장합니다.

출력 예제

import sys

print = sys.stdout.write

result = 42
print(str(result) + '\n')
  • 결과를 출력할 때는 숫자를 문자열로 변환하고, 줄바꿈 문자를 추가합니다.