WEBVTT 00:00.800 --> 00:02.300 무슨 생각 하시는지 알아요 00:02.300 --> 00:03.800 무슨 일인가 싶죠 00:03.830 --> 00:05.000 오늘이 5일째예요 00:05.030 --> 00:06.740 5주 차 중 5일째예요 00:06.770 --> 00:08.840 왜 주피터 공책을 펼쳐놨죠? 00:08.840 --> 00:10.730 4일째라고 하죠 5분 00:10.730 --> 00:18.020 넷째 날에 잠깐 편차가 생겼기 때문이죠 벡터 데이터 저장소를 다른 것으로 바꾸는 게 00:18.020 --> 00:21.110 얼마나 간단한지 보여드리려고요 00:21.110 --> 00:27.020 이건 아주 흔하고 많이 사용되니까 여러분께 보여드리기에 좋을 것 같았어요 다른 벡터 데이터 00:27.020 --> 00:32.930 저장소를 표시하는 데 둘 다 사용하고 이런 추상화로 작업하는 게 얼마나 쉬운지도 보여드리기 00:32.960 --> 00:34.310 위해서요 00:34.340 --> 00:39.140 설명해드릴 게 있는데 이건 벡터 데이터 저장소가 아니에요 00:39.140 --> 00:47.810 Facebook 인공지능 동시성 검색을 뜻합니다 페이스북이 만든 자주 사용되는 아주 일반적인 오픈 00:47.840 --> 00:54.860 소스 라이브러리예요 서로 가까운 벡터에 대한 빠른 검색을 가능하게 하죠 그래서 일종의 00:54.890 --> 00:58.370 인 메모리 벡터 스토어로 사용돼요 00:58.370 --> 01:04.160 디스크에 남아 있진 않지만 벡터를 불러오고 유사한 다른 벡터를 검색하기 위해 01:04.160 --> 01:09.230 사용할 수 있어요 라이브러리로도 사용할 수 있죠 유사한 검색을 하기 01:09.230 --> 01:16.520 위해서요 다른 벡터에 가까운 벡터를 찾기 위해서요 랭샨은 그에 대해 올바른 추상화가 내장되어 있어요 01:16.520 --> 01:19.220 그래서 크로마를 대체할 수 있죠 01:19.220 --> 01:22.310 채도를 사용했는데 디스크에 영구적으로 남아 있었죠 01:22.310 --> 01:26.090 좀 더 심각한 데이터 스토어 악습이죠 01:26.510 --> 01:29.360 채도 대신 쓰면 돼요 01:29.360 --> 01:34.070 얼마나 쉬운지 보여드릴게요 코드는 거의 동일할 테니까요 해당 추상화와 01:34.070 --> 01:37.610 몇 가지 다른 걸 제외하면요 get get it 01:38.240 --> 01:42.110 이 import에서 아까처럼 import를 실행하고요. 01:42.110 --> 01:45.980 크로마에 불러오기를 주석으로 달아 놓은 게 보이시죠 커닝이 안 돼요 01:45.980 --> 01:52.160 크로마는 여기 포함되지 않습니다 대신 페이스 페이스북 인공지능 유사성 검색을 불러왔죠 01:52.190 --> 01:58.760 두 가지 변형이 있다는 걸 알아두세요 CPU 변형과 GPU 변형이죠 Pip가 설치된 01:58.760 --> 01:59.930 것에 따라서요 01:59.930 --> 02:04.490 이 환경에선 Pip가 CPU 변종을 설치했지만 GPU에서 02:04.490 --> 02:11.750 실행되는 고성능 프로젝트를 위해서는 엄청난 속도로 실행할 수 있습니다 바이스를 불러왔는데 에러가 02:11.750 --> 02:13.880 없어요, 훌륭하죠 02:14.150 --> 02:15.650 몇 가지 준비해 주세요 02:15.650 --> 02:17.300 모두 같은 코드예요 02:17.300 --> 02:19.220 전처럼 전부 실어요 02:19.220 --> 02:25.970 get 123개만 있으면 렌 덩어리로 바꿀 수 있어요 02:25.970 --> 02:28.310 자, 123개가 나왔네요 02:28.340 --> 02:29.570 네, 맞아요 02:29.600 --> 02:31.700 메타데이터가 맞는지 확인하죠 02:31.700 --> 02:33.590 네 가지 종류가 있어요 02:33.590 --> 02:35.840 지금까지는 달라진 게 없어요 02:35.840 --> 02:36.980 다 똑같아요 02:36.980 --> 02:38.000 하지만 이걸 보세요 02:38.000 --> 02:40.550 한 줄이 교묘하게 바뀌었어요 02:40.580 --> 02:44.060 그렇게 주의를 끌 필요는 없었어요 02:44.060 --> 02:45.860 이미 눈치챈 것 같은데요 02:45.860 --> 02:49.850 벡터 스토어는 크로마.문서로부터의 크로마.이죠 02:49.880 --> 02:53.720 덩크 삽입과 지속 디렉터리도 통과시켰죠 02:53.720 --> 02:58.580 이제 같은 구성체에서 bice.를 입력해요 02:58.610 --> 03:00.380 덩어리도 나눠줘요 03:00.380 --> 03:01.970 삽입구도 통과시키죠 03:01.970 --> 03:06.320 디렉터리에는 전달되지 않습니다 바이스가 디스크에 남지 않기 때문이죠 03:06.620 --> 03:09.980 여기 이 두 선도 달라요 03:09.980 --> 03:14.750 데이터 저장소에 질문을 하는 낮은 레벨의 방법은 달라요 03:14.750 --> 03:20.300 Feist를 사용할 경우 이게 있으면 유용합니다 벡터의 수나 차원값 03:20.300 --> 03:23.600 같은 것에 대해 쿼리를 할 수 있으니까요 03:23.630 --> 03:27.530 채도로 할 때 몇 개의 차원이 있었는지 기억하실지 모르겠네요 03:27.650 --> 03:32.630 하지만 여기 나오는 차원의 개수는 같아요 03:32.630 --> 03:36.590 같은 오픈AI 엠딩을 벡터라이즈로 사용하고 있어요 03:36.590 --> 03:40.550 벡터를 생성하기 위해 동일한 LLM을 사용하고 있죠 03:40.550 --> 03:45.620 바뀐 건 벡터들을 저장하는 방법이에요 크로마가 아니라 Feis에요 03:46.130 --> 03:50.540 123마리의 벡터가 한 덩어리당 한 마리씩 있는 건 당연해요 03:50.540 --> 03:54.470 오픈라이에서 온 차원들이 있어요 03:55.190 --> 04:01.370 또 바뀐 건 작업 전 섹션이 4일째에 달라졌다는 거예요 04:01.400 --> 04:04.010 4일째에 다시 알려드릴게요 사전 작업이죠 04:04.010 --> 04:05.660 가서 한번 보죠 04:06.080 --> 04:07.850 네, 네 04:08.450 --> 04:14.270 pre-work는 더 간단해 보입니다. 크로마에서 벡터, 문서, doc 타입을 04:14.300 --> 04:15.890 가져오는 것이죠. 04:15.890 --> 04:19.970 이 데이터를 get을 위해 채도 쿼리를 하는 방법도 볼 수 있죠 04:20.170 --> 04:22.810 풍기단속반에서 일할 때도 이렇게 했어요 04:22.840 --> 04:25.840 더 빡빡한 방법이 있을 수도 있지만 이 정도면 간단해 보이네요 04:25.840 --> 04:31.810 문서, 문서 타입, 색깔 등 같은 벡터를 수집하고 예상되는 색상에 매핑합니다. 04:31.990 --> 04:38.410 다이어그램과 같은 방식으로 벡터를 시각화할 수 있습니다. 2D에서 했던 04:38.410 --> 04:40.480 것처럼요. 04:40.600 --> 04:44.290 이 코드는 한 가지만 빼고 동일해요 04:44.320 --> 04:45.670 찾을 수 있나 보세요 04:45.670 --> 04:47.290 그게 유일한 변화죠 04:47.290 --> 04:52.570 제목을 크로마에서바이스로 바꿨습니다 하지만 그 외 코드는 같아요 04:52.750 --> 04:55.390 데이터 저장소를 시각화할 거예요 04:55.390 --> 05:00.250 여기 벡터가 있습니다 악행에서 묘사되는 모습이죠 05:00.250 --> 05:04.660 물론 예상하셨겠지만 벡터화 접근법은 같아요 05:04.660 --> 05:06.430 그래서 비슷해 보이죠 05:06.430 --> 05:11.020 벡터 데이터 저장소로 다른 기본 기술을 사용할 뿐이죠 05:11.260 --> 05:13.960 물론 3D로 표현할 수 있죠 05:13.990 --> 05:21.190 지금 바이스에서 3D 표현을 보고 있는데 아주 보기 좋네요 이번엔 05:21.190 --> 05:24.370 아주 잘 분리됐어요 05:24.400 --> 05:25.060 됐어요 05:25.090 --> 05:26.560 온종일 볼 수도 있겠어요 05:27.160 --> 05:28.510 Get it, get it, get it. 그런 느낌이죠 05:28.510 --> 05:31.930 그걸 한데 모으는 코드는 동일하고요 05:31.930 --> 05:33.310 하나도 안 바꿨어요 05:33.340 --> 05:38.020 레트리버로 저장된 벡터는 채도로 호출되거나 얼굴로 호출될 수 있어요 05:38.020 --> 05:39.190 그게 그거죠 05:39.190 --> 05:39.940 자, 됐어요 05:39.970 --> 05:40.750 우리가 운영해요 05:40.780 --> 05:41.740 오류는 없어요 05:41.740 --> 05:42.370 괜찮아요 05:42.370 --> 05:45.550 바로 그라디오 얘기를 하죠 05:45.820 --> 05:49.180 자, 시작할게요 05:49.210 --> 05:51.820 이게 그라디오 인터페이스예요 05:52.150 --> 05:58.690 지난번에 보여드리려고 했던 것 중 하나가 채도 검사에서도 같은 05:58.690 --> 06:04.600 효과를 볼 수 있어요 질문을 받을 수 있는데 에이버리가 전에 06:04.600 --> 06:07.060 뭘 했는지 기억하시죠 06:07.060 --> 06:11.710 올바른 컨텍스트를 검색할 만큼 교활합니다 랭커스터라고 06:11.710 --> 06:17.500 하지 않고 소문자 a로 썼는데도요 더 나아가서 이렇게 말할 수도 있죠 06:17.500 --> 06:21.370 에이버리 이름도 그렇게 틀리게 쓸 수 있어요 06:21.400 --> 06:24.400 에이버리는 뭘 했죠? 06:25.870 --> 06:27.670 네 06:27.670 --> 06:32.920 이 코드를 그대로 실행해 뭐가 나왔는지 보죠 06:33.130 --> 06:40.390 에이버리 랭커스터에 대해 정확히 식별했습니다 그녀의 인사 기록을 찾아봤고 이노베이트 06:40.390 --> 06:45.580 보험 솔루션에서 일했다는 걸 다시 정확히 식별했어요 06:45.670 --> 06:48.760 들어가서 빨리 확인해 보죠 06:48.760 --> 06:51.700 이미 정해졌으니까 직원들 서류로 가야죠 06:51.700 --> 06:53.500 에이버리 랭커스터를 찾았어요 06:53.500 --> 06:54.580 여기 있네요 06:54.580 --> 06:56.560 인사 기록이에요 06:56.560 --> 06:57.700 어떻게 했는지 보죠 06:57.700 --> 07:03.310 이노베이트 보험 솔루션에서 일하긴 했죠 인큐어 엘름 창립 전에요 07:03.550 --> 07:06.010 이게 발명품이 아니라 다행이네요 07:06.340 --> 07:16.270 그러니까 요점은 이겁니다 이걸 보면 텍스트 매칭만 한 게 아니란 걸 알 수 07:16.270 --> 07:17.530 있어요 07:17.530 --> 07:23.230 심지어 잘못된 케이스로 비난받지도 않았어요 소문자나 대문자로요 get it get it 07:23.230 --> 07:30.160 철자가 틀렸다는 걸 밝혀냈어요 Y로 시작하는 랭커스터와 같은 07:30.190 --> 07:31.870 의미라는 걸요 07:31.870 --> 07:39.220 상식적으로 충분히 우리가 추구하는 게 그거라는 걸 알 수 있죠 07:39.220 --> 07:44.890 왜냐하면 이것을 벡터로 바꿀 때 벡터로 놓았기 때문입니다. 벡터 데이터 07:44.890 --> 07:51.640 스토어에서 그것과 가까운 벡터를 보면 에이버리 랭커스터의 HR 기록이 데이터 스토어에서 07:51.820 --> 07:56.050 그것과 비슷한 것을 발견하게 되죠. 07:56.050 --> 08:00.430 철자를 틀려도 잘 된다는 게 정말 놀라워요 08:00.430 --> 08:06.580 벡터 찾기 접근법이 첫 번째 시간에 사용한 브루트 포스 기술보다 얼마나 나은지 08:06.580 --> 08:11.080 보여주는 명백한 예입니다 이 테스트에서는 가망이 전혀 08:11.080 --> 08:12.130 없었겠죠 08:12.190 --> 08:17.890 채도를 사용하면 같은 결과가 나온다는 걸 증명하게 해 드릴게요 둘 다 해 볼 08:17.890 --> 08:19.720 수 있지만 두고 보세요 08:19.720 --> 08:23.350 채도와 바이스가 잘 맞았으면 좋겠네요 08:23.440 --> 08:26.020 하지만 가장 중요한 건 그걸 봤다는 거예요 08:26.050 --> 08:33.220 전에 설명드린 대로 랭은 아주 간단하게 뒤에서 다른 벡터 데이터 저장소를 변경하게 합니다 08:33.220 --> 08:37.510 래그 워크플로우에도 같은 배관을 사용하고요 08:38.080 --> 08:39.760 슬라이드로 돌아가죠