צמצם עלויות AI עם מטמון סמנטי – חיפוש וקטורי למודלי שפה

כיצד פועל מטמון סמנטי

תארו לעצמכם אפליקציה ניידת עם מאות אלפי משתמשים. כל יום היא מייצרת אלפי שאילתות LLM דומות: "איך מוסיפים איש קשר?", "איך יוצרים איש קשר חדש?", "איך מכניסים איש קשר לרשימה?". ללא מטמון סמנטי, כל בקשה כזו פוגעת ב-API, ומכפילה את העלויות. אנו פותרים זאת על ידי פריסת מנגנון השומר תשובות יחד עם הייצוג הווקטורי של השאילתה. בבקשות חוזרות, המערכת מחפשת embeddings קרובים סמנטית ומחזירה את התשובה השמורה, תוך עקיפת ה-LLM. בפועל, זה מפחית את עלויות ה-API ב-40–60% ומקצר את זמן ההשהיה משניות למילישניות.

בעיות שמטמון סמנטי פותר

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

איך אנחנו עושים את זה: FastAPI Middleware

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

import numpy as np
from openai import AsyncOpenAI

client = AsyncOpenAI()
cache: list[dict] = []  # В проде — Redis + pgvector или Pinecone


async def get_embedding(text: str) -> list[float]:
    response = await client.embeddings.create(
        model="text-embedding-3-small",
        input=text
    )
    return response.data[0].embedding


def cosine_similarity(a: list[float], b: list[float]) -> float:
    a_arr, b_arr = np.array(a), np.array(b)
    return float(np.dot(a_arr, b_arr) / (np.linalg.norm(a_arr) * np.linalg.norm(b_arr)))


async def semantic_cache_lookup(query: str, threshold: float = 0.92) -> str | None:
    query_emb = await get_embedding(query)
    for entry in cache:
        similarity = cosine_similarity(query_emb, entry["embedding"])
        if similarity >= threshold:
            return entry["response"]
    return None

הסף הוא פרמטר קריטי. ב-0.85 המטמון הופך לאגרסיבי מדי: שאלות שונות סמנטית מקבלות את אותה תשובה. ב-0.97 הוא כמעט לא עובד. הטווח האופטימלי לרוב התחומים הוא 0.90–0.95, מכוונן על שאילתות אמיתיות.

התקנת מטמון סמנטי שלב אחר שלב

1. תעדו שאילתות משתמשים בסביבת ייצור (לפחות 1000).
2. צרו embeddings באמצעות המודל הנבחר (אנו משתמשים ב-text-embedding-3-small).
3. בנו אינדקס וקטורי: HNSW לחיפוש מהיר.
4. כווננו את הסף על קבוצת אימות: נתחו שיעור פגיעה ואיכות.
5. פרסו middleware בצד השרת.
6. נטרו שיעור פגיעה, חיסכון ותוצאות חיוביות שגויות.

למה סף 0.92 הוא נקודת התחלה אופטימלית

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

מתי מטמון סמנטי לא עובד

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

Redis לעומת pgvector: מה לבחור

Redis עם RediSearch מהיר פי 3 מ-pgvector עבור מטמונים עד 50 אלף רשומות, אך pgvector מתקפל למיליונים ללא אובדן דיוק.

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

ביטול ו-TTL

יש לבטל מטמון סמנטי כאשר מעדכנים את ה-system prompt או את המודל הבסיסי — תשובות ישנות עשויות שלא להתאים להתנהגות החדשה. TTL מומלץ: 7–30 ימים לשאלות יציבות דמויות FAQ. לשאלות רגישות לזמן, איננו מיישמים מטמון.

מה כלול בעבודה

• תרשים ארכיטקטורה לשילוב מטמון סמנטי באפליקציה ניידת (iOS/Android).
• התקנת יצירת embeddings ובחירת מודל (OpenAI, Cohere, SentenceTransformers).
• כיוונון סף הדמיון על לוגי השאילתות שלכם.
• יישום middleware בצד השרת (FastAPI, Node.js, Go).
• ניטור שיעור פגיעה וחיסכון בעלויות.
• תיעוד והדרכת צוות.

הניסיון שלנו כולל 5+ פריסות לאפליקציות עם קהל מ-10 אלף עד 1 מיליון משתמשים פעילים יומית. אנו מבטיחים שיעור פגיעה של לפחות 40% בשאלות יציבות.

טעויות נפוצות ביישום

• בחירת סף נמוך מדי — המטמון מתחיל לבלבל בין שאילתות שונות סמנטית.
• התעלמות מביטול כאשר ה-prompt משתנה — משתמשים מקבלים תשובות מיושנות.
• חוסר ב-fallback: אם חיפוש וקטורי נכשל, הבקשה חייבת ללכת ישירות ל-LLM.
• בחירה שגויה של אינדקס וקטורי (flat לעומת HNSW) לגודל המטמון.

הערכות לוחות זמנים

מטמון סמנטי בסיסי על Redis + OpenAI Embeddings — 2–3 ימים. עם כיוונון סף על נתונים אמיתיים וניטור שיעור פגיעה — 3–5 ימים. אם נדרשת אינטגרציה לתשתית ניידת קיימת, צרו קשר להערכה. כמו כן, הזמינו ביקורת על עלויות ה-AI הנוכחיות שלכם — נחשב חיסכון פוטנציאלי ונציע ארכיטקטורה לעומס שלכם. קבלו ייעוץ ממהנדס שכבר פרס פתרונות כאלה.

מקור: תיעוד Redis Stack