WEBVTT 00:01.310 --> 00:03.650 5일째에 오신 걸 환영해요 00:03.680 --> 00:04.490 진짜로요 00:04.490 --> 00:06.680 주피터 공책에 있는 거예요 00:06.710 --> 00:11.060 오늘은 5일째예요 5주 차죠, 준비됐어요 00:11.060 --> 00:13.610 예전과 똑같아요 00:13.940 --> 00:16.580 4일 반이 아니라 4일 차와 똑같은 거예요 00:16.580 --> 00:22.760 크로마 Datastore를 사용하고 있습니다 빠르게 살펴보겠습니다 이미 00:22.760 --> 00:24.560 다 알고 계시니까요 00:24.560 --> 00:31.160 그리고 그래디오 인터페이스로 돌아갈 거예요 get it 00:31.160 --> 00:31.970 이렇게요 00:31.970 --> 00:33.110 그게 우리를 따라잡았죠 00:33.230 --> 00:33.890 그려진 거예요 00:33.890 --> 00:36.080 무대 뒤에서 2D와 3D 도표가 펼쳐지죠 00:36.080 --> 00:37.130 하지만 그럴 시간이 없어요 00:37.130 --> 00:37.490 지금요 00:37.490 --> 00:38.840 계속 가야 해요 00:39.200 --> 00:45.230 먼저 보여드릴 게 있어요 전에 했던 조류 실험은 바이브스 실험처럼 채도로도 00:45.260 --> 00:46.550 효과가 있어요 00:46.550 --> 00:49.190 우리도 빨리 해보죠 00:49.400 --> 00:56.750 철자를 틀리게 쓴 새장은 어떤 역할을 했죠? 00:57.320 --> 01:00.350 상상이 돼요 01:00.350 --> 01:01.130 두고 봐야죠 01:01.160 --> 01:01.820 네 01:01.820 --> 01:06.280 채도가 전혀 문제가 없어요 01:06.310 --> 01:07.810 놀랍지도 않네요 01:07.840 --> 01:11.980 좋아요, 하지만 잘 안 될 만한 걸 보여드리죠 01:11.980 --> 01:16.360 먼저 직원 인사 자료를 좀 볼게요 01:16.390 --> 01:22.210 지식 기반으로 가서 직원들을 살펴보죠 맥신 톰프슨의 01:22.210 --> 01:25.360 직원 기록을 살펴볼 거예요 01:25.390 --> 01:27.610 마크다운으로 시작하죠 01:27.610 --> 01:30.010 그래서 완전히 파손된 모습을 보게 되죠 01:30.040 --> 01:35.830 맥신 톰프슨의 인사 기록이에요 텍사스주 오스틴에 사는 데이터 엔지니어죠 01:35.830 --> 01:41.110 잠시 주목해 주셨으면 하는 게 있어요 여기 아래를 보시면 01:41.110 --> 01:47.860 맥신이 2023년 올해의 엘름 이노베이터로 선정된 게 보일 거예요 01:47.890 --> 01:56.410 2023년 엘름 최고의 혁신가 부문에서 아이오티상을 수상했죠 01:56.440 --> 01:59.110 고백하자면 이 문장은 제가 추가했어요 01:59.110 --> 02:06.760 GPT 4나 클로드가 만든 합성 데이터의 일부로 만들어진 건 아니었어요 02:07.090 --> 02:08.620 다 내 탓이에요 02:08.830 --> 02:09.640 끔찍해요 02:09.640 --> 02:11.500 그러니 날 탓해요 02:11.830 --> 02:21.580 이제 5일 차로 돌아가서 질문을 하나 할게요 누가 이겼을까요? 02:24.400 --> 02:36.820 누가 2023년에 권위 있는 슈리람 올해의 혁신자 상을 받았는지를요 02:36.850 --> 02:38.740 뭐라고 쓰여 있는지 보죠 02:40.570 --> 02:42.160 모른다고 나오네요 02:42.190 --> 02:43.510 직설적으로 말하네요 02:43.540 --> 02:44.710 퉁명스럽죠 02:44.770 --> 02:46.420 그게 흥미로워요 02:46.450 --> 02:47.530 실패하고 말았죠 02:47.530 --> 02:49.330 그게 우리가 제공한 정보였어요 02:49.330 --> 02:51.370 서류에 다 나와 있었어요 02:51.370 --> 02:52.900 비트가 좀 실망스럽네요 02:52.900 --> 02:56.290 그러니 이제 이 문제를 진단해 봐야죠 02:56.290 --> 03:00.520 그렇게 함으로써 랑체인의 작동 원리를 비트 아래서 배울 거예요 03:00.700 --> 03:02.950 그리 놀랍지도 않을 거예요 03:03.370 --> 03:06.310 여기선 어떤 상황인지 볼 수 있죠 Get up 03:06.370 --> 03:11.850 아주 유용한 게 있어요 표준 아웃 콜백 처리기라는 걸 만드는 거죠 03:11.850 --> 03:17.010 말 그대로 뒤에서 무슨 일이 일어나는지 표준에 프린트할 03:17.010 --> 03:19.590 수 있게 해주는 거예요 03:19.620 --> 03:22.710 여러분이 아주 익숙한 동일한 코드예요 03:22.740 --> 03:24.000 경보를 울리는 거죠 03:24.090 --> 03:25.530 메모리를 만드는 거죠 03:25.560 --> 03:32.340 리트리버와 대화 사슬을 만듭니다 이 아름다운 한 줄이 LM을 통과하죠 03:32.340 --> 03:35.850 리트리버, 메모리요 03:35.850 --> 03:40.410 제가 하나를 더 넘기고 있는 게 보이시죠 콜백 목록이에요 03:40.410 --> 03:46.560 여기선 한 개의 콜백만 만들고 있어요 표준 아웃 콜백 처리기죠 03:46.560 --> 03:53.430 여러분이 예상하시듯이 반복적으로 표준에 프린트될 겁니다 이 대화 03:53.430 --> 03:55.710 사슬이 실행될 때요 03:55.800 --> 03:58.650 다시 문제입니다 누가 이겼을까요? 03:58.680 --> 03:59.460 전 다르게 표현했어요 Put it up Put it up Put it up 03:59.730 --> 04:00.540 똑같이 해 보죠 04:00.570 --> 04:07.020 2023년 Iet상을 받은 사람은 누구일까요? 04:07.050 --> 04:07.770 됐어요 04:07.800 --> 04:09.030 그 질문을 해보죠 04:09.030 --> 04:10.110 Get get get, get get, get 답을 찾아볼게요 04:10.110 --> 04:11.930 뭐라고 쓰여 있는지 보죠 04:12.770 --> 04:18.350 비트 박스를 통해 흔적을 얻으면 랭 체인이 어떻게 돌아가는지 알 04:18.350 --> 04:19.010 수 있죠 04:19.010 --> 04:21.170 다양한 물체가 있어요 04:21.170 --> 04:28.010 이런 걸 체인이라고 하는데 대화를 구성하는 단계를 거치면서 연결되는 04:28.010 --> 04:30.440 거예요 래그 쿼리요 04:30.440 --> 04:34.490 다양한 콜백을 이용해 각 단계에서 일어나는 일에 대해 보다 상세히 04:34.490 --> 04:36.590 프린트할 수도 있어요 원한다면요 04:36.590 --> 04:41.600 하지만 정말 중요한 건 GPT 4에 도달하는 프롬프트죠 04:41.600 --> 04:43.040 여기 있네요 04:43.040 --> 04:44.090 시스템요 04:44.090 --> 04:47.330 다음 컨텍스트를 이용해 사용자의 질문에 답하세요 04:47.330 --> 04:50.300 모르면 모른다고 하면 되잖아요 04:50.300 --> 04:52.220 없는 말 지어내지 마세요 04:52.250 --> 04:57.200 정말 흥미로운 건 랭 체인 전문가들이 다양한 llm에 04:57.230 --> 05:02.090 보낼 이상적인 프롬프트란 거예요 05:02.090 --> 05:06.020 따라서 이건 여러분이 자신의 프로젝트에 사용하기에 아주 좋아요 05:06.020 --> 05:07.730 아주 공들여 쓴 거예요 05:07.730 --> 05:13.250 아주 효과적인 약이에요 GPT 4가 환각 증상을 보이지 않게 막았으니까요 05:13.370 --> 05:16.670 각본이 잘 짜여진 게 좋았어요 05:17.390 --> 05:18.710 하지만 문제가 있어요 05:18.710 --> 05:25.520 이 컨텍스트가 제공된 곳은∙∙∙ 여기 나오는 LM이죠 05:25.520 --> 05:30.740 보시면 아시겠지만 여러 덩어리에서 몇 개만 추출한 거예요 05:30.770 --> 05:36.200 두세 덩어리인데 인사 기록에서 빼낸 것 같아요 05:36.410 --> 05:38.180 하지만 옳지 않아요 05:38.180 --> 05:42.140 아이오티상은 언급하지 않으니까요 05:42.140 --> 05:47.060 안타깝게도 이 경우엔 엉뚱한 덩어리를 식별했어요 05:47.300 --> 05:51.230 그리고 이 마지막 부분이 질문이에요 05:51.230 --> 05:55.400 아이오티상을 받은 인간이라고 쓰여 있어요 05:55.730 --> 05:56.780 내가 인간이에요 05:56.780 --> 06:03.320 그 질문에 대한 답을 하기에는 좋은 맥락이 없었어요 06:03.320 --> 06:07.160 그래서 이런 반응을 보였겠죠 06:07.850 --> 06:10.370 그럼 어떻게 해야 할까요? 06:10.370 --> 06:14.990 래그와 관련해 아주 흔한 문제입니다 올바른 컨텍스트를 제공하지 않을 06:14.990 --> 06:15.590 때요 06:15.590 --> 06:17.440 할 수 있는 게 몇 가지 있어요 06:17.680 --> 06:22.420 하나는 청킹 전략을 다시 살펴보는 거예요 06:22.540 --> 06:25.270 서류를 어떻게 덩어리로 나누죠? 06:25.270 --> 06:26.050 그러고 있어요? 06:26.050 --> 06:26.500 네 06:26.500 --> 06:28.780 바로 시도해 볼 만한 게 몇 가지 있어요 06:28.810 --> 06:34.300 그 중 하나는 청크링 대신에 전체 문서를 컨텍스트로 보낼 수 있다는 거죠 06:34.300 --> 06:40.480 그래서 전체 문서를 get get get에 넣고 가장 가까운 문서를 찾아봤어요 06:40.510 --> 06:46.930 반대로 큼직큼직하게 잘라 입자가 곱거나 작을 수도 있어요 06:47.140 --> 06:52.030 또한 덩어리 간의 중첩을 조사해서 겹치는 부분이 늘어나는지 줄어들는지 확인할 06:52.030 --> 06:52.960 수도 있죠 06:52.960 --> 06:57.490 이런 경우에는 유용한 정보를 제공할 가능성이 더 크죠 06:57.490 --> 07:04.990 모두 조사해볼 만한 것들이에요. 청킹 전략이 잘 작동하도록 하기 위해서요. 그래서 올바른 컨텍스트가 제공되고 있어요. 07:04.990 --> 07:06.160 Get up! 07:06.190 --> 07:07.420 한 가지 더 있어요 07:07.420 --> 07:08.230 아주 간단해요 07:08.230 --> 07:09.910 이 경우에 그렇게 할 거예요 07:10.090 --> 07:15.850 get의 개수를 조절하는 거죠 실제로 전송되는 컨텍스트의 양을요 07:16.090 --> 07:21.390 음, 저희 경우엔 그냥∙∙∙ 여기로 전송되는 건 3개일 07:21.390 --> 07:28.650 거예요 전송되는 덩어리의 수를 컨트롤할 수 있어요 이렇게 할 수 있죠 07:28.650 --> 07:36.240 리트리버 벡터 스토어를 리트리버로 생성할 때 얼마나 많은 덩어리를 반환하고 넘길지 07:36.270 --> 07:38.040 정할 수 있어요 07:38.040 --> 07:44.340 이 경우에 전 25개의 덩어리가 생성돼 전달되도록 지정했어요 07:44.370 --> 07:49.470 경험상 LLM에 많은 컨텍스트를 보내는 게 좋아요 07:49.500 --> 07:56.730 Rms는 관련 맥락에만 초점을 맞추고 불필요한 맥락을 무시하는 데 뛰어나요 07:56.730 --> 07:59.670 그러니 덩어리를 많이 보내는 게 좋아요 07:59.670 --> 08:03.810 그러지 않는 게 나은 상황도 가끔 있어요 08:03.840 --> 08:10.260 예를 들어 오픈AI가 제공하는 최신 모델 중 하나가 그 예입니다 즉각적으로 08:10.260 --> 08:17.970 더 자세히 살펴보고 보이지 않는 곳에서 분석을 통해 제대로 이해하는 모델이죠 08:17.970 --> 08:20.070 일종의 사고의 연속이죠 08:20.250 --> 08:25.710 그리고 비관련 컨텍스트를 많이 제공하지 않는 걸 추천합니다 그러면 속도가 08:25.710 --> 08:28.230 느려지고 모델이 산만해지니까요 08:28.230 --> 08:34.020 하지만 가끔씩 나오는 예들을 보면 경험상 일반적인 규칙은 더 많은 컨텍스트가 08:34.020 --> 08:35.040 좋다는 거죠 08:35.490 --> 08:42.660 이 경우에는 큰 해가 되지 않아요 가장 가까운 25개를 두세 개보다 더 많이 주는 08:42.660 --> 08:43.260 거죠 08:43.260 --> 08:45.900 덩어리가 총 123개예요 08:45.900 --> 08:48.810 그러니 이건 전체 데이터의 5분의 1에 불과해요 08:48.810 --> 08:51.210 전체 데이터 세트를 보내는 게 아니에요 08:51.240 --> 08:58.680 가장 관련 있는 25개의 청크를 선택하고 있어요 LLM을 보내기 위한 콘텐츠 중 가장 관련 있는 5분의 1이죠 08:58.680 --> 09:00.360 잘 되는지 보죠 09:00.360 --> 09:02.010 이걸 실행할게요 09:02.010 --> 09:07.530 그리고 전처럼 평소대로 그래디오 인터페이스를 켜죠 09:07.530 --> 09:15.540 그럼 바로 질문을 시작하죠 누가 이겼는지 누가 그걸 사용하게 됐는지요 09:15.570 --> 09:16.860 그래서 일관성을 유지하죠 09:16.890 --> 09:26.960 2023년 아이티유상을 수상했죠 09:26.990 --> 09:27.950 어디 보죠 09:27.980 --> 09:29.240 드럼 부탁해요 09:29.270 --> 09:30.230 맥신이에요 09:30.260 --> 09:35.300 맥신은 명망 높은 Iot 2023 상을 받았어요 09:35.300 --> 09:40.730 달 착륙선에 더 많은 덩어리를 제공한 게 문제 해결이었죠 09:40.940 --> 09:46.370 이제 돌아가서 이걸 실험해 보세요 09:46.370 --> 09:47.960 어려운 질문을 해보세요 09:47.960 --> 09:51.140 언제든 문서에 몇 가지 삽입해 어떻게 되는지 볼 수 있어요 09:51.350 --> 09:54.440 그리고 다양한 청량 전략을 실험해 보는 거죠 09:54.440 --> 10:01.370 전체 문서를 입력해보세요 더 작은 덩어리로요 100글자 정도로요 더 많거나 덜 겹치게요 그게 10:01.370 --> 10:09.140 결과의 질에 어떤 영향을 미치는지 느껴보세요 너무 적은 컨텍스트를 제공할 수도 있고요 Get it 10:09.170 --> 10:11.780 너무 많은 컨텍스트를 제공하면 어떤 영향을 미치는지 알 수 있죠 10:11.810 --> 10:14.540 그래서 NTSB의 반응이 less로 나오는 것 같아요 10:14.540 --> 10:23.000 그래서 좋은 점과 나쁜 점을 파악하고 가장 효과적인 방법을 잘 파악할 수 있도록요 10:23.030 --> 10:24.830 get it 10:24.830 --> 10:28.010 그럼 다음 영상에서 다시 만나요