You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 

382 lines
11 KiB

WEBVTT
00:00.770 --> 00:03.530
지금쯤이면 정말 지쳤을 거예요
00:03.560 --> 00:05.330
그렇다고 해도 괜찮아요
00:05.360 --> 00:07.430
정말 잘하셨어요
00:07.430 --> 00:15.290
이번 주는 정말 힘들었죠 새로운 정보가 수없이 많았거든요 처음부터 리더보드와
00:15.290 --> 00:20.990
경기장에서부터 코드 번역기 구현까지 프론티어 모델과
00:21.020 --> 00:25.070
오픈 소스 모델에서요
00:25.070 --> 00:29.450
많은 일을 겪었고 꽤 긴 여정이었어요
00:29.480 --> 00:37.490
새로운 기술을 많이 익혔으니 축하해주러 온 거예요 그리고 오늘 마지막
00:37.490 --> 00:44.240
수업은 꽤 짧을 거예요 다음 주를 준비하니까요
00:44.270 --> 00:49.190
우선, 다시 말하지만 개척 시대의 음악이었어요
00:49.190 --> 00:53.600
이번에는 클로드가 쇼에서 이기게 해줘야 해요
00:53.690 --> 01:01.130
파이썬과 C 플러스 간의 코드를 작성하고 번역하는 소프트웨어를 개발하는 건 정말 즐거웠어요
01:01.130 --> 01:01.640
더 있어요
01:01.640 --> 01:05.490
클로드가 대장 노릇을 하는 걸 봤죠
01:05.490 --> 01:10.260
알고리즘을 다시 구현한 건 정말 멋진 일이에요
01:10.500 --> 01:15.810
오늘 마무리로 오픈 소스와 비공개 소스 모델의 성능에 대해
01:15.810 --> 01:17.700
좀 더 논의할 텐데요
01:17.790 --> 01:21.510
코드 생성 시 상업적 유스 케이스도 다룰 거예요
01:21.510 --> 01:23.940
물론 당신에게 주어진 과제도 있어요
01:23.940 --> 01:25.560
큰 임무잖아요
01:25.560 --> 01:32.550
이 세션이 비교적 짧지만 당신에게 주어진 일은 상대적으로 훌륭합니다 어떤 걸 생각해내실지
01:32.550 --> 01:34.350
빨리 보고 싶네요
01:34.770 --> 01:42.930
하지만 먼저 중요하고 중요한 문제에 대해 잠시 얘기하고 싶습니다 여러분의 인공지능
01:42.930 --> 01:49.170
솔루션이 실제로 잘 작동하는지 어떻게 결정하나요?
01:49.260 --> 01:53.400
평가할 때 어떤 기술이 필요한가요?
01:53.460 --> 01:59.190
아까도 말했지만 가장 중요한 질문일 겁니다 성공의 척도는
01:59.190 --> 02:01.530
많은 걸 좌우하니까요
02:01.560 --> 02:06.070
미리 생각하고 확립하고 연구해야 하는 거죠
02:06.610 --> 02:13.720
하지만 성능 지표에는 두 종류가 있습니다 그 차이를 이해하고
02:13.720 --> 02:17.770
적절하게 사용하는 게 중요하죠
02:17.800 --> 02:23.560
첫 번째 종류는 모델 중심이라고도 불리는 기술적 측정법이에요
02:23.560 --> 02:29.620
데이터 과학자들은 이런 측정 기준에 목숨을 걸어요 모델을 최적화할
02:29.620 --> 02:37.690
수 있는 측정 기준이고 모델의 성능을 바로 측정하는 경향이 있거든요
02:37.720 --> 02:41.200
이제 이런 지표 몇 가지에 대해 말씀드리겠습니다 전부는 아니고요 일부는
02:41.200 --> 02:43.300
전통적인 머신 러닝과 더 관련이 있거든요
02:43.300 --> 02:46.030
이미 경험이 있을 수도 있고 없어도 괜찮아요
02:46.030 --> 02:53.170
첫 번째 항목 손실은 일반적인 용어로 LLM이 작업에서 얼마나 형편없었는지를 뜻합니다
02:53.170 --> 02:56.530
일반적으로 최적화에 사용되죠
02:56.530 --> 03:01.480
손실을 최소화하려고 노력하죠 그게 최적화의 작업이에요
03:01.480 --> 03:03.100
모델을 훈련할 때요
03:03.340 --> 03:10.910
이 분야에서 가장 자주 발생하는 손실은 교차 엔트로피 손실이라고 하는데 이렇게 작용해요
03:10.940 --> 03:17.480
여러분의 입력 텍스트인 토큰의 입력 집합과 토큰의 시퀀스가 있다고 상상해 보세요
03:17.480 --> 03:19.730
다음 토큰을 예측하는 거군요
03:19.730 --> 03:23.570
훈련 데이터에서 다음 토큰이 무엇인지 알 수 있죠
03:23.780 --> 03:28.820
하지만 훈련의 일부로 이 시퀀스의 일부를 모델에 피드하려고 할 겁니다 예를 들어
03:28.850 --> 03:32.750
다음 토큰을 예측하고 진짜 다음 토큰을 갖게 되는 거죠
03:32.750 --> 03:37.220
이 두 결과로 손실을 계산하고 싶겠죠
03:37.250 --> 03:38.780
이런 방법도 있어요
03:38.810 --> 03:44.810
모델이 실제로 하는 일은 다음 토큰을 예측하는 것이 아닙니다 지금까지 제가 말한 방식으로는요
03:44.810 --> 03:50.450
이것은 확률을 분배하는 역할을 합니다. 목록에 있는 다음 토큰의
03:50.450 --> 03:52.370
확률을 말이죠.
03:52.370 --> 03:55.880
예를 들어 가능성이 가장 높은 걸 고를 수도 있죠
03:55.910 --> 04:02.750
교차 엔트로피 손실을 계산하는 방법은 이제 진짜 다음 토큰이 뭔지 안다고
04:02.750 --> 04:03.770
하는 거죠
04:03.800 --> 04:08.850
모델이 토큰에 어떤 확률을 기록했는지 알아보죠
04:08.850 --> 04:13.800
다음에 나올 것은 hello로 시작해서 다음 것은 단어에
04:13.800 --> 04:15.570
대한 토큰이죠
04:15.600 --> 04:20.130
그럼 모델이 제시한 단어의 확률을 알아보죠
04:20.130 --> 04:25.560
그 확률을 교차 엔트로피 손실의 토대로 사용할 거예요
04:25.560 --> 04:27.360
사실, 손실로 바꾸어 놓았죠
04:27.360 --> 04:31.260
확률을 따져 보면 높은 숫자가 더 낫거든요
04:31.260 --> 04:35.190
인명 손실은 나쁜 거예요 우리는 인명 손실이 많으면 더 나빠지길 바라죠
04:35.190 --> 04:39.810
그래서 네거티브 로그를 선택해요
04:39.840 --> 04:42.600
확률을 빼고 계산해 보죠
04:42.630 --> 04:44.100
비트 때문에 좀 헷갈리실 거예요
04:44.130 --> 04:44.790
왜 그래야 하죠?
04:44.790 --> 04:50.910
만약 확률이 1이라면, 그게 완벽한 대답이 되겠죠. 그 말은 다음
04:50.910 --> 04:57.390
토큰이 정확히 다음 토큰이 될 확률이 100%라는 뜻이 되겠죠.
04:57.390 --> 05:00.450
1의 가능성이 완벽한 답이겠네요
05:00.450 --> 05:04.320
마이너스 1은 0, 0, 0 손실이에요
05:04.320 --> 05:05.340
완벽한 대답이에요
05:05.340 --> 05:06.360
잘 작동하네요
05:06.390 --> 05:12.540
확률이 아주 작은 숫자라면 숫자가 점점 작아질수록 그 숫자에 대한
05:12.540 --> 05:18.000
음수는 0에 가까워질수록 양수가 점점 더 높아져요
05:18.000 --> 05:19.410
이것도 잘 작동하죠
05:19.410 --> 05:21.420
손실이 되죠
05:21.450 --> 05:24.120
손해가 크면 안 좋죠
05:24.210 --> 05:31.590
그래서 확률의 부정적인 로그를 즉, 예상된 확률을 실제 다음 토큰으로
05:31.590 --> 05:39.720
추정한 건데 교차 엔트로피 손실이라고 해요 사용되는 기본 지표 중 하나죠
05:39.750 --> 05:44.700
일반적으로 훈련 LMS와 관련해 언젠가 우리가 직접 사용하게 될 텐데요
05:45.330 --> 05:50.790
흔히 듣는 또 다른 측정법은 이와 밀접한 관련이 있는데 당혹스러움이라고 해요
05:50.820 --> 05:54.180
교차 엔트로피 손실의 힘의 약자를 뜻하죠
05:54.210 --> 06:02.850
결과가 그렇게 나오면 당혹스럽죠 그 모델은 결과에 대해 완전히 확신하고
06:02.850 --> 06:05.280
정확해요
06:05.280 --> 06:08.490
100% 정확하고 100% 확실하죠
06:08.490 --> 06:10.470
그럼 한 가지 당혹감이 생기겠죠
06:10.500 --> 06:13.560
2는 50점 만점에 50점이에요
06:13.590 --> 06:15.540
절반은 맞아요
06:15.690 --> 06:21.120
4의 당혹스러움은 25% 확률이에요
06:21.120 --> 06:22.800
그걸 보면 감이 오죠
06:22.800 --> 06:31.350
더 높고 복잡한 건 토큰이 몇 개 필요한지 알게 돼요 모든 게 평등하다면
06:31.350 --> 06:35.820
다음 토큰을 예측하기 위해서요
06:36.030 --> 06:39.330
그래서 상실감과 당혹감이 들죠
06:39.330 --> 06:45.870
다른 건 언급하지 않겠지만 모델의 정확성 혹은 부정확성을 측정하는
06:45.870 --> 06:52.170
즉각적인 방법들이고 모델 최적화나 분석에 사용될 수 있어요.
06:52.350 --> 06:55.110
그게 모델 중심 지표예요
06:55.110 --> 06:56.880
다른 측정 기준은 뭔가요?
06:56.910 --> 07:00.750
사업 중심 지표나 결과 지표도 있어요
07:00.750 --> 07:05.220
이런 것들이 비즈니스 팬들에게 가장 큰 반향을 일으킬 거예요
07:05.220 --> 07:08.610
궁극적으로 그들이 해결하라고 요구하는 문제이기도 하고요
07:08.690 --> 07:14.990
따라서 기업 측에서 요구한 실제 결과와 연관된 KPI죠
07:15.020 --> 07:17.390
투자 수익률 같은 거겠죠
07:17.480 --> 07:23.030
최적화를 위한 것이라면 시간이 지나면 개선되겠죠
07:23.390 --> 07:28.850
우리가 방금 한 걸 생각해보면 궁극의 메트릭은 코드에 대한 거예요
07:28.850 --> 07:30.740
방금 만든 코드 솔루션이요
07:30.740 --> 07:34.610
C 플러스 플러스 코드가 파이썬 코드보다 얼마나 빠른가요?
07:34.730 --> 07:38.030
같은 답을 쓰면 몇 배나 빨라지죠?
07:38.210 --> 07:45.020
비즈니스 중심 혹은 결과 지표의 한 예입니다 전체 제품을 실행하고 결과가
07:45.020 --> 07:48.620
어떻게 나오는지 보라는 거니까요
07:49.280 --> 07:53.780
벤치마크와 비교할 수 있는 또 다른 예가 있어요
07:53.780 --> 07:58.400
뭔가를 하고 있다면 특정 비즈니스 작업을 수행하는 데 다른
07:58.400 --> 08:02.630
벤치마크를 뛰어넘는 솔루션을 구축하는 거죠
08:02.660 --> 08:08.360
따라서 이런 측정법의 큰 이점은 명확하고 구체적인 측정법이 여러분의 사업
08:08.360 --> 08:10.700
목표에 반영된다는 거죠
08:10.700 --> 08:15.740
이런 측정값에서 바늘을 움직일 수 있다면 충격을 전달한 것이고 증명할 수 있어요
08:15.770 --> 08:21.830
물론 문제는 모델의 연기와 바로 연결되지 않는다는 거죠
08:21.830 --> 08:25.730
다른 모든 것과 관련돼 있죠 여러분이 가진 데이터, 환경, 사용 방법 그리고
08:25.730 --> 08:30.260
원래 아이디어가 정말 비즈니스 문제를 해결하는 데 도움이 되는지 같은 거요
08:30.260 --> 08:36.260
모델의 성과와 비즈니스 척도 사이에는 미지의 요소가 많아요
08:36.260 --> 08:41.870
하지만 비즈니스 지표가 현실에서 의미 있다는 큰 장점이 있어요
08:41.870 --> 08:46.130
그래서 답은 두 가지 측정법을 모두 써야 한다는 거죠
08:46.130 --> 08:47.780
같이 써야 해요
08:47.780 --> 08:54.620
하나는 모델을 최적화해 빠른 성능을 보여주기 위해 미세 조정하는 것이죠
08:54.620 --> 09:01.520
다른 하나는 솔루션 뒤에 숨겨진 비즈니스 영향을 궁극적으로 증명할 때 사용하죠
09:01.520 --> 09:04.490
다음 세션에선 잠시 중단할게요
09:04.490 --> 09:09.530
한 번 더 돌아가서 코딩 솔루션을 살펴보고 다음 레벨로 넘어가기 위해 무엇을
09:09.530 --> 09:11.600
할 수 있는지 얘기해보죠