אינטגרציית YandexGPT API: אימות, מודלים, RAG לפי 152-FZ

למה אינטגרציה של YandexGPT נשברת כבר בתחילת הפרויקט

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

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

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

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

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

מה נותנת אינטגרציה של YandexGPT: מהירות תגובה ושיעור כשלים

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

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

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

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

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

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

ניתוב שאילתות

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

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

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

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

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

מה הלקוח מקבל לידיו: סכימות, מדיניות, נהלים

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

תיעוד טכני

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

מסמכים ארגוניים ו-152-ФЗ

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

מקרה בוחן: עוזר תמיכה עונה לפי מאגר ידע פנימי

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

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

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

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

מה שינינו

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

מדדים לפני ואחרי

• תשובה ראשונה: 12 דקות → 2 דקות, כולל זמן בדיקה מול המקור.
• פניות שנסגרו ללא הסלמה לקו השני: 58% → 81%.
• הבהרות חוזרות לאותה שאלה: 31% → 9%.
• כל תשובה מקושרת לקטע ספציפי במאגר — יכולת בדיקה במקום «הנציג אמר כך».

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

במה שונה חיפוש במאגר ידע מאימון נוסף של המודל

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

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

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

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

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

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

כיצד מופרדות הרשאות העובדים?

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

מה מתעד יומן השאילתות?

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

מה לעשות אם ספק המודל לא יתאים?

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

בואו נדון במשימה: מה לשלוח להערכה ותוכנית

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

• תרחיש: 2-3 דוגמאות «שאילתה → תשובה צפויה» וכיצד התוצאה מגיעה למשתמש.
• מקורות ידע: היכן נמצאים מסמכים ונהלים, באיזה פורמט, מי אחראי לעדכניותם.
• נתונים: היקף, תדירות שינויים, האם יש נתונים אישיים ואיזה מצב עיבוד נדרש.
• סביבה: היכן מאוחסן השירות, כיצד בנויות הגישות, האם יש הגבלות על שירותים חיצוניים.
• תפקידים: מי מקבל את התוצאה ומי יקצה זמן לבדיקת תשובות המודל.
• מגבלות: לוחות זמנים להשקה ראשונה, דרישות להגנת נתונים, מה כבר ניסיתם ומדוע לא התאים.
• קריטריונים להצלחה: לפי אילו סימנים תבינו שהפיילוט הצליח.

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

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