חיפוש וקטורי במאגר ידע נייד: pgvector, Embeddings, HNSW

בפיתוח מובייל עולה בעיה נפוצה: משתמש מקליד שאילתה כמו 'איך לשחזר גישה' והמערכת מחזירה מסך ריק. חיפוש תת-מחרוזת רגיל נכשל עם מילים נרדפות, שגיאות כתיב וניסוחים שונים. חיפוש וקטורי פותר זאת: הוא מוצא מסמכים דומים סמנטית, לא התאמות מדויקות. 'שחזור גישה' → 'איפוס סיסמה' → המאמר הדרוש נמצא במילישניות. במשך 5 שנים יישמנו חיפוש כזה ביותר מ-20 פרויקטים של iOS ואנדרואיד, ועכשיו אנחנו חולקים ניסיון מעשי.

לפי תיעוד pgvector, ניתן ליישם חיפוש סמנטי באמצעות אינדקסים HNSW ו-IVFFlat, המספקים מהירות גבוהה גם על מיליוני וקטורים.

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

כל קטע טקסט מומר לוקטור — מערך מספרים עם ממד 384, 768 או 1536 (תלוי במודל). טקסטים דומים סמנטית הם בעלי וקטורים קרובים. חיפוש משמעותו מציאת הוקטורים הקרובים ביותר לשאילתה (חיפוש שכן קרוב מקורב, ANN).

בפועל, הצינור נראה כך:

1. המשתמש מזין שאילתה באפליקציית המובייל.
2. הלקוח שולח את השאילתה לשרת האחורי.
3. השרת האחורי מייצר embedding דרך API (OpenAI, Cohere) או מודל מקומי.
4. מסד הנתונים הווקטורי מחזיר את קטעי ה-top-K הקרובים ביותר.
5. התוצאות מועברות ל-LLM לסיכום או מוחזרות ישירות.

כל הצינור עד שלב 4 אורך 50–300 אלפיות שנייה — מקובל לחוויית משתמש במובייל. לשם השוואה, pgvector מחזיר תוצאות בממוצע ב-100 אלפיות שנייה, מהיר פי 3 מ-Pinecone עם אותו אינדקס HNSW על קבוצה של 500,000 מסמכים.

למה pgvector עדיף לפרויקטי מובייל

pgvector הוא הרחבה של PostgreSQL שמוסיפה תמיכה באינדקסים וקטוריים. אם כבר יש לכם PostgreSQL, זה אפס תשתית נוספת. אנחנו משתמשים בו ב-80% מהפרויקטים שבהם נפח המסמכים אינו עולה על מיליון. הטבלה שלהלן משווה פתרונות פופולריים:

pgvector תומך באינדקסים HNSW ו-IVFFlat. HNSW מספק דיוק ומהירות חיפוש טובים יותר אך דורש יותר זיכרון במהלך הבנייה. עבור מאגרי ידע עד 500,000 מסמכים, HNSW עובד היטב מחוץ לקופסה.

-- Создание HNSW-индекса для cosine distance
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64);

-- Поиск топ-5 ближайших
SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM documents
ORDER BY embedding <=> $1
LIMIT 5;

-- Создание HNSW-индекса для cosine distance CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64); -- Поиск топ-5 ближайших SELECT id, content, 1 - (embedding <=> $1) AS similarity FROM documents ORDER BY embedding <=> $1 LIMIT 5; הוא מרחק קוסינוס. עבור וקטורים מנורמלים, ניתן להשתמש במכפלה פנימית (<=>), אבל <#> עובד ללא נורמליזציה.

איך לייצר embeddings במכשיר נייד?

ישנן שתי גישות: בצד השרת ובצד הלקוח. צד השרת עדיף לרוב היישומים — מודלי embedding שוקלים 80–500 MB, הסקה מקומית מרוקנת סוללה, ומפתחות API אינם חשופים מה-APK. היוצא מן הכלל הוא תרחיש לא מקוון לחלוטין, כמו אפליקציה ארגונית לעבודה ללא אינטרנט. ב-iOS אנחנו משתמשים ב-Core ML (המרה דרך <=>), באנדרואיד — ONNX Runtime. דוגמה: coremltools ב-ONNX שוקל ~22 MB ומייצר וקטורים בממד 384 המספיקים לחיפוש תיעוד.

להלן השוואה של מודלי embedding פופולריים לשימוש במובייל:

סינון מטא-דאטה — מלכודות

חיפוש וקטורי ללא מסננים סורק את כל האינדקס. אם צריך להגביל את היקף החיפוש (למשל, רק מסמכים עבור מוצר X ברוסית), הוסיפו מסננים:

SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM documents
WHERE language = 'ru'
  AND category = 'installation'
  AND updated_at > NOW() - INTERVAL '1 year'
ORDER BY embedding <=> $1
LIMIT 10;

חשוב: pgvector מבצע סינון לאחר חיפוש וקטורי בעת שימוש ב-HNSW/IVFFlat. עבור מסננים סלקטיביים מאוד (בחירת < 10% שורות), זה יכול להוביל לתוצאות ריקות — יש לבנות אינדקסים נפרדים לכל תת-קבוצה או להשתמש ב-HNSW מחולק, שאנחנו מגדירים לפי הצורך.

מה כלול ביישום

• ביקורת של מאגר הידע הקיים: מבנה, נפח, סוגי תוכן.
• בחירת מודל embedding וממד (384/768/1536) לתרחיש שלכם.
• הגדרת pgvector: יצירת אינדקס, אופטימיזציה של all-MiniLM-L6-v2 ו-SELECT id, content, 1 - (embedding <=> $1) AS similarity FROM documents WHERE language = 'ru' AND category = 'installation' AND updated_at > NOW() - INTERVAL '1 year' ORDER BY embedding <=> $1 LIMIT 10; .
• פיתוח צינור קליטה — חלוקה אוטומטית ווקטוריזציה של מסמכים.
• API חיפוש עם תמיכה בסינון, דפדוף ומיון.
• אינטגרציה עם ממשק המשתמש במובייל (שורת חיפוש, תוצאות, פירורי לחם).
• בדיקות איכות: precision@K, recall@K, בדיקות A/B.
• אופטימיזציה למצב לא מקוון אם נדרש.
• תיעוד והעברת קוד מקור.

ציר זמן ואיך להתחיל

חיפוש וקטורי עבור קורפוס של עד 50,000 מסמכים עם pgvector — 2–4 שבועות. עם מודל embedding מותאם אישית, דירוג מחדש ותמיכה רב-לשונית — 5–8 שבועות. העלות מחושבת באופן אישי לאחר ניתוח מאגר הידע שלכם.

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