הטמעת מערכת השלמת טקסט (Text Completion)

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מדוע השלמה אוטומטית של טקסט נשברת על נתונים אמיתיים

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

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

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

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

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

מה נותנת השלמה אוטומטית מנוהלת של טקסט במוצר

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

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

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

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

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

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

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

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

אפשרויות מימוש של השלמות בזמן הקלדה: במה הן נבדלות

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

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

שירות חיצוני מכסה מגוון רחב של תרחישים בלי תשתית משלכם, אבל מוציא את הנתונים מחוץ להיקף ומצרף בקשת רשת לכל הקלדה.

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

איך לבחור גישה

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

הטמעה שלב אחר שלב: מביקורת נתונים ועד מסירה

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

  1. ביקורת נתונים ודרישות. בוחנים את הנפח והאחידות של הקורפוס, את שיעור הכפילויות והזבל השירותי, את קיומו של תיוג ותיקונים של «אדם בתוך המעגל». מתעדים את רשימת התרחישים והמגבלות — מניסוחים אסורים ועד לנתונים אישיים שאסור שייכנסו למערך האימון.
  2. סכמת הפתרון. בוחרים גישה: אימון מחדש של מודל קומפקטי על הדומיין או פנייה לשירות חיצוני, עם מטמון להשלמות שכיחות. מגדירים נקודות אינטגרציה, פורמט החלפה והתנהגות כאשר השירות אינו זמין.
  3. הרכבה. מכינים את הקורפוס, מכווננים את המודל, מרכיבים את המעטפת, מוסיפים טלמטריה על כל וריאנט שהוצג והתקבל.
  4. מדדי איכות. קודם מערך אופליין עם תיוג קבוע, אחר כך השוואה על תעבורה חיה: שיעור ההשלמות שהתקבלו, אורך הקטע המוקלד, מספר הביטולים והעריכות של הטקסט שהתקבל.
  5. בדיקת עומס. מריצים פרופיל של בקשות אמיתיות, מודדים את השהיית התגובה בתורים בשיא, ובודקים את ירידת הביצועים: ההשלמות מנותקות, ההקלדה נשארת פעילה.
  6. קבלת הפתרון. משווים את התוצאה לרמת הבסיס לפני ההטמעה לפי המדדים המוסכמים, מאשרים את תקנון העלייה לאוויר ואת סדר החזרה.
  7. מסירה לצוות. מוסרים תיעוד, הרשאות והדרכה למהנדסי הלקוח: כיצד לעדכן את הקורפוס, לקרוא מדדים ולשנות הגדרות בבטחה.

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

קונפיגורציות, סכמות ותקנונים בפלט הפרויקט

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

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

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

מקרה בוחן: איך ההשלמות הפסיקו לעצבן משתמשים

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

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

מה שינינו

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

מה קרה

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

בטקסטים ארוכים מכמה עמודים ההכנה התקצרה בערך בחצי — את האפקט נותנת לא מהירות ההקלדה, אלא היעדר החזרות.

ספקות טכניים לפני תחילת הפרויקט

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

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

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

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

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

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

נדון במשימה ונחזור עם אומדן ותוכנית

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

  • דוגמאות של נתוני קלט והמשכים כמידה — כמה עשרות מקרים אמיתיים מספיקים כדי להבין את סוג המשימה;
  • היכן המערכת חיה: מעגל סגור, ענן או היברידי, ומה נדרש באשר לשמירת היסטוריה;
  • מקורות נתונים לאימון מחדש והאם יש תיוג — או שיהיה צריך לאסוף אותו מאפס;
  • נקודות אינטגרציה: עורך, CRM, פורטל פנימי, אפליקציית מובייל;
  • דרישות למהירות התגובה ולעומס השיא בשעות הפעילות;
  • מי בצד הלקוח מקבל את התוצאה ומאשר את איכות המידה.

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

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

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

מה לעשות אם מחולל ההשלמות כבר הוטמע?

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

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

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

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

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