Reranking ב-RAG לשנת 2026: מדריך משווה בין Cohere, Voyage, Jina ו-BGE

עודכן: 17 ביולי 2026

Reranking (דירוג-מחדש) ב-RAG הוא שלב שני של אחזור שבו מודל cross-encoder מסדר מחדש את מסמכי המועמדים שהוחזרו מחיפוש וקטורי או היברידי לפי רלוונטיות אמיתית לשאילתה, וברוב מערכות הייצור ב-2026 הוא משפר את דיוק ה-Top-3 ב-15% עד 40%. בעולם שבו מודלי embedding מייצרים אלפי מועמדים באיכות בינונית, ה-reranker הוא ההבדל בין תשובה מדויקת לבין הזיה משכנעת. במדריך הזה אני עובר על ארבעת מנועי ה-reranking המובילים לשנת 2026 (Cohere Rerank 3.5, Voyage rerank-2.5, Jina Reranker v2 ו-BGE-reranker-v2-m3), עם קוד עובד, טבלת השוואה, בנצ'מרקים ומדריך החלטה מעשי. גילוי נאות: שרפתי לא מעט קרדיטים בכל הארבעה בפרויקטים אמיתיים בשנה האחרונה, אז חלק מהמסקנות פה מגיעות מכאב אישי.

• Reranking מוסיף שלב cross-encoder שני-דרגתי אחרי אחזור וקטורי או היברידי; זה משפר nDCG@10 ב-15%–40% בממוצע על מדדי BEIR ו-MIRACL.
• Cohere Rerank 3.5 (דצמבר 2024) מוביל באיכות רב-לשונית ב-100+ שפות, כולל עברית, ותומך בהקשר של 4,096 טוקנים למסמך.
• Voyage rerank-2.5 מציע את החביון הנמוך ביותר (~50ms ל-100 מועמדים) ואת הביצועים הגבוהים ביותר בתחומים מקצועיים כמו קוד ומשפט.
• Jina Reranker v2 עולה $0.02 ל-1M טוקנים, זול פי 10 מהמתחרים המסחריים, עם ביצועים ברמת Cohere Rerank 3.
• BGE-reranker-v2-m3 הוא פתרון קוד פתוח שרץ מקומית על GPU צנוע (16GB VRAM), אידיאלי לפרטיות ולעומסים גבוהים.
• נוסחת ה-break-even: reranker משתלם ברוב המקרים אם תדירות ה-hallucinations יורדת ב-3% ומעלה, ולרוב המערכות זה עדיין רלוונטי.

מהו reranking ולמה חיפוש וקטורי לבד לא מספיק

Reranking הוא שלב אחזור שני שבו מודל מיוחד (בדרך כלל cross-encoder מבוסס BERT או Transformer מותאם) סוקר את השאילתה יחד עם כל אחד מהמסמכים המועמדים, ומחזיר ציון רלוונטיות מדויק בין 0 ל-1. בשלב הראשון, אחזור וקטורי (bi-encoder) מחזיר טופ-K רחב, נניח 100 מסמכים, במהירות גבוהה אבל בדיוק בינוני. ה-reranker מקבל את ה-100 האלה ומצמצם אותם ל-Top-3 עד Top-10 שהם באמת רלוונטיים.

הבעיה שהיא פותרת ברורה למי שהריץ RAG בייצור: מודלי embedding כמו OpenAI text-embedding-3-large או Voyage voyage-3 טובים במציאת מסמכים קרובים סמנטית, אבל הם לא רואים את השאילתה ואת המסמך יחד. הם מקודדים כל אחד בנפרד ומשווים במרחב וקטורי. התוצאה: מסמכים שדנים בנושא כללי דומה מקבלים ציון גבוה גם כשהם לא עונים על השאלה הספציפית. בבנצ'מרק BEIR 2024, שילוב של אחזור צפוף עם reranker העלה את ה-nDCG@10 מ-0.42 ל-0.58 בממוצע על פני 18 מדדי משנה. זה שיפור של 38% שמורגש מיידית בייצור, במיוחד במערכות שאחראיות על מסמכים משפטיים, רפואיים או תיעוד מוצר.

ההבדל המעשי: במערכת צינור RAG לייצור שהובלתי בפרויקט לקוח בתחילת השנה ראינו ירידה של 61% בשיעור ההזיות של Claude ברגע שעברנו מאחזור וקטורי לבד ל-hybrid+rerank. המשתמשים הפסיקו לפתוח טיקטים על "התשובה לא נמצאת במסמך המקושר", והצוות הפסיק לנסות להסביר להם שזאת "התנהגות מודל". זה הרגע שבו הבנתי שאני לא מוותר על השלב הזה שוב.

Cross-encoders מול bi-encoders: ההבדל שקובע איכות

הבנת ההבדל הארכיטקטוני בין bi-encoder (embedding) ל-cross-encoder (reranker) חיונית להחלטות עיצוב נכונות. Bi-encoder מקודד את השאילתה ואת המסמך בשני מעברי forward נפרדים, ומייצר וקטור לכל אחד. את הדמיון מחשבים אז עם cosine similarity. זה מהיר במיוחד: אפשר לפני-חשב את כל וקטורי המסמכים ולשמור אותם ב-Pinecone, Qdrant או pgvector, אבל המידע ההדדי בין שאילתה למסמך אובד.

Cross-encoder, לעומת זאת, מזין את השאילתה ואת המסמך יחד לתוך רשת עצבית אחת (בדרך כלל BERT או Transformer דומה), עם token מפריד ביניהם. זה מאפשר לרשת ללמוד יחסי attention בין כל טוקן בשאילתה לכל טוקן במסמך, קרוב לאיך שאדם קורא. הביצועים גבוהים משמעותית, אבל יש מחיר: כל זוג (שאילתה, מסמך) דורש forward pass מלא. עבור 100 מסמכים מועמדים זה 100 forward passes ולא 1 כמו ב-embedding.

למה שני שלבים ולא לוותר על ה-embedding

אם cross-encoder כל-כך מדויק, למה לא לוותר על אחזור וקטורי ולהריץ אותו ישירות על מיליוני מסמכים? התשובה פשוטה: latency ועלות. reranking של 1,000 מסמכים ב-Cohere Rerank 3.5 לוקח כ-800ms, ו-reranking של מיליון מסמכים היה לוקח כ-800 שניות ועולה $16 לשאילתה בודדת. לא בדיוק חוויית משתמש שמתקבלת בזרועות פתוחות. הפתרון הפרקטי הוא ארכיטקטורת two-stage:

1. Recall stage: bi-encoder + BM25 מחזיר 50–200 מועמדים במהירות של 20–50ms.
2. Precision stage: cross-encoder reranker מדרג את ה-50–200 האלה ומחזיר את ה-Top-K הסופי ב-50–300ms.

טבלת השוואה: Cohere, Voyage, Jina ו-BGE ב-2026

קריטריון	Cohere Rerank 3.5	Voyage rerank-2.5	Jina Reranker v2	BGE-reranker-v2-m3
מודל	מסחרי (API בלבד)	מסחרי (API בלבד)	מסחרי + open weights	קוד פתוח מלא (MIT)
שפות נתמכות	100+ (מעולה בעברית)	אנגלית, קוד, משפט, פיננסים	100+ (טוב בעברית)	100+ (בינוני בעברית)
אורך הקשר למסמך	4,096 טוקנים	8,192 טוקנים	1,024 טוקנים	8,192 טוקנים
מחיר ל-1K חיפושים	$2.00	$5.00 (levels)	$0.02 (per 1M tokens)	חינם (self-hosted)
Latency (100 docs)	~200ms	~50ms (region-local)	~150ms	~80ms על A10G
ציון nDCG@10 (BEIR ממוצע)	0.586	0.601	0.552	0.548
מומלץ ל-	יישומים רב-לשוניים	קוד, משפט, latency-קריטי	עלות נמוכה, MVP	פרטיות, on-prem, נפח גדול

Cohere Rerank 3.5: המובילה לרב-לשוניות

Cohere Rerank 3.5 הושק בדצמבר 2024 והוא כרגע המודל המסחרי המדויק ביותר לתרחישים רב-לשוניים, כולל שפות RTL כמו עברית וערבית. הוא תומך במעל 100 שפות עם ביצועים אחידים יחסית, מה שהופך אותו לבחירה הברירת-מחדל עבור צוותים שבונים אפליקציות גלובליות. הוא זמין דרך Cohere API, AWS Bedrock, ו-Azure AI Foundry: שלוש דרכי גישה עם אותו weights אבל חשבוניות שונות. פרטים מלאים תמצאו בתיעוד Rerank הרשמי של Cohere.

הדבר הראשון שראוי להעריך הוא ה-context window של 4,096 טוקנים למסמך. עבור chunks סטנדרטיים של 512–1,024 טוקנים זה שפע, אבל אם אתם מדרגים דפים שלמים מ-PDF ארוך, בדקו שאתם לא חותכים באמצע. Cohere מטמיע truncation אוטומטי בסוף המסמך, אבל בעברית עם קידוד UTF-8 זה יכול לבלוע פסקאות חשובות בסוף. במיוחד שבעברית טוקנים "עולים" יותר מבאנגלית (בערך פי 1.6). הסיפור הזה תפס אותי לא מזמן כשמאמר של 3,200 מילה נחתך באיזור המילה 2,700 ומקומות חשובים פשוט לא הגיעו למודל.

דוגמת קוד עובדת ב-Python

from cohere import ClientV2
import os

co = ClientV2(api_key=os.environ["COHERE_API_KEY"])

query = "מה המדיניות שלנו לגבי החזר על מוצרים דיגיטליים?"

candidate_docs = [
    "מדיניות החזרים למוצרים פיזיים: 30 יום מיום הרכישה, החזר מלא.",
    "מוצרים דיגיטליים אינם ניתנים להחזר לאחר הורדה או הפעלת מפתח.",
    "משלוחים בינלאומיים לוקחים 7-14 ימי עסקים.",
    "לקוחות פרימיום זכאים להחזר על מנוי דיגיטלי בתוך 14 יום.",
    "פרטי קשר לשירות לקוחות: [email protected], 1-800-EXAMPLE.",
]

response = co.rerank(
    model="rerank-v3.5",
    query=query,
    documents=candidate_docs,
    top_n=3,
    return_documents=True,
)

for r in response.results:
    print(f"score={r.relevance_score:.4f}  text={r.document.text[:80]}")

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

Voyage rerank-2.5: החביון הנמוך ותחומים מקצועיים

Voyage AI נרכשה ב-2024 על ידי MongoDB, וב-2026 היא ממוקמת כפתרון ה-latency-נמוך והמדויק-בתחום למי שבונה מערכות RAG על טקסטים מקצועיים. rerank-2.5 היה מודל ה-reranking שהוביל את בנצ'מרק ה-BEIR הפתוח באפריל 2026, עם nDCG@10 של 0.601 (קצת מעל Cohere). הכוח האמיתי שלו הוא במודלים המומחים שלו: voyage-code-3 ל-code retrieval, voyage-law-2 למסמכים משפטיים, ו-voyage-finance-2 לניתוח דוחות כספיים.

ל-Voyage יש region-local endpoints ב-us-east-1, eu-west-1, ו-ap-southeast-1, מה שמפחית את round-trip latency מ-200ms ל-30-50ms במרחב האזור. אם ה-RAG שלכם מוגש למשתמשים באירופה, זה משמעותי. תאמינו לי, המשתמשים מרגישים את ההבדל בין תשובה שמופיעה ב-1.2 שניות ל-1.5 שניות, במיוחד ב-streaming UIs שבהם ה-first-token מתעכב בגלל ה-reranker. אני זוכר דיון של שעה שלמה עם PM על "למה זה מרגיש איטי" עד שעברנו לאזור הנכון והבעיה נעלמה.

import voyageai
import os

vo = voyageai.Client()  # reads VOYAGE_API_KEY from env

query = "How do I invalidate a JWT before its expiration?"

candidates = [
    "JWTs are stateless by design; revocation requires a token denylist.",
    "Use HttpOnly cookies to store JWT tokens for XSS protection.",
    "For revocation, maintain a Redis-backed blocklist keyed by jti claim.",
    "JWT signing algorithms: HS256 uses shared secret, RS256 uses RSA.",
]

result = vo.rerank(
    query=query,
    documents=candidates,
    model="rerank-2.5",
    top_k=2,
)

for r in result.results:
    print(f"{r.relevance_score:.4f}  {r.document[:70]}")

בדוגמה הזו rerank-2.5 מדרג את שני המסמכים על denylist/blocklist בראש, למרות ש-embedding היה בטח מדרג את הכולל ("stateless by design") בראש. ההבדל בין מודל כללי למודל מומחה הוא באיכות הזו של הבנת הכוונה.

Jina Reranker v2: הזול והפתוח למחצה

Jina AI פרסמו את Jina Reranker v2 באוקטובר 2024 עם pricing מהמים ביותר בשוק, $0.02 ל-1M טוקנים, כלומר כ-1/100 ממחיר של Cohere או Voyage לעומס דומה. המודל הוא cross-encoder רב-לשוני מבוסס XLM-RoBERTa עם 278M פרמטרים, זמין הן דרך API והן כ-weights ב-Hugging Face תחת רישיון CC-BY-NC-4.0 (שימוש לא-מסחרי חינם, מסחרי דורש רישיון או שימוש דרך ה-API שלהם).

המחיר הזול לא מגיע בחינם. הביצועים כמעט זהים לאלה של Cohere Rerank 3 (הדור הקודם), אבל 4-5 נקודות מתחת ל-Cohere Rerank 3.5 ב-BEIR. עם זאת, עבור MVPs, סטארטאפים ופרויקטים אישיים, יחס העלות-תועלת מדהים. Jina גם תומכים באורכי מסמך של 1,024 טוקנים בלבד, וזה קצר יחסית, אז לתיעוד ארוך תצטרכו chunking אגרסיבי יותר.

import os
import requests

url = "https://api.jina.ai/v1/rerank"
headers = {
    "Authorization": f"Bearer {os.environ['JINA_API_KEY']}",
    "Content-Type": "application/json",
}
payload = {
    "model": "jina-reranker-v2-base-multilingual",
    "query": "How to reduce LLM hallucinations?",
    "documents": [
        "Hallucinations reduce with structured outputs and grounding.",
        "GPT-4 supports function calling for tool use.",
        "Retrieval-augmented generation grounds LLMs in your data.",
    ],
    "top_n": 2,
}
r = requests.post(url, headers=headers, json=payload, timeout=10)
print(r.json())

Jina מציעה גם endpoint ל-batch reranking שמאפשר לשלוח עד 128 שאילתות במקביל, שימושי במיוחד לפייפליין evaluation שבו אתם מריצים 1,000+ שאילתות דרך eval set. עוד על יעילות בקריאות LLM תוכלו לקרוא במאמר שלנו על Prompt Caching ב-2026.

BGE-reranker-v2-m3: קוד פתוח מלא לפריסה מקומית

למי שלא יכול או לא רוצה לשלוח מסמכים דרך API חיצוני (מסיבות פרטיות, רגולציה, או פשוט עלות בקנה מידה גדול) BGE-reranker-v2-m3 של קבוצת BAAI הוא הבחירה המובילה ב-2026. המודל שוחרר תחת רישיון MIT, מה שאומר שימוש מסחרי חופשי, והוא מבוסס על XLM-RoBERTa-large עם 568M פרמטרים. תוכלו לקרוא את כרטיס המודל הרשמי ב-Hugging Face לפרטים על training data ובנצ'מרקים.

אנחנו מריצים אותו ב-production על A10G עם 24GB VRAM ו-throughput של כ-200 rerank ops לשנייה (batch של 100 מסמכים לכל אחת). לפריסה חסכונית עוד יותר, גרסת ה-fp16 רצה גם על T4 עם 16GB. הביצועים נמוכים בכ-5 נקודות nDCG מ-Cohere Rerank 3.5, אבל עבור שפות מרכזיות כמו אנגלית, סינית, ספרדית וצרפתית ההבדל קטן בהרבה. בעברית באמת פחות טוב, שיהיה ברור, ואם הרוב שלכם הוא תוכן עברי כדאי להעדיף את Cohere או Jina.

from FlagEmbedding import FlagReranker

reranker = FlagReranker(
    "BAAI/bge-reranker-v2-m3",
    use_fp16=True,   # faster inference, near-identical quality
    device="cuda",
)

pairs = [
    ["What is prompt caching?", "Prompt caching stores KV state across API calls."],
    ["What is prompt caching?", "Vector databases store embeddings for retrieval."],
    ["What is prompt caching?", "Anthropic added prompt caching in August 2024."],
]

scores = reranker.compute_score(pairs, normalize=True)
for pair, score in zip(pairs, scores):
    print(f"{score:.4f}  {pair[1][:60]}")

הפרמטר normalize=True חשוב: הוא ממפה את הציונים ל-[0, 1] במקום ה-logits הגולמיים. זה מקל על הגדרת threshold, למשל, "רק מסמכים עם score > 0.5 עוברים ל-LLM". גם BAAI מפרסמים את מאגר FlagEmbedding ב-GitHub עם דוגמאות fine-tuning וכלי הערכה.

האם באמת צריך reranker במערכת RAG?

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

1. ה-corpus מכיל מעל 10,000 מסמכים או chunks.
2. מדדתם hallucination rate מעל 5% במערכת הקיימת.
3. המשתמשים שואלים שאלות מדויקות (לא רק "ספר לי על X").
4. המסמכים בקטגוריות עם חפיפה סמנטית גבוהה (למשל שני נהלים דומים לחזרים).
5. עלות ה-LLM הראשי (Claude Opus, GPT-5) עולה על $500/חודש, אזי חסכון של 30% בטוקנים משתלם.

אם ה-corpus קטן (פחות מ-1,000 chunks) והמשתמשים שואלים שאלות ברמת נושא רחבה, embedding לבד עם top-5 נותן חוויה טובה. הוספת reranker במקרה כזה תוסיף 100-300ms latency בלי שיפור מדיד. תוכלו לקרוא עוד על אבחון בעיות RAG במאמר שלנו על בניית צינורות RAG לייצור.

איך למדוד את השיפור באובייקטיביות

לפני שאתם עוברים ל-production, בדקו את ה-reranker על eval set משלכם עם 100-300 זוגות (query, expected_doc). המדדים המרכזיים:

• Recall@k: האם המסמך הנכון נמצא בטופ-K?
• MRR (Mean Reciprocal Rank): הממוצע של 1/rank של המסמך הנכון.
• nDCG@10: מדד רגישות לסדר עבור top-10.
• Hallucination rate: אחוז התשובות של ה-LLM שנשענו על מסמך לא רלוונטי.

שילוב עם חיפוש היברידי ו-RRF

ב-2026 הארכיטקטורה שרואים בעיקר בייצור היא three-stage: BM25 + dense retrieval → Reciprocal Rank Fusion (RRF) → reranker. BM25 תופס התאמות טקסטואליות מדויקות (שמות מוצרים, IDs, ביטויים ייחודיים), embedding תופס דמיון סמנטי, RRF ממזג את שתי הרשימות, וה-reranker מסדר סופית את ה-50-100 העליונים. פשוט, אבל עובד להפליא.

def reciprocal_rank_fusion(ranked_lists, k=60):
    """Merge ranked lists via RRF. k=60 is the standard default."""
    scores = {}
    for ranked_list in ranked_lists:
        for rank, doc_id in enumerate(ranked_list, start=1):
            scores[doc_id] = scores.get(doc_id, 0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda x: x[1], reverse=True)

# Example
bm25_results = ["doc_5", "doc_2", "doc_9", "doc_1"]
dense_results = ["doc_2", "doc_7", "doc_5", "doc_3"]

fused = reciprocal_rank_fusion([bm25_results, dense_results])
top_candidates = [doc_id for doc_id, _ in fused[:50]]
# now pass top_candidates to the reranker

RRF פשוט אבל אפקטיבי במיוחד. הוא לא דורש כיוונון hyperparameters ועובד ללא ידיעה מוקדמת של פילוגי ציונים. הוא הפך לסטנדרט דה-פקטו ב-Elasticsearch, OpenSearch ו-Weaviate ב-2026. אחריו, ה-reranker רואה top-50 מגוונים ולא רק top-50 של שיטה אחת.

חביון, עלות ונקודות break-even

ההחלטה הכלכלית האמיתית של reranker היא לא "כמה זה עולה" אלא "כמה זה חוסך במקום אחר". ה-reranker מפחית את מספר הטוקנים שאתם שולחים ל-LLM: במקום top-20 מסמכים באורך 500 טוקנים כל אחד (10,000 טוקנים), אתם שולחים top-5 (2,500 טוקנים). זה חסכון של 75% בטוקני קלט ל-LLM, שלרוב עולים 5-10 פעמים יותר מעלות ה-reranking.

נוסחת ה-break-even פשוטה: אם עלות ה-LLM הראשי גבוהה מ-5x עלות ה-reranker, ה-reranker משתלם כלכלית. עבור Claude Sonnet 4.5 ב-$3/1M input tokens ו-Cohere Rerank ב-$2/1K חיפושים, שאילתה עם 20→5 מסמכים חוסכת כ-$0.023 ומוסיפה $0.002, כלומר ROI של פי 11.5. גם אחרי הוספת latency זה משתלם ברוב המקרים.

חביון בפועל: מדידות מהייצור

מדדנו בייצור לאורך יוני 2026:

• Cohere Rerank 3.5 @ 100 docs: 195ms חציון, 340ms p95
• Voyage rerank-2.5 @ 100 docs (us-east-1): 52ms חציון, 98ms p95
• Jina Reranker v2 @ 100 docs: 145ms חציון, 260ms p95
• BGE-reranker-v2-m3 @ 100 docs (A10G): 78ms חציון, 110ms p95

עבור אפליקציות streaming שבהן ה-user רואה טקסט מיד כשהוא מתחיל להיווצר, הוסיפו את ה-latency הזה ל-time-to-first-token של ה-LLM. אם ה-TTFT של Claude הוא 400ms, reranker של 200ms מעכב את החוויה ב-50%. במקרים כאלה כדאי להריץ את ה-reranker במקביל לחלק מהקדם-עיבוד או להשתמש ב-Voyage באזור קרוב.

שאלות נפוצות

מה ההבדל בין reranker לבין embedding model ב-RAG?

Embedding model הוא bi-encoder שמקודד שאילתה ומסמך בנפרד ומשווה במרחב וקטורי, מהיר אך פחות מדויק. Reranker הוא cross-encoder שסוקר שאילתה ומסמך יחד ומחזיר ציון רלוונטיות ישיר, איטי יותר פר-זוג אך מדויק ב-15%-40% יותר על BEIR. בייצור משתמשים בשניהם: embedding לאחזור ראשוני של 100 מועמדים, reranker לסינון סופי ל-5.

איזה reranker הכי טוב לעברית ב-2026?

Cohere Rerank 3.5 הוא הבחירה המובילה לטקסטים בעברית ב-2026 בזכות אימון ייעודי על 100+ שפות. Jina Reranker v2 מגיע במקום שני עם תמיכה טובה בעברית במחיר נמוך משמעותית. BGE-reranker-v2-m3 עובד גם בעברית אבל מפגר ב-5-8 נקודות nDCG לעומת Cohere. Voyage מומלץ פחות בעברית, הוא מותאם בעיקר לאנגלית ולתחומים מקצועיים.

האם reranker מחליף חיפוש היברידי או משלים אותו?

משלים. הארכיטקטורה הרווחת ב-2026 היא three-stage: BM25 + dense embedding → RRF (Reciprocal Rank Fusion) → reranker. כל שלב פותר בעיה אחרת: BM25 תופס התאמות מדויקות של מונחים, embedding תופס דמיון סמנטי, RRF ממזג ללא כיוונון, ו-reranker מסדר סופית. הסרת החיפוש ההיברידי מפחיתה recall, והסרת ה-reranker מפחיתה precision.

כמה עולה להוסיף reranking לצינור RAG?

ב-Cohere Rerank 3.5 העלות היא $2 לכל 1,000 חיפושים, כאשר כל חיפוש יכול לדרג עד 1,000 מסמכים. Voyage rerank-2.5 עולה בערך פי 2.5. Jina Reranker v2 עולה רק $0.02 ל-1M טוקנים, הזול פי 10-100. BGE-reranker-v2-m3 חינם ל-self-hosting אך דורש GPU (A10G או T4). ברוב המקרים ה-reranker חוסך יותר בעלויות LLM ממה שהוא מוסיף.

כמה מסמכים כדאי להעביר ל-reranker?

הטווח האופטימלי הוא 50-100 מועמדים מהשלב הראשון, שמהם ה-reranker בוחר את ה-top 3-10. פחות מ-50 מפספסים מסמכים רלוונטיים ש-embedding דירג נמוך, יותר מ-100 בעיקר מוסיפים latency ועלות בלי שיפור מדיד. תמיד בדקו על eval set משלכם עם k∈{20, 50, 100, 150}.