RAG פשוט יותר ממה שנדמה: שש ארכיטקטורות בלי סיבוך מיותר

למה חיפוש הופך למסובך מדי

רוב הצוותים שבונים מערכות RAG (יצירה משופרת באחזור) קופצים ישר ל-embeddings, למסדי נתונים וקטוריים ולצינורות reranking, בעוד שהמשתמשים רק רוצים למצוא את המסמך שמסביר איך לאפס סיסמה. בהנדסה לכל בעיה יש כלי מתאים, כותב מחבר Lighthouse Newsletter, ומערכות אחזור אינן יוצאות דופן.

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

שישה מתכונים, מהמינימלי למורכב

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

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

אחר כך מגיע חיפוש היברידי: BM25 בוחר 50 עד 100 מועמדים, ומודל embedding מדרג אותם מחדש לעשרה. בתעריף של text-embedding-3-small, שני סנט למיליון טוקנים, הטמעת 50 מסמכים של כ-500 טוקנים כל אחד עולה כחצי סנט לאלף שאילתות, כלומר כ-15 דולר בחודש באלף שאילתות ביום. ההוצאה האמיתית היא השהיה: 200 עד 500 אלפיות השנייה נוספות לכל שאילתה.

שלושת המתכונים הנותרים הם הטמעה בזמן אמת למאגרים משתנים מאוד, חלוקה לשכבה חמה וקרה שמטמיעה מראש רק את 20 האחוזים מהמסמכים שמקבלים 80 אחוזים מהתנועה, והטמעה מוקדמת מלאה למאגרים גדולים ויציבים. הטמעה מוקדמת של מיליון מסמכים עולה כעשרה דולרים פעם אחת ועוד 10 עד 30 דולר בחודש לאחסון, אבל החלפת מודל Embedding בהמשך עולה 10,000 דולר כשהכול מוטמע מראש, 2,000 דולר לשכבה חמה, וכלום בהטמעה בזמן אמת.

שאלות עם כמה כוונות

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

שורת התחתונה

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