일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- android exoplayer
- build with ai
- kotlin list
- getChangePayload
- FastAPI
- ListAdapter
- 유튜브
- android
- video caching
- ListAdapter DiffUtil
- 독서
- map
- AWS EC2
- exoplayer cache
- 스피너
- ExoPlayer
- android ktor
- DiffUtil.ItemCallback
- 시행착오
- ChatGPT
- 안드로이드
- 카카오톡 웹뷰
- kotlin collection
- llm
- Python
- doc2vec
- android custom view
- list map
- ktor api call
- ktor client
- Today
- Total
버튼 수집상
[메모] <Build With AI in Songdo> 후기 본문
일시: 2024년 04월 13일 (토)
장소: 인천 스타트업 파크
주최: GDG 인천
HelloWorld 2024에서 한상준 연사님의 발표에서 알게 된 행사.
LLM과 Gemini에 관련한 세션들이었다.
<트랜스포머는 대체될 수 있는가? - 이영빈>
사실 이 세션은 내용을 거의 알아듣지 못했다..
최근에 어떤 논의가 오가는지, 어떤 개념이 거론되는지 궁금해서 검색/정리 해본다.
- Transformer는 병렬처리를 위해 구글에서 만든 아키텍쳐.
- Transformer의 장점 : (RNN과 달리) Attention을 병렬처리 가능함.
- Attention Mechanism이란? 출처
입력 문장의 모든 단어를 동일한 가중치로 취급하지 않고, 출력 문장에서 특정 위치에 대응하는 입력 단어들에 더 많은 가중치를 부여하는 매커니즘
- Transformer의 단점 : 계산복잡도, 메모리 사용량, 약한 장거리 의존성 (long range dependency)
- Long Range Dependency란? 출처
자연어 처리에서의 장거리 종속성은 앞에 위치한 단어와 뒤에 위치한 단어 사이의 종속성을 의미하는 경우가 많다.
- Transformer 계열이 아닌 SSM 계열에서 mamba라는 모델이 있다.
- State Space Model (이하 SSM)
시계열 데이터 처리에 약한 Transformer의 대안으로 각광받고 있다고 한다..? 참고
SSM은 시계열 데이터를 분석하고 예측하는 데 효과적인 모델로, 데이터의 시간적 변화를 고려하여 미래를 예측합니다. 반면, Transformer는 '어텐션 메커니즘(Attention Mechanism)'을 사용하여 데이터의 관계를 학습합니다.
- SSM을 딥러닝에 도입하기 위해서는 이산화 처리가 필수다.
딥러닝은 기본적으로 이산형 변수를 다루는데 SSM은 연속형 변수.
- SSM을 딥러닝에 도입하면 얻을 수 있는 이점
장거리 의존성 해소할 수 있음
계산 효율성
메모리 사용량 적음
- 그래서 Transformer는 대체될 수 있는지?
지금은 아직 아니다.
-(Q&A) mamba로 나온 상용수준 모델은 없다.
상용화된 모델이 아니라 아직은 하나의 컨셉.
- 검색하다가 같은 연사분이 작성한 아티클을 발견했다.
발표 내용과 거의 유사하다.
<HAERAE: LLM의 한국어 능력을 어떻게 평가할 수 있는가? - 이한울>
언어모델을 평가하는 기준으로 쓰이는, 벤치마크 데이터셋이라는 것을 알게 되었다.
모델을 직접 개발하는 것이 아니더라도, LLM이라는 우산 아래에 다양한 비즈니스적인 수요가 있구나..
- 시중에 LLM이 너무 많기 때문에 일일히 써볼 수 없고, 언어모델의 평가가 중요해짐
- LLM은 학습데이터 corpus에 없는 데이터가 "창발"하는 특징 있음
그래서 사람을 평가하듯 여러가지 요소를 한 번에 고려해야 함
- HAERAE BENCH
한국어로 이루어진 전문지식 데이터셋
공무원시험 NCS등을 참고해서 사람의 정답률과 기계의 정답률을 비교할 수 있게 됨.
사람과 기계가 체감하는 난이도가 달랐다고 한다.
- Benchmark 란? 출처
Benchmark Datasets are like the SAT for LLMs. They are the fixed, standardized approach for assessing the quality of the models. The grades these LLMs get allows us to determine their performance and compare them, and what's more : know which subjects they are good at.
- 한국어 지식 순위가 가장 높은 LLM은 (당일 기준) GPT-4
궁금증: 평가기준이 가장 높은 LLM외의 모델을 써야할 이유가 있나? 이용요금?
- Chatbot Arena : 모델끼리 비교 가능
- Benchmarking 문제점1
프롬프트에 민감하다.
질문의 문장 순서를 바꾸는 것으로도 정답률에 영향을 줌.
언어모델의 성능은 특정 값이 아닌 범위값으로 파악해야 함.
- Benchmarking 문제점2
MCQA 특정 토큰이 등장할 확률, 즉 가장 그럴듯한 패턴.
MCQA가 실제 성능이진 않음.
- Benchmarking 문제점3
벤치마크로 학습을 시키면 '오염된 벤치마크'
- (Q&A) 왜 GPT-4의 한국어 처리 능력이 월등히 좋은 것으로 나올까?
오픈소스가 아니기 때문에 추측 밖에 할 수 없음.
다국어 언어모델은 언어간 전이현상이 있기 때문에 영어를 잘 하는 모델은 다른 언어도 잘 한다고 한다.
KMMLU 평가에서 한국의 맥락을 알아야 풀 수 있는 문제가 20%, 아닌 문제가 80%.
- LLM의 한국어 능력평가 (KMMLU)
<LLM의 Token Limit은 해소될 수 있을까? - 장승희>
RAG prompting을 떼작떼작 해봤던 경험이 있어서 그런지 가장 재밌게 들었다.
MemGPT라는 개념을 알게 되었다.
- 연사님은 몬드리안 AI에서 일하신다고 한다.
이 회사는 항상 GDG 행사를 후원하는 것 같던데.
- LLM이 언어를 생성하는 원리.
문장을 토큰으로 나눈다.
토큰 사이사이의 조사를 유추한다.
LLM은 N개의 단어로 구성된 문장을 '예측'하는 것.
- LLM의 문제점1: Hallucination
이전 단어로부터 다음 단어를 확률에 따라 예측하는 구조에서 기인함.
- LLM의 문제점2: Token Limitation
제약사항. 입력값이 길어질수록 연산할 내용이 많아짐.
- 현재의 트랜스포머 기반의 LLM이 이 문제들을 극복하지 못하면,
강인공지능으로 나아가기는 커녕 확률성 앵무새로 전락한다.
- 한국인이 토큰제한을 더 신경써야 하는 이유.
동일한 의미를 지닌 영어문장과 비교했을 때 토큰 수가 2배 차이 난다.
- 궁금증: 더 이상 쪼개면 안 되는, 의미있는 단어를 직접 입력하면 옵션이 있다고 들었는데.. 뭐라고 검색하지?
custom dictionary? custom vocabulary?
- 기존의 Token Limit 극복 방법 : VectorDB를 활용한 Retrieval 프로세스 고도화. (RAG)
splitting, summarizing, history memory, english translation 같은 트릭들.
한 마디로 검색 성능을 높여서 (프롬프팅에 활용할) 정보 손실을 줄인다.
- RAG의 한계.
어떤 데이터를 가져올지 판단할 부분이 명확하지 않다.
Retrieval 성능에 따라 프롬프팅의 결과가 크게 달라진다.
- 대안 : MemGPT
UC버클리에서 개발.
4,5개월 전에 출시, 파이썬 패키지로 나와있음.
OS 컨셉을 그대로 차용했다: 메모리 용량이 부족해서 처리하기 어려우면 HDD의 가상메모리를 할당하여 처리.
- Andrej Karpathy가 고안한 LLM OS
LLM OS. Bear with me I'm still cooking.
— Andrej Karpathy (@karpathy) November 11, 2023
Specs:
- LLM: OpenAI GPT-4 Turbo 256 core (batch size) processor @ 20Hz (tok/s)
- RAM: 128Ktok
- Filesystem: Ada002 pic.twitter.com/6n95iwE9fR
- LLM은 연산용이 아니라 언어를 생성하는 모델.
더하기 10만번 이런 건 잘 못함 -> 컨텍스트 윈도우가 늘어나기 때문.
결국 연산을 해주는 function을 직접 호출해서 그 결과를 LLM에 태우는 것이 Best Practice.
- MemGPT 논문 발췌.
컨텍스트를 그대로 입력하는 것은 비효율적.
LLM function calling을 사용해서 마치 무제한 컨텍스트가 있는 것처럼 구현.
MemGPT manages a virtual context (inspired by virtual memory in operating systems) to create unbounded LLM contextWith MemGPT, we demonstrate that LLMs can be taught to manage their own memory!
- MemGPT 구조.
- Archival Storage : 대화에 중요한 working context 관리.
RDBMS로 구성됨.
- Recall Storage : 이전의 Outdated된 대화를 가져옴.
질문을 받으면 Recall Storage를 제일 먼저 검색.
- (Q&A) Key Context는 어떤 기준으로 뽑는지?
LLM이 판단.
결국 Retrieval 프로세스를 LLM에 위임하는 것.
그럼 GPU를 더 쓰게 되긴 할 것.
'TIL - 메모' 카테고리의 다른 글
[메모] <딥린이를 위한 AI> 전 직장 CTO에게 들었던 딥러닝/인공지능 설명회 요약 (0) | 2024.05.13 |
---|---|
[메모] <Build With AI United 2024> 후기 (1) | 2024.04.28 |
[메모] <AI 시대, 성장하는 개발자가 되기 위한 전략> 웨비나 요약 (0) | 2024.04.25 |
[메모] HelloWorld 2024 후기 (0) | 2024.04.21 |
[메모] 인상적인 사이트들 정리 (0) | 2024.01.11 |