شباهت جاکارد در برابر نگاشت LLM برای مدیریت محتوای پیچیده

تصور کنید یک مدل محتوایی دارید که در مقیاس چهل نوع محتوی مختلف (Content Type) گسترده شده و هر یک از این انواع، ده‌ها فیلد خاص به خود دارند. در چنین سناریویی، ارسال یک سند حجیم گوگل داک (Google Doc) به یک مدل زبانی بزرگ (LLM) برای اینکه مدل تشخیص دهد هر بخش از متن در کجای سیستم مدیریت محتوا (CMS) جای می‌گیرد، نسخه‌ای برای هزینه‌های نجومی و دقت پایین است؛ به‌ویژه از آن جهت که اسناد اغلب ساختارهایی کاملاً متفاوت دارند. به‌جای تکیه بر یک مدل گران‌قیمت برای استدلال در مورد تمام احتمالات موجود (ضرب دکارتی احتمالات)، یک خط‌لوله (Pipeline) کارآمدتر از یک مرحله پیش‌فیلتر قطعی (Deterministic) استفاده می‌کند تا ابتدا دامنه مسئله را محدود کند.

این استراتژی دقیقاً مشکل «سوزاندن توکن‌ها» را که مربوط به انواع محتوای نامرتبط است، هدف قرار می‌دهد. ارسال کل سند به LLM منجر به مصرف شدید پنجره زمینه (Context Window) روی بخش‌هایی می‌شود که هیچ کمکی به نتیجه نمی‌کنند؛ این اتفاق در واقع نتایج را تخریب می‌کند، زیرا مدل به‌جای تمرکز بر یک فهرست کوتاه و گزینه‌شده، مجبور می‌شود در مورد کل فضای احتمالات استدلال کند. طبق یک راهنمای فنی که در ۲۸ ژوئیه ۲۰۲۶ در وب‌سایت dev.to منتشر شد، هدف این است که اسناد به مناطق متوالی (Contiguous Regions) تقسیم شوند، هر منطقه در برابر هر نوع محتوا امتیازدهی شود و سپس مجموعه‌ای کوچک از جفت‌های (محدوده، انواع محتوای کاندید) به LLM تحویل داده شود. این رویکرد تضمین می‌کند که LLM فقط با تطبیقات با احتمال بالا سروکار داشته باشد، نه با کل هستی‌شناسی (Ontology) سیستم. این تمرکز بر دقت و کاهش هزینه، مشابه نیازی به دقت قابل‌راستی‌آزمایی است که در سایر سیستم‌های هوش مصنوعی دیده‌ایم، مانند اجماع چند-مدلی NexaVerify که برای شناسایی نشت‌های API استفاده می‌شود. این رویکرد بهینه‌سازی جریان داده، یادآور استراتژی‌های پیشرفته‌ای است که در خط لولهٔ خودکار Revicheva برای بهینه‌سازی نرخ کلیک ارگانیک دیدیم تا از طریق فیلتر کردن داده‌های غیرضروری، کارایی سیستم را افزایش دهد.

مدل بخش‌بندی (The Segmentation Model)

فرآیند با treating سند به عنوان توالی‌ای از بلوک‌ها آغاز می‌شود. هرگاه سیستم با یک «بازکننده تب» (Tab Opener)، یک تیتر H1 یا یک تیتر H2 مواجه شود، محدوده‌های (Scopes) جدیدی تعریف می‌شوند. هر بلوکی که بین دو بازکننده قرار دارد، متعلق به محدوده‌ای است که توسط اولین بازکننده ایجاد شده است. خروجی این فرآیند، یک آرایه تخت از اشیاء DocumentScope است.

هر DocumentScope حاوی متادیتای حیاتی برای هدایت فرآیند نگاشت (Mapping) است:

• openerText: متن خام تیتر یا برچسب تبی که محدوده را باز کرده است.
• openerKind: برچسبی که مشخص می‌کند محرک از نوع 'tab'، 'heading' یا 'document-root' است.
• blocks: برش متوالی از محتوای سند.
• matches: تمام انواع محتوایی که در برابر این محدوده امتیاز گرفته‌اند و به‌صورت نزولی مرتب شده‌اند.
• topMatch: یک اشاره‌گر تسهیل‌کننده به اولین تطبیق؛ اگر هیچ تطبیقی از حد آستانه نویز بالاتر نرود، مقدار null برمی‌گرداند.
• needsReview: یک پرچم بولی (Boolean) که نشان می‌دهد آیا این بخش نیاز به تردید LLM یا بازبینی انسانی دارد یا خیر.

این منطق در تابع segmentDocumentScopes محصور شده است. این تابع یک NormalizedDocument و یک ContentModelOntologySlice را به عنوان ورودی می‌گیرد. ContentModelOntologySlice در واقع یک گراف پیش‌ساخته از گره‌های نوع محتوا و گره‌های فیلد است که شامل مجموعه‌های مشتق‌شده‌ای از «عبارات نیت» (intentTerms) می‌باشد.

شباهت جاکارد به‌جای بردارها (Jaccard Similarity over Vectors)

به‌جای استفاده از جاسازی‌های برداری (Vector Embeddings) یا شباهت کسینوسی (Cosine Similarity)، این سیستم از شباهت جاکارد روی مجموعه‌های توکن‌سازی شده استفاده می‌کند. فرمول این روش، اندازه اشتراک دو مجموعه تقسیم بر اندازه اجتماع آن‌ها است (|A ∩ B| / |A ∪ B|). توکن‌سازی با تبدیل متن به حروف کوچک، جایگزینی نویسه‌های غیر-حرفی/عددی با فاصله و فیلتر کردن توکن‌هایی با طول یک یا کمتر انجام می‌شود.

به عنوان مثال، اگر محدوده‌ای شامل عبارات { "product", "info", "title" } باشد و در برابر نوع محتوایی با عبارات نیت { "product", "title", "description" } بررسی شود، نتیجه امتیاز ۲ / ۴ = ۰.۵ خواهد بود.

نویسنده این رویکرد را به سه دلیل خاص انتخاب کرده است:

• سرعت: پیچیدگی زمانی آن O(|A| + |B|) است و در هر درخواست به‌صورت هم‌زمان پیش از هرگونه فراخوانی LLM اجرا می‌شود. این روش هیچ تأخیر قابل‌اندازه‌گیری ایجاد نمی‌کند.
• صفر بودن وابستگی‌ها: برخلاف Embeddingها که نیاز به فراخوانی مدل دارند، یا TF-IDF که نیازمند پیش‌محاسبه آمارهای پیکره (Corpus) از کل اسناد است، جاکارد قطعی و بازتولیدپذیر است.
• قابلیت حسابرسی (Auditability): نیازی نیست این روش کامل باشد؛ فقط باید «به اندازه کافی خوب» باشد تا چهل نوع محتوا را به سه کاندید محدود کند. توسعه‌دهندگان می‌توانند کد را بخوانند و دقیقاً بفهمند چرا یک امتیاز خاص به یک بخش اختصاص یافته است.

لایه‌های thưởng ساختاری (Structural Bonus Layers)

همه کلمات وزن یکسانی ندارند. برچسب تبی که «Product Info» (اطلاعات محصول) نوشته شده است، به‌طور دسته‌بندی‌شده سیگنال قوی‌تری نسبت به پاراگرافی در بدنه است که یک‌بار کلمه «product» را ذکر کرده باشد. چون امتیاز پایه جاکارد با تمام اصطلاحات به طور برابر برخورد می‌کند، سیستم یک لایه «جایزه» (Bonus) را برای پاداش دادن به موقعیت‌های ساختاری اعمال می‌کند.

• برچسب‌های تب (Tab Labels): اگر یک برچسب تب با عبارات نیت هم‌پوشانی داشته باشد، سیستم هم‌پوشانی جاکارد را محاسبه کرده و مقدار ۰.۲ × مقدار هم‌پوشانی را به امتیاز اضافه می‌کند. یک تطبیق کامل، ۰.۲ امتیاز جایزه می‌دهد.
• تیترها (Headings): عبارات هم‌پوشان در تیترها، ضرایبی معادل ۰.۱ × مقدار هم‌پوشانی را به امتیاز پایه اضافه می‌کنند.
• متن بدنه (Body Text): امتیازات پایه از منطق body-term-match استخراج می‌شوند.

این بدان معنای است که سندی با تبی به نام «Product Info»، امتیاز مادی و بسیار بالاتری در برابر نوع محتوای «Product» می‌گیرد تا سندی که کلمه «product» را در یک پاراگراف بدنه بدون هیچ نشانگر ساختاری ذکر کرده است. سیستم همچنین سه کد دلیل (Reason Code) تولید می‌کند: tab-label، heading-match و body-term-match. این کدها برای قابلیت مشاهده (Observability) وجود دارند و به LLM و ابزارهای مانیتورینگ می‌گویند دقیقاً از چه شواهدی برای پیشنهاد یک تطبیق استفاده شده است.

استخراج نیت از متادیتای عمیق (Mining Metadata for Intent)

سیستم فقط به نام‌های نمایشی (Display Names) نگاه نمی‌کند. بلکه یک ContentModelOntologySlice را از طریق توکن‌سازی شناسه‌های برنامه‌نویسی، نام فیلدها و قوانین اعتبارسنجی می‌سازد. تابع buildContentModelOntologySlice روی انواع محتوا پیمایش می‌کند تا سیگنال‌ها را از منابع زیر جمع‌آوری کند:

• شناسه سیستمی نوع محتوا (ct.sys.id).
• نام نمایشی (ct.name).
• توضیحات (Description)، در صورت وجود.
• شناسه‌های فیلد (Field IDs) و نام فیلدها.
• قوانین اعتبارسنجی لینک: اگر یک فیلد از نوع 'Link' باشد، سیستم تمام شناسه‌های linkContentType مجاز برای آن فیلد را توکن‌سازی می‌کند.

به عنوان مثال، یک نوع محتوای به نام ctProductVariant که دارای فیلدی به نام linkedEntries با اعتبارسنجی linkContentType: ["BlogPost"] است، عبارات نیتی شامل ctproductvariant ، linkedentries و blogpost تولید می‌کند. این امر حیاتی است زیرا مدل‌های محتوای عملیاتی اغلب از شناسه‌های برنامه‌نویسی (مانند pgBlogEntry) استفاده می‌کنند که حاوی اطلاعات معنایی هستند که در نام‌های نمایشی کاربر یافت نمی‌شود. علاوه بر این، روابط اعتبارسنجی اجازه می‌دهد محدوده‌ای که به «blog posts» اشاره می‌کند، امتیاز بالایی در برابر یک نوع محتوای «کانتینر» (Container) بگیرد که به آن‌ها لینک می‌دهد، حتی اگر نام خود آن کانتینر بسیار کلی باشد.

مدیریت عدم قطعیت با needsReview

برای جلوگیری از شکست خط‌لوله در مواجهه با تطبیقات کم-اعتماد، سیستم به جای یک «دروازه سخت» (Hard Gate)، از پرچم needsReview استفاده می‌کند. این یک مکانیسم مسدودکننده نیست، بلکه سیگنالی است که به مراحل پایین‌دست ارسال می‌شود. این پرچم در سه شرایط خاص برابر با true قرار می‌گیرد:

۱. محدوده‌های خالی: محدوده هیچ بلوک محتوایی ندارد و چیزی برای امتیازدهی وجود ندارد.
۲. اعتماد ضعیف: امتیاز بالاترین گزینه زیر آستانه ۰.۱ است، که نشان می‌دهد هیچ نوع محتوایی با اطمینان تطبیق نیافته است.
۳. ابهام (بررسی شکاف یا Gap Check): تفاوت بین امتیاز اول و امتیاز دوم کمتر از ۰.۰۵ است.

این «بررسی شکاف» بسیار حیاتی است؛ زیرا در یک تابع ساده هم‌پوشانی مجموعه‌ها، تفاوت بین امتیاز ۰.۱۵ و ۰. anecdotal ۰.۱۴ به عنوان «نویز» تلقی می‌شود. به‌جای اینکه اجازه داده شود یک تساوی نزدیک به‌جای یک انتصاب مطمئن عبور کند، سیستم آن را علامت‌گذاری می‌کند تا LLM هر دو کاندید را با جدیت بررسی کند.

با علامت‌گذاری ابهام به‌جای شکست دادن فرآیند، سیستم تضمین می‌کند که موارد خاص (Edge Cases) مشروع — مانند اسنادی بدون تیتر یا انواع محتوایی با عبارات نیت پراکنده — باعث توقف واردات (Import) نشوند. سپس LLM می‌تواند این محدوده‌ها را با این دانش کامل که امتیازدهنده قطعی مطمئن نبوده است، مدیریت کند.

تحلیل تبادل‌های مهندسی (Engineering Trade-offs)

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

تعمیم‌های کلیدی از این طراحی عبارتند از:

• وزن‌دهی به موقعیت: موقعیت ساختاری باید ضرایب ضرب دریافت کند، زیرا یک عبارت در تیتر همیشه شواهدی قوی‌تر از عبارت در بدنه است.
• شکست شفاف: استفاده از needsReview به عنوان یک خروجی درجه اول، برتر از کرش کردن یا عبور بی‌صدا از تصمیمات کم-اعتماد است.
• استخراج متادیتای عمیق: توکن‌سازی نام فیلدها و قوانین اعتبارسنجی، واژگانی را شکار می‌کند که در API موجودند اما در متن نمایشی نیستند.
• امتیازدهی نسبی: فاصله بین مقام اول و دوم به اندازه خودِ امتیاز برتر اهمیت دارد.

با صریح کردن شواهد از طریق کدهای دلیل (Reason Codes)، LLM می‌تواند نسبت به تطبیقاتی که صرفاً توسط body-term-match رانده شده‌اند مشکوک باشد و به تطبیقاتی که توسط tab-label هدایت شده‌اند اعتماد کند. بدین ترتیب، پنجره زمینه LLM برای تصمیمات با ارزش بالا رزرو می‌شود. این تغییر در معماری، LLM را از یک «طبقه‌بندی‌کننده اولیه» به یک «داور نهایی» برای مجموعه‌ای بسیار فیلتر شده از کاندیداها تبدیل می‌کند و یک مسئله جست‌وجوی عظیم را به سری تصمیمات کوچک و محدود شده تغییر می‌دهد.

گام بعدی شما

• اگر در حال توسعه سیستم‌های واردات داده (Import) هستید، به‌جای ارسال مستقیم متن به LLM، یک لایه پیش‌فیلتر مبتنی بر اشتراک کلمات (Set Overlap) پیاده کنید.
• برای بهبود دقت، به جای وزن یکسان کلمات، برای تیترها و برچسب‌های رابط کاربری (UI Labels) ضریب امتیاز مثبت در نظر بگیرید.
• در خروجی‌های سیستم خود، فیلد «دلیل انتخاب» (Reason Code) را اضافه کنید تا LLM بتواند بر اساس شواهدی ساختاری تصمیم بگیرد.

اما بهینه‌سازی هزینه تنها بخشی از ماجراست؛ بررسی اینکه چگونه مدل‌های کوچک‌تر (SLM) می‌توانند این نقش داور نهایی را ایفا کنند، در گزارش بعدی ما خواهد بود.