WEBVTT

00:00:00.100 --> 00:00:02.960
Представьте себе такую ситуацию. Вы работаете в корпоративном приложении.

00:00:03.140 --> 00:00:06.980
Может быть, это HR-портал, база поддержки клиентов или внутренняя Вики со всеми правилами,

00:00:07.060 --> 00:00:10.240
которые нужно соблюдать. Вы вводите вопрос в строку поиска. Например,

00:00:10.520 --> 00:00:15.140
как подать отчет о расходах на деловой ужин. Нажимаете «ввод» и что получаете? Ничего.

00:00:15.380 --> 00:00:18.060
Или, что еще хуже, список случайных PDF-файлов трехлетней давности,

00:00:18.220 --> 00:00:21.780
которые лишь отдаленно соответствуют введенным словам. Поиск — это-то, чем мы пользуемся каждый

00:00:21.780 --> 00:00:25.840
день. И чаще всего он работает ужасно. Но вот в чем дело. Так быть не должно. Что,

00:00:26.020 --> 00:00:28.980
если бы ваши приложения могли действительно понимать, о чем вы спрашиваете? Что,

00:00:28.980 --> 00:00:32.820
если бы они могли искать так же, как Google, находя правильный ответ, даже если вы не подобрали

00:00:32.820 --> 00:00:37.620
идеальные слова? Сегодня мы поговорим об Azura AI Search. Что это такое, как это работает под капотом,

00:00:37.740 --> 00:00:41.900
и почему на нем строятся современные поисковые системы для приложений. Берите кофе и давайте

00:00:41.900 --> 00:00:45.700
погружаться. Почему поиск не работает? Чтобы понять, почему поиск часто дает сбой,

00:00:45.900 --> 00:00:49.500
нужно взглянуть на то, как его выполняют большинство приложений. Традиционный метод называется

00:00:49.500 --> 00:00:55.300
ключевым или лексическим поиском. Вы вводите слово «ноутбук» в строку, и система находит все документы,

00:00:55.300 --> 00:00:58.960
в которых есть это конкретное слово. Под капотом многие из этих системы

00:00:58.960 --> 00:01:04.940
используют алгоритм под названием BM25. Он несложный, но по-своему умный. BM25 ранжирует

00:01:04.940 --> 00:01:09.080
результаты на основе нескольких факторов. Как часто поисковый запрос встречается в документе,

00:01:09.300 --> 00:01:13.320
какова длина документа и насколько редок этот запрос во всем наборе данных. Представьте его

00:01:13.320 --> 00:01:17.460
как очень сложный счетчик слов, который определяет наиболее релевантные документы на основе

00:01:17.460 --> 00:01:22.180
этих параметров. И вот здесь начинаются проблемы. Человеческий язык запутан. Люди не задают вопросы,

00:01:22.180 --> 00:01:25.640
используя те же слова, что содержатся в документах. Приведу конкретный пример.

00:01:25.640 --> 00:01:30.400
Пользователь вводит в портал поддержки следующие. «Мой ноутбук постоянно зависает во время

00:01:30.400 --> 00:01:35.740
видеозвонков». Поиск по ключевым словам старательно будет искать документы, содержащие слова «ноутбук»

00:01:35.740 --> 00:01:40.860
постоянно зависает во время видеозвонков. Но что, если лучшая статья по этой теме называется

00:01:40.860 --> 00:01:45.040
«Устранение зависаний системы во время встреч в Teams» или «Управление троттлингом процессора на

00:01:45.040 --> 00:01:48.300
ноутбуках с док-станцией»? Поиск по ключевым словам их полностью проигнорирует.

00:01:48.300 --> 00:01:51.880
Почему? Потому что слова не совпадают. Основная проблема заключается в следующем.

00:01:51.880 --> 00:01:55.900
Поиск по ключевым словам понимает написание. Он понимает шаблоны символов, но не понимает

00:01:55.900 --> 00:01:59.740
смысла. Вы получаете результаты, в которых совпадают буквы, но часто не совпадает содержание.

00:01:59.740 --> 00:02:03.580
Итак, если точное совпадение слов оставляет такие пробелы, какая есть альтернатива?

00:02:03.580 --> 00:02:08.680
Новый подход — векторный поиск. Итак, векторный поиск — это совершенно иной способ решения задач.

00:02:08.680 --> 00:02:13.180
Вместо поиска точных слов он ищет смысл. Звучит абстрактно. Давайте разберемся.

00:02:13.180 --> 00:02:17.680
Простейшее определение «вектор» — это просто список чисел, который представляет данные,

00:02:17.680 --> 00:02:20.580
понятные компьютеру. Вот и все. Просто список чисел.

00:02:20.580 --> 00:02:25.200
Имбеддинг — это особый тип вектора, который улавливает смысл текста. Он берет предложение,

00:02:25.200 --> 00:02:28.740
абзац или даже целый документ и превращает их в длинный список чисел.

00:02:28.740 --> 00:02:33.780
Компьютер не понимает слова, но он понимает числа. Вот полезная аналогия. Представьте векторы

00:02:33.780 --> 00:02:37.900
как координаты на карте. На карте похожие места расположены близко друг к другу. В векторном

00:02:37.900 --> 00:02:42.540
пространстве схожие понятия также оказываются рядом. Векторы для «короля» и «королевы» находятся

00:02:42.540 --> 00:02:48.000
близко, потому что они отражают связанные идеи. А векторы для «короля» и «яблока» расположены далеко друг от

00:02:48.000 --> 00:02:52.460
друга. Компьютер не знает, что «король» значит для человека, но может измерить расстояние между

00:02:52.460 --> 00:02:57.120
его координатами и координатами любого другого слова или документа. Это как GPS для идей.

00:02:57.340 --> 00:03:02.540
Система понимает степень различия понятий, просто глядя на числа. Когда вы ищете с помощью векторов,

00:03:02.780 --> 00:03:07.260
система преобразует ваш запрос в имбеддинг. Затем она находит документы, имбеддинги которых

00:03:07.260 --> 00:03:11.240
ближе всего к вашему. Она находит то, что семантически схоже, что разделяет смысл,

00:03:11.420 --> 00:03:15.000
а не просто словарный состав. Представьте, что вы ищете документ по устранению неполадок

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

00:03:19.540 --> 00:03:23.560
Но с векторным поиском вы можете ввести «мой компьютер постоянно клинит», и он найдет нужный

00:03:23.560 --> 00:03:28.180
документ. В этом и заключается сила понимания смысла. Вернемся к нашему примеру с поиском.

00:03:28.340 --> 00:03:33.240
Пользователь пишет «мой ноутбук постоянно зависает». С помощью векторного поиска система может

00:03:33.240 --> 00:03:37.700
выдать статью о системных сбоях во время встреч в Teams, даже если этих слов нет в запросе.

00:03:37.800 --> 00:03:43.060
Почему? Потому что значение «системный сбой» очень близко к зависанию компьютера в векторном пространстве.

00:03:43.060 --> 00:03:48.080
Эти понятия находятся рядом на той самой карте. Системе не важны точные слова. Ей важно-то,

00:03:48.200 --> 00:03:51.980
что вы имеете в виду. Это настоящий прорыв. Компьютеры начинают понимать намерения,

00:03:52.140 --> 00:03:56.020
а не только правописание. Они находят ответы, которые ключевой поиск пропустил бы полностью.

00:03:56.200 --> 00:04:00.040
Но у векторного поиска есть и слабое место. Он может упустить точные совпадения,

00:04:00.240 --> 00:04:04.080
которые критически важны. Если технический специалист ищет конкретный код ошибки,

00:04:04.200 --> 00:04:09.940
например, X8070570, векторный поиск может отдать приоритет документам об ошибках диска

00:04:09.940 --> 00:04:14.040
или повреждений файловой системы, а не самому документу, описывающему этот конкретный код.

00:04:14.160 --> 00:04:17.700
Он жертвует точностью ради понимания контекста. Итак, у нас есть два метода.

00:04:17.840 --> 00:04:21.060
Ключевой поиск отлично подходит для точности. Он идеально находит точные термины,

00:04:21.200 --> 00:04:24.480
ID продуктов и номер контрактов. Векторный поиск отлично подходит для поиска по смыслу.

00:04:24.560 --> 00:04:27.880
Он находит верный ответ, даже если вы не используете нужные слова. У каждого из них есть

00:04:27.880 --> 00:04:32.680
свои слепые зоны. И это порождает закономерный вопрос. А что, если объединить оба подхода и взять

00:04:32.680 --> 00:04:36.980
лучшие от каждого из них? Гибридный прорыв. Гибридный поиск – это лучшее из обоих миров.

00:04:36.980 --> 00:04:41.340
Он одновременно выполняет ключевой и векторный поиск, а затем объединяет результаты в единый

00:04:41.340 --> 00:04:45.020
ранжированный список. Вместо того, чтобы выбирать один подход в ущерб другому, система использует

00:04:45.020 --> 00:04:49.160
метод, называемый взаимным ранговым слиянием или RRF. Вот как это работает. RRF анализирует,

00:04:49.240 --> 00:04:52.400
на каком месте находится каждый документ в результатах ключевого поиска и на каком в результатах

00:04:52.400 --> 00:04:56.100
векторного. Затем он присваивает комбинированную оценку. Если документ занимает высокие позиции в

00:04:56.100 --> 00:05:00.380
обоих, он получает бонус. Это как взять мнение двух экспертов и вывести средние значения. Итоговый ответ более

00:05:00.380 --> 00:05:04.300
надежен, чем результат любого из методов по отдельности. Это важно, поскольку ключевой и векторный

00:05:04.300 --> 00:05:07.920
поиск обладают фундаментально разными сильными сторонами. Ключевой поиск превосходно справляется

00:05:07.920 --> 00:05:12.140
с точными совпадениями. Это ваш лучший выбор для ID-продуктов, номеров контрактов, конкретных имен

00:05:12.140 --> 00:05:16.560
и кодов ошибок. Он точен и предсказуем. Векторный поиск превосходен в семантической близости,

00:05:16.740 --> 00:05:20.660
находя документы, схожие по смыслу с вашим запросом, даже если в них нет точных словарей.

00:05:20.860 --> 00:05:24.660
Вместе они закрывают слепые зоны друг друга. Система обнаруживает и точные совпадения,

00:05:24.660 --> 00:05:28.440
и концептуальные соответствия в рамках одного запроса. В этом и заключается настоящая сила.

00:05:28.580 --> 00:05:32.460
И это не просто теория. Исследования корпоративного гибридного поиска показывают точность

00:05:32.460 --> 00:05:37.960
извлечения от 70 до 80% в зависимости от набора данных. Это примерно на 15-20% пунктов выше,

00:05:38.200 --> 00:05:42.020
чем при использовании только векторного поиска. Разница существенна, и она отражается на

00:05:42.020 --> 00:05:46.980
реальных бизнес-показателях. Возьмем бухгалтерскую платформу Ксера. Они внедрили гибридный поиск в свою

00:05:46.980 --> 00:05:51.540
систему поддержки клиентов с помощью компании Кавиа. В течение трех месяцев они зафиксировали рост

00:05:51.540 --> 00:05:56.200
самостоятельного решения проблем на 20%. Клиенты стали чаще находить ответы самостоятельно,

00:05:56.340 --> 00:06:00.440
не обращаясь в службу поддержки. Другие клиенты в том же исследовании добились сокращения

00:06:00.440 --> 00:06:05.220
времени решения обращений в поддержку до 40%. Это означает, что агенты быстрее находили нужную

00:06:05.220 --> 00:06:09.260
информацию, клиенты получали ответы оперативнее, а затраты на поддержку снизились. Это не просто

00:06:09.260 --> 00:06:13.160
приятная функция, это измеримое влияние на финансовые показатели компании. В этом и заключается

00:06:13.160 --> 00:06:17.000
ключевой момент. Гибридный поиск – это не просто приятное обновление или галочка в списке функций,

00:06:17.120 --> 00:06:20.940
он объективно лучше. Он обеспечивает более высокую точность, полноту выдачи и лучшие результаты для

00:06:20.940 --> 00:06:25.220
пользователей. И именно это сочетание подходов делает Azure AI Search таким мощным инструментом для

00:06:25.220 --> 00:06:28.840
современных приложений. Но есть еще одна технология, которую открывает эта комбинация,

00:06:29.000 --> 00:06:33.140
и сейчас она привлекает много внимания. Она называется RAG или связь с RAG. Итак,

00:06:33.360 --> 00:06:36.760
давайте поговорим о RAG. RAG расшифровывается как Retrival Abmented Generation – генерация с

00:06:36.760 --> 00:06:40.280
дополнением выборки. Звучит сложно, но вот самое простое определение. Это система,

00:06:40.460 --> 00:06:45.220
которая дает и помощникам доступ к информации, на которой они не обучались. Большие языковые модели,

00:06:45.220 --> 00:06:50.040
такие как GPT, многое знают об истории, науке и программировании, но они не знают внутренних

00:06:50.040 --> 00:06:54.940
документов вашей компании, политик, истории клиентов или специфических процедур вашей команды.

00:06:55.080 --> 00:06:59.200
Многие думают, что можно просто загрузить все эти внутренние знания прямо в саму модель.

00:06:59.340 --> 00:07:04.040
Это не работает, это дорого и сложно обновлять. RAG решает эту проблему изящным способом.

00:07:04.200 --> 00:07:08.260
Вместо того, чтобы впихивать все в модель, вы извлекаете нужную информацию из базы знаний в тот

00:07:08.260 --> 00:07:12.580
момент, когда кто-то задает вопрос. Вы берете запрос пользователя, ищите по своим внутренним данным,

00:07:12.580 --> 00:07:17.140
находите наиболее релевантные документы и передаете этот контекст в LLM вместе с исходным вопросом.

00:07:17.140 --> 00:07:21.500
Затем LLM генерирует ответ, основанный на ваших данных. В этом и заключается магия.

00:07:21.700 --> 00:07:26.900
Azure AI Search — это поисковая часть этого уравнения. Это движок, который находит нужные документы,

00:07:27.140 --> 00:07:31.680
чтобы LLM могла ответить точно. Безнадежного уровня поиска система RAG будет лишь настолько хороша,

00:07:31.840 --> 00:07:35.280
насколько хороши найденные ею документы. И здесь гибридный поиск по-настоящему сияет,

00:07:35.340 --> 00:07:39.040
поскольку запросы RAG часто представляют собой вопросы на естественном языке, а ответы часто

00:07:39.040 --> 00:07:42.460
содержатся в документах с совершенно иной терминологией. Позвольте привести несколько цифр,

00:07:42.600 --> 00:07:46.780
которые наглядно показывают разницу. Исследование поиска в корпоративных приложениях показало,

00:07:46.780 --> 00:07:52.040
что гибридная структура RAG улучшила точность поиска TOP-K в 18-25 раз по сравнению с простым

00:07:52.040 --> 00:07:56.900
ключевым поиском. Точность выполнения рабочих задач улучшилась в 21 раз. Это означает,

00:07:57.080 --> 00:08:01.400
что пользователи гораздо чаще успешно справлялись со сложными задачами при поддержке системы RAG

00:08:01.400 --> 00:08:05.600
с использованием гибридного поиска. В целом, правильно внедренные системы RAG могут повысить

00:08:05.600 --> 00:08:11.020
точность поиска в среднем на 85%, а в некоторых специализированных областях — почти до 99%.

00:08:11.020 --> 00:08:15.340
А поскольку LLM генерирует ответы на основе извлеченного контекста, а не собственных догадок,

00:08:15.520 --> 00:08:19.240
системы RAG показали снижение количества галлюцинаций примерно на 40%.

00:08:19.240 --> 00:08:23.460
Вот почему Azure AI сёч играет ключевую роль в создании и агентов, и копилотов.

00:08:23.560 --> 00:08:28.300
Он обеспечивает основанный на фактах поиск, который делает LLM надежными в бизнес-контексте.

00:08:28.460 --> 00:08:32.060
Если вы создаете помощника, который должен точно отвечать на вопросы и ссылаться на источники,

00:08:32.220 --> 00:08:35.540
гибридный поиск в сочетании с RAG — это именно та архитектура, которая вам нужна.

00:08:35.540 --> 00:08:38.920
Итак, гибридный поиск плюс RAG — это мощная комбинация.

00:08:39.080 --> 00:08:40.700
Но как это выглядит на практике?

00:08:40.880 --> 00:08:42.520
Реальное практическое применение.

00:08:42.740 --> 00:08:44.580
Где же это находит отражение в реальности?

00:08:44.740 --> 00:08:46.360
Позвольте привести несколько примеров.

00:08:46.460 --> 00:08:48.760
Электронная коммерция — пожалуй, самый понятный из них.

00:08:48.880 --> 00:08:51.620
Клиент вводит в строку поиска «удобные кроссовки для бега».

00:08:51.620 --> 00:08:54.740
В карточке товара может быть написано «амортизирующая спортивная обувь»,

00:08:54.740 --> 00:08:56.540
потому что отдел маркетинга выбрал другие слова.

00:08:56.740 --> 00:08:59.440
Обычный поиск по ключевым словам просто не нашел бы совпадений.

00:08:59.620 --> 00:09:02.380
Благодаря Azure AI и iSearch система понимает, что в данном контексте

00:09:02.380 --> 00:09:05.300
«удобные» и «амортизирующие» означают примерно одно и то же.

00:09:05.440 --> 00:09:08.080
Она находит нужный товар, даже если слова не совпадают.

00:09:08.260 --> 00:09:11.780
В итоге клиент находит то, что искал, вместо того, чтобы разочарованным покинуть сайт.

00:09:11.940 --> 00:09:14.340
Порталы технической поддержки работают по тому же принципу.

00:09:14.420 --> 00:09:17.220
Представьте, что клиент спрашивает, как мне отменить подписку.

00:09:17.460 --> 00:09:21.300
Соответствующее правило может называться «прекращение действия договора об оказании услуг».

00:09:21.300 --> 00:09:25.340
Гибридный поиск находит этот документ по ключевым словам из юридической терминологии,

00:09:25.480 --> 00:09:28.300
но также предлагает похожий раздел часто задаваемых вопросов

00:09:28.300 --> 00:09:31.180
о досрочном расторжении плана благодаря семантическому сходству.

00:09:31.180 --> 00:09:35.800
Клиент получает исчерпывающий ответ, не тратя время на изучение пяти разных статей.

00:09:35.920 --> 00:09:38.420
Поиск юридических документов – еще один пример.

00:09:38.600 --> 00:09:42.520
Юристам нужно находить контракты по точным номерам пунктов и ссылкам на разделы.

00:09:42.620 --> 00:09:44.480
Это чисто поисковая задача по ключевым словам,

00:09:44.560 --> 00:09:47.380
но им также необходимо находить похожие формулировки в разных соглашениях,

00:09:47.440 --> 00:09:48.680
даже если они написаны по-разному.

00:09:48.860 --> 00:09:51.280
Гибридный поиск справляется с обеими задачами в одном запросе,

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

00:09:53.220 --> 00:09:56.080
почему именно был выдан результат, критически важна для соблюдения нормативов.

00:09:56.200 --> 00:09:58.700
Внутренние базы знаний также получают от этого выгоду.

00:09:58.700 --> 00:10:01.440
Сотрудник, ищущий информацию об отпускной политике,

00:10:01.620 --> 00:10:03.280
получает официальные документы HR,

00:10:03.440 --> 00:10:06.100
а также связанное с этим письмо от юристов о переносе дней

00:10:06.100 --> 00:10:08.520
и недавнее обновление во внутренней сети компании.

00:10:08.740 --> 00:10:12.340
Поиск понимает, что все эти элементы связаны с одним и тем же вопросом.

00:10:12.440 --> 00:10:15.500
Производство – менее очевидный, но очень показательный пример.

00:10:15.680 --> 00:10:19.480
Технический специалист вводит в интерфейс поиска устранения перегрева двигателя.

00:10:19.680 --> 00:10:23.000
Система выдает раздел по устранению неполадок из руководства по оборудованию,

00:10:23.000 --> 00:10:25.300
а также отсканированную схему с нужными деталями.

00:10:25.300 --> 00:10:30.080
Несмотря на то, что схема – это изображение, Azure iSearch может извлечь и проиндексировать ее текстовое содержимое,

00:10:30.240 --> 00:10:31.860
поэтому она появляется в результатах поиска.

00:10:31.980 --> 00:10:34.840
Общая черта всех этих примеров – неструктурированные данные.

00:10:34.980 --> 00:10:38.560
PDF-файлы, документы Word, письма в техподдержку, отсканированные изображения.

00:10:38.720 --> 00:10:42.600
Традиционные запросы к базам данных и поиск по ключевым словам не были предназначены для таких данных.

00:10:42.740 --> 00:10:45.900
Azure iSearch создана специально для таких задач, и чем глубже вы погружаетесь,

00:10:46.020 --> 00:10:49.060
тем яснее становится, что гибридный поиск – это не просто приятное дополнение.

00:10:49.200 --> 00:10:52.240
Это фундаментальная часть того, как создаются современные приложения.

00:10:52.240 --> 00:10:54.260
Как эти элементы сочетаются друг с другом?

00:10:54.360 --> 00:10:56.520
Итак, как же все это работает под капотом?

00:10:56.660 --> 00:11:01.700
Azure iSearch состоит из трех основных блоков – источника данных, индексатора и поискового индекса.

00:11:01.860 --> 00:11:04.520
Источник данных – это место, где хранится ваша информация.

00:11:04.720 --> 00:11:09.220
Это может быть хранилище био-лобби объектов, база данных Azure SQL, Cosmos DB или даже SharePoint.

00:11:09.380 --> 00:11:11.960
Это сырой материал, который должен стать доступным для поиска.

00:11:12.100 --> 00:11:15.040
Представьте это как стопку документов, ожидающих систематизации.

00:11:15.300 --> 00:11:18.420
Индексатор – это конвейер, который считывает данные из источника,

00:11:18.420 --> 00:11:23.080
извлекает контент, применяет настроенные и обогащение, и затем строит поисковый индекс.

00:11:23.220 --> 00:11:25.000
Вот простой способ это представить.

00:11:25.120 --> 00:11:28.460
Представьте библиотекаря, который заходит на склад полной книг.

00:11:28.520 --> 00:11:30.940
Он прочитывает каждую из них, делает подробные заметки,

00:11:31.100 --> 00:11:34.460
определяет ключевые темы и объекты, а затем упорядочивает все в картотеку.

00:11:34.540 --> 00:11:37.040
Это чтение и ведение записей, процесс индексации.

00:11:37.200 --> 00:11:39.520
Поисковый индекс – это и есть та самая картотека.

00:11:39.660 --> 00:11:40.600
Это не сами книги.

00:11:40.740 --> 00:11:45.740
Это структурированная, оптимизированная система, позволяющая найти именно то, что нужно за миллисекунды.

00:11:45.740 --> 00:11:50.080
Когда вы вводите запрос, система не возвращается к исходным документам и не сканирует их.

00:11:50.220 --> 00:11:53.940
Вместо этого она обращается к индексу, который уже знает, где все находится.

00:11:54.160 --> 00:11:57.100
Такая предварительная организация называется инвертированным индексом.

00:11:57.260 --> 00:11:59.400
Вместо хранения документов со списком содержащихся в них слов,

00:11:59.620 --> 00:12:01.740
вы храните слова со списком документов, в которых они есть.

00:12:01.880 --> 00:12:04.780
Это означает, что при поиске термина вы сразу попадаете в нужное место,

00:12:04.980 --> 00:12:06.760
без необходимости листать каждую страницу.

00:12:06.940 --> 00:12:08.920
Результат – колоссальное увеличение скорости.

00:12:09.120 --> 00:12:10.900
Вместо того, чтобы сканировать каждый документ,

00:12:11.060 --> 00:12:13.000
что занимает все больше времени по мере роста данных,

00:12:13.200 --> 00:12:14.860
вы переходите сразу к нужному результату.

00:12:14.860 --> 00:12:17.620
При миллионах документов эта разница становится решающей.

00:12:17.800 --> 00:12:20.080
Поиск занимает либо секунды, либо миллисекунды.

00:12:20.240 --> 00:12:22.560
Итак, теперь вы понимаете, что такое Azure AI Search,

00:12:22.700 --> 00:12:26.020
как работают его основные компоненты и почему гибридный поиск меняет правила игры.

00:12:26.200 --> 00:12:28.660
Давайте подытожим, что именно вы можете с этим делать.

00:12:28.840 --> 00:12:30.740
Во-первых, разберитесь в своих данных.

00:12:30.900 --> 00:12:33.740
Если они уже структурированы, например, таблицы продуктов в SQL,

00:12:33.980 --> 00:12:36.800
записи клиентов в базе данных, все с четкими строками и столбцами,

00:12:36.920 --> 00:12:38.760
вы можете запрашивать их напрямую через SQL.

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

00:12:41.400 --> 00:12:44.880
Это PDF-файлы, электронные письма, документы Word, тикеты в службу поддержки.

00:12:44.980 --> 00:12:46.800
Именно здесь он приносит реальную пользу.

00:12:46.940 --> 00:12:50.040
Во-вторых, если вы создаете ARRAG-приложение или E-помощника,

00:12:50.200 --> 00:12:53.800
Azure AI Search с гибридным поиском — это движок извлечения данных, который вам нужен.

00:12:53.960 --> 00:12:56.780
Он обеспечивает точные совпадения по ключевым словам для конкретики

00:12:56.780 --> 00:12:58.460
и семантическое понимание для контекста.

00:12:58.580 --> 00:13:01.740
Такое сочетание дает более надежные ответы со ссылками на источники,

00:13:01.940 --> 00:13:03.420
чем каждый из подходов по отдельности.

00:13:03.560 --> 00:13:05.540
В-третьих, не усложняйте настройку.

00:13:05.660 --> 00:13:07.740
На портале Azure есть мастер импорта данных.

00:13:07.740 --> 00:13:10.260
Подключите хранилище биолоби-объектов, задайте несколько параметров

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

00:13:12.040 --> 00:13:14.180
Вы сможете выполнить свой первый поиск менее чем за час.

00:13:14.340 --> 00:13:16.320
Вот что такое Azure AI Search простыми словами.

00:13:16.500 --> 00:13:18.480
Система берет разрозненную, неструктурированную информацию

00:13:18.480 --> 00:13:21.040
и превращает ее в доступные для поиска знания, готовые для работы с E.

00:13:21.160 --> 00:13:22.380
Спасибо, что были со мной.

00:13:22.640 --> 00:13:23.080
Подписывайтесь.

00:13:23.320 --> 00:13:24.600
Увидимся в следующем выпуске.

00:13:24.600 --> 00:13:54.580
Продолжение следует...