Unstructured Data Engineering — הפיכת מסמכים, מיילים וטקסט ל-Data

מאת צוות מדיה דיל · 09.08.2026 · Technology · 8 דק׳

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

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

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

מהו "נתון לא מובנה" בהקשר AI

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

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

שלב הנרמול: מגיוון פורמטים לייצוג אחיד

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

ניקוי רעש בלי לאבד מידע

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

Chunking: חיתוך נכון של תוכן ארוך

מסמכים ותמלולים ארוכים צריכים להיחתך ליחידות קטנות יותר (chunks) לפני שהם מתאימים לעיבוד AI - חלון הקשר מוגבל, ועיבוד יעיל דורש יחידות בגודל סביר. חיתוך נאיבי לפי מספר תווים קבוע שובר משפטים ורעיונות באמצע, ופוגע קשות באיכות כל עיבוד שבא אחר כך. חיתוך סמנטי, שמכבד גבולות טבעיים כמו פסקאות או נושאים, נותן תוצאות טובות משמעותית - הרחבה מלאה במדריך Semantic Chunking.

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

סיווג, תיוג וחילוץ ישויות

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

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

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

אחרי החילוץ, הנתונים בדרך כלל מתפצלים לכמה יעדים: הטקסט המקורי והמנוקה נשמר לאחסון עצמים (object storage) זול, השדות המובנים שחולצו נכנסים לטבלאות SQL רגילות, וה-embeddings לחיפוש סמנטי נכנסים לאינדקס וקטורי. חשוב לשמור קישור ברור (מזהה משותף) בין שלוש הצורות האלה של אותה רשומה מקורית, כדי שאפשר תמיד לחזור מהתוצאה המובנית למקור הגולמי המלא. הרחבה על תכנון השכבות האלה במדריך Database Architecture לעידן AI.

איכות וולידציה של תהליך החילוץ

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

Observability ו-Audit לתהליך החילוץ

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

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

אבטחה ופרטיות בנתונים לא מובנים

מיילים ותמלולי שיחות מכילים לעיתים קרובות מידע אישי מזוהה (שמות, מספרי טלפון, כתובות) שלא תמיד רלוונטי לצורך העסקי של החילוץ. חשוב לתכנן שלב מיסוך (redaction) ייעודי שמזהה ומסתיר מידע רגיש לפני שהוא נשמר בשכבות משניות כמו אינדקס וקטורי, ולוודא שגישה לטקסט המקורי המלא מוגבלת לפי הרשאות ברורות. הטיפול הזה חשוב במיוחד כשהמאגר המעובד משמש בהמשך שכבת RAG שחשופה למשתמשים רבים בארגון - עקרונות אלה מפורטים במדריך RAG Poisoning ובLeast Privilege Agents.

טעויות נפוצות

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

דוגמה מהשטח

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

שאלות נפוצות

מה ההבדל בין הנדסת נתונים לא מובנים ל-RAG רגיל?

הנדסת נתונים לא מובנים היא השלב שקודם ל-RAG - היא מכינה, מנקה ומבנה את הטקסט הגולמי; RAG משתמש בתוצר המוכן הזה לצורך retrieval וגנרציה.

איך יודעים אם החיתוך (chunking) שנבחר טוב?

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

האם צריך לשמור את הטקסט המקורי הגולמי אחרי העיבוד?

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

האם מודל שפה גדול תמיד נדרש לחילוץ מטקסט?

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

איך מודדים איכות חילוץ לאורך זמן?

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

איך מטפלים במידע אישי רגיש בתוך טקסט חופשי?

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

מה עושים כשמקור נתונים חיצוני משנה פתאום את הפורמט שלו?

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

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

תגיות: unstructured data · data engineering · semantic chunking · text extraction · document processing · data pipeline

← חזרה לבלוג · צור קשר