רווחים:
- יכולת לקחת SQL וקוד פנדה חזקים ולקרוא ולאמת אותו שורה אחר שורה על ידי מתן סכימה ומטרה ברורה לבינה מלאכותית
- יכולת לתפוס שגיאות שקטות כגון ספירת שורות, פונקציית התאמה ותפוקה לאחר מיזוג/הצטרפות
- יכולת לפתור את הבעיה ב-debug מבלי להשתיק אותה ולהימנע מהפעלת הקוד מבלי לבדוק אותו בסביבת הייצור
למדעי הנתונים יש שתי שפות עיקריות: SQL (שפת שאילתות מובנית - השפה לשאילתת נתונים מבסיסי נתונים) ו-Python (באופן ספציפי, ספריית הפנדות - הכלי הסטנדרטי לתפעול טבלאות באופן פרוגרמטי). ביחידה זו, נלמד להשתמש בבינה מלאכותית כשותף לקוד: לקבל ממנו SQL וקוד פנדה מוצק עם השאלות הנכונות, לקרוא ולאמת את הקוד הזה, לנפות אותו באגים ולעולם לא להריץ אותו בצורה עיוורת. AI כותב קוד חוזר בשניות במקום דקות; אבל זה התפקיד שלך לוודא שהקוד שהוא מייצר מעבד את העמודה הנכונה עם ההיגיון הנכון. קוד עבודה אינו אומר קוד נכון.
מדוע הפקת קוד עם AI היא חזקה אך מסוכנת
בינה מלאכותית מספקת שלושה יתרונות גדולים ביצירת קוד: מהירות (כותבת פעולה של 30 שורות קבוצה אחר ציר בשניות), תזכורת (מזכירה לך פונקציית פנדה ששכחת), והוראה (מסביר את הקוד שורה אחר שורה). אבל הוא טומן בחובו שלושה סיכונים: שגיאת לוגיקה שקטה (קוד שמסכם את העמודה הלא נכונה פועל ללא שגיאות), פונקציה מותאמת (מציע שיטה שלא קיימת), ומלכודת תשואה (קוד שעובד על נתונים קטנים אבל קורס ב-10 מיליון שורות). אז כלל הזהב: קרא את הקוד של ה-AI כאילו כתבת אותו בעצמך. אל תפעיל את הקו שאתה לא מבין.
SQL: עיבוד נתונים במקור
SQL מאפשר לך לאחזר נתונים ממסד הנתונים ולעבד אותם שם; אתה יכול לסכם מיליוני שורות מבלי למשוך אותם לפייתון. אבני בניין בסיסיות: SELECT (אילו עמודות), WHERE (אילו שורות), GROUP BY (לקבץ ולסכם), JOIN (צירוף טבלאות), HAVING (מסנן לאחר קבוצה). בינה מלאכותית עוזרת מאוד בכתיבת JOIN ופונקציות חלונות מורכבות, אך הקפידו לבדוק שני דברים: האם ה-JOIN באמצעות המפתח הנכון (המפתח השגוי משכפל שורות) והאם לוגיקה של המסנן נכונה (במיוחד התנהגות NULL וטווחי תאריכים).
זהירות: אל תריצו שאילתת SQL שנוצרת בינה מלאכותית ישירות מול מסד הנתונים הייצור. בדוק תחילה עם עותק קטן או LIMIT. לעולם אל תפעיל שאילתת UPDATE/DELETE מבלי לאמת את תנאי WHERE; שגוי WHERE יכול למחוק את כל הטבלה.
Python/Pandas: ניתוח גמיש
pandas היא הדרך הסטנדרטית לתפעל טבלאות (DataFrame) ב-Python. השימוש היעיל ביותר ב-AI הוא לתת לו תכנית ומטרה ברורה. הפעולות הנפוצות ביותר: סינון, groupby, merge, pivot_table, החל. AI כותב את אלה במהירות; מה שאתה רוצה לבדוק זה ההיגיון: האם הקיבוץ בעמודה הנכונה, האם המיזוג שינה את מספר השורות באופן בלתי צפוי (בדוק תמיד את מספר השורות לאחר המיזוג), האם פעולות השרשרת משנות את המקור.
עסקה
SQL
פנדות
מחסום
סינון
איפה
df[df.x > 5]
התנהגות NULL/NaN
קיבוץ
GROUP BY
df.groupby()
האם זה העמודה הימנית?
מיזוג
הצטרף
df.merge()
שינוי ספירת שורות
סיכום
AVG(), SUM()
.mean(), .sum()
איזה טור נאסף
מיין לפי
הזמנה לפי
.sort_values()
כיוון (עלייה/יורד)
מניעת כפילות
נבדל
.drop_duplicates()
באילו טורים?
איתור באגים: עם AI
כאשר הקוד נכשל, AI הוא שותף מעולה לניפוי באגים. תן לו את הודעת השגיאה המלאה ואת קטע הקוד הרלוונטי. אבל היזהרו משתי מלכודות. ראשית, ה-AI עשוי להציע פתרון ש"משתיק" את השגיאה (למשל, הסתרת התראות) - זה לא מתקן את השגיאה, אלא מסתיר אותה. שנית, AI לפעמים משנה בשקט התנהגות אחרת תוך כדי "פתרון" של בעיה. כלל: הבן את התיקון, פתרון לא השתקה, וודא שהפלט עדיין תקין לאחר התיקון.
רוצה קוד בר-פירוש וניתן לתחזוקה
כאשר קונים קוד מ-AI, בקשו קוד קריא וניתן לתחזוקה, לא רק קוד ש"עובד". כאשר אתה או עמית פותח את הקוד חודשים לאחר מכן, הוא אמור להיות מסוגל להבין מה הוא עושה. כדי לעשות זאת, עשו לכם הרגל שה-AI יכלול שלושה דברים: שמות משתנים משמעותיים (orders_temiz, לא df2), שורות הערה קצרות בשלבים קריטיים (המסבירים מדוע, לא מה נעשה), וקבוע בשם במקום מספר קסם (ACCEPT_ESIGI = 0.85 במקום 0.85 קבור בקוד). הימנעו גם משרשרות ארוכות של קו בודד (חיבור חמש פעולות בקו אחד); אלה מקשים על ניפוי באגים. כברירת מחדל, בינה מלאכותית מייצרת לעתים קרובות קוד תמציתי ו"חכם"; אם אתה אומר בבירור "כתוב קריא, ניתן לפירוש, ניתן לתחזוקה", תקבל פלט הרבה יותר שניתן לתחזוקה. זה גם הבסיס לשחזור (יחידה 10): קוד שלא מובן הוא קוד שלא ניתן להפעיל מחדש בבטחה.
שלושה מיני תיקים
מקרה 1 - שכפול JOIN. אנליסט שילב את ההזמנות עם טבלת המוצרים ומצא שהמחזור הכולל גבוה פי 3. סיבה: לכל מוצר היו מספר שורות (צבעים שונים) בטבלת המוצרים; JOIN שכפל כל הזמנה. הקוד של ה-AI "עבד", אבל מספר השורות קפץ מ-240 אלף ל-690 אלף. שיעור: בדוק תמיד את מספר השורות לאחר המיזוג/הצטרפות.
מקרה 2 - פונקציית התאמה. הוא הציע AI df.groupby('x').summarize() למתמחה; אין שיטה כזו בפנדות (יש .agg()). הקוד לא עבד, המתמחה אבד ל-20 דקות. שיעור: אמת פונקציה שאינך מזהה מהמסמך; AI יכול להמציא שיטות.
מקרה 3 - קריסת תשואה. קוד אחד ערך שאילתה למסד הנתונים ביישום עבור כל שורה; הוא רץ על 5,000 קווים, לקח 9 שעות על 4 מיליון קווים, והפסיק. כאשר AI הציע פתרון וקטורי (אצווה), הזמן הצטמצם ל-40 שניות. לקח: קוד שעובד על נתונים קטנים עלול לקרוס על נתונים גדולים; קחו בחשבון יעילות.
ארבע תבניות הניתנות להעתקה
1) בקשת SQL עם סכימה:
תפקידך: עוזר SQL (PostgreSQL). טבלאות:- orders(id, customer_id, תאריך זמן, כמות מספרית)- customers(id, city text)משימה: קבל את המחזור הכולל ומספר ההזמנות לעיר בשנת 2024, ממוינים לפי מחזור בסדר יורד. הסבר כיצד אתה מטפל בערים NULL. אני אבדוק תחילה את השאילתה עם LIMIT; דור עדכון/מחק.
2) תהליך פנדות עם מחסום:
יש לי DataFrames df (הזמנות) ו-df_customers (לקוחות). חשב כמות ממוצעת לעיר. חשוב: הדפס את מספר השורות לפני ואחרי המיזוג כדי שאוכל לראות אם יש כפילות. הסבר באיזו עמודה מיזגת ומדוע בחרת פנימי/שמאלי.
3) הסבר ואימות קוד:
הסבירו את הקוד של הפנדות הבאות שורה אחר שורה: מה כל שורה עושה, אילו הנחות היא מניחה, באילו מקרים היא עלולה לתת תוצאות שגויות? תודיע לי אם השתמשתי בפונקציית פאדג'. קוד: [הדבק]
4) איתור באגים:
קוד זה נותן שגיאה זו. הודעת שגיאה מלאה: [הדבק]. קוד: [הדבק]. הסבר את סיבת ה-ROOT לשגיאה ותקן אותה. תקן זאת על ידי פתרון הבעיה בפועל, לא על ידי השתקת ההתראה. ציינו גם אם התיקון שינה את הפלט.
הנחיה חלשה / הנחיה חזקה
הנחיה חלשה:
כתוב שאילתה שנותנת לי מכירות לכל עיר.
שמות טבלאות, עמודות, סוג מסד נתונים, התנהגות NULL אינם ברורים. ה-AI נפוץ, הוא כנראה יפיק שאילתה שלא מתאימה לטבלה שלך.
הנחיה עוצמתית:
תפקידך: עוזר SQL (MySQL 8). טבלה: מכירות (מזהה, עיר varchar, סכום עשרוני, תאריך תאריך). משימה: קבל את הסכום הכולל והממוצע, מספר ההזמנות לעיר לשנת 2024; מיון יורד לפי כמות כוללת; הצג רק ערים עם יותר מ-100 הזמנות (HAVING). NULL אל תכלול עיר. הסבר את השאילתה; אני אבדוק עם LIMIT.
כאן מסד נתונים, סכימה, מסנן, מיון וכלל NULL ברורים.
טעויות נפוצות
- הפעלת הקוד מבלי לקרוא אותו. קוד עבודה אינו קוד נכון; הקוד שמתמרן את העמודה הלא נכונה פועל גם ללא שגיאות.
- לא בודק את מספר השורות לאחר המיזוג/הצטרפות. המפתח השגוי משכפל בשקט שורות ומנפח סכומים.
- לא מאמת את פונקציית ההתאמה. AI עשוי להציע שיטות שאינן קיימות; אשר מהמסמך שאינך מזהה אותו.
- לא חושב על יעילות. החל/לופ עבודה על קריסות נתונים קטנות במיליוני שורות; וקטוריזה.
- הפעל ישירות על מסד הנתונים הייצור. במיוחד הפעלת UPDATE/DELETE ללא WHERE או בדיקה היא הרת אסון.
טיפ: התרגל להוסיף "שורת אימות" לכל פיסת קוד שאתה מקבל מה-AI: מספר שורות לפני ואחרי עיבוד, כמה שורות לדוגמא וסכום קריטי ביד. שלושת הבדיקות הללו תופסות את רוב שגיאות הלוגיקה השקטות.
לסיכום
בינה מלאכותית היא שותף רב עוצמה שמייצר במהירות SQL וקוד פנדה, אבל היא לא סמכות עיוורת. תן לו את התוכנית והמטרה בצורה ברורה; קרא את הקוד שהוא מייצר כאילו כתבת אותו בעצמך; בדוק את מספר השורות, פונקציות התאמה ותפוקה לאחר מיזוג/הצטרפות; אל תפעיל אותו מבלי לבדוק אותו במסד הנתונים הייצור. בעת איתור באגים, כוונו לפתור את הבעיה, לא להשתיק אותה. הקוד שעובד אינו הקוד הנכון; רק אתה יכול להבטיח דיוק.
משימת יישום
בחר שאלת ניתוח (למשל "מחזור חודשי לערוץ") ובקש קוד מה-AI עם SQL וגם עם פנדות. קרא את שני הקוד שורה אחר שורה, בדוק את מספר השורות לאחר המיזוג/JOIN ואמת ידנית לפחות סכום קריטי אחד. השווה אם שני הקודים מייצרים את אותה תוצאה; אם שונה, גלה מדוע.
רשימת בדיקה
- [ ] האם נתתי את הטבלה/סכימה ואת המטרה בבירור ל-AI?
- [ ] האם קראתי והבנתי את הקוד שהוא הפיק שורה אחר שורה?
- [ ] האם בדקתי את מספר השורות לאחר המיזוג/הצטרפות?
- [ ] האם אימתתי את הפונקציות שאני לא מזהה מהתיעוד?
- [ ] האם בדקתי תחילה את הקוד על נתונים בטוחים/קטנים ולא בסביבת הייצור?