פיתוח RAG עם Pinecone: תהליכי עיבוד, חיפוש היברידי, תרחישי שימוש

למה RAG עם Pinecone נשבר על נתונים אמיתיים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מצבי חיפוש ב-RAG עם Pinecone: השוואת גישות

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

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

שלבי עבודה: מביקורת נתונים ועד מסירת המעגל

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

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

ערכת מסירה: תצורות, סכימות ותקנונים

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

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

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

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

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

מה היה לפני השינויים

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

מה שינינו

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

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

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

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

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

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

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

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

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

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

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

מגבלות ומלכודות: מה לקחת בחשבון מראש

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

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

איך תשובה מתחשבת בהרשאות גישה למסמכים?

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

מה לעשות עם פורמטים לא אחידים?

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

האם יש גבול לנפח הקורפוס?

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

מה קורה בעת החלפת מודל?

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

נדון במשימה: מה צריך כדי להתחיל

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

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

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