WEBVTT

00:00:00.000 --> 00:00:02.860
Уявіть собі таке. Ви працюєте у корпоративному додатку.

00:00:03.040 --> 00:00:07.720
Можливо, це HR-портал, база даних клієнтської підтримки чи внутрішньої вікі з усіма правилами, яких ви маєте дотримуватися.

00:00:07.880 --> 00:00:09.740
Ви вводите запитання у рядок пошуку.

00:00:09.900 --> 00:00:12.700
Наприклад, як мені подати звіт про витрати на бізнес вечерю.

00:00:12.960 --> 00:00:15.360
Натискаєте ENTA і що отримуєте? Нічого.

00:00:15.540 --> 00:00:20.060
Або ще гірше, список випадкових PDF-файлів трирічної давнини, які лише приблизно збігаються зі словами, що ви ввели.

00:00:20.060 --> 00:00:23.600
Ми користуємося пошуком щодня. І здебільшого він жахливий.

00:00:23.720 --> 00:00:25.560
Але ось у чому річ так не має бути.

00:00:25.760 --> 00:00:28.560
Що якби ваші додатки могли насправді розуміти, про що ви питаєте?

00:00:28.720 --> 00:00:33.440
Що якби вони могли шукати як Google, знаходячи правильну відповідь, навіть якщо ви не добираєте ідеальних слів?

00:00:33.600 --> 00:00:35.660
Сьогодні ми розглянемо Azure AI Search.

00:00:35.860 --> 00:00:40.720
Що це таке, як воно працює зсередини і чому саме на ньому будуються сучасні пошукові системи?

00:00:40.840 --> 00:00:42.320
Беріть каву і почнемо.

00:00:42.440 --> 00:00:43.740
Чому пошук не працює?

00:00:43.740 --> 00:00:48.140
Щоб зрозуміти, чому пошук часто дає звій, потрібно подивитися, як більшість додатків роблять це насправді.

00:00:48.260 --> 00:00:51.340
Традиційний спосіб називається ключовим або лексичним пошуком.

00:00:51.500 --> 00:00:56.720
Ви вводите слово «ноутбук» у поле, і система знаходить кожен окремий документ, що містить це слово.

00:00:56.980 --> 00:01:01.100
Зсередини багато таких систем використовують алгоритм під назвою BM25.

00:01:01.420 --> 00:01:03.580
Він не складний, але по-своєму хитромудрий.

00:01:03.920 --> 00:01:06.700
BM25 ранжує результати на основі кількох факторів.

00:01:06.700 --> 00:01:12.680
Як часто ваш пошуковий термін зустрічається в документи, яка довжина документа та наскільки рідкісним є термін у всьому наборі даних?

00:01:12.780 --> 00:01:18.140
Уявіть це як дуже складний лічильник слів, який визначає, які документи найбільш релевантні на основі цих факторів.

00:01:18.260 --> 00:01:19.580
І ось тут усе руйнується.

00:01:19.780 --> 00:01:20.980
Людська мова хаотична.

00:01:21.140 --> 00:01:24.160
Люди не ставлять запитання, використовуючи ті самі слова, що містяться в документах.

00:01:24.300 --> 00:01:26.000
Дозвольте навести конкретний приклад.

00:01:26.160 --> 00:01:31.160
Користувач вводить таке в портал підтримки «Мій ноутбук» постійно зависає під час відеодзвінків.

00:01:31.160 --> 00:01:38.360
Ключовий пошук сумлінно шукатиме документи, що містять слова «ноутбук» постійно зависає під час відео та дзвінків.

00:01:38.520 --> 00:01:43.420
Але що, як найкраща стаття на цю тему, має назву «Усунення системних зависень під час нарад у Teams»

00:01:43.420 --> 00:01:46.300
або «Керування тротлінгом процесора на підключених ноутбуках».

00:01:46.300 --> 00:01:48.260
Ключовий пошук повністю пропустить їх.

00:01:48.420 --> 00:01:50.240
Чому? Тому що слова не збігаються.

00:01:50.420 --> 00:01:51.720
Основна проблема ось у чому.

00:01:51.900 --> 00:01:53.540
Ключовий пошук розуміє правопис.

00:01:53.700 --> 00:01:56.400
Він розуміє послідовності символів, але не розуміє значення.

00:01:56.400 --> 00:01:59.780
Ви отримуєте результати, де літери правильні, але зміст часто помилковий.

00:01:59.900 --> 00:02:03.520
Отже, якщо точний збіг слів залишає стільки прогалин, яка є альтернатива.

00:02:03.660 --> 00:02:05.300
Новий шлях – векторний пошук.

00:02:05.460 --> 00:02:08.300
Отже, векторний пошук – це зовсім інший підхід до роботи.

00:02:08.460 --> 00:02:11.060
Замість зіставлення точних слів, він зіставляє значення.

00:02:11.200 --> 00:02:13.420
Це звучить абстрактно, тому давайте розберемося.

00:02:13.620 --> 00:02:18.840
Найпростіше визначення, яке варто знати, вектор – це просто набір чисел, що представляє щось зрозуміле для комп'ютера.

00:02:18.980 --> 00:02:20.620
Це все просто набір чисел.

00:02:20.620 --> 00:02:24.140
Embedding – це особливий тип вектора, який вловлює значення тексту.

00:02:24.280 --> 00:02:28.640
Він бере речення, абзац або цілий документ і перетворює його на довгий список чисел.

00:02:28.760 --> 00:02:31.360
Комп'ютер не розуміє слів, але він розуміє числа.

00:02:31.540 --> 00:02:33.080
Ось аналогія, яка допоможе.

00:02:33.260 --> 00:02:35.140
Уявіть вектори як координати на карті.

00:02:35.300 --> 00:02:37.180
На карті схожі місця розташовані поруч.

00:02:37.320 --> 00:02:40.100
У векторному просторі схожі концепції також опиняються поруч.

00:02:40.280 --> 00:02:44.840
Вектор для короля і вектор для королеви знаходяться близько один до одного, бо вони представляють споріднені поняття.

00:02:44.840 --> 00:02:48.260
Вектор для короля і вектор для яблука знаходяться далеко один від одного.

00:02:48.460 --> 00:02:55.380
Комп'ютер не знає, що означає король у людському розумінні, але може виміряти відстань між його координатами та координатами будь-якого іншого слова чи документа.

00:02:55.540 --> 00:02:57.120
Це як мати GPS для ідей.

00:02:57.320 --> 00:03:01.080
Система знає, наскільки концепції віддалені одна від одної, просто дивлячись на числа.

00:03:01.220 --> 00:03:04.920
Коли ви шукаєте за допомогою векторів, система перетворює ваш запит на Embedding.

00:03:05.100 --> 00:03:08.120
Потім вона знаходить документи, чиї Embeddingи найближчі до вашого.

00:03:08.120 --> 00:03:12.460
Вона знаходить речі, які семантично схожі, які мають спільне значення, а не лише словниковий склад.

00:03:12.640 --> 00:03:15.760
Уявіть, що ви шукаєте документ про усунення несправностей завислого ноутбука.

00:03:15.880 --> 00:03:19.540
При пошуку за ключовими словами вам довелося б ввести «зависення» або «зависну» дослівно.

00:03:19.660 --> 00:03:23.940
Але з векторним пошуком ви можете ввести «мій комп'ютер постійно гальмує» і він знайде потрібний документ.

00:03:23.980 --> 00:03:26.080
У цьому й полягає сила розуміння значення.

00:03:26.320 --> 00:03:28.320
Повернімося до нашого прикладу з пошуком.

00:03:28.500 --> 00:03:30.960
Користувач вводить «мій ноутбук» постійно зависає.

00:03:30.960 --> 00:03:37.740
Завдяки векторному пошуку система може повернути статтю про збої системи під час нарад у Teams, навіть якщо жодне з цих слів не згадується у запиті.

00:03:37.880 --> 00:03:38.180
Чому?

00:03:38.420 --> 00:03:42.820
Тому що значення «збої системи» дуже близьке до «зависення» комп'ютера у векторному просторі.

00:03:42.960 --> 00:03:45.700
Ці концепції знаходяться поруч одна з одною на цій карті.

00:03:45.840 --> 00:03:48.960
В системі байдуже наточні слова їй важливо те, що ви маєте на увазі.

00:03:49.100 --> 00:03:50.380
Це і є справжній прорив.

00:03:50.520 --> 00:03:53.060
Комп'ютери починають розуміти намір, а не лише написання слів.

00:03:53.200 --> 00:03:56.060
Вони знаходять відповіді, які пошук за ключовими словами повністю пропустив би.

00:04:00.960 --> 00:04:05.960
Якщо технічний фахівець шукає конкретний код помилки, як от X8070570,

00:04:06.740 --> 00:04:11.080
векторний пошук може надати пріоритет документам про помилки диска або пошкодження файлової системи,

00:04:11.160 --> 00:04:14.120
замість того, щоб знайти документ, у якому розбирається саме цей код.

00:04:14.280 --> 00:04:16.160
Він жертвує точністю заради розуміння.

00:04:16.320 --> 00:04:17.640
Отже, у нас є два методи.

00:04:17.760 --> 00:04:19.640
Ключовий пошук чудово підходить для точності.

00:04:19.800 --> 00:04:22.400
Він ідеально знаходить терміни, ідентифікатори продуктів, номери контрактів.

00:04:22.520 --> 00:04:24.400
Векторний пошук чудово підходить для розуміння сенсу.

00:04:24.400 --> 00:04:26.920
Він знаходить правильну відповідь, навіть якщо ви не використовуєте правильні слова.

00:04:27.080 --> 00:04:28.580
Кожен із них має свої сліпі зони.

00:04:28.740 --> 00:04:30.520
І це викликає цілком логічне запитання,

00:04:30.700 --> 00:04:33.700
що якби можна було поєднати обидва підходи і отримати переваги кожного з них.

00:04:34.000 --> 00:04:34.760
Гібридний прорив.

00:04:34.960 --> 00:04:37.100
Гібридний пошук – це найкраще з обох світів.

00:04:37.280 --> 00:04:39.720
Він одночасно виконує як ключовий, так і векторний пошук,

00:04:39.820 --> 00:04:42.320
а потім об'єднує результати в єдиний ранжуваний список.

00:04:42.400 --> 00:04:45.140
Замість того, щоб обирати один метод, система використовує підхід,

00:04:45.140 --> 00:04:47.260
що називається взаємним ранжуванням або РАРФ.

00:04:47.380 --> 00:04:48.380
Ось як це працює.

00:04:48.520 --> 00:04:51.360
РАРФ аналізує, яке місце документ займає в результатах ключового пошуку

00:04:51.360 --> 00:04:52.660
та в результатах векторного пошуку.

00:04:52.800 --> 00:04:54.460
Потім він присвоює комбіновану оцінку.

00:04:54.620 --> 00:04:56.980
Якщо документ має високий рейтинг в обох, він отримує підвищення позиції.

00:04:57.120 --> 00:04:59.740
Це схоже на те, якби ви взяли думку двох експертів і вивели середнє значення.

00:04:59.880 --> 00:05:02.420
Кінцева відповідь є надійнішою, ніж будь-яка з них окремо.

00:05:02.420 --> 00:05:06.220
Це важливо, оскільки ключовий і векторний пошук мають принципово різні сильні сторони.

00:05:06.340 --> 00:05:08.780
Ключовий пошук перевершує інших у знаходженні точних збігів.

00:05:08.880 --> 00:05:11.480
Це ваш найкращий інструмент для ідентифікаторів продуктів, номерів контрактів,

00:05:11.560 --> 00:05:12.740
специфічних назв та кодів помилок.

00:05:12.900 --> 00:05:14.320
Він точний і передбачуваний.

00:05:14.500 --> 00:05:16.980
Векторний пошук перевершує інших у семантичній схожості,

00:05:17.100 --> 00:05:20.740
знаходячи документи, що мають спільний зміст із вашим запитом, навіть без точних слів.

00:05:20.880 --> 00:05:23.180
Разом вони перекривають сліпі зони одне одного.

00:05:23.180 --> 00:05:26.680
Система знаходить як точні, так і концептуальні збіги в одному запиті.

00:05:26.820 --> 00:05:28.080
У цьому справжня сила.

00:05:28.260 --> 00:05:29.580
І це не просто теорія.

00:05:29.740 --> 00:05:31.780
Дослідження корпоративного гібридного пошуку показують,

00:05:31.860 --> 00:05:35.700
що він забезпечує точність пошуку на рівні 70-80% залежно від набору даних.

00:05:35.800 --> 00:05:39.940
Це приблизно навіть 15-20% пунктів вище, ніж при використанні лише векторного пошуку.

00:05:40.100 --> 00:05:43.160
Різниця суттєва, і вона відображається в реальних бізнес-результатах.

00:05:43.320 --> 00:05:45.040
Візьмемо бухгалтерську платформу Zero.

00:05:45.040 --> 00:05:49.620
Вони впровадили гібридний пошук у свою службу підтримки клієнтів за допомогою компанії Coveo.

00:05:49.760 --> 00:05:53.540
За три місяці вони побачили збільшення самостійного вирішення проблем на 20%.

00:05:53.540 --> 00:05:57.780
Клієнти частіше знаходили відповіді самостійно, без необхідності звертатися в підтримку.

00:05:57.960 --> 00:06:03.020
Інші клієнти в тому ж дослідженні досягли скорочення часу вирішення запитів у підтримку до 40%.

00:06:03.020 --> 00:06:05.740
Це означає, що агенти швидше знаходили потрібну інформацію,

00:06:05.840 --> 00:06:09.020
клієнти отримували відповіді оперативніше, а витрати на підтримку зменшилися.

00:06:09.020 --> 00:06:12.300
Це не просто приємна функція, це вимірний вплив на прибутковість.

00:06:12.440 --> 00:06:13.480
Це ключовий момент.

00:06:13.660 --> 00:06:17.700
Гібридний пошук – це не просто приємне оновлення чи пункт у списку функцій, він справді кращий.

00:06:17.820 --> 00:06:21.420
Він забезпечує вищу точність, кращу повноту результатів та ефективнішу роботу для користувачів.

00:06:21.600 --> 00:06:26.220
Саме це поєднання підходів робить Azure AI Search таким потужним інструментом для сучасних додатків.

00:06:26.340 --> 00:06:30.400
Але ця комбінація відкриває ще одну технологію, яка зараз привертає багато уваги.

00:06:30.540 --> 00:06:32.780
Вона називається RAD або Зв'язок RAD.

00:06:32.780 --> 00:06:34.240
Отже, поговоримо про RAD.

00:06:34.240 --> 00:06:37.420
RAD розшифровується як «Генерація з доповненням пошуком Retrival Augmented Generation».

00:06:37.420 --> 00:06:39.580
Це складна назва, але ось найпростіше визначення.

00:06:39.720 --> 00:06:43.760
Це інфраструктура, яка надає ще помічникам доступ до інформації, на якій їх не навчали.

00:06:43.940 --> 00:06:48.160
Великі мовні моделі, як-от GPT, багато знають про історію, науку та програмування,

00:06:48.320 --> 00:06:52.200
але вони не знають внутрішніх документів вашої компанії, політик, історії клієнтів

00:06:52.200 --> 00:06:54.840
чи конкретних процедур, яких дотримується ваша команда.

00:06:54.840 --> 00:06:59.120
Більшість людей вважають, що можна просто завантажити всі ці внутрішні знання в саму модель.

00:06:59.120 --> 00:07:01.920
Це не працює. Це дорого і складно оновлювати.

00:07:02.120 --> 00:07:03.920
RAD вирішує це досить розумно.

00:07:04.100 --> 00:07:07.940
Замість того, щоб втискати все в модель, ви отримуєте релевантну інформацію з бази знань

00:07:07.940 --> 00:07:09.700
у момент, коли хтось ставить запитання.

00:07:09.880 --> 00:07:12.520
Ви берете запит користувача, шукаєте у своїх внутрішніх даних,

00:07:12.620 --> 00:07:15.700
знаходите найбільш релевантні документи і передаєте цей контекст у мовну модель

00:07:15.700 --> 00:07:17.140
разом із оригінальним запитанням.

00:07:17.140 --> 00:07:20.260
Потім мовна модель генерує відповідь, що ґрунтується на ваших даних.

00:07:20.320 --> 00:07:21.440
У цьому вся магія.

00:07:21.440 --> 00:07:24.500
Azure AI Search – це пошукова половина цього рівняння.

00:07:24.660 --> 00:07:28.620
Це рушій, який знаходить потрібні документи, щоб мовна модель могла відповісти точно.

00:07:28.840 --> 00:07:31.460
Безнадійного рівня пошуку система RADG настільки ефективна,

00:07:31.540 --> 00:07:33.280
наскільки ефективні знайдені нею документи.

00:07:33.480 --> 00:07:35.240
Саме тут гібридний пошук справді демонструє себе,

00:07:35.340 --> 00:07:37.720
оскільки запити RADG часто є запитаннями природною мовою,

00:07:37.720 --> 00:07:41.020
а відповіді часто містяться в документах, де використовується зовсім інша термінологія.

00:07:41.160 --> 00:07:44.040
Дозвольте навести кілька цифр, які справді показують різницю.

00:07:44.040 --> 00:07:46.320
Дослідження пошуку в корпоративних додатках показало,

00:07:46.440 --> 00:07:51.000
що гібридна інфраструктура RADG покращила точність пошуку TOP-K у 18-25 разів

00:07:51.000 --> 00:07:52.720
порівняно зі звичайним ключовим пошуком.

00:07:52.840 --> 00:07:56.340
Точність виконання завдань у робочих процесах покращилася в 21 раз.

00:07:56.480 --> 00:08:00.060
Це означає, що користувачі значно частіше успішно виконували складні завдання,

00:08:00.060 --> 00:08:02.900
коли їх підтримувала система RADG із гібридним пошуком.

00:08:03.020 --> 00:08:06.440
Загалом, правильно впроваджені системи RADG можуть підвищити точність пошуку

00:08:06.440 --> 00:08:11.000
в середньому на 85%, а в деяких спеціалізованих сферах – до 99%.

00:08:11.000 --> 00:08:14.100
Оскільки мовна модель генерує відповіді на основі отриманого контексту,

00:08:14.160 --> 00:08:17.960
а не власних здогадок, системи RADG продемонстрували скорочення кількості галюцинацій

00:08:17.960 --> 00:08:19.160
приблизно на 40%.

00:08:19.160 --> 00:08:23.380
Ось чому Azure AI Search є центральним елементом для створення щі агентів і копілетів.

00:08:23.540 --> 00:08:25.940
Він забезпечує пошук на основі підтверджених фактів,

00:08:25.940 --> 00:08:28.440
що робить мовні моделі надійними в бізнес-середовищі.

00:08:28.560 --> 00:08:31.480
Якщо ви створюєте помічника, який має точно відповідати на запитання

00:08:31.480 --> 00:08:34.180
та посилатися на джерела, гібридний пошук разом із RADG –

00:08:34.180 --> 00:08:35.580
це архітектура, яка вам потрібна.

00:08:35.700 --> 00:08:38.840
Отже, гібридний пошук і RADG – це потужна комбінація.

00:08:38.960 --> 00:08:40.780
Але як це виглядає на практиці?

00:08:41.460 --> 00:08:42.320
Реальний вплив.

00:08:42.460 --> 00:08:44.520
Тож, де це насправді проявляється в роботі?

00:08:44.680 --> 00:08:46.280
Дозвольте навести кілька прикладів.

00:08:46.420 --> 00:08:48.700
Електронна комерція, мабуть, найвідоміший приклад.

00:08:48.840 --> 00:08:51.560
Клієнт вводить у рядок пошуку зручні кросівки для бігу.

00:08:51.700 --> 00:08:53.140
У картці товару може бути написано

00:08:53.140 --> 00:08:54.680
«Амортизаційне спортивне взуття»,

00:08:54.680 --> 00:08:56.440
бо відділ маркетингу обрав інші слова.

00:08:56.620 --> 00:08:59.460
Пошук лише за ключовими словами взагалі не дав би результату.

00:08:59.620 --> 00:09:01.160
Зежур AI Search система розуміє,

00:09:01.320 --> 00:09:03.520
що зручні та амортизаційні в цьому контексті

00:09:03.520 --> 00:09:05.140
означають приблизно одне й те саме.

00:09:05.280 --> 00:09:08.140
Вона показує потрібний товар, навіть якщо слова не збігаються.

00:09:08.320 --> 00:09:09.780
Це означає, що клієнт знаходить те,

00:09:09.900 --> 00:09:11.940
що шукав, замість того, щоб розчаровано йти з сайту.

00:09:12.080 --> 00:09:14.200
Портали підтримки клієнтів працюють так само.

00:09:14.380 --> 00:09:17.260
Уявіть, що клієнт вводить, як скасувати мою підписку.

00:09:17.260 --> 00:09:19.000
Відповідна політика може називатися

00:09:19.000 --> 00:09:21.220
«Припинення дії договору про надання послуг».

00:09:21.220 --> 00:09:23.180
Гібридний пошук знаходить саме цей документ

00:09:23.180 --> 00:09:25.960
через відповідність ключових слів у юридичній термінології,

00:09:26.060 --> 00:09:28.200
а також пропонує пов'язані питання з FAQ

00:09:28.200 --> 00:09:31.180
про дострокове завершення плану завдяки семантичній схожості.

00:09:31.440 --> 00:09:33.700
Клієнт отримує вичерпну відповідь замість того,

00:09:33.880 --> 00:09:35.740
щоб переглядати п'ять різних статей.

00:09:35.860 --> 00:09:38.320
Пошук юридичних документів – ще один приклад.

00:09:38.500 --> 00:09:41.000
Юристам потрібно шукати контракти за точними номерами,

00:09:41.000 --> 00:09:42.700
пунктів і посиланнями на розділи.

00:09:42.820 --> 00:09:44.140
Це чиста сфера ключових слів,

00:09:49.000 --> 00:09:50.940
Пошук обробляє обидва запити одночасно,

00:09:51.000 --> 00:09:52.720
а в регульованих галузях можливість відстежити,

00:09:52.820 --> 00:09:54.060
чому з'явився саме цей результат,

00:09:54.200 --> 00:09:56.100
є критично важливою для відповідності вимогам.

00:09:56.220 --> 00:09:58.500
Внутрішні бази знань також отримують вигоду.

00:09:58.700 --> 00:10:00.740
Працівник, який шукає правила відпусток,

00:10:00.840 --> 00:10:02.580
отримує офіційний документ HR,

00:10:02.740 --> 00:10:04.300
а також пов'язаний електронний лист

00:10:04.300 --> 00:10:06.360
від юридичного відділу про перенесення днів

00:10:06.360 --> 00:10:08.780
і нещодавнє оновлення на корпоративному порталі.

00:10:08.780 --> 00:10:10.780
Пошук розуміє, що все це пов'язано

00:10:10.780 --> 00:10:12.340
з одним і тим самим питанням.

00:10:12.340 --> 00:10:14.100
Виробництво – менш очевидний,

00:10:14.240 --> 00:10:15.560
але дуже потужний приклад.

00:10:15.720 --> 00:10:17.720
Технік вводить у пошуковий інтерфейс

00:10:17.720 --> 00:10:19.220
усунення перегріву двигуна.

00:10:19.420 --> 00:10:21.380
Система видає розділ з усунення несправностей

00:10:21.380 --> 00:10:22.540
спосібника до обладнання,

00:10:22.680 --> 00:10:23.840
а також відскановану схему,

00:10:23.980 --> 00:10:25.360
де показані відповідні деталі.

00:10:25.500 --> 00:10:27.060
Навіть якщо схема – це зображення,

00:10:27.180 --> 00:10:28.560
Azure AI Search може витягти

00:10:28.560 --> 00:10:30.180
та проіндексувати її текстовий вміст,

00:10:30.180 --> 00:10:31.940
щоб він з'явився в результатах пошуку.

00:10:32.080 --> 00:10:34.920
Спільним для всіх цих прикладів є неструктуровані дані –

00:10:34.920 --> 00:10:36.420
PDF-файли, документи Word,

00:10:36.420 --> 00:10:38.420
листи підтримки, відскановані зображення.

00:10:38.560 --> 00:10:40.880
Традиційні запити до баз даних і пошук за ключовими словами

00:10:40.880 --> 00:10:42.640
ніколи не були розраховані на такий тип даних.

00:10:42.780 --> 00:10:44.840
Azure AI Search створений спеціально для цього світу,

00:10:44.920 --> 00:10:46.040
і що більше ви його вивчаєте,

00:10:46.140 --> 00:10:47.940
то очевиднішим стає, що гібридний пошук –

00:10:47.940 --> 00:10:49.100
це не просто приємна функція.

00:10:49.240 --> 00:10:50.560
Це фундаментальна частина того,

00:10:50.740 --> 00:10:52.220
як створюються сучасні програми,

00:10:52.220 --> 00:10:54.340
як ці елементи поєднуються між собою.

00:10:54.500 --> 00:10:56.460
Отже, як усе це працює насправді.

00:10:56.640 --> 00:10:59.180
Azure AI Search має три основні компоненти –

00:10:59.180 --> 00:11:01.640
джерело даних, індексатор та пошуковий індекс.

00:11:01.800 --> 00:11:04.580
Джерело даних – це місце, де зберігається ваша інформація.

00:11:04.700 --> 00:11:07.280
Це може бути блок-сховище, база даних Azure SQL,

00:11:07.460 --> 00:11:09.100
Cosmos DB або навіть SharePoint.

00:11:09.260 --> 00:11:11.960
Це необроблені дані, які мають стати доступними для пошуку.

00:11:12.120 --> 00:11:14.980
Уявіть це як стос документів, що чекають на впорядкування.

00:11:15.240 --> 00:11:17.760
Індексатор – це конвейер, який щитує дані з джерела,

00:11:17.940 --> 00:11:21.220
видобуває вміст, застосовує налаштоване вами AI-збагачення,

00:11:21.360 --> 00:11:23.060
а потім створює пошуковий індекс.

00:11:23.060 --> 00:11:24.960
Ось простий спосіб – це уявити.

00:11:25.140 --> 00:11:28.460
Уявіть бібліотекаря, який заходить на склад повний книжок.

00:11:28.600 --> 00:11:30.720
Він читає кожну з них, робить детальні нотатки,

00:11:30.860 --> 00:11:34.320
визначає ключові теми та сутності і впорядкувує все в картковий каталог.

00:11:34.500 --> 00:11:37.000
Це читання та нотування і є процесом індексації.

00:11:37.160 --> 00:11:39.420
Пошуковий індекс – це той самий картковий каталог.

00:11:39.600 --> 00:11:40.680
Це не самі книжки.

00:11:40.860 --> 00:11:42.640
Це структурована, оптимізована система,

00:11:42.820 --> 00:11:45.700
що дозволяє знайти саме те, що вам потрібно за мілі секунди.

00:11:45.860 --> 00:11:49.160
Коли ви вводите запит, система не звертається до оригінальних документів

00:11:49.160 --> 00:11:51.740
і не сканує їх. Натомість вона переглядає індекс,

00:11:51.880 --> 00:11:54.000
який уже точно знає, де все розташовано.

00:11:54.140 --> 00:11:57.140
Така попередня організація називається інвертованим індексом.

00:11:57.300 --> 00:11:59.040
Замість зберігання документів зі списком слів,

00:11:59.140 --> 00:12:01.600
ви зберігаєте слова зі списком документів, у яких вони є.

00:12:01.740 --> 00:12:03.360
Це означає, що коли ви шукаєте термін,

00:12:03.460 --> 00:12:04.880
ви переходите прямо в потрібне місце.

00:12:05.040 --> 00:12:06.720
Без потреби гортати кожну сторінку.

00:12:06.940 --> 00:12:09.020
Результатом є значне підвищення швидкості.

00:12:09.180 --> 00:12:10.800
Замість сканування кожного документа,

00:12:10.800 --> 00:12:12.960
що займає більше часу зростом обсягу даних,

00:12:12.960 --> 00:12:14.860
ви переходите прямо до потрібного місця.

00:12:15.000 --> 00:12:17.600
При мільйонах документів ця різниця стає очевидною,

00:12:17.760 --> 00:12:19.900
пошук займає не секунди, а мілісекунди.

00:12:20.040 --> 00:12:22.020
Тепер ви розумієте, що таке Azure AI Search,

00:12:22.160 --> 00:12:23.800
як основні компоненти поєднуються разом

00:12:23.800 --> 00:12:25.660
і чому гібридний пошук змінює правила гри.

00:12:25.800 --> 00:12:27.660
Підсумуємо кілька речей, які ви можете зробити

00:12:27.660 --> 00:12:28.940
за допомогою цього інструменту.

00:12:29.060 --> 00:12:30.760
По-перше, зрозумійте свої дані.

00:12:30.900 --> 00:12:32.420
Якщо вони вже структуровані, наприклад,

00:12:32.420 --> 00:12:35.220
таблиці продуктів у SQL, записи клієнтів у базі даних,

00:12:35.220 --> 00:12:36.600
усе з чіткими рядками та стопцями,

00:12:36.700 --> 00:12:38.740
ви можете запитувати їх безпосередньо через SQL.

00:12:38.900 --> 00:12:41.520
Azure AI Search створений для неструктурованого тексту.

00:12:41.660 --> 00:12:44.680
Це PDF-файли, електронні листи, документи Word, тікети підтримки.

00:12:44.880 --> 00:12:46.900
Саме там він забезпечує справжню цінність.

00:12:47.020 --> 00:12:49.960
По-друге, якщо ви створюєте ArrayG-додаток або AI-помічника,

00:12:50.100 --> 00:12:51.880
Azure AI Search з гібридним пошуком –

00:12:51.880 --> 00:12:53.920
це саме той механізм пошуку, який вам потрібен.

00:12:53.920 --> 00:12:56.740
Він забезпечує точні збіги за ключовими словами для точності

00:12:56.740 --> 00:12:58.440
та семантичне розуміння для контексту.

00:12:58.440 --> 00:13:01.660
Така комбінація забезпечує більш надійні відповіді з посиланнями,

00:13:01.800 --> 00:13:03.360
ніж кожен із цих підходів окремо.

00:13:03.460 --> 00:13:05.520
По-третє, не ускладнюйте налаштування.

00:13:05.700 --> 00:13:07.840
На порталі Azure є майстер імпорту даних.

00:13:07.940 --> 00:13:09.940
Підключіть сховище блобів, налаштуйте кілька параметрів

00:13:09.940 --> 00:13:11.860
і дозвольте індексатору створити ваш перший індекс.

00:13:12.020 --> 00:13:14.200
Ви можете виконати свій перший пошук менш ніж за годину.

00:13:14.360 --> 00:13:16.440
Отже, це Azure AI Search простими словами.

00:13:16.440 --> 00:13:18.560
Він бере безладну, неструктуровану інформацію

00:13:18.560 --> 00:13:20.840
та перетворює її на готові до пошуку знання для ЩІ.

00:13:20.840 --> 00:13:22.320
Дякую, що були зі мною.

00:13:22.480 --> 00:13:24.600
Підписуйтесь і побачимося в наступному епізоді.