LLM Loss Function without 수식

서론

개발자라 몰랐지만, IT 쪽 대화는 지금 현재도 내가 인공지능의 답변을 수정해 주거나 거의

꿰뚫다

라는 표현을 자주 듣는다. 지난 1년간 모르다가 최근 비개발자들이 LLM을 쓰고 받은 답변을 보다 IT 필드에서 이런 표현 자체를 받은 적이 없는 사람을 보게 되면서, 글의 주제를 정하기가 편해졌다. LLM Loss function을 물어보다. 이런 답을 받으면,

써서 비개발자에게 도움 될 무언가가 생긴 것이다. 대한민국의 IT 실력을 끌어올릴 포인트를 찾은 것이다. 프로그래머는 모두 목표는 다 알고 있다. 그러나 배우려고 하는 자의 현재 위치를 아는 사람이 그나마 도움이 되고 가장 빠른 길을 아는 경험자가 교수자가 된다.

이 또한 정규과정을 만든 것은 아니니 '추억' 카지노 게임에 넣어둔다.

우선, 수식은 적으면 안 된다. 수식 하나가 모든 것을 설명하고 있지만. 수식은 이과의 영역이라 설명에 공정하지 못하다. 학문적 관점에서의 설명이 아니고 실무 필드의 경험이라 틀릴 수 있음을 미리 써둔다. 생각날 때마다 고칠 것이지만 오랜 구독자를 잘 알듯이 아닐 수도 있다. 관리가 안 된 오랜 글은 지운다.

이 글은 역사서로 남겨두려고 LLM 이야기와 여러 IT 역사를 섞어 두려 한다.

서론이 길었다. 요즘 LLM을 만들고 있다 보니 공부를 많이 하고 있다. LLM은 만드는 과정이 데이터에서 base LLM을 만들고 어닐링을 한다. 어닐링 파트는 LLM을 만들어 본 사람이 아니면 거의 모르기 때문에 인터넷 자료 + 강의 자료 + linked in에서 AI 기업에 속한 엔지니어나 교수자도 모른다. 이 이후에는 SFT, DPO를 하게 되는데. 이 둘을 instruct 버전이라고 한다. 자, 그럼 여기 나온 단어를 나열해 보자.

LLM, base, SFT, DPO, Instruct

LLM의 핵심은 다음 단어를 예측하는 것이 전부이다. 정말 이것밖에 없다. "나는 오늘 글을"이라고 하면 "쓴다", "읽는다", "본다" 등등이 정답이다. 그리고 이런 문장 완성이 안 되는지 안되는지 그 오류를 측정하는 것이 수식의 전부다. 관련 수식을 찾았을 때 수식 좀 복잡해 보이는 이유는 전체를 합하기 위해 시그마(E 거꾸로) 기호를 쓰고, 다시 그것을 평균내기 위해 1/N을 하기 때문이다. 확률이 들어가니 probability의 첫 글자 p가 들어가고, 틀렸을 때 그 틀린 것을 극대화하려고 log를 쓴다. 정확히는 자연로그를 쓰는데 미분이나 곱셈을 덧셈으로 바꾸는 등의 기법을 활용하기 위해서이다. 자세한 것은 LLM을 통해 공부하면 된다. 결국 이야기하고자 하는 것은 LLM base 모델은 다음 단어 예측 밖에 없다. 이런 base 모델은 어디서 구할까?

허깅페이스에서 받을 수 있다. base 모델받아서 구동하는 프로그램은 ollama를 이용하면 되는데 올라마 이용법은 인터넷에 매우 많다. 거기서 base 모델에 질문을 해 보면 답변 대신 문장을 완성하는 것을 볼 수 있다. 본인 컴퓨터에 잘 돌아가게 하려면 3B 이하 모델을 받으면 된다. 3B 모델은 추론이 되는 버전과 추론이 없는 버전으로 나눌 수 있는데 추론이 없는 버전을 받아야 base 모델이 뭔지 확실하게 이해할 수 있다. 안 해봐도 되겠지만 실험은 무조건 해봐야 한다는 실험주의자라 나는 그랬다.

https://en.wikipedia.org/wiki/Experimentalism

SFT나 DPO는 문장 완성에서 정답지를 주고 문장 완성이 아닌 답변을 하는 형태로 바꿔주는 작업이다. 그래서 base 모델이 무조건 있어야 한다. Supervised Fine Tuning이라는 SFT의 약어처럼 지시하고 가르쳐 주는 것이다. 가끔 바이브 코더가 욕을 해야 모델이 잘 알아듣는다고 하는데, 인터넷 크롤링을 통해 비속어를 배우기는 하지만 그것도 숫자로 바뀐 단어라 비슷한 위치의 공간의 단어와 매칭이 되는 것뿐이다. 그리고 엉뚱하게 비속어 데이터를 기준으로 SFT를 하면 모르겠으나 웬만하면 표준어와 정확한 맞춤법 등 고품질 데이터로 튜닝을 하기 때문에 명확한 프롬프팅이 안된다. 그럼 SFT로 질문-답변을 가르쳤으면 끝난 것 아닐까? 여기서 한 단계 더 나아가는 게 바로 DPO(Direct Preference Optimization, 직접 선호도 최적화)다. 말이 어려워 보이지만 이것도 알고 보면 아주 단순하다. "둘 다 맞는 말인데, 사람이 듣기에 어느 쪽이 더 기분 좋고 깔끔한가?"를 가르치는 과정이다. SFT가 학생에게 모범답안을 주고 주입식으로 달달 외우게 하는 것이라면, DPO는 "눈치와 매너"를 가르치는 쪽에 가깝다. 예를 들어 사용자가 "파이썬으로 구구단 짜줘"라고 했을 때, 모델이 낼 수 있는 답변은 여러 가지다.

(좋은 답변) 군더더기 없이 깔끔한 코드와 실행 예시를 딱 보여준다.

(별로인 답변) 쓸데없이 파이썬의 역사부터 줄줄 읊다가 코드는 맨 밑에 대충 던져놓는다.

둘 다 코드가 돌아가니 기술적으로는 둘 다 정답이다. 하지만 사람은 당연히 A를 좋아하고 B는 피곤해한다.

예전에는 이 "인간의 취향"을 맞추기 위해 RLHF(인간 피드백 기반 강화학습)라는 무시무시하게 복잡한 방식을 썼다. 채점관 역할을 하는 인공지능을 따로 하나 더 만들어서 점수를 매기게 했는데, 서버도 엄청 잡아먹고 학습 중에 모델이 툭하면 바보가 되는 등 현업 개발자 입장에선 여간 골치 아픈 게 아니었다. 이걸 스탠퍼드 연구진이 천재적으로 단순화한 게 바로 DPO다. 복잡하게 채점관 모델을 따로 둘 필요 없이, 모델한테 딱 두 가지만 보여주는 것이다. "너한테 [좋은 답변 A]와 [별로인 답변 B]를 동시에 줄 테니까, A를 말할 확률은 올리고, B를 말할 확률은 깎아내려!" 이게 DPO의 전부다.

그래서 LLM 썼던 일부의 사람들은 답변을 선택하고, 좋아요를 눌러야 하는 등의 작업을 했을 것이다. 과거 국내 대기업 포털 사이트가 정답도 없는 중복 방지 문자를 보여주며 답을 스스로 누적했던 것과 같은 방식이다. 어찌 보면 "사기"지만 지난 30년간의 IT 경력상 고난도의 사기는 사실 사기 축에도 못 들고 법의 심판도 받지 않는다. 업비트가 무죄를 받은 이유도 마찬가지다. 클라우드 컴퓨터의 내용은 증거 수집 위법이라 증거로 인정 안된다는 정말 몰상식하고 눈앞에서 코 베어가는 판결이었다. 이런 류의 글을 쓴 이후 업비트에서 사용자 확인을 여러 번 거치고 나를 불편하게 만드는 것을 보면, 또 CTO가 바쁜 사람 불러서 사람 귀찮게 하고 시스템 오류에 대해서는 아무런 보상을 안 해줄 것인지 궁금하기도 하다. 어차피 보상을 해줘도 그럴 것이라는 월급 루팡들이 내는 의견이 회사를 더 힘들게 해 줄 테지만 이미 사기 친 애들은 다 떠나고 껍데기만 정부에 넘겼다. 사기가 합법이 되었으니 이제 안 하면, 바보다. 따지고 보면 업비트와 코인은 Base 모델과 같을 수도 있다. 인터넷 글을 수조 개 읽어서 "다음 단어 잇기"를 엄청나게 잘하는 천재 갓난아기처럼 말이다. 수조 원을 벌 수 있다는데 뭐라도 했을 것이다. SFT "질문을 받으면 답을 해야 한다"는 기본 규칙과 지식을 가르친 초등학생이라고 하면 아직 초등학생은 되지 못했다. DPO "사람의 마음을 읽고 센스 있고 정중하게 말하는 법"을 장착한 성인은 꿈도 못 꿀 일이다.

LLM이라는 거대한 기술도 껍데기를 다 벗겨내면, "다음 단어를 맞히는 수학적 확률 놀이(Base)"에서 시작해, "질문-답변의 형태를 갖추고(SFT)", "사람의 취향을 반영하는(DPO)" 이 3단계 계단을 차근차근 밟아 올라가는 것뿐이다.

회사 보안상 일반적인 이야기만 풀었고, 데이터 수집을 위해 대기업이 하던 짓거리와 사기꾼 이야기도 잠시 썼는데, 하루 이틀 일은 아니다.

포털은 방조로 사이트 유행시킨 후 나중에는 마치 경찰 코스프레로 저작권 법을 진두 지휘 하듯이 바뀌었고, 음원에 돈 붙여서 돈을 벌면서 기술적으로는 사용자 컴퓨터 리소스를 무단으로 쓰는 짓을 했었다. 이제 관련 증거는 찾기도 힘들고, 대한민국의 고인 물들 만이 아는 히스토리가 되었다.

하긴 뭐, 삼성도 사카린 밀수해서 큰 것을 보면,