iPhone에서 Llama3 8B 모델을 구동시키는데 성공했다는 뉴스가 나오자마자 인터넷 곳곳에서 따라하기에 성공사례가 연달아 나오고 있습니다.
정리하자면
애플 실리콘은 애플이 독자적으로 만든 반도체입니다. 그래서 인텔, AMD의 프로세서와 Nvidia GPU용으로 만들어진 모델이 그냥 작동하지 않습니다. Llama3도 마찬가지입니다. 돌아간다고 하더라도 효율이 문제인데 그래서 애플은 애플 실리콘에서 작동하는 자체 고속행렬연산 프레임워크인 MLX라는 것을 만들었습니다.
Llama3를 애플의 아이폰, 아이패드에서 돌리려면 MLX에서 돌도록 해야 제대로 되는데 그걸 매우 쉽게 했다는 것입니다.
아이폰 다음 모델에는 거의 온디비이스 AI 탑재될 것이 분명합니다.
온디바이스AI는 디바이스내에서 외부 통신없이 자체 능력만으로도 AI 프로세싱을 처리할 수 있는 것을 말합니다.
세상이 바뀌는 순간이 매우 빠르게 오고 있다는 느낌이 듭니다.
다음은 Llama3 8B를 iPhone 15 Pro Max에 설치하는 방법입니다. 편의상 영문 그대로 올립니다.
UPDATE: Successfully ran Llama3 8B Instruct on iPhone 15 Pro Max
LLM 의 구조적인 특징으로 인해 할루시네이션은 AI모델 자체로는 완벽하게 극복이 안됩니다. 나중에 개선된 모델이나 다른 방법이 나온다면 가능하겠지만 지금은 아닙니다.
LLM의 작동방식은 확률적으로 입력한 단어의 다음 단어가 나올 것을 예측하고 그것을 매우 긴 단어의 연결에 대해 연속적으로 행하는 모델이기 때문입니다. 깊은 고찰이나 인과적 사실 검증, 사실 의심 같은 인간의 고급 사고 능력이 LLM에게 없기때문입니다. 그리고 인간도 할루시네이션이 있습니다. 잘못 알고 있는 것을 잘 알고 있다고 착각하고 우기는 것 말입니다. 하지만 인간은 자신이 틀렸을지도 모른다는 의심 또한 하기 때문에 현명한 사람들은 할루시네이션이 거의 없습니다.
학습량을 마구 늘리면 할루시네이션이 극복되지만 얼마까지 늘려야 눈치채지 못할 만큼 줄어드는지는 알 수 없습니다.
RAG (Retrieval Augmented Generation)
현재 LLM의 할루시네이션을 극복하는 거의 유일한 방법은 RAG (Retrieval Augmented Generation)을 사용하는 것입니다.
RAG는 AI가 대답할 때 질문과 관련이 있는 자료를 찾아서 참고해서 대답하게 만드는 방법입니다.
간단하게 말하면 AI가 대답하기 전에 벡터데이터베이스를 뒤져서 자료를 찾은 다음에 대답할 때 참고하도록 합니다. 당연히 벡터DB에는 사실만 저장되어 있어야 합니다.
RAG는 AI모델에 검색 엔진을 결합한 것
RAG에서 사용하는 DB또는 검색엔진 꼭 벡터 기반일 필요는 없습니다. 텍스트기반의 검색엔진인 엘라스틱 등을 사용해도 되고 DB를 사용해도 됩니다. 벡터 기반을 사용하는 이유는 벡터기반이 렉시컬 기반이 아닌 컨텍스트 기반으로 매치가 가능하기 때문입니다. 전통적인 검색엔진이나 DB는 단어들이 얼마나 일치하는지를 찾는 방법으로 쓰지만 벡터 기반은 의미가 비슷한지를 확인하는 구조로 되어 있습니다.
ASI모델을 사용할 때 RAG로 해결해야 하는 문제는 프롬프트와 관련이 있는 또는 챗봇의 경우 사용자가 질의한 것가 관련이 있는 것만 잘 추출해서 지시어로 넣어주어야 한다는 것입니다. 잘못된 검색 결과는 의미가 일치하지 않는 콘텐츠를 지시어로 넣어주면 할루시네이션이 생기거나 조금 엉성하고 엉뚱한 답을 하게 됩니다.
RAG가 정말 할루시네이션을 해결 해주는가?
다른 구조의 모델이 나오거나 파인튜닝을 엄청나게 많이 하지 않으면 RAG외에는 할루시네이션을 없애는 방법은 없습니다.
RAG를 위해서 필요한 것
벡터검색엔진
벡터검색엔진에 넣을 콘텐츠
RAG가 적용되어 빌드된 모델
좋은 청킹 방법
여기서 가장 중요한 것은 2번입니다. RAG가 적용된 모델은 없어도 지시어로 충분히 해결할 수 있지만 있다면 더 매끄러운 결과를 보여줍니다.
청킹은 매우 중요한 기술인데 콘텐츠를 어떻게 잘라서 검색엔진에 추가할지에 대한 방법입니다. RAG에서 가장 중요한 노하우라고 할 수 있습니다.
좋은 방법은 잘 알려지지 않고 각 기업의 내부에서만 사용되고 있습니다. OpenAI도 RAG를 지원하지만 어떤 방법으로 청킹을 하는지에 대해서는 오픈하고 있지 않습니다.
RAG의 미래는?
AI모델을 실시간으로 빌드할 수 있는 방법은 없습니다. 모델을 만드는데 계산양이 매우 많기 때문입니다. 최신 지식을 인간처럼 곧바로 업데이트하지 못합니다.
MMLU(Massive Multitask Language Understanding)는 인공지능 모델의 지식 습득 능력을 종합적으로 평가하기 위한 벤치마크 중 하나입니다. 이 평가는 인공지능이 어느 정도까지 다양한 지식 영역을 이해하고 있는지를 측정하기 위해 고안되었습니다.
즉, 인공지능이 얼마나 다양한 지식을 가지고 있는지 평가하는 지표입니다.
MMLU의 특징
다양한 주제 범위: MMLU는 STEM(과학, 기술, 공학, 수학), 인문학, 사회과학 등 약 57가지의 다양한 주제에 대한 이해를 평가합니다.
다지선다 형식의 문제: 평가는 주로 다지선다 형식의 문제를 사용하여, 모델이 주어진 정보를 바탕으로 가장 적절한 답을 선택하도록 요구합니다.
zero-shot 및 few-shot 학습 환경: 이 벤치마크는 특히 모델이 사전에 해당 주제에 대한 특정한 학습 없이도 얼마나 잘 수행할 수 있는지(zero-shot), 또는 매우 제한된 데이터로 학습한 후의 성능(few-shot)을 평가합니다.
현재 성과와 리더보드
최신 인공지능 모델들의 성능은 Papers with Code 웹사이트의 MMLU 벤치마크 섹션에서 확인할 수 있습니다. 현재 GPT-4가 86.4%의 높은 정확도로 최고 성능을 기록하고 있습니다.
자료 및 리소스
공식 GitHub: MMLU의 구현과 관련된 자세한 정보, 데이터셋 접근 및 사용 방법 등은 GitHub 페이지에서 확인할 수 있습니다. 이 페이지에는 또한 연구자들이 자신의 모델을 벤치마크에 적용해 볼 수 있는 지침과 도구들이 제공됩니다.
MMLU의 중요성
MMLU는 단순히 특정한 지식 영역에서의 모델 성능을 측정하는 것을 넘어, AI 모델이 얼마나 광범위하고 다양한 주제를 이해하고 있는지를 평가함으로써, 인공지능 기술의 종합적인 이해력과 다재다능성을 테스트합니다.
OpenAI Assistant API는 openapi에서 모델을 활용해서 개발하게 하는 API인데 2023 말에 Beta V1을 발표했습니다.
하지만 몇가지 단점과 한계, 버그가 있었는데 새 버전 2가 발표되었습니다.
간략한 요약은 다음과 같습니다.
2024년 4월 발표. OpenAI Assistants API의 기본 버전에 새로운 기능과 개선 사항을 넣어 OpenAI-Beta: assistants=v2 릴리즈로 만듦
파일 검색 도구 개선: ‘file_search’ 도구는 이전보다 500배 많은 최대 10,000개 파일을 처리할 수 있습니다. 이 도구는 검색 속도가 빠르고, 멀티 스레드 검색을 통한 병렬 쿼리를 지원하며, 향상된 재정렬 및 쿼리 재작성 기능을 제공합니다. 기능 개선 및 신규 지원
벡터 스토어 객체 도입: 파일이 벡터 스토어에 추가되면 자동으로 파싱, 청킹, 임베딩되어 검색 준비가 완료됩니다. 벡터 스토어는 여러 보조기와 스레드에 걸쳐 사용할 수 있어 파일 관리와 결제가 간소화됩니다. 신규 지원
토큰 사용 최대치 제어: 실행할 때 사용하는 최대 토큰 수를 제어할 수 있어 토큰 사용 비용을 관리할 수 있습니다. 또한, 각 실행에서 사용되는 이전/최근 메시지의 수에 대한 제한을 설정할 수 있습니다. 신규 지원
도구 선택 매개변수 지원: 특정 실행에서 특정 도구(예: file_search, code_interpreter 등)의 사용을 강제할 수 있는 ‘tool_choice’ 매개변수를 추가했습니다. 신규 지원
역할이 보조인 메시지 생성 가능: Threads에서 사용자 정의 대화 이력을 생성할 수 있습니다.
보조 및 실행 객체의 모델 구성 매개변수 지원: 인기 있는 모델 구성 매개변수(온도, 응답 형식(JSON 모드), top_p 등)를 지원합니다. 신규 지원
미세 조정 모델 사용 가능: 현재는 gpt-3.5-turbo-0125의 미세 조정 버전만 지원됩니다. 신규 지원
스트리밍 지원: Assistants API가 이제 스트리밍을 지원합니다. 신규 지원
스트리밍 및 폴링 도우미 추가: Node 및 Python SDK에 여러 스트리밍 및 폴링 도우미를 추가했습니다. 신규 지원
마이그레이션 가이드 제공: 최신 버전의 Assistants API로 도구 사용을 마이그레이션하는 방법에 대해 자세히 알아볼 수 있습니다. 신규 지원
사실 비율 보다는 샘플의 크기가 중요하지만 어쨌든 95%대 5%로는 A/B테스트는 문제를 만듭니다.
A/B테스트 흔히 온라인서비스에서는 버킷테스트라고 하는데 이 테스트에서 A와 B 두개의 샘플의 수가 서로 불균등하다고 하면 대부분의 통계학자들은 표정이 안좋아지며 심각하게 생각하지만 개발자들은 별것 아니라고 생각합니다.
이게 논란의 여지가 항상 있는 것이므로 조심스럽지만
A/B테스트는 통계학에서 나온 것이므로 통계학자들이 더 잘 알것이므로 이쪽을 더 신뢰하는 것이 맞습니다. 통계학자들은 경험과 이론을 통해 그게 왜 문제인지 설명하지만 개발자들은 그런 설명을 하지 않습니다.
개발자들은 근거를 말하지 않지만 통계학자들은 근거를 말합니다.
A/B 테스트, 버킷테스트는 여러개의 샘플에 각기 다른 처치(작용 또는 변화를 주는것)를 하고 그게 정말 효과가 있는 지 살펴보는 것이라는 것을 기억해야 합니다.
A/B 테스트는 샘플이 중요하다
A/B 테스트는 통계학에서 다루는 실험 운영 방법입니다. 실험계획법이라는 통계학 과목이 있습니다. 과목이 따로 있을 만큼 만만한 것이 아닙니다
통계학은 샘플을 매우 중요하게 생각합니다. 적어도 통계학파 중에 빈도주의자(Frequatist)들은 매우 중요하게 생각합니다. 그와 비교되는 다른 학파들도 있지만 이건 다음에 얘기하겠습니다.
샘플은 어떤 집합에서 일부를 떼어 낸 것을 말합니다.
통계학에서 샘플을 중요하게 생각하는 이유는 샘플을 통해서 원래 전체 데이터의 특성을 파악해야 하기 때문입니다. 샘플을 사용해서 원래 집합을 알아내려고 하는 이유는 대부분의 전체 데이터를 다 확인하는 것은 불가능하기 때문입니다.
“빅데이터 플랫폼도 있는데 전체데이터 확인을 왜 못하냐?” 라고 물어볼 수 있습니다. 잘못 이해한 것인데 거기서 말하는 전체데이터는 실제로 알고자 하는 사실을 얻어야 하는 대상의 전체가 아니기 때문입니다. 예를 들어서 어제까지 가입한 쇼핑몰 전체의 고객 데이터는 전체 데이터가 맞긴 하지만 쇼핑몰의 고객 전체는 아닙니다. 앞으로도 가입할 사람이 있을 것이고 탈퇴할 사람도 있을 것이기 때문입니다. 그런 관점에서 통계학에서 생각하는 전체 데이터를 얻는 것은 불가능하다고 할 수 있습니다.
어제까지 전체 고객 데이터는 통계학에서는 전체데이터가 아닌 그냥 매우 큰 샘플데이터입니다.
A/B테스트에서 A와 B는 각각 전체 모집단에 대한 샘플이라고 봅니다.
A/B테스트에서 샘플 수가 균등하지 않으면 통계 검정을 할 수 없는가?
그래서 A/B의 비율이 5:5로 균등하지 않으면 정확한 비교를 하지 못하는가? 라는 의문이 있을 것이다. 할 수는 있습니다. 다만 꽤 복잡한 방법을 써야 하고 정확하지 않은데다 선택한 검정 자체를 적용하는 것 자체가 맞는지 안맞는지는 확인하려고 하는 것은 노련하고 뛰어난 통계학자도 매우 어렵게 하는 것입니다.
간단하게 공식 몇 개 넣어서 계산하면 되는 것이 아닙니다.
그래서 이렇게 불균등한 샘플 비교를 최대한 피해야 합니다.
샘플 간의 성능 비교를 한다면 균등한 것이 낫다
균등하지 않은 샘플로 샘플의 불균형성을 극복하면서 테스트하는 것 보다 균형 샘플을 만들어서 테스트하는 것이 더 쉽고 돈도 더 적게 듭니다. 균등하지 않은 샘플로 서로를 비교하는 것은 일반적으로 실험계획이 잘못된 경우나 하지 못한 후시 테스트일 가능성이 높습니다.
A/B 테스트와 관련되었대고 하면 무조건 샘플 수를 맞추고 시작합니다.
불균등한 것이 뭐가 그리 문제인가?
샘플이라고해서 그렇게 거창한 것은 아닙니다. A그룹에서 추출한 숫자들, B그룹에서 추출한 숫자들을 비교하는 것인데 샘플이 균등하지 않으면 크게 달라질 수 있는 것이 파라미터(모수, parameter)인데 평균과 분산입니다. A/B테스트는 A와 B의 평균과 분산이 실험 후에 많이 차이가 나는지 아닌지를 보는 것입니다. 이때 샘플의 수 그러니까 숫자의 갯수가 많이지면 숫자의 갯수가 적을 때 보다 분산은 무조건 커집니다. 이게 자연적인 현상입니다. 그래서 샘플의 수가 50대 50으로 균등하지 않으면 샘플 수로 인해서 생길 수 있는 기본적인 분산의 차이를 보정하고 검정을 해야 하는데 보정이 매우 어렵고 보정을 해도 정확도가 떨어집니다.
실험결과를 잘못 해석하게 됩니다. 이런 결과로 결정을 하면 비즈니스에 큰 실패를 가져올 수 있습니다.
실험 자체를 잘못하는 것은 그 실험을 없었던 것으로 하면 되기 때문에 피해가 덜하지만 결과를 잘못해석하면 틀렸다는 것 자체를 의심하지 않기 때문에 큰 문제를 생깁니다.
한쪽을 언더샘플링(Under sampling)을 하면 어떤가?
크기(갯수)가 다른 두 샘플들이 있을 때 크기가 적은 샘플 수만큼을 크기가 큰 색플에서 도려내서 숫자를 맞추는 것이 언더샘플링(under sampling)이라는 방법입니다. 간단히 말하면 그냥 큰 쪽을 작은쪽의 크기 만큼 잘라서 맞추는 것입니다. 보통 자를 때 무작정 자르지 않고 랜덤으로 샘플링을 합니다. (확실하게 랜덤으로 분할 한 것과 같은 것으로 분할 할 수 있으면 랜덤 샘플링을 하지 않아도 됩니다. 이건 따로 설명하지요)
어쨌든 이러면 괜찮지 않은가? 라고 생각할 수 있는데 이것도 괜찮지 않습니다.
언더샘플링을 하는 순간 샘플의 모집단이 달라지게 됩니다. 샘플이 뽑힌 것의 자유도라는 것도 다르기 때문에 두 샘플은 비교하기 어렵게 됩니다. 부모가 낳은 형과 동생을 비교하다가 형과 동생의 아들인 조카를 비교하는 꼴인 것이다. 부트스트래핑을 쓰면 하게되면 이러 불균형에서 샘플링을 통해 문제를 해결할 수 있지만 역시 그 보다는 샘플 수를 맞추는게 편하고 낫습니다.
대부분의 버킷시스템은 샘플 수를 맞추도록 설계되어 있다
빅테크 회사들의 버킷시스템이 존재합니다. A/B테스트를 할 수 있도록 플랫폼이 갖춰줘 있고 샘플의 수 등을 수정할 수 있습니다. 저런 대형 기업들의 시스템에서도 기본으로 두 비교군의 샘플 수를 맞추도록 설계되어 있습니다. 다른 대기업들도 모두 마찬가지입니다. 그들은 왜 모두 그렇게 하는지 생각을 해보기로 합시다. 그냥 그렇게 하거나 단순한 전통이어서 그렇게 하는 걸이다 아닙니다. 그것이 통계적이고 과학적으로 실험의 결과를 오해석하지 않는 최선의 방법이기 때문입니다.
통계학자들이 무능하고 실력이 없으면서 복잡해 보이기 좋아하기 때문에 저렇게밖에 못한다고 생각할 수도 있지만.
버킷시스템에서는 언더샘플링이 가능하다
추가로 말하면 대부분의 버킷시스템은 사용자의 ID 또는 비식별ID를 비트연산을 통해 그룹을 나눠서 관리하도록 되어 있습니다.
따라서 많은 쪽의 비트 몇개를 무시해서 언더샘플링을 하면 샘플비교를 할 수 있습니다. 조금 복잡하니 자세한 것은 따로 설명하겠습니다.
참고
A/B테스트에 대해 포스트를 올린적이 있습니다. 시간이 있다면 자세한 내용은 그걸 참조하세요.