בפוסט הראשון (לינק) הצגנו תהליך Canonicalization והכרנו כמה כלי NLP בסיסיים וחשובים – אבל היו כמה שלא הזכרנו – שחשוב להכיר. לכך מוקדש הפוסט הזה.

Lemmatization (או Morphological Normalization)

בבלשנות, מורפולוגיה היא תחום העוסק באופן שבו מילים נוצרות ומוטות (משתנות לפי זמן, מספר, מין וכו’). למשל:
• run → running, runs, ran — פּוֹעַל בצורות שונות.
• service → services, servicing — שם עצם ופּוֹעַל הנגזרים מאותו שורש.
• good → better → best — שינוי מדרגת תואר.

lemmatization עוזר לנו לנרמל את המשמעות בכך שהוא הופך מילים להטיה קאנונית שקל להשוות. למשל:

Explanation	Part of Speech (POS)	Lemma	Token
Irregular plural normalized to singular	Noun	child	children
Past tense → base verb “be”	Auxiliary Verb	be	were
Present participle → base “run”	Verb	run	running
No change; already base form	ADV	fast	fast
No change for prepositions	ADP	in	in
Determiner, unchanged	DET	the	the
Noun in singular form, stays same	Noun	park	park

שווה לציין מונח דומה בשם Stemming תהליך דומה ל Lemmatization אבל מבוסס-חוקים / יוריסטיקות – לא ניתוח תחבירי או מורפולוגי. הוא מהיר הרבה יותר, ומשמעותית פחות מדויק. מתאים בעיקר לכמויות גדולות של טקסט כאשר הדיוק חשוב פחות. לדוגמה Stemmer הוא חלק מתהליך ניתוח הטקסט של ה Indexing של Elasticsearch.

בואו נראה קצת קוד:

from rapidfuzz import fuzz
import spacy

nlp = spacy.load("en_core_web_sm") # small vector english model. Included.

def lemmatize(text):
    return " ".join([t.lemma_ for t in nlp(text.lower())])

text1 = "children were running fast in the park"
text2 = "a child in the park ran fast"

fuzz.WRatio(text1, text2) # score: ~70
fuzz.WRatio(lemmatize(text1), lemmatize(text2)) # score: ~92

כמובן ש RapidFuzz הוא לא שימוש יחיד. במקרה, בפוסט, השתמשנו בו. הרבה פעמים נשתמש בטקסט לחיפוש, פענוח intent, סיווג הטקסט – ושימושים אחרים. בכל אלו – lemmatization הוא כלי מרכזי.

חשוב לציין שלמטיזציה (lemmatization) מטפלת רק בצורה של המילה, לא במשמעות שלה. במקרה של Good vs. Best – צפויה לנו אכזבה.

print(fuzz.WRatio("good", "better")) # score: 0.0
print(fuzz.WRatio("good", "best")) # score: 0.0
print(fuzz.WRatio(lemmatize("good"), lemmatize("better"))) # score: 0.0

במקרה שאנחנו רוצים להשוות משמעות, אנחנו משתמשים ב semantic similarity, למשל:

import spacy

nlp = spacy.load("en_core_web_lg") # LARGE vector english model

print(nlp("good").similarity(nlp("better"))) # score: ~81
print(nlp("good").similarity(nlp("bad"))) # score: ~73; note we didn't get a negative number since the algorith directional closeness, not semantic opposition.
print(nlp("good").similarity(nlp("best"))) # score: 70

שימו לב שכדי שזה יצליח, עברנו לעבוד במודל הוקטורי הגדול של Spacy (צריך להוריד כ 400MB).

יש מגוון כלים/אלגוריתמים ל Semantic Similarity, ספציפית Spacy משתמשת ב cosine similarity – עליו ארצה להרחיב ולהסביר בפוסט המשך.

הפונקציה nlp() מריצה pipeline של עיבוד שפה:

• Tokenizer – חלוקת טקסט למלים / יחידות בעלות משמעות. במקרה שלנו, token יחיד.
  • כל אלגוריתם שמנסה “להבין” טקסט, בין אם זה מנוע חיפוש, מודל Transformer, או סתם regex — צריך לדעת מהן יחידות המשמעות שעליהן לעבוד. ללא Tokenization, כל הטקסט הוא רק רצף תווים חסר גבולות.
  • הערה: מודלי שפה גדולים (LLM) token הוא לא בהכרח מילה. לפעמים מחלקים מילה לכמה tokens, למשל: unbelievable ל ["un", "believ", "able"].
• Token to Vector (קרי embedding) – הופך את ה tokens לייצוג וקטורי (מערך של מספרים, למשל בין 1.0- ל 1.0). נרחיב עליו בהמשך.
• רכיבים שונים שמוסיפים metadata על ה tokens.
  • Tagger -סיווג Part of Speech (POS).
  • Parser – מנתח תלויות תחביריות במשפט. מי קשור למי.
  • NER – סיווג יישויות בטקסט: ״חברה״, ״מדינה״ וכו׳.

האובייקט שחוזר מפונקציית ה nlp() הוא doc המכיל את ה tokens ו metadata (סיווגים). ניתן לקסטם את ה pipeline ולהשבית / להוסיף שלבים. במקרה שלנו אנחנו מסתמכים על רק על ה embedding.

הפונקציה similarity() היא פונקציה הפועלת על מסמכים ומחזירה את המרחק הממוצע (ליתר דיוק: דמיון קוסיני) בין המסמכים. במקרה שלנו, כל מסמך מכיל רק token אחד, אז מדובר בדמיון סמנטי בין המושגים הבודדים ששלחנו.

Sentence Segmentation (או Sentence Boundary Detection בקיצור SBD)
פונקציית ה nlp() של SpaCy כוללת רכיב בשם dependency parser המפרק טקסט למשפטים. בסוג של tokenization, אנו יכולים לגשת ל doc.sents (בפייטון ובשפת C אוהבים לקצר שמות משתנים, לדעת) – רשימת המשפטים בטקסט. פירוק למשפטים הוא לא מלאכה קלה, ולא כל המודלים תומכים ביכולת הזו. בתוך אובייקט ה doc ה source of truth של החלוקה למשפטים הוא ברמת ה token, בתכונה token.is_sent_start ועריכת הערך שלו, קובעת את חלוקת המשפטים במסמך.

• שימוש בסיסי הוא להבין אם הטקסט שלנו כולל משפט אחד או יותר. למשל: אולי מישהו שרשר שני משפטים במקום שציפינו לאחד?
• כאשר מבצעים חיפוש / אינדוקס לפי הטקסט – יש משמעות לחלוקה למשפטים.
• צריך להגביל אורך של טקסט. אולי נעדיף לחתוך לפי משפטים, ולא חיתוך אקראי של הטקסט…
• וכו׳.

Embedding

תהליך ה embedding הוא תהליך שהופך tokens לוקטור (מערך מספרים עשרוניים). לכל וקטור יש מימדים, ו token נתון ממופה במרחב בכל מימד בנפרד. המרחקים במרחב מבטאים דמיון סמנטי, למשל:

• ״חתול״ ממופה ל [0.7, 0.5, 0.1]
• "כלב״ ממופה ל [0.8, 0.3, 0.1]
• ״אבטיח״ ממופה ל [0.1, 0.2, 0.8]

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

המימדים נקבעים ע״י ניתוח סטטיסטי ולא תמיד ניתן לתאר או להסביר אותם בצורה אינטואטיבית. כאשר עושים embedding לטקסט, אז כל token הופך לוקטור. תלוי במספר המימדים, אך הייצוג הוקטורי יכול להיות גדול או קטן מהייצוג הטקסטואלי (כאשר מודדים ב KB).

מדוע עושים embedding? רשתות ניורונים עובדות רק על מספרים, לא על טקסט. הייצוג הוקטורי מאפשר לנו לעבד את הטקסט ברשתות ניורוניות. אלגוריתמים כמו זיהוי סנטימנט או כוונה, סיכום, תרגום, זיהוי יישויות ועוד משיגים תוצאות טובות בהרבה על גבי רשתות ניורוניות מאשר בכלי NLP קלאסיים. ה Embedding הוא התרגום הנדרש כדי להפעיל טקסט על רשתות ניורונים לצורך הפעלת האלגוריתמים האלו. בעצם embedding הוא הייצוג הטבעי (״שפת המכונה״) של רשתות הניורונים.

יש מעט embeddings סטנדרטיים (למשל Word2Vec או GloVe) אבל רוב הפעמים שנעשה embedding נעשה אותם ל״שפה״ של מודל ספציפי, למשל BERT, GPT-4, GPT-5. כל embedding מגדיר:

• מבנה פנימי שונה (מספר שכבות, גודל וקטור, normalization),
• אוצר מילים שונה (tokenization אחר),
• מערכת קואורדינטות סמנטית שונה לגמרי.

נסווג את המודלים הזמינים לנו לשלוש קבוצות:

• מודלים קלאסיים – SpaCy (או ספריות דומות) מכילה מגוון מודלים, עם תכונות שונות, לשפות שונות (אנגלית, גרמנית, וכו׳). הם מיועדים בעיקר לניתוח ותיוג טקסט בשיטות NLP קלאסיות. יש מודלים לשפה כללית (web), משפטית, רפואית, וכו׳. המודלים משתמשים בעיקר ב embedding סטנדרטיים כגון GloVe שהם סטטים – כלומר לכל מילה יש וקטור קבוע מראש, ב 300 מימדים (במקרה של GloVe).
  • מודלים סטטיים לא ידע לסווג אחרת את המילה Apple במשפטים ״Apple release a new iPhone״ ו "He ate an apple״. למילה מסוימת, למשל "Apple״, יש משמעות קבועה.
  • מודל סטנדרטי אומר שניתן לעשות לטקסט embedding פעם אחת – ולהשתמש בו בכמה מודלים.
• מודלים קונטקסטואליים – במודלים האלו ה embedding הוא חלק מובנה במודל (ולכן לא יכול להיות סטנדרטי). המודל בוחן את הטקסט ולומד בצורה דינאמית את משמעות המילים ובונה להם וקטורים במרחב. פלטפורמה פופולארית למודלים קונטקסטואליים היא Hugging Face Transformers המספקת מודלים של Deep Learning (מסוג Transformers). יש מודלים למשימות שונות כגון ניתוח סנטימנט, תרגום, סיכום, OCR, וכו׳. המודלים הללו איטיים יותר, אבל מספקים תוצאות מדויקות יותר ממודלים קלאסיים. לרוב הם עובדים בייצוג של 500 עד 1000 מימדים.
  • במודלים קונטקסטואליים, ה־embedding הוא חלק אינטגרלי מהמודל עצמו, ולכן אינו סטנדרטי או ניתן להפרדה. המודל מנתח את הטקסט ולומד באופן דינמי את משמעות המילים בהתאם להקשר שלהן, ובונה עבורן ייצוגים וקטוריים במרחב רב־ממדי.
  • למשל, כאשר נעשה embedding לשני מסמכים, א׳ וב׳:
    • במסמך א': "Apple announced a new iPhone" המודל רואה את המילים "announced" ו-"iPhone". הוא מבין שההקשר הוא טכנולוגיה, ולכן הוא ממקם את "Apple" בנקודה על המפה שהיא:
      • גבוהה בציר "טכנולוגי" (ציר 17).
      • נמוכה בציר "אכיל" (ציר 250).
    • במסמך ב': "She ate an apple" המודל רואה את המילים "ate" ו-"an". הוא מבין שההקשר הוא אוכל, ולכן הוא ממקם את "apple" בנקודה אחרת לגמרי על אותה מפה:
      • נמוכה בציר "טכנולוגי" (ציר 17).
      • גבוהה בציר "אכיל" (ציר 250).
  • כלומר, שומרים על ״חוקי הפיסיקה״ של כל embedding: יחסי הקירבה עובדים לפי אותם כללים, מרחקים נמדדים בצורה זהה, ויש אותו מספר מימדים – אבל המיקום של אותן מילים במימדים – שונה.
  • עבור משימות מסוימות, כמו השוואת משעות של הטקסט – חיבור וקטורים יכול לעבוד (צירוף של רשימת הוקטורים של מסמך א׳ לוקטורים של מסמך ב׳). המילים המקוריות לא משנות – רק המשמעות שלהן.
  • עבור משימות אחרות, למשל סיכום טקסט או זיהוי סנטימנט – פתאום המילים מטשטשות משמעות. למילה ״Apple״ אין כבר משמעות יחידה. מכאן שחיבור embedding יגרום לפגיעה קשה בתוצאות.
    • הפתרון הפשוט הוא לחבר את המסמכים א׳+ב׳ – ולבצע embedding מחדש לאיחוד שלהם.
    • יש אלגוריתמים שמאחדים embedding שונים שנוצרו בהקשרים שונים – אך יש בהם פשרות.
• מודלים ענקיים (LLM) אלו מודלים מסוג Transformers אבל עצומים בגודלם (ולכן איטיים הרבה יותר – לרוב מריצים אותם על שרת מרוחק). הם קונטקסטואליים וכוללים גם ידע עולמי, ולא רק הקשר מקומי מתוך הטקסט. המודלים הללו הם general-purpose ולרוב יכולים להתמודד עם כל הבעיות (ברמת הצלחה כזו או אחרת), או לפחות לנסות.
  • למשל (דוגמה רגישה), ״ישראל״ במודל קונטסטואלי רגיל ≈ מדינה, מופיעה יחד עם מילים כמו “מזרח”, “תל־אביב”, “ממשלה”. “ישראל” תשב קרוב ל־“ירדן”, “לבנון”, “סוריה”, “ארה״ב” ו״אירופה״ – פשוט כי אלו מופיעים יחד הרבה בטקסטים שעליהם אומן.
  • מודל LLM יידע ש״ישראל״ יושבת במזרח התיכון (עובדה) ולא באמריקה. שיש בה קונפליקטים ביטחוניים מתמשכים, שהיא מזוהה עם טכנולוגיה, דמוקרטיה, דתות, צבא, ועוד. כלומר הוא ימפה את הידע הזה בתוך מימדים ב embedding (בשונה למשל מ״מונטנגרו״ – בעלות מאפיינים אחרים).
  • מודלי LLM לרוב משתמשים ביותר מימדים, לרוב 1500-4000 מימדים (בעת כתיבת הפוסט).

סיכום

אם לפני הפוסט הזה (חלק א׳+ב׳) לא היה לכם מושג מהו NLP (מלבד מושג כללי) ואיך משתמשים בו – הרי בסוף הפוסט אמור להיות לכם את ה״א״, וחצי ה״ב״.

ייתכן ומומחי NLP יכעסו על הפוסט – שלא פתחתי בהגדרות כמו תחביר, פונולוגיה, סמנטיקה, ופרגמטיקה. שאני בכלל לא מומחה NLP בעצמי. נו… שיכעסו 🤷.

בפוסט הכרנו הרבה מונחים חשובים ושימושיים (lemma, embedding ועוד) שיכולים ממש לעזור ולהתמצא במרחב הדיון כאשר מדברים על ניתוח טקסט. זה בסיס חיוני להמשך הדיון – ואני מתכוון לכתוב עוד, ולצלול יותר לדוגמאות מעשיות, המובילות לפיתוח יעיל של מערכות LLM.

שיהיה בהצלחה!

כאשר פיתחנו מערכות Web, היה חשוב להבין את ה HTTP protocol בכדי לעשות את העבודה שלנו בצורה מקצועית.

כאשר אנחנו מפתחים מערכות LLM, פרוטוקול שאנחנו עומדים לעסוק בו הרבה הוא ״טקסט של שפה אנושית״, אפילו בתסריטים של Machine to Machine. בפוסט הזה אני רוצה לדבר על כמה כלי NLP בסיסיים שעוזרים לעבוד עם טקסט, ועל השימושים שלהם במערכות LLM. בואו נתחיל להבין איפה הכלים האלו יכולים לשמש אותנו:

1. custom) RAG) – כדי להגיע לתוצאות מצוינות הרבה פעמים נצטרך לנהל את ה context retrieval בעצמנו ולתפור אותו ל use-case, לא סתם להשתמש ב RAG Framework מהמדף. לשלב טכניקות כגון vector similarity, hybrid search ו BM25.
2. Safety / Validation – כאשר אנחנו רוצים לבדוק את ה output של ה LLM שהוא סביר / לגיטימי / בגבולות שאנו מצפים ולא פוגע / לא-חוקי / מעבר לגבולות האחריות שלנו – אנחנו צריכים לאתר תבניות מסוימות בטקסט. איך עושים את זה? בעזרת כלי NLP כמובן. NER (קרי Named Entity Recognition – זיהוי אלמנטים כמו כתובת, שם עסק, עיסוק, וכו׳) למשל לאיתור PII או, Text Classification (סיווג טקסט לקטגוריה, למשל ״עצה ביטוחית״ או ״תוכן רעיל״).
3. Evaluation – כאשר אנחנו רוצים לאמוד כמה מוצלחות התשובות של ה LLM שהפעלנו. לזהות מגמות של רגרסיה כדי לטפל בהן. יש מדדי הערכה קלאסיים כגון F1 או ROUGE, טכניקות חדשות יותר כגון LLM-as-a-Judge ו Pairwise Comparison.
4. ניקוי נתונים בתהליך ה ingest ל Knowledge Base – נרצה לצמצם כפילויות סמנטיות, ולצמצם טקסט מיותר שלא שווה לאנדקס. כאן יש שימוש ב Canonicalization, Stemming, Lemmatization, Deduplication ועוד.
5. Intent extraction / routing – אנחנו רוצים לאבחן את סוג הבקשה (intent) של המשתמש (אנושי או מכונה) ולנתב אותו ל branch הנכון של ה LLM. נשתמש בכלים כגון SVM (Support Vector Machine) או LLM Chains.

ועוד ועוד. כמובן ש NLP הוא דומיין עשיר וותיק שלא אוכל לכסות בפוסט אחד (או עשרה). הכוונה לתת את קצה הקרחון השימושי בו מהנדסים יכולים להתחיל להשתמש מחר.

את רוב הפונקציות הנ״ל תוכלו למצוא בספריות כגון SpaCy או NLTK (קרי Natural Language Toolkit) לעיבוד טקסט + scikit-learn ל intent/safety ו evaluation בפייטון או Apache OpenNLP בעולמות הג׳אווה.
חשוב לציין שה ecosystem בעולם הפייטון מוביל על פני כל stack טכנולוגי אחר בעולמות הללו.

ניתן למצוא גם יכולות NLP חלק ממוצרים מוכרים המטפלים בטקסט, בעיקר Apache Lucene / Elasticsearch/OpenSearch אבל גם בסיסי נתונים כמו Postgres או אורקל (שממנו הושפע רבות) – בעזרת plugins כמו pg_bm25 או pgvector אבל גם SQLite (בסיס נתונים embedded – קטן ופשוט) עם כמה יכולות. במהלך הדרך התוודעתי לבסיס נתונים קטן ו embedded נוסף בשם DuckDB (הוא Columnar, vectorized, multi-threaded DB) המצוין לאבטיפוס בעולמות ה retrieval ומאפשר להריץ דירוג לשוני (BM25) ודירוג סמנטי (וקטורי) במנוע אחד.

Use case פשוט להתחלה

אנחנו רוצים לזהות במערכת שלנו לקוחות B2B שמנסים להרשם פעמיים. הם מספקים כתובת אימייל ושם העסק (Business Name). אם המייל + שם העסק זהים – נודיע להם שיש משתמש במערכת ונציע להם retrieval email (קרי ״forgot my password״).

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

• שגיאות כתיב. Dainel ולא Daniel
• אותיות גדולות/קטנות, רווחים, או סימני פיסוק A.C.M.E., Inc. מול ACME Inc.
• קיצורים שונים, למשל: Ezra&Sons International מול Ezra and sons Intl.

לשמחתנו, אנחנו מכירים גוגל/פרפלקסיטי ויכולנו למצוא בקלות ספרייה כגון RapidFuzz (פייטון) שעושה Fuzzy matching לטקסט. יש שם מגוון פונקציות, אבל הטובה ביותר (לפי GPT) היא WRatio. נשתמש בה!

> fuzz.WRatio("fuzzy wuzzy was a bear", "wuzzy fuzzy was a bear")
95.0
> fuzz.WRatio("ACME international", "ACME INTERNATIONAL")
34.54
>>> fuzz.WRatio("AIG", "AIF") # keyboard-adjastant typo
66.66
>>> fuzz.WRatio("AIG", "AI±") # keyboard-distant typo
66.66

כלומר, אני מבין ש Fuzzy Match מחזיר מספר בין 0 ל 100, ואני צריך לקבוע מעל איזו ציון אני מקבל תוצאה כחיובית – זה מובן, אבל הספריה המובילה הזו, שגם GPT וגם Claude המליצו לי עליה – לפעמים דיי מפגרת!

אולי שווה להשתמש בפונקציות אחרות ולא דווקא WRatio?
weighted ratio מריץ כמה ״אלגוריתמים״ שונים ונותן את התוצאה הגבוהה ביותר. לפעמים יש אלגוריתם ״אופטימי״ שיקפיץ תוצאות וייתן false positive, אז כן – כדאי להכיר מה הספרייה עושה.

אולי צריך להבין טיפה NLP גם כאשר משתמשים בספרייה ״מובילה״?
בהחלט. Fuzzy match הוא אלגוריתם שמכסה תחומים מסוימים – ולא מכסה אחרים. הוא יידע לזהות חילופי מילים, מילים בודדות שנוספו לטקסט, או שגיאות כתיב מסוימות (אות חסרה) – אבל יש אלמנטים שלמים של טקסט (אפילו בסיסיים כמו UPPERCASE vs. lowercase) שהוא לא בנוי להתמודד איתם.

בדומיין כמו שמות עסקים (לא אביא דוגמאות – אבל האמנו לי, בבקשה) – יש הרבה תצורות של שוני שמחוץ ל״רדאר״ של fuzzy match. אז מה עושים? Canonicalization.

כמפתחים, אנו רגילים לעשות normalization בטקסט, קרי יצירת ייצוג עקבי לצורת הטקסט כגון ״ CAFÉ״ ו "cafe״.
כעת נרצה קצת להתקדם ולבצע canonicalization שמשמעו ייצוג עקבי למשמעות הטקסט (בדומיין) כגון ״Acme LLC״ ו ״acme״ (למי שלא מכיר LLC ≈ ה ״בע׳מ״ של ארה״ב).

יישום canonicalization לצורך השוואת טקסט

נתחיל ב normalization:

import spacy
import unicodedata 

tokenizer = spacy.blank("en") # english-only

def normalize_text(text: str) -> str:
  
    text = text.lower() #lowercase

    # Unicode normalization
    text = unicodedata.normalize("NFKD", text) # **1** Unicode normalize (NFKD)
    text = "".join(character for character in text if unicodedata.combining(character) == 0) # **2** remove combining characters

    # Tokenize with spaCy **3**
    doc = tokenizer(text)

    # Strip punctuation/whitespace **4**
    tokens = []
    for token in doc:
      if token.is_punct or token.is_space:
        continue
      tokens.append(token.text)

    # Join back
    return " ".join(tokens)

1. זו נורמליזציה של Unicode כפי שהסברתי בפוסט על תוכנה רב-לשונית (תחת חיפוש ו Normalization). ייתכן והטקסט שמגיע אלינו, גם ממשתמשי קצה לא אחיד בצורה שלו. למשל:  מרכאות ניטראליות ( " ) מול מרכאות בעלות כיוון ( ” , ‟ ). או בגרמנית Fuβ שזו צורת כתיבה שקולה ל Fuss. נרמול NFKD הוא לרוב הנרמול המומלץ.
2. זה שלב נוסף של הסרת סימנים מסוימים, כמו accent (נפוץ בשפות אירופאיות).
   למשל café ל cafe.
3. כאן אנחנו משתמשים בספרייה בשם SpaCy (מקור השם: space – מרחב בין מילים/לשוני + Cy כי מומשה ב Cython גרסה מהירה של פייטון) לביצוע tokenization – חלוקת טקסט ליחידות בסיסיות הנקראות tokens — לרוב מילים, סימני פיסוק, מספרים וכו’. לדוגמא:
   "I love NLP." → [ "I", "love", "NLP", "." ]
4. אנחנו משתמשים ב tokenization על מנת לנקות whitespace (זה קל, אפשר גם ב Regex), וסימני פיסוק (נקודה, פסיק וכו׳).
   ״אבל ליאור, אפשר בקלות לעשות את זה ב Regex״ – זה דיי נכון, אבל לא מדויק. למשל, אנחנו רוצים להוריד גרשיים ׳ מסביב למילה, אבל לא בתוך המילה "don't״. או למשל לא לשבור את "U.S.A״ ל ["U","S","A"]. בעוד Regex ייפול במקרי הקצה אלו, SpaCy לא.
   כמובן שזה קצה הקרחון של היכולות של SpaCy – אבל זה הרגל טוב להשתמש בו – ואז ניתן להרחיב ולהשתמש ביכולות נוספות.

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

למשל, בשמות חברות בארה״ב נהוג (אבל לא חובה) להוסיף LLC או INC (המקביל ל״בע׳מ״ בישראל). נרצה להסיר את הביטויים האלו על מנת שאם נרשם השם פעם עם, ופעם בלי – עדיין נדע להשוות אותם. למשל:
["llc", "inc", "corp", "co", "pc", "lp", "llp"]

שימו לב ש llc מופיע בטקסט לרוב כ L.L.C – אבל מכיוון שכבר הסרנו סימני פסוק, אין צורך לבדוק את המקרים הללו.

השלב הבא הוא לנקות Stop Words. אלו מילים מאוד נפוצות, אך שלא מוסיפות משמעות לתוכן הטקסט (ולכן מקשות על השוואה יעילה). למשל: the, a, an, and, or, is, was, are, to, from, for, of

אנחנו יכולים להשתמש ברשימה מוכנה / גנרית כמו spacy.lang.en.stop_words.STOP_WORDS (המכילה 326 מילים) אבל בד״כ התוצאות טובות / נשלטות יותר אם ננהל את הרשימה בעצמנו. במקרה שלנו, בחנתי את הטקסט* ומצאתי ש and ו the הן המילים הנפוצות שארצה להגדיר ב STOP WORDS.

בנוסף, ארצה להחליף את הטקסט "&" ב " and ״ – כחלק מהתהליך. כמובן שחשוב לעשות זאת, לפני הסרת סימני הפיסוק. הכל מצפייה בטקסט*

* האמת, מאז שיש LLM – הוא עושה הרבה מהעבודה הזו. אני שולף מבסיס הנתונים כ 10K רשומות של שמות עסקים, לוקח מודל חזק (כיום: GPT5-thinking-high) ומבקש ממנו לעזור לי לנתח את הטקסט. מה ה stop words? מה ה designations הנפוצים? מה ה synonyms (נדבר עליהם מיד)? מה עוד פספסתי? כמובן שאני חושב ומבקר את מה שהוא אומר וגם בודק בעצמי – אבל הוא בהחלט מאוד עוזר. (למשל את קיצורי החברות lp ו pc הוא זיהה – ואני לא הייתי מודע אליהם).

השלב האחרון שנשתמש בו הוא Synonym expansion.
synonym הן מילים נרדפות, ושוב – הרשימה הרלוונטית היא לרוב מבוססת דומיין. הנה מונחים לדוגמא שזיהיתי:

synonyms:
  service:
    - services
    - solutions
  construction:
    - contruction # very common spelling mistake
    - constrcution # a common spelling mistake
    - builders
    - contractors
  consulting:
    - advisory
  cleaning:
    - janitorial
 ...

אני אעבור על הטקסט ואחליף כל ערך ברשימת המילים הנרדפות, למילה המובילה (למשל: services ל service). שימו לב ש:

1. יש מקרים בודדים של יחיד <=> רבים. לא טיפלתי בזה בצורה גורפת כי לא ראיתי שזה נפוץ בדוגמאות הטקסט. כמו כן, בסוף אשתמש ב RapidFuzz שהאלגוריתמים שלו מתמודדים טוב עם יחיד-רבים בשפה האנגלית.
2. הכנסתי שגיאות כתיב נפוצות במקרה של construction. הכנסה של שגיאות כתיב כ synonym הוא לא לגמרי סטנדרטי ונתון להחלטה ספציפית. במקרה שלי, הטקסט להשוואה מוקלד ע״י משתמש במובייל – קרקע פורייה לשגיאות כתיב נפוצות. הוספתי את האפשרות יותר כדוגמא, כי היעד הסופי של ה canonicalization במקרה הזה, RapidFuzz, ״אוכל״ היטב גם שגיאות כתיב מהסוג הזה.

בשלב הזה, סיימנו canonicalization איכותי לדומיין של שמות עסקים – ועכשיו אנחנו יכולים להפעיל את RapidFuzz בבטחה, ולקבל תוצאות איכותיות.

סיכום

גם בעולם בו יש את ה״קסם״ של LLM – עדיין יש מקום ל NLP ״קלאסי״.

אפשר לומר שדווקא ה־LLM החזיר (חלק מ) ה־NLP למרכז. בכל מקרה שבו המודל לא מצליח “במכה אחת” וללא עזרה (מה שנקרא ״zero-shot״), אנו נדרשים לעבד טקסט: לנקות, להבין, למיין, וכו׳ — בדיוק שם נכנס ה־NLP הקלאסי לתמונה.

בדוגמה, ראינו ש Fuzzy Matching לא תמיד עובד Out of the Box, ללא הכנת הטקסט. עשינו Canonicalization והכרנו כמה מושגים חשובים ושימושיים בעיבוד טקסט כמו Stop Words ו Synonyms Expansion. לא הזכרנו Lemmatization ו Embedding – מה שיחייב אותי לכתוב פוסט המשך 😅.

חשוב לציין שבעוד ש Normalization הוא דיי גנרי. Canonicalization לרוב מאוד מושפע מהדומיין – וחשוב להכיר את הטקסט שבו מטפלים.

שווה גם לציין שחלק מהשימושים בכלים שראינו הם ספציפיים Use Case. למשל Synonyms expansion הוא לא תמיד החלפה של רשימת מונחים בערך קאנוני. זה תלוי במקרה. למשל, עבור חיפוש טקסט, ייתכן ונרצה להרחיב ערך מהרשימה לכל ה synonyms המוגדרים. דוגמה: אם הופיעה ב query המילה ״service״ נרחיב את החיפוש לכל הערכים [״service״, ״services״, ״solutions״] כי כל אחד מהם רלוונטי פוטנציאלית לחיפוש שלנו.

שיהיה בהצלחה!

קל מאוד להכריז על מהפיכות בעולם, אבל בעת הזו אני מניח שיהיה לי קל לשכנע ש Agentic IDEs הם מהפכה של ממש בעולם התוכנה.
כשהגיע GitHub Co-Pilot (לפני ה coding agent) הייתה התרגשות כללית, אבל דיי מהר הבנו שזה עדיין ״לא זה״. אני ועוד רבים מעמיתי פשוט כיבינו אותו – שיפסיק ״להרעיש״.

בכמה השבועות האחרונות יצא לי ולעוד עמיתים ב NEXT לעבוד עם Cursor ו WindSurf – ומהר מאוד הבנתי שמדובר במשהו אחר, עליית מדרגה משמעותית מעל ל GitHub Co-Pilot:

• הוא יכול לערוך מספר קבצים במקביל.
• הוא מסוגל לעשות שינויים רוחביים, ולא רק Generation לפיסת קוד. למשל:
  • תיקון באג או בילד שנכשל – כשהבעיה נגרמת בכמה קבצים שונים בקוד.
  • הוא מסוגל לחפש ב code base, ולעזור להתמצא בו ולהסיק ממנו תובנות.
• הוא מסוגל לבצע פעולות ב command line ובעצם להפעיל קומפיילר, להתקין חבילות, להזיז קבצים בפרויקט וכו׳.
• והוא רק בחיתולים…

אני עובד בעיקר עם Cursor אבל יש מגוון כלים שמתרוצצים כרגע, שמציגים יכולות שלא ראינו בשנה שעברה: Loveable, CLline, V0, Base44, Claude Code, Jules – ועד שתקראו את הפוסט בוודאי יהיו עוד כמה משמעותיים.

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

חשבו איך שינו את עולם פיתוח-התוכנה האינטרנט (רפרנסים אונליין, StackOverflow), מהפכת האג׳ייל, או מהפכת הבדיקות / TDD. זה סדר הגודל המדובר (לפחות), רק שנראה שזה מתקדם מאוד מהר.

איך זה ייגמר?

שאלה מעניינת, וכמובן שאיני יודע.

• האם ארגונים יסגרו את ארגון הפיתוח, ואנשי מוצר יעבדו ישירות מול LLM בעוד המפתחים עומדים בתור לנסות ולקבל משרה במקדונלדס? – פחות סביר.
• האם תוכנות בעולם יתקדמו בקצב מסחרר ונראה פיצ׳רים חדשים משוחררים כל יום? סטארטאפים שמשיקים מוצר עם מפתח בודד? – כנראה שזה הכיוון, אבל בהגזמה גדולה.
• מפתחים יוכלו לעשות עבודה פי 10 יותר מהירה מהיום? – גם לא נראה לי.

אבל מספיק שמפתח יוכל לעשות עבודה 10% יותר מהר בממוצע מהיום – וזו כבר מהפיכה.

שפות תכנות או Frameworks חדשים, לא מצליחים לייצר כזו התקדמות בפריון. רק קפיצות המדרגה הגדולות יותר, כמו אג׳ייל או Testing – הצליחו להביא לכזו תוצאה, וזה היה תהליך של שנים עד שהוטמעו בהצלחה.

נזכיר, שכתיבת קוד היא כ 20% מהזמן של מפתחים בארגוני תוכנה בוגרים. דזיין, תקשורת, עבודה עם פרודקט – תופסים את רוב הזמן. שיפור של פי 2 בקצב כתיבת קוד = תוספת פריון ממוצע של 10% למהנדסי תוכנה, וכרגע זה לא נראה דמיוני.

בעוד ש Agentic IDEs מאיצים בצורה ניכרת את זמן כתיבת הקוד / troubleshooting, אין סיבה שכלי LLM אחרים לא יצליחו לעזור גם בשלבי הפיתוח האחרים, כמו תקשורת או עבודה עם פרודקט. אני משתמש תדיר ב ChatGPT (ולאחרונה Gemini) על משימות שוטפות – ואין סיבה שלא נראה גם כאן קפיצות מדרגה בשלב מסוים.

איך זה מתחיל?

מתקינים Agentic IDE טוב (בעת כתיבת הפוסט: Cursor נראה כמו מוביל המגמה) – ומתחילים לעבוד איתו.

להתרגל ל IDE חדש: לוקח יומיים.
לאשר לעבוד עם כלי חדש בארגון: בין שעה לחודשיים – תלוי בארגון 😅.
ההתחלה יכולה להיות דיי מהירה.

ללמוד לעבוד עם הכלי בצורה יעילה – לוקח קצת יותר זמן. הנה שלבי הלמידה כפי שאני צופה בהם:

שלב #1: להאמין ב Agent

יותר מדי פעמים, ראיתי אנשים שעובדים עם ה Agent ב Agentic IDE ונותנים לו פירורי עבודה: ״שנה את שם המשתנה״. ״הוסף פרמטר לפונקציה״. סוג של פקודת refactoring בטקסט חופשי.
זה עובד וזה נחמד, אבל כאן לא הפוטנציאל.
העזו ואתגרו את הסוכן (Agent) בדברים שלא נראה לכם שהוא יכול לעשות. ברוב הפעמים – הוא יפתיע אתכם לטובה. עד שלא תאמינו ב agent – לא תצליחו להפיק ממנו משהו שדומה לפוטנציאל.

• בסשן הראשון שלי עם הסוכן ביקשתי ממנו לעשות Refactoring ל class ולחלץ תת מחלקה החוצה.
• אח״כ ביקשתי שיקמפל את הפרויקט. הוא טעה – אבל עם טיפה הדרכה – הצליח.
• ביקשתי שיריץ בדיקות. הייתה בדיקה שנכשלה. ביקשתי שיתקן – והוא הצליח.
• אמרתי לו שיעשה commit לקוד, ויכתוב commit message מתאים – הצליח.
• העזתי, וביקשת שיפתח Pull Request בגיטאהב, וישים reviewer מסוים. הוא הסביר שהוא צריך להתקין כלי בשם GH כדי להפעיל את GitHub. התקין – ואז הצליח לפתוח PR. לא הצליח לשים reviewer.
• תיקנתי אותו בשם המשתמש של ה reviewer – והוא הצליח לשים (assign) אותו כראוי.
• אמרתי לו שיכתוב הודעה בסלאק ל reviewer שכבר יגיב ל PR!
  הוא ענה לי שאין לו גישה ל Slack – אבל כתב עבורי הודעה שאעשה לה paste.

שלב #2: לא לסמוך על ה Agent

ה Agnet (סוכן) רץ מהר ועושה שינויי קוד יפים והגיוניים. פה ושם הוא עושה שטויות, כאילו בכוונת מחבר, כדי לשמור עלינו engaged בקוד שנכתב. לפעמים אלו טעויות טיפשיות (חסר import), לפעמים כשלים לוגים גדולים (הוסיף שורת logout במקום שלא ציפיתי, ולא שמתי לב שהוסיף. התגלה רק בביקורת קוד עם מפתח אחר).

מקום שנפלתי בו, וראיתי אחרים נופלים בו בצורה דומה היא כתיבת בדיקות. עבדתי על מחלקה ללא בדיקות, ולכן הוריתי לסוכן לכתוב לה בדיקות. תוך חצי דקה היו 10-12 test cases כתובים למהדרין. עברתי על שניים-שלושה, נראו הגיוניים וכתובים יפה.

״נו, מה יכול להשתבש בבדיקות?! מקסימום הקפיד יותר מדי״ – אמרתי לעצמי. הכנסתי את הקוד רק בכדי לגלות אח״כ ש:

• הסוכן כתב שתי בדיקות לא נכונות עסקית, שעברו כרגע – אבל נפלו בשלב הבא של פיתוח הקוד, ועיכבו אותי זמן מה כי ״הבדיקה נופלת => משהו לא בסדר בקוד״.
• הסוכן כתב כמה בדיקות שהן overfit מוגזם למצב הקיים. לא בדיקות טובות.
  • גיליתי את זה כאשר הוריתי לו לתקן את הבדיקות שנפלו והוא הלך ושינה את הקוד המבצעי – כדי להעביר את הבדיקה. Big No-No!
  • הסבר: הבדיקה הייתה כתובה כל-כך Overfitted שנראה לרגע הגיוני לשנות את הקוד – ולא את הבדיקה.

בקיצור: הייתי צריך לסמוך פחות על הסוכן, ולבקר היטב את כל הקוד שכתב.

לוקח כמה רגעים להפנים, שהסוכן אולי כותב מהר, ורוב הקוד מוצלח, אבל הוא משאיר לנו ״easter eggs״ שאם לא ננפה אותן מוקדם – יגרמו לבזבוז זמן ואפילו לתקלות חמורות.

מכאן הכלל המומלץ לארגונים הוא: ״!You pushed it – you own it״. לא מומלץ לקבל שיח מסוג ״האא.. זה באג של הסוכן שלא שמתי לב אליו״ בתור הנחה מקלה. הניחו שהסוכן מייצר קצב קבוע פחות או יותר של באגים.

שלב 3א – להפנים ש ״context is king״

מיומנות חשובה המשפיעה על ביצועי הסוכן היא קביעת הקשר (context) נכון.

• להבין איך ה IDE שאתם עובדים איתו קובע את ה Context (התיעוד הזה חסר, השלמנו מפורומים ובניסוי /תעיה הבנה טובה יותר איך בדיוק הוא עובד)
• להבין אילו קבצים חשוב להוסיף לו כדי שתהיה לסוכן תמונה מספיק שלמה על המשימה.
• להבין איזה טקסט מינימלי / הנחיות חשוב להוסיף מעבר לקוד – כדי שיצליח במשימה. זכרו שהקוד לא מתאר כוונה לשינוי – אלא רק מצב קיים.
  • טריק: לפני עבודה עם הסוכן הוסיפו הערות בקוד מה בכוונתכם לשנות והיכן. Cursor מגיב להערות הללו היטב.
• להבין שככל שה context גדול יותר – המיקוד על כל אלמנט ב context הוא קטן יותר. זה לא עוזר להעמיס מודל ב 2 מליון טוקנים – אם בסוף הוא יעשה עבודה פחות טובה.

שלב 3ב: להפנים שמודלים הם שונים

ב Cursor IDE, כברירת מחדל בחירת מודל ה LLM שעובדים איתו היא אוטומטית, ואין נראות לאיזה מודל נבחר. זה לא טוב.

• לא פעם, מודלים פשוטים יותר, לא מצליחים טוב במשימות. למשל, GPT-4.1 (ש Windsurf אוהב לבחור) פשוט לא טוב במשימות רוחביות. הוא טוב בעיקר לשינויים נקודתיים.
  ההבדל בין sonnet-3.5 ל sonnet-3.7 הוא משמעותי. קצת יותר ממה ש״פער של 0.2״ נשמע…
• יש מודלים יותר ״מִתְחַכְּמִים״, כמו o3 או sonnet-3.7 שיותר סביר ש״יגדילו ראש״ במקומות שלא ציפיתם להם. אני מאוד אוהב את sonnet-3.7 והוספתי לו rule ממוקד בכדי ״לרסן״ אותו.

- When responding to user queries, strictly follow the instructions provided without making unsolicited improvements to code structure or functionality. Only implement changes or suggestions explicitly requested by the user.

• Gemini-2.5-pro עושה פחות שטויות, אבל הוא קשקשן (verbose) ואם אתם עובדים איתו אתם הולכים לקרוא הרבה טקסט שהוא כותב…
• צורת האינטראקציה עם כל מודל שונה ב IDE. חלק יותר יוזמים פעולה, חלק בעיקר ממליצים. Cursor IDE מציג UI elements שונים כתגובה למודלים שונים (למשל: כפתורים עם אפשרויות – כיצד להנחות את המודל לגבי הצעד הבא)
• צצים מדריכים כיצד לבחור מודלים. הנה המאמר של Cursor על בחירת מודלים. התחברתי יותר לכוונה, ופחות לתוצאה. אני מניח שקשה להעביר את המיומנות / חוויה של עבודה עם מודלים שונים.
• אם אתם עובדים עם כמה IDEs שונים, חשוב לציין שכל IDE מוסיף system prompts ייחודים שלו למודל ה LLM. המשמעות היא ש Sonnet-3.7 על Windsurf מתנהג שונה מ Sonnet-3.7 על Cursor.
• יש עניין של עלויות שימוש במודלים שונים. כשאתם מדברים / מפעילים את הסוכן, יורד לכם credit או שאתם משלמים ל LLM API בהתאם. מתישהו תגלו שיצא יקר או שחסמו לכם קריאות מהירות למודל. הגישה שלי היא לבחור בשני מודלים שנוח לי איתם: אחד ״יקר״ (נניח sonnet-4.0-thinking) ואחד זול או חינמי (נניח gemini-2.5-flash) ולעבור בין שניהם: למשימות פשוטות להפעיל את המודל הזול, ולמשימות מורכבות להשתמש במודל היקר.

שלב 3ג: ללמוד מתי לא להשתמש ב Agent

כשמתחילים לעבוד עם Agentic IDE מומלץ מאוד לעשות הכל בעזרת ה Agent chat (ראה שלב #1): פעולות rename, לעשות commit, להריץ בדיקות – הכל. להתרגל שה IDE הפך להיות ממשק דומה ל Google Search שבו יש תיבת קלט אחת: chat עם הסוכן.

יותר מאוחר, אתם תראו שיש פעולות שאתם עושים מהר יותר או בצורה אמינה יותר – ולכן חבל להפעיל סוכן. הנה רשימה של דברים קטנים שאני מעדיף לעשות ללא-סוכן:

• Refactoring ב IDE – אמין יותר מהתוצאה של סוכן, שלפעמים מפספס מופעים.
• פעולות גיט – נוח לי להקליד פקודת gcam (קרי: git commit+message) לטרמינל מאשר לכתוב לסוכן ״commit the changes and write a proper commit message״. היו פעמים שהסוכן בחר לעשות commit והודעה לכל קובץ פתוח בנפרד – ממש מרגיז. לא פעם הייתי צריך לדייק אותו על ההודעה.
• קומפילציה / הרצת בדיקות – פחות לחיצות על המקלדת דרך ה IDE, אם הסוכן יכול לגשת אח״כ בקלות לתוצאות (תלוי ב IDE).
• נ.ב. Cursor הוא fork של VSCode ולכן התמיכה שלו בקוטלין / ג׳אווה דיי עלובה
  (בצד ה IDE). אני עובד כרגע side by side עם Cursor לעבודה עם הסוכן, ו IntelliJ כדי לבדוק מה הוא עשה. זו לא תצורה נוחה – אבל היא עדיפה על כמה אלטרנטיבות אחרות.

שלב #4 – ללמוד לדבר אל הסוכן בשפתו

זה שלב טריקי, שלוקח משמעותית יותר זמן מהשלבים הקודמים.

יש בבירור אנשים שמצליחים להוציא מהסוכן יותר מאנשים אחרים: יותר מהר, פשוט, פחות תקלות. לא מצאתי שום תיעוד לדבר הזה, אבל עשיתי לא מעט pair programming עם אנשים שונים+סוכן – וראיתי שזה עובד אחרת.

ראיתי בגדול שתי גישות שעובדות טוב:

• להסביר במדויק, מה שנקרא Technical communication טוב, להשתמש במונחים הנכונים, בסדר הנכון, להסביר תמונה רחבה ופרטים קטנים. זו מיומנות שיש לאנשים מסוימים יותר מאנשים אחרים.
  • הסברים לא מדויקים, במינוח לא טוב יגרמו לזה שתחשבו שהטכנולוגיה של Agentic IDE ״לא בשלה עדיין״
• לעבוד עם דוגמאות טובות, סוכנים הם מעתיקנים מצויינים. בהרבה מקרים, או כי הנושא סבוך וקשה להסבר, או כי הדובר פחות רהוט / מדויק – דווקא להשתמש בדוגמאות היא דרך פעולה מוצלחת. צרפו קבצים דומים / מימושים דומים ל context ובקשו מהסוכן לכתוב קוד כמו הקובץ או inspired by – והתוצאות יכולות להיות טובות מאוד, ממש תחליף להסבר תמציתי ומדויק.

בניתי לעצמי סדר תקשורת שעובד לי עם סוכנים:

1. Smalltalk – אם המשימה מורכבת (קשה לי להסביר, אני בעצמי לא בטוח מה אני רוצה, מנגנון עסקי מורכב) אני מתחיל בשיחה קלילה עם הסוכן:
   • ״מצא באיזה קובץ עושים X״
   • תאר לי את ה flow?
   • ״למה עושים א ולא ב״, או ״הסבר לי את הפונקציה״
   • חשוב להשתמש בשלב הזה לדייק את הסוכן מתי שהוא טועה. יש איזו דינמיקה שהתקשורת עם סוכן היא או ״משדרים על אותו גל״ או ״התדרדרות מהירה״. כשהסוכן בונה תמונת עולם שגויה ומתחיל להתחפר בה – קשה להוציא אותו מזה. אני מעדיף להתחיל context חדש ולהתחיל מאפס, מאשר לנסות ״לחלץ״ סוכן שנתקע. זה יותר יעיל.
   • אחת מההנאות שלי מה Agentic IDE הוא לשוחח עם הסוכן על קוד קיים. הוא סורק קוד מהר, ולא פעם מגלה תובנות מעניינות. בונוס ענק על פני כלים כמו GitHub Co-Pilot שלא התקרבו לזה.
2. עבודה הדרגתית בשלבים – כשהמשימה מורכבת, חשוב ללכת עם הסוכן צעד צעד. להנחות אותו. אתם ה supervisor והוא המתלמד. יש לכם מתלמד חרוץ מאוד וידען מאוד (הרבה פעמים – יותר מכם), אבל עם זיכרון של דג ליצן (הוא לא זוכר מה קרה היום בבוקר) ואפס היכרות עם הארגון ובסיס הקוד.
   • עם הזמן תפתחו יותר אינטואיציה מהו גודל הצעד הנכון: לא קטן מדי, ולא גדול מדי.
   • אם הסוכן מסתבך – נסו להחזיר אותו למסלול. Git Revert + new context/chat – היא לפעמים הדרך הקצרה להמשיך להתקדם.
3. הפעילו ביקורות – לא רק שלכם, אלא גם של כלים והסוכן עצמו
   • ״check yourself״ – prompt סתמי כזה לא פעם מצא לי באגים.
   • ״compile and test״ – רוב המודלים יתחילו לתקן ברגע שתתגלה שגיאה. חלקם לא.
   • ״simplify the code״ – המודל יכול לשפר מאוד את הקוד, אבל לא יעשה את זה – עד שלא תנחו אותו.
   • ביקורות מתוחכמות יותר כמו מודל ששינה SQL ושהתבקש ״וודא שמספר הרשומות והעמודות נשאר זהה לאחר השינוי״ ענה ב״אוי, סליחה! בעצם יהיו יותר פחות רשומות כי הוספתי <פילטר מטופש שלא ביקשת בכלל>״.

יש טענה / אמונה שנצליח ״לאלף״ את הסוכן לעבוד בשפתנו. כרגע הרושם שלי, כפי שתראו גם באייטם הבא, הוא שיותר מעשי הוא לאמץ במידה רבה את שפת הסוכן.

שלב #5 – לקבל סגנון אחר
כבר הזכרתי שלסוכנים / מדלי LLM יש זיכרון מוגבל? הקוד שהסוכנים עומדים לכתוב יהיה שונה מהסגנון שאתם כותבים בעצמכם.

יותר מעצבן: החלפה של מודל באמצע העבודה, תשנה את הסגנון. קרה לי לא פעם שהחלפתי מודל באמצע העבודה, והמודל החדש החליף הרבה קוד שנכתב ע״י המודל הקודם – לקוד שקול אך בסגנון אחר.

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

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

1. זה גוזל זמן. הרבה.
2. להגיע ל 100% סגנון רצוי עשויה להיות השקעת עבודה גדולה פי 2-3 מלהגיע ל 80% סגנון רצוי.

כמה זה משנה? כמה תשקיעו כדי לדייק את הסגנון?

אני מאמין שחלק מהעניין של לעבור לעבוד עם סוכן, הוא להתגמש ב code style כל עוד הוא ברור וטוב. זו לא התפשרות על איכות – אלא התפשרות על טעמים אישיים.

לא פעם, נתקלתי בסגנון זר של קוד. ביקשתי מהמודל להסביר את ההגיון – ובעצם הבנתי שכרגע למדתי משהו חדש ו/או נחשפתי לסגנון מוצלח יותר ממה שהכרתי.

השיח עם הסוכן, הוא לפעמים הזדמנות ללמידה. מִכָּל־תַּלְמִידַי הִשְׂכַּלְתִּי (השינוי מכוון).

אתם בוודאי יודעים של Agentic IDEs מאפשרים לכתוב AI Rules הנוספים ל context ומנחים את הסוכן כיצד לעבוד. מאוד שימושי ללמד אותו דברים בעזרת ה rules ולחסוך זמן, מדוע לא ״להעביר אותו בית מדרש – וללמד אותו לכתוב בקונבנציות המדויקות של הצוות״?

• ה rules הם לא מדע מדויק. גם rules שהעברתי כמה איטרציות של שיפור דיוק (גם בעזרת LLM) – לא תמיד השיגו את התוצאה הרצויה. נראה ש rules טובים משיגים תוצאה רק 90% מהפעמים.
• ככל שתתנו לסוכן יותר rules – יהיה פחות משקל לכל rule. אני מאמין בלתת לסוכן לא יותר מ 10-20 חוקים חשובים – ובשאר לקבל את הסגנון השונה שלו. זו נראית לי כרגע הגישה הפרגמטית.
• שינויים במודל ו/או system prompts מתרחשים כל הזמן, ומשפיעים על דיוק הביצוע של ה rules. כמה עבודה אתם מסכימים להשקיע בכדי לתחזק את ה rules עובדים לכל המודלים, ולאורך זמן?

לא דמיוני בעיני להחליף ספריות, סגנון קוד, או אולי אפילו שפת תכנות בארגון (בקוד חדש) – לכזה שעובד טוב יותר עם מודלי ה LLM העדכניים. זה אומר לא-פעם להיות יותר סטנדרטיים לתעשייה. היתרונות בעבודה חלקה עם Agentic IDEs יכולה להצדיק לא שינויים הנובעים מה״היסטוריה״ של הארגון.

שלב #6 – להפנים שלסוכן אין רגשות, אבל למפתחים יש

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

• יש הבדל גדול בין לקרוא בעיתון על מישהו רחוק ואחר, מאשר להרגיש חוסר-ודאות לעתיד על בשרנו.
  • בתגובה לכתבה על עובדים שפוטרו או הוזזו מתפקידם בעקבות תוכנת אוטומציה חדשה אנחנו יכולים להגיב: ״זו הקדמה, אין מה לעשות״ או ״שיחשבו הלאה וימצאו מקצוע אחר״
  • כשהעתיד שלנו פתאום לא ברור – זה נראה אחרת. זה אנושי והגיוני למדי.
• במשך שנים התרגלנו לסגנון קוד מסוים, לדרך כתיבה מסוימת, להקפדה על הפרטים והערכה רבה להקפדה על הפרטים. לומר ביום אחד ״טוב, סגנון קוד לא כזה משנה״ – זה סוג של זעזוע. איך? למה? מתי זה קרה?! ״האם אין לנו יותר ערכים״?
• ״תחשוב שקיבלת לחנוך בוגר אוניברסיטה מבריק וחרוץ. אתה לא אמור לכתוב כמעט קוד, אתה אמור בעיקר להנחות אותו״ – הסברתי למישהו את הרעיון של עבודה עם Agentic IDE.
  • ״אבל אני לא רוצה לחנוך בוגר אוניברסיטה. אני אוהב לכתוב את הקוד בעצמי. אני טוב בזה ונהנה מזה. אם הייתי רוצה לחלק הנחיות – הייתי הולך לנהל״.
• ״מה יוצא לי מזה?״ – ישאל במודע או לא במודע המפתח. לדלוור 10% יותר פ׳יצרים זה נחמד – אבל זה לא באמת מה שיוצר מוטיבציה אצל מפתחים. יותר מעניין לכתוב קוד טוב יותר, איכותי ונקי. לעשות עבודה מקצועית להתגאות בה.
  • האם שימוש ב Agentic IDE עומד לשפר את הערכים המקצועיים של המפתחים? או אולי בעצם הוא יאלץ את המפתח לשנות סגנון התנהלות – ולעשות לפעמים פחות ממה שהוא אוהב, וטוב בו?
  • האם, למשל, ארגון יקצה חלק משיפור התפוקה שהושגה בעזרת Agentic IDE כדי להקדיש יותר זמן לשיפור איכות קוד? או שכל השיפור ״ישרת״ רק את הגדלת הרווחים?

זוכרים את ימי אימוץ האג׳ייל, כאשר הסברנו (או מישהו אחר הסביר) לראשי צוותים שהם הופכים ל Scrum Masters – וזה רק לטובה? אלו לא היו ימים פשוטים. אני זוכר הרבה ראשי צוותים מודאגים, ובדיעבד – היה הרבה בדאגה שלהם.

אני מאמין שאנחנו פה בשינוי דומה, רגשי, של ערכים וקדימויות. שינוי שאינו קל לאנשים – וארגון חכם יכיל את הקשיים ויעזור לאנשים להתמודד איתם, ולא יצא בהצהרות כמו ״עברו לעבוד ל Agentic IDE – או לכו הביתה״.

שלב #7 – להפנים שכולנו עדיין Juniors בעולם הזה

השינוי עוד בחיתוליו.

בני אדם נוטים להעריך יתר שינוי בטווח הקצר – ולהעריך הערכת חסר שינויים בטווח הארוך.

בצמוד לדוגמאות המרשימות של Agentic IDE שמקצר המון עבודה, יהיו גם הדוגמאות שבהן הוא כושל ומפשל. בהן המוצרים (טכנית) לא בוגרים מספיק ומלאים בבאגים ובחוסרים.

לעבוד עם Agentic IDE זו אינה חווית פרמיום בימים אלו – זו חלוציות. אבל כל הסימנים מעידים שהחוויה תשתפר, ובקצב דיי גבוה.

אני מאמין שעבודה עם ה Agentic IDE תהפוך מהר מאוד להיות ה Premium Skill הכי חשוב והכי משמעותי בתעשיית פיתוח-התוכנה בזמן הקרוב. אני ממליץ להתחיל ולרכוש את ה skill הזה – כבר עכשיו.

לא הייתי נקשר יותר מדי ל IDE מסוים, למודל מסוים, או אפילו ל Flow עבודה מסוים – כי פרטים רבים עשויים עוד להשתנות. לחוש ולתמרן בתוך השינוי.

ה Juniors הכי גדולים עומדים להיות המנהלים. אלו שהיו פעם אנשי המקצוע החדים ביותר – כרגע צוברים הכי מעט שעות עם ה Agentic IDE. נראה שכרגע רוב המנהלים ניזונים בעיקר מסרטוני תדמית וסיפור הצלחה – וזה גורם לשטחיות בהבנה. אני ממליץ בחום לכל המנהלים להקצות את הזמן, להפשיל שרוולים, ולעבוד עם Agentic IDE בעבודה משמעותית. זה לא עוד שינוי של מה-בכך.

• יש הבדל מאוד גדול בחוויה בעבודה עם Agentic IDE למשך יום או למשך שבועיים. הסוכן מייצר גם תסכולים, ואי-הצלחות. קל לראות את ה case-studies הטובים – ולפספס את התמונה הגדולה והמורכבת יותר.
• מנהל שיפנה לעובדים שלו ויצהיר ״אני מצפה מהיום, מכל אחד מכם, לשיפור תפוקה של 50% לפחות״ – הוא בור. תצאו מנהלים טובים יותר אם תבינו על מה אתם מדברים, לפני שאתם דורשים מהעובדים. אלו כלים יש לכם לעזור לעובדים שמתקשים להסתגל למגמה החדשה, טכנית או רגשית – מלבד לשלוח אותם לעמיתים או להפעיל לחץ? אני מאמין ששווה שיהיה לכם סט כלים מעט יותר גדול מזה. בעת שינויים עמוקים דרושה מנהיגות שמבינה את ההתרחשות באמת.

סיכום

כרגיל, אני יכול להמשיך ולהאריך בדברים – אבל הגיע הזמן לסכם.

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

עולות גם הרבה שאלות פתוחות:

• מה קורה עם מפתחים חדשים? האם צריך ״למנוע״ מהם עבודה עם Agentic IDE כדי שיוכלו לפתח מיומנויות בסיסיות (אינסטינקטים, troubleshooting)?
  • ליאור: אני מאמין שלא. אני מאמין שאפשר תוך כדי עבודה עם סוכן ללמוד המון. אולי יותר מבעבר, אם כי בדרך קצת אחרת.
• האם איכות הקוד עומדת לרדת? האם הקוד נכתב מהר יותר עכשיו – אבל עוד שנה המערכת תהיה סבוכה יותר וקשה יותר לעבודה – כך שבסוף הכנסת Agentic IDE תפגע בסה״כ הפריון?
  • ליאור: אני בטוח שזו אפשרות. אני חושב שזה בעיקר עניין של תרבות ארגונית והקפדה על ערכים של הנדסת תוכנה. הצלחתי לעשות בעזרת סוכן כל מיני שיפורי קוד שלא הייתי מספיק לעשות (מבחינת לו״ז) – בלעדיו. הצלחתי – כי היה לי חשוב לשפר את הקוד.
• האם המפתחים המוצלחים של היום, יהיו גם המפתחים המוצלחים של מחר, או האם יש פה שינוי של המיומנות החשובות – ובעצם קבוצת אנשים ״תרד במעמד״ וקבוצה אחרת ״תעלה״?
  • ליאור: לא יודע. אשמח לענות עוד שנתיים-שלוש, ולטעון בדיעבד שתמיד ידעתי את התשובה.

אם אתם קוראים את הפוסט הזה ב 2026, והארגון שאתם עובדים בו סגור בפני אימוץ של Agentic IDEs – אני חושב שזה זמן ללחוץ יותר חזק על הארגון להיפתח, או לשקול לגוון ארגון. אני מאמין שקורה פה אירוע בלתי-חוזר. משהו משתנה בעולם פיתוח התוכנה – לתמיד.

שיהיה בהצלחה!