جست‌وجوی OpenAI در برابر استنتاج GPT؛ جداسازی ابزار از تفکر

«مدل استدلالی و موتور جست‌وجو دیگر نیازی ندارند که یک موجودیت واحد باشند.» این فرض بنیادین در پسِ pi-gpt-search نهفته است؛ ابزار جدیدی که توسط توسعه‌دهنده‌ای ساخته شده که بک‌اند OpenAI Codex را مهندسی معکوس کرده است. این ابزار با ایزوله کردن لایه بازیابی وب (Web Retrieval Layer) در Codex، به مدل‌هایی مانند Claude، Gemini یا مدل‌های زبانی محلی (Local LLMs) اجازه می‌دهد تا فرآیند جست‌وجو را مدیریت کنند، در حالی که خودِ مدل همچنان تنها عامل مسئول استدلال باقی می‌ماند.

این پیشرفت در حالی رخ می‌دهد که صنعت هوش مصنوعی با مشکل «آلودگی زمینه» (Context Pollution) و پیوند شدید قابلیت‌های عامل‌ها به ارائه‌دهندگان خاص دست‌وپنجه نرم می‌کند. در حالی که پیش‌تر پوشش دادیم که شرکت Anthropic چگونه از اوت ۲۰۲۶ برای ردیابی منشأ هوش مصنوعی، واترمارک‌های جهانی را برای خروجی‌های Claude پیاده‌سازی می‌کند، چالش فعلی برای توسعه‌دهندگان اغلب «هارنس» (Harness) است؛ یعنی ابزارها، حافظه و زیرساخت‌های جست‌وجویی که مدل را احاطه کرده‌اند.

تصور کنید سناریویی را که در آن برای حفظ حریم خصوصی، قابلیت‌های استدلالی یک مدل محلی را ترجیح می‌دهید، اما در عین حال به ایندکس وب باکیفیت یک ارائه‌دهنده پیشرو نیاز دارید. به‌طور سنتی، شما مجبور بودید کل اکوسیستم آن ارائه‌دهنده را بپذیرید. pi-gpt-search این پیوند را می‌شکند و با جست‌وجو به عنوان یک ابزار کاربردی مستقل (Standalone Utility) برخورد می‌کند، نه به عنوان یک ویژگی ادغام‌شده در مدل. این رویکرد در تضاد با مدل‌های یکپارچه‌ای است که در آن‌ها جست‌وجو به عنوان یک قابلیت داخلی ارائه می‌شود، مشابه آنچه اخیراً در سرویس بدراک آمازون برای مدل‌های GPT-5 مشاهده شد.

فرآیند مهندسی معکوس

این پروژه با تحلیل پروتکل app-server در Codex آغاز شد. توسعه‌دهنده کار را با رهگیری ترافیک شبکه به‌صورت تصادفی یا حدس زدن درخواست‌ها شروع نکرد. در عوض، او از اطلاعات ساختاری که از طریق تولید پروتکل خودِ Codex در دسترس بود، استفاده کرد. او با اجرای دستور codex app-server generate-ts --out /tmp/codex-ts توانست پیوندهای پروتکل TypeScript را تولید کند.

جست‌وجو در این تعاریف تولید شده، انواع داده‌های حیاتی مانند WebSearchItem و WebSearchAction را آشکار کرد. یک کامنت در مستندات Rust به‌طور مشخص افشاگر بود و بیان می‌کرد: «نتایج جست‌وجوی ساختاریافته که به‌صورت خارج از باند (out-of-band) توسط جست‌وجوی وب مستقل بازگردانده می‌شوند.» اصطلاحات «مستقل» و «خارج از باند» شواهدی بودند که ثابت می‌کرد جست‌وجوی وب صرفاً یک اثر جانبی مبهم در داخل یک نوبت (Turn) معمولی مدل Codex نیست.

برای یافتن نقطه اتصال (Endpoint) واقعی، توسعه‌دهنده فایل باینری Codex را کاوش کرد. او فایل اجرایی نصب شده را با استفاده از دستور strings /Applications/ChatGPT.app/Contents/Resources/codex | grep -iE "(search|alpha/search|backend-api)" جست‌وجو کرد. این عملیات چندین شناسه کلیدی را بازگرداند:

• standalone_web_search
• codex.web_search.results
• alpha/search
• https://chatgpt.com/backend-api/

این نتایج در نهایت به کشف نقطه اتصال مستند نشده منجر شد: https://chatgpt.com/backend-api/codex/alpha/search.

بازسازی قرارداد API

یافتن URL تنها نیمی از مشکل بود؛ شمای واقعی درخواست‌ها همچنان ناشناخته بود. توسعه‌دهنده از روشی به نام «بازسازی مبتنی بر خطا» (Error-driven Reconstruction) استفاده کرد. او با استفاده مجدد از اعتبارنامه‌های OAuth که توسط codex login تولید شده بود، نقطه اتصال را با درخواست‌هایی که عمداً ناقص بودند، مورد بررسی قرار داد. خطاهای اعتبارسنجی بک‌اند به عنوان راهنمایی برای بازسازی قرارداد عمل کردند:

• شناسه گم‌شده: ارسال تنها یک پرس‌وجو (Query) منجر به خطایی درباره نبود id شد.
• مدل گم‌شده: افزودن id سپس فیلد مورد نیاز بعدی یعنی model را آشکار کرد.
• پاسخ‌های اعتبارسنجی: افزودن مدل باعث تولید پاسخ‌های اعتبارسنجی بیشتری شد.
• سینتکس دستور: ارسال command به‌جای commands منجر به دریافت یک اصلاحیه شد.
• ناهماهنگی نوع: ارسال نوع اشتباه برای search_query فاش کرد که API منتظر آرایه‌ای از اشیاء است.

ساختار نهایی و حداقلی درخواست به این شکل است:

{
  "id": "1",
  "model": "gpt-4o",
  "commands": {
    "search_query": [
      {
        "q": "OpenAI Codex GitHub repository"
      }
    ]
  }
}

شفاف‌سازی در مورد فیلد model ضروری است. در حالی که نقطه اتصال این فیلد را به عنوان بخشی از پروتکل می‌طلبد، pi-gpt-search پرامپت کاربر را برای حل مسئله به GPT نمی‌فرستد. مدل فعال Pi همچنان تصمیم می‌گیرد که چه چیزی جست‌وجو شود، اطلاعات را دریافت می‌کند و استدلال را انجام می‌دهد.

مکانیزم استنتاج صفر (Zero-GPT Inference)

یک ادعای حیاتی در این پروژه، «استنتاج صفر از GPT» است. برای تأیید این موضوع، توسعه‌دهنده یک تست زنده با استفاده از یک پروکسی رهگیر برای پوشاندن فراخوانی‌های fetch() پیاده‌سازی کرد. این تست تمام درخواست‌های خروجی را برای مسیرهای مرتبط با اجرای مدل، از جمله مسیرهای تکمیل (completion)، پاسخ (response)، گفتگو (conversation) و شروع نوبت (turn-start) نظارت می‌کند. اگر افزونه سعی کند هر یک از این مسیرها را فراخوانی کند، تست شکست می‌خورد.

طبق گزارش dev.to که در ۱۱ اوت ۲۰۲۶ منتشر شد، این تست تأیید می‌کند که افزونه دقیقاً دو درخواست HTTP برای جست‌وجوی مستقل ارسال می‌کند و صفر درخواست مجزا برای استنتاج مدل GPT می‌فرستد. رفتار شبکه مورد انتظار به این صورت است:

pi-gpt-search $ \rightrightarrows $ /backend-api/codex/alpha/search $ \rightrightarrows $ /backend-api/codex/alpha/search

این موضوع تأیید می‌کند که افزونه هیچ نوبت مدل GPT/Codex اضافی را به عنوان بخشی از جریان کاری جست‌وجو انجام نمی‌دهد. اگرچه توسعه‌دهنده نمی‌تواند بک‌اند داخلی OpenAI را بازرسی کند تا ثابت کند هیچ مدلی در داخل سرویس /codex/alpha/search وجود ندارد، اما ویژگی مهم این است که هیچ نوبت مدل اضافی توسط افزونه شروع نمی‌شود و مدل فعال Pi همچنان عامل استدلالی باقی می‌ماند.

از جست‌وجوی ساده تا تحقیق وب

این ابزار دو رابط مجزا را برای مدل استدلالی فراهم می‌کند تا یک نقطه اتصال خام را به یک ابزار پژوهشی تبدیل کند:

1. codex-search
این رابط بازیابی‌های ساده تک‌پرس‌وجویی را مدیریت می‌کند. این رابط پرس‌وجو را به همراه پارامترهای اختیاری برای کنترل می‌پذیرد:

• فیلتر دامنه: محدود کردن نتایج به سایت‌های خاص (مثلاً domains: ["rust-lang.org"]).
• فیلتر تازگی: کنترل اینکه نتایج تا چه حد باید به‌روز باشند.
• کنترل طول پاسخ: تنظیم طول پاسخ روی «کوتاه»، «متوسط» یا «بلند».

یک نمونه فراخوانی به این صورت خواهد بود: codex-search({ query: "latest Rust release", domains: ["rust-lang.org"], response_length: "short" }).

2. codex-research
این یک هارنس پژوهشی غنی‌تر است. از آنجا که عامل‌ها اغلب نیاز دارند جست‌وجو کنند، یک نتیجه را بررسی کنند، بخش خاصی را بیابند و سپس یک مرجع دیگر را دنبال کنند، codex-research ساختار دستورات پیچیده‌تری را ارائه می‌دهد:

• Search Query: اجازه پرس‌وجوهای دقیق را می‌دهد، مانند {"search_query": [{"q": "OpenAI Codex GitHub repository", "domains": ["github.com"]}], "response_length": "medium"}.
• Open: به مدل اجازه می‌دهد یک مرجع بازگردانده شده را با استفاده از ref_id باز کند (مثلاً {"open": [{"ref_id": "turn0search0"}]}).
• Find: اجازه جست‌وجو در داخل یک سند خاص را می‌دهد (مثلاً {"find": [{"ref_id": "turn1view0", "pattern": "terminal"}]}).
• Click: پشتیبانی از کلیک روی عناصر در جریان پژوهش.

ارائه‌دهنده یک هویت نشست (Session Identity) پایدار را در طول این فراخوانی‌ها حفظ می‌کند و تضمین می‌کند مراجعی که در یک عملیات تولید شده‌اند، در مراحل بعدی مفید باقی بمانند. این امر ابزار را از یک پوشش ساده جست‌وجو به یک هارنس کامل پژوهش وب تبدیل می‌کند.

حل مشکل آلودگی زمینه

یکی از موانع فنی اصلی در مرورگری عامل‌محور، «آلودگی زمینه» است؛ یعنی هدر دادن توکن‌ها با ریختن پاسخ‌های خام وب، متادیتای HTTP و ساختارهای عظیم نتایج مستقیماً در زمینه مدل فعال.

pi-gpt-search این مشکل را با جداسازی محتوای رو به مدل از متادیتای TUI (رابط کاربری ترمینال) حل می‌کند. خروجی‌های پاک‌سازی شده و استنادها به مدل استدلالی بازگردانده می‌شوند، در حالی که نتایج ساختاریافته مفصل به عنوان متادیتای جزئیات محلی باقی می‌مانند که توسط UI مدل Pi استفاده می‌شوند. علاوه بر این، لایه خروجی، مراجع استناد داخلی Codex را به مراجع منبع قابل استفاده و هایپرلینک‌های ترمینال تبدیل می‌کند تا تضمین شود مدل فقط اطلاعات مورد نیاز برای ادامه استدلال را دریافت می‌کند، بدون اینکه هر بایت بازگردانده شده توسط بک‌اند را به ارث ببرد.

پیاده‌سازی و محدودیت‌ها

این افزونه از نشست‌های احراز هویت موجود Codex استفاده مجدد می‌کند. اگر کاربر قبلاً codex login را اجرا کرده باشد، ابزار توکن دسترسی و شناسه حساب را از ~/.codex/auth.json می‌خواند. اعتبارنامه‌ها همچنین می‌توانند از طریق متغیرهای محیطی ارائه شوند. درخواست جست‌وجو تنها شامل دستور و متادیتای نشست است؛ این ابزار کل گفتگوی Pi، فایل‌های پروژه یا پرامپت سیستم را به نقطه اتصال جست‌وجو ارسال نمی‌کند. این امر از تفویض بی‌صدای کل مسئله به عاملی دیگر توسط ابزار جست‌وجو جلوگیری می‌کند.

برای تضمین قابلیت اطمینان، ارائه‌دهنده مدیریت صریحی برای موارد زیر در نظر گرفته است:

• شکست‌ها: شکست‌های احراز هویت، شکست‌های مجوزدهی و Time-outها.
• مشکلات شبکه: پاسخ‌های گذار ۵۰۲، ۵۰۳ و ۵۰۴ به‌طور خودکار تکرار (Retry) می‌شوند.
• لغو عملیات: AbortSignal مدل Pi به درخواست متصل است، بنابراین لغو یک عملیات ابزار، باعث لغو fetch زیربنایی می‌شود، به‌جای اینکه یک درخواست HTTP در پس‌زمینه در حال اجرا باقی بماند.

این پروژه توسط یک مجموعه تست جامع پشتیبانی می‌شود:

• تست‌های واحد (Unit Tests): برای اعتبارسنجی دستورات و نرمال‌سازی پاسخ‌ها.
• تست‌های یکپارچگی (Integration Tests): برای بررسی رفتار ارائه‌دهنده.
• تست‌های نقطه اتصال زنده: تأیید وضعیت فعلی API مستند نشده.
• تست استنتاج صفر: همان تست پروکسی رهگیر که پیش‌تر ذکر شد.
• تست سرتاسری (End-to-End): یک تست کامل از هارنس پژوهش.

این ابزار در npm منتشر شده و از طریق pi install npm:pi-gpt-search یا به‌صورت موقت با pi -e npm:pi-gpt-search قابل اجرا است. کاربران همچنین می‌توانند آن را به‌صورت محلی در پروژه با پرچم -l نصب کنند. پس از نصب، مدل به codex-search و codex-research دسترسی پیدا می‌کند و کاربران می‌توانند از دستور مستقیم /gpt-search [query] استفاده کنند. پیش‌نیازها شامل Pi، Node.js 18+ و یک نشست احراز هویت شده Codex است. این پروژه تحت مجوز MIT است.

با این حال، توسعه‌دهنده به چندین محدودیت قابل توجه اشاره می‌کند:

• پایداری: به عنوان یک رابط مستند نشده، OpenAI می‌تواند هر زمان که بخواهد شماما، احراز هویت یا نقطه اتصال را تغییر دهد. این ابزار جایگزینی برای یک API رسمی نیست.
• وابستگی: در حالی که مدل استدلالی مستقل است، زیرساخت بازیابی همچنان وابسته به ارائه‌دهنده (OpenAI) است. این ابزار «مستقل از مدل استدلالی» است، نه «مستقل از زیرساخت».
• دامنه: این یک مرورگر بدون سر (Headless Browser) نیست و فاقد رندر DOM کامل برای اتوماسیون دلخواه مرورگر است.

چرخش معماری

این پروژه یک درک رو به رشد در مهندسی هوش مصنوعی را برجسته می‌کند: یک «عامل کدنویسی» صرفاً یک مدل نیست. بلکه ترکیبی از یک مدل و یک هارنس متشکل از ابزارها، بازیابی، مدیریت زمینه، دسترسی به سیستم فایل، اجرای شل، زیرساخت مرورگر/جست‌وجو، حافظه، تأیید و سیاست‌های کنترل استفاده از آن‌هاست. این دیدگاه با تلاش‌هایی برای بهینه‌سازی محیط‌های اجرای کد همسو است، مانند آنچه پروژه Cobalt برای حذف تداخل محیط‌های کدنویسی AI از طریق اختصاص رایانه‌های ابری مجزا انجام داد.

با استخراج زیرسیستم جست‌وجو از Codex، توسعه‌دهنده نشان می‌دهد که این اجزا ترکیب‌پذیر (Composable) هستند. اکنون می‌توانید قدرت بازیابی یک ارائه‌دهنده را با منطق استدلالی ارائه‌دهنده دیگری جفت کنید. برای مثال، یک مدل Gemini می‌تواند تصمیم بگیرد که اطلاعات به‌روز مورد نیاز است، زیرساخت جست‌وجوی Codex را فعال کند، شواهد وب را دریافت کند و سپس استدلال نهایی را انجام دهد. این انعطاف‌پذیری در استفاده از زیرساخت‌های مختلف، مشابه روش‌هایی است که برای اجرای Codex CLI با مدل‌های پیشرفته‌تر مانند GPT-5 از طریق ارائه‌دهندگان سفارشی به کار می‌رود.

این تغییر نشان می‌دهد که آینده عامل‌های هوش مصنوعی ممکن است نه یک «مدل خدا» (God-model) که همه کارها را انجام دهد، بلکه پشته‌ای ماژولار از ابزارهای تخصصی باشد که توسط یک موتور استدلالی مرکزی هماهنگ می‌شوند. هنگامی که مدل و هارنس به عنوان اجزای مجزا در نظر گرفته شوند، معماری‌های عامل بسیار ترکیب‌پذیرتر می‌شوند. ابزار می‌تواند یک قرارداد پایدار را ارائه دهد، حتی زمانی که پیاده‌سازی پشت آن قرارداد متعلق به سیستمی کاملاً متفاوت باشد.