embeddings: איך ייצוג מספרי מאפשר חיפוש לפי משמעות

מה הם embeddings ואיך הם מאפשרים חיפוש לפי משמעות

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

לפי תיעוד של Google לייצוגי טקסט, הווקטורים נועדו לייצג את משמעות הטקסט, ולכן אפשר לחפש קטעים שמתאימים למשמעות השאילתה ולא רק להתאמה מדויקת של מילים. התיעוד מציין למשל שהמודל gemini-embedding-001 מפיק וקטורים בני 3072 ממדים. בדוגמת הקוד של Microsoft למודל text-embedding-ada-002 התוצאה היא וקטור בן 1,536 ממדים.

סקירת החיפוש הווקטורי של Microsoft נותנת דוגמה פשוטה: המילים "dog" ו"canine" שונות בכתיבה אך קרובות במשמעות, וחיפוש וקטורי יכול לקשר ביניהן.

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

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

איך מסמך הופך לתוצאת חיפוש ולעיתים לתשובה

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

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

למה מחלקים לקטעים

מודלי embeddings מקבלים כמות מוגבלת של טקסט. לפי התיעוד על חלוקת מסמכים, הקלט המרבי של המודל text-embedding-3-small הוא 8,191 טוקנים, שהם בערך 6,000 מילים באנגלית. חלוקה לקטעים מונעת איבוד מידע בגלל חיתוך. היא גם עוזרת כשעמוד אחד מכסה נושאים רבים, כי ייצוג אחד לכל העמוד מייצג אותם גרוע.

התיעוד מציג כמה שיטות: קטעים בגודל קבוע, קטעים בגודל משתנה לפי סימני פיסוק או כותרות, וקטעים סמנטיים ששומרים על הקשר. כנקודת פתיחה הוא ממליץ על קטעים של 512 טוקנים (כ־2,000 תווים) עם חפיפה של 25%, והחפיפה נועדה לשמור על רצף. הוא מוסיף שהגודל המתאים משתנה לפי מבנה המסמכים והשאלות הצפויות. לספירה משוערת של טוקנים בטקסט שלכם אפשר להשתמש במחשבון הטוקנים המשוער.

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

מחיפוש לתשובה

כאשר מעבירים את הקטעים שנמצאו למודל שפה כדי שינסח תשובה, החיפוש משתלב בתהליך שנקרא RAG. ה־embeddings תומכים באיתור המידע, ומודל השפה מנסח את המענה על בסיס המידע שהועבר אליו. במדריך על חיבור בינה מלאכותית למסמכי העסק מוסבר התהליך הרחב יותר.

מתי השימוש מועיל ומה הוא לא פותר

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

האפשרות לחיפוש בין שפות תלויה ביכולות של המודל שנבחר. לפי סקירת החיפוש הווקטורי של Microsoft, חיפוש רב־לשוני דורש מודלי embeddings שאומנו בכמה שפות. לכן בעברית כדאי לבדוק את המודל על תוכן אמיתי לפני שמחליטים.

מילות מפתח, סינון וחיפוש משולב

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

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

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

מה לבדוק לפני שמזמינים פתרון לעסק

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

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

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

לגבי עלות, לפי סקירת Microsoft החיפוש הווקטורי עצמו ב־Azure AI Search אינו כרוך בתשלום נוסף, אך יצירת embeddings עשויה להיות כרוכה בחיוב של ספק המודל. בקשו לראות את החיוב הזה מפורט בהצעה, ובדקו את התעריף העדכני באתר הספק לפני החלטה.

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