תארו לעצמכם את זה. אתם עובדים ביישום כלשהו בחברה שלכם. אולי זה פורטל משאבי אנוש, מאגר תמיכה בלקוחות או הוויקי הפנימי עם כל הנהלים שצריך להכיר. אתם מקלידים שאלה בשורת החיפוש. משהו כמו, איך אני מגיש דוח הוצאות על ארוחת ערב עסקי? אתם לוחצים על Enter ומה אתם מקבלים? כלום. או גרוע מכך, רשימה של קבצי PDF אקראיים מלפני שלוש שנים שבערך תואמים למילים שהקלדתם. חיפוש הוא משהו שאנחנו משתמשים בו בכל יום, וברוב המקרים הוא נורא. אבל הנה העניין, זה לא חייב להיות ככה. מה אם היישומים שלכם יכלו באמת להבין מה אתם שואלים? מה אם הם יכלו לחפש כמו שגוגל עושה ולמצוא את התשובה הנכונה גם כשלא משתמשים במילים המדויקות? היום אנחנו עוסקים ב-Azure Eye Search. מה זה בעצם? איך זה עובד מאחורי הקלעים? ומדוע זה מנוע החיפוש שעליו נבנים יישומים מודרניים? קחו את הקפה שלכם ובואו נצלול פנימה. מדוע החיפוש שבור? כדי להבין מדוע החיפוש בדרך כלל נכשל, עלינו לבחון איך רוב היישומים באמת עושים זאת. הדרך המסורתית נקראת חיפוש מילות מפתח או חיפוש לקסיקלי.

אתם מקלידים את המילה, מחשב נייד, בטבע, והמערכת יוצאת למצוא כל מסמך שמכיל בדיוק את המילה הזו. מאחורי הקלעים, הרבה מהמערכות הללו משתמשות באלגוריתם שנקרא BM25. זה לא מסובך, אבל זה חכם בדרכו שלו. BM25 מדרג תוצאות על סמך כמה דברים. באיזו תדירות מונח החיפוש שלכם מופיע במסמך, מהו אורך המסמך ועד כמה המונח נדיר בכל מאגר הנתונים. חישבו על זה כעל מונה מילים מתוחכם מאוד שמבין אילו מסמכים הם הרלוונטיים ביותר על בסיס הגורמים הללו. כאן זה מתפרק. שפה אנושית היא מבולגנת. אנשים לא שואלים שאלות באמצעות אותן מילים שבהן המסמכים משתמשים. תן לי לתת לכם דוגמה קונקרטית. משתמש מקליד את זה בפורטל תמיכה. המחשב הנייד שלי ממשיך לקפוא במהלך שיחות וידאו. חיפוש מילות מפתח יחפש בחריצות מסמכים המכילים מחשב נייד, כופה במהלך שיחות ווידאו. אבל מה אם המאמר הטוב ביותר בנושא נקרא פתרון תקלות של כפיאת מערכת במהלך פגישות טימס? או ניהול אומס מעבד במחשבים ניידים מחוברים לתחנת הגינה. חיפוש מילות המפתח מפספס אותם לחלוטין. למה? כי המילים לא תואמות.

הבעיה המרכזית היא זו. חיפוש מילות מפתח מבין איות. הוא מבין תבניות של תווים, אבל הוא לא מבין משמעות. אתם מקבלים תוצאות שיש להן את האותיות הנכונות, אבל לרוב את התוכן הלא נכון. אז אם התאמת מילים מדויקת משאירה כל כך הרבה פערים, מהי החלופה? הדרך החדשה, חיפוש וקטורי. אז, חיפוש וקטורי זו דרך שונה לחלוטין לעשות דברים. במקום להתאים מילים מדויקות, הוא מתאים משמעות. זה נשמע מופשט, אז בואו נפרק את זה. ההגדרה הפשוטה ביותר שצריך לדעת היא זו. וקטור הוא פשוט רשימה של מספרים שמייצג את משהו שמחשב יכול לעבוד איתו. זה הכל רשימה של מספרים. אמבדינג, שיקון, הוא סוג מיוחד של וקטור שתופס את המשמעות של טקסט. הוא לוקח משפט, פסקה או אפילו מסמך שלם, והופך אותו לרשימה ארוכה של מספרים. המחשב לא מבין את המילים, אבל הוא מבין את המספרים. הנה האנלוגיה שעוזרת. תחשבו על וקטורים כמו קואורדינטות על מפה. על מפה, מקומות דומים נמצאים קרוב זה לזה. במרחב וקטורי, מושגים דומים מסתיימים קרוב זה לזה. פוקטור של מלך, והווקטור של מלכה קרובים זה לזה כי הם מייצגים רעיונות קשורים.

פוקטור של מלך, והווקטור של תפוח רחוקים מאוד. המחשב לא יודע מה מלך אומר במובן אנושי, אבל הוא יכול למדוד את המרחק בין הקואורדינטות שלו לקואורדינטות של כל מילה או מסמך אחר. זה כמו להחזיק GPS לרעיונות המערכת יודעת כמה רחוקים המושגים זה מזה רק על ידי הסתכלות על המספרים כשמחפשים באמצעות וקטורים, המערכת ממירה את השאילתה שלכם לאמבדינג לאחר מכן היא מוצאת את המסמכים שהאמבדינג שלהם הכי קרובים לשלכם היא מוצאת דברים שהם דומים סמנטית, שחולקים משמעות, לא רק עוצר מילים תארו לעצמכם שאתם מחפשים מסמך על פתרון בעיות במחשב נייד כפו אם חיפוש מילות מפתח, תצטרכו להקליד, קופה או נתקה בדיוק אבל אם חיפוש וקטורי, אתם יכולים להקליד, המחשב שלי ממשיך להינעל והוא ימצא את המסמך הנכון זה הכוח של הבנת משמעות בואו נחזור לדוגמת החיפוש השבורה שלנו משתמש מקליד, המחשב הנייד שלי ממשיך לקפו אם חיפוש וקטורי, המערכת יכולה להחזיר את המאמר על תקיעות מערכת במהלך פגישות טימס למרות שאף אחת מהמילים הללו לא מופיעה בשאילתה למה? כי המשמעות של תקיעות מערכת קרובה מאוד לקפיאת מחשב במרחב וקטורי המושגים האלה חיים קרוב זה אלה זה על המפה ההיא למערכת לא אכפת מהמילים המדויקות, אכפת לה ממה שאתם מתכוונים זוהי פריצת הדרך מחשבים מתחילים להווים כוונה, לא רק איות הם מוצאים תשובות שחיפוש מילות מפתח יחמיץ לחלוטין אבל לחיפוש וקטורי יש גם חולשה הוא עלול להחמיץ התאמות מדויקות שהן קריטיות לחלוטין אם טכנאי מחפש קוד שגיאה ספציפי כמו X80070570 חיפוש וקטורי עשוי לתעדף מסמכים על שגיאות דיסק או שחיתות במערכת הקבצים במקום את המסמך המדויק שמנתח את הקוד הספציפי הזה הוא מקריב דיוק לטובת הבנה אז יש לנו שתי שיטות חיפוש לפי מילות מפתח מצוין לדיוק הוא פוגע בול במונחים מדויקים, מזהי מוצר ומספרי חוזים חיפוש וקטורי מצוין למשמעות הוא מוצא את התשובה הנכונה גם כשלא משתמשים במילים הנכונות לכל אחד מהם יש נקודות עברות וזה מעלה שאלה מתבקשת מה אם אפשר היה לשלב בין שתי הגישות ולהנות מכל העולמות ריצת הדרך ההיברידית חיפוש היברידי הוא הטוב מכל העולמות הוא מריץ חיפוש מילות מפתח וחיפוש וקטורי בו זמנית ואז מאחד את התוצאות לרשימה מדורגת אחת במקום לבחור בגישה אחת על פני השנייה המערכת משתמשת בשיטה שנקראת איכות דירוג הדדי או RRF כך זה עובד RRF בוחן היכן כל מסמך מדורג בתוצאות מילות המפתח והיכן הוא מדורג בתוצאות הוקטוריות לאחר מכן הוא נותן ציון משוקלל אם מסמך מדורג היטב בשניהם הוא מקבל דחיפה זה כמו לקחת שתי חוות דעת של מומחים ולמצוא להן ממוצע התשובה הסופית אמינה יותר מכל אחת מהן בנפרד זה חשוב כי לחיפוש מילות מפתח וחיפוש וקטורי יש חוזקות שונות מהותית חיפוש מילות מפתח מצטיין בהתאמות מדויקות הוא הבחירה המועדפת למזהי מוצר, מספרי חוזים, שמות ספציפיים וקודי שגיעה הוא מדויק וצפוי חיפוש וקטורי מצטיין בדמיון סמנטי הוא מציאת מסמכים שחולקים משמעות עם השאילתה שלך גם כשהמילים המדויקות אינן מופיעות יחד הם מכסים את הנקודות העברות זה של זה המערכת תופסת התאמות מדויקות והתאמות רעיוניות בשאילתה אחת זה הכוח האמיתי וזה לא רק תיאורטי מחקר על חיפוש ארגוני היברידי מראה שהוא מספק 70-80% דיוק בשליפה תלוי במערך הנתונים זה בערך 15-20% הפרש יותר ממה שמקבלים בחיפוש וקטורי בלבד ההבדל משמעותי והוא בא לידי ביטוי בתוצאות עסקיות אמיתיות קחו למשל את פלטפורמת הנהלת החשבונות Zero הם התמיעו חיפוש היברידי בחוויית תמיכת הלקוחות שלהם דרך חברה בשם קוווי בתוך שלושה חודשים הם ראו עלייה של 20% בפתרון שירות עצמי לקוחות מצאו תשובות בעצמם לעתים קרובות יותר מבלי להזדקק לפנייה לתמיכה לקוחות אחרים באותו מחקר מקרה ראו הפחתה של עד 40% בזמן הפתרון עבור פניות תמיכה זה אומר שנציגים מצאו את המידע הנכון מהר יותר לקוחות קיבלו תשובות מהר יותר ועלות התמיכה ירדה זו לא רק תכונה נחמדה, זו השפעה מדידה על השורה התחתונה זו נקודת המפתח חיפוש היברידי הוא לא רק שדרוג נחמד או סימון בתיבת רשימת תכונות הוא טוב יותר באופן מדיד הוא מספק דיוק טוב יותר, שליפה טובה יותר ותוצאות טובות יותר עבור המשתמש והשילוב הזה של גישות הוא מה שהופך את Azure AI Search לך עוצמתי עבור יישומים מודרניים אבל יש טכנולוגיה נוספת שהשילוב הזה מאפשר כזו שזוכה להרבה תשומת לב כרגע קוראים לזה REG, הרג קונקשון אז בואו נדבר על REG REG מייצג Retrieval Augmented Generation, יצירה מואשרת בשליפה זה נשמע מורכב, אבל הנה ההגדרה הפשוטה ביותר זוהי מסגרת שנותנת לעוזרי AI גישה על המידע שעליו הם לא הומנו מודלי שפה גדולים כמו GPT יודעים הרבה על היסטוריה, מדע ותכנות אבל הם לא מכירים את המסמכים הפנימיים, המדיניות, היסטוריית הלקוחות או הנהלים הספציפיים שהצוות שלכם עוקב אחריהם רוב האנשים חושבים שפשוט אפשר להזרים את כל הידע הפנימי הזה לתוך המודל עצמו זה לא עובד, זה יקר וקשה לעדכון REG פותר את זה בדרך חכמה במקום לדחוס הכל לתוך המודל, אתם שולפים את המידע הרלוונטי ממאגר ידע ברגע שמישהו שואל שאלה אתם לוקחים את השאילתה של המשתמש, מחפשים בנתונים הפנימיים שלכם, מוצאים את המסמכים הרלוונטיים ביותר ומזינים את ההקשר הזה לתוך ה-LLM יחד עם השאלה המקורית ה-LLM לאחר מכן מייצר תשובה המבוססת על הנתונים שלכם זה הקסם שבדבר כעת Azure Eye Search הוא חצי השליפה של המשוואה הזו זה המנוע שמוצא את המסמכים הנכונים כדי שה-LLM יוכל לענות בצורה מדויקת ללא שכבת שליפה היתנה, מערכת REG טובה רק כתיב המסמכים שהיא מוצאת וכאן חיפוש היברידי באמת מבריק כי שאילתות REG הן לרוב שאלות בשפה טבעית והתשובות לרוב נמצאות במסמכים המשתמשים בטרמינולוגיה שונה לחלוטין תנו לי לתת לכם כמה מספרים שבאמת מראים את ההבדל מחקר על חיפוש בישומי ארגון מצא שמסגרת REG היברידית שיפרה את דיוק השליפה של הטופ-KP-18 עד 20 ו-5 בהשוואה לחיפוש מילות מפתח בלבד דיוק השלמת משימות בזרימת עבודה השתפר P-21 זה אומר שמשתמשים היו בעלי סיכוי גבוה בהרבה להשלים בהצלחה משימות מורכבות כאשר נתמכו על ידי מערכת REG המשתמשת בחיפוש היברידי בסך הכל, מערכות REG שיוסמו כראוי יכולות להגביר את דיוק החיפוש בממוצע של 85% כאשר בתחומים מיוחדים מסוימים זה מתקרב למד מינוס 99% דיוק ומכיוון שהLLM מייצר תשובות בהתבסס על הקשר שנשלף ולא על ניחושי משלו מערכות REG הראו הפחתה של קף מינוס 40% בתשובות הזויות זו הסיבה ש-Azure Eye Search הוא מרכזי לבניית סוכני AI ו-K-Pilots הוא מספק את השליפה המבוססת על עובדות שהופכת מודלי שפה למאמנים בהקשר עסקי אם אתם בונים עוזר שצריך לענות על שאלות בדיוק ולציין את מקורותיו חיפוש היברידי בשילוב REG הוא הארכיטקטורה שתבחרו בה אז חיפוש היברידי יחד עם REG הוא שילוב עוצמתי אבל איך זה נראה בפועל?

ההשפעה בעולם האמיתי אז איפה זה באמת בא לידי ביטוי בשטח? תן לי לתת לכם כמה דוגמאות מסחר אלקטרוני הוא כנראה הדוגמה המוכרת ביותר לקוח מקליד נעלי ריצה נוחות בשורת החיפוש רישום המוצר עשוי לומר הנעלה אתלטית מרופדת כי צוות השיווק בחר מילים אחרות חיפוש מילות מפתח בלבד היה מחמיץ את ההתאמה לחלוטין עם Azure Eye Search המערכת מבינה שנוח ומרופד זה בערך אותו דבר בהקשר הזה זה מציף את המוצר הנכון גם כשהמילים לא תואמות זה לקוח שמוצא את מה שהוא מחפש במקום לעזוב את האתר מתוסכל פורטלים של תמיכת לקוחות עובדים באותה צורה דמיינו לקוח שמקליד איך אני מבטל את המינוי שלי המדיניות הרלוונטית עשויה להיות תחת הכותרת סיום הסכם שירות חיפוש היברידי מוצא את המסמך המדויק באמצעות התאמת מילות מפתח על טרמינולוגיה משפטית אך גם מציף דף שאלות נפוצות קשור על סיום מוקדם של התוכנית דרך דמיון סמנטי הלקוח מקבל תשובה מקיפה במקום לנבור בחמישה מאמרים שונים החזור מסמכים משפטיים הוא עוד דוגמה עורכי דין צריכים לחפש חוזים לפי מספרי סעיפים מדויקים והפניות לפרקים זה שטח מובהק של מילות מפתח אבל הם גם צריכים למצוא ניסוח דומה בהסכמים שונים גם כשהניסוח משתנה חיפוש היברידי מטפל בשניהם בשאיל תא אחת ובתעשיות מוסדרות היכולת לעקוב בדיוק אחרי הסיבה להופעת תוצאה היא קריטית לצורכי תאימות גם מאגרי ידע פנימיים נהנים מכך עובד שמחפש מדיניות חופשות מקבל את מסמך משאבי האנוש הרשמי אבל גם אימייל קשור מצוות משפטי לגבי ימי חופשה שנותרו ועדכון אחרון שפורסם ברשת הארגונית החיפוש מבין שכל אלה קשורים לאותה שאלה ייצור הוא דוגמה פחות ברורה אך עוצמתית טכנאי מקליד תיקון התחממות מנוע בממשק החיפוש המערכת מחזירה את פרק פתרון הבעיות מתוך מדריך הציוד בתוספת תרשים שרוק שמראה את החלקים הרלוונטיים למרות שהתרשים הוא תמונה Azure Eye Search יכול לחלץ ולהנדקס את תוכן הטקסט שלו כך שהוא מופיע בתוצאות החיפוש החוט המקשר בין כל הדוגמאות האלה הוא נתונים לא מובנים קובצי PDF, מסמכי Word, כרטיסי תמיכה באימייל, תמונות סרוקות שאילתות מסדי נתונים מסורתיות וחיפוש מילות מפתח מעולם לא תוכננו לסוג כזה של נתונים Azure Eye Search בנוי במיוחד לעולם הזה וככל שמסתכלים על זה יותר מתברר שחיפוש היברידי הוא לא רק פיצ'ר נחמד זהו נדבח יסודי באופן שבו נבנות אפליקציות מודרניות איך החלקים משתלבים יחד?

אז איך כל זה עובד באמת מאחורי הקלעים? ל-Azure Eye Search יש שלושה אבני בניין מרכזיות מקור הנתונים, האינדקסר ואינדקס החיפוש מקור הנתונים הוא המקום שבו המידע שלך נמצא זה יכול להיות איחסון בלוב, מסד נתונים Azure SQL, Cosmos DB או אפילו SharePoint זהו חומר הגלם שצריך להפוך לניתן לחיפוש תחשוב על זה כעל ארימת מסמכים שמחכה לארגון האינדקסר הוא הצינור שקורא נתונים מהמקור, מחלץ את התוכן, מיישם האשרת AI שהגדרת ואז בונה את אינדקס החיפוש הנה דרך פשוטה לדמיין את זה דמיין ספרן שנכנס למחסן מלא בספרים הוא קורא כל אחד מהם רושם הערות מפורטות, מזהה נושאים מרכזיים וישויות ומארגן את הכל בקטלוג כרטיסיות הקריאה והרישום האלו הם תהליך האינדוקס אינדקס החיפוש הוא כתלוג הכרטיסיות הזה הוא לא הספרים עצמם זו המערכת המובנית והאופטימלית שמאפשרת לך למצוא בדיוק את מה שאתה צריך במי לשניות כשאתה מקליד שאילת, המערכת לא חוזרת למסמכי המקור כדי לסרוק אותם במקום זאת, היא בודקת באינדקס שכבר יודע בדיוק איפה כל דבר נמצא הארגון המוקדם הזה נקרא אינדקס הפוך במקום להכסן מסמכים עם רשימת המילים שהם מכילים אתה מאכסן מילים עם רשימת המסמכים שבהם הן מופיעות זה אומר שכאשר אתה מחפש מונח, אתה קופץ ישר למקום הנכון בלי לדפדף בכל עמוד התוצאה היא שיפור עצום במהירות במקום הצורך לסרוק כל מסמך מה שלוקח יותר זמן ככל שהנתונים שלך גדלים אתה קופץ ישר למיקום הנכון עם מיליוני מסמכים, ההבדל הזה הוא ההבדל בין חיפוש שלוקח שניות לחיפוש שלוקח מילי שניות אז עכשיו אתה מבין מהו Azure Eye Search איך המרכיבים המרכזיים משתלבים ומדוא החיפוש היברידי משנה את כללי המשחק בוא נסכם עם כמה דברים שבאמת אפשר לעשות עם זה ראשית, הבן את הנתונים שלך אם הם כבר מובנים, כמו טבלאות מוצרים בסקיואל רשומות לקוחות במסד נתונים כל דבר עם שורות ועמודות נקיות אפשר לתשאל אותם ישירות בסקיואל Azure Eye Search בנוי לטקסט לא מובנה זה כולל קבצי PDF, מיילים, מסמכי וורד וחרטיסי תמיכה שם הוא מספק ערך אמיתי שנית, אם אתה בונה אפליקציית רג או עוזר Eye Azure Eye Search עם חיפוש היברידי הוא מנוע השליפה שאתה רוצה מאחוריו הוא נותן לך חתאמות מדויקות של מילות מפתח לדיוק והבנה סמנטית להקשר השילוב הזה מפיק תשובות אמינות ונוחות לציטוט יותר מכל גישה אחרת בפני עצמה שלישית, אל תסבכו את ההגדרה יתר על המידה בפורטל Azure יש אשף לאיבון נתונים חברו את איחסון הבלוב, הגדירו כמה הגדרות ותנו לאינדקסר לבנות את האינדקס הראשון שלכם תוכלו להריץ את החיפוש הראשון שלכם בפחות משעה אז זה Azure Eye Search במילים פשוטות הוא לוקח מידע מבולגן ולא מובנה והופך אותו לידע שניתן לחפש בו ומוכן לבינה מלאכותית