RAG בייצור (Production) בקנה מידה רחב: לקחים ממעל 10,000 מודעות מדי יום
בניתי pipeline של RAG עבור לוח דרושים. הוא עבד בסביבת staging, אך התקשה תחת עומס אמיתי. עיבוד של אלפי מודעות מדי יום דורש יותר מאשר רק vector store טוב. עליכם להבין היכן המערכת נשברת.
הנה הלקחים שלי בנושא chunking, embeddings, עלויות ו-observability.
1. אל תנחשו את אסטרטגיית ה-chunking שלכם
רוב המדריכים מתייחסים ל-chunking כאל הגדרה פשוטה. בייצור (production), האסטרטגיה שלכם קובעת את הדיוק ואת העלות.
בדקתי שלוש שיטות עבור מודעות דרושים:
- Fixed-size chunks: השיטה הזו נכשלה. היא פיצלה סעיפים כמו "דרישות" ו"הטבות" בנקודות אקראיות. זה יוצר שליפה (retrieval) רועשת.
- Semantic chunking: זה היה טוב יותר אך לא עקבי. חלק מה-chunks היו ארוכים מדי ואחרים קצרים מדי.
- Recursive character splitting עם overlap: זה עבד הכי טוב. פיצלתי לפי שורות חדשות ומשפטים. השתמשתי בגודל של 400 tokens עם overlap של 50 tokens. זה מבטיח שמשפטים שמתפרסים על פני שני chunks יישארו מחוברים.
טיפ מקצועי: נרמלו את הנתונים שלכם לפני ה-chunking. מקורות שונים כמו Greenhouse או Lever מחזירים פורמטים שונים. נקו את הטקסט תחילה כדי שה-chunker שלכם יראה מבנה עקבי.
2. Embeddings: עלות מול דיוק
בדקתי את Llama 3.1 דרך Ollama מול text-embedding-3-small של OpenAI. המודל המקומי היה בחינם אך התקשה עם מונחים ספציפיים לתחום כמו "equity compensation". הוא הפיק תוצאות רועשות. OpenAI עלה יותר אך סיפק התאמות מדויקות. בחרתי ב-OpenAI כי שליפה (retrieval) גרועה עולה יותר בשיחות LLM מאוחר יותר.
כדי לחסוך זמן, אני מבצע batching לבקשות שלי. אני שולח עד 100 chunks בקריאה אחת. זה מפחית את ה-latency ושומר על ה-pipeline מהיר.
3. הטרייד-אוף של ה-Vector Store
השתמשתי ב-Pinecone עבור prototyping כי קל להגדיר אותו במהירות. עם זאת, בקנה מידה רחב, העלויות גדלו מדי.
עברתי ל-pgvector בתוך PostgreSQL.
- זה דרש יותר עבודה בהגדרה.
- זה חסך סכומי כסף עצומים.
- זה סיפק עקביות טרנזקציונית (transactional consistency). מכיוון שה-embeddings נמצאים באותו מסד נתונים של נתוני המשרות, יש לכם מקור אמת אחד (source of truth). אין צורך לסנכרן בין שתי מערכות שונות.
4. שליטה בעלויות LLM
דירוג (Scoring) של כל מודעה עם GPT-4o הוא יקר. השתמשתי בשלוש טקטיקות להורדת עלויות:
- OpenAI Batch API: אני מעבד משימות דירוג במהלך הלילה. זה מספק הנחה משמעותית.
- Caching: אני מבצע caching לתוצאות עבור פרופילי מועמדים חוזרים.
- Model tiering: אני משתמש ב-GPT-4o-mini לתפקידים נפוצים כמו "Sales Representative". אני משתמש ב-GPT-4o רק לתפקידים נישתיים שבהם הדיוק הוא קריטי.
5. בונים observability קודם כל
ה-pipeline שלי נכשל פעם אחת בשקט. נתונים לא תקינים (malformed data) גרמו ל-chunks ריקים, שהמערכת דילגה עליהם ללא שגיאה.
תיקנתי זאת על ידי הוספת structured logging עם correlation ID. זה אפשר לי לעקוב אחר מודעה אחת מתהליך ה-ingestion ועד לדירוג. סוף סוף יכולתי לראות אילו מקורות נתונים גרמו לכשלים.
הלקח הכי גדול: רוב הבעיות מגיעות מנתונים מבולגנים, לא מה-AI. תקנו קודם כל את ה"צנרת" (plumbing) של הנתונים שלכם.
קהילת למידה אופציונלית: https://t.me/GyaanSetuAi