جست‌وجوی معنایی با PostgreSQL و pgvector؛ از مدل تا ایندکس

چه زمانی جست‌وجوی برداری به کار می‌آید؟

کاربری که می‌نویسد «شرایط مرجوع کردن کالا» شاید در سندی پاسخ بگیرد که عنوانش «ضوابط بازگشت سفارش» است. جست‌وجوی کلمه‌ای همیشه این ارتباط را پیدا نمی‌کند. جست‌وجوی معنایی متن را به یک بردار عددی تبدیل می‌کند و شباهت بردارها را می‌سنجد. pgvector این مسیر را داخل PostgreSQL فراهم می‌کند؛ بنابراین برای یک نمونه محدود، داده توصیفی و بردار سند می‌توانند کنار هم مدیریت شوند. این انتخاب زمانی ارزش دارد که تیم از قبل PostgreSQL را اداره می‌کند و حجم و زمان پاسخ با امکانات آن سازگارند.

بردار جایگزین سند و مجوز نیست. همچنان باید متن اصلی، شناسه سازمان، نسخه سند و نشانی منبع را نگه دارید. مدل embedding باید برای زبان فارسی و نوع متن شما آزمایش شود؛ یک مدل مناسب اسناد انگلیسی الزاماً اصطلاحات محصول یا نیم‌فاصله فارسی را خوب پوشش نمی‌دهد. مدل مورد استفاده برای پرسش و سند باید یکسان و ابعاد خروجی ثابت باشد. در مثال از سه بُعد ساختگی استفاده کرده‌ایم تا SQL قابل فهم بماند؛ این اعداد مدل واقعی نیستند.

پیاده‌سازی را از کیفیت داده شروع کنید

قبل از تولید بردار، سندهای تکراری و نسخه‌های منقضی را جدا کنید. برای یک راهنمای بلند، هر قطعه را با عنوان بخش و شناسه سند ذخیره کنید تا نتیجه قابل ردیابی باشد. قطعه بسیار کوتاه زمینه را از دست می‌دهد و قطعه بسیار بزرگ چند موضوع را مخلوط می‌کند. پیشنهاد تحریریه این است که ابتدا دو اندازه قطعه را روی پرسش‌های واقعی مقایسه کنید؛ از انتخاب یک عدد ثابت صرفاً به دلیل رایج بودن آن پرهیز کنید و منبع پاسخ را در خروجی حفظ کنید.

کوئری دقیق، فاصله را میان پرسش و همه بردارهای مرتبط محاسبه می‌کند. در داده بزرگ‌تر، HNSW یا IVFFlat می‌تواند زمان جست‌وجو را کاهش دهد، اما نتیجه تقریبی است و باید کیفیت بازیابی را بسنجید. ایندکس باید با عملگر فاصله هماهنگ باشد؛ در این مثال فاصله کسینوسی و vector_cosine_ops کنار هم قرار دارند. فیلتر سازمان را پیش از نمایش نتیجه اعمال کنید. در جست‌وجوی تقریبی همراه با فیلتر، ممکن است نتیجه کمتر از حد درخواستی شود؛ فقط زیاد کردن LIMIT مشکل را لزوماً حل نمی‌کند.

برای ارزیابی، مجموعه‌ای از پرسش‌ها بسازید که پاسخ درستشان را می‌دانید: عبارت دقیق، مترادف، غلط تایپی، نام محصول و پرسش بدون جواب. در هر آزمایش بررسی کنید سند مناسب در پنج نتیجه اول هست یا نه و زمان پاسخ صدک ۹۵ چقدر است. اگر شناسه یا کد کالا اهمیت دارد، جست‌وجوی کلمه‌ای را کنار برداری نگه دارید. نسخه ترکیبی را با همان مجموعه بسنجید؛ کیفیت را از چند پاسخ جذاب به دستیار نتیجه نگیرید. تغییر مدل به معنی نیاز به بازتولید و نسخه‌بندی بردارهاست.

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE demo_documents (
  id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  tenant_id integer NOT NULL,
  title text NOT NULL,
  embedding vector(3) NOT NULL
);
INSERT INTO demo_documents (tenant_id,title,embedding) VALUES
  (1,'Return policy','[1,0,0]'),
  (1,'Shipping guide','[0,1,0]'),
  (2,'Private policy','[0.99,0.01,0]');
CREATE INDEX ON demo_documents
  USING hnsw (embedding vector_cosine_ops);
SELECT id,title,1-(embedding <=> '[1,0,0]') AS similarity
FROM demo_documents
WHERE tenant_id=1
ORDER BY embedding <=> '[1,0,0]'
LIMIT 5;

قبل از گسترش چه چیزی را اندازه بگیریم؟

یک پایلوت عملی می‌تواند از اسناد یک واحد، جست‌وجوی فقط‌خواندنی و چند کاربر مشخص شروع شود. گزارش آزمایش باید مدل، ابعاد بردار، تعداد اسناد، تنظیم ایندکس، محدودیت مجوز و پرسش‌های شکست‌خورده را ثبت کند. پس از سنجش هزینه به‌روزرسانی و بازیابی، درباره گسترش تصمیم بگیرید. موفقیت این پروژه پیدا کردن نزدیک‌ترین عدد نیست؛ رساندن کاربر به سند معتبر، قابل استفاده و مجاز است. برای همین، بازخورد کاربر و باز شدن منبع اصلی باید بخشی از معیار پذیرش باشند.

توضیح‌ها و پیشنهادهای اجرایی این مطلب، تحلیل تحریریه دانشنامه لیان هستند.منابع: pgvector — official documentation

این مطلب بازنویسی تحلیلی دانشنامه لیان بر پایه منبع اصلی است.مشاهده منبع اصلی