تصور کنید یک برنامه‌نویس بخواهد سیستمی بسازد که هم پاسخ کاربر را بنویسد و هم هم‌زمان صحت آن را قضاوت کند؛ در اکثر مدل‌های فعلی، این دو وظیفه در تضاد هستند و مدل تمایل دارد اشتباهات خودش را تأیید کند. آیا یک فراخوانی واحد از مدل زبانی بزرگ (LLM) می‌تواند با موفقیت پاسخی را بنویسد و هم‌زمان دقت آن را قضاوت کند؟ معمولاً خیر، این کار با شکست مواجه می‌شود. کلودفلر (Cloudflare) با معرفی Clef این گره را باز کرد؛ مدلی تخصصی که منحصراً برای وظیفه دوم، یعنی تصمیم‌گیری، طراحی شده است. چارچوب Clef نقش هوش مصنوعی را از تولید متن (Prose) به بازگرداندن احتمالات ساختاریافته برای مجموعه‌ای از گزینه‌های ثابت تغییر می‌دهد.
بسیاری از توسعه‌دهندگان اکنون از یک مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — هم برای خلق محتوا و هم برای نقد آن استفاده می‌کنند. این وضعیت باعث ایجاد تضاد منافع می‌شود؛ چراکه مدل اغلب اشتباهات خود را تأیید می‌کند. نوشتن یک مسئله باز (Open-ended) است، اما قضاوت یک انتخاب محدود (Bounded choice) است: «پشتیبانی شده یا خیر»، «ایمن است یا نیست»، «ارسال شود یا نشود». در یک ساختار تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — ممکن است مدل سند درستی را پیدا کند اما معنای آن را دچار توهم (Hallucination) — یعنی مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — شود. در چنین حالتی، پرسیدن از همان مدل که «آیا این پاسخ درست است؟» به‌ندرت شواهد محکمی از حقیقت ارائه می‌دهد.
برای درک بهتر، یک سیاست شرکتی را تصور کنید که بیان می‌کند «فقط کالاهای بازنشده قابل مرجوع هستند». یک LLM ممکن است به اشتباه ادعا کند که همه مشتریان می‌توانند هر کالایی را پس بدهند، در حالی که به سند درست سیاست‌های شرکت استناد می‌کند. در این مورد، بررسی‌های استنادی (Citation checks) پاس می‌شوند، اما معنای پاسخ غلط است. تطبیق رشته‌ای (String matching) نمی‌تواند این خطا را بگیرد و یک پرامپت متنی دوم نیز اغلب در شناسایی این تفاوت ظریف شکست می‌خورد. Clef با تبدیل حکم نهایی به یک «انتخاب محدود» به‌جای «گفتگوی باز»، این مشکل را حل می‌کند.
سازوکار مدل Clef
طبق مستندات کلودفلر، Clef بر اساس یک قرارداد سخت‌گیرانه بین کاربر و مدل عمل می‌کند. شما از آن نمی‌خواهید متنی بنویسد، بلکه یک وضعیت (State) و یک طرحواره (Schema) از پرسش‌های تایپ‌شده را به آن می‌دهید. هر فراخوانی شامل سه بخش اصلی است:
- وضعیت (State): داده‌هایی که باید ارزیابی شوند، که می‌تواند شامل متن، JSON یا تصاویر باشد.
- پرسش‌ها (Questions): حداکثر ۶۴ پرسش تایپ‌شده که هر کدام دارای یک شناسه‌ی (ID) منحصربه‌فرد هستند.
- پاسخ‌ها (Answers): یک شیء بازگشتی که بر اساس آن شناسه‌ها کلیدگذاری شده و برای هر گزینه مجاز، احتمالات آماری را ارائه می‌دهد.
توسعه‌دهندگان سه نوع پرسش خاص در اختیار دارند:
- noul: یک پرسش بله/خیر که یک احتمال را برمی‌گرداند.
- choice: الزامی برای انتخاب یکی از چندین گزینه برچسب‌دار.
- score: یک مقیاس رتبه‌بندی شده و مرتب.
به دلیل این ساختار، دیگر نیازی نیست به مدل دستور دهید «فقط در قالب JSON پاسخ بده» یا منطق‌های پیچیده برای مدیریت زمان‌هایی که مدل «گپ می‌زند» (Chat back) و پاسخ‌های اضافی می‌دهد، بنویسید. برای مثال در یک سناریوی تریاژ (Triage)، توسعه‌دهنده می‌تواند یک پرسش choice برای شناسه‌ی team تعریف کند و معیارهایی را برای billing (پرداخت‌ها، فاکتورها و استردادها)، technical (قطعی‌ها، خطاها و پیکربندی) و sales (طرح‌ها و ارتقاءها) تعیین کند. نتیجه یک شیء ساختاریافته است که کد برنامه‌نویسی می‌تواند مستقیماً آن را بررسی کند، نه جمله‌ای که نیاز به تجزیه (Parsing) داشته باشد. این رویکرد بهینه‌سازی سرعت تصمیم‌گیری یادآور تلاش‌های مشابه در مدل‌های دیگر است؛ برای مثال، بررسی نحوه استفاده از Logprobs برای افزایش سرعت تصمیم‌گیری در مدل‌های زبانی نشان می‌دهد که چگونه می‌توان با تحلیل احتمالات خروجی، به سرعت پاسخ‌های مدل‌های پیچیده را شبیه‌سازی کرد.
پیاده‌سازی در خط‌لوله Evidence Lab
برای نمایش این قابلیت در محیط عملیاتی، نمونه‌ای به نام Evidence Lab برای تأیید پاسخ‌های RAG ساخته شد. این خط‌لوله توالی دقیقی را برای تضمین مبنی‌سازی (Grounding) پاسخ‌ها دنبال می‌کند تا اطمینان حاصل شود پاسخ نهایی بر اساس واقعیت است.
ابتدا، سیستم یک «بسته شواهد» (Evidence pack) را بازیابی و منجمد می‌کند؛ مجموعه‌ای از گزیده‌های متنی که برای پاسخ به پرسش استخراج شده‌اند. این گزیده‌ها با شناسه‌ها و نسخه‌های مشخص پین می‌شوند. این کار تضمین می‌کند که تولیدکننده، تأییدکننده و هر تلاش برای اصلاح، دقیقاً از یک منبع یکسان استفاده کنند. بدون این سازوکار، ممکن است سیستم پاسخی را بر اساس متنی تأیید کند که تولیدکننده اصلاً آن را ندیده است.
سپس، تولیدکننده بلوک‌های پاسخ را با شناسه‌های استنادی می‌نویسد. یک بلوک واحد می‌تواند شامل چندین ادعای واقعی باشد. پیش از رسیدن به Clef، کدهای ساده ساختار (Schema)، شناسه‌های استنادی و هرگونه متن نقل‌شده را اعتبارسنجی می‌کنند. اگر پیش‌نویس از نظر فنی ناقص یا بدساخت (Malformed) باشد، برای کاهش هزینه استنتاج (Inference) — یعنی لحظه‌ای که مدل واقعاً جواب تولید می‌کند، شبیه خودِ آشپزی نه دوره آموزش آشپز — بلافاصله به‌عنوان یک شکست فنی رد می‌شود.
در این مرحله Clef به‌عنوان دروازه تأیید عمل می‌کند. پرسش، پیش‌نویس دقیق و شواهد منجمد شده به عنوان «وضعیت» به مدل ارسال می‌شوند. هر بلوک پاسخ به یک پرسش choice با چهار برچسب مشخص تبدیل می‌شود:
- تأیید شده (Supported): هر ادعا از گزیده‌های استناد شده پیروی می‌کند.
- متناقض (Contradicted): یک گزیده، عکس ادعا را بیان می‌کند.
- شواهد ناکافی (Insufficient Evidence): گزیده‌ها ادعا را اثبات نمی‌کنند.
- شواهد متضاد (Conflicting Evidence): گزیده‌ها در این مورد با یکدیگر اختلاف نظر دارند.
علاوه بر بلوک‌های فردی، Clef در همان مسیر رفت‌وبرگشت (Round trip)، سه معیار کلی را بررسی می‌کند: اینکه آیا پاسخ در محدوده وظیفه (Scope) باقی مانده است، آیا از نظر داخلی سازگار است، و اینکه آیا هر یک از گزیده‌های بازیابی‌شده — حتی آن‌هایی که در پاسخ استناد نشده‌اند — با پاسخ در تضاد هستند یا خیر. این آخرین بررسی برای شناسایی پاسخ‌هایی که به‌طور نامحسوس شواهد نامطلوب را نادیده می‌گیرند، حیاتی است.
اعتبارسنجی و اصلاح
به نقل از گزارش‌های فنی کلودفلر، عبور از فیلتر Clef پایان کار نیست. کد برنامه باید حکم نهایی را اعتبارسنجی کند. سیستم به حکم مدل اعتماد کورکورانه نمی‌کند؛ بلکه الزام می‌کند که هر پرسش مورد انتظار دقیقاً یک بار پاسخ داده شده باشد. سپس برچسب‌ها، احتمالات، شناسه‌های دور (Round IDs) و هش‌های پاسخ و شواهد را بررسی می‌کند تا از عدم تطابق داده‌ها جلوگیری شود.
اگر پیش‌نویسی رد شود، سیستم دقیقاً یک فرصت برای اصلاح (Repair attempt) می‌دهد. تولیدکننده شناسه‌های بررسی‌های شکست‌خورده و شواهد منجمد اصلی را دریافت می‌کند تا بلوک را بازنویسی کند. این پیش‌نویس جدید باید دوباره از بررسی‌های ساختاری و سپس از فیلتر Clef عبور کند. اگر تلاش برای اصلاح نیز شکست بخورد، سیستم یک «امتناع از پاسخ» (Abstention) برمی‌گرداند و پیش‌نویس هرگز منتشر نمی‌شود.
خطاهای فنی باعث توقف فوری عملیات می‌شوند. این خطاها شامل داده‌های نامعتبر، بررسی‌های مفقود، عدم تطابق هش، تایم‌اوت یا اتمام بودجه‌های محاسباتی است. فراخوانی‌های از راه دور، هزینه خود را پیش از ارسال رزرو می‌کنند و تلاش‌های مجدد برای انتقال (Transport retries) محدودیت‌های جداگانه‌ای دارند. یک حکم بدساخت همیشه به‌عنوان شکست تلقی می‌شود، نه تأیید.
در نهایت، یک «دروازه انتشار» (Publication gate) تضمین می‌کند که خروجی با یک سیاست واجد شرایط مطابقت دارد. یک انتشار زنده نیازمند سیاستی است که به شواهد ارزیابی‌شده متصل باشد. در حالت Shadow یا تحت سیاستی که واجد شرایط نیست، پیش‌نویس‌ها و احکام فقط برای ردیابی اپراتور ذخیره می‌شوند و کاربران نهایی هیچ پاسخی نمی‌بینند.
گسترش لایه تصمیم‌گیری
الگوی «تولید، سپس تصمیم» فراتر از RAG کاربرد دارد. طراحی کلی این است: یک LLM تولید می‌کند (باز و گران برای استدلال)، Clef تصمیم می‌گیرد (برچسب‌های محدود و احتمالات در یک فراخوانی)، و کد برنامه اجرا می‌کند (اعتبارسنجی، آستانه‌ها و سیاست انتشار).
کاربردهای احتمالی این مدل عبارتند از:
- دسته‌بندی پشتیبانی: مسیریابی، علامت‌گذاری فوریت و امتیازدهی به شدت مشکل در یک فراخوانی.
- حفاظ‌های عامل (Agent Guardrails): پرسیدن اینکه آیا اقدام پیشنهادی یک ابزار با درخواست کاربر مطابقت دارد و آیا پیش از اجرا، قابل بازگشت است یا خیر.
- نظارت بر محتوا: استفاده از پرسش‌های انتخاب چندگانه به‌جای یک پرامپت مبهم «آیا این متن مناسب است؟».
- تأیید استخراج داده: بررسی اینکه آیا فیلدی که از یک سند استخراج شده، واقعاً در منبع وجود دارد.
- بررسی رابط کاربری (UI): به‌دلیل پشتیبانی از تصویر، می‌توان پرسید «آیا این صفحه وضعیت خطا را نشان می‌دهد؟».
برای توسعه‌دهندگان، این رویکرد فرض بنیادی ارکستراسیون هوش مصنوعی را تغییر می‌دهد. اگر تصمیمی را بتوان در قالب مجموعه‌ای از گزینه‌های ثابت با تعاریف روشن تعریف کرد، جای آن در Clef است، نه در یک پرامپت متنی دوم.
با این حال، پروژه Evidence Lab چند نکته مهم را برجسته می‌کند. نخست اینکه احتمالات بازگشتی هنوز کالیبره نشده‌اند؛ یعنی عدد ۰.۹ برای «تأیید شده» لزوماً به معنای دقت ۹۰ درصدی نیست تا زمانی که اندازه‌گیری شود. دوم، کیفیت نهایی هنوز با داده‌های انسانی سنجیده نشده تا مشخص شود مدل چقدر پاسخ‌های درست را مسدود یا پاسخ‌های غلط را عبور می‌دهد. در نهایت، تأییدکننده نمی‌تواند نقص بازیابی را جبران کند؛ اگر سند درست هرگز بازیابی نشود، Clef فقط می‌تواند گزارش «شواهد ناکافی» بدهد.
پروژه Evidence Lab به‌عنوان یک اثبات مفهوم (PoC) برای مکانیسم‌ها عمل می‌کند: شواهد منجمد، بررسی‌های ساختاریافته در یک فراخوانی، یک تلاش برای اصلاح، و یک تصمیم صریح برای انتشار، که توسط تست‌های خودکار برای اعتبارسنجی پاسخ و اتصال شواهد پشتیبانی می‌شود.
گام بعدی شما
- اگر از RAG استفاده می‌کنید، به‌جای پرسیدن «آیا این پاسخ درست است؟» از مدل، یک لایه طبقه‌بندی (Classification) با گزینه‌های محدود برای تأیید پاسخ‌ها پیاده کنید.
- برای کاهش هزینه‌های استنتاج، اعتبارسنجی‌های ساختاری (Schema Validation) را پیش از ارسال داده‌ها به مدل‌های گران‌قیمت قرار دهید.
- در طراحی عامل‌های هوش مصنوعی، هر تصمیم حساس را به یک پرسش
choiceتبدیل کنید تا خروجی مدل قابل پیش‌بینی و توسط کد قابل کنترل باشد.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو