بلوک‌های رمزنگاری‌شده در برابر متون قابل‌انتقال؛ نبرد برای مالکیت تاریخچهٔ کاربر

اگر امروز یک برنامه کاربردی بر پایه APIهای هوش مصنوعی توسعه می‌دهید، باید بدانید که دیگر مالک تاریخچهٔ گفتگوهای کاربران خود نیستید. شما تنها به نمایی ناقص از جلساتی دسترسی دارید که کلید گشایش آن‌ها در دست شرکت‌های ارائه‌دهنده است.

وعده اولیه APIهای استنتاج (Inference) بسیار ساده و جذاب بود: ارسال یک ورودی و دریافت یک خروجی. در آن مدل، اگر شما هر دو طرف این تبادل (هم ورودی و هم خروجی) را ذخیره می‌کردید، مالک کامل آن گفتگو بودید. این بدان معنا بود که می‌توانستید محتوا را بازرسی کنید، آن را بایگانی نمایید، دوباره پخش کنید یا آن را به مدلی رقیب بدهید تا جریان کار را ادامه دهد. در واقع، رکورد معنایی یک جلسه — که شامل دستورالعمل‌ها، پیام‌ها، فراخوانی‌های ابزار (Tool Calls) و نتایج حاصل از ابزارها بود — متعلق به کاربر بود. حتی اگر مدل دیگری نمی‌توانست دقیقاً به همان شیوه پاسخ دهد، اما می‌توانست بفهمد چه اتفاقی افتاده است و کنترل جلسه را به دست بگیرد.

باید پذیرفت که این انتزاع هرگز به‌طور کامل صادق نبود. برای مثال، حافظه‌های پنهک (Prompt Caches) روی پردازنده‌های گرافیکی (GPU) شخص دیگری قرار دارند. نحوه توکن‌بندی (Tokenization) بین مدل‌های مختلف متفاوت است و نمونه‌برداری (Sampling) به‌طور عمدی غیرقابل‌تکرار طراحی شده است. با این حال، تغییر فعلی نشان‌دهنده یک تحول بنیادی‌تر در مالکیت هوش مصنوعی است. ارائه‌دهندگانی چون OpenAI، گوگل و آنتروپیک (Anthropic) به سمت مدلی حرکت می‌کنند که در آن وضعیت عملیاتی (Operational State) به‌طور عمدی غیرقابل‌انتقال است. آن‌ها مفهومی به نام «وضعیت مهروموم‌شدهٔ سازنده» (Provider-Sealed State) را معرفی کرده‌اند؛ بلوک‌های رمزنگاری‌شده و شناسه‌های سمت-سرور که فقط توسط همان ارائه‌دهنده اصلی رمزگشایی یا بازشناسی می‌شوند.

مکانیسم‌های حبس کاربر در اکوسیستم

انتقال به جلسات غیرقابل‌انتقال از چندین جبهه فنی در حال رخ دادن است. بر اساس تحلیل فنی EARENDIL که در ۳۱ ژوئیه ۲۰۲۶ منتشر شد، صنعت در حال جایگزینی تاریخچه‌های قابل‌فهم با نشانگرهای مبهم است.

• استدلال رمزنگاری‌شده: در مدل‌های بدون وزن‌های باز (Non-Open-Weights)، زنجیره تفکر (Chain-of-Thought) خام پنهان می‌شود. طبق مستندات، وقتی گزینه store: false فعال باشد، APIها محتویاتی را تحت عنوان encrypted_content باز می‌گردانند. این یک قابلیت حریم خصوصی برای کاربر نیست، بلکه کپسولی است که فقط سازنده آن را می‌گشاید. ارائه‌دهنده است که کلیدها را انتخاب می‌کند و تعریف می‌کند داده‌ها در کجا قابل بازپخش هستند. برای مثال، آنتروپیک تفکر کامل رمزنگاری‌شده را در یک فیلد امضا (Signature) بازمی‌گرداند؛ در حالی که متن تفکر خواندنی، اغلب تنها خلاصه‌ای است که توسط یک مدل دیگر تولید شده و نه زنجیره تفکر خام. این بلوک‌های تفکر باید در نوبت‌های استفاده از ابزار (Tool-use turns) بدون تغییر بازگردانده شوند و به مدل خاصی که آن‌ها را تولید کرده متصل هستند. مستندات آنتروپیک صراحتاً بیان می‌کند که این بلوک‌ها هنگام تعویض مدل باید حذف شوند، به این معنی که آن‌ها حتی در داخل یک اکوسیستم نیز قابل‌انتقال نیستند. نمونه‌هایی از این بلوک‌های مبهم عبارتند از: {"type": "reasoning", "encrypted_content": "gAAAAAB..."}، {"type": "thinking", "thinking": "", "signature": "EqQBCg..."} و {"type": "thought", "summary": [], "signature": "EpoGCp..."}.

• گفتگوهای ذخیره‌شده: APIهای پاسخ‌دهی OpenAI به‌طور پیش‌فرض پاسخ‌ها را ذخیره می‌کنند. مستندات این شرکت می‌گوید اشیاء پاسخ (Response Objects) به‌طور پیش‌فرض حداقل برای ۳۰ روز نگهداری می‌شوند؛ اما مواردی که به یک «گفتگو» (Conversation) متصل هستند، مشمول این محدودیت ۳۰ روزه (TTL) نمی‌شوند. APIهای Gemini نیز مشابه این عمل می‌کنند: مقدار پیش‌فرض روی store: true است، به‌طوری که تعاملات لایه پولی برای ۵۵ روز و لایه رایگان برای یک روز نگهداری می‌شوند. استفاده از store: true به برنامه اجازه می‌دهد تا داده‌های کمتری را از طریق ارجاعات previousResponseId ارسال کند که مسیریابی کش را تسهیل می‌کند، اما در واقع یک رونوشت محلی را به یک «کلید خارجی» (Foreign Key) در پایگاه‌داده‌ای تبدیل می‌کند که کاربر هیچ کنترلی روی آن ندارد.

• فشردگی مبهم: برای مدیریت پنجره‌های متنی (Context Window) طولانی، OpenAI از فشردگی سمت-سرور استفاده می‌کند که یک آیتم رمزنگاری‌شده تولید می‌کند. مستندات این شرکت صراحتاً توصیف می‌کند که این داده «مبهم و غیرقابل‌تفسیر برای انسان» است. نقطه اتصال (Endpoint) /responses/compact یک «پنجره متنی بعدی استاندارد» (Canonical next context window) بازمی‌گرداند که کلاینت‌ها باید دقیقاً همان را بازگردانند. این مکانیسم، یک تاریخچه گران‌قیمت اما قابل‌انتقال شامل ۲۰۰ هزار توکن قابل‌فهم (شامل پیام‌های کاربر، پیام‌های دستیار و نتایج ابزارها) را با یک رشته متنی ارزان جایگزین می‌کند که فقط ارائه‌دهنده اصلی می‌تواند آن را تفسیر کند. در مقابل، فشردگی سمت-سرور در آنتروپیک یک بلوک فشردگی با فیلد محتوای خواندنی بازمی‌گرداند و اجازه می‌دهد دستورالعمل‌های خلاصه‌سازی سفارشی اعمال شود.

جعبه سیاه ابزارهای میزبانی‌شده

جست‌وجوی وب سمت-سرور، نمونه‌ای بارز از این فقدان شفافیت است. در یک ابزار سمت-کلاینت، کاربر مانند یک توسعه‌دهنده عمل می‌کند: او یک تابع جست‌وجو را فراخوانی می‌کند، کوئری، برچسب زمانی و مجموعه کامل نتایج (شامل URLها، عناوین و قطعات متنی) را ثبت می‌کند و سپس آن نتیجه را به مدل می‌فرستد. در این حالت کاربر می‌تواند رتبه‌بندی را بررسی کند، صفحات را دوباره فراخوانی نماید یا همان شواهد را به مدل دیگری ارائه دهد.

اما در جست‌وجوی میزبانی‌شده (Hosted Search) توسط گوگل، OpenAI و آنتروپیک، آن‌ها تنها ارجاعات (Citations) یا URLها را نمایش می‌دهند. آن‌ها یک حلقه ابزار خصوصی (Private Tool Loop) را اجرا می‌کنند. یک URL رکورد پایداری نیست؛ محتوا تغییر می‌کند، ناپدید می‌شود، شخصی‌سازی می‌شود یا پیش از آنکه مدل ببیند، به یک قطعه متنی (Snippet) خاصِ ارائه‌دهنده تبدیل می‌شود.

این موضوع یک نقطه شکست در نوبت بعدی ایجاد می‌کند. اگر کاربر از یک مدل جدید بخواهد که «منبع سوم را با اولی مقایسه کند»، «عدد مورد مناقشه را دوباره بررسی کند» یا «این تحقیق را با استفاده از مدل دیگری ادامه دهد»، مدل جدید ناتوان است. مدل جدید رتبه‌بندی نتایج، قطعات استخراج‌شده، متریال‌های فیلتر شده یا شواهد دقیقی را که مدل اول استفاده کرده بود، دریافت نمی‌کند. ارائه‌دهنده قدیمی حتی اگر درخواست به جای دیگری ارسال شود، همچنان بخشی ضروری از جلسه باقی می‌ماند. جست‌وجوی میزبانی‌شده برای اینکه قابل‌انتقال بماند، نیازمند یک حالت صادرات با دقت کامل (Full-fidelity export mode) شامل هش‌ها (Hashes) و مراحل فیلترینگ است.

پیچیدگی‌های سامانه‌های چندعاملی

این مشکل در سامانه‌های چندعاملی (Multi-Agent Systems) تشدید می‌شود زیرا دیگر تنها یک تاریخچه وجود ندارد، بلکه درختی از جلسات و جریان‌های پیام در جریان است. استفاده از رویکردهای پیشرفته‌تر در این سامانه‌ها، مانند به‌کارگیری دسته‌عاملی برای حذف خطاها، می‌تواند دقت را بالا ببرد اما ریسک حبس داده‌ها در لایه‌های میزبانی‌شده را نیز افزایش می‌دهد. در نسخه بتای چندعاملی OpenAI، سیستم سه نوع آیتم جدید معرفی می‌کند: multi_agent_call ، multi_agent_call_output و agent_message.

پیام‌های بین-عاملی اغلب تنها حاوی encrypted_content هستند. علاوه بر این، وقتی حالت چندعاملی فعال باشد، فشردگی خودکار سمت-سرور به‌طور ضمنی برای هر عامل فعال می‌شود، فارغ از درخواست کلاینت. خلاصه‌های استدلالی پشتیبانی نمی‌شوند و API دستورالعمل‌های ریشه (Root) و زیر-عامل (Sub-agent) را تزریق می‌کند که توسعه‌دهنده نمی‌تواند آن‌ها را ویرایش یا حذف کند. این وضعیت، یک بسته از تفویض اختیار مهروموم‌شده و ارکستراسیون میزبانی‌شده توسط ارائه‌دهنده ایجاد می‌کند.

در ژوئن ۲۰۲۶، یک کامیت در کلاینت متن‌باز Codex با عنوان «رمزنگاری محموله‌های پیام چندعاملی v2» این جریان را تأیید کرد. مدل والد یک آرگومان ابزار متنی رمزنگاری‌شده (به عنوان مثال spawn_agent با یک پیام <ciphertext>) ارسال می‌کند و API آن را به‌صورت داخلی برای مدل فرزند رمزگشایی می‌کند. در رکورد Codex، فیلد InterAgentCommunication.content خالی است. وظیفه دقیقی که به زیر-عامل سپرده شده، در تاریخچه خواندنی غایب است. این بدان معناست که اگر یک عامل فرزند فایلی را اشتباه تغییر دهد، رازی را لو دهد یا از یک فرض غلط پیروی کند، کاربر نمی‌تواند به این سؤال ساده پاسخ دهد: «از آن عامل خواسته شده بود چه کاری انجام دهد؟». اکنون یک Issue باز در Codex برای دریافت یک کپی جهت حسابرسی (Audit copy) برای رفع این مشکل درخواست شده است. این نیاز به شفافیت و حسابرسی در سامانه‌های پیچیده، مشابه چالش‌های شناسایی نشت‌های API است که ابزارهای تحلیل چند-مدلی مانند NexaVerify با دقت بسیار بالاتری نسبت به انسان‌ها شناسایی می‌کنند.

جنگ روی تقطیر مدل‌ها

این حبس کاربر به لایه مدل‌ها و خصومتی نسبت به تقطیر (Distillation) کشیده شده است. در فوریه ۲۰۲۶، آنتروپیک تلاش آزمایشگاه‌هایی مثل DeepSeek، Moonshot و MiniMax برای تقطیر مدل‌هایش را «حملات تقطیری» نامید. شرایط تجاری آن‌ها به‌طور صریح استفاده از سرویس برای آموزش مدل‌های هوش مصنوعی رقیب را ممنوع می‌کند.

در اینجا یک عدم تقارن اخلاقی آشکار وجود دارد. آنتروپیک اذعان می‌کند که تقطیر زمانی که آزمایشگاه‌های پیشرو (Frontier Labs) آن را روی مدل‌های خودشان اجرا می‌کنند، یک «روش آموزشی گسترده و مشروع» است. هم آن‌ها و هم OpenAI روی حجم عظیمی از آثار انسانی در اینترنت عمومی — اغلب بدون اجازه فردی — آموزش می‌بینند و استدلال می‌کنند که این یک «استفاده منصفانه» (Fair Use) است. حتی OpenAI یک گردش‌کار تقطیر API درجه‌یک ارائه می‌دهد تا مدل‌های کوچک‌تر OpenAI را با استفاده از مدل‌های قوی‌تر تنظیم دقیق (Fine-tune) کند.

آن‌ها با مسدود کردن تقطیر برای دیگران، از ایجاد مدل‌های کوچک‌تر، سریع‌تر و محلی که بتوانند به‌صورت آفلاین یا روی سخت‌افزارهای محدود اجرا شوند، جلوگیری می‌کنند. تقطیر باید مسیری برای افزایش رقابت و حفظ قابلیت‌ها در زمانی باشد که یک API بازنشسته می‌شود یا یک سرویس از دسترس خارج می‌گردد.

تعریف یک جلسه قابل‌انتقال

برای اینکه یک جلسه واقعاً قابل‌انتقال باشد، نباید برای بازگشایی یک شناسه، رمزگشایی یک بلوک یا به یاد آوردن یک نتیجه جست‌وجو، به ارائه‌دهنده قدیمی وابسته باشد. قابلیت انتقال یعنی کاربر بتواند دستور const transcript = session.export(); را اجرا کند، اعتبارنامه‌های قدیمی را لغو نماید و سپس دستور session = newProvider.continueFrom(transcript); را اجرا کند.

یک جلسه سالم باید ۵ آزمون بحرانی را پشت سر بگذارد:
۱. بازرسی (Inspection): آیا کاربر می‌تواند ببیند مدل چه دیده است، ابزارها چه کرده‌اند و عامل‌ها به یکدیگر چه گفته‌اند؟
۲. صادر کردن (Export): آیا جلسه، به‌جز آثار قابل دانلود معمولی، به‌طور کامل خودکفا (Self-contained) است؟
۳. بازپخش (Replay): آیا پیاده‌سازی دیگری می‌تواند یک بستر معنایی معادل را بازسازی کند؟
۴. حسابرسی (Audit): آیا یک انسان می‌تواند دلیل یک اقدام سیستم را پس از وقوع توضیح دهد؟
۵. حذف (Deletion): آیا کاربر می‌تواند تمام نسخه‌های سمت-سرور را که جلسه به آن‌ها وابسته است، شناسایی و حذف کند؟

تحلیل تحریریه: تغییر انگیزه‌ها

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

وقتی بستر (Context) قابل‌انتقال باشد، ارائه‌دهندگان باید بر سر کیفیت، قیمت، قابلیت اطمینان و اعتماد رقابت کنند. اما وقتی بستر انباشته شده — که برای یک جلسه تحقیق یا کدنویسی می‌تواند روزها و برای یک دستیار شخصی می‌تواند سال‌ها باشد — تنها توسط یک ارائه‌دهنده قابل تفسیر باشد، هزینه تغییر (Switching Cost) بازدارنده می‌شود. این موضوع انگیزه‌های ناگواری را برای ارائه‌دهنده ایجاد می‌کند.

برای توسعه‌دهندگان، این امر معیار «عملکرد» را تغییر می‌دهد. ما شاهد یک معامله هستیم که در آن عملکرد وضعیت‌دار (Stateful) بهتر، با کنترل کمتر کاربر جفت شده است. وضعیت با دقت بالا (High-fidelity state) مفید است، اما باید یک بهینه‌سازی اختیاری باشد که همراه با یک تحویل خواندنی ارائه شود، نه اینکه جایگزین آن گردد.

راه پیش رو: حداقل آزادی

ما معتقدیم ارائه‌دهندگان و سازندگان عامل‌ها باید مجموعه‌ای از قوانین را برای جلوگیری از حبس کامل کاربر بپذیرند:

• لاگ رویداد محلی باید مرجع (Canonical) باشد: ذخیره‌سازی سروری باید آینه آن باشد، نه جایگزین آن. کلاینت باید بتواند جلسه را بدون شناسه‌های سرور بازسازی کند.

• ذخیره‌سازی باید صریح باشد: گزینه store: false باید پیش‌فرض مستند شده و استفاده از آن آسان باشد.

• پایان معنای مبهم: استدلال رمزنگاری‌شده یا فشردگی باید یک نمایش تحویلی خواندنی و خنثی (بدون وابستگی به ارائه‌دهنده) داشته باشند.

• لاگ کامل ابزارها: ورودی‌ها، خروجی‌ها، شواهد، منشأ (Provenance)، برچسب‌های زمانی و هش‌های محتوا به‌طور دقیق ثبت شوند، نه فقط ارجاعات صیقل‌خورده.

• عامل‌های قابل حسابرسی: وظیفه دقیق خواندنی، پیام‌ها، نتایج، تبار (Lineage)، مدل و مجوزهای ابزار برای هر زیر-عامل ذخیره شود.

• آثار قابل صادر کردن: فایل‌ها، خروجی‌های کانتینر و اسنپ‌شات‌های جست‌وجو باید در آرشیوهای محلی با آدرس‌دهی محتوایی (Content-addressed) قابل دانلود باشند.

• فشردگی قابل بازرسی: یک خلاصه خواندنی و دستورالعمل‌های خاص مورد استفاده برای ایجاد آن، همراه با تبار کافی برای مشاهده موارد حذف شده، بازگردانده شود.

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

گام بعدی شما

• اگر از APIهای store: true استفاده می‌کنید، یک لایه ذخیره‌ساز محلی برای تمام ورودی‌ها و خروجی‌ها (Raw Logs) بسازید تا وابستگی به دیتابیس سازنده را کاهش دهید.
• در پیاده‌سازی‌های چندعاملی، از مدل‌هایی استفاده کنید که اجازه ارسال دستورات شفاف را می‌دهند، نه کپسول‌های رمزنگاری‌شده.
• برای انتقال مدل‌ها، به جای تکیه بر APIهای بسته، روی مدل‌های با وزن‌های باز (Open Weights) سرمایه‌گذاری کنید تا کنترل کامل داده‌های استنتاج را داشته باشید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.