מאוד נהניתי לראות שמישהו מהחבר'ה הקים היום עמדת התקנה לאוצריא במיר.
בכל פעם שעברתי ליד העמדה, חיכו שם לפחות שניים-שלושה אברכים בתור להתקנה.
אולי זה רעיון שכדאי לשכפל גם במקומות נוספים: להציב במקום ציבורי דיסק-און-קי עם קובץ ההתקנה, כבל מאריך, ושלט ברור עם הסבר קצר. לפעמים זה כל מה שנדרש כדי להנגיש את ההתקנה לעוד הרבה אנשים.
לקראת בין הזמנים הביקוש לאוצריא רק יגדל יש המון אברכים שממש יעזור להם כי הם מסכמים את הנלמד בזמן קיץ.
זוהי כתבה שרציתי לכתוב כבר הרבה זמן היום קצת אין לי כח לתיכנות אז הנה הכתבה
מנוע חיפוש מיישם אינדקס פשוט למדי שמאפשר לענות על השאילתה "אילו ספרים מכילים את המילים הללו?" כמעט באופן מיידי.
במקום לעבור על כל ספר בצורה ליניארית – פעולה שעלולה לקחת זמן רב – הוא פשוט בודק באינדקס באילו ספרים כל מילה מופיעה, ומחזיר את התוצאה במהירות.
מנועי חיפוש קלאסיים מיישמים בדרך כלל אלגוריתם שנקרא Term Frequency (TF). הרעיון הוא שככל שמילה מופיעה יותר פעמים באותו מסמך, כך סביר יותר שהמסמך רלוונטי לחיפוש.
זוהי הנחה טובה מאוד עבור מסמכים רגילים, אך לדעתי היא פחות מתאימה לזירה התורנית, שבה לעיתים דווקא אזכור בודד במקום המדויק הוא החשוב ביותר.
בגוגל מיושם כמובן גם ניקוד לפי פרמטרים נוספים, כגון פופולריות, סמכות הדף, מוניטין ועוד. בזית מיושם ניקוד גם לפי פרמטרים ייעודיים לעולם התורני, כגון ספרי יסוד וכדומה.
המנוע צריך למצוא במהירות את החיתוך בין רשימות המסמכים של המילים שבשאילתה – כלומר אילו מסמכים מכילים את כולן.
הרעיון המרכזי נקרא leap-frog ("קפיצת צפרדע"): במקום לעבור על שתי הרשימות במקביל איבר אחר איבר, לוקחים את הערך הנוכחי ברשימה האחת ו"דוהרים" קדימה ברשימה השנייה בקפיצות הולכות וגדלות עד שעוברים את הערך המבוקש, ואז מצמצמים בחיפוש בינארי על הטווח שנותר. שיטת הקפיצות האקספוננציאליות הזו נקראת Galloping Search. לאחר מכן מחליפים תפקידים בין הרשימות וחוזר חלילה. כך, כאשר רשימה אחת קצרה משמעותית מהשנייה, מדלגים על נתחים ענקיים של הרשימה הארוכה כמעט מבלי לגעת בהם.
איך זה עובד מאחורי הקלעים (פירוט טכני):
בפועל הרשימות (postings) שמורות בצורה דחוסה (Delta + VarInt – ראו בהמשך), כך שאין אליהן גישה אקראית: "התקדמות" ליעד מסוים מתבצעת על ידי פענוח הזרם קדימה. אסטרטגיית ה-Galloping וה-leap-frog עובדת גם כך – פשוט מפענחים קדימה עד שעוברים את הערך המבוקש.
כדי להוזיל את הקפיצות הגדולות קיימת אופטימיזציה בשם Skip List (מפורט בהמשך): נקודות עצירה דלילות הנשמרות מראש ומאפשרות לדלג מעל נתחים שלמים בלי לפענח אותם. זוהי אופטימיזציה שלא תמיד נדרשת – עבור רשימות קצרות הפענוח קדימה מהיר דיו.
אבל כאשר רשימות ההופעות ארוכות מאוד, גם הדילוג בעזרת ה-Skip List מתחיל לאבד מיעילותו יחסית. במקרים כאלה משתמשים לעיתים ב-Roaring Bitmaps – שיטה שמייצגת את המסמכים כרצף של ביטים ומאפשרת לחשב חיתוכים במהירות גבוהה במיוחד.
איך Roaring Bitmaps עובדים (פירוט טכני):
כדי להבין כיצד הם עובדים, צריך להבין מהו Bit. ביט הוא יחידת המידע הקטנה ביותר במחשב, והוא יכול להכיל רק 0 או 1.
במקום לשמור רשימת מזהי מסמכים, ניתן להקצות ביט אחד לכל מסמך:
לדוגמה:
מסמך: 1 2 3 4 5 6 7 8
ביטים: 1 0 1 0 0 1 1 0
את החיתוך בין שתי מילים ניתן לחשב באמצעות פעולת AND על שני מערכי הביטים. מכיוון שהמעבד מבצע פעולות על עשרות ואף מאות ביטים במקביל, הוא למעשה משווה כמות גדולה של מסמכים בפעולה אחת, ולכן החישוב מהיר מאוד.
כדי שלא לבזבז זיכרון על מיליוני ביטים שערכם 0, Roaring Bitmaps דוחסים את המידע בצורה חכמה (חלוקה לבלוקים ממוענים) ועדיין מאפשרים לבצע את פעולות ה-AND במהירות גבוהה. מכיוון שהבלוקים ממוענים, יש כאן דווקא גישה אקראית אמיתית – ולכן דילוג בין בלוקים (block-jump) הוא מקום שבו טכניקה בסגנון Galloping כן ישימה ומועילה.
למרות זאת, ברוב מנועי החיפוש הדילוג הרגיל (Galloping, לרוב בעזרת Skip List) עדיין מהיר יותר ברוב החיפושים, משום שרוב רשימות ההופעות אינן גדולות מספיק כדי להצדיק את העלות והמורכבות של Roaring Bitmaps. לכן נהוג להשתמש בו כברירת מחדל, ולעבור ל-Roaring Bitmaps רק עבור רשימות ענק וצפופות במיוחד.
Skip Lists (או Skip Pointers) הם אופטימיזציה של אסטרטגיית ה-Galloping, ולא תמיד נעשה בהם שימוש. הרעיון פשוט: מוסיפים לרשימה "נקודות קפיצה" מראש, כך שבמקום לפענח את הזרם הדחוס קדימה עד היעד, אפשר לדלג ישר לאזור הרלוונטי ולחסוך את הפענוח המיותר. עבור רשימות קצרות פענוח קדימה מהיר דיו, ולכן לא תמיד מוסיפים Skip List.
פרטי המימוש (טכני):
כל כמה ערכים נשמר מצביע (offset בקובץ) יחד עם הערך שאליו הוא מצביע. כך אפשר לאתר במהירות (למשל בחיפוש בינארי על נקודות הקפיצה) את הבלוק הרלוונטי, ולפענח החל ממנו בלבד – במקום להתקדם ולפענח איבר אחר איבר מתחילת הרשימה.
בספריות כמו Lucene זהו בדיוק המנגנון שמשמש להתקדמות (advance) על פני postings מדוחסים על הדיסק, בדרך כלל במבנה רב-שכבתי (multi-level skip list). Galloping Search כן מופיע במנועי חיפוש, אך רק מעל מבנים עם גישה אקראית אמיתית (כגון מערכים מפוענחים בזיכרון או מבני DocIdSet) – לא מעל זרם הבתים הדחוס עצמו.
מנוע החיפוש חייב לדחוס את הנתונים המספריים, אחרת האינדקס יתפח במהירות לממדים עצומים הן בשטח הדיסק והן בזיכרון.
שיטות הדחיסה (טכני):
אחת משיטות הדחיסה הנפוצות נקראת Delta + VarInt: במקום לשמור כל מספר במלואו, שומרים רק את ההפרש מהמספר הקודם. מכיוון שההפרשים בדרך כלל קטנים, ניתן לקודד אותם באמצעות VarInt, שתופס מעט מאוד בתים עבור מספרים קטנים. השיטה פשוטה, מהירה ויעילה מאוד.
ישנן גם שיטות מודרניות יותר הדוחסות את הנתונים בבלוקים, בדרך כלל של 128 ערכים. מעבר לדחיסה טובה יותר, הן מאפשרות לעיתים לדלג על בלוק שלם כאשר ברור שאין בו תוצאה רלוונטית.
כשמסתכלים לראשונה על מבנה האינדקס, קל להיבהל מכך שהוא אינו קובץ אחד רציף אלא מורכב ממספר מקטעים (Segments) נפרדים. אבל אין בכך שום דבר מפחיד – זוהי תוצאה טבעית של הדרך היעילה לכתוב לדיסק.
הסיבה היא שכתיבה לדיסק פריט אחר פריט היא איטית מאוד. במקום זאת, המסמכים נצברים תחילה בזיכרון (buffer), וכאשר הוא מתמלא, כל התוכן נכתב לדיסק בבת אחת כמקטע חדש – פעולה הנקראת Flush. כתיבה מרוכזת (batch) של הרבה נתונים בבת אחת מהירה בהרבה מאלפי כתיבות קטנות ונפרדות, ולכן שלב ה-Flush הוא הכרחי לביצועים טובים.
כל מקטע הוא בפני עצמו אינדקס קטן ושלם, שאינו משתנה עוד לאחר שנכתב (immutable). בזמן חיפוש, המנוע פונה לכל המקטעים ומאחד את התוצאות. מכיוון שכל Flush יוצר מקטע נוסף, עם הזמן מצטברים מקטעים רבים – וריבוי מקטעים מאט את החיפוש.
הפתרון הוא מיזוג (Merge): מדי פעם מאחדים כמה מקטעים קטנים למקטע אחד גדול יותר. בכתבי הקודש בחרתי בגישת מיזוג בסגנון LSM (Log-Structured Merge tree), שהיא בטוחה וחכמה במיוחד.
עיקר החוכמה של LSM הוא שהמיזוג מתרחש בדיוק בקצב הנכון – לא תכוף מדי (שיבזבז משאבים על כתיבה חוזרת של אותם נתונים) ולא נדיר מדי (שיותיר יותר מדי מקטעים ויאט את החיפוש) – בזכות ארגון המקטעים ברמות (levels).
כיצד מבנה הרמות עובד (טכני):
המקטעים מאורגנים בשכבות לפי גודלם. כל Flush יוצר מקטע קטן ברמה הנמוכה ביותר, וכאשר מצטברים ברמה מסוימת מספיק מקטעים בגודל דומה, הם מתמזגים יחד – והתוצאה, מקטע גדול יותר, "מקודמת" (bump) לרמה הבאה מעליה. וכך הלאה: הרמות הגבוהות מחזיקות מעט מקטעים גדולים, והרמות הנמוכות הרבה מקטעים קטנים.
התוצאה היא שמיזוגים קטנים ותכופים מתבצעים ברמות הנמוכות, ומיזוגים גדולים ויקרים מתבצעים לעיתים רחוקות בלבד ברמות הגבוהות – כך שקצב המיזוג מאוזן מאליו לפי כמות הנתונים שנצברה.
הבסיס לכל זה הוא ש-LSM היא שיטה של הוספה בלבד (append-only): לעולם לא עורכים מקטע קיים במקומו, אלא רק כותבים מקטעים חדשים. וזהו בדיוק הסוד למהירות – כתיבה רציפה של נתונים חדשים מהירה בהרבה מעדכון מפוזר של קובץ קיים, וגם בטוחה יותר: מכיוון שהמקטעים אינם משתנים, גם אם התהליך נקטע באמצע (קריסה או הפסקת חשמל), הנתונים הקיימים נשארים שלמים ואין סכנה לאיבוד מידע או להשחתת האינדקס.
תנאי הכרחי לכל המנגנון הזה הוא שהנתונים בכל מקטע יהיו ממוינים לפי מזהה המסמך. המיזוג עצמו אפשרי רק בזכות המיון: איחוד שני מקטעים ממוינים למקטע ממוין אחד הוא פעולה יעילה מאוד (בדומה למיזוג שתי רשימות ממוינות), הנעשית במעבר אחד בלבד. ללא מיון, המיזוג היה דורש מיון מחדש של כל הנתונים בכל פעם.
המיון חשוב לא פחות גם לחישוב תוצאות החיפוש: כל האלגוריתמים שתוארו למעלה (Skip List, leap-frog, חיתוך רשימות) מניחים שרשימות ההופעות ממוינות לפי מזהה. לכן כל מסמך חייב מזהה מספרי יציב שלפיו ממיינים.
במנועי חיפוש קלאסיים מקצים לכל פריט מזהה (id) פנימי משלהם. בכתבי הקודש בחרתי שלא ליצור מזהה חדש, אלא להשתמש במזהה השורה המובנה (line id) הקיים ממילא בקובץ seforim.db – כך המזהה כבר קיים, יציב, ומקשר ישירות בין תוצאות החיפוש למקור בטקסט.
רוב מנועי החיפוש תומכים גם בחיפוש תחיליות, סיומות, חיפוש מטושטש ועוד. לשם כך הם משתמשים בדרך כלל במבנה נתונים קומפקטי בשם FST (Finite State Transducer).
זהו מעין עץ שבו מילים בעלות תחילית משותפת חולקות את אותו נתיב, כך שנמנעות כפילויות ונחסך זיכרון רב. החיסרון הוא שבדרך כלל יש לטעון את מבנה הנתונים לזיכרון, דבר שדורש זמן אתחול וצריכת RAM נוספת.
בכתבי הקודש בחרתי להשתמש ב-SQLite, שמממש אינדקס מסוג B-Tree. גם כאן החיפוש לפי תחילית מהיר מאוד, אך אין צורך לטעון את כל מילון המילים מראש לזיכרון.
המעלה הגדולה של FST היא תמיכה טבעית בחיפוש מטושטש, בזכות המבנה שלו. ב-SQLite יכולת זו אינה מובנית.
החיסרון המשותף לשתי הגישות הוא חיפוש לפי סיומת או תת-מחרוזת: כאשר תחילת המילה אינה ידועה, אין לעץ נקודת התחלה יעילה.
הפתרון הקלאסי לבעיה זו הוא N-Grams. במקום לאנדקס רק מילים שלמות, מפרקים כל מילה למקטעים קצרים, למשל באורך 3 תווים, ומאנדקסים גם אותם.
לדוגמה:
ברכות
ברכ
רכו
כות
כך ניתן למצוא גם רצפים המופיעים באמצע המילה.
בכתבי הקודש לא הסתפקתי בטבלת N-Grams רגילה, אלא בניתי מבנה נתונים דחוס במיוחד שמייצג את כל ה-Grams בצורה קומפקטית.
רוב מנועי החיפוש יודעים לייצר גזירים (Snippets), אך הדבר בדרך כלל מחייב לשמור גם את תוכן המסמך בתוך האינדקס, מה שמגדיל אותו משמעותית ויוצר כפילות נתונים.
אפשר כמובן לבנות אינדקס "רזה" שאינו שומר את הטקסט, אך אז יש לחשב את הגזיר בזמן אמת, פעולה שאינה מהירה במיוחד.
חיסרון נוסף הוא שרוב מנועי החיפוש אינם מספקים גישה ישירה לרשימת המילים שהתאימו לשאילתה. לעיתים ניתן לקבל מידע זה, אך רק באמצעות שאילתה נוספת.
בכתבי הקודש, כבר בתחילת החיפוש נטענות כל המילים שהתאימו לשאילתה יחד עם מיקומן, ולכן ניתן לייצר גזירים במהירות, בגמישות ובדיוק רב.
שלב ה-Tokenization אחראי להחליט כיצד הטקסט יחולק למילים שהאינדקס ישמור.
במאגר של אוצריא קיימת מורכבות מיוחדת, משום שיש לטפל בראשי תיבות, סימנים, קיצורים וצורות כתיב שונות. לכן נדרש Tokenizer חכם שיודע לזהות נכון מהי מילה.
כדי לייצר גזירים נוסף שלב נוסף: בתוך החלוקה למילים נשמר גם המיקום המדויק של כל מילה במסמך. מידע זה נקרא Token Stream.
המידע הזה מאפשר לייצר גזירים מדויקים, להדגיש את המילים שנמצאו בתוצאות החיפוש, ולבצע זאת ללא צורך לסרוק מחדש את הטקסט כולו.
החישוב הזה מאפשר גם לסנן תוצאות לפי םרמטרים של מרחק בי מילים וכיו"ב
מנועי חיוש מודרניים שומרים את כל המידע הזה כבר בעת האינדוקס - אני בחרתי לא לעשות זאת עקב שיקולים של חסכון משמעותי בנפח דיסק.
בסופו של דבר, מנוע חיפוש קלאסי מורכב ממספר רעיונות פשוטים יחסית:
כל השאר הם בעיקר שיפורי ביצועים ותכונות נוספות.
@י.-פל.
שכחת לציין את הסייעתא דשמיא המיוחדת של אוצריא שזה לא דבר מובן מאליו (וזה אחד מהסיבות ששמרתי על פרופיל נמוך בהתחלה כשאוצריא הופיע כדי לא להפריע - היה לי תוכנה בדרך וביטלתי אותה הרבה אמרו לי חבל אני חושב ממש לא חבל!)
שרשור זה מיועד לדיווח על בעיות ותקלות התוסף כלי קודש לוורד (ממשק כתבי הקודש) הייחודיות לאוצריא.
כל בעיה אחרת יש לדווח ב־GitHub בלבד.
בלי נדר, אשתדל שלא להתייחס כאן לפניות שאינן קשורות באופן ישיר לאוצריא.
קודם כול, חשוב לי להדגיש שזו תחושה אישית שלי, וייתכן שהיא מושפעת גם מהבדלי תרבות או מתפיסות שונות.
אני נתקל לא פעם בתופעה שבה אדם מביע הסתייגות או ביקורת עניינית, ומיד קופצים עליו כמה אנשים ומבטלים את דבריו, כאילו עצם העובדה שהעז להציג עמדה שונה כבר הופכת אותו לבלתי לגיטימי.
על מה אני מדבר?
בעיקר על שני נושאים שחוזרים שוב ושוב: זכויות יוצרים והשימוש בבינה מלאכותית.
בכל הקשור לזכויות יוצרים, נראה שיש אנשים שנפגעים מאוד מכך שאני ואחרים מסרבים אפילו לשקול פעולות מסוימות. האם אסור לנו להסתייג מרעיונות כמו העתקה, סריקה או עקיפת מגבלות שנועדו להגן על יצירה וקניין רוחני? האם אסור לנו לומר שדברים כאלה אינם מתיישבים עם הערכים שלנו?
באופן דומה, כאשר מישהו מביע הסתייגות משימוש מופרז ובלתי מבוקר בבינה מלאכותית, התגובה לעיתים אינה דיון ענייני אלא ניסיון לבטל את עצם הביקורת. כאילו כל מי שמצביע על מגבלות, סיכונים או חסרונות של הטכנולוגיה הוא בהכרח מתנגד לקדמה. בעיניי, אפשר להכיר ביתרונות העצומים של הבינה המלאכותית ובו בזמן להודות שיש לה גם מגבלות ושיש מקום לשימוש מושכל ואחראי בה.
מה שמפריע לי במיוחד הוא הגישה שלפיה מי שבוחר להציב לעצמו גבולות או לפעול מתוך שיקולים ערכיים מיד נתפס כ"פראייר" או כמי שאינו מבין את המציאות. לא כל מי שמכבד זכויות יוצרים הוא נאיבי, ולא כל מי שמזהיר מפני הסתמכות מופרזת על בינה מלאכותית הוא מתנגד לטכנולוגיה.
הייתי שמח לראות יותר מקום לשיח מכבד, שבו אפשר להביע עמדה ערכית או מקצועית גם אם אינה מקובלת על כולם, מבלי להיתקל מיד בזלזול, בביטול או בהתקפות אישיות. דיון אמיתי מתחיל דווקא במקום שבו אנשים מוכנים להקשיב לטענות, גם כאשר הן אינן תואמות את עמדתם המוקדמת.
בתכנות אומרים כל ההתחלות קלות ולא להיפך
אז הנה סתם משהו לגרות אתכם אבל ראו הוזהרתם מוקדם מדאי מכדי לפתח ציפיות
התמונה שלפניכם זה לא תמונה זה טקסט!
מחילה, אולי לא כל כך יפה מצידי לבקש את זה, ובאמת נוגע ללב לקרוא את כל מה שאתם כותבים כאן.
אבל במטותא מינייכו – רוצים לפרגן? מצוין! זה בהחלט נותן כוח ומחזק.
אבל בבקשה, אל תתחילו לנתח את האישיות שלי גם לא לצורך שבח. זה גורם לי אי נוחות מרובה.
תודה רבה לכולכם על המילים הטובות ועל כל הפרגון.
רבותיי מרגש או לא מרגש?
יש באגים אני יודע
אבל אותי זה ריגש
יש לשנות את הסיומת לhtml
עדיין חסר הרבה מסכתות שלא חתוכות אם הציבור יכול להירתם זה יעזור מאוד
תודה מראש
יש"כ לכולם כבר קפץ מישהו על המציאה ותרם סכום נאה לטובת הפרוייקט
ברוך אומר ועושה לאוצריא יש פלטפורמה לעריכת ספרים כל מי שעוד לא הצטרף מוזמן להצטרף לזיכוי הרבים להיות מכותבי ספרים ומפיצם לרבים
רוב האנשים משתמשים בבינה מלאכותית בצורה די דומה: הם משקיעים זמן בניסוח כמה משפטים מדויקים, או מנהלים שרשור ארוך של שאלות ותיקונים עד שהבינה סוף סוף מבינה למה הם התכוונו.
לפעמים זה עובד מצוין. אבל לא מעט פעמים התוצאה רחוקה ממה שציפינו.
אז האם יש דרך להפיק מהבינה המלאכותית יותר – בפחות מאמץ, ובדרך שגם תהיה מהנה יותר?
נתחיל במשל.
דמיינו שאתם מגיעים לסביבה חדשה. לא מדובר באתגר מורכב במיוחד, אבל הייתם רוצים להצליח ולהתמצא במהירות. מה הדבר הראשון שתעשו?
סביר להניח שתשאלו: איך המקום הזה עובד? מה הכללים? מה חשוב לדעת?
אותו עיקרון נכון גם בעבודה עם בינה מלאכותית.
לפני שמתחילים לבקש ממנה לבצע משימה, כדאי לעצור לרגע ולבקש ממנה להסביר את הרקע: כיצד מקובל לבצע את המשימה, אילו אפשרויות קיימות, מהם השיקולים המרכזיים ואילו דרכי פעולה מומלצות.
ברגע שמבינים טוב יותר את התחום, גם הרבה יותר קל לנסח בקשות מדויקות ולהכווין את הבינה אל התוצאה הרצויה.
הוראות כלליות מדי מאלצות את הבינה להשלים בעצמה פרטים רבים. ככל שהיא נדרשת לנחש יותר, כך גדל הסיכוי שהתוצאה תהיה פחות מדויקת.
לכן, בדרך כלל קיימות שתי גישות עיקריות:
הגישה הראשונה היא להשקיע מראש בכתיבת פרומפט מפורט ומדויק, שמתאר בצורה ברורה ככל האפשר את התוצאה הרצויה. ככל שההנחיות מפורטות יותר, כך קטן הצורך של הבינה להשלים פערים בעצמה.
הגישה השנייה, `ולעיתים גם היעילה יותר, היא לעבוד עם הבינה כתהליך משותף. במקום לנסות להגיע לתוצאה המושלמת כבר בבקשה הראשונה, מתקדמים צעד אחר צעד: בוחנים את התוצאה, מתקנים, מוסיפים הנחיות ומדייקים את הכיוון עד שמגיעים למה שרוצים.
העיקרון הזה נכון במיוחד ביצירת תמונות באמצעות בינה מלאכותית.
במקום לנסות לתאר תמונה מורכבת בפרומפט אחד ארוך, עדיף להתחיל ברעיון בסיסי. אפשר לבקש סגנון דומה למה שמחפשים, לבחור את הכיוון המוצלח ביותר, ומשם לשפר אותו בהדרגה.
בכל שלב מוסיפים עוד פרט, משנים צבעים, מתקנים קומפוזיציה, מחליפים אלמנטים או משפרים את האווירה. כך, במקום להילחם בפרומפט אחד מושלם, בונים את התוצאה באופן טבעי עד שמתקבלת תמונה מרשימה ומדויקת.
הטעות הנפוצה ביותר היא להתייחס לבינה המלאכותית כמכונה שמקבלת פקודה אחת ומחזירה תשובה מושלמת.
בפועל, התוצאות הטובות ביותר מתקבלות כאשר עובדים איתה כמו עם שותף: לומדים מעט את התחום, מספקים הקשר, מגדירים מטרות ברורות, ומשפרים את התוצאה בהדרגה.
ככל שתשקיעו פחות בניסיון לנסח את "הפרומפט המושלם", ויותר בתהליך עבודה נכון – כך תגלו שאפשר להפיק מהבינה המלאכותית הרבה יותר, בהרבה פחות מאמץ.
תודה רבה לציבור הקדוש על העלאת הצדדים לכאן ולכאן מכאן ואילך אני מאמין שזוהי החלטה של המפתח
@י.-פל.
באוטובוס של מיר כל אברך שני (שיש לו מחשב) יושב עם אוצריא ועושה שטייגן.
אבל זה היה עוד לפני הפירסום של היום
חשבתי נו כבר יש לכולם ואז ראיתי מה שהולך עם העמדה הזו ופשט השתוממתי.
נסיתי להתקשר אליך רק לספר לך מה קורה שם.
לא הבנתי ממה כולם עושים עסק זה לא פיתוח מסובך זה שאלה של העדפות תאמינו או לא יש דברים שקודמים לפיתוח הזה.
לחץ מטורף כמדובר - לדעתי זה לא התנהגות יפה.
אני לא חושש שלא אצליח אני רק חושש מכמה זמן זה ייקח לי כרגע כמעט ואין לי זמן לזה.
@הבל-הבלים
אפשר אולי להוסיף הגדרה האם עושים כזו הגדרה 
בנוסף היא מהירה כברק ואינטואיטיבית מאוד!
תודה - אלו שני נושאים שמאוד חשובים לי
אם כבר מדברים על תרומות אני מציע אולי אחרי החגים ארגן קמפיין (כל אחד בכולל שלו להוראו קבע קטנות של שקלים בודדים ללא הגבלה למי שהתקין את אוצריא)
אוצריא זקוקה לכסף שוטף בשביל כמה דברים ואם ננהל את זה נכון קמפיין כזה יכול מאוד להצליח לעניות דעתי
אני לא עבדתי על זה תקופה באלול אחרי הכל יש פחות זמן לכאלו דברים