🔐 SECRET_KEY의 주요 용도

1.암호화 및 서명(Signing) Django에서는 다양한 데이터를 안전하게 다룰 때 암호화 또는 서명을 한다. 예를 들어, 세션 쿠키, CSRF 토큰, 비밀번호 리셋 링크, 사인된 URL 등 이때 데이터를 서명하고 검증하는데 SECRET_KEY가 사용된다. 즉, 이 값이 외부에 노출되면 서명을 위조할 수도 있다.

2.세션 데이터 보호 기본적으로 Django는 세션 정보를 암호화해서 클라이언트에 저장할 수 있어. 이때도 SECRET_KEY가 필요하다.

3.보안 해시 생성 비밀번호를 해시하거나 기타 민감한 정보를 다룰 때, 이 키가 내부적으로 해시 알고리즘의 솔트(salt)로 사용되기도 한다.

❗️ 주의할 점❗️ 절대 유출되면 안 된다. SECRET_KEY가 유출되면 누군가가 악의적인 세션 쿠키나 CSRF 토큰을 위조할 수 있다. 그래서 보통 .env 파일이나 환경 변수로 따로 관리하고, GitHub 같은 곳에 절대 올리면 안된다.

다행히도 배포 전에 노출되었다면 아직 공격에 노출된 상태는 아니니까, SECRET_KEY를 변경만 하면 문제가 없다.

지금이라도 알아서 다행이다.

** ✅ 해야 할 일 **

1.새로운 SECRET_KEY를 생성한다. Django 콘솔이나 Python에서 쉽게 만들 수 있다.

python -c "from django.core.management.utils import get_random_secret_key; print(get_random_secret_key())"

2.새 키로 설정 변경 settings.py에 하드코딩 되어 있다면, 다음처럼 .env 파일이나 환경 변수로 빼는 것을 추천한다.

import os
SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY')

.gitignore에 .env 파일을 넣어야한다.

3.노출된 키는 더 이상 사용하지 말 것 Git에 푸시했다면 커밋에서 제거하고 기록도 지우는 걸 추천한다.

🛠 Git 기록에서 SECRET_KEY 노출된 파일 제거하기

1. 저장소 백업

cp -r /Users/sujinkim/python/question_journal /Users/sujinkim/python/question_journal_backup

2. 필터 브랜치 실행

git filter-branch --force --index-filter \
"git rm --cached --ignore-unmatch settings.py" \
--prune-empty --tag-name-filter cat -- --all

위 명령은 모든 커밋에서 settings.py를 제거해서 SECRET_KEY를 기록에서 지우는 작업이다.

3. Git 기록 정리 (Garbage Collection)

git reflog expire --expire=now --all
git gc --prune=now --aggressive

4. 원격 저장소에 강제로 푸시 ❗ 이 작업은 공용 저장소의 기록을 바꾸기 때문에, 협업 중이라면 팀원에게 먼저 공유하고 진행해야한다.

git push origin --force --all
git push origin --force --tags

왜 장점이냐고? 취업이 잘 돼서? ❌ 요즘 개발자 취업 시장도 꽤 춥다. 진짜 이유는, 내가 생각한 서비스를 직접 개발할 수 있는 능력이 있기 때문이다. ⭕

ChatGPT나 Claude처럼 LLM이 등장하면서, 이제는 정말 누구나 손쉽게 서비스를 만들 수 있는 시대가 됐다. 그래서 잠깐, ‘이러다 내 일자리 사라지는 거 아냐?’ 걱정도 했다. 실제로 LLM은 웬만한 개발자보다 더 똑똑하니까.

하지만 생각해보면, LLM을 잘 활용하려면 개발 지식이 없는 사람보다는 개발을 이해하고 있는 사람(=나!)이 더 빠르고 정확하게 원하는 서비스를 만들 수 있지 않을까?

그래서 취업을 준비하는 이 시기에, 그동안 머릿속에만 있던 다양한 toy-project들을 직접 만들어보려고 한다. 나의 든든한 사수, ChatGPT와 Claude와 함께.

완전 럭키비키자나🍀

⭕️ poetry를 사용하면 좋은 점 poetry는 Python 패키지 관리와 가상환경 관리를 도와주는 도구인데, 한마디로 정리하면 "pip + virtualenv + setuptools를 한 방에 해결해주는 깔끔한 툴"이다.

✅ 1. Poetry 설치

먼저, 터미널에서 Poetry가 설치되어 있는지 확인한다.

poetry version

없으면 아랭 명령어로 설치한다.

curl -sSL https://install.python-poetry.org | python3 -

✅ 2. PyCharm 프로젝트 폴더 준비

PyCharm에서 프로젝트 폴더를 열거나 새 프로젝트를 생성한다.

✅ 3. Poetry 초기화

터미널(프로젝트 루트 경로)에서 아래 명령어를 실행한다:

poetry init

질문에 따라 프로젝트 이름, 버전 등을 입력하거나 그냥 엔터로 넘겨도 된다. pyproject.toml 파일이 생성된다.

✅ 4. 가상환경(.venv) 생성

Poetry는 프로젝트별 가상환경을 자동으로 생성한다. 먼저 Python 버전으로 가상환경을 지정한 후,

poetry env use python3.x

Poetry는 .venv 폴더를 프로젝트 디렉토리 내부에 두지 않고, 기본적으로 ~/.cache/pypoetry/virtualenvs/에 가상환경을 만든다.

_(선택) 로컬 프로젝트 안에 .venv로 생성하고 싶으면 아래 설정을 한다. _

poetry config virtualenvs.in-project true

.venv 폴더가 생성된다.

poetry install

*✅ 5. PyCharm에 Poetry 가상환경 연결 *

1. PyCharm에서 File > Settings > Python Interpreter (Mac: PyCharm > Preferences > Python Interpreter)

2. 오른쪽 상단의 톱니바퀴 아이콘 클릭 → Add Interpreter

3. Add Local Interpreter → Existing environment 선택

4. ... 버튼을 눌러 가상환경 경로를 찾아 선택

   프로젝트 안에 .venv가 있다면:

   <프로젝트 경로>/.venv/bin/python
   

   시스템 경로에 있다면 poetry env info --path로 위치를 확인:

   poetry env info --path
   

   출력 경로의 bin/python 선택.

5. OK → 적용.

*✅ 6. Poetry 의존성 추가 방법 *

poetry add package_name

자동으로 pyproject.toml과 poetry.lock이 업데이트된다. PyCharm에서도 바로 반영된다.

**🍀 터미널에서 가상환경 활성화 ** 가상환경의 경로가 /Users/xxx/python/project-name/.venv 같은 형태라면,

source .venv/bin/activate

도커란?

도커는 프로그램을 실행하기 위한 가상의 컨테이너를 만들어주는 도구입니다. 쉽게 말해, 개발자가 만든 프로그램을 어디서든 동일한 환경에서 실행할 수 있도록 해주는 마법같은 기술입니다.

what container 공식페이지에서 아래와 같이 정의합니다. 컨테이너는 소프트웨어의 표준 단위로, 애플리케이션이 실행되는데 필요한 코드와 모든 종속성을 패키징하여 환경과 상관없이 빠르고 안정적으로 실행할 수 있도록 합니다.도커 컨테이너 이미지는 코드, 실행환경, 시스템 도구, 시스템 라이브러리, 설정 등을 포함한 독립적이고 가벼운 실행 패키지입니다. 컨테이너 이미지는 실행될 때 컨테이너가 되며, 도커 컨테이너의 경우 도커 엔진에서 실행되면서 컨테이너가 활성화됩니다. 리눅스 및 윈도우 기반 어플리케이션 모두에서 사용할 수 있으며, 환경과 관계없이 동일한 방식으로 실행할 수 있습니다. 컨테이너는 소프트웨어를 실행 환경에서 격리하여 개발, 테스트, 운영 환경 간 차이로 인해 발생하는 문제를 방지할 수 있도록 합니다.

도커를 사용하는 이유

개발자들은 종종 이런 문제를 겪습니다.

• 내 컴퓨터에서는 잘 실행되는데, 서버에서는 왜 안될까?
• 버전이 달라서 프로그램이 깨지는 것 같아.
• 이 프로그램을 실행하려면 환경 설정이 너무 복잡해.

도커는 이러한 문제를 해결해줍니다. 프로그램과 실행에 필요한 모든 환경을 하나의 컨테이너에 담아 어디서든 동일하게 실행할 수 있도록 만들어줍니다.

도커와 가상머신(virtual machine)

도커 컨테이너와 가상머신 모두 프로그램을 독립된 환경에서 실행할 수 있도록 해주는 기술이지만, 몇 가지 차이점이 있습니다.

즉, 컨테이너는 가상머신보다 훨씬 가볍고 빠르며, OS를 공유하기 때문에 더 적은 자원을 사용합니다. 반면 가상머신은 OS를 독립적으로 포함하고 있어 더 무겁지만, 강력한 격리 기능을 제공합니다.

도커의 핵심 개념

1. 이미지(image): 프로그램과 실행 환경을 포함한 템플릿
2. 컨테이너(container): 이미지를 실행한 상태, 실제 동작하는 프로그램
3. 도커 허브(Docker Hub): 다양한 이미지가 공유되는 온라인 저장소
4. Dockerfile: 이미지를 만들기 위한 설정 파일

부스트캠프 AI Tech NLP 트랙 기업 해커톤에서 HyperClovaX를 활용한 자동 콘텐츠 생성 서비스를 개발하였다. 이 서비스는 카피라이트와 음악을 포함한 다양한 콘텐츠를 자동으로 생성한다. 🎵✨

🎯 음악과 관련된 작업

1️⃣ 음악 생성 모델 리서치 2️⃣ 생성된 음악을 평가하기

먼저, LLM을 활용한 음악 생성 기능을 구현하기 위해 음악 생성 모델을 조사하였다. 후보로 검토한 모델은 다음과 같다.

🎶 음악 생성 모델 후보 ✔️ MusicGen ✔️ AudioLDM2 ✔️ MusicLDM

이 중, 나는 Meta의 MusicGen과 관련된 논문을 분석하며 해당 모델의 구조와 작동 방식을 연구하였다.

📖 논문 원문: Simple and Controllable Music Generation

🤯 솔직한 후기

솔직히 말해, 논문의 절반 이상을 완전히 이해하지 못했다... 😭 코드북 패턴(Codebook pattern), 인터리빙(Interleaving) 등 처음 접하는 개념이 많았기 때문이다.

🔎 논문에서 주목한 내용

가장 중요한 부분 중 하나는, 음악 샘플, 코드, 모델이 오픈소스로 공개되어 있다는 점이다.연구자와 개발자는 아래 깃허브 리포지토리를 통해 이를 활용할 수 있다.

🔗 GitHub - facebookresearch/audiocraft

또한, 생성된 음악의 품질이 만족스럽지 않을 경우, 파인튜닝(Fine-tuning)이 필요할 수도 있다.이 점에서 MusicGen은 오픈소스 모델이라는 강점이 있다.

하지만 실험 결과,MusicGen은 추가적인 파인튜닝 없이도 충분히 고품질의 음악을 생성할 수 있었다.

📊 MusicGen과 다른 음악 생성 모델 비교 평가

🔍 비교 대상 모델 ✔️ Riffusion ✔️ Mousai ✔️ MusicLM ✔️ Noise2Music

📌 평가 메트릭

객관적 평가 Fréchet Audio Distance (FAD) → 생성된 오디오의 품질(현실감) 평가 Kullback-Leibler Divergence (KL) → 생성된 음악과 원본 음악의 유사성 평가 CLAP Score → 생성된 음악과 텍스트 설명 간의 정렬 평가

주관적 평가 Overall Quality (OVL) → 전반적인 오디오 품질 평가 Relevance to Text Input (REL) → 생성된 음악이 입력 텍스트와 얼마나 관련 있는지 평가

📈 평가 결과

💡 MusicGen 성능 요약 ✅ 오디오 품질과 텍스트 관련성에서 기준 모델들보다 우수 ✅ Noise2Music은 FAD에서 가장 낮은 점수를 기록했지만, MusicGen은 인간 평가에서 더 나은 성과를 보임

📊 모델 크기별 성능 분석 ✅ 모델 크기가 클수록 성능이 개선됨 ✅ 주관적 품질(OVL)은 1.5B 모델에서 최적, 큰 모델(3.3B)은 텍스트 입력을 더 잘 이해.

🎵 실험 및 최종 선택

musicgen 데모 사이트에서 다양한 모델로 생성된 음악을 직접 들어볼 수 있었다. 팀원들과 블라인드 테스트를 진행한 결과, MusicGen의 선호도가 가장 높았다! ⚠️ 다른 모델들은 기계음이 강하거나 노이즈가 많았음.

📌 결론 최종적으로 MusicGen을 프로젝트에 적용하였다. 그 이유는 논문에서도 확인된 인간 평가에서의 우수한 성능 때문이었다.

📌 MusicGen을 프로젝트에서 어떻게 활용했는가? 영어로 프롬프트를 입력하면 해당 내용에 맞는 음악을 생성한다.

다음에는, 프롬프트를 생성하는 방법과 생성된 음악을 평가하는 방법에 대한 글을 작성하려고 한다.

Abstract

이 논문은 자연어 생성 시스템의 품질 평가에 대한 문제를 다루며, 특히 기존 평가 지표의 한계와 대안을 제시한다.

1. 배경 및 문제제기

• 기존 지표의 한계: BLEU와 ROUGE 같은 기존 reference-based 지표는 창의성과 다양성이 요구되는 작업에서 인간 평가와의 상관성이 낮다.
• 새로운 접근법: reference-free 평가 방법으로 LLMs를 사용하는 것을 제안한다.

2. G-EVAL

• CoT: LLMs의 사고 과정을 단계적으로 표현하여 더 정교한 평가를 수행한다.
• Form-Filling: 평가 기준을 구조화된 형식으로 채워넣는 방식으로, 더 명확하고 체계적인 평가를 가능하게 한다.

3. 의의와 결론

• G-EVAL은 기존의 평가 방식을 능가하며, 대화나 창의성을 요구하는 task에서 효과가 뛰어나다.
• 텍스트 요약과 대화 생성 태스크에 있어 GPT-4를 백본으로 사용하는 G-EVAL 프레임워크는 사람 평가와의 피어슨 상관계수가 0.514로, 기존에 제안된 모든 방법을 크게 능가하는 상관성을 보인다.
• 단, 이 방식은 프롬프트에 민감하기 때문에 CoT를 통해 더 많은 컨텍스트와 가이드를 제공할 때 alignment가 높아진다.
• LLM 기반의 평가를 면밀히 조사한 결과, 사람이 작성한 텍스트보다 LLM이 작성한 텍스트를 선호하는 편향성을 발견하였다. 따라서 LLM 기반의 매트릭을 LLM 학습의 보상 신호로 사용할 경우, 편향된 결과를 야기할 수 있다. (self reinforcement of LLMs)

Method: G-EVAL Framework

1.생성 결과물 평가를 위한 프롬프트 설계 프롬프트: 평가하려는 태스트에 대한 정의와 원하는 평가 기준을 정의하는 자연어 명령어

텍스트 요약의 경우 아래와 같은 프롬프트를 사용할 수 있다.

You will be given one summary written for a news article. Your task is to rate the summary on one metric. Please make sure you read and understand these instructions carefully. Please keep this document open while reviewing, and refer to it as needed.
뉴스 기사에 대해 작성된 하나의 요약이 주어질 것이다. 너의 임무는 하나의 매트릭으로 요약문을 평가하는 것이다.
아래 지침을 주의 깊게 읽고 이해하도록 하라. 검토를 진행하는 동안 이 지침을 열어두고, 필요할 때 참조하라.

태스크에 대한 평가에 필요한 기준을 프롬프트화하면 된다. 평가 기준은 일관성, 간결성, 문법적 오류 없음 등 태스크에 따라 다양하게 설정할 수 있다.

텍스트 요약에서 일관성 항목을 평가하고자 하는 경우, 아래와 같은 내용을 프롬프트에 추가할 수 있다.

Evaluation Criteria:
Coherence (1-5) - the collective quality of all sentences. We align this dimension with the DUC quality question of structure and coherence whereby ”the summary should be well-structured and well-organized. The summary should not just be a heap of related information, but should build from sentence to sentence to a coherent body of information about a topic.”

평가 기준:
일관성 (1-5) - 일관성은 모든 문장에 대한 총체적인 품질을 의미한다. 이 기준은 다음과 같은 구조와 일관성에 대한 DUC 품질 질문과 관련이 있다: "요약문은 잘 구조화되고 잘 정리되어 있어야 한다. 요약문은 관련된 정보를 나열한 수준이 아니라 하나의 주제에 대한 일관된 정보로 문장에서 문장으로 이어져 있어야 한다."

2.CoT CoT는 텍스트 생성 과정에서 LLM이 생성하는 중간 representation 시퀀스이다. 생성된 텍스트를 평가하는 단계에서는 단순한 정의 이상의 자세한 평가 지침이 필요한데, 각각의 태스크에 대해 이러한 평가 단계를 수동으로 설계하는 것은 많은 시간이 소요된다. 대규모 언어모델은 이러한 평가단계를 스스로 생성할 수 있기 때문에 CoT를 통해 LLM이 텍스트를 평가할 수 있도록 더 많은 컨텍스트와 지침을 제공할 수 있고, 평가 과정과 결과를 설명하는데 도움이 될 수 있다.

텍스트 요약에서 일관성 항목을 평가하고자 하는 경우, 프롬프트에 "Evaluation Steps:"라는 표현을 추가하여 LLM이 생성하도록 한 CoT이다.

1. Read the news article carefully and identify the main topic and key points.
2. Read the summary and compare it to the news article. Check if the summary covers the main topic and key points of the news article, and if it presents them in a clear and logical order.
3. Assign a score for coherence on a scale of 1 to 5, where 1 is the lowest and 5 is the highest based on the Evaluation Criteria.

1. 뉴스 기사를 주의 깊게 읽고 주요 주제와 요점을 한다.
2. 요약문을 읽고 뉴스 기사와 비교한다. 요약이 뉴스 기사의 주요 주제와 요점을 명확하고 논리적인 순서로 제시하였는지 확인한다.
3. 일관성에 대한 점수를 1-5점까지의 척도로 부여한다. 이때 평가 기준에 따라 1은 가장 낮은 점수, 5가 가장 높은 점수이다.

3.Scoring Function 아래의 세 가지를 input으로 LLM을 호출한다

생성 결과물 평가를 위한 프롬프트
자동으로 생성된 CoT
입력 컨텍스트와 평가해야할 대상 텍스트

G-EVAL은 양식 채우기 방식으로 평가 작업을 직접 수행한다. 예를 들어, 텍스트 요약의 일관성을 평가하기 위해 텍스트 요약에서 프롬프트와, CoT, 뉴스 기사, 요약문을 입력으로 LLM을 호출하여 각 평가 항목에 대해 1에서 5까지의 점수를 출력한다.

하지만, 이렇게 직접 점수를 출력하는 방식에는 두가지 문제가 있다:

• 일부 평가 태스크에서는 하나의 숫자가 점수 분포를 지배한다. 예를 들어 1-5점 척도에서는 3점이 지배적으로 출력되었다. 이로 인해 사람이 판단하기에 점수가 낮은 결과물과 G-EVAL 점수와의 상관관계가 낮아질 수 있다.
• 프롬프트에서 소수점 단위의 평가를 명시적으로 요청하더라도 LLM은 주로 정수 아웃풋을 출력하였다. 이로 인해 평가에서 동점이 많이 발생하였고 이로 인해 생성된 텍스트 간의 미묘한 차이를 포착하지 못한다.

이를 해결하기 위해 LLM의 출력 토큰 확률을 사용하여 점수를 정규화하고 그들의 가중합을 최종 결과로 사용할 것을 제안한다. 이 방식을 통해 생성된 텍스트와 품질과 다양성을 더 반영할 수 있는 연속적인 점수를 얻을 수 있다.

G-EVAL은 LLM이 생성한 텍스트를 선호하는가

LLM을 평가자로 사용할 때 우려사항 중 하나는 모델이 직접 작성한 고품질 텍스트보다 LLM 자체에서 생성한 결과물을 더 선호할 수 있다는 점이다.

데이터는 다음의 세 카테고리로 나누어진다:

1) 사람이 평가했을 때 GPT-3.5가 작성한 요약보다 사람이 작성한 요약이 더 높은 점수를 받은 경우 2) 사람이 평가했을 때 GPT-3.5가 작성한 요약보다 사람이 작성한 요약이 더 낮은 점수를 받은 경우 3) 사람이 평가했을 때 GPT-3.5가 작성한 것과 사람이 작성한 요약이 같은 품질이라고 평가한 경우 그림에서 볼 수 있듯이 G-EVAL-4는 항상 GPT-3.5가 작성한 요약을 선호한다.

그 이유는 다음과 같다.

• NLG 평가의 본질적 어려움: 고품질 시스템의 출력(NLG 텍스트)은 평가가 본질적으로 어렵다. 인간 평가자 간 합의도(Inter-Annotator Agreement)가 매우 낮았으며, 크리펜도르프 알파(Krippendorff’s alpha)는 0.07로 나타남.
• LLM 평가자의 LLM 출력 편향: G-EVAL-4는 LLM 생성 요약에 대해 편향을 가질 가능성이 있음. 이는 평가 모델(G-EVAL)과 생성 모델(GPT-3.5)이 평가 기준을 공유할 가능성 때문.LLM은 텍스트를 생성하고 평가할 때 동일한 개념과 기준을 사용할 수 있으며, 이로 인해 LLM 생성 텍스트에 더 높은 점수를 부여할 가능성이 있음.

참고 논문리뷰 G-Eval: LLM을 사용해 인간의 견해와 보다 일치하는 NLG 평가 시스템 구축하기

Data Parallelism

torch.nn.DataParallel

torch.nn.DataParallel은 single-node와 multi-GPU에서 동작하는 multi-thread 모듈이다.

Forward pass

• GPU 0이 master GPU로써 batch를 사용하는 GPU 4개로 나누어준다. (scatter)
• Model을 GPU 수만큼 복제한다.(replicate)
• GPU 0에 올라와있는 모델의 파라미터를 GPU 1,2,3으로 broadcast한다.
• 나누어진 batch를 각각 복제된 model에 forward, Logits을 계산한다.
• forward된 outputs를 master GPU에 다시 모아준다.(gather)
• Logits으로부터 Loss를 계산한다.

Backward pass

• 계산된 Loss를 각 디바이스에 scatter한다.
• 전달받은 Loss를 이용해서 각 디바이스에서 Backward를 수행하여 Gradients를 계산한다.
• 계산된 모든 Gradient를 GPU 0로 Reduce하여 GPU 0에 전부 더한다.
• 더해진 Gradients를 이용하여 Gradient 0에 있는 모델을 업데이트한다.

torch.nn.DataParallel의 문제점

single-process multi-thread parallelism이 GIL에 의한 방해를 받는다. 파이썬은 GIL(Global Interpreter Lock)에 의해 하나의 프로세스에서 동시에 여러 개의 thread가 작동할 수 없다. 따라서 multi-thread가 아닌 multi-process 프로그램으로 만들어서 여러 개의 프로세스를 동시에 실행하게 해야한다.

GIL이란, 여러 개의 thread가 파이썬 바이트 코드를 한번에 하나만 사용할 수 있게 락을 거는 것을 의미한다. GIL은 파이썬의 메모리 안정성을 보장하기 위해 설계되었는데, 이로 인해 파이썬 multi-thread 프로그램에서 multi-thread가 signle-thread처럼 동작하는 성능 병목 현상을 발견할 수 있다.

GIL의 등장 배경은 다음과 같다. 레퍼런스 카운팅이란 파이썬에서 생성된 객체가 객체를 가리키는 참조의 수를 추적하는 참조 카운트 변수를 가진다는 것을 의미한다.

그림에서 보듯이 우측의 객체는 참조의 수가 2인데, 좌측의 객체는 참조가 없어져 0이 된다. 이 개수가 0에 도달하면 개체가 점유한 메모리가 메모리 가비지 컬렉터에 의해 해제된다. 문제는 이 레퍼런스 카운팅 변수가 멀티 스레드 환경에서 두 스레드가 동시에 값을 늘리거나 줄이는 Race Condition이 발생할 수 있다는 것이다. 이러한 상황이 발생하면 메모리 누수가 발생하거나 객체에 대한 참조가 남아있는데도 메모리를 잘못 해제할 수 있다. GIL은 그래서 멀티 스레드 프로그램에서 이러한 레퍼런스 카운팅에 의해 발생할 수 있는 문제를 미리 예방하고자 한다.

하나의 모델에서 업데이트된 모델이 다른 device로 매 스텝마다 복제되어야한다. 현재의 방식은 각 디바이스에서 계산된 Gradient를 하나의 디바이스로 모아서(Gather) 업데이트를 하는 방식이기 때문에 업데이트된 모델을 매번을 다른 디바이스들로 복제(Broadcast)해야하는데, 이 과정에서 많은 비용이 든다. 따라서, Gradient를 Gather하지 않고 각 디바이스에서 자체적으로 step()을 수행한다면 모델을 매번 복제하지 않아도 될 것이다.

All-reduce 연산을 통해 각 디바이스에서 계산된 Gradients를 모두 더해서 모든 디바이스에 균일하게 뿌려준다면 각 디바이스에서 자체적으로 step()을 수행할 수 있다.

하지만, All-reduce 연산 또한 매우 비용이 높다.

Distributed Data Parallelism

Data Parallelism의 문제를 개선하기 위해 등장한 데이터 병렬처리 모델으로, single/multi-node & multi-GPU에서 동작하는 multi-process 모듈이다.

동작원리는 다음과 같다.

• 각기 다른 GPU를 가진 프로세스에 모델을 복제하고, Rank 0의 프로세스가 다른 프로세스들에게 가중치를 broadcast한다.
• 각 프로세스는 DistributedSampler()를 통해 overlapping 없어 서로 다른 mini-batch data를 load한다.
• 각 프로세스의 GPU에서 Forward pass와 loss를 계산한다.
• backward 시에 각 GPU에서 gradient를 구하고 서로 all-reduce 연산을 한다.

마스터 프로세스를 사용하지 않기 때문에 특정 디바이스로 부하가 쏠리지 않고, 효율적인 방식으로 모든 디바이스의 파라미터를 동시에 업데이트하기 때문에 파라미터를 매번 replicate하지 않아도 된다는 장점을 가지고 있다.

backward()와 all-reduce를 중첩시키는 것이 가장 효율적인 방식이다. all-reduce 네트워크 통신에 해당되며, backward(), step()은 GPU 연산이기 때문에 동시에 처리할 수 있다. 이들을 중첩시키면, computation과 communication이 최대한으로 overlap되기 때문에 연산 효율이 크게 증가한다. backward 연산과 all-reduce 연산을 중첩하는 경우에 backward 연산이 뒤쪽 레이어부터 순차적으로 이루어지기 때문에 계산이 끝난 뒤쪽 레이어부터 먼저 전송하게 된다.

또 all-reduce 연산의 경우 layer마다 이루어지는 것이 아니라 Gradient Bucketing을 수행하여 bucket이 가득찰 때 수행하게 된다. Gradient bucketing은 일정한 사이즈의 bucket에 gradient를 저장해두고, 가득차면 다른 프로세스로 전송하는 방식을 말한다. backward 연산과정에서 뒤쪽부터 계산된 gradient들을 차례로 bucket에 저장하다가 bucket의 용량이 가득차면 all-reduce를 수행해서 각 디바이스에 gradient 평균 값을 계산하여 전달한다.

참고자료 https://sonstory.tistory.com/123 https://da2so.tistory.com/21 https://nbviewer.org/github/tunib-ai/large-scale-lm-tutorials/blob/main/notebooks/05_data_parallelism.ipynb https://bloofer.net/114

Towards Online Prediction

Continual Learning이 주류로 자리잡기까지는 아직 몇 년이 남았다고 생각하지만, 많은 기업들이 Online Inference로 전환하기 위해 상당한 투자를 하고 있다. 이번 글에서는 Batch Prediction System으로 시작하여 Session-based Adaptation에 유용한 배치 피처를 사용하는 간단한 온라인 예측 시스템을 구축하기 위해 필요한 것들을 살펴본다. (예: 웹사이트나 모바일 앱 내에서 사용자의 활동을 기반으로 한 예측 제공). 그런 다음, 복잡한 스트리밍 피처와 배치 피처(streaming + batch features)를 모두 활용하는 보다 성숙한 온라인 예측 시스템으로 전환하는 방법을 논의한다.

Stage 1. Batch prediction

이 단계에서는 모든 예측이 배치 단위로 사전 계산되며, 일정한 간격(예: 4시간마다 또는 하루 단위)으로 생성된다. 배치 예측의 일반적인 사용 사례는 협업 필터링(Collaborative Filtering), 콘텐츠 기반 추천(Contents-Based Recommendations)이다. 배측 예측을 사용하는 대표적인 기업으로는 2021년 기준 Netflix의 추천 시스템이 있다. 이 글을 작성하는 시점에서 Netflix는 예측 시스템을 온라인 방식으로 전환하고 있다. 배치 예측에는 여러 가지 제한사항이 있다. 예를 들어, 방문자 중 절반이 새로운 사용자이거나 로그인을 하지 않은 상태인 전자상거래 웹사이트를 생각해보자. 이 방문자들은 새로운 사용자이기 때문에 이들에게 개인화된 사전 계산 추천이 없다. 다음 배치 추천이 생성될 때까지 이 방문자들은 이미 구매 없이 사이트를 떠났을 가능성이 높다. 그 이유는 그들에게 적절한 추천이 제공되지 않았기 때문이다.

지난 10년동안 빅데이터 처리는 주로 MapReduce나 Spark와 같은 배치 시스템에 의해 지배되었다. 이러한 시스템은 대량의 데이터를 주기적으로 매우 효율적으로 처리할 수 있도록 해준다. 기업들이 머신러닝을 처음 도입했을 때, 기존의 배치 시스템을 활용해 예측 작업을 수행하기 시작했다. 그러나 오늘날 새로운 머신러닝 시스템을 구축한다면, 굳이 배치 예측을 거치지 않고 온라인 예측으로 시작하는 것이 가능하다.

Stage 2. Online prediction with batch features

이 단계에서는 요청이 도착하기 전에 예측을 생성하는 대신, 요청이 도착한 후 예측을 생성한다. 기업들은 앱에서 사용자 활동을 실시간으로 수집하지만, 이러한 이벤트는 사전 계산된 임베딩을 조회하여 세션 임베딩을 생성하는데만 사용된다. 스트리밍 데이터에서 실시간으로 피처를 계산하지는 않는다.

전자상거래 웹사이트를 예시로 들면, 새로운 방문자가 웹사이트를 방문할 때 그들에게 일반적인 아이템을 추천하는 대신, 그들의 활동을 기반으로 아이템을 추천한다. 에를 들어, 방문자가 키보드와 컴퓨터 모니터를 살펴봤다면, 이는 재택 근무 환경을 찾고 있을 가능성을 나타냅니다. 따라서 알고리즘은 HDMI 케이블이나 모니터 거치대와 같은 관련 아이템을 추천해야한다.

실시간 데이터 수집 및 세션 임베딩 생성 이를 구현하려면 방문자의 활동을 발생하는 즉시 수집하고 처리해야한다. 방문자가 아이템1, 아이템10, 아이템20을 살펴봤다면, 데이터 웨어하우스에서 해당 아이템들의 임베딩을 가져온다, 이 임베딩들은 평균값 등으로 결합되어 해당 방문자의 현재 세션 임베딩을 생성한다.

가장 관련성 높은 아이템 찾기 생성된 세션 임베딩을 기반으로 가장 관련성 높은 아이템을 찾아야한다. 단순하게는 모든 아이템을 모델로 점수화하고 가장 높은 점수를 가진 아이템을 방문자에게 보여줄 수 있다. 그러나 웹사이트에 수백만 개의 아이템이 있을 수 있으며, 모든 아이템을 점수화하는데 시간이 오래 걸릴 수 있다. 방문자가 추천 결과를 기다리게 하는 것은 바람직하지 않다.

후보 생성 대부분의 기업은 아이템-아이템 협업 필터링(collaborative filtering)이나 k-nearest neighbors와 같은 알고리즘을 사용하여 소수의 후보 아이템을 생성한다. 이후 이 후보 아이템만 점수화하며 방문자에게 가장 높은 점수의 아이템을 추천한다.

Stage 3. Online prediction with online features

온라인 예측 시스템은 Batch Features와 Online Features를 모두 사용할 수 있다.

Batch Features: 과거 데이터를 기반으로 배치 처리를 통해 추출된 피처. 주기적으로 사전 계산된다. 예측 요청 시 빠르게 조회 가능하다. 오래된 데이터를 기반으로 하므로 최신성이 부족하다.

Online Features: 최신 데이터를 기반으로 추출된 피처. Real-Time Features(예측 시 실시간으로 계산). Near Real-Time Features(사전 계산되며, 최신 데이터를 주기적으로 반영)

Real-Time Features 예측 요청이 생성되는 즉시 계산된다. 최신 데이터 반영, 지연 시간 내에서 결과를 제공한다. 항상 신선한 데이터를 기반으로 예측한다. 확장성 문제(트래픽 증가와 변동성에 따라 계산 지연이 사용자 경험에 영향을 줄 수 있다.) 복잡한 피처는 계산 시간이 길어져 지원하기 어려울 수 있다.

Near Real-Time Features(Streaming Features) 예측 요청 이전에 비동기로 계산된 피처 사용. 최신 값 조회 시 계산 지연이 없으며 복잡한 피처도 지원이 가능하다. 데이터의 신선도가 몇 초 단위로 업데이트된다. 예측 요청 시 빠른 조회 가능하다. 방문하지 않는 사용자를 위한 계산은 수행되지 않아 리소스 낭비를 방지한다. 완전한 실시간 데이터는 아니다. 사용 기술: Flink SQL, KSQL, Spark Streaming 등 스트리밍 처리 엔진

Stage2의 기업이 스트리밍 처리를 거의 사용하지 않았다면, Stage3의 기업은 스트리밍의 이점을 훨씬 더 많아질 수 있다. 예를 들어, DoorDash 사용자가 주문을 넣은 후 배달 시간을 추정하려면 다음과 같은 피처가 필요할 수 있다. 배치 피처: 이 레스토랑의 과거 평균 준비 시간 실시간 피처: 레스토랑 위치와 배달 위치 간의 거리 스트리밍 피처: 현재 레스토랑에 접수된 다른 주문 수, 앞으로 30분 동안 사용 가능한 배달원 수

Stripe, Uber, Faire와 같은 기업들이 이 단계에 있으며, 주요 사용 사례는 다음과 같다. 사기 탐지, 신용평가, 운전 및 배달 추정, 추천 시스템

Discussion: Online prediction for bandits and contextual bandits

온라인 예측은 모델이 더 정확한 예측을 할 수 있도록 할 뿐만 아니라, 밴딧 알고리즘을 활용한 온라인 모델 평가를 가능하게 한다.

밴딧 알고리즘은 도박에서 유래되었다. 카지노에는 서로 다른 보상을 주는 여러 슬롯 머신이있다. 슬롯 머신은 "one-armed bandit"으로도 알려져 있으며, 여기서 밴딧이라는 이름이 유래되었다. 슬롯 머신 중 어느 것이 가장 높은 보상을 주는지 알지 못할 때, 실험을 통해 시간이 지나면서 최적의 슬롯 머신을 찾는 동시에 보상을 극대화하려고 합니다. "multi-armed bandit"은 과거에서 가장 높은 보상을 준 슬롯 머신을 선택하는 활용(exploitation)과 더 높은 보상을 줄 가능성이 있는 다른 슬롯 머신을 선택하는 탐색(exploration) 간의 균형을 맞출 수 있도록 하는 알고리즘이다.

Bandits for model evaluation 현재 업계 표준 온라인 모델 평가 방식은 A/B 테스트이다. A/B 테스트에서는 트래픽을 각 모델로 무작위로 라우팅하고, 실험 종료 시 어떤 모델이 더 나은 성능을 보였는지 측정한다. 상태 비저장(Stateless) 방식으로, 현재 모델의 성능에 대한 정보 없이 트래픽을 라우팅할 수 있다. 배치 예측에서도 A/B 테스트를 수행할 수 있다.

밴딧 알고리즘을 활용하면, 여러 모델을 평가할 때 각 모델을 슬롯 머신으로 간주하고, 보상을 알지 못하는 상태에서 트래픽을 어떻게 라우팅할지 결정하여 최적의 모델을 찾을 수 있다. 밴딧은 상태 저장(Stateful) 방식으로, 요청을 특정 모델에 라우팅하기 전에 모든 모델의 현재 성능을 계산해야한다.

효율성 측면에서 밴딧 알고리즘은 A/B 테스트보다 훨씬 데이터 효율적이라는 점이 학계에서 잘 연구되었다. 많은 경우 밴딧은 최적의 방법으로 간주된다. 데이터 요구량 측면에서도 밴딧은 최적의 모델을 결정하기 위해 더 적은 데이터를 요구하며, 동시에 더 나은 모델로 트래픽을 빠르게 라우팅함으로써 기회 비용을 줄인다.

Contextual bandits as an exploration strategy 모델 평가를 위한 밴딧은 각 모델의 보상을 결정하는데 사용되는 반면, Contextual 밴딧은 각 행동의 보상을 결정하는데 사용된다. 추천 시스템의 경우, 행동은 사용자에게 보여줄 아이템이고 보상은 사용자가 해당 아이템을 클릭할 확률이다.

Contextual 밴딧의 예시로는, 총 10,000개의 아이템이 있는 추천 시스템이 있다고 가정한다. 한 번에 사용자에게 10개의 아이템을 추천할 수 있다. 사용자는 이 10개의 아이템에 대해 클릭 또는 비클릭으로 피드백을 제공한다. 그러나 나머지 9,990개 아이템에 대한 피드백은 받을 수 없다. 사용자가 클릭할 가능성이 가장 높은 아이템만 계속 추천하면, 결국 인기있는 아이템만 계속 추천하게 되고 이로 인해 덜 인기 있는 아이템에 대한 피드백을 받을 기회를 영원히 잃게 된다. 따라서, Contextual 밴딧은 context를 활용하여 사용자가 좋아할만한 아이템을 추천하는 활용과 아직 잘 모르는 아이템을 추천하는 탐색을 균형있게 수행한다. 동시에 최적이 아닌 행동(suboptimal actions)의 비용을 최소화한다.

하지만 구현이 어려우며, 탐색 전략은 머신러닝 모델의 아키텍처에 따라 달라지기 떄문에, 범용성이 낮다.

Towards Continual Learning

지속학습이라는 용어를 들으면 많은 사람들이 모델을 매우 자주 업데이트하는 것을 상상한다. 예를 들어 5분마다 업데이트를 실행하는 것을 떠올리곤 한다. 그러나 대부분의 사람들은 기업 대다수가 그렇게 빈번한 업데이트가 필요하지 않다고 주장한다. 그 이유는 그 정도의 재훈련 주기를 감당할 만큼의 트래픽이 없고 모델의 성능이 그렇게 빠르게 저하되지 않기 때문이다. 이 주장에 동의하지만, 지속학습은 재훈련 빈도가 아니라 모델이 재훈련되는 방식에 관한 것이다.

기존 방식: 대부분의 기업은 상태 비저장 재훈련을 수행한다. 즉, 모델을 매번 처음부터 다시 학습시킨다. 지속 학습: 상태 저장 재훈련을 하용한다. 즉, 모델이 새로운 데이터로 계속 학습(fine-tuning)을 진행한다.

지속 학습을 위한 인프라를 구축하면, 재훈련 빈도는 단순히 설정 가능한 매개변수(knob)가 된다. 한 시간에 한 번, 하루에 한 번 업데이트하거나 시스템이 데이터 분포의 변화를 감지할 때마다 모델을 업데이트할 수도 있다.

모델 업데이트의 두 가지 유형 모델 반복: 기존 모델 아키텍처에 새로운 피처를 추가하거나 모델 아키텍처 자체를 변경 데이터 반복: 동일한 모델 아키텍처와 피처를 유지하되, 새로운 데이터를 학습

현재 상태 저장학습은 데이터 반복을 의미힌다. 만약 모델 아키텍처를 변경하거나 새로운 피처를 추가한다면, 여전히 처음부터 모델을 다시 학습해야한다.

Stage1. Manual, Stateless Retraining 초기단계: 머신러닝 팀은 사기 탐지, 추천 시스템, 배달 시간 예측 등 가능한 많은 비즈니스 문제를 해결하기 위해 새로운 ML 모델 개발에 집중한다. 기존 모델 업데이트는 우선순위에서 밀려나고 모델이 너무 저조한 성능으로 오히려 부정적인 영향을 미칠 때나 팀이 업데이트 작업을 수행할 시간이 있을 때에만 이루어진다. 모델 업데이트는 수동으로 이루어지며, 임시적(ad-hoc)으로 수행된다. 대부분의 비기술 산업 분야 기업은 이 단계에 머물러있다.

Stage2. Automated Retraining 모델 재훈련이 수동 및 임시 방식에서 스크립트를 통한 자동화로 전환된다. 일반적으로 배치 처리를 통해 이루어지며, Spark와 같은 도구를 사용한다.

Stage 3. Automated, Stateful Training Stateful Training은 모델을 처음부터 재훈련하지 않고, 새로운 데이터로 기존 모델을 계속 학습(fine-tuning)하는 방식이다. 데이터와 리소스를 효율적으로 활용하면서도 모델의 성능 유지할 수 있다. 하지만 과거 데이터의 영향을 잃을 위험이 있기 때문에 정기적으로 과거 데이터를 포함한 더 큰 데이터로 모델 품징을 검증하거나 재훈련할 필요가 있다.

Stage 4. Continual Learning 지속 학습은 고정된 일정에 따라 모델을 업데이트하는 대신, 데이터 분포의 변화가 발생하거나 모델 성능이 저하되었을 때 즉시 모델을 업데이트하는 방식을 지향한다.

지속학습의 궁극적인 목표는 Edge Deployment와 결합하는 것이다. 이는 모델이 환경에 지속적으로 적응하며, 데이터 프라이버스를 강화하고 비용을 절감하며, 실시간으로 성능을 최적화할 수 있는 새로운 시대를 열 수 있다.

언어모델을 target task에 맞게 adapting하거나 finetuning하는 방법론. Finetuning Large Language Models

1. Feature-Based Approach 사전 학습된 LLM을 로드한 뒤, 대상 데이터셋에 적용하여 출력 임베딩을 생성한다. 이 임베딩은 이후 분류 모델의 입력 특징으로 사용된다. BERT처럼 임베딩 중심 모델에서 주로 사용되며 미리 계산한 임베딩을 저장해 사용하기 때문에 실용적인 시나리오에서 편리하다.

2. Finetuning1 - Updating The Output Layers Feature-Based Approach와 유사하게, 사전 학습된 LLM의 매개변수를 Freeze한다. 대신, 모델의 새로 추가된 출력 레이어만 학습한다. Feature-Based Approach와 모델 성능 및 학습 속도는 동일하지만, 사전 학습된 백본 모델은 고정되므로 효율적이다.

3. Finetuning2 - Updating All Layers 사전 학습된 LLM의 모든 레이어를 업데이트하는 방식이다. 훨씬 더 높은 계산 비용을 요구하지만, 일반적으로 더 우수한 성능을 보인다.

세 가지 방법을 성능(Y축)과 학습 효율(X축)로 나누어 살펴볼 때, 모든 파라미터를 학습하는 경우 가장 높은 성능을 기록하는 것을 확인할 수 있다.

기존의 LLM 학습 방법론2: In-Context Learning

Language Models are Few-Shot Learners Target Task에 대해 몇 가지 예시를 모델에 입력해주면 모델을 튜닝하지 않고 쉽게 문제를 풀 수 있다. (few-shot prompting)

하지만, 한 논문에서는 정확한 레이블(ground truth)이 반드시 필요하지 않다는 것을 보여준다. 데모에서 레이블을 무작위로 대체해도 분류 및 다중 선택 작업에서 성능이 거의 떨어지지 않는다. Rethinking the Role of Demonstrations:What Makes In-Context LearningWork?

PEFT

자연어처리의 중요한 패러다임 중 하나는 일반 도메인 데이터에 대한 대규모 사전 학습과 특정 task 또는 도메인에 대한 adaptation으로 구성된다. 더 큰 모델을 사전 학습할수록 모든 모델 매개변수를 다시 학습시키는 full fine-tuning은 점점 더 비현실적이 된다. Parameter-Efficient Fine-Tuning은 파라미터 수가 많은 LLM을 효울적으로 학습할 수 있는 방법이다.

다음은 가장 대표적인 네가지 접근 방식이다. A Survey of Large Language Models

LoRA

Low-Rank Adaptation은 PEFT methods 중 가장 널리 쓰이는 방법론이다. 사전 학습된 모델의 가중치를 고정하고, 각 Transformer 아키텍처 레이어에 학습 가능한 저차원(rank decomposition) 행렬을 삽입하여 다운스트림 작업을 위한 학습해야 할 매개변수 수를 크게 줄인다. LoRA는 세 가지 데이터셋 모두에서 파인튜닝 기준 성능을 맞추거나 초과한다. LoRA는 더 우수한 scalability와 task performance를 보여준다.

LoRA: Low-Rank Adaptation of Large Language Models

(IA)^3

Gradient Descent and step size

Gradient Descent

머신러닝에서 모델을 학습시킬 때, Gradient Descent(경사하강법)는 손실을 줄이기 위해 매번 최적의 방향으로 조금씩 나아가는 방식이다. (ex.산의 정상/최적의 모델 파라미터에 도달하기 위해 경사를 따라 올라가는 것)

step size

경사를 따라 이동할 때 한번에 얼마나 이동할지를 결정하는 값이 step size(학습률)이다. 이 값이 너무 작거나 크면 문제가 생길 수 있다. step size가 너무 작을 경우: 정상에 도달하는 시간이 너무 오래 걸려 학습이 비효율적이다. step sie가 너무 클 경우: 경사를 넘어가 길을 잃거나, 최적의 경로에서 벗어나 오히려 나쁜 위치로 갈 위험이 높다.

강화학습에서 학습 안정성 문제

강화학습에서는 단순히 손실을 줄이는 것이 아니라 정책을 업데이트하여 모델이 더 좋은 행동을 하도록 만든다. 하지만 gradient descent 방식만으로 다음과 같은 문제가 발생할 수 있다. 잘못된 방향으로 큰 업데이트가 이루어지면 학습이 불안정해질 수 있다. 특히 정책을 업데이트할 때 너무 크게 변하면, 모델이 예전의 행동 패턴을 완전히 잊어버리거나 성능이 크게 저하될 수 있다.

이러한 문제를 해결하기 위해 TRPO와 같은 방법로이 개발되었다.

TRPO(Trust Region Policy Optimization)

TRPO는 업데이트를 안전구역(Trust Region)으로 제한한다. 너무 큰 변화로 인해 학습이 실패하는 위험을 줄이고 정책이 조금씩 안정적으로 개선되도록 돕는다. 하지만, TRPO는 안전 구역을 계산하기 위해 복잡한 수학적 계산이 필요하다.

PPO

TRPO처럼 안전 구역을 계산하는 대신, r_t(θ) 값을 제한된 범위로 Clipping. r_t(θ)는 새로운 정책이 기존 정책과 얼마나 다른지 나타내는 비율으로, 이 값을 1 근처의 작은 범위(예. 1±𝜖)로 제한하여 정책이 너무 많이 변하지 않도록 한다. PPO는 간단한 방식으로 학습 안정석을 유지하면서도 정책을 효율적으로 업데이트할 수 있는 알고리즘이다.

참고자료 Proximal Policy Optimization Algorithms chatGPT에 사용된 RLHF와 PPO 알고리즘 뜯어보기 Proximal Policy Optimization (PPO) - How to train Large Language Models

RHLF(Reinforcement Learning from Human Feedback)

step0. 기본 GPT 모델 준비

대규모 텍스트 데이터로 사전학습된 GPT 모델을 사용한다. 이 모델은 단어를 예측하거나 문장을 생성할 수 있지만, 아직 구체적인 지시를 잘 따르지는 못한다.

step1. SFT(Supervised Fine-tuning)

사람이 작성한 답변 데이터를 준비한다. (예를 들어, 어떤 prompt에 대해 사람이 작성한 고품질의 답변을 데이터로 준비한다.) 이 데이터를 모델에 학습시켜, 사람이 작성한 답변과 유사한 답변을 생성할 수 있도록 모델을 미세조정(Fine Tuning)한다. 이렇게 만들어진 모델을 SFT(Supervised Fine-Tuned) 모델이라고 부른다.

SFT Model: 기본적으로 사람의 답변을 흉내내는 모델

step2. Reward Model(RM) 학습

1. SFT 모델로 답변을 생성한다. Step1에서 만든 SFT 모델의 여러 버전을 준비한다. 동일한 질문(prompt)을 입력하고, 각각의 SFT 모델이 생성한 다양한 답변을 수집한다.

2. 사람의 평가 데이터 생성 수집된 답변들 중에서, 사람이 어떤 답변이 더 좋은 평가하여 순위를 매긴다.

3. 쌍(pair) 데이터를 샘플링 위에서 만든 순위를 활용해, 답변 K개 중 임의로 두 개의 답변 쌍을 만든다. 두 답변 중에서 사람이 더 선호한 답변을 기준으로 모델에게 학습을 시킨다.

4. 보상 모델(RM) 학습 보상 모델(RM)은 입력된 질문(prompt)와 답변에 대해 "이 답변이 얼마나 좋은가"를 예측하는 역할을 한다. 아래의 수식에 따라, 사람이 더 선호한 답변과 그렇지 않은 답변의 차이를 예측하도록 RM을 훈련한다. rθ(x,y): 질문 x와 답변 y에 대해 보상 모델이 출력한 점수(스칼라 값). 𝑦𝑖,𝑦1−𝑖: 인간이 선호한 답변과 그렇지 않은 답변.
   이 과정을 통해 보상 모델은 어떤 답변이 더 "좋은" 답변인지 판단하는 능력을 갖추게 됩니다.

   RM: 어떤 답변이 좋은지 평가하는 모델

step3. 강화학습

1. PPO 정책 모델 초기화 step1에서 만든 SFT 모델을 기반으로 새로운 정책(policy) 모델을 초기화한다. (초기화된 모델을 기반으로 행동 규칙을 설정한다.) 이 모델은 다양한 답변을 생성하며 학습할 준비가 되어있다.
2. 답변 생성 및 평가 정책 모델은 질문(prompt)에 대해 여러가지 답변을 생성한다. 각 답변에 대해 step2에서 학습된 보상 모델(RM)이 "얼마나 좋은 답변인지" 점수(reward)를 제공한다.
3. 강화 학습 진행 모델은 RM에서 제공한 보상을 최대화하려고 노력한다. PPO 알고리즘을 사용하여, 사람이 선호할 가능성이 높은 답변을 생성하도록 모델을 강화학습한다. 이때, 학습이 지나치게 한쪽으로 치우치지 않도록 KL divergence를 사용해 SFT 모델과 차이를 제한한다. 이를 통해 모델이 안정으로 학습하면서도 더 나은 답변을 생성할 수 있도록 돕는다.

   PPO Policy Model: 실제로 질문에 대해 사람이 선호하는 답변을 생성하는 모델

RL에서의 용어정리

왜 policy(정책)이라는 용어를 사용하는가? 강화학습은 본질적으로 미래의 보상을 극대화하는 방법을 학습하는 과정이다. 이 과정에서 정책(policy)은 "결정을 내리는 규칙" 또는 "행동 방침"에 해당한다. ex. PPO 알고리즘은 "답변을 생성하는 방식(policy)"을 점진적으로 개선하여 보상을 최대화하려고 한다.

상태(state): 현재 환경의 상황정보(예. 주어진 질문 또는 프롬프트) 행동(action): 모델이 생성하는 답변이나 출력 정책(policy): 상태에 따라 행동을 결정하는 전략(예. 정책은 어떤 질문이 들어오면 어떤 방식으로 답변을 생성해야 가장 높은 보상을 받을지를 결정한다.)

참고자료 Training language models to follow instructions with humanfeedback Learning to summarize from human feedback chatGPT에 사용된 RLHF와 PPO 알고리즘 뜯어보기

abstract

LLM의 지식 업데이트가 제대로 이루어지지 않는 점과 높은 비용, 환각 문제는 지식 집약적인 작업에서 활용을 제한해왔다. 이에 대한 문제는 RAG가 도움을 줄 수 있는데, 기존 RAG 모델들은 일반적으로 쿼리와 문서 간의 유사성을 매개체로 사용하며, 정보를 검색한 후 읽는 (retrieve-then-read) 절차를 따른다.

본 연구에서는 유사성이 항상 만능 해결책이 아니며, 유사성에만 전적으로 의존할 경우 RAG의 성능이 저하될 수 있다고 주장한다. 이를 해결하기 위해 METRAG(Multi–layEred Thoughts enhanced RetrievalAugmented Generation)라는 다층적 사고를 활용한 RAG 프레임워크를 제안한다.

먼저, 기존의 유사성 지향 사고(similarity-oriented thought)를 넘어, LLM의 지도를 받아 효용성을 평가하는 소규모 효용 모델을 도입하여 효용성 지향 사고(utility-oriented thought)를 구현한다. 그리고 유사성과 효용성을 종합적으로 결합하여 더 똑똑한 모델을 설계한다.

더 나아가, 검색된 문서 집합이 방대하고 이를 개별적으로 사용하는 경우 문서들 간의 공통점과 특성을 파악하기 어렵다는 사실을 고려하여, LLM을 작업 적응형 요약기(task-adaptive summarizier)로 활용한다. 이를 통해 RAG에 간결성 지향 사고를 부여한다.

마지막으로, 이전 단계에서 얻은 다층적 사고를 기반으로, LLM을 활용한 지식 증강 생성(knowledge-augmented generation)을 수행한다.

Introduction

유사성은 항상 RAG의 만능 해결책은 아니다. 오히려 전적으로 유사성에 의존할 경우 성능이 저하될 수 있다.

예를 들어, "Tell me about author George RR Martin,"라는 쿼리를 입력했을 때, 유사성 기반 검색 시스템은 코퍼스 내 문서를 유사성 점수(semantic relevance or TFIDF)에 따라 정렬한다. 높은 유사성을 가진 문제(ex. George RR Martin is an author)는 적은 정보량에도 상위에 랭크될 수 있다. 반면, 더 유익한 정보를 담고 있지만 유사성 점수가 낮은 문서(ex. "the book set The song of Ice and Fire" is one of George RR Martin's most famous books.)는 하위에 밀릴 수 있다.

검색된 문서가 다수인 경우, LLM의 컨텍스트 제한으로 이를 개별적으로 사용하는 것이 일반적이다. 하지만 문서 간의 관계를 고려하지 않고 Top-K 문서를 단순히 결합하면 문서의 공통점과 특성을 포착하기 어려워진다. 또한 과도한 텍스트 길이로 인해 정보 손실이 발생하거나, LLM이 혼란을 겪어 성능이 저하될 수 있다.

따라서, 이 논문에서는 기존의 유사성 기반 접근을 넘어, 다층적 사고를 활용하여 RAG의 성능을 향상시키고자 한다. 여기에는 효용성 지향 사고와 간결성 지향 사고가 포함된다. 그러나 이를 구현하기 위해서는 다음과 같은 주요 도전 과제가 존재한다.

C1: 효용성 지향 사고 모델 훈련 효용성을 인식할 수 있는 모델을 훈련하려면 외부 레이블 데이터가 필요하지만 이를 얻는 것이 어렵다. LLM을 데이터 레이블링 도구로 사용할 수는 있지만, 이 과정에서 LLM의 불안정성과 통제 불가능한 특성으로 인해 성능 저하가 발생할 수 있다.

C2: 간결성 지향 사고를 가진 요약 모델 훈련 검색된 문서의 수가 많을 경우, LLM에 부하를 줄이고 문서 간의 공통점과 특성을 더 잘 포착하기 위해 문서 요약이 필요하다. 그러나 단순 요약만으로는 쿼리와 관련된 가장 중요한 정보를 보장할 수 없다. 따라서 작업에 맞게 조정된 모델이 필요하며, 이 모델은 간결성 지향 사고를 가져야한다.

제안된 접근법: METRAG 효용성 모델의 도입 LLM이 쿼리와 문서의 효용성을 판단하는 감독을 제공하도록 활용한다. 이를 통해 유사성만이 아니라 효용성 지향 사고를 갖춘 효용성 모델을 설계한다. LLM은 대부분의 경우 강력한 성능을 보이지만 가끔 통제 불가능한 경우가 있기 때문에, 안정적인 유사성 모델과 효용성 모델을 결합한다. 위의 그림과 같이 두 모델의 출력을 함께 고려한다.

간결성 지향 사고를 가진 요약 모델 훈련 강력한 교사 모델(ex. GPT-4)로부터 요약 모델을 증류(distillation)한다. 여러 요약본을 생성한 후, 보상 모델을 활용하여 요약 모델이 최종 작업에 맞게 조정되도록 추가로 제약을 가한다.

다층적 사고 시반의 지식 증강 생성 앞선 단게에서 얻은 다층적 사고(효용성과 간결성)을 활용하여 지식 증강 생성을 수행한다.

Related work

RAG는 입력 쿼리가 주어졌을 때 retrieve-then-read 파이프라인을 따라 LLM의 성능을 향상시키는 접근법이다. 이 파이프라인은 크게 두 단계로 이루어진다.

1. 문서 검색 단계: 외부 코퍼스에서 관련 문서를 검색한다.
2. 문서 활용 단계: 검색된 문서를 LLM이 최종 예측을 수행하는데 참고 정보로 활용한다.

기존 RAG 방식의 한계

1. 검색된 문서 품질의 중요성: RAG 방식의 핵심은 검색된 문서의 품질이다. 그러나 많은 기존 접근법은 유사성을 기반으로 문서를 검색하며, 이 과정에서 문서의 실제 효용을 간과하는 경향이 있다.
2. LLM에만 의존한 검색의 위험성 Self-RAG와 REPLUG와 같은 최신 방법은 LLM의 강력한 능력을 활용해 검색 능력을 강화하거나 적용형 검색을 가능하게 했다. 그러나 LLM에만 전적으로 의존하는 것은 위험할 수 있다. LLM은 본질적으로 통제 불가능한 특성을 가지므로, 이로 인해 성능 저하가 발생할 수 있다.
3. 검색된 문서 간의 관계 무시 검색된 문서들이 가지고 있는 잠재적인 내적관계를 무시하고 문서를 개별적으로 활용하는 경향이 있다. 이러한 방식은 문서 간의 시너지를 발휘하지 못하고 결과적으로 RAG 성능 저하로 이어질 수 있다.

작업 지향 요약 대규모 상용 LLM을 사용하는 것은 높은 비용을 초래하며, 데이터 유출 문제가 발생할 가능성도 있다. 이러한 이유로, 대규모 LLM(ex. ChatGPT)의 능력을 소규모 LLM(Liama2)으로 증류하여 후속 작업에서 성능을 향상시키려는 접근법들이 등장했다.

문제점

1. 단순 요약의 한계 지식 집약적 작업에서 단순한 요약은 최적의 결과를 제공하지 못한다. 단순 요약 방식은 입력 쿼리와 관련된 가장 중요한 정보를 보장할 수 없다. 따라서, 후속 작업에 적합한 요약을 생성할 수 있어야 한다.
2. RECOMP의 제한점 질문 응답 및 언어 모델링과 같은 작업에서 성능 향상을 위해 요약 모델을 훈련하려는 시도를 했다. 그러나 복잡한 샘플을 설계하고 증류를 수행하는데 초점을 맞췄을뿐, 성능 향상을 위한 추가적인 정렬 전략은 도입하지 않았고 이로 인해, RECOMP는 실제 애플리케이션에서의 성능이 저하되었다.

따라서, 단순 요약을 넘어 입력 쿼리와 관련성이 높은 정보를 효과적으로 포함하는 작업 지향 요약이 필요하며, 대규모 LLM의 증류를 통해 소규모 LLM의 능력을 강화하되, 요약 과정이 후속 작업과 잘 정렬되도록 설계된 전략이 필요하다. 이러한 접근은 질문 응답, 언어 모델링, 기타 지식 집약적 작업에서 보다 높은 성능을 보장할 수 있다.

The proposed approach

METRAG는 유사성, 효용성 간결성을 결합한 다층적 사고를 기반으로 하여, 기존 RAG 모델보다 향상된 성능을 제공한다.

3.2. A Tale of Two Models 3.2.1. similarity model as an off-the-shelf-retriever 주어진 입력 쿼리 q에 대해, off-the-shelf dense retriever R을 사용하여 입력을 저차원 임베딩 E(⋅)으로 매핑한다. 이를 통해 주어진 코퍼스 D={d_1, d_2 ,…,d_n}에서 쿼리 q와 관련된 문서를 효율적으로 검색할 수 있다. 작동방식 유사성 점수 계산: 미리 정의된 유사성 척도 M(예: 코사인 유사도 등)을 사용하여 쿼리q와 각 문서 d_i 사이의 유사성 점수를 계산한다. Top-K 문서 선택: 계산된 유사성 점수를 기반으로, 입력 쿼리 q와 가장 높은 유사성을 가진 문서 상위 k개를 선택한다. 후속 작업 강화: 선택된 D 문서들은 후속 작업(답변 생성, 정보 요약 등)을 강화하기 위한 입력 정보로 사용된다.

3.2.2. LLM의 감독을 통한 효용성 모델 강화 LLM의 강력한 능력을 활용하여 문서의 효용성에 대한 감독을 제공한다. 문서의 효용성은 쿼리에 대해 LLM이 올바른 답변을 생성하는데 기여하는 정도로 정의한다. 이를 모델링하기 위해, 특정 LLM을 사용해 정답을 생성할 확률을 정규화하여 문서의 효용성을 나타낸다.

검색기 R에 의해 쿼리 q와 가장 유사하다고 간주된 상위 n개의 문서 집합 D를 생성한다. 문서 효용성에 대한 LLM의 통찰을 검색기 R에 제공하여, 유사성 외에 문서가 제공하는 효용성도 고려하도록 학습된 효용성 모델을 생성한다.

유사성 분포를 효용성 분포로 점짐적으로 이동시키는 최적화 과정을 통해, 검색기 R가 단순히 유사성에 의존하지 않고 LLM의 감독을 반영한 효용성 지향 검색을 수행할 수 있도록 만든다.

3.2.3. Reunion of Similarity- and Utility oriented Thoughts 이 접근법을 통해 검색 성능을 최적화하면서도 RAG의 최종 결과 품질을 보장하는데 중요한 역할을 한다.

3.3. Pursuit of Compactness-oriented Thoughts Task-adaptive Summarizer는 검색된 문서들을 처리하고 LLM의 효율성을 높이기 위해 설계된 요약 모델로, 다음과 같은 기능을 제공한다. 작업 정렬 요약: 단순 요약이 아닌, 답변 생성과 같은 후속 작업에 적합한 요약을 생성한다. 이를 통해 쿼리와 관련성이 높은 정보만을 유지한다. LLM이 대량의 검색된 문서를 처리할 필요를 줄여, 계산 비용을 낮춘다. LLM 부하 감소: 요약을 통해 간결성 지향 사고를 구현하여, LLM이 중요한 정보를 더 잘 식별할 수 있도록 돕는다.

3.3.1. Distilling from Strong Teacher Models 교사 모델의 전문성 증류: GPT-4와 같은 강력한 모델의 요약 능력을 소규모 모델(Llama2)로 증류한다. 작업 지향 학습: 학생 모델은 후속 작업의 요구 사항에 맞춰 최적화된 요약 모델로, 효율적이고 적합한 요약 결과를 제공한다. LoRA 튜닝의 활용: 계산 비용을 최소화하면서도 학습 모델을 세밀히 조정하여 요약 품질을 높인다.

3.3.2 Alignment via End-task Feedback Task-adaptive summarizer가 최종 작업의 요구에 맞춰 요약을 생성하도록 정렬한다. LLM의 응답 품질을 기반으로 요약 모델의 성능을 개선한다. DPO를 활용해 보상 모델 추정 과정을 간소화하고 최적화를 효율적으로 수행한다.

METRAG라는 다층적 사고를 강화한 RAG 프레임워크를 제안한다.

1. 효용성 지향 사고 LLM의 감독을 활용하여 문서의 효용성을 평가한다. 문서의 유사성과 효용성을 결합하여 성능을 향상한다.
2. 간결성 지향 사고 Task-adaptive Summarizer를 통해 검색된 문서의 정보를 통합하고, 가장 관련성이 높은 정보를 추출한다. 이를 통해 LLM의 효율성을 높이고 방해 요소를 줄인다.
3. 지식 증강 생성 이전 단계에서 얻은 다층적 사고를 기반으로 LLM을 활용하여 최종 답변을 생성한다.

한계 효용성 모델의 LLM 의존성 효용성 모델의 성능은 강력한 LLM 감독에 크게 의존한다. 그러나 실험 결과, Llama7B나 13B와 같은 상대적으로 소규모 LLM도 만족스러운 효용성 모델을 훈련하는데 충분함을 확인했다. 복잡한 상황에서의 제한 법률 문서나 의료 문서와 같이 대량의 자료를 읽고 답변을 생성해야하는 복잡한 상황은 여전히 해결되지 않은 과제로 남아있다.

4비트 AWQ(Activation-aware Weight Quantization) 양자화를 적용한 지시 조정(instruction-tuned) 모델이다. 위 모델을 사용해서 실험을 진행하려고 했는데 아래와 같은 오류가 발생했다.

Target module WQLinear_GEMM(in_features=5120, out_features=5120, bias=True, w_bit=4, group_size=128) is not supported. Currently, only `torch.nn.Linear` and `Conv1D` are supported.

AWQ Quantization Issues로 huggingface transformers Issues를 확인해보니, AutoAWQ는 training과 함께 사용할 수 없다고 한다.

huggingface transformers Code autoawq를 확인해보아도 test_awq와 관련된 코드만 확인할 수 있었다.

LoRA(Low Rank Adaptation)

미세 조정 시에 메모리의 효율성을 개선하기 위한 방법이다. 기존 모델의 파라미터는 고정하고, 저차원 업데이트만 학습한다. 특히 LM의 경우, 모든 파라미터를 업데이트하는 것은 메모리와 계산 비용이 크기 때문에 LoRA를 통해 효율적인 미세 조정을 가능하게 한다.

peft_config = LoraConfig(
    r=self.training_config["lora"]["r"],
    lora_alpha=self.training_config["lora"]["lora_alpha"],
    lora_dropout=self.training_config["lora"]["lora_dropout"],
    target_modules=self.training_config["lora"]["target_modules"],
    bias=self.training_config["lora"]["bias"],
    task_type=self.training_config["lora"]["task_type"],
)

r: 저차원 업데이트의 차원. 이 값이 작을수록 메모리 사용량이 줄어든다. lora_alpha: LoRA의 학습률을 조절하는 파라미터 lora_dropout: 드롭아웃 확률로, 과적합을 방지하기 위해 사용. target_modules: LoRA가 적용될 모듈. ex. ["q_proj", "k_proj"] : q_proj와 k_proj는 Self-Attention Layer의 Query와 Key 생성 모듈. 이 두 모듈에 대해 LoRA를 적용하면, 효율적인 파라미터 업데이트가 가능하다. task_type: "CAUSAL_LM"으로 설정되어있다면, 이는 Auto-Regressive Language Model을 의미한다.

LoRA 설정을 통해 모델 파라미터의 일부만 업데이트함으로써 메모리 사용량과 계산 비용을 줄이면서도 높은 성능을 유지할 수 있다.

SFT(Supervised Fine-Tuning)

지도학습을 통해 모델이 특정 task에 맞게 최적화되도록 학습하는 과정이다. 프롬프트 응답생성, 텍스트 분류 등 특정 데이터와 task에 맞는 성능을 끌어올리는 것이 목적이다. SFT는 일반적으로 모델 전체의 파라미터를 업데이트하지만, LoRA와 함께 사용하면 효율적인 부분 업데이트가 가능하다.

대형 모델을 SFT로 미세 조정할 때, LoRA를 적용하면 메모리 문제를 해결하면서도 효과적인 태스크 맞춤형 학습을 할 수 있다.

1. 8bit 양자화 fp16의 이상치와 int8의 비이상치를 곱한 후, 비이상치 값을 fp16으로 다시 변환하고, 이들을 합산하여 fp16으로 가중치를 반환한다. 이렇게 하면 이상치 값이 모델 성능에 미치는 저하 효과를 줄일 수 있다.
   
2. 4bit 양자화 모델을 더욱 압축하며, QLoRA와 함께 사용하여 양자화된 대규모 언어 모델을 미세 조정하는데 흔히 사용되며, 모델 파라미터와 메모리 사용량을 크게 줄인다.

   bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",  
    bnb_4bit_use_double_quant=True,
    bnb_4bit_compute_dtype=torch.float16,
   )

   양자화 타입(bnb_4bit_quant_type)의 예로는 fp4, nf4가 있다.

• fp4(floating-point 4 bit) 4bit 부동소수점 형식. 4bit를 사용하여 값을 표현하므로, 메모리 효율성을 크게 높일 수 있다. 일부 모델에서 nf4보다 성능이 떨어질 수 있다.
• nf4(normalized float 4 bit) 데이터 분포를 고려한 양자화 방식으로, 특히 신경망의 활성화 값 분포에 맞춰 설계되었다. 일반적인 신경망의 활성화 값은 정규분포를 따르는 경우가 많은데, nf4는 이러한 분포를 반영하여 양자화된 값이 더 균일하게 분포되도록한다. fp4보다 정밀한 표현이 가능할 수 있다.
• QLoRA에서는 기본적으로 nf4가 권장된다.

bnb_4bit_use_double_quant 양자화된 데이터의 양자화 상수를 추가로 양자화하여 메모리 사용량을 줄인다. 이를 통해 파라미터당 평균 0.4비트를 추가로 절약할 수 있다.

0. 설치하기 일단, !pip install pororo를 하면 에러가 발생한다. 따라서 git clone으로 라이브러리를 가지고 온다.

   !git clone https://github.com/kakaobrain/pororo

1. 코드 수정하기 몇 가지 코드를 수정해야한다. 가장 먼저, setup.py를 아래와 같이 수정한다.

   #setup.py
   torch==1.6.0을 torch>=1.6.0으로 수정
   torchvision==0.7.0을 torchvision>=0.7.0으로 수정

   tokenizer.py 또한 아래와 같이 수정한다.

   # pororo/tasks/utils/tokenizer.py
   class CustomTokenizer(BaseTokenizer):
      def __init__(
        ...
        tokenizer.pre_tokenizer = pre_tokenizers.Metaspace(
            replacement=replacement,
            prepend_scheme="first",
            split=True,
        )
   
        tokenizer.decoder = decoders.Metaspace(
            replacement=replacement,
            prepend_scheme="first",
            split=True,
        )

   3. pip 버전 설정

      pip install "pip<24.1"

2. install

   cd pororo
   pip install .

3. import Pororo

   from pororo import Pororo
   

불안이 잠식하는 삶..."남들이 날 어떻게 볼까 '시선 염려증' 떨쳐내라"

사설 내용을 간략하게 소개하자면, 아래와 같다. 최근 불안을 다룬 책이 많이 출간되고 있다. 흔히 공포와 불안을 구분할 때 차이점은 대상이 어떤 것인가에 달려있다. 공포에는 어떤 특정한 대상이 있는 반면, 불안에는 그러한 구체적인 대상이 존재하지 않는다. 철학자들은 불안의 원인을 찾으려고 했다. 특히, 쇼펜하우어는 불안의 원인을 '남이 나를 어떻게 평가할까'에 대한 지나친 걱정에 있다고 했다. 불안의 원인이 되는 타인의 평가에 대한 우려와 병적인 집착이 없다면 "사치가 지금의 10분의 1로 줄어들지도 모른다"라고 판단했다. 모든 걱정과 근심, 안달과 성화, 불안과 긴장 등은 대부분 타인의 견해와 관계가 있기에 타인의 시선에 갇히면 누구나 죄인처럼 살아가게 된다. 이처럼 불안의 절반은 남의 평가에 지나치게 집착한 결과다. 만약 타인의 눈에 어떻게 비치느냐에 따라 사람의 가치가 결정된다면 우리의 인생은 불행할 수밖에 없다.

따라서, 우리는 타인과 나를 비교하지 말고 타인의 견해에 휘둘리지 않는 삶을 살아야 불안감뿐만 아니라 고독감, 열등감이 함께 사라진다. 우리가 타인의 평가에 노예가 되어 불안에 사로잡히지 않으려면 나의 관점에서 자신을 볼 수 있어야 한다.

나는 늘 생각한다. 남과 비교하지 말자. 나는 나다. 하지만 늘 잊게 되고 다시 비교를 시작한다. 누구는 어디에 취업을 했고 누구는 어디로 놀러 갔고 요즘에는 누구는 결혼까지 했다.

최근에 친구 결혼식을 갈 일이있었다. 너무나 축하했지만 한편으로는 나는 지금 취업 준비 중인데, 친구는 직장에서 자리도 잡고 결혼도 하는 모습을 보고 내가 지금 뭘하고있나하는 생각이 들기도 했다. 이 생각 또한 비교에서 시작되었다. 비교하지말자. 나는 나의 속도에 맞춰서 살아가면 된다.

colBERT란 dense retrieval에서 일반적으로 사용하는 벡터 임베딩 기법과 sparse retrieval의 효율성을 결합한 모델이다.

4가지 단계로 진행된다.

1. training 문서와 쿼리 사이의 의미적 유사성을 반영하는 임베딩을 학습한다. 쿼리 및 문서 임베딩: ColBERT는 쿼리와 문서를 각각 BERT를 사용해 임베딩 벡터로 변환한다. 이때 단순히 하나의 벡터로 문서나 쿼리를 표현하는 것이 아니라, 각 토큰마다 임베딩 벡터를 생성한다. 즉, 문서와 쿼리 모두 여러 개의 임베딩 벡터로 표현된다. MaxSim Loss: 훈련 시 쿼리와 문서 간의 유사도를 계산할 때, 쿼리와 문서의 각 토큰 임베딩을 비교하여 가장 유사한 토큰 페어의 유사도를 활용한다. 이를 통해 세밀한 토큰 수준에서 상호작용을 고려할 수 있다.

2. indexing 문서 컬렉션에 포함된 모든 문서의 임베딩을 미리 계산하고 저장하는 과정이다. 이 단계는 검색 시 빠른 성능을 제공하기 위해 매우 중요하다. 문서 토큰 임베딩 계산: 훈련이 완료된 ColBERT 모델을 사용해, 데이터베이스에 있는 모든 문서의 각 토큰에 대한 임베딩을 계산한다. 일반적인 dense retrieval 모델은 문서 전체를 하나의 벡터로 변환하지만, ColBERT는 각 문서의 모든 토큰에 대해 개별 임베딩 벡터를 계산한다.

3. searching 검색과정에서는 주어진 쿼리와 데이터베이스에 있는 문서들 간의 유사도를 계산해 관련 문서를 반환한다. 쿼리 토큰 임베딩 계산: 사용자가 입력한 쿼리에 대해 BERT를 사용하여 각 토큰의 임베딩 벡터를 계산한다. 이 벡터들은 인덱스에 저장된 문서 토큰 임베딩과 비교되어야 한다. 유사도 계산 및 정렬: 문서의 모든 토큰에 대해 쿼리의 모든 토큰과 비교한 후, 가장 높은 유사도를 가진 토큰 간의 매칭 결과를 기반으로 문서 전체의 유사도를 계산한다. 이 유사도를 바탕으로 관련성이 높은 문서들을 정렬하여 검색 결과로 반환한다.

4. inference reader 부분만 실행하면 된다.

실험 결과, DPR보다 colBERT의 성능이 더 우수했다. 이는 DPR이 문서나 쿼리를 단일 벡터로 표현하는 것과 달리, colBERT는 각 토큰마다 임베딩 벡터를 생성하여 문서와 쿼리를 여러 개의 임베딩 벡터로 표현함으로써 더 풍부한 문맥 정보를 반영할 수 있기 때문이라고 생각된다. 또한 BM25와 유사한 성능을 보였으며, Elastic Search를 사용한 Rerank를 Retrieval로 사용했을 때보다는 성능이 낮았다. Elastic Search의 Rerank가 colBERT보다 더 나은 성능을 보인 이유는, Rerank 과정에서 검색 결과의 품질을 추가로 향상시키고, Elastic Search가 대규모 데이터에서 더 효율적이고 최적화된 Retrieval을 제공하기 때문이라고 생각한다.

프로젝트의 마감일이 다가왔을 때 ColBERT를 사용하여 실험을 진행하였고 BM25만큼 성능이 잘 나오는 것을 확인해서 제출해보지 못한 것과 코드를 베이스라인 코드에 이식하지 못한 것이 아쉬움으로 남아있다.

우리 조가 제출기록 1등을 했다. 제출횟수도 1등을 했다. 누군가에게 제출횟수는 중요하지 않을 수 있지만, "최선"을 다하는 "과정"을 중요시하는 나에게는 대회 1등을 했다는 사실보다는 제출횟수를 1등했다는 사실이 더 기쁘게 다가왔다.