הניוזלטר Legal Engineering 101 של Elly Meenan פרסם ב-22 בספטמבר את החלק השלישי בסדרה על תפקיד ה-Legal Engineer. הפעם זה מילון מעשי: חמישה מושגים הנדסיים שאנשי משפט נתקלים בהם בכל שיחה עם ספק, מוסברים בדימויים יומיומיים ובלי צורך ברקע במדעי המחשב.
חמישה מושגים, חמישה דימויים
הפוסט פותח ב-API, שמתואר כמלצר: מוסרים לו הזמנה, והוא חוזר מהמטבח עם התוצאה. השאלה "יש לזה API?" מתורגמת לשאלה פשוטה יותר: האם הכלים יכולים לדבר זה עם זה אוטומטית. Webhook הוא פעמון הדלת. במקום לרענן שוב ושוב מערכת כדי לבדוק אם חוזה נחתם, המערכת מודיעה כשמשהו קרה.
המושג השלישי הוא MCP, שמתואר כ-USB-C של עולם ה-AI. Anthropic הציגה את הפרוטוקול בנובמבר 2024 כתקן פתוח לחיבורים מאובטחים ודו-כיווניים בין מקורות מידע לכלי AI. בפוסט ההבדל מומחש כך: בלי MCP, המודל מציע נוסח מייל ואתם מדביקים אותו בעצמכם. עם MCP, הוא שולח את המייל, קורא קבצי חוזים ומעדכן כרטיסים במערכת בעצמו.
המושג הרביעי הוא ההבחנה בין אינטגרציה לאוטומציה. אינטגרציה היא הצנרת שמחברת שתי מערכות. אוטומציה היא הפעולה שמתבצעת כשמשהו מפעיל אותה, למשל עדכון רשומה ב-CRM והודעה בערוץ צוות כשחוזה נחתם. בין הכלים שמוזכרים: Zapier ו-n8n. על מבחן פשוט לחלוקת עבודה בין אוטומציה לבין מודל שפה מאותו ניוזלטר כתבנו באוגוסט.
אבני הבניין של תהליך סוכני
החלק החמישי מציע מודל לפירוק כמעט כל תהליך עבודה מבוסס AI לחמישה רכיבים. הסוכן הוא המתזמר, שקורא את הבקשה, מזהה אותה ובוחר מה להפעיל. המיומנויות (Skills) הן הוראות ביצוע למשימות מוגדרות, כמו סימון שינויים בחוזה או העברת סוגיה לבן אדם. המחברים וערוצי הקליטה מכניסים עבודה דרך API ו-Webhook ומחזירים תוצאות דרך MCP. ה-Playbooks והמאגרים, כמו עמדות נסיגה וספריות סעיפים, קובעים מה המערכת יודעת. הפרומפט הוא הטריגר, מה שמבקשים בפועל.
הדוגמה המרכזית בפוסט נשענת על Wordsmith, פלטפורמת AI למחלקות משפטיות בחברות: בקשה נכנסת מ-Jira עם הקבצים המצורפים, Wordsmith מסמן שינויים בחוזה לפי Playbook מותאם, והחוזה המסומן חוזר ל-Jira דרך מחבר ייעודי. הפוסט אינו מציין זיקה של המחבר לספק כלשהו. גישה דומה, שבה העבודה נכנסת לסוכן ישירות מהכלי שבו היא נוצרת, תיארנו בטקסט על AI משפטי בלי מסך משלו.
כללי עבודה עם פרומפטים
החלק המעשי האחרון עוסק בכתיבת הוראות. בין ההמלצות: לשים את הכללים הקריטיים בתחילת ההנחיה ובסופה, להורות למודל לשאול שאלות הבהרה כשהוא לא בטוח, להראות דוגמה במקום לתאר מילים עמומות כמו "אגרסיבי", ולבקש קודם את הנימוק ורק אחריו את התוצר כדי לתפוס טעויות. עוד מומלץ לשנות משתנה אחד בכל פעם, לנהל גרסאות של פרומפטים כמו קוד, ולבדוק אותם על קלט אמיתי ומבולגן, עם שגיאות כתיב ובקשות עמומות, כי מקרי מבחן נקיים תמיד עוברים.
לפי הפוסט, מודלים שונים מגיבים אחרת לאותה הנחיה, ולכן מעבר בין מודלים מחייב בדיקה מחדש. החלק הבא בסדרה, כך נכתב, יעבור מתיאוריה לבנייה בפועל. על חמשת סוגי ה-Legal Engineer שמיפתה אלי מינן כתבנו בספטמבר.
עוד בנושא
- לא כל שלב צריך מודל: מבחן פשוט לחלוקת עבודה בין אוטומציה ל-LLM בתהליך משפטי
- חמישה תפקידים תחת שם אחד: מה עושה בפועל Legal Engineer
- AI משפטי בלי מסך משלו: עבודה שנכנסת לסוכן ישירות מ-Slack, Salesforce וטפסים
- מחקר INSEAD והרווארד: חברות שנבנו סביב AI קטנות ב-25% ומעסיקות פחות עובדי כניסה