WEBVTT

00:00:00.000 --> 00:00:01.140
תארו לעצמכם את זה.

00:00:01.260 --> 00:00:03.080
אתם עובדים ביישום כלשהו בחברה שלכם.

00:00:03.180 --> 00:00:04.480
אולי זה פורטל משאבי אנוש,

00:00:04.620 --> 00:00:07.680
מאגר תמיכה בלקוחות או הוויקי הפנימי עם כל הנהלים שצריך להכיר.

00:00:07.820 --> 00:00:09.620
אתם מקלידים שאלה בשורת החיפוש.

00:00:09.800 --> 00:00:12.780
משהו כמו, איך אני מגיש דוח הוצאות על ארוחת ערב עסקי?

00:00:12.880 --> 00:00:14.760
אתם לוחצים על Enter ומה אתם מקבלים?

00:00:14.940 --> 00:00:15.300
כלום.

00:00:15.460 --> 00:00:19.860
או גרוע מכך, רשימה של קבצי PDF אקראיים מלפני שלוש שנים שבערך תואמים למילים שהקלדתם.

00:00:19.860 --> 00:00:23.660
חיפוש הוא משהו שאנחנו משתמשים בו בכל יום, וברוב המקרים הוא נורא.

00:00:23.720 --> 00:00:25.800
אבל הנה העניין, זה לא חייב להיות ככה.

00:00:25.900 --> 00:00:28.500
מה אם היישומים שלכם יכלו באמת להבין מה אתם שואלים?

00:00:28.640 --> 00:00:33.380
מה אם הם יכלו לחפש כמו שגוגל עושה ולמצוא את התשובה הנכונה גם כשלא משתמשים במילים המדויקות?

00:00:33.480 --> 00:00:35.520
היום אנחנו עוסקים ב-Azure Eye Search.

00:00:35.700 --> 00:00:37.720
מה זה בעצם? איך זה עובד מאחורי הקלעים?

00:00:37.920 --> 00:00:40.460
ומדוע זה מנוע החיפוש שעליו נבנים יישומים מודרניים?

00:00:40.580 --> 00:00:42.700
קחו את הקפה שלכם ובואו נצלול פנימה.

00:00:42.700 --> 00:00:43.900
מדוע החיפוש שבור?

00:00:44.020 --> 00:00:48.020
כדי להבין מדוע החיפוש בדרך כלל נכשל, עלינו לבחון איך רוב היישומים באמת עושים זאת.

00:00:48.120 --> 00:00:51.320
הדרך המסורתית נקראת חיפוש מילות מפתח או חיפוש לקסיקלי.

00:00:51.480 --> 00:00:56.800
אתם מקלידים את המילה, מחשב נייד, בטבע, והמערכת יוצאת למצוא כל מסמך שמכיל בדיוק את המילה הזו.

00:00:56.920 --> 00:01:01.020
מאחורי הקלעים, הרבה מהמערכות הללו משתמשות באלגוריתם שנקרא BM25.

00:01:01.500 --> 00:01:03.700
זה לא מסובך, אבל זה חכם בדרכו שלו.

00:01:03.700 --> 00:01:06.580
BM25 מדרג תוצאות על סמך כמה דברים.

00:01:06.580 --> 00:01:12.680
באיזו תדירות מונח החיפוש שלכם מופיע במסמך, מהו אורך המסמך ועד כמה המונח נדיר בכל מאגר הנתונים.

00:01:12.900 --> 00:01:18.380
חישבו על זה כעל מונה מילים מתוחכם מאוד שמבין אילו מסמכים הם הרלוונטיים ביותר על בסיס הגורמים הללו.

00:01:18.500 --> 00:01:19.400
כאן זה מתפרק.

00:01:19.600 --> 00:01:20.980
שפה אנושית היא מבולגנת.

00:01:21.140 --> 00:01:24.060
אנשים לא שואלים שאלות באמצעות אותן מילים שבהן המסמכים משתמשים.

00:01:24.200 --> 00:01:25.880
תן לי לתת לכם דוגמה קונקרטית.

00:01:26.080 --> 00:01:28.140
משתמש מקליד את זה בפורטל תמיכה.

00:01:28.140 --> 00:01:31.320
המחשב הנייד שלי ממשיך לקפוא במהלך שיחות וידאו.

00:01:31.560 --> 00:01:38.160
חיפוש מילות מפתח יחפש בחריצות מסמכים המכילים מחשב נייד, כופה במהלך שיחות ווידאו.

00:01:38.280 --> 00:01:43.140
אבל מה אם המאמר הטוב ביותר בנושא נקרא פתרון תקלות של כפיאת מערכת במהלך פגישות טימס?

00:01:43.280 --> 00:01:46.160
או ניהול אומס מעבד במחשבים ניידים מחוברים לתחנת הגינה.

00:01:46.320 --> 00:01:48.500
חיפוש מילות המפתח מפספס אותם לחלוטין.

00:01:48.660 --> 00:01:48.920
למה?

00:01:49.080 --> 00:01:50.200
כי המילים לא תואמות.

00:01:50.320 --> 00:01:51.660
הבעיה המרכזית היא זו.

00:01:51.660 --> 00:01:53.460
חיפוש מילות מפתח מבין איות.

00:01:53.620 --> 00:01:56.080
הוא מבין תבניות של תווים, אבל הוא לא מבין משמעות.

00:01:56.220 --> 00:01:59.820
אתם מקבלים תוצאות שיש להן את האותיות הנכונות, אבל לרוב את התוכן הלא נכון.

00:01:59.960 --> 00:02:03.420
אז אם התאמת מילים מדויקת משאירה כל כך הרבה פערים, מהי החלופה?

00:02:03.520 --> 00:02:05.380
הדרך החדשה, חיפוש וקטורי.

00:02:05.500 --> 00:02:08.480
אז, חיפוש וקטורי זו דרך שונה לחלוטין לעשות דברים.

00:02:08.680 --> 00:02:11.060
במקום להתאים מילים מדויקות, הוא מתאים משמעות.

00:02:11.260 --> 00:02:13.180
זה נשמע מופשט, אז בואו נפרק את זה.

00:02:13.180 --> 00:02:15.320
ההגדרה הפשוטה ביותר שצריך לדעת היא זו.

00:02:15.480 --> 00:02:18.800
וקטור הוא פשוט רשימה של מספרים שמייצג את משהו שמחשב יכול לעבוד איתו.

00:02:18.920 --> 00:02:20.520
זה הכל רשימה של מספרים.

00:02:20.700 --> 00:02:24.260
אמבדינג, שיקון, הוא סוג מיוחד של וקטור שתופס את המשמעות של טקסט.

00:02:24.380 --> 00:02:28.700
הוא לוקח משפט, פסקה או אפילו מסמך שלם, והופך אותו לרשימה ארוכה של מספרים.

00:02:28.880 --> 00:02:31.500
המחשב לא מבין את המילים, אבל הוא מבין את המספרים.

00:02:31.700 --> 00:02:32.880
הנה האנלוגיה שעוזרת.

00:02:32.880 --> 00:02:35.140
תחשבו על וקטורים כמו קואורדינטות על מפה.

00:02:35.220 --> 00:02:37.340
על מפה, מקומות דומים נמצאים קרוב זה לזה.

00:02:37.480 --> 00:02:40.180
במרחב וקטורי, מושגים דומים מסתיימים קרוב זה לזה.

00:02:40.320 --> 00:02:44.780
פוקטור של מלך, והווקטור של מלכה קרובים זה לזה כי הם מייצגים רעיונות קשורים.

00:02:44.920 --> 00:02:48.240
פוקטור של מלך, והווקטור של תפוח רחוקים מאוד.

00:02:48.400 --> 00:02:50.640
המחשב לא יודע מה מלך אומר במובן אנושי,

00:02:50.820 --> 00:02:55.160
אבל הוא יכול למדוד את המרחק בין הקואורדינטות שלו לקואורדינטות של כל מילה או מסמך אחר.

00:02:55.160 --> 00:02:57.380
זה כמו להחזיק GPS לרעיונות

00:02:57.380 --> 00:03:01.000
המערכת יודעת כמה רחוקים המושגים זה מזה רק על ידי הסתכלות על המספרים

00:03:01.000 --> 00:03:04.960
כשמחפשים באמצעות וקטורים, המערכת ממירה את השאילתה שלכם לאמבדינג

00:03:04.960 --> 00:03:08.600
לאחר מכן היא מוצאת את המסמכים שהאמבדינג שלהם הכי קרובים לשלכם

00:03:08.600 --> 00:03:12.360
היא מוצאת דברים שהם דומים סמנטית, שחולקים משמעות, לא רק עוצר מילים

00:03:12.360 --> 00:03:15.740
תארו לעצמכם שאתם מחפשים מסמך על פתרון בעיות במחשב נייד כפו

00:03:15.740 --> 00:03:19.380
אם חיפוש מילות מפתח, תצטרכו להקליד, קופה או נתקה בדיוק

00:03:19.380 --> 00:03:22.800
אבל אם חיפוש וקטורי, אתם יכולים להקליד, המחשב שלי ממשיך להינעל

00:03:22.800 --> 00:03:24.160
והוא ימצא את המסמך הנכון

00:03:24.160 --> 00:03:25.900
זה הכוח של הבנת משמעות

00:03:25.900 --> 00:03:28.200
בואו נחזור לדוגמת החיפוש השבורה שלנו

00:03:28.200 --> 00:03:30.940
משתמש מקליד, המחשב הנייד שלי ממשיך לקפו

00:03:30.940 --> 00:03:35.380
אם חיפוש וקטורי, המערכת יכולה להחזיר את המאמר על תקיעות מערכת במהלך פגישות טימס

00:03:35.380 --> 00:03:37.940
למרות שאף אחת מהמילים הללו לא מופיעה בשאילתה

00:03:37.940 --> 00:03:42.900
למה? כי המשמעות של תקיעות מערכת קרובה מאוד לקפיאת מחשב במרחב וקטורי

00:03:42.900 --> 00:03:45.700
המושגים האלה חיים קרוב זה אלה זה על המפה ההיא

00:03:45.700 --> 00:03:49.180
למערכת לא אכפת מהמילים המדויקות, אכפת לה ממה שאתם מתכוונים

00:03:49.180 --> 00:03:50.500
זוהי פריצת הדרך

00:03:50.500 --> 00:03:53.000
מחשבים מתחילים להווים כוונה, לא רק איות

00:03:53.000 --> 00:03:55.980
הם מוצאים תשובות שחיפוש מילות מפתח יחמיץ לחלוטין

00:03:55.980 --> 00:03:58.100
אבל לחיפוש וקטורי יש גם חולשה

00:03:58.100 --> 00:04:01.300
הוא עלול להחמיץ התאמות מדויקות שהן קריטיות לחלוטין

00:04:01.300 --> 00:04:06.300
אם טכנאי מחפש קוד שגיאה ספציפי כמו X80070570

00:04:06.300 --> 00:04:11.300
חיפוש וקטורי עשוי לתעדף מסמכים על שגיאות דיסק או שחיתות במערכת הקבצים

00:04:11.300 --> 00:04:14.380
במקום את המסמך המדויק שמנתח את הקוד הספציפי הזה

00:04:14.380 --> 00:04:16.120
הוא מקריב דיוק לטובת הבנה

00:04:16.120 --> 00:04:17.580
אז יש לנו שתי שיטות

00:04:17.580 --> 00:04:19.580
חיפוש לפי מילות מפתח מצוין לדיוק

00:04:19.580 --> 00:04:22.560
הוא פוגע בול במונחים מדויקים, מזהי מוצר ומספרי חוזים

00:04:22.560 --> 00:04:24.380
חיפוש וקטורי מצוין למשמעות

00:04:24.380 --> 00:04:27.020
הוא מוצא את התשובה הנכונה גם כשלא משתמשים במילים הנכונות

00:04:27.020 --> 00:04:28.820
לכל אחד מהם יש נקודות עברות

00:04:28.820 --> 00:04:30.380
וזה מעלה שאלה מתבקשת

00:04:30.380 --> 00:04:33.480
מה אם אפשר היה לשלב בין שתי הגישות ולהנות מכל העולמות

00:04:33.480 --> 00:04:34.380
ריצת הדרך ההיברידית

00:04:34.940 --> 00:04:37.120
חיפוש היברידי הוא הטוב מכל העולמות

00:04:37.120 --> 00:04:39.880
הוא מריץ חיפוש מילות מפתח וחיפוש וקטורי בו זמנית

00:04:39.880 --> 00:04:42.320
ואז מאחד את התוצאות לרשימה מדורגת אחת

00:04:42.320 --> 00:04:44.140
במקום לבחור בגישה אחת על פני השנייה

00:04:44.140 --> 00:04:47.380
המערכת משתמשת בשיטה שנקראת איכות דירוג הדדי או RRF

00:04:47.380 --> 00:04:48.260
כך זה עובד

00:04:48.260 --> 00:04:51.180
RRF בוחן היכן כל מסמך מדורג בתוצאות מילות המפתח

00:04:51.180 --> 00:04:52.820
והיכן הוא מדורג בתוצאות הוקטוריות

00:04:52.820 --> 00:04:54.520
לאחר מכן הוא נותן ציון משוקלל

00:04:54.520 --> 00:04:57.000
אם מסמך מדורג היטב בשניהם הוא מקבל דחיפה

00:04:57.000 --> 00:04:59.720
זה כמו לקחת שתי חוות דעת של מומחים ולמצוא להן ממוצע

00:04:59.720 --> 00:05:02.400
התשובה הסופית אמינה יותר מכל אחת מהן בנפרד

00:05:02.400 --> 00:05:06.300
זה חשוב כי לחיפוש מילות מפתח וחיפוש וקטורי יש חוזקות שונות מהותית

00:05:06.300 --> 00:05:08.860
חיפוש מילות מפתח מצטיין בהתאמות מדויקות

00:05:08.860 --> 00:05:12.940
הוא הבחירה המועדפת למזהי מוצר, מספרי חוזים, שמות ספציפיים וקודי שגיעה

00:05:12.940 --> 00:05:14.140
הוא מדויק וצפוי

00:05:14.140 --> 00:05:16.300
חיפוש וקטורי מצטיין בדמיון סמנטי

00:05:16.300 --> 00:05:20.780
הוא מציאת מסמכים שחולקים משמעות עם השאילתה שלך גם כשהמילים המדויקות אינן מופיעות

00:05:20.780 --> 00:05:23.300
יחד הם מכסים את הנקודות העברות זה של זה

00:05:23.300 --> 00:05:27.080
המערכת תופסת התאמות מדויקות והתאמות רעיוניות בשאילתה אחת

00:05:27.080 --> 00:05:28.200
זה הכוח האמיתי

00:05:28.200 --> 00:05:29.480
וזה לא רק תיאורטי

00:05:29.480 --> 00:05:35.520
מחקר על חיפוש ארגוני היברידי מראה שהוא מספק 70-80% דיוק בשליפה תלוי במערך הנתונים

00:05:35.520 --> 00:05:39.820
זה בערך 15-20% הפרש יותר ממה שמקבלים בחיפוש וקטורי בלבד

00:05:39.820 --> 00:05:43.000
ההבדל משמעותי והוא בא לידי ביטוי בתוצאות עסקיות אמיתיות

00:05:43.000 --> 00:05:45.340
קחו למשל את פלטפורמת הנהלת החשבונות Zero

00:05:45.340 --> 00:05:49.540
הם התמיעו חיפוש היברידי בחוויית תמיכת הלקוחות שלהם דרך חברה בשם קוווי

00:05:49.540 --> 00:05:53.600
בתוך שלושה חודשים הם ראו עלייה של 20% בפתרון שירות עצמי

00:05:53.600 --> 00:05:57.760
לקוחות מצאו תשובות בעצמם לעתים קרובות יותר מבלי להזדקק לפנייה לתמיכה

00:05:57.760 --> 00:06:03.280
לקוחות אחרים באותו מחקר מקרה ראו הפחתה של עד 40% בזמן הפתרון עבור פניות תמיכה

00:06:03.280 --> 00:06:05.980
זה אומר שנציגים מצאו את המידע הנכון מהר יותר

00:06:05.980 --> 00:06:08.980
לקוחות קיבלו תשובות מהר יותר ועלות התמיכה ירדה

00:06:08.980 --> 00:06:12.220
זו לא רק תכונה נחמדה, זו השפעה מדידה על השורה התחתונה

00:06:12.220 --> 00:06:13.460
זו נקודת המפתח

00:06:13.460 --> 00:06:16.640
חיפוש היברידי הוא לא רק שדרוג נחמד או סימון בתיבת רשימת תכונות

00:06:16.640 --> 00:06:17.800
הוא טוב יותר באופן מדיד

00:06:17.800 --> 00:06:21.320
הוא מספק דיוק טוב יותר, שליפה טובה יותר ותוצאות טובות יותר עבור המשתמש

00:06:21.320 --> 00:06:26.280
והשילוב הזה של גישות הוא מה שהופך את Azure AI Search לך עוצמתי עבור יישומים מודרניים

00:06:26.280 --> 00:06:30.800
אבל יש טכנולוגיה נוספת שהשילוב הזה מאפשר כזו שזוכה להרבה תשומת לב כרגע

00:06:30.800 --> 00:06:32.900
קוראים לזה REG, הרג קונקשון

00:06:32.900 --> 00:06:34.220
אז בואו נדבר על REG

00:06:34.220 --> 00:06:37.140
REG מייצג Retrieval Augmented Generation, יצירה מואשרת בשליפה

00:06:37.140 --> 00:06:39.760
זה נשמע מורכב, אבל הנה ההגדרה הפשוטה ביותר

00:06:39.760 --> 00:06:43.580
זוהי מסגרת שנותנת לעוזרי AI גישה על המידע שעליו הם לא הומנו

00:06:43.580 --> 00:06:47.960
מודלי שפה גדולים כמו GPT יודעים הרבה על היסטוריה, מדע ותכנות

00:06:47.960 --> 00:06:54.920
אבל הם לא מכירים את המסמכים הפנימיים, המדיניות, היסטוריית הלקוחות או הנהלים הספציפיים שהצוות שלכם עוקב אחריהם

00:06:54.920 --> 00:06:59.400
רוב האנשים חושבים שפשוט אפשר להזרים את כל הידע הפנימי הזה לתוך המודל עצמו

00:06:59.400 --> 00:07:01.800
זה לא עובד, זה יקר וקשה לעדכון

00:07:01.800 --> 00:07:03.740
REG פותר את זה בדרך חכמה

00:07:03.740 --> 00:07:09.540
במקום לדחוס הכל לתוך המודל, אתם שולפים את המידע הרלוונטי ממאגר ידע ברגע שמישהו שואל שאלה

00:07:09.540 --> 00:07:17.120
אתם לוקחים את השאילתה של המשתמש, מחפשים בנתונים הפנימיים שלכם, מוצאים את המסמכים הרלוונטיים ביותר ומזינים את ההקשר הזה לתוך ה-LLM יחד עם השאלה המקורית

00:07:17.120 --> 00:07:20.260
ה-LLM לאחר מכן מייצר תשובה המבוססת על הנתונים שלכם

00:07:20.260 --> 00:07:21.360
זה הקסם שבדבר

00:07:21.360 --> 00:07:24.680
כעת Azure Eye Search הוא חצי השליפה של המשוואה הזו

00:07:24.680 --> 00:07:28.960
זה המנוע שמוצא את המסמכים הנכונים כדי שה-LLM יוכל לענות בצורה מדויקת

00:07:28.960 --> 00:07:33.260
ללא שכבת שליפה היתנה, מערכת REG טובה רק כתיב המסמכים שהיא מוצאת

00:07:33.260 --> 00:07:34.960
וכאן חיפוש היברידי באמת מבריק

00:07:34.960 --> 00:07:37.340
כי שאילתות REG הן לרוב שאלות בשפה טבעית

00:07:37.340 --> 00:07:41.000
והתשובות לרוב נמצאות במסמכים המשתמשים בטרמינולוגיה שונה לחלוטין

00:07:41.000 --> 00:07:44.060
תנו לי לתת לכם כמה מספרים שבאמת מראים את ההבדל

00:07:44.060 --> 00:07:47.300
מחקר על חיפוש בישומי ארגון מצא שמסגרת REG היברידית

00:07:47.300 --> 00:07:50.840
שיפרה את דיוק השליפה של הטופ-KP-18 עד 20 ו-5

00:07:50.840 --> 00:07:52.740
בהשוואה לחיפוש מילות מפתח בלבד

00:07:52.740 --> 00:07:56.040
דיוק השלמת משימות בזרימת עבודה השתפר P-21

00:07:56.040 --> 00:07:58.560
זה אומר שמשתמשים היו בעלי סיכוי גבוה בהרבה

00:07:58.560 --> 00:08:00.180
להשלים בהצלחה משימות מורכבות

00:08:00.180 --> 00:08:02.920
כאשר נתמכו על ידי מערכת REG המשתמשת בחיפוש היברידי

00:08:02.920 --> 00:08:04.900
בסך הכל, מערכות REG שיוסמו כראוי

00:08:04.900 --> 00:08:07.480
יכולות להגביר את דיוק החיפוש בממוצע של 85%

00:08:07.480 --> 00:08:11.080
כאשר בתחומים מיוחדים מסוימים זה מתקרב למד מינוס 99% דיוק

00:08:11.080 --> 00:08:15.660
ומכיוון שהLLM מייצר תשובות בהתבסס על הקשר שנשלף ולא על ניחושי משלו

00:08:15.660 --> 00:08:19.160
מערכות REG הראו הפחתה של קף מינוס 40% בתשובות הזויות

00:08:19.160 --> 00:08:23.440
זו הסיבה ש-Azure Eye Search הוא מרכזי לבניית סוכני AI ו-K-Pilots

00:08:23.440 --> 00:08:28.520
הוא מספק את השליפה המבוססת על עובדות שהופכת מודלי שפה למאמנים בהקשר עסקי

00:08:28.520 --> 00:08:32.520
אם אתם בונים עוזר שצריך לענות על שאלות בדיוק ולציין את מקורותיו

00:08:32.520 --> 00:08:35.560
חיפוש היברידי בשילוב REG הוא הארכיטקטורה שתבחרו בה

00:08:35.560 --> 00:08:38.840
אז חיפוש היברידי יחד עם REG הוא שילוב עוצמתי

00:08:38.840 --> 00:08:40.960
אבל איך זה נראה בפועל?

00:08:41.000 --> 00:08:42.460
ההשפעה בעולם האמיתי

00:08:42.460 --> 00:08:44.680
אז איפה זה באמת בא לידי ביטוי בשטח?

00:08:44.800 --> 00:08:46.260
תן לי לתת לכם כמה דוגמאות

00:08:46.260 --> 00:08:48.780
מסחר אלקטרוני הוא כנראה הדוגמה המוכרת ביותר

00:08:48.780 --> 00:08:51.620
לקוח מקליד נעלי ריצה נוחות בשורת החיפוש

00:08:51.620 --> 00:08:54.700
רישום המוצר עשוי לומר הנעלה אתלטית מרופדת

00:08:54.700 --> 00:08:56.460
כי צוות השיווק בחר מילים אחרות

00:08:56.460 --> 00:08:59.700
חיפוש מילות מפתח בלבד היה מחמיץ את ההתאמה לחלוטין

00:08:59.700 --> 00:09:00.980
עם Azure Eye Search

00:09:00.980 --> 00:09:05.160
המערכת מבינה שנוח ומרופד זה בערך אותו דבר בהקשר הזה

00:09:05.160 --> 00:09:08.280
זה מציף את המוצר הנכון גם כשהמילים לא תואמות

00:09:08.280 --> 00:09:11.740
זה לקוח שמוצא את מה שהוא מחפש במקום לעזוב את האתר מתוסכל

00:09:11.740 --> 00:09:14.240
פורטלים של תמיכת לקוחות עובדים באותה צורה

00:09:14.240 --> 00:09:17.140
דמיינו לקוח שמקליד איך אני מבטל את המינוי שלי

00:09:17.140 --> 00:09:21.040
המדיניות הרלוונטית עשויה להיות תחת הכותרת סיום הסכם שירות

00:09:21.040 --> 00:09:26.320
חיפוש היברידי מוצא את המסמך המדויק באמצעות התאמת מילות מפתח על טרמינולוגיה משפטית

00:09:26.320 --> 00:09:31.140
אך גם מציף דף שאלות נפוצות קשור על סיום מוקדם של התוכנית דרך דמיון סמנטי

00:09:31.140 --> 00:09:35.760
הלקוח מקבל תשובה מקיפה במקום לנבור בחמישה מאמרים שונים

00:09:35.760 --> 00:09:38.160
החזור מסמכים משפטיים הוא עוד דוגמה

00:09:38.160 --> 00:09:42.680
עורכי דין צריכים לחפש חוזים לפי מספרי סעיפים מדויקים והפניות לפרקים

00:09:42.680 --> 00:09:44.440
זה שטח מובהק של מילות מפתח

00:09:44.440 --> 00:09:48.620
אבל הם גם צריכים למצוא ניסוח דומה בהסכמים שונים גם כשהניסוח משתנה

00:09:48.620 --> 00:09:51.100
חיפוש היברידי מטפל בשניהם בשאיל תא אחת

00:09:51.100 --> 00:09:56.180
ובתעשיות מוסדרות היכולת לעקוב בדיוק אחרי הסיבה להופעת תוצאה היא קריטית לצורכי תאימות

00:09:56.180 --> 00:09:58.400
גם מאגרי ידע פנימיים נהנים מכך

00:09:58.400 --> 00:10:02.560
עובד שמחפש מדיניות חופשות מקבל את מסמך משאבי האנוש הרשמי

00:10:02.560 --> 00:10:06.380
אבל גם אימייל קשור מצוות משפטי לגבי ימי חופשה שנותרו

00:10:06.380 --> 00:10:08.780
ועדכון אחרון שפורסם ברשת הארגונית

00:10:08.780 --> 00:10:12.180
החיפוש מבין שכל אלה קשורים לאותה שאלה

00:10:12.180 --> 00:10:15.340
ייצור הוא דוגמה פחות ברורה אך עוצמתית

00:10:15.340 --> 00:10:19.140
טכנאי מקליד תיקון התחממות מנוע בממשק החיפוש

00:10:19.140 --> 00:10:22.520
המערכת מחזירה את פרק פתרון הבעיות מתוך מדריך הציוד

00:10:22.520 --> 00:10:25.380
בתוספת תרשים שרוק שמראה את החלקים הרלוונטיים

00:10:25.380 --> 00:10:30.080
למרות שהתרשים הוא תמונה Azure Eye Search יכול לחלץ ולהנדקס את תוכן הטקסט שלו

00:10:30.080 --> 00:10:31.720
כך שהוא מופיע בתוצאות החיפוש

00:10:31.720 --> 00:10:34.840
החוט המקשר בין כל הדוגמאות האלה הוא נתונים לא מובנים

00:10:34.840 --> 00:10:38.640
קובצי PDF, מסמכי Word, כרטיסי תמיכה באימייל, תמונות סרוקות

00:10:38.640 --> 00:10:42.720
שאילתות מסדי נתונים מסורתיות וחיפוש מילות מפתח מעולם לא תוכננו לסוג כזה של נתונים

00:10:42.720 --> 00:10:45.040
Azure Eye Search בנוי במיוחד לעולם הזה

00:10:45.040 --> 00:10:49.100
וככל שמסתכלים על זה יותר מתברר שחיפוש היברידי הוא לא רק פיצ'ר נחמד

00:10:49.100 --> 00:10:52.320
זהו נדבח יסודי באופן שבו נבנות אפליקציות מודרניות

00:10:52.320 --> 00:10:54.020
איך החלקים משתלבים יחד?

00:10:54.160 --> 00:10:56.380
אז איך כל זה עובד באמת מאחורי הקלעים?

00:10:56.380 --> 00:10:59.420
ל-Azure Eye Search יש שלושה אבני בניין מרכזיות

00:10:59.420 --> 00:11:01.820
מקור הנתונים, האינדקסר ואינדקס החיפוש

00:11:01.820 --> 00:11:04.520
מקור הנתונים הוא המקום שבו המידע שלך נמצא

00:11:04.520 --> 00:11:09.260
זה יכול להיות איחסון בלוב, מסד נתונים Azure SQL, Cosmos DB או אפילו SharePoint

00:11:09.260 --> 00:11:12.020
זהו חומר הגלם שצריך להפוך לניתן לחיפוש

00:11:12.020 --> 00:11:14.920
תחשוב על זה כעל ארימת מסמכים שמחכה לארגון

00:11:14.920 --> 00:11:21.120
האינדקסר הוא הצינור שקורא נתונים מהמקור, מחלץ את התוכן, מיישם האשרת AI שהגדרת

00:11:21.120 --> 00:11:23.080
ואז בונה את אינדקס החיפוש

00:11:23.080 --> 00:11:25.100
הנה דרך פשוטה לדמיין את זה

00:11:25.100 --> 00:11:28.080
דמיין ספרן שנכנס למחסן מלא בספרים

00:11:28.080 --> 00:11:32.660
הוא קורא כל אחד מהם רושם הערות מפורטות, מזהה נושאים מרכזיים וישויות

00:11:32.660 --> 00:11:34.560
ומארגן את הכל בקטלוג כרטיסיות

00:11:34.560 --> 00:11:37.100
הקריאה והרישום האלו הם תהליך האינדוקס

00:11:37.100 --> 00:11:39.380
אינדקס החיפוש הוא כתלוג הכרטיסיות הזה

00:11:39.380 --> 00:11:40.680
הוא לא הספרים עצמם

00:11:40.680 --> 00:11:45.600
זו המערכת המובנית והאופטימלית שמאפשרת לך למצוא בדיוק את מה שאתה צריך במי לשניות

00:11:45.600 --> 00:11:50.060
כשאתה מקליד שאילת, המערכת לא חוזרת למסמכי המקור כדי לסרוק אותם

00:11:50.060 --> 00:11:54.300
במקום זאת, היא בודקת באינדקס שכבר יודע בדיוק איפה כל דבר נמצא

00:11:54.300 --> 00:11:56.760
הארגון המוקדם הזה נקרא אינדקס הפוך

00:11:56.760 --> 00:11:59.360
במקום להכסן מסמכים עם רשימת המילים שהם מכילים

00:11:59.360 --> 00:12:01.900
אתה מאכסן מילים עם רשימת המסמכים שבהם הן מופיעות

00:12:01.900 --> 00:12:05.160
זה אומר שכאשר אתה מחפש מונח, אתה קופץ ישר למקום הנכון

00:12:05.160 --> 00:12:06.640
בלי לדפדף בכל עמוד

00:12:06.640 --> 00:12:08.580
התוצאה היא שיפור עצום במהירות

00:12:08.580 --> 00:12:10.460
במקום הצורך לסרוק כל מסמך

00:12:10.460 --> 00:12:13.020
מה שלוקח יותר זמן ככל שהנתונים שלך גדלים

00:12:13.020 --> 00:12:14.720
אתה קופץ ישר למיקום הנכון

00:12:14.720 --> 00:12:16.660
עם מיליוני מסמכים, ההבדל הזה

00:12:16.660 --> 00:12:18.560
הוא ההבדל בין חיפוש שלוקח שניות

00:12:18.560 --> 00:12:20.040
לחיפוש שלוקח מילי שניות

00:12:20.040 --> 00:12:22.260
אז עכשיו אתה מבין מהו Azure Eye Search

00:12:22.260 --> 00:12:23.900
איך המרכיבים המרכזיים משתלבים

00:12:23.900 --> 00:12:26.060
ומדוא החיפוש היברידי משנה את כללי המשחק

00:12:26.060 --> 00:12:28.780
בוא נסכם עם כמה דברים שבאמת אפשר לעשות עם זה

00:12:28.780 --> 00:12:30.700
ראשית, הבן את הנתונים שלך

00:12:30.700 --> 00:12:33.300
אם הם כבר מובנים, כמו טבלאות מוצרים בסקיואל

00:12:33.300 --> 00:12:34.940
רשומות לקוחות במסד נתונים

00:12:34.940 --> 00:12:37.040
כל דבר עם שורות ועמודות נקיות

00:12:37.040 --> 00:12:38.960
אפשר לתשאל אותם ישירות בסקיואל

00:12:38.960 --> 00:12:41.420
Azure Eye Search בנוי לטקסט לא מובנה

00:12:41.420 --> 00:12:45.040
זה כולל קבצי PDF, מיילים, מסמכי וורד וחרטיסי תמיכה

00:12:45.040 --> 00:12:46.600
שם הוא מספק ערך אמיתי

00:12:46.600 --> 00:12:49.680
שנית, אם אתה בונה אפליקציית רג או עוזר Eye

00:12:49.680 --> 00:12:51.780
Azure Eye Search עם חיפוש היברידי

00:12:51.780 --> 00:12:53.880
הוא מנוע השליפה שאתה רוצה מאחוריו

00:12:53.880 --> 00:12:56.900
הוא נותן לך חתאמות מדויקות של מילות מפתח לדיוק

00:12:56.900 --> 00:12:58.400
והבנה סמנטית להקשר

00:12:58.400 --> 00:13:03.020
השילוב הזה מפיק תשובות אמינות ונוחות לציטוט יותר מכל גישה אחרת בפני עצמה

00:13:03.020 --> 00:13:05.740
שלישית, אל תסבכו את ההגדרה יתר על המידה

00:13:05.740 --> 00:13:07.820
בפורטל Azure יש אשף לאיבון נתונים

00:13:07.820 --> 00:13:09.900
חברו את איחסון הבלוב, הגדירו כמה הגדרות

00:13:09.900 --> 00:13:11.920
ותנו לאינדקסר לבנות את האינדקס הראשון שלכם

00:13:11.920 --> 00:13:14.320
תוכלו להריץ את החיפוש הראשון שלכם בפחות משעה

00:13:14.320 --> 00:13:16.480
אז זה Azure Eye Search במילים פשוטות

00:13:16.480 --> 00:13:18.300
הוא לוקח מידע מבולגן ולא מובנה

00:13:18.300 --> 00:13:21.060
והופך אותו לידע שניתן לחפש בו ומוכן לבינה מלאכותית