جایگزینی میانگین‌گیری با بردارهای تک‌نما، دقت تطابق تصاویر را به ۹۷٪ رساند

امتیاز ۰.۹۲۵۹؛ عددی که باعث شد یک تطابق کامل، در برابر آستانه ۰.۹۳ شکست بخورد. این کشف توسط یک مؤسس انفرادی در بازارچه مد آذربایجان رخ داد که نشان داد چگونه یک باگ ساده در میانگین‌گیری در یک پایگاه‌داده برداری می‌تواند باعث شود تصویری کاملاً یکسان، تست تطابق دقیق را رد کند. طبق گزارش فنی مفصلی که در ۱۴ اوت ۲۰۲۶ منتشر شد، این شکست فاش کرد که چگونه یک خطای محاسباتی کوچک می‌تواند دقت سیستم‌های بازیابی بصری را نابود کند.

جست‌وجوی بصری اغلب بر بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه یا تصویر که می‌گوید این مورد «همسایه‌ی» چه چیزهای دیگری است — تکیه می‌کند تا محصولات مشابه را بیابد. اکثر آموزش‌های موجود پیشنهاد می‌کنند برای هر محصول، میانگین تمام عکس‌ها گرفته شود تا یک بردار «اصلی» ساخته شود. در حالی که این روش برای طبقه‌بندی کلی (Classification) جواب می‌دهد، اما اثر «رقیق‌سازی» ایجاد می‌کند که دقت را در پرس‌وجوهای خاص (Specific Queries) می‌کشد.

همان‌طور که در تحلیل قبلی ما درباره‌ی شناسایی باگ‌های ردیابی هزینه در Gemini اشاره کردیم، این مورد یک شکست نامرئی دیگر را برجسته می‌کند: شکاف معماری بین اینکه هوش مصنوعی یک شیء را «طبقه‌بندی» کند یا یک مورد خاص را «بازیابی» (Retrieve) نماید.

دروازه و خط لوله تشخیص

هر تصویر آپلود شده ابتدا به مدل Gemini Flash-Lite می‌رسد. این «دروازه» فقط نمی‌پرسد که آیا تصویر یک محصول است یا خیر؛ بلکه یک شیء JSON ساختاریافته برمی‌گرداند که شامل برند، شناسه‌های دسته‌بندی و جعبه‌های محصورکننده (bbox) برای آیتم‌های شناسایی شده است. ساختار این JSON شامل فیلدهای is_product و brand و یک آرایه از items است که هر آیتم شامل name_az (نام آذربایجانی)، name_ru (نام روسی)، color_az (رنگ)، category_public_id (شناسه دسته)، subcategory_public_id (شناسه زیردسته)، variant_item_public_ids (شناسه‌های متغیر)، bbox (مختصات جعبه)، و پرچم‌های partial (جزئی) و primary (اصلی) است.

برای تضمین دقت، مؤسس این سیستم یک خلاصه ۳۰۰۰ توکنی از تاکسونومی زنده کاتالوگ را به پرامپت تزریق می‌کند. این خلاصه که شامل دسته‌ها، زیردسته‌ها و واژگان متغیر است، هر ۱۲ ساعت در Redis کش می‌شود. این کار مدل را مجبور می‌کند به‌جای برچسب‌های متنی آزاد، شناسه‌های واقعی پایگاه‌داده را برگرداند. این استراتژی نیاز به لایه تطبیق رشته‌ای تقریبی (Fuzzy String-Matching) را از بین می‌برد و برچسب‌های آیتم را در هر چهار زبان رابط کاربری به‌صورت رایگان فراهم می‌کند.

دو قانون سخت‌گیرانه در این مرحله حاکم است:

• اولویت آیتم اصلی: مدل «ستاره» عکس را شناسایی می‌کند. برای مثال، اگر مدلی یک کیف سفید در دست دارد اما بلوزی بزرگ‌تر پوشیده است، کیف به عنوان آیتم اصلی علامت‌گذاری می‌شود، نه بلوز.
• قانون رؤیت ۹۰ درصدی: هر آیتمی که بیش از ۱۰٪ از کادر بیرون باشد یا بریده شده باشد، به عنوان partial: true ثبت می‌شود. این موارد در رابط کاربری به عنوان برچسب نمایش داده می‌شوند اما هرگز برش نمی‌خورند و هرگز برای جست‌وجوی برداری واقعی استفاده نمی‌شوند. این قانون به تنهایی دسته‌ای کامل از نتایج زباله را حذف کرد.

اگر فراخوانی دروازه با خطا مواجه شود یا زمانش تمام شود (Timeout)، سیستم به‌گونه‌ای طراحی شده که «باز» بماند (Fail-open) و اجازه دهد جست‌وجو بدون راهنماهای متنی ادامه یابد. هزینه این مرحله، شامل هزینه خلاصه کاتالوگ، حدود ۰.۰۰۲ دلار برای هر جست‌وجو است.

حل مشکل عدم تقارن

یک عدم تطابق بنیادی بین عکس‌های کاتالوگ (که حرفه‌ای و تمام‌کادر هستند) و پرس‌وجوهای کاربر (که اغلب اسکرین‌شات‌های برش‌خورده هستند) وجود دارد. یک پرس‌وجوی برش‌خورده در واقع تکه‌ای زوم شده است که هنگام مقایسه با بردارهای محصول کامل، منجر به «انحراف اثر انگشت» (Drifted Fingerprints) می‌شود.

برای رفع این مشکل، سیستم تصویر را دو بار تبدیل به بردار می‌کند:

• برش (Crop): جعبه محصورکننده اصلی با ۵٪ حاشیه (Padding) برش می‌خورد. اگر جعبه از قبل بیش از ۸۵٪ کادر را پوشانده باشد، از برش صرف‌نظر می‌شود زیرا تصویر از قبل متمرکز است.
• تصویر کامل: بایت‌های تصویر اصلی بدون توجه به هر چیزی تبدیل به بردار می‌شوند.

با استفاده از gemini-embedding-2، سیستم دو جست‌وجوی kNN (نزدیک‌ترین همسایه) با ۴۰ کاندید برای هر کدام اجرا می‌کند. سپس نتایج را با تابع merge_max_by_product ادغام کرده و بهترین امتیاز را برای هر محصول برمی‌دارد. این «بیمه» حدود ۰.۰۰۰۱۲ دلار هزینه دارد اما تقریباً تمام پرس‌وجوهای اسکرین‌شاتی را نجات می‌دهد.

باگ میانگین‌گیری و اصلاح Max-Merge

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

در تست مؤسس، یک لباس عکس‌های جلو و پشت داشت. آپلود عکس پشت، پرس‌وجویی ایجاد کرد که دقیقاً روی مختصات «عکس پشت» بود، اما امتیاز آن در برابر نقطه میانی ذخیره شده تنها ۰.۹۲۵۹ بود. چون آستانه روی ۰.۹۳ تنظیم شده بود، تصویر یکسان به دلیل رقیق شدن، از خط تطابق دقیق پایین افتاد. این باعث شد محصولات تک‌عکس عالی عمل کنند اما محصولات چهارعکس مدام شکست بخورند و تجربه کاربری «ناپایدار» ایجاد شود.

راهکار این بود که ذخیره بردارهای تک‌تک عکس‌ها متوقف نشود. طرح جدید از مدل VisualImageEmbedding در PostgreSQL با pgvector استفاده می‌کند. انتخاب این ابزار بر اساس نیاز به تعادل میان سادگی پیاده‌سازی و کارایی بود، موضوعی که در مقایسه pgvector با دیتابیس‌های تخصصی مانند Qdrant و Milvus به تفصیل بررسی شده است:

• فیلدها: product (کلید خارجی)، color_combination (کلید خارجی)، source (منبع: اصلی/گالری/cc)، image_ref (مسیر ذخیره‌سازی به عنوان کلید حذف تکرار طبیعی)، و embedding (فیلد برداری با ۱۵۳۶ بُعد).
• محدودیت‌ها: یک UniqueConstraint روی محصول و مرجع تصویر از ایجاد ردیف‌های تکراری جلوگیری می‌کند.

در زمان پرس‌وجو، سیستم kNN را روی تمام نماها اجرا کرده و امتیاز محصول را بر اساس بهترین تطابق تک‌نمای آن (max-merge) تعیین می‌کند. پس از این تغییر، تست «بی‌رحمانه» تصویر یکسان از ۰.۹۲۵۹ به ۰.۹۷۴۳ جهش کرد و جایگاه اول را گرفت.

تبدیل مجدد کاتالوگ شامل ۹۰۶ محصول و ۳۰۱ ترکیب رنگ بود که در مجموع حدود ۰.۲۵ دلار هزینه داشت. این فرآیند از بررسی‌های upsert روی محصول، مرجع تصویر و model_id استفاده کرد تا از فراخوانی‌های تکراری API جلوگیری شود و بردارهای ذخیره شده قبلی بازیافت شوند.

رتبه‌بندی و «قانون طلایی»

شباهت کسینوسی (Cosine Similarity) نسبت به دسته‌بندی‌ها کور است. بدون مرحله استدلال، سیستم ممکن است یک ست مانیکور را کنار یک کرم صورت قرار دهد، صرفاً چون هر دو «اشیاء کوچکی روی پس‌زمینه سفید» هستند.

برای حل این مشکل، سیستم از مرکزهای ثقل (Centroids) تصویری برای طبقه‌بندی استفاده می‌کند. هر دسته، زیردسته و جنسیت یک مرکز ثقل دارد که میانگین بردارهای تصاویر محصولات آن دسته است. پرس‌وجو در یک مرحله در برابر حدود ۷۰ مرکز ثقل طبقه‌بندی می‌شود. در یک تست «حذف یکی» (Leave-one-out) روی ۵۸۳ محصول تولیدی، این روش به ۸۴.۷٪ صحت در دسته‌بندی و ۹۵.۹٪ در جنسیت رسید که حدود ۷ امتیاز از روش رای‌گیری همسایگی (Neighbor-vote) بهتر بود.

فرآیند ساخت مرکز ثقل:

• یک شغل زمان‌بندی شده هفتگی، میانگین بردارهای تمام محصولات «منتشر شده» را محاسبه می‌کند.
• برای ایجاد یک مرکز ثقل، حداقل ۳ نمونه (min_samples=3) لازم است؛ در غیر این صورت سیستم به رای‌گیری بازمی‌گردد.
• این روش نیاز به حلقه‌های آموزشی پیچیده یا جلسات بررسی انحراف (Drift meetings) را از بین می‌برد.

با این حال، مؤسس یک «قانون طلایی» را برای جلوگیری از فیلتر بیش از حد توسط هوش مصنوعی اجرا کرد. این قانون پس از آن نوشته شد که عکس یک ست بیکینی به اشتباه از شبکه اصلی حذف شد چون دروازه آن را «بالاتنه بیکینی» دید اما کمیته رای به «لباس» داد.

قانون طلایی: هر کاندیدایی با امتیازی بالاتر از آستانه تطابق دقیق (۰.۹۳)، از تمام فیلترهای دسته‌بندی، محدوده تاکسونومی، بازآرایی رنگ یا کاهش رتبه اقلیت معاف است. یک تطابق ۹۳٪+ بر هر رای کمیته‌ای برتری دارد.

زیرساخت تولید و هزینه‌ها

کل این پشته روی Cloud SQL Postgres با ایندکس‌های HNSW اجرا می‌شود و چون روی همان نمونه (Instance) فروشگاه قرار دارد، نیاز به ذخیره‌ساز دوم را از بین می‌برد. برای بهینه‌سازی این لایه، درک فرمول‌های محاسبه هزینه حافظه و زمان ساخت ایندکس در pgvector برای رسیدن به حداکثر Recall ضروری است.

بهینه‌سازی‌های فنی:

• اسکن تکرار شونده: چون HNSW معمولی هنگام استفاده از فیلترها (مثل status='Published') نتایج را کمتر از حد مورد نیاز پر می‌کند، سیستم از hnsw.iterative_scan استفاده می‌کند تا محدودیت پر شود. این قابلیت در یک Context Manager با استفاده از SET LOCAL درون یک تراکنش پیچیده شده تا با PgBouncer سازگار باشد.
• مهاجرت‌های محافظت شده: ایندکس‌های HNSW درون RunPython با بررسی connection.vendor == "postgresql" ایجاد می‌شوند تا محیط‌های توسعه SQLite کرش نکنند.
• تأخیر: سه برابر شدن تعداد ردیف‌ها به دلیل ذخیره بردارهای هر نما، تأثیر قابل اندازه‌گیری روی تأخیر نداشت؛ سیستم صرفاً مجموعه‌ای از ردیف‌های نما را می‌گیرد و آن‌ها را در پایتون به محصولات متمایز ادغام می‌کند.

سنجش هزینه و مقیاس:

• هزینه کل: حدود ۰.۰۰۲ دلار برای هر جست‌وجو (دروازه + ۲ بردار).
• مقیاس کاتالوگ: ۹۰۶ محصول و ۳۰۱ ترکیب رنگ با هزینه ۰.۲۵ دلار.
• مرکزهای ثقل: حدود ۷۰ مورد (۱۷ دسته / ۵۰ زیردسته / ۳ جنسیت).

حالت‌های شکست و مشاهده‌پذیری

سیستم برای پایداری در تولید، به‌گونه‌ای طراحی شده که در صورت خطا، «باز» بماند (fail-open):

• خرابی دروازه: جست‌وجو بدون چیپ‌ها یا راهنماها ادامه می‌یابد.
• عدم دسترسی به خلاصه کاتالوگ: دروازه از طریق بلوک‌های try/except به پرسش‌های پایه تنزل می‌یابد.
• خطای API بردار: خطای ۵۰۳ برمی‌گرداند و اعتبارها فقط پس از تبدیل موفق مصرف می‌شوند.
• آپلود زباله: خطای ۴۲۲ برمی‌گرداند اما برای جلوگیری از سوءاستفاده از سهمیه (Quota abuse)، اعتبار کسر می‌شود.
• عدم تطابق بالای ۰.۷۸: به‌جای پر کردن شبکه با نتایج نامرتبط، وضعیت خالی صادقانه را نمایش می‌دهد.

مشاهده‌پذیری از طریق یک خط لاگ ساختاریافته برای هر جست‌وجو مدیریت می‌شود: [VS-RANK] hint=clothing src=gate rag_sub=48(Dresses) sub_score=0.845 margin=0.019 gender=women(0.83) mode=focused demoted=0 | n=12 | 19/48:0.8165, 19/48:0.9259...

دو درس حیاتی در لاگ‌گذاری آموخته شد: اول، همیشه max(scores) را به عنوان top_score ثبت کنید تا داده‌های کالیبراسیون مسموم نشوند. دوم، دیکشنری‌های با کلید پویا را به صورت یک رشته json.dumps در یک ستون رشته‌ای در BigQuery ذخیره کنید تا از ایجاد هزاران ستون جدید توسط auto-schema جلوگیری شود.

کارخانه انسان-در-حلقه

هر جست‌وجوی بصری به صف ناظران می‌رود. انسان‌ها دسته‌بندی، زیردسته، جنسیت و متغیرهای تشخیص داده شده توسط هوش مصنوعی را در برابر واژگان واقعی متغیرها تأیید یا اصلاح می‌کنند. همچنین تیک می‌زنند که کدام محصولات نمایش داده شده واقعاً مرتبط بوده‌اند.

این ردیف‌های بررسی شده از پاکسازی ۹۰ روزه معاف هستند و به یک مجموعه آموزشی دائمی و تأیید شده توسط انسان تبدیل می‌شوند. این رابط کاربری نظارت در واقع یک کارگاه برچسب‌گذاری است که داده‌های مورد نیاز برای کالیبراسیون آستانه، غنی‌سازی مرکزهای ثقل و Fine-tuning آینده را فراهم می‌کند.

این رویکرد از «قابلیت‌های متمایز نشده» جلوگیری می‌کند. مؤسس Vertex AI Search for Commerce را رد کرد چون ۴ تا ۶ برابر گران‌تر بود و قانون معافیت را نداشت. همچنین دیتابیس‌های برداری اختصاصی را برای تعداد $10^3$ محصول غیرضروری دانست. با استفاده از یک فضای برداری مشترک، ویژگی‌های آینده مثل «این کیف اما به رنگ قهوه‌ای» به یک ادغام ساده تبدیل می‌شود، نه یک مهاجرت داده‌ای.

گام بعدی شما

• اگر از میانگین‌گیری برای بردارهای چند-تصویری استفاده می‌کنید، فوراً آن را با استراتژی Max-Merge جایگزین کنید تا تطابق‌های دقیق را بازیابید.
• برای کاهش خطای دسته‌بندی در جست‌وجوی بصری، از روش مرکزهای ثقل (Centroids) به‌جای تکیه صرف بر شباهت کسینوسی استفاده کنید.
• یک «قانون طلایی» برای امتیازات بسیار بالا تعریف کنید تا استدلال‌های احتمالی مدل، نتایج قطعی و دقیق را فیلتر نکنند.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.