PageIndex: RAG ללא ווקטורים עם החזרת מסמכים מבוססת חשיבה

נקודה מרכזית

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

מה זה PageIndex?

הריפו PageIndex הוא גישה מהפכנית ל-RAG (Retrieval-Augmented Generation) שחושבת מחדש באופן יסודי איך אנחנו מחזירים מידע ממסמכים. הפרויקט PageIndex פותר את הבעיה של אובדן הקשר והחזרת מידע לא מדויקת שכולנו מתמודדים איתה כשעובדים עם מסמכים ארוכים ומורכבים במערכות RAG מסורתיות מבוססות ווקטורים.

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

הבעיה שכולנו מכירים

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

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

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

איך PageIndex עובד

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

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

הקטע המדליק הוא שקורה בזמן ההחזרה. במקום לחשב ציוני דמיון ווקטורי, PageIndex משתמש במה שנקרא agentic workflow שבו ה-LLM מחשיב את דרכו דרך מבנה העץ. ה-LLM בוחן את הסיכומים ברמה העליונה, מחליט איזה ענף סביר ביותר להכיל את התשובה, צולל לרמה הבאה, מעריך את הסיכומים האלה, וממשיך לנווט עד שהוא מגיע לתוכן הרלוונטי.

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

התחלה מהירה

ככה אנחנו מתחילים עם PageIndex:

# התקנה
pip install pageindex

# שימוש בסיסי
from pageindex import TreeIndexer, ReasoningRetriever

# בניית אינדקס עץ ממסמך
indexer = TreeIndexer()
tree = indexer.build_tree(document_path="report.pdf")

# שאילתה באמצעות החזרה מבוססת חשיבה
retriever = ReasoningRetriever(tree)
result = retriever.query("מה היה גידול ההכנסות ברבעון השלישי?")
print(result.answer)
print(result.reasoning_path)  # מראה את המסלול דרך העץ

דוגמה אמיתית

נגיד שאנחנו מנתחים דוח רווח פיננסי וצריכים למצוא מדדים ספציפיים:

from pageindex import TreeIndexer, ReasoningRetriever

# בניית אינדקס היררכי של דוח הרווח
indexer = TreeIndexer(
    summarization_model="gpt-4",
    preserve_structure=True
)
tree = indexer.build_tree("Q3_earnings_report.pdf")

# שאילתה עם חשיבה
retriever = ReasoningRetriever(
    tree=tree,
    reasoning_model="gpt-4",
    max_depth=5  # עד כמה עמוק לנווט בעץ
)

# ה-LLM יחשיב: "גידול הכנסות כנראה בסעיף תוצאות פיננסיות,
# כנראה בתת-סעיף הכנסות, ספציפית בנתוני רבעון 3"
result = retriever.query(
    "מה היה גידול ההכנסות שנה-על-שנה ברבעון השלישי?"
)

print(f"תשובה: {result.answer}")
print(f"מסלול חשיבה: {result.path}")  # מראה את הניווט
print(f"מיקום מקור: {result.source_reference}")  # מיקום מדויק במסמך

פיצ'רים מרכזיים

• החזרה ללא ווקטורים - בלי Embeddings, בלי חלוקה לחתיכות. המערכת שומרת על מבנה המסמך המקורי ומשתמשת בחשיבת LLM כדי לנווט בו. תחשבו על זה כמו שיש לנו עוזר מחקר AI שיודע איך להשתמש בתוכן עניינים במקום לעשות חיפוש טקסט מלא.
• מבנה עץ היררכי - מסמכים מיוצגים כעצים רב-רמתיים עם סיכומים בכל צומת. זה משמר את הארגון הלוגי והופך את הניווט להסביר - אנחנו יכולים לראות בדיוק איזה מסלול ה-LLM עבר במסמך.
• ניווט מבוסס חשיבה - במקום ציוני דמיון, ה-LLM מחליט באופן אקטיבי לאן להסתכל הבא בהתבסס על כוונת השאילתה ומבנה העץ. זה מה שנקרא agentic workflow מאחורי הקלעים, שבו המודל שולט בתהליך ההחזרה שלו.
• הסבר מלא - כל החזרה מראה את המסלול המלא דרך העץ. אנחנו יכולים לבדוק בדיוק למה המערכת בחרה לנווט לסעיף מסוים, מה שהופך אותה למתאימה לאפליקציות בעלות סיכון גבוה כמו ניתוח משפטי או פיננסי.
• ביצועים מהשורה הראשונה - משיג 98.7% דיוק על FinanceBench, בנצ'מארק מאתגר לשאלות ותשובות על מסמכים פיננסיים. זה מנצח משמעותית גישות RAG ווקטוריות מסורתיות על מסמכים מורכבים ומובנים.

מתי להשתמש ב-PageIndex לעומת אלטרנטיבות

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

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

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

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

בעיניי - האם אשתמש בזה?

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

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

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

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

כדאי לבדוק את הפרויקט: PageIndex ב-GitHub

שאלות נפוצות

מה זה PageIndex?

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

מי יצר את PageIndex?

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

מתי כדאי להשתמש ב-PageIndex?

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

מה האלטרנטיבות ל-PageIndex?

מערכות RAG מבוססות ווקטורים מסורתיות (LangChain עם FAISS/Pinecone/Weaviate) הן אלטרנטיבות מעולות לחיפוש סמנטי על פני אוספי מסמכים גדולים. נשתמש בווקטורים לחיפוש רחב על פני קורפוסים, נשתמש ב-PageIndex לניתוח מדויק בתוך מסמכים מובנים.

מה המגבלות של PageIndex?

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