יש לך POC שעובד. Claude עונה נכון, הלקוחות מתרגשים, והצוות רוצה לשחרר לפרודקשן. ואז מישהו שואל: "מה קורה אם Claude לא זמין?" ו-"מה יהיה החשבון בסוף החודש?"
רוב הצוותים מגלים את הפער בין demo לפרודקשן בדרך הקשה. שיעור זה עוצר אתכם לפני כן ומראה את ארכיטקטורת הפרודקשן המלאה, מהחלטת המודל ועד לניטור, עם דוגמאות קוד שעובדות.
ההחלטה הכי חשובה: באיזה מודל להשתמש?
הטעות הנפוצה ביותר בפרודקשן: שולחים הכל ל-Opus. זה כמו לשכור מנהל בכיר שיענה על כל מייל בארגון, כולל "מה שעות הפתיחה?".
הגישה הנכונה היא model routing לפי סוג הבקשה:
| סוג בקשה | מודל מומלץ | עלות יחסית |
|---|---|---|
| סיווג, תגיות, שאלות קצרות | Haiku 4.5 | x1 (הכי זול) |
| כתיבה, ניתוח, קוד רגיל | Sonnet 4.6 | x5 |
| ניתוח מורכב, מחקר, קוד ארכיטקטורה | Opus 4.7 | x15 |
חברות שמיישמות routing חכם מדווחות על חיסכון של 60% בעלויות API ללא פגיעה באיכות. 60% מהשאלות בממוצע מתאימות ל-Haiku.
ארכיטקטורת Production: שבע שכבות
סטארטאפ ת"א שבנה chatbot לשירות לקוחות גילה בשבוע הראשון שלושה בעיות: המחיר היה פי 8 מהצפוי, כשה-API של Anthropic איטי, הכל הקפיא, ואותה שאלה נשאלה 200 פעם ביום וחויבה בכל פעם מחדש. הפתרון הוא ארכיטקטורה עם שבע שכבות:
בקשת משתמש
↓
[Rate Limiter] ← הגבלת requests לפי משתמש/IP
↓
[Auth + Validate] ← אימות token, ניקוי קלט
↓
[Cache Layer] ← Redis: בדוק אם קיימת תשובה זהה
↓ (cache hit: החזר מיד, ללא קריאה ל-API)
[Model Router] ← Haiku / Sonnet / Opus לפי סוג בקשה
↓
[Claude API] ← קריאה עם retry ו-exponential backoff
↓
[Circuit Breaker] ← אם Claude לא זמין: fallback מיידי
↓
[Structured Logger] ← latency, cost, user_id, cache_hit
↓
תגובה למשתמש
כל שכבה פותרת בעיה ספציפית. אפשר לבנות אותן בהדרגה, לא חייבים הכל ביום הראשון.
שלושת האדנים: Caching, Retry, Fallback
1. Prompt Caching, הכלי הכי משתלם בפרודקשן
אם ה-system prompt שלכם ארוך (מדריך מוצר, בסיס ידע), prompt caching חוסך עד 90% על tokens שחוזרים. מ-2026 יש TTL של שעה אחת, מתאים לsystem prompts שלא משתנים. Anthropic הוסיפה גם automatic caching (beta) שמנהל את cache points אוטומטית.
2. Retry עם Exponential Backoff
Claude API מחזיר לפעמים שגיאות 429 (rate limit) ו-529 (overloaded). ה-retry חייב להיות חכם, לא loop פשוט:
from tenacity import retry, stop_after_attempt, wait_exponential
@retry(
stop=stop_after_attempt(3),
wait=wait_exponential(multiplier=1, min=2, max=30)
)
def call_claude(messages, system=""):
return client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
system=system,
messages=messages
)
3. Circuit Breaker, fallback כשה-API לא זמין
Circuit Breaker עוקב אחרי שגיאות רצופות. לאחר X כישלונות, עובר למצב OPEN ומחזיר תגובת fallback מיידית במקום לחכות timeout ולחסום את המשתמש. זה ההבדל בין "שגיאה 504 לאחר 30 שניות" לבין "ניסח תגובה כללית תוך חצי שניה".
ניטור עלויות ואיכות, מה לעקוב
כלל האצבע: מה שלא מודדים לא משתפר. בכל request יש לרשום:
- latency, זמן תגובה מלא (P50, P95, P99)
- input_tokens + output_tokens, עלות לפי מודל
- cache_hit, האם נשמרה קריאה ל-API
- user_id, עלות לפי משתמש (חשוב לתמחור)
- model_used, לוודא ש-routing עובד נכון
חישוב עלות מהיר ל-Sonnet 4.6: עלות = (input_tokens * 3 + output_tokens * 15) / 1,000,000 (בדולרים). כל ה-model calls של Claude הם OTel-compliant, ניתן לייצא ישירות ל-Grafana, Datadog, או Prometheus.
הגדירו alert ב-80% מה-rate limit שלכם, לא ב-100%. ב-80% יש עדיין זמן לתגובה לפני שמשתמשים מרגישים.
Production Checklist, לפני שמשחררים
לפי ניסיון מצוות שבנו Claude services לפרודקשן, הטעויות הנפוצות ביותר שמתגלות אחרי שחרור:
- API key מוכנסת hard-coded בקוד (!), תמיד ב-environment variables או Vault
- אין max_tokens, Claude יכול לחזור עם תגובה ארוכה מאוד ולפוצץ עלויות
- context window גדל ללא בקרה, שיחה ארוכה שולחת אלפי tokens מיותרים בכל request
- אין fallback, כשה-API איטי, כל המשתמשים תקועים
- לא בודקים output לפני שמחזירים למשתמש, hallucination עלולה להופיע בממשק
טיפ מעשי: שמרו על context window מתחת ל-200K tokens. מעל זה מחיר הקלט מכפיל את עצמו. השתמשו בסיכומים, RAG, או (מ-2026) ב-context compaction האוטומטי של Anthropic.
דוגמה ישראלית: chatbot לשירות לקוחות נדל"ן
חברת תיווך בת"א בנתה chatbot שעונה לשאלות על נכסים. ה-system prompt כולל 4,000 tokens של מידע על אזורים, מחירים, ותנאי מכירה. ללא caching, כל שאלה עלתה $0.012. עם prompt caching, $0.0015 (87% חיסכון). עם model routing (Haiku לשאלות "מה השכר דירה ממוצע בפלורנטין?"), החיסכון הכולל הגיע ל-91%.
הם גם הוסיפו circuit breaker עם fallback שמחזיר: "כרגע אין לי גישה למידע עדכני, נציג יחזור אליך תוך שעה." במקום timeout של 30 שניות שגרם לנטישת משתמשים.
