Agentic Search — סוכן שמתכנן בעצמו אסטרטגיית חיפוש

מאת צוות מדיה דיל · 12.08.2026 · AI Retrieval · 5 דק׳

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

אנליסט במחלקת מחקר שאל צ'אטבוט מבוסס RAG שאלה פשוטה לכאורה: "האם המתחרה שלנו הוריד מחירים ברבעון האחרון, ואם כן — באיזה היקף?". מערכת RAG קלאסית ביצעה שליפה אחת, מצאה כמה מסמכים על "תמחור" ו"מתחרים", והחזירה תשובה חלקית ומטעה שהתבססה על מסמך ישן משנה שעברה. הבעיה לא הייתה באיכות ה-Embeddings אלא בארכיטקטורה עצמה: Retrieve-then-Generate בשלב אחד לא מסוגל להתמודד עם שאלה שדורשת כמה סבבי חיפוש, בדיקת עדכניות, והצלבה בין מקורות. זה בדיוק המקום שבו Agentic Search נכנס לתמונה — סוכן שמתכנן, מבצע, בודק את התוצאה, ומחליט בעצמו אם צריך עוד סבב חיפוש.

ההבדל בין Retrieval פסיבי לחיפוש Agentic

ב-RAG המסורתי, זרימת העבודה קבועה מראש: שאילתה נכנסת, embedding מחושב, top-k מסמכים נשלפים, והכל מוזרם למודל השפה לייצור תשובה. הסוכן לא "מחליט" כלום — הוא מבצע pipeline סטטי. Agentic Search הופך את זה ללולאה: הסוכן מקבל שאלה, מנסח תת-שאלה או שאילתת חיפוש ראשונית, מריץ אותה, קורא ומעריך את התוצאות שקיבל, ורק אז מחליט אם יש לו מספיק מידע לענות, אם הוא צריך לחדד את השאילתה, לפנות למקור אחר לגמרי, או לבצע שאילתת המשך שמבוססת על מה שגילה בסבב הקודם. זו בעצם וריאציה של תבנית ReAct (Reasoning + Acting) המותאמת ספציפית לבעיית retrieval.

ההבדל הפרקטי ניכר בדיוק בתרחיש כמו זה שפתחנו איתו: סוכן agentic היה שם לב שהמסמך הראשון שנמצא מתוארך לפני תשעה חודשים, מנסח שאילתת המשך ("מחירי מתחרה X רבעון אחרון 2026"), ואולי אף פונה למקור נתונים שונה — API חיצוני של נתוני שוק, ולא רק מאגר המסמכים הפנימי. זה הבדל איכותי, לא רק כמותי: הסוכן לא רק "שולף יותר" אלא שולף אחרת, בהתאם למה שהוא לומד תוך כדי התהליך.

מרכיבי הלולאה: תכנון, ביצוע, הערכה, החלטה

ארכיטקטורה עובדת של Agentic Search בנויה מארבעה שלבים חוזרים: תכנון — ניסוח שאילתת החיפוש הבאה בהתבסס על השאלה המקורית ועל מה שכבר נאסף; ביצוע — הרצת השאילתה מול מקור המידע הרלוונטי (Vector DB, מנוע לקסיקלי, API, גרף ידע); הערכה — בדיקה אוטומטית אם התוצאות שהתקבלו רלוונטיות ומספיקות, בדרך כלל באמצעות קריאה נוספת למודל השפה שמדרג את התוצאות מול השאלה המקורית; והחלטה — לעצור ולענות, להמשיך לסבב נוסף, או לשנות כיוון לגמרי.

השלב הקריטי ביותר, וגם הכי פעמים נשכח, הוא ההערכה. בלי מנגנון הערכה אמיתי, הסוכן פשוט ירוץ מספר קבוע של סבבים (למשל שלושה) בלי קשר לאיכות התוצאות — מה שמבזבז tokens כשהתשובה כבר נמצאה בסבב הראשון, ומחזיר תשובה חלקית כשבאמת נדרשים חמישה סבבים. הערכה טובה כוללת שאלה מפורשת למודל: "האם המידע שנאסף עד כה מספיק כדי לענות במלואו על השאלה המקורית? אם לא — מה חסר?" והתשובה משמשת ישירות לניסוח השאילתה הבאה. מנגנון re-ranking בין הסבבים, כמו שמתואר במדריך Reranking ב-RAG, משפר משמעותית את דיוק ההערכה הזו.

ניהול תקציב: מתי לעצור

סוכן שלא יודע לעצור הוא בעיה תפעולית לא פחות מסוכן שלא יודע לחפש נכון. יש שלושה סוגי גבולות שצריך להטמיע בכל ארכיטקטורת Agentic Search בפרודקשן: תקרת סבבים — מספר מקסימלי של איטרציות חיפוש, גם אם ההערכה ממשיכה להגיד "עוד לא מספיק" (בדרך כלל 3-6, תלוי בתחום); תקציב Token/עלות — עצירה כשהעלות המצטברת של הקריאות למודל חוצה סף מוגדר מראש, קריטי כשמדובר במוצר עם משתמשי קצה רבים; וזיהוי stagnation — עצירה כשסבב חדש מחזיר תוצאות זהות או כמעט זהות לסבב הקודם, סימן שהמשך חיפוש לא יוסיף מידע חדש.

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

איך זה שונה מתכנון מראש של כל השאילתות

חשוב להבחין בין Agentic Search לבין Query Planning — תכנון מראש של כל שאילתות המשנה לפני ביצוע כלשהו. תכנון מראש עובד טוב כשמבנה הבעיה ידוע מראש (למשל "תמיד צריך לבדוק מחיר, זמינות ומשלוח"), אבל נכשל כששלב חיפוש אחד חושף מידע שמשנה את הצורך בשלבים הבאים. Agentic Search גמיש יותר בדיוק בגלל שהוא לא מתכנן הכל מראש — אבל המחיר הוא פחות צפיות וקושי גדול יותר בדיבוג ובקרת עלויות. בפועל, המערכות הטובות ביותר משלבות: תכנון ראשוני גס שמכסה את המקרה הנפוץ, עם יכולת סטייה agentic כשההערכה מזהה שהתכנון המקורי לא מספיק. הבסיס התאורטי לגישה כולה מפורט במדריך RAG מתקדם, שם מוסבר גם למה pipeline סטטי מגיע למגבלה טבעית בשאלות מרובות-שלבים.

Observability: איך מדבגים סוכן שמחליט בעצמו

הבעיה המעשית הגדולה ביותר עם Agentic Search בפרודקשן היא שקשה להבין למה הסוכן קיבל החלטה מסוימת אחרי שהיא כבר קרתה. כשמערכת RAG סטטית מחזירה תשובה גרועה, קל לבדוק את ה-chunks שנשלפו ולזהות את הבעיה. כשסוכן agentic מריץ שישה סבבי חיפוש עם שינויים דינמיים בשאילתה, יש צורך בתשתית logging ייעודית שמתעדת כל איטרציה בנפרד: מה הייתה השאילתה שנוסחה, אילו תוצאות התקבלו, מה הייתה החלטת ההערכה, ולמה. בלי זה, כל תקלה בייצור הופכת לחקירה ארוכה של שחזור state שכבר אבד. כלי מעקב (tracing) ברמת סבב-סבב, לא רק ברמת הבקשה הכוללת, הוא לא Nice-to-have אלא דרישת סף לכל מערכת agentic שרצה מול משתמשי אמת.

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

כלי נוסף שמשתלם לבנות מוקדם הוא "replay" — יכולת להריץ מחדש בדיוק את אותה שרשרת החלטות עם אותם קלטים, כדי לבודד אם תקלה מסוימת נובעת משינוי בקוד, משינוי בגרסת המודל, או פשוט מהשונות הטבעית (non-determinism) שקיימת בכל קריאת LLM. בלי replay אמין, קשה מאוד להבחין בין "התנהגות אקראית חד-פעמית" לבין "רגרסיה אמיתית שדורשת תיקון", וזה גורם לצוותים לרדוף אחרי תקלות פאנטום שלא ניתנות לשחזור.

תגיות: Agentic Search · ReAct · Query Planning · AI Agents · Retrieval Strategy · RAG

← חזרה לבלוג · צור קשר