AI 기초 및 활용 18회: LLM의 원리 — 다음 낱말 맞히기가 어떻게 전부를 흡수했나

오늘의 질문 — 다음 낱말 맞히기가 어떻게 다 됩니까

거대 언어 모델이 훈련 중에 하는 일은 딱 하나입니다. 글을 주고 그 다음에 올 조각을 맞히게 하는 것. 그게 전부예요.

이 말을 처음 들으면 대개 믿기지 않습니다. 번역도 하고, 요약도 하고, 코드도 짜고, 논리 문제도 푸는데, 훈련 목표가 고작 빈칸 채우기라니요.

실제로 2018년 무렵까지 대다수 연구자도 그렇게 생각했습니다. 다음 낱말 맞히기는 진짜 과제를 위한 준비운동 정도로 여겨졌어요. 번역을 잘하려면 번역 데이터로 따로 가르쳐야 한다고 봤습니다.

오늘의 질문은 이것입니다. 그 시시해 보이는 목표 하나가 어떻게 나머지를 전부 흡수했을까요.

지난 회차 연결 — 제4부를 열며

제3부에서 부품과 배열을 전부 손에 넣었습니다. 특히 16회차의 트랜스포머가 오늘의 전제예요. 순환 구조를 걷어내 병렬 처리가 열렸고, 그래서 모델을 키울 수 있게 됐다는 그 이야기 말입니다.

그리고 16회차 끝에서 디코더 계열이 주류가 됐다고 했죠. 앞을 보고 다음을 만들어 내는 그 구조가 오늘의 주인공입니다.

제4부는 그 위에서 벌어진 일을 다룹니다. 오늘은 원리, 19회차는 어떻게 길러지는가, 20회차는 잘 쓰는 법, 21회차는 한계, 22회차는 언어를 넘어서, 23회차는 스스로 일하는 AI입니다.

토큰 — 낱말도 글자도 아닌 단위

모델은 글을 그대로 먹지 않습니다. 먼저 토큰이라는 조각으로 자릅니다.

왜 낱말 단위로 자르지 않을까요. 낱말은 종류가 너무 많고 계속 새로 생깁니다. 신조어, 고유명사, 오타까지 전부 다루려면 목록이 끝없이 커져요.

그러면 글자 단위는 어떨까요. 종류는 적지만 이번엔 조각 수가 너무 많아집니다. 16회차에서 봤듯 어텐션 비용은 길이의 제곱이라, 조각이 많아지면 곧장 비용이 됩니다.

그래서 중간을 택합니다. 자주 나오는 덩어리는 통째로 한 토큰, 드문 것은 잘게 쪼개는 방식이에요. 이 목록은 사람이 만들지 않고 데이터에서 통계적으로 학습됩니다. 흔한 영어 낱말은 대개 한 토큰이고, 긴 전문용어는 서너 조각으로 나뉩니다.

토큰이 만드는 실제 차이

토큰은 추상적인 이야기가 아니라 매일 겪는 현상의 원인입니다.

모델에게 "딸기에 ㄹ이 몇 개 있나요"처럼 글자를 세게 하면 자주 틀립니다. 모델에게 그 낱말은 글자의 나열이 아니라 덩어리 하나이기 때문이에요. 안을 들여다볼 수가 없습니다.

끝말잇기나 글자 수 맞추기가 어려운 이유도 같습니다. 능력이 부족해서가 아니라 애초에 그 단위로 세상을 보지 않기 때문이에요.

그리고 비용이 토큰으로 매겨집니다. API 요금도 문맥 길이도 전부 토큰 기준이죠. 19번째 섹션에서 이 이야기를 실무 관점으로 다시 하겠습니다.

모델이 실제로 내놓는 것 — 확률 분포

여기가 가장 자주 오해되는 대목입니다. 모델은 다음 토큰 하나를 내놓지 않습니다.

모델이 내놓는 것은 가능한 모든 토큰에 대한 점수표입니다. 어휘 목록이 십만 개라면 십만 개 전부에 대해 "이게 다음에 올 확률" 값을 매겨요.

"오늘 날씨가 참 —" 다음이라면 '좋다'에 높은 값, '맑다'에도 꽤 높은 값, '슬프다'에는 낮은 값, '자동차'에는 아주 낮은 값이 붙습니다. 전부 더하면 1이 되고요.

9회차에서 배운 확률 분포가 정확히 이것입니다. 그리고 이 사실이 오늘 이후 모든 이야기의 열쇠예요. 21회차의 환각도, 20회차의 프롬프트 기법도 전부 여기서 설명됩니다.

샘플링 — 그중 하나를 고르는 일

점수표가 나왔으면 하나를 골라야 합니다. 이 고르는 일을 샘플링이라고 해요.

가장 단순한 방법은 제일 높은 것을 고르는 것입니다. 그런데 이렇게만 하면 문제가 생겨요. 답이 항상 똑같고, 밋밋하고, 같은 표현을 맴돕니다. 같은 구절을 무한 반복하는 현상도 여기서 나옵니다.

그래서 실제로는 확률에 비례해 뽑습니다. 40퍼센트짜리는 자주, 5퍼센트짜리는 가끔 뽑히는 식이죠. 여기에 꼬리를 자르는 장치를 얹습니다. 확률이 아주 낮은 후보들은 아예 후보에서 빼는 거예요. 엉뚱한 말이 튀어나오는 것을 막습니다.

중요한 것은 이겁니다. 모델은 결정론적이지 않습니다. 같은 질문에 다른 답이 나오는 이유가 여기 있어요. 버그가 아니라 설계입니다.

온도 — 뾰족하게 할까 펼칠까

샘플링을 조절하는 대표적인 손잡이가 온도입니다. 이름이 특이하지만 하는 일은 단순해요. 확률 분포의 모양을 뾰족하게 또는 평평하게 만듭니다.

온도를 낮추면 높은 확률은 더 높아지고 낮은 확률은 더 낮아집니다. 분포가 뾰족해져요. 그러면 답이 일관되고 예측 가능해집니다. 사실을 다루거나 코드를 짤 때 유리합니다.

온도를 올리면 분포가 평평해집니다. 낮은 확률 후보도 자주 뽑혀요. 답이 다양하고 뜻밖이 됩니다. 아이디어를 발산할 때 유리하죠.

다만 오해가 하나 있습니다. 온도를 올린다고 더 창의적이 되는 게 아닙니다. 그냥 덜 그럴듯한 것을 더 자주 고르게 하는 거예요. 지나치면 창의가 아니라 헛소리가 됩니다.

자기회귀 — 자기가 쓴 것을 다시 읽는다

토큰 하나를 골랐으면 그다음은 어떻게 될까요. 고른 토큰을 입력 뒤에 붙이고, 그 전체를 다시 모델에 넣습니다.

그러면 또 점수표가 나오고, 또 하나를 고르고, 또 붙입니다. 이 반복을 자기회귀라고 해요. 자기가 방금 쓴 것을 읽고 다음을 쓴다는 뜻입니다.

여기서 중요한 사실 하나. 모델은 문장 전체를 미리 계획하지 않습니다. 한 조각씩 앞으로 나아갈 뿐이에요. 글이 논리적으로 이어져 보이는 것은 계획이 있어서가 아니라, 앞에 쓴 것이 다음의 확률 분포를 강하게 제약하기 때문입니다.

여러분이 채팅 화면에서 글자가 한 조각씩 흘러나오는 것을 보신 적 있을 겁니다. 그건 연출이 아니라 실제로 그렇게 만들어지고 있는 겁니다.

그래서 생기는 성질들

자기회귀 구조에서 곧장 따라 나오는 성질이 몇 가지 있습니다. 실무에서 자주 부딪히는 것들이에요.

한 번 쓴 것은 되돌릴 수 없습니다. 앞에서 잘못된 전제를 뱉었으면 그 위에 계속 쌓아 올립니다. 사람처럼 "아, 아까 그건 틀렸네" 하고 지우지 않아요. 그래서 틀린 답이 점점 더 정교하게 틀려집니다.

생각할 자리가 필요합니다. 모델의 계산량은 토큰 하나당 정해져 있어서, 어려운 문제도 한 조각에 답하면 그만큼밖에 못 씁니다. 그런데 중간 과정을 글로 쓰게 하면 그 글이 다음 계산의 입력이 되어 실질적으로 계산을 더 하게 돼요. 20회차에서 다룰 단계적으로 생각하게 하기가 통하는 이유가 이것입니다.

길이가 비용입니다. 출력이 길수록 자기회귀를 그만큼 더 돌려야 합니다. 그래서 응답 속도는 출력 길이에 거의 비례해요.

왜 다음 낱말 맞히기가 전부를 흡수했나

이제 오늘의 핵심 질문으로 돌아갑니다. 답은 "인터넷의 모든 글에는 이미 모든 과제가 들어 있다"입니다.

생각해 보세요. 웹에는 "다음 문장을 영어로 옮기면:"으로 시작하는 글이 무수히 많습니다. 그 빈칸을 잘 맞히려면 번역을 할 줄 알아야 합니다.

"요약하자면" 다음을 맞히려면 요약을 할 줄 알아야 하고, "정답은" 다음을 맞히려면 문제를 풀 줄 알아야 하며, 코드 주석 다음 줄을 맞히려면 코딩을 할 줄 알아야 합니다.

즉 다음 조각 맞히기는 시시한 과제가 아니라 세상의 거의 모든 과제를 담는 그릇이었던 겁니다. 그릇이 충분히 크고 데이터가 충분히 많으면, 그 안에 든 과제들을 부수적으로 배우게 됩니다.

압축은 곧 이해입니다

조금 더 깊은 설명이 있습니다. 잘 예측하는 것과 잘 압축하는 것은 같은 일이라는 관점이에요.

다음에 올 것을 정확히 맞힐 수 있다면, 그 부분은 따로 적어 둘 필요가 없습니다. 맞힐 수 있으니까요. 예측을 잘할수록 저장할 것이 줄어듭니다.

그런데 웹 전체를 정해진 크기의 파라미터 안에 담으려면 통째로 외울 수는 없습니다. 데이터가 파라미터보다 훨씬 크거든요. 그러면 어떻게 해야 할까요.

규칙을 찾아내야 합니다. 문법, 상식, 인과관계, 사람들이 말하는 방식. 이런 것을 파악하면 훨씬 적은 자리에 훨씬 많은 것을 담을 수 있어요.

그러니까 "다음 조각을 잘 맞혀라"라는 압박이 모델을 규칙을 찾아내는 쪽으로 몰아붙인 겁니다. 6회차에서 과적합을 다루며 "외우지 말고 규칙을 배워야 한다"고 했던 이야기가, 여기서 지능처럼 보이는 것의 기원으로 돌아옵니다.

사전학습 — 웹을 통째로 읽기

이 훈련 단계를 사전학습이라고 부릅니다. 정답 표를 사람이 만들 필요가 없다는 점이 결정적이에요.

7회차의 지도학습에서는 사람이 하나하나 이름표를 붙여야 했습니다. 그게 병목이었죠. 그런데 사전학습에서는 글 자체가 정답을 품고 있습니다. 뒷부분을 가리면 그게 곧 정답이니까요.

이것을 자기지도학습이라고 부릅니다. 8회차의 비지도학습과 7회차의 지도학습 사이에 있는 방식이에요. 그리고 이 성질 덕분에 데이터를 인터넷 규모로 늘릴 수 있었습니다. 사람의 손이 필요 없으니까요.

다만 대가가 있습니다. 웹에는 좋은 글만 있는 게 아니에요. 편향, 혐오, 잘못된 정보, 저작권 있는 글이 전부 함께 들어갑니다. 이 문제가 19회차와 28회차의 주요 주제가 됩니다.

규모의 법칙 — 키우면 좋아진다

2020년 전후로 연구자들이 놀라운 규칙성을 발견합니다. 모델 크기, 데이터 양, 계산량을 늘리면 성능이 예측 가능하게 좋아진다는 것이었어요.

단순히 좋아지는 정도가 아니라 매끄러운 곡선을 그렸습니다. 얼마를 투자하면 손실이 얼마가 될지 미리 계산할 수 있었어요.

이 발견의 파괴력을 이해해야 합니다. 그전까지 AI 연구는 더 나은 구조를 찾는 일이었습니다. 그런데 규모의 법칙은 구조를 안 바꿔도 돈과 계산을 넣으면 좋아진다고 말했어요.

연구 문제가 공학 문제이자 자본 문제로 바뀐 순간입니다. 오늘날 AI 기업들이 조 단위 데이터센터를 짓는 이유, 반도체가 지정학의 중심이 된 이유가 전부 이 곡선 하나에서 나옵니다.

세 가지를 함께 키워야 합니다

다만 무작정 키운다고 되는 게 아니라는 것도 곧 밝혀졌습니다. 모델 크기와 데이터 양의 균형이 중요했어요.

초기에는 모델만 키우는 경쟁이 있었습니다. 그런데 2022년 연구에서 당시 큰 모델들이 데이터에 비해 지나치게 컸다는 것이 드러납니다. 같은 계산 예산이라면 모델을 좀 줄이고 데이터를 훨씬 늘리는 편이 나았어요.

실제로 그 원칙을 따른 더 작은 모델이 훨씬 큰 모델을 이겼습니다. 이후 개발 관행이 여기에 맞춰 바뀌었고, 요즘은 같은 크기 모델에 훨씬 많은 데이터를 먹이는 것이 표준입니다.

그래서 파라미터 수만 보고 모델을 비교하는 것은 부정확합니다. 뉴스에서 "몇 조 파라미터"라는 숫자를 볼 때 함께 물어야 할 것은 "데이터는 얼마나 먹였나"예요.

창발 — 없던 능력이 갑자기 나타납니다

규모를 키우다 보니 예상 밖의 일이 관측됩니다. 어떤 능력은 매끄럽게 좋아지지 않고 어느 크기에서 갑자기 나타났어요.

작은 모델에서는 거의 0에 가깝다가, 어느 규모를 넘자 급격히 솟아오르는 능력들이 있었습니다. 여러 단계 산수, 복잡한 지시 따르기, 예시 몇 개만 보고 새 과제를 해내는 것 같은 일들이요.

이것을 창발이라고 부릅니다. 그리고 이 현상이 사람들을 흥분시키기도 하고 불안하게도 만들었어요. 다음에 무엇이 나타날지 예측할 수 없다는 뜻이니까요. 30회차의 논쟁이 여기서 출발합니다.

창발을 어떻게 봐야 할까요

그런데 여기에 중요한 반론이 있습니다. 이 시리즈의 원칙상 반드시 함께 다뤄야 해요.

2023년 연구자들이 이렇게 지적했습니다. 창발이 측정 방식 때문에 생긴 착시일 수 있다고요.

여러 자리 곱셈을 예로 들어 봅시다. 답이 완전히 맞아야만 점수를 주면, 모델이 조금씩 나아지는 동안에는 계속 0점이다가 어느 순간 갑자기 점수가 생깁니다. 계단처럼 보이죠.

그런데 자릿수별로 부분 점수를 주면 같은 데이터가 매끄러운 곡선으로 보입니다. 능력은 계속 자라고 있었는데 자로 재는 방식이 계단이었던 겁니다.

그래서 정직한 결론은 이렇습니다. 어떤 창발은 측정의 착시이고, 어떤 것은 실제일 수 있으며, 아직 결론이 나지 않았습니다. 10회차에서 "무엇을 재느냐가 무엇을 보느냐를 정한다"고 했던 그 교훈이 최전선에서 반복되고 있어요.

문맥 창 — 모델이 한 번에 보는 것

여기서 반드시 짚어야 할 개념이 문맥 창입니다. 모델이 한 번에 볼 수 있는 토큰의 양이에요.

가장 중요한 사실부터 말하면, 모델은 대화를 기억하지 않습니다. 매번 지금까지의 대화 전체를 다시 통째로 입력받아요. 기억처럼 느껴지는 것은 앞의 대화가 매번 다시 들어가고 있기 때문입니다.

그래서 대화가 길어져 문맥 창을 넘으면 앞부분이 잘려 나갑니다. "아까 말했잖아요"가 안 통하는 순간이 오는 이유죠.

16회차에서 봤듯 문맥을 늘리는 비용은 제곱입니다. 그래서 문맥 길이가 계속 뉴스가 되고요. 그리고 그때 말한 주의사항이 그대로 유효합니다. 넣을 수 있는 양과 실제로 잘 쓰이는 양은 다릅니다. 긴 문맥의 중간에 둔 정보를 모델이 놓치는 현상이 꾸준히 보고되고 있어요.

파라미터 수는 무엇을 뜻하나

12회차에서 파라미터는 가중치와 편향이라고 했습니다. 조절 가능한 다이얼의 개수죠. 이제 조금 더 실질적인 의미를 붙일 수 있습니다.

파라미터가 많으면 담을 수 있는 양이 늘어납니다. 더 많은 규칙, 더 많은 사실, 더 미세한 구분을 담을 수 있어요.

대신 비용이 함께 늘어납니다. 훈련 비용만이 아니라 쓸 때마다의 비용도요. 파라미터가 많으면 답변 한 번에 계산이 더 들고, 그만큼 느리고 비쌉니다.

그래서 요즘 업계의 관심사가 "같은 성능을 더 작게"로 옮겨 갔습니다. 큰 모델의 능력을 작은 모델에 옮겨 담는 기법, 필요한 부분만 켜서 쓰는 구조 같은 것들이죠. 뉴스에 자주 나오는 "작지만 강한 모델"이 전부 이 흐름입니다.

실전 ① 토큰으로 값이 매겨집니다

실무에서 가장 먼저 부딪히는 것이 비용입니다. API를 쓰면 요금이 토큰 단위로 매겨져요. 그리고 입력 토큰과 출력 토큰의 단가가 다릅니다. 대개 출력이 몇 배 비쌉니다.

이유는 오늘 배운 내용으로 설명됩니다. 입력은 한 번에 병렬로 처리할 수 있지만, 출력은 자기회귀라 한 조각씩 만들어야 하거든요. 병렬이 안 되니 비쌉니다.

그래서 비용을 줄이는 실질적인 방법은 출력을 짧게 요구하는 것입니다. "간결하게", "표 없이 세 문장으로" 같은 지시가 실제로 요금을 줄여요.

그리고 긴 문서를 반복해서 넣는다면 같은 부분을 매번 다시 계산하지 않는 기능을 확인해 볼 만합니다. 앞부분이 동일한 요청을 여러 번 보낼 때 비용을 크게 줄여 줍니다.

실전 ② 왜 같은 질문에 다른 답이 나오나

이제 이 흔한 의문에 정확히 답할 수 있습니다. 샘플링이 확률적이기 때문입니다.

같은 질문이라도 점수표에서 매번 다시 뽑으니 다른 경로로 갈 수 있어요. 그리고 자기회귀라 초반에 조각 하나만 달라져도 이후가 전부 달라집니다.

일관성이 필요하면 온도를 낮추면 됩니다. 다만 완전히 같아지지는 않을 수 있어요. 여러 요청을 묶어 처리하는 방식이나 하드웨어의 계산 순서 차이로 미세한 흔들림이 남기 때문입니다.

그래서 실무 원칙은 이렇습니다. 같은 답이 나오는 것에 의존하는 설계를 하지 마세요. 형식이 중요하면 형식을 검사하는 절차를 따로 두고, 사실이 중요하면 21회차에서 다룰 검증 습관을 붙여야 합니다.

실전 ③ 한국어 사용자가 겪는 불리함

이 시리즈의 관점에서 반드시 짚어야 할 것이 있습니다. 토큰 분할은 언어마다 공평하지 않습니다.

토큰 목록은 학습 데이터의 분포를 따라 만들어집니다. 그런데 그 데이터에서 영어의 비중이 압도적이에요. 그래서 영어는 흔한 낱말이 대개 한 토큰인데, 한국어는 같은 뜻을 담는 데 훨씬 많은 토큰이 듭니다.

결과가 셋입니다. 같은 내용을 넣어도 문맥 창을 더 많이 차지하고, 요금이 더 나오고, 출력이 더 느립니다. 같은 도구를 쓰는데 언어 때문에 불리한 겁니다.

다행히 격차는 줄고 있습니다. 최근 모델들은 한국어 토큰 효율을 상당히 개선했어요. 하지만 구조적으로 남는 차이라는 점은 알아 둘 만합니다. 그리고 이것은 29회차에서 다룰 언어별 AI 접근성 격차의 가장 밑바닥에 있는 층입니다.

이 원리에서 곧장 나오는 한계

오늘 배운 원리만으로도 왜 그런 한계가 생기는지가 대부분 설명됩니다. 21회차의 예고편으로 짚어 둘게요.

왜 그럴듯한 거짓을 말하나. 모델의 목표는 참을 말하는 것이 아니라 그럴듯한 다음 조각을 고르는 것입니다. 참과 그럴듯함이 대체로 겹치지만 항상 겹치지는 않아요. 존재하지 않는 논문 제목도 논문 제목처럼 그럴듯하게 생겼습니다.

왜 모르면서 모른다고 안 하나. 훈련 데이터에서 "모르겠습니다"는 드물게 나오는 답이기 때문입니다. 사람들은 대개 아는 것을 씁니다.

왜 최신 정보를 모르나. 사전학습에는 마감 시점이 있고 그 이후는 배우지 못했습니다.

왜 계산을 틀리나. 계산기가 아니라 계산 결과처럼 보이는 조각을 고르는 장치이기 때문입니다. 자주 본 식은 잘 맞히고 처음 보는 큰 수는 틀립니다.

핵심 정리 — 세 줄

첫째, LLM은 다음 토큰의 확률 분포를 내놓고 거기서 하나를 뽑는 장치입니다. 답 하나를 내는 것이 아니라 어휘 전체에 점수를 매기며, 그중 하나를 확률에 비례해 뽑아 뒤에 붙이고 전체를 다시 읽는 자기회귀로 글을 만듭니다. 온도는 그 분포를 뾰족하게 또는 평평하게 만드는 손잡이입니다.

둘째, 다음 조각 맞히기가 전부를 흡수한 이유는 웹의 모든 글에 이미 모든 과제가 들어 있기 때문입니다. 번역문 다음을 맞히려면 번역을 할 줄 알아야 하고, 정해진 크기에 웹을 담으려면 외우는 대신 규칙을 찾아야 합니다. 잘 예측하는 것과 잘 압축하는 것이 같은 일이라는 점이 지능처럼 보이는 것의 기원입니다.

셋째, 규모의 법칙은 AI를 연구 문제에서 자본 문제로 바꿨습니다. 구조를 바꾸지 않아도 크기·데이터·계산을 함께 키우면 성능이 예측 가능하게 좋아졌고, 그래서 데이터센터와 반도체가 판돈이 됐습니다. 다만 창발이 실제 도약인지 측정의 착시인지는 아직 결론이 나지 않았습니다.

용어 정리

토큰 — 모델이 글을 다루는 단위. 낱말도 글자도 아닌 중간 크기이며, 자주 나오는 덩어리는 통째로 드문 것은 잘게 쪼갭니다.

어휘 목록 — 모델이 아는 토큰의 전체 목록. 데이터에서 통계적으로 학습됩니다.

확률 분포(다음 토큰) — 가능한 모든 토큰에 매겨진 다음 차례일 확률. 모델의 실제 출력물입니다.

샘플링 — 확률 분포에서 실제로 하나를 뽑는 일. 확률에 비례해 뽑고 꼬리를 잘라 냅니다.

온도 — 분포를 뾰족하게 하거나 평평하게 하는 값. 낮추면 일관되고 올리면 다양해집니다.

자기회귀 — 고른 토큰을 뒤에 붙이고 전체를 다시 읽어 다음을 만드는 반복. 앞으로만 나아가며 되돌릴 수 없습니다.

사전학습 — 방대한 글로 다음 토큰 맞히기를 훈련하는 단계. 정답표를 사람이 만들 필요가 없습니다.

자기지도학습 — 데이터 자체에서 정답을 만들어 내는 학습 방식. 사람의 이름표가 필요 없어 규모를 키울 수 있습니다.

규모의 법칙 — 모델 크기·데이터·계산량을 늘리면 성능이 예측 가능하게 좋아진다는 경험적 규칙.

창발 — 어느 규모를 넘어서면서 없던 능력이 갑자기 나타나는 것처럼 보이는 현상. 측정 방식에 따른 착시라는 반론이 있습니다.

문맥 창 — 한 번에 볼 수 있는 토큰의 양. 모델은 대화를 기억하지 않고 매번 전체를 다시 입력받습니다.

지식 마감 시점 — 사전학습 데이터가 수집된 시점. 그 이후 일은 배우지 못했습니다.

다음 회차 예고 — 그리고 생각해볼 질문

19회차는 「LLM은 어떻게 길러지는가」입니다. 오늘 다룬 사전학습만 끝낸 모델은 사실 대화를 못 합니다. 질문을 넣으면 답을 하는 게 아니라 비슷한 질문을 계속 만들어 내기도 해요. 웹에는 질문 목록이 흔하니까요.

다음 회차에서는 그 날것의 모델이 어떻게 대화할 줄 알고, 지시를 따르고, 위험한 요청을 거절하는 존재가 되는지를 다룹니다. 지시 미세조정과 인간 피드백 강화학습이 주제이고, 11회차에서 예고한 그 기법이 마침내 등장합니다. 그리고 그 과정에서 누구의 선호가 기준이 되는가라는 질문도 함께 봅니다.

생각해볼 질문. 오늘 "잘 예측하는 것과 잘 이해하는 것이 같은 일일 수 있다"는 관점을 봤습니다. 압축을 잘하려면 규칙을 찾아야 하고, 규칙을 찾은 것을 우리는 이해라고 부르니까요.

그런데 정말 같을까요? 다음에 무슨 일이 벌어질지 아주 잘 맞히는 사람이 있다면, 우리는 그가 이해했다고 말할까요, 아니면 패턴을 익혔을 뿐이라고 말할까요? 그 둘을 가르는 기준이 있다면 무엇일지 댓글로 들려주세요.

이 포스트는 SVIL 연구소 「AI 기초 및 활용」 30회 시리즈의 18회차이며, 제4부 「생성형 AI와 LLM 시대」의 첫 회입니다. 하버드 CS50 AI, MIT 6.S191 등 공개 교육과정의 구조를 참고했으며, 모든 내용은 이미지 없이 본문만으로 이해할 수 있도록 구성되어 있습니다. 모든 이미지에는 내용을 설명하는 대체텍스트가 포함되어 있습니다.

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://kuroicode-beep.github.io/svil-homepage/