פיתוח RAG עם OpenSearch: חיפוש וקטורי והיברידי

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

RAG OpenSearch: מדוע החיפוש במאגר הידע מחזיר לא את הנכון

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

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

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

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

מה נותן שכבת חיפוש מנוהלת מעל מאגר ידע

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

בבסיס — OpenSearch במצב חיפוש היברידי: החלק הלקסיקלי תופס מונחים מדויקים, מק״טים וראשי תיבות, והחלק הווקטורי — ניסוחים מחדש לפי משמעות. מעל זה פועל דירוג מחדש של מועמדים וסף לחיתוך התאמות חלשות, כדי שלא ייכנס זבל להקשר. על מדגם ביקורת של שאלות אמיתיות, שיעור התשובות הרלוונטיות עולה מ-55–60% ל-85–90%.

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

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

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

מצבי חיפוש ב-RAG OpenSearch: מה לבחור

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

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

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

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

שלבי הטמעה: מאודיט הקורפוס ועד מסירה

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

  1. אודיט ותיוג הקורפוס. מאחדים מקורות, בודקים פורמטים, כפילויות וגרסאות. מתייגים מקטעים — טקסט, טבלאות, קבצים מצורפים — ושדות סינון: סוג מסמך, מחלקה, תאריך מהדורה.
  2. סט שאלות ביקורת. עם הצוות שלכם אוספים שאלות אמיתיות עם תשובות ייחוס ומקורות. את הסט מקבעים: הוא משמש מדד איכות עד סוף העבודה.
  3. סכמת אינדקסים. מחליטים מה נכנס לאינדקס ובאילו מנות, אילו שדות פועלים בחיפוש וקטורי וטקסטואלי וכיצד מורכב הדירוג ההיברידי.
  4. הגדרת החיפוש. מתאימים מודל אמבדינגס לשפת הקורפוס, גודל מקטע, חפיפה ומשקלות היברידיות — תחילה על מדגם, ואחר כך על כל המערך.
  5. בדיקה על שאלות ביקורת. סופרים באיזו תדירות המקור הנכון נכנס למיקומים העליונים, ומפרקים את הפספוסים לפי סיבות: חלוקה, מהדורה מיושנת, שאלה מחוץ לקורפוס.
  6. התאמה ומסירה. מתקנים חלוקה, מטא-נתונים ומסננים עד לייצוב המדדים, ואז מוסרים את תצורות האינדקס, נוהל העדכון, סקריפטים למדידות ותיעוד למהנדסים שלכם.

כיצד נסגר כל שלב

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

מה כלול במסירה: אינדקסים, סכמות, נהלי עדכון

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

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

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

מקרה בוחן: מאגר ידע של תמיכה, מדדים לפני ואחרי

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

המדדים נלקחו על אותו מדגם: 200 פניות אמיתיות עם מאמרי ייחוס. בדיקה על שאלות ביקורת נתנה בסיס: המסמך הנדרש בשלוש התוצאות הראשונות — 41%, הסלמה לקו שני — 38%, זמן ממוצע עד לתשובה — כ-9 דקות.

מה שינו

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

מה התוצאה

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

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

במה חיפוש היברידי שונה מחיפוש וקטורי טהור

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

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

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

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

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

חששות טכניים נפוצים לפני התחלה

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

עד כמה חיפוש היברידי יאריך את זמן התגובה?

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

כיצד לחתוך כפילויות של מסמכים ומקטעים חוזרים?

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

האם נדרש אינדוקס מחדש מלא בכל עדכון של הקורפוס?

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

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

האם אפשר להחליף מודל בלי לבנות מחדש את החיפוש?

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

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

נדון במשימה: מה לשלוח להערכה

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

  • קורפוס מסמכים או ייצוא: פורמטים (PDF, DOCX, טבלאות, מאגר ידע), נפח, שפות, שיעור סריקות — מזה תלויים החלוקה למקטעים והזיהוי.
  • 50–100 שאילתות משתמשים אמיתיות בניסוח חי ותשובות צפויות לפחות לחלקן — עליהן נמדוד איכות לפני תחילת העבודה.
  • תיוג רלוונטיות, אם נעשה: אילו מסמכים נחשבים לפגיעה נכונה. בלעדיו נאסוף מדדים על מדגם מוסכם.
  • כללי גישה: מי רשאי לראות אילו מסמכים, והאם יש הפרדה לפי מחלקות. את ההרשאות אנחנו משבצים לתוך השאילתה עצמה, אחרת תיווצר דליפה בפלט.
  • כיצד החיפוש בנוי כיום ועל מה מתלוננים המשתמשים: שאילתות בלי תשובה, פלט לא רלוונטי, מסמכים אבודים.
  • סביבה ומגבלות: היכן פורסים את השירות, האם מותרת העברת נתונים למודלים חיצוניים, והאם נדרשת עבודה בתוך סביבת הארגון.
  • עומס ועדכונים: כמה שאילתות ביום, תקופות שיא, זמן תגובה סביר, באיזו תדירות משתנה הקורפוס.

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