متن باز

یه تست واقعی هم گزارش شده: تیم threat intelligence خود کلادفلر با Clef، دسته‌بندی دامنه‌ها رو توی ۲.۲ ثانیه انجام داده، در برابر ۴.۷ ثانیه با gpt-oss-120b، یعنی تعداد دسته‌بندی بیشتر با تقریباً نصف تأخیر.

کجا در دسترسه و قیمت؟

Clef همین الان روی Workers AI از طریق API کلادفلر در دسترسه، و وزن‌هاش هم با لایسنس Apache 2.0 روی Hugging Face منتشر شدن. قیمت‌گذاری توی اعلامیه مشخص نشده.

پلتفرم RL برای fine-tune کردن

کنار مدل‌ها، کلادفلر یه سرویس reinforcement learning هم معرفی کرده که با اون مشتری‌ها می‌تونن Clef رو برای کار مشخص خودشون fine-tune کنن. این پلتفرم از AI Gateway (برای جمع‌آوری داده‌ی آموزشی)، Workers AI (برای تولید rollout)، Cloudflare Containers (به‌عنوان sandbox RL) و یه ماژول trainer (برای آپدیت وزن‌ها) استفاده می‌کنه و امکان آوردن مدل شخصی (BYO Model) هم داره. فعلاً fine-tune فقط با همکاری مستقیم مهندس‌های کلادفلر انجام میشه و نسخه‌ی self-serve برای بعداً برنامه‌ریزی شده.

کاربردها

کلادفلر کاربردهایی مثل مسیردهی و triage پشتیبانی مشتری، دسته‌بندی دامنه برای threat intelligence، پردازش فاکتور، دسته‌بندی حوادث امنیتی، تشخیص fraud و phishing، تشخیص ربات خوب از بد، و ارزیابی گزارش‌های Trust and Safety رو نام برده.

چیزهایی که باید با احتیاط بهشون نگاه کرد

همه‌ی اعداد بالا از خود کلادفلر اومدن، و مقایسه با Jev توسط خود کلادفلر انجام شده، نه یه ارزیابی مستقل. قیمت و سقف throughput اعلام نشده، دسترسی به fine-tune فعلاً محدوده، و خود کلادفلر هم اشاره کرده که بخشی از عملکرد به نزدیکی زیرساخت به شبکه‌ی edge کلادفلر بستگی داره. با ورود یه بازیگر به این بزرگی، رقابت توی دسته‌ی مدل‌های تصمیم‌گیر عملاً جدی شده، ولی هنوز باید منتظر تست‌های مستقل موند.

• عدد ۷۶.۶٪ مال checkpoint ای هست که روی خود split آموزشی همون بنچمارک fine-tune شده؛ مدل پایه‌ی zero-shot فقط ۳۶.۲٪ گرفته، که حتی از baseline اکثریت (۴۶.۱٪) هم پایین‌تره.
• مقایسه‌ی سرعت، یه inference لوکال روی GPU گرم‌شده رو با یه فراخوانی API میزبانی‌شده (که زمان شبکه رو هم شامل میشه) مقایسه می‌کنه — یعنی سیب و پرتقال.
• روی Banking77 که باید بین ۷۷ برچسب intent انتخاب کنی، Jev عدد ۰.۸۷۰ گرفته و Laya فقط ۰.۴۲۵؛ یعنی روی دسته‌بندی‌های با تعداد برچسب بالا، Jev فاصله‌ی زیادی داره و برای Laya باید سلسله‌مراتب coarse-to-fine بسازی.
• خود مدل‌کارت Laya هشدار میده که مدل تا وقتی temperature ش دوباره calibrate نشه، بیش‌ازحد مطمئن (overconfident) خروجی میده — که برای مدلی که ارزشش توی احتمال‌های واقعیه، یه نکته‌ی کوچیک نیست.

یه تست مستقل که هر دو مدل رو روی یه مجموعه‌ی ۴۰۰ تصمیمی و توی یه harness یکسان اجرا کرده، نتیجه‌ی متعادل‌تری داده: Laya روی دو تا از شش سؤال جلو بوده و توی بقیه Jev برتری داشته. سرعت Laya روی مک بین ۲۰ تا ۵۰ میلی‌ثانیه بوده که واقعاً چشمگیره، ولی دقتش به‌طور کلی پایین‌تر از Jev بوده.

مقایسه‌ی سریع

پس کدوم رو استفاده کنیم؟

جواب صادقانه اینه که این‌ها جایگزین هم نیستن، دو تا ابزار برای دو تا موقعیت متفاوتن. اگه دقت روی برچسب‌های زیاد یا سؤال‌های پیچیده‌تر براش مهمه، نمی‌خوای زیرساخت اجرای مدل رو خودت نگه داری، و ارسال داده به یه API خارجی مشکلی نداره، Jev هنوز انتخاب امن‌تریه. ولی اگه داده‌هات حساسن و نباید از سرورت خارج بشن، حجم فراخوانی اونقدر بالاست که حتی هزینه‌ی ناچیز به ازای هر توکن هم جمع میشه، تأخیر چندده‌میلی‌ثانیه‌ای برات حیاتیه (مثلاً یه حلقه‌ی کنترل real-time)، یا با متن چندزبانه کار می‌کنی، Laya قابل‌توجه‌تره — به شرط اینکه حاضر باشی یه مقدار وقت برای fine-tune و calibrate کردنش بذاری.

پیشنهاد عملی من اینه که به هیچ‌کدوم از اعداد منتشرشده‌ی هیچ‌طرفی تکیه نکنی: ۲۰۰ تا ۵۰۰ نمونه‌ی واقعی از داده‌ی خودت جمع کن، برچسب‌گذاریشون کن، و هر دو مدل رو روی همون‌ها امتحان کن. چون Laya رایگانه و توی چند دقیقه نصب میشه، این تست تقریباً بی‌هزینه‌ست، و نتیجه‌ش خیلی بیشتر از هر بنچمارک عمومی به کارت میاد. اگه Laya روی داده‌ی تو به دقت قابل‌قبولی رسید، یه مدل لوکال رایگان با تأخیر چندده‌میلی‌ثانیه‌ای ارزش جدی داره؛ اگه نرسید، هزینه‌ی Jev احتمالاً همچنان از خطاهای اضافی ارزون‌تره.

زمان‌بندی: چرا درست بعد از خرید Qualcomm

نکته‌ی جالبی که تقریباً همه‌ی گزارش‌ها روش تأکید کردن، زمان‌بندیه. Qualcomm خرید Modular رو ۲۹ جولای نهایی کرد؛ فقط سه هفته بعد، اولین حرکت بزرگ مالک جدید این بوده که کامپایلر رو کاملاً ببخشه. این تصمیم برای خیلی‌ها غیرمنتظره بود، چون تاریخچه‌ی Qualcomm تو متن‌باز چندان درخشان نیست، و بعضی تو کامیونیتی نگران بودن که خرید یه شرکت سازنده‌ی چیپ، تعهد Modular به یه پلتفرم توسعه‌ی خنثی از نظر vendor رو به خطر بندازه.

استدلال منطقی پشت این تصمیم اینه: هر ساعتی که یه توسعه‌دهنده صرف قفل‌شدن تو CUDA (اکوسیستم اختصاصی NVIDIA) می‌کنه، یه ساعتیه که تراشه‌های Qualcomm نمی‌تونن گزینه‌ی رقیب باشن. باز کردن toolchain برای Qualcomm عملاً هزینه‌ای نداشته (چون هیچ‌وقت قرار نبوده از فروش لایسنس کامپایلر پول دربیاره)، ولی می‌تونه به پذیرش گسترده‌تر Mojo رو انواع سخت‌افزار کمک کنه؛ از جمله سخت‌افزار خود Qualcomm.

گستره‌ی سخت‌افزاری: فراتر از NVIDIA

طبق اعلام‌های ModCon، پلتفرم Modular (که Mojo موتور اصلیشه) الان از AWS Trainium و Google TPU هم پشتیبانی می‌کنه، علاوه بر GPU های NVIDIA، AMD، و Apple Silicon. حتی یه دمو رو یه شتاب‌دهنده‌ی چینی (Houmo، با ۲۴ گیگابایت حافظه‌ی M.2) هم نشون داده شده. تراشه‌های خود Qualcomm (مثل Cloud AI 100 Ultra و Dragonfly) هم حالا هدف اول‌درجه‌ی این stack هستن. یه مقام از GV (سرمایه‌گذار وابسته به گوگل) این چشم‌انداز رو این‌طور خلاصه کرده: «هر مدل هوش مصنوعی رو هر تراشه‌ای اجرا کن.»

نکته‌ی مهم: MAX هنوز کاملاً باز نشده

یه تمایز مهم که نباید فراموشش کرد: Mojo (خود زبون و کامپایلر) کاملاً متن‌بازه، ولی MAX (لایه‌ی بالاتر که مدل‌های هوش مصنوعی رو serve و بهینه می‌کنه) فقط «source-available» شده، نه open source؛ یعنی می‌تونی کدش رو ببینی، ولی زیر یه لایسنس community با شرایط خاص (محدودیت‌هایی درباره‌ی telemetry، برندینگ، و ساختن جایگزین‌های رقیب) قرار داره. طبق تحلیل Forbes، محدودیت‌های قدیمی مبتنی بر تعداد دستگاه از MAX برداشته شده که پیشرفت واقعی‌یه، ولی source-available با governance واقعی کامیونیتی فرق داره. ریسک بزرگ‌تر هم اینه که Modular Cloud (لایه‌ای که تصمیم می‌گیره workload ت رو کدوم تراشه اجرا بشه) کاملاً proprietary باقی مونده؛ یعنی Apache 2.0 فقط خود زبون رو محدود می‌کنه، نه ابر (cloud) بالادستیش.

پشتیبانی پلتفرم

Mojo فعلاً از macOS و لینوکس پشتیبانی می‌کنه. طبق اعلام Modular، دارن مستقیم با تیم ویندوز مایکروسافت همکاری می‌کنن تا Mojo رو به‌صورت native (نه فقط از طریق WSL) به ویندوز بیارن؛ این یکی از پرتقاضاترین درخواست‌های کامیونیتی Mojo بوده.

این برای توسعه‌دهنده‌ها چه معنایی داره

اگه دنبال یه زبون سیستمی با سینتکس نزدیک به پایتون هستی که بتونه هم‌زمان CPU، GPU، و شتاب‌دهنده‌های AI رو با performance بالا هدف بگیره، Mojo حالا از هر نظر (نه فقط کتابخونه، بلکه کل زنجیره‌ی ساخت) قابل بازرسی و تغییره؛ چیزی که برای شرکت‌هایی که نگران قفل‌شدن تو یه vendor خاص (مثلاً NVIDIA/CUDA) هستن، جذابیت واقعی داره. با این حال، CUDA همچنان عمیق‌ترین و جاافتاده‌ترین toolchain مخصوص سخت‌افزار NVIDIA است؛ یه دهه کتابخونه، پشتیبانی driver، و ابزار که Mojo قرار نیست یک‌شبه جایگزینش کنه. اگه پروژه‌ت به ویندوز وابسته‌ست، فعلاً باید صبر کنی تا پشتیبانی native تکمیل بشه.

پایه‌ی نظری: Metric First-Order Temporal Logic

از نظر فنی، Dogwood رو یه فرمالیسم از رشته‌ی runtime verification به اسم MFOTL (Metric First-Order Temporal Logic) ساخته شده. عملگرهایی که به Cedar اضافه می‌کنه شامل چیزهایی مثل formerly (چیزی قبلاً اتفاق افتاده؟)، count_within (چند بار تو یه بازه‌ی زمانی؟)، count_distinct_within، و sum_within (مجموع یه مقدار تو یه بازه) هستن؛ دقیقاً همون عملگرهایی که برای بیان قوانین بالا لازمه.

ادغام با Amazon Bedrock AgentCore

Dogwood مستقیم پشت یه قابلیت جدید تو AgentCore Policy قرار گرفته؛ لایه‌ای تو Amazon Bedrock AgentCore که مستقل از خود مدل عمل می‌کنه: مدل یه tool call رو پیشنهاد می‌ده، policy engine قبولش می‌کنه یا ردش می‌کنه، و خود مدل هیچ‌وقت مستقیم درگیر اجرای enforcement نمی‌شه. تا قبل از این، این چک‌ها کاملاً stateless بودن؛ حالا با «temporal policies» که Dogwood قدرتش رو می‌ده، این تصمیمات می‌تونن به تاریخچه‌ی سشن agent هم نگاه کنن.

AWS همچنین یه ابزار به اسم Policy Authoring هم معرفی کرده که با هوش مصنوعی، سند policy نوشته‌شده به زبون طبیعی رو مستقیم به قوانین Dogwood درست تبدیل می‌کنه؛ یعنی لازم نیست حتماً خودت سینتکس Dogwood رو یاد بگیری تا بتونی قوانین سازمانیت رو پیاده کنی.

چطور همین الان امتحانش کنیم

Dogwood زیر لایسنس Apache 2.0 منتشر شده و شامل یه راهنمای زبان و یه پیاده‌سازی مرجع (reference interpreter) روی گیت‌هابه. برای شروع:

یه نمونه‌ی خیلی ساده از یه قانون Dogwood که همون سناریوی پرداخت اول مقاله رو حل می‌کنه، تقریباً این‌طور به نظر می‌رسه (بر پایه‌ی گسترش Cedar):

یعنی پرداخت فقط زمانی مجازه که قبلش یه فاکتور برای همون resource ثبت شده باشه، و مجموع پرداخت‌های همون روز از یه سقف مشخص بیشتر نشه.

اگه از قبل رو Amazon Bedrock AgentCore کار می‌کنی، AgentCore Policy همین الان از Dogwood پشتیبانی می‌کنه و می‌تونی مستقیم ازش استفاده کنی. اگه رو یه استک دیگه کار می‌کنی، می‌تونی پیاده‌سازی مرجع رو مستقیم از گیت‌هاب بگیری و باهاش آزمایش کنی.

نکته‌ی مهم: هنوز برای production آماده نیست

خود AWS صراحتاً اعلام کرده که پیاده‌سازی مرجع Dogwood برای اکتشاف و تست طراحی شده، نه استفاده‌ی production. اگه بخوای این رو تو یه محیط واقعی اجرا کنی، باید خودت چیزهایی مثل نگه‌داری قابل‌اعتماد تاریخچه‌ی رویدادها، ایزوله‌سازی بین tenant های مختلف، و سیاست نگه‌داری داده رو پیاده‌سازی کنی؛ این‌ها جزو خود زبان یا reference interpreter نیستن.

چرا این موضوع مهمه

با گسترش استفاده از agent های خودمختار برای کارهای حساس (پرداخت، دسترسی به داده‌ی حساس، تغییرات زیرساختی)، مشکلی که Dogwood حلش می‌کنه دقیقاً همون چیزیه که این روزها تو خیلی از تیم‌های مهندسی مطرحه: چطور می‌شه به یه agent اجازه داد کار واقعی انجام بده، بدون این‌که مجبور بشیم به کل هیستوری رفتارش اعتماد کورکورانه داشته باشیم؟ Dogwood با اضافه کردن حافظه به لایه‌ی authorization (بدون از دست دادن قابلیت‌های اثبات‌پذیر Cedar)، یه جواب مشخص و متن‌باز به این سؤال می‌ده؛ و چون AWS از جامعه دعوت کرده که Dogwood رو تو محصولات و پروژه‌های خودشون هم بسازن، این رویکرد می‌تونه فراتر از خود AWS هم به یه استاندارد غیررسمی تبدیل بشه.

نتیجه‌ی هر ارزیابی می‌تونه allow، deny، یا یه زنجیره‌ی پیچیده‌تر شامل داور LLM یا تأیید انسانی (مثلاً از طریق Slack) باشه؛ یعنی برای عملیات پرریسک مثل kubectl delete pod، می‌شه درخواست رو متوقف کرد تا یه انسان تأییدش کنه.

مدیریت credential ها

یکی از نکات کلیدی طراحی اینه که credential های واقعی هیچ‌وقت رو خود agent نمی‌شینن. Agent فقط یه placeholder می‌فرسته، و این gateway است که موقع عبور دادن ترافیک، توکن واقعی رو جایگزینش می‌کنه. یعنی حتی اگه agent کامل کنترل بشه یا لاگش لو بره، خود secret ها هیچ‌وقت در معرض دید agent قرار نمی‌گیرن.

سه مدل استقرار

طبق ریپازیتوری رسمی گیت‌هاب، Claw Patrol سه شکل مختلف استقرار داره:

• clawpatrol run: یه تونل مخصوص هر پروسه باز می‌کنه (رو لینوکس با netns، رو مک با NetworkExtension)؛ فقط ترافیک همون دستور wrap‌شده از gateway عبور می‌کنه.
• clawpatrol join: یه تونل WireGuard کامل بالا میاره که کل ترافیک host رو مسیر می‌ده.
• clawpatrol gateway: خود proxy است؛ یه باینری تکی که HCL config رو لود می‌کنه و کلاینت‌ها رو می‌پذیره.

می‌تونی هرکدوم از این سه شکل رو بسته به نیازت انتخاب کنی؛ لازم نیست همیشه کل host رو مسیر بدی.

چطور همین الان امتحانش کنیم

پروژه زیر لایسنس MIT منتشر شده و از طریق اسکریپت نصب خود پروژه یا از سورس (که نیاز به Go و Node.js داره) قابل بیلده. برای شروع:

بعد از نصب، یه فایل HCL برای قوانینت می‌نویسی (مثلاً بلاک کردن DROP TABLE رو یه دیتابیس خاص، یا نیاز به تأیید انسانی برای حذف پاد رو Kubernetes production)، و agent ت رو طوری تنظیم می‌کنی که ترافیکش از یکی از سه مسیر بالا عبور کنه. ابزار همچنین یه دستور clawpatrol test هم داره که می‌تونی قوانینت رو در برابر یه سری fixture (رکورد شده از دشبورد یا نوشته‌شده‌ی دستی) تو CI تست کنی؛ اگه یه تغییر قانون، نتیجه‌ی یه fixture رو عوض کنه، تست fail می‌شه و diff نشونت می‌ده.

نکته‌ی مهم: هنوز alpha است

خود Deno صراحتاً اعلام کرده که Claw Patrol فعلاً alpha software است. پشتیبانی پروتکل‌ها دقیقاً به اندازه‌ی نیاز خود Deno گسترشه، نه بیشتر؛ اگه پروتکل خاصی می‌خوای که پشتیبانی نمی‌شه، باید یا خودت کدش رو اضافه کنی (مستندات کافی برای این کار هست)، یا از تیم Deno درخواست کنی. شرکت هم صراحتاً از جامعه خواسته که الگوهای قانون‌نویسی واقعی، پروتکل‌های موردنیاز بعدی، و باگ‌های مسیر نصب رو گزارش بدن.

جمع‌بندی

اگه داری agent هایی می‌سازی که دسترسی نوشتنی به زیرساخت واقعی (دیتابیس، کلاستر، سرویس‌های ابری) دارن، Claw Patrol یه لایه‌ی امنیتی جدی و متن‌باز ارائه می‌ده که فراتر از یه HTTP proxy ساده عمل می‌کنه؛ مخصوصاً به این خاطر که پروتکل‌های غیر-HTTP رو هم می‌فهمه و credential های واقعی رو از دید خود agent مخفی نگه می‌داره. ولی چون هنوز alpha است، برای استفاده‌ی production جدی، بهتره اول رو یه محیط تست یا staging امتحانش کنی و منتظر بلوغ بیشتر پروژه بمونی.