Search Relevance و Faceted Discovery

وقتی _score بالا هنوز جواب خوبِ یادگیرنده نیست

یک یادگیرنده عبارت debug flaky async tests را جست‌وجو می‌کند. پنج محتوای کاتالوگ match می‌شوند؛ facet زبان دو مورد را حذف می‌کند. در سه نتیجه‌ی باقی‌مانده، یک مقاله‌ی مقدماتی با _score بالاتر از راهنمای پیشرفته‌ی عیب‌یابی قرار می‌گیرد. از دید موتور جست‌وجو این ranking ممکن است کاملاً طبیعی باشد، اما از دید information need یادگیرنده‌ی باتجربه شاید ترتیب ضعیفی باشد.

در این درس Search Relevance & Facet Evaluation Contract v1 را می‌سازیم. هدف این نیست که یک الگوریتم ranking را «بهترین» اعلام کنیم؛ هدف این است که بتوانیم نشان دهیم چه چیزی از query score آمده، چه چیزی از filter حذف شده، facet چه candidate setی ساخته، judgmentهای صریح درباره‌ی relevance چه می‌گویند و metric انتخاب‌شده چه چیزی را واقعاً اندازه می‌گیرد.

مرز درس و مسیر یادگیری

MKN-007 مالک Search Relevance و Faceted Discovery است. prerequisite سخت آن MKN-003 است. outcome درس قبل (MKN-006) و درس بعد (MKN-008) جذب این درس نمی‌شوند؛ بنابراین اینجا credential architecture یا documentation monitoring را حل نمی‌کنیم و هیچ index زنده‌ای تغییر نمی‌کند.

مسیر Foundation از نقشه‌ی ۱۶ فیلد و baseline شروع می‌کند. مسیر Repair اولین evidence شکسته—مثلاً judgment گمشده یا taxonomy drift—را جدا می‌کند. مسیر Experienced باید بتواند score، filter، facet و judgment را بدون تبدیل vendor defaults یا metric به authority پنهان از هم تفکیک کند.

مدل ذهنی: intent → retrieval → score + filter → rank → facet → judgment → metric → keep/tune/fallback

جریان تصمیم این است:

learner intent → candidate retrieval → scored query clauses + binary filters → ranked candidate set → facet navigation → relevance judgments → rank evaluation → keep / tune / fallback / hold

Query score درباره‌ی «چقدر match شدن» در مدل موتور است. Filter فقط candidate را داخل/خارج می‌کند. Facet راهی برای navigate یا محدودکردن candidate set بر اساس taxonomy است. Judgment شواهد صریح درباره‌ی مناسب‌بودن یک نتیجه برای information need است. Metric خلاصه‌ای از کیفیت ranking نسبت به همان judgmentهاست. یکی‌کردن این چهار لایه، false confidence می‌سازد.

قرارداد پایه: شانزده بُعد شواهد

query_id و learner_intent هویت مسئله را مشخص می‌کنند. candidate_set دامنه‌ی retrieved items را ثبت می‌کند. relevance_score خروجی scoring را نگه می‌دارد و filter_state نشان می‌دهد چه چیزهایی به‌صورت binary حذف یا نگه داشته شده‌اند. rank_position ترتیب نهاییِ candidateهای قابل نمایش است.

facet_dimension، facet_value و taxonomy_version نشان می‌دهند navigation تحت کدام taxonomy انجام شده است. judgment_set و relevance_grade relevance labels را به intent مشخص وصل می‌کنند. evaluation_metric و metric_result کیفیت ranking را نسبت به آن labels خلاصه می‌کنند. zero_result_state و fallback_route شکست discovery را visible نگه می‌دارند و review_owner مسئول تصمیم را مشخص می‌کند.

یک row کامل، evidence package است؛ نه مجوز خودکار برای «ranking خوب است».

توضیح عمیق: FACT، INFERENCE و DESIGN را جدا نگه دار

FACT — query در برابر filter. مستندات فعلی Elasticsearch query context را جایی می‌داند که match علاوه بر yes/no، relevance score می‌سازد؛ filter context پاسخ binary می‌دهد و score محاسبه نمی‌کند. پس تبدیل یک scored query clause به filter فقط optimization نیست؛ semantics ranking را عوض می‌کند.

FACT — rank evaluation. Elasticsearch _rank_eval مجموعه‌ای از search requestها و rated documents را می‌گیرد و metricهایی مثل precision، mean reciprocal rank و discounted cumulative gain را محاسبه می‌کند. وجود metric به معنی درست‌بودن metric برای هدف ما نیست.

INFERENCE — facet را جدا audit کن. اگر نتیجه‌ای ناپدید شد، باید بفهمیم به‌خاطر score پایین بوده یا filter/facet آن را از candidate set حذف کرده. facet count به‌تنهایی quality signal نیست.

DESIGN — MAKNOW. query fixture، intent، judgment policy، relevance grades، metric، threshold، zero-result fallback، taxonomy version و owner تصمیم‌های محلی‌اند. vendor documentation این authority را تأمین نمی‌کند.

مثال‌های حل‌شده: debugging، shortcut غلط و transfer

Baseline — production debugging. سه نتیجه‌ی انگلیسی بعد از filter باقی می‌مانند. ranking موتور intro-async → advanced-debugging → checklist است؛ ولی برای intent «production debugging» gradeها 1,3,2 هستند. NDCG@3 ≈ 0.7364 می‌شود. در fixture محلی threshold طراحی 0.85 است، پس نتیجه RANK_TUNING_REVIEW_REQUIRED است. این state نمی‌گوید Elasticsearch اشتباه است؛ می‌گوید ranking فعلی نسبت به judgmentهای این intent هنوز به bar محلی نرسیده است.

Shortcut غلط — score هست، judgment نیست. اگر _scoreها را نگه داریم ولی judgmentها را حذف کنیم، metric معتبرِ relevance نسبت به information need نداریم. state باید HOLD_RELEVANCE_JUDGMENTS_MISSING باشد؛ score خودش label relevance نیست.

Transfer — beginner explanation. همان content set و همان query text می‌تواند intent دیگری داشته باشد. برای beginner، gradeها ممکن است 3,1,2 شوند و همان ranking NDCG@3 ≈ 0.9721 بگیرد. این نتیجه فقط وقتی معتبر است که judgmentها واقعاً برای intent جدید rebuild شده باشند؛ کپی‌کردن labelهای baseline ممنوع است.

failure modeهایی که باید fail-closed باشند

اگر query یا intent نامعلوم است، candidate set قابل بازسازی نیست، scored query به filter تبدیل شده اما recomputation انجام نشده، relevance score لازم UNKNOWN است، filter state یا rank position ناسازگار است، judgment/relevance grade وجود ندارد، metric پشتیبانی نمی‌شود یا metric result با evidence هم‌خوان نیست، taxonomy version نامعلوم است، facet value دیگر در taxonomy map نمی‌شود، owner خالی است یا transfer baseline labels را reuse می‌کند، نتیجه باید HOLD بماند.

Zero-result هم «صفر relevance» نیست. اگر candidate set خالی است، باید zero_result_state و fallback_route روشن باشند. fallback می‌تواند broadening، spelling recovery، alternate facet یا human navigation باشد؛ اما باید به‌عنوان route جدا ثبت شود، نه اینکه silently نتیجه‌ی نامرتبط نشان دهیم.

گزینه‌ها و trade-offها: score، metric، facet و threshold

Precision@k ساده و توضیح‌پذیر است، اما موقعیت دقیق resultهای relevant داخل top-k را نادیده می‌گیرد. MRR برای use caseهایی مناسب است که اولین جواب relevant مهم است. DCG/NDCG graded relevance و position را وارد محاسبه می‌کند؛ برای نتیجه‌هایی با درجات relevance مختلف مفید است. انتخاب metric باید از task بیاید، نه از راحتی API.

facetهای زیاد discovery را قابل explore می‌کنند اما taxonomy ضعیف می‌تواند false precision بسازد. filter سخت candidate set را کنترل می‌کند اما ممکن است نتیجه‌ی relevant را قبل از scoring حذف کند. threshold سخت QA را شفاف می‌کند اما اگر بدون intent-specific judgment انتخاب شود، عددی تزئینی است. Contract عمداً این trade-offها را جدا نگه می‌دارد.

پل مسیر Experienced: relevance یک property ثابتِ document نیست

relevance رابطه‌ای میان document، query، learner intent و context است. یک محتوای مقدماتی می‌تواند برای beginner عالی و برای production debugging ضعیف باشد. همین نکته دلیل اصلی versionکردن judgment fixtures و taxonomy است.

برای آزمایش‌های ranking، query fixture را immutable reference بده، judgment set را با intent version کن، metric configuration را ثبت کن و تغییرات facet/filter را مستقل trace کن. اگر یک مدل AI relevance label پیشنهاد می‌کند، آن پیشنهاد candidate evidence است؛ تا وقتی authority محلی و review owner آن را نپذیرفته، ground truth canonical نیست.

تمرین هدایت‌شده و مستقل

1. baseline را اجرا کن و محاسبه‌ی NDCG@3 را از rank + grades بازتولید کن. 2. judgmentها را حذف کن و ببین چرا score نمی‌تواند جای آن‌ها را بگیرد. 3. یک scored query clause را به filter تبدیل کن و recomputation را اجباری کن. 4. facet taxonomy را version کن و یک value قدیمی را بدون mapping بگذار؛ state باید taxonomy drift را آشکار کند. 5. candidate set را صفر کن و یک fallback route قابل دفاع ثبت کن. 6. intent را به beginner تغییر بده و بدون نگاه‌کردن به baseline labels judgmentهای جدید بساز.

در تمرین مستقل expected state حذف می‌شود. فقط ۱۶ بُعد Contract، rules visible و fixture synthetic در اختیار یادگیرنده است.

شواهد verification: reviewer چه چیزی را باید بتواند بازسازی کند؟

Reviewer باید query/intent، candidate set، score evidence، filter inclusion/exclusion، final rank، facet/taxonomy، judgment grades، metric configuration/result، zero-result/fallback و owner را از artifact قابل مشاهده بازسازی کند. همچنین باید بتواند metric اعلام‌شده را دوباره محاسبه کند و تشخیص دهد تغییر ordering از scoring آمده یا candidate set قبل‌تر با filter کوچک شده است.

Lab deterministic baseline، rank خوب، judgment گمشده، query/filter collapse، score/filter/rank defects، metric mismatch، taxonomy drift، zero-result fallback، owner missing، intent-change بدون judgment rebuild و baseline-oracle reuse را پوشش می‌دهد.

ارزیابی و Transfer: یک query text، دو information need

Assessment چهار بخش blocking دارد: مرز MKN-007 و یک non-goal را توضیح بده؛ Contract baseline را بساز؛ shortcut «score بدون judgments» را diagnose کن؛ و transfer را برای beginner از صفر محاسبه کن.

Transfer فقط وقتی PASS است که learner_intent عوض شود، judgment grades جدید ثبت شوند، metric دوباره محاسبه شود و facet/filter use با intent جدید بازبینی شود. اینکه query text و content set ثابت مانده‌اند هیچ اجازه‌ای برای reuse کردن baseline relevance labels نمی‌دهد.

منابع، freshness و مرز authority

مستندات رسمی Elastic برای Query and filter context و Ranking evaluation در 2026-09-13 دوباره بررسی شدند. claimهای مربوط به query score/filter semantics و _rank_eval به‌عنوان FACT نگه داشته می‌شوند و تا 2027-01-15 یا زودتر در صورت تغییر material باید recheck شوند.

تفکیک facet audit، relevance judgment policy، metric/threshold choice، taxonomy versioning، fallback و stateهای HOLD/REVIEW_REQUIRED، MAKNOW DESIGN authority هستند. این درس عمداً vendor fact و product decision را یکی نمی‌کند.