דלג לתוכן הראשי
חזרה לבלוג

Drupal

ארכיטקטורת RAG ב-Drupal: מה לבנות ומה להעביר לניהול שירות

מפו את Search API, חלוקת התוכן, embeddings, מסדי נתונים וקטוריים, LLM, ציטוטים ובקרות גישה ב-Drupal — והחליטו מה לבנות ומה לנהל.

Founder, Achla AIMichael Shamanoff
פורסם
עודכן

9 דקות קריאה

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

ארכיטקטורת RAG ב-Drupal היא הרבה יותר מצ׳אטבוט. פתרון שנבנה בתוך Drupal זקוק בדרך כלל לחילוץ תוכן, חלוקה למקטעים, embeddings, אחזור וקטורי, הגדרת Search API, מודל LLM, ציטוטים, בדיקות גישה, משימות רענון, ממשק ותפעול. שירות מנוהל לאתר ציבורי מעביר כמה מן השכבות אל מחוץ ל-Drupal; הגבול הנכון תלוי בגישה לנתונים ובשאלה מי אחראי לכשלים.

Michael Shamanoff Founder, Achla AI למי: בעלי אתרי Drupal, ארכיטקטים ומיישמים שבוחנים חיפוש סמנטי או תשובות עם מקורות. כיצד: על בסיס דפי הפרויקטים הרשמיים של Drupal וקובצי המוצר העדכניים של Achla שנבדקו ב-3 באוגוסט 2026, וכן מטריצת אחריות וכרטיס ניקוד לפיילוט שנוצרו במיוחד. נעשה שימוש ב-AI לסיוע בכתיבה; טענות עובדתיות מהותיות ממופות במאגר המקורות הנלווה. מדוע: מדריכי התקנה מפרטים רכיבים, אך מקבלי החלטות צריכים לדעת גם מי מפעיל כל שכבה, כיצד היא עלולה להיכשל ואילו דרישות פוסלות מסלול מנוהל המבוסס על סריקת אתר ציבורי.

ארכיטקטורת RAG ב-Drupal, שכבה אחר שכבה

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

תהליך האינדוקס: מתוכן למקטעים ניתנים לאחזור

  1. בחרו ישויות, שדות ומצבי תצוגה של Drupal שמכילים חומר מקור שימושי.
  2. חלצו את הטקסט תוך שמירת הזהות, השפה, כתובת ה-URL, מטא-נתוני הגישה והאותות לעדכון או למחיקה.
  3. חלקו תוכן ארוך למקטעים עם די הקשר כדי לשמור על משמעותם.
  4. צרו embeddings ואחסנו אותם במערכת backend שתומכת בווקטורים.
  5. עדכנו, החליפו או מחקו רשומות כאשר התוכן ב-Drupal משתנה.

הפרויקט הרשמי AI Search משלב embeddings וקטוריים עם Search API ומתעד backend וקטורי, חלוקת תוכן, ספי ציון, בדיקות גישה לישויות לאחר השאילתה, חיפוש היברידי ושילוב RAG. אלה אבני בניין, לא מודל תפעול מלא.

תהליך השאילתה: משאלה לתשובה עם ציטוטים

  1. המירו או נתבו את השאלה לשיטת האחזור שנבחרה.
  2. אחזרו מקטעים מועמדים והפעילו ספים, מסננים או היגיון של חיפוש היברידי.
  3. הרכיבו הקשר עבור ה-LLM בלי לאבד את זהות המקור או את מגבלות הגישה.
  4. צרו תשובה או תוצאה ריקה וכנה.
  5. הציגו ציטוטים ורשמו מספיק ראיות כדי לאבחן את האחזור בנפרד מן היצירה.

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

מה Search API עושה — ומה הוא אינו עושה לבדו

Search API הוא מסגרת החיפוש הניתנת להרחבה של Drupal. הוא מגדיר אינדקסים ועובד עם backends, שדות, מעבדים, Views, מסננים ופאות חיפוש. לבדו הוא אינו בוחר מודל embedding, אינו מפעיל כל backend, אינו מרכיב prompt ל-LLM, אינו יוצר תשובה, אינו מעצב ממשק צ׳אט ואינו מעריך עד כמה התשובה מעוגנת במקורות.

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

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

מצבם הנוכחי של פרויקטי Drupal חייב להשפיע על החלטת הסיכון

תוויות גרסאות וכיסוי אבטחה משתנים, לכן רעננו את הטבלה לפני אישור אנושי ושוב לפני כל החלטת יישום. הנתונים הבאים נצפו בדפים הרשמיים ב-Drupal.org ב-3 באוגוסט 2026.

פרויקטמצב הגרסה שנצפהמצב כיסוי הודעות האבטחה
Search API8.x-1.41, גרסה יציבה עבור Drupal 10.3/11הגרסה היציבה מכוסה במדיניות הודעות האבטחה של Drupal.
AI Search2.0.0-alpha2 ו-1.3.0-alpha4; לפי הדף אין גרסה יציבה נתמכתגרסאות יציבות מכוסות, אך לא הייתה גרסה יציבה נתמכת; הגרסאות הרשומות הן alpha.
RAG Search1.0.5, בלי סיומת alpha/betaהפרויקט מציין במפורש שאינו מכוסה במדיניות.
Drupal as RAG1.0.0-alpha5הפרויקט מציין במפורש שאינו מכוסה במדיניות.
AI RAG Search Chat1.0.7, בלי סיומת alpha/betaהפרויקט מציין במפורש שאינו מכוסה במדיניות.

מספר 1.0.x אינו תחליף לכיסוי אבטחה. בדקו בנפרד בגרות, תחזוקה, גרסאות Drupal, תלות בספקים ומעמד לפי מדיניות האבטחה.

מסלול בנייה עצמית: הרכיבים שהצוות שלכם חייב להפעיל

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

Drupal as RAG מדגים מסלול אחר המשתמש ב-Drupal 11, ב-PostgreSQL עם pgvector וב-Ollama במארח מקומי או ברשת. הגרסה שנצפתה הייתה alpha ומחוץ לכיסוי, ולכן זהו מבנה לדוגמה ולא המלצה.

שכבהתפקידבעלים בבנייה עצמיתבעלים במסלול מנוהלסימן לכשלבדיקת קבלה מזעריתהסתייגות נתונים/גישה
חילוץלבחור ולעבד תוכן מקורצוות Drupal/תוכןמפעיל הסורקדפים חסרים או פגומיםלהשוות מקורות מאונדקסים למלאי מאושראסור ששדות פרטיים ידלפו לאינדקס ציבורי.
חלוקה ו-embeddingsליצור ייצוגים ניתנים לאחזורמהנדס AI/חיפושמפעיל השירותrecall חלש או אובדן הקשרסט אחזור של מונחים מדויקים וניסוחים חלופייםהחלפת ספק או מודל עשויה לשנות תוצאות.
אחזור וקטורילהחזיר מקטעים רלוונטייםבעל החיפוש/backendמפעיל השירותמועמדים לא רלוונטיים או ריקיםלרשום מקורות וציונים לפני היצירהמסננים ומטא-נתוני גישה חייבים להישמר.
Prompt ו-LLMלייצר ניסוח מוגבלבעל יישום ה-AIמפעיל השירותתשובה לא נתמכת או בטוחה מדימקרי תשובה ידועה, עמומה וחסרההקשר שאוחזר אינו מבטיח ניסוח נכון.
ממשק וציטוטיםלהציג תשובה וראיותצוות Drupal/frontendמפעיל הווידג׳ט/שירותקישורים שבורים או מומצאיםלפתוח כל ציטוט; לבדוק מקלדת וניידהציטוט חייב לזהות את המקור שאוחזר בפועל.
רענון ומחיקהלשמור על התאמת האינדקסבעל התורים/תפעולמפעיל הסורק/אינדקסתוכן ישן או מחוק נשארלערוך ולמחוק דף בדיקה ולצפות באינדקסביטול cache ומחיקה זקוקים לבעלים מפורש.

הפשרה הרחבה יותר בין שליטה בתשתית לתפעול מנוהל מפורטת ב-חיפוש AI ארגוני לעומת בנייה עצמית.

מסלול מנוהל: אילו שכבות עוברות אל מחוץ ל-Drupal

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

קובצי המוצר של Achla שנבדקו מתארים מחבר ל-Drupal 10/11 המופץ באמצעות Composer, מטריצת אימות ל-PHP 8.3 ועדכונים אוטומטיים שסומנו כזמינים בבדיקה האחרונה מ-16 ביולי 2026. השירות סורק ומאנדקס את האתר הציבורי ומציג תשובות המקושרות למקורות באמצעות widget. ה-widget תומך במיקומי bubble, inline ו-attach.

Achla אינו backend של Search API. זהו מסלול נפרד של סריקה ציבורית ו-widget מנוהלים. אין להציגו כמסלול לתוכן Drupal פרטי או מאומת, לאחזור מודע לתפקידים, להרשאות ברמת שורה או לפעולות טרנזקציוניות ב-Drupal. ראו הגדרה מנוהלת ללא מפתח להבנת גבול התפעול הזה.

לבנות או לנהל? השתמשו בדרישות, לא באופנה

דרישההעדיפו אבטיפוס מקורי ב-Drupal כאשר…שקלו מסלול מנוהל לאתר ציבורי כאשר…
גבול התוכןהאחזור חייב לשקף שדות, גרסאות, תפקידים או תוכן מאומת של Drupal.המקור המאושר ציבורי במכוון וניתן לסריקה.
השקעה קיימתכבר קיימים אינדקסי Search API, ספקים וצוות תפעול.הצוות אינו רוצה להפעיל embeddings, אחסון וקטורי, קריאות LLM וממשק תשובות.
שליטהבחירת ספק, לוגיקת prompt, מקום אחסון וכיוונון אחזור חייבים להישאר בארגון.חוזה שירות מוגבל והגבלה לתוכן ציבורי מקובלים.
ממשקViews, טפסים, הרשאות או תהליכי Drupal מותאמים הם חיוניים.מספיק widget עם תשובות מצוטטות או חיפוש ציבורי מצורף.
אחריות לתקריותהצוות יכול לאבחן תורים, גישה, אחזור, יצירה, cache וממשק.המפעיל אחראי לשכבות ומציג ראיות ופתרון חלופי מספיקים.

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

הגנו על הגישה, הציטוטים והתנהגות הרענון

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

הפרויקט AI RAG Search Chat מראה שמשטח הייצור רחב מאחזור: הוא מוסיף דפי חיפוש וצ׳אט, sessions, הרשאות, הגבלת קצב, ספקים ומקורות מקושרים. גרסת 1.0.7 שנצפתה הייתה מחוץ לכיסוי הודעות האבטחה של Drupal.

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

השתמשו בכרטיס ניקוד שחוזר על עצמו לפיילוט

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

  1. רשמו את השאלה, דף המקור הצפוי, מחלקת התוכן/גישה ותוצאת ״לא נמצא״ מקובלת.
  2. כללו מונחים מדויקים, ניסוחים חלופיים, דפים סותרים, תוכן מיושן או מחוק ושאלה שאין לה תשובה.
  3. בבדיקת תוכן פרטי במסלול מקורי, השתמשו בחשבונות בעלי תפקידים שונים והכשילו את הבדיקה בכל חשיפה של מקור לא נגיש.
  4. רשמו את המקורות שאוחזרו בנפרד מהניסוח שנוצר ומהציטוטים הגלויים למבקר.
  5. בדקו רענון אינדקס לאחר עריכה ומחיקה, ואז חזרו על הבדיקה כאשר caches רלוונטיים עשויים להיות מעורבים.
  6. הוסיפו בדיקות מקלדת, נייד, תקלה, תוצאה ריקה ו-fallback לממשק שנבחר.
  7. שייכו כל כשל לקליטה, אחזור, יצירה, ציטוט/ממשק, גישה או תפעול — וציינו מי מתקן אותו בכל ארכיטקטורה.

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

טעויות ארכיטקטורה נפוצות

  • להתייחס ל-LLM כאילו הוא מנגנון האחזור במקום למדוד את הראיות שאוחזרו.
  • לאנדקס שדות או תוכן פרטיים בלי לשמר ולבדוק את כללי הגישה.
  • לאבד כתובות URL, שפה, גרסה או זהות ישות במהלך החלוקה.
  • לבדוק תוספות אך לא עריכות, מחיקות, ביטול cache והחמצות כנות.
  • לכנות גרסה ״בטוחה״ משום שאין לה סיומת alpha, תוך התעלמות מכיסוי האבטחה.
  • לכנות סורק ציבורי backend של Search API או שילוב לתוכן פרטי.
  • להשוות מחיר רישיון תוך השמטת התשתית והאחריות לתקריות.

צעד מעשי הבא לאתר Drupal ציבורי

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

אם הדרישה היא תשובות עם ציטוטים מעל דפים ומסמכים ציבוריים של Drupal בלי להפעיל את מערכת RAG בתוך Drupal, העריכו את ההגדרה של Achla ל-Drupal. Achla אינו backend של Search API ואינו המסלול לתוכן הפרטי שתואר לעיל.

שאלות שצוותי Drupal שואלים

האם אני זקוק ל-Search API?

למסלול מקורי ב-Drupal שנבנה סביב מודולי Search API — כן. שירות מנוהל ונפרד שסורק תוכן ציבורי יכול להשתמש באינדקס משלו. אלה ארכיטקטורות שונות; מחבר או widget אינם הופכים את האינדקס המנוהל ל-backend של Search API.

האם אני תמיד זקוק למסד נתונים וקטורי?

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

האם חיפוש סמנטי יכול לפעול בלי צ׳אט?

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

מה לגבי תוכן פרטי?

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

כיצד משווים פיילוטים?

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

איור משותף

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

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