רלוונס / Relevance AI

מה זה רלוונס וממה המערכת בנויה?

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

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

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

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

הפיצ'רים המרכזיים של רלוונס

שש יכולות מרכזיות. הראשונה היא הבסיס האמיתי של המוצר, והשלישית היא זו שמפרידה אותו מכלים דומים.

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

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

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

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

כמה זה עולה?

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

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

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

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

רלוונס מול הכלים האחרים לבניית סוכנים

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

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

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

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

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

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

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

הפיצ'ר שעושה את ההבדל: כלי עם חוזה קבוע

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

# בדיקת חוזה לכלי סוכן. רצה לפני כל שינוי, כדי שסטייה תתגלה כאן ולא אצל לקוח
import os
import json
import time
import requests

BASE = os.environ["RELEVANCE_API_BASE"]
AUTH = {"Authorization": os.environ["RELEVANCE_API_KEY"]}
TOOL_ID = "classify-inbound-v3"
MAX_SECONDS = 12
MAX_CREDITS = 40

# מקרי בדיקה שמייצגים גם את הרגיל וגם את מה שנוטים לשכוח
FIXTURES = [
    {"name": "פנייה רגילה",
     "input": {"text": "שלום, אשמח להצעת מחיר לשלושה רישיונות"},
     "expect": {"label": "מכירה", "has_contact": False}},
    {"name": "טקסט ריק",
     "input": {"text": ""},
     "expect": {"label": "אחר"}},
    {"name": "שתי בקשות במייל אחד",
     "input": {"text": "יש תקלה בהתחברות, ואגב כמה עולה שדרוג?"},
     "expect": {"label": "תמיכה"}},
    {"name": "טקסט ארוך מאוד",
     "input": {"text": "פנייה " * 4000},
     "expect": {"label": "אחר"}},
]

REQUIRED_FIELDS = ("label", "confidence", "entities")
ALLOWED_LABELS = ("מכירה", "תמיכה", "חשבונית", "אחר")

def call_tool(payload):
    started = time.time()
    r = requests.post(BASE + "/tools/" + TOOL_ID + "/trigger",
                      headers=AUTH, json={"params": payload}, timeout=90)
    r.raise_for_status()
    body = r.json()
    return body, time.time() - started

def check(fixture):
    problems = []
    body, seconds = call_tool(fixture["input"])
    output = body.get("output") or {}
    for field in REQUIRED_FIELDS:
        if field not in output:
            problems.append("חסר שדה " + field)
    if output.get("label") not in ALLOWED_LABELS:
        problems.append("תווית לא מוכרת: " + str(output.get("label")))
    if not isinstance(output.get("entities"), list):
        problems.append("entities אינו רשימה")
    for key, value in fixture["expect"].items():
        if key in output and output[key] != value:
            problems.append("ציפינו ל" + str(value) + " בשדה " + key)
    if seconds > MAX_SECONDS:
        problems.append("איטי מדי: " + str(round(seconds, 1)) + " שניות")
    credits = body.get("credits_used", 0)
    if credits > MAX_CREDITS:
        problems.append("יקר מדי: " + str(credits) + " נקודות")
    return {"name": fixture["name"], "seconds": round(seconds, 2),
            "credits": credits, "problems": problems}

def run():
    results = [check(f) for f in FIXTURES]
    failed = [r for r in results if r["problems"]]
    report = {"tool": TOOL_ID, "checked": len(results),
              "failed": len(failed), "results": results}
    with open("contract-report.json", "w", encoding="utf-8") as f:
        json.dump(report, f, ensure_ascii=False, indent=2)
    return report

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

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

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

חסרונות שאתם צריכים לדעת

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

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

היתרונות שעושים את רלוונס שווה

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

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

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

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

מתי לבחור רלוונס ומתי לבחור אחרת?

שלוש נקודות מכריעות את התשובה: מי בונה, כמה עיבוד תוכן נדרש, וכמה ודאות התהליך מחייב.

# עץ החלטה לבחירת סביבת בנייה לתהליך חכם
שאלה 1: מי בונה ומתחזק?
    איש תפעול או שיווק  -->  פלטפורמה ללא קוד
    איש אוטומציה        -->  מנוע חזותי, אולי עם רכיבי מודל
    מפתח                -->  ספריית קוד, שליטה מלאה

שאלה 2: מה נדרש מהתהליך?
    העברת מידע בלבד     -->  אוטומציה פשוטה
    סיווג וחילוץ מידע   -->  רלוונס, זו נקודת החוזק
    ניסוח סופי ללקוח    -->  לשלב אדם או שלב ניסוח נפרד

שאלה 3: כמה קריאות ליום?
    עד 50               -->  החבילה המקצועית
    50 עד 500           -->  לאחד שלבים לכלי אחד לפני שמרחיבים
    מעל 500             -->  חבילה צוותית ובדיקת עלות לכל הרצה

שאלה 4: כמה סוכנים באמת צריך?
    אחד עם כלים טובים   -->  זו התשובה ברוב המקרים
    שניים בתחומים שונים -->  צוות קטן, עם חוזה ברור בין השניים
    שלושה ומעלה         -->  לבדוק שוב, כמעט תמיד יותר מדי

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

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

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

השורה התחתונה: האם רלוונס שווה?

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

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

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

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