המוח שמאחורי החיפוש הסמנטי
כשאתה מחפש "מדיניות החזרות" ב-Google, אתה מקבל דף שכולל בדיוק את המילים האלה. אבל מה אם לקוח שואל "האם אפשר להחזיר נעליים שנקנו לפני חודש?". מנוע חיפוש רגיל ייכשל, אין "החזרה" ואין "נעליים" ב-FAQ שלך. Embeddings פותרות את הבעיה הזו.
Embedding הוא ייצוג של טקסט כרשימת מספרים, וקטור, במרחב מתמטי. הרעיון: טקסטים דומים במשמעות יושבים קרוב זה לזה במרחב. "החזרת מוצר" ו"החזרת סחורה" ו-"refund", כולם קרובים. "מחשב נייד" רחוק מהם. זה מה שנקרא חיפוש סמנטי.
חשוב לדעת: Anthropic לא מציעה מודל embeddings משלה. השותף המומלץ הרשמי הוא Voyage AI. נכון לינואר 2026, הדור הנוכחי הוא voyage-4, עם context window של 32,000 טוקן.
מה זה Vector Database ולמה צריך אחד?
אחרי שהמרת מסמכים לוקטורים, אתה צריך מקום לאחסן אותם ולחפש בהם בצורה מהירה. PostgreSQL רגיל לא מתאים, חיפוש "מי הכי קרוב" בין מיליוני וקטורים של 1024 מספרים זה חישוב יקר. Vector DB מיועד בדיוק לזה.
| כלי | סוג | יתרון | מתאים ל- |
|---|---|---|---|
| Chroma | Local / Python | אפס הגדרה, מקומי | POC, ניסויים |
| Pinecone | Managed Cloud | Serverless, auto-scale | Production, SaaS |
| pgvector | PostgreSQL Extension | SQL + Vectors יחד | Supabase, DB קיים |
| Qdrant | Self-hosted / Cloud | ביצועים גבוהים, Rust | High-performance |
| Weaviate | Self-hosted / Cloud | Hybrid search, GraphQL | Enterprise |
לפרויקט חדש: תתחיל עם Chroma. כשתגיע ל-production עם עשרות אלפי מסמכים, תשקול Pinecone serverless או pgvector על Supabase.
RAG, הדפוס שמשנה הכל
RAG (Retrieval-Augmented Generation) הוא הדרך לתת ל-Claude גישה למידע שהוא לא אמון עליו, תיעוד פנימי, מוצרים, נהלים, כל דבר. במקום לדחוף אלפי עמודים ל-prompt (יקר ואיטי), שולפים רק את החלקים הרלוונטיים לכל שאלה.
הזרימה המלאה:
- Indexing (פעם אחת): פצל מסמכים ל-chunks, צור embeddings לכל chunk, אחסן ב-Vector DB
- Retrieval (כל שאלה): צור embedding לשאלת המשתמש, מצא את ה-chunks הקרובים ביותר
- Generation: שלח ל-Claude את השאלה + ה-chunks הרלוונטיים, קבל תשובה מבוססת-מידע
import anthropic
import chromadb
# 1. אינדוקס, פעם אחת
client_db = chromadb.Client()
collection = client_db.create_collection("company_docs")
collection.add(
documents=[
"מדיניות ביטול הזמנה: ניתן לבטל עד 24 שעות לפני מועד האספקה",
"משלוח אקספרס עולה 35 שקל ומגיע תוך יום עסקים אחד",
"ערבות החזר כסף מלאה ב-30 יום ראשונים לכל רכישה",
"שירות לקוחות זמין ראשון עד חמישי 9:00-18:00, שישי עד 14:00"
],
ids=["cancel", "express", "refund", "support"]
)
# 2. שליפה + 3. יצירה, כל שאלה
def ask_about_company(question: str) -> str:
results = collection.query(query_texts=[question], n_results=2)
context = "\n".join(results["documents"][0])
client_ai = anthropic.Anthropic()
response = client_ai.messages.create(
model="claude-opus-4-7",
max_tokens=512,
system="אתה נציג שירות לקוחות של החברה. ענה רק על בסיס המידע הבא, בעברית.",
messages=[{"role": "user", "content": f"מידע:\n{context}\n\nשאלה: {question}"}]
)
return response.content[0].text
print(ask_about_company("אפשר לבטל הזמנה?"))
Chunking, האמנות שקובעת הכל
"The most common RAG failures include chunking boundaries that cut semantic context at the wrong point", זו הטעות שחוזרת בכל פרויקט RAG שנכשל. גודל ה-chunk משפיע על כל שאר הצינור.
- Chunks קטנים מדי (100-200 tokens): דיוק גבוה אבל אובדן הקשר, Claude מקבל פיסת מידע שלא מספיק לענות
- Chunks גדולים מדי (2000+ tokens): הקשר רחב אבל פחות דיוק, embeddings פחות ממוקדים
- ה-sweet spot: 300-600 tokens עם חפיפה של 10-15% בין chunks
- עדיף לפצל לפי מבנה: פסקאות, כותרות, סעיפים, לא לפי מספר תווים
טעות נוספת: שימוש במודל embeddings שונה לאינדוקס ולשאילתות. אם הכנסת מסמכים עם voyage-4, חייב לחפש עם voyage-4. ערבוב מודלים הורס את הדיוק לחלוטין.
Contextual Retrieval, שיפור הביצועים של RAG
Anthropic פרסמה ב-2024 שיטה שמשפרת RAG בצורה משמעותית: Contextual Retrieval. הבעיה: כשמפצלים מסמך לchunks, כל chunk מאבד את ההקשר של המסמך כולו.
הפתרון: לפני יצירת embeddings, שולחים כל chunk ל-Claude Haiku עם הפרומפט: "בהינתן המסמך הבא, תן הסבר קצר (50 מילה) שמסביר מה המקום של הקטע הזה במסמך". מוסיפים את ההסבר לתחילת כל chunk, ואז יוצרים embeddings.
התוצאות של Anthropic: שיפור של 35% בדיוק השליפה. עם שילוב hybrid search (סמנטי + BM25): שיפור של 49%. עם reranking: שיפור של 67%. זה הנתון שהכי מפתיע מקצוענים שמכירים RAG.
דוגמה ישראלית: מערכת ידע לחברת נדל"ן
חברת נדל"ן בת"א עם 200 נכסים ו-50 עמודי תנאים, מדיניות, ונהלים רצתה שסוכני המכירות יוכלו לשאול שאלות בשפה חופשית. הפתרון:
- פיצול כל מסמך לפי סעיפים (לא לפי גודל)
- Contextual Retrieval עם Claude Haiku, כל chunk קיבל הסבר של "איזה חלק של חוזה שכירות זה?"
- pgvector על Supabase (כבר השתמשו ב-Supabase לCRM)
- Claude Sonnet מקבל 3 chunks רלוונטיים ועונה עם ציטוטים
תוצאה: סוכן שואל "מה קורה אם דייר רוצה לצאת לפני תום החוזה?", ומקבל תשובה מדויקת עם הפניה לסעיף הרלוונטי, תוך 2 שניות.
השיעור הבא: Claude Code + MCP, כלי הפיתוח של העתיד
RAG נותן ל-Claude גישה למידע, MCP נותן לו גישה לכלים. בשיעור הבא תלמד כיצד Model Context Protocol מאפשר ל-Claude לתקשר עם כל API, מסד נתונים וכלי חיצוני דרך ממשק אחיד, ותבנה MCP server משלך ב-TypeScript.
⏱️ 45 דקות · 🎯 MCP server עובד המחובר ל-Claude Code עם tool use אמיתי
