פורום אוצריא

@pcinfogmach אפשר אולי בכל OCR שיעשו בעתיד לספרים [או לתייג מחדש גם ספרים קיימים] לשמור קובץ נתונים עם מידע כמו סוג הגופן גודל פריסה וכו' ואז לשחזר בטקסט חי ממש דומה למקור [כמובן מי שלא אוהב יוכל לשנות גופן וכו'] מה שיאפשר את כל המעלות ביחד כולל יחודיות לכל ספר

לא ממש באג אבל הצעת שיפור ששנת ההדפסה של הספר תהיה שנה עברית [ או מיספור אבל לבריאת העולם לא למניינם] להרבה ראשונים יש בזה איסור גמור

Spoiler

הצעה למודל AI עבור חיפוש סמנטי - כידוע יש באוצריא מבנה של פירושים וקישורים וכו' שיכול לאפשר לכוונן מודל קיים כמו ברל 3 של דיקטא על המאגר באופן שינתן דירוג התאמה לתרגום\פירוש\קישור\מקורות\ציטוטים [לא יודע האם הכל קיים בDB של אוצריא אולי רק במקור בספריא ]וליצור זוגות חיובים ושלילים וכמובן לחלק את זה לפי פסקאות \קטעים וכו' ויהיה לנו מודל הטמעה נהדר לאינדוקס וקטורי עבר חיפוש סמנטי @arieldaniely
@elie-gambache

@arieldaniely אולי תשתף פעולה עם @המשיב המפתח של http://hameshiv.com/ לצורך דאטה לאימון

הצעת שיפור חשובה לקבוע כללים מתי יש תואר הרב מתי רבי ומתי בכלל בלי שזה שרירותי לגמרי כרגע

@י.-פל. רק מציע למרכז במסך את הכלים והתוספים כמו איתור וכמו חיפוש לשמור על שפה עיצובית אחידה

@יאיר-דניאל כבר העליתי מאז גירסא אחרת קלת משקל מבוססת קוד PS1 התוכנה מבוססת על קוד שכתבתי עוד לאוצריא קדם הDB - אז זה היה מזעזע לכו"ע -עכשיו לי ולעוד זה עדיין מפריע - כרגע הרעיון פשוט מחיקת השדות בDB בהם מאוחסנים התיאורים

@הבל-הבלים זה היה המטרה - אבל הבוט החליט להגיב אז הסברתי

@י.-פל. @pcinfogmach יש לי רעיון בר מימוש לחסכון בגודל הקבצים עבור משתמשי PDF
[אפשר לבנות אותו אולי כתוסף - אבל צריך שהתוכנה תתמוך ברעיון]
הרעיון מבוסס על כך שבשביל לסמן את התוצאות בPDF יש 3 רעיונות
1 לשמור באינדקס מיקומים מדויקים [קואורדינטות]-מה שמגדיל את האינדקס מאוד
2 לשמור רק את העמוד ולהריץ חיפוש מקומי שיסמן את הטקסט [אני מניח מחוסר ידיעה שבזה אוצריא משתמשת]
3 לשמור את האופסט [מספר המילה - מה שעושים בדרך כלל לאינדקס של טקסט - אולי באוצריא עושים גם לטקסט את שיטה 2 ]

אני מציע שאם האינדקס יתמוך לPDF באפשרות 3 אז יהיה ניתן אחרי האינדוקס להריץ מחיקה של הOCR חלקית ולשמור רק את התיבות ללא הטקסט בתוכם - מה שישאיר את המיספור ויאפשר סימון אבל יחסוך הרבה מקום

@otzaria-bot על "חלון או מלא": זה חלון, לא מלא — המנוע חותך עד 800 תווים סביב ההתאמה. אבל מה שחשוב הוא שכשהוא עושה את זה, הטקסט המלא של העמוד כבר אצלו [הוא קורא את השדה המלא ורק אחר כך מריץ את מחולל ה-snippet]. כלומר להחזיר גם את טווח התווים זה כמעט בלי עלות — שדה נוסף בתוצאה, בלי שינוי סכמה, בלי בנייה מחדש.

על המיפוי לפי מספר תו — מקבל, ומדדתי את המחיר: קובץ התיבות עם מפתח אופסט תווים גדל ב-20% גולמי / 53% דחוס [3.68→4.42MB, 0.67→1.03MB]. קטן, ובתמורה חסינות מוחלטת לשינויי טוקניזציה. [אם גם האינדקס עצמו יעבור לאופסטי תווים במקום מספרי מילים זה +17-19% — אבל זה רלוונטי רק להצעה הגדולה.]

שתי הצעות נפרדות, עם קריטריונים שונים:

הצעה קטנה [מה שאנחנו מבקשים עכשיו]: המנוע נשאר כמו שהוא + שדה אחד נוסף [טווח תווים בעמוד] + קובץ תיבות צד [~1MB דחוס לספר] + אופציונלי: מחיקת שכבת ה-OCR [−38% מהקובץ, 28.1→17.5MB]. מקבלים: סימון ישיר בלי סריקה מקומית בכל חיפוש, וקובץ קטן יותר. האינדקס לא נוגעים בו בכלל.

הצעה גדולה [פרויקט נפרד]: גם החלפת האינדקס בעיצוב אופסטים [מילה → אופסטים, הטקסט המלא משוחזר מהאינדקס]. מוסיף חיסכון נוסף — אינדקס של ~2MB במקום הטקסט המלא השמור. אבל זה בנייה מחדש, והמנוע שלכם שומר את הטקסט בכוונה [בשביל ה-snippets] — אז זו החלטה נפרדת לגמרי.

ובונוס לטובת ההצעה הקטנה: מאחר שהטקסט שמור בתוך אינדקס tantivy — מחיקת שכבת ה-OCR לא מסכנת כלום. ה-snippets ממשיכים לעבוד מהאינדקס; הטקסט לא תלוי בקובץ.

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

@הבל-הבלים התוסף הוא למחיקת שכבת הOCR עבור המעוניינים ויצירת קובץ תיבות מקביל - אנחנו לא רוצים לכפות מחיקת שכבתOCR ממי שלא מעוניין הרעיון מתוכנן ככה שיעבוד בכל מקרה