ارزیابی کیفیت جست وجوی فروشگاهی با داوران مدل زبانی: از شکاف برچسب ها تا آزمون معناداری

مقدمه: «جست وجوی جدید واقعا بهتر است؟»

هر تیمی که روی جست وجوی یک فروشگاه اینترنتی کار می کند، دیر یا زود با این پرسش روبه رو می شود. از BM25 به جست وجوی برداری رفته اید، یک مرحله ی رتبه بندی دوباره (reranker) اضافه کرده اید یا بازنویسی پرسش را فعال کرده اید. عددهای ارزیابی آفلاین هم کمی بالا رفته اند. اما آیا این بهبود واقعی است، یا حاصل نویز، برچسب های ناقص و یک داور یک طرفه؟

در این یادداشت روشی را توضیح می دهم که برای پاسخ دادن به همین پرسش به کار می برم و آن را در یک ابزار متن باز پایتون به نام llm-search-eval پیاده کرده ام (کد منبع در GitHub). تمرکز یادداشت روی ایده هاست، نه روی خود ابزار: این ایده ها در هر سامانه ی ارزیابی جست وجو قابل پیاده سازی اند.

ارزیابی آفلاین معمولا کجا خراب می شود؟

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

1. برچسب ها تمام می شوند. مجموعه ی طلایی (gold set) که فصل پیش برچسب خورده، محصولاتی را که بازیاب جدید امروز پیدا می کند پوشش نمی دهد. نتیجه های بدون برچسب بی صدا «نامرتبط» حساب می شوند و سامانه ی جدید بدتر از واقعیت دیده می شود.
2. میانگین ها نویز را پنهان می کنند. دو درصد بهبود nDCG روی پنجاه پرسش به راحتی می تواند تصادفی باشد.
3. یک مدل، یک نظر است. یک داور مدل زبانی سوگیری های خودش را دارد و معمولا کسی بررسی نمی کند که چقدر با برچسب گذارهای انسانی هم نظر است.
4. هزینه بی صدا بالا می رود. داوری هزاران جفت «پرسش محصول» با یک مدل بزرگ گران است و معمولا تا رسیدن صورت حساب کسی متوجه نمی شود.
5. کاتالوگ های چندزبانه نامرتب اند. متن فارسی ترکیبی از حروف عربی و فارسی، چند نظام رقم و نیم فاصله است و تطبیق ساده را خراب می کند.

اصل اول: برچسب طلایی مقدم است، داور فقط شکاف ها را پر می کند

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

نکته ی مهم دیگر این است که همه ی سامانه ها روی یک مخزن برچسب مشترک سنجیده شوند. اگر محصولی برای سامانه ی B داوری شده، همان برچسب برای سامانه ی A هم به کار می رود. در غیر این صورت مقایسه منصفانه نیست.

برچسب ها درجه بندی شده اند: از ۰ (نامرتبط) تا ۳ (کاملا مرتبط). برای معیارهای دودویی، درجه ی ۲ و بالاتر به طور پیش فرض «مرتبط» حساب می شود.

اصل دوم: یک داور کافی نیست؛ هیئت داوران و توافق

به جای یک مدل، می توان چند مدل را به عنوان «هیئت داوران» به کار برد و رای ها را با یکی از قاعده های اکثریت، میانگین، میانه، کمینه یا بیشینه ترکیب کرد. اگر یکی از داوران خطا بدهد (مثلا timeout)، جفت از دست نمی رود، به شرط اینکه حداقل تعداد رای لازم جمع شده باشد.

اما هیئت داوران تنها وقتی ارزش دارد که توافق آن ها اندازه گیری شود. آماره هایی که در این روش گزارش می شوند:

• سهم اتفاق آرا: جفت هایی که همه ی داوران درجه ی یکسان داده اند.
• کاپای فلایس (Fleiss' kappa): توافق اصلاح شده برای شانس، برای هر تعداد داور.
• آلفای کریپندورف (Krippendorff's alpha): با نسخه های اسمی، ترتیبی و فاصله ای. برای درجه های ۰ تا ۳، نسخه ی ترتیبی آموزنده ترین است و رای های گم شده را هم تحمل می کند.
• کاپای کوهن دوبه دو: ساده و وزن دار درجه دوم برای هر جفت داور.

به عنوان یک قاعده ی سرانگشتی، کاپا یا آلفای بالای ۰٫۸ توافق قوی، بین ۰٫۶ و ۰٫۸ توافق قابل توجه، و زیر ۰٫۴ نشانه ی این است که دستورالعمل داوری یا مدل ها نیاز به اصلاح دارند.

واسنجی در برابر برچسب های انسانی

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

اصل سوم: هر مقایسه یک آزمون معناداری لازم دارد

معیارهای کلاسیک بازیابی اطلاعات پایه ی کارند: nDCG@k با بهره ی نمایی (2^rel − 1) یا خطی، دقت@k، بازخوانی@k، MRR و MAP. اما گزارش میانگین به تنهایی کافی نیست.

هر سامانه با سامانه ی پایه با یک آزمون تصادفی سازی جفتی دوطرفه (sign-flip) روی مقدار هر پرسش از معیار اصلی مقایسه می شود. این آزمون فرض نرمال بودن ندارد و انتخاب رایج در ارزیابی بازیابی اطلاعات است. کنار آن، برای هر میانگین و هر اختلاف، فاصله ی اطمینان بوت استرپ و شمار برد، تساوی و باخت پرسش ها گزارش می شود.

یک جزئیات روش شناختی مهم: پرسشی که در مخزن برچسب هیچ محصول مرتبطی ندارد، معیارهایش تعریف نشده است. چنین پرسشی به جای اینکه صفر حساب شود از میانگین کنار گذاشته می شود و تعداد پرسش های واقعا شمرده شده (n) برای هر میانگین ثبت می شود.

اصل چهارم: داوری دوبه دو و خنثی کردن سوگیری جایگاه

وقتی دو سامانه از نظر nDCG نزدیک اند یا برچسب ها کم اند، داوری دوبه دو (pairwise) یک نظر دوم مفید است. در این روش داور برای هر پرسش، k نتیجه ی برتر دو سامانه را کنار هم می بیند و می گوید خریدار کدام فهرست را ترجیح می دهد: A، B یا تساوی.

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

اصل پنجم: هزینه و منشا هر داوری باید ثبت شود

دو موضوع عملی اغلب نادیده گرفته می شوند:

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

منشا (provenance). نتیجه ی داور مدل زبانی به سه چیز بستگی دارد: مدل، ارائه دهنده و متن پرامپت. از نسخه ی 0.4.0 هر پرامپت یک نسخه ی دستی و یک هش دارد: ۱۲ نویسه ی اول SHA-256 روی متن کامل پرامپت. این هش بخشی از کلید حافظه ی نهان است، پس داوری ای که با پرامپت دیگری انجام شده هرگز از حافظه ی نهان برنمی گردد. در تغییرات منتشرنشده ی بعدی، نسخه ی تاریخ دار مدلی که ارائه دهنده واقعا پاسخ داده هم ثبت می شود و اگر در یک اجرا چند نسخه از یک مدل دیده شود، گزارش هشدار می دهد که امتیازها مستقیما قابل مقایسه نیستند. دلیلش این است که ارائه دهنده ها گاهی مدل را بی صدا به روز می کنند.

اصل ششم: فارسی شهروند درجه یک است

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

برای پرسش های فارسی، پیش از تطبیق، «ی» و «ک» عربی به «ی» و «ک» فارسی تبدیل می شوند، ارقام فارسی و عربی یکسان می شوند، اعراب، کشیده و نویسه های جهت حذف می شوند و نیم فاصله مرز کلمه حساب می شود. زبان پرسش اگر مشخص نشده باشد از روی خط تشخیص داده می شود و گزارش، معیار اصلی را به تفکیک زبان نشان می دهد. پرامپت داور هم زبان پرسش را ذکر می کند و ترجمه یا نویسه گردانی میان فارسی و انگلیسی را تطابق حساب می کند؛ مثلا پرسش «گوشی سامسونگ» با محصولی به نام Samsung Galaxy.

یک مثال عملی

مخزن پروژه یک کاتالوگ کوچک دوزبانه ی لوازم الکترونیکی با سه سامانه برای مقایسه دارد. با داور شبیه ساز (mock)، که قطعی است و برای CI و اجرای آفلاین ساخته شده، می توان بدون هیچ هزینه ای اجرا کرد:

pip install llm-search-eval

llm-search-eval run \

 --queries examples/electronics/queries.jsonl \

 --products examples/electronics/products.jsonl \

 --qrels examples/electronics/qrels.csv \

 --system bm25=examples/electronics/runs/bm25.jsonl \

 --system semantic=examples/electronics/runs/semantic.csv \

 --system hybrid=examples/electronics/runs/hybrid.trec \

 --judge mock --output-dir reports/

در این داده ی نمونه، nDCG@10 برای bm25 برابر 0.5305، برای semantic برابر 0.9865 و برای hybrid برابر 0.9767 است. این عددها فقط برای نمایش کارکرد ابزار روی یک داده ی کوچک نمونه اند و نباید به عنوان مقایسه ی عمومی روش ها خوانده شوند.

برای داور واقعی کافی است داور، قیمت و سقف بودجه را مشخص کنید:

llm-search-eval run ... --judge openai=gpt-4o-mini \

 --cache .judge-cache.jsonl --price gpt-4o-mini=0.15,0.60 --max-cost 2

خروجی شامل گزارش Markdown و JSON، یک داشبورد HTML مستقل (بدون سرور و CDN)، گزارش هزینه و فایل همه ی داوری هاست.

از ارزیابی تا دروازه ی کیفیت در CI

ارزیابی وقتی بیشترین ارزش را دارد که خودکار باشد. با فرمان gate یا GitHub Action پروژه می توان قاعده هایی مثل «nDCG@10 نباید از فلان کف پایین تر برود» یا «نسبت به سامانه ی فعلی نباید افت کند» تعریف کرد. اگر تغییری در رتبه بندی این قاعده ها را نقض کند، build شکست می خورد و نتیجه در یک کامنت به روزشونده روی pull request نمایش داده می شود. اجراها را هم می توان مستقیما از Elasticsearch، OpenSearch، Algolia، Meilisearch، Typesense یا هر API جست وجوی HTTP/JSON گرفت.

محدودیت ها

• داور مدل زبانی جایگزین برچسب گذار انسانی نیست؛ واسنجی فقط میزان هم نظری را نشان می دهد و آن را تضمین نمی کند.
• آزمون معناداری روی مجموعه ای کوچک از پرسش ها توان آماری کمی دارد. «معنادار نبودن» به معنای «برابر بودن» نیست.
• داور شبیه ساز فقط پوشش واژه ها را می سنجد و برای آزمون خط لوله ساخته شده، نه برای قضاوت درباره ی کیفیت.
• مقایسه ی دوبه دو هیچ معیار نقطه ای را تغییر نمی دهد و باید کنار آن خوانده شود.

جمع بندی

برای اینکه بگوییم جست وجوی جدید واقعا برای خریداران بهتر است، چهار چیز لازم است: پر کردن شکاف برچسب ها با داوری که توافقش با انسان سنجیده شده، مقایسه ی همه ی سامانه ها روی یک مخزن برچسب مشترک، یک آزمون معناداری جفتی برای هر اختلاف، و ثبت هزینه و منشا هر داوری. هیچ کدام از این ها پیچیده نیست، اما نبود هر کدام می تواند تصمیم اشتباهی را با عددهای قانع کننده توجیه کند.

منابع و لینک ها

• کد منبع llm-search-eval: https://github.com/sadrmanesh/llm-search-eval
• نسخه ی نرم افزار در Zenodo: https://doi.org/10.5281/zenodo.23944666
• مستندات: https://sadrmanesh.github.io/llm-search-eval/
• داشبورد نمونه: https://sadrmanesh.github.io/llm-search-eval/demo/report.html
• نسخه ی قابل اجرا در مرورگر (Hugging Face Space): https://huggingface.co/spaces/sadrmanesh/llm-search-eval-demo
• داده ی نمونه: https://huggingface.co/datasets/sadrmanesh/llm-search-eval-electronics

نوشته های مرتبط

• Is your new search actually better? Label gaps, LLM judge panels, and paired statistics (Dev.to)
• Is your new search actually better? Five questions I ask before shipping a ranking change (LinkedIn)
• ی عربی، نیم فاصله و PDF برعکس: سه دشمن پنهان جست وجوی فارسی (سیویلیکا)
• طراحی بنچمارک persian-rag-bench (سیویلیکا)
• Four open-source tools for AI in e-commerce, and what building them taught me (Dev.to)
• وب سایت شخصی