Save time building applications with LLMs by utilizing tools like LangChain, Llama index, Guidance, GPTCache and many more
תאריך עליית הפרק לאוויר: 28/08/2023.
לי: שלום לכולם, היום בפרק נדבר על הבחירות שאתם צריכים לעשות כשאתם הולכים ובונים אפליקציה מבוססת LLM-ים, נדבר על איך בוחרים LLM Provider ואיזה פריימורקים כדאי לעבוד, Output Structuring, Caching, VectorDB, Prompt Engineering ועוד הרבה נושאים.
זה פרק שלא מומלץ לשמוע בנהיגה, [צוחק קלות] כי אני חושב שאנחנו מדברים על הרבה דברים יחסית מהר, אולי תרצו לכתוב לכם כזה notes. אז יאללה, בואו נתחיל.
[מוזיקת רקע]
אז החלטה הראשונה שאנחנו צריכים לקבל זה על ה-LLM Provider, כן? זה שנותן לנו את ה-LLM עצמו. יש את OpenAI, כן? כל ה-GPT 3.5, GPT-4, ויש גם את Hugging Face, ש-Hugging Face זה יותר פלטפורמה שעושה הוסטינג לכל ה-Open Source LLMs, מ-LLama, Vicuna, Guanaco, Falcon, כל מיני שמות כאלה ואחרים ששמעתם, כל אחד מהם בגרסאות השונות שלו.
הדברים שחשוב לקחת בחשבון ככה כשבוחרים LLM, שלושה דברים מרכזיים זה זמן הריצה, ככל שלוקחים מודל יותר גדול, אז הזמן ריצה הולך וגדל גם, ואז דברים לוקחים יותר זמן. אז ל-use-case-ים שהם יותר real-time-ים כמו צ׳אט זה פחות מתאים, כאילו אנחנו נעדיף לקחת runtime יותר נמוך. Quality, שעכשיו גם דיברנו על זה, ככל שהמודל יותר גדול, האיכות של התוצאים, תוצרים שלו יהיו יותר... תהיה יותר טובה. GPT-4 יותר טוב מ-GPT 3.5. זה רגע כלל... שנייה, הכוונה מהבחינה הזאתי, ועלויות, אז GPT-4 גם משמעותית יותר יקר מ-GPT 3.5, והחיוב הוא לפי טוקנים כמובן.
אממ... עוד כמה נקודות קטנות שחשוב לשים לב אליהם בהקשר של LLM Provider, זה להבין אם אפשר או אי אפשר לעשות Fine-tuning. לאורך הדרך כשתגיעו לתקרת זכוכית עם הביצועים של LLM, יכול להיות שתרצו לעשות את זה ושווה שכבר אפשר יהיה לעשות את זה מלכתחילה.
עוד נקודה זה ה-Context Window, אז יש מודלים כמו למשל Claude שנותנים Context Window ענק של 100,000 טוקנים, לעומת GPT-4 שנותן 8,000 ו-GPT 3.5 שנותן, תלוי בגרסה שלו, אבל יכול לתת עד 16,000 טוקנים.
אממ… שתי… כמה מקומות ב-Hugging Face ששווה לכם להסתכל עליהם, גם בשביל לעזור לכם לקבל את ההחלטה, יש את Chatbot Arena, שזה Space ב-Hugging Face, שפשוט נותן לכם לשחק עם כל מיני Chat Models ולהעריך אותם, יכול לתת להם אותו Input ולראות את ה-output-ים של שני מודלים שונים side-by-side. יש את Text Generation Web UI של מישהו ב-GitHub שקוראים לו Oobabooha, או Oobabooga, משהו כזה, [צחוק קל] שזה פשוט איזשהו Lightweight UI שאתם גם יכולים לשחק, להוריד מודלים מהאינטרנט ולשחק איתם On-Prem ולהעריך ביצועים.
ועוד שני Leaderboards, זה Hugging Face LLM Leaderboard, שתוכלו לראות השוואות בין כל המודלים ה-Open Sources-ים ל-LLM ו-MTEB, שזה אותו דבר רק ל-Embeddings Model.
גל: אז רק בשביל לסדר קצת את ה... איך זה נכנס לתוך האפליקציה, אז אמנם אנחנו צריכים להחליט על LLM Provider, זה לא חייב להיות אחד, כן? זאת אומרת, תחשבו על זה שהאפליקציה שלכם בסופו של דבר, אם אנחנו ממירים את האפליקציה כמו שאנחנו מכירים מתוכנה רגילה, בסוף כל מיני חלקים פשוט יוחלפו ב-LLM, אינפוט-אאוטפוט של LLM.
עכשיו, החלקים, החלקים האלה הם… לכל חלק יש את הדרישות שלו. למשל, יש חלק שהוא דורש יותר reasoning - אז תבחרו ב-GPT-4 על פני GPT-3.5. יש חלק שאולי הוא מאוד קריטי ועובר בו, הרבה פעמים עובר בו הדאטה, אז אולי שווה מבחינה להתחשב במחיר ולבחור ב-3.5 ולהתחשב במהירות, כי המהירות היא מאוד משמעותית ולבחור באיזשהו מודל יותר מהיר. יש לכם אולי חלקים שה-reasoning והמהירות חשובה ו... ודברים כאלה, אולי אתם רוצים לשים שם איזה מודל Open Source Fine-Tuned שאתם עשיתם. אז שוב, אז כאילו תחשבו על החלקים שאתם מחליפים ותחשבו על הדרישות של כל חלק, וככה תעשו החלטה.
עוד איזה נקודה קטנה למודלים שהם בעצם Close Source, אז אתם יכולים כמובן ללכת ל-OpenAI, אבל אם חשוב לכם למשל סקיוריטי, אז אולי שווה לכם ללכת ל-Azure, או אם אתם יכולים כמובן לקבל קרדיטים, זה תמיד טוב, אז יש קרדיטים משמעותיים שמיקרוסופט נותנים ל-Azure, ל-OpenAI Models. ומהצד השני כמובן שיש את המלחמה של AWS, שחברה לכל החברות Close Source, כמו AI21, Tropic וכו', והם בעצם נותנים גרסאות Close Source על AWS עצמה.
לי: אחלה. אז הנקודה השנייה זה… כמו שיש לנו LLM Provider, יש לנו גם Embedding Provider.
OpenAI נותנים את המודל Embedding שלהם שנקרא ADA, יש גם הרבה מודלי Embeddings אחרים ב-Hugging Face, שוב, יש את MTEB Leaderboard, תסתכלו עליו, תשוו בין דברים. גם פה חשוב לשים לב איזה dataset ה-Embedding Model הזה יתאמן עליו, ולוודא שזה בדומיין שלכם, או שזה קרוב למשימה שאתם מנסים לבצע, או שאתם מנסים לאנדקס, כדי להבטיח ביצועים הכי טובים. וגם פה יש שוב את המשולש הזה של זמן ריצה מול איכות של התוצרים אל מול העלויות. אז צריך למצוא פה גם את הנקודת איזון שנכונה ל-use-case שלכם, ושימו לב שפה גם בא יותר לידי ביטוי, גם ב-LLM-ים, אבל פה אפילו יותר, הנושא של אונליין מול אופליין אינדקסינג.
אז הרבה פעמים ב-Embeddings Model משתמשים בהם כדי לאנדקס את ה-VectorDB שלנו, ולפעמים גם משתמשים בו באונליין כשהיוזר שולח הודעה ואני רוצה להבין מה ה-Embeddings שלו, ולהשוות את זה למה שיש לי כבר ב-DB, אז צריך לקחת את שני הדברים האלה בחשבון.
גל: כן. מבחינת פריימוורק, אז איזה פריימוורק הייתם רוצים להשתמש? זאת אומרת, כשאנחנו אומרים פריימוורק, אז בעצם מה ה-Glue Code, או מה ה-Library שתעשה אורקסטרציה לכל האפליקציה שלכם, ול-LLM כמובן במרכז. אז לדוגמה - LangChain, זה ספרייה יחסית ידועה שדי מתרוממת, בוא נגיד, בתקופה האחרונה. אנחנו מדברים עליה גם הרבה בפודקאסט ואנחנו חושבים שהיא… שווה, בוא נגיד, לנסות לפחות לאמץ אותה.
אבל יש ספריות אחרות, כמו למשל Haystack, שהן גם מאפשרות בנייה של agent-ים ואיזשהו חיבור של פייפליינים עם VectorDB, עם query, פרומפטים, דברים כאלה. חוץ מזה יש ספריות שהן קצת יותר מנסות לתפוס איזה זווית של עזר יותר, כמו למשל Llama Index, שהיא מאוד טובה ב-retrieve של דאטה. היא מתחברת ל-LangChain, זאת אומרת החיבור ל-LangChain הוא יחסית טבעי, והיא עושה… יש לה הרבה אדאפטרים אחרים, שלמשל ל-LangChain אין.
אז זה מאוד תלוי מה ה-use-case שלכם, וככה אתם תבינו אם אתם רוצים להשקיע את ה-learning curve הזה וללמוד את הספרייה ולהטמיע דברים כמו שצריך, או שזה סתם POC, דברים כאלה, ואפשר אולי ללכת על כיוונים של… בכלל בלי ספרייה, זה גם אפשרות, כן.
לי: כן, אז שווה להגיד שמהבחינה הזאת LangChain היא הספרייה באמת הכי פופולרית היום עם כמעט 60 אלף סטארים ב-GitHub. אני חושב שהיתרון של LangChain זה שאתה יכול לעשות POC ממש מהר, אם זה כבר use-case שהם מימשו, למשל SQL Database Agent שמאפשר לך מטקסט חופשי לעשות שאילתות על הדאטאבייס שלך ולהפוך את התשובה לטקסטואלית גם. ממש בכמה שורות קוד אפשר כבר להשיג את זה ואז באמת, ככל שרוצים דברים יותר custom-ים, אז צריך להכיר את הספרייה ולדעת לעבוד איתה ויש פה איזושהי עקומת למידה.
עוד דבר שיש ב-LangChain זה למשל את כל הנושא של פלאגינים ואינטגרציות אליהם, כמו SERP, שזה חיפוש בגוגל, או Wolfram Alpha, או REPL, שזה הרצת קוד פייתון וכל מיני דברים כאלה ואחרים, שאפשר פשוט להשתמש בהם כ-tools יחסית גנריים ופופולריים לאייג'נטים שלכם. ועוד דבר זה כל הנושא של Structured Output. אז יש ב-LangChain חלק מהפריימורקס זה Output Parser-ים.
אז מתי צריך את זה? נגיד כשאתם עובדים עם אייג'נטים, אז הרבה פעמים לאייג'נט יש איזשהו תהליך מחשבתי, כן? נגיד Chain of Thought, זה הסוג אייג'נט שבחרתם, ועכשיו הוא אמור להוציא את ה-output שלו בצורה שיחסית Structured. למשל, ב-Chain of Thought הוא צריך להוציא action ואת ה-action input, כלומר, מה ה-action שהוא בוחר לעשות, באיזה פונקציה הוא בוחר להשתמש, ומה ה-input לאותה פונקציה. ולפעמים הוא טועה, לפעמים הוא פשוט לא עושה את זה, או מדלג על אחד מהם, או שוכח, או כל מיני, אתם יודעים, בעיות כאלה ואחרות של LLM-ים.
אז Output Parser בדיוק בא להציל אתכם מזה. הוא גם מזהה את זה, וגם יש לו כל מיני מנגנוני retry שעוזרים לכם לתקן את ה-output. בהקשר הזה יש עוד שני כלים שאני אמליץ עליהם בהקשרים של Output Parser-ים, אחד זה OpenAI Functions, שמניסיון שלי הוא פשוט עובד מעולה, אני ממש ממליץ להשתמש בו לכל Structured Output. זה בגדול JSON סכמה שאתם מספקים ל-API של OpenAI, וה-LLM כאילו יודע לציית לאותו... לאותה סכמה, שרק ב-sidenote אני, חשוב להגיד, הוא לא מציית ב-100% במקרים, אבל בוא נגיד זה מעלה לו את הדיוק באופן משמעותי, אז עדיין אני חושב ששווה לשים Output Parser לצידו.
ועוד ככה ספרייה די פופולרית לנושא הזה, זה Guidance של מיקרוסופט, גם Open Source Library, שגם עוזר להצמד לאיזשהו מבנה ידוע מראש של output צפוי.
גל: אז בעצם נניח ועשינו את כל ההחלטות האלה, אנחנו כבר נראה לי במצב שאנחנו יכולים לבנות POCs, אפילו POCs יחסית מתוחכמים של אייג'נטים, ואנחנו רוצים קצת לבחון את הדברים, להראות את הדברים אולי אפילו לאיזשהו Stakeholders בחברה, אז מה לעשות? אנחנו או מפתחי Backend או מפתחי… או Data scientists-ים, אנחנו לא יודעים לכתוב react, או חלקנו כן, אבל לכאלה שלא, יש פתרון בעצם בפייתון בצורה של ספריות בשם Gradio, שהיא לפי דעתי ספרייה של Hugging Face, ו-Streamlit, שאיתה אתם יכולים בעצם לבנות סוג של UI. אנחנו השתמשנו בו עם פרויקט בתור UI כזה Dev-י, UI מאוד מאוד מהיר, להוריד את ה-dependency על הפרונט-אנד, ועדיין לתת אפשרות להתחיל לתייג דאטה, לתת אפשרות ל-Stakeholders להתחיל לשחק עם המוצר, ובעצם ממש לתת הרגשה שהמוצר עובד.
לי: קוּל, אז הנקודה הבאה היא באמת caching. זאת נקודה שככה, אנחנו מכירים אותה כבר מאפליקציות קלאסיות, המטרה שלה זה א', להוריד עלויות חישוב, כן? במקרה שלנו זה עלויות ריצה של LLM. ודבר שני זה לשפר את הזמני ריצה של האפליקציה שלנו, כי השליפה היא הרבה יותר מהירה.
אז יש ב-Redis קודם כל פיצ'ר של… קודם כל Redis בתור caching רגיל, וגם יש שמה איזשהו פיצ'ר חדש, שהאמת לא יצא לי לנסות, אבל הוא קיים, של Semantic Caching, אז יכול להיות שכדאי להסתכל על זה. יש גם פרויקט Open Source שנקרא GPT Cache, שבעצם בא לעזור עם Semantic Caching. כן? הבעיה ב-caching בסוג הזה של האפליקציות, זה שאנחנו לא מדברים פה על אינפוטים שהם אחד לאחד כל הזמן. אבל אם יוזר כותב לי "Hi", או אם הוא כותב לי "Hello", רוב הסיכויים שאני צריך לענות לו את אותה תשובה. ואז סמנטית "Hi" ו-"Hello" הם מאוד קרובים.
אז צריך לעשות פה איזשהו מנגנון קצת יותר מתוחכם ל-caching. אז באמת יש פרויקטים כמו GPT Cache שעוזר לפתור את זה. מצד שני, יש גם הרבה בעיות עם הדבר הזה, וזה לא כזה פשוט. למשל, ניתן דוגמה מאיפה יכולה להגיע מורכבות, זה כשהתשובה תלויה ביוזר. כלומר, אם היוזר כותב לי "Hello", אבל השם שלו זה גל, אז אני אענה לו משהו אחד, ואם השם שלו זה לי, אז אני אענה לו משהו אחר. או אם יש לי מאטה-דאטה על אותו יוזר, באיזה ארגון הוא נמצא, באיזה אזור בעולם הוא נמצא, יכול להיות שזה ישנה לי את ה-caching. שוב, זה לא דברים שאי אפשר לפתור, אבל זה דברים שצריך לקחת אותם בחשבון.
וגם יכול להיות שהתשובה שאנחנו נשמור, היא תהיה… כאילו צריך לעדכן אותה מדי פעם בהתאם לכל מיני לוגיקות. אז זה גם דברים שנלקחים, שוב, כמו בכל מנוע caching, נלקחים כחלק מהסיפור.
גל: כן, בכללי, caching סמנטי הוא קצת מפחיד אותי ב-use-case הזה של צ'אט. כנראה שהוא טוב ב-use-case-ים אחרים מאוד, אבל ב-use-case הזה, זה מאוד מאוד תלוי ה-Similarity Model שאתה בוחר, ו… כאילו, יש מודלים שאומרים, זה Similar לזה, אבל למה? כאילו, למה זה דומה? זה מדבר על אותו נושא, אבל יכול להיות שזה מדבר על זה בצורה סמנטית. כלומר, זה מדבר על זה נגטיבית וזה מדבר על זה פוזיטיבית, אבל זה עדיין אותו נושא, אז… אז אני צריך להחזיר תשובות אחרות לגמרי, כן… אז… אז קחו את זה בחשבון, תסתכלו האם זה באמת מתאים ל-use-case שלכם. זה מאוד… יש לך איזה רצון כזה לחסוך בקריאות ל-GPT, כי גם הן עולות כסף וגם מהירות, אז יש לך איזה רצון כזה לעשות אופטימיזציה, אבל צריך לקחת את זה עם grain of salt.
אז הנושא הבא אולי ששווה לגעת בו, זה כל העניין של VectorDB, זה גם מתקשר לנו לכל העניין של ה-caching, כי אנחנו צריכים להבין האם יש לנו משהו ב-cache שדומה, ומה זה אומר דומה? אז יש לנו איזשהו וקטור, רפרזנטציה, ואנחנו בעצם רוצים להבין האם ה-query שאנחנו מסתכלים עליו, הוא דומה לאיזשהו אייטם שכבר יש לנו ב-cache.
אבל ל-VectorDB, כמובן, יש עוד use-case-ים. שאנחנו, יש לנו המון דאטה, המון documents, ואנחנו רוצים להבין האם יש לנו איזה document שמתאים ל-query מסוים, אז אנחנו מאנדקסים את זה כמובן ושמים את זה בדאטאבייס. אז פה יש לכם Provider-ים, המון Provider-ים, והניואנסים הם... הם... בוא נגיד, דקים. אז דבר ראשון שאתם רוצים להבין, האם אתם רוצים Managed Service או לא Managed Service. אם אתם רוצים Managed Service, אז יש לנו את Pinecone הישראלית, שעושה עבודה די טובה, וכמובן יש את Elasticsearch, שהם די טובים, גם הם נותנים Out of the Box Keyword Search לטקסט שלכם. זה היה ה-use-case שלהם מתחילת הדרך, שהם בעצם נותנים איזה מנוע חיפוש טקסטואלי מאוד מאוד טוב, Out of the Box. והם הוסיפו עכשיו פיצ'ר של וקטור, אז אתה יכול גם לאחסן את ה-Vectors ובעצם לשלב, לעשות query משולב כזה של Keyword Search פלוס Vector Search ולעשות איזשהו שילוב כזה.
ואם אתם רוצים ללכת על Open Source, אז כמובן יש לכם כל מיני החלטות שאתם צריכים לעשות. למשל, מה... מה כבר יש לכם בסטאק. אם למשל יש לכם Postgres, אז אולי שווה לכם לחשוב על Quick Wins עם pgvector, כי זה איזשהו מן שכבה כזאתי שמתלבשת על ה... על ה-SQL שלכם, על הדאטאבייס שכבר יש לכם, ונותנת את הפונקציונליות של Vector Search.
אממ… אז צריכים לחשוב על דברים כאלה, על מחיר, ועל דברים קצת יותר טכניים, אם נכנסים לעומק, כמו איזה Query Mechanism אני יכול לעשות, האם זה… מה, מה הדיוק של הדברים, בגלל שהרבה מהמנויים האלה עובדים על Approximate Nearest Neighbors, אז יש כל מיני אלגוריתמים כאלה ואחרים ששווה לקחת בחשבון.
לי: נראה לי זה גם ההזדמנות ככה להגיד שיש לנו פרק ייעודי רק על Vector Databases, אז שווה, מי שזה מעניין אותו הנקודה הזאת, פשוט יש הרבה מאוד על מה לדבר פה, שווה ללכת לשמוע את הפרק.
אממ… ניגע עכשיו קצת בכל הנושא של Prompt Engineering, Prompt Management, אז נחלק אותם באמת לשתי הקבוצות האלה. אז Prompt Engineering זה בעצם, לצורך העניין, זה כלים שיעזרו לנו לכתוב את הפרומפט הנכון. אני באופן אישי לא חסיד של... של המונח הזה Prompt Engineering, כי בעיניי זה עולם מאוד מאוד מצומצם ומאוד רזה, אין שם יותר מדי מה לעשות. אם כבר, כן אני אכווין פה לשני resources שיכולים לעזור, זה… יש המון המון מדריכים ברחבי האינטרנט על איך לעשות פרומפטינג נכון. שני הדברים שאני כן אגיד, זה אחד, learnprompting.org, פשוט, לא יודע, אני אהבתי אותו, זה כזה כל מיני מדריכים יחסית פשוטים לפי קונספטים שמעניין אתכם, אם זה security, אם זה structuring, כל מיני כאלה. או Prompt Perfect, שגם נותנים איזשהו סרוויס כזה, יש להם שירות שנקרא Prompt as a Service, שעוזרים לך ליצור את הפרומפט האידיאלי למשימה שלך.
והדבר השני בהיבט של Prompt Engineering שאני מאוד ממליץ עליו, זה להסתכל על, זה בעיקר ל-Open Source Model, להסתכל על הפרומפטים שהשתמשו בהם בשלב האימון. הרבה פעמים כשמאמנים למשל מודלים, למשל את "פלקון" או מודלים אחרים, היה איזשהו structure שהשתמשו בו כשעשו את האימון הזה, את האימון על צ'אט למשל. למשל, כתבו כל פעם Human נקודותיים ו-AI נקודותיים. ואם עכשיו אנחנו בפרומפט שלנו נכתוב, במקום Human נרשום User נקודותיים, ובמקום AI נרשום Assistant נקודותיים, זה עלול לפגוע בביצועים. לא, כנראה לא דרמטית, אבל זה בדיוק הדברים המינוריים שיכולים לעשות את ההבדל.
ויש עוד כל מיני טכניקות, גם טכניקה מרכזית שכזה אני חושב שהיא מאוד מאוד אפקטיבית, זה כל הנושא של Few-shot, גם דיברנו על זה בהרחבה באחד הפרקים שלנו, אז שווה לשמוע.
בהיבט של Prompt Management, זה יותר כלים שנועדו לאפשר לכם לראות את כל הפרומפטים שלכם באפליקציה, ולהבין איך הם עובדים, ולתת לכם שליטה מבחוץ, במקום בתוך הקוד, איזשהו כלי חיצוני, No-code עם UI, שמאפשר לכם גם Version control. בשביל זה יש כלים כמו PromptLayer או Pezzo הישראלים, ויש גם עוד מיני כלי כזה שנקרא Tokenizer, שאתם יכולים להכניס אליו את הפרומפט שלכם, והוא אומר לכם כמה טוקנים יש בו. כן? כאילו כל מיל... יש נטייה לחשוב שכל מילה היא טוקן, אבל זה לא מדויק, בממוצע כל שלושת רבעי מילה זה טוקן. אז אם יש לכם איזשהו פרומפט שאתם רוצים להשתמש בו, תכניסו ותראו על מה מתבזבזים לכם הטוקנים. הרבה פעמים זה כל מיני white spaces שאתם לא באמת צריכים, או… או אם סתם אתם רוצים לדעת כמה יש לכם, אז גם, זה אחלה כלי.
גל: בהקשר הזה של פרומפטים, אז יש פה כמובן את ה-Prompt Management ואת ה-Prompt Engineering, אבל גם יש את הנושא של איך מתחבר כל העניין של לנהל פרומפט בתוך הקוד. איך... איך בעצם אנחנו עוקבים אחרי הפרומפטים, איך אנחנו נותנים לפרודקט מנג'ר אולי בלי ידע בקוד, אולי את האפשרות לערוך את הפרומפטים שלנו. אז אולי שווה, כשמדברים על פתרון לאפליקציה, לבניית אפליקציה, שווה לכם להסתכל, ב-LangChain, למשל קוראים לזה Serializable, שבעצם אתם יכולים לנהל את הפרומפטים שלכם עם Yaml-ים ועם JSON-ים, ככה שפרודקט מנג'ר למשל יכולים לבוא ל-Yaml הזה ולערוך אותו, ככה, והם לא משנים בעצם את הקוד. אז… ואחרי זה כמובן שווה לכם קודם כל להשתמש ב-Prompt Management Tools, בשביל להבין מה ה-output ולבדוק שבאמת השינוי לא משפיע, או משפיע לטובה, אבל אחרי זה באמת צריך ללכת ולנהל את זה גם ב-codebase. אז יש לכם את האפשרות לעשות את זה עם Serializable.
עוד נושא חשוב זה כל העניין של ה-debugging והאבלואציה. אז LangChain יצאו עם פלטפורמה בשם LangSmith, שנותנת דבר ראשון ויזיביליות יותר טובה. זאת אומרת אתם יכולים תמיד לקחת את ה… לקחת כל chain ולתת... לתת ארגומנט שנקרא Verbose=True ואז מה שיקרה זה שזה פשוט ידפיס לכם לקונסול את כל הפרומפטים שנשלחים ל-LLM. אבל LangSmith הוא לוקח את זה קצת צעד מעבר, אולי אפילו הרבה צעד מעבר. הוא מדפיס בעצם את כל ה-chain-ים ואיך פרומפטים קשורים ל-chain-ים ואיך chain-ים קשורים אחד לשני. אז למשל אם אנחנו מדברים על Sequential-chains-ים שמכין chain-ים בעצמו, אז הוא כבר נותן לכם את כל הסטאק ומראה לכם מה קרה בכל הריצה. וחוץ מזה הוא גם כמובן סופר את הטוקנים הנכנסים, את הטוקנים היוצאים, ואתם יכולים לקבל הערכה של כמה פרומפט עולה ואתם יכולים בעצם גם ליצור dataset-ים מהפרומפטים. למשל, אתם יכולים, יש לכם input של פרומפט ו-output של ה-LLM, אתם יכולים לתת פידבק, זה פרומפט טוב, זה use-case טוב, זה הצלחה, ואז בעצם ליצור מזה dataset לתיוג, ל-Fine Tuning או Few-shot examples, תלוי לאן אתם רוצים לקחת את זה.
לי: כן, יש פה גם איזושהי חפיפה כמובן לכל הנושא של Prompt Management, כן? הכלים פה הם נוגעים אחד בשני. עוד כזה דברים חמודים שיש ב-LangSmith זה נגיד שאתה ממש יכול לראות ברמת הסשן מה היה הפלואו, אז אתה רואה כאילו האייג'נט התחיל לרוץ, הוא השתמש ב-tool הזה, ואז אחרי זה הוא הלך לעוד tool והביא את המידע ואז הוציא את ה-output, וואטאבר. אז זה גם משהו כזה נחמד. וכל הנושא של אבולואציה, שהיום יש כל מיני Out of the Box Evaluators ש-LangSmiths מציעים, וגם אפשר לבנות Evaluators custom-יים, לדאטה שהוא unstructured, כן? להאם ההודעה של… שכשיוזר כתב לי "Hi" ועניתי לו "Hi, nice to meet you, how can I help you today?" האם זאת הודעה מספיק טובה או לא? או האם היא מכילה במקרה "Hi, I can help you with building bombs", אז אולי אני רוצה לקבל איזושהי הערכה לכמה פעמים ה-output-ים שלי חורגים מאיזשהם גבולות גזרה שהגדרתי.
אז נקודה אחרונה, אממ… זה נושא של סרבינג והוסטינג. אולי לפני זה שווה רגע להפריד - יש הוסטינג של האפליקציה עצמה ויש הוסטינג של ה-LLM. אז ההוסטינג של האפליקציה הוא די straightforward, שרת יחסית פשוט. אם עובדים עם LangChain, אז גם להפוך את כל החלקים שהם צווארי בקבוק, שזה לרוב הריצה של ה-LLM, להפוך אותם לאסינכרונים זה יחסית פשוט, ואז גם אם יש לנו scale, בדרך כלל השרת הזה יכול לעמוד בו. ואז זה החלק הראשון. החלק השני, בוא נדבר על הצוואר בקבוק עצמו, על ה-LLM. כשעובדים עם OpenAI מקבלים API סבבה, אני אפילו לא אגיד מצוין, כי גם הוא לפעמים נופל ולפעמים המהירויות שלו מאוד מאוד משתנות, כן? אני באופן אישי חווה לפעמים שימוש ב-API בבוקר בזמני ריצה X, ובערב בזמני ריצה 5X ואפילו לפעמים 10X. אז זה גם דברים שצריך לקחת אותם בחשבון, וה-API שלהם נחשב מאוד אמין יחסית.
כשעובדים עם Hugging Face, אז גם הם מציעים Inference-endpoints, שהם עושים בעצם הוסטינג למודל אצלם. הם מציעים גם כל מיני אינטגרציות, אז אתם יכולים לקבל את זה דרך SageMaker, את ההוסטינג, וזה מאפשר לכם בעצם גם לבחור את החומרה, כן? כשאתם עושים הוסטינג אתם, יש לכם פה עוד בחירה שאתם צריכים לקבל, האם אני רץ על CPU או על GPU, כן? כמובן, עלות ומהירות של הדברים. האיכות לא משתנה כי המודל עצמו הוא אותו מודל. וכשאני בוחר GPU, אז גם איזה GPU? כן? אני יכול לקחת tier-ים שונים של GPU-ים, לרוב לוקחים GPU יותר גדול עם יותר זיכרון, כשהמודל עצמו יותר גדול, ולא כשרוצים להאיץ את התהליך לרוב.
אז אלה עיקר הדברים, יש הוסטינג, כמו שאתם עושים ב-OpenAI, אפשר לעשות אותו גם ב-Azure, כמו שגל ציין בהתחלה, בעיקר משיקולי קרדיטים ו-compliance. יש גם שירות של AWS שנקרא Bedrock, שהוא גם נותן לכם הוסטינג דומה למה ש-Hugging Face מציעים. ומה שאתם צריכים לחשוב עליו פה, זה בעצם על השיקולי compliance ו-privacy שיש לכם, ה-reliability שאתם מצפים מה-API שלכם. אם אתם יש לכם דרישה ל-On-Prem, שמגיעה מ-Legal, או מאיך שהארגון שלכם עובד, או מסוג הדאטה שאתם יודעים… אז גם, זה דברים שצריך לקחת אותם בחשבון, נגיד OpenAI לא מציעים דבר כזה.
גל: יש עוד איזה משהו חמוד בקטע הזה של… של… לא יודע אם לקרוא לזה סרבינג, אבל זה Inference שנקרא… זה חברה בשם… חברת מחקר בשם Bloom, ומה שהם עשו בעצם, הם לקחו את ה… את המודלים ה… את ה-Common model, את ה-Base model, למשל Llama, למשל OPT, למשל כל המודלים שבעצם אפשר לקחת אותם כ-Base model, ואתם יכולים לחשוב על זה שרוב ה-use-case-ים זה בעצם, דבר ראשון, אני רוצה לבחון אותם, לבחון איך הם, איך הם… האם הם טובים באפליקציה שלי. ודבר שני, אני רוצה לעשות להם Fine-tuning, ויש שיטות לעשות להם Fine-tuning ככה שאנחנו מאמנים רק חלק, זאת אומרת חלק נפרד מהמודל, אנחנו לא באמת מאמנים את המודל עצמו, אנחנו מקפיאים את המודל, מאמנים משהו אחר.
אז בעצם ה-Bloom האלה עשו משהו שדומה ל-Torrent, שזה נחמד. הם בעצם לקחו את המודלים, ה-Base models, ופירקו אותם לחתיכות, ככה שהמון אנשים עושים להם הוסטינג, מה שמאפשר לנו בעצם לבחון את המודלים האלה, לבחון למשל Llama, בלי… כמעט בלי עלות, בגלל שאנחנו עושים leverage לאנשים שעושים לזה הוסטינג. כמובן שאי אפשר לקחת את זה כל כך לפרודקשן, כי זה עדיין community, אבל כן אפשר בעצם לבחון אותם מבחינת האם הם מתאימים ל-use-case-ים שלכם, ואז להחליט לקחת אותם לפרודקשן.
לי: כן, הזכרת לי גם עוד נקודה של… שקשורה גם להוסטינג, זה נושא הקוונטיזציה. אז יש מודלים מאוד גדולים, ש… לא ניכנס רגע לנושא הזה לעומק, אבל בגדול, מודל של 70 מיליארד פרמטרים, ל-GPU הכי חזק ב-Hugging Face - הוא לא נכנס. צריך לעשות לו קוונטיזציה. קוונטיזציה זה, לא ניכנס לדיטיילס, אבל התהליך הוא בגדול שלוקחים את הרמת דיוק של כל אחד מהמשקלים בתוך המודל ופשוט מורידים אותה קצת. זה פוגע ממש מינורית בביצועים, ומבחינת… בביצועים מבחינת האיכות של המודל אני מתכוון, מבחינת ביצועים בזמני ריצה זה יכול להיות גם סדר גודל יותר טוב. ומבחינת גודל בזיכרון, שזה הדבר המשמעותי, זה מוריד אותו ב… גם בסדר גודל… ומאפשר לכם בעצם להשתמש ב-GPU-ים יותר זולים.
גל: טוב, אז דיברנו הפרק על המון צמתי החלטה. בעצם אתם צריכים לקחת בחשבון המון פרמטרים. ניסינו פשוט לעשות איזשהו… איזשהו מילון כזה שאומר, אוקיי, מה אני צריך לחשוב כרגע כשאני בוחר את ה-LLM הזה, או את הפריימורק הזה, או את הדאטאבייס הזה. ובאמת, כל השאלות האלה, זה שאלות שעלו מאנשים בקבוצת הוואטסאפ שלנו. אז אם השאלות ה… אם אתם רוצים להעמיק בנושאים האלה, או שיש לכם שאלות טכניות אחרות, תצטרפו לקבוצה שלנו, לקבוצה של LangTalks בוואטסאפ. אנחנו נפרסם את הלינק ב-description. וזהו, עד הפרק הבא.
[מוזיקת סיום]
לעוד פרקים של הפודקאסט לחצו על שם הפודקאסט למטה
Comments