פיתוח מערכת שאלות ותשובות (מבוססת מסמכים)

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

לקוח מתלונן: "יש לנו 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 גבוה קיים גבוה נמוך

אילו בעיות אנחנו פותרים?

בפרויקט טיפוסי, לקוחות מתמודדים עם שלוש בעיות:

  1. נתונים במערכות שונות. Confluence, SharePoint, Google Drive, 1C — מסמכים מפוזרים. אנחנו בונים אינדקסר מאוחד דרך Airbyte או צינורות ETL מותאמים אישית.
  2. טבלאות וסריקות. מודלי LLM מתקשים להבין טבלאות מורכבות. אנחנו משתמשים ב-Text2SQL או בסריאליזציה ל-Markdown. עבור סריקות — Tesseract + layout-parser, שמבטיחים זיהוי מסמכים באיכות גבוהה.
  3. השהיה גבוהה. משתמשים לא רוצים להמתין יותר מ-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 ימים.