تصور کنید یک برنامهنویس ارشد را استخدام کردهاید که هر بار ترمینال را میبندد، تمام تصمیمات معماری پروژه را فراموش میکند و دوباره اشتباهات قبلی را تکرار میکند. این دقیقاً همان نقطهی ضعفی است که اکثر عاملهای کدنویسی فعلی با آن دستوپنجه نرم میکنند.
به نقل از تحلیل فنی منتشر شده در ۶ ژوئیه ۲۰۲۶ در وبسایت dev.to، موتور ارکستراسیون جدید Sonn این مشکل پایداری حافظه را حل کرده است. این سیستم بهجای اینکه حافظه را یک مسئلهی «جستوجو» ببیند، آن را به عنوان یک مسئلهی «استدلال» تعریف میکند.
اکثر عاملهای فعلی بر بازیابی غیرفعال تکیه دارند؛ ابزارهایی مثل mem0 یا Zep که تکههای متن را ذخیره و جستوجو میکنند. این وضعیت شبیه به کتابخانهای است که مدل فقط زمانی به قوانین آن رجوع میکند که دقیقاً به یاد بیاورد باید بپرسد. در عمل، عامل اغلب کد اشتباه مینویسد — مثلاً اعتبارسنجی در مرزها را فراموش میکند — پیش از آنکه اصلاً به فکر جستوجوی الگوی درست بیفتد.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، مدیریت بستر متن (Context) کلید اصلی کنترل رفتار مدل است. در سیستمهای سنتی، چرخه «ذخیره $\rightarrow$ جستوجو $\rightarrow$ بازگرداندن تکهها» کاملاً غیرفعال است و منتظر میماند تا از آن سوال شود. اما یک عامل کدنویس بهجای سوال کردن، «عمل» میکند؛ بنابراین بازیابیای که فقط در صورت درخواست فعال شود، مانند کتابخانهای است که هیچکس به آن پا نمیگذارد.
برای حل این مشکل، Sonn یک معماری سهلایه را روی یک پایگاهداده SQLite با استفاده از sqlite-vec پیاده کرده است. این رویکرد نیاز به پایگاهدادههای برداری (Vector Database) — مثل یک دفترچه تلفن دیجیتال که کلمات را بر اساس شباهت معنایی دستهبندی میکند — و عملیات پیچیدهی همگامسازی را حذف میکند.
این معماری سهلایه شامل موارد زیر است:
- لایه حافظه (Memory Layer): زیربنای سیستم است که فعالیتها را بهصورت غیرمداخلهگر از طریق هوکها ثبت میکند. بازیابی در اینجا ترکیبی است و از شباهت برداری، جستوجوی تماممتن BM25 و بازرتبهبندی (Reranking) برای یافتن دقیقترین دادهها استفاده میکند.
- فرشته یا استدلال (Angel): یک فرآیند دائمی است که بهجای انتظار برای پرسش، روی دادههای ذخیرهشده فکر میکند. این لایه الگوها را استخراج کرده و تصمیم میگیرد چه زمانی یک الگو ارزش نمایش دادن دارد. برای جلوگیری از سوگیریهای تکجلسهای، چندین بررسی مستقل باید روی یک الگو توافق کنند تا آن الگو ارتقا یابد؛ در غیر این صورت، به عنوان نویز در نظر گرفته میشود.
- نجوا یا رفتار (Whisper): یک مکانیزم هدایت در لحظه است. بهجای استفاده از پرامپتهای حجیم و ایستا — مثل یک دفترچه دستورالعمل غولپیکر که مدل نیمی از آن را نادیده میگیرد — راهنماهای موقعیتی با برچسبهای شرطی ذخیره میشوند و فقط در زمان نیاز فعال میگردند.
بر اساس گزارش dev.to، پرامپتهای ایستا مقیاسپذیر نیستند. وقتی فایلهای تنظیمات (مانند .cursorrules) بیش از حد بزرگ شوند، مدل در نهایت کل متن را نادیده میگیرد. Sonn این روند را وارونه کرده است؛ پرامپت ایستا را به ضروریات شناسیت محدود میکند و قوانین و درسها را به «نجواها» تبدیل میکند.
در شروع هر جلسه یا در هر نوبت که ساختار درخواست مناسب باشد، یک شناسگر سبک میپرسد: «آیا این لحظهای است که راهنمای ذخیرهشده کمک میکند؟». اگر پاسخ مثبت باشد، نجوا بلافاصله پیش از پاسخ مدل به بستر متن تزریق میشود. این کار باعث میشود مدل طوری رفتار کند که انگار قانون را درونی کرده است، بدون اینکه نیاز به تنظیم دقیق (Fine-tuning) — شبیه به دادن تخصص پوست به یک پزشک عمومی برای دقیقتر شدن در یک حوزه — یا تغییر وزنهای مدل باشد. این تغییر، هوش مصنوعی را از یک پایگاهداده به یک مدرس تبدیل میکند.
با این حال، سیستم با چالشی به نام «شلیک اشتباه» (Misfire) روبروست؛ یعنی زمانی که نجوا در لحظهای نامناسب تزریق شود. هزینهی این خطا نامتقارن است: یک نجوا درست کمی اعتماد میسازد، اما یک نجوای غلط که جریان کاری برنامهنویس را قطع کند، هزینهی زیادی دارد.
تیم Sonn استدلال میکند که هدف، رسیدن به خطای صفر نیست، زیرا این موضوع سیستم را بیش از حد محتاط و بیفایده میکند. در عوض، استاندارد این است که نجوای غلط باید بهراحتی قابل نادیده گرفتن باشد؛ یعنی غیرمداخلهگر و بدون مسدود کردن مسیر. هزاران تلنگر آرام و درست، ارزشمندتر از یک رکورد بینقص هستند.
این چرخش معماری نشان میدهد که آیندهی هوش مصنوعی عاملمحور (Agentic AI) در پنجرههای متنی (Context Window) بزرگتر نیست، بلکه در ارکستراسیون هوشمندانهتر این بستر است. با انتقال «تفکر» دربارهی حافظه به خارج از حلقهی اصلی استنتاج (Inference) — لحظهای که مدل واقعاً جواب تولید میکند و شبیه به خودِ آشپزی است، نه دورهی آموزش — توسعهدهندگان میتوانند امنیت را حفظ کرده و همزمان مدل را با قراردادهای خاص پروژه همراستا کنند.
گام بعدی شما
- بررسی کنید که آیا پشتهی RAG فعلی شما بیش از حد غیرفعال است و فقط منتظر پرسش میماند یا خیر.
- مستندات sonn.dev را برای مقایسهی تزریق بستر متن در لحظه با استراتژی پرامپتنویسی فعلی خود مطالعه کنید.
- ارزیابی کنید که کدام قوانین تکرارشونده در پروژهتان میتواند به یک «نجوا» تبدیل شود تا حجم پرامپت سیستمی شما کاهش یابد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو