Replies: 26 comments 4 replies
-
첫 발표!기획: Dead Project Snipper간단 소개
프로젝트 3단 구성
의문: 룰베이스 해도 되는데 왜 LLM을 쓰는가?
이번 시즌 목표:
이론: Evaluation 개요LLM Evaluation의 평가 대상 3가지
Model Evaluations:
Evaluating Conversational FlowCoherence : 아웃풋이 말이 되는 소리를 하는지, 전체적인 논리적 흐름을 나타내는 개념입니다. Cohesion : 앞의 말과 다른 말이 두서없지 않게 잘 쓰여졌는지, 단어나 구 사이의 흐름을 이야기한다고 합니다. 독해력 테스트: Flesch Reading Ease test or Gunning Fog Index 등이 쓰임. **** 그렇지만 나는 Model 평가 하고싶은게 아니다! 프롬프트 평가를 진행하는걸 알아보자. Prompt EvaluationsPrompt - Offline Evaluation:Example Suites
Testing Suite (테스트 자동화에서 쓰이는 용어)과 다른 점은 ‘자동으로 측정할 방법’이 없다는 것. Finding Samples: 데이터셋 찾기질의응답 예제는 아래 세곳에서 찾으면 됨
1번 예시: AI를 적용하기도 전에 이미 데이터가 많은 경우가 있음. 예를 들면 논문과 abstract를 뽑아서 제공하는 경우를 생각. 논문을 abstract로 만드는 task는 충분히 많은 데이터를 활용할 수 있음. 이건 데이터셋이 있는 경우임 (1번) 2번 예시 1: 내 앱이 풀고 싶은 문제랑 완벽하게 들이맞는 데이터셋이 없는 경우 그와 ‘유사한’ 문제를 푸는 데이터셋을 찾기. 예를 들어 깃헙 코파일럿은 “유저의 다음 (코드) 입력이 무엇일가?”에 대한 추측을 해야 함. 정답을 알면 자동완성을 해 줌. 그러나 이 경우, 확장가능한(scaleable) 크기의 오픈 소스 ‘데이터셋’이 존재하지 않음. 그 대신 사용해 볼 수 있는 건 깃헙 리포에 널려있는 오픈 소스 코드들임. 이 경우 샘플을 다음 단계로 만들어볼 수 있음
2번 예시 2: 깃헙 코파일럿이 서비스를 시작하면 데이터가 축적되기 시작할 것임. 매우 현실적이고 좋은 데이터지만. 여기도 문제는 있음
3번 예시 : 데이터셋을 사용하거나, 합성 데이터 쓰기. LLM에게 특정 데이터를 만들라고 전할 수 있다. 토픽 생성 + 토픽별 예제까지 생성하라고 하는 게 꽤나 유용하다. 이 경우 주의사항:
Evaluating Solutions‘골드 스탠다드’ (=’정답’) : 예제 문제에 대한 예제 답변을 준비하고, 일치율이 높은지를 대응시킬 수 있는 경우. 예를 들어 역사적인 레코드(AI 적용 이전)을 크게 발굴해서 특정 질문에 대한 좋은 답변이 여러개가 있는지를 찾아내는 경우다. (토플 글쓰기 문제은행이 떠오르네요.) 이게 잘 되어 있으면 다른 평가나 데이터셋이 필요가 없을 수 있다.
그러나 자유 형식의 텍스트를 출력하는 경우 어려움: 예제 문제에 대한 예제 답변과 일치율이 높은지 대응시키기 어려움. 그 안에서 뭘 봐야 하는지도 애매함.
이럴 때 부분 매칭을 쓸 수 있음. 예를 들어 여행 목적지를 제안해줘야 하는 경우, 실제 여행지 (’국가’/’도시’)만 체크하고 그 외의 디테일을 전부 배제할 수 있음. 어떤 걸 배제할 것인가 결정하는게 어려움. 예를 들어 스마트 홈 관리자를 작성하는 경우를 생각해보자.
아래 두가지 기준으로 확인하는게 좋음
이런 특정들을 집어넣고, 이 경우 종류의 어떤 실패가 나는지와 그 파장이 어느정도인지 확인할 수 있음. 순환적인 문제가 있기는 함. 이 모델의 현 셋업에서 ‘현재’ 잘 해결하는 테스트가 있는데, 그걸 바탕으로 발전시키다 보면 발전 방향이 고정되어버릴 수 있음. 답변에 형식이 갖춰져 나오는 경우, 그 부분을 집중적으로 테스트하는건 가능함. 그 중에서 가장 크리티컬한 부분에 집중해야 할 것. 예를 들어 에이전트가 툴을 사용 하는 앱의 경우가 그럼 (위의 예시 참조). 왼쪽은 틀린 답변, 오른쪽은 맞는 답변들. 첫 토큰부터 to=functions가 안 나오는 경우 아예 글러먹을 가능성이 크므로, 이런 걸 없애는 방향으로 테스트를 만들어야겠다. Functional Testing 기능 테스트만약에 ‘골드 스탠다드’(=정답)가 존재하지 않거나 솔루션과 비교할 수 없는 상황이라면, 기능 테스트를 해 볼 수 있음. 예를 들면 LLM이 파싱이 가능한 답변을 리턴하는지, 내가 준 툴과 함수들만을 불러내는지 등을 확인할 수 있겠음. 형식이 정해지고 정량적인 경우에는 제한적으로 도움이 된다. (weak but effective sometimes) 코파일럿 예시로 돌아가자. 코파일럿으로 코드 파일 일부를 지운 다음 그걸 자동완성시킨 예시에서, 이 함수가 제대로 돌아가는지를 그 리포지토리에 달려 있는 유닛 테스트들에 대조해서 확인할 수 있다. LLM assessment & SOMA 평가특히 정성적인 답변의 경우, 다른 LLM보고 답변을 판단하라고 하는게 좋음 . 놀라운 점: 자기 답변을 자평하라고 하면 평가 능력이 떨어진다는 말이 있음! RLHF 하는 모델들의 경우, 인간이 살짝만 의심하는 경향을 보여도 자기 답을 과하게 수정한다고 함. SOMA: Specific Questions, Ordinaled scaled answers, Multiaspect coverage 의 줄임말 구체적 질문 Specific Questions 스마트 홈 예시로 돌아가자. “나 춥다” → Ordinaled Scaled Answers 어느 정도면 “통과”인지 정하기 어렵다. 답변을 Yes/no로 평가하지 말고, 연속적인 점수를 매기라고 하는 방식을 쓸 수 있다. 그 점수에 대해 설명을 제공하라는 식으로 작성한다. 이 문단 무슨 말인지 모르겠다: One such ambiguity is that it’s unclear how good a completion would need to be to be “right.” It’s no good if the standards that an individual answer is held to depend on the model’s capriciousness and the next answer is held to a different standard. It’s even worse if, instead of a random effect, there’s a systematic bias, such as the model holding answers trying for more accuracy to higher standards or accepting generally OK answers (that are more than 50% correct) while rejecting almost perfect answers (that are not completely right). Multi-aspect coverage 어떤 관점(aspect)에서 llm 답변을 평가할지를 적어줘라. 스마트 홈 관리자의 예시에서 “나 춥다”를 보면,
이 세가지 질문에 각각 점수를 주어서 더하면 되겠다. 어떤 관점/특징(aspect)에 집중할지에 대해 intent/execution 기준을 참고해보자
다른 예시: “모로코를 갈 때 절대 놓치면 안될 것” 을 여행 정보 앱에 물어보았을 때, 실제로 1. 관광 정보를 주었는가를 확인하고 (vs “모로코를 갈 때 비행기를 놓치지 마세요” 같은 엉뚱한 답변을 안하고) 2. 복합적으로 추천을 잘 해줬는가 (vs 일부만 추천, 예를 들어 최고의 카페만 추천한다거나 하지 않고)를 볼 수 있음. 이런게 (RTC: Relevance - truth - completeness) system. 깃헙 코파일럿에서 쓰는 평가 기준임. Soma Mastery
요약Prompt Versioning with Promtpfoo 소개 (박정환님 글 펌)Promptfoo 소개Promptfoo는 LLM(대형 언어 모델) 앱을 로컬에서 테스트하고 평가하는 강력한 도구입니다. LLM 개발 과정에서 프롬프트와 모델의 성능을 신속하게 평가할 수 있는 기능을 제공하여 개발자의 생산성을 높이고 앱의 품질을 보장합니다. 이 도구는 OpenAI, Anthropic, Azure, Google, HuggingFace, Llama 등 다양한 LLM API와 연동이 가능하며, 커스텀 API 프로바이더도 통합할 수 있습니다. Promptfoo는 LLM 개발에서 테스트 주도 개발(TDD)을 가능하게 하여, 시행착오를 반복하며 LLM 기반 애플리케이션을 개발하지 않을 수 있습니다. Promptfoo Workflow1544×332 28.7 KB Promptfoo가 다른 평가 도구들에 비해 특징적인 부분들은 다음과 같습니다:
Promptfoo의 주요 기능Promptfoo는 다음과 같은 주요 기능을 제공합니다:
프로젝트 구현 1 : Demo코랩 프로젝트! (소스는 아직 비공개, ) 프로젝트 구현 2 : PormptFoo + 테스트 / 실험 환경 (예진)설치(Installation)Install promptfoo globally using npm: npm install -g promptfoo 설치 안 하고 쓰려면 npx 사용하는 방법도 있음. 여기서는 뒤의 모든 과정을 npm 기준으로 정리함. npx promptfoo@latest 잘 설치되었는지 확인하고 싶으면 아래 코드로 버전 확인 (버전 넘버가 출력됨) promptfoo --version 설치는 최초 한 번만 하면 됨. 이전에 설치해두고 다시 돌릴 때는 명령 프롬프트에 promptfoo init 입력하고 바로 시작하면 됨. 시작(Initialization)Initialize a new promptfoo project: promptfoo init What would you like to do? Which model providers would you like to use? 의 질문 두 개가 나오는데 적절히 선택하면 Wrote promptfooconfig.yaml. Run 아래 Configuration 단계를 거친 후, 명령 프롬프트에 promptfoo eval 치라는 의미임. Configuration현재 디렉토리에 생성된 promptfooconfig.yaml 파일 열기 (VS로 열림) 💡promptfooconfig.yaml 파일은
구조로 되어 있음.
|
Beta Was this translation helpful? Give feedback.
-
Tensor Parallelism and Model Parallelism (모델 분산 학습)
Tensor Parallelism방식
특징
실제 적용분산 추론 및 서빙vLLM은 분산 텐서 병렬 추론 및 서빙를 지원합니다. 현재 Megatron-LM의 텐서 병렬 알고리즘을 비롯하여, 온라인 서빙용으로 파이프라인 병렬 기능을 베타로 지원하고 있습니다. 분산 런타임은 Ray 또는 파이썬 기본 multiprocessing을 통해 관리됩니다. 단일 노드에 배포하는 경우 multiprocessing을 사용할 수 있으며, 다중 노드 추론은 현재 Ray를 필요로 합니다. 기본적으로 Ray 배치 그룹이 아닐 경우 및 동일 노드에 충분한 GPU가 제공된다면 multiprocessing이 사용됩니다. 이러한 기본 설정은 LLM 클래스의 다중 GPU 추론을 실행하려면 LLM 클래스의 from vllm import LLM
llm = LLM("facebook/opt-13b", tensor_parallel_size=4)
output = llm.generate("San Francisco is a") 다중 GPU 서빙를 실행하려면 서버 시작 시 vllm serve facebook/opt-13b --tensor-parallel-size 4 추가적으로 vllm serve gpt2 --tensor-parallel-size 4 --pipeline-parallel-size 2 이와 같은 설정을 통해 vLLM에서 분산 추론 및 서빙를 효과적으로 수행할 수 있습니다. 참고 자료딥러닝 모델의 분산 학습이란?-Homo Nomad |
Beta Was this translation helpful? Give feedback.
-
LLM Prompt Caching 활용하기1. 개요프롬프트 정규화(Normalization)사용자1: "맛있는 파스타 레시피 알려줘" 프롬프트 정규화는 다양한 형태로 입력된 질문들을 표준화된 형태로 변환하는 과정으로 다음과 같은 단계를 거침:
주요 사용 시나리오
작동 프로세스flowchart TD
A[사용자 프롬프트 입력] --> B[프롬프트 정규화]
B --> C[캐시 키 생성]
C --> D{캐시 검색}
D -->|캐시 히트| E[저장된 응답 반환]
D -->|캐시 미스| F[LLM API 호출]
F --> G[응답 캐싱]
G --> H[응답 반환]
KV Caching과의 차이점목적 KV Caching: 단일 프롬프트 내에서의 attention states 재사용 Prompt Caching: 여러 프롬프트 간의 attention states 재사용 2. API 활용 방법ChatGPT기본적으로 prompt caching이 적용되며, 캐시 사용 시 비용이 절반으로 감소합니다.
특징:
Claude헤더에 curl https://api.anthropic.com/v1/messages \
--header "x-api-key: $ANTHROPIC_API_KEY" \
--header "anthropic-version: 2023-06-01" \
--header "content-type: application/json" \
--header "anthropic-beta: prompt-caching-2024-07-31" \
--data \
'{
"model": "claude-3-5-sonnet-20241022",
"max_tokens": 1024,
"system": [
{
"type": "text",
"text": "넌 법률문서를 해석하는 AI assistant야."
},
{
"type": "text",
"text": "여기 복잡한 법률 계약의 전문이 있어: [엄청 긴 법률 계약 문서]",
"cache_control": {"type": "ephemeral"}
}
],
"messages": [
{
"role": "user",
"content": "이 계약의 주요 약관은?"
}
]
}' 가격 정책
주요 특징:
3. 로컬 모델 설정참조: https://github.com/MachineLearningSystem/24MLSYS-prompt-cache.git 지원 아키텍처
설치 및 설정
pip install -r requirements.txt
cd ./dependency/bleurt
pip install . 디렉토리 구조
실행 방법# 캐시 활성화
python demo.py --enable_cache=True
# 캐시 비활성화
python demo.py --enable_cache=False |
Beta Was this translation helpful? Give feedback.
-
연속 배치를 통한 LLM 추론 최적화요약
소개대형 언어 모델(LLM)을 활용하는 애플리케이션의 급증은 생산 환경에서 이러한 모델을 효율적으로 제공하는 데 문제가 있었습니다. LLM이 텍스트를 생성하는 방식, 즉 반복적으로 출력 토큰을 생성하는 방식은 추론 프로세스에서 비효율성을 초래합니다. 정적 배치와 같은 전통적인 배치 전략은 GPU 리소스를 충분히 활용하지 못해 지연 시간 증가와 운영 비용 상승으로 이어집니다. 이러한 과제를 해결하기 위해 연속 배치(Continuous Batching) 라는 새로운 배치 전략이 개발되었습니다. 이 방법은 생성 중에 배치 내용을 동적으로 조정하여 추론 프로세스를 최적화하고, 처리량을 크게 향상시키고 지연 시간을 줄입니다. Continuous Batching에 대해서 자세히 알아보도록 하겠습니다. 배경LLM은 한 번에 하나의 단어 또는 토큰을 예측하여 텍스트를 생성합니다. 사용자로부터 입력 프롬프트를 받으면, 모델은 해당 프롬프트를 기반으로 다음에 올 단어를 예측하고, 그 단어를 추가한 새로운 시퀀스를 만들어 다시 다음 단어를 예측하는 과정을 반복합니다. 이 과정을 정지 조건(예: 특정 길이 도달 또는 종료 토큰 생성)까지 계속합니다. 이러한 반복적인 생성 과정은 다음과 같은 문제가 있습니다.
LLM 추론 파이프라인LLM 추론 과정은 크게 세 단계로 나눌 수 있습니다.
이렇게 모델은 한 번에 하나의 토큰을 생성하며, 이 과정이 반복적으로 이루어집니다. 단일 요청 처리와 배치 처리
배치 전략정적 배치(Static Batching)※색상 설명
정의 : 고정된 배치의 요청을 함께 처리하며, 추론 과정 내내 배치 크기가 일정하게 유지됩니다. 제한사항
비유 : 버스가 가득 찰 때까지 기다렸다가 출발하며, 경로를 완전히 완료할 때까지 새로운 승객을 태우지 않는 것과 같습니다. 일부 승객이 일찍 하차해도 그들의 좌석은 남은 경로 동안 비어 있게 됩니다. 동적 배치(Dynamic Batching)정의 : 요청이 도착함에 따라 동적으로 배치로 그룹화되며, 배치가 가득 차거나 일정 시간 후에 처리됩니다. 장점
제한사항
비유 : 버스가 좌석이 모두 채워지거나 일정 시간이 지나면 출발하지만, 여전히 버스가 경로를 완료할 때까지 새로운 승객을 태우지 않습니다. 일찍 목적지에 도달한 승객은 중간에 새 승객으로 대체될 수 없습니다. 연속 배치(Continuous Batching)정의 : 생성 과정 중에도 새로운 요청을 배치에 추가하고, 완료된 요청은 즉시 제거하여 리소스를 재활용하는 방식입니다. 장점
비유 : 시내버스가 경로를 따라 승객을 타고 내릴 수 있게 하여 버스가 항상 가득 차고 효율적으로 운영되는 것과 같습니다. 승객이 하차하면 즉시 새로운 승객이 탑승할 수 있어 좌석 활용이 극대화됩니다. 연속 배치의 작동 원리연속 배치는 LLM의 반복적인 생성 특성을 활용하여 배치의 구성원을 동적으로 관리합니다.
이를 통해 다양한 길이의 요청을 효율적으로 처리하고, GPU의 활용도를 높이며, 지연 시간을 줄일 수 있습니다. 벤치마크 결과연속 배치의 성능 향상은 다음과 같은 벤치마크 결과에서 확인할 수 있습니다. 실험 설정
처리량 결과
처리량 개선 요약
지연 시간 결과
결론연속 배치는 LLM 추론을 최적화하기 위한 중요한 기술입니다. LLM의 특성에 맞게 배치 전략을 조정함으로써 GPU 활용도를 높이고, 처리량을 향상시키며, 지연 시간을 줄일 수 있습니다. 오로지 연속 배치만으로 이루어진 벤치마크 결과는 아니지만 연속 배치를 도입함으로써 최대 23배의 처리량 향상이 있었음을 볼 수 있었습니다. |
Beta Was this translation helpful? Give feedback.
-
매일 아침 스트리밍 뉴스간단 소개왜 뉴스보다 나무위키가 재밌을까?나무위키는 전후 맥락이 잘 정리되어 있어서 어떤 사건/객체에 대해 전체적인 그림이 그려지지만, 뉴스는 하루하루 소식을 전하는 데에 충실할 뿐이다. 배경지식이 있는 사람만 재밌다. 이 서비스는 뭐가 다른가?소식을 사건의 배경과 함께 재구성하여 전달한다. 듣는 사람이 아는 것은 되도록 생략하고, 몰랐던 사실들을 잘 엮어 완결성 있는 ‘스토리’를 스트리밍 한다. 가령, 다음과 같은 예시들이 있을 수 있는데, 예시 1) 곽튜브-이나은 논란을 이해하기 위한 배경지식
예시 2) 삼성전자 주가가 떨어지는 이유를 설명하기 위한 배경지식
이렇게 그 날의 소식을 검색하고, 기반이 되는 지식을 병합해서 하나의 온전한 사실로 재구성한다. 큰그림: 사건의 수집, 반응과 담론의 기록을 자동화한다그리고 어떤 집단이 어떤 사건에 대해 어떤 반응을 보였는지, 어떤 사실에 대해 거부반응을 보이고 어떤 결론을 내고싶어 하는지를 연구할 수 있는 프레임워크를 구축한다. 서비스 구조도1차) 최종) 로드맵MVP 단계
1차 고도화
2차 고도화
현재 개발단계어떤 형태로 이벤트를 기록할지는 정의됨 키워드로 뉴스를 검색해서 규격화된 format으로 처리, DB에 적재하는 기능 개발중! 재사용성 있게 클래스로 쪼개려는 데서 시간 뺏기는 중..(search-refiner 부분) |
Beta Was this translation helpful? Give feedback.
-
강수진님 모두연 BIZ 강연 11/1Introduction(prompt engineering이 유망하다는 이야기와 근거 )
(scaling law를 일반인도 쓸 수 있는 시대는 좋다) (llm 쪽 모델 정보: 2024년 뉴스 소개) (chatbot arena가 무엇인지 보여주기 + 모델비교통계) The latest Prompt Engineering Techniques트렌드:프롬프트 엔지니어링 기법 흐름: LLM → VLM (비전 영상으로 확장되어 연구되는 중) The Prompt Report: A systematic Survy of Prompting Techniques (2024) 기법의 발전사 (2021~2024)Meta-Analysis of Prompting In Context Learning Zero-shot Few-shot Thought Generation Decomposition Ensembling Self-criticism: LLM이 자기 답변 셀프로 검증해라 2024 PE 중요한 사건 2개:Anthoropic - LLM is no longer a black box‘We mostly Treat AI Models as a black box’ ‘Sparse Autoencoder ‘ 모델 개발 AI의 신경망을 매핑하고, 특정 개념을 담고 있는 클러스터나 패턴을 찾아냄 Golden Gate Bridge 피쳐를 10배로 늘리면, Claude가 자신이 Golden Gate Bridge라고 함 피쳐가 뭉쳐서 등장한다 (?) Prompt Engineering, Feature Tuning o1 Model’s Advice on Prompt Engineering: o1 is an entirly different model
How Reasoning Works:output truncating - 정확히 무슨 말이지? extracting? Sharing Prompt Development Cases
사용자 의도 파악을 위한 단서들
대화 분석의 4가지 기준 / 프롬프트 제작 / LLM MODEL (이런게 있다만 하고 빨리 넘어감) 세그먼트 비율 분포 불균형1 정보 검색을 하는 사용자의 비율이 압도적이다 (chatgpt plugins 망함. 사람들이 굳이 다른 서비스 할때 GPT를 쓰는걸… 귀찮다고 느낀다) 2 사용자의 리텐션이 저조하다. 두가지 이유이다 프롬프트가 너무 간단하여 좋은 결과를 얻지 못한다 (메타 프롬프트 & 프롬프트 제너레이터 등장) 3 불만족한 사용자 세그먼트가 만족한 사용자 세그먼트보다 많다 시스템 프롬프트 A/B 테스트LLM을 작동하게 하는 설정 값 현 날짜, 시간, 모델이 학습한 지식정보 knowledge cut-off 등을 주입함. 챗봇의 답변 스타일 조정: 여섯가지 톤과 fine-tuning 프롬프트 평가Preference 개념 - 두 대안 사이에서의 비대칭을 일컫는 말 평가 지표텍스트, 프레젠테이션, 인터랙션 |
Beta Was this translation helpful? Give feedback.
-
Securing and governing models with LLMOps대규모 언어 모델(LLM)은 다양한 분야에서 활용 의료, 법률, 금융 등 민감한 분야에서는 보안 문제가 중요 LLM의 취약성은 개인 정보 침해, 잘못된 정보 생성, 모델 도난, 데이터 오염 등의 위험을 초래 이를 방지하기 위해 강력한 보안 조치가 필요 LLM의 OWASP(Open Web Application Security Project) 상위 10대 보안 위험1. 프롬프트 인젝션 (Prompt Injection)SQL Injection에서 유래 사용자가 프롬프트를 교묘하게 조작하여 모델이 원래 의도와 다르게 동작하도록 만드는 공격 Direct(의도적) vs. Indirect(비의도적) Obfuscation 예시 입력 검증을 강화 및 필터링으로 악성 프롬프트 차단 2. 불안전한 출력 처리 (Insecure Output Handling)LLM 출력이 검증 없이 사용될 때 발생하는 보안 위험으로, 코드 실행이나 웹 콘텐츠 삽입 시 민감 데이터 노출 가능 출력 검토와 데이터 세척을 통해 민감 데이터 노출 방지 3. 학습 데이터 중독 (Training Data Poisoning)악의적인 데이터가 학습 과정에 삽입되어 모델이 편향된 답변을 하도록 조작 데이터 출처 검증과 감사로 학습 데이터의 무결성 유지 4. 모델 서비스 거부 (Model Denial of Service)과도한 요청으로 LLM 자원을 고갈시켜 사용 불능 상태를 유도 DDoS 공격과 유사, 단일 요청으로도 큰 부하 매우 긴 텍스트나 복잡한 수학 문제를 계속 요청 요청 토큰 및 속도 제한과 모니터링으로 자원 고갈 방지 5. 공급망 취약성 (Supply Chain Vulnerabilities)외부 라이브러리나 데이터셋에 삽입된 악성 코드로 인해 시스템 전체가 위험에 노출 외부 라이브러리 검토와 보안 업데이트 유지 6. 민감 정보 노출 (Sensitive Information Disclosure)LLM이 의도치 않게 민감한 데이터를 공개 자동 필터링 도구와 보안 정책으로 데이터 보호 7. 불안전한 플러그인 설계 (Insecure Plugin Design):보안 부족으로 시스템 전체의 취약성 증가 정기적인 보안 검사와 최소 권한 부여 8. 과도한 자율성 (Excessive Agency)인간의 적절한 감독 없이 자동 결정으로 인해 발생하는 문제 인간의 감독 절차와 행동 경계 설정 9. 과도한 의존성 (Overreliance)중요한 결정을 모델에 맡겨 적절한 검증 없이 작동 LLM 출력에 대한 인간 검토와 혼합 모델 사용 10. 모델 도난 (Model Theft)LLM의 설정에 무단 접근 및 복제 모델 암호화와 접근 제어, 법적 보호 조치 출처: https://www.wattlecorp.com/llm-security/ |
Beta Was this translation helpful? Give feedback.
-
Multi-GPU 전략LLM을 접했을 떄, 저런 거대한 파라미터를 담을 수 있는 GPU가 있는 건가..? 아니면, 여러 대의 GPU를 사용한건가? 라는 의문이 들었습니다. 당연히 GPU 클러스터를 사용하였다고 합니다. 아마 대부분의 분들이 알고 있겠지만, 이 때 사용되는 기법들에 대한 내용을 알아보도록 하겠습니다. 목차는 다음과 같습니다.
들어가기에 앞서서먼저 본격적으로 들어가기에 앞서 DDP와 FSDP의 핵심적인 방법론에 대해 간단하게 짚을 수 있도록 하겠습니다. 먼저 모든 multi-gpu 전략에서는 쓰레드가 아닌 프로세스 단위로 처리됩니다. 하나의 프로세스에 하나의 GPU를 할당 받아 각 연산을 처리하도록 되어 있습니다. 이 때 각 프로세스를 관리하는 ProcessGroup이라는 객체가 생성되어 관리합니다. IPCIPC는 Inter Process Communication의 약자로, 프로세스 간의 통신을 말합니다. IPC는 다만, 프로그래밍과 데이터 처리에서 아주 자연스러운 개념은 아닙니다. 왜냐면, 기본적으로 프로그램은 실행되는 순간 해당 프로그램이 점유하는 메모리 공간을 배당받고 해당 메모리 공간 내에서 데이터를 처리하기 때문입니다. 이는 각 프로그램의 독립성을 보장하기 위해서도 행해지는 조치인데, 하나의 프로그램이 연산 과정에서 다른 프로그램의 메모리의 데이터를 변경시키거나 훼손시키면 안 되기 때문입니다. 하지만 이와 별개로 IPC의 중요성은 서로 동시에 처리되는 프로그램끼리 각 프로세스에서 처리되는 데이터에 서로 연산을 처리해야 하는 경우에 부각됩니다. 예를 들어 OS에서 사용자가 동시에 여러 개의 프로그램을 사용하는 경우나 여러 개의 센서 데이터를 받아 종합적으로 처리해야 할 때, 등등이 있겠습니다. 실제로 DDP와 FSDP를 사용시 아래의 IPC 중 하나를 골라 사용할 수 있습니다. 아래에 간단하게 IPC의 종류를 설명해보겠습니다. Shared MemoryShared Memory는 이름에서 바로 직관적으로 알 수 있듯이, 여러 개의 프로세스가 같은 메모리 공간을 점유하는 것입니다. 이 경우에는 다른 프로세스 간에 실제로 데이터가 송수신되는 처리가 될 필요 없이 같은 메모리 공간에서 읽기/쓰기 처리를 하기 때문에 매우 빠른 데이터 처리가 가능합니다. 하지만, 하나의 프로세스가 점유하고 있는 데이터에 대해서 다른 프로세스가 접근하는 것을 막아줘야 합니다. 이유는 원래 각 프로세스끼리 독립된 메모리 공간을 갖는 이유와 같습니다. Shared File System하나의 프로세스가 파일을 쓰면 다른 프로세스들이 해당 파일을 열어서 읽는 형태의 데이터 공유 방법입니다. PUB/SUB 방식의 통신과 상당히 유사함을 알 수 있습니다. PipePIPE는 사실 Shared File System과 유사합니다. 실제로는 Shared Memory에서 필수적으로 사용하는 Message Queue 방식을 파일 형태로 하여 한 쪽에서 쓰면 한 쪽에서 읽는 것입니다. 다만 일반적인 파일이 아닌 OS의 커널에서 관리하는 특별한 형태의 파일입니다. Socket Communication위의 방안들은 모두 하나의 호스트 머신에서 프로세스끼리 통신하는 과정입니다. 만약, 같은 서버 클러스터 혹은 원격 상황에서 서로 다른 프로세스끼리 데이터를 공유해야 하는 상황이 있다면 이는 필연적으로 네트워크를 통해 통신해야 합니다. 소켓 통신은 TCP/UDP 통신의 과정이긴 하지만, 실제로 직접적으로 소켓 통신을 가장 활발하게 사용하는 경우는 IPC가 요구되는 상황입니다. 통신 패턴Point to Point to Communication하나의 프로세스와 다른 하나의 프로세스가 직접 통신하는 경우이다. 좀 더 세밀하게 프로세스들을 제어해야 하는 상황에서 사용하기 좋은 방안이다. 메소드로는
Collective Communicationpoint to point 통신 방식과는 다르게 프로레스 그룹 내의 모든 프로세스들이 통신 패턴에 맞추어 통신할 수 있게 함. Collective Patterns Scatter : 해당 패턴은 각 텐서를 분할 후에 각 프로세스에 하나씩 할당하는 패턴이다. Reduction에 사용되는 연산 같은 경우 torch.distributed 에 정의된 4개의 연산이 존재한다.
torch.distributed 에 정의된 메소드들은 아래와 같다.
DDP학습 과정 요약
Ring All Reduce각기 흩어져 있는 프로세스의 데이터를 한군데로 합치는 과정의 연산은 분산 학습에서 필수적인 과정입니다. 위의 이러한 collectives 연산 과정에서 allreduce가 사용되곤 했지만, 필수적으로 all-reduce과정의 연산은 master 프로세스의 과도한 부담을 안겨 주므로 이를 보완하고자 ring-allreduce가 제안되었습니다. 2 . 프로세스의 chunk[p]를
FSDPFSDP는 Fully Sharded Data Parellel의 약자로 DDP의 사촌(?)입니다. DDP의 사촌이라한 까닭은 DDP처럼 모델을 관리하는 프로세스 그룹이 스폰되고 통신을 통해 순전파, 역전파, 옵티마이징에서의 parameter와 grad를 동기화하기 때문입니다. 그렇다면, DDP 와의 가장 큰 차이점은 무엇이 있을까, 가장 큰 차이점은 두 가지가 있습니다.
Workflow이제는 모델의 생성, 모델의 분할 샤딩 전략, 순전파, 역전파, 통신패턴 등을 살펴 보겠습니다. 모델 파티셔닝
모델 샤딩
모델 초기화모델을 로컬에서 한 번에 올리 때와는 달리 모델 인스턴스를 생성한 후에 분할하는 것은 소스코드의 수정을 피할 수 없었습니다. 논문에서는 이를 해결하기 위해서는 두 가지 문제를 해결해야 한다고 합니다.
1번의 문제를 해결하기 위해서 FSDP 2번의 경우가 만족되기 위해서는, 이상적으로 정확하게 할당 받은 샤드만을 디바이스에서 생성해야 합니다. 하지만 , 모델의 특정 파라미터 구간이 init() 함수 내부에서 다른 인자나, 다른 레이어에 의존적으로 설계된 경우 이를 반영하여 분할하는 것은 매우 까다로운 일입니다. 즉 할당받지 않은 샤드에 모델의 초기화에 관련된 정보가 있는 경우를 말합니다. 이를 해결하기 위해서, FSDP에서는 하나의 순전파/역전파에서 샤드를 다루는 것처럼, 한 번에 하나씩 지연된 초기화를 도입하여 생성하는 방식으로 해결합니다. 순전파와 역전파의 간단한 예시샤딩 전략샤딩 전략은 샤딩을 어떤 방식으로 수행할 것인가를 결정하는 것입니다. 이는, 몇 개의 Rank를 사용할 것인가에 관련된 부분과 어떤 대상을 샤딩 대상으로 둘 것인가에 관한 내용으로 나뉠 수 있습니다. FSDP 논문에서는 샤딩 전략과 관련하여, 샤딩할 때 사용될 Rank의 개수를 조절하는 요인인 샤딩 팩터 어떤 대상을 샤딩 대상으로 두느냐에 관한 내용은 torch.distributed의 프레임워크에서 지원하는 전략으로 학습할 때 대상이 되는 파라미터 (모델 파라미터, 옵티마이저의 파라미터, gradient 등)을 전부 샤딩할지 아니면, 옵티마이저와 gradient만 샤딩할지에 관한 내용입니다. 샤딩 팩터에 따른 샤딩 전략샤딩 팩터
샤딩 팩터 사용되는 메모리가 제일 적고 통신 부담은 제일 큰 방식의 샤딩입니다. 다시 인용한 위의 그림에서 볼 수 있다시피, input size가 모두 EVEN 합니다. 이 때 even한 사이즈를 맞추기 위해 패딩이 사용됩니다. EVEN한 사이즈는 CUDA의 NCCL 라이브러리에서 통신 시 가해지는 부담을 최소화하기 위함입니다. 더불어서, 이 때 최대한 GPU의 Vram 가용한 선 내에서 최대한 커다란 양의 배치 사이즈를 가져야 통신에 발생하는 부담을 줄일 수가 있습니다. 이유는 위와 마찬가지입니. FSDP에서 위와 같은 텐서의 분배를 가능하게 하도록 하기 위하여, 순전파
역전파
All Reduce to (Reduce-Scatter, All-gather)FSDP의 샤딩과정을 보는 방법은 all_reduce 연산을 Reduce-Scatter 와 All-gather 분해한 후 재배치하는 과정으로 이해하는 것 입니다. All_Reduce 연산은 아래와 같이 분할한다. 즉, 궁극적으로 각 GPU에 배분된 파라미터를 결국 하나의 계산된 결과값으로 모든 gpu에서 공유하고 갖고 있는 것을 말합니다. 샤딩 팩터가
위의 예시 그림에서와 같이 하이브리드 샤딩은 샤딩과 복제를 사용합니다. 샤드는 샤드의 그룹을 이 때 발생하는 gradient의 reduction 연산의 경우, 각 샤드 그룹 내부에 행해지는 reduce-scatter연산을 따라서 행해지는 all-reduce 연산과 같습니다. 하이브리드 샤딩은 가속화 된 데이터 센터의 지역성을 이점으로 취할 수 있고, 호스트 간의 통신 트래픽을 감소시킬 수 있는 이점이 있습니다. 샤딩 대상에 따른 샤딩 전략이는 토치 프레임워크에서 지원하는 기능 혹은 전략이라 할 수 있습니다. 샤딩하고자 하는 범주를 설정할 수 있는 전략이라고 할 수 있습니다. zero3sharding 학습할 때 대상이 되는 파라미터 (모델 파라미터, 옵티마이저의 파라미터, gradient 등)을 전부 샤딩하는 전략을 말합니다. zero2sharding 옵티마이저와 gradient만 샤딩하는 전략을 말합니다. 아래와 같이 파라미터를 조절하여 실행할 수 있습니다. torch.cuda.set_device(local_rank)
model = FSDP(model,
auto_wrap_policy=t5_auto_wrap_policy,
mixed_precision=bfSixteen,
device_id=torch.cuda.current_device(),
sharding_strategy=ShardingStrategy.SHARD_GRAD_OP # ZERO2) AutogrdFSDP의
(1)번은 (2)번은 gradient에 hook을 등록합니다. (webhook이라고 할 때의 그 hook이 맞습니다.) 따라서, multi-gpu inference이는 때에 따라 각각 다르며 ,위에 언급드린 모델 파티셔닝을 사용할 수 있으며, TensorParellel과 pipeline parellel 등이 인퍼런스 시에 사용될 수 있습니다. 프레임워크에서 편안하게 사용하고자 하는 경우에는 huggingface의 multigpu-inference와 관련한 프레임워크가 있으니 참고바랍니다. 만약 multi-gpu를 통한 routing을 하고 싶으신 거라면, router를 통해 각 모델이 할당된 gpu의 인덱스를 사용하는 방안이 있는 것 같습니다. 어떤 multi-gpu 전략을 수행해야 하는가?마지막으로, 각 용도에 맞는 어떤 multi-gpu 전략을 수행해야할지를 정리하면서 마치도록 하겠습니다.
|
Beta Was this translation helpful? Give feedback.
-
Knowledge Distillation ## Knowledge DistillationKnowledge Distillation은 NIPS 2014 workshop에서 발표한 논문 “Distilling the Knowledge in a Neural Network”에서 처음으로 등장한 개념입니다. 어떻게 큰 모델로부터 작은 모델로 지식을 전달할 수 있는 걸까요 Soft Label일반적으로, 이미지 클래스 분류와 같은 task는 신경망의 마지막 softmax 레이어를 통해 각 클래스의 확률값을 뱉어내게 됩니다. 다음과 같은 수식을 통해 ii번째 클래스에 대한 확률값(qiqi)를 만들어내는 방식입니다. 이를 레이블을 통해 구체적으로 살펴보겠습니다. (↑) 기존의 개 사진의 레이블을 Original (Hard) Targets라고 생각할 수 있습니다. (Hard = discrete) Hard Label vs. Soft Label:
이를 통해 교사모델의 미세한 판단과 추론 방식을 학습하게 됨 Temperature의 역할 emperature는 이 과정에서 중요한 역할을 합니다. 구체적으로 설명하면:
요약하자면:
요약이 구조는 Teacher 모델의 soft labels를 통해 Student 모델이 단순한 정답만 학습하는 것이 아니라, Teacher 모델의 세부적인 판단까지 배우도록 유도합니다. Distillation Loss와 Cross Entropy Loss의 조합을 통해 Student 모델이 Teacher 모델의 지식을 잘 이어받으면서도 정확한 분류 성능을 유지할 수 있게 합니다. t는 하이퍼 파라미터로 사람이 실험적으로 찾아야 함. 일반적으로 T를 2~5정도로 설정하고 찾음
언어모델에서의 Knowledge Distillation 선행사례DistilBERT구글의 bert-base에서 레이어 수를 절반으로 줄이고 Pooling layer를 제거하여 Student 모델을 만들었습니다. 학습할 때에는 위에서 언급한 L1, L2에 더해 Student과 Teacher의 마지막 Hidden state도 Cosine embedding loss를 계산하여 추가적인 성능 향상을 이끌었습니다. BERT에 비해 크기는 40% 줄였지만(440mb → 268mb), 성능은 97%로 유지하였습니다.
TinyBERT 4구글의 bert-base에서 레이어 수를 12개에서 4개로 줄여서 Student 모델을 만들었습니다. L1, L2 로스에 더해 Transformer layer의 Hidden state와 Attention matrix의 오차도 계산하였으며, 성능은 96.8%로 유지하였지만 크기는 87% 줄였습니다(440mb → 62mb). DistilGPT2DistilBERT와 거의 동일한 방법으로 구현되었습니다. 모델 크기는 40% 감소되었으며(548mb → 353mb), 성능 감소치는 보고되지 않았습니다. White-Box KD
이 방식은 교사 모델 내부 정보를 활용하기 때문에 학생 모델이 더 높은 수준의 표현력을 얻을 수 있습니다. → 학생모델이 교사모델의 중간레이어 출력까지 가깝게 학습되게 하는 방식 출력뿐 아니라 레이어 출력까지 반영. → 종합적인 로스 계산 Kullback-Leibler Divergence 등을 사용해 정밀하게 로스계산 Black-Box KD
Black-Box 방식은 교사 모델의 내부를 알 수 없는 상황에서도 예측 결과만으로 학생 모델을 학습시키는 방법이므로, 모델의 구조에 제한 없이 사용할 수 있는 장점이 있습니다. PruningUnstructured Pruning과 Structured Pruning은 AI 모델의 크기를 줄이고 효율성을 높이기 위해 사용되는 기술입니다. 이제 각각을 쉽게 설명해볼게요. Unstructured Pruning https://arxiv.org/abs/2301.00774
Structured Pruning
Semi-structured Pruning
분석 (GUM의 연구) https://arxiv.org/abs/2302.03773
혁신적 방법 (GUM의 접근 방식)
quantization
PTQ의 주요 특징과 다양한 방식
PTQ의 장점과 단점 요약
|
Beta Was this translation helpful? Give feedback.
-
LLM 온라인 평가요약
소개Github Copliot은 LLM을 사용한 최초의 산업 규모 응용 프로그램입니다. 이 Copilot의 codebase에서 가장 오래된 부분이자 첫번째 코드는 proxy, prompt, UI, IDE가 아닌 평가였으며, 이는 매우 빠르고 성공적으로 진행할 수 있게 한 원동력입니다. 성공적인 원동력의 이유는 평가로 인해 변경 사항을 적용할때마다 올바른 방향으로 나아가는 것인지, 실수인지, 혹은 큰 영향을 미치지는 못했지만 좋은 시도였는지 직접 확인할 수 있기 때문입니다. 이것이 LLM 애플리케이션에 대한 평가 프레임워크의 주요 장점입니다. 평가 프레임워크의 두가지 큰 범주로 나누면 오프라인 평가, 온라인 평가로 나누어집니다. 온라인 평가는 추후 자세히 소개할 것이고, 오프라인 테스트에 대해 간단하게 정리하면 다음과 같습니다 오프라인 평가
온라인 평가에 대해 자세히 설명하기 전 테스트에 대해 간단하게 설명해 보겠습니다.
그리고 테스트 접근법에 따라 다음과 같이 나눌 수 있습니다.
온라인 평가온라인 평가는 오프라인 테스트를 진행 후 출시된 앱을 실제로 실행하면서 실제 사용자가 루프에 참여하게 되고, 도출된 사용자의 데이터 및 피드백을 통해 라이브 성능과 사용자 만족도를 평가하는 것입니다. 온라인 테스트 진행시 문제점
A/B Testing분할 테스트 또는 버킷 테스트라고도 하며, 두가지 콘텐츠를 비교하여 방문자/뷰어가 더 높은 관심을 보이는 버전을 확인합니다. 주요 측정지표를 기반으로 가장 성공적인 버전을 측정하기 위해 사용자들을 두 집단 A,B로 나누고, 각 집단에 기존모델(A), 새 모델(B)을 테스트하는 대조 실험입니다. 이는 실제 사용자의 직/간접적인 반응을 평가 지표로 측정 할 수 있습니다. 온라인 테스트 초기 진행 시 어느 부분을 최적화 할 것인지 결정하는 것이 가장 중요한데 이는 사전에 오프라인 테스트 반복 진행을 통해 테스트할 부분을 줄이고 최적화 할려는 지표를 미리 정의할 수 있습니다. Metrics평가지표에는 5가지로 나눌 수 있다.
결론평가는 중요한 주제이지만, 조건에 따라 조정해야 할 부분도 많고 완벽한 선택은 각 애플리케이션마다 달라 어렵습니다. 하지만 항상 사실인 것은 평가가 앱의 지속적인 개발에 필수적이며, 이 분야에 투자한 시간은 시간 낭비가 아니라는 것입니다. REF
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
프로젝트 컨셉-> LLM을 활용한 주술앱 서비스 제작 샘플 (리액트)
점술, 주술 시장의 셀링포인트는 신비롭다는 이미지입니다. 무당 등을 봐도 온갖 화려한 장식으로 그들의 신비로움을 표현하려고하죠. 타로의 특성은 그 신비로움이 카드라는 오브젝트를 중심으로 이뤄진다는 점입니다. 오브젝트 자체가 매우 이국적이면서도 은밀하고 신비롭다는 이미지가 강합니다. 따라서, 가상적인 서비스기반인 온라인에서, 오브젝트 중심의 이미지 메이킹만으로도 사람들의 니즈를 충족시키는 서비스 제작이 가능한 이유입니다.
→ ❗친밀감이 생기는 대화형으로 만들어야 한다.
→ 점술사의 ❗캐릭터성을 강조해야 한다.
→ ❗미려한 디자인의 타로카드를 제작해야 한다.
→ 점술의 셀링포인트는 얼마나 ❗신비로움으로 사람들을 매료시키냐에 있습니다.
대화형 → 카드를 한장 뽑을때마다 그사람의 ‘고민’과 ‘상황’을 반영해 캐릭터성→ 일러스트를 매력적으로 준비해 캐릭성을 부여합니다. 샘플 이미지(firefly를 통한 스타일링을 지정한 생성) 프로젝트 진행사항 -> DB 스키마제작 프로젝트 남은 사항 |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Multi AgentAgent
Stockelper Agent
Multi AgentMulti Agent Workflow
Single Agent vs Multi Agent
Multi Agent TrendFact-Subjectivity Aware Reasoning Multi AgentMulti Agent FrameworkCrewAI
AutoGenLangGraphCrewAI vs AutoGen vs LangGraph
Referencehttps://towardsdatascience.com/building-a-simple-agent-with-tools-and-toolkits-in-langchain-77e0f9bd1fa5 |
Beta Was this translation helpful? Give feedback.
-
논문: Unifying Large Language Models and Knowledge Graphs [링크]
|
Beta Was this translation helpful? Give feedback.
-
Prompt Engineering for LLMs 책의 Chapter 5. Prompt Content, Chapter 6. Assembling The Prompt 내용을 요약 정리한 글입니다. Prompt Content일반적인 문제를 구조화하고 명확히 하는 데 사용되는 정적 콘텐츠와 요청 시 검색하여 특정 사용자와 해당 사용자의 특정 문제에 대한 세부 정보를 전달하는 데 사용되는 동적 콘텐츠로 나뉨. 정적 콘텐츠
동적 콘텐츠
Retrieval-Augmented Generation (RAG)
RAG를 위한 요약
결론
Assembling the prompt이상적인 프롬프트 구조
Relationships Among Prompt Elements프롬프트 요소 간 관계를 구성할 때 고려해야 할 세 가지 중요한 측면 : 위치, 중요도, 의존성.
Putting It All Together
결론
프로젝트 적용
추가 참고할만한 자료
|
Beta Was this translation helpful? Give feedback.
-
StockelperPart 1. Pseudo-Lab 8기 Stockelper가짜연구소 8기 Stockelper 프로젝트 개발기[NAVER Cloud X PseudoLab Green Developers] 주식투자 도우미 챗봇 개발기 2 이달의 Nclouder 10월 선정[네이버클라우드 (NAVER Cloud) : 네이버 블로그] Part 2. Pseudo-Lab 9기 GJS5 Stockelper개선 필요 사항
LLM 프레임워크 및 백엔드 소스코드 고도화(LangGraph)기존 stockelper agent 분석
LangGraph로 stockelper agent 구현
Stockelper Nodes
Stockelper States & Configuration
Langfuse Callback
종목 관련 뉴스, 투자 관련 정보, 주식 정보 등 수집 정보 고도화 및 스케줄링 개선Server
Database
수집 데이터
변동률 예측 모델 개발
국내 주식(KOSPI, KOSDAQ, KONEX) 이외 시장 반영NASDAQhttps://github.com/jh941213/Stockelper_nasdaq
기업 간 관계정보를 추가한 LLM 답변 고도화(지식그래프 적용)지식그래프 관련 연구1. [지식 그래프 연구 및 적용 방안 개발] 계획 세우기 [2. [지식 그래프 연구 및 적용 방안 개발] - 지식그래프 활용 사례 조사](https://www.notion.so/2-44e78322d52747f09b37429f37da3321?pvs=21)**](https://www.notion.so/2-44e78322d52747f09b37429f37da3321?pvs=21) [3. [지식 그래프 연구 및 적용 방안 개발] - GraphRAG 실습](https://www.notion.so/3-GraphRAG-c077fe64ccfc4e25856661c050bb5ef4?pvs=21) [4. [지식 그래프 연구 및 적용 방안 개발] - GraphRAG 실습, 한투API, LLM 논문 찾기](https://www.notion.so/4-GraphRAG-API-LLM-b603ef11db2f4af0b4c3dbf586b2b36c?pvs=21) [5. [지식 그래프 연구 및 적용 방안 개발] - 발표준비 & GUG 세미나 정리](https://www.notion.so/5-GUG-62591d0b44b74aea803dfc2630fbcbf2?pvs=21) KG 구축(국내 주식)
개선 사항들을 반영한 UI 개선가쓰돼https://tossinvest.com/signin?redirectUrl=%2Fscreener%2Fuser%2Fcustom 밑그림
TODO
|
Beta Was this translation helpful? Give feedback.
-
CPU vs GPU공통점
CPU(Central Processing Unit)
GPU(Graphics Processing Unit)
Nvidia ArchitectureTF32
A100 GPU에서 format별 연산량
CPU 추론GGML(GPT-Generated Model Language)
GGUF(GPT-Generated Unified Format)
llama.cpp
bitnet.cpp
GPU 추론을 위한 양자화AWQ(Activation-aware Weight Quantization)
GPTQ
참고한 자료https://github.com/ggerganov/ggml/blob/master/docs/gguf.md |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Quantization목차)
1. Quantization 이란?정의) Quantization(양자화): 모델의 parameter, activation을 더 낮은 bit로 표현하며 memory usage를 줄이고 memory access 속도를 향상시키는 방법 (e.g., FP32 → FP16) 배경)
장점 및 의의)
2. Quantization 종류
3. 관련 논문 소개3-1) QAT (Quantization Aware Training)
3-2) PTQ (Post Training Quantization)
느낀점)Quantization은 이상치 분석 및 관리가 중요한 부분인 것 같습니다 |
Beta Was this translation helpful? Give feedback.
-
Incorporating Continuous Improvement in LLMLifecycle of LLMChallenges in LLMExample Case지속적 개선을 위한 필수 요소Three Phase Testing ApproachImportance of BenchmarkOpenAI's Evals: https://github.com/openai/evals Anthropic's initiative: https://www.anthropic.com/news/a-new-initiative-for-developing-third-party-model-evaluations Google's BIG-bench: https://github.com/google/BIG-bench Salesforce's benchmark : https://www.salesforce.com/blog/llm-benchmark/?bc=OTH
Creating Your Own BenchmarkThe Importance of Customer Feedback in LLM Benchmarkingself-evolving models예시) 사용자가 모델에게 출시 예정인 새로운 휴대폰인 NovaPhone의 제품 상세 페이지 작성을 요청합니다. 사용자는 "적응형 화면 밝기" 및 새로운 휴대폰의 다른 기능과 성능을 강조합니다. 자체 진화 모델은 이 "적응형 화면 밝기"에 대한 지식이 없기 때문에 이를 불확실한 기능으로 식별하고 - 이 새로운 사실을 학습 대상으로 표시합니다. 모델이 제품 페이지를 생성하는 동안, 동시에 이 새로운 정보를 자신의 메모리에 통합합니다. 이 시점 이후부터 모델은 수동 업데이트 없이도 동적으로 적응하면서 사용자와의 향후 상호작용에서 이 새로운 사실들을 자연스럽게 통합할 수 있습니다.
자체 진화 모델의 위험성
Reference
|
Beta Was this translation helpful? Give feedback.
-
Trade-offs between inference speed and output quality |
Beta Was this translation helpful? Give feedback.
-
GraphRAG (From Local to Global: A Graph RAG Approach to Query-Focused Summarization)논문 링크 : https://arxiv.org/pdf/2404.16130 프로젝트 링크 : https://www.microsoft.com/en-us/research/project/graphrag/ 배경 및 문제점기존의 Retrieval-Augmented Generation(RAG) 방식은 다음과 같은 문제점을 갖고 있습니다.
“What are the top 5 themes in the data?”와 같이 데이터 전체를 아우르는 질문을 하였을때 Basic한 RAG보다 GraphRAG가 훨씬 답변의 정확도와 내용이 풍부한 것을 확인할 수 있다. 이러한 부분을 해결하고자 Microsoft에서는 GraphRAG 방법론을 제안하였습니다. GraphRAG 프로세스Index: 그래프 인덱스 생성 절차GraphRAG의 Index 생성 절차는 다음과 같은 단계로 구성됩니다.
1. Source Text → Text Chunks
2. Text Chunks → Element Instances
3. Element Instances → Element Summaries
4. Element Summaries → Graph Communities
5. Graph Communities → Community Summaries
Query: 그래프 인덱스 기반 질문 응답쿼리 단계에서는 위에서 생성한 인덱스를 활용하여 다양한 유형의 질문에 답변합니다.
1. Global Search사용자 쿼리에 대한 Global Search는 커뮤니티 보고서를 기반으로 Map-Reduce 방식으로 응답을 생성
2. Local Search (Entity-based Reasoning)로컬 검색 방식은 지식 그래프에서 의미적으로 관련된 엔티티를 식별하고, 이와 연관된 데이터를 효율적으로 추출, 필터링하여 응답 생성에 필요한 컨텍스트로 활용
3. Drift Search (Combining Local and Global Search)DRIFT Search는 Global Community 데이터와 Local 세부 사항을 결합하여 쿼리를 탐색하고, 초기 답변 → 후속 질문 → 계층적 결과물로 이어지는 과정을 통해 답변을 제공
평가1. Query 생성 (LLM 사용)
2. Condition여섯 가지 조건을 비교하여 분석을 수행했습니다. 이 조건에는 네 가지 수준의 그래프 커뮤니티(C0, C1, C2, C3)를 사용하는 Graph RAG(숫자가 낮을 수록 Global로 이해함), 원본 텍스트에 Map-Reduce 접근 방식을 직접 적용한 텍스트 요약(TS), 그리고 단순한 "의미 기반 검색" RAG 접근 방식(SS)이 포함됩니다.
3. MetricsLLM을 평가자로 사용하여 다음 네 가지 Metrics를 사용했습니다.
4. Result
|
Beta Was this translation helpful? Give feedback.
-
Summarisation and Understanding of Scaling Monosemanticity: Extracting Interpretable Features from Claude 3 Sonnet |
Beta Was this translation helpful? Give feedback.
-
LLM의 주요 문제점
자동화된 피드백을 통한 수정
Self-correction 접근법
훈련 시 수정(Training-time Correction)
(a) Direct Optimization with Human Feedback
(b) Reward Modeling and RLHF
(c) Self-Training
c-1) 외부 메트릭 가이드 (External Metric Guidance)
c-2) 내재적 피드백 - Self-Training
Generation-Time Correction (생성 시점 수정)
(a) Generate-then-Rank (생성 후 순위 매기기)
(b) Feedback-Guided Decoding (피드백 기반 디코딩)
사후 수정(Post-hoc Correction)
(a) Self-Correction
(b) 외부 피드백을 활용한 수정 - 모델 / 도구를 활용한 피드백
(c) 다중 에이전트 논쟁(Multi-Agent Debate)
향후 방향:
Reference |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
매일 스터디 한 내용을 올립니다!
최신 글이 여기로 올라옵니다.
Beta Was this translation helpful? Give feedback.
All reactions