WEBVTT

00:00:00.000 --> 00:00:07.540
상상해보세요. 회사 앱에서 작업 중입니다. 인사 포털일 수도 있고 고객 지원 데이터베이스나 지켜야 할 사내 정책이 담긴 위키일 수도 있죠.

00:00:07.720 --> 00:00:15.640
검색창에 질문을 입력합니다. 고객 적대 식사비용 보고서는 어떻게 작성하나요? 같은 질문 말이죠. 엔터를 눌렀을 때 무엇이 나오나요? 아무것도 없습니다.

00:00:15.960 --> 00:00:23.740
아니면 더 나쁘게도 입력한 단어와 대충 일치하는 3년 전이 무작위 pdf 목록만 나옵니다. 우리는 매일 검색을 사용합니다. 그런데 대부분의 경우 검색은 엉망이죠.

00:00:23.740 --> 00:00:32.960
하지만 사실 꼭 그럴 필요는 없습니다. 앱이 여러분의 질문을 실제로 이해할 수 있다면 어떨까요? 정확한 단어를 사용하지 않아도 구글처럼 정답을 찾아낼 수 있다면 어떨까요?

00:00:33.180 --> 00:00:40.580
오늘 우리는 에이저 AI 서치를 다룰 것입니다. 이것이 정확히 무엇인지, 내부적으로 어떻게 작동하는지, 그리고 왜 현대 앱들이 검색 엔진을 기반으로 구축되는지 알아봅니다.

00:00:40.740 --> 00:00:48.100
커피 한 잔 들고 바로 시작해보죠. 검색이 고장난 이유. 검색이 왜 주로 실패하는지 이해하려면 대부분의 앱이 실제로 검색을 수행하는 방식을 살펴봐야 합니다.

00:00:48.100 --> 00:00:56.920
전통적인 방식을 키워드 검색 또는 어휘 검색이라고 합니다. 상자에 노트북이라는 단어를 입력하면 시스템이 해당 단어가 정확히 포함된 모든 문서를 찾아냅니다.

00:00:57.160 --> 00:01:03.620
내부적으로는 많은 시스템이 bm25라는 알고리즘을 사용합니다. 복잡하지는 않지만 나름대로 영리한 방식이죠.

00:01:03.820 --> 00:01:12.600
bm25는 몇 가지 요소를 기준으로 결과 순위를 매깁니다. 검색어가 문서에 얼마나 자주 등장하는지, 문서 길이는 어느 정도인지, 전체 데이터 세트에서 검색어가 얼마나 드문지 등입니다.

00:01:12.600 --> 00:01:18.000
이러한 요소들을 바탕으로 어떤 문서가 가장 관련성이 높은지 파악하는 매우 정교한 단어 개수기라고 생각하면 됩니다.

00:01:18.200 --> 00:01:24.060
여기서 문제가 발생합니다. 인간의 언어는 복잡하니까요. 사람들은 문서에 사용된 것과 똑같은 단어로 질문하지 않습니다.

00:01:24.240 --> 00:01:28.320
구체적인 예를 들어보겠습니다. 한 사용자가 지원 포털에 이렇게 입력합니다.

00:01:28.560 --> 00:01:38.200
화상 통화 중에 노트북이 계속 멈춰요. 키워드 검색은 노트북, 계속, 멈춰요, 동안, 화상, 통화라는 단어가 포함된 문서를 충실히 찾을 것입니다.

00:01:38.200 --> 00:01:43.180
하지만 그 주제에 관한 최고의 기사 제목이 팀즈 회의 중 시스템 멈춤 문제 해결이라면 어떨까요?

00:01:43.340 --> 00:01:46.020
또는 도킹된 노트북의 cpu 스로틀링 관리라면 어떨까요?

00:01:46.180 --> 00:01:48.180
키워드 검색은 그런 것들을 완전히 놓치고 맙니다.

00:01:48.340 --> 00:01:50.440
왜일까요? 단어가 일치하지 않기 때문입니다.

00:01:50.600 --> 00:01:53.520
핵심 문제는 이것입니다. 키워드 검색은 철자를 이해합니다.

00:01:53.780 --> 00:01:56.340
문자 패턴은 이해하지만 의미는 이해하지 못합니다.

00:01:56.560 --> 00:01:59.500
글자는 맞지만 내용은 틀린 검색 결과만 얻게 되는 것이죠.

00:01:59.680 --> 00:02:03.460
그렇다면 단어의 정확한 일치가 이렇게 많은 공백을 남긴다면 대안은 무엇일까요?

00:02:03.460 --> 00:02:08.280
새로운 방식, 벡터 검색. 자, 벡터 검색은 완전히 다른 방식의 접근법입니다.

00:02:08.480 --> 00:02:11.140
정확한 단어를 일치시키는 대신 의미를 일치시킵니다.

00:02:11.280 --> 00:02:13.480
추상적으로 들릴 수 있으니 하나씩 뜯어보죠.

00:02:13.620 --> 00:02:18.320
가장 간단히 정의하자면 벡터란 컴퓨터가 처리할 수 있는 형태의 숫자 목록일 뿐입니다.

00:02:18.520 --> 00:02:20.860
그게 전부입니다. 그냥 숫자들의 나열이죠.

00:02:21.080 --> 00:02:24.060
인베딩은 텍스트의 의미를 담아내는 특별한 형태의 벡터입니다.

00:02:24.320 --> 00:02:28.360
문장이나 문단, 심지어 문서 전체를 긴 숫자 목록으로 변환하는 것이죠.

00:02:28.580 --> 00:02:31.340
컴퓨터는 단어를 이해하지 못하지만 숫자는 이해할 수 있습니다.

00:02:31.340 --> 00:02:35.000
이해를 돕기 위한 비유가 있습니다. 벡터를 지도위의 좌표라고 생각해보세요.

00:02:35.260 --> 00:02:37.400
지도에서는 비슷한 장소들이 서로 가까이 위치하죠.

00:02:37.560 --> 00:02:40.500
벡터 공간에서도 비슷한 개념들은 서로 가까이 위치하게 됩니다.

00:02:40.740 --> 00:02:44.480
왕과 여왕위 벡터는 서로 관련 있는 개념이기에 가까이 있습니다.

00:02:44.860 --> 00:02:48.000
반면, 왕과 사과위 벡터는 멀리 떨어져 있죠.

00:02:48.260 --> 00:02:51.060
컴퓨터는 인간의 관점에서 왕이 무엇인지 모르지만,

00:02:51.620 --> 00:02:54.740
다른 모든 단어 나 문서와의 좌표 거리를 측정할 수는 있습니다.

00:02:55.060 --> 00:02:57.280
아이디어를 위한 GPS를 가진 것과 같습니다.

00:02:57.660 --> 00:03:00.920
시스템은 숫자만 보고도 개념들이 얼마나 떨어져 있는지 알 수 있습니다.

00:03:00.920 --> 00:03:04.900
벡터를 사용해 검색하면 시스템은 질문을 인베딩으로 변환합니다.

00:03:05.060 --> 00:03:08.180
그런 다음 자신의 인베딩과 가장 가까운 문서를 찾아냅니다.

00:03:08.380 --> 00:03:12.340
단어뿐만 아니라 의미를 공유하는 문맥상 유사한 것들을 찾아내는 것이죠.

00:03:12.540 --> 00:03:15.680
노트북이 멈췄을 때 해결 방법을 찾는 문서를 검색한다고 상상해보세요.

00:03:15.900 --> 00:03:19.420
키워드 검색이라면 멈춤이나 정지 라는 단어를 정확히 입력해야 합니다.

00:03:19.640 --> 00:03:23.980
하지만 벡터 검색을 쓰면 컴퓨터가 계속 굳어버려 라고 입력해도 올바른 문서를 찾아줍니다.

00:03:24.200 --> 00:03:26.100
이것이 바로 의미를 파악하는 힘입니다.

00:03:26.100 --> 00:03:28.000
다시 검색 예시로 돌아가 보죠.

00:03:28.180 --> 00:03:31.020
사용자가 노트북이 자꾸 멈춰요 라고 입력합니다.

00:03:31.180 --> 00:03:34.260
벡터 검색을 사용하면 질문에 포함되지 않은 단어라도

00:03:34.260 --> 00:03:37.540
팀즈 회의 중 시스템 중단에 관한 문서를 찾아낼 수 있습니다.

00:03:37.780 --> 00:03:38.300
왜일까요?

00:03:38.500 --> 00:03:42.840
벡터 공간에서 시스템 중단의 의미가 컴퓨터 멈춤과 매우 가깝기 때문입니다.

00:03:43.040 --> 00:03:45.420
이 개념들은 지도위에서 서로 가까이 위치합니다.

00:03:45.700 --> 00:03:48.800
시스템은 정확한 단어에는 관심이 없고 사용자의 의도에 집중합니다.

00:03:49.020 --> 00:03:50.460
이것이 바로 획기적인 변화입니다.

00:03:50.700 --> 00:03:53.200
컴퓨터가 철자가 아닌 의도를 이해하기 시작한 것이죠.

00:03:53.200 --> 00:03:55.980
키워드 검색이 전혀 찾지 못하는 답변들을 찾아냅니다.

00:03:56.160 --> 00:03:58.020
하지만 벡터 검색에도 약점은 있습니다.

00:03:58.340 --> 00:04:01.360
매우 중요한 정확한 일치 단어를 놓칠 수도 있다는 점입니다.

00:04:01.600 --> 00:04:06.240
기술자가 에러코드 x80070570과 같은 특정 코드를 검색할 경우

00:04:06.240 --> 00:04:09.760
벡터 검색은 해당 코드에 대한 정확한 분석 문서 대신

00:04:09.760 --> 00:04:13.740
디스크 오류나 파일 시스템 손상에 관한 문서를 우선순위에 둘 수 있습니다.

00:04:14.040 --> 00:04:15.960
정확성 대신 이해도를 선택하는 셈이죠.

00:04:16.200 --> 00:04:17.780
자, 우리에게는 두 가지 방법이 있습니다.

00:04:18.000 --> 00:04:19.580
키워드 검색은 정확성에 탁월합니다.

00:04:19.800 --> 00:04:22.500
정확한 용어, 제품 아이디, 계약번호를 찾는데 아주 유용하죠.

00:04:22.500 --> 00:04:24.340
벡터 검색은 의미 파악에 뛰어납니다.

00:04:24.520 --> 00:04:26.760
올바른 단어를 사용하지 않아도 정답을 찾아냅니다.

00:04:26.960 --> 00:04:28.540
각각의 방식에는 사각지대가 있습니다.

00:04:28.840 --> 00:04:30.400
그러면 당연히 이런 의문이 생깁니다.

00:04:30.580 --> 00:04:33.280
두 가지 방식을 결합하여 두 장점을 모두 취할 수는 없을까요?

00:04:33.460 --> 00:04:34.720
바로 하이브리드 혁신입니다.

00:04:34.960 --> 00:04:37.360
하이브리드 검색은 두 방식의 장점을 모두 갖췄습니다.

00:04:37.560 --> 00:04:39.960
키워드 검색과 벡터 검색을 동시에 실행한 다음

00:04:39.960 --> 00:04:42.100
결과를 하나의 순위 목록으로 통합합니다.

00:04:42.320 --> 00:04:43.660
한 가지 방식을 선택하는 대신

00:04:43.660 --> 00:04:46.960
시스템은 상호순위 융합, RRF, 이라는 방법을 사용합니다.

00:04:47.160 --> 00:04:48.380
작동 원리는 다음과 같습니다.

00:04:48.380 --> 00:04:52.700
RRF는 각 문서가 키워드 결과에서 몇 위인지, 벡터 결과에서 몇 위인지 확인합니다.

00:04:52.880 --> 00:04:54.380
그런 다음 통합 점수를 산출합니다.

00:04:54.560 --> 00:04:57.040
두 결과 모두에서 좋은 평가를 받은 문서는 더 높은 순위를 얻게 됩니다.

00:04:57.260 --> 00:04:59.260
마치 두 전문가의 의견을 종합하는 것과 같습니다.

00:04:59.560 --> 00:05:02.400
최종 답변은 어느 한쪽만 사용했을 때고 다 훨씬 신뢰할 수 있습니다.

00:05:02.620 --> 00:05:06.260
키워드 검색과 벡터 검색은 근본적으로 다른 강점을 가지고 있기 때문에 중요합니다.

00:05:06.440 --> 00:05:08.740
키워드 검색은 정확한 일치 항목을 찾는데 탁월합니다.

00:05:08.960 --> 00:05:12.680
제품 아이디, 계약 번호, 특정 이름, 에러코드 등을 찾을 때 필수적이죠.

00:05:12.680 --> 00:05:14.360
정확하고 예측 가능합니다.

00:05:14.560 --> 00:05:16.720
벡터 검색은 의미적 유사성에 뛰어나며,

00:05:17.160 --> 00:05:20.660
정확한 단어가 없더라도 질의어와 의미가 통하는 문서를 찾아냅니다.

00:05:20.880 --> 00:05:22.820
이 둘은 서로의 사각지대를 보완합니다.

00:05:23.100 --> 00:05:26.520
시스템은 단 한 번의 검색으로 정확한 일치와 개념적 일치를 모두 잡아냅니다.

00:05:26.740 --> 00:05:27.880
그것이 진정한 힘입니다.

00:05:28.120 --> 00:05:30.080
이는 단지 이론적인 이야기가 아닙니다.

00:05:30.280 --> 00:05:32.240
엔터프라이즈 하이브리드 검색 연구에 따르면,

00:05:32.440 --> 00:05:35.540
데이터셋에 따라 70에서 80%의 검색 정확도를 보여줍니다.

00:05:35.740 --> 00:05:37.580
이는 벡터 검색만 단독으로 사용했을 때고,

00:05:37.680 --> 00:05:39.900
다 약 15에서 20%포인트 더 높은 수치입니다.

00:05:39.900 --> 00:05:42.960
그 차이는 상당하며 실제 비즈니스 성과로 나타납니다.

00:05:43.140 --> 00:05:45.080
회계 플랫폼인 제로를 예로 들어보겠습니다.

00:05:45.460 --> 00:05:49.620
그들은 코베오라는 기업을 통해 고객 지원 서비스의 하이브리드 검색을 구현했습니다.

00:05:49.980 --> 00:05:53.240
3개월 만에 셀프 서비스 해결률이 20% 증가했습니다.

00:05:53.580 --> 00:05:57.660
고객들은 지원팀에 문외하지 않고도 스스로 답을 찾는 경우가 더 많아졌습니다.

00:05:57.880 --> 00:06:02.880
같은 사례 연구에 다른 고객사들은 지원 사례 해결 시간을 최대 40%까지 단축했습니다.

00:06:03.220 --> 00:06:05.580
즉, 상담원은 올바른 정보를 더 빠르게 찾고,

00:06:05.740 --> 00:06:08.540
고객은 더 빨리 답변을 얻으며 지원 비용은 절감된 것입니다.

00:06:08.540 --> 00:06:12.380
이것은 단순히 좋은 기능을 넘어 수익에 측정 가능한 영향을 미치는 요소입니다.

00:06:12.540 --> 00:06:13.460
이것이 핵심입니다.

00:06:13.660 --> 00:06:16.320
하이브리드 검색은 단순히 괜찮은 업그레이드나 기능 목록의 항목 하나가 아니라

00:06:16.320 --> 00:06:17.800
측정 가능한 수준으로 더 뛰어납니다.

00:06:17.960 --> 00:06:21.260
더 나은 정밀도, 더 나은 재현률, 그리고 더 나은 사용자 경험을 제공합니다.

00:06:21.440 --> 00:06:26.260
이러한 접근방식의 결합이야말로 에이저 AI 서치가 최신 애플리케이션에서 강력한 힘을 발휘하는 이유입니다.

00:06:26.420 --> 00:06:30.100
하지만 이 조합이 열어주는 또 다른 기술이 있는데 현재 많은 주목을 받고 있습니다.

00:06:30.380 --> 00:06:30.960
바로 RAG.

00:06:31.200 --> 00:06:32.620
RAG 연결이라 불리는 기술입니다.

00:06:32.800 --> 00:06:34.140
그럼 RAG에 대해 이야기해보겠습니다.

00:06:34.140 --> 00:06:37.260
RAG는 검색 증강 생성, 리트리블 아규먼티드 제너레이션, 이 약자입니다.

00:06:37.420 --> 00:06:39.720
용어가 조금 어렵게 들릴 수 있지만 가장 간단하게 정의해보겠습니다.

00:06:40.000 --> 00:06:43.840
이는 AI 어시스턴트가 학습되지 않은 정보에 접근할 수 있게 해주는 프레임워크입니다.

00:06:44.040 --> 00:06:48.500
GPT와 같은 거대 언어 모델은 역사, 과학, 코딩에 대해선 많이 알지만

00:06:48.500 --> 00:06:54.640
여러분 회사의 내부 문서, 정책, 고객 이력, 팀이 따르는 구체적인 절차는 알지 못합니다.

00:06:54.860 --> 00:06:58.480
대부분의 사람들은 내부 지식을 모델 자체에 전부 넣으면 된다고 생각합니다.

00:06:58.720 --> 00:07:00.120
하지만 그건 효과적이지 않습니다.

00:07:00.320 --> 00:07:02.200
비용이 많이 들고 업데이트하기도 어렵기 때문입니다.

00:07:02.200 --> 00:07:04.100
RAG는 이를 영리하게 해결합니다.

00:07:04.260 --> 00:07:09.860
모든 것을 모델에 억지로 넣는 대신 누군가 질문하는 순간 지식 베이스에서 관련 정보를 검색하는 방식입니다.

00:07:10.020 --> 00:07:12.320
사용자의 질문을 받아 내부 데이터를 검색하고

00:07:12.320 --> 00:07:16.800
가장 관련성 높은 문서를 찾아 원본 질문과 함께 LLM의 맥락을 제공합니다.

00:07:17.000 --> 00:07:19.740
그러면 LLM은 여러분의 데이터에 기반하여 답변을 생성합니다.

00:07:19.960 --> 00:07:21.400
그것이 바로 마법 같은 부분이죠.

00:07:21.600 --> 00:07:25.020
에이저 AI의 서치는 바로 이 방정식에서 검색에 해당하는 절반의 역할을 담당합니다.

00:07:25.220 --> 00:07:28.580
LLM이 정확하게 답변할 수 있도록 올바른 문서를 찾아주는 엔진입니다.

00:07:28.580 --> 00:07:33.040
판단한 검색 계층 없이는 RH 시스템도 찾아낸 문서의 수준만큼만 기능할 수 있습니다.

00:07:33.220 --> 00:07:35.640
이 지점에서 하이브리드 검색이 진가를 발휘합니다.

00:07:35.840 --> 00:07:37.580
RH 커리는 종종 자연어 질문 형태인데

00:07:37.580 --> 00:07:41.140
답변은 완전히 다른 용어를 사용하는 문서에 포함되어 있는 경우가 많기 때문입니다.

00:07:41.280 --> 00:07:43.940
그 차이를 확실히 보여주는 몇 가지 수치를 말씀드리겠습니다.

00:07:44.220 --> 00:07:46.460
기업용 애플리케이션 검색에 대한 한 연구에 따르면

00:07:46.460 --> 00:07:49.880
하이브리드 RH 프레임워크는 키워드 검색만 사용했을 때고

00:07:49.880 --> 00:07:52.740
다탑K 검색 정확도가 18에서 25배 향상되었습니다.

00:07:53.000 --> 00:07:55.900
워크플로우 작업 완료 정확도는 21배 향상되었습니다.

00:07:55.900 --> 00:07:59.220
즉, 하이브리드 검색을 사용하는 RH 시스템의 지원을 받을 때

00:07:59.220 --> 00:08:02.860
사용자가 복잡한 작업을 성공적으로 완료할 확률이 훨씬 높았다는 뜻입니다.

00:08:03.020 --> 00:08:05.060
전반적으로 적절히 구현된 RH 시스템은

00:08:05.060 --> 00:08:07.780
검색 정확도를 평균 85% 향상시킬 수 있으며

00:08:07.780 --> 00:08:10.980
일부 전문 분야에서는 99% 정확도에 근접하기도 합니다.

00:08:11.120 --> 00:08:12.640
또한 LLM 이 자체적 인추칙이 아닌

00:08:12.640 --> 00:08:14.960
검색된 맥락을 기반으로 답변을 생성하기 때문에

00:08:14.960 --> 00:08:19.020
RH 시스템은 환각, 할로시네이션, 응답을 약 40% 줄여주었습니다.

00:08:19.240 --> 00:08:21.700
이것이 바로 에이저 AI 서치가 AI 에이전트와

00:08:21.700 --> 00:08:23.300
코파일럿 구축의 핵심인 이유입니다.

00:08:23.300 --> 00:08:26.780
에이저 AI 서치는 비즈니스 환경에서 LLM을 신뢰할 수 있게 만드는

00:08:26.780 --> 00:08:28.520
사실 기반의 검색 기능을 제공합니다.

00:08:28.660 --> 00:08:31.900
정확하게 질문에 답하고 출처를 인용해야 하는 어시스턴트를 구축한다면

00:08:31.900 --> 00:08:35.440
하이브리드 검색과 RH가 가장 먼저 고려해야 할 아키텍처입니다.

00:08:35.640 --> 00:08:38.580
즉, 하이브리드 검색과 RH는 강력한 조합입니다.

00:08:38.800 --> 00:08:40.740
하지만 실제로 이는 어떤 모습일까요?

00:08:41.020 --> 00:08:42.500
실질적인 영향력 말이죠.

00:08:42.700 --> 00:08:44.700
그렇다면 실제로는 어디에서 나타날까요?

00:08:44.900 --> 00:08:46.040
몇 가지 예를 들어보겠습니다.

00:08:46.480 --> 00:08:48.600
전자상거래가 아마 가장 익숙한 사례일 겁니다.

00:08:48.900 --> 00:08:51.320
고객이 검색창에 편한 러닝화를 입력합니다.

00:08:51.320 --> 00:08:53.280
마케팅 팀에서 다른 용어를 사용했다면

00:08:53.280 --> 00:08:56.280
제품 목록에는 쿠션감 있는 운동화라고 적혀있을 수 있습니다.

00:08:56.460 --> 00:08:59.580
키워드 검색만으로는 이런 경우 일치하는 항목을 아예 찾지 못할 것입니다.

00:08:59.780 --> 00:09:02.140
에이저 AI 서치를 사용하면 시스템은 이 문맥에서

00:09:02.140 --> 00:09:05.140
편한과 쿠션감 있는 이 거의 같은 의미라는 것을 이해합니다.

00:09:05.340 --> 00:09:08.100
단어가 정확히 일치하지 않아도 올바른 제품을 찾아 냅니다.

00:09:08.300 --> 00:09:11.620
결과적으로 고객은 좌절하며 사이트를 떠나는 대신 원하는 상품을 찾게 됩니다.

00:09:11.860 --> 00:09:13.860
고객 지원 포털도 같은 방식으로 작동합니다.

00:09:14.060 --> 00:09:17.560
고객이 구독을 어떻게 취소하나요? 라고 입력한다고 가정해봅시다.

00:09:17.780 --> 00:09:20.860
관련 정책의 제목은 서비스 계약 해지일 수 있습니다.

00:09:20.860 --> 00:09:24.220
하이브리드 검색은 법률 용어에 대한 키워드 매칭을 통해

00:09:24.220 --> 00:09:25.940
해당 문서를 정확히 찾아내고

00:09:25.940 --> 00:09:31.080
의미론적 유사성을 통해 플랜 조기 종료에 관한 관련 FAQ도 함께 제공합니다.

00:09:31.480 --> 00:09:35.740
고객은 5개의 다른 문서를 뒤질 필요 없이 포괄적인 답변을 얻게 됩니다.

00:09:36.000 --> 00:09:38.160
법률 문서 검색도 또 다른 사례입니다.

00:09:38.400 --> 00:09:42.580
변호사는 정확한 조항번호와 섹션 참조를 통해 계약서를 검색해야 합니다.

00:09:42.800 --> 00:09:44.300
이는 순수한 키워드 영역이지만

00:09:44.300 --> 00:09:48.400
표현이 다르더라도 여러 계약서에서 유사한 문구를 찾아내야 할 때도 있습니다.

00:09:48.400 --> 00:09:51.360
하이브리드 검색은 한 번이 커리로이 두 가지를 모두 처리하며

00:09:51.360 --> 00:09:54.520
규제 산업에서는 결과가 나타난 정확한 근거를 추적할 수 있어야

00:09:54.520 --> 00:09:56.100
컴플라이언스를 준수할 수 있습니다.

00:09:56.320 --> 00:09:58.420
사내 지식 페이스도 큰 혜택을 봅니다.

00:09:58.820 --> 00:10:01.680
직원이 휴가 정책을 검색하면 공식 인사 문서는 물론

00:10:01.680 --> 00:10:04.760
2월 휴가 일수에 관한 법무팀의 관련 이메일과

00:10:04.760 --> 00:10:08.360
사내 인트라넷에 게시된 최근 업데이트까지 모두 확인할 수 있습니다.

00:10:08.640 --> 00:10:12.280
검색 기능이 모든 것이 같은 질문과 연결되어 있음을 이해하는 것입니다.

00:10:12.280 --> 00:10:15.620
제조업은 덜 분명해 보일 수 있지만 매우 강력한 사례입니다.

00:10:15.820 --> 00:10:19.400
기술자가 검색 인터페이스에 모터 과열 해결법을 입력합니다.

00:10:19.660 --> 00:10:23.320
시스템은 장비 매뉴얼의 문제 해결 섹션과 관련 부품이 표시된

00:10:23.320 --> 00:10:25.060
스캔 다이어그램을 반환합니다.

00:10:25.300 --> 00:10:27.040
다이어그램이 이미지임에도 불구하고

00:10:27.040 --> 00:10:29.460
에이저 AI 서치는 텍스트 내용을 추출하고

00:10:29.460 --> 00:10:31.620
인덱싱하여 검색 결과에 표시할 수 있습니다.

00:10:31.880 --> 00:10:34.780
이 모든 사례를 관통하는 공통점은 비정형 데이터입니다.

00:10:35.000 --> 00:10:38.540
pdf, 워드 문서, 이메일 지원 티켓, 스캔된 이미지 등이 있죠.

00:10:38.540 --> 00:10:42.400
기존 데이터베이스 커리와 키워드 검색은 이런 종류의 데이터를 위해 설계된 적이 없습니다.

00:10:42.700 --> 00:10:44.940
에이저 AI 서치는 바로 이런 세상을 위해 구축되었으며

00:10:44.940 --> 00:10:49.080
살펴볼수록 하이브리드 검색은 단순히 좋은 기능을 넘어 필수적이라는 사실이 더욱 명확해집니다.

00:10:49.220 --> 00:10:51.900
이는 현대 애플리케이션 구축 방식의 기초가 되는 요소입니다.

00:10:52.100 --> 00:10:54.060
각 요소들이 어떻게 결합되는지 살펴보겠습니다.

00:10:54.440 --> 00:10:56.600
그렇다면 내부적으로는 어떻게 작동하는 걸까요?

00:10:56.780 --> 00:11:01.860
에이저 AI 서치에는 데이터 원본, 인덱서, 검색 인덱스라는 세 가지 핵심 구성 요소가 있습니다.

00:11:02.140 --> 00:11:04.200
데이터 원본은 정보가 저장되는 곳입니다.

00:11:04.200 --> 00:11:09.460
블랍 스토리지, 에이저 SQL 데이터베이스, 코스모스 DB, 심지어 시어포인트일 수도 있습니다.

00:11:09.620 --> 00:11:11.740
이는 검색이 가능해져야 할 원재료입니다.

00:11:11.920 --> 00:11:14.780
정리되기를 기다리는 문서 덤이라고 생각하시면 됩니다.

00:11:15.120 --> 00:11:18.460
인덱서는 해당 원본에서 데이터를 읽어와 콘텐츠를 추출하고

00:11:18.460 --> 00:11:22.900
구성한 AI 보강을 적용한 뒤 검색 인덱스를 구축하는 파이프라인입니다.

00:11:23.120 --> 00:11:24.900
간단하게 이해하는 방법이 있습니다.

00:11:25.260 --> 00:11:28.320
사서가 책으로 가득 찬 창고에 들어간다고 상상해보세요.

00:11:28.320 --> 00:11:34.380
사서는 모든 책을 읽고 자세히 기록하며 주요 주제와 엔터티를 파악해 카드 목록으로 정리합니다.

00:11:34.540 --> 00:11:36.960
그 읽고 기록하는 과정이 인덱싱 과정입니다.

00:11:37.200 --> 00:11:39.280
검색 인덱스는 바로 그 카드 목록입니다.

00:11:39.520 --> 00:11:40.740
책 그 자체가 아닙니다.

00:11:40.960 --> 00:11:45.660
필요한 정보를 밀리초 단위로 정확하게 찾아낼 수 있도록 최적화된 구조화 시스템입니다.

00:11:45.880 --> 00:11:49.900
커리를 입력할 때 시스템은 원본 문서를 다시 일일이 확인하지 않습니다.

00:11:50.140 --> 00:11:53.640
대신 모든 정보의 위치를 이미 알고 있는 인덱스를 참조합니다.

00:11:53.960 --> 00:11:56.980
이러한 사전 정리 방식을 역색인 인버티드 인덱스 이라고 합니다.

00:11:56.980 --> 00:12:01.800
문서에 포함된 단어 목록을 저장하는 대신 단어별로 해당 단어가 포함된 문서 목록을 저장하는 방식입니다.

00:12:01.940 --> 00:12:04.660
따라서 용어를 검색하면 바로 올바른 위치로 이동하게 됩니다.

00:12:04.900 --> 00:12:06.600
모든 페이지를 넘겨볼 필요가 없습니다.

00:12:06.920 --> 00:12:08.920
그 결과 속도가 엄청나게 향상됩니다.

00:12:09.140 --> 00:12:14.540
데이터가 늘어날수록 시간이 더 걸리는 전체 문서 스캔 대신 즉시 정확한 위치로 이동하기 때문입니다.

00:12:14.760 --> 00:12:19.960
수백만 개의 문서가 있는 경우 이는 몇 초가 걸리는 검색과 밀리초가 걸리는 검색의 차이를 만듭니다.

00:12:20.160 --> 00:12:25.980
이제 에이저 AI 서치가 무엇인지 핵심 구성 요소가 어떻게 결합되는지 그리고 하이브리드 검색이 왜 판도를 바꾸는지 이해하셨을 겁니다.

00:12:25.980 --> 00:12:28.520
이를 활용할 수 있는 몇 가지 사례로 마무리하겠습니다.

00:12:28.840 --> 00:12:30.640
첫째, 데이터를 파악하세요.

00:12:30.880 --> 00:12:38.520
이미 구조화된 데이터, 즉 SQL 위 제품 테이블, 데이터베이스의 고객 기록처럼 깔끔한 행과 연로된 데이터라면 SQL로 직접 커리할 수 있습니다.

00:12:38.740 --> 00:12:41.460
에이저 AI 서치는 비정형 텍스트를 위해 만들어졌습니다.

00:12:41.640 --> 00:12:44.680
PDF, 이메일, 워드 분석, 고객 지원 티켓 등이 이에 해당합니다.

00:12:44.820 --> 00:12:46.900
바로 이런 곳에서 진정한 가치가 발휘됩니다.

00:12:47.080 --> 00:12:53.960
둘째, RAG 애플리케이션이나 AI 어시스턴트를 구축 중이 라면 에이저 AI 서치 위 하이브리드 검색이 필요한 검색 엔진이 될 것입니다.

00:12:53.960 --> 00:12:58.260
정확성을 위한 키워드 일치와 맥락 파악을 위한 의미론적 이해를 모두 제공합니다.

00:12:58.440 --> 00:13:02.980
이 조합은 어느 한쪽 방식보다 더 신뢰할 수 있고 출처 제시가 용이한 답변을 제공합니다.

00:13:03.180 --> 00:13:05.620
셋째, 설정을 너무 복잡하게 만들지 마세요.

00:13:05.840 --> 00:13:07.860
에이저 포털에는 데이터 가져오기 마법사가 있습니다.

00:13:08.100 --> 00:13:11.880
블락 저장소를 연결하고 몇 가지 설정을 구성한 다음, 인덱서가 첫 번째 인덱스를 빌드하도록 하세요.

00:13:12.040 --> 00:13:13.940
한 시간 안에 첫 번째 검색을 실행할 수 있습니다.

00:13:14.200 --> 00:13:16.480
에이저 AI 서치에 대한 쉬운 설명은 여기까지입니다.

00:13:16.680 --> 00:13:20.780
복잡하고 구조화되지 않은 정보를 검색 가능하고 AI가 활용할 수 있는 지식으로 바꿔줍니다.

00:13:20.780 --> 00:13:22.100
함께 해주셔서 감사합니다.

00:13:22.420 --> 00:13:24.400
구독해주시고 다음 에피소드에서 뵙겠습니다.