Perplexity Portable Computer و یک انتخاب معماری متفاوت

Perplexity این هفته نسخهٔ محلی عامل «Portable Computer» را معرفی کرد؛ راه‌حلی که روی ایستگاه‌های کاری NVIDIA DGX اجرا می‌شود و نشان می‌دهد به‌جای افزایش صرفِ اندازهٔ مدل‌ها برای بهبود اطمینان، وظایف بین «استدلال احتمالاتی» و «کنترل قطعی» تفکیک شده است. هزینهٔ اجرا قابل‌توجه است: یک DGX Spark از $4,700 شروع می‌شود و یک کارت 24GB RTX 3090 دست‌دوم بالای $1,500 قیمت دارد.

تفکیک نقش‌ها: پیشنهادگر و مرجع اعمال

در این معماری، مدل محلی به‌عنوان پیشنهادگر عمل می‌کند و احتمالاً اقدام بعدی را پیشنهاد می‌دهد—مثلاً تعیین می‌کند چه ابزاری فراخوانی شود یا چه زمانی از یک سرویس ابری مشورت گرفته شود—اما تصمیم نهایی برای اجرای آن اقدام توسط نرم‌افزار قطعیِ ارکستراتور گرفته می‌شود. این جداسازی شبیه مفهوم control plane است: استدلال، گزینه‌ها را ارائه می‌دهد و نرم‌افزارِ قابل‌بررسی اختیار را حفظ می‌کند.

هارنس (harness) و نقش محوری آن

Perplexity از اصطلاح «هارنس» برای توصیف چارچوبی استفاده می‌کند که زمینه را گردآوری، سیاست‌ها را اعمال و فراخوانی ابزارها را داخل یک سندباکس در سطح سیستم‌عامل اجرا می‌کند. هارنس فراتر از کد ارکستراسیون است و شامل پرامپت‌ها، اسکیمای ابزارها، مدیریت کانتکست، قلاب‌های تأیید و پردازش اسناد می‌شود. Nate Kupp، معاون Perplexity در بخش سازمانی، می‌گوید بخش زیادی از تلاش مهندسی روی همین هارنس متمرکز بوده است.

نتایج بنچ‌مارک: همان وزن‌ها، نتایج متفاوت

برای برجسته‌سازی اهمیت معماری، Perplexity مدل پایه و سخت‌افزار را ثابت نگه داشت و Qwen3.8-27B را روی یک DGX Spark در سه پشتهٔ عامل اجرا کرد. در «Local Knowledge Work Bench» با 53 تکلیف ثابت، Computer امتیاز 82.6% کسب کرد، در حالی که Pi به 77.6% و Hermes به 74% رسیدند.

در مجموعهٔ ParseBench-100 که روی نمودارها، چیدمان‌ها، جداول و قالب‌بندی تمرکز دارد، فاصله افزایش یافت: Computer به 65.1%، Hermes به 34.6% و Pi به 13.9% رسید. از آن‌جا که وزن‌های پایه ثابت بودند، این اختلاف نشان‌دهندهٔ تأثیر پلتفرم و مهندسی هارنس است، نه صرفاً مدل بهتر.

Perplexity سپس Qwen را پس‌ترِین کرد و نسخهٔ PPLX 27B را با 85.4% گزارش داد؛ نشانه‌ای که هر دو عامل—مهندسی هارنس و بهینه‌سازی وزن‌ها—در عملکرد نهایی نقش دارند.

امنیت: مرز سندباکس بیرون از مدل

Perplexity مرز امنیتی را در سندباکس قرار می‌دهد، نه در خود مدل. سندباکس فرایندها، مسیرهای فایل‌سیستم و دسترسی شبکه را محدود می‌کند و هرگاه سندباکس در دسترس نباشد، هارنس از فراخوانی ابزارها جلوگیری می‌کند. کاربرد کد قطعی در لایهٔ کنترل امکان بازرسی و ممیزی سیاست‌ها را فراهم می‌آورد؛ با این حال کد قطعی نیز ممکن است حاوی آسیب‌پذیری یا رفتار نادرستی باشد که به اجرای غیرمبتنی بر مدل منجر می‌شود.

تمایز اصلی این است که آیا اعمال مجوزها و سیاست‌ها توسط ساختاری قابل‌بررسی انجام می‌شود یا صرفاً از مدل خواسته می‌شود که به‌صورت لفظی «تبعیت کند». این انتخاب روش مدیریت ریسک و شفافیت در سازمان‌ها را تعیین می‌کند.

مصرف کانتکست و مدیریت پنجرهٔ زمینه

Perplexity گزارش می‌دهد Qwen3.8-27B پنجرهٔ زمینهٔ اعلام‌شدهٔ 260,000 توکن دارد، اما کارایی آن پس از حدود 100,000 توکن کاهش می‌یابد. بنابراین هارنس پرامپت اصلی و مجموعهٔ ابزارها را کوچک نگه می‌دارد و مهارت‌ها را بر حسب تقاضا بارگذاری می‌کند. برخی کانکتورها به ابزارهای خط فرمان تبدیل شده‌اند تا نیازی به قرار دادن تعاریف کاملِ Model Context Protocol در کانتکست دائمی نباشد.

آزمون‌های محلی در مقابل مشورت ابری

اجرای محلی در Terminal Bench 2.1 به‌طور محلی 59.6% گزارش شد؛ اما وقتی عامل محلی اجازهٔ مشورت با Claude Opus 5 را پیدا کرد، نتیجه به 73.0% افزایش یافت. برای مقایسه، Opus 5 به‌تنهایی 82.4% کسب کرد. این ارقام نشان می‌دهد اجرای محلی ممکن است محدودیت‌هایی داشته باشد و ترکیب محلی-ابری بتواند بخشی از شکاف عملکرد را کاهش دهد، هرچند نه لزوماً تا سطح کامل سرویس ابری.

پیام برای شرکت‌ها

  • تمرکز روی لایهٔ اختیار: در ارزیابی عامل‌های محلی، تمرکز باید بر لایه‌ای باشد که اختیار را می‌دهد و می‌گیرد—هارنس، سندباکس و سیاست‌های اجرایی—نه صرفاً روی وزن‌های مدل.
  • هزینهٔ سخت‌افزار و مقیاس‌پذیری: اجرای محلی روی DGX هزینه‌بر است؛ سازمان‌ها باید هزینه را در برابر مزایای کاهش تأخیر و کنترل داده‌ها بسنجند. برای آگاهی از مشخصات سخت‌افزار به صفحات NVIDIA مراجعه کنید.
  • تعادل محلی و ابری: مدل‌های محلی پیشرفته‌اند اما در برخی کاربردها هنوز با مدل‌های ابری فاصله دارند؛ ترکیب هوشمندانهٔ محلی و ابری معمولاً بهترین نتیجه را می‌دهد. این رویکرد می‌تواند شامل استفاده از سرویس‌ها یا مشاوران خارجی مانند Anthropic باشد.

نتیجه‌گیری

معماری Perplexity نشان می‌دهد مهندسی پلتفرم—شامل پرامپت‌ها، اسکیمای ابزارها، مدیریت کانتکست و هارنس—می‌تواند به اندازهٔ خودِ مدل تعیین‌کننده باشد. سازمان‌هایی که قصد استقرار عامل‌های محلی دارند باید بیش از وزن‌های مدل به نحوهٔ اعمال اختیار و مرزبندی امنیتی توجه کنند تا سامانه‌ها هم قابل‌اطمینان و هم کنترل‌شدنی باقی بمانند.

ارجاعات و منابع

برای بررسی بیشتر به سایت رسمی Perplexity و مستندات مدل‌ها مراجعه کنید. مرجع مناسب برای مفهوم کنترل و control plane صفحهٔ Wikipedia است.