사내 지식플랫폼에 문서를 올리면 Obsidian에 뜨도록 만드는 작업이었다. 아침에 시작해 저녁까지 붙들었고, 그 사이 결함 8개를 찾았다. 전부 오류 메시지 없이 조용히 실패하는 종류였다.

무엇을 만들고 있었나

회의록 같은 문서를 웹에 올리면 LLM이 인물·조직·주제를 뽑아 지식그래프(Neo4j)에 넣는 파이프라인이다. 중간에 사람이 검토하는 단계가 있고, 그 검토를 Obsidian에서 할 수 있게 하려 했다.

웹 업로드 → 텍스트 추출 → LLM 구조화 → .md 초안 → [사람 검토] → 승인 → Neo4j
                                            ↑
                                    여기를 Obsidian으로

구조는 이랬다. 서버(Docker 컨테이너)가 vault 폴더에 파일을 쓰고, LiveSync Bridge가 CouchDB에 올리고, Obsidian 플러그인이 받아간다.

RAGFlow 컨테이너 → 서버 vault → Bridge → CouchDB → Obsidian

파일을 올렸다. Obsidian에는 뜨지 않았다. 여기서부터 시작이다.

왼쪽 웹에는 올린 파일이 다 보인다. 오른쪽 Obsidian에는 없다. 같은 폴더를 보고 있는데도.

1. 파일은 있는데 앱이 모른다

먼저 확인한 건 단순했다. 파일이 실제로 있는가?

$ ls ~/kothea-vault/Inbox/
0714 projectJ 부회장님_미팅_회의록.docx    ← 있다

있다. Obsidian은 이 폴더를 직접 열고 있었고, showUnsupportedFiles: true도 켜져 있었다. 그런데 사이드바에 없다.

판별용 파일을 두 개 만들어봤다. 하나는 터미널에서, 하나는 컨테이너에서.

터미널에서 만든 두 파일은 확장자와 무관하게 즉시 떴다. 같은 폴더에 컨테이너가 쓴 docx는 여전히 없다.

Docker Desktop for Mac의 바인드 마운트는 컨테이너가 쓴 파일에 대해 호스트로 FSEvents를 발생시키지 않는다. 파일은 분명히 폴더에 생기는데, 호스트에서 도는 앱은 그 사실을 통보받지 못한다.

사실 이 함정은 이미 한 번 밟았었다. 우리 코드의 파일 감시자에 이런 주석이 있다.

# inotify/FSEvent 대신 폴링을 쓴다. 컨테이너 바인드 마운트에서
# 파일 이벤트가 유실되는 사례가 있어서다.

서버 쪽은 폴링으로 우회했지만, Obsidian은 우리가 만든 프로그램이 아니다.

그래서 우회로를 택했다. Obsidian이 서버 폴더를 직접 보는 대신, CouchDB를 거쳐 네트워크로 받게 하는 것이다. 컨테이너끼리는 이벤트가 정상 전달되니 Bridge는 파일을 잘 감지한다. 팀원들이 원격에서 쓸 환경과 같아진다는 이점도 있었다.

이 결정이 이후 네 시간을 만들었다.

2. 한 번도 동작한 적 없는 pull

vault를 분리하고 연결했다. 여전히 안 온다. Bridge 로그를 봤다.

WATCH: START: (since:0)
WATCH: CONNECTION HAS BEEN CLOSED, RECONNECTING...
WATCH: START: (since:0)
WATCH: CONNECTION HAS BEEN CLOSED, RECONNECTING...

10초마다 재접속만 반복하고 있었다. 코드를 열어보니 Bridge는 CouchDB의 변경사항을 이렇게 받는다.

const response = await this._fetch(["_changes"], {
    filter: "replicate/pull",   // ← 이것
    feed: "continuous",
    ...

replicate/pull은 CouchDB의 design document다. 있는지 확인했다.

$ curl '.../_changes?filter=replicate/pull'
{"error":"not_found","reason":"missing"}

없다. CouchDB는 존재하지 않는 필터를 요청받으면 _changes 스트림을 즉시 끊는다. 그래서 Bridge는 영원히 재접속만 하고 있었다.

즉 CouchDB → 서버 방향 동기화가 한 번도 동작한 적이 없었다. push는 정상이라 겉보기에는 아무 문제가 없었다. 파일을 올리면 CouchDB에 잘 들어갔으니까.

이건 단순한 버그가 아니다. 설계의 핵심이 죽어 있었다는 뜻이다 — "초안을 Obsidian에서 수정하면 승인할 때 그 내용이 반영된다"가 작동한 적이 없었다.

재미있는 건, 그 필터를 만드는 함수가 Bridge 자신의 코드에 있다는 점이다.

// utils_couchdb.ts
const design = {
    "_id": "_design/replicate",
    "ver": 2,
    "filters": {
        "pull": function (doc, req) { return !(doc.type && doc.type == "leaf") }.toString(),
        ...

다만 Bridge가 실제로 쓰는 경로(DirectFileManipulator)에서는 이 함수가 호출되지 않는다. 아무도 만들지 않은 채 남아 있었다.

직접 만들어 넣으니 즉시 회복됐다.

교훈: 단방향만 되는 동기화가 가장 발견하기 어렵다. 화면상 아무 이상이 없다.

3. 언더스코어 하나가 파일을 삼킨다

pull이 살아나자 파일이 오가기 시작했다. 그런데 CouchDB를 들여다보다 이상한 걸 봤다.

서버 폴더:  _drafts/회의록.md
CouchDB:     drafts/회의록.md    ← 언더스코어가 없다

Bridge 코드를 뒤졌다.

// Peer.ts:22
const ret = (relative.startsWith("_")) ? ("/" + relative) : relative;

// Peer.ts:27
let path = pathSrc.startsWith("_") ? pathSrc.substring(1) : pathSrc;

22행은 맞다. LiveSync 규칙대로 _로 시작하는 경로에 /를 붙인다(_drafts/x.md → /_drafts/x.md).

27행이 그 역변환인데, startsWith("/")를 검사해야 할 자리에 "_"를 검사한다. 그래서 /를 떼는 게 아니라 언더스코어 자체를 잘라낸다.

결과는 이렇다.

서버는 _drafts/를 읽는데 Obsidian은 drafts/에 쓴다. Obsidian에서 고친 초안이 승인 시 반영되지 않고 조용히 사라진다.

vendored 라이브러리는 고칠 수 없으니 폴더 이름에서 언더스코어를 뺐다. 정렬 목적이었을 뿐 기능상 필요가 없었다.

4. 콜론도 삼킨다

며칠 전 회의록 파일을 올렸다. 3:31 회의록_품질책임자_챗봇_ProjectJ.docx. 안 온다.

로그를 봤더니 이렇게 찍혀 있었다.

deleteDB By path:31 ProjectJ_회의록_상세.docx
Entry removed: [DEL] 31 ProjectJ_회의록_상세.docx

원래 이름은 Attachments/3:31 ProjectJ_회의록_상세.docx다. Attachments/3:가 통째로 사라졌다.

플러그인 코드에서 찾았다.

function stripPrefix(prefixedPath){
    const [prefix, body] = prefixedPath.split(":", 2);
    return body || prefix
}

LiveSync는 문서 ID를 prefix:경로 형태로 인코딩한다. 파일명에 콜론이 있으면 그 구분자와 충돌해 앞이 잘린다. 그리고 깨진 경로로 처리가 이어지다 삭제까지 간다.

언더스코어(3장)와 콜론(4장)이 같은 뿌리다. 경로를 문자열로 인코딩하면서 구분자를 이스케이프하지 않았다. 경로에 구분자와 같은 문자가 들어오면 파싱이 어긋나는데, 오류를 내지 않고 잘린 경로로 계속 진행한다.

우리가 고칠 수 있는 건 라이브러리가 아니라 입력이다.

# ':'  LiveSync가 'prefix:경로' 구분자로 오인해 앞부분을 잘라먹는다.
# '#^[]|'  Obsidian 링크 문법 문자. 파일명에 있으면 위키링크가 깨진다.
_UNSAFE_IN_FILENAME = re.compile(r'[:/\\|#^\[\]*?<>"]')

def safe_filename(name: str) -> str:
    """확장자는 두고 이름 부분의 위험 문자만 밑줄로 바꾼다."""

회의 시각이 들어간 파일명(3:31, 10:00)은 앞으로도 계속 올라온다. 저장 시점에 막는 것이 유일하게 확실한 방법이다.

5. 증상을 보고 설정을 바꾸면 안 된다

CouchDB를 살펴보다 같은 파일이 두 벌씩 있는 걸 발견했다.

Inbox/0804 project J 내부 회의.pdf
inbox/0804 project j 내부 회의.pdf    ← 소문자

Bridge는 원본 대소문자로 쓰고, 플러그인은 handleFilenameCaseSensitive: false 설정 때문에 소문자로 정규화한다. 두 시스템이 같은 파일에 다른 ID를 부여하고 있었다.

그래서 그 설정을 true로 바꿨다. 결과는 동기화 정지였다.

Rule violation: handleFilenameCaseSensitive is true but should be false

뒤에 또 만난 같은 종류의 화면. 이 기기와 원격의 값이 다르면 플러그인이 결정을 요구한다. "이 기기에 설정 적용"이 정답이다 — 원격이 기준이다.

이 값은 개별 기기의 취향 설정이 아니라 같은 원격 DB를 쓰는 모든 기기가 공유해야 하는 계약이다. 어긋나면 플러그인이 사고를 막으려 동기화를 중단한다.

증상(중복 문서)을 보고 처방했는데, 그 증상은 두 시스템이 규칙을 달리 해석한 결과였지 설정 문제가 아니었다. 원격이 정한 값에 기기를 맞췄어야 했다.

역설적으로 이건 이날 LiveSync가 유일하게 명확한 오류 메시지를 남긴 사례다. 나머지는 전부 침묵했다.

6. 진단이 시스템을 망가뜨렸다

문제를 좁히려고 CouchDB에서 문서를 여러 번 지웠다. 콜론 문서 3건, 소문자 중복 6건, 설정 파일 10건, 테스트 잔재 7건.

그 삭제가 클라이언트에 전파됐다. 로컬 DB에 "이 경로는 삭제됨"이 tombstone으로 남았고, 이후 서버가 같은 이름으로 새 문서를 올려도 클라이언트는 자기 삭제 기록을 더 최신으로 판단해 무시했다.

전체 재수신을 걸어도 소용없다. 리비전 비교에서 삭제가 이긴다.

교훈: 진단 대상 시스템의 상태를 직접 고치면, 진단하려던 것을 진단 불가능하게 만들 수 있다. 손대야 한다면 클라이언트를 먼저 멈추고, 끝나면 클라이언트를 새로 만드는 편이 빠르다.

7. 서버 로그에 없는 답

여기까지 오는 데 세 시간이 걸렸다. 결함을 여섯 개 고쳤는데도 파일이 오지 않았다.

서버 쪽은 모든 층에서 정상이었다.

• CouchDB: 문서 6개 + 청크 690개, 참조 깨짐 0건
• 설정: Rule 위반 0건
• Bridge: 양방향 모두 동작

CouchDB 접근 로그를 요청 종류별로 세어봤다.

159  GET _all_docs      ← 대부분 내 진단용 curl
  1  GET _changes
  0  청크(h:) 다운로드   ← ?

LiveSync는 파일을 받을 때 _changes로 변경 목록을 읽고 → 청크를 내려받아 → 파일을 조립한다. 청크 요청이 0건이다. 연결은 살아 있는데 데이터를 받지 않는다.

플러그인 로그도 계속 들여다봤지만, 여기에도 "왜 멈췄는지"는 없었다. 파일을 처리했다는 줄만 반복될 뿐이었다.

포기하기 직전에 vault를 새로 만들어봤다. 그러자 대화상자가 떴다.

Review compatibility details를 눌렀다. 이날 처음으로 LiveSync가 "내가 왜 멈춰 있는지"를 스스로 말해준 화면이다.

Synchronisation paused for compatibility review

No previously acknowledged internal database version was found for this existing Vault. This can happen when a Vault is copied or restored, or when it is opened with a new Obsidian profile.

Remote replication is blocked before work begins.

LiveSync는 "이 기기가 원격 DB의 내부 버전을 승인한 적이 있는가"를 확인하고, 기록이 없으면 replication을 시작 자체를 차단한다. vault를 복사했거나 새 프로필로 열면 발생하고, 사용자가 명시적으로 Resume을 눌러야 풀린다. 대화상자를 닫으면 차단이 유지된다.

이것 하나로 증상이 전부 설명된다.

서버 로그를 아무리 뒤져도 찾을 수 없었던 이유가 여기 있다. 막힌 지점이 클라이언트 안이라 CouchDB에는 정상 요청만 찍힌다.

그 사이 나는 서버 설정만 계속 바꾸고 있었다.

8. 30줄이면 됐다

Resume을 눌렀지만 파일은 여전히 오지 않았다. 여덟 번째 결함이 있었던 것이고, 나는 여기서 멈췄다.

대신 처음 질문으로 돌아갔다. 막힌 게 정확히 무엇이었나?

"컨테이너가 쓴 파일에 대해 호스트가 파일 이벤트를 받지 못한다" — 이것 하나였다. CouchDB도 Bridge도 그걸 우회하려고 끌어들인 것이다.

그런데 이벤트가 안 오면, 만들면 된다.

def _rewrite(path: Path) -> bool:
    """경로를 잠깐 비웠다 되돌려 호스트 쪽 '생성' 이벤트를 만든다."""
    tmp = path.with_name(path.name + ".notify-tmp")
    path.rename(tmp)
    time.sleep(GAP)
    tmp.rename(path)

폴더를 주기적으로 훑어 처음 보는 파일의 이름을 잠깐 바꿨다 되돌린다. 그러면 호스트 쪽에서 파일 생성 이벤트가 발생하고, Obsidian이 인식한다.

이 30줄을 만드는 데도 네 번 고쳤다.

4번이 특히 얄궂었다. 내가 손으로 검증할 때는 이렇게 했다.

mv "$F" "$F.x" && sleep 1 && mv "$F.x" "$F"

sleep 1이 있었다. 코드에는 없었다. macOS FSEvents는 짧은 간격의 이벤트를 하나로 합치기 때문에, 삭제와 생성이 즉시 이어지면 "이름 변경"으로 병합되어 Obsidian이 새 파일로 볼 기회가 없다. 경로가 실제로 비어 있는 시간이 필요했다.

네 번 모두 수동 검증은 통과하고 코드는 실패했다. 손으로 한 것과 코드가 미묘하게 달랐던 것이다.

결국 어떻게 됐나

.md 파일은 자동으로 뜬다. .docx 원본은 끝내 안 됐다.

그런데 파이프라인에서 Obsidian이 실제로 다루는 건 .md 초안이다. .docx는 Obsidian에서 열 수도 없는 파일이라 목록에 이름이 있든 없든 하는 일이 없다.

즉 가장 오래 붙들었던 문제가 가장 덜 중요한 문제였다. 이 판단을 훨씬 일찍 했어야 했다.

같은 날 한 다른 작업 — LLM이 회의록에서 아무것도 못 뽑던 문제 — 은 두 시간 만에 해결됐고 효과가 훨씬 컸다.

원인은 두 가지였다. 출력 형식을 프롬프트로 부탁만 하고 있었던 것(→ JSON Schema로 강제), 그리고 모델이 한국어 문서에 맞지 않았던 것(qwen2.5:7b는 중국어로 답하고 날짜를 지어내고 없는 인물을 만들어냈다 → gemma3:4b).

파라미터가 절반도 안 되는 모델이 이겼다. 크기보다 언어 적합성이 결정적이었다.

남는 것

이날 만난 결함은 성격이 하나로 모인다. 전부 오류 없이 실패했다.

• Bridge의 pull은 재접속 로그만 남기고
• 경로의 언더스코어와 콜론은 말없이 잘려나가고
• 설정 플래그 하나는 아무 안내 없이 동기화를 잠재우고
• 클라이언트 게이트는 _changes까지만 읽고 멈춘다

화면에는 어느 것도 오류로 나타나지 않는다. "파일이 그냥 안 온다"로만 보인다.

이런 시스템을 다룰 때 배운 것 세 가지를 적어둔다.

1. 조용한 실패를 만들지 말 것. 우리 코드에도 같은 게 있었다.

try:
    parsed = parse_json_response(call_llm(prompt))
except Exception:
    return None          # ← 왜 폴백됐는지 아무 데도 안 남는다

이걸 고친 게 그날 가장 값어치 있는 변경일지도 모른다.

2. 우회로를 설계하기 전에, 막힌 것 하나만 직접 풀 수 없는지 먼저 묻기. 나는 파일 이벤트 하나 때문에 3계층 동기화 구조를 끌어들였고, 결국 30줄짜리 스크립트로 돌아왔다.

3. 가장 오래 붙드는 문제가 가장 중요한 문제인지 수시로 되묻기. 네 시간을 쓴 것은 파이프라인에서 가장 덜 중요한 부분이었다.

물론 그 시간이 완전히 헛되지는 않았다. 팀원 원격 접속이 필요해지면 CouchDB 경로를 다시 써야 하는데, 그때 밟게 될 지뢰가 전부 문서로 남았다.

서버에 띄워둔 Obsidian과 내 로컬 Obsidian이 항상 같은 상태로 동기화되어야 했다. 서버에서 관리되는 노트를 로컬에서도 그대로 열어 보고 편집하고, 반대로 로컬에서 고친 것도 서버에 바로 반영되는 구조가 필요했다. 이걸 self-hosted 방식(데이터를 우리가 직접 들고 있는)으로 구현하는 방법을 찾다가 Self-hosted LiveSync 플러그인에 도달했다.

결론부터 말하면 잘 된다. 다만 처음 세팅할 때 똑같은 화면에서 5번은 막혔다. 대부분 "에러처럼 보이지만 사실은 정상인 화면"을 잘못 처리해서였다. 이 글은 그 삽질 포인트까지 포함한 전체 설치 기록이다.

전체 구성

        [CouchDB 서버]  ←  노트를 저장·중계하는 동기화 허브
             ↑↓ 실시간 양방향 동기화
[서버의 Obsidian vault]      [내 로컬 Obsidian]

• CouchDB: 노트를 저장·중계하는 데이터베이스 서버 (Docker로 띄움)
• Self-hosted LiveSync: 각 Obsidian에 설치하는 커뮤니티 플러그인
• 한쪽에서 노트를 고치면 CouchDB를 거쳐 몇 초 안에 다른 쪽에도 반영된다. (기기가 더 늘어도 같은 방식으로 붙는다.)

1. CouchDB 서버 준비 (Docker)

먼저 노트를 담을 CouchDB를 띄운다. 상시 켜져 있는 서버(또는 사내 PC)에서 실행하면 된다.

docker run -d --name couchdb-livesync --restart unless-stopped \
  -e COUCHDB_USER=admin -e COUCHDB_PASSWORD=your-strong-password \
  -v ~/couchdb-livesync/data:/opt/couchdb/data \
  -v ~/couchdb-livesync/etc:/opt/couchdb/etc/local.d \
  -p 5984:5984 couchdb:latest

여기서 컨테이너를 띄우는 것만으로는 부족하다. CouchDB는 기본적으로 CORS가 꺼져 있어서, Obsidian 앱(app://obsidian.md이라는 출처)의 요청을 거부한다. 이게 나중에 "연결은 되는데 계속 실패하는" 증상의 원흉이다. 그래서 시스템 DB 초기화 + CORS 허용을 넣어준다. ($C는 http://admin:비번@서버주소:5984)

# 시스템 DB 초기화 (_users, _replicator, _global_changes)
curl -X POST $C/_cluster_setup -H "Content-Type: application/json" \
     -d '{"action":"finish_cluster"}'

# Obsidian 접속 허용 (CORS)
curl -X PUT $C/_node/_local/_config/chttpd/enable_cors -d '"true"'
curl -X PUT $C/_node/_local/_config/cors/origins \
     -d '"app://obsidian.md,capacitor://localhost,http://localhost"'
curl -X PUT $C/_node/_local/_config/cors/credentials -d '"true"'
curl -X PUT $C/_node/_local/_config/cors/methods -d '"GET, PUT, POST, HEAD, DELETE"'
curl -X PUT $C/_node/_local/_config/cors/headers \
     -d '"accept, authorization, content-type, origin, referer"'
curl -X PUT $C/_node/_local/_config/chttpd/require_valid_user -d '"true"'

💡 설정이 잘 들어갔는지는 프리플라이트로 확인할 수 있다.

curl -I -X OPTIONS $C/ -H "Origin: app://obsidian.md" \
     -H "Access-Control-Request-Method: GET"

응답에 Access-Control-Allow-Origin: app://obsidian.md가 보이면 성공.

⚠️ 외부/인터넷에 공개한다면 HTTPS(유효한 SSL 인증서)가 필수이고, 비밀번호도 반드시 강력하게. 사내망 전용이면 위 설정 그대로도 충분하다.

2. Obsidian 플러그인 설치 & 서버 연결

플러그인 설치

Obsidian 설정(Cmd/Ctrl + ,) → 커뮤니티 플러그인 → 제한 모드 해제 → 탐색에서 Self-hosted LiveSync 검색 → 설치 → 활성화. 활성화하면 설정 마법사가 자동으로 시작된다.

연결 방법 선택

연결 방법을 물어보면 「서버 정보를 수동으로 입력」을 고른다. (다른 기기에서 만든 Setup URI가 있으면 위쪽 옵션으로 더 간단히 끝낼 수 있는데, 그건 뒤에서 다룬다.)

연결 방법은 「서버 정보를 수동으로 입력」

종단 간 암호화(E2EE)

서버에 노트가 암호화되어 저장되도록 E2EE를 켜고 passphrase를 정한다. 이 passphrase는 모든 기기에서 동일하게 입력해야 하니 팀 공통값으로 정해두자. (테스트만 할 거라면 꺼도 되지만, 실사용이면 켜는 걸 권장한다.)

E2EE를 켜고 공통 passphrase 입력

서버 유형과 접속 정보

서버 유형은 CouchDB를 선택한다.

맨 위 CouchDB

이어서 접속 정보(URI, 아이디, 비밀번호, DB 이름)를 입력한다. Use Internal API는 체크하지 않는다. 그리고 Check server requirements로 서버 상태를 점검한다.

정보 입력 후 Check server requirements로 점검

점검 결과에 빨간 줄이 있으면 그 줄의 Fix 버튼을 누르면 CouchDB에 설정을 자동으로 넣어준다. 1번에서 CORS를 미리 넣었다면 대부분 초록불이다. 모두 초록이면 Create or connect to database and continue.

3. 삽질 포인트 — 여기서 5번 막혔다

삽질 ① "Fetch Remote Configuration Failed"

설정 도중 이 빨간 제목의 창이 뜬다. 처음엔 에러인 줄 알고 파란색 Retry를 계속 눌렀다. 몇 번을 눌러도 똑같이 실패한다.

이 화면에서 Retry는 함정이다

사실 이건 에러가 아니라 정상 안내다. 서버(DB)에 아직 저장된 LiveSync 설정이 없어서 "가져올 게 없다"고 알려주는 것뿐. 방금 내가 직접 설정을 넣는 중이니 당연하다.

✅ 파란 Retry가 아니라 회색 Skip and proceed를 누른다. 그러면 설정이 새로 만들어진다.

초기화 & 서버에 첫 업로드

첫 설정자(서버를 처음 채우는 사람)라면, 이 기기의 노트를 서버에 원본으로 올린다.

Restart and Initialise Server

확인 3개 체크 후 Overwrite Server (빈 서버라 안전하다)

삽질 ② "Synchronisation paused"

동기화가 호환성 확인 때문에 잠시 멈췄다는 창. 여기서도 보라색으로 강조된 버튼(Keep synchronisation paused)을 무심코 누르면 동기화가 멈춘 채로 남는다.

가운데 Resume synchronisation을 눌러야 한다

✅ 가운데 Resume synchronisation을 누른다.

4. 실시간 자동 동기화 켜기

여기까지 하면 동기화가 수동으로만 된다. 노트를 고쳐도 자동으로 안 올라가고, 화면 우하단 동기화 아이콘이 빨간색이면 실시간 모드가 꺼진 상태다. (이게 삽질 ③이었다 — "왜 저장해도 반영이 안 되지?")

플러그인 설정으로 들어간다. 설정 → 커뮤니티 플러그인 → Self-hosted LiveSync → 옵션.

플러그인 정보 화면의 「옵션」 버튼

동기화 설정 → 동기화 방법에서 Sync Mode를 LiveSync로 바꾼다. 그러면 저장하는 즉시 양방향으로 자동 동기화된다. (Keep replication active in the background도 켜두면 창이 백그라운드일 때도 동기화가 유지된다.) Sync Mode → LiveSync

Sync Mode를 LiveSync로 바꾸면 Sync on Save 같은 개별 토글이 사라지는데, 정상이다. 실시간 모드는 항상 붙어 있어서 개별 설정이 필요 없다.

5. 두 번째 기기에서 받기

이제 다른 기기(내 로컬, 또는 함께 쓰는 팀원)가 같은 서버에 붙어 노트를 받아오는 과정이다. 빈 vault에서 플러그인을 설치하고 서버에 연결하면, 상황을 묻는 화면이 나온다.

두 번째 항목 「My remote server is already set up. I want to join this device.」를 선택한다.

서버는 이미 있고, 이 기기를 참여시킴

⚠️ 첫 번째 항목(새 서버 설정/리셋)을 고르면 내 빈 vault로 서버를 덮어써서 공용 노트가 전부 날아간다. 반드시 두 번째다.

이어서 서버 데이터를 내려받는다.

Restart and Fetch Data

데이터 처리 방식은 Overwrite all with remote files(서버 것을 그대로 받기)를 선택하고,

여분 로컬 파일은 Delete local files if not on remote(서버와 똑같이 맞추기)를 선택한다. 빈 vault라 삭제될 것이 없어 안전하다.

재시작하면 서버의 노트가 이 vault로 쏟아져 내려온다. 🎉

빈 vault에 공용 노트가 자동으로 나타났다

참여자도 마지막에 Sync Mode를 LiveSync로 바꿔야 실시간이 된다. (4번 과정과 동일)

정리 — 삽질 방지 체크리스트

처음 세팅할 때 막히기 쉬운 지점만 추리면:

Setup URI로 팀 배포를 더 쉽게

팀원마다 접속 정보를 일일이 입력하게 하는 대신, 첫 설정자가 명령 팔레트(Cmd/Ctrl + P) → Copy settings as a new setup URI로 설정을 문자열 하나로 만들어 공유하면, 팀원은 그 URI를 붙여넣는 것만으로 접속 설정이 끝난다. (단, 실시간 모드는 각 기기에서 한 번씩 켜야 한다.)

CouchDB의 CORS만 제대로 잡아두면 나머지는 대부분 "정상인데 에러처럼 보이는 화면"을 침착하게 넘기는 일이다. 같은 곳에서 막힌 사람에게 이 글이 시간을 아껴주길.

CPU 343% → 30%. 원인은 클라우드에 올라간 .pyc 15만 개였다.

어느 날부터 맥북이 이상했다. 부팅하자마자 앱이 우르르 열리고, 아무것도 안 하는데 배터리가 눈에 띄게 빨리 닳았다. "부팅할 때 프로그램이 다 켜져서 그런가?" 싶어 시작한 추적이 전혀 다른 곳으로 이어졌다.

이 글은 그 과정을 막다른 길과 오판까지 포함해 그대로 기록한 것이다. 결론만 보면 세 줄이지만, 그 세 줄에 도달하기까지 몇 번이나 틀렸다.

환경: MacBook (Apple Silicon) / macOS 26 / Nextcloud · OneDrive · iCloud Drive 동시 사용

1. 증상 — 두 가지 문제, 사실은 별개였다

• A. 부팅하자마자 앱 10개 이상이 한꺼번에 열림
• B. 배터리가 비정상적으로 빨리 닳음

처음엔 A 때문에 B가 생긴 줄 알았다. 결론부터 말하면 둘은 관계가 없었다. 이걸 구분하는 데 시간이 좀 걸렸다.

2. 첫 번째 오해 — "로그인 항목"이 아니었다

앱이 자동으로 열리니 당연히 로그인 항목을 의심했다.

osascript -e 'tell application "System Events" to get the name of every login item'
# → Nextcloud

등록된 앱이 하나뿐이었다. 시스템 설정을 아무리 뒤져도 나머지 앱은 없다. 다른 경로가 있다는 뜻이다.

macOS에서 앱이 자동 실행되는 경로는 세 가지로 나뉜다.

범인은 세 번째였다.

plutil -p ~/Library/Preferences/ByHost/com.apple.loginwindow.*.plist | grep -A2 TALApps

"TALAppsToRelaunchAtLogin" => [
    "BundleID" => "com.apple.systempreferences"
    "BundleID" => "com.kakao.kakaotalkmac"
    "BundleID" => "ru.keepcoder.telegram"
    "BundleID" => "com.hnc.discord"
    "BundleID" => "com.google.chrome"
    ... 총 13개
]

TAL(Transparent App Lifecycle) — 시스템 종료 대화상자의 그 체크박스, "다시 로그인할 때 창 다시 열기"가 이 목록을 만든다. 무서운 건 이게 무차별이라는 점이다. 어제 잠깐 열어본 텍스트 편집기, 설정 확인하려고 연 시스템 설정까지 전부 기록된다.

이 목록은 로그인 후 앱을 복원하면 스스로 비워진다. 그래서 부팅 후에 확인하면 비어 있고, 다음 종료 때 다시 채워진다. 범인을 잡기 어려운 이유다.

조치

defaults write com.apple.loginwindow TALLogoutSavesState -bool false
defaults write com.apple.loginwindow LoginwindowLaunchesRelaunchApps -bool false

다만 이 키만으로 확실히 막힌다는 보장은 없었다. 확실한 건 종료 대화상자에서 체크박스를 한 번 해제하는 것이다(상태가 기억되므로 1회면 된다).

그리고 정말 필요한 앱만 골라 로그인 항목에 등록했다. 13개 → 3개.

주의: TAL을 끄면 Chrome 탭도 함께 날아간다. Chrome이 부팅 후 탭을 복원해주던 건 Chrome이 잘해서가 아니라 macOS가 Chrome을 통째로 되살려주고 있었기 때문이다. chrome://settings/onStartup에서 "중단한 위치에서 계속하기"를 켜서 Chrome 자체 복원으로 넘겨야 한다. 프로필별로 따로 설정해야 한다는 점도 함정.

여기까지가 문제 A. 이제 진짜 문제로 넘어간다.

3. 배터리 진단 — 하드웨어는 멀쩡했다

system_profiler SPPowerDataType | grep -A4 "Health Information"

Cycle Count: 53
Condition: Normal
Maximum Capacity: 100%

사이클 53회, 최대 용량 100%. 배터리는 새것이나 다름없었다. 그럼 소프트웨어가 CPU를 태우고 있다는 뜻이다.

ps -Aceo pid,pcpu,pmem,rss,etime,comm -r | head -10

  PID  %CPU %MEM    RSS ELAPSED COMM
 1296 111.8  0.7 187664   04:00 FileProviderExt
  695  49.8  0.6 156160   05:18 fileproviderd
  721  37.8  1.7 422368   05:18 corespotlightd
  494  23.3  0.2  39104   05:21 syspolicyd
  826   5.0  0.8 195824   05:16 mediaanalysisd

%CPU가 100을 넘는 건 멀티코어 합산 기준이다. 111.8%는 코어 하나를 다 쓰고도 남는다는 뜻.

FileProviderExt의 정체를 확인해보니:

ps -p 1296 -o args=
# /Applications/Nextcloud.app/Contents/PlugIns/FileProviderExt.appex/...

Nextcloud였다. 그리고 fileproviderd(macOS 파일 동기화 데몬)와 Spotlight 관련 프로세스들이 줄줄이 따라붙어 있었다. 합계 343%.

메모리도 확인했지만 여유 78%, 스왑 0바이트. 메모리 문제는 아니었다.

4. 첫 번째 실험 — Nextcloud를 꺼봤다

가장 단순한 검증. 껐다 켜서 CPU가 어떻게 변하는지 본다.

절반은 잡혔는데 fileproviderd만 오히려 올라갔다. Nextcloud 탓이 아니었다는 뜻이다.

여기서 첫 번째 교훈

처음에 나는 합계만 보고 "안 줄었네"라고 판단할 뻔했다. 실제로 뒤에서 한 번 그 실수를 한다. 프로세스별로 뜯어봐야 한다.

5. fileproviderctl dump — 26시간짜리 무한 재시도

macOS에는 File Provider 상태를 통째로 덤프하는 명령이 있다.

fileproviderctl dump > dump.txt

이게 280MB에 112만 줄이 나왔다. 이 크기 자체가 이미 단서다. 안에서 이런 걸 발견했다.

i:docID(691592) create-item: 🔶 last:'-7h10min' expired:'never' count:1
  error: NSFileProviderErrorDomain -2010
  └ BRCloudDocsErrorDomain:83 "Excluded From Sync Due To Filename"

i:docID(691567) create-item: 🔶 last:'-25h42min' expired:'never'
i:docID(691563) create-item: 🔶 last:'-25h59min' expired:'never'

BRCloudDocsErrorDomain은 iCloud Drive의 에러 도메인이다. Nextcloud가 아니라 iCloud였다.

expired: 'never' — 이게 핵심이다. 만료되지 않는 재시도. "파일 이름 때문에 동기화할 수 없다"는 파일을 26시간 동안 쉬지 않고 다시 올리려 하고 있었다. 성공할 리 없는데도.

조치: 데몬 재시작

killall fileproviderd   # launchd가 즉시 자동 재시작

결과는 극적이었다.

fileproviderd        183%  →  0.0%
corespotlightd      96.7%  →  0.0%
mds / suggestd / spotlightknowledged  →  전부 0.0%

343% → 0%. 해결한 줄 알았다.

6. 두 번째 교훈 — 재시작은 증상만 없앤다

Nextcloud를 다시 켜고 2분 만에:

FileProviderExt   86.6%
spotlightknowledged 38.9%
fileproviderd     35.8%

전부 돌아왔다. killall이 해결한 건 "재시도 루프에 갇힌 상태" 하나뿐이었고, 왜 그런 상태가 되는지는 그대로였다.

재부팅이나 데몬 재시작으로 고쳐지는 문제는, 대개 고쳐진 게 아니라 타이머가 리셋된 것이다.

7. 진짜 원인 — 클라우드에 개발 환경이 통째로 올라가 있었다

덤프에서 확장자별로 집계해봤다.

grep -oE '/[A-Za-z0-9_{}]+\.[a-z0-9]{1,10} cver' dump.txt \
  | grep -oE '\.[a-z0-9]{1,10} cver' | sed 's/ cver//' \
  | sort | uniq -c | sort -rn | head -12

176410 .jpg
156548 .py
152718 .pyc      ← Python 바이트코드 캐시
 80752 .h        ← C 헤더 (패키지 내부)
 56916 .parquet
 48712 .json
 46482 .hpp
 41524 .js

총 100만 개 이상. 그리고 실제 경로를 추적하니:

OneDrive/프로그램/eclipse-jee-2023-03-R-win32-x86_64/
    └ Windows용 Eclipse IDE 전체 (node_modules 다수)

OneDrive/프로그램/cli-11.0.0-pre.1/node_modules/
    └ npm CLI 소스 전체

OneDrive/Study/<강의명>/<venv>/lib/python3.11/site-packages/
    └ Python 가상환경 전체 — torch 포함

eclipse-...-win32-x86_64. 맥에서는 실행조차 안 되는 Windows 전용 빌드가 수만 개 파일로 동기화되고 있었다.

여기서 가장 중요한 통찰

폴더 용량은 93MB밖에 안 됐다.

du -sh ~/Library/CloudStorage/*
#  93M  Nextcloud-...
#  16M  OneDrive-...
# 3.5M  iCloud Drive

용량만 보면 아무 문제 없어 보인다. 왜냐하면 File Provider 방식은 파일 실체를 내려받지 않고 목록만 관리하기 때문이다.

부하의 실체는 용량이 아니라 항목 수다. 100만 개 파일의 "변경됐는지"를 계속 추적하는 것 자체가 비용이다. 파일이 0바이트여도 마찬가지다.

그리고 연쇄가 일어난다

클라우드가 파일 상태 갱신
   ↓
Spotlight가 "새 파일이네?" 하고 색인하려 함
   ↓
색인하려면 내용을 읽어야 하니 다운로드 요청
   ↓
File Provider가 서버에서 받아옴 → 파일이 새로 생김
   ↓
Spotlight가 또 색인 ... (무한 반복)

corespotlightd, mds, suggestd, spotlightknowledged가 함께 폭주하고 있었던 이유가 이것이다. Nextcloud 하나가 시스템 데몬 5개를 끌고 다니고 있었다.

8. 조치 두 가지

① OneDrive 선택적 동기화 해제

프로그램 폴더(Windows Eclipse + npm CLI) 동기화 해제. 서버에는 그대로 남고 이 맥에서만 안 받는다.

② Spotlight 색인에서 클라우드 폴더 제외

시스템 설정 > Spotlight > 검색 개인 정보 보호에 ~/Library/CloudStorage 추가.

~/Library는 숨김 폴더라 파일 선택창에서 ⌘⇧G로 경로를 직접 입력해야 한다.

검증:

mdfind -onlyin ~/Library/CloudStorage "kMDItemFSName == '*'" | wc -l
# → 0    (색인에서 완전히 빠짐)

9. 세 번째 교훈 — 부하 증가가 성공의 신호일 때가 있다

조치 직후 CPU가 590%까지 치솟았다.

OneDrive                    127.7%
fileproviderd               117.6%
Finder                      103.0%
suggestd                     98.4%
spotlightknowledged.updater  62.2%

실패한 줄 알고 되돌릴 뻔했다. 하지만 이건 100만 개 항목을 인덱스에서 걷어내는 일회성 청소 비용이었다.

대규모 정리 작업은 서서히 줄지 않는다. 100% 근처를 유지하다가 어느 순간 한 번에 떨어진다. 중간에 조급해져서 개입하면 오히려 처음부터 다시 시작한다.

10. suggestd의 정체 — sample로 스택을 뜬다

청소가 끝나도 suggestd 하나만 99%를 유지했다. 나는 이걸 "오늘 문제와 무관한 별개 건"이라고 두 번이나 판단했다. 틀렸다.

이 프로세스는 로그를 전혀 남기지 않았다.

log stream --predicate 'process == "suggestd"' --style compact
# (출력 없음)

이럴 때 쓰는 게 sample이다. 프로세스가 지금 어떤 함수에서 CPU를 쓰는지 스택을 떠준다.

sample $(pgrep -x suggestd) 5 -file out.txt

HVQueues informObserversToDeleteWithRequest:
 └ HVConsumerCoordinator deleteContentWithRequest:
   └ HVSpotlightDeletionRequest              ← Spotlight 삭제 요청
     └ PPLocalNamedEntityStore deleteAllNamedEntities...
       └ PPLocalTopicStore deleteAllTopics...
         └ PPRecordStorageHelper deleteAllRecordsSourcedFromBundleId:

HVSpotlightDeletionRequest. 내가 Spotlight에서 클라우드를 제외한 바로 그 작업의 후속 처리였다.

macOS는 파일을 색인할 때 목록만 만드는 게 아니라, "개인화 프로필"(Personalization Portrait) DB에 그 파일의 주제·인물·개체를 뽑아 저장한다. Siri 제안이 똑똑해지는 원리다. 그래서 색인 100만 개가 사라지면 거기 딸린 개인화 데이터 100만 건도 SQLite에서 하나씩 지워야 한다.

메모리 32MB에 CPU만 100%였던 것도 이걸로 설명된다. 대용량 로딩이 아니라 작은 레코드를 끝없이 지우는 작업이니까.

그리고 예상대로, 40분쯤 뒤 한 번에 0%가 됐다.

11. 결과

FileProviderExt가 남은 29%도 의미가 있다. Nextcloud는 똑같이 켜져 있는데 3분의 1로 줄었다. 연쇄가 끊겼기 때문이다. 예전엔 파일을 건드릴 때마다 Spotlight 4개가 따라붙었지만, 이제 혼자 조용히 돈다.

12. 시행착오 기록 — 안 통한 것들

성공한 것만 적으면 다음에 또 같은 길로 들어간다.

❌ DSDontWriteNetworkStores

.DS_Store 생성을 막는 Apple 공식 설정. 실패 항목 샘플 3건이 전부 .DS_Store여서 이게 범인인 줄 알았다.

defaults write com.apple.desktopservices DSDontWriteNetworkStores -bool true

결과: update-item 실패 1,243 → 1,247건. 변화 없음.

원인은 두 가지였다. 이 설정은 원래 SMB/AFP 네트워크 드라이브용이라 File Provider엔 통하지 않고, 무엇보다 .DS_Store는 전체 1,247건 중 41건뿐이었다. 샘플 3건을 보고 전체를 단정한 게 잘못이었다.

❌ 클라우드 폴더를 find/ls로 탐색

find ~/Library/CloudStorage/Nextcloud-* -name ".DS_Store"
# → 2분 타임아웃

ls ~/Library/CloudStorage/Nextcloud-*/어떤폴더/
# → 4초 타임아웃

File Provider 폴더는 디렉터리 목록조차 서버에 물어봐야 한다. 로컬 디스크처럼 즉시 답이 오지 않는다. 게다가 탐색 자체가 파일 다운로드를 유발해서 문제를 악화시킨다.

mdfind(Spotlight 색인 조회)는 파일에 접근하지 않아 안전하지만, 색인에서 제외한 뒤에는 당연히 0건이 나온다. 실제로 나는 이것 때문에 "Nextcloud엔 .pyc가 없다"고 잘못 판단했다가, 덤프를 보고 3만 개가 있다는 걸 뒤늦게 알았다.

❌ 합계 CPU만 보고 판단

10분 추적 로그에서 합계가 386% → 423%로 오히려 늘어난 것처럼 보였다. 그런데 프로세스별로 보니:

OneDrive File Provider   30.8% → 0.6%   ▼ 98%
corespotlightd           80.7% → 5.2%   ▼ 94%
suggestd                 98.8% → 99.3%  변화 없음  ← 이게 다 가리고 있었다

한 프로세스가 100%를 붙들고 있으면 나머지의 개선이 통째로 묻힌다.

❌ 남은 시간 추정

"5~15분이면 끝날 것"이라고 말했다가 틀렸다. 감소 추세를 가정했는데 실제로는 등락이었다. macOS는 이런 정리 작업의 진행률을 어디에도 노출하지 않는다. 근거 없는 추정은 하지 않는 게 낫다.

13. 재사용 가능한 진단 레시피

# 1. CPU 상위 프로세스 — 합계 말고 개별로 본다
ps -Aceo pid,pcpu,pmem,rss,etime,comm -r | head -15

# 2. 프로세스 정체 확인
ps -p <PID> -o args=

# 3. 배터리 하드웨어 상태 (사이클/최대용량)
system_profiler SPPowerDataType | grep -A4 "Health Information"

# 4. 잠자기 방지 요인
pmset -g assertions

# 5. 자동 실행 3종 경로
osascript -e 'tell application "System Events" to get the name of every login item'
ls ~/Library/LaunchAgents/ /Library/LaunchAgents/
plutil -p ~/Library/Preferences/ByHost/com.apple.loginwindow.*.plist

# 6. File Provider 상태 덤프 (280MB+, 2분 이상 걸림)
fileproviderctl dump > dump.txt
grep -c "🔶" dump.txt                      # 실패 항목 수
grep "expired:'never'" dump.txt | head     # 무한 재시도 탐지

# 7. 로그를 안 남기는 프로세스의 스택 추적 ★
sample <PID> 5 -file out.txt

# 8. Spotlight 색인 조회 (파일 접근 없음 — 안전)
mdfind -onlyin <path> "kMDItemFSName == '*.pyc'" | wc -l

# 9. 데몬 재시작 (launchd가 자동 복구)
killall fileproviderd
killall suggestd

특히 7번 sample은 이번에 가장 큰 도움이 됐다. 로그도 없고 이름만 봐선 뭘 하는지 알 수 없는 시스템 데몬의 정체를, 스택 한 번으로 확인할 수 있다.

14. 정리 — 배운 것

1. macOS의 앱 자동 실행은 세 갈래다. 로그인 항목만 봐서는 절대 못 찾는다. TAL 세션 복원은 무차별로 기록하고, 복원 후 스스로 목록을 비운다.

2. File Provider의 부하는 용량이 아니라 항목 수에 비례한다. 93MB 폴더가 코어 3개를 태울 수 있다. du -sh로 판단하면 안 된다.

3. 클라우드에 개발 환경을 올리지 말자. .pyc, node_modules, venv, site-packages는 전부 재생성 가능한 산출물이다. .gitignore에 넣는 것들은 클라우드 동기화에서도 빼는 게 맞다.

4. 데몬 재시작으로 고쳐진 건 대개 안 고쳐진 것이다. 원인이 남아 있으면 반드시 돌아온다.

5. 조치 직후의 부하 급증은 성공의 신호일 수 있다. 대규모 정리는 서서히가 아니라 한 번에 끝난다.

6. 합계가 아니라 개별 프로세스를 봐라. 하나가 나머지를 다 가린다.

7. 진행률이 없는 작업의 남은 시간을 추정하지 말자. 근거 없이 말하면 틀린다.

마지막으로

가장 아이러니한 건, 이 모든 게 "클라우드를 편하게 쓰려고" 한 선택의 결과였다는 점이다. 프로젝트 폴더를 통째로 동기화 폴더에 넣어두면 어디서든 이어서 작업할 수 있으니까. 그런데 그 안에 venv와 node_modules가 딸려 들어가는 순간, 파일 개수가 만 단위로 뛴다.

동기화 폴더에도 .gitignore가 필요하다. 이번에 얻은 가장 실용적인 결론이다.

Nextcloud에도 여전히 개발 파일 13만 개가 남아 있지만, 이건 의도적으로 두기로 했다. 폴더 접근성을 해치면서까지 남은 29%를 줄일 이유는 없었다. 필요해지면 sync-exclude.lst에 규칙을 추가하면 된다.

]*.pyc
]__pycache__
]venv
].venv
]site-packages
]node_modules

이러면 폴더 구조는 그대로 두고 재생성 가능한 파일만 빠진다.

이번 3강에서는 현재 가장 많은 관심을 받고 있는 초거대 언어모델에 대해 다룰 예정입니다. 특히, 오픈AI의 GPT 시리즈와 그 이후의 다양한 라지 랭귀지 모델(LLM)들에 대해 살펴보고, 이들 모델이 인공지능 연구와 개발에 어떤 영향을 미치고 있는지 논의할 것입니다.

GPT-3와 그 이후

GPT-3

GPT-3 (Generative Pre-trained Transformer 3)는 오픈AI에서 개발한 모델로, 1,750억 개의 파라미터를 가진 초거대 언어모델입니다. GPT-3는 다양한 태스크에 대해 놀라운 성능을 보이며, 번역, 요약, 코딩 등 다양한 작업을 수행할 수 있습니다. GPT-3의 등장은 기존의 특정 태스크에만 집중된 인공지능 모델과 달리, 범용 인공지능의 가능성을 열었습니다.

인스트럭트 GPT (GPT-3.5)

GPT-3 이후, 오픈AI는 인스트럭트 GPT라는 모델을 개발했습니다. 이 모델은 사용자의 지시를 더욱 잘 이해하고 따를 수 있도록 강화 학습(특히 RLHF, Reinforcement Learning from Human Feedback)을 통해 학습되었습니다. 인스트럭트 GPT는 GPT-3의 언어 이해 능력을 바탕으로, 사용자가 제공하는 지시를 유용하고 안전하게 수행할 수 있도록 설계되었습니다.

ChatGPT

ChatGPT는 인스트럭트 GPT에 대화형 사용자 인터페이스를 결합한 모델입니다. 2022년 11월에 출시되었으며, 일반 사용자들도 쉽게 접근할 수 있게 되었습니다. ChatGPT는 출시 두 달 만에 월간 활성 사용자 수(MAU) 1억 명을 돌파하며, 매우 빠른 성장세를 보였습니다.

GPT-4

GPT-4는 두 가지 주요 특징을 강조합니다: 멀티모달 처리와 인간 시험에서의 뛰어난 성능입니다. 멀티모달 처리란 텍스트뿐만 아니라 이미지를 함께 이해하고 처리할 수 있는 능력을 의미합니다. 또한 GPT-4는 변호사 시험, 대학 입학 시험 등에서 상위 20%의 성적을 기록할 정도로 높은 성능을 보입니다.

다른 초거대 언어모델들

Anthropic의 Claude

Claude는 2021년에 오픈AI를 떠난 연구진이 설립한 Anthropic에서 개발한 모델입니다. Claude는 GPT와 유사한 성능을 보이며, 지속적으로 개선되고 있습니다.

구글의 Bard

구글은 GPT에 대응하기 위해 Bard라는 모델을 개발했습니다. Bard는 구글 검색과 연동되어 사용자에게 더욱 편리한 검색 경험을 제공합니다. 구글의 팜(PaLM) 모델을 기반으로 하며, 5천억 개의 파라미터를 가진 대규모 모델입니다.

메타의 LLaMA

메타는 오픈소스 전략을 통해 LLaMA 모델을 공개했습니다. 이 모델은 다양한 사이즈로 제공되며, 학계와 산업계에서 널리 활용되고 있습니다. 메타는 이를 통해 많은 사용자 기반을 확보하고, 다양한 응용 분야에서 사용될 수 있도록 하고 있습니다.

셀프 인스트럭션 튜닝

스탠포드 대학 연구진은 메타의 LLaMA 모델을 가져와 셀프 인스트럭션 튜닝을 통해 성능을 향상시켰습니다. 이를 통해 GPT와 유사한 성능을 저렴하게 얻을 수 있으며, 다양한 응용 분야에 활용할 수 있습니다.

Vicuna

Vicuna는 LLaMA 모델을 기반으로 개발된 모델입니다. ShareGPT.com에서 수집한 50만 개의 데이터셋을 활용해 학습되었으며, 약 300달러의 비용으로 개발되었습니다. Vicuna는 높은 성능을 저렴한 비용으로 제공하는 예시로 주목받고 있습니다.

결론

초거대 언어모델의 발전은 데이터 중심의 인공지능을 더욱 강화하고 있습니다. 오픈AI의 GPT 시리즈뿐만 아니라, 구글, 메타, Anthropic 등 다양한 회사들이 경쟁하며 이 분야를 발전시키고 있습니다. 초거대 언어모델은 앞으로도 빠르게 발전할 것이며, 연구자와 개발자들에게 많은 기회를 제공할 것입니다.

지속적인 관심과 연구를 통해 초거대 언어모델의 발전과 함께할 수 있기를 바랍니다.

이 요약본은 LG Aimers Academy의 교육 내용을 바탕으로 작성되었습니다.

이번 강의에서는 오버피팅과 언더피팅의 개념에 대해 살펴볼 예정입니다. 이 두 개념은 기계학습의 목표인 일반화와 밀접한 관계가 있으며, 바이어스와 배리언스와도 깊게 연관되어 있습니다. 이를 이해하는 것이 적절한 기계학습 모델을 선택하는 데 필수적입니다.

기계학습의 포멀한 정의

기계학습에서 학습 데이터는 주어진 입력(x)과 그에 대응하는 출력(y)의 쌍으로 구성됩니다. 예를 들어, D차원의 벡터 형태의 입력과 이진 분류를 위한 출력(y)이 플러스 1 또는 마이너스 1로 주어질 수 있습니다.

모델 클래스 정의

모델 클래스는 학습 데이터에 대한 예측을 수행하기 위한 함수 형태로 정의됩니다. 예를 들어, 선형 모델을 사용할 경우, 모델은 선형 함수로 정의됩니다. 학습을 통해 모델의 파라미터가 결정되며, 이 파라미터는 학습 데이터에 대한 예측 성능을 최적화합니다.

손실 함수 (Loss Function)

손실 함수는 모델의 예측값과 실제값 사이의 차이를 수치적으로 나타내는 함수입니다. 예를 들어, 회귀 문제에서는 예측값과 실제값의 차이의 제곱을 손실로 정의할 수 있고, 분류 문제에서는 예측이 틀린 경우 손실을 1로 정의할 수 있습니다. 학습 과정에서 이 손실을 최소화하는 방향으로 모델 파라미터가 조정됩니다.

일반화의 중요성

일반화는 모델이 학습 데이터 외의 새로운 데이터에서도 좋은 성능을 보이는 능력입니다. 기계학습의 궁극적인 목표는 학습 데이터에 대한 성능이 아니라, 새로운 데이터에 대한 성능을 높이는 것입니다. 이는 오버피팅과 언더피팅과 관련이 있습니다.

오버피팅과 언더피팅

• 오버피팅: 모델이 학습 데이터에 너무 맞춰져서 새로운 데이터에 대해 성능이 떨어지는 현상입니다. 학습 데이터의 노이즈까지 학습하여 복잡한 모델이 되는 경우입니다. • 언더피팅: 모델이 학습 데이터에 충분히 맞춰지지 않아 성능이 떨어지는 현상입니다. 모델의 복잡도가 너무 낮아 데이터를 잘 설명하지 못하는 경우입니다.

일반화 오류

기계학습의 목적은 일반화 오류(Generalization Error)를 최소화하는 것입니다. 이는 모델이 보지 못한 새로운 데이터에 대해 얼마나 잘 예측하는지를 나타내는 지표입니다.

트레이닝 에러와 테스트 에러

• 트레이닝 에러: 학습 데이터에 대한 오류입니다. • 테스트 에러: 보지 못한 새로운 데이터에 대한 오류입니다.

오버피팅은 트레이닝 에러는 낮지만 테스트 에러는 높은 상황이며, 언더피팅은 트레이닝 에러와 테스트 에러 모두 높은 상황입니다.

Bias와 Variance

Bias와 Variance는 모델의 성능을 평가하는 중요한 개념입니다.

• Bias: 모델이 실제값과 얼마나 떨어져 있는지를 나타내는 지표입니다. 높은 바이어스는 모델이 단순하여 데이터의 복잡성을 잘 반영하지 못하는 경우입니다. • Variance: 모델이 얼마나 불안정하게 예측하는지를 나타내는 지표입니다. 높은 배리언스는 모델이 학습 데이터의 노이즈까지 학습하여 새로운 데이터에 대해 성능이 불안정한 경우입니다.

Bias-Variance Trade-off

Bias와 Variance는 서로 트레이드오프 관계에 있습니다. 모델의 복잡도를 높이면 Bias는 낮아지지만 Variance는 높아지고, 반대로 모델의 복잡도를 낮추면 Bias는 높아지지만 Variance는 낮아집니다.

앙상블 러닝

앙상블 러닝은 여러 개의 모델을 결합하여 바이어스와 배리언스를 모두 낮추는 방법입니다. 이를 통해 보다 안정적이고 성능이 높은 모델을 만들 수 있습니다.

정리

이번 강의에서는 오버피팅, 언더피팅, 바이어스, 배리언스의 개념과 이들 사이의 관계를 살펴보았습니다. 기계학습의 목표는 일반화 오류를 최소화하는 것이며, 이를 위해 바이어스와 배리언스를 적절히 조절하는 것이 중요합니다. 이를 위해 모델의 복잡도를 조절하고, 필요에 따라 레귤러라이제이션을 사용하는 등의 방법을 사용할 수 있습니다.

이 요약본은 LG Aimers Academy의 교육 내용을 바탕으로 작성되었습니다.

기계학습의 정의

기계학습은 인공지능의 한 분야로, 실험적으로 얻은 데이터로부터 점점 개선되는 알고리즘을 설계하고 개발하는 학문입니다. 기계학습의 목표는 데이터로부터 학습하여 성능을 향상시키는 것입니다. 이를 통해 기계학습 시스템은 주어진 작업(T)을 통해 성능 지표(P)를 개선할 수 있습니다.

• 인공지능: 사람과 같은 지능을 만들기 위한 학문. • 기계학습: 데이터로부터 스스로 개선되는 알고리즘을 다루는 학문. • 딥러닝: 신경망 기반의 기계학습의 한 분야로, 특히 깊은 신경망(Deep Neural Networks)을 사용.

기계학습의 역사

1. 허벌트 사이먼 (Herbert Simon): 기계학습을 경험을 통해 성능을 높이는 시스템이라고 정의.
2. Arthur Samuel: 체스 프로그램을 개발하면서 기계가 직접 프로그래밍 없이 학습할 수 있는 능력을 강조.
3. 탐 미첼 (Tom Mitchell): 기계학습을 T(작업), P(성능 지표), E(경험 데이터)로 정의. 이는 작업, 성능 지표, 학습 데이터를 명확히 정의함으로써 기계학습 문제를 설정.

기계학습과 전통적 프로그래밍의 비교

• 전통적 프로그래밍: 코드와 입력을 컴퓨터에 주어 결과를 도출. • 기계학습: 입력과 원하는 출력을 컴퓨터에 주어 프로그램을 생성.

예시: 스펠체킹 프로그램

• 전통적 방식: 규칙과 예외를 일일이 코드로 작성. • 기계학습 방식: 올바른 입력-출력 쌍을 학습 데이터로 주어 알고리즘이 규칙을 학습.

기계학습의 중요한 개념: 일반화

일반화란, 학습된 모델이 학습 데이터 외의 새로운 데이터에서도 좋은 성능을 보이는 능력입니다. 이는 기계학습의 핵심 목표입니다.

일반화의 예시

아이들은 다양한 나무를 보면서 공통된 특성을 파악하여 ‘나무’라는 일반적인 개념을 형성합니다. 이와 마찬가지로 기계학습 모델은 학습 데이터를 통해 패턴을 파악하여 새로운 데이터에 적용할 수 있습니다.

기계학습의 종류

1. Supervised Learning (지도학습): 입력(X)과 그에 대응하는 출력(Y)의 쌍을 학습하여 모델을 구축. 주로 분류(Classification)와 회귀(Regression) 작업에 사용.
2. Unsupervised Learning (비지도학습): 레이블이 없는 데이터(X)만을 사용하여 모델을 학습. 주로 클러스터링(Clustering)과 이상 탐지(Anomaly Detection) 작업에 사용.
3. Semi-Supervised Learning (반지도학습): 일부 데이터는 레이블이 있고, 일부는 레이블이 없는 데이터를 사용하여 학습.
4. Reinforcement Learning (강화학습): 에이전트가 환경과 상호작용하며 보상을 통해 학습.

Supervised Learning (지도학습)

• 입력(X): 예측하려는 데이터. • 출력(Y): 예측 대상 데이터. • 대표 작업: 분류(Classification), 회귀(Regression).

Unsupervised Learning (비지도학습)

• 입력(X): 레이블이 없는 데이터. • 대표 작업: 클러스터링(Clustering), 이상 탐지(Anomaly Detection), 밀도 추정(Dense Estimation).

Semi-Supervised Learning (반지도학습)

• 입력(X): 일부는 레이블이 있고, 일부는 레이블이 없는 데이터. • 레이블링: 비용과 시간 절약을 위해 일부 데이터만 레이블링.

Reinforcement Learning (강화학습)

• 에이전트와 환경: 에이전트가 환경과 상호작용하며 학습. • 보상(Reward): 에이전트의 행동에 대한 피드백으로 학습. • 예시: 바둑, 체스 등.

참고 도서

기계학습을 공부하는 데 유용한 책들을 소개합니다. 많은 책들이 온라인 튜토리얼이나 오픈소스 코드를 제공하므로 이를 활용하여 공부할 수 있습니다.

• 초보자용: 기초부터 시작하는 R 또는 Python 기반의 예제를 제공. • 심화용: 기계학습 이론과 알고리즘을 깊이 있게 다룸.

이상으로 기계학습의 정의와 종류, 기계학습과 전통적 프로그래밍의 차이, 일반화의 중요성, 기계학습의 다양한 종류, 참고 도서에 대해 살펴보았습니다. 다음 강의에서는 기계학습의 구체적인 알고리즘과 응용에 대해 다룰 예정입니다.

이 요약본은 LG Aimers Academy의 교육 내용을 바탕으로 작성되었습니다.

PCA의 동기

차원 축소의 필요성

고차원 데이터는 분석, 시각화, 모델링에 어려움을 줄 수 있습니다. 예를 들어, 2차원 데이터에서 두 번째 차원(X2)은 거의 0에 가깝고 의미가 없는 경우, 이를 무시하고 차원을 줄여 분석하는 것이 효율적입니다. PCA는 이러한 고차원 데이터를 저차원으로 축소하여 의미 있는 정보만을 남기고 분석하는 데 유용합니다.

예시

예를 들어, 집을 구매할 때 고려하는 다섯 가지 요소(집의 크기, 방의 개수, 화장실의 개수, 학교 근처 여부, 우범지역 여부)를 두 가지 요소(사이즈와 위치)로 축소하여 쉽게 결정할 수 있게 해줍니다.

PCA 알고리즘

1. 센터링(Centering): 각 데이터에서 평균을 빼서 데이터의 중심을 원점으로 이동시킵니다.
2. 스탠다드 데비에이션(Normalization): 각 차원의 분산이 1이 되도록 데이터를 정규화합니다.
3. 데이터 공분산 행렬(Covariance Matrix): 공분산 행렬을 계산하고, 이 행렬의 고유값(Eigenvalue)과 고유벡터(Eigenvector)를 구합니다.
4. 차원 축소(Target Dimension Reduction): 원하는 차원(M개)만큼 가장 큰 고유값에 해당하는 고유벡터를 선택하여 데이터를 축소합니다.
5. 프로젝션(Projection): 선택된 고유벡터 공간으로 데이터를 투영하여 저차원 데이터를 얻습니다.

데이터 공분산 행렬

데이터 공분산 행렬 ( S )는 데이터 매트릭스 X 를 이용하여 다음과 같이 정의됩니다:

S = \frac{1}{n} X X^T

이 행렬은 항상 대칭(symmetric)이고 양의 정부호(positive definite)입니다. PCA는 이 공분산 행렬의 고유값과 고유벡터를 이용하여 차원을 축소합니다.

PCA의 수학적 원리

Variance Maximization

PCA의 목표는 데이터를 저차원 공간으로 투영했을 때 분산(variance)을 최대화하는 방향을 찾는 것입니다. 이를 위해 공분산 행렬의 고유값과 고유벡터를 사용합니다. 가장 큰 고유값에 해당하는 고유벡터가 가장 중요한 주성분(principal component) 방향이 됩니다.

증명 과정

1. 기본 개념 정리: X는 원본 데이터, B는 투영 행렬, Z는 저차원 공간의 데이터입니다. Z의 분산을 최대화하는 방향을 찾는 것이 목표입니다.
2. Optimization: 주어진 공분산 행렬 S에서 가장 큰 고유값과 이에 대응하는 고유벡터를 찾습니다.
3. 수학적 증명: Lagrangian 함수와 KKT 조건을 이용하여 가장 큰 고유값과 고유벡터를 찾고, 이를 통해 최적의 투영 방향을 구합니다.

Low-Rank Approximation

PCA는 로우랭크 매트릭스 근사(low-rank matrix approximation)와 밀접한 관련이 있습니다. 에카르트-영 정리에 따르면, PCA는 주어진 데이터 매트릭스를 저차원 공간에서 가장 잘 근사하는 방법을 제공합니다.

효율적인 PCA 계산

데이터 차원이 데이터 개수보다 큰 경우, 공분산 행렬의 고유값 분해 대신 SVD(Singular Value Decomposition)를 사용하여 효율적으로 PCA를 계산할 수 있습니다. SVD는 다음과 같이 표현됩니다:

X = U \Sigma V^T

여기서 U와 V는 각각 좌우 고유벡터, \Sigma는 고유값 행렬입니다. 이를 이용하여 공분산 행렬의 고유값과 고유벡터를 효율적으로 구할 수 있습니다.

결론

PCA는 고차원 데이터를 저차원으로 축소하여 중요한 정보를 유지하면서 분석을 용이하게 합니다. 이를 통해 데이터의 시각화, 분석, 머신러닝 모델의 성능을 향상시킬 수 있습니다. 이번 강의에서는 PCA의 기본 개념, 알고리즘, 수학적 원리 및 효율적인 계산 방법을 다루었습니다.

다음 강의에서는 PCA의 응용과 더 발전된 차원 축소 기법에 대해 다룰 예정입니다. 이 요약본은 LG Aimers Academy의 교육 내용을 바탕으로 작성되었습니다.

최적화 문제의 개요

머신러닝 모델을 학습할 때, 우리는 보통 특정 목적 함수를 최소화하는 최적화 문제를 해결하게 됩니다. 이러한 최적화 문제는 크게 두 가지로 나눌 수 있습니다:

1. Unconstrained Optimization (무제약 최적화): 제약 조건이 없는 최적화 문제
2. Constrained Optimization (제약 최적화): 특정 제약 조건을 만족하면서 최적화하는 문제

Convex Optimization은 제약 조건이 있는 최적화 문제의 한 유형으로, 목적 함수와 제약 조건이 모두 볼록 함수인 경우를 말합니다.

Gradient Descent

Gradient Descent는 최적화 문제를 해결하기 위한 기본적인 방법 중 하나입니다. 이 방법은 목적 함수의 기울기를 따라 내려가며 최소값을 찾는 방식입니다. 기본 알고리즘은 다음과 같습니다:

[ \mathbf{x}_{k+1} = \mathbf{x}_k - \gamma_k \nabla f(\mathbf{x}_k) ]

여기서 (\gamma_k)는 학습률(스텝 사이즈)이고, (\nabla f(\mathbf{x}_k))는 함수 (f)의 기울기입니다. Gradient Descent는 스텝 사이즈를 잘 조절하면 함수의 로컬 옵티마로 수렴하게 됩니다.

Stochastic Gradient Descent (SGD)

SGD는 데이터의 전체 배치 대신 무작위로 선택된 작은 배치로 Gradient Descent를 수행하는 방법입니다. 이는 계산 비용을 줄이고, 큰 데이터셋에서 효율적으로 동작합니다. Mini-batch Gradient Descent는 이와 유사한 방식으로, 작은 배치를 사용하여 업데이트를 수행합니다.

Momentum Gradient Descent

Momentum Gradient Descent는 이전 업데이트 방향을 고려하여 업데이트를 가속화하는 방법입니다. 기본 아이디어는 이전 단계의 기울기 방향을 현재 단계에서도 일정 부분 반영하는 것입니다. 이를 통해 수렴 속도를 높일 수 있습니다.

Constrained Optimization

제약 조건이 있는 최적화 문제를 해결하기 위해 라그랑주 함수를 사용합니다. 라그랑주 함수는 다음과 같이 정의됩니다:

[ \mathcal{L}(\mathbf{x}, \lambda, \mu) = f(\mathbf{x}) + \sum_{i} \lambda_i g_i(\mathbf{x}) + \sum_{j} \mu_j h_j(\mathbf{x}) ]

여기서 (\lambda_i)와 (\mu_j)는 라그랑주 승수이며, 각각의 제약 조건 (g_i)와 (h_j)에 해당합니다. 이 함수는 원래의 최적화 문제를 변형하여 제약 조건을 포함한 형태로 만듭니다.

KKT 조건

KKT 조건은 제약 최적화 문제의 최적성을 확인하는 데 사용됩니다. 이 조건을 만족하면 해당 해가 최적 해임을 보장합니다. KKT 조건은 다음과 같습니다:

1. Primal feasibility: (g_i(\mathbf{x}) \leq 0), (h_j(\mathbf{x}) = 0)
2. Dual feasibility: (\lambda_i \geq 0)
3. Stationarity: (\nabla f(\mathbf{x}) + \sum_{i} \lambda_i \nabla g_i(\mathbf{x}) + \sum_{j} \mu_j \nabla h_j(\mathbf{x}) = 0)
4. Complementary slackness: (\lambda_i g_i(\mathbf{x}) = 0)

KKT 조건은 모든 제약 최적화 문제에 대해 필요 조건이며, Convex Optimization 문제에서는 충분 조건이기도 합니다.

Convex Optimization

Convex Set and Convex Function

Convex Optimization 문제는 볼록 집합(convex set)과 볼록 함수(convex function)에서 정의됩니다.

• Convex Set: 집합 내의 두 점을 잇는 선분이 항상 집합 내에 포함되는 경우
• Convex Function: 함수의 두 점을 잇는 선분의 함수값이 항상 함수의 그래프 위에 있는 경우

Convex Optimization Problem

볼록 최적화 문제는 다음과 같이 정의됩니다:

[ \min_{\mathbf{x}} f(\mathbf{x}) \quad \text{subject to} \quad \mathbf{x} \in \mathcal{C} ]

여기서 (f(\mathbf{x}))는 볼록 함수이고, (\mathcal{C})는 볼록 집합입니다.

Strong Duality

Strong Duality는 Convex Optimization 문제에서 프라이멀 문제와 듀얼 문제의 최적값이 같음을 의미합니다. 이를 통해 듀얼 문제를 풀어 프라이멀 문제의 최적값을 쉽게 찾을 수 있습니다.

결론

이번 강의에서는 Convex Optimization의 기본 개념과 이를 해결하기 위한 다양한 방법에 대해 정리하였습니다. Gradient Descent, Stochastic Gradient Descent, Momentum Gradient Descent 등 다양한 최적화 기법을 다루었고, 제약 조건이 있는 최적화 문제를 해결하기 위한 라그랑주 함수와 KKT 조건을 설명했습니다. Convex Optimization은 머신러닝 모델 학습에서 중요한 역할을 하며, 이를 이해하는 것이 좋은 모델을 만드는 데 큰 도움이 됩니다.

다음 강의에서는 Convex Optimization의 응용과 더 발전된 최적화 기법에 대해 다룰 예정입니다. 이 요약본은 LG Aimers Academy의 교육 내용을 바탕으로 작성되었습니다.

디터미넌트와 트레이스

디터미넌트

디터미넌트는 행렬의 성질을 나타내는 중요한 값 중 하나입니다. 예를 들어, 2x2 행렬의 디터미넌트는 다음과 같이 계산됩니다:

det(𝐴) = 𝑎𝑑−𝑏𝑐

이 값이 0이 아니면 행렬 A는 역행렬을 가지며, 0이면 역행렬이 존재하지 않습니다.

트레이스

트레이스는 행렬의 주대각선 요소들의 합을 의미합니다. 예를 들어, 2x2 행렬의 트레이스는 다음과 같이 계산됩니다:

tr(𝐴)=𝑎+𝑑

트레이스는 주로 행렬의 성질을 파악하거나, 행렬의 대각화 과정에서 중요한 역할을 합니다.

아이겐 디컴포지션

아이겐밸류와 아이겐벡터

아이겐밸류(고유값)와 아이겐벡터(고유벡터)는 행렬의 중요한 성질을 나타냅니다. 행렬 𝐴가 주어졌을 때, 다음 조건을 만족하는 𝜆와 𝑥를 각각 아이겐밸류와 아이겐벡터라고 합니다:

𝐴𝑥 = 𝜆𝑥

아이겐 디컴포지션은 행렬을 고유값과 고유벡터로 분해하는 방법으로, 주어진 행렬 𝐴를 다음과 같이 표현합니다:

𝐴 = 𝑃Λ𝑃 −1

여기서 𝑃는 고유벡터들로 이루어진 행렬이고, Λ는 고유값들이 대각선에 위치한 대각 행렬입니다.

초월스키 디컴포지션

초월스키 디컴포지션은 대칭 행렬을 두 개의 하삼각 행렬로 분해하는 방법입니다. 대칭 양의 정부호 행렬 𝐴는 다음과 같이 분해할 수 있습니다:

𝐴 = 𝐿𝐿^𝑇

여기서 𝐿은 하삼각 행렬입니다. 초월스키 디컴포지션을 사용하면 역행렬 계산, 행렬식 계산 등이 간단해집니다.

싱글러 밸류 디컴포지션 (SVD)

SVD의 정의

SVD는 임의의 행렬을 세 개의 행렬로 분해하는 방법입니다. 행렬 𝐴는 다음과 같이 분해됩니다:

𝐴 = 𝑈Σ𝑉^𝑇

여기서 𝑈와 𝑉는 각각 직교 행렬이고, Σ는 대각 행렬입니다. SVD는 모든 행렬에 대해 존재하며, 데이터 압축, 잡음 제거 등 다양한 응용 분야에서 사용됩니다.

SVD와 아이겐 디컴포지션의 관계

SVD는 아이겐 디컴포지션의 일반화된 형태입니다. 아이겐 디컴포지션이 대칭 행렬에만 적용되는 반면, SVD는 모든 행렬에 적용될 수 있습니다. 따라서, SVD는 더 넓은 범위의 문제에 대해 사용될 수 있습니다.

정리 및 결론

이번 강의에서는 매트릭스 디컴포지션의 기본 개념과 다양한 방법에 대해 알아보았습니다. 디터미넌트와 트레이스, 아이겐 디컴포지션, 초월스키 디컴포지션, 그리고 싱글러 밸류 디컴포지션에 대해 다루었으며, 각각의 방법이 어떤 상황에서 유용한지에 대해 정리해보았습니다.

이 요약본은 LG Aimers Academy의 교육 내용을 바탕으로 작성되었습니다.

데이터 과학의 중요성과 성공 사례

데이터 과학의 역할

데이터 과학은 디지털 전환을 성공적으로 이끄는 핵심 요소입니다. 데이터 과학자들은 다양한 데이터를 분석하고 이를 통해 유의미한 통찰을 얻어내며, 이를 바탕으로 사회적 문제를 해결하고 새로운 기회를 창출합니다.

• 예시: 서울시의 야간 버스 노선 개선은 통신사와의 협업을 통해 이루어졌습니다. 휴대전화 기지국 데이터를 활용하여 이동 인구를 분석하고 최적의 버스 노선을 설계했습니다.

데이터 과학자의 호기심과 상상력

세계적인 데이터 과학자들이 공통적으로 가지고 있는 특징은 바로 데이터에 대한 호기심과 이종 데이터를 결합하는 능력입니다.

• 뉴욕시 소통 패턴 분석: 인터넷과 전화 소통 데이터를 지리 정보와 결합하여 지역 간 소통 패턴을 분석했습니다.
• 소셜 네트워크 분석: 소셜 네트워크의 모양을 통해 사용자의 정치 성향, 선호 브랜드, 커플의 지속 가능성 등을 예측할 수 있습니다.

데이터 과학자로서의 실천 방법

끊임없는 학습과 도전

데이터 과학자는 끊임없이 변화하는 트렌드와 기술을 따라잡기 위해 지속적인 학습과 도전을 해야 합니다.

• 실리콘밸리의 사례: 구글, 아마존, 페이스북 등의 기업은 기존의 산업을 재정의하며 다양한 분야에 도전하고 있습니다. 이러한 도전 정신이 데이터 과학자에게도 필요합니다.

높은 목표 설정

페이스북에서의 경험을 바탕으로 목표 설정 방법을 공유합니다. 50%만 달성 가능성이 있는 높은 목표를 설정함으로써 더 큰 진전을 이루는 방법입니다.

• 목표 설정: 높은 목표를 세우고, 50%만 달성하더라도 성공으로 간주하는 방식으로 더 큰 성과를 이루도록 노력합니다.

협업과 멘토십

큰 성공을 위해서는 멘토와 협업할 팀을 찾는 것이 중요합니다. 다양한 관점을 가진 사람들과 함께 일함으로써 더 나은 결과를 도출할 수 있습니다.

• 레이 달리오의 성공 원칙: 목표 설정, 문제 발견, 근본 원인 분석, 극복 계획 수립, 실행의 반복을 통해 성공을 이루는 방법을 강조합니다.

데이터 과학의 사회적 기여

개발도상국의 물가 예측

UN과 협력하여 인도네시아의 물가 예측 프로그램을 개발했습니다. 소셜미디어 데이터를 활용하여 실시간 시장 가격을 예측함으로써 빈곤 문제 해결에 기여했습니다.

가짜뉴스 탐지

빅데이터와 인공지능을 활용하여 가짜뉴스를 탐지하는 방법을 연구했습니다. 네트워크에서 퍼지는 모양을 분석하여 진짜 뉴스와 가짜 뉴스를 구분합니다.

우주 항공 분야

미성 영상의 처리 기술을 통해 고해상도 주간 영상을 분석하고, 최빈국의 경제 상황이나 도시의 녹지양을 분석하는 등의 연구를 수행했습니다.

결론

데이터 과학자는 데이터에 대한 호기심과 상상력을 바탕으로 끊임없이 학습하고 도전해야 합니다. 높은 목표를 설정하고, 협업과 멘토십을 통해 더 나은 결과를 이루어낼 수 있습니다. 데이터 과학은 사회적 문제를 해결하고 새로운 기회를 창출하는 데 중요한 역할을 합니다. 여러분 모두가 데이터 과학자로서 큰 비전과 열정을 가지고 활동하길 바랍니다.

이 요약본은 LG Aimers Academy의 교육 내용을 바탕으로 작성되었습니다. 데이터 과학의 중요성과 윤리적 문제를 깊이 이해하고, 기술 발전과 함께 윤리적, 사회적 책임을 다하는 멋진 데이터 과학자가 되길 바랍니다.

AI와 창작의 만남

AI와 예술의 융합

AI는 주어진 문제에 대한 답을 잘 찾는 것으로 알려져 있습니다. 많은 직업들이 AI로 인해 대체될 가능성이 높지만, 예술과 창작 활동은 여전히 인간 고유의 영역으로 여겨졌습니다. 그러나 AI의 발전으로 이제는 예술 작품도 AI가 창작할 수 있는 시대가 되었습니다.

• 음악 창작: 스페인 말라가 대학에서 개발된 AI ‘IAMUS’는 단 6분 만에 교향곡을 작곡했습니다. 이 곡은 런던 심포니 오케스트라에 의해 연주되었으며, AI가 창작하고 인간이 연주하는 형태를 보여주었습니다.

• 문학 창작: 일본 호카이도 대학에서 개발한 AI는 SF 소설을 작성하여 호시 신이치 문학상 1차 예선을 통과하기도 했습니다.

• 시각 예술: AI 알고리즘으로 생성된 작품들이 고액에 판매되면서 예술 시장에서 큰 주목을 받고 있습니다. 예를 들어, AI가 생성한 작품을 3D 프린터로 출력하여 판매하는 등의 사례가 있습니다.

AI 창작의 윤리적 문제

AI가 창작한 작품에 대한 저작권 문제는 복잡한 윤리적, 법적 문제를 야기합니다. AI 작품의 저작권을 누구에게 부여할지, 학습에 사용된 데이터 제공자에게 어떤 권리를 줄지 등에 대한 논의가 필요합니다.

• 저작권 문제: AI가 생성한 작품에 대해 프로그래머, 데이터 제공자, 기획자 등 다양한 주체 간의 저작권 분배 문제가 발생합니다.

• 학습 데이터의 기여: 학습에 사용된 데이터의 기여도를 평가하고, 원 제작자에게 적절한 보상을 제공하는 방안 마련이 필요합니다.

• 법적 제도 부재: 현재 법적 제도는 인간만이 저작권을 가질 수 있도록 되어 있어, AI에게 저작권을 부여하는 것은 법적으로 인정되지 않습니다.

• 윤리적 문제: AI가 생성한 작품이 폭력을 조장하거나 차별을 조장하는 등의 윤리적 문제가 발생할 수 있습니다.

AI의 결정과 인간 윤리

로봇 3원칙과 자율주행 자동차

아시모프의 로봇 3원칙은 AI와 로봇의 윤리적 문제를 다루는 데 중요한 기준을 제공합니다. 그러나 자율주행 자동차와 같은 실제 사례에서는 여전히 많은 윤리적, 법적 문제가 남아 있습니다.

• 로봇 3원칙:

  1. 로봇은 인간을 다치게 해서는 안 되며, 인간이 해를 입는 것조차 방관해서는 안 된다.
  2. 로봇은 인간의 명령에 복종해야 한다. 단, 첫 번째 원칙에 위배되지 않는 한에서다.
  3. 로봇은 스스로를 보호해야 한다. 단, 첫 번째 및 두 번째 원칙에 위배되지 않는 한에서다.

• 자율주행 자동차: 자율주행 차량으로 인한 사고 발생 시, 법적 책임이 누구에게 있는지에 대한 명확한 기준이 필요합니다. 예를 들어, 자율주행 차량이 보행자를 치어 사망하게 한 사건에서 법적 책임이 운전자, 개발자, 차량 소유자 중 누구에게 있는지가 논란이 되었습니다.

Moral Machine Experiment

MIT의 Moral Machine Experiment는 자율주행 자동차의 윤리적 문제를 다루는 연구로, 다양한 윤리적 딜레마 상황에서 AI의 결정을 평가합니다.

• 트롤리 문제: 빠르게 다가오는 기차나 자동차가 멈출 수 없는 상황에서 A나 B 둘 중 하나의 길을 선택해야 하는 딜레마를 다룹니다.

• 연구 결과: 다양한 상황에서 사람들이 선택하는 윤리적 결정을 수집하여 AI의 윤리적 판단 기준을 마련하고자 했습니다.

결론

AI의 발전은 우리의 삶을 혁신적으로 변화시키고 있습니다. 그러나 AI가 창작자로서 활동하고, 자율주행 자동차와 같은 윤리적 딜레마에 직면하게 되면서, 우리는 새로운 윤리적, 법적 문제에 직면하고 있습니다.

• 저작권과 법적 제도: AI의 창작물에 대한 저작권 문제와 법적 제도의 개선이 필요합니다.

• 윤리적 기준 마련: AI의 결정이 인간의 윤리와 충돌하지 않도록 윤리적 기준을 마련해야 합니다.

• 사회적 책임: AI가 인간의 삶에 미치는 영향을 고려하여, 기술 발전과 함께 윤리적, 사회적 책임을 다하는 것이 중요합니다.

이 요약본은 LG Aimers Academy의 교육 내용을 바탕으로 작성되었습니다.

상관관계와 인과관계 구분

상관관계: 두 변수 간의 연관성. 인과관계: 하나의 변수가 다른 변수에 직접적인 영향을 미침. 예시: 초콜릿 소비와 노벨상 수상자 수의 상관관계는 있지만, 인과관계를 의미하지는 않음. 유의점: 상관관계는 반드시 인과관계를 의미하지 않음. 데이터 분석 시, 이를 명확히 구분해야 하며, 잘못된 결론을 도출하지 않도록 주의해야 함.

에러 바의 중요성

에러 바: 데이터의 신뢰도를 나타내는 시각적 가이드. 통계적 유의미성을 판단할 때 에러 바를 활용해 정확한 해석 필요. 유의점: 에러 바를 통해 데이터의 변동성을 이해하고, 이를 반영하여 신뢰할 수 있는 결론을 도출해야 함.

2. 데이터 전처리와 정제

데이터 정규화 및 아웃라이어 제거

비정상적으로 큰 값이나 작은 값을 제거해 데이터의 품질을 높임. EDA(탐색적 데이터 분석) 과정을 통해 데이터의 이상치를 찾아내고 정제함. 유의점: 데이터 정제 과정에서 발생할 수 있는 손실을 최소화하고, 분석의 정확성을 높이기 위해 데이터를 세심하게 다루어야 함.

학습 데이터의 양

언더피팅: 모델이 너무 단순해 충분히 학습되지 않은 상태. 오버피팅: 모델이 너무 복잡해 특정 데이터에만 특화된 상태. 적절한 데이터 양과 모델 복잡성을 유지해야 함. 유의점: 모델의 성능을 최적화하기 위해 데이터 양과 모델 복잡성의 균형을 맞추는 것이 중요함.

3. 블랙박스 모델의 문제점

설명력 부족

AI 모델의 내부 작동 방식을 이해하기 어려움. 예시: WCO의 탈세범 잡는 알고리즘에서 설명력이 부족해 세관원들이 신뢰하지 못했던 사례. 유의점: 블랙박스 모델의 한계를 극복하기 위해 설명력을 높이는 노력이 필요함.

설명력 향상 노력

사후 설명력: 모델의 결정 과정을 시각화해 제공. 해석 가능한 모델: 처음부터 설명 가능한 형태로 설계된 모델. 유의점: 설명 가능한 AI 모델을 통해 사용자 신뢰를 높이고, 더 나은 의사결정을 지원할 수 있음.

4. 데이터 편향 문제

인터넷 데이터 분석의 주의점

스파이럴 오브 사이런스: 소수의 강한 의견이 다수의 의견처럼 보이는 편향 현상. 오정보의 빠른 확산과 인포데믹 문제. 유의점: 데이터의 대표성과 진실성을 확보하기 위해 편향된 정보를 걸러내는 노력이 필요함.

개인정보 보호와 잊혀질 권리

개인 정보의 안전한 보관과 필요 최소한의 정보 요청. 과거의 정보가 계속 노출되지 않도록 검색 결과에서 제거하는 법적 권리. 유의점: 데이터의 보안과 개인 정보 보호를 위해 최신 법률과 규정을 준수해야 함.

5. 알고리즘의 편향 문제

콤파스 제도와 인종차별

피고의 재범률을 예측하는 콤파스 알고리즘의 인종적 편향 사례. 유의점: 알고리즘이 사회적 편향을 반영하지 않도록 데이터의 편향을 제거하고, 공정성을 확보해야 함.

채용 알고리즘의 성차별

아마존의 채용 알고리즘이 남성 중심의 데이터를 학습해 여성 지원자를 차별한 사례. 유의점: 채용 과정에서의 성차별 문제를 해결하기 위해 알고리즘의 편향을 주의 깊게 점검해야 함. 챗봇의 편향 문제 MS의 챗봇 테이가 사용자들에게 편향된 데이터를 학습해 차별적 발언을 한 사례. 유의점: 챗봇 등의 AI 서비스가 편향된 정보를 학습하지 않도록 지속적으로 모니터링하고 관리해야 함.

결론

데이터 품질 관리

데이터 확보, 전처리, 분석, 해석의 전 과정에서 주의해야 함. 데이터의 품질이 바로 알고리즘의 학습 품질을 결정하기 때문에 데이터에 대한 많은 노력을 드려야 함. 특히 오차 범위, 특이점, 대표성 문제를 항상 고민해야 함.

알고리즘의 설명력과 신뢰성

성능만 높은 것이 아니라 설명력과 신뢰성을 겸비한 알고리즘이 필요함. AI가 인간의 결정을 돕거나 대체하는 경우, 윤리적이고 사회적 규범에 맞는 의사결정을 지원할 수 있도록 노력해야 함.

편향에 대한 경각심

알고리즘이 사회적 편향을 조장하지 않도록 주의해야 함. 이를 위해 데이터의 편향을 제거하고, 공정성을 유지하는 것이 중요함.

이 요약본은 LG Aimers Academy의 교육 내용을 바탕으로 작성되었습니다. 데이터 과학과 AI 학습에서 윤리적 소양을 중요하게 여기는 모든 분들에게 도움이 되길 바랍니다.

벌써 패스트캠퍼스 AI 부트캠프 과정의 마지막 프로젝트 회고 시간이 왔다. 이 많은 프로젝트를 어떻게 쳐냈는지, 어떻게 여기까지 버텨왔는지 생각만해도 꿈만 같다. 마지막 프로젝트에서는 팀원도 한 명 더 늘었고 마지막이기도 해서 2개의 프로젝트에 참여하기로 하였다.(인간의 욕심은 끝이 없고 같은 실수를 반복하지..ㅋ) 그래도 프로젝트 기간이 4주 정도 되어서 프로젝트를 2개 참여하여도 무리 없을 거라고 생각하였다.

1. 프로젝트 개요

A. 개요

24시간 내내 운영되는 화학 공정은 이상이 발생하면 막대한 금전적 피해를 입을 수 있다. 공정 상태를 예측하고 대비책을 마련하는 것이 중요한 과제인데, 이를 위해서는 공정 데이터를 이해하고 이상 징후를 파악하는 것이 필수적이다.

본 대회는 화학 공정 데이터를 이용한 이상 탐지(anomaly detection)를 수행하여, 공정 데이터에서 비정상적인 동작을 탐지하는 것을 목표로 한다. 이를 통해 공정에서 발생할 수 있는 문제를 예측하고 대비할 수 있다.

본 대회에서 사용되는 입력 데이터와 출력 데이터는 모두 CSV 파일 형태로 제공된다. 입력 데이터로는 약 25만 개의 화학 공정 데이터가 제공되며, 이에 대응하는 약 7만 2천 개의 출력 데이터가 제공된다.

이상 탐지를 위한 알고리즘 개발은 화학 공정 분야에서 매우 중요한 과제이며, 이를 통해 공정의 안정성을 높이고 예기치 않은 문제를 예방할 수 있다는 점에서 큰 의미가 있다.

제공된 데이터셋

1. train data 250,000
2. test data 72,000

데이터셋 설명

학습 데이터는 csv 파일 형태로 제공된다. 학습 데이터에는 모두 정상 가동인 상태의 화학 공정 데이터만 포함 되어있다.

학습 데이터는 250000 개의 row와 55개의 column 으로 구성되어 있고, column 의 데이터 타입은 float 형태이다.

각 column의 의미는 다음과 같다.

• faultNumber : 정상인지, 비정상인지 나타내는 Label. 정상일 경우 '0', 비정상일 경우 '1'

• simulationRun : 시뮬레이션이 실행된 Run 의 번호 동일한 하나의 simulationRun 이 정상일 경우 faultNumber 가 모두 '0'. 반대로 하나의 simulationRun 이 비정상일 경우 faultNumber 가 모두 '1'. 학습 데이터에는 정상 데이터만 존재. 따라서 faultNumber 가 모두 '0'. 테스트 데이터에는 정상/비정상 데이터가 모두 존재. 따라서 faultNumber 가 모두 '0'인 simulationRun도 있고, faultNumber 모두 '1'인 simulationRun도 있다.

• sample : 하나의 Run 안의 sample 번호를 의미한다. 학습 데이터는 한 Run 당 500 sample 이 있다.

• xmeas_* : measurement 의 약자로, 화학 공정에서 측정된 센서 값.

• xmv_* : manipulated variable 의 약자로, 화학 공정에서 제어되는 값.

• summary : 해당 대화를 바탕으로 작성된 요약문.

B. 환경

• 팀 구성 및 컴퓨팅 환경

  7인 1팀, 인당 RTX 3090ti 서버를 VSCode와 SSH로 연결하여 사용

• 협업 환경

  Notion, GitHub

• 의사 소통

  KakaoTalk, Zoom, Slack, Discord

2. 프로젝트 팀 구성 및 역할

• 팀 구성 이번 프로젝트 팀원으로 배정된 인원은 7명 이었다. 매니저님 말씀으로는 우리 팀이 안정된 팀이고 잘 운영되고 있는 팀이라 계속 팀원을 한 명씩 추가하는 것이라고 하셨다. 나는 팀원이 좀 더 늘면 할 수 있는 Task 가 많아질 것이라 생각하였고 좋은 방향이라는 생각을 하였다.

  

• 역할

Task 목록은 다음과 같다.
> 데이터 이해 및 시각화(Data understanding and visualization)
> 통계기반 이상탐지(Statistical-based anomaly detection)
> 1인 1모델링 및 파라미터 튜닝(Individualized modeling and hyperparameter tuning)
> 결과 정리 및 보고서 작성(Summarization of Results and Report Writing)


이번 프로젝트에서는 간트차트를 적극 활용하였다. 팀원 중 한 분과 나는 간트차트 제작을 담당하기로 하였다. 처음 만들어보는 간트차트에 막막하기도 하고 구성이 잘 되지 않았었는데 우여곡절 끝에 하루를 통째로 투자한 결과 아주 만족스러운 결과가 나왔다. 막상 만들어놓으니 프로젝트 진행상황을 파악하기도 편했고 그 때, 그 때 회의록 작성하기도 좋았다. 회의에 참여하지 못한 사람이 이 간트차트의 내용만 파악해도 이해가 될 수 있도록 구성하려고 노력했던 것 같다.

3. 프로젝트 수행 절차 및 방법

A. 팀 목표 설정

1주차 : 주어진 Upstage 강의 다 듣기, train 데이터 및 test 데이터 패턴 파악하기, base line code 이해하기 2주차 : 통계 기반 이상탐지, Model 탐색 및 baseline code 작성 3주차 : 모델링, 모델 튜닝, 최종 모델 완성, 모델 고도화 4주차 : Dash Board 작성, Report 작성, PPT 제작, GitHub 관리

B. 프로젝트 사전 기획

(1) 협업 문화

1. 특별한 일을 제외하고는 항상 모여서 의논하면서 Task 진행할 것(Zoom, Discord)
2. 오프라인 모임이 가능할 경우 오프라인 만남을 적극 활용할 것(소통 Skill Up)
3. 논의 사항 및 오류 사항이 있을 경우 즉각 팀원들과 상의할 것
4. New 아이디어 발생 시 Team Notion에 작성 후 팀원 호출하여 해당 아이디어에 대해 공유할 것
5. 말하지 않아도 각자 중간 진행 상황에 대해 틈틈이 보고할 것

우리팀의 좋았던 점은 별 일 없으면 항상 온라인 소통 플랫폼에 항상 접속해 있는 것이었다. 문제가 생기면 언제든 소통이 가능했고 좋은 아이디어가 생겨도 실시간으로 바로바로 소통이 가능했다. 이 점이 팀 프로젝트 결과물을 뽑아내는 데 중요한 요소였던 것 같다. 이번에 새로 합류한 팀원께도 플랫폼 초대 링크를 보내어 참석할 수 있도록 하였다. 우리 팀은 기존의 Zoom 플랫폼 보다 Discord 활용을 더 많이 한 것 같다. 팀원이 많았기 때문에 다양한 시도를 해볼 수 있었다. 항상 매일 Meeting을 통해 그 날 그 날 할 일에 대해 계획을 수립하였고 수립한 계획을 Notion에 작성하였다. 그리고 다 진행된 내용에 대해서는 check 표시를 하여 모두가 진행 상황을 알 수 있도록 기록으로 남겨두었다. 우리 팀은 1인 1모델링을 하기로 했었으므로 7가지의 모델 중 1가지의 모델을 심도있게 공부하여 팀원들과 공유하는 시간을 가지기도 하였다.

4. 프로젝트 수행 결과

Public - Final Result(F1 score : 0.9204)

Private -Final Result(F1 score : 0.9091)

결론적으로 K-Means 모델링 결과가 가장 좋게 나왔다. 나는 DBSCAN을 담당하였는데, 모델을 공부할 당시 DBSCAN은 K-Means 모델의 단점을 개선한 모델이라 더 명확한 구분이 가능하다는 장점을 소개한 내용을 확인했었다. 하지만 막상 모델링을 해보니 그렇지 않았다. DBSCAN은 밀도 기반 클러스터링이므로 애초에 화학공정 이상 탐지 데이터와는 특성이 맞지 않은 모델이었던 것 같다.

5. 자체 평가 의견

A. 잘했던 점

• 각자 하나의 모델을 심도있게 파보는 시간을 가졌다. 모델 고도화에 초점을 맞췄던 점이 좋았다.
• 각자의 다양한 관점을 실시간으로 공유하여 함께 진행하는 프로젝트 분위기를 만들고자 하였다.
• 간트차트를 활용하여 프로젝트 진행 상황을 보기 좋게 정리하고자 하였다.

B. 시도 했으나 잘 되지 않았던 것들

• DBSCAN 모델을 고도화 시키기 위해 정말 많은 방법을 시도해보았다. DBSCAN의 Hyperparameter는 epsilon과 Minpts 로 2가지가 있다. 나는 elbow point를 고려하여 epsilon 값을 설정하고 강의에서 MinPts는 주로 4이하의 값으로 쓴다는 이야기를 반영하여 Hyperparameter 설정을 해보았지만 결과는 크게 달라지지 않았다. Hyperparameter 값을 수정하면서 Clustering 수를 늘려보아도 이상치들이 너무 많이 검출되었고, 완벽하게 clustering 되지 않는 결과를 보였다.

C. 아쉬웠던 점들

• 1인 1모델을 담당했던 점이 좋기도 하면서 아쉬운 점이기도 했다. 우리는 대회를 2개를 참여하는 팀이었기에 한 대회에만 목을 맬 수 없는 상황이었다. 하지만 각자의 모델을 지정하고 해당 모델을 고도화 시키는 방법을 선택하니 그 모델 이외에 다른 모델을 도전해볼 시간이 부족하였다. 데이터를 먼저 확인하고 데이터에 맞는 모델을 선택하여 고도화 시키는 방법을 선택했으면 더 좋은 결과를 산출할 수 있지 않았을까 하는 아쉬움이 남는다.

D. 프로젝트를 통해 배운 점 또는 시사점

• 멘토링 해주신 멘토님의 말씀이 기억에 남는다. "아무 근거 없이 모델을 선택하여 그 모델을 바탕으로 데이터를 분석하기 보다는 먼저 데이터 분석을 완벽히한 후 해당 데이터에 맞는 모델을 선택하는 과정이 필요하며, 그 과정이 굉장히 중요하다"는 말씀을 하셨다. 이번 대회를 통해서 모델을 세부적으로 공부하는 시간을 가졌으니 다음 대회에서는 데이터 파악에 좀 더 힘을 실어야겠다는 생각을 하게 되었다.

마무리

드디어 길고 길었던 AI 부트캠프 과정이 끝이 났다. 마지막 대회여서 시원 섭섭하기도 하고 뿌듯하기도 하고 그렇지만 아쉬운 부분이 굉장히 많이 남는다. 여기서 배웠던 모든 과정들 그리고 훌륭하신 멘토님과 강사님께서 해주신 말씀들을 잘 새겨 담아 실무에서 유능하게 써먹을 수 있는 사람이 되도록 노력할 것이다.

#패스트캠퍼스 #UpstageAILab #Upstage #부트캠프 #AI #데이터분석 #데이터사이언스 #인공지능개발자 #ML #머신러닝 #경진대회 #딥러닝 #NLP

앞서 작성한 Anomaly Detection과 겹치는 내용이 많기에 상당 부분 생략될 수 있음을 미리 말씀 드리고자 한다.

1. 프로젝트 개요

A. 개요

LLM의 등장 이후 여러 산업 분야에서 지식을 다루는 업무들이 점점 고도화되고 있다.

특히 정보를 찾기 위해 검색엔진의 입력창에 키워드를 입력하고 결과를 확인하고 원하는 정보가 없으면 다른 키워드로 다시 검색하기를 반복하는 번거로운 과정을 이제 더이상 자주 할 필요가 없어졌다.

이제 LLM한테 물어보면 질문의 의도까지 파악해서 필요한 내용만 잘 정리해서 알려 준다.

그렇지만 LLM이 가진 근본적인 한계도 있다.

먼저, 정보라는 것은 의미나 가치가 시간에 따라 계속 변하기 때문에 모델이 이를 실시간으로 학습하기 힘들고 이 때문에 아래 예시처럼 knowledge cutoff 가 자연스럽게 발생한다.

그리고 LLM이 알려주는 지식이 항상 사실에 기반한 것이 아닌 경우가 종종 있다. 특히 특정 도메인이나 문제 영역은 매우 심각한 거짓 정보들을 생성해 내곤 한다. 아래 예시에서 추천하는 맛집들은 모두 실재하지 않는 장소들이다.

이러한 환각 현상은 메타인지를 학습하지 않은 LLM의 근본적인 한계라 볼 수 있다.

모델은 학습 과정에서 정보를 압축해서 저장하기 때문에 정보의 손실이 발생할 수밖에 없고, 이 때문에 특정 입력 조건에 대해서는 사실 여부보다는 지식를 표현하는 국소적인 패턴이 더 큰 영향을 주면서 답변이 생성될 수 있기 때문이다.

이러한 문제를 극복하기 위해서는 RAG(Retrieval Augmented Generation) 기술이 필수이다.

RAG는 질문에 적합한 레퍼런스 추출을 위해 검색엔진을 활용하고 답변 생성을 위해 LLM(Large Language Model)을 활용한다.

이때 LLM은 스스로 알고 있는 지식을 출력하기보다는 언어 추론 능력을 극대화하는 것에 방점을 둔다.

이렇게 사실에 기반한 지식 정보를 토대로 질문에 답을 하고 출처 정보도 같이 줄 수 있기 때문에 사용자는 훨씬 더 안심하고 정보를 소비할 수 있게 된다.

이번 대회에서는 과학 상식을 질문하는 시나리오를 가정하고 과학 상식 문서 4200여개를 미리 검색엔진에 색인해 둔다.

대화 메시지 또는 질문이 들어오면 과학 상식에 대한 질문 의도인지 그렇지 않은 지 판단 후에 과학 상식 질문이라면 검색엔진으로부터 적합한 문서들을 추출하고 이를 기반으로 답변을 생성한다. 

만일 과학 상식 이외의 질문이라면 검색엔진을 활용할 필요 없이 적절한 답을 바로 생성한다.

마지막으로, 본 프로젝트는 모델링에 중점을 둔 대회가 아니라 RAG(Retrieval Augmented Generation) 시스템의 개발에 집중하고 있다. 이 대회는 여러 모델과 다양한 기법, 그리고 앙상블을 활용하여 모델의 성능을 향상시키는 일반적인 모델링 대회와는 다르다. 대신에 검색 엔진이 올바른 문서를 색인했는지, 그리고 생성된 답변이 적절한지 직접 확인하는 것이 중요한 대회이다.

따라서, 참가자들은 작은 규모의 토이 데이터셋(10개 미만)을 사용하여 초기 실험을 진행한 후에 전체 데이터셋에 대한 평가를 진행하는 것을 권장한다. 실제로 RAG 시스템을 구축할 때에도 이러한 방식이 일반적으로 적용되며, 이를 통해 실험을 더욱 효율적으로 진행할 수 있다. 따라서 이번 대회는 2주간 진행되며, 하루에 제출할 수 있는 횟수가 5회로 제한된다.

자, 이제 여러분만의 RAG 시스템을 구축하러 가보실까~?

출처: Upstage(AI Stages)

제공된 데이터셋

과학 상식 정보를 담고 있는 순수 색인 대상 문서 4200여개(학습 데이터 별도 제공 X)

파일 포맷은 각 line이 json 데이터인 jsonl 파일이다.

학습 데이터 설명

이번 대회는 머신러닝 모델을 학습하는 것 보다는 임베딩 생성 모델, 검색엔진, LLM 등을 활용하여 레퍼런스를 잘 추출하고 이를 토대로 얼마나 답변을 잘 생성하는지 판단하는 대회이다.

따라서 모델 학습을 위한 학습데이터를 별도로 제공하지 않고, 과학 상식 정보를 담고 있는 순수 색인 대상 문서 4200여개가 제공된다. 

문서의 예시는 아래와 같다. 'doc_id'에는 uuid로 문서별 id가 부여되어 있고 'src'는 출처를 나타내는 필드이다. 그리고 실제 RAG에서 레퍼런스로 참고할 지식 정보는 'content' 필드에 저장되어 있다.

참고로  데이터를 Open Ko LLM Leaderboard에 들어가는 Ko-H4 데이터 중 MMLU, ARC 데이터를 기반으로 생성했기 때문에 출처도 두가지 카테고리를 가진다.

B. 환경

• 팀 구성 및 컴퓨팅 환경

  7인 1팀, 인당 RTX 3090ti 서버를 VSCode와 SSH로 연결하여 사용

• 협업 환경

  Notion, GitHub

• 의사 소통

  KakaoTalk, Zoom, Slack, Discord

2. 프로젝트 팀 구성 및 역할

• 팀 구성 IR 대회도 AD 대회와 마찬가지로 7명이서 진행하였다. 공식적으로 등록된 건 AD 3명, IR 4명 이었지만 모두가 함께 2개의 대회에 참여하였다. 이 중 나는 공식적으로는 IR 팀에 배정되어 대회에 참여하게 되었다. IR도 AD와 동일하게 간트차트를 작성하여 Task 구성을 한 눈에 보기 좋게 구성하였다. 나는 IR 간트차트를 담당하게 되었었는데 처음 간트차트를 접하고 구성하느라 하루를 통째로 투자하였던 것 같다. 덕분에 결과물은 보기 좋게 나온 것 같아 만족스러웠다.

  

• 역할

Task 목록은 다음과 같다.
> Information Retrieval 공부하기 및 강의 듣기
> 데이터 확인 및 분류(Data Verification)
> 프롬프트 엔지니어링(Prompt Engineering)
> 모델링 및 파라미터 튜닝(Modeling and Parameter Tuning)
> 결과 정리 및 보고서 작성(Summarization of Results and Report Writing)


IR은 모두가 처음 접해보는 분야기도 하고 아직 다른 교육 과정에서 쉽게 접할 수 없는 내용이어서 개인적으로 공부하는 시간을 오래가졌다. 이 분야는 RAG 실습만 짜여진대로 잘 따라하고 짜여진 baseline code만 잘 이해해도 반 이상은 얻어가는 분야라는 이야기가 많았다. 처음 나의 목표는 '짜여진 Baseline code라도 잘 이해해서 얻어가자' 였다. 

3. 프로젝트 수행 절차 및 방법

A. 팀 목표 설정

1주차 : 주어진 Upstage 강의 다 듣기, Data 구성 확인하기, base line code 이해하기 2주차 : Prompt engineering 고도화 3주차 : 모델링, 모델 튜닝, prompt 수정, 최종 모델 완성 4주차 : 보고서 작성, PPT 제작, GIT 관리

B. 프로젝트 사전 기획

(1) 협업 문화

1. 특별한 일을 제외하고는 항상 모여서 의논하면서 Task 진행할 것(Zoom, Discord)
2. 오프라인 모임이 가능할 경우 오프라인 만남을 적극 활용할 것(소통 Skill Up)
3. 논의 사항 및 오류 사항이 있을 경우 즉각 팀원들과 상의할 것
4. New 아이디어 발생 시 Team Notion에 작성 후 팀원 호출하여 해당 아이디어에 대해 공유할 것
5. 말하지 않아도 각자 중간 진행 상황에 대해 틈틈이 보고할 것

이번 대회에서는 정말 많은 플랫폼을 활용하였다. Notion부터 시작해서 Discord, Zoom, GitHub 등등 좀 더 활용하고 있는 플랫폼을 극대화 시키고자 노력했던 것 같다. 나는 Meeting을 진행할 때마다 꼭 회의록을 작성하여 Notion에 남겨두는 습관을 들였다. 나중에 회의에 불참한 사람이든, 집중하지 못한 사람이든 누가봐도 어떤 회의를 진행하였는지 확인하기 위함이었다.

4. 프로젝트 수행 결과

팀 최고 점수 Public - Final Result(MAP : 0.9045) 개인 점수 Public - Final Result(MAP : 0.7121)

팀 최고 점수 Private -Final Result(MAP : 0.8652) 개인 점수 Private - Final Result(MAP : 0.7227)

우리 팀에서는 총 5가지의 관점으로 이 대회에 접근하였다.

나는 이 중에서 Hybrid retrieval(Sparse + Dense)와 HyDE(Hypothetical Document Embeddings), Prompt engineering에 집중하였다.

참고 자료로 PPT 링크를 첨부하도록 하겠다. 참고자료 : PPT

5. 자체 평가 의견

A. 잘했던 점

• 새로운 관점으로 접근하기 위해 HyDE 기법을 추가하였다.
• 대회 방향에 알맞은 문서 색인을 할 수 있도록 Prompt 수정을 끊임없이 하였다.

B. 시도 했으나 잘 되지 않았던 것들

• Hybrid retrieve(Sparse + Dense)를 적용하기 위해 나름대로 코드를 작성했으나 적용이 되지 않고 있었다는 것을 대회 마무리 때 알게 되었다. 급한대로 Hybrid 적용을 한 코드로 여러가지 프롬프트 실험을 많이 해보았지만 이상하게 나만 성능이 잘 나오지 않았다. 이후에 대회가 끝나고 코드 탐색을 다시 해보았는데 Sparse와 Dense의 score를 맞추는 작업이 이루어 지지 않고 있던 문제를 발견하게 되었다.

C. 아쉬웠던 점들

• 실제로 HyDE 기법은 성능 향상에 효과가 있었다. 비록 잘못된 코드(Sparse + Dense score 작업이 이루어지지 않은)로 돌렸지만 12.55% 성능 향상이 결과적으로 확인 되었다. 하지만 Prompt 수정에 너무 많은 시간을 썼었고, HyDE 기법을 대회 마무리 쯤 알게 되어 많은 시도를 해보지 못한 것이 아쉬웠다. 팀원들에게 이 기법을 공유하여 적용할 수 있는 시간이 없어서 나 혼자 시도 해보고 마무리 했던 점이 굉장히 아쉬웠다.

D. 프로젝트를 통해 배운 점 또는 시사점

• 접하기 어려운 RAG 시스템을 직접 공부하고 경험할 수 있어서 정말 값진 경험이었다고 생각한다. 실제로 Open AI API Credit 까지 일정 금액 제공해주셔서 실제로 GPT 를 사용하여 모델을 학습시킬 수 있었던 것이 정말 좋았다. LLM의 발전은 무궁무진하다. 이 분야로 뛰어들기 위해서는 정말 많은 공부를 해야겠다는 다짐을 하게 된 계기였던 것 같다.

마무리

Information Retrieval 대회까지 모두 마무리하였다. 패스트 캠퍼스 부트캠프를 참여하며 정말 상상도 못할 정도로 많은 성장이 있었다는 생각이 든다. 코드 한 줄 칠 줄 몰랐던 내가 조금씩이나마 코드를 칠 줄 알게 되었다는 점, 코드를 읽고 이해할 수 있게 되었다는 점, 컴퓨터 프로그램 언어를 활용하여 데이터를 분석할 수 있게 되었다는 점, 이 모든 게 패스트캠퍼스가 아니었으면 불가능 했을 것 같다. 이 값진 경험들을 잊지 않고 계속 활용할 수 있도록 앞으로도 많은 노력을 할 것이다 !

#패스트캠퍼스 #UpstageAILab #Upstage #부트캠프 #AI #데이터분석 #데이터사이언스 #인공지능개발자 #ML #머신러닝 #경진대회 #딥러닝 #NLP

CH01 - 이상 탐지 개요

• 차원 축소 기술
• EDA
• 데이터 시각화

CH02 - ML 기반 이상 탐지

• 본격적인 이상 탐지 학습

• D/L이 아닌 조금 더 전통적인 방식의 머신러닝 기술에 대해 학습

  • 통계 기반
  • 분류 기반
  • 군집 기반

• D/L is not all you need!

CH03 - DL 기반 이상 탐지

• 딥러닝을 사용하는 이상 탐지 기술에 대해 알아보는 시간
• 모든 경우에 딥러닝이 적잘하지는 않지만, 여전히 가장 강력한 AI 기술
• 비 선형적인 데이터에 적용하기 적절

CH04 - 이상 탐지 Case study

• 공개된 데이터 셋으로 이상탐지에 대해 구체적으로 알아보는 시간
• 2개의 kaggle case study

이상탐지 개요

1. 이상 탐지?

   • 데이터의 대다수와 현저히 다르며 정상 범위에서 벗어나서 드물게 발생하는 항목, 사건, 관측치를 찾아내는 과정

2. 이상 탐지 use-case

   • 이상탐지 기술이 활용되는 예시
   1. Image 이상 탐지

       - 촬영된 이미지
       - 의료 도메인, 산업용 공정 등에서 활용

   2. Text 이상 탐지
   • 문자로 표현되는 데이터의 의미를 파악하는 이상 탐지
   3. Tabular data 이상 탐지
   • 테이블(표) 형태로 표현 가능한 데이터의 이상 탐지
   • 수치적, 통계적 특성을 주로 활용
   4. Time-series data 이상 탐지
   • 일정한 시간 정보를 포함한 데이터의 이상 탐지
   • 사이버 공격 방어, 실시간 금융 거래 모니터링

3. 이번 강의에서는!

   • Tabular + Time-series + a
   • 전통적인 방식의 머신 러닝 알고리즘에 대해 학습

데이터 특성의 이해

1. 데이터 종류 [데이터 정보] 정량적 vs 정성적 정보 => 정량적 : 수치, 도형, 기호 등 바로 측정할 수 있는 정보 => 정성적 : 언어나 문자 등 '설명'이 필요한 정보 [데이터 유형] 정형 데이터(Structured data) => 행과 열로 구성되어 있는 테이블 형태의 데이터 시계열 데이터(Time Series Data) => 시간 정보가 존재하는 tabular data 비정형 데이터(Unstructured data) => 정해진 구조가 없이 저장된 데이터 반정형 데이터(Semi-Structured data) => 데이터 내용 안에 구조에 대한 설명이 함께 존재함 => tabular data와 다르게 고정된 스키마가 없음 => XML, HTML, Json 등

2. EDA(Exploratory Data Analysis)

• EDA란? => 시각화, 통계적 기법 적용 등을 통해 데이터를 탐색하는 과정

• EDA의 핵심 요소 => 데이터의 각 column의 의미를 파악하고 상관 관계를 파악 => 결측치 처리 및 데이터 필터링 => 직관적이고 쉽게 이해할 수 있는 데이터 시각화

• Dataset 이해

• 결측치 파악

• 데이터 시각화

  • hourly / daily / weekly
  • Value Distribution (Day & Hour)
  • Hour & Day: Demand by Hour

차원 축소

1. 고차원 데이터와 차원 축소

• 고차원 데이터 => 고차원 데이터 : 많은 수의 변수나 특성을 가진 데이터 => 차원의 저주(The Curse of Dimensionality) : 데이터의 차원이 증가함에 따라 필요한 데이터 샘플의 양이 기하급수 적으로 증가하여 모델 학습과 일반화에 어려움을 초래하는 현상 => 시각화 문제 : 차원이 높은(복잡한) 데이터는 직관적으로 이해하기 힘듦

• 차원 축소 => 데이터의 특성(Feature)을 줄여서 데이터를 간결하게 만드는 기술

2. 차원 축소 방법

• 차원 축소 유형 => Feature Selection : 분석 목적에 부합하는 소수의 특징만을 선택 => Feature Extraction : 기존 특징의 변환을 통해 새로운 특징 추출

• PCA(Principal Component Analysis; 주 성분 분석) => 여러 변수간 존재하는 상관관계를 이용해 이를 대표하는 주성분을 추출해 차원을 축소하는 방법

• t-SNE(t-distributed Stochastic Neighbor Embedding) => 고차원 데이터를 저차원에 t-확률 분포로 표현하는 비선형 차원축소 방법

• PCA vs t-SNE => 데이터가 비 선형적인 관계를 가진다면 t-SNE 활용 => 데이터가 선형적인 관계를 가진다고 PCA가 더 좋은 것은 아님

딥러닝 프로젝트 중 2번째 프로젝트인 NLP 프로젝트가 끝났다. NLP 프로젝트 회고를 작성해보고자 한다.

1. 프로젝트 개요

A. 개요

Dialogue Summarization 경진대회는 주어진 데이터를 활용하여 일상 대화에 대한 요약을 효과적으로 생성하는 모델을 개발하는 대회이다. 

일상생활에서 '대화'는 항상 이루어지고 있다. 회의나 토의는 물론이고, 사소한 일상 대화 중에도 서로 다양한 주제와 입장들을 주고 받는다. 나누는 대화를 녹음해두더라도 대화 전체를 항상 다시 들을 수는 없기 때문에 요약이 필요하고, 이를 위한 통화 비서와 같은 서비스들도 등장하고 있다.

그러나 하나의 대화에서도 관점, 주제별로 정리하면 수 많은 요약을 만들 수 있다. 대화를 하는 도중에 이를 요약하게 되면 대화에 집중할 수 없으며, 대화 이후에 기억에 의존해 요약하게 되면 오해나 누락이 추가되어 주관이 많이 개입되게 된다.

이를 돕기 위해, 우리는 이번 대회에서 일상 대화를 바탕으로 요약문을 생성하는 모델을 구축하려고 한다.

제공된 데이터셋

1. train data 12,457
2. dev 499
3. hidden-test 249

주어진 데이터는 다음과 같았으며, 각 column의 설명은 다음과 같다. frame : 대화 고유 번호. 중복되는 번호가 없음. dialogue : 최소 2명에서 최대 7명이 등장하여 나누는 대화 내용이다. 각각의 발화자를 구분하기 위해 #Person”N”#: 을 사용하며, 발화자의 대화가 끝나면 '\n' 으로 구분한다. 이 구분자를 기준으로 하여 대화에 몇 명의 사람이 등장하는지 확인해보는 부분은 EDA 에서 다루고 있다.

summary : 해당 대화를 바탕으로 작성된 요약문.

B. 환경

• 팀 구성 및 컴퓨팅 환경

  6인 1팀, 인당 RTX 3090ti 서버를 VSCode와 SSH로 연결하여 사용

• 협업 환경

  Notion, GitHub

• 의사 소통

  KakaoTalk, Zoom, Slack, Discord

2. 프로젝트 팀 구성 및 역할

• 팀 구성 이번 프로젝트 팀원으로 배정된 인원은 6명 이었다. 늘 함께하던 4명, 그리고 이전 Computer Vision 대회에서 새로 추가된 1명을 제외하고 또 한 분이 새로 들어오게 되었다. 역시나 이번에도 또래여서 큰 불화 없이 프로젝트를 잘 마무리 하였다.

• 역할

Task 목록은 다음과 같다.
> 데이터 확인 및 분류(Data Verification and Classification)
> 데이터 전처리 및 EDA(Data Preprocessing and Exploratory Data Analysis)
> 모델링 및 파라미터 튜닝(Modeling and Parameter Tuning)
> 결과 정리 및 보고서 작성(Summarization of Results and Report Writing)


모두가 함께 모든 Task 에 참여했다. 하지만 우리 팀에 Deep Learning 쪽으로 연구를 오래 진행하셨던 분이 두 분이나 계셔 그 분들의 지식과 인사이트를 바탕으로 프로젝트를 진행하였다. ~~그 분들도 NLP Project 는 처음이라 하셨지만 Deep Learning에 이제 막 발을 담근 나보다는 더 잘할 것이라 생각했고, 현실적으로 그게 맞았다.~~

3. 프로젝트 수행 절차 및 방법

A. 팀 목표 설정

1주차 : 주어진 Upstage 강의 다 듣기, train 데이터 및 test 데이터 패턴 파악하기, base line code 이해하기 2주차 : 기존 데이터 탐색 및 파악하기(EDA 및 전처리), 데이터 증강하기(Data Augmentation, EDA + AEDA) 3주차 : 모델링, 모델 튜닝, 최종 모델 완성

B. 프로젝트 사전 기획

(1) 협업 문화

1. 특별한 일을 제외하고는 항상 모여서 의논하면서 Task 진행할 것(Zoom, Discord)
2. 오프라인 모임이 가능할 경우 오프라인 만남을 적극 활용할 것(소통 Skill Up)
3. 논의 사항 및 오류 사항이 있을 경우 즉각 팀원들과 상의할 것
4. New 아이디어 발생 시 Team Notion에 작성 후 팀원 호출하여 해당 아이디어에 대해 공유할 것
5. 말하지 않아도 각자 중간 진행 상황에 대해 틈틈이 보고할 것

우리팀의 좋았던 점은 별 일 없으면 항상 온라인 소통 플랫폼에 항상 접속해 있는 것이었다. 문제가 생기면 언제든 소통이 가능했고 좋은 아이디어가 생겨도 실시간으로 바로바로 소통이 가능했다. 이 점이 팀 프로젝트 결과물을 뽑아내는 데 중요한 요소였던 것 같다. 이번에 새로 합류한 팀원께도 플랫폼 초대 링크를 보내어 참석할 수 있도록 하였다. 우리 팀은 기존의 Zoom 플랫폼 보다 Discord 활용을 더 많이 한 것 같다. 다른 팀 보다 늘 다양한 과정과 관점, 다양한 결과물을 완성시켰던 것 같다. 이번 발표회에서도 강사님께서 이 부분을 우리팀의 장점이라 높이 칭찬하셨다. EDA 프로젝트부터 Machine Learning 프로젝트, Machine Learning 대회, Deep Learning(CV), Deep Learning(NLP) 대회까지 동일한 팀원들과 프로젝트를 진행 중인데 변하지 않고 이런 협업 분위기가 지속되고 있어 개인적으로 너무 만족스럽다. 새로 팀에 합류하신 또 다른 한 분도 우리의 팀 분위기에 자연스럽게 녹아들어 임해주셔서 너무 감사한 마음이 들었다.

4. 프로젝트 수행 결과

Public - Final Result(F1 score : 42.5474)

Private -Final Result(F1 score : 39.3707)

우리 팀은 8가지 Tokenizer 를 사용하여 다양한 시도를 해보았다. Hugging Face에 업로드 되어있는 각기 다른 8가지의 Tokenizer를 활용하여 다른 적용을 시도하려 했다.

이후에는 EDA 를 통해 Data 를 증강하고자 했다. 데이터 증강 기법에 대한 기술은 PPT에 자세히 기술해두었으니 참고하면 될 것 같다. PPT링크

5. 자체 평가 의견

A. 잘했던 점

• 다양한 Tokenizer를 사용해보고 다양한 EDA(데이터 증강)을 진행하였다.
• 각자의 다양한 관점을 실시간으로 공유하여 함께 진행하는 프로젝트 분위기를 만들고자 하였다.
• wandb 를 통해 팀원들의 모델 학습 결과를 실시간으로 확인하며 피드백하는 방식으로 진행하였다.

B. 시도 했으나 잘 되지 않았던 것들

• 큰 모델을 돌려보고 싶었으나 서버 용량 이슈로 인해 중간에 서버가 여러번 끊기는 현상이 발생하였다. T5만 돌리려고 해도 GPU 용량 문제로 오류가 발생하였다. 좀 더 큰 용량의 서버였다면 T5와 같은 큰 모델도 잘 돌아가지 않았을까 싶다.

C. 아쉬웠던 점들

• 저번 CV 대회 때와 동일하게 팀원 간의 수준 차이가 상당히 컸다. 나를 비롯한 4명의 사람들은 딥러닝 실전에 경험이 없는 사람이었으며, 나머지 2명은 딥러닝에 경험이 있는 사람들이었다. 그 분들과 대화를 하는 과정에서 의견 교류가 원활하게 되지 않았던 것 같다. CV 때도 버벅이며 따라가기 벅찼는데 이어서 NLP 까지 진행하려니 여간 힘든 게 아니었다. 아마 그 분들이 엄청 답답했을 것 같다.그래도 관련 도서를 구매하여 개인적으로 공부를 시작하기로 다짐하는 계기가 되었다.

D. 프로젝트를 통해 배운 점 또는 시사점

• 자연어 처리를 어떻게 하는 건지에 대해 대략적으로 알 수 있게 되었다.
• 자연어 처리 중 '요약'이 어떤 모델과 과정을 통해 진행되는지 파악할 수 있던 시간이었다.

마무리

Computer Vision 대회에 이어서 NLP 대회를 마무리하게 되었다. 모든 게 다 처음인 딥러닝 대회는 초심자에게 쉬운 대회는 아니었던 것 같다. 그래도 팀원 중 두 분이 어느 정도 경험이 있어 어깨 너머로 단어 하나하나 접해가며 천천히 배워가는 과정을 겪었던 시간이었다. NLP는 지금 현재 중요하게 뜨고 있는 분야이다. 정말 열심히 기초부터 잘 채워서 실무에 바로 적용할 수 있는 정도까지의 실력을 키워야겠다는 생각을 하게 되었다. NLP 교재 또한 2권 정도 구매하여, 복습할 겸 부족한 지식을 채워나가야 겠다.

#패스트캠퍼스 #UpstageAILab #Upstage #부트캠프 #AI #데이터분석 #데이터사이언스 #인공지능개발자 #ML #머신러닝 #경진대회 #딥러닝 #NLP

우여곡절 길고 길었던 CV 프로젝트가 끝났다. 처음 접해보는 Deep Learning 프로젝트여서 순탄하게 진행되지 않았던 것 같지만 그래도 열심히 참여했던 CV 프로젝트 회고를 작성해보고자 한다.

1. 프로젝트 개요

A. 개요

이번 대회는 computer vision domain에서 가장 중요한 태스크인 이미지 분류 대회이다.

이미지 분류란 주어진 이미지를 여러 클래스 중 하나로 분류하는 작업이다. 이러한 이미지 분류는 의료, 패션, 보안 등 여러 현업에서 기초적으로 활용되는 태스크이다. 딥러닝과 컴퓨터 비전 기술의 발전으로 인한 뛰어난 성능을 통해 현업에서 많은 가치를 창출하고 있다.

그 중, 이번 대회는 문서 타입 분류를 위한 이미지 분류 대회였다. 문서 데이터는 금융, 의료, 보험, 물류 등 산업 전반에 가장 많은 데이터이며, 많은 대기업에서 디지털 혁신을 위해 문서 유형을 분류하고자 한다. 이러한 문서 타입 분류는 의료, 금융 등 여러 비즈니스 분야에서 대량의 문서 이미지를 식별하고 자동화 처리를 가능케 할 수 있다.

제공된 데이터셋

1. 총 17개 종의 문서로 분류되어 있는 1570장의 train data
2. 총 17개 종의 문서로 분류해야 하는 3140장의 test data

주어진 데이터는 다음과 같았으며, 이번 대회는 test data 가 train data 보다 많다는 점이 의아한 점이었다. 또한 이번 data는 현업에서 사용하는 실 데이터를 기반으로 대회를 제작했다고 하여 기대감이 컸다.

B. 환경

• 팀 구성 및 컴퓨팅 환경

  5인 1팀, 인당 RTX 3090ti 서버를 VSCode와 SSH로 연결하여 사용

• 협업 환경

  Notion, GitHub

• 의사 소통

  KakaoTalk, Zoom, Slack, Discord

2. 프로젝트 팀 구성 및 역할

• 팀 구성 프로젝트 팀원으로 배정된 인원은 5명 이었다. 늘 함께하던 4명을 제외하고 한 분이 새로 들어오게 되었는데 이번에 들어오신 분은 참여도가 높으셔서 개인적으로 만족스러운 팀워크를 형성할 수 있어 좋았다.

• 역할

Task 목록은 다음과 같다.
> 데이터 확인 및 분류(Data Verification and Classification)
> 데이터 전처리 및 EDA(Data Preprocessing and Exploratory Data Analysis)
> 모델링 및 파라미터 튜닝(Modeling and Parameter Tuning)
> 결과 정리 및 보고서 작성(Summarization of Results and Report Writing)


모두가 함께 모든 Task 에 참여했다. 하지만 우리 팀에 Computer Vision 쪽으로 연구를 오래 진행하셨던 분이 두 분이나 계셔 그 분들의 지식과 인사이트를 바탕으로 프로젝트를 진행하였다.

3. 프로젝트 수행 절차 및 방법

A. 팀 목표 설정

1주차 : 주어진 Upstage 강의 다 듣기, test 데이터 패턴 파악하기, base line code 이해하기 2주차 : Human Classification, 기존 데이터 탐색 및 파악하기(EDA 및 전처리) 3주차 : 모델링, 모델 튜닝, 최종 모델 완성

B. 프로젝트 사전 기획

(1) 협업 문화

1. 특별한 일을 제외하고는 항상 모여서 의논하면서 Task 진행할 것(Zoom, Discord)
2. 오프라인 모임이 가능할 경우 오프라인 만남을 적극 활용할 것(소통 Skill Up)
3. 논의 사항 및 오류 사항이 있을 경우 즉각 팀원들과 상의할 것
4. New 아이디어 발생 시 Team Notion에 작성 후 팀원 호출하여 해당 아이디어에 대해 공유할 것
5. 말하지 않아도 각자 중간 진행 상황에 대해 틈틈이 보고할 것

우리팀의 좋았던 점은 별 일 없으면 항상 온라인 소통 플랫폼에 항상 접속해 있는 것이었다. 문제가 생기면 언제든 소통이 가능했고 좋은 아이디어가 생겨도 실시간으로 바로바로 소통이 가능했다. 이 점이 팀 프로젝트 결과물을 뽑아내는 데 중요한 요소였던 것 같다. 다른 팀 보다 늘 다양한 과정과 관점, 다양한 결과물을 완성시켰던 것 같다. EDA 프로젝트부터 Machine Learning 프로젝트, Machine Learning 대회, Deep Learning(CV) 대회까지 동일한 팀원들과 프로젝트를 진행 중인데 변하지 않고 이런 협업 분위기가 지속되고 있어 개인적으로 너무 만족스럽다. 새로 팀에 합류하신 분도 우리의 팀 분위기에 자연스럽게 녹아들어 임해주셔서 너무 감사한 마음이 들었다.

4. 프로젝트 수행 결과

Public - Human Classification(F1 score : 0.9885)

Private - Efficientnet-b4 (F1 score : 0.9061)

우리 팀은 Model 을 사용하여 학습 시키는 방법과 직접 우리가 분류하는 Human Classification 방법 2가지를 사용하였다. 자세한 Code 및 PPT 자료는 Github 에서 확인할 수 있다. 프로젝트를 진행하며 작성했던 회의록들도 Notion_FastCampus & Notion_Plus를 통해 확인할 수 있다.

[Human Classification]

데이터를 받고 모델 학습을 진행하기 전에 test data를 확인해보자 하는 의견이 나와 data의 형태를 파악하고자 하나하나 확인하던 과정 중에 '직접 분류해보는 게 어떨까?' 하는 생각이 들었다. 팀원 모두 비슷한 생각을 하고 있었고 우리는 우리가 직접 분류를 해보기로 하였다. 이 결과물을 제출하여 1등 해야겠다! 라는 마음보다는 human 분류를 하였을 때 정확도가 얼마나 나오는지 궁금했다. 그리고 직접 분류한 결과물을 활용하여 모델 학습 시킨 결과와 비교할 때도 유용하게 쓰일 것 같아 일단 분류를 직접하기 시작했다.

[Model 학습]

우리 팀은 다양한 모델을 활용하였다. CV에서 쓸 수 있는 모델은 다 써본 것 같다. 각 모델의 자세한 결과는 Notion 및 PPT에 자세히 기록해 뒀다.

위의 모델을 사용하여 학습 된 결과를 Human Classification 한 결과와 비교하여 어떤 class에서 예측을 잘하고 못하는지 확인해보는 과정도 거쳤다.

5. 자체 평가 의견

A. 잘했던 점

• 다양한 방법으로 Augmentation을 진행하였다.
• 각자의 다양한 관점을 실시간으로 공유하여 함께 진행하는 프로젝트 분위기를 만들고자 하였다.

B. 시도 했으나 잘 되지 않았던 것들

• 강사님의 Feed back 을 통해 이 대회는 Augmentation이 중요한 대회임을 캐치하였다. 하지만 과도한 Augmentation으로 인해 서버가 터지는 이슈가 빈번하게 발생하였고, 모델 학습 시 1 epoch 을 돌리는데 2시간이 넘게 걸렸다. 결국 1500분을 투자하여 약 30 epoch 까지 학습을 시켰지만 결론적으로 서버가 터져 해당 모델을 사용할 수 없었다.

C. 아쉬웠던 점들

• 팀원 간의 수준 차이가 상당히 컸다. 나를 비롯한 3명의 사람들은 딥러닝 실전에 경험이 없는 사람이었으며, 나머지 2명은 딥러닝에 경험이 있는 사람들이었다. 그 분들과 대화를 하는 과정에서 의견 교류가 원활하게 되지 않았던 것 같다. 아마 그 분들이 엄청 답답했을 것 같다.

D. 프로젝트를 통해 배운 점 또는 시사점

• 이미지 분류를 어떻게 하는 건지에 대해 대략적으로 알 수 있게 되었다.
• 딥러닝 시스템이 어떻게 돌아가는 지에 대해 파악할 수 있던 시간이었다.

마무리

딥러닝은 강의도 처음이고 대회도 처음이고 모든 것이 처음이었던 분야라 사실 우왕좌왕 많이 했던 것 같다. 팀원 중 두 분이 어느 정도 경험이 있어 어깨 너머로 단어 하나하나 접해가며 천천히 배워과는 과정을 겪었던 시간이었던 것 같다. 이제는 어느 분야를 중점적으로 더 파고 들어야 하고 더 공부해야 하는 지 알게 되어 앞으로 그 부분을 중점적으로 더 공부해보고자 한다. 의료 AI 에 관심이 많기에 Computer Vision에 대해 더 열심히 공부해야 할 것 같다는 생각을 하였다.

#패스트캠퍼스 #UpstageAILab #Upstage #부트캠프 #AI #데이터분석 #데이터사이언스 #인공지능개발자 #ML #머신러닝 #경진대회 #딥러닝 #Computer Vision

벌써 몇 번째 프로젝트인지 모르겠다. 정신없이 달리다보니 여기까지 와 버렸다. 앞서 진행된 프로젝트 정리도 채 끝나지 않은 채 이번 Machine Learning 대회 개인 회고를 작성해보고자 한다.

1. 프로젝트 개요

A. 개요

본 대회는 House Price Prediction 경진대회는 주어진 데이터를 활용하여 서울의 아파트 실거래가를 효과적으로 예측하는 모델을 개발하는 대회이다.

부동산은 의식주에서의 주로 중요한 요소 중 하나인데, 이런 부동산은 아파트 자체의 가치도 중요하고, 주변 요소(강, 공원, 백화점 등)에 의해서도 영향을 받아 시간에 따라 가격이 많이 변동하기도 한다. 개인의 입장에서는 더 싼 가격에 좋은 집을 찾고 싶고, 판매자의 입장에서는 적절한 가격에 집을 판매하기를 원한다. 부동산 실거래가의 예측은 이러한 시세를 예측하여 적정한 가격에 구매와 판매를 도와주게 한다. 정부의 입장에서는 비정상적으로 시세가 이상한 부분을 체크하여 이상 신호를 파악하거나 업거래, 다운거래 등 부정한 거래를 하는 사람들을 잡아낼 수도 있다.

제공된 총 4가지의 데이터셋

1. 국토교통부에서 제공하는 아파트 실거래가 데이터(아파트 위치, 크기, 건축년도, 주변시설 및 교통 편의성 등)
2. 서울시에서 제공하는 지하철역 데이터
3. 서울시에서 제공하는 버스정류장 데이터
4. 평가 데이터(최종 모델 성능에 대한 검증을 위해 사용)
   • input : 9,272개의 아파트 특징 및 거래정보
   • output : 9,272개의 input에 대한 예상 아파트 거래금액

주어진 데이터는 다음과 같았으나 외부 데이터에 대한 제한 사항이 규칙에 없어 다양한 외부 데이터를 끌어다 대회에 응용시킬 수 있었다.

B. 환경

• 팀 구성 및 컴퓨팅 환경

  5인 1팀, 인당 RTX 3090ti 서버를 VSCode와 SSH로 연결하여 사용

• 협업 환경

  Notion, GitHub

• 의사 소통

  KakaoTalk, Zoom, Slack, Discord

2. 프로젝트 팀 구성 및 역할

• 팀 구성 프로젝트 팀원으로 배정된 인원은 5명 이었으나 한 분은 재직자 신분이어 개인 업무로 인해 프로젝트에 거의 참여하지 못하셨다. 결과적으로 4명이서 프로젝트를 진행하게 되었고 나눠지는 Task 또한 4명으로 나뉘어지게 되었다.

• 역할

Task 목록은 다음과 같다.
> 데이터 확인 및 수집(Data Verification and Collection)
> 데이터 전처리 및 EDA(Data Preprocessing and Exploratory Data Analysis)
> 모델링 및 파라미터 튜닝(Modeling and Parameter Tuning)
> 결과 정리 및 보고서 작성(Summarization of Results and Report Writing)


모두가 함께 모든 Task 에 참여하긴 했지만 각자 중점적으로 두고 진행했던 Task 는 각기 달랐다. 아래의 표에서 표시되어 보여지겠지만, 나는 데이터 확인 및 수집(Data Verification and Collection)과 모델링 및 파라미터 튜닝(Modeling and Parameter Tuning)에 비중을 크게 두고 프로젝트를 참여하였다. 

3. 프로젝트 수행 절차 및 방법

A. 팀 목표 설정

1주차 : 주어진 Upstage 강의 다 듣기, 사전에 주어진 참고 대회 자료 데이콘, 캐글 활용하여 코드 미리 파악하고 데이터 패턴 파악하기 2주차 : 외부 데이터 수집하기, 기존 데이터 탐색 및 파악하기(EDA 및 전처리) 3주차 : 모델링, 모델 튜닝, 최종 모델 완성, 앙상블 전략 사용

B. 프로젝트 사전 기획

(1) Time-Line 수립

(2) 협업 문화

1. 특별한 일을 제외하고는 항상 모여서 의논하면서 Task 진행할 것(Zoom, Discord)
2. 오프라인 모임이 가능할 경우 오프라인 만남을 적극 활용할 것(소통 Skill Up)
3. 논의 사항 및 오류 사항이 있을 경우 즉각 팀원들과 상의할 것
4. New 아이디어 발생 시 Team Notion에 작성 후 팀원 호출하여 해당 아이디어에 대해 공유할 것
5. 말하지 않아도 각자 중간 진행 상황에 대해 틈틈이 보고할 것

우리팀의 좋았던 점은 별 일 없으면 항상 온라인 소통 플랫폼에 항상 접속해 있는 것이었다. 문제가 생기면 언제든 소통이 가능했고 좋은 아이디어가 생겨도 실시간으로 바로바로 소통이 가능했다. 이 점이 팀 프로젝트 결과물을 뽑아내는 데 중요한 요소였던 것 같다. 다른 팀 보다 늘 다양한 과정과 관점, 다양한 결과물을 완성시켰던 것 같다. EDA 프로젝트부터 Machine Learning 프로젝트, Machine Learning 대회까지 동일한 팀원들과 프로젝트를 진행 중인데 변하지 않고 이런 협업 분위기가 지속되고 있어 개인적으로 너무 만족스럽다. 프로젝트를 진행할 수록 여러 Fast Campus 매니저님들과 여러 강사님들께 인정 받고 있어 뿌듯하기도 하다. 이번 프로젝트에서는 'EDA 장인들' 이라는 극찬까지 받기도 했다.

4. 프로젝트 수행 결과

Public 4등(RMSE : 18590.4353), Private 3등(RMSE : 14283.4856)

우리 팀은 Strategy I, Strategy II 2가지의 전략을 이용하였다. 자세한 Code 및 PPT 자료는 Github 에서 확인할 수 있다. 프로젝트를 진행하며 작성했던 회의록들도 Notion 을 통해 확인할 수 있다.

[Strategy I]

활용 데이터(외부 데이터)

• 금리(한국 은행)
• GDP(한국 은행)
• 대통령 득표율
• 아파트 정보 크롤링(네이버 페이 부동산)
• 역세권(버스, 지하철)
• 한강 대교 거리(하버 사인)
• 학군(서울시 학군 정보)
• 전세가율(KB 부동산)

사용 모델

[Strategy II]

활용 데이터(외부 데이터)

• 금리(한국 은행)

사용 모델

Strategy I은 다양한 외부 데이터를 활용하여 아파트 집 값과 관련이 높은 Feature 들을 생성하여 각각의 Model(CatBoost, XGBoost, LightGBM)을 돌려 Ensemble 하는 전략이었고, Strategy II는 외부 데이터를 다양하게 활용하기보다는 기존의 데이터를 활용하여 새로운 Feature 를 만들어내는 Feature Engineering 에 Focus 를 맞춘 전략이었다.

여기서 Strategy II 부분이 내가 집중적으로 파고 들었던 전략이다. 우선 Categorical 한 아파트명 변수를 Numerical 하게 변경하여 각각의 아파트에 키 값을 부여하였고, 아파트 거래 값이 최근 거래에 영향을 많이 받을 것이라 생각하여 아파트 최근 거래 가격(recent_price), 아파트 최근 거래량(transaction_cnt) 의 feature 를 생성하였다. 그 후 금리 데이터를 추가하여 Modeling(Random Forest, XGBoost, LightGBM)을 하여 Ensemble 하였다.

본 대회의 리더보드에 오류가 있어 오류 발생 전에는 Strategy II 전략이 상대적으로 높은 것으로 나타났으나, 오류 수정 후 Strategy I 의 결과가 더 좋게 나오게 되었다. 리더보드에 오류가 없었다면 Score를 눈으로 확인하며 모델의 성능을 더 좋은 방향으로 변경시키며 수정할 수 있었겠지만 치명적인 오류로 인하여 그러지 못했던 것이 아쉬웠던 부분이었다.

결과적으로 개고생 하며 열심히 수집하고 만들었던 많은 외부 데이터들을 활용한 Strategy I 의 성능이 좋게 평가되어 다행이라고 생각한다. 역시 노력은 배신하지 않아ㅋ

5. 자체 평가 의견

A. 잘했던 점

• 무작정 Modeling 에 뛰어들지 않고 데이터 확인, 수집에 시간을 많이 투자하여 여러가지 Data를 활용하고자 하였다.
• EDA 에 많은 시간을 투자하여 Data를 완벽하게 파악하고자 하였다.
• Auto ML을 사용하지 않고 직접 Modeling 을 하여 각 Model 의 장단점을 파악하려고 하였다.
• 각자의 다양한 관점을 실시간으로 공유하여 함께 진행하는 프로젝트 분위기를 만들고자 하였다.

B. 시도 했으나 잘 되지 않았던 것들

• Data 크롤링에 많은 시간을 투자하였으나 시간이 부족하여 크롤링한 Data를 활용하여 Modeling 을 다양하게 해보지 못하였다.
• 각자의 Task 가 너무 많아 각자 좋은 관점으로 만들어진 Feature 들을 합쳐서 Modeling 해보지 못하였다.
• 수집해 온 외부 Data들을 적합하게(Model의 성능에 도움이 되도록) 적용시킬 방법에 대해 구상하지 못했던 것 같다.

C. 아쉬웠던 점들

• 대회 주최 측의 오류가 너무나도 많았다. 서버가 끊기는 경우도 많았고, 제일 큰 오류는 리더보드 오류. 대회를 진행하면서도 의문을 품은 사람들이 많았으나 빠르게 개선되지 않았던 점이 아쉬웠다. 더 좋은 결과를 낼 수 있었는데...ㅠ

D. 프로젝트를 통해 배운 점 또는 시사점

• Auto ML 을 사용하지 않고 Modeling 을 할 수 있게 되었다.
• EDA 실력이 한층 더 향상 되었다.
• 협업 스킬이 더 향상 되었다.
• 프로젝트 진행에 있어 시간 배분을 잘하는 것이 중요하다는 것을 깨닫게 되었다.

마무리

정말 좋은 팀을 만났다. 현재까지 고등학교, 대학교, 대학원 때 했던 모든 조별 과제 및 프로젝트를 통틀어 가장 열정적인 팀을 만난 것 같다. 한 명도 빠짐없이 모두가 다 한 마음, 한 뜻인 경우는 이번 팀이 처음이었다. (보통 조에서 한 두명은 무임승차하는 경우가 대부분이었는데... 나 혼자 밤 새가며 발표 자료 만들었던 때가 생각난다..) 또 신기한 건 내가 부족한 부분은 다른 팀원이 강점으로 가지고 있는 부분이고, 다른 팀원이 부족한 부분은 내가 강점으로 가지고 있는 부분이라는 것이다. 서로서로 그런 부분들을 채워줄 수 있는 팀원들인 것이 우리 팀의 최대 강점이다. EDA 프로젝트 때 부터 만나 지금까지 프로젝트를 진행하며 모두가 빠르게 성장하고 있는 모습이 보여 이 시간이 정말 값지고 의미있는 시간이라 생각한다. 이제 ML 은 완전히 끝났고! DL 프로젝트, 대회 열심히 참여해야겠다!! 우리 팀 끝까지 화이팅 하자!

#패스트캠퍼스 #UpstageAILab #Upstage #부트캠프 #AI #데이터분석 #데이터사이언스 #인공지능개발자 #ML #머신러닝 #경진대회

Chapter 1-1 & 1-2. 딥러닝의 발전 5단계 1 : 1단계 ~ 5단계

딥러닝의 발전 5단계 | DL Development in 5 Steps

• AI/ML/DL 관점에서 크게 5단계로 개발 방법론이 진화(세 단계로 SW 1.0, SW 2.0, SW 3.0 으로도 나뉨)

  [단계 별 특징]

  1. Rule based programming(SW 1.0 방식)
     1. 목표 달성에 필요한 연산 방법을 사람이 전부 고안
  2. Conventional machine learning(SW 1.5 방식)
     1. 특징 값을 뽑는 방식은 사람이, 특징 값을 판별하는 로직은 기계가 고안
  3. Deep Learning(SW 2.0 방식)
     1. 모든 연산들을 기계가 고안
  4. Pre-training &Fine-tuning
     1. 전체 특징을 구별하는 모델을 고정 시켜둔 후(Pre-training) mapping 부분만 해당 Task에 대한 Data로 미세 조정(Fine-tuning)하는 방식
  5. Big Model & zero/few shot
     1. in-context learning
     2. 입력된 문장을 보고 기계가 스스로 해야 할 Task를 찾아서 진행

Chapter 1-3 & 1-4. 딥러닝 기술 종류들 : 학습 방식, 데이터 형식, 태스크 종류에 의한 구분

AI 구분법

• 데이터 Data
  • 정형 데이터 / 이미지, 동영상 / 텍스트 / 음성
• 학습 Learning
  • Supervised Learning / Un-Supervised Learning / Reinforcement Learning
• 태스크 Task
  • 인식 / 생성

AI = 모델 = 연산의 집합 = 프로그램

• 컴퓨터는 숫자만 이해하므로, 입/출력 모두 숫자

학습 방식에 의한 구분

교사 학습(Supervised Learning)

• 정답이 필요함
• 라벨링 데이터
• 직접 피드백
• 교사 학습으로 학습된 모델은 분류(Classification) 태스크 혹은 회귀(Regression) 태스크를 수행
  • 분류(Classification) : 분류는 기정의된 클래스들 중 입력이 어느 클래스에 해당하는지 맞추는 태스크
  • 회귀(Regression): 회귀는 입력 데이터에 대한 실수 혹은 실수의 집합을 (벡터) 출력으로 맵핑 해주는 (Mapping) 태스크
• 라벨링 노이즈(Labeling Noise)
  • 라벨링 결과에 대한 노이즈 = 라벨링 작업에 대해 일관되지 않음의 정도

비교사 학습(Un-Supervised Learning)

• 정답이 없음

• 라벨링 데이터 X

• 피드백 X

• 숨은 구조 찾기

• 비교사 학습으로 학습된 모델은 차원 축소(Dimension Reduction) 혹은 클러스터링 (Clustering) 태스크를 수행

  • 클러스터링(Clustering)

    1. 임의의 두 점을 정하고 클래스 부여(클래스의 중심점)
    2. 나머지 점들은 가장 가까운 쪽의 클래스 중심점의 클래스 부여
    3. 클래스별 중심점 재 계산 후 2번 과정 반복

  • 차원 축소(Dimension Reduction)

    • N차원 입력을 N>n 차원 출력으로 변경하는 태스크

    • 차원 축소를 하는 이유

      1) 정보 압축: 이미지/비디오/오디오 압축

      2) 정보 시각화: 사람이 눈으로 확인할 수 있는 것은 3차원 까지

      3) 정보 특징: 중요한 특징을 추출하여 분석에 사용

강화 학습(Re-Inforcement Learning)

• 라벨링 데이터 X
• 지연 피드백
• 보상 신호(정답과 유사한)
• 강화학습의 4가지 구성요소 : 에이전트(Agent), 보상(Reward), 행동(Action), 환경(Environment)
  • 예시
    1. 자전거 배우는 예제
       1. Agent: 어린 아이
       2. Action: 핸들/브레이크/페달 조정
       3. Environment: 학교 운동장
       4. Reward: 자전거 넘어지지 않고 이동하는 시간
       5. State: 시각/청각/촉각
    2. 아타리 비디오 게임 예제
       1. Agent: 게이머
       2. Action: Up/Down
       3. Environment: 아타리 게임 시스템
       4. Reward: 게임 점수
       5. State: 게임 화면
• Model-Free 강화학습에서는 정책/가치 함수에 해당하는 두 가지 AI가 필요

학습 방식에 의한 구분

정형 데이터(Tabular Data)

• 구조화된 정보롤 저장되어 있는 것
• 딥러닝을 통해서 비정형 데이터를 구조화된 정보로 바꿀 수 있음

컴퓨터 비전(Computer Vision)

• 입력으로 이미지나 동영상 데이터를 받는 AI

자연어 처리(Natural Language Processing)

• 입력으로 텍스트 데이터를 받는 AI
• LLM(Large Language Model)

음성 인식/생성 (Speech Recognition/Generation)

• 입/출력으로 음성 데이터가 활용되는 AI
  • 음성 인식(Speech Recognition) : 입력 = 음성
  • 음성 생성(Speech Generation) : 출력 = 음성

태스크 종류에 의한 구분

인식 및 생성(Recognition & Generation)

• 비정형 데이터와 정보의 입출력 관계에 따라 인식 혹은 생성으로 구분됨
  • 인식(Recognition) : 비정형 데이터 입력에 정보가 출력
  • 생성(Generation) : 출력이 비정형 데이터인 경우
• 인식 기술이 어려울까 생성 기술이 어려울까?
  • “What I cannot create, I do not understand.” - Richard Feynman

생성 모델의 역사(History of Generative Models)

• 이미지 생성
  • 2014년의 GAN(Generative Adversarial Network)
  • 2021년도에 공개한 DALL-E
    • 입력을 텍스트로 받아서 통제력 문제를 해결
  • 2023년도에 Stability AI의 Stable Diffusion이 상업적으로 이용 가능하게 됨
• 텍스트 생성
  • 2023년도의 OpenAI가 내놓은 ChatGPT

[참고 자료] https://kdt.fastcampus.co.kr/classroom/234515

#패스트캠퍼스 #UpstageAILab #Upstage #부트캠프 #AI #데이터사이언스 #무료교육 #국비지원

신경망(neural networks)

• 인간의 뇌를 모방하여 만든 알고리즘으로, 데이터를 처리하고 패턴을 학습하는 데 사용
• 여러 층(layer)과 노드(node)로 구성되어 있으며, 각 노드는 입력 데이터를 가중치와 결합하여 출력을 생성함

• 선형 회귀구조를 이용해서 하나의 특성을 만들어냄
• 몇 개의 특성을 만들어내는 지는 설정하기 나름
• 더 많은 노드, 레이어 얼마든지 생성 가능 -> 레이어가 깊어지면 "딥러닝"

• 신경망을 깊이 쌓으면 쌓을 수록 어떤 데이터에 대한 정보는 많이 학습됨 -> 많은 특성을 추출 가능 => "정확한 예측"
• 주의점: 지나치게 복잡한 모델 사용으로 성능을 끌어올리는 경우 -> "과적합 문제" 발생
• 수많은 선형 변환이 여러 개로 이어져있더라도 결국 한 번에 가는 선형 변환이 존재함 => 따라서 "비선형 변환이 필요함"

선형변환 (Linear Transformation)

• 선형변환은 입력 데이터에 가중치를 곱하고 편향을 더하는 과정
• 수학적으로는 y = Wx + b 형태로 표현
  • 여기서 W는 가중치(weight), x는 입력(input), b는 편향(bias)입니다.
• 선형 변환은 데이터의 크기만 조정하거나 회전시키는 등의 단순한 변환을 수행

[중요성]

• 선형 변환은 데이터를 다루는 가장 기본적인 방법
  • 하지만 혼자서는 복잡한 데이터의 패턴이나 특성을 충분히 표현하지 못함

비선형변환 (Non-linear Transformation)

[Sigmoid 함수]

• Sigmoid 함수는 대표적인 비선형 활성화 함수
• 함수 형태는 σ(x) = 1 / (1 + e^(-x))로 표현
• 이 함수는 입력값을 0과 1 사이의 값으로 변환함, 이는 확률과 같은 형태로 해석될 수 있음

[중요성]

• 비선형 변환은 딥러닝 모델이 복잡한 데이터의 특성을 학습할 수 있게 해줌
• Sigmoid 함수와 같은 활성화 함수는 선형 변환된 데이터에 적용되어 모델에 비선형성을 부여함

활성화 함수 (Activation Functions)

• 딥러닝 모델에서 활성화 함수는 매우 중요한 역할을 함
• 이 함수들은 인공신경망에서 입력 데이터를 받아 처리한 뒤, 출력을 결정하는 데 사용
• 주로 Sigmoid와 ReLU 함수가 널리 사용

1. Sigmoid 활성화 함수

• Sigmoid 함수는 σ(x) = 1 / (1 + e^(-x))로 정의
• 이 함수는 모든 입력값을 0과 1 사이의 값으로 변환

[특징]

• 출력이 0과 1 사이로 제한되기 때문에, 이진 분류 문제에서 유용
• Sigmoid는 곡선의 형태를 띄기 때문에, 입력값에 따른 출력의 변화가 부드러움

[단점]

• 그라디언트 소실(Vanishing Gradient) 문제가 발생할 수 있음
  • 신경망이 깊어질수록 학습이 어려워진다는 것을 의미
• 출력이 0에 가까울 때와 1에 가까울 때 Gradient가 매우 작아져, 학습 속도가 느려질 수 있음

2. ReLU (Rectified Linear Unit) 활성화 함수

• ReLU 함수는 f(x) = max(0, x)로 정의
• 입력이 0 이상이면 그 입력을 그대로 출력하고, 0 미만이면 0을 출력

[특징]

• ReLU는 간단하고 계산 효율성이 뛰어나 대규모 신경망에서 널리 사용
• 그라디언트 소실 문제를 상당 부분 해결해주어 깊은 네트워크에서도 효과적으로 학습할 수 있음

[단점]

• '죽은 ReLU' 문제
  • 즉, 네트워크의 일부 뉴런이 0 이하의 값만 받게 되면, 항상 0만 출력하게 되어 해당 뉴런이 더 이상 학습에 기여하지 못하는 문제가 발생

일반적으로, Sigmoid는 출력층에서 이진 분류 문제에 자주 사용, ReLU는 은닉층에서 널리 사용

가중치 행렬(weight matrix)

• 신경망에서 입력과 출력 사이의 관계를 결정하는 매개변수.
• 각 노드의 입력값에 곱해지는 가중치들의 집합으로, 학습 과정에서 최적화됨.

경사 하강법(gradient descent)

• 최적화 알고리즘의 일종으로, 손실 함수(loss function)의 최소값을 찾기 위해 가중치를 조정함
• 손실 함수의 기울기(gradient)를 계산하여 오차를 줄이는 방향으로 가중치를 업데이트함

학습률(Learning Rate)

• 딥러닝에서 매우 중요한 hyperparameter
• 이는 모델이 데이터로부터 학습하는 속도와 방식을 결정짓는 역할을 함

학습률(Learning Rate)이란?

• 학습률은 모델이 학습하는 동안 가중치(weight)를 얼마나 조정할지를 결정하는 값
• 가중치의 업데이트는 "가중치 = 가중치 - 학습률 * 손실 함수의 기울기"로 계산
• 즉, 학습률이 크면 가중치 조정이 크고, 학습률이 작으면 가중치 조정이 작음

Optimizer의 종류

경사 하강법을 개선한 다양한 알고리즘들이 있습니다. 대표적인 예로는 SGD(Stochastic Gradient Descent), Adam, RMSprop 등이 있으며, 각각의 알고리즘은 특정 상황에서 더 효과적일 수 있습니다.

SGD(Stochastic Gradient Descent)

• 작동 방식: 각 단계에서 무작위로 선택된 하나의 데이터 샘플에 대해 Gradient(기울기)를 계산하고, 이를 사용해 모델의 가중치를 업데이트함
• 장점: 메모리 효율적이며, 대규모 데이터셋에서도 잘 작동함
• 단점: 수렴 속도가 비교적 느리고, 최적점에 도달하기까지 불안정할 수 있음

Batch GD(Batch Gradient Descent)

• 작동 방식: 전체 데이터셋을 사용하여 한 번에 그라디언트를 계산함
• 장점: 안정적인 그라디언트 추정과 수렴을 제공함
• 단점: 매우 큰 데이터셋에 대해서는 계산 비용이 많이 들고, 메모리 요구량이 높음

Mini-batch GD / Single sample GD

• 작동 방식: 데이터셋을 작은 배치로 나누고, 각 배치에 대해 Graident를 계산
• 장점: SGD와 Batch GD의 장점을 결합하여 더 빠른 수렴과 효율적인 메모리 사용을 가능하게 함
• 단점: 배치 크기 선택이 중요하며, 잘못된 크기는 성능에 영향을 미칠 수 있음

Momentum

• 작동 방식: 이전 Gradient의 방향을 고려하여 현재 업데이트에 '관성'을 추가함
• 장점: 지역 최소값에서 벗어나기 쉽고, 수렴 속도가 빨라짐
• 단점: 관성 때문에 최적점을 지나칠 수 있으며, 파라미터 조정이 필요함

AdaGrad

• 작동 방식: 각 매개변수에 대해 개별적인 학습률을 적용
• 장점: 간단한 문제에서 잘 작동하며, 희소한 데이터에서 유용
• 단점: 학습률이 지속적으로 감소하여 장기적으로는 학습이 멈출 수 있음

RMSprop

• 작동 방식: AdaGrad의 단점을 개선하기 위해 과거 모든 Gradient를 똑같이 고려하지 않고, 최근 Gradient에 더 큰 가중치를 둠
• 장점: 비교적 새로운 데이터에 잘 반응하며, 다양한 종류의 문제에 잘 작동
• 단점: 여전히 하이퍼파라미터의 조정이 필요함

Adam(Adaptive Moment Estimation)

• 작동 방식: Momentum과 RMSprop의 아이디어를 결합하여, 모멘텀과 스케일링된 Gradient 모두를 고려함
• 장점: 다양한 조건에서 잘 작동하며, 특히 높은 차원의 데이터셋이나 매개변수가 많은 모델에서 효과적임
• 단점: 상대적으로 많은 메모리를 사용하며, 하이퍼파라미터 조정이 중요함

역전파(backpropagation)

• 신경망에서 출력 오차를 입력 층으로 전파하여 가중치를 조정하는 방법
• 출력층에서 발생한 오차를 역방향으로 전파하며, 각 노드의 가중치를 최적화함

[정의]

• 역전파는 딥러닝 모델을 훈련시키는 기본적인 알고리즘으로, 오차를 출력층에서 입력층으로 거슬러 올라가며 전파하는 방식
• 이 과정에서 각 층의 가중치는 오차에 기여하는 정도에 따라 조정됨

[작동 원리]

1. 먼저, 신경망은 입력 데이터에 대한 예측을 수행
2. 예측값과 실제값 사이의 오차를 계산
3. 이 오차를 기반으로, 출력층에서 시작하여 각 층의 가중치를 손실 함수의 그라디언트(기울기)에 따라 조정

• 이 과정은 신경망이 오차를 최소화하는 방향으로 학습하도록 함

소프트맥스(softmax)

• 다중 클래스 분류 문제에서 출력 레이어에 주로 사용되는 함수
• 소프트맥스 함수는 각 클래스에 대한 예측 확률을 계산하여, 가장 높은 확률을 가진 클래스를 모델의 예측으로 선택함

[작동 원리]

1. 각 클래스에 대한 신경망의 출력(일반적으로 로짓이라고 함)을 받아, 이를 정규화하여 각 클래스에 속할 확률로 변환함
2. 결과적으로, 모든 클래스에 대한 확률의 합이 1이 되도록 함

크로스 엔트로피(cross-entropy)

• 분류 문제에서 손실 함수로 널리 사용됨
• 모델의 예측 확률 분포와 실제 레이블의 분포 사이의 차이를 측정함
• 낮은 크로스 엔트로피 값은 모델의 예측이 정확함을 의미함

역전파 / 소프트맥스 함수 / 크로스 엔트로피 정리

• 역전파는 신경망이 오차를 줄이는 방향으로 학습하도록 도와줌
• 소프트맥스 함수는 다중 클래스 분류에서 모델의 출력을 확률로 변환함
• 크로스 엔트로피 손실은 모델의 예측이 얼마나 실제 레이블과 일치하는지를 측정함