API تصمیم‌گیری (Decisions API) شرکت Perplexity اکنون با فعال‌سازی مبنی‌سازی وب زنده (live web grounding) روی ادعاهای واقعیِ زمان‌حساس به دقت ۹۷.۳٪ می‌رسد — جهشی که دقت را از ۵۶.۴٪ بدون مبنی‌سازی به بیش از ۹۷٪ می‌کشاند. این افزایش تک‌مرحله‌ای بزرگ‌ترین پیشرفت دقتی است که Perplexity برای نقطه‌پایانی تصمیم‌گیری ساختاریافته گزارش کرده است.
API تصمیم‌گیری از نقطه‌پایانی‌های استاندارد چت متمایز است: آن حالت (state) — متن، JSON، تصویر یا URL — را می‌پذیرد و به‌جای متنِ آزاد، پاسخ‌های عددی ساختاریافته برمی‌گرداند. یک سؤال بله/خیر احتمال بله را تولید می‌کند؛ یک سؤال چندگزینه‌ای احتمال هر گزینه را؛ و یک سؤال امتیازدهی احتمالات روی یک مقیاس ترتیبی به‌علاوه امتیاز انتظار. توسعه‌دهندگان این مقادیر را به‌عنوان آستانه‌ها در طبقه‌بندی، مسیریابی و سایر تصمیمات خودکار به کار می‌برند.
Perplexity ویژگی مبنی‌سازی وب را در ۴ نوامبر ۲۰۲۶ اعلام کرد. شرکت مواردی را هدف قرار داده که جوابشان پس از آموزش قابل تغییر است: سمت اجرایی یک شخص، انتشار جدیدترین یک بسته نرم‌افزاری، یا اینکه یک رویداد همچنان در برنامه است. ویژگی زمانی فعال می‌شود که توسعه‌دهنده پارامتر mode را روی web_grounding تنظیم کند.
جستجوی زنده در دروازه API (API gateway) Perplexity قبل از فراخوانی مدل اجرا می‌شود. دروازه برای هر سؤال یک پرس‌وجو از متن سؤال و ابتدای متن حالت می‌سازد. جستجوها به‌صورت موازی اجرا شده، نتایج ادغام و URLهای تکراری حذف می‌شوند. سؤال‌هایی که پرس‌وجوی یکسانی تولید می‌کنند یک جستجوی مشترک دارند. دروازه سپس عناوین صفحات، URLها و متن‌ها را به عنوان شواهد به حالت الحاق می‌کند. پاسخ‌ها همچنان مبتنی بر احتمال هستند، در حالی که فیلد search_results به توسعه‌دهندگان اجازه می‌دهد ببینند مدل چه چیزی دیده است.
جستجوها محدودیت‌های صریح دارند. حداکثر ۱۰ جستجو به‌صورت همزمان با سقف یک ثانیه برای هر جستجو و سه ثانیه کل اجرا می‌شوند. تصاویر جستجو نمی‌شوند. پرس‌وجوها به API جستجوی Perplexity (Perplexity Search API) می‌روند و می‌توانند هم متن سؤال و هم بخش آغازین حالت را داشته باشند؛ بنابراین داده‌ای که به جستجو ارسال می‌شود بخشی از ملاحظات حریم خصوصی یکپارچه‌سازی است. شکست جستجوها لزوماً پاسخ تصمیم را متوقف نمی‌کند. اگر فقط برخی جستجوها موفق شوند، مدل از نتایج رسیده استفاده می‌کند. اگر هیچ‌کدام موفق نشوند، از حالت اصلی پاسخ می‌دهد و آرایه search_results خالی برمی‌گرداند.
Perplexity همان مدل تصمیم را روی ۳۲۸ ادعای درست/نادرست مستخرج از اخبار اکتبر ۲۰۲۶ و حقایق نادر ویکی‌پدیا آزمایش کرد. هر ادعای درست یک همتای نادرست با اختلاف در یک جزئی داشت. هیچ شهادی در حالت فراهم نشده بود. دقت بدون مبنی‌سازی ۵۶.۴٪ و با آن ۹۷.۳٪ بود. خطاها از ۱۴۳ به ۹ مورد کاهش یافتند. تأخیر میانه از ۱۳۹ به ۳۶۶ میلی‌ثانیه و تأخیر صدک ۹۵ از ۵۱۴ به ۷۴۲ میلی‌ثانیه افزایش یافت.
سیستم‌های وب موازی (Parallel Web Systems) یک بنچمارک جداگانه به نام PWS-Decisions با ۳۰۰ سؤال بسته دارد. این مجموعه برای دشواری انتخاب شده، نه برای برآورد دقت روی ترافیک متوسط. تابلوی امتیازات Parallel دقت میانگین و انحراف معیار نمونه در سه اجرا ارزیابی‌شده در ۲۹ اکتبر ۲۰۲۶ را گزارش می‌دهد و دقت ۵۱٪ روی مجموعه عمومی برای Perplexity Decisions را نشان می‌دهد. Perplexity اعلام کرد که pplx-decider-v1.2 با مبنی‌سازی وب در اجرای ۴ نوامبر ۲۰۲۶، ۸۶ از ۱۰۰ سؤال عمومی را درست پاسخ داده — بالاترین دقت مجموعه عمومی در برابر آن تابلوی امتیازات منتشرشده. مشتری شرکت تأخیر میانه ۳۷۰ میلی‌ثانیه و صدک ۹۵ به ۶۸۵ میلی‌ثانیه روی آن ۱۰۰ سؤال را اندازه‌گیری کرده است.
قیمت‌گذاری هزینه جستجو را بر هزینه توکنها اضافه می‌کند. یک درخواست مبناسازی می‌تواند تا ۱۰۰ سؤال داشته باشد. هر جستجوی کامل ۰.۰۰۱ دلار هزینه دارد، بنابراین هزینه جستجو برای درخواست ۱۰۰ سؤالی حداکثر ۰.۱۰ دلار است. شواهد بازیابی‌شده نیز به عنوان توکن‌های ورودی محاسبه شده و به سقف ۲۵۶ هزار توکن ورودی احتساب می‌شوند. مدل استاندارد pplx-decider-v1.2 هزینه ۰.۰۲ دلار در میلیون توکن ورودی دارد. نوع فلش (flash) هزینه ۰.۰۱ دلار در میلیون توکن دارد. توکن‌های خروجی رایگان هستند. گروه‌بندی سوالات صورتحساب توکن نهایی را تحت تأثیر قرار می‌دهد. روی مدل استاندارد، شواهد وقتی محدودیت ورودی سوالات را به گروه‌های جداگانه می‌شکند، مجدد شمارش می‌شوند. فلش هر سؤال را به‌صورت مستقل ارزیابی کرده و حالت و شواهد را هر بار مجدد محاسبه می‌کند.
یکپارچه‌سازی در حال حاضر یک نکته تایپ‌گذاری (typing) دارد. کتابخانه پایتون Perplexity نسخه ۰.۴۴.۰ یا جدیدتر و SDK تایپ‌اسکریپت نسخه ۰.۳۹.۰ یا جدیدتر API را پشتیبانی می‌کنند. نوع‌های آن‌ها هنوز mode و search_results را افشا نمی‌کنند. پایتون mode را از طریق extra_body عبور می‌دهد. تایپ‌اسکریپت آن را در بدنه درخواست می‌فرستد. کارهای پیشنهادی Perplexity شامل بررسی اینکه آیا حساب‌ها در ۹۰ روز گذشته سرمایه جذب کرده‌اند، نظارت بر وابستگی‌ها برای انتشارهای پایدار جدیدتر از یک نسخه پین‌شده، و تأیید اینکه یک رویداد همچنان برنامه‌ریزی شده است قبل از اینکه یک عامل (agent) آن را رزرو کند، می‌شود.
جهش دقت شگفت‌انگیز است اما با مقادیر قابل‌سنجش هزینه‌بر است. تأخیر در میانه تقریبا دو برابر و در صدک ۹۵ به میزان ۴۴٪ افزایش می‌یابد. مصرف توکن به دلیل شمارش شواهد به عنوان ورودی رشد می‌کند. هزینه جستجو یک بُعد متغیر هزینه جدید اضافه می‌کند. توسعه‌دهندگان باید بسنجند که آیا تغییر احتمال برای هر گردش‌کار تأخیر و هزینه را توجیه می‌کند. فیلد search_results امکان بازبینی را فراهم می‌کند که برای ردپای حسابرسی و اشکال‌زدایی مهم است.
تفاوت بنچمارک‌ها توجه می‌طلبد. تست داخلی Perplexity ۹۷.۳٪ روی ۳۲۸ ادعا بدون شاهد در حالت را نشان می‌دهد. مجموعه عمومی PWS-Decisions ۸۶٪ روی ۱۰۰ سؤال را گزارش می‌دهد. مجموعه خصوصی همچنان منتشر نشده است. توزیع‌های آزمایشی متفاوت بخشی از شکاف را توضیح می‌دهند. تست Perplexity از اخبار اکتبر ۲۰۲۶ و حقایق نادر ویکی‌پدیا استفاده کرد. PWS برای دشواری انتخاب کرده است. هیچ‌کدام ترافیک تولید متوسط را نمایندگی نمی‌کنند. تیم‌ها باید ارزیابی‌های خود را روی داده‌های نماینده اجرا کنند قبل از تعهد.
مدل قیمت‌گذاری القاهای جالبی ایجاد می‌کند. حالت فلش شواهد را برای هر سؤال محاسبه می‌کند که می‌تواند هزینه‌ها را برای دسته‌های بزرگ چند برابر کند. حالت استاندارد وقتی سوالات پرس‌وجوی جستجوی مشترکی دارند، شواهد را بازاستفاده می‌کند. توسعه‌دهندگانی که سوالات را برای بهینه‌سازی اشتراک پرس‌وجو ساختاربندی می‌کنند، کمتر پرداخت می‌کنند. سقف ۲۵۶ هزار توکن ورودی میزان شواهدی که در یک درخواست واحد جا می‌شود را محدود می‌کند. برای تصمیمات خودکار با حجم بالا، هزینه هر جستجوی ۰.۰۰۱ دلاری ممکن است هزینه توکنها را غلبه کند.
شکاف تایپ‌گذاری در SDKها یک نقطه اصطکاک موقت است. توسعه‌دهندگان پایتون باید از extra_body استفاده کنند. توسعه‌دهندگان تایپ‌اسکریپت mode را در بدنه درخواست می‌فرستند. هر دو کار می‌کنند اما ایمنی نوع برای فیلدهای جدید ندارند. Perplexity احتمالاً تعریف‌های نوع را به‌زودی به‌روزرسانی می‌کند. تا آن زمان، تیم‌ها باید اعتبارسنجی زمان اجرا برای search_results اضافه کنند تا حالت آرایه خالی هنگام شکست جستجوها مدیریت شود.
برای نتایج مجموعه خصوصی PWS-Decisions وقتی منتشر شوند منتظر بمانید. ۲۰۰ سؤال خصوصی ممکن است نشان دهد که آیا پیشرفت دقت روی موارد خصمانه یا خارج از توزیع نیز برقرار است. همچنین به‌روزرسانی‌های نوع SDK را رصد کنید — راهکار extra_body نشان‌دهنده انتشار پیوسته‌ی سریع است.
گام بعدی شما
- اگر خط لوله طبقه‌بندی یا مسیریابی خودکار می‌سازید، مبنی‌سازی وب را روی یک برش ترافیک سایه (shadow traffic) آزمایش کنید و تغییر احتمال روی آستانه‌های تصمیم واقعی خود را بسنجید.
- تأخیر و دلتای هزینه قابل پیش‌بینی هستند؛ دلتای دقت روی داده‌های شما نیست — ارزیابی نماینده قبل از استقرار الزامی است.
- سوالات را برای بهینه‌سازی اشتراک پرس‌وجوی جستجو بازنویسی کنید تا هزینه‌های حالت استاندارد و سقف توکن ورودی کنترل شود.
گفتگو