RAG עם FAISS: חיפוש וקטורי מקומי ללא ענן

פיתוח RAG נתקל במגבלות של חיפוש בענן

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

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

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

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

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

מה נותן אינדקס וקטורי מקומי: מהירות ושליטה

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

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

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

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

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

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

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

אפשרויות פיתוח RAG: ענן, מתאר מקומי, היברידי

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

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

איך מתבצעת ההטמעה: מביקורת נתונים ועד להשקה

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

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

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

3. הגדרת חיפוש. בונים אינדקס וקטורי מקומי (FAISS) ומוסיפים מסננים לפי מטא-נתונים, כך שעובד יקבל רק מסמכים שמותר לו. אינדוקס מחדש מתבצע לפי נוהל, לא ידנית.

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

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

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

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

מה נשאר במתאר הלקוח: תצורות ונהלים

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

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

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

מקרה בוחן: חיפוש בבסיס ידע פנימי במתאר סגור

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

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

מה שינו

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

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

מדדים לפני ואחרי

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

במה חיפוש וקטורי שונה מחיפוש טקסטואלי מלא

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

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

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

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

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

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

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

מהי התדירות לבנות את האינדקס מחדש?

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

איזה מרווח עומס יישאר?

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

מה קורה לאחר המסירה?

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

נדון במשימה ונחזור עם תוכנית עבודה

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

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

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