הערה

רוב הכשלים ב-RAG מתחילים במסמכים

Chunking, כותרות, metadata, מבנה parent-child, reranking ו-QA לקורפוס במערכות RAG.

12 בפברואר 20263 דק׳ קריאהמאת Alex Chernysh

RAGRetrievalData QualityAI Engineering

לקפוץ לחלק

כשמערכת RAG נכשלת, המודל בדרך כלל מקבל את האשמה. למסמכים הייתה בדרך כלל מקדמה על הכישלון.

1. מסמך הוא יחידת מוצר

מסמכים במערכת RAG הם לא רק חומר גלם. הם חלק מהמוצר.

לכן לכל מסמך צריך להיות לפחות:

בלי זה, גם embedding טוב נשאר עם חומר קלט חלש.

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

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

Titles טובים ומטא-דאטה סבירים מקטינים צורך ב-query gymnastics.

הם עוזרים ל:

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

הרבה קורפוסים מרוויחים ממבנה parent-child:

היתרון הוא שאפשר:

זה דפוס טוב במיוחד במסמכים ארוכים, פוליסות, חוזים ורגולציה.

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

בדיוק שם sentence-window retrieval או reranking טובים יכולים לעזור.

אבל צריך לזכור: אלה שכבות polishing. הן לא תחליף לקורפוס מסודר.

קורפוס צריך לעבור QA בדיוק כמו קוד.

אני מחפש לפחות:

אם לא עושים את זה, הרבה “בעיות RAG” הן פשוט data hygiene עם marketing יפה יותר.

קורפוס טוב לא רק מאפשר retrieval. הוא הופך אותו לפחות דרמטי.

בפועל זה אומר:

כשהיסודות האלה תקינים, גם שאר המערכת נהיית רגועה יותר.

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

אם לא, כדאי להתחיל שם. זה פחות זוהר, וגם הרבה יותר יעיל.