פיתוח פתרונות LLM ו-Generative AI

פיתוח LLM: כיוונון עדין, RAG, סוכנים ופריסה לייצור

שימוש ב-GPT‑4 או Claude 3.5 Sonnet דרך API ציבורי אינו פתרון — זה רק כלי. כשהדרישה היא "לעשות את זה כמו ChatGPT, אבל על הנתונים שלנו," יש מאחוריה אתגר הנדסי אמיתי: מהנדסת פרומפטים ועד אימון מודל 70B על תשתית משלך. פיתוח פתרון LLM מקצה לקצה הוא מחסנית טכנולוגית מורכבת, ואנחנו עוסקים בזה כבר למעלה מ-5 שנים. בתקופה זו השלמנו למעלה מ-20 פרויקטים ב-AI גנרטיבי: ממערכות RAG למחלקות משפטיות ועד סוכני תמיכה מותאמים אישית. היכן בדיוק המשימה שלך נופלת תלוי בנתונים, בדרישות השהיה, בתקציב ובמידת הקריטיות של סודיות.

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

למה מערכות RAG נשברות ואיך לתקן?

RAG (Retrieval-Augmented Generation) נראה פשוט: למצוא מסמכים רלוונטיים, לשים אותם בהקשר, לקבל תשובה. בפועל, זה נכשל בכמה מקומות.

חיתוך ללא חפיפה. טעות קלאסית: chunk_size=512, overlap=0. אם התשובה נמצאת על פני שני חלקים, אחזור לא ימצא אף אחד מהם בביטחון מספק. פתרון: חפיפה של 15–25% מ-chunk_size, או יותר טוב, פיצול מודע למשפטים עם spaCy או NLTK במקום פיצול תווים נאיבי.

מטמיע חלש. text-embedding-ada-002 טוב לשימוש כללי, אבל על טקסטים משפטיים או רפואיים, מודלים מתמחים כמו E5-large-v2, BGE-M3, או sentence-transformers מכווננים על נתוני תחום עולים עליו. הבדלי Recall@5 יכולים להיות 15–25%.

ללא דירוג מחדש. חיפוש וקטורי מייעל למהירות, לא לרלוונטיות. דירוג מחדש עם cross-encoder (ms-marco-MiniLM-L-6-v2, bge-reranker-large) אחרי אחזור ראשוני משפר את דיוק שלושת הראשונים עם שהיה מקובלת (+50–150ms). זה לעיתים קרובות משפיע יותר משיפור מודל המטמיע.

חיפוש היברידי. וקטורים צפופים לבדם עובדים גרוע על שאילתות מדויקות: שמות, SKU, קודים. BM25 (דליל) מוצא התאמות מדויקות אבל מפספס סמנטיקה. היברידי דרך RRF (Reciprocal Rank Fusion) הוא הפשרה האופטימלית. Qdrant, Weaviate ו-pgvector 0.7+ תומכים בחיפוש היברידי באופן טבעי.

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

הנדסת פרומפטים פותרת ~70% ממשימות התאמת LLM לתחום. 30% הנותרים דורשים כיוונון עדין. שלושה סימנים: המודל מתעלם מתבנית פלט ספציפית גם עם פרומפט מפורט; המשימה דורשת ידע עמוק באוצר מילים מתמחה (רפואה, משפט); אתה צריך להפחית משמעותית עלויות אסימונים על ידי החלפת מודל גדול במודל קטן ומתמחה.

LoRA ו-QLoRA הם הסטנדרט ל-SFT. LoRA מוסיף מטריצות דירוג נמוך הניתנות לאימון לשכבות קשב. תצורה טיפוסית ל-Llama-3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] מניבה ~0.8% פרמטרים הניתנים לאימון, אימון על A100 40GB אחד. QLoRA מוסיף קוונטיזציה של 4-bit (NF4) ומאפשר כיוונון עדין של מודלי 70B על שני A100 40GB, אם כי המהירות יורדת בחצי בהשוואה ל-bf16.

DPO במקום RLHF. Direct Preference Optimization דורש רק זוגות (נבחר, נדחה), לא אותות תגמול סקלריים. DPOTrainer מספריית trl (Hugging Face) מיישם זאת בכמה עשרות שורות.

טעות נפוצה. מערך נתונים של 500 דוגמאות, 5 עידנים, אובדן אימות 0.8 — נראה בסדר. אבל בבדיקה, המודל מתדרדר בהוראות כלליות. סיבה: שכחה קטסטרופלית. פתרון: הוסף 10–20% דוגמאות של מעקב אחר הוראות כלליות (Alpaca, FLAN) למערך האימון כדי לשמר יכולות מקוריות.

איך לבחור מודל בסיס: 8B או 70B?

עבור רוב המשימות, כיוונון עדין של מודל 8B מספיק. 70B נדרש כאשר נדרשת חשיבה עמוקה או שמודל ה-8B לא מגיע לאיכות הנדרשת גם אחרי כיוונון עדין. עלות ההסקה עבור Llama-3 8B דרך vLLM על A100 יעילה; העלות המדויקת תלויה בנפח.

מה PagedAttention מביא לייצור?

vLLM היא הבחירה הראשונה להגשת מודלים בקוד פתוח. PagedAttention הוא החידוש הטכני המרכזי: מטמון KV מנוהל כמו זיכרון וירטואלי במערכת הפעלה, ללא פרגמנטציה. זה מניב תפוקה גבוהה פי 2–4 בהשוואה להסקת HuggingFace Transformers נאיבית. תיעוד vLLM מאשר ש-continuous batching ו-PagedAttention הם הסטנדרט לשירותי LLM בעומס גבוה.

מספרים טיפוסיים על A100 80GB עבור Llama-3 8B (bf16): 400–600 בקשות/שנייה, שהיית P50 200–400ms, שהיית P99 600–900ms בריצות מקבילות של 64. עבור 70B על שני A100 עם מקביליות טנזורית: 80–120 בקשות/שנייה, שהיית P99 1.5–2.5 שניות. קוונטיזציה AWQ או GPTQ מפחיתה צריכת זיכרון פי 2 עם אובדן איכות בטווח 1–3%.

מערכות מרובות סוכנים

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

• ReAct (Reason + Act): המודל חושב → בוחר כלי → צופה בתוצאה → חושב שוב. LangChain ו-LlamaIndex מיישמים זאת מחוץ לקופסה.
• תזמור מרובה סוכנים: מספר סוכנים מתמחים עם מתאם בראש. דוגמה: מתאם → חוקר (חיפוש + סיכום) → מתכנת (יצירת קוד וביצוע) → מבקר (אימות). כלים: AutoGen (מיקרוסופט), CrewAI, יישום מותאם על LangGraph.

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

איך אנחנו עובדים: שלבים, לוח זמנים, תוצרים

מה כלול

אנחנו מספקים:

• תיעוד טכני (כרטיס מודל, תצורות, הוראות פריסה)
• גישה לתשתית (מאגר קוד, משקלים מאומנים)
• חודש אחד של תמיכה לאחר פריסה (ייעוץ, תיקוני באגים)
• הדרכת צוות הלקוח (2–3 מפגשים על תפעול המערכת)

לוח זמנים: אב טיפוס RAG בסיסי — 1–2 שבועות. כיוונון עדין עם נתוני לקוח — 3–6 שבועות (כולל הכנת נתונים). מערכת ייצור עם ניטור ואימון מחדש — 2–4 חודשים. העלות מחושבת באופן פרטני לפי נפח נתונים, מורכבות מודל ודרישות תשתית.

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

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