pgvector לעומק — בניית Semantic Search בתוך PostgreSQL

מאת צוות מדיה דיל · 09.08.2026 · AI · 9 דק׳

מדריך טכני מעמיק ל-pgvector: הגדרת עמודת וקטור ב-PostgreSQL, בחירה בין HNSW ל-IVFFlat, שילוב עם Full-text search ל-Hybrid Search, וטעויות ביצועים נפוצות.

צוות שכבר מריץ PostgreSQL בפרודקשן, ופתאום צריך חיפוש סמנטי - עומד בפני החלטה: להוסיף מסד נתונים וקטורי ייעודי נפרד, עם כל התפעול, הגיבוי וה-monitoring שכרוכים בזה, או להרחיב את מה שכבר קיים. pgvector הוא Extension ל-PostgreSQL שמוסיף סוג עמודה חדש - vector - ואת כל התשתית הנדרשת לאחסון, אינדוקס וחיפוש דמיון ישירות בתוך מסד הנתונים הרגיל. עבור מרבית מערכות ה-RAG וה-Semantic Search בקנה מידה בינוני, זו הדרך הפשוטה והבטוחה ביותר להתחיל - בלי לוותר על שקיפות תפעולית, גיבויים, וטרנזקציות SQL רגילות.

התקנה והגדרת עמודת וקטור

ההתקנה עצמה פשוטה יחסית - pgvector זמין כ-Extension בכל ספק PostgreSQL מנוהל מרכזי, וההפעלה דורשת פקודה בודדת. לאחר מכן, הגדרת עמודה וקטורית היא פשוט הוספת עמודה מסוג vector עם ממד קבוע מראש - הממד חייב להתאים בדיוק לממד הפלט של מודל ה-Embeddings שנבחר, ולא ניתן לשנות אותו מבלי ליצור עמודה חדשה.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id bigserial PRIMARY KEY,
  content text NOT NULL,
  metadata jsonb,
  embedding vector(1536)
);

נקודה שקל לפספס: עמודת vector ללא אינדקס עדיין עובדת - שאילתות דמיון פשוט ירוצו כחיפוש מדויק (Brute-force) על כל הטבלה. זה בסדר גמור בסביבת פיתוח או על טבלאות קטנות, אבל הופך לצוואר בקבוק אמיתי כשמדובר במאות אלפי שורות ומעלה. הוספת אינדקס היא צעד נפרד ומודע, לא משהו שקורה אוטומטית.

HNSW מול IVFFlat ב-pgvector - איזה אינדקס ומתי

pgvector תומך בשני סוגי אינדקס ANN, בדיוק כמו שתואר במדריך ארכיטקטורת Vector Database הכללי: HNSW ו-IVFFlat. ההמלצה הרווחת כיום היא HNSW כברירת מחדל - הוא נותן דיוק גבוה יותר ברוב מקרי השימוש, ולא דורש "אימון" מקדים (unlike IVFFlat, שדורש שתהיה כבר כמות מסוימת של נתונים בטבלה לפני בניית האינדקס כדי שהאשכולות ייבנו נכון).

-- אינדקס HNSW על מרחק Cosine
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);

-- שאילתת דמיון - 10 המסמכים הקרובים ביותר
SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM documents
ORDER BY embedding <=> $1
LIMIT 10;

האופרטור <=> מחשב מרחק Cosine; יש גם <-> ל-Euclidean ו-<#> ל-Dot Product (עם סימן הפוך, כי PostgreSQL ממיין רק בסדר עולה). בחירת האופרטור צריכה להתאים לסוג ה-vector_ops שהאינדקס נבנה עליו - אינדקס שנבנה עם vector_cosine_ops ולא ישמש שאילתה עם <-> ביעילות, כי האינדקס בנוי סביב המדד שהוגדר לו מראש.

כיול ef_search לשאילתה בודדת

בדיוק כמו שתואר במדריך הכללי על HNSW, גם ב-pgvector ניתן לכייל את פרמטר ef_search ברמת סשן או שאילתה בודדת, בלי לבנות מחדש את כל האינדקס:

SET hnsw.ef_search = 100; -- דיוק גבוה יותר, איטי יותר
-- ברירת מחדל היא 40; אפשר להעלות זמנית לשאילתות שדורשות דיוק מקסימלי

Hybrid Search בתוך Postgres - tsvector ווקטורים באותה שאילתה

אחד היתרונות הגדולים ביותר של pgvector הוא היכולת לשלב Hybrid Search - חיפוש וקטורי וחיפוש מילות מפתח - בתוך אותה שאילתת SQL, בלי לתאם בין שתי מערכות נפרדות. PostgreSQL כולל מנוע חיפוש טקסט מלא (Full-text search) מובנה מבוסס tsvector, שאפשר לשלב עם עמודת הוקטור באותה טבלה:

ALTER TABLE documents ADD COLUMN content_tsv tsvector
  GENERATED ALWAYS AS (to_tsvector('english', content)) STORED;

CREATE INDEX ON documents USING gin (content_tsv);

-- שילוב RRF פשוט בין שתי השיטות ב-CTE
WITH vector_results AS (
  SELECT id, row_number() OVER (ORDER BY embedding <=> $1) AS rank
  FROM documents ORDER BY embedding <=> $1 LIMIT 50
),
text_results AS (
  SELECT id, row_number() OVER (ORDER BY ts_rank(content_tsv, query) DESC) AS rank
  FROM documents, plainto_tsquery('english', $2) query
  WHERE content_tsv @@ query LIMIT 50
)
SELECT COALESCE(v.id, t.id) AS id,
  COALESCE(1.0/(60+v.rank),0) + COALESCE(1.0/(60+t.rank),0) AS score
FROM vector_results v FULL OUTER JOIN text_results t ON v.id = t.id
ORDER BY score DESC LIMIT 10;

חשוב לשים לב: תצורת השפה ב-to_tsvector קובעת stemming ו-tokenization - שימוש ב-'english' על תוכן עברי ייתן תוצאות גרועות. עבור עברית, כדאי לבדוק תצורות ייעודיות או להסתמך יותר על הרכיב הווקטורי, שפחות תלוי בהתאמת שפה מדויקת.

Filtering משולב עם WHERE רגיל

יתרון תפעולי נוסף: מכיוון שהחיפוש הווקטורי הוא חלק מ-SQL רגיל, שילוב עם תנאי WHERE - Filtering לפי מטא-דאטה, הרשאות, תאריכים - הוא טבעי לחלוטין ולא דורש שכבת אינטגרציה נפרדת:

SELECT id, content FROM documents
WHERE metadata->>'department' = 'sales'
  AND created_at > now() - interval '90 days'
ORDER BY embedding <=> $1
LIMIT 10;

יש לשים לב לסדר הביצוע: PostgreSQL לא בהכרח מריץ את הסינון לפני החיפוש הווקטורי - ה-query planner מחליט על סדר הביצוע האופטימלי, ולפעמים תנאי סינון עם selectivity נמוכה (שמשאירים חלק גדול מהטבלה) יגרמו לתכנון גרוע יותר מהצפוי. שווה לבדוק את תוכנית הביצוע עם EXPLAIN ANALYZE על שאילתות עם filtering משמעותי, במיוחד כשהתנאי מצמצם דרסטית את המאגר - במקרה כזה ייתכן שכדאי לשקול אינדקס מורכב יותר או partial index על תת-קבוצת הנתונים הרלוונטית.

ביצועים בקנה מידה - מתי pgvector מספיק ומתי לא

pgvector מתפקד מצוין למאגרים בסדר גודל של עד כמה מיליוני רשומות על חומרה סבירה, במיוחד כשמנוהל נכון עם אינדקס HNSW מכויל. מעבר לזה - עשרות ומאות מיליוני רשומות - ההגבלות של הרצה בתוך תהליך PostgreSQL רגיל (ניהול זיכרון משותף עם שאר עומס העבודה על אותו מסד נתונים, מגבלות על מקביליות בבניית אינדקס) מתחילות להיות מורגשות יותר מאשר במנוע ייעודי שנבנה מהיסוד סביב חיפוש וקטורי בלבד.

יתרון תפעולי משמעותי שנשמר לאורך כל הטווח: כל הגיבויים, ה-replication, וה-point-in-time recovery של PostgreSQL עובדים "בחינם" גם על נתוני הווקטורים - אין צורך בפתרון גיבוי נפרד למערכת החיפוש. עבור צוותי תשתית קטנים יחסית, זה שיקול מכריע לעיתים יותר מהבדלי ביצועים תיאורטיים.

Connection Pooling ו-Read Replicas לחיפוש בקנה מידה

כשעומס שאילתות החיפוש הווקטורי גדל, שני כלים קלאסיים מעולם ה-PostgreSQL עוזרים בלי צורך בשינוי ארכיטקטורה מהותי. Connection pooling (למשל דרך PgBouncer) מונע מצב שבו כל שאילתת חיפוש פותחת חיבור חדש למסד הנתונים - פתיחת חיבור היא יקרה יחסית, ותחת עומס גבוה של שאילתות embedding קצרות אך תכופות, ה-overhead הזה יכול להוות חלק ניכר מזמן התגובה הכולל. Read replicas מאפשרים להפנות שאילתות חיפוש (שהן קריאה בלבד) לעותקים נפרדים של מסד הנתונים, ולשמור את המופע הראשי (Primary) פנוי לכתיבות ועדכוני embeddings - הפרדה שמונעת מצב שבו עדכון המוני של וקטורים "חונק" את ביצועי החיפוש בזמן אמת עבור משתמשים.

חשוב לזכור שאינדקס HNSW חייב להיות מסונכרן בין ה-Primary ל-Replicas - ב-PostgreSQL סטנדרטי זה קורה אוטומטית דרך streaming replication, אבל שווה לוודא שגרסת pgvector זהה בכל המופעים, כי אי-התאמת גרסאות בין Primary ל-Replica עלולה ליצור התנהגות לא צפויה באינדקס.

תחזוקת אינדקס - VACUUM ו-Re-index

נקודה שרבים מזניחים: אינדקס HNSW ב-pgvector, כמו כל אינדקס PostgreSQL, נפגע מעדכונים ומחיקות תכופות. עדכון תדיר של embeddings (למשל בעקבות שינוי תוכן מסמכים) יוצר "מתים" (dead tuples) שדורשים VACUUM תקופתי כדי לפנות שטח ולשמור על ביצועי חיפוש יציבים. בטבלאות עם קצב עדכון גבוה, כדאי לוודא ש-autovacuum מכויל בצורה אגרסיבית מספיק, ולא להסתמך על ברירת המחדל שתוכננה עבור עומסי עבודה כלליים ולא עבור טבלאות וקטוריות בעלות שינוי גבוה.

מעבר ל-VACUUM שגרתי, יש מקרים שבהם בנייה מחדש מלאה של אינדקס HNSW (REINDEX) עדיפה - בעיקר אחרי מחיקות המוניות שמשאירות את הגרף עם הרבה "חורים", או אחרי שינוי פרמטרים כמו M שדורש מבנה גרף שונה מהיסוד. בניית אינדקס HNSW על טבלה גדולה היא פעולה יקרה שצורכת זיכרון ו-CPU משמעותיים, ולכן כדאי לתזמן אותה בשעות עומס נמוך ולא כפעולה ספונטנית באמצע יום עבודה.

בחירת ממד וסוג מרחק בזמן תכנון סכימה

החלטה שקל לזלזל בחשיבותה בשלב התכנון: ממד עמודת ה-vector נקבע פעם אחת ביצירת הטבלה, ושינוי שלו בעתיד דורש בפועל יצירת עמודה חדשה, re-embedding מלא של הנתונים, ומעבר הדרגתי - לא פעולת ALTER COLUMN פשוטה. לכן כדאי להקדיש זמן מראש לבחירת מודל ה-embedding וממדו לפני כתיבת סכימת הטבלה, ולא להניח שאפשר "לשנות אחר כך בקלות". אותו דבר נכון לגבי סוג המרחק (Cosine, L2, Dot Product) - האינדקס נבנה סביב אופרטור ספציפי, ומעבר לאופרטור אחר דורש בניית אינדקס חדש מהיסוד, לא רק שינוי בשאילתה.

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

טעויות נפוצות בעבודה עם pgvector

• שכחת אינדקס לגמרי - הרצת שאילתות דמיון על טבלה גדולה בלי אינדקס HNSW או IVFFlat, מה שמריץ Brute-force בשקט בלי אזהרה.
• אי-התאמה בין vector_ops לאופרטור השאילתה - בניית אינדקס עם vector_l2_ops ואז שימוש באופרטור Cosine בשאילתה, מה שמונע מהאינדקס לשמש ביעילות.
• הזנחת EXPLAIN ANALYZE - לא בודקים בפועל אם ה-query planner משתמש באינדקס, ומגלים בעיה רק כשה-latency בפרודקשן גבוה בהפתעה.
• שימוש בברירת מחדל של ef_search בלי כיול - לא בודקים את הטרייד-אוף בין דיוק למהירות עבור מקרה השימוש הספציפי.

דוגמה מהשטח - כשה-query planner החליט לא להשתמש באינדקס

בפרויקט שכלל מערכת RAG פנימית על גבי pgvector, הצוות בנה אינדקס HNSW כמו שצריך, אך גילה שחלק מהשאילתות עדיין רצות באיטיות חריגה. בדיקה עם EXPLAIN ANALYZE חשפה ש-query planner בחר לא להשתמש באינדקס בכלל עבור שאילתות מסוימות שכללו סינון מטא-דאטה עם selectivity נמוכה מאוד - כשהתנאי הנוסף השאיר רוב הטבלה רלוונטית, ה-planner העריך ש-scan מלא זול יותר מ-scan דרך האינדקס ואז סינון. הפתרון כלל שילוב של אינדקס מורכב (composite index) על שדה המטא-דאטה הנפוץ ביותר לסינון, יחד עם עדכון סטטיסטיקות הטבלה (ANALYZE) שהיו מיושנות ולכן הטעו את ה-planner. הלקח: אינדקס וקטורי קיים לא מבטיח שהוא בפועל בשימוש בכל שאילתה - צריך לאמת את זה במפורש, במיוחד כששילוב עם filtering נכנס לתמונה.

שאלות נפוצות

האם pgvector דורש מסד נתונים נפרד?

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

מה ההבדל בין HNSW ל-IVFFlat ב-pgvector?

HNSW נותן דיוק גבוה יותר ולא דורש נתונים מקדימים לבניית האינדקס; IVFFlat חסכוני יותר בזיכרון אך דורש כמות נתונים מסוימת מראש לאשכולות איכותיים.

איך משלבים Hybrid Search ב-pgvector?

באמצעות שילוב עמודת tsvector לחיפוש טקסט מלא עם עמודת vector לחיפוש דמיון, ואיחוד תוצאות בשאילתת SQL אחת בגישת RRF, כפי שמתואר במדריך Hybrid Search.

מתי pgvector מפסיק להספיק?

בדרך כלל מעבר לעשרות-מאות מיליוני רשומות, כשההגבלות של ריצה בתוך תהליך PostgreSQL רגיל מתחילות לפגוע בביצועים לעומת מנוע ייעודי.

האם צריך VACUUM מיוחד לעמודות וקטוריות?

לא מיוחד, אבל בטבלאות עם עדכוני embeddings תכופים כדאי לוודא ש-autovacuum מכויל אגרסיבי מספיק כדי למנוע הצטברות dead tuples שפוגעת בביצועי האינדקס.

שילוב נכון של pgvector בתשתית PostgreSQL קיימת יכול לחסוך שכבת תשתית שלמה בלי לוותר על ביצועים. מדיה דיל בונה מערכות AI ותשתית פרודקשן מהיסוד הנכון - דברו איתנו בוואטסאפ.

תגיות: pgvector · PostgreSQL · Vector Database · HNSW · Semantic Search · Hybrid Search · SQL

← חזרה לבלוג · צור קשר