בירור | יצירת אלגוריתם/כללים למנוע חיפוש
-
קלוד טוען שמנוע מוכן לא יעזור כאן, כי הדרישות שלי כאן שונות...
המנועים לא יעזרו לתיקון שגיאות כמו שף חתנים במקום שס חתנים.
רעיון לגיטימי, ויש כמה מנועים כאלה. אבל לדעתי מנוע חיפוש לא היה מציל את השיחה של "ש"ס חתנים", כי הבעיה שם לא הייתה בחיפוש.
מה כבר קיים היום. הקטלוג מריץ מנוע חיפוש שנכתב כאן (packages/core/hebrew.js). הוא מנרמל עברית, וסולח לשגיאות לפי מרחק עריכה, כשהסף תלוי באורך המילה. מעליו, בערוץ הטלפוני, יש מפל ניסיונות (apps/voice/facts/book-search.js): טבלת תיקונים לשיבושי תמלול, מילים נרדפות, הסרת מילים תיאוריות ושער כיסוי. בפועל זה מנוע קטן עם סובלנות לשגיאות, בדיוק מה שמנוע מוכן היה נותן.
מה מנוע מוכן היה עושה עם השאילתות מהשיחה:
שאילתה למה זה לא היה עוזר
"שש חתנים" / "שף חתנים" מנועים כמו Meilisearch ו-Typesense לא סולחים על טעות במילים קצרות. כברירת מחדל, תיקון שגיאה מתחיל רק מ-5 אותיות. "שש"→"שס" זו אות אחת מתוך שתיים, ושום מנוע לא יתקן אותה, ובצדק.
"שוקאמין" זה שיבוש של צליל, לא של כתיב. אף מנוע טקסט לא יחבר את זה ל-"ש"ס חתנים".
המנוע כן יכול להשמיט מילה שלא נמצאה. ב-Meilisearch יש לזה הגדרה מובנית, matchingStrategy: last. אבל זה בדיוק "לנסות שוב בלי המילה הקצרה", שדחית כתיקון שמותאם להדגמה. זה אותו פתרון, רק עטוף בספרייה.השיבוש קורה לפני החיפוש: המתמלל שומע ארמית וראשי תיבות לא נכון. את זה מתקנים במקום אחר:
הטיית המתמלל לשמות שבקטלוג. זה כבר קיים חלקית ב-asr-vocab.
שם מדובר או מפתח פונטי לכל מוצר. "שס", "שַׁס" ו"שש" יקבלו מפתח צליל אחד.
התאוששות בשיחה: אחרי שני כישלונות הסוכן מציע קטגוריה או מבקש לאיית, ולא שואל "בטוח שזה השם?".
איפה מנוע מוכן כן מתאים: ביעד ארוך הטווח של מנוע מענה לכל סוג מוצר. שם דירוג, סינון לפי שדות וקטלוגים גדולים זה עבודה שלא כדאי לכתוב בעצמנו. אפשרויות עם רישיון שמתיר שימוש מסחרי:MiniSearch (MIT) או Orama (Apache 2.0): ספרייה שרצה בתוך התהליך, בלי שרת נוסף. ל-4,077 ספרים זה מספיק לגמרי.
Meilisearch: הליבה ברישיון MIT. זה שרת נפרד, כלומר תהליך נוסף שצריך לסנכרן מול SQLite.
Typesense (GPL-3): מותר להריץ אותו כשירות מסחרי. גם הוא שרת נפרד.
SQLite FTS5: כבר קיים במסד, אבל אין בו סובלנות לשגיאות.
ההמלצה שלי: לא להחליף מנוע עכשיו כתיקון לבעיה הזו. במקום זה להכריע לפי מדידה, שזה גם הצעד הראשון בהצעה לשיטה שממתינה לך:לאסוף מהלוגים של השיחות קורפוס של שאילתות אמיתיות: מה המתמלל שמע, ואיזה ספר הלקוח התכוון.
להריץ את הקורפוס מול המנוע הקיים ומול מנוע מוכן אחד, למשל MiniSearch, ולספור תוצאה נכונה, "לא נמצא" ותוצאה שגויה.
לבחור לפי המספרים."שש חתנים" / "שף חתנים" מנועים כמו Meilisearch ו-Typesense לא סולחים על טעות במילים קצרות. כברירת מחדל, תיקון שגיאה מתחיל רק מ-5 אותיות. "שש"→"שס" זו אות אחת מתוך שתיים, ושום מנוע לא יתקן אותה, ובצדק.
גם המנוע שאתה תעשה לא יכול לתקן את זה ובצדק, ולכן צריך פתרונות אחרים שאינם בתוך החיפוש עצמו, זה לא סיבה לא להשתמש במנוע בחיצוני, אם כי יותר מתאים להשתמש כאן בספריה פנימית, לא נראה לי שיש צורך להריץ תהליך נוסף חיצוני
-
קלוד טוען שמנוע מוכן לא יעזור כאן, כי הדרישות שלי כאן שונות...
המנועים לא יעזרו לתיקון שגיאות כמו שף חתנים במקום שס חתנים.
רעיון לגיטימי, ויש כמה מנועים כאלה. אבל לדעתי מנוע חיפוש לא היה מציל את השיחה של "ש"ס חתנים", כי הבעיה שם לא הייתה בחיפוש.
מה כבר קיים היום. הקטלוג מריץ מנוע חיפוש שנכתב כאן (packages/core/hebrew.js). הוא מנרמל עברית, וסולח לשגיאות לפי מרחק עריכה, כשהסף תלוי באורך המילה. מעליו, בערוץ הטלפוני, יש מפל ניסיונות (apps/voice/facts/book-search.js): טבלת תיקונים לשיבושי תמלול, מילים נרדפות, הסרת מילים תיאוריות ושער כיסוי. בפועל זה מנוע קטן עם סובלנות לשגיאות, בדיוק מה שמנוע מוכן היה נותן.
מה מנוע מוכן היה עושה עם השאילתות מהשיחה:
שאילתה למה זה לא היה עוזר
"שש חתנים" / "שף חתנים" מנועים כמו Meilisearch ו-Typesense לא סולחים על טעות במילים קצרות. כברירת מחדל, תיקון שגיאה מתחיל רק מ-5 אותיות. "שש"→"שס" זו אות אחת מתוך שתיים, ושום מנוע לא יתקן אותה, ובצדק.
"שוקאמין" זה שיבוש של צליל, לא של כתיב. אף מנוע טקסט לא יחבר את זה ל-"ש"ס חתנים".
המנוע כן יכול להשמיט מילה שלא נמצאה. ב-Meilisearch יש לזה הגדרה מובנית, matchingStrategy: last. אבל זה בדיוק "לנסות שוב בלי המילה הקצרה", שדחית כתיקון שמותאם להדגמה. זה אותו פתרון, רק עטוף בספרייה.השיבוש קורה לפני החיפוש: המתמלל שומע ארמית וראשי תיבות לא נכון. את זה מתקנים במקום אחר:
הטיית המתמלל לשמות שבקטלוג. זה כבר קיים חלקית ב-asr-vocab.
שם מדובר או מפתח פונטי לכל מוצר. "שס", "שַׁס" ו"שש" יקבלו מפתח צליל אחד.
התאוששות בשיחה: אחרי שני כישלונות הסוכן מציע קטגוריה או מבקש לאיית, ולא שואל "בטוח שזה השם?".
איפה מנוע מוכן כן מתאים: ביעד ארוך הטווח של מנוע מענה לכל סוג מוצר. שם דירוג, סינון לפי שדות וקטלוגים גדולים זה עבודה שלא כדאי לכתוב בעצמנו. אפשרויות עם רישיון שמתיר שימוש מסחרי:MiniSearch (MIT) או Orama (Apache 2.0): ספרייה שרצה בתוך התהליך, בלי שרת נוסף. ל-4,077 ספרים זה מספיק לגמרי.
Meilisearch: הליבה ברישיון MIT. זה שרת נפרד, כלומר תהליך נוסף שצריך לסנכרן מול SQLite.
Typesense (GPL-3): מותר להריץ אותו כשירות מסחרי. גם הוא שרת נפרד.
SQLite FTS5: כבר קיים במסד, אבל אין בו סובלנות לשגיאות.
ההמלצה שלי: לא להחליף מנוע עכשיו כתיקון לבעיה הזו. במקום זה להכריע לפי מדידה, שזה גם הצעד הראשון בהצעה לשיטה שממתינה לך:לאסוף מהלוגים של השיחות קורפוס של שאילתות אמיתיות: מה המתמלל שמע, ואיזה ספר הלקוח התכוון.
להריץ את הקורפוס מול המנוע הקיים ומול מנוע מוכן אחד, למשל MiniSearch, ולספור תוצאה נכונה, "לא נמצא" ותוצאה שגויה.
לבחור לפי המספרים. -
"שש חתנים" / "שף חתנים" מנועים כמו Meilisearch ו-Typesense לא סולחים על טעות במילים קצרות. כברירת מחדל, תיקון שגיאה מתחיל רק מ-5 אותיות. "שש"→"שס" זו אות אחת מתוך שתיים, ושום מנוע לא יתקן אותה, ובצדק.
גם המנוע שאתה תעשה לא יכול לתקן את זה ובצדק, ולכן צריך פתרונות אחרים שאינם בתוך החיפוש עצמו, זה לא סיבה לא להשתמש במנוע בחיצוני, אם כי יותר מתאים להשתמש כאן בספריה פנימית, לא נראה לי שיש צורך להריץ תהליך נוסף חיצוני
-
@עידו300 זה כי הוא מתעקש שיש קשר בין השניים, אין קשר בין חיפוש בעמודות שונות לבין תיקון שגיאות כתיב.
זה שני אלגוריתמים שונים לגמרי.@עידו300 זה כי הוא מתעקש שיש קשר בין השניים, אין קשר בין חיפוש בעמודות שונות לבין תיקון שגיאות כתיב.
זה שני אלגוריתמים שונים לגמרי.אבל הם צריכים לעבוד ביחד, כי הרי "שש" זה לא שגיאת כתיב, זו מילה נכונה רק שהAI תמלל את החיפוש לא נכון (או שהמחפש זכר את השם בערך), צריך משהו שכן ימצא את השינויים האלו וכן ידע להתאים אותם נכון.
-
ולכן צריך פתרונות אחרים שאינם בתוך החיפוש עצמו
כמו? איזה פתרון?
כמו? איזה פתרון?
כמו ש @המלאך כבר כתב וגם אתה הזכרת, לדייק יותר את הזיהוי, ותנסות להתאים אותו למילים הקיימות וכו'
אבל הם צריכים לעבוד ביחד, כי הרי "שש" זה לא שגיאת כתיב, זו מילה נכונה רק שהAI תמלל את החיפוש לא נכון (או שהמחפש זכר את השם בערך), צריך משהו שכן ימצא את השינויים האלו וכן ידע להתאים אותם נכון.
מנועי חיפוש לא מזהים שגיאות כתיב בגלל שהם שגיאות, אלא ע"י אליגוריתמים למשל כמו לוינשטיין שהזכרת, אין נפק"מ אם המילה שכתבו בפועל קיימת גם היא
-
כמו? איזה פתרון?
כמו ש @המלאך כבר כתב וגם אתה הזכרת, לדייק יותר את הזיהוי, ותנסות להתאים אותו למילים הקיימות וכו'
אבל הם צריכים לעבוד ביחד, כי הרי "שש" זה לא שגיאת כתיב, זו מילה נכונה רק שהAI תמלל את החיפוש לא נכון (או שהמחפש זכר את השם בערך), צריך משהו שכן ימצא את השינויים האלו וכן ידע להתאים אותם נכון.
מנועי חיפוש לא מזהים שגיאות כתיב בגלל שהם שגיאות, אלא ע"י אליגוריתמים למשל כמו לוינשטיין שהזכרת, אין נפק"מ אם המילה שכתבו בפועל קיימת גם היא
-
@ע-ה-דכו-ע @המלאך אז מה אתם מציעים בעצם?
לממש מרחק לוינשטיין? בעקרון זה כבר קיים ועדיין לא מוצא את התוצאות הנ"ל...איך אני יכול לדעת אם המנוע חיפוש שהוא כתב לי מספיק טוב או שכדאי לשנות לאחד מוכן כבר?
-
@עידו300 אני אומ לשנות את הדרך פיתוח.
לחלק לשני פיתוחים שונים.
נסה ותראה ניפלאות, אפילו רק קלוד -
@עידו300 1 -מנוע חיפוש רגיל (שאמור לכלול גם חיפוש במספר עמודות שונות),
2 -אלגוריתם לזיהוי מילות החיפוש המדוייקות הנצרכות, (לווינשטיין וכו׳) -
תראו מה יש עד עכשיו, בקשתי מקלוד שיתמצת בשביל להראות לחבר שיחווה דעתו.
לדעתי עשה שם שטויות, אבל אני לא מבין בזה.
בעקרון הוא חילק את זה ל-4 לא ל-2.
-
-
-
שלום! נראה שהשיחה הזו מעניינת אותך, אבל עדיין אין לך חשבון.
נמאס לכם לגלול בין אותם הפוסטים בכל ביקור? כשנרשמים לחשבון, תמיד תחזרו בדיוק למקום שבו הייתם קודם, ותוכלו לבחור לקבל התראות על תגובות חדשות (בין אם במייל, ובין אם בהתראת פוש). תוכלו גם לשמור סימניות ולפרגן ב-upvote לפוסטים כדי להביע הערכה לחברי קהילה אחרים.
בעזרת התרומה שלך, הפוסט הזה יכול להיות אפילו טוב יותר 💗
הרשמה התחברות