ייצוג וקטורי
המרה של טקסט לרשימת מספרים שמייצגת את המשמעות שלו, כך שקטעים בעלי משמעות דומה יוצאים קרובים זה לזה.
מסד וקטורי
Vector database
מאגר שמאחסן ייצוגים וקטוריים ומחזיר במהירות את הקטעים הקרובים ביותר לשאלה. זו התשתית שמאחורי שלב האחזור במערכות RAG. זה רכיב פנימי של המנוע, לא משהו שמפרסם מזין אליו תוכן.
עודכן:
מה בעצם שמור שם
מסד וקטורי מחזיק אוסף של רשימות מספרים, ולצד כל רשימה מצביע לקטע הטקסט שממנו היא נוצרה. הוא אינו מחזיק את המשמעות ואינו מבין דבר. הוא מחזיק מיקומים, ויודע לענות מהר מאוד על שאלה אחת: אילו מיקומים קרובים למיקום הזה. כל השאר, כולל השאלה מה ראוי להחזיר ומה לא, קורה מחוץ לו.
ההבחנה הזו נשמעת פדנטית וחוסכת כסף. מסד כזה אינו מחליט מה נכון, אינו יודע איזה מסמך עדכני יותר, ואינו מבחין בין נוהל בתוקף לנוהל שבוטל אשתקד, כי מבחינתו שניהם רק שתי נקודות במרחב. הוא תמיד יחזיר משהו. גם כשאין תשובה טובה בכלל, יחזרו עשרה קטעים, והם יהיו הקרובים ביותר לשאלה מתוך מה שהיה שם. האחריות להכריע ביניהם נופלת על השכבה שמעליו, ושם יושבת גם רוב העבודה האמיתית בפרויקטים כאלה.
למה המהירות היא כל העניין
אם היו מיליון קטעים ורוצים למצוא את העשרה הקרובים, השוואה ישרה מול כל אחד תיקח זמן שאף משתמש לא מוכן לחכות לו. לכן מסדים כאלה בונים מבנה אינדקס שמאפשר לוותר מראש על רוב האוסף. התוצאה מוחזרת בשברירי שנייה.
יש לזה מחיר, והוא מעניין גם למי שאינו מהנדס: החיפוש הוא מקורב ולא מדויק. המערכת מחזירה כמעט תמיד את השכנים הקרובים ביותר, ולעיתים מפספסת אחד. בפועל זה אומר שאותה שאלה עלולה להחזיר סט מקורות מעט שונה בפעמים שונות, וזו אחת הסיבות למה בדיקה בודדת של נראות אינה מדידה אלא דגימה.
איפה עסק באמת פוגש מסד כזה
לא בצד של מנועי החיפוש. שם זה רכיב פנימי שאין אליו גישה, אין בו חשבון ואין לאן להזין. הפגישה האמיתית קורית כשאתם בונים משהו משלכם: צאט שעונה ללקוחות מתוך מסמכי החברה, חיפוש חכם באתר על קטלוג גדול, או כלי פנימי שמאפשר לצוות למצוא תשובה בתוך נהלים.
בפרויקטים כאלה ההחלטות שקובעות את התוצאה כמעט לא נוגעות במסד עצמו. מה שקובע הוא איך חתכתם את המסמכים, אילו מסמכים בכלל הכנסתם, ומה קורה כשהתשובה לא נמצאת. ספק שמדבר איתכם בעיקר על סוג המסד ופחות על שלושת אלה כנראה מוכר לכם תשתית במקום פתרון.
יש כאן גם שיקול שנוטים לגלות מאוחר, והוא הרשאות. ברגע שכל המסמכים של החברה יושבים במאגר אחד, כלי שעונה לכל שואל עלול להחזיר לעובד זוטר קטע מתוך חוזה, מתוך נתוני שכר או מתוך מסמך שהוגדר פנימי, כי מבחינת המנגנון זה פשוט קטע קרוב לשאלה. הפרדה לפי קהל היא החלטה שצריך לקבל לפני ההטמעה ולא אחריה. כשמדובר בכלי שפונה ללקוחות מבחוץ, הכלל פשוט אף יותר: נכנס למאגר רק מה שאתם מוכנים שיופיע באתר הפומבי.
מה זה לא, ולמה זה דווקא מרגיע
זה לא ערוץ שיווקי ולא מקום שאפשר לקנות בו הופעה. אין הזנת תוכן למסדים של מנועים, ומי שמציע לכם להכניס את העסק למאגר הווקטורי של מנוע מסוים מוכר משהו שלא קיים. זה גם לא חיפוש סמנטי, שהוא ההתנהגות, ולא ייצוג וקטורי, שהוא מה שמאוחסן. ההפרדה הזו שווה לכם כסף בשיחה עם ספק. מה שכן קיים כערוץ נמצא במקום אחר לגמרי, בשני המסלולים שאנחנו עובדים בהם.
איך זה נראה בפועל
נניח יבואן ציוד מטבח מקצועי עם אלף פריטים בקטלוג ומחלקת שירות שעונה כל היום על אותן שאלות תאימות. הוא מחליט לבנות צאט באתר שיענה מתוך המפרטים והנהלים. הטקסטים נחתכים לקטעים, כל קטע מומר לרשימת מספרים, והכול נשמר במסד וקטורי.
לקוח שואל: האם הדגם הזה מתאים למתח תלת פאזי. המערכת ממירה את השאלה, שולפת חמישה קטעים קרובים, ומגישה אותם למודל שמנסח תשובה. כאן מתגלות שתי בעיות שאין להן שום קשר לטכנולוגיה. הראשונה, הקטעים נחתכו באמצע טבלת מפרט, ולכן מספר המתח נותק מהשורה שמציינת לאיזה דגם הוא שייך. השנייה, שני מסמכים סותרים נמצאים במאגר, כי המפרט הישן לא נמחק כשעלה החדש. המסד עשה את עבודתו במדויק. הוא החזיר את הקרובים ביותר, וזה לא אותו דבר כמו הנכונים ביותר.
זוויות שונות
לחנות מקוונת עם קטלוג גדול
חיפוש פנימי שמחזיר אפס תוצאות על ניסוח יומיומי הוא הפסד ישיר בסל, והוא בדיוק המקום שבו טכנולוגיה כזו משתלמת. לפני שקונים אותה כדאי להוציא מדוח החיפוש הפנימי את מאה השאילתות הנפוצות ולבדוק כמה מהן מחזירות תוצאה ריקה היום. אם המספר נמוך, הבעיה שלכם בכלל לא כאן.
לעסק שמחזיק הרבה ידע כתוב
משרדים שמנהלים נהלים, חוזים או מפרטים הם המועמדים הטבעיים, ושם התועלת נמדדת בזמן שהצוות מפסיק לבזבז. התנאי הקריטי הוא היגיינה של מקורות: גרסה אחת נכונה לכל מסמך, ומחיקה מסודרת של הישנות. מאגר עם שתי גרסאות סותרות מייצר תשובות בטוחות ושגויות, וזה גרוע יותר מלא לענות.
מה זה אומר בפועל
אם אתם בעלי עסק שמנסה להופיע בתשובות של מנועים, אין כאן משימה עבורכם, וזו מסקנה שראוי לומר במפורש. התקציב שלכם צריך ללכת לעמודים שאפשר לשלוף. אם לעומת זאת אתם שוקלים לבנות כלי משלכם, התחילו מלמדוד את הבעיה ולא מלבחור ספק: כמה פניות חוזרות בחודש, על אילו שאלות, וכמה זמן צוות מוציא עליהן. אחר כך בדקו אם המידע בכלל כתוב במקום אחד ובגרסה אחת. ברוב הפרויקטים שנכשלים, הכשל היה בשלב הזה ולא בטכנולוגיה. ויש מבחן זול שכדאי להריץ לפני שמשלמים: קחו חמש שאלות אמיתיות, הדביקו ידנית לצאט כללי את המסמכים שאמורים לענות עליהן, ובדקו אם התשובה שיוצאת מספקת. אם היא לא מספקת כשהמקור מוגש על מגש, שום מסד לא יציל אותה.
איך בודקים את זה לבד
- רשמו את עשר השאלות שחוזרות הכי הרבה בשירות, כלשונן.
- חפשו לכל אחת את המסמך שעונה עליה. אם אין מסמך, אין מה לבנות עליו.
- בדקו אם קיימת יותר מגרסה אחת של אותו מסמך, וסמנו איזו תקפה.
- בכלי קיים שיש לכם, שאלו שאלה שהתשובה לה אינה במאגר, ובדקו אם הוא אומר שאינו יודע או ממציא.
- בדקו בדוח החיפוש הפנימי כמה חיפושים מחזירים אפס תוצאות בחודש.
המלכודת
המלכודת המסחרית כאן חדה. ספקים מציגים מסד וקטורי כאילו הוא עצמו הפתרון, ואז מודדים הצלחה במהירות שליפה. מהירות היא הדבר שקל למכור. מה שקובע אם הכלי שווה משהו הוא אחר לגמרי: האם המקורות נכונים ומעודכנים, האם החיתוך שמר על ההקשר, ומה קורה כשאין תשובה. כלי שממציא במקום להודות שאינו יודע גרוע מכלי שלא הותקן, כי הוא מייצר נזק בשם העסק ובביטחון מלא. שאלו כל ספק איך הוא מטפל בדיוק במקרה הזה.
מתי זה לא רלוונטי לכם
לרוב העסקים זה פשוט לא הנושא. אם אין לכם קטלוג גדול, אין לכם מאגר נהלים, ואין לכם נפח פניות חוזר שמצדיק אוטומציה, מסד וקטורי הוא הוצאה בלי בעיה שהיא פותרת. גם לאתר קטן עם עשרות עמודים, חיפוש רגיל ועמוד שאלות כתוב היטב יעשו את העבודה בשבריר מהעלות. ובכל מקרה, זה אינו כלי נראות: הוא לא ישפיע על מה שמנוע חיצוני אומר עליכם.
שאלות נפוצות
אני צריך מסד וקטורי כדי להופיע בתשובות של ChatGPT?
לא. המסדים של המנועים הם רכיבים פנימיים שלהם, ואין שום דרך להזין אליהם תוכן. מה שמשפיע הוא נוכחות בחיפוש ואיכות הפסקאות באתר.
מה ההבדל בינו לבין מסד נתונים רגיל?
מסד רגיל מחזיר שורות שעונות לתנאי מדויק. מסד וקטורי מחזיר את הקטעים הקרובים ביותר במשמעות, בלי תנאי חד, ולכן הוא תמיד מחזיר משהו גם כשאין תשובה טובה.
כמה עולה לבנות צאט פנימי כזה?
אין מספר שנכון לומר כאן בלי להכיר את היקף המסמכים ואת דרישות האבטחה. מה שכן אפשר לומר הוא שעלות הבנייה היא בדרך כלל החלק הקטן, ותחזוקת המקורות היא החלק שממשיך לעלות.
אפשר להסתדר בלי, ורק עם חיפוש רגיל באתר?
בהרבה מקרים כן, במיוחד כשהקטלוג קטן והשאלות חוזרות על עצמן. הבדיקה הפשוטה היא כמה חיפושים פנימיים מסתיימים באפס תוצאות.
מונחים קשורים
חיפוש סמנטי
שליפה שמבוססת על משמעות ולא על התאמת מחרוזת.
יצירה מבוססת אחזור
שיטה שבה המודל שולף קודם מסמכים ממקור חיצוני ורק אז מנסח את התשובה על בסיסם, במקום להסתמך על מה שלמד באימון.
חלוקה לקטעים
פירוק העמוד ליחידות קצרות שנשמרות ונשלפות בנפרד.
דירוג מחדש
שלב שני שבו מודל עובר על תוצאות ששלף שלב ראשון ומסדר אותן מחדש לפי התאמה לשאלה.
להרחבה
הערך נבדק מול המקורות הרשמיים של הפלטפורמות. כשמשהו אינו ידוע, כתוב כאן שהוא אינו ידוע. שינויים מתועדים בארכיון העדכונים.
בואו נדבר.
בלי מצגת, בלי התחייבות ובלי שיחת מכירה. עשרים דקות שבסופן תדעו אם יש כאן משהו בשבילכם.
- מה המוצר ומי הלקוח שלכם
- איך נמדדת אצלכם המרה היום
- מאיזה תקציב זה מתחיל להיות הגיוני
לא בקטע של טפסים? info@boostit.co.il