ה-Batch Pipeline — קטלוג חנות שלם דרך API

מ-ידני ל-engine — למה batch הוא ה-differentiator

עד עכשיו עבדתם במצב שאני קורא לו "single-shot workflow" (זרימת עבודה חד-קריאתית): מוצר → reference → prompt → הרצה → בדיקה → תיקון → שמירה. עובד. איטי. ברגע שיש לכם 30+ מוצרים, המצב הזה נשבר: כל תמונה לוקחת 5-15 דקות, ו-30 מוצרים = 2.5-7.5 שעות של עבודה ידנית. ב-200 מוצרים זה כבר לא ריאלי בכלל.

ה-batch pipeline הוא לא רק "לעשות את אותו דבר מהר יותר". זה סוג אחר של עבודה. במקום 200 קריאות ידניות, יש לכם engine — מנוע חוזר שמריץ את אותו template על כל המוצרים, באותה איכות, באותה עקביות, בלי לשכוח prompt באמצע, בלי לטעות ב-seed, בלי לפספס resolution.

המעבר מידני ל-engine הוא ההבדל בין חנות שיכולה להפיק 30 מוצרים בשבוע לחנות שיכולה להפיק 200. ולא רק בכמות — בעקביות. ה-template הוא אותו template לכל ה-200; היד עלולה לרעוד בקריאה ה-87.

ארכיטקטורת ה-pipeline — הצינור שמחבר הכל

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

צעד 1 — CSV של SKUs

קובץ טבלה פשוט. שורה אחת לכל מוצר. עמודות מינימליות: sku (קוד ייחודי), name (שם המוצר), category (לאיזה template הוא שייך), reference_paths (רשימת 6 נתיבי תמונות reference, מופרדים ב-|), output_dir (לאן לשמור את התוצאה). אפשר גם עמודות של angles_count ו-lifestyle_background אם רוצים גמישות.

למה CSV ולא JSON או Excel? כי CSV הוא הפורמט שהכי קל לקרוא בכל שפה ובכל סביבה. אפשר לפתוח ב-Google Sheets, לייצא, לקרוא ב-Python, ב-Node, ב-Bash, ובכלי no-code. אם אתם מגיעים מ-Shopify, ה-CSV של המוצרים שלכם כבר קיים — אתם רק צריכים להוסיף לו עמודת reference_paths.

צעד 2 — תמונות reference לכל SKU

תיקייה עם references מסודרות: references/[SKU]/img-1.jpg עד img-6.jpg. 6 תמונות לכל מוצר, מאותן 6 זוויות שלמדנו בפרק 3-4. חשוב: אותו שמות-קבצים לכל SKU (img-1 עד img-6). זה מאפשר לסקריפט לטעון אוטומטית בלי לחשוב.

צעד 3 — template פר-קטגוריה (קפוא)

ה-template מפרק 4 — נוסחה של subject + angle + lighting + surface + composition + brand-aesthetic — נשמר בקובץ טקסט פשוט: templates/[category].txt. הסקריפט קורא את הקובץ, מחליף את ה-subject בשם המוצר מה-CSV, ושולח. ה-template הוא קבוע — לא נוגעים בו בכל batch. אם רוצים לשנות — פותחים template חדש ולא משנים את הקיים.

צעד 4 — קריאת batch ל-API

הלב של ה-pipeline. הסקריפט עובר על כל שורה ב-CSV, בונה prompt מה-template + subject + reference paths, שולח קריאה ל-API של המנוע (Nano Banana 2 / Seedream 5.0 Lite דרך fal או Replicate), ומקבל חזרה תמונות. לרוב 4-6 תמונות בקריאה אחת (המודלים המובילים תומכים ב-n parameter שמגדיר כמה תמונות להחזיר).

צעד 5 — תיקיית QA

התוצאות נשמרות ב-qa/[category]/[SKU]/ עם שמות ברורים. רק אחרי שעברו את ה-QA (פרק 6) הן עולות לחנות. תיקיית ה-QA היא ה-buffer (מאגר ביניים) בין הייצור לפרסום — והיא הסיבה שאפשר להריץ batch של 200 תמונות בלי לחשוש שמשהו פגום יעלה לחנות.

תרשים הזרימה

┌─────────────┐    ┌──────────────┐    ┌──────────────┐
│   CSV/      │───▶│  references/ │───▶│  templates/  │
│  Google     │    │   [SKU]/     │    │ [category].  │
│  Sheets     │    │ img-1..6.jpg │    │     txt      │
└─────────────┘    └──────────────┘    └──────────────┘
        │                                       │
        │           ┌───────────────────────────┘
        ▼           ▼
┌─────────────────────────────────────────┐
│         SCRIPT (20-30 lines)           │
│  for row in csv:                       │
│    prompt = template(row.subject)      │
│    images = api(row.references, prompt)│
│    save(images, row.output_dir)        │
└─────────────────────────────────────────┘
                    │
                    ▼
        ┌───────────────────────┐
        │   qa/[cat]/[SKU]/     │
        │   packshot.png        │
        │   angle-1.png         │
        │   angle-2.png         │
        │   lifestyle.png       │
        └───────────────────────┘
                    │
                    ▼  (פרק 6)
        ┌───────────────────────┐
        │   חנות Shopify/Amazon  │
        └───────────────────────┘

fal.ai מול Replicate — היכן כל אחד מנצח

יש שתי פלטפורמות-על (aggregators) שמריצות batch של מודלי תמונה בקלות: fal.ai ו-Replicate. שתיהן תומכות ב-Nano Banana Pro/2, Seedream 4.5/5.0 Lite, GPT Image 2, ועוד. ההבדל הוא לא במחיר (דומה) אלא ב-UX ובארכיטקטורה.

fal.ai — ה-queue/async king

fal.ai בנויה סביב queue (תור): שולחים 50 בקשות בבת-אחת, מקבלים 50 request_id, ואז בודקים את הסטטוס בלולאה. זה אידיאלי ל-batch גדול. ה-API שלהם מתועד היטב, יש להם pricing פשוט פר-תמונה (~$0.08 לתמונת 1K Nano Banana 2), ויש גם playground אינטראקטיבי לבדיקות. ההמלצה למתחילים: התחילו ב-fal. ה-UX ברור יותר, ה-error messages מועילים, והמסמכים טובים.

דוגמה לקריאת fal (פורמט JSON):

{
  "model": "fal-ai/nano-banana-2",
  "input": {
    "prompt": "A serum bottle on a marble surface, softbox lighting, 5600K, e-commerce style. Product identical to the references.",
    "image_urls": [
      "https://mysite.com/refs/SKU-001/img-1.jpg",
      "https://mysite.com/refs/SKU-001/img-2.jpg",
      "https://mysite.com/refs/SKU-001/img-3.jpg",
      "https://mysite.com/refs/SKU-001/img-4.jpg",
      "https://mysite.com/refs/SKU-001/img-5.jpg",
      "https://mysite.com/refs/SKU-001/img-6.jpg"
    ],
    "num_images": 4,
    "image_size": "square_hd",
    "seed": 42
  }
}

Replicate — המבחר הרחב

Replicate ידועה במבחר המודלים הקהילתיים הגדול ביותר — כל מודל שמישהו פרסם ב-HuggingFace, בערך, נמצא שם. זה יתרון אם אתם רוצים לנסות מודלים נישתיים (למשל מודל של תכשיטים ספציפית). החיסרון: ה-UX של ה-batch פחות מלוטשת, וה-pricing לפי שנייה-של-GPU במקום פר-תמונה — מה שאומר שאתם צריכים להבין כמה זמן המודל לוקח.

הכלל המעשי

ברירת מחדל: fal.ai ל-90% מהמקרים. אם אתם צריכים מודל קהילתי ספציפי שלא קיים ב-fal — עברו ל-Replicate לאותה עבודה. אל תערבבו באותו pipeline — מודל אחד, פלטפורמה אחת, כל הקטלוג.

מתי לעבור ל-API הרשמי של המודל

אם אתם מפיקים מעל 10,000 תמונות בחודש, ה-pricing של ה-API הרשמי (Gemini API ל-Nano Banana, OpenAI API ל-GPT Image) עלול להיות זול יותר. עד אז — fal/Replicate. המעבר הוא לא מסובך (אותם inputs, אותו output), אבל צריך להחליט מראש כי ה-billing וה-SLA שונים.

קריאת batch אחת בפועל — 4-6 תמונות ב-2K

עכשיו לעבודה. קריאת batch אחת למודל נראית כך: קלט אחד (prompt + references) → פלט של 4-6 תמונות. לא 4-6 קריאות. קריאה אחת. המודל יודע לייצר מספר וריאנטים של אותו prompt בבת-אחת.

הפרמטרים הקריטיים

בכל קריאת batch יש 4 פרמטרים שמשפיעים על התוצאה, העלות, והזמן:

למה 4-6 ולא 1, ולא 20?

1 תמונה לקריאה = 4-6 קריאות לאותו SKU = עלות גבוהה פי 4-6, זמן רב יותר, ו-overhead של רשת. בזבוז.

4-6 תמונות לקריאה = sweet spot. מספיק וריאציות כדי לבחור את הטובה ביותר ל-QA, עלות סבירה, זמן סביר. אתם תבחרו 1-2 מתוך ה-4-6, ותשמרו את השאר כגיבוי.

10-20 תמונות לקריאה = overkill. המודל מתחיל "לערבב" בין הוריאציות, האיכות יורדת, העלות עולה בלי תמורה. ב-20 תמונות אתם מקבלים בערך 4-6 שימושיות; שאר 14 הן רעש.

למה 2K ולא 1K, ולא 4K?

2K (2048px) = ברירת-מחדל ל-PDP. מספיק גדול לזום-אין (zoom-in) על תוויות, מספיק חד למרקטפלייס, מספיק קטן לא לשלם פרמיה. 90% מהחנויות צריכות 2K.

1K (1024px) = thumbnails, social, איפה שהתמונה תוצג ב-300-600px. זול יותר בערך 30-40%.

4K (4096px) = רק ל-hero shots — התמונה הראשית של המותג, banners, או קמפיינים. עולה בערך פי 2-3 מ-2K. בנו את ה-pipeline סביב 2K ורק את ה-hero — סביב 4K.

הזמן האמיתי

קריאת batch אחת (4-6 תמונות ב-2K) לוקחת 8-25 שניות ב-Nano Banana 2 / Seedream 5.0 Lite דרך fal, תלוי בעומס השרת. ב-Nano Banana Pro — 15-40 שניות. ב-GPT Image 2 — 20-50 שניות. הזמן הזה הוא לכל הקריאה, לא לכל תמונה. עם async, אתם שולחים 50 קריאות ב-30 שניות, והן חוזרות ב-3-8 דקות.

סקריפט מינימלי לבעל-חנות — בלי לכתוב קוד מאפס

אני יודע מה אתם חושבים: "אני לא מתכנת". גם אני לא הייתי, עד שהבנתי שאני לא צריך להיות. הסקריפט הזה הוא 20 שורות של Python שאפשר להעתיק-להדביק-לשנות. אין מבני-נתונים מסובכים, אין class hierarchy, אין dependency מוזר. רק: קרא CSV, לולאה, שלח ל-API, שמור.

# batch_pipeline.py — 20 שורות, מוכן להרצה
import csv, os, requests, time

API_KEY = os.environ.get("FAL_KEY")              # מ-env variable
TEMPLATE = open("templates/serum.txt").read()    # ה-template הפר-קטגוריה

with open("catalog.csv") as f:
    for row in csv.DictReader(f):
        prompt = TEMPLATE.replace("[SUBJECT]", row["name"])
        refs = row["reference_paths"].split("|")
        r = requests.post(
            "https://fal.run/fal-ai/nano-banana-2",
            headers={"Authorization": f"Key {API_KEY}"},
            json={"input": {
                "prompt": prompt,
                "image_urls": refs,
                "num_images": 4,
                "image_size": "square_hd",
                "seed": 42,
            }},
        )
        result = r.json()
        for i, img_url in enumerate(result["images"]):
            out = f"qa/{row['category']}/{row['sku']}/angle-{i+1}.png"
            os.makedirs(os.path.dirname(out), exist_ok=True)
            with open(out, "wb") as fout:
                fout.write(requests.get(img_url).content)
        time.sleep(1)   # rate limit — רוב הפלטפורמות 60 קריאות/דקה
print("done")

מה עושה הסקריפט הזה

שורה 1-3: imports — ספריות סטנדרטיות. csv לקרוא את ה-CSV, os לעבודה עם קבצים, requests לקריאות HTTP, time ל-rate limiting (הגבלת קצב — לא לשלוח יותר מדי קריאות בשנייה).

שורה 5-6: טעינת משתנים — API key מ-environment variable (לא לכתוב בקוד!), template מקובץ טקסט.

שורה 8-9: קריאת ה-CSV. csv.DictReader הופך כל שורה ל-dictionary עם שמות העמודות כמפתחות.

שורה 10-11: בניית ה-prompt — החלפת [SUBJECT] בשם המוצר מה-CSV. שאר ה-template נשאר קפוא.

שורה 12-19: שליחת הקריאה ל-fal. שימו לב למבנה: model ב-URL, input ב-body, num_images ו-image_size כפרמטרים.

שורה 20-25: שמירת התוצאות. כל תמונה נשמרת עם שם ברור (angle-1.png וכו') בתיקייה הנכונה.

שורה 26: time.sleep(1) — חשוב! רוב הפלטפורמות מגבילות ל-60 קריאות/דקה. בלי sleep — ה-API יחזיר 429 (Too Many Requests) ותצטרכו להתחיל מחדש.

איפה מריצים את זה

אפשרות 1 — מקומית. התקינו Python 3.10+, התקינו requests (pip install requests), שמרו את הקובץ, הריצו python batch_pipeline.py. עובד. דורש מחשב שלא נכבה.

אפשרות 2 — Google Colab. פתחו notebook חדש, הדביקו את הסקריפט, הריצו. חינם (עם מגבלות). טוב לבדיקות.

אפשרות 3 — Replit / GitHub Actions. עבור batch שלרוצים לרוץ על לוח-זמנים. קצת יותר מורכב, אבל אחרי שהסקריפט עובד מקומית — קל להעביר.

over-engineering — מלכודת בעלי-חנויות

הפיתוי הגדול: לבנות מערכת מורכבת. retry logic (לוגיקת ניסיון חוזר) עם exponential backoff (המתנה מתארכת בין ניסיונות), parallel processing (עיבוד מקבילי) עם asyncio, error handling (טיפול בשגיאות) מקיף, monitoring, dashboard, alerts. אל תעשו את זה. הסקריפט למעלה עובד. הוא מטפל ב-200 SKU ב-15-20 דקות. אם משהו נשבר — תראו את השגיאה בטרמינל ותריצו מחדש. ה-over-engineering הוא הבזבוז האמיתי.

בקרת עלות — resolution לפי ערוץ

אחרי 3 תרגילים אתם כבר רואים שהתמונות עולות כסף. $0.08 לתמונת Nano Banana 2 ב-1K, $0.15 ב-4K. על 200 SKU x 5 תמונות, זה הופך מ-80$ ל-150$ רק בגלל הרזולוציה. ההחלטה על resolution היא ההחלטה התקציבית הכי גדולה שלכם — גדולה יותר מבחירת מנוע.

המטריצה: ערוץ → resolution → מחיר

העיקרון: אל תשלמו 4K על תמונה שתוצג ב-600px. זה כמו לקנות מכונית ספורט לנסיעה לסופר — יקר יותר, לא מועיל יותר. 2K ברירת-מחדל ל-PDP; 1K לכל השאר; 4K רק לבאנרים וקמפיינים.

המקרה המעשי: קטלוג שלם בתקציב

נניח חנות עם 200 SKU, רוצה לכל אחד packshot (2K), 2 זוויות (2K), lifestyle (2K), ו-3 חיתוכים (1K). זה 6 תמונות לכל SKU. הנה החישוב:

לכל SKU:
  1 x packshot 2K     = $0.067
  2 x angles 2K       = $0.134
  1 x lifestyle 2K    = $0.067
  3 x crops 1K        = $0.135
  --------------------
  total per SKU       = $0.403

ל-200 SKU:
  200 x $0.403 = $80.6
  --------------------
  + cache 60% hit  = $32.2 נטו
  --------------------
  = ~$32 (כ-120 ₪)

זאת העלות לכל הקטלוג. עם מצלם מקצועי, 200 מוצרים ב-$50 למוצר = $10,000. החיסכון הוא 99.7%. עם צלם פנים-ארצי ב-$10 למוצר = $2,000. עדיין חיסכון של 96%.

שכבת cache — איך ~60% חיסכון נראה בפועל

הרעיון פשוט: לפני שליחת קריאה ל-API — בדוק אם כבר הפקת תמונה כזו. אם כן — החזר אותה מהמטמון (cache). אם לא — שלח קריאה ושמור במטמון. זה cache layer.

למה זה קריטי ל-batch

בקטלוג יש הרבה חזרתיות (redundancy):

• וריאנטים של אותו מוצר (חולצה ב-3 צבעים) — רקע ותאורה זהים, רק הצבע משתנה. אם תפיקו 3 קריאות עם prompt כמעט זהה, הרקע יישאר זהה. התמונה השנייה והשלישית — שמרו במטמון.
• חיתוכים מאותו מקור (1:1, 4:5, 9:16 מתמונת 2K) — זה אותו מקור בדיוק. החיתוך עצמו לא דורש קריאה חדשה, הוא רק crop.
• רענון עונתי (אותו מוצר, רקע חורף/קיץ) — רוב המוצר זהה, רק הסביבה משתנה.
• תמונות bundle (2-3 מוצרים בסצנה אחת) — המוצר הבודד כבר הופק, רק צריך להרכיב אותו עם אחרים.

המספרים האמיתיים

בקטלוג טיפוסי של 200 SKU עם 5 תמונות לכל אחד, החזרתיות היא ~50-70%. משמע: ~60% מהקריאות שאתם תשלחו בלי cache — כבר הופקו בעבר. אם תוסיפו cache layer עם hit-rate של 60% — אתם חוסכים 60% מהעלות. על $80 לקטלוג — זה $32 במקום $80. על 12 קטלוגים בשנה — זה $580 במקום $960. חיסכון של $580 — שווה עלות ה-setup.

איך מימשים cache layer

ה-cache הוא בעצם key-value store (אחסון של מפתח→ערך): מפתח הוא hash של ה-prompt+references+seed, הערך הוא URL התמונה (או התמונה עצמה). לפני קריאה — חשב hash, בדוק אם קיים. אם כן — החזר. אם לא — שלח ושמור.

# cache.py — 8 שורות של cache layer
import hashlib, json, os
CACHE_FILE = "cache/images.json"

def get_cached(prompt, refs, seed):
    key = hashlib.md5(
        json.dumps([prompt, refs, seed], sort_keys=True).encode()
    ).hexdigest()
    if os.path.exists(CACHE_FILE):
        cache = json.load(open(CACHE_FILE))
        return cache.get(key)
    return None

def save_to_cache(prompt, refs, seed, image_urls):
    key = hashlib.md5(
        json.dumps([prompt, refs, seed], sort_keys=True).encode()
    ).hexdigest()
    cache = (json.load(open(CACHE_FILE)) if os.path.exists(CACHE_FILE) else {})
    cache[key] = image_urls
    json.dump(cache, open(CACHE_FILE, "w"))

זה cache "טיפש" — קובץ JSON אחד. עובד עד 10,000 תמונות. אחרי זה — תעברו ל-Redis (מסד נתונים in-memory) או ל-S3 (storage) + metadata DB. לרוב החנויות — קובץ JSON מספיק.

cache invalidation (מתי לרענן)

ה-cache תקף כל עוד הקלט זהה. אם שיניתם את ה-template — הקריאות החדשות הן hashes חדשים, לא מתנגשות עם הישנות. אם שיניתם את ה-reference image (צילמתם מחדש) — גם hash חדש. אין צורך "לרענן" cache — הוא מתעדכן אוטומטית כשהקלט משתנה.

תקצוב batch בשקלים — מ-token pricing לעלות אמיתית

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

שער ההמרה — ומתי הוא משנה

באמצע 2026, שער הדולר לשקל הוא בערך 3.7 ₪/$. אבל זה לא המספר שצריך לתקצב לפיו. המספר שצריך לתקצב לפיו הוא שער הכרטיס שלכם + עמלת המרה + מע"מ. כרטיסי אשראי ישראלים גובים עמלת המרה של 1-3.5%, ומע"מ על שירותים דיגיטליים מחוץ לישראל הוא סיפור מורכב (חלק מהפלטפורמות מוסיפות מע"מ ישראלי, חלק לא). כלל אצבע מעשי: תקצבו לפי 4.0 ₪/$ — זה נותן לכם margin של 8% מעל ההמרה הבנקאית.

המחירון המעשי (ב-₪, לפי 4.0 ₪/$)

הטעות הנפוצה — לחשב ממספרי "per-image" בבלוגים

בלוגים רבים מפרסמים "Nano Banana Pro עולה $0.039 לתמונה". זה המחיר הנמוך ביותר (1K ריבוע, ללא multi-reference). בפועל, אתם עובדים עם 6 references, 2K, ו-multi-image — והמחיר עולה ל-$0.10-0.15 לתמונה. תקצבו לפי המחיר בתרחיש האמיתי שלכם, לא לפי המחיר המינימלי.

המקרה: קטלוג של 200 SKU בשקלים

חישוב מלא — מודל Nano Banana 2, mix של 2K ל-PDP ו-1K לחיתוכים, עם cache 60%:

לכל SKU (6 תמונות):
  1 x packshot 2K    = ₪0.40
  2 x angles 2K      = ₪0.80
  1 x lifestyle 2K   = ₪0.40
  3 x crops 1K       = ₪0.81
  -------------------
  total per SKU      = ₪2.41

ל-200 SKU (ללא cache):
  200 x ₪2.41 = ₪482

עם cache 60% hit:
  40% x ₪482 = ₪193 נטו
  -------------------
  = ~₪193 (~$48)

₪193 לקטלוג שלם של 200 מוצרים. עם צלם ב-₪50/מוצר = ₪10,000. חיסכון של 98%.

תקציב חודשי מעשי

לחנות שמעלה 30 מוצרים חדשים בחודש, עם 6 תמונות לכל אחד, בלי cache (חנות חדשה, אין עדיין מה לשמור):

• 30 SKU x 6 תמונות = 180 תמונות/חודש
• ב-2K mix: ~₪72/חודש
• ב-4K לכל התמונות: ~₪180/חודש (לא מומלץ)
• ב-Nano Banana Pro (הכי יקר): ~₪170/חודש
• ב-Seedream 5.0 Lite (הכי זול): ~₪36/חודש

זה תקציב שמתאים לכל חנות, גם לחנות שרק מתחילה. בלי over-engineering, בלי enterprise plan, בלי מינוי חודשי — רק pay-per-image בפלטפורמה כמו fal.

חיתוכי ערוץ — ממקור 2K אחד לכל הפלטפורמות

זה ה-trick שחוסך הכי הרבה זמן וכסף ב-pipeline. לא צריך להפיק תמונה נפרדת לכל ערוץ. מפיקים תמונה אחת ב-2K (ריבוע, עם קצת רווח מסביב למוצר) וממנה חותכים (crop) את כל ה-proportions שצריך.

ה-proportions העיקריים ב-e-commerce

למה לא להפיק כל אחד בנפרד?

כל הפקה נוספת = עלות נוספת. אם תפיקו 1:1 + 4:5 + 9:16 כל אחד בקריאה נפרדת למודל, תשלמו 3x. בנוסף — המודל לא תמיד מייצר את אותו מוצר בדיוק בכל ה-proportions (הוא רואה את ההוראה 4:5 ומשנה את הקומפוזיציה). החיתוך מתמונה אחת נותן לכם אותה תמונה בדיוק בכל ה-proportions.

איך עושים את החיתוך נכון

צעד 1 — תכננו את הקומפוזיציה לריבוע 2K. המוצר במרכז, רווח של 20-30% מסביב (כדי שיהיה מקום לחתוך בלי לאבד את המוצר).

צעד 2 — חתכו לכל aspect ratio. החיתוך צריך לשמור על המוצר במרכז ה-frame של ה-proportion החדש. עבור 4:5 — חיתוך מהאמצע, מעט יותר גובה. עבור 9:16 — חיתוך צר מהאמצע, הרבה יותר גובה. עבור 16:9 — חיתוך רחב, פחות גובה.

צעד 3 — שמרו בתיקייה נפרדת. crops/[SKU]/1x1.png, 4x5.png, 9x16.png. ה-pipeline הראשי מייצר את ה-2K; סקריפט חיתוך קטן (5 שורות) מייצר את השאר.

הסקריפט לחיתוך

# crop.py — 8 שורות, מקבל תיקיית qa/[cat]/[sku]/ ויוצר crops/
from PIL import Image
import os, glob

for source in glob.glob("qa/*/*/packshot.png"):
    sku_dir = os.path.dirname(source)
    img = Image.open(source)
    w, h = img.size
    out = f"{sku_dir}/crops"
    os.makedirs(out, exist_ok=True)

    # 1:1 — ריבוע מהאמצע
    s = min(w, h)
    img.crop(((w-s)//2, (h-s)//2, (w+s)//2, (h+s)//2)).save(f"{out}/1x1.png")

    # 4:5 — חיתוך אנכי
    target_w_4x5 = int(h * 4 / 5)
    img.crop(((w-target_w_4x5)//2, 0, (w+target_w_4x5)//2, h)).save(f"{out}/4x5.png")

    # 9:16 — חיתוך צר-ארוך
    target_w_9x16 = int(h * 9 / 16)
    img.crop(((w-target_w_9x16)//2, 0, (w+target_w_9x16)//2, h)).save(f"{out}/9x16.png")

מתי כן צריך להפיק מחדש ל-proportion

אם המוצר עצמו ארוך מאוד (שרשרת, מקל הליכה, רולר) — החיתוך 9:16 יקצר אותו. במקרה כזה, הפיקו גרסה 9:16 ייעודית עם prompt שמדגיש "vertical composition, full product visible top to bottom". עבור רוב המוצרים הסטנדרטיים — חיתוך מספיק.

bundle / set shots — כמה SKU בסצנה אחת

לפעמים אתם רוצים תמונה אחת עם כמה מוצרים ביחד: ערכת מוצרים (קרם + טונר + סרום ביחד), סט רהיטים (ספה + שולחן + מנורה), או אוסף מוצרים ב-banner של החנות. זה bundle / set shot.

הטכניקה — multi-reference מורחבת

במקום 6 references של אותו מוצר — מזינים 6 references של 6 מוצרים שונים, וב-prompt מבקשים "all 6 products arranged on the marble surface, softbox lighting". המודל ישמור על כל אחד מהמוצרים בזהותו (עד 14 אובייקטים, לפי התיעוד של Nano Banana Pro/2) וירכיב אותם בסצנה אחת.

למה זה שימושי

• עמודי collection: "הקולקציה החורפית שלנו" — 6 מוצרים בתמונה אחת. הלקוח רואה את כל הסט, נכנס לחנות לראות כל אחד לעומק.
• banners: ה-banner הראשי של החנות — מוצר מוביל + 2-3 מוצרים משלימים. תמונה אחת מספרת סיפור.
• cross-sell: "קנית קרם? הנה הטונר והסרום שעובדים איתו יפה". תמונה אחת עם 3 מוצרים = upsell ויזואלי.
• קיטים וערכות: "ערכת טיפוח מלאה" — 5 מוצרים ביחד, במחיר ערכה. תמונה אחת = ה-look-and-feel של הערכה.

האתגר — עקביות בין המוצרים

ככל שיש יותר מוצרים בתמונה, כך קשה יותר למודל לשמור על כולם. ב-3 מוצרים — מצוין. ב-5 — טוב. ב-8+ — מתחיל לערבב, לשנות גוונים, "לאבד" מוצרים. המלצה: עד 5 מוצרים לכל bundle. אם צריך יותר — פצלו ל-2 תמונות.

prompt template ל-bundle

Subject: [PRODUCT-1], [PRODUCT-2], [PRODUCT-3], [PRODUCT-4]
Composition: arranged in a [composition style — flat lay, hero stack, side by side]
Surface: [surface — marble, oak, linen, white seamless]
Lighting: [lighting — softbox, three-point, golden hour]
Style: [brand aesthetic — minimalist, warm, editorial, e-commerce]
Arrangement: [arrangement notes — spaced, overlapping, pyramid, grid]
Negative: no fake reflections, no extra products not in references, no style drift between products

ה-batch flow ל-bundles

ב-CSV, צרו עמודה נוספת bundle_partner_skus (מופרד ב-|). אם השדה ריק — מוצר בודד. אם מלא — הסקריפט אוסף את כל ה-references של ה-SKUs המשותפים, מייצר prompt template, ושולח קריאה אחת.

catalog refresh — רענון קטלוג ישן בלי לצלם מחדש

לרוב החנויות יש קטלוג ישן — תמונות מ-2018-2022, צילום טלפון, תאורה לא-אחידה, רקעים עמוסים. צילום מחדש של 200 מוצרים = בלתי-אפשרי תקציבית. catalog refresh פותר את זה: לוקחים את התמונות הישנות, מעלים אותן כ-reference, ומבקשים מהמודל "same product, new background, studio lighting".

הזרימה

קלט: תמונה ישנה (אפילו באיכות בינונית) של המוצר על רקע לא-מקצועי. פלט: תמונה חדשה על רקע נקי, באותו template כמו שאר הקטלוג.

המודל מזהה את המוצר מה-reference (גם אם הוא באיכות בינונית) ומייצר אותו מחדש על רקע חדש. זה כמו "לקחת את המוצר מהעולם הישן ולשים אותו בעולם החדש".

ההבדל מ-multi-reference רגיל

ב-multi-reference רגיל (פרק 4) העלינו 6 זוויות נקיות. ב-catalog refresh, לפעמים יש רק 1-2 תמונות, והן באיכות בינונית. זה עובד, אבל פחות טוב. המודל מסתמך על מה שיש — ואם ה-reference מטושטשת או חשוכה, התוצאה תהיה פחות מדויקת. לכן catalog refresh עובד הכי טוב על מוצרים שה-reference שלהם מספיק ברורה — גם אם לא מושלמת.

תהליך העבודה

1. מיינו את הקטלוג הישן. סמנו תמונות "לרענון" (רקע עמוס, תאורה גרועה, רזולוציה נמוכה) לעומת "להשאיר" (תמונות טובות שכבר קיימות).
2. העלו ל-CSV. עמודה נוספת old_image_path עם הנתיב לתמונה הישנה.
3. prompt מותאם. "Same product as in the reference (old photo). New background: [white seamless / marble / oak]. Studio lighting, e-commerce style. Match the product exactly — same color, same label, same proportions."
4. batch. אותו pipeline, רק עם reference אחת במקום 6, ו-prompt שמתייחס ל"reference photo".
5. QA קפדני. catalog refresh הוא הסיכון הגבוה ביותר לפגמים — בדקו כל תמונה לעומק.

למה catalog refresh הוא חוסך-כסף אמיתי

צילום מחדש של 200 מוצרים = $2,000-10,000. Catalog refresh דרך batch = $80-150. חיסכון של 95-99%. וזה לא רק חיסכון — זה שיפור איכות. הקטלוג שלכם ייראה אחיד (אותו template), מקצועי (תאורת סטודיו), ועדכני (2026-style).

מלכודת ה-cohesion — למה batch מתפזר בלי נעילה

המלכודת הגדולה ביותר ב-batch pipeline. אתם מריצים batch על 50 SKU מ-template אחד, ומקבלים 50 תמונות — אבל כל אחת נראית כמו צילום אחר. רקע שונה, תאורה שונה, סגנון שונה. כל העקביות מפרק 4 נמחקה.

למה זה קורה? כי בלי נעילה מספיק, המודל "מתפזר" — כל קריאה מקבלת הקשר קצת אחר, ומייצרת תוצאה קצת אחרת.

חמש דרגות הנעילה — מחלשה לחזקה

1. רק template זהה. כל ה-SKUs מקבלים את אותו template. חלש — זה הבסיס המינימלי.

2. + seed קבוע. אותו seed לכל הקריאות. חזק יותר — נועל את ה"רנדומיזציה" של המודל.

3. + 6 references זהות של רקע. לא רק references של המוצר — גם reference image אחת של הרקע (ה-moodboard, לוח השראה). חזק יותר — נועל את הרקע.

4. + prompt זהה מילה במילה. אסור לשנות שום מילה בין SKU ל-SKU, רק את subject. חזק יותר — נועל את הסגנון.

5. + אותו num_inference_steps ואותו image_size. אסור שונות בפרמטרים. חזק ביותר — נועל את ההפעלה עצמה.

המתכון המעשי ל-batch עקבי

אני ממליץ להשתמש בדרגה 3-4 לרוב המקרים. הנה הקוד שמבטיח זאת:

# בתוך הסקריפט, לפני כל קריאה:
SEED = 42                          # אותו seed לכל ה-SKUs
BG_REFERENCE = "templates/bg-marble.jpg"  # reference של הרקע
STEPS = 30                         # אותו מספר steps
SIZE = "square_hd"                 # אותה רזולוציה

# ה-prompt בנוי כך שרק subject משתנה
prompt = f"""[TEMPLATE_FULL_TEXT]
Subject: {row['name']}
Preserve the background and lighting from the BG_REFERENCE exactly.
Same product as in the 6 references, not inspired by them."""

הסימן המעשי לכשל cohesion

אחרי הריצה, פתחו 3 תמונות רנדומליות מהקטלוג זו לצד זו. שאלו: "האם הן נראות כמו צילום של אותה חנות באותו בוקר?". אם התשובה "לא" — ה-cohesion נשבר. חזרו לבדוק: (1) האם ה-template זהה? (2) האם ה-seed זהה? (3) האם הרקע references זהות? אחת מהן כנראה לא נכונה.

GA מול Preview — לא לבנות pipeline על חול

לפני שאתם בונים pipeline ל-200 SKU, חשוב להבין את מצבי הזמינות של הפיצ'רים בפלטפורמות. כל פיצ'ר חדש בעולם ה-AI מתחיל ב-Preview (ניסיוני) ועובר ל-GA (Generally Available — זמין ויציב). ההבדל קריטי.

מה ההבדל

Preview: זמין לשימוש, אבל: (1) עלול להשתנות בלי התראה; (2) עלול להיסגר; (3) ללא SLA (Service Level Agreement — התחייבות לזמינות ואיכות); (4) לפעמים רק לחלק מהמשתמשים. GA: זמין לכולם, יציב, נתמך, עם SLA.

המקרה הקלאסי — 4K ב-Vertex AI

ב-Vertex AI (הפלטפורמה של Google Cloud), רזולוציית 4K ל-Nano Banana Pro היא Preview נכון לאמצע 2026. זה אומר: היא עובדת, אבל אין לה תאריך GA רשמי. אם תבנו את כל ה-pipeline שלכם על 4K, ייתכן שבעוד חודש-חודשיים היא תיסגר או תשתנה. תיקון: תכננו על 2K (GA) והשתמשו ב-4K רק למקרים ספציפיים.

הרשימה המעשית (אמצע 2026)

הכלל: "GA לפני Preview"

אם פיצ'ר הוא Preview — אל תבנו עליו pipeline. תכננו שתוכלו לעבור בקלות לחלופה GA אם ה-Preview נסגר. זה לא אומר לא להשתמש — זה אומר לא לבנות תלות קריטית.

תרגילים — 3 תוצרים שעוזבים אתכם עם הפרק

שלושת התרגילים האלה בונים את ה-batch pipeline הראשון שלכם end-to-end: CSV → references → template → batch API → תיקיית QA. כל תרגיל מייצר קובץ שישמש אתכם בפרק 6 ובקטלוג האמיתי.

טעויות נפוצות

ארבע טעויות שחוזרות על עצמן אצל כל מי שמתחיל batch pipeline. כולן ניתנות לתיקון — אם מזהים אותן מוקדם.

Work Routine — שגרת batch

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

מילון מונחי הפרק