ארכיטקטורת Production AI: מ-Prompt בסיסי ל-LLMOps מקצועי

אם יש לכם סקריפט Python שקורא ל-OpenAI API עם Prompt קבוע ומחזיר תשובה זה מצוין, יש לכם דמו. אבל אין לכם מוצר. המרחק בין "זה עובד לי על המחשב" לבין מערכת Production שמשרתת אלפי משתמשים, לא דורפטת (drift), לא ממציאה עובדות ולא קורסת תחת עומס, המרחק הזה הוא בדיוק מה שנקרא LLMOps. המדריך הזה לוקח אתכם צעד אחר צעד מ-Prompt בודד ועד ארכיטקטורה שלמה שמוכנה לעולם האמיתי. בלי קיצורי דרך, בלי הבטחות שווא, עם קוד שאפשר להריץ היום.

לפני שנצלול לארכיטקטורה, בואו נעשה סדר מושגי. LLMOps — קיצור של Large Language Model Operations — הוא מערך הפרקטיקות, הכלים והתהליכים שמאפשרים להריץ מודלים גנרטיביים גדולים (LLMs) בסביבת Production בצורה אמינה, מדידה וניתנת לשליטה.

ב-MLOps הקלאסי עסקנו באימון מודלים, ניהול features, ו-model registry. ב-LLMOps רוב הצוותים לא מאמנים מודל בכלל, הם צורכים API של מודל קיים (GPT-4, Claude, Gemini, Mistral) ומוסיפים מעליו שכבות של הנדסת Prompt, שליפת מידע (RAG), guardrails ומוניטורינג.

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

למה Prompt בסיסי לא מספיק ל-Production?

נניח שבניתם צ'אטבוט שירות לקוחות. ביום הראשון הוא עובד מצוין. בשבוע השני ספק ה-API שינה את המודל — ופתאום התשובות התארכו ב-40% והנימה השתנתה. בחודש השלישי לקוח שאל שאלה בערבית והמערכת החזירה שטויות. וכל הזמן הזה — אין לכם שום מדד שמגלה את הבעיה לפני שהלקוח מתלונן.

הנה הבעיות שצפים ברגע שלוקחים LLM ל-Production:

• Prompt drift: שינויים במודל הבסיסי גורמים לתוצאות שונות עם אותו Prompt בדיוק.
• הזיות (Hallucinations): המודל ממציא עובדות בביטחון מלא, ובלי evaluation אוטומטי, אף אחד לא יודע.
• עלויות בלתי צפויות: בלי ניהול tokens חכם, חשבון ה-API יכול לפוצץ תקציבים.
• אבטחה ופרטיות: מידע רגיש של לקוחות יכול לדלוף ל-API חיצוני.
• חוסר שחזוריות: בלי ניהול גרסאות ל-Prompts, אי אפשר לחזור לגרסה שעבדה.

מהן חמש השכבות של ארכיטקטורת LLMOps?

כל מערכת LLM ב-Production צריכה חמש שכבות, לא יותר, לא פחות:

1. שכבת Prompt Management: ניהול גרסאות, templating, A/B testing של Prompts.
2. שכבת אורקסטרציה (Orchestration): שרשור קריאות, RAG, tool calling, ניהול זיכרון.
3. שכבת Evaluation: בדיקות אוטומטיות לאיכות תשובות — LLM-as-a-judge, מדדי relevance, faithfulness.
4. שכבת Observability: לוגים, traces, latency, token usage, עלויות — הכול בזמן אמת.
5. שכבת Guardrails: סינון input/output, הגנה מפני prompt injection, אכיפת מדיניות תוכן.

עכשיו ניגש לחלק שבו מלכלכים ידיים. אני הולך להראות לכם בנייה שלב-אחר-שלב של מערכת Production AI שכוללת RAG, evaluation אוטומטי ו-observability. הדוגמאות כתובות ב-Python עם LangChain, אבל העקרונות רלוונטיים לכל סטאק.

שלב 1: ניהול Prompts כקוד — איך מונעים כאוס?

הכלל הראשון: Prompt הוא קוד. הוא חי ב-Git, עובר code review, יש לו גרסה, יש לו בדיקות. אם ה-Prompt שלכם חי בתוך string בקוד Python ומישהו משנה אותו ב-commit בלי תיעוד — אתם בדרך לאסון.

המבנה המומלץ לפרויקט:

project-root/
├── prompts/
│   ├── v1/
│   │   ├── system_prompt.txt
│   │   ├── user_template.txt
│   │   └── metadata.yaml
│   ├── v2/
│   │   ├── system_prompt.txt
│   │   ├── user_template.txt
│   │   └── metadata.yaml
│   └── current -> v2/          # symlink לגרסה הפעילה
├── evals/
│   ├── test_cases.jsonl
│   └── run_eval.py
├── chains/
│   └── rag_chain.py
├── guardrails/
│   └── content_policy.yaml
└── observability/
    └── callbacks.py

וכך נראה קובץ metadata.yaml שמתעד כל גרסה:

version: "2.1"
author: "dana.k"
date: "2026-09-10"
description: "שיפור דיוק בתשובות על מדיניות החזרות"
model: "gpt-4o"
temperature: 0.2
max_tokens: 1024
eval_score: 0.87
promoted_to_prod: true
changelog:
  - "הוספת הנחיה מפורשת לציטוט מקור"
  - "הורדת temperature מ-0.4 ל-0.2 לעקביות"

טעות נפוצה: הרבה צוותים מנהלים Prompts ב-UI של פלטפורמה כלשהי, בלי Git. ביום שהפלטפורמה משנה API או שצריך לעשות rollback — הם מגלים שאין להם היסטוריה. Prompt-as-Code הוא לא אופציה, הוא תנאי סף.

שלב 2: בניית שרשרת RAG מוכנה ל-Production

RAG — Retrieval Augmented Generation — הוא הפטרן הנפוץ ביותר ב-Production AI. במקום לסמוך על הזיכרון הפנימי של המודל, אנחנו שולפים מידע רלוונטי ממאגר ידע ומזריקים אותו ל-Prompt. לפי סקרים בתעשייה מהשנה האחרונה, למעלה מ-80% ממערכות ה-LLM ב-Production משתמשות ב-RAG בצורה כזו או אחרת.

הנה קוד עובד של שרשרת RAG עם LangChain:

from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import Chroma
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_core.runnables import RunnablePassthrough
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.document_loaders import DirectoryLoader

# 1. טעינה ופיצול מסמכים
loader = DirectoryLoader("./knowledge_base", glob="**/*.md")
docs = loader.load()
splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=100,
    separators=["nn", "n", ".", " "]
)
chunks = splitter.split_documents(docs)

# 2. יצירת Vector Store
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db"
)
retriever = vectorstore.as_retriever(
    search_type="mmr",        # Maximal Marginal Relevance - מגוון תוצאות
    search_kwargs={"k": 5, "fetch_k": 20}
)

# 3. טעינת Prompt מקובץ (לא hardcoded!)
with open("prompts/current/system_prompt.txt", "r") as f:
    system_prompt = f.read()

prompt = ChatPromptTemplate.from_messages([
    ("system", system_prompt),
    ("human", """השתמש אך ורק במידע הבא כדי לענות על השאלה.
אם אין מספיק מידע — אמור בכנות שאינך יודע.

הקשר:
{context}

שאלה: {question}""")
])

# 4. בניית השרשרת
llm = ChatOpenAI(model="gpt-4o", temperature=0.2)

chain = (
    {"context": retriever, "question": RunnablePassthrough()}
    | prompt
    | llm
    | StrOutputParser()
)

# 5. הרצה
response = chain.invoke("מהי מדיניות ההחזרות לרכישות מעל 500 שקל?")
print(response)

שימו לב לכמה דברים קריטיים בקוד הזה: ה-Prompt נטען מקובץ חיצוני (לא hardcoded), ה-retriever משתמש ב-MMR לגיוון תוצאות, וה-temperature נמוך (0.2) לעקביות. אלה לא פרטים קטנים, אלה ההבדלים בין דמו ל-Production.

שלב 3: איך בודקים איכות של LLM באופן אוטומטי?

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

הפרקטיקה המקובלת כיום היא שילוב של שלושה סוגי evaluation:

• Rule-based: בדיקות דטרמיניסטיות, האם התשובה מכילה ציטוט? האם האורך בטווח? האם אין מילים אסורות?
• LLM-as-a-judge: מודל שני שמעריך את התשובה לפי קריטריונים: דיוק, רלוונטיות, נאמנות למקור.
• Human-in-the-loop: דגימה של תשובות לסקירה ידנית, בעיקר לאיתור edge cases.

הנה סקריפט evaluation בסיסי שמשלב שני הסוגים הראשונים:

import json
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate

# טעינת test cases
with open("evals/test_cases.jsonl", "r") as f:
    test_cases = [json.loads(line) for line in f]

judge_llm = ChatOpenAI(model="gpt-4o", temperature=0.0)

judge_prompt = ChatPromptTemplate.from_messages([
    ("system", """אתה שופט איכות. העריך את התשובה לפי הקריטריונים:
1. relevance (0-1): האם התשובה רלוונטית לשאלה?
2. faithfulness (0-1): האם התשובה נאמנה למידע שסופק בהקשר?
3. completeness (0-1): האם התשובה שלמה?
החזר JSON בלבד: {{"relevance": X, "faithfulness": X, "completeness": X, "reasoning": "..."}}"""),
    ("human", """שאלה: {question}
הקשר שסופק: {context}
תשובת המערכת: {answer}
תשובה מצופה: {expected}""")
])

results = []
for case in test_cases:
    # הרצת השרשרת
    answer = chain.invoke(case["question"])

    # בדיקות Rule-based
    rule_checks = {
        "length_ok": 50 < len(answer) < 2000,
        "no_forbidden_words": not any(w in answer for w in ["כנראה", "אולי אני טועה"]),
        "has_source_ref": "לפי" in answer or "על פי" in answer
    }

    # LLM-as-a-judge
    judge_response = judge_llm.invoke(
        judge_prompt.format(
            question=case["question"],
            context=case.get("context", ""),
            answer=answer,
            expected=case["expected_answer"]
        )
    )
    scores = json.loads(judge_response.content)

    results.append({
        "question": case["question"],
        "rule_checks": rule_checks,
        "llm_scores": scores
    })

# חישוב ציון כולל
avg_relevance = sum(r["llm_scores"]["relevance"] for r in results) / len(results)
avg_faithfulness = sum(r["llm_scores"]["faithfulness"] for r in results) / len(results)
print(f"Average Relevance: {avg_relevance:.2f}")
print(f"Average Faithfulness: {avg_faithfulness:.2f}")

# Gate: אם הציון מתחת לסף — לא עולים ל-Production
MINIMUM_SCORE = 0.85
if avg_faithfulness < MINIMUM_SCORE:
    raise ValueError(f"Faithfulness {avg_faithfulness:.2f} below threshold {MINIMUM_SCORE}")

הסקריפט הזה אמור לרוץ כחלק מה-CI/CD שלכם. כל שינוי ב-Prompt, בלוגיקת ה-RAG, או בגרסת המודל, עובר evaluation אוטומטי לפני שהוא מגיע ל-Production. אם הציון נמוך מהסף, ה-deployment נכשל. נקודה.

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

שורה תחתונה לפועלים: אין כלי אחד שעושה הכול. הארכיטקטורה המומלצת היא שילוב: LangChain לאורקסטרציה + LiteLLM ל-routing + LangSmith או Helicone ל-observability + Guardrails AI ל-validation. התחילו עם שניים, הוסיפו בהדרגה.

מתי כדאי לבחור מודל קוד-פתוח לעומת API מנוהל?

זו שאלה שעולה בכל פרויקט LLM בישראל, במיוחד בחברות שמטפלות בנתונים רגישים (פינטק, הלת'טק, ביטחון). לפי סקרים בתעשייה מהתקופה האחרונה, כ-40% מחברות הטכנולוגיה בישראל כבר מריצות מודלים מקומיים (on-premise או VPC פרטי) לפחות חלק מה-workloads שלהם.

בחרו API מנוהל (OpenAI, Anthropic, Google) כאשר: אתם צריכים את הביצועים הטובים ביותר, הנתונים לא רגישים במיוחד, אתם רוצים TTM (Time To Market) מהיר, והצוות קטן.

בחרו מודל קוד-פתוח (Llama, Mistral, Qwen) כאשר: יש דרישות רגולטוריות לפרטיות (GDPR, רגולציית בנק ישראל), אתם צריכים שליטה מלאה על המודל, העלויות ב-scale גבוהות מדי עם API חיצוני, או שאתם צריכים fine-tuning על דומיין ספציפי.

הגישה המעשית ביותר: LiteLLM כ-proxy שמאפשר לכם להחליף בין ספקים בלי לשנות קוד. הנה הגדרה בסיסית:

# litellm_config.yaml
model_list:
  - model_name: "main-model"
    litellm_params:
      model: "gpt-4o"
      api_key: "os.environ/OPENAI_API_KEY"

  - model_name: "main-model"      # fallback עם אותו שם
    litellm_params:
      model: "anthropic/claude-3.5-sonnet"
      api_key: "os.environ/ANTHROPIC_API_KEY"

  - model_name: "fast-model"       # למשימות פשוטות / חסכוניות
    litellm_params:
      model: "groq/llama-3.1-70b-versatile"
      api_key: "os.environ/GROQ_API_KEY"

router_settings:
  routing_strategy: "latency-based-routing"
  num_retries: 2
  timeout: 30
  fallbacks: [{"main-model": ["fast-model"]}]

general_settings:
  max_budget: 500          # דולר לחודש — hard limit
  budget_duration: "30d"

# הרצת LiteLLM proxy
pip install litellm[proxy]
litellm --config litellm_config.yaml --port 4000

# עכשיו כל קריאה עוברת דרך ה-proxy
curl http://localhost:4000/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{
    "model": "main-model",
    "messages": [{"role": "user", "content": "מהי מדיניות ההחזרות?"}]
  }'

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

מה צריכים לנטר במערכת LLM ב-Production?

הנה המדדים הקריטיים:

• Latency: P50, P95, P99 — לא רק ממוצע. אם ה-P99 שלכם הוא 12 שניות, אחד מכל מאה משתמשים מחכה 12 שניות.
• Token usage ועלות: לכל קריאה, לכל משתמש, לכל שרשרת. בלי זה אתם מגלים בסוף החודש שחרגתם מהתקציב.
• שיעור הזיות: כמה אחוז מהתשובות נכשלות ב-faithfulness check. הסף המקובל הוא מתחת ל-5%.
• Retrieval quality: ב-RAG — האם ה-chunks שנשלפו רלוונטיים? אפשר למדוד עם hit rate ו-MRR (Mean Reciprocal Rank).
• User feedback: 👍/👎 פשוט, אבל שווה זהב כשמצטבר לאלפי דגימות.
• Guardrail triggers: כמה קריאות נחסמו, ולמה? עלייה פתאומית = מישהו מנסה prompt injection.

איך מגדירים Guardrails שמונעים תקלות?

Guardrails הם הקו האחרון בין המודל לבין המשתמש. הם בודקים גם את ה-input (מה שהמשתמש שולח) וגם את ה-output (מה שהמודל מחזיר):

from guardrails import Guard
from guardrails.hub import (
    ToxicLanguage,
    DetectPII,
    RestrictToTopic,
    ReadingTime
)

# הגדרת Guard עם validators מרובים
guard = Guard().use_many(
    # בדיקת input
    ToxicLanguage(
        threshold=0.8,
        on_fail="exception"
    ),
    DetectPII(
        pii_entities=["EMAIL_ADDRESS", "PHONE_NUMBER", "CREDIT_CARD"],
        on_fail="fix"         # מסיר PII אוטומטית במקום לחסום
    ),

    # בדיקת output
    RestrictToTopic(
        valid_topics=["מדיניות החזרות", "משלוחים", "שירות לקוחות"],
        invalid_topics=["פוליטיקה", "דת", "מתחרים"],
        on_fail="reask"       # מבקש מהמודל לנסות שוב
    ),
    ReadingTime(
        reading_time=30,      # לא יותר מ-30 שניות קריאה
        on_fail="fix"
    )
)

# שימוש ב-Guard עם LLM
raw_response = guard(
    llm_api=chain.invoke,
    prompt="מה מדיניות ההחזרות למוצרי חשמל?",
    num_reasks=2              # ניסיונות חוזרים אם נכשל
)

if raw_response.validation_passed:
    print(raw_response.validated_output)
else:
    print(f"Blocked: {raw_response.error}")

המציאות: לפי דוח של OWASP מהשנים האחרונות, prompt injection נמצא בראש רשימת הסיכונים של אפליקציות LLM. ב-Production ישראלי, במיוחד בפינטק ובהלת'טק, guardrails הם לא nice-to-have — הם דרישת רגולציה.

המעבר מ-Prompt בסיסי ל-LLMOps מקצועי הוא לא שאלה של כלים, הוא שאלה של חשיבה. ברגע שאתם מפנימים שה-Prompt הוא קוד, שה-output חייב להיבדק, שכל קריאה חייבת להיות מתועדת, ושהמודל יכול להשתנות מתחתיכם, אתם בדרך הנכונה. השאר הוא הנדסה, והנדסה אפשר ללמוד.

• התחילו מ-Prompt Management: העבירו את כל ה-Prompts שלכם ל-Git עם גרסאות ו-metadata. זה יום עבודה אחד שחוסך חודשים של כאב.
• בנו evaluation pipeline לפני שמוסיפים פיצ'רים: 20 test cases מוגדרים היטב שווים יותר מ-1,000 שורות קוד חדשות.
• הוסיפו observability מהרגע הראשון: LangSmith או Helicone — פשוט תדליקו. העלות אפסית, הערך עצום.
• אל תתחילו עם fine-tuning: ב-90% מהמקרים, RAG טוב עם Prompt מדויק מספיק. Fine-tuning שמור למקרים שבהם באמת מיציתם את הפוטנציאל.
• השקיעו ב-guardrails לפני שאתם חושפים את המערכת למשתמשים: prompt injection הוא אמיתי, PII leaks הם אמיתיים, ותביעה משפטית על הזיה היא אמיתית.

עודכן: 2026-09-14

מה ההבדל בין MLOps ל-LLMOps?

MLOps עוסק בניהול מחזור החיים של מודלי Machine Learning שאתם מאמנים, ניהול נתוני אימון, feature store, model registry ו-retraining. LLMOps עוסק בניהול מערכות שצורכות מודלי שפה גדולים קיימים — ניהול Prompts, שרשרות RAG, evaluation של תשובות טקסטואליות, guardrails ומוניטורינג של עלויות tokens. למרות ששניהם שייכים ל-AI Operations, הכלים והאתגרים שונים מהותית.

כמה זמן לוקח לבנות ארכיטקטורת LLMOps ל-Production?

עם ניסיון והכלים הנכונים, MVP מוכן ל-Production עם RAG, evaluation בסיסי ו-observability — בין שבוע לשבועיים. ארכיטקטורה מלאה עם guardrails, A/B testing של Prompts, ומוניטורינג מתקדם, בין חודש לשלושה חודשים, תלוי בגודל הצוות ובמורכבות הדומיין.

האם חייבים להשתמש ב-LangChain לבניית מערכת LLM?

ממש לא. LangChain היא ספרייה פופולרית ונוחה, אבל לא חובה. חלופות כמו LlamaIndex (במיוחד ל-RAG), Haystack, או אפילו קוד Python "נקי" שקורא ישירות ל-API — כולם לגיטימיים. הבחירה תלויה במורכבות המערכת, בניסיון הצוות, ובצורך באינטגרציות. לפרויקטים פשוטים, קריאה ישירה ל-API עם LiteLLM כ-proxy יכולה להספיק.

איך מונעים הזיות (Hallucinations) של המודל?

אי אפשר למנוע הזיות לחלוטין, אבל אפשר להקטין אותן דרמטית: שימוש ב-RAG עם מסמכים איכותיים, הנחיה מפורשת ב-Prompt "אם אינך יודע, אמור שאינך יודע", temperature נמוך (0.1-0.3), evaluation אוטומטי עם faithfulness check, ו-guardrails שמסננים תשובות שלא מגובות בהקשר שסופק. השילוב של כל אלה מוריד את שיעור ההזיות למתחת ל-5% ברוב המקרים.

מה העלות החודשית הממוצעת של מערכת LLM ב-Production?

העלות תלויה בנפח הקריאות ובמודל שנבחר. לצורך הדגמה: מערכת שמשרתת 10,000 שאילתות ביום עם GPT-4o עולה בערך 300-800 דולר לחודש על API בלבד. הוספת כלי observability (LangSmith/Helicone) — 50-200 דולר. Vector DB מנוהל (Pinecone/Weaviate Cloud) — 70-250 דולר. סך הכול: 500-1,500 דולר לחודש ל-workload ממוצע. שימוש ב-LiteLLM עם fallback למודלים זולים יותר יכול לחתוך 30-50% מהעלות.

איך בודקים שה-RAG שולף מסמכים רלוונטיים?

שתי שיטות עיקריות: (1) Hit Rate — מתוך קבוצת שאילתות מוגדרת מראש, באיזה אחוז מהמקרים המסמך הנכון נמצא ב-top-k תוצאות; (2) MRR (Mean Reciprocal Rank) — באיזה מיקום ממוצע מופיע המסמך הנכון. כדי למדוד את אלה, צריך "golden dataset" — רשימה של שאלות עם המסמכים הנכונים שאמורים להישלף. המלצה: התחילו עם 50 זוגות שאלה-מסמך, הריצו eval כל שבוע.

האם LLMOps רלוונטי גם לחברות קטנות בישראל?

דווקא חברות קטנות הן אלה שלא יכולות להרשות לעצמן לעבוד בלי LLMOps. כשאין צוות גדול שיתפוס באגים ידנית, אוטומציה של evaluation ומוניטורינג היא קריטית עוד יותר. בנוסף, חברות ישראליות שמשרתות לקוחות אירופיים חייבות guardrails ל-GDPR compliance. הכלים בקוד פתוח (LangChain, LiteLLM, Guardrails AI) מאפשרים לעשות את זה בעלות אפסית כמעט.

הגעתם עד לכאן? מצוין. עכשיו יש לכם מפת דרכים ברורה — מ-Prompt בודד ועד ארכיטקטורה מלאה של LLMOps ב-Production. אנחנו יודעים שזה הרבה — ובדיוק בשביל זה הדלת פתוחה. באתר rt-ed.co.il תמצאו מדריכים נוספים, תרגולים מעשיים וקורסים שלוקחים את הנושאים האלה לעומק — עם ידיים על המקלדת, לא רק תיאוריה. כי ללמוד AI בלי לבנות מערכות אמיתיות זה כמו ללמוד לשחות מספר — בשלב מסוים צריך לקפוץ למים.

מקורות לימוד מומלצים

• קורסים: מסלול קורס AI Engineer המעניק הבנה מעמיקה בבנייה ואימון של מודלים למידת מכונה ולמידה עמוקה (Deep Learning), עבודה עם ארכיטקטורות Transformer, פיתוח אפליקציות מבוססות LLM (כמו RAG ו-Agents), ופריסת מודלים בסביבות ייצור (MLOps).

• בלוגים / פורומים: Hugging Face Blog, Distill.pub, OpenAI Research, Towards Data Science (Medium), Reddit (r/MachineLearning, r/LocalLLaMA).

• ספרים: Hands-On Machine Learning with Scikit-Learn, Keras, and TensorFlow (של Aurélien Géron), Designing Machine Learning Systems (של Chip Huyen).

• קורס סייבר ואבטחת מידע
• קורס Real Time Embedded
• קורס דאטה סיינס
• קורס למידת מכונה AI
• קורס דאטה אנליסט
• קורס DEVOPS
• קורס IT
• קורס אוטומציה
• קורס Full Stack
• קורס בניית אתרים