לקוח מתלונן: "יש לנו 10,000 מסמכים ב-Confluence, אבל למצוא תשובה זה לוטו." מצב אופייני: עובדים מבלים עד 30% מזמן העבודה שלהם בחיפוש מידע.
אנחנו פותרים זאת עם מערכת שאלות-תשובות המבוססת על RAG (Retrieval-Augmented Generation) — גישה המשלבת אחזור ויצירה. היא מאפשרת לשאול שאלות בשפה טבעית ולקבל תשובות מדויקות עם ציטוטי מקורות.
במהלך 5+ שנים סיפקנו יותר מ-50 פרויקטי NLP, ו-RAG הוא הכלי העיקרי עבור מאגרי ידע ארגוניים וחיפוש חכם. לפי Question Answering, משימת QA מורכבת מחילוץ או סינתזה של תשובה מתוך סט מסמכים.
RAG עולה על extractive QA במשימות סיכום — הדיוק גבוה ב-15%, וההזיות מצטמצמות בחצי. עבור חברה משפטית עם 5,000+ חוזים, השגנו F1 של 82% וזמן חיפוש של 30 שניות.
החיסכון בחיפוש מידע מסתכם בכ-cost calculated after audit לחודש עבור חברה עם 500+ עובדים. עבור חברה עם 2,000+ עובדים, החיסכון מגיע ל-cost calculated after audit לחודש. RAG גם זול פי 10 מ-Long-context LLM באיכות דומה.
מדוע RAG היא הגישה הטובה ביותר לשאלות ותשובות?
Extractive QA (מודלים deepset/roberta-base-squad2, sberbank-ai/rubert-base-cased-qa) טובה כאשר התשובה היא ציטוט מדויק. אך אם שאלה דורשת סיכום או מידע ממספר מסמכים, Extractive QA אינה מסוגלת להתמודד עם זה.
Long-context LLM (Claude 3.5, 200K tokens) פשוטה יותר, אך יקרה ואינה מתרחבת מעבר ל-500 עמודים. RAG היא דרך הזהב: חיפוש זול על פני אינדקסים וקטוריים + סינתזת תשובות באמצעות LLM. אנו משתמשים בה ב-90% מהפרויקטים.
| גישה | דיוק | הזיות | עלות | יכולת הרחבה |
|---|---|---|---|---|
| Extractive | גבוה (EM ~80%) | מינימלי | נמוך | גבוה |
| RAG | בינוני (F1 ~75%) | מתון | בינוני | גבוה מאוד |
| Long-context | גבוה | קיים | גבוה | נמוך |
אילו בעיות אנחנו פותרים?
בפרויקט טיפוסי, לקוחות מתמודדים עם שלוש בעיות:
- נתונים במערכות שונות. Confluence, SharePoint, Google Drive, 1C — מסמכים מפוזרים. אנחנו בונים אינדקסר מאוחד דרך Airbyte או צינורות ETL מותאמים אישית.
- טבלאות וסריקות. מודלי LLM מתקשים להבין טבלאות מורכבות. אנחנו משתמשים ב-Text2SQL או בסריאליזציה ל-Markdown. עבור סריקות — Tesseract + layout-parser, שמבטיחים זיהוי מסמכים באיכות גבוהה.
- השהיה גבוהה. משתמשים לא רוצים להמתין יותר מ-5 שניות. אנחנו מייעלים: מטמון embedding, הסקה בקבוצות, vLLM עבור GPU.
איך אנחנו עושים את זה: מקרה בוחן של חברה משפטית
עבור חברה משפטית (5,000+ חוזי PDF), השקנו מערכת RAG תוך 3 שבועות. סטאק: LangChain + Qdrant + GPT-4o-mini. תוצאה: זמן החיפוש ירד מ-15 דקות ל-30 שניות, דיוק התשובות — 82% (F1).
הדבר המרכזי — הוספנו בדיקת Faithfulness: פרומפט נפרד מאמת שכל עובדה בתשובה נתמכת על ידי לפחות מסמך אחד. אם לא — המערכת כותבת "המסמכים אינם מכילים את המידע."
בחרנו פרמטרים של chunking באופן ניסיוני:
| גודל chunk | חפיפה | F1 על סט הבדיקה |
|---|---|---|
| 256 טוקנים | 32 | 78% |
| 512 טוקנים | 64 | 82% |
| 1024 טוקנים | 128 | 80% |
כדי לשפר את הדיוק, אנחנו משתמשים בחיפוש היברידי: dense embeddings (OpenAI text-embedding-3-small) משולבים עם BM25, ולאחר מכן re-ranking באמצעות Cohere rerank v3. זה מניב תוספת של 3-5 נקודות אחוז ב-F1.
כיצד אנו מעריכים את איכות התגובות?
אנו יוצרים מערך נתוני בדיקה של למעלה מ-100 שאלות המכסות תרחישים טיפוסיים. מדדים: F1, EM (התאמה מדויקת), faithfulness (שיעור התגובות ללא הזיות), השהיה p95. סף היעד הוא F1 ≥ 75% ו-faithfulness ≥ 95%.
במידת הצורך, אנו מבצעים כיוונון עדין (fine-tuning) של ה-retriever (כיוונון k, בחירת מודל ה-embedding) או של ה-LLM (פרומפטים few-shot).
דוגמה לתצורת אינדקסר
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
from langchain_community.vectorstores import Qdrant
from langchain.chains import RetrievalQA
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Qdrant.from_existing_collection(
embeddings=embeddings,
url="http://localhost:6333",
collection_name="docs"
)
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
llm=llm,
chain_type="stuff",
retriever=vectorstore.as_retriever(search_kwargs={"k": 5}),
return_source_documents=True,
)
result = qa_chain.invoke({"query": "What is the procedure for terminating a contract?"})
כמה עולה הטמעת מערכת QA?
פרויקט בסיסי (עד 10,000 עמודים, מקור אחד) — בין 3 ל-5 שבועות. פרויקט מורכב (מספר מקורות, טבלאות, סריקות) — בין 6 ל-10 שבועות. אנו מספקים את העלות המדויקת לאחר ביקורת נתונים — כתבו לנו, ואנו נעריך את המקרה שלכם. פרויקט טיפוסי מחזיר את ההשקעה תוך 3-6 חודשים הודות לצמצום זמן החיפוש.
תהליך העבודה
- אנליטיקה: ביקורת של מקורות נתונים, סוגי מסמכים, נפחים, תדירות בקשות.
- עיצוב: בחירת ארכיטקטורה (RAG / היברידי / multi-agent), הגדרת צינור ה-chunking, ה-embedding וה-retrieval.
- מימוש: אינדוקס נתונים, הגדרת LLM, אינטגרציה עם מערכות ארגוניות (Confluence, SharePoint, בוט Telegram).
- בדיקות: יצירת מערך נתוני בדיקה של 100+ שאלות, הערכת מדדים (F1, EM, faithfulness, latency).
- פריסה וניטור: פריסה על Kubernetes או Managed ML (SageMaker, Vertex AI), תיעוד תגובות, בדיקות A/B.
מה כלול בתוצרים
- אינדקסר מסמכים עם תמיכה בעדכון מצטבר
- REST API לשאלות (תיעוד Swagger)
- ממשק אינטרנט (ממשק צ'אט פשוט)
- אינטגרציה עם מסנג'רים (Telegram, Slack) — אופציונלי
- לוח מחוונים למטריקות (מספר בקשות, השהיה p95, שיעור כשלים)
- תיעוד תפעולי
- הדרכת צוות (2-3 שעות)
- אחריות לבאגים למשך 3 חודשים
המהנדסים שלנו מוסמכים ב-AWS וב-GCP, ואנו מבטיחים דיוק של לפחות 75% F1 על הנתונים שלכם. הזמינו אודיט — נעריך את ההיקף, סוגי המסמכים ולוח הזמנים ליישום. קבלו ייעוץ והצעת מחיר תוך 1-2 ימים.







